Too many connections and init_conntrack
Fri, 19 Apr 2002 08:20:48 +0200
Ankit Jain wrote:
> Today we create a connection tracking entry for every
> new packet that we see, whether valid, invalid or
> even for one that will be dropped in future by filter.
> Is there an advantage in this design approach?
Simplicity and cleanness.
> Does it make sense not to create these entries so that
> an intruder is not able to bog down the system by
> just sending new connections which may not be allowed
> altogether but end up causing new resources to be
Not much in the current design, as it then involves adding yet another
table to the system to filter before connection tracking.
It may be possible to have the connection tracking entries created "on
demand" to defer the creation until actually needed
On demand is:
* NAT targets executed
* state/conntrack matches executed
* packet is leaving the system (could be made optional for advanced
Problem is that this would add some overhead to the code
* Each "NEW" session would require twice as many lookups in the
conntrack table. Once for connection tracking of tracked sessions, once
when creating the new conntrack entry.
* Every module making use of conntrack gets a slightly more
complicated code path (hidden by a macro, no public API change required)
to have a condition and call to create the new conntrack entry.
The question is which of the overheads is the worst..
A) the temporary creation/deletetion of conntrack entries for packets
blocked by the ruleset
B) the addition of yet another filter table, executed before conntrack
C) the increased code path to dynamically create conntrack entries
"only when needed"