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

[Tom Herbert <[e-mail]>]

On Fri, Jul 12, 2019 at 7:10 AM Black, David <[e-mail]> wrote:
>
> 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.

David,

The integrity provided by the checksum is only part of the story. An
important observation is that many devices will include the surplus
space in their calculation of the UDP checksum. Unless the surplus
space sums to zero, an incorrect UDP checksum may be derived and the
result is a high probability that packets will be dropped somewhere in
the network. The other important use is disambiguation with legacy
uses of the surplus space.

So the first requirement is simple:

"If the UDP checksum is used (non-zero) then a checksum MUST be used
in the surplus space such that the surplus space sums to zero"

Given that IPv6 requires the UDP checksum, the surplus space checksum
needs to be present in all IPv6 packets. For cases in IPv4 where the
UDP checksum is zero, I think use of the surplus space checksum is
still a MUST. A common misnomer is that optional UDP checksums is
somehow a benefit to hosts since it allows them to omit the checksum
calculation. It's not. We've already accounted for presence required
checksums in TCP and UDPv6. For instance, RFC6936 only benefited
routers not hosts; the effect of supporting RFC6936 in hosts has been
more complexity, more test cases, and more bugs to fix. Making surplus
space checksum optional is more work for little gain.

Tom

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