Re: [tsvwg] New Version Notification for draft-herbert-udp-space-hdr-01.txt

[Tom Herbert <[e-mail]>]

On Wed, Jul 10, 2019, 5:21 PM Joe Touch <[e-mail]> wrote:

>
>
> > On Jul 10, 2019, at 5:07 PM, Tom Herbert <[e-mail]> wrote:
> >
> >> On Wed, Jul 10, 2019 at 4:45 PM Joe Touch <[e-mail]> wrote:
> >>
> >>
> >>
> >>
> >>
> >> On 2019-07-10 16:24, Tom Herbert wrote:
> >>
> >> On Wed, Jul 10, 2019 at 3:49 PM Joe Touch <[e-mail]> wrote:
> >>
> >> ...
> >>
> >> In summary, please look at the current draft and note that OCS is now 3
> bytes. That is incorrect in the table (we already noted that on the list;
> it's in the next round of opdates) but not in the text of the OCS section.
> >>
> >> Actually, there are two places that say it is a one byte checksum:
> >>
> >> +--------+--------+
> >> | Kind=2 |checksum|
> >> +--------+--------+
> >>
> >> 2*      2         Option checksum (OCS)
> >>
> >>
> >> The first one doesn't "say" anything per se, but yes, it could be
> extended to make it more clear. As I noted, this was mentioned already on
> the list and is on the pending items.
> >>
> >>
> >> Assuming that this is supposed to be a two byte checksum:
> >>
> >> 1) An optional checksum cannot protect against corruption of the type
> >> field containing the option. I've have mentioned this several times
> >> and there has never be a reasonable response as to why this isn't a
> >> problem
> >>
> >>
> >>
> >> It's a choice, just as whether to use checksums in IPv4 UDP. It's the
> user's choice and it saves bytes when not desired. The default is to use
> it, though.
> >
> > The checksum field in UDP is *not* optional, it is in every UDP
> > header.
>
> This isn’t a new header. We’ve already covered that.
>
> > Use of the checksum is optional only by the sender setting the
> > field to zero in IPv4, it is not optional in IPv6. The risk of
> > undetected corruption, other than the unfortunate situation where
> > mutliple bit corruptions occur that cancel out each other in the one's
> > complement sum, is if a non-zero checksum gets flipped to be zero then
> > then will be accepted by an IPv4 stack (not IPv6). Contrast this to
> > the situation where the type field of checksum option gets corrupted.
> > A receiver will no longer see the checksum. Barring some other
> > mechanism to detect a corrupted checksum, a corrupted packet is
> > accepted.
>
> Receivers who care can require the checksum.
>
> >
> >>
> >>
> >>
> >> 2) The checksum option is at least three bytes, or four bytes if
> >> alignment is required. A fixed checksum only consumes two bytes.
> >>
> >>
> >>
> >> Yes, and we've been around that block before too. A fixed checksum
> could take 2-4 bytes too - due to the same alignment issues. So we're
> talking about 1 byte and the design is based on the principle that ALL
> options are optional in UDP - there is no "default" header.
> >>
> >>
> >>
> >> 3) A fixed checksum disambiguates uses standard uses from legacy uses
> >> of the surplus space. An optional checksum doesn't help with that.
> >>
> >>
> >>
> >> Yes, it does. Optionally. However, note that we still have exactly ZERO
> legacy uses discovered. And if - or when - we get comfortable with that, it
> can be optionally omitted.
> >
> > No it doesn't. I suggest you send your implementation of UDP options a
> > bunch of random bytes in surplus space and see what happens. As far as
> > the fact that zero legacy uses have been discovered, that does not
> > mean that in the forty year history of UDP that no one else though out
> > using the surplus. The space was NEVER reserved, so if anyone is using
> > the space then we can't break them. The checksum is a reasonable
> > defense against that.
>
> And you can require it if this keeps you up at night. The rest of us don’t
> need to be stuck with it forever.
>

Yes, that's why checksum is in the fixed header. The benefits far outweigh
the cost.


> We’re not designing a Byzantine robust protocol here.
>
> Joe
>
>