Ensuring securing for SDN
Software-Defined Networking (SDN) is a new approach to building networks; previously hardwired network topology gets replaced with a software implementation. For large-scale networks (think “cloud”), the additional flexibility and efficiency make all the difference in the world.
Within Software-Defined Networking, one trend is to move data using off-the-shelf, generalist server processors rather than specialized integrated circuits (ASIC). Again, to much flexibility and efficiency even within the spectrum of SDN solutions.
The security-sensitive, however, may be concerned with the loss of the security that was implicit in the relative inefficiency of the old ways. When the only way to adjust the routing requires physical access to a room of switches, security is “enhanced” as a consequence of this very limitation.
The new programmable ASICs for Software-Defined Networking may be susceptible to attacks that previous, dumb ASICs were impervious to by virtue of being dumb. And of course, generalist processors can run arbitrary code, expanding the possibilities for unintentional failure and malicious appropriation.
How do you make sure that the software works in Software-Defined Networks?
TrustInSoft verified safety properties for part of an Open-Source software component found in many SDN switches, the DPDK framework from dpdk.org. The Git repository reveals that the main contributors are leading SDN companies such as Intel or 6WIND. The perimeter of the study was the testpmd application, plus the parts of the DPDK library exerted by testpmd. The verified properties were the absence of undefined behaviors, including all the memory errors and integer overflows that are at the root of many bugs and security vulnerabilities.
The few defects found were minor in the extreme, and still the code-changes to fix them were well-received by the DPDK community. Interestingly, with the help of TrustInSoft Analyzer to make sense of this very specialized code, Julien was also able to identify a minor optimization opportunity in this code already written with an eye towards performance. But the important fact is that since the study, carried out to completion, did not identify any Heartbleed-like memory error, no such errors exist in testpmd.
So, then, how do you make sure that SDN software works and is secure? We think that one natural step is to extend the analysis initiated by Julien to the rest of DPDK, and then to the other software components of an SDN device, using TrustInSoft Analyzer. Not to mention other software layers that are critical to the network’s security.