Network Working Group William Palter Internet-Draft Pipal Systems Category: Standards Track W. Mark Townsley <draft-ietf-l2tpext-sesinfo-04.txt> cisco Systems Ignacio Goyret Lucent Technologies Suhail Nanji Redback Networks February 2002 L2TP Session Information "sesinfo" Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. 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- ietf-l2tpext-sesinfo-04.txt> and expires August 2002. Please send comments to the L2TP mailing list (l2tpext@ietf.org). Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document defines additional L2TP AVPs that may be used during session or control connection establishment to provide additional node and port information for accounting and debugging use. Townsley, et al. Standards Track [Page 1]
INTERNET DRAFT SESINFO February 2002 Contents Status of this Memo.......................................... 1 1. Introduction.............................................. 2 2. AVPs...................................................... 2 4. IANA Considerations....................................... 5 5. Security Considerations................................... 6 6. Contacts.................................................. 6 7. References................................................ 7 1. Introduction By design, an L2TP LNS is insulated from many of the details of the interface on which the session arrives before being tunneled. This abstraction is further mitigated when an L2TP session is directed to an additional tunnel via an L2TP Tunnel Switching (a.k.a. "Multihop") node. While not necessary for the proper operation of the tunneled session itself, it may be desirable for L2TP node identity, LAC media, and port information to be provided in a descriptive format for accounting or debugging use. It should be noted that the Framing Type and Bearer Type AVPs defined in [RFC2661] are designed simply to allow the LNS to tailor the PPP options it uses for the media the session is running over. They are not intended to fully describe the originating port type or LAC. Further, at the time this document is being written, there there is no standardized mechanism for keeping this information intact as a session traverses L2TP tunnel switching nodes. None of the AVPs described in this document should have any effect on either the functioning of the tunnel or the parameters used in negotiating PPP parameters. They should only be used for logging, session limiting, accounting, and/or debugging purposes. 2. AVPs Each of the following AVPs are defined in a list format which is designed to allow propogation of information forward by receiving and appending values to each AVP list when passing through an L2TP tunnel switching node or LAC. Values in each list AVP are correlated based upon their actual position in the list, thus care must be taken that entries remain balanced properly for all lists propogated. In the event that a value is unknown for a given list, a suitable "default" Townsley, et al. Standards Track [Page 2]
INTERNET DRAFT SESINFO February 2002 or "unknown" value (defined within the context of each AVP) MUST be inserted in any list AVPs before propogating. Each list entry is appended such that the last entry corresponds to the most recent sending node, and all preceding values are for "downstream" L2TP nodes. It is possible that all L2TP nodes did not participate in the Session Information extensions, in which case the entire list of L2TP nodes may not be accurately reflected at the final location. It is permissible, though not recommended, to implement only a portion of the AVP Lists defined in this document. However, if any of the AVPs defined in this document are implemented, the Port Type List MUST be among them. The Port Type List is the basis for correlating values in all other lists defined in this document. For example, if the Port Type List AVP (section 2.1) contained a single entry, and no other AVPs defined in this document are sent, this would be valid for a typical LAC aiming to implement the minimum requirements of this document. A more sophisticated L2TP tunnel switching node may then use the information in the single Port Type List AVP and entry, together with information from other sources (such as other AVPs defined outside this document), to populate the remaining AVP lists defined here. More specific information on this is decribed in the individual AVP definitions throughout this document. 2.1 Port Type List (icrq, iccn) The Port Type List AVP is encoded as IETF Vendor ID 0, attribute TBD. The Value is a list of Port Types, using the same values that are used in RADIUS [RFC2058][RFC2059]. Each time an L2TP node forwards a session, a new value MUST be appended to this list before it is propogated. Note that the last port type (or first if there is only one value in the list) always represents the port type of the sender of the control message containing this AVP. Townsley, et al. Standards Track [Page 3]
INTERNET DRAFT SESINFO February 2002 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Type 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Type 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Port Type n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.2 Channel ID List (icrq, iccn) The Channel ID List AVP is encoded as the IETF Vendor ID 0, Attribute TBD. The Value is a list of four octet values, representing the Channel ID of each node that the session has passed through. Each time an L2TP node forwards a session, a new value MUST be appended to this list before it is propogated. If there is no appropriate value, the reserved value 0 MUST be appended as a place holder. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Channel ID 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Channel ID n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- This AVP is analogous to the Physical Channel ID AVP defined in [RFC2661], except that it is allowed to grow as a list. As with the Port Type List, the last item in the list always represents the Channel ID of the sender of this AVP. Thus, the last value in the list should be identical to the Physical Channel ID AVP at any given node. In the event a tunnel switching node has implemented the extensions defined in this document but does not receive a Channel ID List from its downstream node, it MUST first copy the value received in the Physical Channel ID AVP at Session establishment into the Channel ID List before adding its own Channel ID to the list. 2.3 L2TP Node Name List (sccrq, icrq, iccn) Townsley, et al. Standards Track [Page 4]
INTERNET DRAFT SESINFO February 2002 The LAC Name List AVP is encoded as Vendor ID 0, Attribute TBD. The Value is a list of counted strings, with the octet prior to each string indicating the length of the string that follows it. Each time an L2TP node forwards a session, a new value MUST be appended to this list before it is propogated. If there is no appropriate value, then a length of 0 MUST be inserted for the L2TP Node Name Length as a place holder. The L2TP Node Name should be a human readable value, analogous or equivalent to the value sent the the L2TP Hostname AVP defined in [RFC2661]. Human readable text in all messages MUST be provided in the UTF-8 charset using the Default Language [RFC2277]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length 0 | L2TP Node Name 0 (1-255 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length 1 | L2TP Node Name 1 (1-255 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ length n | L2TP Node Name n (1-255 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This AVP is analogous to the Hostname AVP defined in [RFC2661], except that it is allowed to grow as a list, and may be present at session as well as control connection startup. The last item in the list always represents the name of the sender of the message containing this AVP. Thus, the last value MAY be identical to that in the Hostname AVP. In the event a tunnel switching node has implemented the extensions defined in this document but does not receive a LAC Node Name List from its downstream node, it MUST first copy the value received in the Hostname AVP at Control Connection establishment into the LAC Node Name List before adding its own LAC Node Name to the list. 4. IANA Considerations This document requires three new "AVP Attributes" to be assigned through IETF Consensus [RFC2434] as indicated in Section 10.1 of [RFC2661]. These are: Port Type List (section 2.1) Channel ID List (section 2.2) Townsley, et al. Standards Track [Page 5]
INTERNET DRAFT SESINFO February 2002 L2TP Node Name List (section 2.3) This document defines no additional number spaces for IANA to manage. 5. Security Considerations This document describes a method for propogating additional information about interfaces and equipment information by which a PPP session arrives before and after tunneling via L2TP. While it is not obvious how this information could be used for malicious purposes, if it somehow was used to comprimise security then implementation of the mechanisms described in this document increase the number of times this information is made available on the network. AVP hiding, described in [RFC2661] MAY be used to help mitigate this, though it is not widely regarded as cryptographically secure. [RFC3193] describes a more robust method for securing L2TP in general, and should be used to encrypt all L2TP messages if access to the information sent within the AVPs described in this document is of concern. 6. Contacts Ignacio Goyret Lucent Technologies 1701 Harbor Bay Parkway Alameda, CA 94502 igoyret@lucent.com William Palter Pipal Systems palter.ietf@zev.net W. Mark Townsley cisco Systems 7025 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709 mark@townsley.net Suhail Nanji RedBack Networks 1389 Moffett Park Drive Sunnyvale, CA 94089 suhail@redback.com Townsley, et al. Standards Track [Page 6]
INTERNET DRAFT SESINFO February 2002 7. References [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, [RFC2058] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote Authentication Dial In User Service (RADIUS)," RFC 2058, January 1997 [RFC2059] C. Rigney, RADIUS Accounting, RFC 2059, January 1997 [RFC3193] B. Patel, B. Aboba, W. Dixon, G. Zorn, S. Booth, "Securing L2TP Using IPsec," RFC 3193, November 2001 Townsley, et al. Standards Track [Page 7]
