CenturionStudio.it - Fotolia
While vendors are actively productizing SDN, and analysts predict solid uptake by 2016, most enterprise network engineers say they won't be ready for SDN investment until a few key concerns are addressed.
A group of IT leaders interviewed for this article cited concerns ranging from diminished security performance to a lack of SDN standards, which will prevent them from recommending SDN investment, at least in the short term.
SDN investment concern No. 1: Security and monitoring performance
IT staff are first and foremost fearful that security monitoring will suffer when the SDN stack jointly meets the hypervisor and the physical infrastructure.
Ben Rothkeinformation security manager at a major international hospitality firm
"Before we see SDN adoption for mission-critical and secure environments, vendors need to work on how the SDN software stack interfaces with hypervisors in cloud environments and at the virtualization layer," said George Magklaras, senior systems engineer at the Biotechnology Center of Oslo.
Today, when IT sends a series of bytes down a network path using a Juniper device, there are static checks that make it difficult for attackers to run malware to create information leaks. "That is not true when you are talking about the same scenario using cloud stacks and hypervisors," Magklaras said.
Will IDS/IPS work in an SDN environment?
Magklaras is also a chief consultant at Steelcyber Scientific, where he implemented an SDN pilot for a large financial organization, only to see security performance suffer, particularly when it came to IDS/IPS.
Magklaras' team placed an OpenDaylight-based SDN controller in an environment with Cisco and HP hardware. "We had the responsibility of overseeing a pilot migration of about 60 VLANs to OpenDayLight [control] using an OpenStack private cloud model," said Magklaras.
Problems arose with network monitoring for inbound and outbound IDS/IPS systems, he says. IDS/IPS works by tapping into a range of ports, or a particular port, to replicate the entire traffic of a VLAN or network segment for sniffing. Traditional switch hardware and software replicate that traffic and serve it into the IDS/IPS system. In contrast, SDN uses a hypervisor and general OS routines to replicate the traffic.
"The tests we performed on a variety of IDS/IPS systems showed that SDN loses approximately 25% to 30% of the attack vector events. We attribute that to the SDN software stack being slower to replicate traffic on ports and also dropping Ethernet frames/traffic," Magklaras said.
Problems tracking MAC addresses
Magklaras' team also found a problem in tracking MAC addresses for devices that were connected to the wired and wireless networks. "Many of the recorded MAC addresses were not correct due to faults in the SDN software," said Magklaras. "The SDN software was dropping MAC addresses in congested network segments [due to problems with PXE boot], and SDN even corrupted the MAC addresses in its software registry," he explained.
The hypervisor as a security weak spot
During this testing, Magklaras found that in some circumstances, attackers could tap hypervisors to see network traffic that shouldn't have been exposed.
Once hypervisor security is circumvented, an unauthorized party could use root permissions to tap into the VLANs, he explained.
VMware and others are working to address security concerns, but the "vulnerabilities are still not closed," explained Magklaras. "That is why we find it difficult to recommend SDN stacks to financial organizations and other customers. We know that it will eventually save them money and it will be the way to go, but for now we must be cautious."
SDN investment problem No. 2: Proving automation and DevOps work
Much of the excitement about SDN has centered on its ability to make policy-based decisions about traffic based on its source or destination from a centralized control point.
But SDN also promises automation and dynamic provisioning -- and this is much more of a concern to network pros. Specifically, network engineers want to be able to use SDN for DevOps and to create a framework that ties together heterogeneous vendor hardware using an engine to automatically turn up service for customers. They're not likely to invest in SDN until they can prove this is a reality, according to Christian Teeft, CTO of cloud provider Latisys.
"Latisys has leveraged some of Arista Networks' capabilities to do some phase-one orchestration and automation of provisioning. The reason more organizations aren't doing that is because they lack the resources in DevOps to take their existing provisioning systems to that level," said Teeft.
SDN challenge No. 3: A lack of familiarity
Networking pros read plenty about the benefits of SDN, but they haven't seen the dynamic infrastructure in action. Meanwhile, their existing environments are well defined, and engineers have their own established methods of accomplishing networking tasks. Those methods may be time-consuming, but they work.
"Network engineers need to be able to accomplish the same things with SDN that they are used to doing with known hardware and software combinations," said Magklaras.
Until they get their hands on SDN technology and make it work for their individual needs, network pros won't invest.
"Our network engineers need to understand how SDN will meet the specific needs of their customers," said Jason Parry, VP of Client Solutions at Force3 and previously manager of network engineering at SafeNet Inc.
"SDN is still new. It's a change in how we deploy, manage, support and configure networks. The promise of SDN is network automation, orchestration and new efficiencies. My network engineers need to see SDN prove itself in that fashion," he said.
SDN investment concern No. 4: No standard SDN or skill set
For engineers to get to know SDN, they need new skills, but they're not necessarily sure where to start, since it is unclear which SDN strategies will stick.
"Network engineers want to understand how SDN impacts their existing skill sets," said Parry.
Engineers would like to see some standardization in how SDN is implemented, and then understand how that is linked to a clear skill set so they know how to adapt. Just two years ago, it was assumed that OpenFlow would be central to SDN, but now it is falling out of favor among many vendors and industry organizations.
At this point, "engineers would have to learn at least some of everything that is going on out there, including OpenFlow," said Parry.
SDN investment concern No. 5: Selling SDN to decision makers
Even once network pros and IT managers become intimate with SDN and its benefits, they'll still have to convince the higher-ups to invest, and that won't be easy.
"SDN has not taken off because it requires a massive amount of time, money and hardware. Trying to sell the board on this long-term vision is something many CIOs are not prepared to do," said Ben Rothke, an information security manager with a major international hospitality firm.
SDN is a huge infrastructure reengineering effort. "A lot of CIOs simply don't have the time, staff and money to make it work," he said. There is this feeling of "yet another network approach" to deal with, which scares people off, he added.
If there were more SDN use cases available, the technology might be an easier sell.
"SDN is defined as an emerging architecture. The key term here is emerging. It's developing, maturing, and does not seem to have a lot of large success stories," said Rothke.
Rothke said he will feel comfortable recommending SDN investment when many of his peers tell him SDN works.
"I don't need vendor white papers, webinars or breakfast symposiums. If my colleagues and peers are swearing by it, not at it …that's a fantastic way to know a technology works," he said.
Editor's note: We sent our reporter to find network engineers on Reddit who would share their thoughts on SDN -- and boy, did they! In part two of this piece, see why network pros are blasting SDN.
SDN implementation will rise by 2016, but challenges remain
Will open networking mean lower spending?
Dimension Data will train you in SDN before making a sale
Why you may not be ready for an SDN deployment.