In today’s world filled with cellphones, tablets and other smart devices, operators are on the hot seat to manage network services quickly in order to avoid a slow and overloaded network. Software-defined networking is generating a lot of attention, mainly as a tool to provide the flexibility and programmability needed to do just that. While the hype around its possibilities is here, is SDN ready for primetime? Technically, yes. But there is a problem, which isn’t related to the technology but rather with the people who must manage this change.
The enterprise network has been dominated by trusted OEMs that provide full support for their equipment with its complicated embedded software. SDN helps the network break free of this dominating vendor lock-in by offering bare metal switches, which have the programmability to control and change various parts of the network in order to offer increased flexibility to the network operators. But this process also shifts the ownership of network solutions from the OEMs that designed the software and hardware of the traditional network to the operators, presenting operators with a new area to manage, new responsibilities and a whole new set of programming rules to learn.
This puts added pressure on the operators and carries a lot of risk for them, making the value proposition for SDN less clear. While particularly true for the enterprise, many telecom carriers and cloud data centers are already making adjustments to change their business models accordingly. Many enterprises are seeking ways to reduce the risk by looking for software that will manage their SDN for them. But this creates the same vendor lock-in that SDN is seeking to eliminate. Instead, the industry should work together to create a way for operators to fully control the network within an interface that they are already familiar with. Then, while an SDN expert might be required to deploy an SDN system, an easy-to-use interface could be used to control the network’s behavior. This places operators firmly in control without requiring them to learn an entirely new programming skill set or to hire a fleet of SDN experts.
Solving these SDN adoption issues likely involves restructuring IT boundaries and an emergence of trusted software solutions in order to enable operators to regain control of network configuration in light of their newfound hardware independence. Doing so will be well worth the effort as the network’s programmability and flexibility allows companies to deploy new services, eliminate slow traffic and create a better user experience for both employees and customers.
The security issue
Open source SDN could be scary. Especially after Heartbleed, Shellshock and the recent FREAK scare, people are understandably leery of the security of open source. There is a bit of a mystique that opening up the software programmable interface to anyone who wants to come in and code makes the code vulnerable and open to manipulations.
In reality, an open programming model, like the one being embraced by the Open Networking Foundation, is actually more secure, particularly in the context of SDN. SDN provides the ability to recognize and pinpoint a problem quickly and then quarantine and apply measures to address it. In a threat environment that’s constantly changing, one needs a network that can evolve as fixes are made while also staying ahead of conceivable future threats.
Increased visibility into the code base also makes it easier to address issues. While it would be ignorant to say there isn’t a potential for problems like those associated with FREAK and other vulnerabilities, it’s difficult for me to believe that these were deliberately architected into the software without anyone noticing. We all know that one of the key advantages of open source is that someone is always watching the code and keeping everyone honest. Instead, I believe that these vulnerabilities were simply an oversight that the bad guys found and exploited.
On the contrary, when a hole is exploited in a fixed system, it’s a lot harder to address the problem. It’s hard to update the embedded software, so if a problem arises, there really isn’t a quick way to stop it. Because SDN infrastructure is not fixed in time, there’s increased flexibility to fight attacks. As an example, it wasn’t too long ago that the U.S. and Chinese governments were trading accusations about whether one had built deliberate backdoors into the networking equipment being bought by the other. While the truth of these accusations is a discussion for another time, the bare facts are that in a traditional network, this sort of deviousness is very possible.
In a flexible and programmable SDN network, on the other hand, one can break the linkage between the software and hardware vendors. One can run whatever software one wants, choosing the amount of visibility one wants to offer into the software and deciding how much one trusts that software to not have built-in backdoors. Or one could even go into the software itself to close any vulnerabilities one might find.
SDN holds a huge potential to increase network security. Due to its open, flexible, programmable nature, it may not seem secure on its surface, but beneath that façade is the ability to find and close security vulnerabilities quickly and easily, particularly when compared to traditional, fixed networks.
Editor’s Note: In an attempt to broaden our interaction with our readers we have created this Reader Forum for those with something meaningful to say to the wireless industry. We want to keep this as open as possible, but we maintain some editorial control to keep it free of commercials or attacks. Please send along submissions for this section to our editors at: dmeyer@rcrwireless.com.
