Art of the abstract

Software-defined networking promises extraordinary benefits but can be risky, as Fleur Doidge discovers

The problems of networking are problems for many customers. Abstracting the software layer, decoupling the control plane from the data plane, promises a leap forward for the sector that will hopefully bring networks - and network management - more into line with other developments in IT.

Currently, most networked devices require individual management or even the use of manual processes, so the time is surely ripe for solutions that are defined by the software, rather than fixated on the hardware used. It's about achieving more agile and dynamic computing.

Also, it should be relatively easy for the channel to get a piece of the action, not least because start-ups focused on SDN continue to be snapped up by major OEMs including Dell and HP - meaning partners are well placed to capitalise on existing relationships, with some skill augmentation. The market is already expanding, and has multiple facets.

Gartner has named SDN one of its top 10 tech trends for 2015. And for another example, Infonetics Research this month predicted that North American sales of SDN and network function virtualisation (NFV) hardware and software aimed at carrier networks will reach $11bn (￡6.9bn) by 2018, having estimated previously that sales of datacentre and enterprise-focused SDN controllers and switches alone will tip $9.5bn by then.

Revenue from SDN controllers and switches in 2013 was up 192 per cent year on year, and white-box bare-metal switch deployments by web-scale giants including Google and Amazon have been surging. As Cliff Grossner, directing analyst for datacentre, cloud and SDN at Infonetics, says: "There is no longer any question about SDN playing a role in datacentre and enterprise networks.

"The early SDN explorers - NEC in Japan and pure-play SDN start-ups in North America - were joined in 2013 by the majority of traditional switch vendors and server virtualisation vendors offering a wide selection of SDN products."

There could be trouble in paradise, however, as for all the benefits touted by those who are keen to get customers adopting SDN as fast as possible, there are risks as well. SDN, like most of the latest tech evolutions, is both an opportunity and a serious threat.

It is not news that risks exist - in fact they can be expected to worry users and exasperate the administrators of any IT system - but with SDN the stakes may be raised even higher as the very advantages of being software-defined are, in essence, what increases the risk.

In other words, controlling and centralising everything with some code is convenient to use, but also more convenient to compromise - especially when built on hypervisors, which are themselves eminently hackable.

Security holes
Gregory Pickett, founder and head of cyber security operations at Chicago-based managed security services provider Hellfire Security, gave an impressive one-hour demonstration at Black Hat Europe this year of just how easy it can be to break SDN using leading types of controllers based on the emerging standards and protocols.

"Yes, amazing things are possible with SDN, and we have only just scratched the surface," he told delegates. "SDN has the potential to turn the entire internet into a cloud, the benefits of which would be orders of magnitude above what we see now.

"But there is a hole in the middle of it that could easily be filled by the likes of the NSA or, worse yet, nation states."

The OpenFlow protocol has, he says, weaknesses in its latest iteration, which allows less-secure TCP traffic instead of requiring Transport Layer Security (TLS).

Of two leading controller platforms, Opendaylight and Floodlight, only Opendaylight supports TLS but does not require it, and most switch vendors do not support TLS. This means that most enterprises will thus be unable to use TLS even if they want to, Pickett says.

"With the exception of one [vendor], those that do support TLS aren't implementing the authentication. So while conversations with the controller may be private, anyone can have one - leaving that very same controller open to being attacked by a node able to reach it," he explained.

Dependency issues
Most enterprises adopting SDN currently are vulnerable to data leaks via man-in-the-middle attacks, because they don't have matching TLS-supporting controllers and switches.

They are also vulnerable to denial-of-service attacks due to the lack of TLS, and because those that do have it won't have any authentication - because vendors haven't implemented the standard.

Centralisation entails dependency, notes Pickett: "And this dependency can be easily exploited. So it is important to see how vendors are handling it. So far, they aren't handling it very well."

Floodlight can be relatively easily taken down through traffic floods, as experiments have shown and the DoS vulnerability of Opendaylight - supported by Cisco, HP, IBM, Citrix, Red Hat, Ericsson, Brocade, Juniper and Microsoft - is unknown but rather doubtful.

"It is worth investigating. It is Java, for God's sake!" says Pickett.

He says you can gain control of a Floodlight network directly, because its northbound HTTP API has no encryption and no authentication. Opendaylight has northbound encryption turned off by default and only HTTP Basic Authentication, with a weak default password, and strong passwords turned off by default.

"Despite having some controls in place, they are weak and easily bypassed by exploiting one of the controller's other listening services," he says.

Gaining access to Opendaylight can be a little tricky but "honestly not that hard". Southbound APIs on Opendaylight include TCP-based XML-RPC service Netconf, which uses no encryption nor any authentication and is run by Java, he explains.

Topology, flow, and message modification are all possible through unauthorised access. "Attackers will be able to add access, remove access, hide traffic, and change traffic. Nasty stuff, indeed," Pickett says.

He also detailed a variety of other potential routes for attack using these controllers.

"So the question you have to ask yourself is are the other controllers out there any better? You'd better make sure before you put one of them into production," he says.

According to Pickett, solutions could be developed and they must be, if SDN is to realise its - currently somewhat abstract - promise for organisations of all sizes. Manufacturers need to "step up" and finish implementing TLS as required by the standard.

"And this means implementing all of it including authentication. It wouldn't hurt if the standards body moved back to requiring TLS either," he says. "Next is hardening; these boxes need to be hardened like any other."

He added that he found it difficult to believe that either Floodlight or Opendaylight had been through proper code review. "These vulnerabilities are just too basic.

"It will take forethought by those designing and deploying SDN to make the future of SDN a safe one," says Pickett.

THE BIG BENEFITS OF SDN
■ Supports more data-intensive activities (big data analytics, virtualisation)
■ Greater visibility of the network and all resources
■ Centralised provisioning of the network, detaching management from individual devices
■ Less reliance on specific hardware, repurpose and adopt commoditised versions
■ Increased flexibility and adaptability of the network; scale up and down more easily
■ Resultant potential cost savings through streamlining and centralisation while supporting more complex and intensive IT environments