--- Henrik Nordstrom <[EMAIL PROTECTED]> wrote: > 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 Is there a need to do DNAT before the creation of the conntrack entry? > * state/conntrack matches executed
State match could be part of this new filter table besides other matches. > * 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. Why would modules have to create the conntrack entry? If the filter ACCEPTS the packet, the code branch in the core can create the entry. Is there something I am missing? > > 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" > My question was is there fundamentally/architecturally wrong with C? > Regards > Henrik Thanks __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/
