Re: Non-Last Small IPv6 Fragments

[Brian E Carpenter <[e-mail]>]

On 2019-01-14 07:54, Bob Hinden wrote:
> Unleveling a bit.
> 
> I think the w.g. should be very cautious about making protocol changes based on what appears to be a fragmentation resource management problem in an implementation.

I agree. However, I wonder if we need to clarify that there is no rule that non-last fragments must be at least 1280. It seems that the Linux patch assumed that there is
such a rule.

   Brian

> 
> The fix of “..reject IPv6 fragments less than 1280 that aren't last fragment” seems pretty limited as discussed on the list.   Seems to me that this implementation needs more robust ability to handles it’s reassembly resources.
> 
> Bob
> 
> 
> 
>> On Jan 12, 2019, at 11:45 AM, Ole Troan <[e-mail]> wrote:
>>
>> Tom,
>>
>>> On 12 Jan 2019, at 20:27, Tom Herbert <[e-mail]> wrote:
>>>
>>>> On Sat, Jan 12, 2019 at 10:50 AM Ole Troan <[e-mail]> wrote:
>>>>
>>>>
>>>>
>>>>>> On 12 Jan 2019, at 18:17, Tom Herbert <[e-mail]> wrote:
>>>>>>
>>>>>> On Sat, Jan 12, 2019 at 1:49 AM Ole Troan <[e-mail]> wrote:
>>>>>>
>>>>>> Fernando said:
>>>>>>> I agree with the above (please see the ref I posted to RFC6274, which
>>>>>>> basically argues about this). HOowever, it is still not clear to me
>>>>>>> what's the problem you are addressing by enforcing a minimum fragment
>>>>>>> size. If you allow MIN_MTU/2, then you require first frags to be 640
>>>>>>> bytes.. and teh attacker is required to send 640 as opposed to 60 bytes
>>>>>>> or  so. Doesn't seem to be much of a difference to me.
>>>>>>> And as noted by Bob, I still don't see what's the big deal with the
>>>>>>> small fragments.
>>>>>>>
>>>>>>> There are some DoS attacks where you send a last frag and possibly a
>>>>>>> first frag, and the implementation allocates a buffer that would fit the
>>>>>>> rest of the missing fragments -- obviously exacerbating the problem a
>>>>>>> bit. BUt still i this cases, the size of the first frag is not a big deal.
>>>>>>
>>>>>> In e.g. VPP limiting fragment size would not help at all.
>>>>>> The scarce resource is number of available buffers. One fragment occupies at least one buffer regardless of how much smaller than 2K (default buffer size) it is.
>>>>>>
>>>>>> Mitigations against attack is highly likely to be implementation specific.
>>>>>> As an example see:
>>>>>> https://github.com/FDio/vpp/blob/master/src/vnet/ip/ip6_reassembly.c
>>>>>>
>>>>>> Default reassembly timeout is 100ms (constrasting that with the RFC 60s)
>>>>>> Maximum consequtive reassemblies in progress is limited to 1024.
>>>>>> And in other virtual reassembly algorithms we have also limited maximum allowed number of fragments in chain to 5.
>>>>>>
>>>>> Ole,
>>>>>
>>>>> I don't know what the protocol requirements are for virtual
>>>>> reassembly. Is there an I-D or RFC on this?
>>>>
>>>> Virtual reassembly is just an optimization. The protocol requirements are the same.
>>>>
>>> The same as what requirements? RFC8200 defines how reassembly occurs
>>> at a destination (the addressed node), not how an intermediate node in
>>> the network reassembles packets. It is not the same thing. For
>>> instance, there is an additional implicit requirement in virtual
>>> reassembly that all fragments are routed through the same node. Also,
>>> Hop-by-Hop options and Destination options can precede the fragment
>>> header, so is the requirement that same that nodes MUST process these
>>> before the fragmentation header is processed?
>>>
>>> If virtual reassembly is brought up in the context of standard
>>> protocol discussion, it would really be nice to have a normative
>>> desciption of that protocol mechanism.
>>
>> The code example I gave was for host reassembly.
>> I didn’t intend with my comment any more than that this is quite implementation specific, that it’s not obvious that the IETF can provide anything useful here, apart from removing network layer fragmentation, and I was absolutely not suggesting we should have a document on in-network reassembly.
>>
>> Cheers
>> Ole
>>>
>>> Tom
>>>
>>>> Cheers
>>>> Ole
>>>>
>>>>
>>>>>
>>>>> Thanks,
>>>>> Tom
>>>>>
>>>>>> Now, if we in the IETF think we can provide some guidance here, I will second Erik’s suggestion of getting more research.
>>>>>>
>>>>>> The packet traces I have looked at in the past, the majority of fragmeted packets looked like attacks. UDP port 80, DNS queries to “thisdomainnamewillgiveaverylongresponsepurelyforthepurposeofattack.org”,
>>>>>> didn’t reassemble, 64K size… But it would be interesting to understand fragmentation behaviour in various parts of the network.
>>>>>>
>>>>>> - how long are fragment chains (both in packets and in time span)
>>>>>> - ratio of out of order fragments
>>>>>> - which applications use fragments
>>>>>> - ratio of attack traffic using fragments
>>>>>> - average/min/maximum sizes, same for numbers of fragments in chain
>>>>>> - ratio of complete fragment chain following the same path in the network
>>>>>> - ratio of fragments to total traffic
>>>>>>
>>>>>> Cheers,
>>>>>> Ole
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --------------------------------------------------------------------
>>>>>> IETF IPv6 working group mailing list
>>>>>> [e-mail]
>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>> --------------------------------------------------------------------
>>>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>