Re: [tsvwg] draft-ietf-tsvwg-udp-options-13: Comments concerning Fragments

[Gorry Fairhurst <[e-mail]>]

On 02/03/2022 04:50, [e-mail] wrote:
> Hi, all,
>
> Not sure I addressed these specifically, so here goes (as there’s an 
> update coming)…
>
> Joe
> —
> Dr. Joe Touch, temporal epistemologist
> www.strayalpha.com <http://www.strayalpha.com>
>
>> On Aug 31, 2021, at 3:27 AM, Gorry Fairhurst <[e-mail]> 
>> wrote:
>>
>> I reviewed the latest revision (13) of the draft and have the 
>> following questions relating to the use of Fragments.
>>
>> Best wishes,
>>
>> Gorry
>>
>> (as an individual)
>> ===
>> In section 5.5
>>
>> “   Legacy receivers interpret FRAG messages as zero-length payload
>>    packets (i.e., UDP Length field is 8, the length of just the UDP
>>    header), which would not affect the receiver unless the presence of
>>    the packet itself were a signal.”
>> - can you supply a reference here? (If no other then sect 5 of RFC8085).
>
> Done.
>
>> ===
>> “ This allows either pre-reassembly or post-reassembly
>>    UDP option effects.”
>> - I think I understand a use case and it would be nice to have an 
>> example of using both per-fragment and per-datagram options: could 
>> this be used with fragments req/res options to determine a suitable 
>> PMTU, and the time options used per reassembled datagram (since in 
>> many case this needs to measure the time across the reassembled 
>> end-to-end datagram path).
>
> Done.
>
>> ===
>>    >> UDP reassembly space limits SHOULD NOT be implemented as an
>>    aggregate, to avoid cross-socketpair DOS attacks.
>> - Please explain “aggregate” (is this across multiple socket-pairs?)
>
> Done:
>
> >> UDP reassembly space limits SHOULD NOT be computed as a shared 
> resource across multiple sockets, to avoid cross-socketpair DOS attacks.
>
>
>> ===
>>    Any additional UDP options, if used, follow the FRAG option in the
>>    final fragment and would be included in the reassembled packet.
>> - I don’t like the word “additional” here, can you find a better word 
>> (per-datagram?)
>
> Done.
>
>> ===
>> 5.7. Maximum Reassembled Segment Size (MRSS)
>> - I’m going to make a suggestion here, that was earlier brought up by 
>> Tom Jones: Why don’t we fix the DEFAULT MRSS to 2 packets when MRSS 
>> is supported. Larger values might be supported, which would be fine, 
>> but the case of 2 might have some immediate benefit:
>> - A receiver can then fragment a UDP packet to tunnel of include UDP 
>> options, likely in many current cases a second fragment will be enough.
>> - A receiver can greatly simplify its processing if it tries to 
>> reassemble whenever it receives a second fragment of the same 
>> datagram. The simplification here mitigates some worry about attacks 
>> that target reassembly buffers or processing costs. He previously had 
>> not implemented fragment support because it was cumbersome to include 
>> in the OS he worked with.
>> - Thoughts?
>> ===
>
> We later converged on 3000 bytes or 2 fragments.
>
Thanks for looking at this carefully, This all sounds like what was 
discussed off-list.

Best wishes,

Gorry