Document: draft-ietf-mpls-over-l2tpv3-01.txt Reviewer: Spencer Dawkins Review Date: 2006-09-22 IETF LC Date: 2006-10-04 Summary: This draft is almost ready for publication as a Proposed Standard. Comments: The gaps I saw are mostly in the area of readability, so I don't expect any of my comments to be show-stoppers, but there are some items noted below where the specification is just not clear enough to be published in its current state. These are tagged as "Spencer:". If I was sure enough of the meaning to suggest replacement text, I tagged these as "Spencer (editorial):", and items tagged this way are not part of the Gen-ART review for Brian. Thanks, Spencer 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. Spencer (editorial): "after IP" is really "following IP header", isn't it? ... The optional L2-Specific-Sublayer defined in [RFC3931] is generally Spencer (editorial): I know this term is used in RFC 3931, but wish it was something like "-Sublayer header" or "-Sublayer bits", just for readability. not present for MPLS over L2TPv3. 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. Spencer (editorial): this text seems slightly loose, since previous text said that the Cookie was optional, but this text seems to say that it's mandatory. Isn't it really "and Cookie (if present)"? 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. Spencer: I'm not sure what "applicable compared to" is saying. Is this just "are comparable to", or am I missing something? 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 Spencer (editorial): is this "increases the likelihood that an MPLS label spoofing attack will succeed"? 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 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. Spencer (editorial): "a value that is very difficult to spoof"? MPLS over L2TPv3 may be favorable compared to [RFC4023], if: Spencer: I'm not sure what "may be favorable compared to" is saying. Is this "may have advantages compared to"? 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. Spencer: I'm not sure what this sentence is saying, and can't parse it well enough to rephrase - sorry! 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 Spencer (editorial): ACLs and PEs should both be spelled out on first use. 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). 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 Spencer (editorial): slightly confusing here - "particularly if that hardware is already optimized" 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 L2TPv3. Spencer: I'm confused here. Is this "may be equivalent in complexity to IP encapsulated by MPLS over L2TPv3"? 5. 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 Spencer (editorial): /Operators needs to/Operators should/ to consider the cost to mitigate the risk. 5.1 In the Absence of IPsec However, when the tunnel head and the tunnel tail are not in the same administrative domain, this may become difficult, and filtering based on the destination address can even become impossible if the packets must traverse the public Internet. Spencer: I'm not sure I understand the point being made here. Why does traversing the public internet make this impossible, if crossing administrative domain boundaries makes it difficult? Sometimes only source address filtering (but not destination address 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. 5.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 Spencer: is this "kept secret from an off-path attacker"? 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 Key distribution may be done either manually or automatically by means of IKE [RFC2409]. Manual keying MUST be supported. If Spencer: Is the limitation to IKEv1 intentional? This text seems to preclude use of IKEv2 (RFC 4306). 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.