Re: [mpls] [tsvwg] on UDP encapsulation

[Tom Herbert <[e-mail]>]

On Fri, Nov 13, 2015 at 7:10 PM,  <[e-mail]> wrote:
> https://tools.ietf.org/html/rfc7510
>
> I finally noticed that RFC7510, on MPLS in UDP encap, has
> been published. Do take a look at all of section 3, which
> laboriously goes through the nuances of when to choose
> between UDP checksums, for safety, and turning them off,
> for speed, at slight risk. That section and the RFCs it
> refers to are quite the complex read. And that's just on
> UDP checksums and whether to choose to turn them off. (It
> gives dull security documents a run for their money.)
>
> What's odd is that this is standards track, and the third
> option, use standards-track UDP-Lite to provide checksum
> protection of the UDP/IP pseudoheader to avoid zero-checksum
> port pollution on the host (on IPv4) or anywhere pollution
> (IPv6) is not mentioned as an alternative - particularly as
> UDP-Lite's partial payload coverage can cover the MPLS stack
> s well.
>
> In some cases the Lite checksum is just a precomputed value
> across a generated header that doesn't change, at no encode
> cost and little decode cost, and within corporate private
> networks the barriers to running UDP-Lite are less.
>
> It's unfortunate that UDP-Lite is the ideal approach for
> this, yet doesn't deserve consideration. Going back further
> in time, one might argue it's unfortunate that UDP-Lite was
> pushed to a separate protocol number, dooming it to oblivion.
> And, further back, that it was unfortunate that designers of
> IPv6 thought leaving the pseudo-header demux check up to
> separate transports that could then skip it, while insisting
> UDP always have its checksum on, which was always going
> to be relaxed, was a good idea for consistent error-detecting
> demux...
>

Lloyd, the potential for UDP-Lite is mentioned in Encapsulation
Considerations draft (draft-ietf-rtgwg-dt-encap-00):

"Conceptually, the ideal solution to this problem is a checksum that
   covers only the newly added headers of interest.  There is little
   value in the portion of the UDP checksum that covers the encapsulated
   packet because that would generally be protected by other checksums
   and this is the expensive portion to compute.  In fact, this solution
   already exists in the form of UDP-Lite and UDP based encapsulations
   could be easily ported to run on top of it.  Unfortunately, the main
   value in using UDP as part of the encapsulation header is that it is
   recognized by already deployed equipment for the purposes of ECMP,
   RSS, and middlebox operations.  As UDP-Lite uses a different protocol
   number than UDP and it is not widely implemented in middleboxes, this
   value is lost.  A possible solution is to incorporate the same
   partial-checksum concept as UDP-Lite or other header checksum
   protection into the encapsulation header and continue using UDP as
   the outer protocol.  One potential challenge with this approach is
   the use of NAT or other form of translation on the outer header will
   result in an invalid checksum as the translator will not know to
   update the encapsulation header."

IMO, the allowance that nodes may send a zero UDP checksum is a
concession being made for devices that are unable to perform the
computation. These are precisely devices in the network that before
the advent of UDP tunneling never had any reason to source UDP
packets. At end hosts we've had checksum offload capabilities in NICs
for years, so there is no reason a host should send zero UDP checksums
for IPv6 (except if it knows that the receiver is an aforementioned
device that can't do the checksum calculation).

Also, one of primary reasons for UDP encapsulation (e.g. MPLS/UDP,
GRE/UDP) is to get ECMP in the network for non-TCP, non-UDP protocols.
For IPv6 we can use the flow label to provide for this in lieu of
devices parsing the transport layer (RFC6438). We do need switch
support for this and there does seem to be good progress on this. So
the use of the flow label for ECMP should obviate the motivation to
use UDP encapsulation in the first place (for many use cases).

Tom