[PATCH] aggressive early_drop and reserved conntrack entries
Harald Welte
laforge at netfilter.org
Thu Dec 16 13:31:51 CET 2004
On Thu, Dec 09, 2004 at 09:34:34AM +0100, Jozsef Kadlecsik wrote:
> Hi,
>
> The included patch addresses the following issues:
>
> - When the conntrack table is full, we search only in a single hash
> bucket. We are in trouble anyway, so let's search harder for
> droppable entries: the patch extends the search to at most the third of
> all the buckets.
I don't think it's a good idea to increase cpu and especially cache
usage in sucha (likely DoS) case.
> - If the conntrack table is full, the remote management of the machine
> becomes a little bit complicated :-).
That's why you put in a special rule into 'raw' to bypass conntrack for
administrative connections. I think this is the best way to address the
problem, especially since we're talking about local sockets... and the
local tcp stack should behave just as conntrack itself and reject all
packets that don't match an existing connection.
So from my point of view, even the extra new list is not needed.
We really should think of decreasing complexity of conntrack, not
increasing it more.
And also, all of this new experimentation should definitley be done on
top of nf_conntrack. I already dislike the amount of changes still
going into ip_conntrack at this time :(
--
- Harald Welte <laforge at netfilter.org> http://www.netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : /pipermail/netfilter-devel/attachments/20041216/d1c811ba/attachment.bin
More information about the netfilter-devel
mailing list