Network virtualization, under the umbrella of Software Defined Networking (SDN), presents an opportunity for network innovation but at the same time introduces a new weakness which will more than likely be targeted once solutions become more commercially available.
Whether the underlying technologies used are OpenFlow or Overlay Virtual network, network virtualization solutions are based on a network controller which can be attacked in different ways. A successful attack on the controller will neutralize the entire network operation for which the controller is responsible – it can be said that there will be a new type of attack that will put the entire network operation under denial of service conditions.
A little background on software defined networking (SDN) which includes within it the overall trend of network virtualization and openflow:
OpenFlow/SDN challenges the basis of the old style networking, and suggests a completely new approach – a centralized algorithm and intelligence, rather than a distributed one (distributed algorithms are typically executed concurrently with separate parts of the algorithm having limited information about what the other parts of the algorithm are doing). This centralized approach leads to a democratization of networks, which means that anyone who wants to control the network could do so through programming, using an abstraction layer as the network operating system (Network OS).
Figure 1 – Decoupling the network control logic from the network hardware
The central network control entity is an essential part of the new SDN solutions and brings with it many advantages over the traditional way networks are handled today (you are welcome to read more about it in one of my recent blogs and column “network apps” and “Secure SDN” )
Having said this, the network controller presents a new weakness that can be the target of an attack. In order to illustrate the security issue here’s a simple example for the case of an openflow enabled network:
The basic openflow principle requires that each packet which represents a new “flow” (e.g, typical TCP flow, L3 IP level flow etc.) that enters the openflow network to be sent to the network controller. The controllers will calculate the best path this flow should be routed through and will distribute this knowledge, in the form of flow table entries to all OpenFlow enabled routers and switches in the network. Once this is done, further packets that are associated with the same flow will be routed through the network without any further involvement on the part of the controller.
The SDN, and more specifically OpenFlow technology, allows to define through software in the network controller what the network “flow” is. It can be a typical TCP connection or a pair of source and destination IP addresses, range of IPs, protocol type, etc.
Understanding this process reveals two main security weaknesses that are associated with new types of denial of service attacks:
• The data path infrastructures, i.e., the OpenFlow enabled switches and routers can now be a target of “flow table” saturation attacks.
• The controller entity can be flooded with packets that represent a new flow in rate that it cannot process – leading it to be in a DoS condition that “refuses” to let the new flow enter the network or reach their destinations (each flow can of course represent a new online business transaction or any other type of communication.)
As this is pretty basic and straightforward, I don’t want to give too many ideas to attackers. But, I would give one scenario of an attack on such SDN infrastructure that is supported by openflow:
1. An attack activates a new network scanner that generates legitimate traffic in the openflow supported network
2. The network scan tool is designed to reveal the “routing logic” that the controller was programmed to enforce and the definition of a “flow” in the network, i.e., is it a TCP connection, is it just a pair of IP addresses etc.
3. Once the “flow” definition is known to the attacker, the attacker can produce a high rate of traffic that generates new “flow” until it reaches the network controller capacity and puts the entire network in DoS conditions.
The above attack process is simple but as in the case of other more traditional DoS attacks, it will not be so simple to protect against it. I know that a few companies are already thinking about how to protect against these new SDN weaknesses – it will be interesting to see how much progress is made before SDN becomes more widely implemented. Not adopting new security frameworks that protect against the types of attacks I have illustrated is similar to not protecting today’s DNS infrastructure – a BIG issue!
