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 protected]
https://www1.ietf.org/mailman/listinfo/gen-art
