Re: Firewall rules order and performance

Carson Gaspar <[email protected]>
Newsgroups gmane.comp.security.firewalls.wizards
Message-ID <[email protected]>
Pierre Blanchet wrote:
> This is a well known idea that the rules order is important for the best
> performance of a firewall. However, nowadays: 1. Stateful firewalls use their
> stateful engine for existing connections to allow traffic. That means that
> their performance is more related to the number of existing sessions rather
> than the number of rules, or more exactly it is tied to the ratio
> new/existing sessions. 2. Some firewalls no longer parse the configuration
> line by line but use hardware-based or tree-based model. Again,  the number
> of rules has less effect on the performance.
> 
> I'm looking for benchmarks/ideas that could prove I'm right or wrong. I know
> for sure that FW-1 and IOS depend on the rules order but what about the
> others ? Google didn't give any information one way or the other.

Define "performance"...

For state keeping packet filters, the general rules (in my experience) are:

- New connections / s is generally limited by ruleset size and complexity. As I 
recall, several years ago Lucent had an O(1) algorithm for packet filtering on 
some of their high end routers (OC-12 +) that leveraged some tricky algebra, but 
it was (at the time) limited to 256 not very complex rules. I suspect some other 
folks may have figured out similar optimizations. A simple test is to insert 
10,000+ dummy rules followed by a rule you'll actually hit. Test connection 
setup rate that way, and with your matching rule first. You'll quickly determine 
if there's anything "interesting" going on. Be sure to make the dummy rules 
annoyingly similar to the real one, but not quite the same (say, filter on TCP 
flags)

- Throughput tends to be limited by packet rate and # of existing sessions. This 
is why every vendor specifies throughput based on large packets - ask them for 
64-byte packet throughput and watch them squirm.

- Throughput can also be limited by how much protocol parsing is done and how 
complex it is. If you just have to forward packets, you can do it faster than if 
you have to look for embedded port numbers in FTP, SIP, etc. Include NAT in the 
complexity calculation.

- The above variables can also effect _latency_ which can be more or less 
important that simple throughput, depending on your application.

Application proxies have similar performance correlations, but they're not as 
straightforward.

-- 
Carson
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.