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

[Gorry Fairhurst <[e-mail]>]

I think I may have caused some confusion to all, so sorry.

What I intended to suggest as a strawman described two cases: a baseline that
was expected/required and permission to do more.

1. The spec*recommends*  or better*requires*  reassembly of a much more
conservative value, receivers are only required to be able to process
packets split into 2 fragments. Such that it can be expected to work
when:

(a) In this baseline version a UDP datagram can only be fragmented into
two packets - the first likely being of the size of the PMTU, the second
the remaining bytes. The size is limited to 1460B of UDP payload for
IPv4 (or an equivalent size for IPv6).
- This explicitly supports paths that have a PMTU<0.5*1500B.
- This explicitly allows plenty of space to add EH for OAM; tunnel
headers; link encaps headers; etc.
- It needs the maximum packet size at the sender (PMTU)to be known/configured.

(b) At the receiver, a valid reassembled datagram is then less than 1460B of
UDP payload for IPv4 (or an equivalent size for IPv6).
- A received fragment is one of:
	- a new valid fragment
	- an invalid fragment
	- it completes an earlier fragment
	- it causes this and earlier fragments to be dropped (buffer
	  exhaustion)
- This eliminates the need to support middle packets and makes the processing simple by avoiding
large searches to reassemble multiple fragments at the receiver.
- There is resaonable efficiency with fragment buffers of size RMSS,
which is the same as a "normal" packet size, if an implementation
chooses to do this e.g. to limits attacks that target small buffers or
memory management. An implementation could also decide to limit the size of
the queue of fragments.

2. However, I'd suggest the spec also*allows*  arbitrary number of fragments.
- So a receiver MAY support 3 or more fragments; more
sophisticated buffer management; etc.
- Some receivers will decide to do this and can advertise a RMSS larger
when they do.
- Some senders will be setup to benefit from this.


Is that description any clearer or helpful to comment upon?

Gorry (as an individual member of tsvwg!)

On 31/08/2021 20:51, Joe Touch wrote:
> Two would be closer to 2500.
>
>> On Aug 31, 2021, at 12:29 PM, Gorry Fairhurst <[e-mail]> 
>> wrote:
>>
>> 
>> On 31/08/2021 18:59, [e-mail] wrote:
>>> More responses…
>>>
>>> —
>>> Joe Touch, temporal epistemologist
>>> www.strayalpha.com <http://www.strayalpha.com>
>>>
>>>> On Aug 31, 2021, at 3:17 AM, Gorry Fairhurst <[e-mail] 
>>>> <mailto:[e-mail]>> wrote:
>>>>
>>>> I have the following questions relating to the text about Fragments.
>>>>
>>>> Best wishes,
>>>>
>>>> Gorry
>>>>
>>>> (as an  individual)
>>>>
>>>> ===
>>>> In section 5.3: Frag:
>>>>
>>>> “   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).
>>>
>>> Thanks - I didn’t know that existed. Will do.
>>>
>>>> ===
>>>>
>>>> Concerning Frag:
>>>>
>>>> “ 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).
>>>
>>> OK.
>>>
>>>> ===
>>>>
>>>> Concerning Frag:
>>>>
>>>>    >> 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?)
>>>
>>> Yes; will do.
>>>
>>>> ===
>>>>
>>>> Concerning Frag:
>>>>
>>>>    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?)
>>>
>>> Yes.
>>>
>>>> ===
>>>> In 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?
>>>
>>> IPv6 requires reassembly to 1500B but has no frag count limit (i.e., 
>>> MRSS is a size, not a number). I favor the same approach here, 
>>> especially because it can be argued to serve the same purpose with 
>>> the same impact and vulnerability.
>>>
>> If I am not mistaken, that's two full-sized IPv6 packets. I'd be OK 
>> with this.
>>
>> I can see merits in allowing 1500B plus options plus tunnel headers, 
>> which might sometimes be nice - which would of course be a little larger.
>>
>> Gorry
>>
>>