Re: Non-Last Small IPv6 Fragments

[Tom Herbert <[e-mail]>]

On Fri, Jan 11, 2019 at 4:11 PM David Farmer <[e-mail]> wrote:
>
>
> On Fri, Jan 11, 2019 at 4:47 PM Tom Herbert <[e-mail]> wrote:
>>
>> 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.
>
>
> I'd be fine with adding something like the following;
>
> Destination nodes SHOULD NOT drop non-final fragments shorter than 640 bytes unless they are under stress. However, highly constrained devices, such as devices with minimal memory or CPU, or very low-power devices, could be considered as always under stress, and therefore it might be prudent for such devices to always drop non-final fragments shorter than 640 bytes.
>
> Would that cover your issues?

David,

It make sense from a receiver point of view, but not the transmitter
who wouldn't know that its peer is a such a device. There should be
guidance to senders to the effect that if you want to maximize the
chances your fragments are reassembled then make them at least this
size. From a pragmatic point a view, given that we've identified a
potential DOS attack, I think it's likely that we'll end up setting
the default limit, in Linux at least, probably to 640 anyway unless
there is good argument otherwise that doing so would break operability
(with real implementations and not just in synthetic conformance
tests).

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
> ===============================================