Network Working Group T. Mistretta Internet Draft Juniper Networks Category: Standards Track draft-mistretta-l2tp-infomsg-01.txt I. Goyret Lucent Technologies N. McGill M. Townsley cisco Systems November 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-01.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 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-01.txt [Page 1]
INTERNET DRAFT L2TP Call Information Messages November 2002 debugging purposes. Contents Status of this Memo .......................................... 1 Abstract ..................................................... 1 1. Introduction .............................................. 2 1.1 Specification of Requirements ......................... 3 2. L2TP AVPs ................................................. 3 2.1 Common AVP Properties ................................. 3 2.2 Call-Information AVP .................................. 4 2.3 Platform-Information AVP .............................. 4 2.4 Software Information AVP .............................. 4 2.5 Vendor-Information AVP ................................ 5 3. RADIUS attributes ......................................... 5 3.1 Call-Information RADIUS attribute ..................... 5 3.2 Platform-Information RADIUS attribute ................. 6 3.3 Software-Information RADIUS attribute ................. 7 3.4 Vendor-Information RADIUS attribute ................... 8 4. Security Considerations ................................... 9 5. References ................................................ 9 6. IANA Considerations ....................................... 10 7. Authors' Addresses ........................................ 10 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 Mistretta, et al. draft-mistretta-l2tp-infomsg-01.txt [Page 2]
INTERNET DRAFT L2TP Call Information Messages November 2002 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]. 2. L2TP AVPs 2.1 Common AVP Properties All of the AVPs share the following traits: 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. The treatment of these AVPs through a L2TP tunnel switch follows the "stacking" model introduced in the draft RFC [SESINFO]. This model allows propagation of information from earlier L2TP nodes while at the same time providing a capability to append new information at each hop. A "list" format is defined for the AVPs, where the last entry corresponds to the most recent sending node, and all preceding values are for previous nodes. In the event that an AVP is received where there is no local value to append, an "empty" entry (one whose string length is zero) MUST be appended. Interim L2TP tunnel switches can only append to existing AVPs that are being passed through. They MUST NOT initiate a new AVP if one does not already exist. This is done so that Mistretta, et al. draft-mistretta-l2tp-infomsg-01.txt [Page 3]
INTERNET DRAFT L2TP Call Information Messages November 2002 information across the AVPs can be correlated and reflected accurately at the final location. 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. All AVPs has the following format, the only difference being that the attribute type is particular to the specific AVP being used. 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] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length 0 | Information String 0 (1-253 octets) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length 1 | Information String 1 (1-253 octets) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length N | Information String N (1-253 octets) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.2 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. Examples could include "Atlanta POP", or "Neptune-304x using frame2 module". 2.3 Platform-Information AVP The Platform Information AVP, Attribute type TBD, allows a UTF-8 string to be sent with a human readable description of the platform. Examples could be "Model 457", or "TPX-1700". 2.4 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. Examples could be "Version 4-0.12(c)-2" or "Rev 10.4.2-beta". Mistretta, et al. draft-mistretta-l2tp-infomsg-01.txt [Page 4]
INTERNET DRAFT L2TP Call Information Messages November 2002 2.5 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. Examples: "Hudson Computer Systems", or "Lightning Networks". 3. RADIUS attributes 3.1 Call-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-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 Mistretta, et al. draft-mistretta-l2tp-infomsg-01.txt [Page 5]
INTERNET DRAFT L2TP Call Information Messages November 2002 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. 3.2 Platform-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 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 Mistretta, et al. draft-mistretta-l2tp-infomsg-01.txt [Page 6]
INTERNET DRAFT L2TP Call Information Messages November 2002 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 Length set to 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. 3.3 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, Mistretta, et al. draft-mistretta-l2tp-infomsg-01.txt [Page 7]
INTERNET DRAFT L2TP Call Information Messages November 2002 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 Length set to 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. 3.4 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 Mistretta, et al. draft-mistretta-l2tp-infomsg-01.txt [Page 8]
INTERNET DRAFT L2TP Call Information Messages November 2002 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 Length set to 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. 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. Mistretta, et al. draft-mistretta-l2tp-infomsg-01.txt [Page 9]
INTERNET DRAFT L2TP Call Information Messages November 2002 [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. [SESINFO] Palter, William et al, "L2TP Session Information", draft-ietf- l2tpext-sesinfo-04.txt, February 2002. 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 Tom Mistretta Juniper Networks 10 Technology Park Drive Westford, MA 01886 Email: tmistretta@juniper.net Ignacio Goyret Lucent Technologies 1701 Harbor Bay Parkway Alameda, CA 94502 Email: igoyret@lucent.com Mistretta, et al. draft-mistretta-l2tp-infomsg-01.txt [Page 10]