[secdir] secdir review of draft-ietf-mpls-in-udp-03

[Charlie Kaufman <[e-mail]>]

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