Re: Non-Last Small IPv6 Fragments

[David Farmer <[e-mail]>]

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?

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?

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