Subject: [Gen-art] Gen-ART LC Review of draft-ietf-mpls-over-l2tpv3-01.txt

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 22 Sep 2006 14:37:55 -0500

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?

...

   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.

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Carlos Pignataro <[email-masked]>
Date: Sun, 24 Sep 2006 13:58:15 -0400

Spencer,

Thank you for your review and comments. Please see inline.

> 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".

> 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.

> mandatory. Isn't it really "and Cookie (if present)"?

Yes. And Ack to the rest "Spencer (editorial)" comments.

> "are comparable to", or am I missing something?

Yes it is, will change s/may be applicable compared/is comparable to/.

> spoofing attack will succeed"?

OK.

> Spencer (editorial): "a value that is very difficult to spoof"?

OK.

> "may have advantages compared to"?

OK, "may be advantageous compared to" (was using favorable as synonym to
advantageous, or having advantages).

> 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.

> Spencer (editorial): ACLs and PEs should both be spelled out on first use.

OK.

> hardware is already optimized"

Yes, thanks.

> encapsulated by MPLS over L2TPv3"?

OK.

> Spencer (editorial): /Operators needs to/Operators should/

OK.

> 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

> Spencer: is this "kept secret from an off-path attacker"?

Yes, thanks.

> Spencer: Is the limitation to IKEv1 intentional? This text seems to preclude

It was not intended to preclude IKEv2, we'll add it.

Thanks again,

--Carlos.

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 25 Sep 2006 13:59:41 -0500

Hi, Carlos,

Thanks for the quick feedback. I think we can finish this up today.

Please see inline.

Spencer

> second dash). I'll ensure this is used consistently throughout the doc.

This works for me. I wish "Sublayer" sounded more like a header field than 
part of a protocol stack, but the community may already be accustomed to 
this usage.

> advantageous, or having advantages).

This is fine, and helps me to parse the next sentence.

> pre-existing L2TPv3 tunnel between two routers that can be used to send

OK, I think I understand now. Suggest "Two routers are already "adjacent" 
over an L2TPv3 tunnel established for some other reason, and wish to 
exchange MPLS packets over that adjacency."

> second para in http://ietf-tools.sth.netnod.se/html/rfc4023#section-8.2

I understand the design consideration (and see that the same paragraph 
appears in RFC 4023), I was saying that the text didn't explain why 
destination filtering was difficult/impossible. It may be that I'm the only 
person who doesn't know why - in that case, the text is fine :-)

Thanks,

Spencer

---

From: Carlos Pignataro <[email-masked]>
Date: Mon, 25 Sep 2006 21:24:29 -0400

Hi Spencer,

Thanks again, please see inline.

> part of a protocol stack, but the community may already be accustomed to 

OK. I see your point; but I believe that the common usage of the term
carries an implicit "header" in its meaning though.

OK.

> exchange MPLS packets over that adjacency."

That works, thanks for the suggestion.

> person who doesn't know why - in that case, the text is fine :-)

OK, will keep the text as is.

Many thanks for your review !

--Carlos.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 25 Sep 2006 20:48:41 -0500

Hi, Brian,

I would say "good to go" on this draft, with the editorial changes I
have discussed with Carlos.

Thanks,

Spencer