Subject: [OPSAWG] comments on draft-ietf-opsawg-firewalls-01

From: Cameron Byrne <[email-masked]>
Date: Tue, 23 Oct 2012 13:07:44 -0700

Fred and Paul,

Thanks for writing this draft, a few comments below.  Unfortunately,
my comments are largely the result of me doing a mental diff of your
I-D and my vapor I-D titled "Stateful Packet Inspection Advisory"

1.      The introduction states a worthy goal.

2.      The treatment of E2E and information theory is not required.
It does not add value to the document.  The audience is looking for an
ops BCP, not nuanced discussion of abstract principles.

3.      The overly simplistic definition of a firewall causes
confusion. It may be best to just discuss packet filtering – stateful
and stateless (and flow, or capacity [think qos policers]).  Firewall
is too much of a loaded term and maybe should be abandoned in this
document.

4.      Problems with stateful packet inspection (SPI) firewalls

a.      Require symmetric routing, this frequently creates a single
point of failure as network admins look to create a single point of
entry and policy enforcement.  This also frequently creates routing
complexities.

b.      Require fragment re-assembly, frag cache is another way to
attack an SPI firewall or degrade its performance.

c.      Flow state can degrade capacity and cause outages, this is a
huge issue.  This SPI FW can do 1M sessions....and it starts to break
at 800k sessions, and really tips over a 1.1M sessions. Sessions rate
limiters can help in some cases, but not all.

d.      ALGs are required when filtering many protocols dynamically
base on state.  ALGs are fragile and frequently break, it is hard to
code all the cases of how SIP will behave and what ports need to be
opened as result of an SIP/SDP message (what RTP pin holes to
dynamically open).

e.      ALG are also frequently a control plane function, and control
plane functions scale much less well than hardware forwarding.  This
is yet another attack vector on the SPI firewall itself.

f.       Examples of how to properly use a SPI firewall would help.
For example, a DNS server should never be behind a network based SPI
firewall.  ( the information is public, the ports are open either way,
UDP is stateless, many small sessions open and close quickly.... )

g.      State that an organization’s “network” is seldom a good a
perimeter for an SPI firewall, a LAN may be a perimeter, or a
functional zone within a data center (“bid data” LAN) may be a
perimeter.  Some examples would help.  I would promote the ideas of
zones or enclaves that have specific security policies and controls in
place that match and mitigate specific the risks that are well suited
for an SPI firewall.

5.      Most hosts have firewalls today, and most consumer hosts have
firewalls on by default with a policy to deny all incoming
connections.  The trend should be away from SPI firewalls since this
function is nearly universally deployed in hosts.

6.      Hosts that do not “listen” on ports / sockets have nothing to
block with the exception of ICMP, they typically do not need a network
based firewall.  A network firewall is only helpful in the case that
requires redundant enforcement of policy.  For example, if the policy
is that hosts on a LAN may not have incoming connections allowed,
controlling the hosts to no allow incoming connections is sufficient
to conform to the policy.  This may be achieved by not running any
“services” to listen.  This may be further enforced by local packet
filtering policy on the host.  If the host cannot be trusted, then the
network must enforce the policy within the network.

7.      Another case is the preservation of LAN bandwidth.  We only
allow inbound traffic that was first initiated from the LAN towards
the WAN.  How common / real is a LAN BW starvation threat?

8.      The days of Nimda, code red, sql slammer, and so on are gone
because of host based firewalls as well as greater care when coding
network stacks and applications.  The document should go to some
length to emphasize this point and discuss how the industry has “over
corrected” for sins of the past and now some rationalization must take
place.

9.      An SPI Firewall is most fit for acting as a low volume logging
control point.   They should only be used when adherence to policy is
of extreme important that multiple discrete devices must enforce and
log conformance to policy

10.   Firewall policies scale best when they are stateless.  Need to
define and advise when, how, and where stateless verses stateful can
be employed.  Focus stateless filtering on course grain at the AS
edge, focus on fine stateless grain filtering at the application edge,
and in the rare case on stateful at the application edge.  Hosts are
fit to do both stateful and stateless filtering.

11.   Remote trigger blackhole [RFC5635] is another effective form of
stateless filtering that should be mentioned as an effective tool