Subject: [tsvwg] Multiprotocol tunneling over UDP using AERO

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 2 Dec 2014 20:57:40 +0000

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
[email-masked]

---

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
[email-masked]

---

From: <[email-masked]>
Date: Tue, 2 Dec 2014 22:26:39 +0000

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 <[email-masked]> on behalf of Templin, Fred L <[email-masked]>
Sent: Wednesday, 3 December 2014 7:57 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: [tsvwg] Multiprotocol tunneling over UDP using AERO

Hello,

Thanks - Fred

---

Hello,

Thanks - Fred

---

From: Tom Herbert <[email-masked]>
Date: Tue, 2 Dec 2014 14:40:03 -0800

> 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).

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 2 Dec 2014 23:10:45 +0000

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, December 02, 2014 2:27 PM
> To: Templin, Fred L; [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Multiprotocol tunneling over UDP using AERO
> 
> Fred,
> 
> 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.)
> 
> - 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.
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 2 Dec 2014 23:17:57 +0000

Hi Tom,

> From: Tom Herbert [mailto:[email-masked]]
> Sent: Tuesday, December 02, 2014 2:40 PM
> To: [email-masked]
> Cc: Templin, Fred L; [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [tsvwg] Multiprotocol tunneling over UDP using AERO
> 
> > - 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.
> >
> > 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?
> >

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 2 Dec 2014 23:29:50 +0000

Hi,

One other thing that may or may not be worth mentioning is that AERO already has an
IANA-assigned UDP port number:

aero               8060        udp    Asymmetric Extended Route    [IESG]                                                [IETF_Chair]                                                                        [RFC6706]
                                      Optimization (AERO)

Thanks - Fred

> From: Int-area [mailto:[email-masked]] On Behalf Of Templin, Fred L
> Sent: Tuesday, December 02, 2014 12:58 PM
> Subject: [Int-area] Multiprotocol tunneling over UDP using AERO
> 
> Hello,
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area