Re: [tsvwg] A review of draft-ietf-tsvwg-udp-options-12

["C. M. Heard" <[e-mail]>]

On Mon, Jun 14, 2021 at 11:44 AM Tom Herbert wrote:

> If it's required and it's first then it's no longer an option, it's
> just a two-byte field in a header that precedes the option list. This
> is much better for efficient processing.
>

That idea will work, but if it is adopted, I would like to make sure that
the following points are covered:

1.) Many of us want it to be possible to include "safe" UDP options in a
trailer for compatibility with legacy receivers who don't support UDP
options.

2.) OCS needs to be present in that case too, and it must cover the entire
trailer, in order to ensure middlebox traversal (as discovered by Tom
Jones).

Thus, if there is a UDP options header that contains OCS, it would need to
be at the front end of the options trailer. If that header included a total
options length, EOL would no longer serve a useful purpose. Everything from
the first byte pointed to by the option length to the end of the packet
would be padding, required to be set to zeroes (but not required to be
checked), and would be covered by the OCS.

Honestly, though, I fail to see a compelling advantage in having a UDP
options header, since an implementation of UDP options is required to loop
through all options in the packet. To paraphrase RFC 791, what is optional
is not the requirement to inspect options when present, but the requirement
that they be in any particular packet. Given that, I don't see how an
options header would be better for fragmentation offload than what I
proposed in
https://mailarchive.ietf.org/arch/msg/tsvwg/N1fmoBxQ5iOL5X7o34oVSA8Ayvw/.

On Mon, Jun 14, 2021 at 11:52 AM Joseph Touch <[e-mail]> wrote:

> It isn’t required. It’s required to be first *if present*. It’s still
> optional if the UDP checksum is zero.
>

For the record, it actually does not matter where OCS is placed when it is
required to be present (UDP CS<>0), for it is possible to check OCS without
ever parsing the options at all: just calculate the Internet checksum over
the trailer (using the appropriate pseudo-header, of course). That
comprehensively covers the case where UDP CS<>0, which IMO is the important
one, as CS<>0 is required by operational considerations in most situations.

For sockets where UDP CS=0 is allowed, OCS is optional unless the receiver
is configured otherwise. In that case it is indeed advantageous to require
that OCS be first (preceded only by a handful of NOPs) if it is present.
It's not hard to implement optional OCS with UDP CS=0, but IMO parsing a
list of TLVs without first doing an integrity check is a very risky
business, and I question whether it adds any value. (But I won't squawk if
it stays.)

Mike Heard