Network Working Group W. Mark Townsley Internet-Draft cisco Systems <draft-townsley-l2tpv3-mpls-02.txt> Ted Seely October 2004 Sprint Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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/ietf/1id-abstracts.txt . The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html . Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a protocol for tunneling a variety of payload types over IP networks. This document defines how to carry an MPLS label or label stack and its payload over L2TPv3. This enables an application which traditionally requires an MPLS-enabled core network to utilize an L2TPv3 encapsulation over an IP network instead. Townsley Standards Track [Page 1]
INTERNET DRAFT MPLS over L2TPv3 October 2004 Contents Status of this Memo.......................................... 1 1. Introduction.............................................. 2 2. MPLS over L2TPv3 Encoding................................. 2 3. Assigning the L2TPv3 Session ID and Cookie................ 4 4. Applicability............................................. 4 5. Security Considerations................................... 5 6. IANA Considerations....................................... 5 7. Acknowledgments........................................... 6 8. References................................................ 6 8.1 Normative References.................................. 6 8.2 Informative References................................ 6 9. Contacts.................................................. 6 Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. 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]. 1. Introduction This document defines how to encapsulate an MPLS label or label stack and its payload over L2TPv3. After defining the MPLS over L2TPv3 encapsulation procedure, other MPLS over IP encapsulation options including IP, GRE and IPsec are discussed in context with MPLS over L2TPv3 in an Applicability section. This document only describes encapsulation and does not concern itself with all possible MPLS- based applications which may be enabled over L2TPv3. 2. MPLS over L2TPv3 Encoding MPLS over L2TPv3 allows tunneling of an MPLS stack [RFC3032] over an IP network utilizing the L2TPv3 encapsulation defined in [L2TPv3]. Townsley Standards Track [Page 2]
INTERNET DRAFT MPLS over L2TPv3 October 2004 +-+-+-+-+-+-+-+-+-+-+ | IP | +-+-+-+-+-+-+-+-+-+-+ | L2TPv3 | +-+-+-+-+-+-+-+-+-+-+ | MPLS Label Stack | +-+-+-+-+-+-+-+-+-+-+ Figure 2.1 MPLS Stack over L2TPv3/IP For reference, the L2TPv3 encapsulation carrying a single MPLS label is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cookie (optional, maximum 64 bits)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label | Label | Exp |S| TTL | Stack +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry Figure 2.2 MPLS label over L2TPv3 encapsulation Session ID The L2TPv3 Session ID is a 32-bit identifier field locally selected as a lookup key for the context of an L2TP Session. An L2TP Session contains necessary context for processing a received L2TP packet. At a minimum, such context contains whether the Cookie (see description below) is present and the value it was assigned, as well as what type of tunneled encapsulation follows (i.e., Frame Relay, Ethernet, MPLS, etc). Cookie The L2TPv3 Cookie field contains a variable length (maximum 64 bits) randomly assigned value. It is intended to provide an additional level of guarantee that a data packet has been directed to the proper L2TP session by the Session ID. While the Session ID may be encoded and assigned any value (perhaps optimizing for local lookup capabilities, redirection in a distributed forwarding architecture, etc.), the Cookie MUST be selected as a random value, with the added restriction that it not be the same as a recently used value for a given Session ID. A well-chosen Cookie Townsley Standards Track [Page 3]
INTERNET DRAFT MPLS over L2TPv3 October 2004 will prevent inadvertent misdirection of a stray packet containing a recently reused Session ID, a Session ID that is subject to packet corruption, and protection against some specific malicious packet insertion attacks as described in more detail in Section 4.2 of this document. Label Stack Entry An MPLS label as defined in [RFC3032]. The optional L2-Specific-Sublayer defined in [L2TPv3] is generally not present for MPLS over L2TPv3. Generic IP encapsulation procedures such as MTU considerations, handling of TTL, EXP and DSCP bits, etc. are the same as the "Common Procedures" for IP encapsulation of MPLS defined in Section 5 of [MPLS-IP-GRE] and are not reiterated here. 3. Assigning the L2TPv3 Session ID and Cookie Much like an MPLS label, the L2TPv3 Session ID and Cookie must be selected and exchanged between participating nodes before L2TPv3 can operate. These values may be configured manually, or distributed via a signaling protocol. This document concerns itself only with the encapsulation of MPLS over L2TPv3, so the particular method of assigning the Session ID and Cookie for a given application is out of scope here. 4. Applicability The methods defined [MPLS-IP-GRE], [MPLS-IPSEC] and this document all describe methods for carrying MPLS over an IP network. Cases where MPLS over L2TPv3 may be applicable compared to other alternatives are discussed here. The use of IP or GRE to carry MPLS labels increases the opportunity for MPLS label spoofing attacks. It is generally simpler to have one's border routers refuse to accept an MPLS packet than to configure a router to refuse to accept certain MPLS packets carried in IP or GRE to or from certain IP sources or destinations. When ACLs fail or are not available, L2TPv3 provides an additional level of protection at the PE itself against packet spoofing attacks (much like IPsec provides an additional level of protection at the PE rather than relying on ACL filters). MPLS over L2TPv3 may be favorable compared to [MPLS-IP-GRE], if: Two routers are "adjacent" over an L2TPv3 tunnel that exists for some reason outside the scope of this document, and those two Townsley Standards Track [Page 4]
INTERNET DRAFT MPLS over L2TPv3 October 2004 routers need to send MPLS packets over that adjacency. Implementation considerations dictate the use of MPLS over L2TPv3. For example, some hardware device might only be able to handle L2TPv3 encapsulations in its fastpath. (The above two applicability statements were adopted from [MPLS-IP- GRE]) In summary, L2TPv3 can provide a balance between the limited security against IP spoofing attacks offered by [MPLS-IP-GRE] vs. the greater security and associated operational and processing overhead offered by [MPLS-IPSEC]. Further, MPLS over L2TPv3 may be faster in some hardware, particularly if it is already optimized to classify incoming L2TPv3 packets carrying IP framed in a variety of ways. That is, IP encapsulated by HDLC or Frame Relay over L2TPv3 may be considered not that far removed from IP encapsulated by MPLS over L2TPv3. 5. Security Considerations The L2TPv3 Cookie does not provide cryptographic security. However, when used with a sufficiently random 64-bit value which is kept secret from a hacker, the L2TPv3 Cookie may be used as a simple yet effective packet source authentication check which is quite resistent to brute force packet spoofing attacks. It also alleviates the need to rely solely on filter lists based on a list of valid source IP addresses, and thwarts attacks which could benefit by spoofing a permitted source IP address. L2TPv3 tunnels may also be secured using IPsec. When using IPsec, the tunnel head and the tunnel tail should be treated as the endpoints of a Security Association. The MPLS over L2TPv3 encapsulated packets should be considered as originating at the tunnel head and as being destined for the tunnel tail; IPsec transport mode should thus be used. Key distribution may be done either manually or automatically. Security is also discussed as part of the applicability discussion in section 4 of this document. 6. IANA Considerations There are no IANA considerations for this document. Townsley Standards Track [Page 5]
INTERNET DRAFT MPLS over L2TPv3 October 2004 7. Acknowledgments Thanks to Robert Raszuk, Clarence Filsfils and Eric Rosen for their review of this document. Some text was adopted from [MPLS-IP-GRE]. 8. References 8.1 Normative References [L2TPv3] J. Lau, M. Townsley, I. Goyret, "Layer Two Tunneling Protocol (Version 3)", work in progress, draft-ietf-l2tpext-l2tp-base-14.txt, June 2004. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [MPLS-IP-GRE] T. Worster, Y. Rekhter, E. Rosen, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", work in progress, draft-ietf-mpls-in-ip-or-gre-08.txt, June 2004. 8.2 Informative References [RFC2547] E. Rosen, Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1999. [RFC3032] R. Rosen, et. al., "MPLS Label Stack Encoding," RFC 3032, January 2001. [MPLS-IPSEC] E. Rosen, J. De Clercq, O/ Paridaens, Y. T'Joens, C. Sargor, "Use of PE-PE IPsec in RFC2547 VPNs", work in progress, draft-ietf-l3vpn-ipsec-2547-01.txt, August 2003. 9. Contacts W. Mark Townsley cisco Systems 7025 Kit Creek Road Research Triangle Park, NC 27709 mark@townsley.net Ted Seely Sprint tseely@sprint.net Townsley Standards Track [Page 6]
INTERNET DRAFT MPLS over L2TPv3 October 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Townsley Standards Track [Page 7]