Software-Defined Networking: How it affects network security

You know those stodgy, oft forgotten, work forever with ne’er a complaint switches and routers scattered throughout your network? They’re about to get a well-deserved makeover, ensuring their continued status as networking’s unsung heroes. And, it’s all because of Software-Defined Networking (SDN).

What’s more, routers and switches will no longer be wimpy passive pieces of hardware, but components of a powerful proactive network — something you’d especially appreciate if you have ever been on the receiving end of a DDoS attack. Type a few lines into your computer, and the network you are controlling alters appropriately, sending all DDoS traffic into a black hole.

Some networking-speak

I was told if I wanted to understand SDN technology; I’d need to comprehend “Control Plane” and “Data Plane” as networking concepts. Seems like a good place to start. When talking about a router or a managed switch, firmware developers often separate the device into Control Plane and Data Plane functions similar to the following slide (courtesy of Wiki at NIL .com).

The Control Plane is the brains of the outfit. As shown above, the router receives information from surrounding routers, and network administrators. The Control Plane’s electronics continually process the incoming data, passing appropriate instructions to the Data Plane’s forwarding table.

I liken the Data Plane to a traffic cop, dutifully directing each packet to the right exit ramp. Something to remember, all traffic entering the Data Plane is only passing through on its way to a remote location.

Software-Defined Networking

Leaving routers and switches alone used to be an okay thing. They would just work, pushing traffic down the road. In today’s very mobile digital world there are many more kinds of traffic (latency-sensitive video, for example), so the “one size fits all” is no longer acceptable.

Getting rid of the “one size fits all” scenario has been the quest of a Stanford research team since 2008; their solution is OpenFlow Switching. These videos will give you a good idea of how OpenFlow easily alters a network’s configuration to fit “any size.”

Remember my going on about the concepts of Control Plane and Data Plane? Here’s why. In OpenFlow, the researchers physically pulled the Control Plane function away from the switch, moving it to a PC-based application (courtesy of OpenFlow.org).

OpenFlow enables networks to evolve, by giving a remote controller the power to modify the behavior of network devices, through a well-defined forwarding instruction set.

I wanted to dig into SDN, its future, and its potential a lot deeper; so I asked Sarah Sorensen, author (The Sustainable Network) and principal at Sorensen Consulting, for her opinion. Besides her consulting practice, Sarah writes extensively on SDN technology, and how SDN provides unique network solutions.

I started by asking Sarah to describe what SDN meant to her:

Sorensen: Over the past few decades, we have seen immense innovation on the application-side (think Facebook, Google+, and Salesforce) however, the underlying network has remained basically the same.

SDN tackles the barriers (complex and proprietary networking devices) that inhibit scale, automation, and agility: by separating the forwarding layer (router/switch/network device) from the control layer (network OS, which provides a central view and control over the network) and the application layer (business/software apps).

Next, I asked Sarah why SDN is considered a disruptive technology:

Sorensen: This architecture, combined with open easily-programmable interfaces makes it simple to mix and match solutions from different vendors, create custom management apps, and develop new capabilities. It gives you choice, speed, and agility — all good reasons to be excited about SDN.

I mentioned to Sarah that most of the material I found about SDN was in academic papers, and the only working model I knew of was at Stanford. I wondered aloud if SDN was still in development stage:

Sorensen: It’s true a lot of the bigger deployments are within research environments, for example Stanford, Berkeley, and Indiana. You can check out this website for a comprehensive list of SDN projects.

There are some SDN pilots in telecom-research networks: NEC and Ericsson come to mind. Google has gone public about their inter-data center SDN deployment. I would say most organizations are still trying to figure out where SDN technology potentially fits in their environment.

Is SDN good for security?

Getting the SDN basics squared away, I began to understand the opportunities referred to by security gurus. For example, SDN technology will simplify extending VLANs (network segments) beyond the building perimeter, increasing the chances of data remaining secure.

Another security challenge that SDN technology can help with are nebulous network perimeters. Vague boundaries make it impossible to determine where to deploy security devices such as firewalls. SDN technology can help by allowing administrators to route all (internal and perimeter) traffic through one central firewall. An additional benefit of network traffic flowing through a single point, it facilitates real-time capture and analysis of IDS and IPS data.

SDN’s weaknesses

Once again, I’m reminded that “convenience comes at the price of security,” after reading Roy Chua’s interview with Phillip Porras on SDN Central: “SDN Security — An Oxymoron.”

I listen to what Phillip has to say; his knowledge of IT security impressed me when I was writing about the BLADE project back in 2010. Phillip is currently Program Director of SRI’s Internet Security Group. Needless to say, I quickly reintroduced myself to Phillip wondering the whole time why SDN security is an oxymoron.

To get a flavor of what Phillip thinks about the security of SDN, particularly OpenFlow, here’s a quote from the interview:

I think the state of OpenFlow security is very immature and would not recommend OpenFlow in highly sensitive network.

Further, in the interview, Phillip elaborates:

[T]here are two sides to this coin: a critical analysis of the security challenges posed by SDNs, and the exploration of potential new defensive capabilities that SDNs may enable. I expect more work will be published (this year) discussing the underlying insecurities that must be address in the OpenFlow stack.

I asked Phillip if he was concerned about any issues other than OpenFlow. Phillip emphasized what I alluded to in the beginning. Existing network devices are as close to bulletproof as you can get — offering five-nines in up time. SDNs will have to live up to that standard or they will not make a dent in the networking market.

One area of concern mentioned by Phillip was the connection between the controller and the network devices it communicated with. If you remember the earlier slide, the interconnection was SSL Ethernet. If that fails or becomes compromised, the network does not just lose the connection to the controller — the network goes down.

I wrote earlier that one of SDN’s cool abilities was diverting a DDoS attack. I thought it best to ask Phillip if he agreed with the SDN Central article mentioning Radware’s SDN application, anAdaptive DDoS Protection Solution?

The potential exists that SDNs offer greater dynamic reprogramability of network flows, and greater flexibility in restructuring a network under significant flooding. I find this aspect of OpenFlow very intriguing.

Phillip then added an example of the other side of the coin:

Unfortunately, SDN also introduce new potential security challenges. For example, one could imagine an adversary who attempts DDoSing the SDN stack itself. Rather than flooding routers or attacking the hosts or applications, an adversary might craft traffic streams simply to increase the interactions between the switches and the controller, i.e., a Control Flow saturation attack. We outline such an attack in our FRESCO paper at NDSS 2013.

Phillip then spent some time explaining the real security advantage that SDN affords. For longer than most would care to admit, the only way to fight exploits was blocking the attack. With SDN, many other responses are available: including reflector nets, quarantine systems, emergency broadcasts, tarpits, and advanced OpenFlow-enabled honeynets.

Final thoughts

The advantages and conveniences of SDN technology are numerous and more than a little exciting to those responsible for network administration. My question then becomes: Is it enough so to garner wholesale adaption of SDN?

I’m hoping Sarah, Phillip, and other SDN experts will make sure SDN works as well if not better than the stodgy, oft forgotten, work-forever routers and switches that helped get this article from me to you.

For an interesting infographic about SDN, check out Software-Defined Networking revolution, provided by the Open Networking Summit.