4 ms·

I'm not sure I agree with the argument that faster line rates creating a speed limit for firewalls. It seems like firewall hardware could parallelize internally

I'm not sure I agree with the argument that faster line rates creating a speed limit for firewalls. It seems like firewall hardware could parallelize internally at layer 3, sharding by source/destination IP or port, so all packets from a single flow will go through the same processing core, no? This would add a finite latency, but I don't think it would impact throughput. Am I missing something?

scurvy 11y ago
Probably a lot. I'm not sure exactly what it is though. If it were that easy, we'd have line-rate firewalls from every manufacturer. Considering that the performance rates are much lower, there are indeed challenges. Tuple based hashing can get complicated and is highly dependent upon the installation. Some would want source IP. Some want destination IP. Some want a mixture of destination IP and source IP and port. How much you can get through each core (in aggregate) definitely impacts throughput. Think of a volumetric DDoS attack that rolls into a network over a single path and overwhelms a 1/10/40/100G link. You could have a dozen of those links, but your throughput is hosed because that link is effectively saturated. It might only affect 1/12 of your capacity, but you can't use any of the other links. I hate to bring BGP pathing into a firewall discussion, but maybe it makes sense.
readams 11y ago
Firewalls today are able to filter at line rate for a single flow on an interface. If you want to allow 100G by handing 10 10G flows in parallel this is completely possible, but not quite the same thing.
- EtherealMind 11y ago
  Delivering this function is very costly, because of stateful inspection you must implement flow sticking which require buffering which then impacts performance ..... and so on and so on. no, doesn't work.
EtherealMind 11y ago
There are some non-obvious issues: 1. Why not firewall in the operating system and distribute/scale the load evenly ? Centralising the firewall was done when OS provisioning was bad, now we have Puppet/Chef/Ansible, firewalls operations is simple enough. 2. Simple firewalling is effectively worthless when 99% of all traffic is HTTP/S and SSH. To add value you perform flow analysis combined with deep packet inspection to build a meta-data data to pass through a heuristics/pattern analysis to perform threat detection. 3. Passing through any device creates latency in the order of milliseconds, which is not acceptable in east/west traffic loads. Parallelisation, caching, flow cut-through will all incur a latency penalty. HTH greg
barrkel 11y ago
Cost; specifically, power costs and scaling curves. If you watched the video, you'd see Alex pointing out the disparity between the best dumb switch he could buy (30Tbps, 5kW) and the best firewall (120Gbps with some, but not all features turned on, using 2.4kW). Point being, he could run a datacentre with one switch using 5kW, but would need 250 firewall boxes using 600kW. And trends are driving the two apart; hardware firewalls aren't keeping up.

scurvy 11y ago

Probably a lot. I'm not sure exactly what it is though. If it were that easy, we'd have line-rate firewalls from every manufacturer. Considering that the performance rates are much lower, there are indeed challenges. Tuple based hashing can get complicated and is highly dependent upon the installation. Some would want source IP. Some want destination IP. Some want a mixture of destination IP and source IP and port. How much you can get through each core (in aggregate) definitely impacts throughput. Think of a volumetric DDoS attack that rolls into a network over a single path and overwhelms a 1/10/40/100G link. You could have a dozen of those links, but your throughput is hosed because that link is effectively saturated. It might only affect 1/12 of your capacity, but you can't use any of the other links. I hate to bring BGP pathing into a firewall discussion, but maybe it makes sense.

readams 11y ago

Firewalls today are able to filter at line rate for a single flow on an interface. If you want to allow 100G by handing 10 10G flows in parallel this is completely possible, but not quite the same thing.

EtherealMind 11y ago
Delivering this function is very costly, because of stateful inspection you must implement flow sticking which require buffering which then impacts performance ..... and so on and so on. no, doesn't work.

EtherealMind 11y ago

There are some non-obvious issues: 1. Why not firewall in the operating system and distribute/scale the load evenly ? Centralising the firewall was done when OS provisioning was bad, now we have Puppet/Chef/Ansible, firewalls operations is simple enough. 2. Simple firewalling is effectively worthless when 99% of all traffic is HTTP/S and SSH. To add value you perform flow analysis combined with deep packet inspection to build a meta-data data to pass through a heuristics/pattern analysis to perform threat detection. 3. Passing through any device creates latency in the order of milliseconds, which is not acceptable in east/west traffic loads. Parallelisation, caching, flow cut-through will all incur a latency penalty. HTH greg

barrkel 11y ago

Cost; specifically, power costs and scaling curves. If you watched the video, you'd see Alex pointing out the disparity between the best dumb switch he could buy (30Tbps, 5kW) and the best firewall (120Gbps with some, but not all features turned on, using 2.4kW). Point being, he could run a datacentre with one switch using 5kW, but would need 250 firewall boxes using 600kW. And trends are driving the two apart; hardware firewalls aren't keeping up.