Denial of service attack against ip_conntrack ?

[Rusty Russell]

In message <20000409125451.B18510@aldem.net> you write:
>   The problem is different - my testing show that connection record
>   is created even if I send packet with only FIN or ACK packet set.

I stole the connection tracking code from masquerading.  What do you
think is the correct behaviour if the machine reboots?  It doesn't
matter in this case, because you can always do the same thing with
real SYN packets.

>   In addition - I really do not think that we need unconditional
>   tracking of _all_ connections - in some cases it is not necessary
>   (just imagine two busy gateways/firewall - one is central and one
>   is behind it - but both are responsible for firewalling).

We don't need all of them, but it's much nicer to control.  I am
aiming for completeness and simplicity of administration with the
netfilter stuff, not speed or efficiency (we have FAST NAT, and
hardware routers for that).

> > I'm testing a patch now which introduces a more sophisticated form of
> > DoS avoidance, which should prevent it from hitting the wall quite as
> > suddenly (by definition, you will eventually lose).
> 
>   No way - it cannot be done... Until we have table of connections, and
>   until there is no filtering on the other level (IPsec?) it is not
>   possible by definition - because it is too easy to send a lot of
>   SYN packets...
>   
>   Timeouts can help, but only in case of slow links, not on high-speed
>   links...

Here's my proposed approach:

Firstly, don't track connections where the packets which create them
get dropped.  Secondly, do Random Early Drop when a watermark is
reached.  Thirdly, try to reduce the conntrack size so it will fit
into a 256-byte (rather than 512-byte) slab allocator.  Fourth, TCP
SYN-SENT connections which get a RST reply can be forgotten instantly.

If you have other ideas, please suggest them.

Rusty.
--
Hacking time.