Subject: [tsvwg] UDP Options Implementation Update

From: "[email-masked]" <[email-masked]>
Date: Mon, 5 Nov 2018 06:33:00 +0000

Here is a brief update on the implementation work in FreeBSD.
 
Current UDP Options (as of draft-ietf-tsvwg-udp-options-05) and their
implementation status:
 
 0*      -         End of Options List (EOL)             - Implemented
 1*      -         No operation (NOP)                    - Implemented
 2*      2         Option checksum (OCS)                 - Implemented (replace with CCO?)
 5*      4         Maximum segment size (MSS)            - Implemented
 7       10        Timestamps (TIME)                     - Implememented
 ...     (varies)  UNASSIGNED/RESERVED                   - as in spec.
 
 3*      4         Alternate checksum (ACS)              - OK (but not yet implemented)
 
In September, Joe said he would add the REQ and RES options (described in
draft-ietf-tsvwg-datagram-plpmtud-05) to the next rev of the document.
 
 9       6         Request (REQ)                         - Also implemented
 10      6         Response (RES)                        - Also implemented
 
At IETF-103 we are presenting the CCO
(draft-fairhurst-udp-options-cco, see maprg and tsvwg second meeting).
We think use of the CCO is required on the internet and an checksum
using the CCO pseudo header should replace the OCS.
 
 xx      4         Checksum Compensation Option (CCO)    - An alternative approach to OCS
 
All of the above has been tested and is being used in experiments with UDP-Options.
 
---
   
We are left with questions about FRAG, LITE and AE - all currently not implemented.
 
 4*      4         Lite (LITE)                           - See below
 
LITE - The specification for LITE is complicated, but we think implementation
        is possible.

        The way in which LITE is processed in the current specification, means
        that if there is a mistake in the implemenation or a change to this in
        future, then it will mangle everything in the option space.

        At this time our University does not have a use case that
        needs this, so we don't expect to be adding this anytime soon,
        how does the WG wish to handle this?
 
 6*      8/10      Fragmentation (FRAG)                  - See below
 
FRAG - Support for fragments in transport and network protocols are difficult
       to handle, partly because of need to consider attack vectors and
       partly because of need to manage reassembly buffers. That isn't
       something an endpoint would enable as default.

       The current spec puts data in the UDP payload, which does not seem
       correct.

       We don't have any current plans to add this ourselves. Are others
       implementing?
 
 8       (varies)  Authentication and Encryption (AE)    - See below
 
AE   - I think this is underspecified. An option in this space does make
        sense, but it should probably be could be specified in a seperate document
        where the security details are described - doing this later does not
        appear to be an issue.
 
 - Tom

---

From: Derek Fawcus <[email-masked]>
Date: Mon, 5 Nov 2018 12:22:27 +0000

>  xx      4         Checksum Compensation Option (CCO)    - An alternative approach to OCS

Oh - I like that.

Have you actually observed any middlebox corruption or mis-checking along the lines mentioned?

If so, then it would seem this new option would be mandatory to include in
all UDP packets containing UDP options.

DF

---

From: Joe Touch <[email-masked]>
Date: Mon, 5 Nov 2018 07:14:41 -0800

This is an opportunity to fix a bug.  We don’t design protocols to withstand arbitrary coding errors. This should remain optional.

Joe

> On Nov 5, 2018, at 4:22 AM, Derek Fawcus <[email-masked]> wrote:
>

---

From: Tom Herbert <[email-masked]>
Date: Mon, 5 Nov 2018 07:24:17 -0800

> Have you actually observed any middlebox corruption or mis-checking along the lines mentioned?

That should be explicitly tested by sourcing bad packets. I believe
that a single bit flip in the option type of a OCS will not be
detected as an error.

Tom

---

From: Joe Touch <[email-masked]>
Date: Mon, 5 Nov 2018 07:51:05 -0800

I keep repeating this, but AGAIN:
	
	OCS is NOT intended as a check against bit errors

That is the role of ACS.

Joe

> On Nov 5, 2018, at 7:24 AM, Tom Herbert <[email-masked]> wrote:
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 5 Nov 2018 08:00:47 -0800

FWIW, before everyone jumps in, ACS is for the UDP payload not the options.
We don’t really have a ‘strong’ checksum for the header itself, but that’s no different from IP (which uses a weak checksum) and especially IPv6 (which uses no checksum at all).

There’s simply no reason that UDP should be stronger than IP in this regard. 

Joe

> On Nov 5, 2018, at 7:51 AM, Joe Touch <[email-masked]> wrote:
>

---

From: Derek Fawcus <[email-masked]>
Date: Mon, 5 Nov 2018 16:02:15 +0000

> This is an opportunity to fix a bug.  We don’t design protocols to withstand arbitrary coding errors. This should remain optional.

Well, it isn't just about the BSD bug they fixed.

I see this more as a case of ossification, which their abstract seems to confirm,
and this scheme would appear to get around it for little cost.

Mind that said, I can't really interpret what the stack graphs in the slides are
trying to show.

DF

---

From: Joe Touch <[email-masked]>
Date: Mon, 5 Nov 2018 08:09:13 -0800

> On Nov 5, 2018, at 8:02 AM, Derek Fawcus <[email-masked]> wrote:
> 

You are making bugs into ossification exactly when you require we accommodate them, rather than have them corrected.

It’s not like this error is arguably useful.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Mon, 5 Nov 2018 08:18:56 -0800

>         OCS is NOT intended as a check against bit errors

ACS has the exact same problem. If the option type is corrupted then
the ACS can be completely lost and corrupted data is accepted. These
are edge conditions that should be tested in an implementation.

---

From: Joe Touch <[email-masked]>
Date: Mon, 5 Nov 2018 08:21:08 -0800

I already addressed this issue. It would be rejected by a receiver that requires it, but the default is legacy behavior in which all options are silently ignored.

> On Nov 5, 2018, at 8:18 AM, Tom Herbert <[email-masked]> wrote:
>

---

From: Tom Herbert <[email-masked]>
Date: Mon, 5 Nov 2018 09:05:15 -0800

> I already addressed this issue. It would be rejected by a receiver that requires it, but the default is legacy behavior in which all options are silently ignored.
You are missing the point. Edge conditions need to be tested against
real protocol implementation. If the FreeBSD implementation is only
tested in an environment where there is no loss or no bad packets,
then little is learned. It is easy to make a protocol work, it is
difficult to make it work well.

---

From: Joe Touch <[email-masked]>
Date: Mon, 5 Nov 2018 09:07:00 -0800

I am not discounting the need for testing and for multiple implementations. However, it’s lazy to sit on the sidelines and demand that of others. 

Joe

> On Nov 5, 2018, at 9:05 AM, Tom Herbert <[email-masked]> wrote:
>

---

From: Derek Fawcus <[email-masked]>
Date: Mon, 5 Nov 2018 18:00:16 +0000

> Mind that said, I can't really interpret what the stack graphs in the slides are

OK.  Having looked again, is the following correct:

1) When sending UDP options some middleboxes drop packets in the absense
   of this new CCO option, due to mis-handling of UDP checksums.
2) For some combinations of test nodes and paths, that pass case was on
   order of 40% in the absense of CCO, and raised to around 80% with CCO.

and that the suggestion is that these are (largely) consumer grade boxes
which may never get bug fixes, and the best we can hope for is that when
they die, their replacements will have this fixed - but possibly not.

DF

---

From: Joe Touch <[email-masked]>
Date: Mon, 05 Nov 2018 10:40:30 -0800

> of this new CCO option, due to mis-handling of UDP checksums.

AFAICT, yes. 

> order of 40% in the absense of CCO, and raised to around 80% with CCO.

You'd have to check with Gorry and his team on that. 

> they die, their replacements will have this fixed - but possibly not.

The best we can ever do is point out the bugs to the manufacturer and
the community. I've encouraged their team to post the names of those
devices here, so that at least we can identify them for update and/or
replacement. 

We cannot, however, continue to design our protocols solely for bugs.
It's fine to extend our OCS to 16 bits (which was on the table anyway),
ensure its alignment (minor overhead) and add the UDP Length as
pseudoheader (one additional add) "just in case". 

It would be a mistake to require this option for all users as a default,
though. We need to allow for a future where bugs get fixed. For all UDP
options, as I noted earlier, the decision of what is required lies in
the hands of each individual receiver - exactly because *default
behavior should model legacy behavior*, which is to ignore all options
anyway. 

Joe

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 6 Nov 2018 02:51:30 +0700

See below.

Sent from my iPad

> On 6 Nov 2018, at 01:40, Joe Touch <[email-masked]> wrote:
> 
True, and some end hosts.
> You'd have to check with Gorry and his team on that.
Sounds about correct.
> The best we can ever do is point out the bugs to the manufacturer and the community. I've encouraged their team to post the names of those devices here, so that at least we can identify them for update and/or replacement.
>  
If UDP Options is in future widely used, I can believe there may be fixes in new equipment. However, I still don't see fixes that make DCCP work across the same types of boxes, even though there is an IETF Spec. --- It isn't existence of the Spec that drives changes to new equipment, it is use of the Spec.

> We cannot, however, continue to design our protocols solely for bugs. It's fine to extend our OCS to 16 bits (which was on the table anyway), ensure its alignment (minor overhead) and add the UDP Length as pseudoheader (one additional add) "just in case".
>  
> It would be a mistake to require this option for all users as a default, though. We need to allow for a future where bugs get fixed. For all UDP options, as I noted earlier, the decision of what is required lies in the hands of each individual receiver - exactly because *default behavior should model legacy behavior*, which is to ignore all options anyway.
> 
It would be a huge encouragement to think that the code that is being written actually will send packets across the Internet. I am rather less interested in developing a method that will in future work only when the Internet is "updated" to match the standards.

I really do think we need to think seriously about whether to put this field in every UDP Options datagram.  If the spec then requires us to use bytes to frame that as optional, we can surely do so - that is what we currently do. If the spec wishes to save bytes then that would be more efficient, but then there are indeed implications on ossifying this.  I think this is an engineering trade off. 

> Joe

Gorry

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 6 Nov 2018 03:16:31 +0000

> all UDP packets containing UDP options.

We see UDP Options datagrams being dropped for several reasons. 

The measurements we have vary for each target protocol, but there is
approximately 50% chance of a UDP Options datagram being unable to work
end to end on an internet path.

- [tj]