Network Working Group N. McGill Internet-Draft cisco Systems Category: Standards Track T. Mistretta draft-nmcgill-l2tp-radius-ext-nas-port-01.txt Juniper Networks G. Weber cisco Systems October 2003 RADIUS & L2TP Extended NAS-Port AVPs Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 10 of RFC 2026. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html The distribution of this memo is unlimited. It is filed as "draft- nmcgill-l2tp-radius-ext-nas-port-02.txt" and expires April 30, 2004. Please send comments to the L2TP mailing list (l2tpext@ietf.org). Copyright (C) The Internet Society (2003). All Rights Reserved. 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 ASCII text and port usage information between L2TP peers during call establishment to facilitate authorization, accounting and logging. McGill, et al.draft-nmcgill-l2tp-radius-ext-nas-port-02.txt [Page 1] INTERNET-DRAFT RADIUS & L2TP Extended NAS-Port AVPs October 2003 Contents Status of this Memo .......................................... 1 Abstract ..................................................... 1 1. Introduction .............................................. 3 1.1 Specification of Requirements ......................... 4 2. L2TP Extended NAS-Port AVPs ............................... 5 3. RADIUS Extended NAS-Port AVP .............................. 9 4. Security Considerations ................................... 13 5. References ................................................ 13 6. IANA Considerations ....................................... 13 7. Authors' Addresses ........................................ 13 McGill, et al.draft-nmcgill-l2tp-radius-ext-nas-port-02.txt [Page 2] INTERNET-DRAFT RADIUS & L2TP Extended NAS-Port AVPs October 2003 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 [RFC2865] [3]. Auditing, to ensure that the LNS vendor is being allocated the proper contractual resources by the LAC vendor. L2TP [RFC2661] [1] 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 draft 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. The following diagram depicts a typical dialin scenariou for L2TP with RADIUS accounting servers at the LNS: McGill, et al.draft-nmcgill-l2tp-radius-ext-nas-port-02.txt [Page 3] INTERNET-DRAFT RADIUS & L2TP Extended NAS-Port AVPs October 2003 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]. McGill, et al.draft-nmcgill-l2tp-radius-ext-nas-port-02.txt [Page 4] INTERNET-DRAFT RADIUS & L2TP Extended NAS-Port AVPs October 2003 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: - Each Extended NAS-Port AVP is encoded as the IETF Vendor ID 0, - Each AVP has defined behaviour associated with it, namely: Passthrough AVPs: 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: 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 MUST be generated and appended in the outbound message to the next hop. If no value is appropriate then an AVP of Length 0 MUST be appended. - The value of all bits MUST be preserved in any AVPs copied. McGill, et al.draft-nmcgill-l2tp-radius-ext-nas-port-02.txt [Page 5] INTERNET-DRAFT RADIUS & L2TP Extended NAS-Port AVPs October 2003 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 providers 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. 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. McGill, et al.draft-nmcgill-l2tp-radius-ext-nas-port-02.txt [Page 6] INTERNET-DRAFT RADIUS & L2TP Extended NAS-Port AVPs October 2003 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. McGill, et al.draft-nmcgill-l2tp-radius-ext-nas-port-02.txt [Page 7] INTERNET-DRAFT RADIUS & L2TP Extended NAS-Port AVPs October 2003 TBD - Shelf TBD - Slot TBD - Module TBD - Adapter TBD - Interface 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 passthrough AVPs. All Extended NAS-Port AVPs SHOULD be used in conjunction with the draft RFC ["sesinfo"] [2] Port Type List AVP to allow correlation between port type and usage. 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. McGill, et al.draft-nmcgill-l2tp-radius-ext-nas-port-02.txt [Page 8] INTERNET-DRAFT RADIUS & L2TP Extended NAS-Port AVPs October 2003 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 "=". 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 TBD for Extended NAS-Port. Length >= 3 Value This attribute is of string format, with the following definition: "=" Where "" is one of the following case-sensitive strings: McGill, et al.draft-nmcgill-l2tp-radius-ext-nas-port-02.txt [Page 9] INTERNET-DRAFT RADIUS & L2TP Extended NAS-Port AVPs October 2003 "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 providers 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. "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. McGill, et al.draft-nmcgill-l2tp-radius-ext-nas-port-02.txt [Page 10] INTERNET-DRAFT RADIUS & L2TP Extended NAS-Port AVPs October 2003 "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 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 "" The sequence of RADIUS Extended NAS-Port AVPs MUST follow that of any L2TP Extended NAS-Port AVPs received. McGill, et al.draft-nmcgill-l2tp-radius-ext-nas-port-02.txt [Page 11] INTERNET-DRAFT RADIUS & L2TP Extended NAS-Port AVPs October 2003 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 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 McGill, et al.draft-nmcgill-l2tp-radius-ext-nas-port-02.txt [Page 12] INTERNET-DRAFT RADIUS & L2TP Extended NAS-Port AVPs October 2003 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 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. 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. References [RFC2661] Townsley W., et al., "Layer Two Tunneling Protocol (L2TP)", RFC 2661, August 1999. [DRAFT] Townsley W., et al., "L2TP Session Information "sesinfo"", draft- ietf-l2tpext-sesinfo-04.txt, February 2002 [RFC2865] Network Working Group "Remote Authentication Dial In User Service (RADIUS)." 6. 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. 7. Authors' Addresses McGill, et al.draft-nmcgill-l2tp-radius-ext-nas-port-02.txt [Page 13] INTERNET-DRAFT RADIUS & L2TP Extended NAS-Port AVPs October 2003 Greg Weber cisco Systems 10850 Murdock Road Knoxville, TN 37932 Email: gdweber@cisco.com Tom Mistretta Juniper Networks 10 Technology Park Drive Westford, MA 01886 Email: tmistretta@juniper.net Neil McGill cisco Systems 3rd Floor 96 Commercial Street Edinburgh, EH6 6LX, UK Email: nmcgill@cisco.com Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING McGill, et al.draft-nmcgill-l2tp-radius-ext-nas-port-02.txt [Page 14] INTERNET-DRAFT RADIUS & L2TP Extended NAS-Port AVPs October 2003 TASK FORCE DISCLAIMS 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." McGill, et al.draft-nmcgill-l2tp-radius-ext-nas-port-02.txt [Page 15]