Early Review of draft-ietf-mpls-in-udp-03
review-ietf-mpls-in-udp-03-secdir-early-kaufman-2013-10-24-00

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

This document defines an encapsulation format for MPLS over UDP. There are
already specifications for MPLS over GRE and MPLS over IP. The motivation to
add this third encapsulation format is to allow better path splitting of the
various substreams within the tunnel. It does this with a clever (and some
would say abusive) use of the UDP Source Port field. Because existing routers
know to identify different streams based on the five tuple of source-IP,
destination-IP, source-port, destination-port, and protocol, this encapsulation
attempts to preserve that entropy by setting the source port equal to a hash of
those 5 values of the encapsulated packet.

There is another possible motivation (which I'm surprised the specification
does not mention), which is that some firewalls are willing to pass UDP but not
GRE or MPLS packets.

The Security Considerations correctly notes that this encapsulation format does
not provide any integrity or confidentiality protection, and that if such
protection were to be provided with IPsec in transport mode then the advantage
of better path splitting of the various substreams would be lost. A similar
design could be used when encapsulating IPsec over UDP at the cost of leaking
information about the substreams to traffic analysis. But that would belong in
some other spec that specified an alternate IPsec over UDP format (almost
certainly using a different UDP port).

My only complaint - and it is a minor one - is with the "Congestion
Considerations" section. There, I expected to see something about the handling
of the congestion-experienced bits (though the correct processing is obvious,
probably covered by "Common Procedures" in RFC4023, and perhaps not worth
mentioning). The spec says that if the tunneled traffic is not known to be TCP
friendly and if the flow runs across an unprovisioned path that could
potentially be congested, then the *application* MUST employ additional
mechanisms to ensure that the offered load is reduced appropriately during
periods of congestion. My complaint is that there is no way for the routers
doing the encapsulation/decapsulation to participate in the congestion
mitigation process and therefore no way for an implementation of this
specification to be influenced by this requirement. I believe the spec would be
equivalent and more clear had it said that the tunneled traffic MUST be TCP
friendly. Even then, this seems more like operational guidance than a normative
part of the specification.

I mention these only as suggestions to the community. From a security
standpoint, I believe the document is just fine as is.

        --Charlie