OpenFlow protocol bug to get mitigations, not a rewrite

The Open Networking Foundation is moving to address the protocol vulnerability revealed last week in OpenFlow, but won't revise the protocol. Not yet, anyway.

The issue, discovered by a group of European researchers, was that switches weren't authenticated to controllers – meaning a bad actor could get at communications if they could introduce a malicious switch to an environment.

Greg Cross from the Open Networking Foundation (ONF) contacted The Reg to explain what the Foundation will do to close the hole.

The ONF, he wrote, assesses the vulnerability to be a risk to networks in the following scenarios: an attacker accesses the management port of the device, and can leverage a vulnerability in a switch to access its certificate; a vulnerability exists in a switch's data plane, which gives them access to the switch's certificate; or the attacker can “generate or acquire a certificate that is trusted by the controller.”

You'll note that all of these scenarios assumes that the switch-controller connections are protected by TLS/SSL certificates, a protection suggested by the researchers who found the bug – controllers and switches should enable TLS with client-specific certificates.

That, Cross said, is because while it's not mandated, the specification recommends the use of TLS/SSL certs between switch and controller.

“The spec does not explicitly state that controllers should compare the Datapath ID (DPID) with the client certificate for a particular switch when establishing a connection; this is an implementation decision for controller developers,” Cross told The Register in an e-mail.

“Unfortunately, many open source controllers do not perform this explicit check when establishing secure connections with OpenFlow switches, and this is the crux of the vulnerability.”

As a result, security is implementation-specific at this point.

The ONF's own implementation, ONOS (the Open Network Operating System), will get the fix in release 1.13.2, Cross said, and ONOS already supports blacklisting and whitelisting, which would also help sysadmins control which switches connect to a controller.

“From an OpenFlow perspective, we do not believe that the specification needs to change,” he wrote, but “we are encouraging other SDN controller developers to update their controllers with the mitigation strategy described by the authors of the vulnerability.”

In the future, he said, the SDN community will be replacing OpenFlow as the SDN interface with P4Runtime (part of its Project Stratum).

“P4Runtime runs over gRPC, which provides a secure end-to-end environment and the controller acts as the client (instead of the switch). Both of these properties help harden the security of SDN environments,” he wrote. ®