The OpenFlow handshake does not require the controller to authenticate switches during the OpenFlow handshake. Furthermore, the controller is not required to authorize switches access to the controller. The absence of authentication and authorization in the OpenFlow handshake allows one or more malicious switches connected to an OpenFlow controller to cause Denial of Service attacks in certain OpenFlow controllers by spoofing OpenFlow switch identifiers known as DataPath Identifiers (DPIDs). Additionally, the lack of authentication and authorization in the OpenFlow handshake can be exploited by malicious switches for covert communications, bypassing data plane (and potentially control plane) security mechanisms. In particular, the OpenFlow "Features Reply" message sent by the switch is inherently trusted by the controller. Note that for the attacker to launch an attack, the OpenFlow switch must first establish a (secure) transport connection with the OpenFlow controller (e.g., TLS and TCP), and the switch must be controlled by the attacker.
External Reference:
http://seclists.org/oss-sec/2018/q2/99
Review of ODL packaging and OpenFlow plugin show that we are impacted by the vulnerability described in the CVE, given we package and enable the OpenFlow plugin, and by default - no encryption or authentication is required for the initial controller handshake. A malicious OpenFlow client could handshake with the controller, as described in the CVE. The mitigation available is to enable TLS, which is supported by the OpenDayLight OpenFlow plugin, and would require registered switches and new switches to have correct TLS certificates before a session could be opened with the controller, mitigating the potential attack. The reference configuration should enable this TLS support to mitigate this CVE.