ICTC 2014 1569998443
Mitigating Denial of Service (DoS) Attacks in OpenFlow Networks
Yustus Eko Oktian, SangGon Lee*, HoonJae Lee
Department of Ubiquitous IT
Dongseo University
Busan, Korea
yustus.oktian@gmail.com, nok60@dongseo.ac.kr, hjlee@dongseo.ac.kr
Abstract—Software Defined Networking (SDN) is a promising
step towards the future network. But, it still has some issue
regarding the security. One of the security issues is the
augmented impact of Denial of Service (DoS) attacks. In this
paper, we create an application on the top of Beacon controller to
mitigate the DoS attacks in the OpenFlow networks. The attacks
include IP/MAC Spoofing and Bulky/Garbage Message. We
launch the DoS attacks towards the network and analyze the
performance of the application. All of these attacks, Beacon, and
OpenFlow are implemented in the network simulation
environment Mininet. At the end of this paper, we also discuss
about another strategy and supplementary method to mitigate
the DoS attacks.
Keywords—DoS; Application; OpenFlow; Attacks;
I. INTRODUCTION
Today’s networks have become more complicated and
difficult to manage because of the complexity of designs and
features. The Yankee Group [1] has already done some
measurements and research and they find out that 62% of the
network downtime in multi-vendor networks is caused by
human-error, and 80% of IT budgets were mostly spent in
maintenance and operation. Beside of that, software and
hardware that support layer 7 networking have grown into
sophisticated schemes, like the network virtualization and
cloud computing, meanwhile the network environment that
supports them remains the same, doesn’t evolve yet.
SDN is one answer of the revolutionary networking for
today’s complex networks. The concept of separating control
plane from the data plane makes the switch/router interface to
become dumb, leave all the networking flow and scheme to be
controlled by new instance called ‘controller’. With this
concept in mind, it brings hope to create new networks that are
robust, resilience, and scalable, yet still simple in management
and can react in networks dynamic nature. Unfortunately, the
new concept of SDN brings some weakness in security
perspective. They are lack of security involvement at the
design. [2] already mentioned that implementation of SDN still
has seven main treat vectors that can be used by attacker to
attack the network. One of the vector treats results in
augmented impact of DoS attacks which may enable the
attacker to disrupt the network very easily.
The purpose of (DoS) attacks are breaking down the
network by sending aggressive traffic to the network, making
*Corresponding Author
978-1-4799-6786-5/14/$31.00 ©2014 IEEE
another user in the network can’t receive services from the
network services (e.g. servers), making network peripheral
(e.g. switch, router) overloads, or at least decreasing the
legitimate throughput of the network. It is not a new type of
attack in response to SDN implementation. It already exists in
the traditional network. There are several examples of DoS
attacks that attack famous network services like Twitter [5] and
Facebook [6]. For more recent examples, the DoS attack is
more sophisticated in the way of launching the attacks [7], [8].
The motivation behind these attacks can be varied. It can be
economical or political reasons. These examples remind us
how important the security of our networks is.
The implementation of OpenFlow [3] as a leading SDN
protocol can help mitigate DoS attacks. We can utilize the
advantages of separating control plane and data plane to
counter DoS issues that mentioned before. This separation
enables us to create dynamic networks, which can react to
some of network events, including during the DoS attacks.
In this paper, we create a security application on the top of
the Beacon [4] controller. We detect and react to the DoS
attacks dynamically and calculate its performance. By doing
this, we want to know whether this is a good way to mitigate
DoS attacks or not.
We elaborate this paper in this order, section two will
explain about related works. Section three will explain the
design of our application structure. We explain about the DoS
attacks and mitigation process in section four. Then we explain
our implementation in section five and evaluate in section six.
Finally, we conclude our application and open discussion in
section seven.
II. RELATED WORKS
There are some security related projects or analysis has
been made since OpenFlow released. These also include about
the prevention against the DoS attacks. In common, we can
divide the mitigation process into two kinds: hardware or
software solution. The example of hardware solution is [9]. It
creates an extension called data plane caches that have an
objective to mitigate the DoS attacks towards secure channel
communication between controller and switches. [10] also
creates an extension in data plane to remove the malicious flow
from being sent to the controller. These two projects are
implemented in hardware and need modification of the switch.
325 ICTC 2014
1
 Our application is implemented in software and there are
examples of other software solution. FortNox [11] is a project
that enhances the NOX controller to have a security
enforcement kernel that govern the flow rules from the
dynamic applications, so it would not overlap each other and
make sure that security related applications will get a high
priority and not be circumvented by the adversarial
applications. FRESCO [12] is a security application framework
that runs on top of FortNox environment. We can also
implement our DoS-mitigation application in FRESCO
framework to get the benefit of the framework.
[13] has a project about DoS attacks that takes advantage of
vulnerability that is found in Floodlight controller. This
vulnerability enables the attackers to disable switch connection
from the controller by using DoS attacks towards secure
channel and modify the switch DPID parameter. [14] thesis
project deploys a prototype that cooperatively detects and
mitigates the DoS attacks that are focused on Crossfire attacks.
The action of the mitigation will be flow routing, rate limiting,
and ranking. These two projects are specific to vulnerability
and attack. Meanwhile, our application is more likely to
mitigate common DoS attacks without the need of some
specific vulnerability.
There is also solution about mitigating DDoS attacks using
NOX controller [15]. This solution is based on flow-based
analysis and use Self Organizing Maps (SOM). Flow table is
queried and analyzed periodically to detect the DDoS attacks.
The difference between our application and this is we use both
flow-based analysis and packet-in analysis to provide better
detection, so we can also detect the Internet Protocol (IP)
Spoofing attacks and MAC Spoofing attacks. We also provide
the mitigation process towards the DoS attacks which is not
provided in [15].
Fig. 1. The design of DoS-mitigation application in Beacon controller.
III. DESIGN
Mitigating the DoS attacks is not an easy matter. Usually
the attacks are hard to detect because they behave like a normal
packet that flow into our networks. But, it doesn’t mean that it
is inevitable. There are still some events (e.g. sudden high data
326
2
rate transmission) that we can detect as an opening of the
attempt of DoS attacks. Detecting higher data rate DoS attack
is easier than lower rate attacks. High rate attacks usually use
bulky packet generator that has an intention of binging down
the nodes or make the network throughput slower. Meanwhile,
flow rate attacks use the useless, unintentionally, garbage
packets to the network. The intention is to fill up the switch’s
flow table and make the switch can’t provide flow entries for
the legitimate packets.
Sometimes, the DoS attacks also include combination of
other attacks such as IP or MAC Spoofing. By knowing the
potential target of the attacks and the method that usually taken
by the attacker, we design the application to have 6 features:
binding, location tracker, packets filtering, port and flow
statistic queries, and port status. Figure 1 depicts our design of
application at Beacon controller. The name of the application is
Dossy and it resides in the controller along with other
application like learning switch, device manager, and topology
applications. In our application, there will be three main
processes: packet in, switch statistics, and port status. The
application collects these three OpenFlow messages to provide
the mitigation towards the DoS. Each process will specifically
detect and react to the messages independently and
cooperatively provide solution based on six features stated
previously.
A. Bindings
When the network has been set up and run, there will be a
lot of nodes that connect and communicate into our networks.
All of these nodes can be the source of the threats that happen
in our network, so knowing the identity of each node is
important. This will lead into the leak of the identity of each
packet that propagate into the network, from which node this
packet come through, what is the destination node, what is the
kind of transport service that is used, etc. This information is
essentials for security purposes.
TABLE I. BINDING TABLE
Name Type Usage
MACIP Hashtable MAC and IP Bindings
MACSwitch Hashtable MAC and Switch ID Bindings
MACPort Hashtable MAC and Port ID Bindings
MACList ConcurrentList List of currently connected MAC
Address
PortList HashTable List of active ports in switches
a.
Binding Table are components created and used in Beacon
We design our application to keep track of the nodes inside
the network. At network startup, the controller collects MAC,
IP information of all hosts and binds them together into
MACIP hashtable. The collection process is done by inspecting
source MAC/IP address from Packet In messages that sent to
the controller. Then, the controller will compare with MACList
and save them in the hashtable if they are considered to be new
connected device. The controller will replace information about
old device with the new device if there is case when the old
host leaves the network and a new host joins. With this, the list
of connected host will be updated. Table 1 shows list of tables
that is used to store network information.
B. Location Tracking
Knowing the location of hosts can ease the process of
blocking the detected attacks. The application’s design enables
the controller to know who cause the attacks, where to find the
attacker, and do the mitigation as near as possible to the
attacker source. To provide this mechanism, the application
records and saves the position of each connected host in the
network
Fig. 2. Location Tracking: MAC, IP, Switch, Port Bindings
The information that is saved in the controller is MAC/IP
binding, as well as, switch ID and physical port that each host
connected to. An example of location tracking is depicted in
Figure 2. The controller collects information of switch DPID
and port ID during inspection of Packet In messages. For the
first time, this information collected at network startup. Then it
will be automatically updated if there is a change in the
network. This location tracking feature will help the controller
to block the attack as close as possible to the attacker by
inserting flow rules near to the switch where the attacker
connected to.
C. Packets Filtering
In OpenFlow, packets that do not match any of the flow
entries that reside in the switch will be sent to the controller for
further analysis using Packet In messages. Then, controller can
use this message to generate Flow Mod messages to the switch
so that the subsequent packets will not be sent to controller. We
design our application to do packets filtering process during
Packet In message. Controller inspects over source MAC/IP to
detect MAC/IP Spoofing attack. This is done by comparing the
MAC and IP that are collected from Packet In with the MACIP
binding table that collected earlier in the network startup. The
controller generates Flow Mod based on the result of the
inspection. It will forward legitimate packets and drop
malicious spoofed packets
D. Port Statistic Queries
To detect the DoS attacks, the controller must be able to
detect the events of DoS attacks. The events mean something
that can be used to warn the controller that suspicious behavior
happen in the network. An example of this event is high
density port rate. A drastically sudden change of rate in one or
more ports on the switch is considered as an entry point of DoS
attacks. The controller queries for the port statistics of each
327
3
switch in the networks periodically to monitor byte rate and
packet rate of ports in switches. If their value exceeds the
threshold and there is congestion in the network, the controller
will look up for switch’s flow table to find out if there is high
rate flow entry inside the table. The range of threshold must be
set based on the characteristic of the network. So the value may
be varied. This method can also be used as a step for load
balancing process.
E. Flow Statistic Queries
In order to safely insert security flow into the switch, the
controller needs to know existing flow entries that reside at
each switch. This step is necessary to make sure that there will
not be overlapping or conflict flow rules in the switch. To do
this, the controller sends Flow Statistic Request message
periodically and the switch will reply with their state of flow
table. Then the controller looks up for malicious flow entries,
deletes them, and inserts counter flow entries to block the
attacks or applies Quality of Service (QoS) over it. This step is
complementary step when use port statistic queries, and
substitute of port statistic queries.
F. Port Status
Upon connection starts up between controller and switch,
the controller will query for port status of the switch to find out
which port is used and which link is up/down. The controller
will save the list of active ports for every switch in PortList
hashtable. This information is used to help the application to
detect MAC spoofing attack and build the location tracking
service by assigning only active port into the MACPort
hashtable. After that, the controller keeps monitoring the port
status of the switch and detects if there is change of port states
(e.g. port is up/down, existing user disconnect from the
network, new user connect to the network, switch
connect/disconnection). The value of those two hashtables will
be updated according to the changes.
IV. ATTACKS
The DoS attacks have evolved and become more
sophisticated and hard to detect because they combine with
other attack like, MAC/IP spoofing. This section explains
about the attacks used in this paper and the mechanism to block
such attacks.
A. MAC Spoofing
This attack has a focus on impersonating other host so that
the originality of the source is compromised. By using this
attack on DoS attacks, the original source of the packets will be
hard to locate. This will encourage the attacker to do the
attacks over and over again since the system can’t locate and
block the attacks. The packets filtering and port status features
can be used to block this kind of attack.
Upon network starts up, the controller already learned and
saved all of the connected MAC addresses in the MACList
table. When the controller receives Packet In with a new MAC
address, means that it haven’t showed up on the network
before, it uses MACSwitch and MACPort to check from which
switch and port this message coming from. Then, it checks for
the port status of that port. If there is no port status changing
(i.e, link up/down) report for that port. Then the new MAC
address is considered as a result of spoofing and the controller
will insert flow entries to drop these attacks. If there is port
status changing report, then this new MAC address is the result
of a new device connection, so the controller saves the new
MAC in MACList and MACPort. Thus, process the packets
normally.
B. IP Spoofing
The design method to detect IP address changes may vary
and is adjustable to the network IP environment. In dynamic IP
environment (DHCP), hosts will request for IP to the DHCP
server. Then, the controller can save and lock this IP address in
the MACIP hashtable. The subsequent packets for this host will
be filtered and compared to the previous data stored in MACIP.
If IP changes detected before request of new DHCP request,
then it will be considered as IP spoofing attack and controller
will block this attack.
The implementation of IP static environment in this
application is designed to be more tolerable to IP changes due
to the flexibility of user in manually changing the IP address.
The host can change the IP address during the active state,
without need to plug off the cable and reconnect, and doesn’t
generate port status changing. So the detection will be based on
IP change rate. The application must check for IP changes rate
during Packet In incoming message. Suppose there is 5
changes of IP for a host in 3 seconds. Then, it is considered to
be spoofing attacks and the controller sends Flow Mod
message to block these attacks.
C. Bulky Message
Servers provide some services that most of the hosts used.
Because of this reason, they mostly become the first target of
DoS attacks in the networks. One of the DoS attacks that can
be done towards the servers is sending bulky message to the
servers. This attack overloads the server or at least, makes the
legitimate network throughput become lower. An example of
this attack is sending large file data to the servers.
The controller periodically query for switch statistics to
know about port and flow table information in the switch. The
controller checks for the byte rate of specific ports. If the byte
rate exceeds the threshold, it looks up the flow table and
searches flow entries with high byte rate. Since there is no byte
rate information on the match fields of the flow entry, the
controller calculates it by dividing the number of bytes that the
flow entry received, with the duration of how long have the
flow entry resided in the switch. This seems like a coarse mean
calculation, but this is enough in this case since that the flow
entry will have the idle timeout parameter of 5 seconds which
is a short time.
D. Garbage Message
DoS attacks can also target the switches in the network.
Because OpenFlow switches rely on the controllers in
forwarding packets, we can intentionally flood the switches
with new flow entries. Attackers can send garbage packets to
other nodes so that the controller will insert flow entries for the
328
4
garbage packets and fill up the switch’s flow table. An example
of this attack is sending UDP packets with random UDP
destination port from 0 to 50000. This will result in new 50000
flow entries inserted into the switch.
The controller can detect this attack by inspecting over flow
entries in the switches. The garbage message usually have
characteristic of small byte of data. The priority of this attack is
to generate a high packet rate, not a high byte rate. It is the
opposite of bulky message attacks. The controller looks for
flow entries that have small packet rate and byte rate value and
detects their variation. Thus, the controller sends the counter
wildcarded flow entry to block the attacks.
V. IMPLEMENTATION
Our security application is implemented on Beacon
controller, a Java open source controller. We create a separate
application service which is called ‘bundle’ that implement the
design that already explained in Section 3. We also test the
application using common DoS attacks that already explained
in Section 4. We use Mininet [16] as network simulation,
which is used to create an OpenFlow network environment,
including the Open vSwitch [17] as an OpenFlow virtual
switch. The network traffic, which is used to simulate the DoS
attacks, is created by utilizing the Python API that Mininet
possesses. The attacker, which resides in host 1 on this
example, will run some python script to create aggressive
traffic to specific hosts inside the Mininet. The network
topology is depicted in Figure 3.
Fig. 3. Network topology diagram created at Mininet
VI. EVALUATION
We run our Mininet, Beacon, and Dossy. We open host in
Mininet using xterm command, and start the python script to
simulate the DoS traffics. We can summarize the mitigation
process done by the controller into two actions: quality of
service and blocking state.
A. Quality of Service
The quality of service is giving priority to one service over
other services in the network. We use the QoS to deal with
Bulky Message. The detection of Bulky Message is based on
byte rate counter, so it is hard to make sure whether this high
byte rate packets contain actual network traffic data or just
camouflaged data contain DoS attacks. Therefore, instead of
dropping the packets when high byte rate is detected, we
implement the QoS over the packets. This is done by
modifying the flow entry to have additional action that is called
Enqueue. This will tell the switch to enqueue detected flow
entries.
Fig. 4. QoS during Bulky Message attacks.
Fig. 5. Packet In flooding in the controller due to DoS attack
Fig. 6. Blocking behavior during DoS attack
Figure 4 shows the example of QoS implementation during
the bulky message attacks. We set the mininet to have the
bandwidth around 1.25 MB, so we set the threshold for high
byte rate around 1.2 MB/s. The bulky messages are
implemented by using iperf command. When the controller
detects high data rate at the early seconds, it checks for the
flow table, searches for the flow entry that have high data rate
and applies the QoS to decrease the data rate to 128 KB/s. So
the subsequent flow, from t=7 and so on, will have reduced
data rate. This threshold value is adjustable, and must be set
according to network characteristics.
B. Blocking State
When the controller can find and assure the DoS attacks. It
must block the attack so that the subsequent DoS packets do
not disrupt the network. After the controller detects the DoS
329
5
attacks, it sends Flow Mod messages to the switches to drop
the DoS attacks. The blocking state ends when the attacker
stops the DoS attacks and the flow entry for dropping the
attack expires. This blocking state is implemented to protect IP
spoofing, MAC spoofing, and garbage message attacks.
Figure 5 depicts the behavior of garbage message attacks. It
shows the timeline of how many Packets In messages arrived at
the controller. At t=19, the garbage messages attack starts and
it will result in a lot of Packets In messages sent to the
controller. At t=30, the Open vSwitch can’t keep up with the
speed of the incoming packets and result in a buffer overflow
exception in Beacon controller [18]. This makes the switch
temporarily disconnect and reconnect to the controller, that’s
why the Packet In message at t=30 is zero.
Figure 6 depicts the behavior of the same garbage message,
but using Dossy implementation. When the garbage messages
start, the controller tries to detect this attack and send the Flow
Mod message to drop these attacks. Starting from t=20 the
switch will drop the subsequent packets and in t=22 all of the
subsequent packets will be dropped and the switch will not
send packets in messages for the garbage messages.
Fig. 7. Throughput measurements benchmark
Fig. 8. Latency measurements benchmark
C. Performance
The implementation of Dossy will increase the processing
time to process the packets and increase the workload of the
controller due to additional processing towards the packets and
switches. It can be measured by comparing Dossy to the
normal controller processing. We measure the performance of
Learning Switch bundle (LS) and depicts the throughput and
latency measurements at Figure 7 and 8. We also measure the
throughput and latency of Dossy (DOS) together with Learning
Switch to find out the difference. The measurements are done
by using cbench [19].
Based on the benchmarking result, Dossy will reduce the
throughput of controller by 35% and increase the latency by
21%. We also measure the Learning Switch bundle and Dossy
bundle without Packet In (PI) processing. Disable MAC/IP
filter processing, only leaves periodically switch statistic and
port status processing behind. This improved the result by
7.76% throughput reduction and 7.37% latency increment. This
shows that to get the best result, the algorithm in Packet In
filtering must be simple and detection of DoS attacks must be
done in switch statistic process, which is using port statistic
messages and flow statistic messages. Although the
implementation of Dossy reduces the throughput of the
controller, the throughput still represents good value because
Beacon has high performance [4]. This throughput depicted in
the figure is using one thread of Beacon. It can be increased by
implementing more threads and utilizing more CPU cores.
VII. DISCUSSION
We end our papers with discussion about mitigation DoS
attacks. In this section, we will discuss about the solution of
DoS attacks, what is the best practice to mitigate the attacks,
and see another solution that can be used with this application
and SDN environment to fight together against DoS attacks.
It is already well known that proactive strategy is the best
and possibly the first list of our to-do list to mitigate DoS
attacks. By using the proactive strategy, we can block all the
access that we don’t use in our network (e.g. block all packets
that using unused TCP or UDP ports). At the network startup,
the admin inserts the flow entries to the switches to block this
unnecessary packet, so it will reduce the time needed for the
controller to detect the DoS attacks since it will be blocked by
the switches before sent to the controller.
The source of DoS attacks is also an important thing to be
noted since they can be varied. It could be from malicious user
who intentionally wants to disrupt the network, a host who has
been compromised by attacker to do DoS attacks, and host
infected by malware to do DoS attacks. So it is important to
secure the hosts on the network. The hosts should be installed
with the updated anti-virus or anti-malware system to minimize
the chance of the host to be compromised.
Besides of that, to make sure that we can mitigate the DoS
better, we may set up the Intrusion Prevention System (IPS) in
our network. This IPS can detect and filter the packet based on
its contents, to see whether the packets carry malicious data
(e.g. malware, worm, and virus) or not. IPS is also useful in
defending against external attacks. Suppose we have server
farms in our network that can be accessed from outside, the
controller can act as a firewall to block unnecessary packets,
and IPS block packets which contain malicious data.
Securing against DoS attacks that coming from outside the
network is challenging. The IP Masquerade or Network
Address translation (NAT) makes things more complicated.
The translation process increases the difficulty to detect who is
the actual sender of the packets. The controller will only know
that the packets come from the outermost router of the
networks. The MAC/IP Spoofing that is implemented in Dossy
will only work if the packets come from the host on the
330
network that is governed by the controller, or internal packets.
To detect the DoS attack that comes from external network,
implementation of method in [14] [15] can be used.
ACKNOWLEDGMENT
This research was supported by Basic Science Research
Program through the National Research Foundation of Korea
(NRF) funded by the Ministry of Education, Science and
Technology. (grant number: NRF 2014). And it also supported
by the 2014 NSRI project.
REFERENCES
[1] Z. Kerravala. Configuration management delivers business resiliency.
The Yankee Group, Nov. 2002.
[2] Kreutz, Diego, Fernando Ramos, and Paulo Verissimo. "Towards secure
and dependable software-defined networks." Proceedings of the second
ACM SIGCOMM workshop on Hot topics in software defined
networking. ACM, 2013.
[3] McKeown, Nick, et al. "OpenFlow: enabling innovation in campus
networks." ACM SIGCOMM Computer Communication Review 38.2
(2008): 69-74.
[4] Erickson, David. "The beacon openflow controller." Proceedings of the
second ACM SIGCOMM workshop on Hot topics in software defined
networking. ACM, 2013.
[5] Buskirk, Eliot Van. (2009, Ags 06). Denial-of-Service Attack Knocks
Twitter Offline (Updated) [Online]. Available: http://goo.gl/7Csnh8
[6] Buskirk, Eliot Van. (2009, Ags 06). Facebook Confirms Denial-of-
Service Attack (Updated) [Online]. Available: http://goo.gl/hKaI0V
[7] Messmer, Allen. (2014, Jan 14). Massive denial-of-service attacks pick
up steam, new nefarious techniques [Online]. Available;
http://goo.gl/hBjy6v
[8] Cid, Daniel. (2014, Mar 10). More Than 162,000 WordPress Sites Used
for Distributed Denial of Service Attack [Online]. Availbale:
http://goo.gl/hvJ0uV
[9] Wang, Haopei, Lei Xu, and Guofei Gu. "OF-GUARD: A DoS Attack
Prevention Extension in Software-Defined Networks."
[10] Shin, Seungwon, et al. "AVANT-GUARD: scalable and vigilant switch
flow management in software-defined networks." Proceedings of the
2013 ACM SIGSAC conference on Computer & communications
security. ACM, 2013.
[11] Porras, Philip, et al. "A security enforcement kernel for OpenFlow
networks." Proceedings of the first workshop on Hot topics in software
defined networks. ACM, 2012.
[12] Shin, Seungwon, et al. "FRESCO: Modular Composable Security
Services for Software-Defined Networks." NDSS. 2013.
[13] Dover, Jeremy M. “A denial of service attack against the Open
Floodlight SDN controller”. Dover Networks LCC.
[14] Gkounis, Dimitrios. “Cross-domain DoS link-flooding attack detection
and mitigation using SDN principles”. M.S. thesis. Institute of
Technology Zurich. 2014.
[15] Braga, Rodrigo, Edjard Mota, and Alexandre Passito. "Lightweight
DDoS flooding attack detection using NOX/OpenFlow." Local
Computer Networks (LCN), 2010 IEEE 35th Conference on. IEEE,
2010.
[16] Mininet. Available: http://mininet.org/
[17] Op en vSwitch. Available: http://openvswitch.org/
[18] Buffer Overflow Exception. Available: http://goo.gl/atZGsO
[19] Cbench. Available: http://sourceforge.net/projects/cbench