Sandra Scott-Hayward addresses SDN security concerns, in response to The Register.
We have billboard ads in the U.K. warning homeowners to take care of their property by locking windows and doors. The tagline goes something like “It’s not a break-in if it’s a walk-in!” This perfectly expresses the sentiment that arose in our ONF discussion around this recent article in The Register.
The article refers to an academic paper by researchers from the University of Padova and Sapienza University. I want to start by saying that I am thrilled to see this research work on Software-Defined Networking (SDN) security. The focus of my own research is exactly this and the more people contributing to this important topic, the better for the networking community! However, I have a few comments… the dreaded words in an academic paper review! In this case, my comments are to The Register. Let me expand.
To The Register: The title of your article is very catchy. I’ve tried to do the same with mine! However, I find the statement “Software-Defined Networking Is Dangerously Sniffable” somewhat suggestive and, I would argue, inaccurate. In the body of the article, the origin of the title statement is found, “an attacker could potentially sniff control traffic, because of inadequate protection (not using TLS, or not using certificates for authentication).” What we’re talking about here is the fact that with the separation of the data and control planes in SDN, control traffic is transmitted between network elements and the controller, and as such is vulnerable to “sniffing” or interception.
However, this is not a concept unique to SDN; the transmission of any data/control traffic on any open, unsecured communication path in any network is vulnerable. For this very reason, the use of TLS, certificates, IPSec, encryption, etc. is recommended in all network deployments, not just SDN.
This is the key – SDN doesn’t have to be any more dangerous than a traditional network. It’s down to how we design our devices, architect our networks, and deploy all of this in a secure fashion. I should highlight that in all the work of the ONF Security Working Group, we strongly recommend the use of TLS or a TLS equivalent protocol.
So I’ve just spent a few paragraphs disputing what is actually detailed in the “Know Your Enemy” paper as a possible method an attacker could leverage to gain a side-channel to the flow table. This potential to access a side-channel to the flow table is a fundamental assumption of the work, and details of the methods (and obviously means to defend against them) are out of scope of the work. This is where my title comes in – if we don’t design and deploy our networks (SDN or otherwise) securely with proper system management, then yes, of course, we can anticipate attacks.
Let’s say it is possible to gain this important side-channel to the flow table. In the article, we’re told that “the attacker can easily work out what conditions will make the controller push a flow rule…” Quite frankly, there doesn’t seem to be anything easy about this process. There are a volume of steps required over a long period of time. The authors, themselves, have identified this as a limitation.
There are some other aspects I would discuss in a conversation with the authors. For example, the proactive installation (rather than reactive as discussed in the work) of flow rules in practical, large networks; the aggregation and normalization of flow rules in hardware switches; the impact of distributed control on this scenario; etc. These could all potentially limit the effectiveness of the KYE attack.
Let’s also not forget that the flow rules under observation in the KYE attacks are the SDN-enabled dynamic defense to those same attacks. SDN brings benefits to network security, including increased awareness of potential threats to the network, that are not attendant to other means of control.
Anyway, my commentary is not to critique the work but to balance the media message it has generated. I thank Mauro, Fabio, and Luigi for their contribution to a growing body of work on SDN security. We can learn from these results to focus our attention in designing and deploying secure SDN.
To The Register, please be cautious with loose use of the word “dangerously.” SDN is no more sniffable than any other unprotected network; in fact, network security can benefit from this innovation.
– Sandra Scott-Hayward, Vice Chair of the ONF Security Working Group