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

[Tom Herbert <[e-mail]>]

On Wed, Jul 10, 2019 at 3:49 PM Joe Touch <[e-mail]> wrote:
>
> Re-sending the full response this time:
>
> On 2019-07-10 15:17, Tom Herbert wrote:
>
> On Wed, Jul 10, 2019 at 12:24 PM Joe Touch <[e-mail]> wrote:
>
>
> On 2019-07-10 11:36, Tom Herbert wrote:
>
>
> ...
> The UDP surplus header provides alignment,
>
>
> UDP options already has NOPs for that.
>
> The NOPs align the options to the start of surplus. If the surplus
> space is unaligned to begin with then there's no point to using NOPs
> to align individual options.
>
>
> That's already supported in the UDP options. They can start with NOPs too.
>
>
>
>
>
> integrity check,
>
>
> UDP options already has a OCS for that.
>
>
> A one byte optional checksum is next to useless as an integrity check.
> This has already been brought up in reference to OCS.
>
>
> It was changed to 2 bytes before the last IETF, between v5 and v6 (we're on v7; the doc table does need to be updated, but the text is accurate and no longer talks about folding it over).
>
>
>
>
>
> disambiguation for other uses of surplus space,
>
>
> This isn't needed. It won't support existing uses (not that any are known) because they won't follow the format.  UDP options already allows for experimental uses and other standards-track extensions through codepoint assignment.
>
>
> If the checksum fails then surplus space isn't processed. So,
> probability of misinterpretation of some random use of surplus space
> is < 0.0015%.
>
>
>
> See above.
>
>
>
>
>
> a means to extend the UDP header,
>
>
> Actually, it hinders UDP options by limiting them to 1020 bytes, as with all "other uses".
>
> That is intentional. Allowing unlimited options is a path towards DOS attack.
>
>
> There are only 256 codepoints; options you don't support you skip over. And only NOPs can be repeated and only up to 3x in a row.
>
> And if you see enough of these with options you don't know or care about, maybe you should throttle.
>
> One thing we do know is that any fixed size limit WILL be insufficient.
>
>
>
>
> friendliness with HW and SW implentations,
>
>
> It has no benefit vs. the existing approach in this regard.
>
> The checksum ensures that the surplus space sums to zero...
>
>
> We've already been over this and the updated text already does EXACTLY the same thing, except that it doesn't need alignment to work.
>
>
>
> ... Along similar lines, a per packet checksum is
> much better than the fragmentation checksum since we can offload the
> former and not the latter.
>
>
>
> That remains one of the items that we're waiting for others to comment on, ones we're NOT discussing because we're still wasting time on this.
>
> ---
>
> 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)

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
2) The checksum option is at least three bytes, or four bytes if
alignment is required. A fixed checksum only consumes two bytes.
3) A fixed checksum disambiguates uses standard uses from legacy uses
of the surplus space. An optional checksum doesn't help with that.

> Joe
>
>