idnits 2.17.1 draft-townsley-mpls-over-l2tpv3-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 319. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 296. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 303. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 309. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 325), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 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 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** There are 15 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'RFC1750' is mentioned on line 139, but not defined ** Obsolete undefined reference: RFC 1750 (Obsoleted by RFC 4086) == Unused Reference: 'RFC2547' is defined on line 264, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2547 (Obsoleted by RFC 4364) == Outdated reference: A later version (-05) exists of draft-ietf-l3vpn-ipsec-2547-01 Summary: 11 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Mark Townsley 3 Internet-Draft cisco Systems 4 Ted Seely 5 December 2004 Sprint 6 Jeffery S. Young 7 Alcatel 9 Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 and any of which I become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress". 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt . 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html . 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a 41 protocol for tunneling a variety of payload types over IP networks. 42 This document defines how to carry an MPLS label or label stack and 43 its payload over L2TPv3. This enables an application which 44 traditionally requires an MPLS-enabled core network to utilize an 45 L2TPv3 encapsulation over an IP network instead. 47 Contents 49 Status of this Memo.......................................... 1 51 1. Introduction.............................................. 2 53 2. MPLS over L2TPv3 Encoding................................. 2 55 3. Assigning the L2TPv3 Session ID and Cookie................ 4 57 4. Applicability............................................. 4 59 5. Security Considerations................................... 5 61 6. IANA Considerations....................................... 6 63 7. Acknowledgments........................................... 6 65 8. References................................................ 6 66 8.1 Normative References.................................. 6 67 8.2 Informative References................................ 6 69 9. Contacts.................................................. 6 71 Specification of Requirements 73 In this document, several words are used to signify the requirements 74 of the specification. These words are often capitalized. The key 75 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 76 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 77 are to be interpreted as described in [RFC2119]. 79 1. Introduction 81 This document defines how to encapsulate an MPLS label or label stack 82 and its payload over L2TPv3. After defining the MPLS over L2TPv3 83 encapsulation procedure, other MPLS over IP encapsulation options 84 including IP, GRE and IPsec are discussed in context with MPLS over 85 L2TPv3 in an Applicability section. This document only describes 86 encapsulation and does not concern itself with all possible MPLS- 87 based applications which may be enabled over L2TPv3. 89 2. MPLS over L2TPv3 Encoding 91 MPLS over L2TPv3 allows tunneling of an MPLS stack [RFC3032] over an 92 IP network utilizing the L2TPv3 encapsulation defined in [RFC3931]. 94 +-+-+-+-+-+-+-+-+-+-+ 95 | IP | 96 +-+-+-+-+-+-+-+-+-+-+ 97 | L2TPv3 | 98 +-+-+-+-+-+-+-+-+-+-+ 99 | MPLS Label Stack | 100 +-+-+-+-+-+-+-+-+-+-+ 102 Figure 2.1 MPLS Stack over L2TPv3/IP 104 The L2TPv3 encapsulation carrying a single MPLS label is as follows: 106 0 1 2 3 107 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 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | Session ID | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | Cookie (optional, maximum 64 bits)... 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 ... | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label 115 | Label | Exp |S| TTL | Stack 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry 118 Figure 2.2 MPLS label over L2TPv3 encapsulation 120 Session ID 122 The L2TPv3 Session ID is a 32-bit identifier field locally 123 selected as a lookup key for the context of an L2TP Session. An 124 L2TP Session contains necessary context for processing a received 125 L2TP packet. At a minimum, such context contains whether the 126 Cookie (see description below) is present, the value it was 127 assigned, as well as what type of tunneled encapsulation follows 128 (i.e., Frame Relay, Ethernet, MPLS, etc). 130 Cookie 132 The L2TPv3 Cookie field contains a variable length (maximum 64 133 bits) randomly assigned value. It is intended to provide an 134 additional level of guarantee that a data packet has been directed 135 to the proper L2TP session by the Session ID. While the Session 136 ID may be encoded and assigned any value (perhaps optimizing for 137 local lookup capabilities, redirection in a distributed forwarding 138 architecture, etc.), the Cookie MUST be selected as a 139 cryptographically random value [RFC1750], with the added 140 restriction that it not be the same as a recently used value for a 141 given Session ID. A well-chosen Cookie will prevent inadvertent 142 misdirection of a stray packet containing a recently reused 143 Session ID, a Session ID that is subject to packet corruption, and 144 protection against some specific malicious packet insertion 145 attacks as described in more detail in Section 4.2 of this 146 document. 148 Label Stack Entry 150 An MPLS label as defined in [RFC3032]. 152 The optional L2-Specific-Sublayer defined in [RFC3931] is generally 153 not present for MPLS over L2TPv3. 155 Generic IP encapsulation procedures such as MTU considerations, 156 handling of TTL, EXP and DSCP bits, etc. are the same as the "Common 157 Procedures" for IP encapsulation of MPLS defined in Section 5 of 158 [MPLS-IP-GRE] and are not reiterated here. 160 3. Assigning the L2TPv3 Session ID and Cookie 162 Much like an MPLS label, the L2TPv3 Session ID and Cookie must be 163 selected and exchanged between participating nodes before L2TPv3 can 164 operate. These values may be configured manually, or distributed via 165 a signaling protocol. This document concerns itself only with the 166 encapsulation of MPLS over L2TPv3, thus the particular method of 167 assigning the Session ID and Cookie is out of scope. 169 4. Applicability 171 The methods defined [MPLS-IP-GRE], [MPLS-IPSEC] and this document all 172 describe methods for carrying MPLS over an IP network. Cases where 173 MPLS over L2TPv3 may be applicable compared to other alternatives are 174 discussed in this section. 176 It is generally simpler to have one's border routers refuse to accept 177 an MPLS packet than to configure a router to refuse to accept certain 178 MPLS packets carried in IP or GRE to or from certain IP sources or 179 destinations. Thus, the use of IP or GRE to carry MPLS labels 180 increases the opportunity for MPLS label spoofing attacks. When ACLs 181 fail or are not available, L2TPv3 provides an additional level of 182 protection against packet spoofing before allowing a packet to enter 183 a VPN (much like IPsec provides an additional level of protection at 184 a PE rather than relying on ACL filters). Checking the value of the 185 L2TPv3 Cookie is similar to any sort of ACL which inspects the 186 contents of a packet header, except that we give ourselves the luxury 187 of "seeding" the L2TPv3 header with a very difficult to spoof value. 188 MPLS over L2TPv3 may be favorable compared to [MPLS-IP-GRE], if: 190 Two routers are "adjacent" over an L2TPv3 tunnel that exists for 191 some reason outside the scope of this document, and those two 192 routers need to send MPLS packets over that adjacency. 194 Implementation considerations dictate the use of MPLS over L2TPv3. 195 For example, a hardware device may be able to take advantage of 196 the L2TPv3 encapsulation for faster processing. 198 Packet spoofing is of a concern, and the L2TPv3 Cookie may be used 199 as a method for validating the source of the L2TPv3 packet before 200 continuing to process it. 202 (The first two of the above applicability statements were adopted 203 from [MPLS-IP-GRE]) 205 In summary, L2TPv3 can provide a balance between the limited security 206 against IP spoofing attacks offered by [MPLS-IP-GRE] vs. the greater 207 security and associated operational and processing overhead offered 208 by [MPLS-IPSEC]. Further, MPLS over L2TPv3 may be faster in some 209 hardware, particularly if it is already optimized to classify 210 incoming L2TPv3 packets carrying IP framed in a variety of ways. For 211 example, IP encapsulated by HDLC or Frame Relay over L2TPv3 may be 212 considered not that far removed from IP encapsulated by MPLS over 213 L2TPv3. 215 5. Security Considerations 217 The L2TPv3 Cookie does not provide protection via encryption. 218 However, when used with a sufficiently random 64-bit value which is 219 kept secret from a hacker, the L2TPv3 Cookie may be used as a simple 220 yet effective packet source authentication check which is quite 221 resistent to brute force packet spoofing attacks. It also alleviates 222 the need to rely solely on filter lists based on a list of valid 223 source IP addresses, and thwarts attacks which could benefit by 224 spoofing a permitted source IP address. 226 L2TPv3 tunnels may also be secured using IPsec. When using IPsec, 227 the tunnel head and the tunnel tail should be treated as the 228 endpoints of a Security Association. The MPLS over L2TPv3 229 encapsulated packets should be considered as originating at the 230 tunnel head and as being destined for the tunnel tail; IPsec 231 transport mode should thus be used. Key distribution may be done 232 either manually or automatically. 234 Security is also discussed as part of the applicability discussion in 235 section 4 of this document. 237 6. IANA Considerations 239 There are no IANA considerations for this document. 241 7. Acknowledgments 243 Thanks to Robert Raszuk, Clarence Filsfils and Eric Rosen for their 244 review of this document. Some text was adopted from [MPLS-IP-GRE]. 246 8. References 248 8.1 Normative References 250 [RFC3931] J. Lau, M. Townsley, I. Goyret, "Layer Two Tunneling 251 Protocol (Version 3)", work in progress, 252 draft-ietf-l2tpext-l2tp-base-15.txt, December 2004. 254 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 255 Requirement Levels", BCP 14, RFC 2119, March 1997. 257 [MPLS-IP-GRE] T. Worster, Y. Rekhter, E. Rosen, "Encapsulating 258 MPLS in IP or Generic Routing Encapsulation (GRE)", 259 work in progress, draft-ietf-mpls-in-ip-or-gre-08.txt, 260 June 2004. 262 8.2 Informative References 264 [RFC2547] E. Rosen, Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1999. 266 [RFC3032] R. Rosen, et. al., "MPLS Label Stack Encoding," RFC 3032, 267 January 2001. 269 [MPLS-IPSEC] E. Rosen, J. De Clercq, O/ Paridaens, Y. T'Joens, 270 C. Sargor, "Use of PE-PE IPsec in RFC2547 VPNs", 271 work in progress, draft-ietf-l3vpn-ipsec-2547-01.txt, 272 August 2003. 274 9. Contacts 276 W. Mark Townsley 277 cisco Systems 278 mark@townsley.net 280 Ted Seely 281 Sprint 282 tseely@sprint.net 283 Jeffrey S. Young 284 Alcatel 285 Jeffrey.S.Young@alcatel.com 287 Intellectual Property Statement 289 The IETF takes no position regarding the validity or scope of any 290 Intellectual Property Rights or other rights that might be claimed to 291 pertain to the implementation or use of the technology described in 292 this document or the extent to which any license under such rights 293 might or might not be available; nor does it represent that it has 294 made any independent effort to identify any such rights. Information 295 on the procedures with respect to rights in RFC documents can be 296 found in BCP 78 and BCP 79. 298 Copies of IPR disclosures made to the IETF Secretariat and any 299 assurances of licenses to be made available, or the result of an 300 attempt made to obtain a general license or permission for the use of 301 such proprietary rights by implementers or users of this 302 specification can be obtained from the IETF on-line IPR repository at 303 http://www.ietf.org/ipr. 305 The IETF invites any interested party to bring to its attention any 306 copyrights, patents or patent applications, or other proprietary 307 rights that may cover technology that may be required to implement 308 this standard. Please address the information to the IETF at 309 ietf-ipr@ietf.org. 311 Disclaimer of Validity 313 This document and the information contained herein are provided on an 314 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 315 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 316 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 317 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 318 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 319 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 321 Copyright Statement 323 Copyright (C) The Internet Society (2004). This document is subject 324 to the rights, licenses and restrictions contained in BCP 78, and 325 except as set forth therein, the authors retain all their rights. 327 Acknowledgment 329 Funding for the RFC Editor function is currently provided by the 330 Internet Society.