RE: Multiprotocol tunneling over UDP using AERO

["Templin, Fred L" <[e-mail]>]

Hi Llloyd,

Thanks for the excellent analysis. I have had my head down on other aspects of the
spec and not following the UDP checksum discussions. I will fix it.

Thanks - Fred
[e-mail]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Tuesday, December 02, 2014 2:27 PM
> To: Templin, Fred L; [e-mail]; [e-mail]; [e-mail]
> Subject: Re: Multiprotocol tunneling over UDP using AERO
> 
> Fred,
> 
> I see Adrian mentioned checksums in his reply to you. To elaborate on his point:
> 
> http://datatracker.ietf.org/doc/draft-templin-aerolink/
> says:
> 
>    The AERO interface
>    also sets the UDP checksum field to zero (see: [RFC6935][RFC6936])
>    unless an integrity check is required (see: Section 3.12.2).
> 
> This misses the more subtle implications of zero checksums. As RFC6936 says:
>    The current recommendation
>    is to use or fall back to using UDP with full checksum coverage.
> 
> RFC6935 is written from the perspective of tunnelled traffic that can have its own checks, rather than from the larger perspective of
> what is good for the network; the zero checksum was inconvenient for tunnellers, hence RFC6935. (While RFC6936 is rather academic
> and nuanced in its tone, as it steps through the necessary safeguards that that use of zero checksums requires of everything else;
> sometimes 'don't do that, stupid!' is the clearer and simpler approach to both writing and engineering.)
> 
> A zero UDP checksum means:
> 
> - in IPv4, potential delivery to any port on the destination device if there is UDP header corruption. (the IPv4 header checksum can
> prevent host misdelivery). This is port pollution.
> 
> - in IPv6, potential delivery to anywhere if there is IP/UDP header corruption (as there is no IP header checksum, and using a zero UDP
> sum turns off the endhost pseudoheader check - and tunnels often terminate on routers that forward packets...). This is network
> pollution.
> 
> So, use a zero UDP checksum, and the IPv6 traffic you generate can be potentially injected anywhere to affect anything, modulo all
> the careful nuance in RFC6936 to start guarding against this - guards required by everything else. But your tunnel traffic can have its
> own checks and its own repeat/replay, so you're alright.
> 
> (UDP-Lite provides a minimal interface to build on with necessary endhost pseudo-header check and low computation cost for
> application designers; shame it's not more prevalent.)
> 
> Analogies with nice clean factories pumping into dirty rivers fit nicely here. It's a tragedy that people downstream were relying on the
> river water, but it's clearly not the factory designer's fault. As if. Those people just didn't implement the safeguards in the small print.
> And environmental protection wasn't a design goal. Why care about the commons?
> 
> My take here is that IPv6 was not well-designed in this regard. An IP header checksum across non-mutable fields, excluding QoS/TTL
> etc., that did not need to be recomputed, would have been preferable. A mandatory endhost pseudoheader check would have been
> preferable. Expecting protocol designers to do the right thing above IP and do the necessary pseudo-header check has been
> repeatedly demonstrated to presume too much knowledge in those that follow. Hardly the only IPv6 mistake, but not one we should
> be compounding.
> 
> Please fix AERO, and follow RFC6936's recommendation.
> 
> Lloyd Wood
> http://about.me/lloydwood
> 
> you'll notice I'm not also asking you to fix the bundle protocol. Lost cause.
> ________________________________________
> From: tsvwg <[e-mail]> on behalf of Templin, Fred L <[e-mail]>
> Sent: Wednesday, 3 December 2014 7:57 AM
> To: [e-mail]; [e-mail]; [e-mail]
> Subject: [tsvwg] Multiprotocol tunneling over UDP using AERO
> 
> Hello,
> 
> I am replaying a message below that was originally posted on the routing-discussion
> list yesterday. Follow-up discussion was then posted in two additional messages. The
> messages are here:
> 
> http://www.ietf.org/mail-archive/web/routing-discussion/current/msg01949.html
> http://www.ietf.org/mail-archive/web/routing-discussion/current/msg01950.html
> http://www.ietf.org/mail-archive/web/routing-discussion/current/msg01951.html
> 
> I am cross-posting to transport area and int area now, because there seems to be
> an overlap of interests with respect to UDP tunneling that may transcend traditional
> area boundaries. Original message appears below; please post comments to the lists.
> 
> Thanks - Fred
> [e-mail]
> 
> ---
> 
> Hello,
> 
> I am working on a spec for generic tunneling of any protocol over UDP, including
> MPLS, GRE, IPsec, etc. The spec is called "AERO", and it includes:
> 
>   - an encapsulation format
>   - a fragmentation and reassembly capability for MTU mitigation
>   - a virtual link model
>   - a control messaging mechanism
>   - a routing and addressing system based on BGP
> 
> https://datatracker.ietf.org/doc/draft-templin-aerolink/
> 
> I understand that there have been discussions regarding protocol-specific
> GRE and MPLS encapsulations within UDP, but I would like to offer up AERO
> as a protocol-independent way of accommodating UDP encapsulations. I
> also believe the routing system and other aspects of AERO should be of
> interest to the routing area.
> 
> This work is derived from an earlier experimental RFC (RFC6706) which was
> originally briefed to the routing area several years ago and published as an
> AD-sponsored Individual Submission RFC. The current document can be
> considered as a second edition of AERO, and the goal is to advance it to
> standards track. Please send any comments or questions to the list.
> 
> Thanks - Fred
> [e-mail]