tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: frag6: better limitation

Le 29/01/2018 à 23:54, Mindaugas Rasiukevicius a écrit :
Maxime Villard <> 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.



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.


-------- Message transféré --------
Sujet : Re: Fwd: Re: frag6: better limitation
Date : Fri, 26 Jan 2018 17:53:59 +0100
De : Maxime Villard <>
Pour : Joerg Sonnenberger <>

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.


Home | Main Index | Thread Index | Old Index