On Thu, Oct 19, 2006 at 01:09:57PM -0600, Breen Ouellette wrote:
> > From: Daniel Hartmeier (danielbenzedrine.cx)
> > pf uses a binary search tree instead of a hash table, which doesn't
> > require pre-defining a maximum size. The tree will just grow until
> > memory allocation fails. With 64MB RAM that typically doesn't happen
> > until you have over 60000 state entries.
>
> I have been doing some research and I came across this message from some
> time ago. Is this still relevant?
Yes. PF still uses a binary search tree.
It should be pointed out that the ipf state tracking also has a maximum
size, it's simply managed in a different way - there is a configurable
number of hash buckets, and a limit to how many states can be in each
hash bucket. Optimistically speaking, the number of entries would be
the product of these two numbers.
However, one advantage of the pf search tree is that it scales on a
fixed curve as the number of states increases. Hash tables can fill
unevenly, or be filled unevenly by an attacher.
> If so, can anyone tell me if the PF binary search tree is more or less
> memory efficient than the ipfilter hash table?
I'd imagine they're approximately the same in terms of memory
consumption, although I've not looked at how big state table entries are
in ipf.
> What is the fallout if PF cannot allocate anymore memory for the binary
> search tree? Does it drop connections or puke all over?
If you've set the maximum state limit correctly existing connections
will continue to work, but new connections will fail until old
connections time out. (I recommend testing on your specific hardware by
creating enough states to reach the limit)
Mechanisms such as adaptive timeouts (on by default in 4.0) will help to
purge old states out of the state table more quickly as the state table
fills.
> I am trying to convince my current employer to move away from ipfilter
> and over to PF. Any assistance would be appreciated.
I think you're focusing on the wrong areas. Without having a clear
understanding of your employer's requirements it's hard to come up with
a specific argument, but think about security, ease of use,
documentation, flexibility, reliability, and performance. Also
important may be software licensing, standardisation, and the OS
compromises you have to make to run IPF.
PF is well established as the leader in all of these areas - you may
find better performance in some other firewalls, but invariably this is
because unacceptable security shortcuts have been taken.
Some resources that you can look at to build your case are:
http://www.benzedrine.cx/pf-paper.html
http://www.openbsd.org/papers/auug2006/pf_evolution/
http://www.openbsd.org/faq/pf/index.html
http://undeadly.org/cgi?action=article&sid=20060929080943
http://undeadly.org/cgi?action=article&sid=20060927091645
http://undeadly.org/cgi?action=article&sid=20060928081238
http://coombs.anu.edu.au/~avalon/
Often one of the most convincing arguments you can make is to take your
existing IPF ruleset an re-write it as a PF ruleset. The vast majority
of security problems are due to user error, and focusing on making your
ruleset understandable and maintainable will likely bring the greatest
security benefits.
Using macros, tables, ruleset expansion, and interface groups, your
ruleset will become smaller and more maintainable, and the difference is
instantly visible.
