RE: [tsvwg] Multiprotocol tunneling over UDP using AERO

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

Hi Tom,

> -----Original Message-----
> From: Tom Herbert [mailto:[e-mail]]
> Sent: Tuesday, December 02, 2014 2:40 PM
> To: [e-mail]
> Cc: Templin, Fred L; [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [tsvwg] Multiprotocol tunneling over UDP using AERO
> 
> On Tue, Dec 2, 2014 at 2:26 PM,  <[e-mail]> wrote:
> > 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.
> >
> Another alternative might be to include a checksum in the
> encapsulation header that includes a pseudo header covering ports and
> addresses. This is what we intend to do in Generic UDP Encapsulation
> (draft-herbert-guecsum-00).

Thanks for supplying the fix. This same approach can be adopted by AERO, but
perhaps it would be sufficient to include just the pseudoheader checksum and
not worry about supplying a coverage length to check additional bytes beyond
the pseudoheader?

AERO is a generic UDP encapsulation format for IP-in-(foo)-in-UDP-in-IP
encapsulation. The "(foo)" can be anything, e.g., GRE, MPLS, ESP, AH, etc.
Is that what your are trying to do, too?

Thanks - Fred
[e-mail]

> > 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]
> >
> >