--- 1/draft-ietf-mpls-over-l2tpv3-01.txt 2006-11-07 22:12:11.000000000 +0100 +++ 2/draft-ietf-mpls-over-l2tpv3-02.txt 2006-11-07 22:12:11.000000000 +0100 @@ -1,25 +1,24 @@ -Network Working Group W. Mark Townsley -Internet-Draft Carlos Pignataro -Expiration Date: August 2006 Scott Wainner +Network Working Group M. Townsley +Internet-Draft C. Pignataro +Expiration Date: April 2007 S. Wainner cisco Systems - Ted Seely - Sprint - Jeffery S. Young - Alcatel + T. Seely + Sprint Nextel + J. Young - February 2006 + October 2006 Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3 - draft-ietf-mpls-over-l2tpv3-01.txt + draft-ietf-mpls-over-l2tpv3-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -35,75 +34,77 @@ http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html 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 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. + payload over the L2TPv3 data encapsulation. This enables an + application which traditionally requires an MPLS-enabled core network + to utilize an L2TPv3 encapsulation over an IP network instead. 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. Applicability............................................. 4 - 5. Security Considerations................................... 6 - 5.1 In the Absence of IPsec............................... 6 - 5.2 Context Validation.................................... 7 - 5.3 Securing the Tunnel with IPsec........................ 7 + 5. Congestion Considerations................................. 6 - 6. IANA Considerations....................................... 8 + 6. Security Considerations................................... 6 + 6.1 In the Absence of IPsec............................... 7 + 6.2 Context Validation.................................... 7 + 6.3 Securing the Tunnel with IPsec........................ 8 - 7. Acknowledgements.......................................... 8 + 7. IANA Considerations....................................... 9 - 8. References................................................ 8 - 8.1 Normative References.................................. 8 - 8.2 Informative References................................ 9 + 8. Acknowledgements.......................................... 9 - 9. Authors' Addresses........................................ 10 + 9. References................................................ 9 + 9.1 Normative References.................................. 9 + 9.2 Informative References................................ 9 + + 10. Authors' Addresses....................................... 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 This document defines how to encapsulate an MPLS 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. + payload inside the L2TPv3 tunnel payload. 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] and its payload over an IP network utilizing the L2TPv3 encapsulation defined in [RFC3931]. The MPLS Label Stack and payload are carried in their - entirety after IP (either IPv4 or IPv6) and L2TPv3. + entirety following IP (either IPv4 or IPv6) and L2TPv3 headers. +-+-+-+-+-+-+-+-+-+-+ | IP | +-+-+-+-+-+-+-+-+-+-+ | L2TPv3 | +-+-+-+-+-+-+-+-+-+-+ | MPLS Label Stack | +-+-+-+-+-+-+-+-+-+-+ | MPLS Payload | +-+-+-+-+-+-+-+-+-+-+ @@ -120,33 +121,33 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cookie (optional, maximum 64 bits)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label | Label | Exp |S| TTL | Stack +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry Figure 2.2 MPLS over L2TPv3 encapsulation - When encapsulating MPLS over L2TPv3, the L2TPv3 L2-Specific-Sublayer + When encapsulating MPLS over L2TPv3, the L2TPv3 L2-Specific Sublayer MAY be present. It is generally not present and hence not included in Figure 2.2. The L2TPv3 Session ID MUST be present. The Cookie MAY be present. 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, the value it was - assigned, the presence and type of an L2TPv3 L2-Specific-Sublayer, + assigned, the presence and type of an L2TPv3 L2-Specific Sublayer, 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 @@ -157,116 +158,148 @@ 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 of this document. Label Stack Entry An MPLS label stack entry as defined in [RFC3032]. - The optional L2-Specific-Sublayer defined in [RFC3931] is generally + The optional L2-Specific Sublayer defined in [RFC3931] is generally not present for MPLS over L2TPv3. Generic IP encapsulation procedures such as fragmentation and 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 [RFC4023] 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, thus the particular method of - assigning the Session ID and Cookie is out of scope. + assigning the Session ID and Cookie (if present) is out of scope. 4. Applicability The methods defined [RFC4023], [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 in this section. + MPLS over L2TPv3 is comparable to other alternatives are discussed in + this section. 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. Thus, the use of IP or GRE to carry MPLS packets - increases the opportunity for MPLS label spoofing attacks. L2TPv3 - provides an additional level of protection against packet spoofing - before allowing a packet to enter a VPN (much like IPsec provides an - additional level of protection at a PE rather than relying on ACL + increases the likelihood that an MPLS label spoofing attack will + succeed. L2TPv3 provides an additional level of protection against + packet spoofing before allowing a packet to enter a VPN (much like + IPsec provides an additional level of protection at a Provider Edge + (PE) router rather than relying on Access Control List (ACL) filters). Checking the value of the L2TPv3 Cookie is similar to any sort of ACL which inspects the contents of a packet header, except that we give ourselves the luxury of "seeding" the L2TPv3 header with - a very difficult to spoof value. + a value that is very difficult to spoof. - MPLS over L2TPv3 may be favorable compared to [RFC4023], if: + MPLS over L2TPv3 may be advantageous compared to [RFC4023], 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. + Two routers are already "adjacent" over an L2TPv3 tunnel + established for some other reason, and wish to exchange MPLS + packets over that adjacency. Implementation considerations dictate the use of MPLS over L2TPv3. For example, a hardware device may be able to take advantage of the L2TPv3 encapsulation for faster or distributed processing. Packet spoofing and insertion, service integrity and resource protection are of concern, especially given the fact that an IP tunnel potentially exposes the router to rogue or inappropriate IP - packets from unknown or untrusted sources. IP ACLs and numbering - methods may be used to protect the PEs from rogue IP sources, but - may be subject to error and cumbersome to maintain at all edge - points at all times. The L2TPv3 Cookie provides a simple means of + packets from unknown or untrusted sources. IP Access Control + Lists (ACLs) and numbering methods may be used to protect the + Provider Edge (PE) routers from rogue IP sources, but may be + subject to error and cumbersome to maintain at all edge points at + all times. The L2TPv3 Cookie provides a simple means of validating the source of an L2TPv3 packet before allowing processing to continue. This validation offers an additional level of protection over and above IP ACLs, and a validation that the Session ID was not corrupted in transit or suffered an internal lookup error upon receipt and processing. If the Cookie value is assigned and distributed automatically, it is less subject to operator error, and if selected in a cryptographically random nature, less subject to blind guesses than source IP addresses (in the event that a hacker can insert packets within a VPN core network). (The first two of the above applicability statements were adopted from [RFC4023]) In summary, L2TPv3 can provide a balance between the limited security against IP spoofing attacks offered by [RFC4023] 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. For - example, IP encapsulated by HDLC or Frame Relay over L2TPv3 may be - considered not that far removed from IP encapsulated by MPLS over + hardware, particularly if that hardware is already optimized to + classify incoming L2TPv3 packets carrying IP framed in a variety of + ways. For example, IP encapsulated by HDLC or Frame Relay over L2TPv3 + may be equivalent in complexity to IP encapsulated by MPLS over L2TPv3. -5. Security Considerations +5. Congestion Considerations + + This document specifies an encapsulation method for MPLS inside the + L2TPv3 tunnel payload. MPLS can carry a number of different protocols + as payloads. When an MPLS/L2TPv3 flow carries IP-based traffic, the + aggregate traffic is assumed to be TCP friendly due to the congestion + control mechanisms used by the payload traffic. Packet loss will + trigger the necessary reduction in offered load, and no additional + congestion avoidance action is necessary. + + When an MPLS/L2TPv3 flow carries payload traffic that is not known to + be TCP friendly and the flow runs across an unprovisioned path, the + application that uses the encapsulation specified in this document + MUST employ additional mechanisms to ensure that the offered load is + reduced appropriately during periods of congestion. The MPLS/L2TPv3 + flow should not exceed the average bandwidth that a TCP flow across + the same network path and experiencing the same network conditions + would achieve, measured on a reasonable timescale. + + The comparison to TCP cannot be specified exactly but is intended as + an "order-of-magnitude" comparison in timescale and throughput. The + timescale on which TCP throughput is measured is the round-trip time + of the connection. In essence, this requirement states that it is not + acceptable to deploy an application using the encapsulation specified + in this document on the best-effort Internet, which consumes + bandwidth arbitrarily and does not compete fairly with TCP within an + order of magnitude. One method of determining an acceptable bandwidth + is described in [RFC3448]. Other methods exist, but are outside the + scope of this document. + +6. Security Considerations There are three main concerns when transporting MPLS labeled traffic between PEs using IP tunnels. The first is the possibility that a third party may insert packets into a packet stream between two PEs. The second is that a third party might view the packet stream between two PEs. The third is that a third party may alter packets in a stream between two PEs. The security requirements of the applications whose traffic is being sent through the tunnel characterizes how significant these issues are. Operators may use multiple methods to mitigate the risk including access lists, - authentication, encryption, and context validation. Operators needs - to consider the cost to mitigate the risk. + authentication, encryption, and context validation. Operators should + consider the cost to mitigate the risk. Security is also discussed as part of the applicability discussion in section 4 of this document. -5.1 In the Absence of IPsec +6.1 In the Absence of IPsec If the tunnels are not secured with IPsec, then some other method should be used to ensure that packets are decapsulated and processed by the tunnel tail only if those packets were encapsulated by the tunnel head. If the tunnel lies entirely within a single administrative domain, address filtering at the boundaries can be used to ensure that no packet with the IP source address of a tunnel endpoint or with the IP destination address of a tunnel endpoint can enter the domain from outside. @@ -279,43 +312,43 @@ filtering) is done at the boundaries of an administrative domain. If this is the case, the filtering does not provide effective protection at all unless the decapsulator of MPLS over L2TPv3 validates the IP source address of the packet. Additionally, the "Data Packet Spoofing" considerations in Section 8.2. of [RFC3931] and the "Context Validation" considerations in Section 5.2 of this document apply. Those two sections highlight the benefits of the L2TPv3 Cookie. -5.2 Context Validation +6.2 Context Validation The L2TPv3 Cookie does not provide protection via encryption. 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 - resistant 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 + kept secret from an off-path attacker, the L2TPv3 Cookie may be used + as a simple yet effective packet source authentication check which is + quite resistant 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. The L2TPv3 Cookie provides a means of validating the currently assigned Session ID on the packet flow, providing context protection, and may be deemed complimentary to securing the tunnel utilizing IPsec. In the absence of cryptographic security on the data plane (such as that provided by IPsec), the L2TPv3 Cookie provides a simple method of validating the Session ID lookup performed on each L2TPv3 packet. If the Cookie is sufficiently random and remains unknown to an attacker (that is, the attacker has no way to predict Cookie values or monitor traffic between PEs) then the Cookie provides an additional measure of protection against malicious spoofed packets inserted at the PE over and above that of typical IP address and port ACLs. -5.3 Securing the Tunnel with IPsec +6.3 Securing the Tunnel with IPsec L2TPv3 tunnels may also be secured using IPsec, as specified in Section 4.1.3. of [RFC3931]. IPSec may provide authentication, privacy protection, integrity checking and replay protection. These functions may be deemed necessary by the operator. When using IPsec, the tunnel head and the tunnel tail should be treated as the endpoints of a Security Association. A single IP address of the tunnel head is used as the source IP address, and a single IP address of the tunnel tail is used as the destination IP address. The means by which each node knows the proper address of the other is outside @@ -344,106 +377,117 @@ Securing L2TPv3 using IPsec MUST provide authentication and integrity. (Note that the authentication and integrity provided will apply to the entire MPLS packet, including the MPLS label stack.) Consequently, the implementation MUST support ESP with null encryption. ESP with encryption MAY be supported if a source requires confidentiality. If ESP is used, the tunnel tail MUST check that the source IP address of any packet received on a given SA is the one expected. Key distribution may be done either manually or automatically by - means of IKE [RFC2409]. Manual keying MUST be supported. If - automatic keying is implemented, IKE in main mode with preshared keys - MUST be supported. A particular application may escalate this - requirement and request implementation of automatic keying. Manual - key distribution is much simpler, but also less scalable, than - automatic key distribution. If replay protection is regarded as - necessary for a particular tunnel, automatic key distribution should - be configured. + means of IKE [RFC2409] or IKEv2 [RFC4306]. Manual keying MUST be + supported. If automatic keying is implemented, IKE in main mode with + preshared keys MUST be supported. A particular application may + escalate this requirement and request implementation of automatic + keying. Manual key distribution is much simpler, but also less + scalable, than automatic key distribution. If replay protection is + regarded as necessary for a particular tunnel, automatic key + distribution should be configured. -6. IANA Considerations +7. IANA Considerations There are no IANA considerations for this document. -7. Acknowledgements +8. Acknowledgements Thanks to Robert Raszuk, Clarence Filsfils and Eric Rosen for their review of this document. Some text was adopted from [RFC4023]. -8. References +9. References -8.1 Normative References +9.1 Normative References [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005. -8.2 Informative References +9.2 Informative References [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001. [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [MPLS-IPSEC] Rosen, E., "Architecture for the Use of PE-PE IPsec Tunnels in BGP/MPLS IP VPNs", draft-ietf-l3vpn-ipsec-2547-05 (work in progress), August 2005. - [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange - (IKE)", RFC 2409, November 1998. - [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. -9. Authors' Addresses + [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange + (IKE)", RFC 2409, November 1998. + + [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", + RFC 4306, December 2005. + + [RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP + Friendly Rate Control (TFRC): Protocol Specification", + RFC 3448, January 2003. + +10. Authors' Addresses W. Mark Townsley cisco Systems + Phone: +1-919-392-3741 EMail: mark@townsley.net Carlos Pignataro cisco Systems 7025 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709 + Phone: +1-919-392-7428 EMail: cpignata@cisco.com Scott Wainner cisco Systems 13600 Dulles Technology Drive Herndon, VA 20171 EMail: swainner@cisco.com Ted Seely - Sprint + Sprint Nextel + 12502 Sunrise Valley Dr + Reston, VA 20196 + Phone: +1-703-689-6425 EMail: tseely@sprint.net - Jeffrey S. Young - Alcatel + Jeff Young - EMail: Jeffrey.S.Young@alcatel.com + EMail: young@jsyoung.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 @@ -459,28 +503,29 @@ 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. + REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE + IETF TRUST 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 (2006). + Copyright (C) The IETF Trust (2006). 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.