Security

Software-Defined Networking: How it affects network security

SDN technology is set to rewrite the book of networking. Michael P. Kassner looks into how SDN will improve security, and where it's vulnerable.

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, an Adaptive 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.

About

Information is my field...Writing is my passion...Coupling the two is my mission.

21 comments
Michael Kassner
Michael Kassner

Phillip mentioned a few in his responses -- OpenFlow and the possibility of DDoS on the controller. It may be that this is so new that there is no real production app to check for vulnerabilities. I will ask Phillip for his thoughts.

stelellico
stelellico

What about Security implications?

paulgauzens
paulgauzens

Existing manufacturers are not rushing to embrace standards-based open control plane codesets for good reason. Standards tend to flatten capability to the common denominator - in other words that which the "committees" will approve. The proprietary devices will continue to proliferate as long as there is plenty of innovation in their offerings.

ES-ES
ES-ES

I thought products like Enterasys were building this type of controls into their switches already in production. It was my understanding that they have had this type of control in place for years now and in the education market that is one of the reasons they have such traction.

JCitizen
JCitizen

but curiously I see now how HP's widely hyped cloud service offerings may be working. The only difference is, that this is WAN router/switching technology; and the new cloud infrastructure is more an isolated instance of computing/networking inside a host cloud service. What I mean is that the way the new Atom architecture is communicating in a similar manner inside the rack space. HP announce a highly touted change in how their server architecture is going to work, and an emphasis was placed on not just the hardware but the software running the show. I know these are two distinctly different subjects, but now I think I understand what HP's CEO was talking about now. Apparently the new hardware was proposed years ago and HP is finally taking the leap to remain competitive in both hardware design and software service. Is it just me? I think too much!! ?:|

Igal Zeifman
Igal Zeifman

Interesting read but I have to agree with Phillip - security wise, SDN needs more polish. Also, I thought that SDN's anti-DDoS capabilities are over exaggerated. "Type a few lines into your computer, and the network you are controlling alters appropriately, sending all DDoS traffic into a black hole..." Dumping/deflating malicious traffic is often not as challenging as identifying it and filtering it out, while still delivering content to the legitimate visitors. (http://www.incapsula.com/ddos/how-to-prevent-ddos-attacks) Yes, SDN allows dynamic traffic routing, but so do other existing solutions (i.e. anycast) so it brings little to the table, but adds yet another critical-resource that can be targeted by a would be attacker. Still, interesting potential.

robo_dev
robo_dev

Remember hardware has software baked in; software and hardware can have security flaws that can be exploited. In order for something to be attacked, it needs to have some attack surface. Is a properly hardened firewall running on a unix server less secure than a firewall running on hardware? The answer is 'it depends'....how well each platform has been hardened, how well things have been tested, and how much, if any attack surface exists on the platform. In this case we would assume you would not leave the SDN controller layer exposed to attack, no? Don't forget that SDN exists and seems to work well in just about any virtulization platform (VMWare, HyperV, etc)...all can be perfectly security as long as they are properly hardened. The security risks of all this are no worse, just different.

Michael Kassner
Michael Kassner

I was amazed at the potential, I was also concerned by what could be perceived as a major weakness in the technology. Also, right now (1000 CDT/08/Apr 2013) the OpenFlow.org website appears to be down.

Michael Kassner
Michael Kassner

I have heard network engineers call SDN a "Cisco killer" in the respect that it eliminates the need to learn their cryptic operating system.

Michael Kassner
Michael Kassner

I know Enterasys has a technology called "One Fabric" but I do not know when it started or just exactly what it does. They require an actual device as a controller, the approach mentioned here is application driven. Not that big a difference, but it is one.

Michael Kassner
Michael Kassner

We will be back to main frames before long. The buzz now days is to move all control away from the troops on the ground. Doing so has good points, yet unlike mainframes, the control and data planes are not in the same facility they are separated by a thin piece of copper or glass.

kmdennis
kmdennis

As you will observe, I am right from the Juniper trees. Juniper has very nice capabilities too. Check this out: Juniper spotlight secure http://www.juniper.net/us/en/local/pdf/datasheets/1000427-en.pdf Juniper webapp secure http://www.juniper.net/us/en/local/pdf/datasheets/1000427-en.pdf Juniper MVS http://www.juniper.net/us/en/local/pdf/whitepapers/2000467-en.pdf And this is in addition to the Pulse Secure access and Pulse Access control service, Screens, and IDP offered on the SRX. I would talk about it more but then I would sound like a salesman. As you indicated, it is a layer solution

Michael Kassner
Michael Kassner

I have been in a DDoS myself and you mentioned the point that SDN will also help with filtering. I had to run around and alter several devices. With SDN, it appears to be all done through the application. Check out some of the OpenFlow videos, you may be impressed.

pgit
pgit

"In this case we would assume you would not leave the SDN controller layer exposed to attack, no?" Regardless, the controller and switches have to do their job. The 'saturation' attack is basically just making the controller 'do it's job' as frequently as possible, I would think in the hope that the controller would begin dropping legitimate traffic (or perhaps expose a switch) due to it's inability to handle the workload. The single point of failure is one thing, but there's also a bandwidth issue, between the controller and whatever switching hardware it has to communicate with. Sort of like you have a single point of DDoS-like vulnerability as well; the physical line the controller is on. I hadn't heard of SDN before, thanks for digging this up Michael. How long before your off the shelf consumer grade router can handle the protocol? ...or is it already possible with something like tomato or dd wrt? I'll have to poke into this a bit.

Michael Kassner
Michael Kassner

Isn't there more risk with the controller separate from the rest of the network? A single failure knocks the entire network out.

Michael Kassner
Michael Kassner

I know Sarah worked for Juniper, so I had thought they may have products in this area.

kmdennis
kmdennis

Juniper(I am biased here, if you get my drift) has pioneered the way when it comes to separating the data plane from the control plane and have it nicely protected. So traffic will still continue to flow even if the Controller gets gets compromised. The question would be what kind of a compromise are we talking about. If the connectivity between the controller and the SDN switch is SSL /IPSecVPN, then we would need be concerned about the physical compromise of the controller. Unless you are remote controlling the controller and your remote device gets compromised.. If the controller is physically secure, then we should not have that issue. But additionally, unless the implementation does not allow for redundant controllers, it will not be a single point of failure.

Michael Kassner
Michael Kassner

What do you mean by redundant controller? You really didn't explain.

JCitizen
JCitizen

Instant job obsolescence.