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

[Gorry Fairhurst <[e-mail]>]

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