Yes. Next question?

If the question is Is SDN your next security nightmare?, then this title is for you! The referenced article appears in Network World, and describes a talk given by Robert Hinden last week at the RSA security conference.

Hinden specifically addresses the OpenFlow flavor of SDN, and in that arena his points are perfectly valid; in fact, I’ve made many of them before in this post. But they probably bear repeating:

1. Availability issues: What happens if the SDN controller crashes, or less catastophically, if some segment of switches become isolated from the controller? There is certainly no standardized mechanism to recover. Much like most network switches still have the “fallback” capability to go into hub mode when their MAC address table is full, any OpenFlow switches that really hit production networks are going to have a fallback mode to “normal switch”. Which is probably a reasonable argument for why OpenFlow technology is probably not going to go campus-wide at all.

2. Scale issues: Hinden questions how well OpenFlow can scale, and raises an interesting point I hadn’t really thought of before, namely size of the flow table. Existing switching and routing protocols use only a small subset of the information in a given packet flow to make forwarding decisions, namely one of the destination addresses. Even with forwarding based on this limited amount of information, network engineers worry about these forwarding tables swamping both network bandwidth as they are exchanged and device memory as they are stored on forwarding devices. The power of OpenFlow is the ability to make much more fine-grained decisions based on other flow data, but this granularity comes at the price of greatly increased forwarding rule complexity and volume. In principle this makes sense, but I think that ultimately the limiting factor here is going to be human understanding of the flow table architecture, rather than technical limitations; I believe many SDN evangelists sell short what I have referred to before as “the mundane genius of Ethernet and TCP/IP…working with a relatively small amount of configuration”.

3. Vulnerability issues: Hinden rightly worries that a compromise of the SDN controller would allow the attacker to wantonly drop, redirect, or collect traffic throughout the network. In some ways this seems like a “no s*&$ Sherlock” sort of statement; if one owns the brain of the network, one can do whatever one wishes. But in a network managed via standardized switching and routing protocols, this actually isn’t true. Even if I grant an attacker full control over a legacy network (short of rewriting the forwarding software on the devices), the attacker only has the capability to tweak parameters of existing algorithms. Of course the attacker could sinkhole selected network traffic to another machine he/she controls and get more robust capability that way, but that requires additional infrastructure that needs to be hidden and I’m sure the networking side of the redirection would have to be pretty delicately balanced. The native capability in an SDN network provides an attacker with much more robust capabilities to manipulate traffic.

Hinden does mention the “security benefits” line sold by SDN evangelists, namely having the network itself involved in security policy, though there’s not enough in the article to determine whether this is true belief or lip service.

My main beef with the article, and presumably with the underlying talk as well, is that there is no claxon sounding about the likelihood of an SDN controller being compromised. The SDN true believer can simply shrug the “central point of vulnerability” argument off with a statement like “best practices demand that the SDN management network be isolated from all other traffic, allowing no point of entry for the SDN controller to be compromised.” Except that best practices have always suggested that management networks be isolated, and those best practices are seldom followed in operational networks. As I stated in a previous post:

Target’s lifeblood is payment processing, and for whatever reason they didn’t segment their network sufficiently to protect their most important systems. Why should anyone think that they would secure their network management traffic with any more care?

In my opinion, not recognizing and addressing this simple truth is the biggest SDN vulnerability of all.

Comments are closed.