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

From: "C. M. Heard" <[email-masked]>
Date: Sun, 29 Dec 2019 16:28:41 -0800

Slide 3 of 4 of the IETF 106 UDP Options presentation, entitled "Issues
posted Sep 2019" covered the items below; see comments in-line.

On Thu, Sep 12, 2019 at 9:30 PM Joe Touch wrote:

> Hi, all,
>
> A summary of some other issues:
>
> - regarding PADN
>
> I have not been able to identify a need for this vs. use of EOL and
> zero-fill for the remainder of the surplus area. If anyone can show a
> need for this *in a transport protocol*, please indicate.
>

If my understanding is correct, the primary motivation for the proposal to
include both PAD1 and PADN was to have UDP options use the same format
as IPv6 options. As the IETF 105 presentation notes, it's easy to add
PADN, but it's impossible to match both TCP ***and*** IPv6 codepoints.
I personally am comfortable with a decision to align with TCP (and IPv4)
codepoints, i.e., to retain the present PAD and EOL definitions.

- regarding LITE, FRAG, LITE+FRAG
> (working on text now)

Slide 4 of 4 states:
  – LITE+FRAG to be supported
  – LITE alone to be removed
  – FRAG alone to be removed

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.

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
(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, 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.

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;
(b) user data shall be transported using that mechanism whenever it is
accompanied by an option that affects how it is processed; 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.

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).

One way to accomplish (a) would be the version of FRAG proposed in
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. 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.

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.

---

From: Joe Touch <[email-masked]>
Date: Tue, 31 Dec 2019 07:08:58 -0800

Thanks for the feedback, Mike. 

Regarding the MUST SUPPORT flag part:

> On Dec 29, 2019, at 4:28 PM, C. M. Heard <[email-masked]> wrote:
> ...

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.

> https://mailarchive.ietf.org/arch/msg/tsvwg/27I9XF-mEdXagcEPah22482v65c <https://mailarchive.ietf.org/arch/msg/tsvwg/27I9XF-mEdXagcEPah22482v65c>
> with that user data,…

As noted above, already supported by FRAG+LITE.

> in the following sense: either the option and the

That’s accomplished by post-reassembly options.

> 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).

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

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

> when OCS fails (for in that case, the option-aware receiver also

a) and b) are already supported.

> https://mailarchive.ietf.org/arch/msg/tsvwg/Wv--BLVMPAX6g5umok9BQsXAEGg <https://mailarchive.ietf.org/arch/msg/tsvwg/Wv--BLVMPAX6g5umok9BQsXAEGg>
> 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

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

> 2- allow at least some options to be silently ignored by legacy receivers (to enable ‘“optionally enhanced” exchanges)
> 8- support LITE, i.e., where some of the payload is not covered by at least some checksum processing
>