The document summarizes research on vulnerabilities in the OpenFlow control channel and potential attacks. It describes conducting a man-in-the-middle attack on an OpenFlow network by sniffing OpenFlow traffic, sending a TCP reset to hijack the control session, and spoofing the controller. It also evaluates the OpenFlow specification making TLS optional and proposes using TLS and padding messages to prevent sequence number prediction attacks. The document analyzes several OpenFlow controllers and their TLS support and concludes more needs to be done to securely adopt SDN technologies.

1. Ying
Observations & Results
MITM Attack and Session Hijacking Procedure
1. Set up a small network with
OpenFLow switch and controller
using Mininet
2. Sniff OF traffic (port 6633)
using Wireshark/Ettercap
3.To Steal switch OF control port:
3.1. Send TCP RST segment to
Controller and Switch
3.2. Start dummy controller on
attacker listning on OF port
3.3. Poison Switch ARP cache
by spoofing attacker machine as controller
3.4. Accept connection request from switch and Hijack OF control session
Sequence number prediction Attack on OF Control
Channel
a. Typically only first packet of a new flow is sent to controller in PKT-IN
and flow installation at switch follows after PKT-OUT
b. With higher number of persistent flows, idle control channel is kept alive
by exchanging OpenFlow Echo Request/Replay messages each of size 8
bytes, this fixed size segments enable attacker to conveniently predict
sequence numbers.
Solutions:
1. Use of TLS with PKI & certificate based authentication between controller
and network devices (switch/router) will provide Privacy and Integrity.
2. Pad Nonce- bytes of arbitrary length (< MSS) to OpenFLow payload to
avoid sequence number prediction.
Potential Attacks & Mitigation
1. Since OpenFlow uses a well known port, it’s easy to identify OpenFlow
traffic during packet sniffing.
2. Network packet is passed as it is in PKT-IN. Lack of encryption leaves flow
initiation parameters and sensitive user data in packet exposed to attacker.
3. By successfully hijacking OpenFlow control channel, attacker can virtually
control all networks elements managed by controller. However, although not
impossible, simulating the RST attack followed by TCP session hijacking is
quite difficult, as multiple TCP/IP header parameters are to be matched in TCP
connection context to reset existing connection and spoofing new controller.
4. We haven’t tested the Nonce padding solution, but it will surely aid to make
sequence number prediction difficult if not impossible.
5. Our study shows that use of TLS with PKI will help to protect authenticity of
communicating OpenFlow nodes and integrity of OpenFlow control channel.
Abstract
Department Of Computer and Information Science Engineering
University Of Florida
Yogesh Patil
Software Defined Networking(SDN) aims at simplifying and enhancing
network control and management. We identify that, failure to adopt TLS for
OpenFlow(OF) control channel may leave OpenFlow vulnerable to Man-In-
The-Middle (MITM) attacks. This work is our attempt to do feasibility study of
such vulnerabilities using TCP Reset attack followed by control session
hijacking. We also show that control channel is vulnerable to TCP Sequence
number Prediction attack and propose use of Nonce in OpenFlow payload to
avoid it. As a result of this study we highlight need for OpenFlow specification
mandating use of TLS for OpenFlow control channel instead of keeping it
optional. Considering the widespread adoption of Network function
Virtualization (NFV) enabled by SDN, it is crucial for secure OpenFlow control
channel to co-exist along with innovative virtualized network security
applications.
OpenFlow Control Channel Threat Model
OpenFlow Control Plane
a. OpenFlow connects logically centralized
Control plane and forwarding data plane.
b. OF Specification makes TLS optional for
control channel, and we aim to target this
potential vulnerability for this study.
c. With plain TCP and standard OF port
(6633), MITM attacks are achievable and
may eventually result in controller hijacking.
d. However, everything less than TLS 1.2 with AEAD mode is
cryptographically broken. This implied control planes supporting TLS, should
be capable of mitigating known SSL/TLS version downgrading attacks (e.g.
POODLE, Lucky 13)
e. We also present list of popular and widely adopted OF controllers from
academia and industry supporting/not supporting TLS. For the open source
controller, we examined source codes for fixes to known SSL/TLS version
downgrading attacks.
f. Finally we propose an enhancement to OpenFlow specification for Keep-
Alive message exchange to protect against sequence number prediction attack.
Conclusion & Future Work
References
Though central controller in SDN presents an opportunity to converge multiple
anomaly detection methods deployed in networks, at the same time it poses concern to
establish Trust between controller and network devices and a challenge to protect this
logically centralized system from DDoS and other attacks as discussed in this study.
Finally, with increasing number of Zero-day vulnerabilities being exposed, TLS is
solution to currently known threats. Lower and buggy SSL/TLS implementations are
still susceptible to version downgrading attacks. More unresolved challenges,
potentially critical, yet remain to be addressd to yield truly secure and reliable
Software Defined Networking.
Controllers TLS Support
NOX/POX No
Beacon No
Floodlight No
MUL No
FlowVisor No
SNAC No
Golfer (UF) No
OpenvSwitch YES (TLS 1.2)
Controllers TLS Support
Big Network
Controller
Yes (TLS 1.2)
Brocade Vyatta Yes (TLS 1.2)
Cisco NXC Yes (TLS 1.1)
Extreme Networks
(Slalom)
Yes (TLS 1.2)
NEC No
OpenDayLight Yes (TLS 1.2)
In Sep’14 Helium Release
ARC/Plexxi -
Table 1. Controllers from Academia and
their TLS support status
Table 2. Controllers adopted by industry and developed
and maintained commercially
Control Plane
OpenFlow
Protocol
Plain TCP or TLS Control
Channel
Fig 1. OF Control Channel
[1] Nick McKeown, Tom Anderson, Hari Balakrishnan, Guru Parulkar, Larry Peterson, Jennifer Rexford, Scott
Shenker, and Jonathan Turner. 2008. Openflow: enabling innovation in campus networks. SIGCOMM Comput.
Commun. Rev. 38, , 2 (March 2008)
[2] "OpenFlow Switch Specification Version 1.3.2” Open Networking Foundation. [Online]. Available:
https://www. opennetworking.org
[3] R. Kloeti, "OpenFlow: A Security Analysis," April 2013. [Online]. Available:
ftp://yosemite.ee.ethz.ch/pub/students/ 2012-HS/MA-2012-20 signed.pdf
[4] D. Kreutz, F. Ramos, and P. Verissimo, "Towards secure and dependable software-defined networks," in
Proceedings of the second ACM SIGCOMM workshop on Hot topics in software defined networking. ACM,
2013, pp. 55-60.
[5] Shin, Seungwon and Yegneswaran, Vinod and Porras, Phillip and Gu, Guofei AVANT-GUARD: scalable and
vigilant switch flow management in software-defined networks Proceedings of the 2013 ACM SIGSAC
conference on Computer & communications security pages: 413-424, 2013 ACM
Unified OpenFlow Controller
Host in Subnet A
Host in Subnet B
Fig 2. Data Center like SDN topology
1. Sniff OF Pkts
2. Send RESET
3. Start Dummy
Controller, Listen
on OF Port
4.Poison
ARP cache