High-speed programmable switches enable efficient in-network defences against cyberattacks. Unfortunately, many existing switch-based security applications are themselves vulnerable to attack, due to the compromises necessary to work within the constraints of today’s packet-processing hardware. Further advances are needed before we have efficient switch-based services that can withstand sophisticated adversaries.
Network operators need robust and efficient ways to protect their networks from cyberattacks. Dedicated hardware middleboxes such as firewalls and Intrusion Detection Systems (IDS) are the conventional choice, but they lack scalability and flexibility. Plus, managing a number of middleboxes also involves high operational and capital costs. Emerging programmable hardware switches offer an appealing alternative.
Unlike traditional fixed-function switches, programmable switches enable operators to develop and deploy customized, high-throughput in-network applications (for example, up to 12.8Tbs on the Intel Tofino2 switch) using high-level programming languages like P4. A single programmable hardware switch can serve multiple security and non-security applications like routing, greatly reducing hardware costs.
Researchers have leveraged P4 and programmable switches to support a diverse set of security tasks (such as firewalls, IDSes, and DDoS mitigation). In particular, researchers have demonstrated the feasibility of porting conventional end-host-based security solutions, such as host-based spoofing detection, to programmable switches. Running at the border of a network, programmable switches have the potential to provide the same security benefits as those end-host-based security solutions, to all hosts in the network at high speed, without modifications to the end-hosts and without deploying dedicated middleboxes.
Programmable switches seem to be a promising building block for developing performant and flexible security applications. However, before embracing this technology, we must understand the limitations.
The design space of programmable switch-based applications is quite different from that of traditional software systems, due to the switch’s limited memory and processing resources and its restricted programming model. For example, a programmable switch should only process each packet once through its processing pipeline to guarantee line-rate performance. This limits the number of allowed operations, therefore some common operations (loop, multiplication, and so on) and cryptographic functions, which serve as the foundation for security applications, are not available.
To cope with these constraints, switch-based applications tend to make certain compromises to maintain high performance. For instance, since the switch does not offer a secure hash function and implementing such functions in the switch can be expensive, an application may use a weak, easy-to-implement hash function instead. The security implications of these commonly made compromises in switch-based applications are, unfortunately, understudied. This leads to the question: Are switch-based security applications secure enough to be used in real-world networks?
Let’s look at an example.
Switch-based SYN Proxy
SYN proxy is a defence against TCP SYN flood attacks. In Figure 1, the SYN proxy responds to a SYN with a SYN-ACK, in which the initial TCP sequence number is a challenge — SYN cookies — generated by a secure hash function. If the ACK (for SYN-ACK) sent from the client contains the correct challenge, the proxy allowlists the corresponding five-tuple and forwards packets back and forth between the client and server. Compared to software-based SYN proxies, a SYN proxy implemented on the modern programmable hardware switch can easily keep up with the attack traffic of terabytes per second.
A secure SYN proxy should make sure the generated SYN cookies cannot be easily forged by the adversary. In Linux, SYN cookies are computed using two rounds of SipHash, a lightweight secure hash function. Unfortunately, implementing secure hash functions on the current generation of programmable switches is challenging and may require sacrificing performance.
A quick workaround is to replace hash functions with CRC functions, which are the built-in primitives in programmable switches. Two known switch-based SYN proxies (as seen here and here) have been implemented in this way. Furthermore, in both SYN proxies, cookies are computed as a function of source and destination IPs, ports, and a constant N, where N is reused across all flows for a given time epoch — the justification is that the switch avoids maintaining per-flow state in this way and achieves better performance.
Consequently, the adversary, who can craft arbitrary packets and observe the corresponding cookies generated by the proxy, can easily recover the exact CRC function and the constant N a switch-based SYN proxy is using, and thus compute the correct cookie for any given spoofed five-tuple to evade the proxies.
We do not want to undermine the security benefits provided by the two SYN proxies. The two SYN proxies indeed mitigate TCP SYN flood attacks launched by a ‘naïve’ attacker who has little insight into the proxy design. However, an ‘adaptive’ attacker that understands how the proxies work, can exploit the issues discussed above to evade the proxies. The attacker can recover the cookie-generation function and send extra packets to allowlist every spoofed IP.
Beyond SYN proxies, we examined five more switch-based security applications and all of them are vulnerable to either evasion (evading attack detection by the application) or disruption (exploiting the system to disrupt other users’ traffic) attacks under their original threat models.
Despite providing certain security and performance benefits, these security applications are not deployment-ready, considering the adversarial context in which they would need to operate. Please see our paper for more details.
Improving the status quo requires multifaceted efforts:
- Developers should perform more rigorous security analysis when developing applications.
- The networking research community should develop more security testing tools (for example, fuzz testing), and reusable, open-source reference implementations of common security building blocks.
- Equipment vendors should offer essential cryptographic primitives in their next-generation programmable switches.
As people begin to pay more attention to the importance of security and programmable switches become increasingly powerful, we believe more practical and deployable switch-based security applications will be developed in the foreseeable future.
Liang Wang is an Associate Research Scholar at Princeton University. His research interests include Internet security and privacy, with recent topics including PKI and BGP security, and security applications of emerging technologies.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
The article makes some good points, the main one being “Do not try to use the hardware for the applications it is not suitable for”.
Having said that, it is not clear how useful this point is: one can easily come up with tons of use cases for which one wouldn’t want to use a high-speed P4-programable switch that doesn’t offer crypto. So what? Wouldn’t it be more productive to discuss the cases where it is actually useful?
Have there been a real case where someone actually tried and deployed such a code that is being described in the article? Even if they did, who would be at fault: a P4-programmable device or an engineer who didn’t understand its limitations?
Overall, the post leaves me with the feeling that the author tries to sensationalize a trivial finding at the expense of putting down very capable devices or even the concept of programmability. For example, the author neglects to mention that no high-speed switching devices operating at Tbps speeds offer cryptographic hashing or allow pipeline loops, no mater whether they are programmable or not — it is just “the nature of the beast”.
I would recommend taking this article with a BIG grain of salt.
Thank you for your interest in our blog post. We agree that no high-speed switching device offers crypto primitives; that is indeed the nature of the beast. We want to clarify that we do not advise against the use of programmable hardware for security applications; in fact, we believe performant security applications are feasible, even with restricted switch hardware. The goal of our paper is to call for more rigorous system design and security analysis, given that practitioners may overlook or misunderstand the hardware limitations, resulting in applications with unexpected security vulnerabilities. It is crucial to understand a system’s security ahead of deployment. Importantly, we hope our paper can draw attention to the topic “HOW to design a practical security application with P4 switch”, which will be useful for broadening the practical use cases of P4; this serves as part of our effort to boost P4 and in-network computation rather than disparaging them.