Spencer, Thank you for your review and comments. Please see inline.
On 9/22/2006 3:37 PM, Spencer Dawkins allegedly said the following: > I have been selected as the General Area Review Team (Gen-ART) reviewer for > this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Please resolve these comments along with any other Last Call comments you > may receive. > > Document: draft-ietf-mpls-over-l2tpv3-01.txt > Reviewer: Spencer Dawkins > Review Date: 2006-09-22 > IETF LC Date: 2006-10-04 > IESG Telechat date: > 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? Yes, we'll change to "following IP (either IPv4 or IPv6) and L2TPv3 headers". > > ... > > 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. I'd like to use the [RFC3931] term, "L2-Specific Sublayer" (without the second dash). I'll ensure this is used consistently throughout the doc. > > 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)"? Yes. And Ack to the rest "Spencer (editorial)" comments. > > 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? Yes it is, will change s/may be applicable compared/is comparable to/. > > 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"? OK. > > 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"? OK. > > 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"? OK, "may be advantageous compared to" (was using favorable as synonym to advantageous, or having advantages). > > 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! It's trying to say that one advantage is when there is already a pre-existing L2TPv3 tunnel between two routers that can be used to send MPLS packets over it. > > 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. OK. > > 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" Yes, thanks. > > 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"? OK. > > 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/ > OK. > 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? Note that a design consideration for this section is to be inline with RFC4023, so there is a desire to stay consistent in this sentence. See second para in http://ietf-tools.sth.netnod.se/html/rfc4023#section-8.2 > > 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"? Yes, thanks. > > 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). It was not intended to preclude IKEv2, we'll add it. Thanks again, --Carlos. > > 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. > -- --Carlos Pignataro. Escalation RTP - cisco Systems _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
