What risks does the OpenFlow protocol vulnerability present?

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.)