Network Working Group W. Mark Townsley Internet-Draft cisco Systems Ted Seely January 2004 Sprint BGP/MPLS IP VPNs over Layer 2 Tunneling Protocol ver 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 describes a variation of "BGP/MPLS IP VPNs" in which the outermost MPLS label of a VPN packet is replaced with an L2TPv3 encapsulation, enabling the VPN packets to be carried over an IP network. Townsley Standards Track [Page 1] INTERNET DRAFT BGP/MPLS IP VPN over L2TPv3 October 2004 Contents Status of this Memo.......................................... 1 1. Introduction.............................................. 2 1.1 Terminology........................................... 3 1.2 Overview.............................................. 3 2. MPLS over L2TPv3 Encapsulation............................ 3 2.1 Encapsulation by Ingress PE........................... 5 2.2 Decapsulation by Egress PE............................ 5 3. Assigning the Session ID and Cookie....................... 5 3.1 Distribution of the Session ID and Cookie via BGP..... 6 4. Implications on Packet Spoofing........................... 6 5. Applicability............................................. 7 6. Security Considerations................................... 8 7. IANA Considerations....................................... 9 8. Acknowledgments........................................... 10 9. References................................................ 10 9.1 Normative References.................................. 10 9.2 Informative References................................ 10 10. Contacts................................................. 11 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 The "BGP/MPLS IP VPNs" base specification described in [RFC2547] defines a particular style of Layer 3 Virtual Private Network (L3VPN) using MPLS label switched paths between Provider Edge (PE) routers. This document describes an extension to the [RFC2547] specification by defining procedures for providing the same style of L3VPN using L2TPv3/IP [L2TPV3] tunnels (rather than MPLS LSPs) as the Townsley Standards Track [Page 2] INTERNET DRAFT BGP/MPLS IP VPN over L2TPv3 October 2004 encapsulation between PE routers. 1.1 Terminology Terminology used in this document is defined in [PPVPN-TERMS] and not reiterated here. Terms relevant to this document include: Customer Edge device (CE) Provider Edge (PE) Virtual Private Network (VPN) Layer 3 VPN (L3VPN) BGP/MPLS IP VPN VPN Routing and Forwarding (VRF) 1.2 Overview In a BGP/MPLS IP VPN, when a PE router receives a packet from a CE router, it looks up the packet's destination IP address in a VPN Routing and Forwarding (VRF) table. As a result of this lookup, it obtains an MPLS label stack, a data link header, and an output interface. The label stack is prepended to the packet, the data link header is prepended to that, and the resulting frame is queued for the output interface. The "bottom label" [RFC3032] on the MPLS label stack is always a label which will not be seen until the packet reaches its point of egress from the network. This label represents a particular route within the packet's VPN and will be referred to in this document as a "VPN label." The purpose of the upper labels is to cause the packet to be delivered to the router which understands the VPN label. Thus, a BGP/MPLS IP VPN may be constructed among any set of PEs for which the VPN label is carried intact. This document describes methods for carrying a VPN label among PEs via the MPLS over L2TPv3 encapsulation as described in [MPLS-L2TPV3]. This enables a BPG/MPLS IP VPN which traditionally required an MPLS- enabled core network to utilize an L2TPv3 encapsulation over an IP network instead. An applicability section describing L2TPv3 in context with MPLS, GRE, IP, and IPsec is presented as well. 2. MPLS over L2TPv3 Encapsulation MPLS over L2TPv3 as defined in [MPLS-L2TPv3] allows the tunneling of an MPLS label stack [RFC3032] over an IP network via L2TPv3. A BGP/MPLS IP VPN over L2TPv3 utilizes a single VPN label (MPLS bottom label) which is carried over the L2TPv3 encapsulation. This is depicted in Figure 2.1 and 2.2. Townsley Standards Track [Page 3] INTERNET DRAFT BGP/MPLS IP VPN over L2TPv3 October 2004 +-+-+-+-+-+-+-+-+-+-+ | IP | +-+-+-+-+-+-+-+-+-+-+ | L2TPv3 | +-+-+-+-+-+-+-+-+-+-+ | VPN Label | +-+-+-+-+-+-+-+-+-+-+ | VPN Payload (IP) | +-+-+-+-+-+-+-+-+-+-+ Figure 2.1 BGP/MPLS IP VPN over L2TPv3/IP 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)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (VPN) Label | Exp |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2.2 MPLS VPN 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. For the application described in this document, this includes whether the Cookie is present, the value it was assigned, and that a MPLS VPN label follows. Cookie The L2TPv3 Cookie field contains a variable length (maximum 64 bits) value assigned by a cryptographically random [RFC1750] algorithm. VPN Label An MPLS label used to identify a route for a BGP/MPLS IP VPN. Please refer to [MPLS-L2TPv3] for other MPLS over L2TPv3/IP encapsulation specifics. Townsley Standards Track [Page 4] INTERNET DRAFT BGP/MPLS IP VPN over L2TPv3 October 2004 2.1 Encapsulation by Ingress PE When a PE receives a packet from a CE, it looks up the packet's IP destination address in the VRF corresponding to that CE. This enables it to find an IP route within the VPN. This route will have an associated MPLS label (the VPN label) and BGP Next Hop with reachability information for the Next Hop in the form of a set of L2TPv3 tunnel parameters (IP Address, Session ID and Cookie). The VPN label, L2TPv3, and IP encapsulation headers are prepended to the packet. The IP source address field of the encapsulation header will be an address of the ingress PE itself. The IP destination address field of the encapsulation header will contain the value of the associated BGP Next Hop attribute; this will be an IP address of the egress PE. As defined in [L2TPv3], the Ingress PE MUST support the ability to encapsulate a 32 and 64 bit Cookie, or no Cookie at all. The Egress PE (section 2.2) is always in control of the size and value of the cookie to be encapsulated by the Ingress PE by virtue of it advertising its own tunnel reachability information (section 3). In order to achieve the anti-spoofing benefits of the Cookie as described in section 4, a 64-bit Cookie MUST always be used. 2.2 Decapsulation by Egress PE Upon receipt of the L2TPv3 packet addressed to a local IP address at the PE, a context lookup on the Session ID returns the Cookie for validation and the type of payload that follows. If the Cookie does not match, the packet MUST be dropped and a counter incremented in order to detect the occurrence of received cookie mismatches (this MAY be a global counter for the PE). If the type of payload is MPLS, then the packet is delivered to the routing function for MPLS switching. The Egress PE is in control of the size and value of the Cookie it will permit packets to be received and processed with. As such, it is not a protocol violation to always advertise a 64-bit cookie, or no cookie at all. In order to achieve the anti-spoofing benefits of the Cookie as described in section 4, a 64-bit Cookie MUST be used and MUST be the default configuration. A zero or 32-bit Cookie MAY be used to reduce the size of the tunnel encapsulation if there are other forms of authentication embedded with the packet at another layer (e.g., IPsec authentication). 3. Assigning the Session ID and Cookie A minimum of one L2TPv3 Session ID must be allocated per PE. This Session ID may be any 32-bit value, and may be manually configured or Townsley Standards Track [Page 5] INTERNET DRAFT BGP/MPLS IP VPN over L2TPv3 October 2004 distributed via a signaling protocol. The Session ID need not be different for all PEs within a VPN, thus a single "global" value MAY be used. The L2TPv3 Cookie MUST be selected via a cryptographically random algorithm [RFC1750] and distributed (either by configuration or a signaling protocol) to all PEs. The default size for the Cookie MUST be 64 bits. A 32 or 0 (not present) bit Cookie MAY be used if another form of packet authentication is present at another layer (e.g. IPsec authentication). Unlike the Session ID, the Cookie SHOULD be different at each PE within a VPN. 3.1 Distribution of the Session ID and Cookie via BGP The combination of the PE IP address, L2TPv3 Session ID, and Cookie embody the necessary reachability information for a PE to participate in an RFC 2547 Style VPN over L2TPv3. BGP may be extended as defined in [NALAWADE] 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 a BGP/MPLS IP VPN. The set of L2TPv3 tunnel parameters (IP address, Session ID and Cookie) MUST be able to be updated for a given PE at any time without disruption of the VPN service. This allows for on-demand or periodic update of reachability information. 4. Implications on Packet Spoofing Without the L2TPv3 Cookie, protection against spoofed VPN packets carried over IP requires having all the boundary routers perform filtering; either filtering out packets from "outside" which are addressed to PE routers, or filtering out packets from "outside" which have source addresses that belong "inside" and filtering on each PE all packets which have source addresses that belong "outside". The maintenance of these filter lists can be management- intensive, and the their use at all border routers can affect the performance seen by all traffic entering the SP's network. Unlike boundary filters, the L2TPv3 Session ID and Cookie are selected and distributed automatically among participating PEs, requiring virtually no additional operational impact and no impact on the performance of border routers whatsoever. While the L2TPv3 Cookie does not provide cryptographic security protection, it does provide effective protection against "blind" spoofed packet insertion attacks on an SP network in a very efficient manner. A "blind" insertion attack is defined as a packet spoofing attack where: Townsley Standards Track [Page 6] INTERNET DRAFT BGP/MPLS IP VPN over L2TPv3 October 2004 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. 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. The blind insertion attack is indicative of an attacker who is 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, the probability approaches one that random guessing would yield a valid result for as few as 256 attempts (2^20/4096 = 256). The more VPN labels advertised, the more likely one might guess a valid label which would end up being routed to the customer VPN. A 64-bit Cookie within L2TPv3 is a very significant barrier against a packet spoofing attack. Consider a PE which has been assigned two valid random cookies. All L2TPv3 traffic entering this PE must be stamped with the proper value in order to be accepted. Thus, the probability that a random guess would yield the correct value is 2/2^64. Assuming the ability to guess at a rate of 10 Mpps, the probability approaches one that a correct value would be selected after 2^64 / 10*10^6 /2 seconds, or more than 29,000 years (note that the same calculation with a 32 bit Cookie yields 3 minutes 35 seconds, thus a 64 bit key is recommended). Further, if it is expected that the Cookie has become compromised, it may be re- advertised without affecting outstanding VPN labels or CE connectivity to the VPN. 5. Applicability The methods defined [MPLS-IP-GRE-L3VPN], [MPLS-IPSEC] and this document all describe methods for carrying MPLS over an IP network in support of an RFC 2547 Style VPN. Situations where L2TPv3 may be preferable include: L2TPv3 can provide protection against VPN packet spoofing in a very lightweight manner. [MPLS-IPSEC] provides cryptographic Townsley Standards Track [Page 7] INTERNET DRAFT BGP/MPLS IP VPN over L2TPv3 October 2004 protection against this and other potential vulnerabilities, but at greater operational and packet processing overhead (it should be noted here that L2TPv3 may be protected by IPsec as well given that it is a general mechanism for securing IP traffic). [MPLS- IP-GRE-L3VPN] does not provide any protection for packet insertion attacks beyond reliance upon core network boundary filtering. (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 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-L3VPN] vs. the greater overhead required by an [MPLS-IPSEC]. Further, an BGP/MPLS IP VPN 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 BGP/MPLS IP VPN security is discussed in detail in [MPLS-VPN-SEC]. The analysis shows that BGP/MPLS IP VPN networks can be considered as secure as a more traditional layer-2 VPN network such as Frame Relay. Many of the properties discussed in this document are equivalent when a VPN label is carried over L2TPv3 or MPLS, in particular topics such as "Address space, Routing and Traffic Separation." The security provided by L2TPv3 acts as an additional layer of protection among the participating PEs themselves. There are subtle differences when discussing resistance to packet spoofing attacks on an IP network vs. an MPLS network, as the core transport for the VPN packets plays a large role. In order for a BGP/MPLS IP VPN to be secure over an MPLS infrastructure, it is assumed in [MPLS-VPN-SEC] that it is impossible to insert spoofed MPLS packets into an MPLS core network since labeled packets should never be accepted from a CE. As long as this principle holds (i.e., there is no physical tap by a hacker on the core of the network), there is no possibility of spoofing since packets cannot enter the network from outside in the first place. Townsley Standards Track [Page 8] INTERNET DRAFT BGP/MPLS IP VPN over L2TPv3 October 2004 In practice, an IP core network may be more vulnerable to spoofing attacks than an isolated MPLS core network as the various L3 ACLs necessary to filter traffic at the edge of the network can be more cumbersome to setup and maintain than simply dropping any MPLS labeled packet. Use of the L2TPv3 Cookie (as described in Section 4) provides an extra layer of anti-spoofing protection as long as the hacker does not have the ability to capture, decode, and utilize traffic on the core network in a coordinated replay attack (i.e., as above, there is no physical tap by a hacker on the core of the network). Thus, given the assumptions for an MPLS core network that no labeled packets may enter the core from an untrusted source, and the assumption for an IP core network that an untrusted source cannot sniff packets in transit for use in a coordinated attack, the security of a BGP/MPLS VPN over L2TPv3 with an IP core is effectively equivalent to that of a BGP/MPLS IP VPN over an MPLS core. It is very important for the security of the anti-spoofing mechanism of L2TPv3 that the Cookie be selected in a truly random manner, and that a series of cookies not be predictable. It should be assumed that a hacker has access to similar hardware and software for examining a series of assigned Cookie values for a given implementation. The precise algorithm for Cookie selection is not defined in this document, though [RFC1750] provides guidelines that should be followed for the selection of an algorithm. The cryptographic protection of IPsec provides greater security than the methods described in this document or that of an MPLS core network as it does not rely on the assumption that a hacker does not have privileged access to traffic in the network core. If an IP or MPLS core network is subject to packet sniffing such that traffic in transit between PEs may be used in a coordinated spoofing attack across core network boundaries, then MPLS over IPsec is necessary to provide true security against these types of attacks. Since IPsec may be used to secure any type of host-to-host IP traffic, it can be used to secure MPLS/L2TPv3 traffic by setting up the proper IPsec policies to match L2TPv3 traffic between participating PEs or to secure MPLS over GRE or MPLS over IP as described in [MPLS-IPsec]. 7. IANA Considerations This document creates a no new requirements on IANA namespaces [RFC2434]. Townsley Standards Track [Page 9] INTERNET DRAFT BGP/MPLS IP VPN over L2TPv3 October 2004 8. Acknowledgments Portions of text in this document was borrowed or adapted from [MPLS-IP-GRE-L3VPN]. Thanks to Dave Meyer and Michael Behringer for review, comments and suggestions. 9. References 9.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. [MPLS-L2TPv3] M. Townsley, "Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3", draft-townsley-l2tpv3-mpls-02.txt October 2004 9.2 Informative References [RFC1750] D. Eastlake III, S. Crocker, J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994 [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. [NALAWADE] G. Nalawade, R. Kapoor, D. Tappan, "IPv4-Tunnel SAFI", work in progress, draft-nalawade-kapoor-tunnel-safi-01.txt, October 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. [PPVPN-TERMS] L. Andersson, T. Madsen, "PPVPN terminology", work in progress, draft-andersson-ppvpn-terminology-04.txt, September 2003. [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. Townsley Standards Track [Page 10] INTERNET DRAFT BGP/MPLS IP VPN over L2TPv3 October 2004 [MPLS-VPN-SEC] M. Behringer, "Analysis of the Security of BGP/MPLS IP VPNs," work in progress, draft-behringer-mpls-security-05.txt, November 2003. [MPLS-IP-GRE-L3VPN] Y. Rekhter, E. Rosen, "Use of PE-PE GRE or IP in RFC2547 VPNs", work in progress, draft-ietf-l3vpn-gre-ip-2547-00.txt April 2003. 10. Contacts W. Mark Townsley cisco Systems 7025 Kit Creek Road Research Triangle Park, NC 27709 mark@townsley.net Ted Seely Sprint tseely@sprint.net 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 Townsley Standards Track [Page 11] INTERNET DRAFT BGP/MPLS IP VPN over L2TPv3 October 2004 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 12]