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

[Martin Duke <[e-mail]>]

OK, I get it now. Reassembled fragments always have UDP CS == 0. Thanks.

I think we've converged on most points.  A couple of things I'm asking the
authors to think about and can live with the result, and maybe we need to
talk more about token generation?

On Fri, Apr 5, 2024 at 11:37 AM C. M. Heard <[e-mail]> wrote:

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