idnits 2.17.1 draft-ietf-l2tpext-sesinfo-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 6 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 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 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 == Line 204 has weird spacing: '... length n ...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (February 2002) is 8099 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: 'RFC2661' is mentioned on line 243, but not defined == Unused Reference: 'RFC1661' is defined on line 277, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 280, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2058 (Obsoleted by RFC 2138) ** Obsolete normative reference: RFC 2059 (Obsoleted by RFC 2139) Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group William Palter 3 Internet-Draft Pipal Systems 4 Category: Standards Track W. Mark Townsley 5 cisco Systems 6 Ignacio Goyret 7 Lucent Technologies 8 Suhail Nanji 9 Redback Networks 10 February 2002 12 L2TP Session Information "sesinfo" 14 Status of this Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet- Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 The distribution of this memo is unlimited. It is filed as and expires August 2002. Please send 37 comments to the L2TP mailing list (l2tpext@ietf.org). 39 Copyright Notice 41 Copyright (C) The Internet Society (2002). All Rights Reserved. 43 Abstract 45 This document defines additional L2TP AVPs that may be used during 46 session or control connection establishment to provide additional 47 node and port information for accounting and debugging use. 49 Contents 51 Status of this Memo.......................................... 1 53 1. Introduction.............................................. 2 55 2. AVPs...................................................... 2 57 4. IANA Considerations....................................... 5 59 5. Security Considerations................................... 6 61 6. Contacts.................................................. 6 63 7. References................................................ 7 65 1. Introduction 67 By design, an L2TP LNS is insulated from many of the details of the 68 interface on which the session arrives before being tunneled. This 69 abstraction is further mitigated when an L2TP session is directed to 70 an additional tunnel via an L2TP Tunnel Switching (a.k.a. "Multihop") 71 node. While not necessary for the proper operation of the tunneled 72 session itself, it may be desirable for L2TP node identity, LAC 73 media, and port information to be provided in a descriptive format 74 for accounting or debugging use. 76 It should be noted that the Framing Type and Bearer Type AVPs defined 77 in [RFC2661] are designed simply to allow the LNS to tailor the PPP 78 options it uses for the media the session is running over. They are 79 not intended to fully describe the originating port type or LAC. 80 Further, at the time this document is being written, there there is 81 no standardized mechanism for keeping this information intact as a 82 session traverses L2TP tunnel switching nodes. None of the AVPs 83 described in this document should have any effect on either the 84 functioning of the tunnel or the parameters used in negotiating PPP 85 parameters. They should only be used for logging, session limiting, 86 accounting, and/or debugging purposes. 88 2. AVPs 90 Each of the following AVPs are defined in a list format which is 91 designed to allow propogation of information forward by receiving and 92 appending values to each AVP list when passing through an L2TP tunnel 93 switching node or LAC. Values in each list AVP are correlated based 94 upon their actual position in the list, thus care must be taken that 95 entries remain balanced properly for all lists propogated. In the 96 event that a value is unknown for a given list, a suitable "default" 97 or "unknown" value (defined within the context of each AVP) MUST be 98 inserted in any list AVPs before propogating. 100 Each list entry is appended such that the last entry corresponds to 101 the most recent sending node, and all preceding values are for 102 "downstream" L2TP nodes. It is possible that all L2TP nodes did not 103 participate in the Session Information extensions, in which case the 104 entire list of L2TP nodes may not be accurately reflected at the 105 final location. 107 It is permissible, though not recommended, to implement only a 108 portion of the AVP Lists defined in this document. However, if any of 109 the AVPs defined in this document are implemented, the Port Type List 110 MUST be among them. The Port Type List is the basis for correlating 111 values in all other lists defined in this document. 113 For example, if the Port Type List AVP (section 2.1) contained a 114 single entry, and no other AVPs defined in this document are sent, 115 this would be valid for a typical LAC aiming to implement the minimum 116 requirements of this document. A more sophisticated L2TP tunnel 117 switching node may then use the information in the single Port Type 118 List AVP and entry, together with information from other sources 119 (such as other AVPs defined outside this document), to populate the 120 remaining AVP lists defined here. More specific information on this 121 is decribed in the individual AVP definitions throughout this 122 document. 124 2.1 Port Type List (icrq, iccn) 126 The Port Type List AVP is encoded as IETF Vendor ID 0, attribute 127 TBD. The Value is a list of Port Types, using the same values that 128 are used in RADIUS [RFC2058][RFC2059]. Each time an L2TP node 129 forwards a session, a new value MUST be appended to this list 130 before it is propogated. 132 Note that the last port type (or first if there is only one value 133 in the list) always represents the port type of the sender of the 134 control message containing this AVP. 136 0 1 2 3 137 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 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | Port Type 0 | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Port Type 1 | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | .... 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 Port Type n | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 2.2 Channel ID List (icrq, iccn) 150 The Channel ID List AVP is encoded as the IETF Vendor ID 0, 151 Attribute TBD. The Value is a list of four octet values, 152 representing the Channel ID of each node that the session has 153 passed through. Each time an L2TP node forwards a session, a new 154 value MUST be appended to this list before it is propogated. If 155 there is no appropriate value, the reserved value 0 MUST be 156 appended as a place holder. 158 0 1 2 3 159 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 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Channel ID 0 | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | .... 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 Channel ID n | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 168 This AVP is analogous to the Physical Channel ID AVP defined in 169 [RFC2661], except that it is allowed to grow as a list. As with 170 the Port Type List, the last item in the list always represents 171 the Channel ID of the sender of this AVP. Thus, the last value in 172 the list should be identical to the Physical Channel ID AVP at any 173 given node. 175 In the event a tunnel switching node has implemented the 176 extensions defined in this document but does not receive a Channel 177 ID List from its downstream node, it MUST first copy the value 178 received in the Physical Channel ID AVP at Session establishment 179 into the Channel ID List before adding its own Channel ID to the 180 list. 182 2.3 L2TP Node Name List (sccrq, icrq, iccn) 183 The LAC Name List AVP is encoded as Vendor ID 0, Attribute TBD. 184 The Value is a list of counted strings, with the octet prior to 185 each string indicating the length of the string that follows it. 186 Each time an L2TP node forwards a session, a new value MUST be 187 appended to this list before it is propogated. If there is no 188 appropriate value, then a length of 0 MUST be inserted for the 189 L2TP Node Name Length as a place holder. The L2TP Node Name should 190 be a human readable value, analogous or equivalent to the value 191 sent the the L2TP Hostname AVP defined in [RFC2661]. Human 192 readable text in all messages MUST be provided in the UTF-8 193 charset using the Default Language [RFC2277]. 195 0 1 2 3 196 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | length 0 | L2TP Node Name 0 (1-255 octets) | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | length 1 | L2TP Node Name 1 (1-255 octets) | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | .... 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 length n | L2TP Node Name n (1-255 octets) | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 This AVP is analogous to the Hostname AVP defined in [RFC2661], 208 except that it is allowed to grow as a list, and may be present at 209 session as well as control connection startup. The last item in 210 the list always represents the name of the sender of the message 211 containing this AVP. Thus, the last value MAY be identical to that 212 in the Hostname AVP. 214 In the event a tunnel switching node has implemented the 215 extensions defined in this document but does not receive a LAC 216 Node Name List from its downstream node, it MUST first copy the 217 value received in the Hostname AVP at Control Connection 218 establishment into the LAC Node Name List before adding its own 219 LAC Node Name to the list. 221 4. IANA Considerations 223 This document requires three new "AVP Attributes" to be assigned 224 through IETF Consensus [RFC2434] as indicated in Section 10.1 of 225 [RFC2661]. These are: 227 Port Type List (section 2.1) 229 Channel ID List (section 2.2) 230 L2TP Node Name List (section 2.3) 232 This document defines no additional number spaces for IANA to manage. 234 5. Security Considerations 236 This document describes a method for propogating additional 237 information about interfaces and equipment information by which a PPP 238 session arrives before and after tunneling via L2TP. While it is not 239 obvious how this information could be used for malicious purposes, if 240 it somehow was used to comprimise security then implementation of the 241 mechanisms described in this document increase the number of times 242 this information is made available on the network. AVP hiding, 243 described in [RFC2661] MAY be used to help mitigate this, though it 244 is not widely regarded as cryptographically secure. [RFC3193] 245 describes a more robust method for securing L2TP in general, and 246 should be used to encrypt all L2TP messages if access to the 247 information sent within the AVPs described in this document is of 248 concern. 250 6. Contacts 252 Ignacio Goyret 253 Lucent Technologies 254 1701 Harbor Bay Parkway 255 Alameda, CA 94502 256 igoyret@lucent.com 258 William Palter 259 Pipal Systems 260 palter.ietf@zev.net 262 W. Mark Townsley 263 cisco Systems 264 7025 Kit Creek Road 265 PO Box 14987 266 Research Triangle Park, NC 27709 267 mark@townsley.net 269 Suhail Nanji 270 RedBack Networks 271 1389 Moffett Park Drive 272 Sunnyvale, CA 94089 273 suhail@redback.com 275 7. References 277 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 278 RFC 1661, July 1994. 280 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 281 Requirement Levels", BCP 14, RFC 2119, March 1997. 283 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 284 Languages", BCP 18, RFC 2277, January 1998. 286 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 287 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 289 [RFC2058] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote 290 Authentication Dial In User Service (RADIUS)," RFC 2058, 291 January 1997 293 [RFC2059] C. Rigney, RADIUS Accounting, RFC 2059, January 1997 295 [RFC3193] B. Patel, B. Aboba, W. Dixon, G. Zorn, S. Booth, "Securing 296 L2TP Using IPsec," RFC 3193, November 2001