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

[Xuxiaohu <[e-mail]>]

Hi Charlie,

Thanks a lot for your Secdir review of this draft. We will incorporate your comments in the next revision.

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: Charlie Kaufman [mailto:[e-mail]]
> 发送时间: 2013年10月22日 7:10
> 收件人: [e-mail]; [e-mail]; [e-mail]
> 主题: [secdir] secdir review of draft-ietf-mpls-in-udp-03
> 
> 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
>