Network Working Group N. McGill Internet Draft Category: Standards Track cisco Systems draft-nmcgill-l2tp-radius-ext-nas-port-00.txt October 2002 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-00.txt" and expires April 30, 2003. Please send comments to the L2TP mailing list (l2tp@l2tp.net). Copyright (C) The Internet Society (2002). 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) port usage information between L2TP peers during call establishment to McGill, et al.draft-nmcgill-l2tp-radius-ext-nas-port-00.txt [Page 1] INTERNET DRAFT RADIUS & L2TP Extended NAS-Port AVPs October 2002 facilitate authorization and accounting. McGill, et al.draft-nmcgill-l2tp-radius-ext-nas-port-00.txt [Page 2] INTERNET DRAFT RADIUS & L2TP Extended NAS-Port AVPs October 2002 Contents Status of this Memo .......................................... 1 Abstract ..................................................... 1 1. Introduction .............................................. 3 1.1 Specification of Requirements ......................... 4 2. L2TP Extended NAS-Port AVPs ............................... 4 3. RADIUS Extended NAS-Port AVP .............................. 6 4. Security Considerations ................................... 8 5. References ................................................ 8 6. IANA Considerations ....................................... 8 7. Authors' Addresses ........................................ 8 1. Introduction It is often desirable to send port usage information from the L2TP Access Concentrator (LAC) to the L2TP Network Server (LNS) during call setup. Such information may be used for authorization purposes, to restrict users to given access types or interfaces. Additionally this information is invaluable in port-based accounting/auditing to ensure that the LNS vendor is being allocated the proper contractual resources by the LAC vendor. An example of such accounting might be via RADIUS [RFC2865] [3]. L2TP [RFC2661] [1] already has a Physical Channel ID AVP that may be used to provide such 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 deconstructing the Physical Channel ID AVP contents at the LNS for (RADIUS) authorization/accounting server extremely difficult. 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 accounting at each end of the tunnel. McGill, et al.draft-nmcgill-l2tp-radius-ext-nas-port-00.txt [Page 3] INTERNET DRAFT RADIUS & L2TP Extended NAS-Port AVPs October 2002 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 port usage information to be transmitted between L2TP peers. The following 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Each Extended NAS-Port AVP is encoded as the IETF Vendor ID 0, The following are valid values for the Attribute Type field: TBD - Shelf TBD - Slot TBD - Module TBD - Adapter TBD - Interface TBD - Line TBD - Port TBD - Channel TBD - Virtual Path TBD - Virtual Circuit TBD - Virtual Lan TBD - Physical Interface TBD - Physical Sub-interface TBD - Virtual Interface TBD - Virtual Sub-interface McGill, et al.draft-nmcgill-l2tp-radius-ext-nas-port-00.txt [Page 4] INTERNET DRAFT RADIUS & L2TP Extended NAS-Port AVPs October 2002 The Attribute Value is a four octet integer value, representing a specific Extended NAS-Port AVP value at this L2TP node. If an L2TP node, which is participating in a multi-hop scenario, receives any Extended NAS-Port AVP, it MUST copy the AVP to the next hop as part of session establishment before encoding its own NAS-Post List AVP of the same type. If no information is available for that AVP at the multi-hop node, the node MUST encode this AVP without the Attribute Value. None of the NAS-Port List AVPs are mandatory. The M-bit MUST be set to 0." Any of the Extended NAS-Port AVPs MAY be hidden. 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-00.txt [Page 5] INTERNET DRAFT RADIUS & L2TP Extended NAS-Port AVPs October 2002 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 Sub-Types, encoded as string attribute-value pairs of the form "=". These Sub-Types exist in a one-to-one mapping with the previously defined L2TP AVPs. The following format is common to all Extended NAS-Port Sub-Type AVPs; only the Sub-Type string name 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 +-+-+-+-+-+-+-+-+ |Extnd. NAS-Port| +-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | "sub-type=value" string +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... Type TBD for Extended NAS-Port. Length >= 3 Value This attribute is of string format, with the following definition: "=" McGill, et al.draft-nmcgill-l2tp-radius-ext-nas-port-00.txt [Page 6] INTERNET DRAFT RADIUS & L2TP Extended NAS-Port AVPs October 2002 Where "" is one of the following case-sensitive string values: "shelf" "slot" "module" "adapter" "interface" "line" "port" "channel" "virtual-path" "virtual-circuit" "virtual-lan" "physical-interface" "physical-sub-interface" "virtual-interface" "virtual-sub-interface" And where "" is encoded as an integer. Some example encodings might be: "virtual-path=3" "virtual-circuit=100" For L2TP tunnels, this attribute 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 AVP MUST follow that of any L2TP Extended NAS-Port AVPS received. For scenarios without L2TP, this attribute MAY also be used in preference over the RADIUS NAS-Port attribute to provide finer granularity during accounting. This attribute MAY be included in accounting or authentication requests, and the resulting strings may be parsed and acted upon, if required. e.g. for port-based authorization. The string is not null terminated, and spaces and other formatting characters MUST NOT be included. McGill, et al.draft-nmcgill-l2tp-radius-ext-nas-port-00.txt [Page 7] INTERNET DRAFT RADIUS & L2TP Extended NAS-Port AVPs October 2002 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. 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 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 (2002). All Rights Reserved. McGill, et al.draft-nmcgill-l2tp-radius-ext-nas-port-00.txt [Page 8] INTERNET DRAFT RADIUS & L2TP Extended NAS-Port AVPs October 2002 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 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-00.txt [Page 9]