Re: [tsvwg] draft-ietf-udp-options issues from IETF 104

[Joe Touch <[e-mail]>]

Hi, Mike,

On 2019-07-16 07:37, C. M. Heard wrote:

> Responding to some points below ... 
> 
> On Mon, Jul 15, 2019 at 1:34 PM Joe Touch <[e-mail]> wrote: 
> 
>> Where we currently are on OCS: 
>> 
>> - 16-bit, as per current UDP-options draft TEXT (figs and tables need to be updated)
> 
> OK 
> 
>> - zeroes-out with the checksummed data, to enable transit of widespread implementation bugs in middleboxes
> 
> Actually it needs to include the surplus length as a pseudo-header per https://tools.ietf.org/html/draft-fairhurst-udp-options-cco

Yes - I think that was cached in my to-do list. 

>> - the OCS field is now manditory (not signalled with a KIND field or optional as a field)
> 
> As mentioned in https://mailarchive.ietf.org/arch/msg/tsvwg/XZxL29UA-95ReA72mxv5-kEytK0for use in the trailer I'd prefer leaving it as an option so that NOPs can be prepended for alignment, at the discretion of the sender

Yes, that's the trade-off. If it's mandatory, we need to decide its
alignment (none, 16-bit, 32-bit) ahead of time for all time. AND it has
to be there even if it's not used. 

If we use the 1-byte flag, the alignment can be at the user's discretion
and we save space when not in use. 

>> - OCS *SHOULD be computed, but MAY be set to zero (e.g., when UDP CS=0, at user discretion and peril)
> 
> Partly agree. I do not want to see any receiver obligated to accept packets with UDP trailers that don't have a computed OCS if UDP CS<>0 (it's fine to allow a mode that does otherwise as long as it's an optional-to-implement capability).

Optional to implement seems odd; it seems fine to say the receiver can
treat ignore the surplus area in that case (i.e., act like a legacy
receiver). 

> Remember, in IPV6 the IP Payload Length is NOT protected by an IP header checksum or by the pseudo-header in the UDP checksum,

Good point - that needs to be noted. 

> so the ONLY protection against corruption of the computed trailer length is the OCS.

Again, this is certainly a risk, but why isn't it just a choice? When
UDP picks CS=0, they're saying they are willing to take that risk. 

>> - with LITE, OCS might be transmit-side computed and receive-side ignored to allow for the intended NON-ROBUST capability (at least when NOT transiting buggy middbleboxes; see below) of LITE 
>> 
>> (if LITE data doesn't change, that will transit middleboxes; if the LITE data does change, there's no way to help it transit middleboxes anyway)
> 
> As a point of clarification: this means that OCS would include the LITE data (which it does NOT do now) and the options; OCS would not be checked on receive; is that correct?

That is what I'm thinking, but there are certainly variants of what
might or might not be covered. 

I.e., we could do things a few different ways: 
- in the current draft text OCS is "all or none" for the CS area, where
LITE is "not covered" because it's jumped over completely 
- if we want protection for PART of the surplus area, we would need two
different CS. That argues for going back to Gorry's CCO proposal. 

--- 

As a note, I think we're diverging from our intended goals. Those might
be useful to include in udp-opts. My recollection was: 

- support a version of what LITE does, if possible 
- support frag/reassy 
- support single-packet (each way) exchanges with legacy receivers
(notably for the DNSSEC case, e.g., send a request with a null option to
allow enabled receivers to respond directly either in legacy mode or
option-enabled-mode) 
- support transport-level security (akin to TCP-AO) 
- support PLPMTUD (via the echo exchange) 

Many of these simply won't work as automatically legacy-compatible with
draft-herbert; the legacy data can easily exceed its limits, at a
minimum. 

Joe