I don't need no stinking firewall!

Wed Jan 6 04:52:49 UTC 2010

Excerpts from Dobbins, Roland's message of Tue Jan 05 20:23:28 -0800 2010:

Roland,

On many of the points you've made, I totally agree. Well-managed
hardware routers that have support for ACLs in hardware are a great
firewall for things that have a relatively small set of rules (e.g.
"any:any -> server:80", "server:80 -> any:any"), and come with the added
bonus of being able to both firewall and route traffic at whatever speed
it forwards at.

However, the "well managed" part seems to be a sticking point for most
organizations I've seen. No doubt, shops that use this effectively have
some sort of homebrew or commercial firewall management platform that
let's you place policy in one place and make sure that it's pushed out
properly.

> Rate-limiting during a DDoS - i.e., an attack against state and *capacity* - is
> absolutely the *worst* thing one can possibly do, in almost all circumstances. 

Why so? Because of something this does to the device doing the rate
limiting (I assume an upstream router of some sort), or because it
renders the attack successful?

> No, I've asserted that all stateful firewalls created in the history of the
> world to date, commercial or open-source, are based upon a specific
> *fundamental architectural premise* which precludes their placement in front of
> servers.  

I'm not so sure I follow you here. How does a "fundamental architectural
premise" (I assume you mean keeping track of application-layer session
state) *preclude* it from being placed in front of a server? Sure,
it's a poor use of raw silicon and electrical power, but why does that
rule out in advance placing it in front of a server?

In theory though, someone could construct a massive state-tracking
machine that can still keep track of stateful traffic, Mpps and above.

Cheers,
jonathan