This document summarizes a research project exploring DDoS vulnerabilities in OpenFlow controllers. The researchers aimed to test if an OpenFlow controller could be overwhelmed by a flood of packet-in messages from switches. They found that the Floodlight controller's performance degraded significantly under high packet-in loads. They also demonstrated a way to generate packet-in events from endpoint hosts using specially crafted ARP packets, allowing them to deny network service. The research highlights security issues in current SDN implementations and the need for mechanisms like rate limiting and anomaly detection to mitigate DDoS risks.

1. Research Project:
Floodlight DDoS Vulnerability
Nir Solomon, Yoav Francis and Liahav Eitan
Supervised by : Yotam Harchol and Anat Bremler-Barr
September 2013 | IDC Herzelia

2. Background

3. Project Goal: DDoS in an OpenFlow
Controller
We aimed to explore the possibility of DDoS on an OpenFlow Controller
OFC – the “soft-belly” in regards to network security of a Software-Defined
Network.
The controller, by being responsible for multiple switches, is a `high-
valued` target.

4. Background - OpenFlow
“an open interface for remotely
controlling the forwarding
tables in network switches,
routers, and access points.
Upon this low-level primitive,
researchers can build networks
with new high-level properties”

5. Jargon – Secure Channel
The secure channel is the interface that connects an OpenFlow device
(switch) to the controller.
This channel is encrypted with SSL.
But… This is not enough to prevent a DDoS from happening!

6. Jargon – “packet_in”
if a packet does not match any of the existing rules on an OFS, default policy
is to send the header to the OFC.
This “packet sent to the controller” message is called a “packet-in”.“packet-in”.
We will explore DDoS using this type of packet.
“an OpenFlow controller can block traffic, install rate limiters,
or even change the default policy for an unmatched packet to
drop it on the ground.”
“ ..But on the other side, being too aggressive—that is blocking
or rate limiting too much—can break features or have a negative
impact on performance.” (Floodlight Blog)

7. Secure Channel Sample pcap

8. DDoS on an OpenFlow Controller
Effects of OFC-DDoS on the network:
• Increased latency and packet loss in the entire network
• The entire network might stop functioning
• Mishandling of specific protocols by the switches
• Protocols that require constant communication with the OFC are
more vulnerable
Difference from classic DDoS attacks:
• An attack carried out at one place in the network can affect the global
network behavior

9. Attack Vectors in Software-Defined
Networks
• OFS / OFC Attacks :
• Switch input buffer overload
• OpenFlow Module vulnerability in OFS (Software vulnerability)
• Secure Channel traffic amplification
• Assuming access to the Secure Channel:
•SYN flood (or any other TCP attack)
•ARP Poison between OFS and OFC if there is no SSL

10. Chosen Attack Vector
• Assume control of multiple endpoint computers in the network
• Send specially-crafted packets that do not match flows in the OFS
• The switches will then create packet_in events to the controller –
Secure Channel Traffic Amplification
• This will also overload the CPU of the controller because of multiple
secure channel connections – CPU depletion
• After some time – the controller will have to drop packets due to
high load  DDoS

11. DDoS Attack – Example
OpenFlow Controller
OpenFlow
Switches
Crafted
Packet
No Flow
available
 Send to
Controller
Packet_in

12. Related Work

13. OpenFlow Vulnerability Assessment
K. Benton, L.J. Camp, C. Small
Sigcomm 2013
A brief overview of the vulnerabilities present in current OpenFlow devices.
Finds that OpenFlow implementations rely on physical security
•Lacks TLS, Access Control
•Repeats errors of older network management protocols
• Telnet, SNMPv2, TFTP
Existing vulnerabilities assuming access to the Secure Channel:
•Man in the Middle
•Listener Mode
•Switch Authentication
•Flow Table Verification
•Denial of Service Risks
•Controller Vulnerabilities

14. Attacking Software-Defined Networks:
A First Feasibility Study
S. Shin, G. Gu
Sigcomm 2013
A method to fingerprint software-defined networks.
The fingerprinting is done by noticing the different response times in the cases of
Existing-Flow and New-Flow.
The article suggests that if an attacker identifies a network as an SDN, they can
move on to conduct a resource consumption attack (DoS).

15. OpenFlow: A Security Analysis
R. Kloti
Swiss Federal Institute of Technology Zurich 2012
A detailed security analysis of OpenFlow 1.0 that describes, categorizes and suggests
solutions for different attack methods.
Three categories of attacks on Software Defined Networks:
•Information Disclosure
•Tampering
•Denial of Service
Several targets for DDoS attacks:
-OFS flow table – overload the switches’ flow table
-OFS input buffer – make the switches send whole packets to the OFC
-OFS OpenFlow Module – software vulnerability
-Management Interface and/or Controller – software vulnerability
Most of these attacks do not target the OFC, but some solutions still applicable:
•Rate limiting, flow aggregation, attack detection

16. Research and Results

17. Floodlight
We have chosen Floodlight as our targeted OpenFlow controller in this work
Common enterprise level controller
 Used by Arista, Brocade, Citrix, Dell, Extreme Networks, Fujitsu, Google, HP, IBM,
Intel, Juniper Networks and Microsoft
Open-source JAVA code with public git repository
Declares itself to be designed for high-performance
 therefore should not be susceptible to DDoS attacks
Easy to use and deploy

18. Floodlight

19. Part I – Floodlight DDoS by Simulating
Packet-In Events with CBench
 Cbench tests OFCs by sending packet-in events
 Cbench emulates switches which connect to a controller, send
packet-in messages, and watch for flow-mods to get pushed down
 We used Cbench to directly test how Floodlight responds to a flood of
packet-in events on the secure channel
 Note that in real-life scenarios, we will also need a way to generate
the packet-in events using specially crafted packets.
 We will demonstrate such a way in part 2.

20. Floodlight’s LoadMonitor
On high loads, the LoadMonitor practically performs DoS by itself!

21. Floodlight’s LoadMonitor - cont

22. Floodlight’s LoadMonitor - cont
The LoadMonitor was disabled by default in the Floodlight git
because the "overload protection is not yet tuned”

23. Floodlight DoS Test Method
We created a Python script which is run on the mininet VM:
•Kills running Floodlight instances
•Runs Floodlight with correct configuration
•Runs Cbench with an increasing number of switches (20-300) and
a constant number of simulated MAC addresses (100000)
•Sniffs the returning packets from the OFC
•Calculates the average number of flow mods per second returned
from the controller, per run
•Saves the average fmods and the sniffed packets to a pickle file

24. Floodlight DoS Test Results
• The blue line represents the
normal mode, and the green
line represents the load
monitor mode.
• Overall, especially when
dealing with a large number
of switches, the load
monitor mode decreases
the controller performance.
• This is practically a DoS
using the secure channel
access, as Cbench simulates
OpenFlow switches.

25. Part II – Create Specially Crafted Packets
 In this part we demonstrate a way to coerce OpenVSwitch to send
packet-ins to the OFC.
 In this part we do not assume access to the Secure Channel – unlike
Cbench in the previous part
 The entire attack must be carried out entirely from the endpoint
computers
 We do this using a specially crafted packet that is sent from the
computers and generates packet-in events in the switches.

26. Part II - Test Method
• The specially-crafted packets that we sent from the mininet hosts are ARP
packets with random source MACs:
Ethernet Header Arp header
Src MAC = random MAC
Dst Mac = FF:FF:FF:FF:FF:FF (broadcast)
Type = ARP Request
Src MAC = random MAC (same as in ETH
header)
Dst MAC = FF:FF:FF:FF:FF:FF (Broadcast)
Src IP = Another host IP
Dst IP = Another host IP (same as Src IP)
• Each host Repeatedly sent this packet to all other hosts that
participate in the DDoS attack, each time with a different source MAC
• We found that when OpenVSwitch observes a packet from a previously
unseen source MAC it sends a packet-in to the Controller and waits for
a flow mod to be installed

28. Part II – Additional Results
• We wanted to also test the network performance during the attack.
• During the attack:
• We ran two hosts that did not participate in the DDoS for performance
evaluation on the end-user
• We used the iperf utility, which calculates network throughput, in a pre-
defined interval to evaluate network performace
• We have examined this attack with varying number of “malicious” hosts
and with varying number of OpenFlow Switches, and measured the network
throughput in each case

29. Part II – Additional Results (cont)
Throughput (Mbit/s)
Switches Hosts initial 30s 60s 90s 120s 150s 180s 210s 240s 270s 300s 10min
2 10 1270 253 146 135 156 140 186 137 150 158 98 158
2 20 1170 72 62 84 62 60 72 81 65 66 80 55
2 25 1190 30 40 37 1 40 35 43 45 34 37 44
5 10 835 94 103 115 97 53 92 76 92 100 90 61
5 20 798 41 41 FAIL 50 48 48 34 49 FAIL
5 25 FAIL
10 10 551 44 66 20 FAIL
10 20 538 FAIL
10 25 FAIL
• These results show clearly that using the Specially-Crafted Packet method we
have successfully denied service in the network.
• As the number of hosts or switches gets sufficiently high, even two hosts that
do not participate in the DDoS attack have a difficulty to communicate

30. Part II – Additional Results (cont)

31. Conclusions
 In the work we have found two vulnerabilities in wide-spread SDN
implementations:
1. A DDoS vulnerability in the Floodlight controller
2. A Packet-In generation vulnerability in OpenVSwitch
 While exploiting these vulnerabilities, we have managed to:
 Generate Packet-In events using specially crafted packets
 Overload the Floodlight OpenFlow controller
 Deny service from all of the OpenFlow switches that rely on the
controller.

32. Possible Solutions
 Rate limiting of Packet-In events per application (switch-level)
 Flow Aggregation
o controller strategy where one rule matches multiple flows
(performance vs. precision)
o Allows network to partially work when the OFC is not responsive
 Fully Proactive Approach (flow rules cover all possible traffic in
advance)
o Immune to this sort of attack
o Relinquishes many benefits of SDN – applications that require
dynamic information can’t function in a proactive network.

33. Possible Solutions (cont)
 Careful event filtering
o Resembles the idea of Floodlight’s Load Monitor
 Anomaly detection
o Under heavy research for various other network security issues
o More effective in a reactive SDN than in classic networks

34. Insights

35. Insights from Research Process
 Current implementations, specifically Floodlight and OpenVSwitch, do
not adhere to the OpenFlow RFC
o TLS is not in supported
o Packets are sent in whole to the OFC by default
 Security is not taken seriously enough in current SDN implementations
o As a Floodlight developer stated: “it would be pretty trivial to
add [TLS support] if there was sufficient interest”
 SDN is inherently susceptible to attacks
 Not enough articles concerning SDN security
 SDN applications need to be designed carefully and to meet a
common security standard:
o Function to some extent without a controller
o Limit the number of packet-in events it generates

36. Questions ?

37. Thanks !