Re: [tsvwg] Comments on ietf-106-tsvwg-udp-options

[Joe Touch <[e-mail]>]

Thanks for the feedback, Mike. 

Regarding the MUST SUPPORT flag part:

> On Dec 29, 2019, at 4:28 PM, C. M. Heard <[e-mail]> wrote:
> ...
> I'll comment when the updated text appears.
>  
> - regarding MUST SUPPORT flag
> 
> The only need for this flag has been data that must not be received by
> legacy endpoints, e.g., compressed. That's already achievable more
> flexibly using the FRAG+LITE with pre and post reassembly options. Can
> anyone show a case this doesn't cover?
> 
> I disagree with this characterization, both of the proposed change and
> the purpose that it serves. 

I made two claims:
1. the need is for data that shares fate with the option on legacy endpoints (is ignored)
2. the need is already addressed by pre and (notably) post-reassembly options in FRAG+LITE
	I was assuming FRAG that supports the degenerate case of a single fragment.

> During the e-mail discussion in the weeks prior to IETF 105, I proposed
> an additional design requirement to supplement those set forth in
> https://mailarchive.ietf.org/arch/msg/tsvwg/27I9XF-mEdXagcEPah22482v65c <https://mailarchive.ietf.org/arch/msg/tsvwg/27I9XF-mEdXagcEPah22482v65c>
> (and also in the IETF 105 presentation slides).* It was:
> 
> - Any option that affects the handling of the user data must share fate
> with that user data,…

As noted above, already supported by FRAG+LITE.

> in the following sense: either the option and the
> user data are processed together, with the data and option indication
> being delivered to the user if the processing succeeds, or else both are
> discarded, and nothing is delivered to the user. This requirement
> applies to all receivers, legacy or otherwise.

That’s accomplished by post-reassembly options.

> I do not believe that the spec, either in previous incarnations or in
> its current (-08) form, provides a way to satisfy this requirement. In
> order to fill that (perceived) gap, I proposed that (a) there shall be
> a means to transport user data in the options area with OCS coverage;

As noted in the update, OCS covers the entire option area now (which thus includes FRAG+LITE).

> (b) user data shall be transported using that mechanism whenever it is
> accompanied by an option that affects how it is processed;

The user makes this decision by selecting to use an option “post reassembly”.

> and (c)
> the Option Kind space shall be subdivided into two ranges, one for
> options that do not affect the handling of user data and another for
> options that do affect the handling of user data.

That’s a mechanism - one that is not needed to achieve the other goals.

> Note that (a) and (b) are needed to ensure that user data accompanied by
> an option that affects its processing is not delivered to a legacy
> receiver (which ignores all options) or to an option-aware receiver
> when OCS fails (for in that case, the option-aware receiver also
> ignores the options).

a) and b) are already supported.

> One way to accomplish (a) would be the version of FRAG proposed in
> https://mailarchive.ietf.org/arch/msg/tsvwg/Wv--BLVMPAX6g5umok9BQsXAEGg <https://mailarchive.ietf.org/arch/msg/tsvwg/Wv--BLVMPAX6g5umok9BQsXAEGg>
> (other alternatives have also been discussed). I'll defer further
> discussion of the details until after I see the new LITE+FRAG option.
> 
> Note that (c) is needed to ensure that user data accompanied by
> an option that affect its processing is not delivered to an option-aware
> receiver that does not recognize the option.

We have already described how this should be achieved using soft-state negotiation between the endpoints.

> As an example, AE
> (Authentication and Encryption), as defined in the current spec, affects
> the processing of the user data, but an implementation is not required
>  to support it. More generally, if an option that affects data
> handling (such as compression) is defined in the future, option-aware
> receivers that implement the current spec won't recognize it. They need
> a means to determine whether it's safe to ignore the option and deliver
> the user data or whether to discard both the data and the option.

They should be doing so using soft state coordination and the combination of pre and post reassembly options.

E.g., encrypt the parts and have a post-reassembly checksum (again, even on a degenerate single fragment). The checksum would be post-decryption and validate the result.

Simply putting in a ‘drop if not supported’ flag wouldn’t address a receiver that implements decompression incorrectly. If an option could modify the data, it’s more than sufficient to check the data after it the option is processed.

Joe

> One way to accomplish (c) would be to reserve a bit in the Option Kind
> for that purpose. The latter is what I assume is meant by a "must
> support" FLAG. I think that's a misleading name; IMO would be more
> accurate to call it a "safe to ignore" flag. I believe that the
> above discussion establishes an essential use for this flag.
> 
> Mike Heard
> 
> *The requirements were:
> 1- support options
> 2- allow at least some options to be silently ignored by legacy receivers (to enable ‘“optionally enhanced” exchanges)
> 3- allow at least some options to be required
> 4- allow the options themselves to be protected
> 5- support for fragmentation/reassembly
> 6- support for MTU discovery
> 7- support (optional) middlebox checksum/payload length bug traversal
> 8- support LITE, i.e., where some of the payload is not covered by at least some checksum processing
> 
> With the probable exception of #8, I believe that these are still current.
>