Re: Non-Last Small IPv6 Fragments

[Tom Herbert <[e-mail]>]

On Fri, Jan 11, 2019 at 1:13 PM David Farmer <[e-mail]> wrote:
>
>
> On Fri, Jan 11, 2019 at 1:58 PM Fernando Gont <[e-mail]> wrote:
>>
>> On 11/1/19 15:38, Simon Hobson wrote:
>> > Fernando Gont <[e-mail]> wrote:
>> >
>> >> ... enforce limits ...
>> >
>> > The guidance also needs to suggest sensible limits - otherwise what one implementer (eg the Linux stack that discards any small fragment that isn't the last)
>>
>> IMO, this is bad behavior advice. As an attacker, I'd fire 1280-sized
>> frags, and your check hasn't achieved anything.
>>
>>
>> >may not interoperate with another (eg make the last two fragments approximately equal in size). In a significant part, that seems to
>> > have been what this thread has been about - what is reasonable
>> guidance for this.
>>
>> In general, what you do is AIMD (additive increase, multiplicative
>> decrease). The numbers limits are a few thousand packets. Which allow
>> fragments to work for some cases - few connections, rather low
>> throughput, but will not allow system breakage when the attacker wants
>> to play.
>>
>> Dropping small frags as in Linux is bad, because you hurt
>> interoperability without any significant/real gain.
>>
>> OTOH, limiting the number of frags is good, because limits kick in at a
>> point in which "you need to do something, because otherwise - DoS".
>>
>> Obviously, you cannot expect big pipes with fragmentation to work. Given
>> high bandwith, multiply 60s * throughput, and you'll need a lot of
>> memory to hold the frags.
>>
>> Adapting the Frag reassembly time out can also help -- there's not much
>> of a point to keep a frag in memory for 60s, particularly when under
>> heavly load. -- well before that TCP timers will fire, or the frag si
>> not useful anymore, anyway.
>
>
> I just had a thought for the guidance;
>
> 1. System-wide limit the number of fragments based on the overall system resources available.
> 2. As you near said limit, maybe 75% of the limit, drop outright, or at a high probability, non-final fragments smaller than (1280/2) 640 bytes.
>
> The reasonable fragmentation algorithms I can think of do not generate non-final fragments that are less than 640 bytes. Nevertheless, such fragments SHOULD NOT be dropped except for when the system is under stress.
>
> What do others think?

I don't see any practical purpose of sending tiny fragments with eight
byte payloads in non-first fragments, these can only happens under DOS
attack or synthetic testing. So I do believe it's prudent to have some
guidance on setting limits for minimal sizes of non-first fragments.
The limit should probably be configurable with some recommended
default value. I believe the 1280 limit in Linux is too high, but
there are some compelling arguments for 640.

Tom

> ===============================================
> David Farmer               Email:[e-mail]
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: [phone]
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------