Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rfc5405bis-00.txt

From: [email-masked]
Date: Mon, 15 Dec 2014 08:58:38 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Transport Area Working Group Working Group of the IETF.

        Title           : UDP Usage Guidelines
        Authors         : Lars Eggert
                          Godred Fairhurst
                          Greg Shepherd
	Filename        : draft-ietf-tsvwg-rfc5405bis-00.txt
	Pages           : 37
	Date            : 2014-12-15

Abstract:
   The User Datagram Protocol (UDP) provides a minimal message-passing
   transport that has no inherent congestion control mechanisms.
   Because congestion control is critical to the stable operation of the
   Internet, applications and other protocols that choose to use UDP as
   an Internet transport must employ mechanisms to prevent congestion
   collapse and to establish some degree of fairness with concurrent
   traffic.  They may also need to implement additional mechanisms,
   depending on how they use UDP.

   This document provides guidelines on the use of UDP for the designers
   of applications, tunnels and other protocols that use UDP.
   Congestion control guidelines are a primary focus, but the document
   also provides guidance on other topics, including message sizes,
   reliability, checksums, and middlebox traversal.

   If published as an RFC, this document will obsolete RFC5405.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tsvwg-rfc5405bis-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: <[email-masked]>
Date: Fri, 26 Dec 2014 17:01:43 +0000

A comment pertaining to checksum use.

This draft does not discuss that the udp checksum is scoped end to end between hosts, unlike the stronger link layer checksums, and that a strong link checksum is no substitute for that path functionality.

While recommending the UDP checksum SHOULD be used is a fine default, a rash of tunnelling protocols have said 'we already have payload protection, we don't need udp checksum compute overhead' and have used the mere existence of RFC6395/RFC6396 as justification for turning the checksum off, nuance be damned. Which is bad from a demultiplexed-corrupted-IPv6-packets go anywhere point of view.

I would argue that using UDP Lite to only checksum your UDP/IP header fields is always preferable to a UDP zero checksum, in that then your payload can still be messed up and that's your problem, but having your corrupted packets injected anywhere else is prevented. A zero udp checksum should always be the very last option. For IPv6, UDP Lite doing the pseudo header check is far far preferable to zero UDP checksum, and the draft should say as much.

Please reread the 'By default' paragraph (second para of 3.4.1) - greater should be lesser in this context, as default is full coverage, and you can only go down.

(What would it take to have UDP itself be changed to allow two okay values for the checksum - checksum is either just across UDP/IP pseudoheaders or full payload, and you can incrementally compute pseudoheader onthe way to full, say 'we matched headers at this point, no need to check rest of payload'. I doubt it weakens the full payload check significantly, and is a more transparent ligtweight header check than UDP Lite. no clue what this ,ight do to middleboxes, though.)

Lloyd Wood
http://about.me/lloydwood

________________________________________
From: tsvwg <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Tuesday, 16 December 2014 3:58:38 AM
To: [email-masked]
Cc: [email-masked]
Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rfc5405bis-00.txt

Abstract:

---

From: "Black, David" <[email-masked]>
Date: Sat, 27 Dec 2014 04:52:35 +0000

Lloyd,

<WG chair hat off>

> This draft does not discuss that the udp checksum is scoped end to end between
> hosts, unlike the stronger link layer checksums, and that a strong link
> checksum is no substitute for that path functionality.

Thanks for a timely comment ...

> While recommending the UDP checksum SHOULD be used is a fine default, a rash
> of tunnelling protocols have said 'we already have payload protection, we
> don't need udp checksum compute overhead' and have used the mere existence of
> RFC6395/RFC6396 as justification for turning the checksum off, nuance be
> damned. Which is bad from a demultiplexed-corrupted-IPv6-packets go anywhere
> point of view.

Indeed, and please have a look at Section 3.1 of draft-ietf-mpls-in-udp-09 as a
current cross-area (TSV/RTG) attempt to do better:

http://tools.ietf.org/html/draft-ietf-mpls-in-udp-09#section-3.1

> I would argue that using UDP Lite to only checksum your UDP/IP header fields
> is always preferable to a UDP zero checksum in that then your payload can
> still be messed up and that's your problem, but having your corrupted packets
> injected anywhere else is prevented.

In principle, sure, I agree, but in practice, there are "running code" problems
with network gear that passes UDP but not UDP-Lite (port-translating NATs are
well-known offenders) and more importantly that load balances (ECMP or Ethernet
LAG) UDP traffic, but not UDP-Lite traffic :-(.

> A zero udp checksum should always be the
> very last option. For IPv6, UDP Lite doing the pseudo header check is far far
> preferable to zero UDP checksum, and the draft should say as much.

No argument there in principle, but when UDP-Lite doesn't work in practice
(wrong protocol # in IP header), then what?

> (What would it take to have UDP itself be changed to allow two okay values for
> the checksum - checksum is either just across UDP/IP pseudoheaders or full
> payload, and you can incrementally compute pseudoheader on the way to full, say
> 'we matched headers at this point, no need to check rest of payload'. I doubt
> it weakens the full payload check significantly, and is a more transparent
> lightweight header check than UDP Lite. no clue what this might do to
> middleboxes, though.)

A significant concern here is backwards compatibility - middleboxes, end systems,
and network mgt/ops tools, although this is something that some new uses of UDP
could be encouraged to do with the next header inside UDP (use zero UDP checksum
and insert a "shim" that includes a checksum of the UDP/IP pseudoheaders and the
shim).

</WG chair hat off>

Thanks,
--David

> -----Original Message-----
> From: tsvwg [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Friday, December 26, 2014 12:02 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rfc5405bis-00.txt
> 
> This draft does not discuss that the udp checksum is scoped end to end between
> hosts, unlike the stronger link layer checksums, and that a strong link
> checksum is no substitute for that path functionality.
> 
> While recommending the UDP checksum SHOULD be used is a fine default, a rash
> of tunnelling protocols have said 'we already have payload protection, we
> don't need udp checksum compute overhead' and have used the mere existence of
> RFC6395/RFC6396 as justification for turning the checksum off, nuance be
> damned. Which is bad from a demultiplexed-corrupted-IPv6-packets go anywhere
> point of view.
> 
> I would argue that using UDP Lite to only checksum your UDP/IP header fields
> is always preferable to a UDP zero checksum, in that then your payload can
> still be messed up and that's your problem, but having your corrupted packets
> injected anywhere else is prevented. A zero udp checksum should always be the
> very last option. For IPv6, UDP Lite doing the pseudo header check is far far
> preferable to zero UDP checksum, and the draft should say as much.
> 
> Please reread the 'By default' paragraph (second para of 3.4.1) - greater
> should be lesser in this context, as default is full coverage, and you can
> only go down.
> 
> (What would it take to have UDP itself be changed to allow two okay values for
> the checksum - checksum is either just across UDP/IP pseudoheaders or full
> payload, and you can incrementally compute pseudoheader onthe way to full, say
> 'we matched headers at this point, no need to check rest of payload'. I doubt
> it weakens the full payload check significantly, and is a more transparent
> ligtweight header check than UDP Lite. no clue what this ,ight do to
> middleboxes, though.)
> 
> Lloyd Wood

---

From: Tom Herbert <[email-masked]>
Date: Sat, 27 Dec 2014 09:42:10 -0800

Lloyd, David

Comments inline.

> current cross-area (TSV/RTG) attempt to do better:
draft-ietf-mpls-in-udp-09 and RFC6936 are much more restrictive in the
use of zero UDP checksum in IPv6 than what is described here. Those
seem to require that IPv6 UDP checksum MUST be enabled unless certain
requirements are meant when using UDP tunnels.

It might be good to include the motivation for using zero UDP checksum.
Presumably, the core motivation is either performance cost of
computing full checksum or communicating with devices that can't
compute the checksum.

I would imagine that the majority of devices that terminate UDP are
end hosts which can already compute UDP checksum, and probably in the
majority of those there are NICs that offload the UDP checksum so it
is no performance impact. In these cases, UDP checksum should be
enabled. In some cases, enabling UDP checksum with tunnels can be a
performance win over using zero UDP checksum when properly leveraging
UDP checksum offload capability.

We do know that some devices, switches in particular, will be
terminating UDP (tunnels) and they may not have the capability to
compute a UDP checksum. For these, UDP zero checksums are useful (per
RFC6336), but the case where one of these devices receives a packet
with a non-zero UDP checksum must be considered. VXLAN (RFC7348) makes
checksum verification optional, but this seems to be inconsistent with
RFC1122. I would suggest a requirement something like: "If a UDP
datagram is received with a checksum that is non-zero and the node is
unable to verify the checksum, the node MUST discard the datagram."

Thanks,
Tom

---

From: <[email-masked]>
Date: Sun, 28 Dec 2014 08:34:57 +0000

David,

an mpls-in-udp suggestion:

as motivation and context: "Across an Ethernet link, errors in transmission of the MPLS stack and payload are detected and prevented from propagating further at the correct destination by the Ethernet frame CRC. Across a longer Internet path, the weaker UDP checksum provides the same important functionality for MPLS-in-UDP"

that is,the motivation should be why the checksum a good idea. not the reverse of "oooh, faster"

Tom, a device that can't compute a UDP checksum (ones complement? not hard) can't compute a TCP checksum either. What is it doing on the public internet, and why is it the IETF's concern?

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: Tom Herbert <[email-masked]>
Sent: Sunday, 28 December 2014 4:42:10 AM
To: Black, David
Cc: Wood L  Dr (Electronic Eng); [email-masked]; [email-masked]; [email-masked]
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rfc5405bis-00.txt

Lloyd, David

Comments inline.

Thanks,
Tom

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 28 Dec 2014 08:43:27 -0000

Lloyd,

> Tom, a device that can't compute a UDP checksum (ones complement? not hard)
> can't compute a TCP checksum either. What is it doing on the public internet,
and
> why is it the IETF's concern?

This was my thought, too, but...
It has been observed that where UDP is being used as a tunnel the end points of
the tunnel are not end systems and will be processing traffic "at line speed".
It has been claimed that, for some of these, the additional overhead of
processing the UDP checksum will be a step too far.
Possibly this is because the tunnel end points will be in software not in
hardware.
I have no knowledge of these reported devices, but I am assured that they exist.

Adrian

---

From: Dave Taht <[email-masked]>
Date: Sun, 28 Dec 2014 08:44:57 -0800

> UDP checksum offload capability.

As a reality injection note, I think tom is one of the authors of the new
"fou" (Foo over UDP) infrastructure in linux, which makes it possible
to hand off even
encapsulated checksumming/checking to hardware.

http://lwn.net/Articles/614348/

I have been struggling to find a mental model for how to use it generically,
(as in the tinc vpn, for instance)...

-- 
Dave Täht

thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks

---

From: [email-masked]
Date: Mon, 29 Dec 2014 03:06:29 -0000

Hi Lloyd,

> This draft does not discuss that the udp checksum is scoped end to end
> between hosts, unlike the stronger link layer checksums, and that a strong
> link checksum is no substitute for that path functionality.
>
> While recommending the UDP checksum SHOULD be used is a fine default, a
> rash of tunnelling protocols have said 'we already have payload
> protection, we don't need udp checksum compute overhead' and have used the
> mere existence of RFC6395/RFC6396 as justification for turning the
> checksum off, nuance be damned. Which is bad from a
> demultiplexed-corrupted-IPv6-packets go anywhere point of view.
>
> I would argue that using UDP Lite to only checksum your UDP/IP header
> fields is always preferable to a UDP zero checksum, in that then your
> payload can still be messed up and that's your problem, but having your
> corrupted packets injected anywhere else is prevented. A zero udp checksum
> should always be the very last option. For IPv6, UDP Lite doing the pseudo
> header check is far far preferable to zero UDP checksum, and the draft
> should say as much.
>
> (What would it take to have UDP itself be changed to allow two okay values
> for the checksum - checksum is either just across UDP/IP pseudoheaders or
> full payload, and you can incrementally compute pseudoheader onthe way to
> full, say 'we matched headers at this point, no need to check rest of
> payload'. I doubt it weakens the full payload check significantly, and is
> a more transparent ligtweight header check than UDP Lite. no clue what
> this might do to middleboxes, though.)
>
> Lloyd Wood
I agree that the draft has to be updated to include better guidance on the
checksum position, and we'll try to do that. The text above seems like a
reasonable list of things to include.

As someone who would like to see UDP-Lite-style checksums in UDP, I'd
support your proposal to explore what would happen if UDP-Lite were to be
used over port 17 rather than just port 136. Is what you are proposing
similar to:
https://tools.ietf.org/html/draft-fairhurst-6man-tsvwg-udptt-03

Since  this was written in 2010, my research group has grown some tools
that could now be used to test deployability and I'm hoping we can do some
middlebox traversal experiments to explore how deployable this may be
early next year... thoughts and other ideas welcome.

Gorry

---

From: <[email-masked]>
Date: Mon, 29 Dec 2014 08:04:49 +0000

Gorry,

We agree that lite fuctionality is really only useful when it covers the udp header, which is why you give a udp length field of 8. Partial payload coverage for additional headers and payloads is nice, but generally rarely used.

But code does rely on that udp length field, which is why udp lite wasn't a simple in-place upgrade to port 17. Many years of reaching rough consensus on udp lite was defeated by the running udp code.

My suggestion differs from your udptt: leave the length field as is, so still full udp length, but the checksum can represent either the full payload check or the header length 8-byte check. No indication of which it is is given - but the header 8-byte check is done on the way to computing the full payload check. If you know you only want to do the header check, if the 8-byte header check passes, stop and you're good. If that doesn't pass, you can continue and do the full udp payload checksum if you want. The risk of a header checksum being corrupted to match a full-length checksum when a packet is damaged is low - most middlebox damage is likely payload truncation. The added overhead of pausing at 8 and checking that value is low - and is only done by endhosts that care, and they gain in those cases from not doing the full payload check.

My belief is that not messing with the udp length field at all will get easier access through middleboxes than flagging 8 bytes in that field, because procssing can key off that length field, while incremental udp checksum fixups after NAT etc will be preserved. Messing with the length field breaks the semantics of the UDP standard, and that's why Lite got booted to a different port; subtly overloading the udp checksum field to have two acceptable values, one for fixed header length, one for full payload length, does not.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: [email-masked] <[email-masked]>
Sent: Monday, 29 December 2014 2:06:29 PM
To: Wood L  Dr (Electronic Eng)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rfc5405bis-00.txt

Hi Lloyd,

Gorry

---

From: [email-masked]
Date: Mon, 29 Dec 2014 08:37:25 -0000

OK - Lloyd, I recall part of the "history" was that at the time, UDP-Lite
was standardised people were advocating different "protocol" values for
different transports - at this point in Internet history it is entirely
possible a different approach may have made its way through the IESG.

I understand the proposal below, and agree that (like UDPTT) it will take
very few additional cycles to process.

Since these are targeted at the edge, I suggest we need to understand the
chances of middlebox traversal for either of the methods - and I will try
to look at these early next year.

Gorry

> Gorry,
>
> We agree that lite fuctionality is really only useful when it covers the
> udp header, which is why you give a udp length field of 8. Partial payload
> coverage for additional headers and payloads is nice, but generally rarely
> used.
>
> But code does rely on that udp length field, which is why udp lite wasn't
> a simple in-place upgrade to port 17. Many years of reaching rough
> consensus on udp lite was defeated by the running udp code.
>
> My suggestion differs from your udptt: leave the length field as is, so
> still full udp length, but the checksum can represent either the full
> payload check or the header length 8-byte check. No indication of which it
> is is given - but the header 8-byte check is done on the way to computing
> the full payload check. If you know you only want to do the header check,
> if the 8-byte header check passes, stop and you're good. If that doesn't
> pass, you can continue and do the full udp payload checksum if you want.
> The risk of a header checksum being corrupted to match a full-length
> checksum when a packet is damaged is low - most middlebox damage is likely
> payload truncation. The added overhead of pausing at 8 and checking that
> value is low - and is only done by endhosts that care, and they gain in
> those cases from not doing the full payload check.
>
> My belief is that not messing with the udp length field at all will get
> easier access through middleboxes than flagging 8 bytes in that field,
> because procssing can key off that length field, while incremental udp
> checksum fixups after NAT etc will be preserved. Messing with the length
> field breaks the semantics of the UDP standard, and that's why Lite got
> booted to a different port; subtly overloading the udp checksum field to
> have two acceptable values, one for fixed header length, one for full
> payload length, does not.
>
> Lloyd Wood
>> From: tsvwg <[email-masked]> on behalf of
>> [email-masked]
>> <[email-masked]>