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 > allocated. 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 users) 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" Regards Henrik
