Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-13.txt

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

On Wed, Jul 7, 2021 at 10:25 PM Joseph Touch wrote:

> Hi, Mike,
>
> On Jun 26, 2021, at 10:13 PM, C. M. Heard wrote:
>
> On Sat, Jun 19, 2021 at 12:39 AM Joseph Touch wrote:
>
>> Here’s a summary - I tried to catch both everything Mike provided
>> feedback on as well as what I have proposed as a way forward.
>>
>
> This is much appreciated, thank you. My item-by-item responses follow.
>
>


>
>>    - OCS
>>       - Uses the standard 2-byte prefix (all but NOP and EOL do)
>>       - Added discussion of RFC 6935 regarding exception to requiring
>>       the UDP checksum and thus OCS
>>       - Allow OCS’s checksum to be precomputed, but still check in the
>>       order options occur
>>       - Occurs over the entire surplus area (doesn’t stop at EOL)
>>
>> OK on most points, but I strongly object to the following when OCS is
> mandatory (as is the case when UDP CS <> 0):
>
>    Note that a receiver can compute the OCS checksum before processing
>    any UDP options, but that computation would assume OCS is used and
>    would not be verified until the OCS option is interpreted.
>
>
> If I perform the computation before processing any options, and OCS is
> mandatory, it would be foolish of me to waste any more effort seeking the
> OCS option in the TLV chain. I already know that the option area is
> invalid,
>
>
> How exactly do you know this? If OCS is mandatory, you need to find it
> (seek it in the TLV chain) in order to know whether the value you compute
> differs from the value in the option.
>

This last statement is not true, and I think it's important to clarify that
fact.

If OCS is mandatory (because UDP CS<>0), then I can determine whether the
options area has an INVALID checksum by computing the 16-bit Internet
checksum over the options area conceptually prepended by a 2-byte options
area pseudo-header containing the options area length. If the result is not
a 1s complement zero, then I KNOW that the option checksum is not valid.
Full stop. Whether that is because the OCS TLV is absent or because it is
present and has the wrong value makes no difference; the option checksum is
not valid, and I do not need to parse a single TLV to determine that. I can
immediately stop option processing and discard the contents of the option
area.

Performing the computation early just allows offloading if desired; the
> value computed still needs to be checked.
>

If UDP CS <> 0 and the result of the above computation is a 1s complement
zero, then strictly speaking I need to look for OCS when I am looping
through the option TLVs: it is possible that there the options area by
chance happens to have a zero checksum even though no OCS TLV is present.
That is on the same level of probability as an undetected checksum error.
Little would be lost by not checking for a required-but-not-present OCS TLV
when the option checksum calculation yields zero. If you insist, I will
make that check; but please don't tell me that I need to check the option
area at all once I know, for sure, that the option checksum is invalid.

If UCP CS=0, and the connection has been configured to accept such packets
(default for IPv4, non-default for IPv6), and has also  not been configured
to require OCS (default by the current spec), then I do have to parse the
option area whether or not the option checksum calculation described above
returns  a 1s complement zero. Whether this is wise from a safety
perspective is debatable, but having been instructed by the user to do so,
I will do as I am told. (I do have to say that I'm not convinced that the
use cases where UDP CS=0 is acceptable (e.g., tunnels) will have much use
for UDP options, especially in the legacy trailer format, but that's a
debate for another thread).

Mike Heard