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

[Tom Herbert <[e-mail]>]

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

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

>
> Joe