Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-options-06

[Joe Touch <[e-mail]>]

Hi, Gorry,

Designing for deployability to me involves adapting to MAYs and
exceptions to SHOULDs - i.e., legitimate deployment options.

Designing to overcome bugs or deliberate deviations from specs is a
losing battle. It helps endorse and entrench bad behavior and undermines
the very nature of specs.

If that's where we are, let's all save each other's time and call it the
"wild west".

In this specific case, there's a cost to requiring OCS - additional
effort exactly where it users decide it isn't needed (e.g., when UDP
CS=0 or the entire packet is covered by another layer, such as protected
tunneled transit) or where they decide the IP sum isn't enough (e.g,
when using ACS).

The default can be to include it, but IMO that's as much as we should do
here.

Joe

On 3/7/2019 11:09 PM, Gorry Fairhurst wrote:
> On 08/03/2019, 03:47, Joe Touch wrote:
>> Hi, Derek,
>>
>>> On Mar 7, 2019, at 1:23 PM, Derek Fawcus
>>> <[e-mail]
>>> <mailto:[e-mail]>> wrote:
>>>
>>> I believe the result of the CCO experiment was that it, or this new
>>> OCS,
>>> would always have to be present in order to guarentee a packet passes
>>> through certain middleboxes.  Except possibly th the case where the
>>> UDP header checksum is zero?
>>>
>>> Given that wouldn't it make sense for this option to be both
>>> mandatory to
>>> implement, and always present in the options area?
>>>
>>> DF
>>
>> You’ve already partly answered your own question.
>>
>> The other case is ACS, in which case (currently) there would be no
>> OCS. It would be somewhat wasteful in both space and computation to
>> include both, unless passing such middle boxes is needed.
>>
>> Note - traversal of incorrectly implemented middle boxes is not a
>> primary design consideration for UDP options. We are absolutely not
>> designing a “byzantine” protocol, i.e., one that survives arbitrary
>> attacks by intermediate boxes, whether deliberate or accidental.
>>
>> Joe
>>
> To be clear: This is not just a middlebox, NAT, etc consideration,
> there are also hosts that offload UDP option checks, that can
> black-hole the UDP Options that do not have the "CCO" like OCS value.
>
> As an individual in the IETF (rather than the WG Chair), I think your
> note is a fair point for more discussion about whether we should
> design for deployability. It seems that a large number of people in
> the QUIC WG are specifically designing their new transport to optimise
> the chance of working through network paths that have middleboxes. At
> least with respect to IPv4, I could see merit in requiring the OCS in
> the options area.
>
> Gorry
>
>