idnits 2.17.1 draft-mistretta-l2tp-infomsg-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 40 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 12 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2002) is 7826 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 103, but not defined == Missing Reference: 'IETF' is mentioned on line 155, but not defined == Missing Reference: 'TBD' is mentioned on line 157, but not defined == Missing Reference: 'RFC2867' is mentioned on line 348, but not defined == Missing Reference: 'RFC2869' is mentioned on line 206, but not defined == Unused Reference: 'RFC2866' is defined on line 412, but no explicit reference was found in the text == Unused Reference: 'BCP14' is defined on line 420, but no explicit reference was found in the text == Unused Reference: 'BCP26' is defined on line 426, but no explicit reference was found in the text == Unused Reference: 'STD51' is defined on line 430, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2866 ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2434 (ref. 'BCP26') (Obsoleted by RFC 5226) Summary: 6 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group T. Mistretta 2 Internet Draft Juniper Networks 3 Category: Standards Track 4 draft-mistretta-l2tp-infomsg-01.txt I. Goyret 5 Lucent Technologies 7 N. McGill 8 M. Townsley 9 cisco Systems 11 November 2002 13 L2TP Call Information Messages 15 Status of this Memo 17 This document is an Internet-Draft and is subject to all provisions 18 of section 10 of RFC 2026 [BCP9]. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress". 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 The distribution of this memo is unlimited. It is filed as "draft- 37 mistretta-l2tp-infomsg-01.txt" and expires April 30, 2003. Please 38 send comments to the L2TP mailing list (l2tp@l2tp.net). 40 Copyright (C) The Internet Society (2002). All Rights Reserved. 42 Abstract 44 This document defines additional L2TP AVPs to communicate 45 informational ASCII text messages between the tunnel endpoints during 46 call establishment. The message contents are not interpreted by the 47 receiving endpoint in any way but can be used for logging or 48 debugging purposes. 50 Contents 52 Status of this Memo .......................................... 1 54 Abstract ..................................................... 1 56 1. Introduction .............................................. 2 57 1.1 Specification of Requirements ......................... 3 59 2. L2TP AVPs ................................................. 3 60 2.1 Common AVP Properties ................................. 3 61 2.2 Call-Information AVP .................................. 4 62 2.3 Platform-Information AVP .............................. 4 63 2.4 Software Information AVP .............................. 4 64 2.5 Vendor-Information AVP ................................ 5 66 3. RADIUS attributes ......................................... 5 67 3.1 Call-Information RADIUS attribute ..................... 5 68 3.2 Platform-Information RADIUS attribute ................. 6 69 3.3 Software-Information RADIUS attribute ................. 7 70 3.4 Vendor-Information RADIUS attribute ................... 8 72 4. Security Considerations ................................... 9 74 5. References ................................................ 9 76 6. IANA Considerations ....................................... 10 78 7. Authors' Addresses ........................................ 10 80 8. Full Copyright Statement .................................. 11 82 9. Expiration Date ........................................... 12 84 1. Introduction 86 It is often desirable to send adjunct information from the LAC to the 87 LNS during call setup. Some such information can be circuit 88 oriented, describing the attributes of the circuit interface. Other 89 information could describe the peer itself. In either case, the 90 information is typically used for for logging or debugging. L2TP 91 [RFC2661] already has a Physical Channel ID AVP that provides a 92 limited logging capability during call setup. It is limited in that 93 its length is only 4 octets. This draft defines extensions whereby 94 human-readable ASCII strings are sent during call setup. The strings 95 are typed, but uninterpreted by L2TP. Their sole purposes are to 96 enhance logging and debugging capabilities in L2TP. 98 1.1 Specification of Requirements 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 2. L2TP AVPs 106 2.1 Common AVP Properties 108 All of the AVPs share the following traits: 110 The AVPs are not mandatory (the M bit MUST be set to 0). The AVP 111 SHOULD NOT be hidden (the H-bit SHOULD be set to 0). 113 The information strings themselves MUST be human readable, they 114 SHOULD contain UTF-8 encoded 10646 [RFC2279] characters using the 115 Default Language [BCP18]. 117 The strings are not null-terminated. Valid lengths are between 1 118 and 253 octets, so it can fit on a RADIUS attribute. 120 The format of the information strings are purposely not defined. 121 The contents of the string MUST NOT be parsed nor interpreted by 122 the receiving L2TP endpoint. 124 As mentioned previously, possible uses of the strings are output 125 to a console or logging to a server. If the strings were to be 126 used in RADIUS accounting or authentication requests, it SHOULD be 127 mapped into corresponding RADIUS attributes defined in section 3. 129 The treatment of these AVPs through a L2TP tunnel switch follows 130 the "stacking" model introduced in the draft RFC [SESINFO]. This 131 model allows propagation of information from earlier L2TP nodes 132 while at the same time providing a capability to append new 133 information at each hop. A "list" format is defined for the AVPs, 134 where the last entry corresponds to the most recent sending node, 135 and all preceding values are for previous nodes. In the event 136 that an AVP is received where there is no local value to append, 137 an "empty" entry (one whose string length is zero) MUST be 138 appended. Interim L2TP tunnel switches can only append to existing 139 AVPs that are being passed through. They MUST NOT initiate a new 140 AVP if one does not already exist. This is done so that 141 information across the AVPs can be correlated and reflected 142 accurately at the final location. 144 For incoming calls, the AVPs are valid either on ICRQ or ICCN. If 145 sent on both, the ICCN AVPs override the ICRQ values. For 146 outgoing calls, the AVPs are valid on OCRP and OCCN, with similar 147 override behavior. 149 All AVPs has the following format, the only difference being that 150 the attribute type is particular to the specific AVP being used. 152 0 1 2 3 153 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 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 |M|H| rsvd | Length | Vendor Id [IETF] | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Attribute Type [TBD] | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Length 0 | Information String 0 (1-253 octets) ... | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Length 1 | Information String 1 (1-253 octets) ... | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | ... 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Length N | Information String N (1-253 octets) ... | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 2.2 Call-Information AVP 170 The Call Information AVP, Attribute type TBD, allows a UTF-8 string 171 to be sent with a human readable description of the call. Examples 172 could include "Atlanta POP", or "Neptune-304x using frame2 module". 174 2.3 Platform-Information AVP 176 The Platform Information AVP, Attribute type TBD, allows a UTF-8 177 string to be sent with a human readable description of the platform. 178 Examples could be "Model 457", or "TPX-1700". 180 2.4 Software Information AVP 182 The Software Information AVP, Attribute type TBD, allows a UTF-8 183 string to be sent with a human readable description of the software 184 running on the platform. Examples could be "Version 4-0.12(c)-2" or 185 "Rev 10.4.2-beta". 187 2.5 Vendor-Information AVP 189 The Vendor Information AVP, Attribute type TBD, allows a UTF-8 string 190 to be sent with a human readable description of the vendor of the 191 platform. Examples: "Hudson Computer Systems", or "Lightning 192 Networks". 194 3. RADIUS attributes 196 3.1 Call-Information RADIUS attribute 198 Description 199 This Attribute indicates text which MAY be supplied to the RADIUS 200 [RFC2865] server during authentication (Access-Request), 201 accounting (Accounting-Request) or tunnel-link accounting 202 [RFC2867] for the purposes of logging only. The message MUST NOT 203 be parsed and as such termination action MUST NOT be based on the 204 contents of this attribute. 206 In contrast to RADIUS Connect-Info [RFC2869], Call-Information 207 indicates where a call terminated, not what it terminated as. For 208 example, Call-Information MAY be used to report NAS module, slot, 209 port in a vendor specific format. Connect-Info MAY be used to 210 specify negotiated compression, connection protocol etc... 212 Multiple Call-Information's MAY be included and if any are 213 displayed, they MUST be displayed in the same order as they appear 214 in the packet. 216 A summary of the Call-Information Attribute format is shown below. 217 The fields are transmitted from left to right. 219 0 1 2 220 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 222 | Type | Length | Text ... 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 225 Type 227 TBD for Call-Information. 229 Length 231 >= 3 233 Text 235 The Text field is one or more octets, and its contents are 236 implementation dependent. It is intended to be human readable, 237 and MUST NOT affect operation of the protocol. It is recommended 238 that the message contain UTF-8 encoded 10646 [RFC2279] characters 239 using the Default Language [BCP18]. The string is not null- 240 terminated. 242 For L2TP calls, this attribute SHOULD be used to log information 243 obtained via Call-Information AVPs. See section 2. 245 3.2 Platform-Information RADIUS attribute 247 Description 248 This Attribute indicates text which MAY be supplied to the RADIUS 249 [RFC2865] server during authentication (Access-Request), 250 accounting (Accounting-Request) or tunnel accounting [RFC2867] for 251 the purposes of logging only. The message MUST NOT be parsed and 252 as such termination action MUST NOT be based on the contents of 253 this attribute. 255 Multiple Platform-Information's MAY be included and if any are 256 displayed, they MUST be displayed in the same order as they appear 257 in the packet. 259 A summary of the Platform-Information Attribute format is shown 260 below. The fields are transmitted from left to right. 262 0 1 2 263 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 265 | Type | Length | Text ... 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 268 Type 270 TBD for Platform-Information. 272 Length 274 >= 2 276 Text 278 The Text field is one or more octets, and its contents are 279 implementation dependent. It is intended to be human readable, 280 and MUST NOT affect operation of the protocol. It is recommended 281 that the message contain UTF-8 encoded 10646 [RFC2279] characters 282 using the Default Language [BCP18]. The string is not null- 283 terminated. 285 For L2TP tunnels, this attribute MUST be used to log information 286 obtained via Platform-Information AVPs. See section 2. To cater for 287 L2TP multihop environments, if no Platform-Information is available, 288 then this attribute MUST be used with Length set to 2. Such 289 attributes indicate that no Platform-Information was available for a 290 particular node within the L2TP tunnel path. The sequence of RADIUS 291 Platform-Information attributes MUST follow that of any L2TP 292 Platform-Information AVPS received. 294 3.3 Software-Information RADIUS attribute 296 Description 297 This Attribute indicates text which MAY be supplied to the RADIUS 298 [RFC2865] server during authentication (Access-Request), 299 accounting (Accounting-Request) or tunnel accounting [RFC2867] for 300 the purposes of logging only. The message MUST NOT be parsed and 301 as such termination action MUST NOT be based on the contents of 302 this attribute. 304 Multiple Software-Information's MAY be included and if any are 305 displayed, they MUST be displayed in the same order as they appear 306 in the packet. 308 A summary of the Software-Information Attribute format is shown 309 below. The fields are transmitted from left to right. 311 0 1 2 312 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 314 | Type | Length | Text ... 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 317 Type 319 TBD for Software-Information. 321 Length 323 >= 2 325 Text 327 The Text field is one or more octets, and its contents are 328 implementation dependent. It is intended to be human readable, 329 and MUST NOT affect operation of the protocol. It is recommended 330 that the message contain UTF-8 encoded 10646 [RFC2279] characters 331 using the Default Language [BCP18]. The string is not null- 332 terminated. 334 For L2TP tunnels, this attribute MUST be used to log information 335 obtained via Software-Information AVPs. See section 2. To cater for 336 L2TP multihop environments, if no Software-Information is available, 337 then this attribute MUST be used with Length set to 2. Such 338 attributes indicate that no Software-Information was available for a 339 particular node within the L2TP tunnel path. The sequence of RADIUS 340 Software-Information attributes MUST follow that of any L2TP 341 Software-Information AVPS received. 343 3.4 Vendor-Information RADIUS attribute 345 Description 346 This Attribute indicates text which MAY be supplied to the RADIUS 347 [RFC2865] server during authentication (Access-Request), 348 accounting (Accounting-Request) or tunnel accounting [RFC2867] for 349 the purposes of logging only. The message MUST NOT be parsed and 350 as such termination action MUST NOT be based on the contents of 351 this attribute. 353 Multiple Vendor-Information's MAY be included and if any are 354 displayed, they MUST be displayed in the same order as they appear 355 in the packet. 357 A summary of the Vendor-Information Attribute format is shown 358 below. The fields are transmitted from left to right. 360 0 1 2 361 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 363 | Type | Length | Text ... 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 366 Type 368 TBD for Vendor-Information. 370 Length 372 >= 2 374 Text 376 The Text field is one or more octets, and its contents are 377 implementation dependent. It is intended to be human readable, 378 and MUST NOT affect operation of the protocol. It is recommended 379 that the message contain UTF-8 encoded 10646 [RFC2279] characters 380 using the Default Language [BCP18]. The string is not null- 381 terminated. 383 For L2TP tunnels, this attribute MUST be used to log information 384 obtained via Vendor-Information AVPs. See section 2. To cater for 385 L2TP multihop environments, if no Vendor-Information is available, 386 then this attribute MUST be used with Length set to 2. Such 387 attributes indicate that no Vendor-Information was available for a 388 particular node within the L2TP tunnel path. The sequence of RADIUS 389 Vendor-Information attributes MUST follow that of any L2TP Vendor- 390 Information AVPS received. 392 4. Security Considerations 394 This document describes mechanisms where arbitrary, human-readable 395 information can be sent between L2TP peers. User of these AVPs 396 should have the understanding that any information sent is completely 397 insecure. If the information sent could be used for malicious 398 purposes, the use of the features described in this document 399 increases the possibility of that information being compromised. In 400 particular, since the text message AVP SHOULD NOT be hidden, even 401 that security feature cannot be employed. 403 5. References 405 [RFC2661] Townsley W., et al., "Layer Two Tunneling Protocol (L2TP)", 406 RFC 2661, August 1999. 408 [RFC2865] C. Rigney, S. Willens, A. Rubens, W. Simpson, "Remote 409 Authentication Dial In User Service (RADIUS)", RFC 2865, June 410 2000. 412 [RFC2866] C. Rigney, "RADIUS Accounting", RFC 2866, June 2000. 414 [RFC2279] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 415 2279, January 1998. 417 [BCP9] Bradner, S., "The Internet Standards Process -- Revision 3", 418 BCP 9, RFC 2026, October 1996. 420 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate 421 Requirement Levels", BCP 14, RFC 2119, March 1997. 423 [BCP18] H. Alvestrand, "IETF Policy on Character Sets and Languages", 424 BCP 18, RFC 2277, January 1998. 426 [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 427 Considerations Section in RFCs", BCP 26, RFC 2434, October 428 1998. 430 [STD51] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 431 1661, July 1994. 433 [SESINFO] Palter, William et al, "L2TP Session Information", draft-ietf- 434 l2tpext-sesinfo-04.txt, February 2002. 436 6. IANA Considerations 438 The "Call Information", "Platform Information", "Software 439 Information", and "Vendor Information" AVPs needs to be assigned an 440 IETF "Attribute Type" from the "Control Message Attribute Value 441 Pairs" maintained by IANA for L2TP. 443 7. Authors' Addresses 445 Tom Mistretta 446 Juniper Networks 447 10 Technology Park Drive 448 Westford, MA 01886 450 Email: tmistretta@juniper.net 452 Ignacio Goyret 453 Lucent Technologies 454 1701 Harbor Bay Parkway 455 Alameda, CA 94502 457 Email: igoyret@lucent.com