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

[Joe Touch <[e-mail]>]

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

We’re not designing a Byzantine robust protocol here. 

Joe