Network Working Group W. Mark Townsley Internet-Draft cisco Systems October 2003 MPLS over Layer 2 Tunneling Protocol (Version 3) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 (2003). 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 2003 Contents Status of this Memo.......................................... 1 1. Introduction.............................................. 2 2. MPLS over L2TPv3 Encoding................................. 3 3. Assigning the L2TPv3 Session ID and Cookie................ 4 4. MPLS over L2TPv3 to enable "BGP/MPLS VPNs" [RFC2547]...... 4 4.1 Distribution of L2TPv3 tunneling parameters........... 5 4.2 Protection Against "Blind" IP Spoofing Attacks........ 5 5. Applicability............................................. 6 6. Security Considerations................................... 7 7. IANA Considerations....................................... 7 8. Acknowledgments........................................... 7 9. References................................................ 7 9.1 Normative References.................................. 7 9.2 Informative References................................ 7 10. Contacts................................................. 8 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 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. Section 2 and 3 describe the encapsulation and operation for MPLS over L2TPv3 in general. Special attention is placed on enabling "BGP/MPLS VPNs" [RFC2547], and use of the L2TPv3 Cookie to protect against "blind" IP spoofing attacks in Section 4. Section 5 is an Townsley Standards Track [Page 2] INTERNET DRAFT MPLS over L2TPv3 October 2003 applicability section describing L2TPv3 in context with GRE, IP, and IPsec. 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]. +-+-+-+-+-+-+-+-+-+-+ | 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 is present and the random 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 Townsley Standards Track [Page 3] INTERNET DRAFT MPLS over L2TPv3 October 2003 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 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. Many of the 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 For point to point applications, the control plane defined in [L2TPv3] should be used to exchange the Session ID and Cookie. For point to multi-point applications, a point to multi-point distribution mechanism should be used. For example, to support BGP MPLS/VPNs over L2TPv3, BGP may be used to carry the L2TPv3 Session ID and Cookie as defined in [NALAWADE] or [RAGGARWA]. 4. MPLS over L2TPv3 to enable "BGP/MPLS VPNs" [RFC2547] MPLS over L2TPv3 may be used to enable BGP/MPLS VPNs [RFC2547] over an IP network. The IP network may either be a native IP core with no MPLS enabled on its P routers, or L2TPv3 may be used as an extension to reach beyond an MPLS core network to certain PE routers which are reachable via IP and not MPLS. To enable BGP/MPLS VPNs [RFC2547] over L2TPv3, the top "tunnel label" of the two-level MPLS stack is replaced with the IP and L2TPv3 headers yielding the following encapsulation: Townsley Standards Track [Page 4] INTERNET DRAFT MPLS over L2TPv3 October 2003 +-+-+-+-+-+-+-+-+-+-+ | IP | +-+-+-+-+-+-+-+-+-+-+ | L2TPv3 | +-+-+-+-+-+-+-+-+-+-+ | MPLS VPN Label | +-+-+-+-+-+-+-+-+-+-+ Figure 4.1 BGP/MPLS VPNs [RFC2547] over L2TPv3/IP 4.1 Distribution of L2TPv3 tunneling parameters The combination of the PE IP address, L2TPv3 Session ID, and Cookie embody the necessary reachability information for a PE to participate in a BGP/MPLS VPN over L2TPv3. BGP may be extended as defined in [NALAWADE] or [RAGGARWA] to distribute the L2TPv3 reachability information for the PE. The VPN label is distributed in BGP via the VPN-IPv4 address family as is typical for [RFC2547] VPNs. The L2TPv3 tunnel parameters (IP address, Session ID and Cookie) MUST be able to be reset at any time for a given PE without disruption of service. It should be noted that if the L2TPv3 Cookie and Session ID are distributed via BGP (or by some other multipoint distribution protocol), there is no requirement to manually configure these on any PE. The Session ID and Cookie are selected locally by software on the PE, the Session ID according to what is most favorable for its local L2TPv3 classification method, and the Cookie as a random 64-bit value. 4.2 Protection Against "Blind" IP Spoofing Attacks The L2TPv3 Cookie provides absolutely no cryptographic security protection against any kind of attack. However, it may still provide a very simple and efficient protection against spoofed packet insertion attacks in certain environments. A "blind" insertion attack is defined as a packet spoofing attack where: The attacker has the ability to insert spoofed IP packets into the service provider core, circumventing edge filters at one or more locations. The attacker knows the address of one or more PEs participating in the VPN service, and can send spoofed packets to these addresses at will. Townsley Standards Track [Page 5] INTERNET DRAFT MPLS over L2TPv3 October 2003 The attacker does NOT have the ability to instantaneously sniff, reroute, or otherwise obtain legitimate data in transit between participating PE routers for use in a coordinated spoofing attack. This is intended to represent the profile of an attacker able to operate without much sophistication, particularly if armed with an automated tool populated with a few unscrupulously obtained parameters such as the VPN PE IP address(es) and vulnerable core entry points. This type of attacker may have very good success in randomly guessing a valid MPLS VPN label for insertion into a customer VPN. For example, if 4096 unique VPN labels are being advertised by a given PE, random guessing would, on average, yield a valid result once for every 256 attempts. The more VPN labels advertised, the more likely one might guess a valid label which would end up being routed to the customer VPN. The 64-bit L2TPv3 Cookie, assigned with a random value for each PE, renders it virtually impossible (at least not within multiple lifetimes at current and foreseeable data rates) to insert a spoofed packet into the customer VPN based on blind guessing alone. Further, if it is expected that the Cookie has become compromised, it may be readvertised (or rolled periodically in an automated manner) without affecting outstanding VPN labels or CE connectivity to the VPN. 5. Applicability The methods defined [MPLS-IP-GRE], [MPLS-IPSEC] and this document all describe methods for carrying MPLS over an IP network. Situations where MPLS over L2TPv3 may be preferable include: If the provider core is vulnerable to blind insertion attacks, L2TPv3 can provide strong protection against these in a very lightweight manner. [MPLS-IPSEC] provides cryptographic protection against this and other potential vulnerabilities, but greater operational and packet processing overhead. [MPLS-IP-GRE] does not provide any protection for packet insertion attacks beyond reliance upon edge-based filtering (limitations of the edge- filtering method are described in section 1.1 of [MPLS-IPSEC]). (The following two applicability statements are adopted from [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 routers need to send MPLS packets over that adjacency. Implementation considerations may dictate the use of MPLS-in- L2TPv3. For example, some hardware device might only be able to Townsley Standards Track [Page 6] INTERNET DRAFT MPLS over L2TPv3 October 2003 handle L2TPv3 encapsulations in its fastpath. In summary, L2TPv3 can provide a balance between the limited security against IP spoofing attacks offered by [MPLS-IP-GRE] vs. the greater overhead required by an [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 an MPLS label carried over L2TPv3. 6. Security Considerations Security is discussed in a number of areas in this document, in particular section 4.2. 7. IANA Considerations There are no IANA considerations for this document. 8. Acknowledgments Thanks to Robert Raszuk and Clarence Filsfils for their review of this document. 9. References 9.1 Normative References [L2TPv3] J. Lau, M. Townsley, I. Goyret, "Layer Two Tunneling Protocol (Version 3)", work in progress, draft-ietf-l2tpext-l2tp-base-10.txt, August 2003. [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-03.txt, September 2003. 9.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. Townsley Standards Track [Page 7] INTERNET DRAFT MPLS over L2TPv3 October 2003 [NALAWADE] G. Nalawade, R. Kapoor, D. Tappan, "IPv4-Tunnel SAFI", work in progress, draft-nalawade-kapoor-tunnel-safi-00.txt, June 2003. [RAGGARWA] R. Aggarwal, R. Raszuk, F. Le Faucheur, C. Geoffrey, J. De Clercq, "Signaling Tunnel Encapsulation/ Deencapsulation Capabilities", work in progress, draft-raggarwa-ppvpn-tunnel-encap-sig-01.txt, June 2003. [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. 10. Contacts W. Mark Townsley cisco Systems 7025 Kit Creek Road Research Triangle Park, NC 27709 mark@townsley.net Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING Townsley Standards Track [Page 8] INTERNET DRAFT MPLS over L2TPv3 October 2003 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." Townsley Standards Track [Page 9]