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

[Tom Herbert <[e-mail]>]

On Fri, Jul 12, 2019 at 8:49 AM Black, David <[e-mail]> wrote:
>
> Tom,
>
> Inline ...
>
> Reminder: All of my comments in this thread are as an individual, not as a WG chair.
>
> Thanks, --David
>
> > -----Original Message-----
> > From: Tom Herbert <[e-mail]>
> > Sent: Friday, July 12, 2019 11:26 AM
> > To: Black, David
> > Cc: Joe Touch; Tom Herbert; tsvwg
> > Subject: Re: [tsvwg] draft-ietf-udp-options issues from IETF 104
> >
> >
> > [EXTERNAL EMAIL]
> >
> > 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"
>
> [David>] With the exception of LITE, I agree.
>
> [David>]I think LITE deserves more thought/discussion, as a user of LITE has already agreed to tolerate things that the network is not supposed to do to non-LITE traffic, and that tolerance may extend further.

The user may see "random" packet loss which could be a bear to debug.
I'm not sure we're doing them a favor by making checksums optional.

> >
> > Given that IPv6 requires the UDP checksum, the surplus space checksum
> > needs to be present in all IPv6 packets.
>
> [David>] That IPv6 requirement statement is incorrect, even though it's "digging in the right place" (IMHO) - see RFC 6935 and RFC 6936.

Yes, that's correct. However, I think you'll agree that the
requirements of RFC6935 and RFC6936 are very narrow and only apply to
UDP tunneling protocols that explicitly meet the requirements (which
AFAIK are only MPLS/UDP, GRE/UDP, an GUE). UDP options proposal
doesn't generally meet the requirements of RFC6936 for using UDPv6
zero checksum.

>
> > 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.
>
> [David>] I acknowledge that view, and for now I will agree to disagree, as I currently see a clear case for "SHOULD use OCS" but not for "MUST use OCS" ... and reserve the right to change my mind as more information is added to the discussion.
> >
> > 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.
> > >
> > > --
> > >
> > >
> > >
> > >