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

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

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

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