ACLs vs. full firewalls

Roland Dobbins rdobbins at
Tue Apr 7 19:28:47 CDT 2009

On Apr 8, 2009, at 4:05 AM, Michael Helmeste wrote:

> However, I wanted to get other opinions of what packet filtering  
> solutions people use in the border and in the
> core, and why.

Stateless ACLs in hardware at the edge are important both for  
infrastructure self-protection (i.e., iACLs) and for policy  
enforcement of the type you indicate.  As others on this thread have  
pointed out, do understand your platform characteristics and craft  
your ACLs accordingly.

Stateful - i.e., context-aware bidirectional - filtering via a  
firewall makes sense in situations in which a) the nodes 'behind' the  
firewall aren't typically operating as servers and/or b) the  
bidirectional communications patterns which should be observed are  
well-known, and in which the participation of hosts is under the  
control/influence of the network operator.  For example, in front of a  
corporate LAN, or between the tiers of a multi-tiered application, one  
can craft quite specific stateful inspection rules which can be used  
to explicitly allow and disallow certain types of traffic.

For front-end, publicly-accessible conventional servers, stateful  
inspection may not add as much value, as basically every connection  
which comes into those servers is unsolicited (i.e., no existing  
stateful communications context against which to measure pass/fail  
decisions); this is where high-speed stateless ACLs, coupled with host  
OS/app/service hardening play a key role.  It's very important to  
avoid the instantiation of unnecessary state in front of public-facing  
assets, as DDoS attacks are essentially attacks against capacity and  
against state.

One should also look into implementing DDoS mitigation techniques such  
as S/RTBH, in conjunction with the chosen policy-enforcement regime.

Roland Dobbins <rdobbins at> // +852.9133.2844 mobile

   Our dreams are still big; it's just the future that got small.

		   -- Jason Scott

More information about the NANOG mailing list