[nycbug-talk] home grown firewall solutions ...

[alex at pilosoft.com]

On Sun, 12 Mar 2006, Fabian Keil wrote:

> alex at pilosoft.com wrote:
> 
> > c) it is, however, nontrivial to do this with pf 'keep state', if
> > that's what you want. if you want to keep state, you need lots of CPU
> > power and/or memory and/or hackery.
> 
> Are you sure this is true for PF?
> 
> Quote from http://kerneltrap.org/node/477:
> 
> |JA: How does pf performance compare to other stateful packet filters? |
> |Daniel Hartmeier: In the benchmarks I did and based on the feedback
> |from people who compared pf with other filters on production machines,
> |very well, often significantly better. In particular, we found that
> |keeping state on all connections scales well and is faster than
> |stateless rule evaluation.
This is probably the case for non-ddos traffic. 

Here's some basic math for you. Line-rate GE traffic is 1.4mpps. In case
of ddos, this is potentially 1.4M different src/dst pairs per second. To
be able to statefully filter it, you need to at least keep in memory 30
seconds worth of traffic - that's 50M flow records. You probably need to
keep at least 50 bytes of data per flow - that's 2.5G memory requirement
right there. Now, for each packet coming in, you need to match it with a
previous flow record. That will take at least 100 comparisons. Each random
memory access is (say) 2ns. 100 comparisons = 200ns. That means, you can
match ~5M new flows per second best case. (which is more than you have to,
but you have to realize you need lots more things to do in than just
memory lookup to match flow).

Now, you need to expire flows every 30 seconds. (at least this means
reading through 2.5G every 30 seconds).

Basically...This is hard. Proper solutions would use TCAM to keep the flow
info.

-alex