Re: Non-Last Small IPv6 Fragments

[David Farmer <[e-mail]>]

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