Re: frag6: better limitation

[Maxime Villard <max%m00nbsd.net@localhost>]

Le 29/01/2018 à 23:54, Mindaugas Rasiukevicius a écrit :
> Maxime Villard <max%m00nbsd.net@localhost> wrote:
> > ...
> >
> > I ended up writing this [1], without a lot of conviction, to say the
> > truth. A per-src-IP policy is implemented: each sender is allowed to have
> > a given number of fragments pending; beyond that limit, they get kicked.
> >
> > ...
> >
> > [1] http://m00nbsd.net/garbage/ip6/frag6.diff
>
> So, you introduce another per-IP state and O(n) scan of the IP addresses?
> What if the host receives an entire /64 subnet of spoofed packets?  Seems
> to me that you would hit the same global limit, just wasting more memory
> and CPU cycles.  I can see your desire to localise the IP fragmentation
> attacks.  Perhaps it would make more sense to have it per-interface, but
> I am not sure whether it is worth the complexity..

I've put at the end of this mail the offlist conversation I had with Joerg.

My patch is useful only if you restrict addresses in the first place. In that
case there is only a limited number of craftable src addresses. Typically:

	wm0 [public side]: allow 10 IPv6 addresses
	wm1 [local side]:  allow everything

You set:

	maxfragsip = 50
	maxfrags = 10*50 + 100 = 600

Now, even if an attacker floods your public interface with fragments, you
will still have 100 fragments that can be treated from your local network.

But yes, it is in O(n). The frag code is not optimized anyway: there is only
one lock we take all the time, and we call kmem_intr_zalloc repeatedly too. It
would be better to use pool_cache.

Maxime



-------- Message transféré --------
Sujet : Re: Fwd: Re: frag6: better limitation
Date : Fri, 26 Jan 2018 17:53:59 +0100
De : Maxime Villard <max%m00nbsd.net@localhost>
Pour : Joerg Sonnenberger <joerg%bec.de@localhost>

Le 26/01/2018 à 15:26, Joerg Sonnenberger a écrit :
> On Fri, Jan 26, 2018 at 03:06:03PM +0100, Maxime Villard wrote:
> > > Firewall configurations with a hard-coded list of IPv6 addresses for
> > > incoming connections are rare. Your patch fixes one form of DoS by
> > > introducing a worse form -- I can just send a couple of fragment from
> > > 2001:db8::1, followed by a couple of fragments from 2001::db8::2 etc.
> > > Before the total amount of memory used for fragments had a fixed limit,
> > > now it doesn't.
> >
> > No, look at the patch. The previous limit is still there. If you send from
> > different addresses this limit is hit and everything gets kicked, just like
> > the current behavior.
>
> But how is it supposed to really help then? I can keep a steady stream
> of fragments with changing source address and the limit will prevent any
> new entries to be cached. LRU doesn't help either -- the sender just
> need to drown out the legimate sources.

I understand what you say. It is clear that if you don't restrict the IPv6
addresses in the firewall, my patch does not change anything.

If you do restrict the addresses, however, you can configure the parameters
to prevent DoSes. If you allow 10 external addresses on wm0, with a maximum
of 50 fragments per address, then you just have to set the total limit to >
10*50. So, if you set the total limit to 600, you will always have 100
fragments that can be treated; and the remaining interfaces on your machine
(like wm1) won't be affected by the mess that may be happening on wm0.

Maxime