Toward Secure Software-Defined Networks Against Distributed Denial of Service Attack

The Journal of Supercomputing
https://doi.org/10.1007/s11227-019-02767-z
Toward secure software‑defined networks

against distributed denial of service attack
Kshira Sagar Sahoo1 · Sanjaya Kumar Panda2 · Sampa Sahoo1 ·

Bibhudatta Sahoo1 · Ratnakar Dash1
© Springer Science+Business Media, LLC, part of Springer Nature 2019
Abstract
The newly emerged software-defined networking (SDN) paradigm provides a flex-
ible network management by decoupling the network control logic from the data
plane, which could effectively resolve many security issues of legacy networks. One
of such security issues is distributed denial of service (DDoS) attack, which is a rap-
idly growing network threat. This is usually performed on a target system to make an
online service unavailable to the users. SDN can easily detect the DDoS attack due
to the centralized control provisioning and network visibility. At the same time, the
changes of fundamental architecture and the developments of various design entities
pose a severe DDoS threat to the SDN platform. This paper presents a concise up-
to-date review of security concerns of SDN, possible DDoS attack in individual lay-
ers of SDN and ongoing research efforts on SDN-enabled DDoS detection solutions.
Based on the findings, an information distance-based flow discriminator framework
has been discussed, which can discriminate the DDoS traffic during flash events,
a similar looking legitimate traffic, in SDN environment. The information distance
metric is used to describe the variations of traffic behavior of such events. The simu-
lation results show that the information distance metric can effectively identify the
DDoS traffic in comparison with other metrics with a higher detection rate. The pro-
posed solution can detect the traffic at the edge switch so that the attack alert can be
raised at the earliest.
Keywords Software-defined networking · Distributed denial of service attack ·

Security threat · Security attack · Infrastructure layer · Control layer · Application
layer
* Sanjaya Kumar Panda

sanjayauce@gmail.com
Extended author information available on the last page of the article
13
Vol.:(0123456789)
K. S. Sahoo et al.
Size of Companies Hit by DDoS Attack

30
25
Percentage
20
15
250-499 500-999 1000-4999 5000-9999 10000+

Number of employees
Fig. 1 Size of companies hit by DDoS attack (Incapsula Survey [11])
1 Introduction
The Internet has created a new revolution in our world. It is an important part of
human life and it reshapes the technology, business, communication, society, eco-
nomic and many more. However, it increases the level of risk in its services and
usage. Therefore, it is indeed essential to adopt a proper defense mechanism in order
to avoid the theft and fraud. Many organizations, governments, corporations, high-
profile companies and industries are investing a substantial amount for this vital
issue. Internet security becomes a top-notch research topic among academic and
industry experts. More specifically, availability-related security threats are the most
essential discussed topic. The reason is that the modern Internet-connected society
expects the intended services without any interruption. Here, downtime can create
user dissatisfaction, which directly affects the business model of the Internet service
provider.
Distributed denial of service (DDoS) attack is an availability-related attack,
which can lead to massive interruption in the network infrastructure [1–3]. Nota-
bly, in the modern virtualized environment, attackers’ target to the network infra-
structure, which creates a severe peril [4–7]. Therefore, the current cyber infrastruc-
ture requires an innovative and efficient defense system to the severity of the DDoS
attack. Without any defense system, this can paralyze the cyber system by crippling
the bandwidth, network devices, storage or server by launching malicious traf-
fic. Although numerous state-of-the-art techniques have been developed for detec-
tion and mitigation, the severity and frequency of this attack are still growing. As
a consequence, it creates negative consequences for the current information tech-
nology (IT) industries [8–10]. For instance, in North America, Incapsula [11] has
performed a survey of 270 organizations in which the number of employees ranges
between 250 and 10,000. The survey concludes that the DDoS attack results in an
average cost of $40,000 per hour to the companies, due to the DDoS attack. The sur-
vey also exhibits that most of the mid-cap companies are the victim of such attack as
shown in Fig. 1. The lack of effective planning to mitigate DDoS assault, shortage of
13
Toward secure software‑defined networks against distributed…
skilled manpower and believe on antiquated firewall-based solutions are the prime
reasons of DDoS penetration in the small and medium-sized organizations. Many
reports also indicate that most of the cyber criminals cause such events for gaining
access to valuable corporate data as well as to cripple down the organization’s ser-
vices and reputations. Consequently, the organizations spend nearly a half million
dollars in their business for fast re-establishment and bear the non-financial costs,
such as intellectual property loss, customer trust malware contamination and many
more [12–14]. The current DDoS trends make it apparent that yesterday’s strategy
was no longer defensible. Therefore, organizations require more advanced, system-
atic tools and efficient methods to overcome this threat. With the emergence of soft-
ware-defined networking (SDN) paradigm, many organizations attract to adopt SDN
technology as an essential security solution. The revolutionary concept of SDN
solves the long-standing ossification problem in networking. The centralized control
logic, software-enabled traffic monitoring capability and dynamic updating of flow
make SDN detect DDoS attack efficiently. However, the separated centralized con-
trol logic and programmability introduce new attack points to the different layers of
SDN.
In this paper, we discuss an up-to-date overview of various DDoS threats and
their countermeasures related to the individual layer of SDN, followed by SDN-
supported DDoS solutions proposed by different researchers. SDN-supported DDoS
solutions use a variety of techniques to combat DDoS attacks in the traditional net-
works. We found that identifying high-rate (HR) DDoS attack during flash events
(FEs) is a hot research topic in the legacy network, but it has paid little attention to
SDN. Although FE is similar to HR DDoS attack, they have few parametric differ-
ences. The information theory-based metrics, such as entropy and information dis-
tance, can identify the variations in the traffic behavior of such events. The above
facts motivate us to propose an informed distance-based flow discriminator (IDFD)
framework, which runs in the edge switch and helps to predict the attack traffic,
before it enters into the network.
The prime contributions of this paper are presented as follows.
• We develop the conceptual idea of SDN architecture. Then, we classify different

DDoS attacks in the traditional networks.
• SDN has various typical features, which make it a major enabler to defend
the DDoS attack. Therefore, we identify the research efforts toward the DDoS
defense mechanism using SDN.
• The centralized control and new entities make SDN more vulnerable. For
instance, a DDoS attack on the controller can defunct the entire network. There-
fore, we present an up-to-date DDoS attack in SDN and classify them accord-
ing to various layers of SDN. Next, we focus different solutions to the threats as
developed by the researchers.
• An information distance-based flow discriminator framework has been proposed
to address the DDoS attack from FEs at the edge device.
The remainder of this paper is organized as follows. In Sect. 2, we highlight the

basic SDN architecture followed by various challenges of SDN in Sect. 3. Section 4
13
K. S. Sahoo et al.
discusses possible security threats and attacks to SDN layers, respectively. Section 5
discusses the taxonomy of DDoS attacks. Section 6 covers the overview of DDoS
attack in SDN. Section 7 presents the potential countermeasures for DDoS attack. In
Sect. 8, we discuss various techniques used for DDoS attack followed by presenting
a detection framework in Sect. 9. We discuss the future research direction and con-
clusion in Sects. 10 and 11, respectively. The general layout of this paper is shown
in Fig. 2.
2 Background of SDN
An Internet protocol (IP)-based network comprises a series of interconnected

devices, such as routers and switches. The conventional router runs a particular
routing module to determine where the incoming traffic must be sent. The routing
algorithm primarily determines the next hop router for the efficient packet delivery.
It usually performs two important tasks. The first task is to apply high-level rout-
ing algorithms for incoming traffic and always keep updating the network topology,
which is referred to as control plane service of the router. The control plane is man-
aged by the locally stored routing tables. The second task is to take forwarding deci-
sions about the incoming traffic based on routing tables, which is referred to as the
data plane service of the router. The conventional routing mechanism needs a lot of
processing burden on the router. In this regard, the traditional communication sys-
tem becomes computationally expensive for the future demand of traffic. In order
to design a viable solution which can satisfy the traffic requirements, the SDN is
considered as the pivotal solution. The basic functionality of a conventional router is
shown in Fig. 3.
Survey Overview
SDN Major Chal-

Background lenges in SDN
Possible Secu- Possible Secu-

rity Threats rity Attacks
DDoS
DDoS in Tradi- DDoS

tional Networks in SDN
SDN as a SDN as a Detection and Mit- Proposed

DDoS Solution DDoS Victim igation Techniques IDFD
Fig. 2 Layout of the paper
13
Fig. 3 Conventional router

comprises of both control and
data plane
The emergence of SDN architecture is designed with a hope to overcome the bur-
geoning demand and requirement of the next-generation networking [15–17]. It per-
mits both the applications and the network elements to connect each other through
a standardized protocol like OpenFlow (OF) [15]. Some of the mechanisms, such as
routing decisions and packet forwarding functionalities, are shifted to the centralized
controller from the underlying hardware devices, which manages the network traffic
through the programmable interface [18, 19].
2.1 Layers of SDN
In this subsection, we provide the fundamental discussion on different layers of

SDN, so that readers can visualize the security concerns about the SDN infrastruc-
ture more conveniently. As per open networking foundation (ONF), SDN can be
segregated into three different layers [20]. Figure 4 illustrates the basic architecture
of SDN, which consists of the following layers [17].
1. Infrastructure layer The infrastructure layer (data plane) comprises the underlying
network infrastructure as well as devices, such as routers and switches [21]. The
role of switches is to forward packets based on the controller’s routing policy. In
order to achieve this, each underlying device maintains forwarding tables. The
entries in these tables are basically forwarding rules that are imposed by the
controller. Currently, there are several SDN-enabled hardware as well as soft-
ware switches designed by the networking hardware vendors. For example, OF
vSwitch, Indigo and openWrt are the available software switches that are gener-
ally meant for creating test bed and developing SDN applications. Some of the
SDN-supported hardware switches are listed in Table 1. For better readability, we
use the term forwarding layer, infrastructure layer and data plane, interchangeably.
2. Control layer While a conventional router manages both data and control plane
simultaneously, SDN moves a router’s control plane to an external network entity,
called controller [20, 30]. This layer is responsible for monitoring and managing
the network. For this, it has a control logic like switching, routing, layer 2 virtual
private network (L2 VPN), layer 3 virtual private network (L3 VPN), firewall
security rules, domain name system (DNS), etc.
The software-based controllers are providing custom policies and high-level
routing algorithms to the underlying infrastructure layer. Some well-known con-
trollers developed by the industry as well as academia are Floodlight [31], Open-
13
K. S. Sahoo et al.
Fig. 4 Basic SDN architecture [17]
Daylight (ODL) [32], POX [33] and NOX [34]. Some well-known controllers and
their brief descriptions are listed in Table 2.
3. Application layer It provides end user business applications that deploy the net-
work services [39]. There are several types of applications can be developed in
this layer. These applications are related to network management, network moni-
toring, intrusion detection system (IDS), load balancers and network virtualiza-
tion. These applications can provide various end-to-end solutions for real-world
data center and enterprise networks. The network vendors are coming up with new
ideas in the form of SDN applications, which are listed in Table 3. For example,
Brocade Inc. [23] provides applications like virtual router, flow optimizer, etc.,
and Hewlett Packard enterprise (HPE) SDN app store [24] provides applications
like network protector, HPE network visualizer, etc. [47].
2.2 Interfaces of SDN
The controller can communicate with the three layers through some standard open
interfaces. The northbound application program interface (API) represents the
interface between the controller and the application layer. The application develop-
ers can manage the network through the API. Frenetic and Pyretic support modular
programming that helps to program the network devices [48, 49]. The southbound
interface makes a communication channel between the controller and the underlying
13
Table 1 SDN-enabled commodity switches made by network device makers
Vendor Model OF version
Pica-8 [22] P-3290, P-3295 It is a switching platform with Linux and integrated seamlessly with the existing network. It supports OF
1.4v.
Brocade [23] MLXe, CER, CES Brocade has released these switches with OF 1.3v for research and education purpose. It provides a wide
range of features, such as group table, IPv6 and quality of service (QoS).
HP [24] 3800, 5400zl HP switch series is a family of nine fully managed Gigabit Ethernet switches. It is available in 24-port
and 48-port models, with or without power over Ethernet plus (PoE +) and either small form-factor
pluggable plus (SFP +) or 10GBASE-T uplinks. It employs the latest ProVision application-specific
integrated circuit (ASIC) technology with OF 1.3v. It automatically configures the switch with various
settings, such as virtual local area network (VLAN), class of service (CoS) and power over Ethernet
(PoE) max power.
Brocade [25] ICX, VDX Brocade switch series supports OF 1.3v and makes operators to address complex network behavior and
optimize performance. It also supports metering, enqueues, group table, QinQ, active-standby control-
ler and time to live (TTL).

Extreme networks [26] EXOS The EOS series supports OF 1.3v. The group table is only supported for multi-protocol label switching
(MPLS) flows. It enables normal and OF controlled traffic to send and receive on the same VLAN port.
IBM [27] RackSwitches G8264, G8264T It is enabled with OF 1.1v and OF 1.3v and supported VMready and Virtual Fabric for virtualized
systems with dynamic optimal performance. The hardware supports up to 64, 10 GB SFP + ports in a
1U form factor.
Juniper [28] EX, MX Some of the series of Juniper support OF 1.0 v and some of the recent release product support 1.3.1v. It
also supports hybrid interface, MPLS and multi VLAN.
Arista [29] 7150, 7300 It supports OF 1.0v, and performs ultra-low latency and balanced set of resources for low latency finan-
cial markets, virtualized data centers, big data and cloud platforms. It is the first product to support
sub-microsecond network address translation (NAT).
13
13
Table 2 Popular SDN controllers and their descriptions
Controller Developer Description
NOX [34] Nicira It is open source and written in C++ and Python.
POX [33] Nicira It is a Python-based open source controller. It supports graphical user interface (GUI) and visualization
tools.
Beacon [35] Stanford university It is open-sourced, cross-platform and modular controller. It supports thread and event-based operation.
It is built upon Spring and Equinox open service gateway initiative (OSGi), which are Java-based
platform.
Floodlight [31] Big switch networks It supports representational state transfer (REST) API. As a result, it is easier for developers to built
applications easily and interface with the real hardware. It can compatible with both SDN-enabled and
traditional switches.
OpenDaylight [32] Multiple developer It is Java-based, modular, multi-protocol, REST API supported and open source platform for customizing
networks of any size.
RYU [36] VA Linux and NTT OSRG It is a Python-based well-defined API. It makes easier for developers to build new network management
applications. It supports various southbound protocols, such as Netconf, OF and OF-config, to support
network devices.
MUL [37] KulCloud It supports various southbound protocols, such as OF, OF-config and ovsdb, and provides a very stable
platform. It is written in C and intended for mission-critical networks.
Trema [38] NEC It is written in Ruby and C programming languages. It provides a framework for the users to build an OF
controller of their choice.
K. S. Sahoo et al.
Table 3 Commercial products of application layer
Vendor Application Description
Brocade [40] Flow optimizer It is an open and policy-based SDN solution that identifies and handles the traffic flows from layers 2 to 4
in the enterprise networks. This application also helps customers to optimize their network infrastruc-
ture, improve network resource utilization and capacity planning.
Brocade [41] Network advisor This application automates various tasks across the network, which simplifies storage management. The
storage management carries out by monitoring both small computer system interface (SCSI) and non-
volatile memory express (NVMe) storage input/output (I/O) condition with customizable dashboards.
Aricent [42] Routing service This application selects multiple paths to the same destination. It allows load balancing across the differ-
ent paths chosen for the same destination. Besides, this application can pre-calculate the alternate path
and assign priority based on the quality of the link.
HP enterprise [43] Network optimizer It provides a flexible solution to monitor the Skype for the business calls. Through this application, the
network administrator can troubleshoot the problems and optimize the quality of the business calls by
leveraging the previously recorded data.
HP enterprise [44] Network protector The application uses the HP virtual application networks (VAN) controller with security intelligence
from HP tippingpoint reputation digital vaccine (RepDV). The entire system turns the network infra-
structure into security-enforcement devices, which renders visibility and threat protection against more
than 1 million malicious malware, botnets and spyware sites.
Tech Mahindra [45] Server load balancer It leverages the end-to-end network visibility and network delay parameters to en-route the traffic effi-
ciently.
HP enterprise [46] Network visualizer The HP VAN SDN controller provides dynamic traffic capture with real-time network monitoring.
13
K. S. Sahoo et al.
forwarding devices. Till now, OF is the standardized protocol supported by ONF and
it is widely used in southbound interface. In a multi-controller-based SDN architec-
ture, each controller has its own network view. Here, SDN utilizes east-west proto-
cols to communicate and exchange topology information with the other controllers.
2.3 Advantages of SDN
The separation of control plane from data plane has many advantages as follows.
• The programming capability of SDN helps to control and manage the network
efficiently.
• The resource virtualization [50–56] and decoupled architecture help SDN to
work in a cross-tenant environment, such as data center and cloud.
• The network devices can be available with lesser cost because of the separation
of the control logic. Thus, service operators minimize their operational expendi-
ture (OPEX) by using such network devices.
• The forwarding information base (FIB) of SDN can discover the better path for
the forthcoming traffic without the presence of expensive network devices.
• As the control logic is a separate entity, a network administrator can further
experiment the network configurations without considering the actual backplane
[19, 57].
• It simplifies network design, because the instructions are set by the controllers
rather than multiple vendor-specific devices and protocols.
• SDN filters the traffic, before it proceeds to the network system. The edge
switches are acting as firewalls for the entire network system.
Moreover, the essential features of this newly emerged paradigm provide a flex-
ible, innovative, vendor-agnostic and cost-effective network architecture.
3 Major challenges in SDN
Although SDN provides many benefits to the enterprises and the cloud providers, it
faces a lot of real-life challenges. They are described as follows.
• Reliability In the traditional network, when a node or link fails, the network traffic
is routed to a nearby available node or link to maintain the flow availability. How-
ever, in centralized SDN architecture, if the controller fails, the entire network may
be collapsed. To address this issue, network designers introduce multi-controller
concept in SDN. To avoid primary path failure (the path between switch and con-
troller), SDN must support multipath connectivity for faster rerouting of the traf-
fic. Specifically, SDN must adopt a master-slave distributed control architecture, so
that during primary control failure, flow request can be handled by another standby
13
controller until the primary control repairs. Similarly, when a switch fails, the active
flows should be mapped to other nearest available switches.
• Scalability The decoupling nature of SDN creates new challenges like scalability
to both control plane and data plane. In [58], authors have claimed that when the
SDN will evolve the number of network elements, such as end hosts, switches and
controllers, then it will become a key bottleneck. As the number of end hosts and
switches increase, the available controller will be unable to handle the generated
request from the control plane. For example, a single NOX controller can handle
up to 30,000 flow requests/s, which may be sufficient for campus network, but it
is inadequate for the large data centers [34]. In addition to the controller overhead,
flow setup time may impose the limitation on SDN scalability.
• Flow setup delay SDN is a flow-based network architecture. The flow setup time
is an important metric to measure the controller’s performance [59]. When a new
packet arrives at the switch, it matches with the flow table entries. If a miss occurs,
the switch sends a request to the controller for further action. The controller sends
the forwarding rule to the corresponding switch. Then, the switch updates the flow
table with the new flow entries. The time taken to set up the flow in the table is
known as flow setup time. The flow setup time is significantly higher if the packet is
new to the flow table. This type of flow setup is known as the reactive mode. On the
other hand, if the flow rule is already known before the packet arrives at the switch,
then it is known as the proactive mode. In this mode, the flow setup time is negligi-
ble. To improve the flow setup delay, the controller’s processing capability should
be faster. On the other hand, adding extra threads to the controller might improve
the latency. However, within a short period, the switch ASICs must be capable
enough to handle such massive flows. Since current ASICs don’t have such capabil-
ity, the flow table must use the cache memory.
• Security A statistical study reveals that 31% of IT organizations are in doubt to
adopt SDN as their major concern is security [60]. The security issues are raised,
because the traditional security solutions cannot emerge with SDN. If an attacker
unlawfully accesses the controller, the whole network becomes collapsed. There-
fore, it is essential to ensure a robust security solution to different layers of SDN.
Without incorporating good security solution, the popularity of SDN becomes a
nightmare.
4 Possible security threats and attacks to SDN layers
In this section, we will discuss various possible security threats and attacks that pose a
serious concern to SDN architecture.
13
K. S. Sahoo et al.
4.1 Possible security threats to SDN layers
4.1.1 Application layer security threats
• Network service chaining functionality uses SDN capabilities to create a ser-

vice chain among the connected services. It creates a virtual chain by ena-
bling automated provisioning of network applications, such as firewall, IDS
or intrusion prevention system (IPS) and NAT. It helps the network operator
to set up a network catalog of connected services for providing many services
in a single network connection. However, application with chained execution
may create a serious security issue. For example, a malicious application may
intentionally drop the packets, which may cause extreme interference to other
applications [61].
• Sometimes the controller shares the internal storage to the certain privileged
SDN applications. Eventually, a malicious application can manipulate the
internal database [62].
• The application server usually keeps the sensitive information of the users,
which can be compromised by a malicious application. Therefore, it is essen-
tial to establish a trust between the controller and the SDN application.
• Transforming from the traditional network to the SDN environment requires
interoperability between the devices. For this, third-party applications are
being deployed. These applications can cause security problems, because they
lack standards and programming models [63].
• Malicious applications can exhaust the available system resources, such as
memory and CPU, which may degrade the end user QoS.
4.1.2 Control layer security threats
• The controller is the key entity of SDN. Any type of threat to the controller
can crash the entire system. Nowadays, the controller becomes a bottleneck
for the high-speed network, which may cause a single point of failure and sat-
uration attack.
• When an incoming packet does not match with the flow table, a packet_in
event is issued by the respective switch to the controller. An attacker may tar-
get the controller by flooding unknown packets to the network. This type of
attack is called as DDoS attack, which is a serious concern in a centralized
architecture.
• A stateful application may not perfectly work in SDN, because the controller
is unable to synchronize the network updates.
• Moreover, changing a system variable may crash the controller state. For
example, changing the system time may disconnect the controller from the
attached devices [64].
13
4.1.3 Data layer security threats
• The switch firmware of SDN can be compromised, because it cannot handle

the crafted flow rules [36].
• There are various potential actions taken by the SDN switch, such as dropping
or forwarding of the packet. Therefore, the controller’s decision depends on the
flow rules of the switches. In this regard, one of the key challenges of the con-
troller is to differentiate a benign flow rule from a fraudulent flow rule.
• Data leakage is another research challenge to SDN data plane. For example, OF
instantiates multiple vSwitch (logical switch) on the top of the OF-enabled hard-
ware switches. Let us assume that each vSwitch is assigned to a separate user. If
the associated credentials, such as certificate and key, are not properly isolated,
then there may be a chance of data leakage. Moreover, it may compromise the
corresponding logical network [65].
• Hardware failure of the data plane is another security concern, which may exploit
the system integrity. It can be reduced by employing high assurance techniques.
4.2 Possible security attacks to SDN layers
There are many security attacks that may happen in the different layers of SDN [2,
66]. The possible attacks to various layers of SDN are presented in Table 4 [67].
In general, the main target of availability attacks is the resources of the computer
system. For example, in the flooding-based DDoS attacks, attacker sends an over-
whelming number of packets to exhaust the victim’s computer resources, such as
memory and network bandwidth, which ultimately disturbs the forwarding layer and
the control layer of SDN. If the application layer does not protect by transport layer
security (TLS) protocol, the policy-based attack might affect the other two layers of
SDN.
The controller access can be gained unlawfully by the authorization related
attacks, which might affect the control layer and the data layer. The data alterna-
tion related attacks can be applied to the forwarding layer. One of the examples of
the data alternation related attack is flow rule alteration. The malicious applications
Table 4 Possible attacks to SDN Layer → Forwarding Control layer Appli-

layers [67] layer cation
layer
Authentication ✓ ✓
Authorization ✓ ✓
Availability ✓ ✓
Data alteration ✓ ✓
Fake rule installation ✓ ✓
Policy implementation ✓ ✓
Side channel ✓ ✓
13
K. S. Sahoo et al.
might employ forge rules in the flow table of the switches, which may affect all the
three layers.
The side channel attack may continue to exist in the forwarding layer. For
instance, the flow rules are established from the input buffer. Moreover, it may able
to control the flow. While availability-related attack is considered, DDoS attack is
coming into the scenario. It can be applied by simply producing a large number of
traffic to create a conflict situation in the network. Nowadays, DDoS attack is drasti-
cally growing and it creates disastrous impact on the system. On the other hand, the
recently developed cyber infrastructure may be a victim of this attack and it may
introduce huge disruption in the system.
5 Overview of DDoS attack
In a DDoS attack, the compromised computer systems attempt to attack a Web site,
server or other computing resources, such as RAM and CPU. It causes unavailability
of resources for the users in the targeted system. The large incoming messages, con-
nection requests or malicious packets force the victim to slow down or even crash
the system. As a result, the legitimate users deprive from the desired services. The
DDoS attack can infect many organizations, such as financial institutions, national-
ized and private banks, IT industries and individuals that are connected to the Inter-
net. It has been carried out by different threat players, varying from single unlawful
hacker to organized professionals and government bodies. In this section, we will
discuss the causes and classification of DDoS attack.
5.1 Causes of DDoS attack
In the last few years, the occurrence of performing a DDoS attack has substantially
increased. Although the criminal side of this attack is obvious, the motivation is
always unclear. For instance, Lizard Squad, a hacking group, has undermined the
gaming services of Sony and Microsoft in 2014 on the eve of Christmas day. When
the reason behind this attack was investigated, one alleged member statement was
“It was for laugh!”. It is usually hard to understand the motivation behind this attack
and why it happens. The main reason is that some hidden external sources are con-
trolling the computing resources, which are performing such attacks. While it is dif-
ficult to find out that who are performing the attacks, at the same time, it is even
tougher to guess why. Many reasons for such attacks are hypothetical, which are
based on speculation with small amounts of evidence.
Nowadays, committing a DDoS attack is not that much difficult. A detailed step-
by-step process can guide a limited technical ability person to start the attack. Many
organizations have severely affected by unnecessary blocking of Internet service and
suffered a huge amount of loss for the same. On the other hand, it is time consuming
and expensive process if counter measured. Now, we summarize the causes of this
attack as follows.
13
• The attackers might target the victim’s system services for the financial gain. To
avoid such situation, the attackers generally demand a lump sump amount. Such
type of intentions is more vulnerable and difficult to settle.
• DDoS is a powerful weapon, when there is a conflict between two groups or two
individuals for obstructing opponent’s applications and infrastructure.
• Sometimes, a disappointed individual may be an attacker in order to take some
unwanted actions in reply to a perceived injustice through this attack.
• In some scenarios, a group of person is influenced by some philosophical truths
that cause DDoS attack to their counterparts [68]. For instance, some of the
events, such as 2010 WikiLeaks event and 2007 Estonia, are politically moti-
vated [69].
• A terrorist group tries to attack some of the sensitive zones in order to demol-
ish the economic system through the cyber warfare. This type of attack is either
politically or geo-politically motivated [3].
• To show off their caliber, some young trained hackers may try to attack specific
Web sites using online tools.
In Table 5, we list out recent high-profile attacks that were occurred across the
globe.
5.2 Taxonomy of DDoS attack
The DDoS attack is intended to hinder the available resources in the network, and
this task is initiated by the multiple connected devices. Moreover, the attackers try
to send overwhelmed fake packets to the victim, so that the malicious packets get
served. On the other hand, the benign traffic is observed due to congestion or una-
vailability of resources, which hampers the end user QoS experience. In this section,
we present a taxonomy of DDoS attack as shown in Fig. 5.
• Volumetric attack The attacker’s goal is to inject a massive amount of traffics

to overwhelm the network bandwidth of the victim. This type of attack is easy
to lunch by employing various amplification techniques. The volumetric attack
is the simplest type of attack, where the attacker uses a reflection medium. By
implanting such medium, a small amount of traffics can be used to generate giga-
bits of traffic [82]. Usually, the reflection-based volumetric attacks target a ser-
vice by simply sending legitimate requests to a DNS or network time protocol
(NTP) server using a spoofed source IP address. The severity of this attack can
be measured in bits/s. The example of this attack is UDP flood and NTP amplifi-
cation.
• Protocol attack This attack exploits the weakness of the network and transport
layers of the protocol stack [14]. The main focus of this attack is to consume
server resources or intermediate sensitive resources, such as a load balancer and
firewall. The magnitude of this attack is measured in terms of packets/s. The
example of this attack is Internet control message protocol (ICMP) smurf attack.
13
K. S. Sahoo et al.
Table 5 Popular DDoS massacres [67]

DDoS events Brief report
BBC Web site cyber attack (2016) [70] The attack was targeted to the Web site of the
British broadcasting corporation (BBC) and its
services like iPlayer radio app. The attackers
inject the overloaded traffic to this Web site.
Blizzard entertainment (2018) [71] The attacks were carried out by PoodleCorp hack-
ing group in early July 2018. This group was
primarily targeted to this gaming platforms.
Boston globe (2017) [72] The Boston Globe is an American daily newspaper.
They have reported that on November 8, 2017,
their Web sites and the internal servers were hit
by a DDoS attack from the different sources,
which made the server unavailable for a few hours
of the day.
Content delivery networks (CDNs) (2017) [73] Multiple CDNs were subjected to face massive
attacks from a botnet, called WireX. The WireX
botnet primarily includes Android devices that
are running malicious applications installed from
the Google app store. It is designed to create huge
DDoS traffic.
Github attack (2015) [74] The well-known programming repository site
GitHub has faced an attack, which includes a
set of attack vectors. The main intention was to
delete some content of the Web site as per the
corresponding authority.
HSBC Internet banking (2016) [75] Hongkong and Shanghai banking corporation
(HSBC), a popular bank of Britain, has faced an
attack just before the tax deadline.
Iris public sector Web sites (2016) [76] Some of the public sector Web sites (e.g., central
statistics office and department of justice) were
bound to stop because of DDoS attack.
Polish airline hacked (June 2015) [77] In June 2015, 10 flights of Polish airliner LOT
with around 1400 passengers were grounded due
to a hacking attack. Moreover, the flights were
stopped due to the document unavailability, which
includes route, weather forecast and other impor-
tant information. This is due to a DDoS attack,
which results an attack to overload the server.
Rio Olympics (September 2015) [78] As per Arbor networks, some of the public Web
sites of the 2016 Rio Olympics were facing a
DDoS attack. LizardStresser and Internet of
things (IoT) botnets were generated the traffic to
the victims, which was ranging up to 540 Gbps.
Russian banks (2016) [79] Five Russian banks were severely affected by a
massive DDoS attack in 2016. It was planned
with 24,000 systems, which was located in 30
different countries. However, the attackers were
unable to interrupt the bank services.
UK national lottery (2017) [80] The attack stops www.national-lottery.co.uk Web
site and cripple its mobile app offline. It causes
many UK citizens to stop playing the lottery with-
out buying the last-minute tickets on the day.
13
Table 5 (continued)
DDoS events Brief report
United states (US) election campaign Web sites In the lieu of US election, a group pointed the Web
[81] site of Doland Trump’s to interrupt his elec-
tion campaign and business. Later, the attackers
pointed both Hillary Clinton and Donald Trump
to down the Web site. They have used Mirai IoT
botnet for this attack, which has remained for
30 s.
DDoS Attack
Volumetric Protocol Application Layer
DNS Amplification Loop Attack HTTP Flood

Fraggle PoD SMTP
ICMP Flood Random Port Attack
NTP Amplification Same Port Attack
TCP Flood Smurf Attack
UDP Flood SYN Flood
Fig. 5 DDoS attack taxonomy
• Application layer attack This attack exploits the weakness of the application
layer of the protocol stack. It is made to distort the genuine users services by con-
suming the server resources, such as processor speed, memory, and bandwidth
between two different memories. The attackers perform the application layer
attacks, which requires a broad knowledge of the complexity of the application
or protocol [1]. The severity of this attack can be measured in terms of requests/s
received by the server. The hypertext transfer protocol (HTTP) flood and DNS
flood are the examples of this attack.
In addition to the above attacks, we present few common types of DDoS attack as
follows.
• HTTP flooding It is an application-level attack. In the session flooding attack,

the attacker’s request rate is higher than that of the legitimate users in the estab-
lishment of the session. Therefore, it absorbs the resources of server and makes
an attack in the system. The HTTP get or post is the example of such attack in
which a massive benign HTTP request is sent to the server.
• User datagram protocol (UDP) flooding UDP is unreliable and session less pro-
tocol. It is used to send short messages, called datagrams. UDP flooding attack
targets to the random ports of the network with UDP packets. The attacker uses
13
K. S. Sahoo et al.
spoofed source IP address during the attack. As a result, a large number of data-
grams are coming to the victim, which is turned into buffer overflow.
• ICMP flood attack ICMP is typically used to determine whether or not a sys-
tem is responding in the network. For this, an ICMP echo request packet is sent
to a system. If the system receives the packet successfully, then it will return
an ICMP echo reply packet. This request-reply process leads to a DDoS attack,
when an attacker tries to overwhelm a target system with ICMP echo requests
and the target system becomes inaccessible to the benign traffic.
• Smurf attack A smurf attack is a variety of ICMP flood attack. It is also a reflec-
tion-based attack. Here, the attacker sends ICMP echo requests to different sys-
tems with victims IP address as source IP address. As a result, the victim is
flooded with a large volume of ICMP echo replies from the random hosts.
• Slowloris attack It is a DDoS program and a type of HTTP get message attack.
The attacker posts a HTTP request and increases the request continuously. The
attacker repeats its operation until the sockets are absorbed by the requests. The
attacker takes the benefit of the transmission control protocol (TCP) protocol as
it provides open connection. Gradually, it reads the responses rather than send-
ing the requests. This attack uses smaller window size as compared to the victim
buffer. Consequently, it opens up the connection of the server to some extent,
which generally creates an attack [83].
• TCP SYN flooding attack Synchronized (SYN) flood exploits the weakness of
stateful network protocols like TCP, because these protocols consume resources
to maintain the states. In the TCP connection sequence (i.e., 3-way handshake),
the client receives a SYN message in order to start the handshake. The server
replies with an acknowledgment (ACK) to the client, and then the client termi-
nates the opened connection. However, in case of SYN flood, the spoofed IP
messages are sent with higher rates. Therefore, the connection is not closed. As a
result, the victim will unable to accept any new incoming connection and thus it
cannot provide services.
• NTP amplification This type of volumetric attack exploits NTP servers and net-
work protocols, which are used to synchronize system clocks, to overwhelm the
target with UDP traffic. In any reflection attack, there is an acknowledgment
from the server to a spoofed IP. Here, the query to response ratio is dispropor-
tionate to the original requests (between 1:20 and 1:200 (or more)). It implies
that if an attacker gets a group of open NTP servers by using a tool like Metas-
ploit, then it can easily perform a high-volume DDoS attack.
• Zero-day attack It is also known as zero-minute attack. It uses a previously
unknown attack and exploits vulnerabilities for which no patch has been made
yet.
• Ping of death (PoD) It is a type of DDoS attack that attempts to destabilize, crash
or stop the service by sending malicious pings to a system. This attack was prev-
alent about two decades ago, but it is less effective in today’s network scenario.
The traditional attack detection techniques can also apply to the SDN architec-
ture. However, the detection of DDoS attack of controller is slightly different from
others, which is discussed in Sect. 7.
13
6 Overview of DDoS attack in SDN
6.1 Does SDN provide protection solution to DDoS or is it a victim of DDoS?
Notably, DDoS attack has become a hot research topic since SDN was proposed. It
has been remarked that there is a contradictory relationship between SDN system
and DDoS attack. The good features of SDN make it easier to detect and react to
DDoS attack. On the other hand, the decoupled nature makes SDN as a victim of
DDoS attack. At the first time, the authors in [84] have stated that SDN structure is
vulnerable to DDoS attack. In another work, the authors have claimed that all the
available controllers are unprotected towards DDoS attack [85]. The pros and cons
of SDN are listed in Table 6. The defense solutions using SDN and the potential
DDoS attack to SDN layers have been discussed in this section.
6.2 SDN as DDoS detection solution
As the controller is a central entity, it has a key feature to allow or discard the
incoming flows. It attracts researchers and vendors to adopt SDN as an excellent
DDoS attack detection tool. The SDN-enabled DDoS detection techniques are listed
in Table 7 [67]. In [86], the authors have demonstrated that a router can efficiently
give security in a SOHO network. FRESCO is an OF-enabled SDN security applica-
tion development framework. It provides a platform to design various OF-enabled
detection and mitigation modules [88]. It offers a click-inspired programming frame-
work that facilitates security researchers to implement and share many different
attack detection and mitigation solutions. In [90], the authors have stated that the
mobile malware needs the Internet connection. Therefore, they have introduced a
method in which the incoming traffic is allowed if the source IP is falling within the
permissible IP range. Here, the access point is responsible for sending the received
traffic to the SDN controller. Then, the controller makes a flow rule and the traf-
fic is routed to the network as per the flow rule. The detection module extracts the
necessary traffic information from the incoming traffic. For detection purpose, four
Table 6 Features of SDN as a enabler and victim of DDoS attack

Pros Cons
The key features of SDN make it easier to It makes new attacks and itself suffers from DDoS attack.
prevent DDoS attack.
It supports dynamic updating of flow rules. The switch has no decision capability.
It enables a programmable network. The processing of packets by the controller is slower than
the router.
It has a centralized control logic plane. There is no such standard for northbound API.
It is easy to install flow rules. The controller might face single point of failure due to a
large volume of network traffics.
It has a centralized monitoring unit. It has the limited size of ternary content-addressable
memory (TCAM) memory.
13
Table 7 State-of-the-art of SDN-enabled anomaly detection solutions [67]
Related work Security issue addressed Description Controller used
13
Mehdi et al. [86] To identify attack traffic in home networks In SDN context, a router enables security in a small NOX
office home office (SOHO) network with OF-enabled
switches and NOX controller.
Yao et al. [87] To validate the source address to combat IP spoofing Virtual source address validation edge (VAVE) is a NOX
better and an efficient protocol than source address
validation implementation (SAVI). VAVE validates it
using the OF device and the NOX controller.
Shin et al. [88] To design detection and mitigation module in program- FRESCO offers a click-inspired programming frame- NOX
ming framework work that facilitates the researchers to implement and
share different security solutions.
Wang et al. [89] To prevent DDoS attack from the cloud-based SDN DaMask uses programmability nature for detection Floodlight
environment purpose, and it uses the flexibility control structure of
SDN for a specific attack.
Jin and Wang [90] To prevent the malicious traffic generated from the It allows the traffic if the source IP is present in a per- Mininet and POX
mobile device missible IP range. Here, they have used both the OF
switch and the controller.
Handigol et al. [91] To enable debugging in the networks A network debugger, called ndb, a prototype network Mininet
and a debugger have introduced to recreate the path
followed by a given packet. It is following the postcard
based technique. The flow table state is logged using
the proxy.
Braga et al. [92] To detect DDoS attack based on the features of traffic It looks into the SDN flow table and extracts the statisti- NOX
flow cal information. The information is used to classify the
correct traffic using SOM architecture.
Giotis et al. [93] To design an efficient and scalable mechanism for per- It fuses both OF and sFlow framework for fine-grained NOX
forming DDoS detection and mitigation using SDN anomaly detection. The controller uses sFlow packet
sampling property for better detection of anomaly.
K. S. Sahoo et al.
Table 7 (continued)
Hunag et al. [7] To realize autonomic self-defense in DDoS detection It uses OF, autonomic and locator separation technolo- Openflow
gies for on-demand network security service. This
framework is used as a DDoS defender by enumerat-
ing the flow volumes through the controller.
Phan et al. [94] To protect the networks from DDoS attack using SDN’s In this framework, a support vector machine (SVM) POX
centralized traffic monitoring capability classifier with idle-timeout adjustment (IA) is used for
the detection of an attack.
Passito et al. [95] To design a framework for building the cooperative An agent-based framework (AgNOS) is developed for Mininet
SDNs expanding the SDNs domain. It has built on top of
the abstractions that are provided by SDN. The agents
generate various message events. The agent may use a
message event to inform in case of DDoS attack.
Shin and Gu [96] To ensure security in cloud networks through SDN CloudWather provides security by writing a simple Mininet and NOX
policy script. Moreover, it utilizes the programmabil-
ity of SDN and provides different routing algorithms
for the security purpose.
Xu and Liu [97] To detect DDoS attack by utilizing flow monitoring A pair of rules has been installed for each suspected Customized simulator
capability of SDN victim IP range.
Fayaz et al. [98] To design a flexible and elastic defense framework for The DDoS defense framework, Bohatei, addresses the OpenDaylight
SYN proxy and DNS reflector attack scalability and responsiveness issues. It utilizes the
flexibility of SDN and elasticity of NFV.
Buragohain and Medhi [99] To utilize the global view of the networks for DDoS The FlowTrApp framework detects both high-rate and sFlow-rt and Floodlight
detection low-rate DDoS attack using flow rate and flow dura-
tion.
Chesla and Doron [100] To mitigate DDoS through dynamic rule updating and The forwarding elements divert the traffic based on the Central controller
programmability of SDN diversion field of the packet through dynamic rule
updating and programmability.
13
Table 7 (continued)
13
Hong et al. [101] To detect and mitigate slow HTTP DDoS attack and It utilizes the network-wide knowledge capability of NS3
slow HTTP POST attack SDN and runs the slow HTTP DDoS defense applica-
tion (SHDA) inside the controller. If any attack is
suspected, the web server makes a request to SHDA in
order to check for any attack.
Mohammadi et al. [102] To address control plane saturation via TCP SYN flood- SLICOTS takes the benefit of the dynamic programma- OpenDaylight
ing attack bility nature of SDN to detect and prevent TCP SYN
attacks.
Shtem et al. [4] To detect low and slow attack It utilizes SDN infrastructure and shark tank concept for Contrail
detecting the slow DDoS attack.
K. S. Sahoo et al.
detection algorithms have been used, namely connection success ratio (CSR), aggre-
gation analysis, IP blacklist and throttling connection.
To solve IP spoofing problem, SAVI is a standardized security architecture. How-
ever, it does not provide the ample security protection due to the solution space con-
straint. VAVE is an improved protocol of SAVI, which is designed to address the
source address validation problem [87]. To resolve this problem, VAVE uses OF
protocol along with the NOX controller for the global view of the network.
DaMask [89] have presented two modules, namely DaMask-D and DaMask-M.
DaMask-D is used for detection purpose, whereas DaMask-M is used for mitiga-
tion purpose. DaMask-D uses the probabilistic interference graphical model that can
address the dataset shift problem. When DaMask-M receives an alert from DaMask-
D, it matches the suitable countermeasure for different attacks and registers a policy
for the new attack type. Phan et al. [94] have used SVM along with an idle-timeout
adjustment algorithm for the detection of an attack. In [93], the authors have fused
the features of both frameworks, namely OF and sFlow. The sampling property of
sFlow is utilized by the controller for the anomaly detection. The security service
industries are adopting various network-based solutions. For example, Radware pro-
vides a DDoS solution to the SDN-enabled Cisco switches with the help of Cisco
ONE controller [103]. Similarly, Flowmon adopts an SDN oriented DDoS mecha-
nism using Juniper contrail networking [104]. In the contrail networking, each node
contains a virtual router instance. The instance is used for the direct traffic flow
between VM and node. Virtual routers collect the flow statistics and store into Cas-
sandra through Sandesh protocol.
6.3 SDN as the victim of DDoS attack
The separation of control and data planes introduces the new threats to the SDN. For
example, the switch sends a packet_in message to the controller on receiving a new
flow. Then, the controller replies it with a flow_mod control packet and processes
the flow rule in the switch. If an attacker is able to get the flow rule, it can initiate
attacks in the control layer or forwarding layer or data in order to control the chan-
nel. Here, we will discuss various threats obtained from the different layers of SDN.
It is also summarized in Table 8. In addition to this, a detailed description of the
possible attack strategies is graphically presented in Fig. 6.
6.3.1 DDoS attack to forwarding layer
The data plane attack can exploit both the infrastructure layer and the southbound
API. The basic working principle of SDN is that the header information is forwarded
to the controller for each incoming flow and the complete flow must wait until the
flow rule is returned. It gives an opportunity for the attacker to inject new and non-
predicted flows to the victim switch. In the traditional switches, the TCAM is lim-
ited in size due to high cost. However, today’s commercial switches are able to hold
a few thousands of rules simultaneously. On the other hand, there is indeed a trade-
off between the cost and the size of TCAM [105]. Additionally, the rule updating
13
K. S. Sahoo et al.
Table 8 Possible DDoS attacks Layer Possible attacks

to SDN layers
Application HTTP flooding and slowris attack
Control Resource exhaustion, channel
congestion, packet_in flooding,
side channel attack and satura-
tion attack
Forwarding Side channel attack, TCAM mem-
ory exhaustion, ICMP, TCP
SYN flooding attack, man at the
end (MATE) attack, link layer
discovery protocol (LLDP)
spoofing and traffic hijacking
Fig. 6 Possible DDoS strategies to the different layers of SDN
process is much slower. For instance, TCAM is able to update approximately 50

rules/s, which is a problem for the current network policies [106, 107]. TCAM
becomes overloaded if a large volume of flows is coming to the network simultane-
ously. The commercially used switch like Pronto Pica 8, contains 2000 flow rules
[108]. It is noteworthy to mention that the controller will install the unnecessary
13
flow rules to the flow table for every new flow, which creates additional congestion
to the data plane. In [109], the authors have stated that a switch can produce at max
1000 requests/s. Therefore, flow table and switch overload are two well-known prob-
lems in the forwarding layer. The pictorial representation of the DDoS threats to the
various layers of SDN is shown in Fig. 7 [67].
6.3.2 DDoS attack to control layer
For a centralized SDN, the single point of failure (SPF) is a challenging task.
Although the distributed SDN architecture is an alternative, still SPF is a serious
threat to the DDoS attack [9]. If overwhelmed flows come to the network, then
packet_in messages are generated in each time. If the overflow request reaches to the
controller, the resources of the controller are exhausting after a specified threshold.
This is referred as saturation attack. In the ElastiCon framework, the authors have
concluded and verified that the throughput and the number of control messages are
inversely proportional to each other [110]. In the similar fashion, the packet rate and
the response time are also conflicting each other due to the queuing delay and the
processor utilization [111]. If the buffer of the victim switch becomes overflow in
contrast to the packet header, the complete flow will forward to the controller. The
new flows will exhaust the data bandwidth to control the link. As a circumstance,
the normal flow request leads to the congestion problem [9]. Here, manipulation of
packet_in messages might cause side channel attack, which is unavoidable [112].
6.3.3 DDoS attack to application layer
A specific application of SDN can be a victim by the attacker. On the other hand,
targeting to application layer can also affect to the northbound APIs. Since the OF is
Fig. 7 DDoS threats to the different layers of SDN [67]
13
K. S. Sahoo et al.
not materialized, attack to a particular application may lead to compromise the other
applications. A malicious application can exhaust the available system resources by
creating unnecessary working threads, which critically exploit the performance of
other applications. Such type of attacks has been tested and verified by Wen et al.
[113]. The authentication mechanism could avoid the forged traffic flows. How-
ever, if the attacker intends to hijack the application server, then it can use the same
authenticated ports and source MAC addresses to inject forged flows into the net-
work [114].
7 Potential countermeasures for DDoS attack in SDN
The important task in DDoS attack is the identification of malicious traffic. In order
to provide a secured framework against DDoS attack in SDN, several solutions have
been proposed in the literature. In fact, it is a challenging research topic, where tra-
ditional detection techniques can be applied. This section summarizes the potential
countermeasures of DDoS attack as proposed by various researchers.
The AVANT-GUARD framework addresses two security challenges, namely
data-control plane interface security and control plane saturation attack [115]. A
connection migration technique has been proposed, which protects the control plane
from the saturation attack. The authors in [116] have proposed a policy-based prior-
itizing algorithm to detect possible attack. To avoid the overloading situation on the
controller, the switches drop the excessive requests. However, this mechanism leads
to a high drop rate of the legitimate flow requests under DDoS attack. As a solution,
Flowranger uses a ranking algorithm to locate the regular users based on their previ-
ous requests to the controller.
The flow request flooding attacks can be defended by FloodGuard [117]. It com-
prises two modules, namely flow rule analyzer and packet migration. If the con-
troller detects an attack, it installs a default rule at the victim switch to redirect all
the incoming new flows to the data plane cache. The cache takes responsibility for
generating the flow requests to the controller. At the same time, the controller pro-
actively makes the rules and installs these rules at the switch to overcome future
requests. For this, it needs to deploy extra devices on the data plane.
SDN-Guard is proposed to protect SDN system against TCAM memory over-
load, data to control channel congestion and controller resource depletion [118].
The architecture of SDN-Guard consists of three modules, namely flow manage-
ment, rule aggregation and monitoring module. The flow management module is
responsible for selecting the routing paths of flows, and it decides the hard timeout
of their respective TCAM entries based on the threat probability. The rule aggrega-
tion module is responsible for collecting flow entries of the malicious traffic in order
to reduce TCAMs entries. Finally, the monitoring module is used for aggregating
flow statistics.
A novel mitigation method, called multilayer fair queueing (MLFQ) has
been proposed by Zhang et al. [119]. This method is based on implementing
fair sharing of controllers resources among host and switches of the network.
The controller expands the respective queues into multiple lower level queues to
13
segregate malicious requests during the attack. However, when the duration and
number of attack streams are too large, MLFQ poorly handles the flow requests.
FloodDefender [120] is a protocol-independent DDoS defense platform. It
comprises four functional modules, namely packet filter, attack detection, table-
miss engineering and flow rule management. When there is no attack, it for-
wards the packet_in messages and the flow rules between the controller and the
applications. When an attack is detected, it redirects the packets to the neighbor-
ing switches with wildcard flow rules, which avoids the unnecessary congestion.
When the generated traffic is too high (especially, during DDoS or FEs), some
of the switches of the network cannot handle the load. In order to overcome this
problem, Scotch brings a novel solution by using an overlay network of vSwitch
(i.e., software switch) instead of hardware switch. Note that vSwitch can run on
powerful CPUs and generate more flow requests as compared to the hardware
switch. The hardware switch redirects the new flows to the software switches.
However, it may not handle the flow request if an attacker sends massive flows
beyond the vSwitch’s capacity.
Dao et al. [121] have analyzed user behavior and used it to assign a time-
out value for the flow entries. The short timeouts are assigned to malicious
flows, whereas longer timeouts are assigned for benign ones. When the number
of packet_in messages exceeds a specified threshold, an alarm for attack can be
raised. However, this technique produces a high false detection rate. Therefore,
the authors have used a statistical tool, called sequential probability ratio test
(SPRT), which detects the low traffic flow coming to the controller [122]. In
[123], the authors have used entropy-based statistical technique to identify the
attack traffic.
Kloti et al. [124] have used four modules, namely event filtering, packet drop-
ping, rate limiting and timeout adjustment techniques to combat DDoS attack.
They have made two modifications, namely connection migration and actuating
trigger for the collection of switch statistics. However, network monitoring is an
overhead task in each time. Therefore, Zhang [125] has presented OpenWatch
framework to monitor the network regularly. The adaptive counting mechanism
identifies the attack traffic more precisely. Shahreza and Ganjali [126] have pre-
sented a FleXam to collect the traffic samples decisively, which is an applica-
tion-related task. It runs in a small network and minimizes the controller load
and the congestion between the controller and the switch.
When the network states are updated, the FlowGuard framework examines the
flow path spaces to detect firewall policies [127]. It also conducts real-time vio-
lation decisions with the help of several innovative strategies, which is intended
for diverse network update situations. OpenSec is an OF-based security frame-
work that allows network operators to implement security policies for the spe-
cific flows [128, 129]. The operators can make simple and human-readable poli-
cies to obtain the desired security rights instead of configuring all the network
devices. Many notable efforts on SDN-based DDoS detection are mentioned in
Table 9 [67].
13
Table 9 Research efforts on SDN-based DDoS detection [67]
Related work Data layer Control layer Appli- Issues addressed Description
cation
13
layer
Shin et al. [115] ✓ ✓ Controller resource depletion (TCP flood attack) It employs DDoS detection technique by extending
and control to data plane channel congestion OF features. A connection migration technique is
proposed on the data plane to secure the control-
ler from the saturation attack.
Wei and Fung [116] ✓ Controller resource depletion It is based on the trust values. It classifies the
requests into multiple buffer queues with differ-
ent priorities. The trust value depends on the past
requests that are sent to the controller.
Wang et al. [117] ✓ ✓ Data to control plane saturation attack In order to protect the controller from being over-
loaded, FloodGuard packet migration module
temporarily stores the flooding packets and
submits them to the controller using rate limit
and round robin scheduling algorithm.
Dridi and Zhani [118] ✓ ✓ TCAM overflow, data to control channel conges- In order to protect the network against DDoS
tion, controller resource depletion attack, the SDN-Guard is dynamically rerouting
the detected malicious traffic, aggregating the
flow rules and adjust the flow timeouts.
Zhang et al. [119] ✓ Controller resource depletion MLFQ framework is based on the fair sharing of
the controller’s resources among SDN switches.
During the DDoS attack, the controller expands
the queue length and assigns the flow request to
the lower level queues.
Chen et al. [130] ✓ Controller resource depletion It employs specialized software tools to increase
the scalability of ingress switches for accommo-
dating the control plane workload. It incorpo-
rates a two-phase filtering mechanism to protect
the controller from the attack.
K. S. Sahoo et al.
Table 9 (continued)
cation
layer
Shang et al. [120] ✓ ✓ TCAM overflow, data to control channel conges- This platform stands between main controller and
tion and controller resource depletion other controller applications. It is a protocol-
independent platform, which can detect different
types of attack traffic, such as TCP- and UDP-
based attack.
Wang et al. [109] ✓ Switch overload Scotch is a switch overload solution that dynami-
cally scales up the control plane capacity by
using a vSwitch, during DDoS or flash crowd
events.
Dao et al. [121] ✓ Switch overload When a new packet_in received by the controller,
it builds a new specific entry with a hard timeout
and an idle timeout to distinguish the attack traf-
fic from the benign traffic.
Porras et al. [131] ✓ ✓ Role-based authorization for the controller FortNOX is a role-based application authentica-
tion through digital signature using the NOX

controller.
Lim et al. [132] ✓ ✓ Blocking DDoS attack by targeting to SDN This scheme requires minimal support from the
applications server under attack. Specifically, the server does
not have a physical replicated service.
Zaalouk et al. [133] ✓ Security solution for serving entity Orchestrator-based architecture (Orchsec) utilizes
network monitoring and control functions to
develop the security applications for preventing
DDoS attack.
Lara and Ramamurthy [128] ✓ Spam detection and DPI OpenSec security framework allows operators to
create and implement the security policies that
are written in the human-readable language.
13
Table 9 (continued)
cation
13
layer
Liyanage et al. [134] ✓ ✓ Protection to control channel of software-defined A novel secure control channel architecture is pro-
mobile networking posed, which is based on host identity protocol
(HIP).
Kloti et al. [124] ✓ ✓ Security analysis It performs security analysis of OF by combining
Microsoft’s STRIDE model and attack trees.
K. S. Sahoo et al.
8 DDoS detection techniques in SDN
We broadly divide the techniques used for DDoS detection into four types, namely
statistical-based, machine learning-based, scheduling-based and connection rate-
based solutions [135]. The conventional methods are also applicable for SDN
defense mechanism. In the previous section, we have discussed state-of-the-art
detection solutions by focusing various layers of SDN. Here, we present an outline
of such techniques that are used to tackle DDoS attack. For easy visualization, we
show the techniques in Fig. 8.
8.1 Statistical‑based solutions
In statistical-based solution, some statistical characteristics and baseline profiles

are collected in the non-attack period and then this information is used during the
detection of an attack. Entropy is a statistical method to assess the randomness of
an entity in a specified time period. High entropy signifies high randomness of an
attribute, and it incurs low overhead of calculations [136]. The system checks the
entropy value of three things, namely port address, IP address and number of pack-
ets, in the detection process. For instance, if all the packets are forwarded to a single
host (or same destination IP), then there is a chance of attack. This technique has
been used extensively in a traditional network for IDS/IPS [137, 138].
Mousavi and St-Hilaire [123] have taken the entropy-based small window to
detect DDoS in the control layer. Wang et al. [139] have proposed a framework for
filtering of attack traffic using an entropy technique. In order to reduce the work-
load of the controller, the detection module runs in the edge switch of the network.
DDoS Techniques
Detection Mitigation
Entropy Based Blocking Port
Machine Learning Drop Packets
Scheduling Based DPI
Connection Rate Based Alternation of Logical/Physical Address
Traffic Pattern Behaviour Traffic Redirection
Fig. 8 Techniques used for DDoS attack detection and mitigation process
13
K. S. Sahoo et al.
In [86], the authors have presented the maximum entropy estimation technique to
distinguish the attack traffic and the normal traffic. In [140], the authors have used
another statistical technique, called generalized information distance (GID) metric
for segregating the HR DDoS attack during FEs traffic. The entropy has some draw-
backs despite of its popularity. One of them is that the entropy is calculated using
a single parameter of the incoming flows. As a result, other important information
about the distribution is not considered. Here, the anomalies that are not influencing
the properties of randomness remain unnoticed.
8.2 Machine learning‑based solutions
Machine learning (ML) techniques like SVM, decision tree, random forest, etc., were
widely used for anomaly detection in the traditional network [141, 142]. These tech-
niques can also be applicable for SDN-based anomaly detection system. Braga et al.
[92] have employed self-organizing map (SOM)-based neural network technique for
their work. They have considered the ADF and GDP features for detection of mali-
cious traffic. In [143], the authors have applied Mamdani algorithm of fuzzy logic
for the detection purpose. The outcomes show that fuzzy logic based decision gives
better performance than the other attack detection algorithm. In another work, Kok-
ila et al. [144] stated that SVM gives higher accuracy with less false positive than
other techniques. In [145], the authors have proposed an IDS for software-defined
5G networks. It integrates relevant security modules into a unified platform, which
is dynamically invoked under the centralized management. The detection framework
uses the random forest for the feature selection, and it combines k-means++ with
adaboost machine learning techniques for the flow classification.
8.3 Scheduling‑based solutions
These solutions are usually designed to protect the controller from saturation attack
[146]. In order to protect the controller, the solutions deal with the assignment of the
requests that are coming from SDN switches. In [147], the authors have proposed
a detection scheme, where multiple queues are maintained by the controller to pro-
cess the scheduling and this is performed on the requests from the SDN switches. A
well-known and popular scheduling approach, called round robin is used to process
the service to the high-rate incoming requests. Therefore, the controller can work
even during a FE. However, it overlooks the DDoS attack. In [148], the authors have
proposed an opposite model of [147], called MultiQ. The scheme ensures that the
controller will be remain active even if an attack affects the network. In the MultiQ,
multiple queues have assigned for each ingress switch. This is due to the fact that
the attack traffic hits the ingress switches of the network during an attack. The main
lacuna of MultiQ is that it serves both attack traffic and FE in the similar fashion.
Therefore, attack traffic can compromise the controller. Yan et al. [149] have pro-
posed a multiple queue scheduling algorithm, which is based on the time slice allo-
cation strategy.
13
8.4 Connection rate‑based solutions
It depends on the connection rate between the controllers and the forwarding
devices. The connection success rate and the number of established connections are
the two possible variants of this solutions [90]. In the first variant, the connection
rate of the legitimate host is higher than the attacked host. In SDN context, TRW-
CB algorithm has been implemented by Mehdi et al. [86] for detection purpose.
As the controller makes all the network policies, it is also essential for the con-
troller to impose mitigation techniques after the detection of an attack. Most of the
SDN-based DDoS detection solutions have incorporated mitigation strategies into
their system. The blocking ports, dropping packets and redirecting traffic are the
most common mitigation strategies in the sense that these are simple and easy to
implement [93, 150, 151]. On the other hand, blocking and dropping methods may
affect the incoming benign traffic. For instance, if a legitimate port is compromised,
then the port is completely blocked. As a result, the internally generated traffic also
gets dropped. Similarly, if a false attack is detected, then the legitimate users are for-
bidden from using the desired services.
The redirection technique usually bypasses all the incoming traffic to another
server with a new IP address [132]. The redirection techniques either impose a high
computation barrier for the attackers by using captcha or imply deep packet inspec-
tion (DPI) to examine and forward the legitimate traffic [152]. Note that the process-
ing overhead is more in these techniques and the overall complexity is also increas-
ing. The summary of the prevailing DDoS detection and mitigation techniques in
SDN architecture is summarized in Table 10.
9 Proposed SDN‑based DDoS detection framework
Previously, we have discussed that SDN is the best tool to detect DDoS attack. At the
same time, the decouple components of SDN are vulnerable to DDoS attack. One of
the possibilities that could cause the control plane to be unavailable is launching HR
DDoS attack during FEs. The characteristics of FE are pretty similar to a HR DDoS
traffic, where thousands of users are trying to access a particular computing resource
in the network (e.g., accessing a Web site during the result announcement or the live
Table 10 Summary of DDoS detection and mitigation techniques

Detection technique Mitigation technique
Method Related work Method Related work
Blocking port [151] Entropy [123, 139, 140]

Redirection [132] Machine learning [92, 153]
Drop packets [93, 150] Scheduling [148, 149]
DPI [152] CRB [86, 88, 143]
Address alteration [132, 152] Traffic behavior [88, 90]
13
K. S. Sahoo et al.
broadcast of a match). The other similar characteristics are the traffic rate change and
response delay, respectively. However, there are some differences in the context of
parameters, such as request rate per source IP, duration of the traffic and URL access
behavior, which can discriminate between these two events [154]. The high volume of
traffic causes delay in the requested service and congestion in the network. As a result,
the server becomes unresponsive and crashes. Therefore, it becomes a crucial issue to
identify the FEs from the HR DDoS attack.
The information distance between two traffic flows is a powerful way to discrimi-
nate the DDoS attack from the FE. Usually, zombies use some pre-built programs or
specific tools to inject attack packets into the victim. As a result, the similarity among
attack flows are much higher than the similarity between randomly legitimate FEs
[155]. Previously, few researchers have used different information distance metrics for
detecting FEs in the legacy network [156, 157]. However, very few works have been
proposed for the detection issues in the SDN context [140]. In most of the SDN DDoS
solutions, the researchers have used their detection scheme as a different module, which
is placed inside the controller. This is due to the fact that the switches are dumb devices
and it will be unrealistic to run complex detection algorithms, such as neural network,
machine learning and deep learning within the OF switch.
Nowadays, the OF switches are not completely a dumb device and the researchers
are trying to bring some intelligence into it. In [115], the authors have extended the OF
data plane by adding an extra module to it. The migration module is used to block the
DDoS SYN traffic from the data plane to the control plane. Furthermore, the local CPU
can be utilized to collect and analyze the data at the switch level, which has been identi-
fied by Moshref et al. [158]. This phenomenon inspires us to propose an information
distance-based flow discriminator (IDFD) scheme to identify the HR DDoS from the
FEs. The IDFD is running inside the OF edge switch that aims to reduce the burden of
the controller. Unlike other works, both the statistics collection module and detection
algorithm are running on the edge switches.
In the statistical approach, the threshold is fixed. Hence, an abnormal deviation of
some statistical features can help to identify malicious traffic. However, the choice of
statistical techniques is so vital in the case of DDoS detection. The information the-
ory related metrics (like entropy) can identify the variations of traffic behavior of such
events and comparatively low processing overload [159]. As SDN deals with flow-
based traffic, we use the frequency of IPdest for calculating the entropy value. Note that
entropy is used to measure the uncertainty of an event that is associated with a given
probability distribution. Although entropy requires minimal calculation, at the same
time, false positive rate increases during the attack. In order to avoid this, we use the
information distance as the abstract metric to discriminate DDoS flows from FEs.
Let us consider two different probability distributions, namely P = (p1 , p2 , … , pn )
∑ ∑
and Q = (q1 , q2 , … , qn ). Note that ni=1 pi = 1 and ni=1 qi = 1. The information dis-
tance metric computes the difference between P and Q. Next, the generalized informa-
tion divergence (D) can be derived in Eq. (1) [160].
( n )
1 ∑
D𝛼 (P||Q) = log p𝛼 q1−𝛼 (1)
1 − 𝛼 2 i=1 i i
13
where 𝛼 ≥ 0. Here, information distance (ID) can be obtained by varying the 𝛼 order.
When 𝛼 = 1, the ID is known as Kullback–Leibler divergence (KLD). It can be
derived in Eq. (2) [160].
n ( ( ))
∑ p
D1 (P||Q) = pi log2 i . (2)
i=1
qi
For higher 𝛼 order, higher information distance value can be obtained, which
helps IDFD to distinguish DDoS and FE flows effectively. To facilitate the above
detection scheme, we fix the flow statistics collection and GID calculation module at
the edge switches, which is shown in Fig. 9. For this, we define a flow that consists
of five tuples, <IPsrc , IPdest , Portdest , Portsrc , IPprotocol >.
The OF edge switch does not have the knowledge of the local topology. There-
fore, we add an extra attribute to the flow table, which indicates the received packets
within a time period. When the edge switch detects the DDoS traffic, it alerts the
controller. In order to stop the attack traffic, the controller sets up drop rules to the
edge switches. To realize more accurate traffic filtering, taking into consideration of
the signature and command provided by the victim, the controller can set more accu-
rate flow filter rules to these edge switches.
The experiments were performed on a system with core i5 processor, 8 GB RAM
and clock speed of 2.30 GHz. We installed Mininet 2.0.0 on the virtual box, which
supports OF version 1.3. To verify our detection scheme, we use POX controller and
Mininet emulator in the experimentation [161, 162]. Note that Mininet is a standard
network emulator tool that can be used in SDN. We generate custom attack packets
and send them to victims in order to create DDoS attack scenario on Mininet. A tree
Fig. 9 SDN-based IDFD DDoS detection framework
13
K. S. Sahoo et al.
topology has been created using the MiniEdit tool for the attack scenario, which
comprises a POX controller, 64 hosts and 8 OF switches. We have used open virtual
switch (OVS) for OF switch in which network interfaces and various protocols have
already been implemented. To each OVS, eight hosts have been connected to create
the network subnet. Out of eight OVS, two has been realized as edge switch with our
modified logic.
In this experiment, two standard datasets have been used. One is center for
applied Internet data analysis (CAIDA) dataset and another is FIFA world cup data-
set. The CAIDA dataset contains DDoS flooding traffic for the duration of one hour.
We used this dataset for detecting the HR DDoS attack. In addition to this, Python-
based Scapy tool is utilized to generate HR DDoS traffic from zombies to the target
victims.
Here, two different scenarios have been considered to evaluate the performance.
In the first scenario, we increase the traffic intensity of the CAIDA dataset to observe
the variation of information distance. In another scenario, we run the FIFA dataset
and create FE with the help of Scapy tool. We keep the normal traffic for both the
scenarios. The experimental outcomes are shown in Figs. 10 and 11, respectively.
In this process, a botnet of 10 hosts attack traffic is injected into the host with IP
address 10.0.0.1.
The GID of the flow samples are computed and the results are compared with
KLD metric at the edge switch. As seen from Fig. 10, the value of KLD metric is
within the range of 0.3–1.2 for CAIDA dataset. Further, it can be observed that the
value of ID varies with the increasing value of 𝛼 . In another experiment, the effec-
tiveness of the GID metric for identifying HR DDoS attack from the FEs for FIFA
Fig. 10 Information distance between legitimate and HR DDoS traffic in CAIDA dataset
13
Fig. 11 Information distance between FE and HR DDoS traffic in FIFA dataset
dataset has been evaluated. As shown in Fig. 11, it can be observed that the ID of
KLD metric remains within the range of 0.8. It is due to the fact that both the flows
have similar traffic rates and similar probability distributions. Therefore, this results
in less ID between the two flows. Furthermore, the ID provides more information
with increasing 𝛼 order. As a result, it could improve the detection efficiency. From
these experiments, we inferred that the GID metric can effectively identify the attack
traffic than the KLD metric.
In order to compare the performance of the GID metric, we have considered the
related work proposed by Mousavi and St-Hilaire [123]. In this work, the authors
have considered Shannon entropy, a statistical technique, as the detection metric. In
Fig. 12, the trade-off between false positive rate (FPR) and detection rate (DR) in
terms of receiver operating characteristic (ROC) curve have been illustrated. Note
that DR denotes how much attack traffic can be detected out of the total generated
attacks and FPR denotes how much legitimate traffic can be detected as attack traf-
fic. To suit the above attack scenario, the threshold value was determined experi-
mentally. For accurate detection, the threshold values are set to 0.5, 0.6, and 0.8 for
𝛼 value 1, 5, and 10, respectively. The ROC curve indicates that the detection accu-
racy of ID metric is higher with 𝛼 = 10. It achieved low FPR with high detection
accuracy as compared to Shannon entropy and KLD metric (𝛼 = 1). Moreover, with
higher 𝛼 order, GID can magnify the more information distance, which helps IDFD
to achieve higher detection accuracy.
As far as the previous work is concerned [86, 92, 163], the controller collects
the flow statistics from the switch periodically and apply the detection algorithm.
The detection time purely depends on the polling interval. In contrary, IDFD
13
K. S. Sahoo et al.
Fig. 12 Detection performance (ROC) of the different metrics
runs on the edge switch and takes the decision on the abnormality of the network
flows, which can reduce the communication overhead between the controller and
the switch. Therefore, GID calculation does not require much computation like
ML algorithms. In a real scenario, it can be easily embedded inside the edge
switch.
10 Future research direction
In this section, few research directions on the security of SDN have been
discussed.
• Flow table compression is a predominant technique in which the fine-grained

entries are combined to form the coarse-grained rules. However, detection of
attack with flow table compression is a challenging task.
• In multi-controller scenario, how to design a lightweight DDoS solution with
enhanced detection accuracy is another key issue.
• Identification of source attack is still an unexplored area in SDN.
• To implement time critical security solution, it is important to reduce the control
messages sending from data plane the control plane.
• To compromise the network elements, the attacker always come up with new
ideas. Therefore, early detection of DDoS is the need of the hour without much
affecting the legitimate traffic.
13
11 Conclusion
In this paper, we have developed various security threats to the newly emerged
SDN architecture and discussed DDoS attack in detail. The global view of the
entire network and centralized control helps SDN controller to efficiently protect
the system through the robust defense mechanisms. In the meantime, research on
DDoS threat has become an open field for the researchers. In this paper, we have
identified various research efforts that enable SDN as a tool to solve the issues of
DDoS attack. Then, we discuss SDN as a victim of DDoS attacks followed by a
comprehensive survey on proposed countermeasures to it. Although the research
community has developed many mechanisms, still there are several challenges,
which are needed to be catered. In this regard, we have proposed a detection
scheme, called IDFD for detecting HR DDoS from the FE using information dis-
tance metric. The proposed scheme runs over the edge switches, and the simula-
tion results show that information distance can effectively identify the HR DDoS
traffic with increasing order of 𝛼 value. Finally, this paper has attempted to high-
light certain research directions about the DDoS attack to SDN, which will help
the beginners to start their future research work.
Acknowledgements The first version of this paper has appeared in one of the chapters of Handbook of
e-Business Security [67]. We would like to thank the anonymous reviewers for their valuable comments
and future research directions, which greatly help us to extend this paper.
References
1. Mirkovic J, Reiher P (2004) A taxonomy of DDoS attack and DDoS defense mechanisms. ACM
SIGCOMM Comput Commun Rev 34(2):39–53
2. Akhunzada A, Ahmed E, Gani A (2015) Securing software defined networks: taxonomy,
requirements and open issues. IEEE Commun Mag 53(4):36–44
3. Zargar ST, Joshi J, Tipeer D (2013) A survey of defense mechanisms against distributed denial
of service (DDoS) flooding attacks. IEEE Commun Surv Tutor 15(4):2046–2069
4. Shtem M, Sandel R, Litoiu M (2014) Towards mitigation of low and slow application DDoS
attacks. In: IEEE International Conference on Cloud Engineering, pp 604–609
5. Palmieri F, Ricciardi S, Fiore U, Ficco M, Castiglione A (2015) Energy-oriented denial
of service attacks: an emerging menace for large cloud infrastructures. J Supercomput
71(5):1620–1641
6. Modi C, Patel D, Borisaniya B, Patel A, Rajarajan M (2013) A survey on security issues and solu-
tions at different layers of cloud computing. J Supercomput 63(2):561–592
7. Hunag CY, Chi TM, Ting CY, Chieh CY, Ren CY (2010) A novel design for future on-demand
service and security. In: IEEE 12th International Conference on Communication Technology, pp
385–388
8. Ali ST, Sivaraman V, Radford A (2015) A survey of securing networks using software defined net-
working. IEEE Trans Reliab 64(3):1086–1097
9. Hussein A, Elhajj IH, Chehab A, Kayssi A (2016) SDN security plane: an architecture for resilient
security services. In: IEEE International Conference on Cloud Engineering Workshop, pp 54–59
10. Fernandez EB (2011) Security in data intensive computing systems. In: Furht B, Escalante A (eds)
Handbook of data intensive computing. Springer, Berlin, pp 447–466
11. Incapsula. https://www.incapsula.com/blog/ddos-impact-cost-of-ddos-attack.html. Accessed on 20
Oct 2017
13
K. S. Sahoo et al.
12. Singh S, Sharma PK, Moon SY, Moon D, Park JH (2016) A comprehensive study on APT attacks
and countermeasures for future networks and communications: challenges and solutions. J Super-
comput. https://doi.org/10.1007/s11227-016-1850-4
13. Yan Q, Yu FR, Gong Q (2016) Software-defined networking (SDN) and distributed denial of ser-
vice (DDoS) attacks in cloud computing environments: a survey, some research issues and chal-
lenges. IEEE Commun Sur Tutor 18(1):602–622
14. Peng T, Leckie C, Ramamohanarao K (2007) Survey of network-based defense mechanisms coun-
tering the DoS and DDoS problems. ACM Comput Surv 39(1):1–42
15. Jarraya Y, Madi T, Debbabi M (2014) A survey and a layered taxonomy of software-defined net-
working. IEEE Commun Surv Tutor 16(4):1955–1980
16. Kobo HI, Abu-Mahfouz AM, Hancke GP (2017) A survey on software-defined wireless sensor
networks: challenges and design requirements. IEEE Access 5:1872–1899
17. Sahoo KS, Mohanty S, Tiwary M, Mishra BK, Sahoo B (2016) A comprehensive tutorial on soft-
ware defined network: the driving force for the future internet technology. In: International Confer-
ence on Advances in Information Communication Technology and Computing. ACM, Article No.
114
18. Vaughan-Nichols SJ (2011) OpenFlow: the next generation of the network? IEEE Comput
44(8):13–15
19. Wibowo FXA, Gregory MA, Ahmed K, Gomez KM (2017) Multi-domain software defined net-
working: research status and challenges. J Netw Comput Appl 87:32–45
20. Xia W, Wen Y, Foh CH (2015) A survey on software-defined networking. IEEE Commun Surv
Tutor 17(1):27–51
21. Hasan SF (2014) Software-defined networking, emerging trends in communication networks.
Springer, Berlin, pp 19–32
22. Pica8. http://www.blucorona.com/solutions/pica8/p-3295.shtml. Accessed on 10 April 2018
23. Software Defined Networking (SDN) Configuration Guide. http://pleiades.ucsc.edu/doc/brocade/
netiron-05900-sdnguide.pdf. Accessed on 10 Jan 2018
24. HPE 3800 Series. https://h20195.www2.hpe.com/v2/GetPDF.aspx/4AA3-7115ENW.pdf. Accessed
on 10 Jan 2018
25. Exploring Software-Defined Networking with Brocade. https://cio.economictimes.indiatimes.com/
files/cp/12/cdoc-1457526264-BRCD_ExploringSDN_WP.pdf. Accessed on 10 Jan 2018
26. OpenFlow 1.3 Features Supported in EXOS. https://gtacknowledge.extremenetworks.com/articles/
Solution/OpenFlow-1-3-features-supported-in-EXOS. Accessed on 10 March 2018
27. IBM System Networking RackSwitch. https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infot
ype=an&subtype=ca&appname=gpateam&supplier=897&letternum=ENUS114-011. Accessed
on 10 March 2018
28. OpenFlow Support on Juniper Network Devices. https://www.juniper.net/documentation/en_US/
release-independent/junos/topics/reference/general/junos-sdn-openfl ow-supported-platforms.html.
Accessed on 10 April 2018
29. Arista 7150 Series. https://www.arista.com/en/products/7150-series. Accessed on 10 April 2018
30. Xie J, Guo D, Hu Z, Qu T, Lv P (2015) Control plane of software defined networks: a survey.
Comput Commun 67:1–10
31. Wallner R, Cannistra R (2013) An SDN approach: quality of service using big switch’s floodlight
open-source controller. Asia-Pacif Adv Netw 35:14–19
32. Medved J, Varga R, Tkacik A, Gray K (2014) OpenDaylight: towards a model-driven SDN control-
ler architecture. In: IEEE international symposium on a world of wireless, mobile and multimedia
networks, pp 1–6
33. Kaur S, Singh J, Ghumman NS (2014) Network programmability using POX controller. In: Inter-
national Conference on Communication, Computing and Systems. IEEE
34. Tavakoli A, Casado M, Koponen T, Shenker S (2009) Applying NOX to the datacenter. Proc. of
workshop on Hot Topics in Networks (HotNets-VIII)
35. Erickson D (2013) The Beacon OpenFlow controller. In: The second ACM SIGCOMM workshop
on hot topics in software defined networking, pp 13–18
36. Build SDN Agilely. https://osrg.github.io/ryu/. Accessed on 5 May 2018
37. MUL. http://www.openmul.org/. Accessed on 1 May 2018
38. Trema: full-stack OpenFlow framework in Ruby and C. https://trema.github.io/trema/. Accessed on
1 April 2018
13
39. Nguyen TMC, Hoang DB, Chaczko Z (2016) Can SDN technology be transported to software-
defined WSN/IoT? In: IEEE International Conference on Internet of Things and IEEE Green Com-
puting and Communications and IEEE Cyber, Physical and Social Computing and IEEE Smart
Data, pp 234–239
40. Brocodo Flow Optimizer. https://www.walkerfirst.com/uploads/files/literature/Brocade%20Flo
w%20Optimizer.pdf. Accessed on 10 May 2018
41. Brocodo Network Advisor Data Sheet. http://www.dataswitchworks.com/datasheets/Network_
Advisor_DS.pdf. Accessed on 19 Aug 2018
42. Aricent Featured White Paper: Routing Protocols and SDN. https://www.sdxcentral.com/articles/
featured/routing-protocols-aricent-white-paper/2015/02/. Accessed on 11 May 2018
43. HPE Network Optimizer SDN Application—1.3.41 Installation Guide. https://support.hpe.com/
hpsc/doc/public/display?docId=c05040243. Accessed on 8 May 2018
44. HPE Network Protector SDN Application Version 1.3.105 Administrator Guide. https://h2062
8.www2.hp.com/km-ext/kmcsdirect/emr_na-c05201088-1.pdf. Accessed on 30 April 2018
45. TechM Server Load Balancer. https://community.arubanetworks.com/t5/TechM-Server-Load-
Balancer/ct-p/TechMServerLoadBalancer. Accessed on 1 May 2018
46. HPE Network Visualizer SDN Application 1.1 Administrator Guide. https://support.hpe.com/hpsc/
doc/public/display?docId=c05040369. Accessed on 30 April 2018
47. SDN - Architecture and Role of OpenFLow. https://www.howtoforge.com/tutorial/software-defin
ed-networking-sdn-architecture-and-role-of-openfl ow/. Accessed on 5 May 2018
48. Foster N, Harrison R, Freedman MJ, Monsanto C, Rexford J, Story A, Walker D (2011) Frenetic: a
network programming language. ACM SIGPLAN Not 46(9):279–291
49. Reich J, Monsanto C, Foster N, Rexford J, Walker D (2013) Modular SDN programming with
pyretic. Technical Report of USENIX
50. Panda S, Jana P (2016) An efficient task consolidation algorithm for cloud computing systems. In:
Bjørner N, Prasad S, Parida L (eds) International Conference on Distributed Computing and Inter-
net Technology. Springer, Berlin, pp 61–74
51. Panda S, Jana P (2015) An efficient resource allocation algorithm for IaaS cloud. In: Natarajan R,
Barua G, Patra MR (eds) International Conference on Distributed Computing and Internet Tech-
nology. Springer, Berlin, pp 351–355
52. Panda S, Jana P (2015) Efficient task scheduling algorithms for heterogeneous multi-cloud environ-
ment. J Supercomput 71(4):1505–1533
53. Panda S, Jana P (2017) SLA-based task scheduling algorithms for heterogeneous multi-cloud envi-
ronment. J Supercomput 73(6):2730–2762
54. Kumar M, Gupta I, Panda S, Jana P (2017) Granularity-based workflow scheduling algorithm for
cloud computing. J Supercomput 73(12):5440–5464
55. Panda S, Jana P (2018) Normalization-based task scheduling algorithms for heterogeneous multi-
cloud environment. Inf Syst Front 20(2):373–399
56. Panda S, Jana P (2018) An energy-efficient task scheduling algorithm for heterogeneous cloud
computing systems. Cluster Comput. https://doi.org/10.1007/s10586-018-2858-8
57. Hungyo M, Pandey M (2016) SDN based implementation of publish/subscribe paradigm using
OpenFlow multicast. In: IEEE International Conference on Advanced Networks and Telecommu-
nications Systems, pp 1–6
58. Voellmy A, Wang J (2012) Scalable software defined network controllers. ACM SIGCOMM Com-
put Commun Rev 42(4):289–290
59. Metzler J, Metzler A (2013) Ten things to look for in an SDN controller. https://www.webtorials
.com/content/2013/05/ten-things-to-look-for-in-an-sdn-controller.html. Accessed 15 Aug 2018
60. Jammal M, Singh T, Shami A, Asal R, Li Y (2014) Software defined networking: state of the art
and research challenges. Comput Netw 72:74–98
61. Monsanto C, Reich J, Foster N, Rexford J, Walker D (2013) Composing software defined networks.
In: 10th USENIX Conference on Networked Systems Design and Implementation, pp 1–13
62. Shin S, Song Y, Lee T, Lee S, Chung J, Porras P, Yegneswaran V, Noh J, Kang BB (2014) Rose-
mary: a robust, secure and high-performance network operating system. In: ACM SIGSAC Confer-
ence on Computer and Communications Security, pp 78–89
63. Xie H, Tsou T, Yin H, Lopez D (2018) Use cases for ALTO with software defined networks. https
://tools.ietf.org/html/draft-xie-alto-sdn-use-cases-00. Accessed on 19 Aug 2018
64. Akhunzada A, Gani A, Anuar NB, Abdelaziz A, Khan MK, Hayat A, Khan SU (2016) Secure and
dependable software defined networks. J Netw Comput Appl 61:199–221
13
K. S. Sahoo et al.
65. Scott-Hayward S, Natarajan S, Sezer S (2016) A survey of security in software defined networks.
IEEE Commun Surv Tutor 18(1):623–654
66. Dayal N, Maity P, Srivastava S, Khondoker R (2017) Research trends in security and DDoS in
SDN. Secur Commun Netw 9(18):6386–6411
67. Sahoo K, Behera R, Sahoo B, Tiwary M (2018) Distributed denial-of-service threats and defense
mechanisms in software-defined networks: a layer-wise review. In: Handbook of e-business secu-
rity, pp 101–135
68. Fultz N, Grossklags J (2009) Blue versus red: towards a model of distributed security attacks. In:
International Conference on Financial Cryptography and Data Security. Lecture Notes in Com-
puter Science, vol 5628, pp 167–183
69. Greenemeier L (2007) Estonian attacks raise concern over cyber nuclear winter. Information Week.
https://www.informationweek.com/estonian-attacks-raise-concern-over-cyber-nuclear-winter/d/d-
id/1055474. Accessed 20 Aug 2018
70. Baraniuk C (2017) DDoS: website-crippling cyber-attacks to rise in 2016. https://www.bbc.co.uk/
news/technology-35376327. Accessed on 15 Sept 2017
71. Kupreev O (2018) DDoS Attacks in Q3 2018. https://securelist.com/ddos-report-in-q3-2018/88617
/. Accessed on 10 Dec 2018
72. Harris David L (2018) Boston Globe says it was hit by cyberattacks. https://www.bizjournals.com/
boston/news/2017/11/09/boston-globe-says-its-website-was-hit-by.html. Accessed on 15 Dec 2018
73. Cochran J (2018) The WireX Botnet: how industry collaboration disrupted a DDoS attack. https://
blog.cloudflare.com/the-wirex-botnet/. Accessed on 10 Dec 2018
74. Newland J (2017) Large scale DDoS attack on github.com. https://blog.github.com/2015-03-27-
large-scale-ddos-attack-on-github-com/. Accessed on 1 Oct 2017
75. Schwartz MJ (2017) DDoS attack slams HSBC. https://www.bankinfosecurity.com/ddos-attac
k-slams-hsbc-a-8835. Accessed on 11 Oct 2017
76. Weckler A (2017) Multiple government websites down as servers under DDoS attack. https://www.
independent.ie/irish-news/news/multiple-government-websites-down-as-servers-under-ddos-attac
k-34387566.html. Accessed on 5 Oct 2017
77. Kharpal A (2017) Hack attack leaves 1,400 airline passengers grounded. https://www.cnbc.
com/2015/06/22/hack-attac k-leave s -1400-passe n gers - of-polis h -airli n e-lot-groun d ed.html.
Accessed on 15 Oct2 017
78. Sullivan B (2017) Rio 2016 Olympics suffered sustained 540 Gbps DDoS attacks. https://www.
silicon.co.uk/secur ity/rio-olympics-ddos-attacks-196998?inf_by=5b79ab16671db8426b8b5246.
Accessed on 1 Oct 2017
79. Bisson D (2017) The 5 most significant DDoS attacks of 2016. https://www.tripwire.com/state-of-
security/security-data-protection/cyber-security/5-significant-ddos-attacks-2016/. Accessed on 10
Oct 2017
80. Cluley G (2018) UK National Lottery knocked offline by DDoS attack. https://www.welivesecurity.
com/2017/10/02/uk-national-lottery-ddos-attack/. Accessed on 10 Dec 2018
81. Rayome AD (2017) Hackers attempt DDoS attacks on Clinton and Trump campaign websites
using Mirai Botnet. https://www.techrepublic.com/article/hackers-attempt-ddos-attacks-on-clinton-
and-trump-campaign-websites-using-mirai-botnet/. Accessed on 10 Sept 2017
82. Kesavan A (2016) Three types of DDoS attacks. https://blog.thousandeyes.com/three-types-ddos-
attacks/. Accessed 20 Sept 2018
83. Shekyan S (2017) Are you ready for slow reading? https://blog.qualys.com/securityla
bs/2012/01/05/slow-read. Accessed on 15 Oct 2017
84. Shin S, Gu G (2013) Attacking software-defined networks: a first feasibility study. In: The second
ACM SIGCOMM workshop on hot topics in software defined networking, pp 165–166
85. Noh J, Lee S, Park J, Shin S, Kang BB (2016) Vulnerabilities of network OS and mitigation with
state-based permission system. Secur Commun Netw 9(13):1971–1982
86. Mehdi SA, Khalid J, Khayam SA (2011) Revisiting traffic anomaly detection using software
defined networking. In: Sommer R, Balzarotti D, Maier G (eds) International workshop on recent
advances in intrusion detection. Springer, Berlin, pp 161–180
87. Yao G, Bi J, Xiao P (2011) Source address validation solution with OpenFlow/NOX architecture.
In: 19th IEEE International Conference on Network Protocols, pp 7–12
88. Shin S, Porras P, Yegneswaran V, Fong M, Gu G, Tyson M (2013) FRESCO: modular composable
security services for software-defined networks. In: NDSS symposium
13
89. Wang B, Zheng Y, Lou W, Hou YT (2015) DDoS attack protection in the era of cloud computing
and software-defined networking. Comput Netw 81(C):308–319
90. Jin R, Wang B (2013) Malware detection for mobile devices using software-defined networking.
In: Second GENI research and educational experiment workshop. IEEE, pp 81–88
91. Handigol N, Heller B, Jeyakumar V, Mazieres D, Mckeown N (2012) Where is the debugger for
my software-defined network? In: The first workshop on hot topics in software defined networks.
ACM, pp 55–60
92. Braga R, Mota E, Passito A (2010) Lightweight DDoS flooding attack detection using NOX/Open-
Flow. In: IEEE Local Computer Network Conference, pp 408–415
93. Giotis K, Argyropoulos C, Androulidakis G, Kalogeras D, Maglaris V (2014) Combining Open-
Flow and sFlow for an effective and scalable anomaly detection and mitigation mechanism on SDN
environments. Comput Netw 62:122–136
94. Phan TV, Toan TV, Tuyen DV, Huong TT, Thanh NH (2016) OpenFlowSIA: an optimized pro-
tection scheme for software-defined networks from flooding attacks. In: IEEE Sixth International
Conference on Communications and Electronics, pp 13–18
95. Passito A, Mota E, Bennesby R, Fonseca P (2014) AgNOS: a framework for autonomous control
of software-defined networks. In: IEEE 28th International Conference on Advanced Information
Networking and Applications, pp 405–412
96. Shin S, Gu G (2012) CloudWatcher: network security monitoring using OpenFlow in dynamic
cloud networks (or: how to provide security monitoring as a service in clouds?). In: 20th IEEE
International Conference on Network Protocols, pp 1–6
97. Xu Y, Liu Y (2016) DDoS attack detection under SDN context. In: The 35th Annual IEEE Interna-
tional Conference on Computer Communications, pp 1–9
98. Fayaz SK, Tobioka Y, Sekar V, Bailey M (2015) Bohatei: flexible and elastic DDoS defense In:
24th USENIX Security Symposium, pp 817–832
99. Buragohain C, Medhi N (2016) FlowTrApp: an SDN based architecture for DDoS attack detection
and mitigation in data centers. In: 3rd International Conference on Signal Processing and Inte-
grated Networks. IEEE, pp 519–524
100. Chesla A, Doron E (2015) Techniques for traffic diversion in software defined networks for miti-
gating denial of service attacks, US Patent
101. Hong K, Kim Y, Choi H (2018) SDN-assisted slow HTTP DDoS attack defense method. IEEE
Commun Lett 22(4):688–691
102. Mohammadi R, Javidan R, Conti M (2017) SLICOTS: an SDN-based lightweight countermeasure
for TCP SYN flooding attacks. IEEE Trans Netw Serv Manag 14(2):487–497
103. DefenseFlow. https://www.radware.com/products/defenseflow/. Accessed on 25 Oct 2017
104. Skoda M (2017) DDoS protection in SDN based networking. https://www.flowmon.com/en/blog/
ddos-protection-sdn-networking/. Accessed on 30 Oct 2017
105. Ravikumar VC, Mahapatra RN (2004) TCAM architecture for IP lookup using prefix properties.
IEEE Micro 24(2):60–69
106. Spitznagel E, Taylor D, Turner J (2003) Packet classification using extended TCAMs. In: 11th
IEEE International Conference on Network Protocols, pp 120–131
107. Jin X, Liu HH, Gandhi R, Kandula S, Mahajan R, Zhang M, Rexford J, Wattenhofer R (2014)
Dynamic scheduling of network updates. ACM SIGCOMM Comput Commun Rev 44(4):539–550
108. Katta N, Alipourfard O, Rexford J, Walker D (2016) Cacheflow: dependency-aware rule-caching
for software-defined networks. In: The symposium on SDN research. ACM, Article No. 6
109. Wang A, Guo Y, Hao F, Lakshman TV, Chen S (2014) Scotch: elastically scaling up SDN control-
plane using vswitch based overlay. In: The 10th ACM International on Conference on Emerging
Networking Experiments and Technologies. ACM, pp 403–414
110. Dixit A, Hao F, Mukherjee S, Lakshman TV, Kompella R (2013) Towards an elastic distributed
SDN controller. ACM SIGCOMM Comput Commun Rev 43(4):7–12
111. Caba C, Soler J (2015) Mitigating SDN controller performance bottlenecks. In: 24th International
Conference on Computer Communication and Networks. IEEE, pp 1–6
112. Dhawan M, Poddar R, Mahajan K, Mann V (2015) SPHINX: detecting security attacks in soft-
ware-defined networks. NDSS: The Internet Society
113. Wen X, Chen Y, Hu C, Shi C, Wang Y (2013) Towards a secure controller platform for OpenFlow
applications. In: The second ACM SIGCOMM workshop on hot topics in software defined net-
working, pp 171–172
13
K. S. Sahoo et al.
114. Kreutz D, Ramos FMV, Verissimo P (2013) Towards secure and dependable software-defined net-
works. In: Second ACM SIGCOMM workshop on hot topics in software defined networking, pp
55–60
115. Shin S, Yegneswaran V, Porras P, Gu G (2013) AVANT-GUARD: scalable and vigilant switch flow
management in software-defined networks. In: ACM SIGSAC Conference on Computer and Com-
munications Security, pp 413–424
116. Wei L, Fung C (2015) FlowRanger: a request prioritizing algorithm for controller DoS attacks in
software defined networks. In: IEEE International Conference on Communications, pp 5254–5259
117. Wang H, Xu L, Gu G (2015) FloodGuard: a DoS attack prevention extension in software-defined
networks. In: 45th Annual IEEE/IFIP International Conference on Dependable Systems and Net-
works, pp 239–250
118. Dridi L, Zhani MF (2016) SDN-guard: DoS attacks mitigation in SDN networks. In: 5th IEEE
International Conference on Cloud Networking, pp 212–217
119. Zhang P, Wang H, Hu C, Lin C (2016) On denial of service attacks in software defined networks.
IEEE Netw 30(6):28–33
120. Shang G, Zhe P, Bin X, Aiqun H, Kui R (2017) FloodDefender: protecting data and control plane
resources under SDN-aimed DoS attacks. In: IEEE Conference on Computer Communications, pp
1–9
121. Dao N, Park J, Park M (2015) A feasible method to combat against DDoS attack in SDN network.
In: International Conference on Information Networking. IEEE, pp 309–311
122. Dong P, Du X, Zhang H, Xu T (2016) A detection method for a novel DDoS attack against SDN
controllers by vast new low-traffic flows. In: IEEE International Conference on Communications,
pp 1–6
123. Mousavi SM, St-Hilaire M (2015) Early detection of DDoS attacks against SDN controllers. In:
International Conference on Computing, Networking and Communications. IEEE, pp 77–81
124. Kloti R, Kotronis V, Smith P (2013) OpenFlow: a security analysis. In: 21st IEEE International
Conference on Network Protocols, pp 1–6
125. Zhang Y (2013) An adaptive flow counting method for anomaly detection in SDN. In: The Ninth
ACM Conference on Emerging Networking Experiments and Technologies, pp 25–30
126. Shahreza SS, Ganjali Y (2013) Efficient implementation of security applications in OpenFlow
controller with FleXam. In: IEEE 21st annual symposium on high-performance interconnects, pp
49–54
127. Hu H, Han W, Ahn G, Zhao Z (2014) FLOWGUARD: building robust firewalls for software-
defined networks. In: The third workshop on hot topics in software defined networking. ACM, pp
97–102
128. Lara A, Ramamurthy B (2014) OpenSec: a framework for implementing security policies using
OpenFlow. In: IEEE Global Communications Conference, pp 781–786
129. Berde P, Gerola M, Hart J, Higuchi Y, Kobayashi M, Koide T, Lantz B, O’Connor B, Radoslavov
P, Snow W, Parulkar G (2014) ONOS: towards an open, distributed SDN OS. In: The third work-
shop on hot topics in software defined networking. ACM, pp 1–6
130. Chen K, Junuthula AR, Siddhrau IK, Xu Y, Chao HJ (2016) SDNShield: towards more compre-
hensive defense against DDoS attacks on SDN control plane. In: IEEE Conference on Communica-
tions and Network Security, pp 28–36
131. Porras P, Shin S, Yegneswaran V, Fong M, Tyson M, Gu G (2012) A security enforcement kernel
for OpenFlow networks. In: The first workshop on hot topics in software defined networks. ACM,
pp 121–126
132. Lim S, Ha J, Kim H, Kim Y, Yang S (2014) A SDN-oriented DDoS blocking scheme for botnet-
based attacks. In: Sixth International Conference on Ubiquitous and Future Networks. IEEE, pp
63–68
133. Zaalouk A, Khondoker R, Marx R, Bayarou K (2014) OrchSec: an orchestrator-based architecture
for enhancing network-security using network monitoring and SDN control functions. In: IEEE
network operations and management symposium, pp 1–9
134. Liyanage M, Ylianttila M, Gurtov A (2014) Securing the control channel of software-defined
mobile networks. In: IEEE international symposium on a world of wireless, mobile and multimedia
networks. IEEE, pp 1–6
135. Bhuyan MH, Kashyap HJ, Bhattacharyya DK, Kalita JK (2014) Detecting distributed denial of
service attacks: methods, tools and future directions. Comput J 57(4):537–556
13
136. Oshima S, Nakashima T, Sueyoshi T (2010) Early DoS/DDoS detection method using short-term
statistics. In: International Conference on Complex, Intelligent and Software Intensive Systems.
IEEE, pp 168–173
137. Nychis G, Sekar V, Andersen DG, Kim H, Zhang H (2008) An empirical evaluation of entropy-
based traffic anomaly detection. In: The 8th ACM SIGCOMM Conference on Internet Measure-
ment, pp 151–156
138. Gu Y, McCallum A, Towsley D (2005) Detecting anomalies in network traffic using maximum
entropy estimation. In: The 5th ACM SIGCOMM Conference on Internet Measurement, pp 32–37
139. Wang R, Jia Z, Ju L (2015) An entropy-based distributed DDoS detection mechanism in software-
defined networking. In: IEEE Trustcom/BigDataSE/ISPA, pp 310–317
140. Sahoo KS, Tiwary M, Sahoo B (2018) Detection of high rate DDoS attack from flash events using
information metrics in software defined networks. In: 10th International Conference on Communi-
cation Systems and Networks. IEEE, pp 421–424
141. Gelenbe E, Loukas G (2007) A self-aware approach to denial of service defence. Comput Netw
51(5):1299–1314
142. Wu Y, Tseng H, Yang W, Jan R (2011) DDoS detection and traceback with decision tree and grey
relational analysis. Int J Ad Hoc Ubiquitous Comput 7(2):121–136
143. Dotcenko S, Vladyko A, Letenko I (2014) A fuzzy logic-based information security management
for software-defined networks. In: 16th International Conference on Advanced Communication
Technology. IEEE, pp 167–171
144. Kokila RT, Selvi ST, Govindarajan K (2014) DDoS detection and analysis in SDN-based envi-
ronment using support vector machine classifier. In: Sixth International Conference on Advanced
Computing. IEEE, pp 205–210
145. Li J, Zhao Z, Li R (2018) Machine learning-based IDS for software-defined 5G network. IET Netw
7(2):53–60
146. Kalkan K, Gur G, Alagoz F (2017) Defense mechanisms against DDoS attacks in SDN environ-
ment. IEEE Commun Mag 55(9):175–179
147. Hsu S, Chen T, Chang Y, Chen S, Chao H, Lin T, Shih W (2015) Design a hash-based control
mechanism in vSwitch for software-defined networking environment. In: IEEE International Con-
ference on Cluster Computing, pp 498–499
148. Lim S, Yang S, Kim Y, Yang S, Kim H (2015) Controller scheduling for continued SDN operation
under DDoS attacks. Electron Lett 51(16):1259–1261
149. Yan Q, Gong Q, Yu FR (2017) Effective software-defined networking controller scheduling method
to mitigate DDoS attacks. IET Electron Lett 53(7):469–471
150. Chin T, Mountrouidou X, Li X, Xiong K (2015) Selective packet inspection to detect DoS flooding
using software defined networking (SDN). In: IEEE 35th International Conference on Distributed
Computing Systems Workshops, pp 95–99
151. Xing T, Huang D, Xu L, Chung C, Khatkar P (2013) SnortFlow: a OpenFlow-based intrusion pre-
vention system in cloud environment. In: Second GENI research and educational experiment work-
shop, pp 89–92
152. Chung C, Khatkar P, Xing T, Lee J, Huang D (2013) NICE: network intrusion detection and
countermeasure selection in virtual network systems. IEEE Trans Dependable Secure Comput
10(4):198–211
153. Ye J, Cheng X, Zhu J, Feng L, Song L (2018) A DDoS attack detection method based on SVM in
software defined network. In: Security and communication networks, Hindawi, pp 1–8
154. Bhandari A, Sangal AL, Kumar K (2016) Characterizing flash events and distributed denial-of-
service attacks: an empirical investigation. Secur Commun Netw 9(13):2222–2239
155. Yu S, Thapngam T, Liu J (2009) Discriminating DDoS flows from flash crowds using information
distance. In: Third International Conference on Network and System Security. IEEE, pp 351–356
156. Behal S, Kumar K (2017) Detection of DDoS attacks and flash events using novel information
theory metrics. Comput Netw 116:96–110
157. Thapngam T, Yu S, Zhou W (2011) Discriminating DDoS attack traffic from flash crowd through
packet arrival patterns. In: IEEE Conference on Computer Communications Workshops, pp
952–957
158. Moshref M, Yu M, Govindan R (2013) Resource/accuracy tradeoffs in software-defined measure-
ment. In: The second ACM SIGCOMM workshop on hot topics in software defined networking, pp
73–78
13
K. S. Sahoo et al.
159. Xiang Y, Li K, Zhou W (2013) Low-rate DDoS attacks detection and traceback by using new infor-
mation metrics. IEEE Trans Inf Forensics Secur 6(2):426–437, 2011. Topics in Software Defined
Networking. ACM, pp 73–78
160. Xu D, Erdogmuns D (2010) Renyis entropy, divergence and their nonparametric estimators. In:
Principe JC (ed) Information theoretic learning. Springer, Berlin, pp 47–102
161. Keti F, Askar S (2015) Emulation of software defined networks using mininet in different simula-
tion environments. In: 6th International Conference on Intelligent Systems, Modelling and Simula-
tion. IEEE, pp 205–210
162. Prete LR, Shinoda AA, Schweitzer CM, Oliveira RLSD (2014) Simulation in an SDN network
scenario using the POX controller. In: IEEE Colombian Conference on Communications and Com-
puting, pp 1–6
163. Niyaz Q, Sun W, Javaid AY (2017) A deep learning based DDoS detection system in software-
defined networking. ICST Trans Secur Saf 4(12):1–12
Publisher’s Note Springer Nature remains neutral with regard to jurisdictional claims in published
maps and institutional affiliations.
Affiliations
Kshira Sagar Sahoo1 · Sanjaya Kumar Panda2 · Sampa Sahoo1 ·

Bibhudatta Sahoo1 · Ratnakar Dash1
Kshira Sagar Sahoo
kshirasagar12@gmail.com
Sampa Sahoo
sampaa2014@gmail.com
Bibhudatta Sahoo
bibhudatta.sahoo@gmail.com
Ratnakar Dash
ratnakar.dash@gmail.com
1
Department of Computer Science and Engineering, National Institute of Technology Rourkela,
Rourkela 769008, India
2
Department of Information Technology, Veer Surendra Sai University of Technology,
Burla 768018, India
13

Toward Secure Software-Defined Networks Against Distributed Denial of Service Attack

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Toward Secure Software-Defined Networks Against Distributed Denial of Service Attack

Uploaded by

Copyright:

Available Formats

The Journal of Supercomputing

Toward secure software‑defined networks

Kshira Sagar Sahoo1 · Sanjaya Kumar Panda2 · Sampa Sahoo1 ·

© Springer Science+Business Media, LLC, part of Springer Nature 2019

Keywords Software-defined networking · Distributed denial of service attack ·

* Sanjaya Kumar Panda

Size of Companies Hit by DDoS Attack

250-499 500-999 1000-4999 5000-9999 10000+

Fig. 1 Size of companies hit by DDoS attack (Incapsula Survey [11])

• We develop the conceptual idea of SDN architecture. Then, we classify different

The remainder of this paper is organized as follows. In Sect. 2, we highlight the

An Internet protocol (IP)-based network comprises a series of interconnected

SDN Major Chal-

Possible Secu- Possible Secu-

DDoS in Tradi- DDoS

SDN as a SDN as a Detection and Mit- Proposed

Fig. 2 Layout of the paper

Fig. 3 Conventional router

In this subsection, we provide the fundamental discussion on different layers of

Fig. 4 Basic SDN architecture [17]

ler and time to live (TTL).

3 Major challenges in SDN

4 Possible security threats and attacks to SDN layers

4.1 Possible security threats to SDN layers

4.1.1 Application layer security threats

• Network service chaining functionality uses SDN capabilities to create a ser-

4.1.2 Control layer security threats

4.1.3 Data layer security threats

• The switch firmware of SDN can be compromised, because it cannot handle

4.2 Possible security attacks to SDN layers

Table 4 Possible attacks to SDN Layer → Forwarding Control layer Appli-

5 Overview of DDoS attack

5.1 Causes of DDoS attack

5.2 Taxonomy of DDoS attack

• Volumetric attack The attacker’s goal is to inject a massive amount of traffics

Table 5 Popular DDoS massacres [67]

Volumetric Protocol Application Layer

DNS Amplification Loop Attack HTTP Flood

Fig. 5 DDoS attack taxonomy

• HTTP flooding It is an application-level attack. In the session flooding attack,

6 Overview of DDoS attack in SDN

6.1 Does SDN provide protection solution to DDoS or is it a victim of DDoS?

6.2 SDN as DDoS detection solution

Table 6 Features of SDN as a enabler and victim of DDoS attack

6.3 SDN as the victim of DDoS attack

6.3.1 DDoS attack to forwarding layer

Table 8 Possible DDoS attacks Layer Possible attacks

Fig. 6 Possible DDoS strategies to the different layers of SDN

process is much slower. For instance, TCAM is able to update approximately 50

6.3.2 DDoS attack to control layer

6.3.3 DDoS attack to application layer

Fig. 7 DDoS threats to the different layers of SDN [67]

7 Potential countermeasures for DDoS attack in SDN

tion through digital signature using the NOX

8 DDoS detection techniques in SDN

In statistical-based solution, some statistical characteristics and baseline profiles

Entropy Based Blocking Port

Machine Learning Drop Packets

Scheduling Based DPI

Connection Rate Based Alternation of Logical/Physical Address

Traffic Pattern Behaviour Traffic Redirection

8.2 Machine learning‑based solutions

8.4 Connection rate‑based solutions

9 Proposed SDN‑based DDoS detection framework

3 Major challenges in SDN

4 Possible security threats and attacks to SDN layers

4.1 Possible security threats to SDN layers

4.1.1 Application layer security threats

4.1.2 Control layer security threats

4.1.3 Data layer security threats

4.2 Possible security attacks to SDN layers

5 Overview of DDoS attack

5.1 Causes of DDoS attack

5.2 Taxonomy of DDoS attack

6 Overview of DDoS attack in SDN

6.1 Does SDN provide protection solution to DDoS or is it a victim of DDoS?

6.2 SDN as DDoS detection solution

6.3 SDN as the victim of DDoS attack

6.3.1 DDoS attack to forwarding layer

6.3.2 DDoS attack to control layer

6.3.3 DDoS attack to application layer

7 Potential countermeasures for DDoS attack in SDN

8 DDoS detection techniques in SDN

8.2 Machine learning‑based solutions

8.4 Connection rate‑based solutions

9 Proposed SDN‑based DDoS detection framework

10 Future research direction