Re: [tsvwg] Review of draft-ietf-tsvwg-udp-options-32

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

On Fri, Apr 5, 2024 at 9:49 AM Martin Duke wrote:

> On Thu, Apr 4, 2024 at 2:22 PM C. M. Heard wrote:
>
>> (11.4) What if Frag. Start is inconsistent with the location of EOL?
>>>
>>
>> Do you mean when Frag. Start points past the end of the packet? It was
>> clear enough to me that this would be considered malformed and discarded,
>> but maybe that's just me being too familiar with the intent, and not
>> actually scrutinizing the text.
>>
>
> "End of the packet" is a pretty ambiguous phrasing at this point :-). What
> I mean is, what if the datagram contains zero payload, a FRAG option, a
> series of other options, EOL, some random bytes, and then the frag start?
> Is that legal? I gathered that the intent would be that Frag Start was
> immediately after EOL, but then there are alignment issues, etc. What's
> legal and what's malformed?
>


Sorry, I misunderstood. I see that the language in Section 11.1 (which
defines EOL) should have some wordsmithing to change the words "the surplus
area" to something like "the surplus area or the options area in a UDP
fragment". With that change, there should be no problem with EOL at an
offset before Frag. Start. It just means that the bytes after EOL and
before the byte pointed to by Frag. Start are ignored (cf. how EOL works in
IPv4 and TCP options). And those bytes should not be random, they should be
zero (though the implementation has no obligation to check that).

This is a good example why it's good to get people who have not read the
spec to have a look. Those of us who have been around it for a long time
have a tendency to see what we are sure it means instead of what it
actually says 😑


(11.4) "the OCS value of the original packet SHOULD be zero if each
>>> fragment will have a non-zero OCS value"
>>>
>>> I don't understand the purpose of this. First, it complicates packet
>>> processing because the full datagram has to use a different OCS
>>> verification path if it's reassembled. Second, if the fragment OCSes are
>>> sufficient, why not simply say that the original packet MUST NOT have an
>>> OCS option?
>>>
>>
>> Actually, the idea was that reassembly could be implemented as a "bump in
>> the stack" and that the handling of reassembled datagrams would not vary
>> much from how it's done for datagrams that are not received as fragments.
>> IPv4 (and under certain circumstances IPv6) allow zero UDP checksum. The
>> OCS is mandatory when UDP checksum is non-zero and recommended (but not
>> required) when the UDP checksum is non-zero. So an implementation already
>> has to deal with datagrams that have UDP CS == 0 but OCS != 0. Given that,
>> it seems (to me at least) fair to keep this as a SHOULD, as it does not
>> require any mechanisms that are not otherwise required.
>>
>
> I'm concerned about the opposite: if UDP CS != 0, then the normal
> processing path is to expect OCS != 0, but the recommendation in (11.4)
> means that OCS will be zero! So there's a special path if the packet is
> reassembled. Am I mixing this up?
>


There is no different path for reassembled packets as compared with those
that are transmitted without UDP fragmentation.

I think the confusion arises because there is no provision to transmit a
separate UDP checksum covering the UDP header and UDP payload of the
original packet (where "original" means prior to fragmentation or after
reassembly). So the recommendation in Section 11.4 is to set that field to
zero. What emerges from a "bump in the stack" implementation of UDP
fragmentation is a packet that has UDP CS == 0 and OCS equal to whatever
was received (which would be whatever was transmitted, in the absence of
errors). These cases (UDP CS == 0 with OCS either non-zero, which must be
checked, or zero, which means it's not present) already have to be handled
for an unfragmented packet. Hence no new processing path.

For fragments the usual rule applies, i.e., if UDP CS != 0 then OCS must be
non-zero; if UDP CS == 0 then OCS may or may not be zero. When each
fragment's UDP checksum is non-zero, then every fragment (and thus the
reassembled payload and surplus area) must be covered by the OCS of the
fragments, so the entire reassembled packet is protected by a checksum (and
so there is no need for a UDP checksum for the original packet). What the
draft recommends is that in this case OCS be set to zero in the original
packet since it does not provide significant additional protection. The
suggestion that "the original packet MUST NOT have an OCS option" in this
case would cause an additional processing path, since OCS is actually a
fixed field, and the way we indicate that it is omitted is to set it to
zero.

If this is not sufficiently clear, please let me know, and I'll take
another stab at it.

Mike Heard