During Christmas lunch discussions, I was offered some new NGFW firewall hardware to test. I said yes, I would like to know the product and its API integrations, although firewalls will not play a role in future enterprise networks. My answer confused many. After all, the firewall is a network legend that is the cornerstone of many companies’ information security. NGFW also played a significant role in my career. Along the way, I have followed the changing direction of application architectures and digitalization requirements, where it is difficult to apply a firewall. That’s why I argue that firewalls will die in 2030 as unnecessary.
The future of HPC and AWS™
One significant signal is the High-Performance Computing (HPC) requirement for fast data transfer. Data center optical networks enable high transfer speeds, but the TCP/IP protocol has become a bottleneck for HPC. The TCP protocol, designed for an unreliable Internet network in the 80s, ensures the arrival of IP packets in the correct order but causes a significant transmission delay. During the transfer delay, the HPC is idle. Another problem is the TCP Single-path architecture, which prevents data transmission from scaling over multiple optical paths. In the SRD protocol developed by AWS™, these problems have been eliminated. The AWS™ ENA Express concept does not use the TCP/IP protocol.
What kind of firewall rule do you make if there is no TCP/IP protocol?
The firewall service policy is based on limiting IP addresses and TCP/UDP ports. Nothing is done with current firewalls if TCP/IP is not used. Similarly, a large part of information security solutions for data traffic is based on analysis around TCP/IP. The challenge does not only concern the firewall but countless information security products. NGFW application inspection was a nice idea, but the reality hits when almost all traffic is encrypted these days.
http/3 and Windows 2022 server
Almost all network services suffer from the same performance challenge as HPC. Reducing the transfer delay and faster data transfer processing requires more advanced protocols. The application transfer delay visible to the user cannot be significantly improved by other means. 5G and fiber optic connection providers have also encountered this challenge. High application e2e latency is visible in the application and network analysis.
The UDP (QUICK) protocol has sought quick solutions for improving service response time. In 40 years, communication networks have become very reliable compared to the technology of the 80s, thanks to optical data transmission and microcircuit development. UDP (QUICK) is well suited to the Internet and is significantly faster than the TCP protocol. The new http/3 and Windows™ 2022 servers know how to use the UDP (QUICK) protocol following social media applications like Facebook.
For firewalls, UDP is inconvenient.
Most firewall technology manufacturers have instructed to prevent using the UDP (QUICK) protocol for years. It tells about the seriousness of the problem. In the firewall, OSI levels 4–7 packet inspection technology has been developed for the TCP protocol and HTTPS inspection for the SSL/TLS protocol. UDP (QUICK) replaces both TCP and TLS protocols. Thus, the firewall limits the user experience of digital services more and more. Regardless of my prediction, I recommend upgrading your firewall or switching to a NaaS/Cloud Firewall. If you get your hardware, ensure the capacity and features cover UDP (QUICK) at best possible level.
Application Development vs. Web Team – Both, Right?
Have you ever been involved in a discussion stating: “the application owner does not know how to define the information required by the firewall rules for the network team,” or vice versa? Neither is wrong. Communication networks and firewalls generally do not understand anything about applications. They blindly forward IP packets to the next device they know. The reality of application identification is TLS (encrypted traffic).
Good cooperation between the application and network team, standardized and professional maintenance of the rules, and documentation in creating the firewall rules have, at best, prevented more significant disasters. Unfortunately, outsourcing, constant turnover of personnel, lack of know-how, information lost in corporate restructuring, and lack of communication and application (update) changes have caused a difficult situation.
How many Firewall teams define API firewall rules in a Docker™, Kubernetes™, or AWS™ environment?
Applications have evolved from massive monoliths to microservices, distributed, and dynamic architectures. Applications now live in any combination of public, private, or hybrid clouds. It complicates the firewall policy definition and the firewall’s applicability even more.
Does the firewall have the ability to decrypt different protocols, identify applications and API calls reliably, and connect application sessions to the right users or processes? – Strong in theory, but in a practical outsourced and decentralized environment, the administrator of the firewall rules hardly applies to the policies unless the customer makes a change request. Who can make and validate such a request if the traffic even goes through the firewall anymore?
I forecast that firewalls will die in the 2030s.
Hannu Rokka, Senior Advisor
5Feet Networks Oy