A Testbed for the Evaluation of Denial of Service Attacks in Software-Defined Networks

Abstract

Software defined networking (SDN) is being widely deployed within enterprise and carrier networks to streamline network services provisioning and reduce costs. This approach improves upon traditional networking protocol technologies by decoupling the data and control planes and moving all control provisioning decisions to a centralized SDN controller. Overall, centralized control delivers much more cost-effective and flexible networking setups that can support a wide range of customized user-driven network management applications, e.g., traffic engineering, security, survivability, policy control, etc. However, the separation of the data and control layers in a SDN network introduces many attack points for malicious users to exploit. In particular, large-scale denial of service (DoS) attacks are a major concern here, as they can effectively shut down vital communications between the SDN controller and data plane nodes. Given the increasing sophistication of such attacks, SDN DoS detection and mitigation have become vital concerns. Although various studies have addressed this problem area, there is a further need to develop and test solutions in live realistic network settings. Along these lines, this paper overviews this important area and demonstrates the impact of DoS attacks on SDN elements in the NSF GENI network testbed. This work provides a key baseline and set of input data from which to develop further detection and mitigation strategies.

Full text

A Testbed for the Evaluation of Denial of Service
Attacks in Software-Defined Networks
Andrea P. Wright
Dept. of Electrical Engineering
University of South Florida
Tampa, FL, USA
apwright@mail.usf.edu
Nasir Ghani
Dept. of Electrical Engineering
University of South Florida
Tampa, FL, USA
nghani@usf.edu
Abstract—Software defined networking (SDN) is being widely
deployed within enterprise and carrier networks to streamline
network services provisioning and reduce costs. This approach
improves upon traditional networking protocol technologies by
decoupling the data and control planes and moving all control
provisioning decisions to a centralized SDN controller. Over-
all, centralized control delivers much more cost-effective and
flexible networking setups that can support a wide range of
customized user-driven network management applications, e.g.,
traffic engineering, security, survivability, policy control, etc.
However, the separation of the data and control layers in a SDN
network introduces many attack points for malicious users to
exploit. In particular, large-scale denial of service (DoS) attacks
are a major concern here, as they can effectively shut down
vital communications between the SDN controller and data
plane nodes. Given the increasing sophistication of such attacks,
SDN DoS detection and mitigation have become vital concerns.
Although various studies have addressed this problem area, there
is a further need to develop and test solutions in live realistic
network settings. Along these lines, this paper overviews this
important area and demonstrates the impact of DoS attacks on
SDN elements in the NSF GENI network testbed. This work
provides a key baseline and set of input data from which to
develop further detection and mitigation strategies.
Index Terms—DoS attacks, GENI, DoS detection, Software-
defined Networking, Software-defined Networking security
I. INTRODUCTION
Software-Defined Networking (SDN) presents a multi-layer
networking architecture for streamlining network service pro-
visioning and operation. Specifically, this framework is com-
prised of three planes, as shown in Figure 1. At the lowest
level is the data plane, which is responsible for forwarding
network traffic. In the SDN realm, routers and switches are
located at this plane. Meanwhile, the middle layer comprises
of the control plane, which essentially drives the data plane
by providing routing tables (with next-hop information). Es-
sentially, the control plane acts as the brain of the network as
it determines the end-to-end routes that packets must traverse
to reach their destinations. Namely, the control plane learns
about the network topology and computes the routing paths,
whereas the data plane uses this filtered information (received
from the control plane) to execute network flow rules. Finally,
the SDN architecture also has a higher-level application plane,
see Figure 1. Specifically, this plane includes an Application
Programming Interface (API) to allow network operators to
access the underlying control and data planes and implement
a wide range of functionality, i.e., routing, security, quality of
service (QoS) support, etc. In particular, SDN-based security
applications can include (or work in conjunction with) fire-
walls, intrusion detection systems (IDS), intrusion prevention
systems (IPS), network-monitoring devices, etc. [1], [2].
Overall SDN provides a highly flexible network setup in
which individual SDN planes can be programmed to support
customized user services. However, this decoupled architecture
also presents many new and unique security vulnerabilities.
For example, the control plane interacts with both the data and
application planes here. Hence malicious users can potentially
interfere with these communications by injecting harmful net-
work traffic (at the data plane) or by creating harmful/hidden
applications (at the application plane). In particular, SDN is
quite susceptible to various denial of service (DoS) attacks,
which can affect the operation of the control plane, and in the
worst case shut down vital communications between the SDN
controller and data plane nodes.
It is also important to note the importance of SDN security
within the context of advances in the Internet of Things (IoT).
Specifically, SDN is being touted as a solution for managing
large numbers of small IoT devices in a centralized manner.
Indeed, SDN setups are well-suited for controlling such sim-
plified networked sensor devices and can provide a complete
framework for machine-to-machine IoT interaction [3]. Today,
most existing IoT devices require constant connection to
cloud or database server over the Internet. Moreover, most of
these systems utilize various types of wireless data transfer
protocols, e.g., 802.11 wireless, Bluetooth, 3G, 4G, Long-
Term Evolution (LTE), etc. Clearly any of these transmissions
can be subject to confidentiality, integrity, and availability
concerns from malicious actors. In fact DoS attacks are two of
the biggest threats emanating from small IoT devices, which
are vulnerable to being compromised/used in large botnet
attacks [4]–[6]. Due to the increasing use of SDN within IoT
setups, there is a real potential to target the SDN control plane
itself through such channels. Hence, the SDN and IoT security
domains are becoming increasingly interdependent today.
In light of the above, this paper focuses on the problem of
DoS attacks on SDN control planes. Although various existing978-1-7281-0137-8/19/$31.00 ©2019 IEEE
Authorized licensed use limited to: University of South Florida. Downloaded on December 28,2020 at 15:40:54 UTC from IEEE Xplore. Restrictions apply.

Fig. 1. Overview of SDN Layers
studies have looked at this problem area, there are few (if any)
efforts, which evaluate the impact of such attacks in realistic
operational network settings. In light of the above, this paper
develops a detailed operational testbed for evaluating DoS
attacks in SDN settings by leveraging the NSF-funded Global
Network for Network Innovation (GENI) facility. Specifically,
this state-of-the-art infrastructure allows for the creation and
testing of a range of SDN topologies using any set of preferred
software tools (installed on end host devices).
Overall, this paper is organized as follows. First, Section II
presents a summary of DoS attacks in SDN networks. Some
existing solutions for such scenarios are then presented in
Section III. Next, the proposed GENI-based SDN testbed for
DoS evaluation is detailed in Section IV, followed by some
detailed empirical results from live network runs in Section V.
Finally, conclusions and future work directions are outlined in
Section VI.
II. DOS ATTACKS IN SDN ENVIRONMENTS
DoS attacks try to exhaust (shutdown) network elements
by rendering their resources unavailable to user services.
These attacks can originate from many initiating elements, i.e.,
volumetric, protocol and application attacks [7]. Namely, volu-
metric attacks generate excessive network traffic to overwhelm
certain devices, thereby causing degradation in bandwidth
capacity. Note that such attacks can be mounted using both
TCP and UDP protocol traffic. Meanwhile [7] also defines
additional DoS attacks which focus on network protocols, i.e.,
to degrade network operations by targeting specific routing or
control protocols. These attacks are a major concern in SDN
settings, as they can hamper critical control plane communi-
cations. Finally, SDN application plane attacks can also be
launched by exploiting vulnerabilities in network application
programs [8]. In the context of the above, the focus of this
effort is to study attacks on the SDN control plane. Consider
the details.
The inherent nature of the SDN framework opens it up
to more targeted control plane attacks. First, consider the
operation of SDN-based networks, which use various protocols
to communicate between the SDN controller (control plane)
and data nodes (data plane). Typically, this communication is
done using a ‘southbound API’ with messaging protocols such
as OpenFlow, Path Computation Element Protocol (PCEP),
etc. In particular, the OpenFlow protocol allows operators to
install flow table entries in data switches, removing the need
for maintaining complex routing tables (by running distributed
routing protocols at each node). Instead, SDN controllers can
simply use OpenFlow messages (over a secure path) to install
flow rules/decisions and dictate routes for user traffic flows
[9]. Meanwhile, PCEP also supports communication with the
SDN controller, which in the IETF context is usually referred
to as the Path Computation Element (PCE). Namely, a PCE
typically maintains a network graph and calculates network
routing paths for user flows (installed using PCEP) [10].
However, this study only focuses on the OpenFlow protocol
as it is gaining the most traction in operator and enterprise
domains today.
In general, the SDN architecture is quite vulnerable to
DoS attacks on the control plane. For example, data plane
switches typically store end-to-end flow routes for packets
arriving from previously seen source and destination hosts,
i.e., to circumvent repeated controller requests and expedite
forwarding. However, malicious user(s) can generate a flood of
spurious/malformed packets that have no preexisting flow rules
or entries in the switch flow tables. These packets can generate
a host of lookup requests from the ingress (entry) switching
nodes, i.e., OpenFlow Packet in messages [11], forcing the
SDN controller to make decisions for each one. The SDN
architecture is also vulnerable to well-known TCP/SYN flood
attacks [12], [13]. Namely, initial SYN packets from spoofed
hosts will likely be unrecognized by the ingress switches and
hence generate Packet in requests at the controller. In turn, the
controller will establish appropriate flow (drop) rules by send-
ing OpenFlow Packet out message responses to one or more
data plane nodes, i.e., including the ingress switches generat-
ing the initial Packet in queries. Finally, destination hosts will
respond by sending SYN/ACK responses to the spoofed source
addresses, triggering another round of Packet in requests from
other switches (connected to the destination victim hosts). As
a result, the overall level of message congestion on the control
plane can be quite high here.
III. REL ATED WO RK
Various studies have looked at DoS detection and prevention
within SDN infrastructures. Foremost, early detection of DoS
attacks is critical for effective mitigation, i.e., since resolving
any attack patterns can greatly improve detection rates [14].
Along these lines, Aleroud et al. utilize table flows to create a
graph model to compare existing network traffic with preexist-
ing attack patterns. This approach also stores the attack history
in local databases for rapid comparison with data traffic flows.
Similar research analyzing southbound controller interface
flow rules is also presented in [15] and [16]. Meanwhile,
Kuerban et al. create and implement an application, termed as
FlowSec, for bandwidth management at the SDN controller.
This solution implements a cap (limit) on the number of
packets that the controller receives from the SDN switch.
Authorized licensed use limited to: University of South Florida. Downloaded on December 28,2020 at 15:40:54 UTC from IEEE Xplore. Restrictions apply.

Hence, by limiting the packet rate, FlowSec can ensure a
QoS metric and mitigate the effects of potential Packet in
floods. In addition, Mohammadi et al. monitor the southbound
controller interface to detect the presence of malicious activity.
The SDN controller is then alerted to implement an appropriate
prevention mechanism. Similarly, [17] proposes to mitigate
DOS attacks by prioritizing the controller’s Packet in mes-
sages based upon the host source. Wei et al. further protect
the SDN control plane by assigning higher priority to the
most likely legitimate source(s). As such, packet requests
from malicious hosts are assigned a lower priority, allowing
traffic to be dropped at a higher rate than legitimate requests.
Meanwhile [18] focuses on SDN control plane flow rules and
probes the flow tables (in the switch nodes) to understand the
network configuration. A unique step here involves acting as a
malicious user in order to understand how packets are handled
by the network, e.g., dropped, forwarded, or established as a
new table entry. Based upon the findings, a more extensive
controller protection framework is proposed by adding new
security applications above the controller. Finally, the authors
in [19] propose a scheme to detect and mitigate DoS attacks
by measuring performance at the controller.
Others have also looked at distributed DoS (DDoS) attacks
on SDN control architectures [20], [21]. For example, several
studies have looked at preventing harmful DDoS traffic from
reaching an SDN controller. Specifically, the EarlyDrop [22]
scheme monitors the SDN controller and blocks all traffic
that is flagged as malicious. Similarly, [23] proposes traffic
flow monitoring for SDN networks and tries to identify any
anomalous traffic by using entropy-based algorithms. Like-
wise, StateSec attempts to detect and mitigate DDoS attacks
on SDN networks by using the decoupled plane as a factor
in mitigation [24]. Again, this scheme uses entropy-based
anomaly detection to limit overload at the SDN controller.
Nevertheless, despite the above contributions, there are
few (if any) studies evaluating SDN-based DoS attacks in
live, realistic network settings. Instead, most existing efforts
have either conducted simulation-based evaluation (e.g., using
Mininet) or analyzed very small setups with a few hosts acting
as SDN devices. Accordingly, Wang [25] even notes that
simulation is a flexible strategy but does not run the actual
operating systems or live applications. In light of the above,
more realistic approaches can be developed by leveraging
real-world networking devices and applications in controlled
environments. Along these lines, this effort proposes to use
the flagship NSF GENI testbed environment to evaluate the
impact of DoS attacks in SDN settings, i.e., to establish SDN
controllers and nodes, initiate DoS attacks on those devices,
and measure/assess the impact on the control plane.
IV. MET HO D
The NSF GENI testbed infrastructure provides a state-of-
the-art facility to build and evaluate SDN test case scenarios.
Hence, this facility is chosen to serve as the virtual laboratory
for the testbed evaluation approach. In particular, GENI allows
users to request/reserve distributed network resources, termed
as ‘slices’, and build arbitrary switch topologies and end-host
configurations for testing purposes. Leveraging the above, a
sample 5 node topology was created in GENI to model a small-
scale SDN-controlled infrastructure network and study the
impact of DoS attacks, as shown in Figure 2. In particular, this
slice was reserved at several InstaGENI facilities by carefully
selecting sites with adequate network resources, i.e., including
those at the University of Kentucky and Ohio State University.
Overall, the GENI testbed setup consisted of 11 EMULAB-
Xen virtual nodes and 12 links. Of these, five nodes were
configured as OpenFlow Virtual Switch (OVS) switches (i.e.,
s1-s4, Figure 2), and an additional five nodes were reserved
as end hosts, each connected to a unique switch (i.e., host1-
host5, Figure 2). Meanwhile, one node was established as
the OpenFlow SDN controller (connected to all five OVS
switches) and was configured to run the Floodlight software
(SDN controller). Carefully note that the virtual nodes are not
switches by default and had to be configured with OVS and
coupled with an Ethernet bridge to serve as the SDN switch.
Finally the jFed toolkit [26], [27] was also used to access all
virtual hosts and switches.
The impact of DoS attacks on the above 5-switch testbed
configuration was evaluated by using the hping3 command
toolkit to generate malicious attack traffic. In particular, the
Linux-based systat and vnstat tools were used to monitor per-
formance behaviors and collect measurement data, i.e., during
both normal and attack conditions. Specifically, appropriate
monitors were placed at all the OVS switch nodes as well as
on the SDN controller. This setup allowed close examination
of the network activity during hping3 floods. Some detailed
empirical results are now presented and discussed, with a focus
on processor (CPU) and memory utilization during attack
intervals.
V. TE ST BE D PER FO RMANCE RESULTS
Experimental DoS attacks were done in the GENI testbed
by varying several hping3 command parameters, i.e., in-
cluding the inter-packet arrival times, source addresses, and
destination addresses. In particular, tests were launched from
host 1 (connected to ingress switch s1, Figure 2) using two
Fig. 2. A five switch SDN topology in GENI
Authorized licensed use limited to: University of South Florida. Downloaded on December 28,2020 at 15:40:54 UTC from IEEE Xplore. Restrictions apply.

Fig. 3. Processor (CPU) utilization at controller during DoS (hping3) attack: 100 µs vs 50µs intervals
different inter-arrival times to simulate varying DoS attack
rates/intensities, i.e., 50 us and 100 us (microseconds). All
attacks were started after 1 minute (60 seconds) of idle
time and concluded after 5 minutes (300 seconds) to clearly
delimit pre-/post-attack intervals. Furthermore, randomized
(non-existent) destination addresses were specified in order
to stress the control plane, and these values were tested for
both valid source addresses (host 1) and spoofed (random)
source addresses. In particular, the former is equivalent to a
basic single source attack, whereas the latter can be considered
equivalent to more realistic a TCP SYN flood attack. Now
as discussed in Section II, unknown destination packets will
end up generating OpenFlow Packet in messages, i.e., lookup
requests, prompting the SDN controller to generate appropriate
OpenFlow Packet out responses to the ingress switch, s1. As
such, these lookups can cause increased processor and memory
utilization at the switch nodes and controller.
Along these lines, Figure 3 plots the measured processor
(CPU) utilization at the ingress switch s1 for hping3 packets
arriving from host 1 with both random destinations and
(spoofed) random source/random destinations. On average,
these findings indicate that the ingress switch experienced
higher processor loads for the smaller hping3 interval, which
corresponds to a faster DoS attack rate. Specifically, this
increase is visible for both tests types (i.e., random destinations
and random source/destinations) as shown by a higher ‘base’
floor for the orange plot line (corresponding to hping3 interval
of 50 us, Figure 3). The random source/destinations scenarios
also exhibited slightly higher average processor utilization
values. Additionally, a review of the vnstat traffic statistics
also showed that the SDN controller sent/received many more
bytes than the ingress switch s1. Overall, the above processor
utilization increase is consistent with the expectations from a
DoS attack on the SDN control plane [28], [29].
Next, the available (free) memory at ingress switch s1 is also
plotted in Figure 4, i.e., for host 1 transmitting hping3 packets
with random destination and (spoofed) random source/random
destinations. For the case of a fixed source address and 50 us
hping3 packet intervals, these results show that the memory
utilization eventually begins to decrease as the duration of
the attack continues. Furthermore, for the more realistic case
of randomized source/destination addresses, the shorter 50 us
packet spacing consumes slightly more memory than the 100
us spacing. In both cases, however, the available (free) memory
trends downward for increasing attack durations.
VI. CONCLUSIONS AND FUTURE DISCUSSIONS
Software-defined networking (SDN) provides a very vi-
able framework for reducing operator costs and streamlining
network service provisioning. However, SDN technologies
also introduce new control plane architectures, which are
vulnerable to a host of security concerns. In particular, denial
of service (DoS) attacks represent a major threat to the smooth
operation of SDN-based infrastructures. As a result, a host of
Authorized licensed use limited to: University of South Florida. Downloaded on December 28,2020 at 15:40:54 UTC from IEEE Xplore. Restrictions apply.

Fig. 4. Memory utilization at switch system during DoS (hping3) attack: 100 µs vs 50µs intervals
studies has looked at detecting and mitigating DoS attacks on
SDN control planes. However, for the most part, these efforts
have used simplified simulation environments or conducted
evaluation with a few emulating host systems. As a result, this
paper presents one of the first efforts to evaluate DoS attacks
in realistic, operational network environments. Specifically, the
flagship NSF GENI testbed facility is used to evaluate the
impact of DoS attacks in a live OpenFlow-based SDN network
setting using the hping3 utility. Overall, the findings confirm
that higher DoS attack intensities (reduced packet inter-arrival
times) can cause increased processor and memory overheads
at data plane switching nodes, i.e., due to excessive OpenFlow
Packet in and Packet out messages processing overheads.
In particular, attacks with spoofed source and destination
addresses yielded most impacts here.
Future tests plan to build upon this initial study and in-
vestigate several additional directions in live SDN settings.
Foremost, the impact of DOS attack traffic on regular (benign)
user packet flows will be investigated, i.e., in terms of resultant
packet loss and delay. Specifically, the iperf tool will be used to
emulate normal network traffic flows, as this solution is quite
effective for traffic generation and bandwidth management
[30]. In addition, expanded testbed configurations will also
be developed to mimic larger distributed DoS (DDoS) type
scenarios, e.g., including multiple attacking hosts, multiple
hosts connected to each switch, etc. Finally, various new and
existing DoS detection/mitigation strategies will also be devel-
oped and tested at the SDN controller, i.e., SDN application
plane development.
ACKNOWLEDGMENT
The authors would like to acknowledge and thank the
Florida Education Fund, the Alfred P. Sloan Foundation and
Cyber Florida for their continued support.
REFERENCES
[1] D. Kreutz, F. M. Ramos, P. E. Verissimo, C. E. Rothenberg, S. Azodol-
molky, and S. Uhlig, “Software-defined networking: A comprehensive
survey,” Proceedings of the IEEE, vol. 103, no. 1, pp. 14–76, 2015.
[2] M. Pham and D. B. Hoang, “Sdn applications-the intent-based north-
bound interface realisation for extended applications,” in NetSoft Con-
ference and Workshops (NetSoft). IEEE, 2016.
[3] S. K. Tayyaba, M. A. Shah, O. A. Khan, and A. W. Ahmed, “Software
defined network (sdn) based internet of things (iot): A road ahead,” in
Proceedings of the International Conference on Future Networks and
Distributed Systems. ACM, 2017, p. 10.
[4] Y. Lee, W. Lee, G. Shin, and K. Kim, “Assessing the impact of
dos attacks on iot gateway,” in Advanced Multimedia and Ubiquitous
Engineering. Springer, 2017, pp. 252–257.
[5] Q. Chen, H. Chen, Y. Cai, Y. Zhang, and X. Huang, “Denial of
service attack on iot system,” in 2018 9th International Conference on
Information Technology in Medicine and Education (ITME). IEEE,
2018, pp. 755–758.
[6] M. Daud, R. Rasiah, M. George, D. Asirvatham, A. F. A. Rahman, and
A. Ab Halim, “Denial of service:(dos) impact on sensors,” in 2018 4th
International Conference on Information Management (ICIM). IEEE,
2018, pp. 270–274.
[7] M. M. Oo, S. Kamolphiwong, and T. Kamolphiwong, “The design of
sdn based detection for distributed denial of service (ddos) attack,” in
2017 21st International Computer Science and Engineering Conference
(ICSEC). IEEE, 2017, pp. 1–5.
Authorized licensed use limited to: University of South Florida. Downloaded on December 28,2020 at 15:40:54 UTC from IEEE Xplore. Restrictions apply.

[8] P. Raghav and A. Dua, “Enhancing flow security in ryu controller
through set operations,” in Computer and Communications (ICCC), 2017
3rd IEEE International Conference on. IEEE, 2017, pp. 1265–1269.
[9] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson,
J. Rexford, S. Shenker, and J. Turner, “Openflow: Enabling
innovation in campus networks,” SIGCOMM Comput. Commun.
Rev., vol. 38, no. 2, pp. 69–74, Mar. 2008. [Online]. Available:
http://doi.acm.org/10.1145/1355734.1355746
[10] E. Husni and A. Bramantyo, “Design and implementation of mpls sdn
controller application based on opendaylight,” in 2018 International
Symposium on Networks, Computers and Communications (ISNCC).
IEEE, 2018, pp. 1–5.
[11] D. Gao, Z. Liu, Y. Liu, C. H. Foh, T. Zhi, and H.-C. Chao, “Defending
against packet-in messages flooding attack under sdn context,” Soft
Computing, vol. 22, no. 20, pp. 6797–6809, 2018.
[12] P. Kumar, M. Tripathi, A. Nehra, M. Conti, and C. Lal, “Safety: Early
detection and mitigation of tcp syn flood utilizing entropy in sdn,” IEEE
Transactions on Network and Service Management, vol. 15, no. 4, pp.
1545–1559, 2018.
[13] R. Mohammadi, R. Javidan, and M. Conti, “Slicots: An sdn-based
lightweight countermeasure for tcp syn flooding attacks,” IEEE Transac-
tions on Network and Service Management, vol. 14, no. 2, pp. 487–497,
2017.
[14] A. Aleroud and I. Alsmadi, “Identifying dos attacks on software defined
networks: a relation context approach,” in Network Operations and
Management Symposium (NOMS), 2016 IEEE/IFIP. IEEE, 2016, pp.
853–857.
[15] M. Kuerban, Y. Tian, Q. Yang, Y. Jia, B. Huebert, and D. Poss,
“Flowsec: Dos attack mitigation strategy on sdn controller,” in 2016
IEEE International Conference on Networking, Architecture and Storage
(NAS). IEEE, 2016, pp. 1–2.
[16] R. Mohammadi, R. Javidan, M. Keshtgary, M. Conti, and C. Lal,
“Practical extensions to countermeasure dos attacks in software defined
networking,” in Network Function Virtualization and Software Defined
Networks (NFV-SDN), 2017 IEEE Conference on. IEEE, 2017, pp.
1–6.
[17] L. Wei and C. Fung, “Flowranger: A request prioritizing algorithm for
controller dos attacks in software defined networks,” in Communications
(ICC), 2015 IEEE International Conference on. IEEE, 2015, pp. 5254–
5259.
[18] P.-C. Lin, P.-C. Li, and V. L. Nguyen, “Inferring openflow rules by active
probing in software-defined networks,” in Advanced Communication
Technology (ICACT), 2017 19th International Conference on. IEEE,
2017, pp. 415–420.
[19] Y. E. Oktian, S. Lee, and H. Lee, “Mitigating denial of service (dos)
attacks in openflow networks,” in Information and Communication
Technology Convergence (ICTC), 2014 International Conference on.
IEEE, 2014, pp. 325–330.
[20] N. Z. Bawany, J. A. Shamsi, and K. Salah, “Ddos attack detection
and mitigation using sdn: methods, practices, and solutions,” Arabian
Journal for Science and Engineering, vol. 42, no. 2, pp. 425–441, 2017.
[21] B. Pande, G. Bhagat, S. Priya, and H. Agrawal, “Detection and miti-
gation of ddos in sdn,” in 2018 Eleventh International Conference on
Contemporary Computing (IC3). IEEE, 2018, pp. 1–3.
[22] R. Bauer, H. Heseding, and M. Flittner, “Earlydrop: A trade-off driven
ddos defense mechanism for software-defined infrastructures,” in Local
Computer Networks (LCN), 2017 IEEE 42nd Conference on. IEEE,
2017, pp. 207–210.
[23] J. Boite, P.-A. Nardin, F. Rebecchi, M. Bouet, and V. Conan, “Statesec:
Stateful monitoring for ddos protection in software defined networks,”
in Network Softwarization (NetSoft), 2017 IEEE Conference on. IEEE,
2017, pp. 1–9.
[24] F. Rebecchi, J. Boite, P.-A. Nardin, M. Bouet, and V. Conan, “Traffic
monitoring and ddos detection using stateful sdn,” in Network Soft-
warization (NetSoft), 2017 IEEE Conference on. IEEE, 2017, pp. 1–2.
[25] S.-Y. Wang, “Comparison of sdn openflow network simulator and emu-
lators: Estinet vs. mininet,” in Computers and Communication (ISCC),
2014 IEEE Symposium on. IEEE, 2014, pp. 1–6.
[26] B. Vermeulen, W. Van de Meerssche, and T. Walcarius, “jfed toolkit,
fed4fire, federation,” in GENI Engineering Conference, vol. 19, 2014.
[27] [Online]. Available: https://jfed.ilabt.imec.be/
[28] V. Vimal and M. J. Nigam, “Plummeting flood based distributed-dos
attack to upsurge networks performance in ad-hoc networks using
neighborhood table technique,” in TENCON 2017-2017 IEEE Region
10 Conference. IEEE, 2017, pp. 139–144.
[29] M. S. Chaudhary and M. P. Thanvi, “Performance analysis of modified
aodv protocol in context of denial of service (dos) attack in wireless
sensor networks,” International Journal of Engineering Research and
General Science, vol. 3, no. 3, 2015.
[30] S. Mishra, S. Sonavane, and A. Gupta, “Study of traffic generation
tools,” International Journal of Advanced Research in Computer and
Communication Engineering, vol. 4, no. 6, pp. 4–7, 2015.
Authorized licensed use limited to: University of South Florida. Downloaded on December 28,2020 at 15:40:54 UTC from IEEE Xplore. Restrictions apply.