Re: Multiprotocol tunneling over UDP using AERO

[<[e-mail]>]

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]