Re: [tsvwg] draft-ietf-udp-options issues from IETF 104

["Black, David" <[e-mail]>]

Joe,

> So no matter what you do, they're still easily optional unless we decide to FORCE the user to do otherwise. Why exactly would that be the case?

I think I’m over on the “FORCE” side of that dichotomy (i.e., I don’t agree with “easily optional”), although we can split hairs on what degree of “FORCE” is appropriate.   My underlying reasons are these two:
                1) strong "running code" evidence of what breaks when the OCS is omitted,
                2) helps defend against … possibility [of] … other uses of surplus space

IMHO, OCS being the “default” is a good starting point, but … my current view is that on its own, item 1) justifies “MUST implement/SHOULD use” language for OCS (and “SHOULD use” is complementary to and stronger than “default”) and setting the space aside for OCS, at least when LITE is not present.  That view is reinforced by item 2), and I note neither of those two items are within the control of the endpoint implementer or application that uses the endpoint’s UDP option support.

> I think you contradict this below, here:
>
> One exception to OCS being mandatory that makes sense to me is that OCS doesn't seem to make a lot of sense with LITE,

Point taken – my response is “not exactly” … but I clearly need to explain my thinking in more detail :-).  IMHO, LITE is “special” …

My rationale for OCS not making a lot of sense with LITE is that use of LITE is a clear indication from the sending application that correctness of the LITE data on receipt is optional.  Beyond that, I believe you’ve pointed out that zeroing the UDP checksum is a related scenario where correctness of all of the UDP data may be optional – that scenario is more subtle, because one of the rationales for zeroing the UDP checksum is presence of another integrity mechanism elsewhere in the protocol stack that covers the data (although protocol designers need to watch out for uncovered IPv6 headers – see RFC 6935 and RFC 6936).  In both cases, if the scenario is one in which “correctness of .. data is optional,” then IMHO (as an individual) correctness of UDP options also has to be optional, and we (WG) need to carefully consider which options are ok vs. ought not to be used when correctness of them on receipt doesn’t matter.

Thanks, --David

From: Joe Touch <[e-mail]>
Sent: Thursday, July 11, 2019 4:45 PM
To: Black, David
Cc: Tom Herbert; tsvwg
Subject: Re: [tsvwg] draft-ietf-udp-options issues from IETF 104


[EXTERNAL EMAIL]

Notes embedded below...


So far, I'm beginning to see that this argument boils down to 1 byte. If that's all it is, then fine - let's add OCS as a fixed field at the head, possibly after NOPs.

NOTE: OCS would still probably need to have a way to be disabled, ala UDPv4 checksums, by setting to zero.

So no matter what you do, they're still easily optional unless we decide to FORCE the user to do otherwise. Why exactly would that be the case?

Joe

On 2019-07-11 13:01, Black, David wrote:
Commenting as an individual, **not** as a WG chair.

-- Option Checksum (OCS)

The IETF 104 tsvwg minutes match my impression that the topic of whether the offsetting option checksum (OCS) should be optional vs. mandatory remains an open issue for UDP options.

Tom has kept this issue open for over a year; there hasn't exactly been a groundswell behind the issue. I also note that you seem to argue yourself out of your own support below, FWIW.

For my part, I've seen strong "running code" evidence of what breaks when the OCS is omitted,

In SOME Internet paths. The issue is whether we need to require this even when we might not need it in the future.

But note that the same thing is largely true for UDP checksums - they find real errors, yet some people choose to turn them off (esp. for IPv4). So even if we kept OCS as a required field, we would still need a way to turn them off in a corresponding way (e.g., set to zero).

in contrast to almost no evidence of things broken by the presence of OCS (computed to offset the UDP checksum calculation when that is done over IP length instead of UDP length).

I think you contradict this below, here:

...
One exception to OCS being mandatory that makes sense to me is that OCS doesn't seem to make a lot of sense with LITE, as the OCS would cover all the LITE payload data, thereby defeating the LITE goal of not having to checksum data whose reliability is not of interest.   One consequence is that UDP Options become unreliable when LITE is used, which may have implications for which UDP options are acceptable to use with LITE.  An important tradeoff is that LITE won't work on network paths that pass  UDP Options only when OCS is present.

There are some other possibilities, such as including an OCS on transmit but not checking it on each fragment received. That would trick middleboxes as needed but avoid duplicate work at the receiver (which is where load tends to be bigger anyway).

This is both why the current doc indicates OCS as both optional and default enabled. In the future, if/when it isn't needed, we can remove it that way - as well as disabling it if needed/possible for LITE.

-- Other uses of surplus space

Any hypothetical existing use of surplus space is incompatible with both UDP options and a new surplus header.  While I haven't seen evidence of any such existing use "running code," making the OCS mandatory helps defend against that possibility, as well as against bad endpoint implementations that put whatever junk bytes happen to be lying around in memory into that extra space, improving UDP Options robustness.

*Using* OCS accomplishes this - and remember, it's default to being used.

Making OCS mandatory is a decision - why do you think that's critical for us to make for all future users?

And regarding the last point, if you really care, users are always welcome to just leave OCS on as defaulted anyway.

--