On Wednesday 11 December 2002 11:59, ryan beasley wrote:
<SNIP>
> When it comes to possible permanent workarounds for the situations above,
> I thought of the following:
>
> 1) New state flag, IS_STATIC or IS_IMMUTABLE, in addition to add'l
> rule option "immutable" (dependent on "keep state"). State entries created
> by rules with the "immutable" option would have the IS_IMMUTABLE
> flag set such that they are simply overlooked when IP Filter must
> crunch to kill off "idle" state entries.
>
Wouldn't that make the problem worse, what if someone found a way to cause
immutable connections in the keep state table ?
> 2) Lightweight state entries (whose merit is fairly dependent on my
> assumption that large filterset lookups can significantly affect
> performance compared to typical state table lookups). I'd
> think of this as a way to bypass the bulk of filter processing.
> These would behave as a hybrid of firewall rules and state entries:
>
> Like a firewall rule entry, cost is paid once at load time.
>
> Rather than having a tree of grouped rules, they're hashed by
> transport protocol, destination address and port only. Lookups
> would be somewhat similar to portions of fr_checkstate with
> SI_W_SADDR|SI_W_SPORT flags set. Additionally, one would shed the
> cost of verifying a TCP segment's presence within the current TCP
> window.
>
> (Anywho, I find the first to be much more plausible, and honestly, I
> started losing focus thinking of / writing about the second while
> becoming increasingly sleepy, though I still thought it worth sharing.
> Apologies if these came up on the list before; didn't find anything
> after a cursory Googling. :).)
>
I don't quite understand the second idea :(
-Antony
*************************************************************************
This e-mail and any attachments may contain confidential or privileged
information. If you are not the intended recipient, please contact the
sender immediately and do not use, store or disclose their contents.
Any views expressed are those of the individual sender and not of Kinetic
Information System Services Limited unless otherwise stated.
www.kinetic.co.uk
