Agencies experiment with software-defined networks
Connecting state and local government leaders
Software-defined networking is giving agencies looking to upgrade their enterprises opportunities to program and virtualize complex networks.
This article was changed March 18 to correct the spelling of Mike Haugh's name.
Science-minded government agencies and universities are exploring software-defined networking (SDN), an emerging field of technology research that seeks to liberate networking from its traditional hardware orientation.
SDN could dramatically change the way governments deploy communications systems, say computer science researchers, who see networks lagging behind servers and storage when it comes to management control and other benefits of virtualization.
Now agencies looking to upgrade their networks may have real opportunities to do so, given recent developments in using SDN to program and virtualize enterprise networks, experts say.
“SDN is exciting because it provides an architectural path forward, cutting through the complexity in networks today and providing more programmability,” noted P. Brighten Godfrey, assistant professor of computer science at the University of Illinois at Urbana-Champaign.
With SDN, software takes on networking chores normally embedded in the guts of routers and switches. In a conventional setup, the network component that determines how data will travel (called the control plane) and the part that actually transmits data (the data plane) remain locked in hardware.
An SDN, however, severs the control plane from the hardware and makes it a software function.
The upshot for IT managers? SDN’s software focus makes networks more flexible and much easier to manage, according to the technology’s advocates.
Currently, network administrators configure individual network devices to accommodate changes in network traffic patterns. SDN, in contrast, lets managers program a network’s multitude of devices from a centralized software controller.
Accordingly, the technology has the potential to reduce the amount of time it would take administrators to perform network management tasks. Security improvements are another possible upside, since admins could more readily flag vulnerabilities and program a network to deal with a particular threat.3
In short, SDN enables new ways of building more secure and more efficient networks, said Godfrey, who is working on SDN projects with National Science Foundation backing.
But while SDN appears promising, the technology is far from mainstream. The arrival of SDN-capable networking gear is a fairly recent development. Tools for managing SDNs are also relatively scarce. And while SDN could improve security, it may also introduce risks. As a nascent technology, it has yet to be fully vetted from a security perspective.
Another question mark regarding SDN: How will agencies go about implementing the new networks? An agency early adopter could attempt to introduce SDN in one fell swoop as part of an overarching network upgrade. But an incremental approach that places SDN at the network’s edge offers another possibility and perhaps a more realistic one for budget-constrained agencies.
Getting started with SDN
The technologies underpinning SDN have been under development for a few years, but most of the deployment activity has occurred since 2011. The basic setup includes an SDN controller – a software application that sends instructions to network devices – and a protocol that lets the controller communicate with those devices. The Open Networking Foundation’s OpenFlow protocol supports a number of SDNs, but other protocols can also do the job. ONF describes OpenFlow as a vendor-neutral communications interface.
SDNs are starting to appear in large commercial enterprises where networking is core to the business. They are also found among cloud providers and other carriers who have plenty of incentive to get out in front of the SDN adoption curve. Among large commercial enterprises, Google deployed SDN in its B4 network, a private wide-area network that links its data centers. Japan’s NTT Communications will use SDN in a virtual network service scheduled to debut in March.
In contrast, government agencies generally find it harder to cost-justify a rapid jump into a new networking approach and are more focused on piecemeal enterprise improvements.
Nevertheless, SDN is in play across the public sector, particularly in the energy and defense spheres. Mike Haugh, senior manager, market development at Ixia, which makes test applications for SDN and other networks, said there are now more than 100 ongoing SDN trials, some of which are in the government space.
The Department of Energy is exploring SDN through the agency’s Energy Sciences Network (ESnet), a high speed network linked to 30 major DOE sites and over 100 other research and education networks. Other current public sector work with SDN tends to be focused in universities, with support from the NSF.
Researchers contend that SDN provides an opportunity for improving network manageability and security in complex, ultra-fast networks. Some of these networks are so complex, in fact, that
operators lack confidence that changes made to a network -- a small tweak to add a new tenant or an alteration to a security policy -- will have the right effect networkwide.
“It has become an inhuman task to understand what the network is really doing,” University of Illinois’s Godfrey said.
To address the difficulty of managing its networks, the University of Illinois is using a tool called VeriFlow, which confirms security levels and ensures interdependent components of a network are working properly. NSF backed the project along with the National Security Agency.
The VeriFlow software runs at the SDN controller, where it observes changes in instructions to the network. The software checks each change in real time and determines whether a change is going to have an adverse impact on the network, such as imposing a critical security flaw. If that’s the case, the change is prevented from going to the network, Godfrey said.
When university researchers used VeriFlow in pilot deployments, they uncovered inconsistent security policies along with other errors and security vulnerabilities, Godfrey said.
SDN’s security upside
Eric Chiu, president and founder of HyTrust Inc., a Mountain View, Calif., company that focuses on cloud security automation, suggested that SDN can also improve cloud computing security. “[SDN] can enable great security benefits, primarily around network and endpoint security automation and making them dynamic to meet the needs of changing cloud environments,” Chiu said.
With SDN, security policies can automatically follow virtualized workloads wherever they are located, he said. And delivered as a virtualized resource, security can be spun up on the fly as the cloud scales up and then spun down when the cloud scales down. SDN takes virtualization a step further, Chiu said, “by enabling the automated deployment of networking and security services without a tremendous amount of human interaction.”
On the security front, SDN could also provide a more flexible, on-the-fly reaction to denial-of-service attacks and other security incidents, said Inder Monga, chief technologist and area lead for ESnet.
At Energy, SDN is also seen as a means to improve network utilization. One ESnet demonstration project, for example, used OpenFlow to match large data flows to the most efficient network tier. This network management technique becomes particularly important for moving enormous scientific data sets around a network. SDN, for example, can identify a large data flow and send it to a network’s optical transport layer, Monga said.
For others, SDN benefits go well beyond network management. “It’s just that you can innovate much faster,” said Deniz Gurkan, an associate professor of computer engineering technology, at the University of Houston. SDN’s programmable software allows for much quicker development than attempting the same innovation in hardware.
Gurkan’s research focuses on creating network debugging tools using SDN technologies. The tools will be built for use on current networks, not just SDN-enabled ones. The idea is to deploy SDN technology on networks as they exist today. “We cannot really overhaul the network to become SDN overnight,” she said.
SDN security trade-off
Although security is a considered a potential benefit of SDN, it carries some weaknesses too, according to researchers.
An SDN program review, hosted late last year by Energy, NSF, and the Networking and Information Technology Research and Development Program, noted that the security of SDN needed additional R&D, according to Monga.
One vulnerability stems from the SDN’s centralization of control. “SDN concentrates risk given that [it collapses] traditional, physical systems, networks and data onto a single software layer, which leads to a single point of failure and attack,” Chiu said.
“All your eggs are in one basket, so to speak.”
This is similar to what happens with virtualization and cloud infrastructure, Chiu noted. Consequently, organizations adopting SDN will need to pay special attention to securing the SDN controller, a measure that becomes critical for addressing the concentration of risk and the potential for catastrophic failure.
Chris Wright, senior principal software engineer for open software developer Red Hat, came to a similar conclusion. “If you have a logically centralized controller in your system, that becomes a point of interest for an attacker,” he said.
To bolster security, Wright said adopters need to make sure data traffic between the controller and the devices managed on a network takes place in a segment of the network not immediately accessible to an end user. The control plane traffic should remain on an administrative portion of the network, rather than traversing the same network that is providing bandwidth for applications.
“We need to be really clear on what the security threats are to this new model and just engineer around those,” Wright said.
Another SDN hurdle is a lack of management tools, which the program review identified as an important gap. “Vendors are focusing on building the product set, but the people who manage networks need not just the product set but a set of tools to be able to manage that,” Monga said.
SDN equivalents of such common diagnostic tools as traceroute have yet to emerge, Monga said, noting that some academic work and startup activity has taken place in the SDN tool space. But, for the most part, the tools network managers need either don’t exist or aren’t sufficiently mature to help run an operational SDN, he said.
Monga said the SDN program review participants discussed building a prototype to explore the architecture’s shortcomings in greater detail. The network, if it were to be built, would operate along the lines of ARPAnet, the predecessor to the Internet, to help government and university network managers gain experience with SDN and to flag security and management issues, Monga said.
Deployment strategies
A test network could also shed light on how to go about deploying SDN, a matter of some debate at the moment. “That is a question we ask everyday,” University of Houston’s Gurkan said.
The deployment method would depend on the type of organization planning to adopt the architecture. An organization with a rigid networking structure and well-defined layers of racks and switches in a single data center may be in a position to pursue an all-at-once SDN deployment, Gurkan said.
An SDN transition isn’t nearly as simple for an enterprise-style network such as a campus environment, Gurkan added. A campus network involves multiple departments, each with its own IT managers and bandwidth needs. One department may need to transmit petabytes of data over high-speed links, but it would prove costly to design an entire network to support such volume.
Another deployment consideration: single vendor versus multi-vendor solutions. Today, many SDN deployments are vertically oriented, single-vendor affairs. Haugh said this situation is due to the limited number of SDN applications available.
“If you choose an OpenFlow solution from vendors like NEC, HP, Cisco and others, they offer the applications, controller and network layer switches,” Haugh said. “The other issue is that most have slightly modified OpenFlow, so they would need other vendors to work with them.” OpenFlow conformance testing will help improve interoperability and limit vendor-only features, Haugh added.
The multi-vendor OpenDaylight Project, a Linux Foundation project that aims to boost adoption of SDN, is also stepping into the SDN arena with an open platform for network programmability. The project last month announced its first open source software release, an offering dubbed Hydrogen, which includes an SDN controller and OpenFlow plugin.
SDN has yet to fully mature, which means agencies can expect further technology approaches and product offerings to emerge, say networking researchers. And while the technology may yet become the standard for virtual networking, the way there is far from settled. “I would say that this area is still innovating in leaps and bounds,” Monga said. “It is very exciting, but it makes it harder to give an accurate prediction on how this market is going to evolve and how this is going to play out.”