Network Working Group T. Mistretta
Internet-Draft Juniper Networks
Expires: January 7, 2007 I. Goyret
Lucent Technologies
N. McGill
M. Townsley
G. Weber
cisco Systems
July 6, 2006
RADIUS & L2TP Extended NAS-Port AVPs
draft-ietf-l2tpext-radius-ext-nas-port-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 7, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document defines additional Layer 2 Transfer Protocol (L2TP) and
Remote Authentication Dial In User Service (RADIUS) Attribute-Value
Pairs (AVPs) to communicate Network Access Server (NAS) informational
Mistretta, et al. Expires January 7, 2007 [Page 1]
Internet-Draft RADIUS & L2TP AVPs July 2006
ASCII text and port usage information between L2TP peers during call
establishment to facilitate authorization, accounting and logging.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Specification of Requirements . . . . . . . . . . . . . . 4
2. L2TP Extended NAS-Port AVPs . . . . . . . . . . . . . . . . . 4
3. RADIUS Extended NAS-Port AVP . . . . . . . . . . . . . . . . . 7
3.1. Table of Attributes . . . . . . . . . . . . . . . . . . . 10
3.2. Interactions with other RADIUS attributes . . . . . . . . 10
3.3. Diameter Compatibility . . . . . . . . . . . . . . . . . . 11
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Mistretta, et al. Expires January 7, 2007 [Page 2]
Internet-Draft RADIUS & L2TP AVPs July 2006
1. Introduction
It is often desirable to send adjunct and port usage information from
the L2TP Access Concentrator (LAC) to the L2TP Network Server (LNS)
during call setup. Such information may be used for:
Logging
to describe system and port related information in a human-
readable, vendor-specific form.
Authorization
to restrict users to particular given access types or
interfaces.
Accounting
to determine port usage on a per-user basis, for example, via
RADIUS accounting [RFC2866].
Auditing
to ensure that the LNS vendor is being allocated the proper
contractual resources by the LAC vendor.
L2TP [RFC2661] already has a Physical Channel ID AVP that may be used
to provide port usage information. However, its usefulness is
limited in multi-vendor LAC/LNS environments where the vendor-
specific bit encoding used for this AVP will often not be understood
by L2TP peers from differing vendors.
This makes the task of de-constructing the Physical Channel ID AVP
contents at the LNS for (RADIUS) authorization/accounting server
extremely difficult.
Additionally, it is length limited to 4 octets of information which
is inadequate in access servers supporting multiple access types and
large numbers of ports.
This document defines extensions whereby such port usage information
may be transferred in a vendor-independent fashion between mixed-
vendor LAC and LNSs, thus facilitating detailed and matching logging
and accounting at each end of the tunnel.
Mistretta, et al. Expires January 7, 2007 [Page 3]
Internet-Draft RADIUS & L2TP AVPs July 2006
The following diagram depicts a typical dialin scenario for L2TP with
RADIUS accounting servers at the LNS:
Authen/Accounting
RADIUS server
|
|
|
|
intranet - - - - LNS - - - - - internet - - - -LAC - - - -client
<----------------------------->
L2TP tunnel
1.1. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. L2TP Extended NAS-Port AVPs
The following collection of Extended NAS-Port AVPs, attribute types
TBD, allow detailed logging and port usage information to be
transmitted between L2TP peers. This format is common to all
Extended NAS-Port AVPs; only the Attribute Type is different for
each:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | Vendor ID (IETF) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type | Attribute Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[until Length is reached]... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NOTES:
o Each Extended NAS-Port AVP is encoded as the IETF Vendor ID 0
o Each AVP has defined behaviour associated with it, namely:
Mistretta, et al. Expires January 7, 2007 [Page 4]
Internet-Draft RADIUS & L2TP AVPs July 2006
Relayed AVPs: See [I-D.ietf-l2tpext-tunnel-switching] for
definition. In summary, if this AVP is received by a node
participating in a multi-hop scenario, then the AVP MUST be
copied as-is to the next hop. A locally generated AVP MAY be
generated if required and appended in the outbound message to
the next hop.
Stackable AVPs: See [I-D.ietf-l2tpext-tunnel-switching] for
definition. In summary, if this AVP is received by a
participating in a multi-hop scenario, then the AVP MUST be
copied as-is to the next hop. A locally generated AVP MUST be
generated and appended in the outbound message to the next hop.
If no value is appropriate then an AVP of Length 6 (minimum AVP
length) MUST be appended.
o The value of all bits MUST be preserved in any AVPs copied.
The following are valid values for the Attribute Type field:
TBD - Platform Information
This AVP, length 0-253, allows a UTF-8 string to be sent with a
human-readable description of the platform.
Examples: "Model 457", or "TPX-1700".
This information MUST NOT be parsed and as such termination
action MUST NOT be based on the contents of this attribute.
The M-bit MUST be set to 0. The H-bit MAY be set based on the
current L2TP node's policy. This AVP is a stackable AVP.
TBD - System Identification Information
This AVP, length 0-253, allows a UTF-8 string to be sent with a
human-readable description of the router's identification
within the provider's network.
Examples: "CommCo LAC", or "SuperProvider AS".
This information MUST NOT be parsed and as such termination
action MUST NOT be based on the contents of this attribute.
The M-bit MUST be set to 0. The H-bit MAY be set based on the
current L2TP node's policy. This AVP is a stackable AVP.
Mistretta, et al. Expires January 7, 2007 [Page 5]
Internet-Draft RADIUS & L2TP AVPs July 2006
TBD - Call Information
This AVP, length 0-253, allows a UTF-8 string to be sent with a
human-readable description of the call.
Examples could include "Atlanta POP", or "Neptune-304x using
frame2 module".
This information MUST NOT be parsed and as such termination
action MUST NOT be based on the contents of this attribute.
The M-bit MUST be set to 0. The H-bit MAY be set based on the
current L2TP node's policy. This AVP is a stackable AVP.
TBD - Software Information
This AVP, length 0-253, allows a UTF-8 string to be sent with a
human-readable description of the software running on the
platform.
Examples: "Version 4-0.12(c)-2", or "Rev 10.4.2-beta".
This information MUST NOT be parsed and as such termination
action MUST NOT be based on the contents of this attribute.
The M-bit MUST be set to 0. The H-bit MAY be set based on the
current L2TP node's policy. This AVP is a stackable AVP.
TBD - Vendor-Information AVP
This AVP, length 0-253, allows a UTF-8 string to be sent with a
human-readable description of the vendor of the platform.
Examples: "Hudson Computer Systems", or "Lightning Networks".
This information MUST NOT be parsed and as such termination
action MUST NOT be based on the contents of this attribute.
The M-bit MUST be set to 0. The H-bit MAY be set based on the
current L2TP node's policy. This AVP is a stackable AVP.
TBD - Shelf
TBD - Slot
TBD - Module
TBD - Adapter
TBD - Interface
Mistretta, et al. Expires January 7, 2007 [Page 6]
Internet-Draft RADIUS & L2TP AVPs July 2006
TBD - Line
TBD - Port
TBD - Channel
TBD - Physical Interface
TBD - Physical Sub-interface
TBD - Virtual Path
TBD - Virtual Circuit
TBD - Virtual Lan
TBD - Virtual Interface
TBD - Virtual Sub-interface
This AVP, length 0 or 4, is an octet integer value,
representing a specific Extended NAS-Port AVP value at this
L2TP node.
The M-bit MUST be set to 0. The H-bit MAY be set based on the
current L2TP node's policy. These AVPs are relayed AVPs.
All Extended NAS-Port AVPs SHOULD be used in conjunction with the
port type values defined in [RFC2058] and [RFC2059].
For incoming calls, these AVPs are valid either on ICRQ or ICCN.
If sent on both, the ICCN AVP MUST override the ICRQ value. For
outgoing calls, the AVPs are valid on OCRP and OCCN, with similar
override behavior.
3. RADIUS Extended NAS-Port AVP
The RADIUS Extended NAS-Port AVP closely resembles its L2TP counter-
part and allows detailed port-usage/accounting information to be
provided in multi-vendor environments.
The key distinction is that for RADIUS we have a single new attribute
with multiple Extensions, encoded as string attribute-value pairs of
the form "<extension>=<value>". These Extensions exist in a one-to-
one mapping with the previously defined L2TP AVPs.
The following format is common to all Extended NAS-Port AVPs; only
the Extension string name is different for each:
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|Extnd. NAS-Port| Length | "extension=value"...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
Mistretta, et al. Expires January 7, 2007 [Page 7]
Internet-Draft RADIUS & L2TP AVPs July 2006
TBD for Extended NAS-Port
Length
>= 3
Value
This attribute is of string format, with the following definition:
"<extension>=<value>"
Where "<extension>" is one of the following case-sensitive
strings:
"platform" - Platform Information
This AVP, length 3-255, allows a UTF-8 string to be sent
with a human-readable description of the platform.
Examples: "platform=Model 457", or "platform=TPX-1700".
This information MUST NOT be parsed and as such termination
action MUST NOT be based on the contents of this attribute.
"system-id" - System Identification Information
This AVP, length 3-255, allows a UTF-8 string to be sent
with a human-readable description of the routers
identification within the provider's network.
Examples: "system-id=CommCo LAC", or "system-
id=SuperProvider AS".
This information MUST NOT be parsed and as such termination
action MUST NOT be based on the contents of this attribute.
"call" - Call Information
This AVP, length 3-255, allows a UTF-8 string to be sent
with a human-readable description of the call.
Examples could include "call=Atlanta POP", or "call=Neptune-
304x using frame2 module".
This information MUST NOT be parsed and as such termination
action MUST NOT be based on the contents of this attribute.
Mistretta, et al. Expires January 7, 2007 [Page 8]
Internet-Draft RADIUS & L2TP AVPs July 2006
"software" - Software Information
This AVP, length 3-255, allows a UTF-8 string to be sent
with a human-readable description of the software running on
the platform.
Examples: "software=Version 4-0.12(c)-2", or "software=Rev
10.4.2-beta".
This information MUST NOT be parsed and as such termination
action MUST NOT be based on the contents of this attribute.
"vendor" - Vendor-Information AVP
This AVP, length 3-255, allows a UTF-8 string to be sent
with a human-readable description of the vendor of the
platform.
Examples: "vendor=Hudson Computer Systems", or
"vendor=Lightning Networks".
This information MUST NOT be parsed and as such termination
action MUST NOT be based on the contents of this attribute.
"shelf" - Shelf
"slot" - Slot
"module" - Module
"adapter" - Adapter
"intf" - Interface
"line" - Line
"port" - Port
"channel" - Channel
"phys-intf" - Physical Interface
"phys-subintf" - Physical Sub-interface
"vpi" - Virtual Path
"vci" - Virtual Circuit
"vlan" - Virtual Lan
"vintf" - Virtual Interface
"vsubintf" - Virtual Sub-interface
These AVPs, length 3-255, allow a UTF-8 string to be sent
with the integer value of the relevant Extended NAS-Port
AVP.
Examples: "vpi=3", "vci=0", "vlan=12345"
For L2TP tunnels, these attributes MUST be used, if available, to log
information obtained via the corresponding L2TP Extended NAS-Port
Mistretta, et al. Expires January 7, 2007 [Page 9]
Internet-Draft RADIUS & L2TP AVPs July 2006
AVPs. See section 2.
To cater for L2TP multi-hop environments, if an L2TP Extended NAS-
Port AVP is available, but without a corresponding value, then the
associated RADIUS AVP MUST be encoded as "<extension>"
The sequence of RADIUS Extended NAS-Port AVPs MUST follow that of any
L2TP Extended NAS-Port AVPs received.
For scenarios without L2TP, these attributes MAY also be used in
preference over the RADIUS NAS-Port attribute to provide finer
granularity during accounting.
Where an attribute was not received from L2TP it is considered
optional to send.
For non L2TP environments, all Extensions are optional.
All strings are NOT null terminated.
Any numbers encoded as the value part of the Extension MUST be as
strings with a minimum value of "0". Only unsigned values MUST be
sent.
The use of the character '"' in this document is included purely as a
visual aid in identifying the beginning and end of strings. It MUST
NOT be included as part of the end format, unless specifically
encoded as data within the AVP Value section.
3.1. Table of Attributes
The following table provides a guide to which attributes may be found
in which kinds of packets, and in what quantity.
For Authentication:
Request Accept Reject Challenge Attribute
0+ 0 0 0 Extended NAS-Port
For Accounting:
Request Response Attribute
0+ 0 Extended NAS-Port
3.2. Interactions with other RADIUS attributes
Extended NAS-Port overlaps in functionality with NAS-Port. However,
whereas the encoding of NAS-Port is limited to 32 bits and often
Mistretta, et al. Expires January 7, 2007 [Page 10]
Internet-Draft RADIUS & L2TP AVPs July 2006
vendor specific, Extended NAS-Port is not. NAS-Port may still
continue to be used but preference SHOULD be given to information
received in Extended NAS-Port.
If a RADIUS vendor detects conflicting values between NAS-Port and
Extended NAS-Port, Extended NAS-Port SHOULD be taken as the more
accurate value.
3.3. Diameter Compatibility
The RADIUS Extended NAS-Port attribute defined in this section may be
translated for transmission via Diameter [RFC3588] by AAA Translation
Agents as described by Section 9 of [I-D.ietf-aaa-diameter-nasreq].
Such a translation might represent the extended NAS-Port information
as a single Diameter attribute of type Grouped. Each RADIUS
<extension> valued defined in section 3 would map to a new Diameter
attribute, all of which would be encapsulated in a single Grouped
Extended-NAS-Port attribute. The ABNF for such an attribute might
look like:
Extended-NAS-Port ::= < AVP Header: TBD >
[ NAS-Port-Platform ]
[ NAS-Port-System-Id ]
[ NAS-Port-Call ]
[ NAS-Port-Software ]
[ NAS-Port-Vendor ]
[ NAS-Port-Shelf ]
[ NAS-Port-Slot ]
...
4. Security Considerations
This document describes mechanisms where port termination information
can be sent between L2TP peers. Users of these AVPs should have the
understanding that any information sent could be used for malicious
purposes. If this is a concern, any of the L2TP Extended NAS-Port
List AVPs MAY be hidden.
5. IANA Considerations
The "Call Information", "Platform Information", "Software
Information", and "Vendor Information" AVPs needs to be assigned an
IETF "Attribute Type" from the "Control Message Attribute Value
Pairs" maintained by IANA for L2TP.
Mistretta, et al. Expires January 7, 2007 [Page 11]
Internet-Draft RADIUS & L2TP AVPs July 2006
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
RFC 2661, August 1999.
6.2. Informative References
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2058] Rigney, C., Rubens, A., Simpson, W., and S. Willens,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2058, January 1997.
[RFC2059] Rigney, C., "RADIUS Accounting", RFC 2059, January 1997.
[I-D.ietf-l2tpext-tunnel-switching]
Jain, V., "PPP over L2TP Tunnel Switching",
draft-ietf-l2tpext-tunnel-switching-07 (work in progress),
June 2006.
[I-D.ietf-aaa-diameter-nasreq]
Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application",
draft-ietf-aaa-diameter-nasreq-17 (work in progress),
July 2004.
Mistretta, et al. Expires January 7, 2007 [Page 12]
Internet-Draft RADIUS & L2TP AVPs July 2006
Authors' Addresses
Tom Mistretta
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
US
Email: tmistretta@juniper.net
Ignacio Goyret
Lucent Technologies
1701 Harbor Bay Parkway
Alameda, CA 94502
Email: igoyret@lucent.com
Neil McGill
cisco Systems
3rd Floor
96 Commercial Street
Edinburgh, EH6 6LX
UK
Email: nmcgill@cisco.com
W. Mark Townsley
cisco Systems
Email: mark@townsley.net
Greg Weber
cisco Systems
10850 Murdock Road
Knoxville, TN 37932
US
Email: gdweber@cisco.com
Mistretta, et al. Expires January 7, 2007 [Page 13]
Internet-Draft RADIUS & L2TP AVPs July 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Mistretta, et al. Expires January 7, 2007 [Page 14]