Network Working Group T. Mistretta Internet Draft Unisphere Networks Category: Standards Track draft-mistretta-l2tp-infomsg-00.txt I. Goyret Lucent Technologies N. McGill M. Townsley cisco Systems June 2002 L2TP Call Information Messages Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 10 of RFC 2026 [BCP9]. 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- mistretta-l2tp-infomsg-00.txt" and expires October 31, 2002. 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 L2TP AVPs to communicate informational ASCII text messages between the tunnel endpoints during call establishment. The message contents are not interpreted by the receiving endpoint in any way but can be used for logging or Mistretta, et al. draft-mistretta-l2tp-infomsg-00.txt [Page 1]
INTERNET DRAFT L2TP Call Information Messages June 2002 debugging purposes. Mistretta, et al. draft-mistretta-l2tp-infomsg-00.txt [Page 2]
INTERNET DRAFT L2TP Call Information Messages June 2002 Contents Status of this Memo .......................................... 1 Abstract ..................................................... 1 1. Introduction .............................................. 3 1.1 Specification of Requirements ......................... 3 2. L2TP AVPs ................................................. 4 3. RADIUS attributes ......................................... 5 4. Security Considerations ................................... 10 5. References ................................................ 10 6. IANA Considerations ....................................... 10 7. Authors' Addresses ........................................ 11 8. Full Copyright Statement .................................. 11 9. Expiration Date ........................................... 12 1. Introduction It is often desirable to send adjunct information from the LAC to the LNS during call setup. Some such information can be circuit oriented, describing the attributes of the circuit interface. Other information could describe the peer itself. In either case, the information is typically used for for logging or debugging. L2TP [RFC2661] already has a Physical Channel ID AVP that provides a limited logging capability during call setup. It is limited in that its length is only 4 octets. This draft defines extensions whereby human-readable ASCII strings are sent during call setup. The strings are typed, but uninterpreted by L2TP. Their sole purposes are to enhance logging and debugging capabilities in L2TP. 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]. Mistretta, et al. draft-mistretta-l2tp-infomsg-00.txt [Page 3]
INTERNET DRAFT L2TP Call Information Messages June 2002 2. L2TP AVPs All of the AVPs share the following attributes: The AVPs are not mandatory (the M bit MUST be set to 0). The AVP SHOULD NOT be hidden (the H-bit SHOULD be set to 0). The information strings themselves MUST be human readable, they SHOULD contain UTF-8 encoded 10646 [RFC2279] characters using the Default Language [BCP18]. The strings are not null-terminated. Valid lengths are between 1 and 253 octets, so it can fit on a RADIUS attribute. The format of the information strings are purposely not defined. The contents of the string MUST NOT be parsed nor interpreted by the receiving L2TP endpoint. As mentioned previously, possible uses of the strings are output to a console or logging to a server. If the strings were to be used in RADIUS accounting or authentication requests, it SHOULD be mapped into corresponding RADIUS attributes defined in section 3. If a session that contains these AVPs goes through a L2TP tunnel switch, the AVPs MUST be "sent through" unchanged. That is, the original AVPs MUST be included on the new call established from the tunnel switch to the next peer. For incoming calls, the AVPs are valid either on ICRQ or ICCN. If sent on both, the ICCN AVPs override the ICRQ values. For outgoing calls, the AVPs are valid on OCRP and OCCN, with similar override behavior. 2a Call-Information AVP The Call Information AVP, Attribute type TBD, allows a UTF-8 string to be sent with a human readable description of the call. The AVP has the following format: 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 [TBD] | Call information string ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2b Platform-Information AVP Mistretta, et al. draft-mistretta-l2tp-infomsg-00.txt [Page 4]
INTERNET DRAFT L2TP Call Information Messages June 2002 The Platform Information AVP, Attribute type TBD, allows a UTF-8 string to be sent with a human readable description of the platform. The AVP has the following format: 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 [TBD] | Platform information string ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2c Software Information AVP The Software Information AVP, Attribute type TBD, allows a UTF-8 string to be sent with a human readable description of the software running on the platform. The AVP has the following format: 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 [TBD] | Software information string ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2a Vendor-Information AVP The Vendor Information AVP, Attribute type TBD, allows a UTF-8 string to be sent with a human readable description of the vendor of the platform. The AVP has the following format: 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 [TBD] | Vendor information string ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3. RADIUS attributes 3a. Call-Information RADIUS attribute Description This Attribute indicates text which MAY be supplied to the RADIUS [RFC2865] server during authentication (Access-Request), Mistretta, et al. draft-mistretta-l2tp-infomsg-00.txt [Page 5]
INTERNET DRAFT L2TP Call Information Messages June 2002 accounting (Accounting-Request) or tunnel-link accounting [RFC2867] for the purposes of logging only. The message MUST NOT be parsed and as such termination action MUST NOT be based on the contents of this attribute. In contrast to RADIUS Connect-Info [RFC2869], Call-Information indicates where a call terminated, not what it terminated as. For example, Call-Information MAY be used to report NAS module, slot, port in a vendor specific format. Connect-Info MAY be used to specify negotiated compression, connection protocol etc... Multiple Call-Information's MAY be included and if any are displayed, they MUST be displayed in the same order as they appear in the packet. A summary of the Call-Information Attribute format is shown below. The fields are transmitted from left to right. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | Text ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type TBD for Call-Information. Length >= 3 Text The Text field is one or more octets, and its contents are implementation dependent. It is intended to be human readable, and MUST NOT affect operation of the protocol. It is recommended that the message contain UTF-8 encoded 10646 [RFC2279] characters using the Default Language [BCP18]. The string is not null- terminated. For L2TP calls, this attribute SHOULD be used to log information obtained via Call-Information AVPs. See section 2. 3b. Platform-Information RADIUS attribute Description This Attribute indicates text which MAY be supplied to the RADIUS Mistretta, et al. draft-mistretta-l2tp-infomsg-00.txt [Page 6]
INTERNET DRAFT L2TP Call Information Messages June 2002 [RFC2865] server during authentication (Access-Request), accounting (Accounting-Request) or tunnel accounting [RFC2867] for the purposes of logging only. The message MUST NOT be parsed and as such termination action MUST NOT be based on the contents of this attribute. Multiple Platform-Information's MAY be included and if any are displayed, they MUST be displayed in the same order as they appear in the packet. A summary of the Platform-Information Attribute format is shown below. The fields are transmitted from left to right. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | Text ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type TBD for Platform-Information. Length >= 2 Text The Text field is one or more octets, and its contents are implementation dependent. It is intended to be human readable, and MUST NOT affect operation of the protocol. It is recommended that the message contain UTF-8 encoded 10646 [RFC2279] characters using the Default Language [BCP18]. The string is not null- terminated. For L2TP tunnels, this attribute MUST be used to log information obtained via Platform-Information AVPs. See section 2. To cater for L2TP multihop environments, if no Platform-Information is available, then this attribute MUST be used with L=2. Such attributes indicate that no Platform-Information was available for a particular node within the L2TP tunnel path. The sequence of RADIUS Platform- Information attributes MUST follow that of any L2TP Platform- Information AVPS received. Mistretta, et al. draft-mistretta-l2tp-infomsg-00.txt [Page 7]
INTERNET DRAFT L2TP Call Information Messages June 2002 3c. Software-Information RADIUS attribute Description This Attribute indicates text which MAY be supplied to the RADIUS [RFC2865] server during authentication (Access-Request), accounting (Accounting-Request) or tunnel accounting [RFC2867] for the purposes of logging only. The message MUST NOT be parsed and as such termination action MUST NOT be based on the contents of this attribute. Multiple Software-Information's MAY be included and if any are displayed, they MUST be displayed in the same order as they appear in the packet. A summary of the Software-Information Attribute format is shown below. The fields are transmitted from left to right. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | Text ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type TBD for Software-Information. Length >= 2 Text The Text field is one or more octets, and its contents are implementation dependent. It is intended to be human readable, and MUST NOT affect operation of the protocol. It is recommended that the message contain UTF-8 encoded 10646 [RFC2279] characters using the Default Language [BCP18]. The string is not null- terminated. For L2TP tunnels, this attribute MUST be used to log information obtained via Software-Information AVPs. See section 2. To cater for L2TP multihop environments, if no Software-Information is available, then this attribute MUST be used with L=2. Such attributes indicate that no Software-Information was available for a particular node within the L2TP tunnel path. The sequence of RADIUS Software- Information attributes MUST follow that of any L2TP Software- Information AVPS received. Mistretta, et al. draft-mistretta-l2tp-infomsg-00.txt [Page 8]
INTERNET DRAFT L2TP Call Information Messages June 2002 3d. Vendor-Information RADIUS attribute Description This Attribute indicates text which MAY be supplied to the RADIUS [RFC2865] server during authentication (Access-Request), accounting (Accounting-Request) or tunnel accounting [RFC2867] for the purposes of logging only. The message MUST NOT be parsed and as such termination action MUST NOT be based on the contents of this attribute. Multiple Vendor-Information's MAY be included and if any are displayed, they MUST be displayed in the same order as they appear in the packet. A summary of the Vendor-Information Attribute format is shown below. The fields are transmitted from left to right. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | Text ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type TBD for Vendor-Information. Length >= 2 Text The Text field is one or more octets, and its contents are implementation dependent. It is intended to be human readable, and MUST NOT affect operation of the protocol. It is recommended that the message contain UTF-8 encoded 10646 [RFC2279] characters using the Default Language [BCP18]. The string is not null- terminated. For L2TP tunnels, this attribute MUST be used to log information obtained via Vendor-Information AVPs. See section 2. To cater for L2TP multihop environments, if no Vendor-Information is available, then this attribute MUST be used with L=2. Such attributes indicate that no Vendor-Information was available for a particular node within the L2TP tunnel path. The sequence of RADIUS Vendor-Information attributes MUST follow that of any L2TP Vendor-Information AVPS received. Mistretta, et al. draft-mistretta-l2tp-infomsg-00.txt [Page 9]
INTERNET DRAFT L2TP Call Information Messages June 2002 4. Security Considerations This document describes mechanisms where arbitrary, human-readable information can be sent between L2TP peers. User of these AVPs should have the understanding that any information sent is completely insecure. If the information sent could be used for malicious purposes, the use of the features described in this document increases the possibility of that information being compromised. In particular, since the text message AVP SHOULD NOT be hidden, even that security feature cannot be employed. 5. References [RFC2661] Townsley W., et al., "Layer Two Tunneling Protocol (L2TP)", RFC 2661, August 1999. [RFC2865] C. Rigney, S. Willens, A. Rubens, W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2866] C. Rigney, "RADIUS Accounting", RFC 2866, June 2000. [RFC2279] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [BCP9] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [BCP18] H. Alvestrand, "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998. [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [STD51] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. 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 Mistretta, et al. draft-mistretta-l2tp-infomsg-00.txt [Page 10]
INTERNET DRAFT L2TP Call Information Messages June 2002 Pairs" maintained by IANA for L2TP. 7. Authors' Addresses Tom Mistretta Unisphere Networks 10 Technology Park Drive Westford, MA 01886 Email: tmistretta@unispherenetworks.com 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 7025 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709 Email: mark@townsley.net 8. Full Copyright Statement Copyright (C) The Internet Society 2002. 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 Mistretta, et al. draft-mistretta-l2tp-infomsg-00.txt [Page 11]
INTERNET DRAFT L2TP Call Information Messages June 2002 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. 9. Expiration Date This memo is filed as "draft-mistretta-l2tp-infomsg-00.txt" and expires October 31, 2002. Mistretta, et al. draft-mistretta-l2tp-infomsg-00.txt [Page 12]