Re: Non-Last Small IPv6 Fragments

[Tom Herbert <[e-mail]>]

On Fri, Jan 11, 2019 at 2:33 PM David Farmer <[e-mail]> wrote:
>
>
> On Fri, Jan 11, 2019 at 3:27 PM Tom Herbert <[e-mail]> wrote:
>>
>> 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.
>
>
> Why non-first fragments? Did you mean non-final? Maybe both first and last should be exempted?
>
Yes.

> I mostly agree with you, but on the other hand is there any compelling reason to potentially break anything if the host isn't under stress?

That depends on what resource is "under stress" in the host.
Reassembly is an expensive packet processing operation that requires
one lookup to find the state for the ID being reassembled, and then a
second lookup to find the position of the fragment in the queue.
Because fragmentation is considered to be rare, there hasn't been a
lot of work to optimize these operations or rely on hardware offload
(there is UDP fragmentation offload, but that is not ubiquitous). I
would be concerned that a well crafted attack with small packets could
be bad for low powered devices. A limit on the fragment size not only
caps the amount of memory burned, but also caps the packet rate and
hence CPU needed for reassmbly.

Tom

>
> Further, if you only limit tiny fragment, there is still a problem, you just have to use packets bigger that the limit, what ever it is.  A few tiny fragments aren't a problem, only lots of them are.
>
> --
> ===============================================
> 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
> ===============================================