Re: [tsvwg] Rregarding soft-state and UDP options

[Joe Touch <[e-mail]>]

> On Jan 4, 2020, at 9:09 AM, Tom Herbert <[e-mail]> wrote:
> 
> On Fri, Jan 3, 2020 at 8:35 PM Joe Touch <[e-mail]> wrote:
>> 
>> Lost in this discussion has been an example to motivate the need for “drop if not supported”.
>> 
>> I’ve been asking for this for over a year and yet NO new existing transport examples have been cited.
>> 
>> The only hypotheticals proposed are content encryption and content compression. Encryption is already supported by the AE option. TCP has a content compression option code point. It was assigned in 1999 with an experimental draft (Bellovin’s) that never made it past -00 individual.
>> 
>> The existing architecture already supports both these examples (i.e., that modify content) using FRAG+LITE as follows:
>> 
>>        - each frag (even if only one) is decrypted/decompressed as processed
>>        - the frags are OCS-verified after reassembly (frag completion)
>>        - if decompression or decryption is silently ignored (i.e., if not supported), then the reassembly OCS would fail
>> 
> 
> Joe,
> 
> Section 11 of the draft describes the handling of the unrecognized
> options, specifically it says:
> 
> "The above requirements prevent using any option that cannot be
> safely ignored unless that capability has been negotiated with an
> endpoint in advance for a socket pair."
> 
> The referenced requirements are different than what you are describing
> here.

Yes. That and other issues will be addressed when the draft is revised. These include:

- clarifying the use of soft state (it is NOT the sole means for ensuring unknown options are used, but it remains useful for other optimizations).
- allowing a code point to create a separate table of options that don’t modify the FRAG+LITE data to cause that data to be dropped if not supported
- updating the design goals to explain they are motivated by the unsupported claim that they may be needed in the future and that no examples are given because none have been offered
- and not necessarily using that code point for AE because it the frag reassembly check has always protected against the modified variant (encryption) and it is the receiver’s discretion whether to ever enforce the unmodified variant (authentication) anyway

I.e., yes, once the changes are made, they do assume update *throughout the document* to address related issues.

I have agreed to these changes even though you and others continue to lack any example of the need for such a feature.

What point are you now arguing?

Joe