2017 8th International Conference on Information Technology (ICIT)
The Effects of DoS Attacks on ODL and POX SDN
Controllers
Huseyin POLAT
Computer Engineering Department
Gazi University
Ankara, Turkey
polath@gazi.edu.tr
Abstract—The use of Software Defined Network (SDN) in
recently networking architecture has brought tremendous
advantage in computer networking technology. Administrative
issues such as routing, security and load balancing can be
centralized and automated in SDN controllers. Controllers have
been an integral part of the SDN architecture enabling intelligent
networking. However, because all the packets are transmitted to
the controller, any flooded packet from an attacker who gets
access to SDN network may lead to Denial of Service (DoS)
attack. In this paper, the effect of DoS attack on bandwidth of
two communicating hosts in SDN network for Opendaylight
(ODL) and POX controllers was investigate. We observed that
the bandwidth was reduced as attack increases and the response
time was also too high. We also find out that, even after a flow
table has been installed in switch, it was impossible for it to be re-
installed again if a flow timeout has been reached due to a
controller handling too many packet-in events and error
notification from the switches.
Keywords—SDN;Controller; Opendaylight; POX; DoS
I. INTRODUCTION
While computer sciences have significantly advanced in the
last 10 years, principles of networks have not seen much
change. The growing and developing data centers and the ever-
changing needs of the world of informatics have shown that the
traditional approach will no longer be sufficient in network
management. Technologies like cloud-computing,
virtualization, mobility which have been rapidly developing
especially in recent years have made network management
more dynamic and open to integration with new structures.
Applications running over a distributed architectural structure
and the diversity of the new generation devices of users
utilizing these applications paved the way for necessity of
managing networks easily without the need for personnel
support.
Another important issue is network management in
growing and ever-complex data centers. More proactive
solutions now are being created world-wide to overcome these
issues. The rapidly changing and ever developing diverse
services makes it an obligation to advance alternatives in
network management. Firms in the field that are still using the
traditional approach should consider the necessity to improve
their systems along with new network management
978-1-5090-6332-1/17/$31.00 ©2017 IEEE
Onur POLAT
Computer Engineering Department
Gazi University
onurpolat@gazi.edu.tr
technologies. The fundamental elements of network
management technologies may be listed as security,
performance management and control. An approach to network
management outside these elements will lead to disruption of
the understanding of the already rapidly changing and
developing services. With a new architecture, SDN has taken
the place of traditional networks due to their capability in
easily and rapidly responding to new developments.
In SDN architecture, network control and forwarding
functions are separated from each other. As network control
has become directly programmable, the devices constituting the
infrastructure of the network (switch, router, etc.) are isolated
from network services. This isolation allows applications and
network services to see the network as a single logical entity
[1]. One of the greatest advantages brought by SDNs is the
separation of the data and control planes and management of
the network by a central controller. This manner, it has been
made easier to make changes on the network due to the
management and programmability of the network. In
comparison to the traditional networks in terms of security, the
most noticeable characteristic is that network-traffic
information related to devices in the network may be collected.
This provides greater advantages in detecting bad traffic [2].
Despite the advantages, there are also genuine threats of
security problems brought about by SDNs. The most prominent
of these are attacks on the controller; which is the brain of the
network. If anyone reaches the controller, he/she may reach the
entire network, therefore overtaking the control of the entire
network. Similarly, DoS attacks on the controller also create a
great threat. DoS attacks are usually in the form of spoofed
traffic. They may be against a switch or a controller on the data
plane. They consist of transfer of bunch of packets to PCs
(personal computers) or servers. If the packets are spoofed, the
switches look at the rules determined by the controller on the
flow table and send the packets to the controller if there is no
mapping. The legitimate and spoofed packets that are collected
by the switches and sent to the controller, saturates the
resources of the controller hence making the entire network
unusable. These attacks may cause SDN architecture to crash
or prevents the controller from installing a flow table for
legitimate packets that need to reach a controller or a certain
destination.
554
2017 8th International Conference on Information Technology (ICIT)
II. RELATED WORKS
OpenFlow protocol in SDN network provides the
communication between the data plane and controller through a
secure channel (such as SSh and IPsec). One of the DoS attacks
carried out in SDN is the packets that are sent to OpenFlow
switches using fake addresses. Secure channel used in
OpenFlow protocol cannot prevent this kind of attack. In this
case, all sent packets from the switch could reach a controller.
As the number of the packets sent to the controller increases,
its resources (bandwidth, CPU) begins to depreciate. The
controller whose resources are depreciated becomes congested.
The result is that the controller as a brain of the network when
is congested, the whole network collapses.
The researchers have investigated the various methods
exploited in different vulnerability attacks on DoS in SDN
networks. K. Cabaj et al. [3] highlighted the characteristics of
SDN networks in relation to security. In order to implement a
secured security system in SDN networks, they suggested three
critical aspects that should be considered. First, a limited
feature provided by an OpenFlow protocol, which provides
communication between data plane and controller. Second,
global network view that should be monitored by a single point
and lastly no support should be provided for additional
applications like middleboxes, NAT or firewall in the
architectural structure of SDN. On the contrary, SDN
architectures may include additional applications like load
balancing, routing, firewall, middleboxes and NAT through
northbound API.
The study of Jeremy M. Dover [4] tried to exploit the
vulnerability in the Open Floodlight controller. He
demonstrated that an attacker with access to the OpenFlow
control network can selectively deny or disabling
communication between an individual forwarding plane with a
controller by using datapath_id or dpid. The attacker data plane
will boot using the same datapath_id being used by a legitimate
data plane forcing the controller to terminate connection with
the legitimate one. If the attacker purposely intended to deny
the legitimate data plane access, it will rationally do it in a
tighter cycle than the legitimate data plane.
While Seungwon and Guofei Gu [5] noted that an attack on
SDN network by use of fingerprint attack can be recognized by
the different response time from the SDN network when there
is no flow for a packet and when there is a flow. Knowing the
target network is using SDN and the condition of the flow rule,
the attacker can send a packet to consume SDN resources.
In Kevin Benton et al. [6] explained the lack of support of
TLS in most of the types of switches and controllers used in
SDN network. They illustrated that a controller or whole SDN
network may be exposed to DoS attacks with Packet-In
messages when the reactive rules designed are not carefully
implemented. They illustrated this by showing a l2_learning
component in POX controller which usually leaves a
possibility of many attacks like traffic flooding of a multicast
address; a traffic to unknown MAC address is flooded without
a rule insertion or a limit counter and filling up a switch flow-
table by crafting packets with random source MAC addresses.
Charu P.P and Mary John [7] created a framework tool to
conduct organized SYN flooding attack on SDN network. In
their study, three hosts were used, a malicious user, Dos attack
user and frequently user were used to attack the SDN network.
The malicious user injects spoofed packets to the switch
infinitely with destination IP address generated randomly. DoS
attack user sends spoofed packets to the switch infinitely with a
source and destination IP addresses that are generated
randomly. The frequent user establishes normal connections to
the server. However, no metrics were taken to measure the
effect of these attacks on SDN network.
On the other hand, Kandoi, R. and Markku A. [8] studied
two types of DoS attacks specific to OpenFlow SDN networks;
attack on the control plane bandwidth and attack on the
switch’s flow table. They found out that the timeout value of a
flow table and the bandwidth between a switch and controller
had significant impact on the switch’s capability. However,
their study was only focused on POX controller and did not
include other metrics such as switch buffer. To add on, the
effect of bandwidth between two communicating hosts was not
explained, if all the attacks were to be performed
simultaneously.
III. SOFTWARE DEFINED NETWORKS
The idea of SDNs was developed by Stanford University
based on the OpenFlow protocol. SDN as it may be understood
from the name, it provides an architectural structure that allows
for the control of the network with the help of a program. SDN
brought a new outlook to computer networks with a series of
values added through the virtualization. SDN as shown in Fig.
1 separates the control and data planes from each other. The
devices become a transfer element, which transmits basic
packets. Packets transmission decisions are not target-based,
but flow-based. A flow may be roughly defined as package
field values acting as matching (filtering) criteria with a set of
actions [9].
In the SDN/OpenFlow framework, a flow is a set of packets
that matches between a source and a target. The same service
protocols are applied to all packets flow on all transmission
devices. The flow allows combination of different types of
network devices such as routers, switches, firewalls and
middleboxes to make decision on packets. Flow programming
provides an unprecedented flexibility achieved only through
the flow tables used. The control logic is isolated from network
devices and may be carried to an external resource.
SDN controller is a software platform that works with a
commercial server technology and provides the necessary
resources and virtualizations based on logic-based and virtual
network outlook principles. Therefore, its purpose is similar to
those of traditional operating systems. The network is
programmed to run software applications over the network
operating system. In the process, interacting with devices under
the data plane made possible through an OpenFlow protocol.
This is the most fundamental characteristic of SDNs.
Centralizing the control logic has many advantages like;
providing a single point of control and policy over the entire
555
2017 8th International Conference on Information Technology (ICIT)

network. It also reduce the operating cost by administratively h1 up to h6 was used for flooding packets to controller with a
control the enterprise operations in one point. random source IP addresses.
Routing Firewall Load balancing

Abstract Network viewa Remote SDN Controller

Northbound API

Network Abstractions
CONTROL PLANE

Global Network view

SDN controllers

h1 S1
S1 s2
s2 h6
h6
Southbound API

h3
h3 h4
h4
Client
Client – h100
h100 h2
h2
h5
h5 Server –– h200
h200

DATA PLANE Fig. 2. Network Model

In this study, hping3 tool was used to simulate a DoS attack

to SDN controller. Hping3 is a packet generator and analyzer
Fig. 1. SDN Architecture for the TCP/IP protocol. This tool can be used for security
IV. DOS ATTACK TO SDN CONTROLLERS
auditing, testing of firewalls and networks. In Fig. 3 hping3 has
many options to be included but for the sake of this study some
In SDN, DoS attack is an attempt to make network devices of them were omitted. The options used in this study are
like controllers, computers, routers, switches, servers or explained in Table 1.
network resource unavailable to its intended users. Attack in
SDN controller aims at making it hard for the controller to TABLE I. HPING3 OPTIONS AND EXPLANATION
handle all the requests. It also aims at installing fake flow hping3 Description
tables, which are useless to the data plane devices thus making --flood Flooding mode.
it impossible for the data plane devices to store flow table for --rand-source Using Random Source IP Addresses.
legitimate packets [8, 10]. 10.0.0.5 Destination IP address of a target machine.

Normally in SDN, every packet received in port of a switch

is matched with the existing flow table. If a flow-table exists Node h1 in Fig. 3 floods the packet with a random source to
for a packet then a packet is forwarded to outgoing port, a destination Node h5. The aim is to flood a controller with a
otherwise a packet is stored in a buffer and a packet header is bunch of packets using Packet-In event. These packets are
forwarded to the controller using OFPT_PACKET_IN. When a received in the switch with different IP addresses, which results
controller is previously known to be on the outgoing port, a in a missed flow and is automatically forwarded to a controller.
flow table is installed to the switch by using
OFPT_FLOW_MOD otherwise flooding a packet to all switch
ports except an incoming port of a switch to learn the
destination.
The packet with a different source IP address means that
most of the packets will lead to packet miss in the switch flows
tables because of the packets being forwarded to the controller.
In this case, a controller will be flooded with many packets to
process and writing a flow table back to the switch. However, Fig. 3. DoS Attack using hping3
the switch buffers may run out of memory because of
overloading with useless flow table. As a result, no more flow Wireshark in Fig. 4 shows a bunch of packets with different
table will be installed in the switch. This bottleneck to the IP addresses forwarded from a switch to a controller using
controller may result in many packets being dropped hence low OpenFlow protocol. The packets forwarded to a controller is
throughput and a longer delay in the network. approximately 2000 packets/sec more than needed.
V. SIMULATION OF DDOS ATTACK
Fig. 2 show a network topology simulated in Mininet-VM-
2.2.1. A topology consists of one remote controller
(Opendaylight (ODL) or POX controller) and two OVSKernel
Switch of which, each is connected with four hosts and has a
connection speed of 2 Gbps. The connection between hosts and
switch were set to 100 Mbps. Host h100 and h200 was used
purposely for testing the bandwidth using iperf command. Host

556
2017 8th International Conference on Information Technology (ICIT)
Fig. 4. Wireshark Result
VI. SIMULATION RESULTS
In this part, the effect of DoS attack in SDN controller was
measured by testing a TCP Bandwidth between two hosts
(Node h100 as a client and Node h200 as a server listening on
port 5001) using iperf command. An iperf is a tool that
measures bandwidth, jitter, loss rate and other parameters of
network link. We launched hping3 attack after starting iperf
command between h100 and h200. The results obtained from
this command are as discussed below.
A. DDoS Attack on ODL Controller
Fig. 5 shows a TCP Bandwidth between Node h100 and
Node h200 when ODL controller was running as a remote
controller for our network model. It is clearly seen that the
flooded packets to the controller affect TCP bandwidth
between these two hosts. ODL proactively installs default flow
tables in the data plane, but these flow tables cannot avoid
flooded packets to reach the controller. From our investigation,
as the time for waiting for response from the server increases, it
affects the bandwidth between the hosts. Additionally, time
taken to receive a response was too large compared to the real
time used in iperf command.
Fig. 5. TCP Bandwidth during ODL controller
B. DDoS Attack on POX Controller
Using l3_learning component in POX controller, no default
flow table is installed by controller unless a controller learns
them when Packet_In event is triggered. In Fig. 6 result shows
that a TCP bandwidth between Node h100 and Node 200,
when no attack is significantly higher than when there is one
host attack and two hosts attack. Results showed that as the
number of flooding host attack increases, a negative impact on
the bandwidth between these hosts is seen.
Fig. 6. TCP Bandwidth during POX controller
VII. CONCLUSION
In this paper, we investigated the DoS attack in ODL and
POX controller and how it affected the bandwidth between two
hosts in SDN network. A low bandwidth result was shown
from the results on ODL and POX controller after launching a
DoS attack. Even after a legitimate user has established a
connection with a server, a DoS attack still negatively affected
a bandwidth of hosts. This effect is due to lack of insufficient
memory to add a flow table for a legitimate user in the switch
after a flow timeout has reached. The controller congestion
when processing packet-In event and trying to install flow
tables whose buffer has been removed from a switch is also
another reason for the negative effect.
These attacks may be prevented by implementing a packets
rate limiter to prevent any traffic that isolates the SDN
architecture. However, this should be implemented carefully
especially if a network consists of many hosts accessing the
same server at a time. To avoid this, a flow aggregator may be
used depending on the target host or application.
REFERENCES
[1] Jain, Raj, and Subharthi Paul. "Network virtualization and software
defined networking for cloud computing: a survey." IEEE
Communications Magazine 51.11 ,pp. 24-31,2013.
[2] Scott-Hayward, Sandra, Gemma O'Callaghan, and Sakir Sezer. "SDN
security: A survey." Future Networks and Services (SDN4FNS), 2013
IEEE SDN For. IEEE, 2013.
[3] Cabaj K, Wytrebowicz J, Kuklinski S, Radziszewski P, Dinh KT. SDN
Architecture Impact on Network Security. InFedCSIS Position Papers
pp. 143-148, 2014 Sep
[4] Dover, Jeremy M. "A denial of service attack against the Open
Floodlight SDN controller." 2013.
[5] Shin, Seungwon, and Guofei Gu. "Attacking software-defined networks:
A first feasibility study." Proceedings of the second ACM SIGCOMM
workshop on Hot topics in software defined networking. ACM, 2013.
[6] Benton, Kevin, L. Jean Camp, and Chris Small. "Openflow vulnerability
assessment." Proceedings of the second ACM SIGCOMM workshop on
Hot topics in software defined networking. ACM, 2013.
[7] Charu P. P, and Mary John. “ A Framework for Design and Simulation
of DoS attacks on SDN Network.” Internation Journal of Innovative
Research in Computer and Communication Engineering. 2016 Feb (pp.
2030-2036).
557
2017 8th International Conference on Information Technology (ICIT)
[8] Kandoi, Rajat, and Markku Antikainen. "Denial-of-service attacks in
OpenFlow SDN networks." Integrated Network Management (IM), 2015
IFIP/IEEE International Symposium on. IEEE, 2015.
[9] Kreutz, Diego, Fernando MV Ramos, Paulo Esteves Verissimo,
Christian Esteve Rothenberg, Siamak Azodolmolky, and Steve Uhlig.
"Software-defined networking: A comprehensive survey." Proceedings
of the IEEE 103, no. 1 ,pp. 14-76,2015.
[10] Shin, Seungwon, and Guofei Gu. "Attacking software-defined networks:
A first feasibility study." Proceedings of the second ACM SIGCOMM
workshop on Hot topics in software defined networking. ACM, 2013
[11] Shea, Ryan, and Jiangchuan Liu. "Understanding the impact of denial of
service attacks on virtual machines." Proceedings of the 2012 IEEE 20th
International Workshop on Quality of Service. IEEE Press, 2012.
[12] Schuchard, Max, et al. "Losing control of the internet: using the data
plane to attack the control plane." Proceedings of the 17th ACM
conference on Computer and communications security. ACM, 2010.
[13] Sim, Yumin, and Hae Young Lee. "Poster: Denial-of-Service Attack
Using Host Location Hijacking in Software-Defined Networks."
558