Security researchers discovered an important vulnerability in OpenFlow -- the dominant protocol for software-defined...
networking -- that can cause several problems, including denial-of-service attacks. What does the OpenFlow vulnerability entail and what risks does it present to enterprises using the SDN protocol?
The vulnerability in the OpenFlow protocol is due to the absence of an authentication and authorization requirement.
As was pointed out by researcher Kashyap Thimmaraju, a Ph.D. candidate at the Technical University of Berlin, the OpenFlow handshake process "does not require the [software-defined networking (SDN)] controller to authenticate switches," and "the controller is not required to authorize switches access to the controller." Because the vulnerability is in the OpenFlow protocol itself, any implementation of OpenFlow may be vulnerable.
The vulnerability enables an attacker to use one or more maliciously configured switches to connect to the victim controller using the OpenFlow protocol. Because authentication is not required, the attacker can use spoofed switch identifiers, known as Datapath IDs (DPIDs), during the handshake process used to open an OpenFlow connection.
An attacker can then cause a denial-of-service (DoS) attack against the controller because the controller can't verify the DPID involved in the OpenFlow handshake. The malicious switches can exploit the OpenFlow handshake for covert communication because security mechanisms on the data plane are bypassed when forwarding traffic to a destination network based on the control plane logic. The controller will also trust the OpenFlow features reply messages sent by the malicious switch.
By spoofing network topology, an attacker can impersonate a host connected to the malicious switches. Because host tracking doesn't require authentication or authorization, the attacker can use the impersonated host to trick the controller into believing an authentic host has migrated to a new physical network location.
In order for an attacker to launch an attack, the switch must first establish a secure transport connection with the controller using a secure protocol like Transport Layer Security (TLS) or TCP. An attacker can also exploit new TLS vulnerabilities even after TLS certificates are established for the switches.
As enterprises increasingly use SDN controllers, fixing this type of vulnerability in OpenFlow switches in an unsegmented network has become more complex. However, other protocols used within the OpenFlow protocol may introduce new vulnerabilities because SDN controllers are vendor-specific.
While some only communicate with switches, others extend their communication to firewalls and load balancers to reduce latency. Overall, firewalls that are properly configured for one network segment may not work well for another segment when the OpenFlow protocol is used.
Ask the expert:
Want to ask Judith Myerson a question about security? Submit your question now via email. (All questions are anonymous.)
Dig Deeper on Data security strategies and governance
Related Q&A from Judith Myerson
Kea, an open source DHCP server, was issued a medium security advisory for a flaw that causes memory leakage in version 1.4.0. Discover the ... Continue Reading
ES&S admitted it installed the insecure remote access program pcAnywhere on election management systems. Learn what pcAnywhere is and what this risk ... Continue Reading
Siemens disclosed six Siclock flaws that were found within its central plant clocks. Discover why three flaws have been rated critical and how threat... Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.