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

["C. M. Heard" <[e-mail]>]

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

> - 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-kEytK0 for
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

> - 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). Remember, in IPV6 the IP Payload Length is NOT protected by an
IP header checksum or by the pseudo-header in the UDP checksum, so the ONLY
protection against corruption of the computed trailer length is the OCS.

> - 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?

Mike




>
>