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

["[e-mail]" <[e-mail]>]

See below...
—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com

> On Nov 14, 2023, at 2:18 PM, Tom Herbert <[e-mail]> wrote:
> 
> On Tue, Nov 14, 2023 at 2:02 PM [e-mail]
> <[e-mail]> wrote:
>> 
>> See below...
>> 
>>> On Nov 14, 2023, at 1:19 PM, Tom Herbert <tom=[e-mail]> wrote:
>>> 
>>> On Tue, Nov 14, 2023 at 12:01 PM C. M. Heard <[e-mail]> wrote:
>>>> 
>>>> IMO, very few currently defined options that are passed to the user are actually useful as per-fragment options,
>>>> 
>>>> In general, options that are transmitted from the upper layer at one end to the upper layer at the other end without processing by UDP options layer other than packaging are ill-suited to being per-fragment options because they cannot be used to provide per-fragment effects. MDS, MRDS, REQ, RES, anf TIME are all in this category.
>>>> 
>>>> APC does require substantive processing by UDP options (specifically, a checksum calculation), but it cannot not do anything useful as a per-fragment option. By definition, it covers the UDP payload in the packet where it appears, and there is no UDP payload on a fragment.
>>> 
>>> Mike,
>>> 
>>> I don't see in the draft where it says that. The wording in the draft
>>> is: "It [APC] is an "alternate" to the UDP checksum that covers the
>>> user data". A fragment contains user data
>> 
>> Fragments do not contain “user data”, i.e., there is no UDP user payload. The UDP length is 8.
>> 
> 
> The term "user data" is ambiguous.I read this as any data created by
> the user which would include the data in fragments. If you mean this
> covers the UDP payload of a reassembled packet then why not just say
> that explicitly?

We do when describing APC. That’s the P in APC.
This thread has been ambiguous in comparison.

> 
>> It’s not so much that you can’t use APC, it’s that it would only protect the pseudoheader. In fragments, the user data is in the surplus area.
> 
> But you just said above, "Fragments do not contain “user data” :-).
> Please use unambiguous terminology.

Fragments contain no UDP payload; APC operates over *only* the UDP payload.

And to be clear, APC does NOT protect the pseudo header; doing so would make it useless when traversing a NAT. My mistake there.

Joe


> 
> Tom
> 
>> 
>> Joe
>> 
>>> and I don't see any
>>> requirement that states it's not allowed to be used with fragments. So
>>> by my reading it is valid where the CRC is performed over the user
>>> data in each packet. I believe it's also useful as doing CRC per
>>> fragment makes it a lot easier to offload the CRC computation to
>>> hardware, and it's more accurate over smaller amounts of data.
>>> 
>>> Tom
>>> 
>>>> Hence in a fragment a value of all-ones will give a correct CRC32c, and anything else would give an incorrect CRC32c, independently of whatever else is in the fragment or reassembled datagram.
>>>> 
>>>> In principle, AUTH and UENC could be useful as per-fragment options by providing coverage for the fragment header as well as the payload. I will note, however, that the IPsec AH does NOT protect the IP fragmentation fields: "If required, IP fragmentation occurs after AH processing within an IPsec implementation.  Thus, transport mode AH is applied only to whole IP datagrams (not to IP fragments)."
>>>> 
>>>> Having to process options during the fragmentation and reassembly processes is clearly a burden on the implementation, and if it's one that does not result in anything clearly useful, we may want to consider dropping it.
>>>> The one place where I have seen a clear use case would be in network options, and I believe that the consensus of the WG is that we would not be going there, at least for now. If we wish to future-proof the spec by including the possibility of per-fragment options either before or after the FRAG header as we do now, maybe that's acceptable, but if we do, I think that an implementation should be allowed to ignore per-fragment options that are really only meaningful as per-datagram options, and the option specifications should say as much. My preference, which I stated long ago, would be to have no per-fragment options and require the FRAG header to appear immediately after the UDP header, as I believe that this will lead to a more unambiguous spec and cleaner and simpler implementations. That being said, I am willing to acquiesce to what we have, for the sake of getting a spec shipped, as long as there is clarity for each and every option in what roles (per-fragment or per-datagram) it can be used.
>>>> 
>>>> Thanks
>>>> 
>>>> Mie Heard
>>>> 
>>>> 
>>>> On Mon, Nov 13, 2023 at 8:00 AM Tom Herbert <tom=[e-mail]> wrote:
>>>>> 
>>>>>> From the new draft:
>>>>> 
>>>>>>> Options and their processing status (success/fail) MUST be provided to the user, except for FRAG, NOP, and EOL; those three options are handled within UDP option processing only.
>>>>> 
>>>>> How does this work for per fragment options? Are options for each
>>>>> fragment passed to the user in a list with the reassembled packet? How
>>>>> would something like APC work if it's set in a per fragment option?
>>>>> 
>>>>> Tom
>>>>> 
>>>>> On Sun, Nov 12, 2023 at 8:13 PM <[e-mail]> wrote:
>>>>>> 
>>>>>> Internet-Draft draft-ietf-tsvwg-udp-options-26.txt is now available. It is a
>>>>>> work item of the Transport and Services Working Group (TSVWG) WG of the IETF.
>>>>>> 
>>>>>>  Title:   Transport Options for UDP
>>>>>>  Author:  Joe Touch
>>>>>>  Name:    draft-ietf-tsvwg-udp-options-26.txt
>>>>>>  Pages:   51
>>>>>>  Dates:   2023-11-12
>>>>>> 
>>>>>> Abstract:
>>>>>> 
>>>>>>  Transport protocols are extended through the use of transport header
>>>>>>  options. This document extends UDP by indicating the location,
>>>>>>  syntax, and semantics for UDP transport layer options.
>>>>>> 
>>>>>> The IETF datatracker status page for this Internet-Draft is:
>>>>>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/
>>>>>> 
>>>>>> There is also an HTMLized version available at:
>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-26
>>>>>> 
>>>>>> A diff from the previous version is available at:
>>>>>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-udp-options-26
>>>>>> 
>>>>>> Internet-Drafts are also available by rsync at:
>>>>>> rsync.ietf.org::internet-drafts
>>>>>> 
>>>>>> 
>>>>> 
>>> 
>>