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 _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
