Subject: [mpls] Fw: on UDP encapsulation

From: <[email-masked]>
Date: Sat, 14 Nov 2015 03:30:55 +0000 (UTC)

oops, typoed mpls list email address previously.
      On Saturday, 14 November 2015, 14:10, "[email-masked]" <[email-masked]> wrote:

 https://tools.ietf.org/html/rfc7510

I finally noticed that RFC7510, on MPLS in UDP encap, hasbeen published. Do take a look at all of section 3, whichlaboriously goes through the nuances of when to choosebetween UDP checksums, for safety, and turning them off,for speed, at slight risk. That section and the RFCs itrefers to are quite the complex read. And that's just onUDP checksums and whether to choose to turn them off. (Itgives dull security documents a run for their money.)
What's odd is that this is standards track, and the thirdoption, use standards-track UDP-Lite to provide checksumprotection of the UDP/IP pseudoheader to avoid zero-checksumport pollution on the host (on IPv4) or anywhere pollution(IPv6) is not mentioned as an alternative - particularly asUDP-Lite's partial payload coverage can cover the MPLS stack s well.
In some cases the Lite checksum is just a precomputed valueacross a generated header that doesn't change, at no encodecost and little decode cost, and within corporate privatenetworks the barriers to running UDP-Lite are less.
It's unfortunate that UDP-Lite is the ideal approach forthis, yet doesn't deserve consideration. Going back furtherin time, one might argue it's unfortunate that UDP-Lite waspushed to a separate protocol number, dooming it to oblivion.And, further back, that it was unfortunate that designers ofIPv6 thought leaving the pseudo-header demux check up toseparate transports that could then skip it, while insistingUDP always have its checksum on, which was always goingto be relaxed, was a good idea for consistent error-detectingdemux...
One might argue it's unfortunate. With the benefit of perfecthindsight, I favour 'bloody stupid' myself.
Does the IETF no longer work on UDP-Lite? Should UDP-Lite bemoved to Historic, along with SCTP and DCCP, becausethey're not TCP or UDP - even though delivery of tunnelledpayloads with demux protection is UDP-Lite's ideal application?
thanks
L.
Lloyd Woodhttp://about.me/lloydwood

---

From: Tom Herbert <[email-masked]>
Date: Sat, 14 Nov 2015 10:06:16 -0800

On Fri, Nov 13, 2015 at 7:10 PM,  <[email-masked]> wrote:
> 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

---

From: "Black, David" <[email-masked]>
Date: Mon, 16 Nov 2015 00:52:38 +0000

Lloyd,

> > gives dull security documents a run for their money.)

To complete the picture, UDP checksums come up again in the
final paragraph of the security considerations section ;-).

With respect to UDP-Lite, Tom described the primary consideration

> GRE/UDP) is to get ECMP in the network for non-TCP, non-UDP protocols.

That consideration ruled out UDP-Lite for the specific MPLS/UDP encap.
However, a discussion of the applicability and merits of UDP-Lite for
this sort of encap would be germane to the UDP Usage Guidelines draft,
draft-ietf-tsvwg-rfc5405bis:

	http://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/

Could I ask you to take a look at that draft?  TSVWG plans to send
it to the IESG in the near future.

Thanks,
--David

> -----Original Message-----
> From: tsvwg [mailto:[email-masked]] On Behalf Of Tom Herbert
> Sent: Saturday, November 14, 2015 1:06 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [tsvwg] on UDP encapsulation
>

---

From: <[email-masked]>
Date: Sun, 22 Nov 2015 11:20:37 +0000 (UTC)

David,
good idea. My suggested changes to RFC5405bis's UDP-Lite section, touching on processing overheads, Lite as a preferable alternative to zero checksums etc., are attached. Lloyd Wood [email-masked] http://about.me/lloydwood  

    On Monday, 16 November 2015, 11:53, "Black, David" <[email-masked]> wrote:

 Lloyd,

Thanks,
--David