Tishk International University

Faculty of engineering (computer engineering)

Software-Defined Networking (SDN) for Security

Abdullah Dara
1.Abstract
Software-defined network (SDNs) have fundamentally changed network infrastructure by
decoupling the data plane and the control plane. This architectural shift rejuvenates the network
layer by granting the re-programmability and centralized management of networks which brings
about exciting challenges. Although an SDN seems to be a secured network when compared to
conventional networks, it is still vulnerable and faces rigorous deployment challenges. Moreover,
the bifurcation of data and control planes also opens up new security problems. This systematic
literature review (SLR) has formalized the problem by identifying the potential attack scenarios
and highlighting the possible vulnerabilities. Eighty-six articles have been selected carefully to
formulize the SLR. In this SLR, I have identified major security attacks on SDN planes, including
the application plane, control plane, and data plane. Moreover, this research also identifies the
approaches used by industry experts and researchers to develop security solutions for SDN
planes. In this research, I have introduced an attack taxonomy and proposed a collaborative
security model after comprehensively identifying security attacks on SDN planes. Lastly,
research gaps, challenges, and future directions are discussed for the deployment of secure SDNs.

2.Introduction
The software-defined network (SDN) has become one of the top networking architectures for
simplifying network management by enabling innovation in network communication. The
fundamental characteristic of SDN architecture is to decouple the control plane from the data
plane. A control plane is logically centralized to maintain the network state and gives instructions
to the data plane [1]. In the data plane network, devices forward data packets by following the
control instructions. However, this architectural transformation has received immense attention
from the network industry and academic fields. Additionally, the advantages of SDNs have been
proven in different scenarios, such as Google B4, NTT’s edge gateways, and Microsoft’s public
cloud [2–4]. SDN also offers a standardized or consistent application programming interface
(API) for adding up-to-date programmable features to the network to overcome flexibility and
programmability issues in traditional networks. In addition, SDNs help network service providers
to obtain a more flexible, manageable, and programmable network architecture [5]. These
properties of SDNs help to empower the control plane and accomplish a global view of network
topology to dynamically modify the functionalities of the network. Although SDNs manage
networks in a more centralized way, it is now endorsed by both academic and industrial
practitioners. This is because security has become a major concern at all levels, especially in
newly designed network systems, such as cloud networks and peer-to-peer networks. Therefore,
despite the number of advantages, SDNs have many inherent network security challenges,
including scalability, reliability, controller placement, and latency [6]. Moreover, several security
attacks were also investigated by other researchers and were examined in other network systems
[7–10]. On the downside, the increased potential of security attacks on SDN layers has become a
prime concern. The increased potential of security threats, including the consistency of flow rules,
controller vulnerability, legitimacy, malicious applications, and standardized and northbound and
southbound communications, occurs due to a lack of best practices of SND functions,
components, and the open programmability of networks. From the literature, it is clear that due to
the multi-layered architecture of SDN, security threats to different layers are different.
SDN architecture is presented in Figure 1, with the most common and major security challenges
on SDN layers. The application layer is also known as the management layer and is the topmost
layer in the SDN architecture. All business and security applications that are designed by
developers are executed on this layer. Applications controlled by this layer consist of firewall
implementation, access control, load balancer, intrusion prevention system (IPS), intrusion
detection system (IDS), and network virtualization.

Unauthorized
Modification

Figure 1. SDN Architecture with major security attacks.

The application layer communicates with the control layer by using northbound API [11].
Although applications deploy multiple network services in SDN, there are still some major
security challenges in SDN due to the emerging abilities of hackers. The most common security
threats at this layer are authentication, authorization, access control, and accountability. The
control layer is the mediator between the application layer and the data layer, which consists of
the SDN controller or network operating system (NOS). The overall responsibility of this layer is
to manage the functionality of the entire network by taking decisions on packet forwarding and
routing [12]. The control layer communicates with its lower layer (data layer) by using
southbound API. The logically centralized controller consists of node flows like flood light, POX,
NOX, MUL, Jaxon, etc. This layer is only responsible for decision making due to its logically
centralized controller; therefore, it is easily targeted in order to perform malicious tasks across the
entire network. Major security challenges on this layer are unauthorized applications, flow rule
modification, policy enforcement, and forwarding policy discovery. The data layer is responsible
for packet forwarding, according to the assigned policies of forwarding devices, such as physical
switches and virtual switches.

3.Literature Review

Security challenges in SDN are increasing as its technology spreads across various areas.
Recognizing these challenges is essential to implement necessary security measures and fully
benefit from SDN. In this section, I've identified vulnerabilities in different SDN layers.

Kreutz et al. pointed out threat vectors, highlighting the lack of a reliable mechanism for trust
between applications and controllers in SDNs. This vulnerability allows attackers to inject forged
traffic flows, triggering potential DoS attacks using network elements like servers and switches.
Attacks on controller and switch vulnerabilities can disrupt the entire network. Preventing DDoS
attacks is crucial, and robust solutions are needed for detection and mitigation [13-20].

Schehlmann et al. proposed an evaluation methodology for SDN security, emphasizing criteria
like authenticity, availability, confidentiality, consistency, and integrity [21].
Abdulkarem et al. identified DDoS attacks in the SDN data layer and proposed a Python-based
solution for detection and mitigation. The central controller is a vulnerable component due to
weak authentication, information disclosure, and incomplete encryption, affecting the entire
network if not properly secured. Switches are prone to attacks on communication channels,
potentially disrupting links between switches and controllers [19-25].

Security challenges also extend to the northbound and southbound interfaces. The northbound
interface lacks consistent authentication and authorization methods, leaving room for attacks.
Exploiting its programmability, an attacker can access critical resources in the control, leading to
changes or network occupation. The southbound interface faces security issues due to open flow
protocol leakage, using an insecure TLS/SSL protocol for data encryption. This can result in data
leakage, controller spoofing, eavesdropping, and other security attacks [26-35].

Scott-Hayward et al. conducted a comprehensive survey on SDN security challenges, proposing

holistic approaches for solutions. Ahmad et al. identified security threats in SDN across the
application, data, and control planes, recommending security platforms to protect each plane from
various attacks [36].
Table 1 shows already published SLRs, high- lighting the contribution of my research. We have
compared our defined research questions with already available solution where C symbol
indicates the matched contribution of the study and × symbol shows the gaps of their study.
 Addressed Attacks Addressed Attacks Addressed Attacks Proposed Security Discussed Challenges, Gaps,
Ref.: and Solutions for and Solutions for and Solutions for Model against Each and Future Research
Application Plane Data Plane Control Plane Attack Directions
[38] × C × × C
[39] C C C × C
[40] × × × × C

[41] × × × × C
[42] C C C x C
[43] C C C × c
[44] × × × × C

[45] C C C x C
[46] × C × × C

4.Research Method

The primary objective of a SLR is to present inclusive knowledge from the literature in the
research field in an organized and holistic way. Apart from that, a SLR can also help to identify
existing research gaps as well as the consequent recognition of avenues for research in the future.
In this section, we define the method used to conduct this SLR. The method involved research
questions (RQ), search string, data sources.

4.1. Research Questions

The objective of this SLR is to provide a comprehensive review of security and privacy issues in
SDNs. Therefore, we designed seven research questions in the first phase of this SLR. We
evaluated the security attacks/threats on SDN layers/planes and proposed solutions for those
attacks. The RQs are given in Table 2 with their corresponding motivations.
Table 2. Research questions (RQs).

NO Research Question Main Motivation

RQ1 How has the frequency of research approaches been To identify the published studies in the SDN security area
changed over time in the field of SDN security? over time.
RQ2 What are the primary publication channels for identifying To identify the primary sources published in SDN security
security attacks and their solutions on SDN planes? and privacy issue-related studies.
RQ3 What research approaches have been used by researchers To identify the proposed research approaches related to SDN
to identify the security and privacy issues on SDN planes? security issues, security solutions, and attack causes.
RQ4 What are the major attacks targeting planes in SDNs To address the security attacks and proposed solutions for
addressed by the literature? SDN planes.
RQ5 What are the major types of attacks identified To identify the attacks/threats on SDN planes.
by researchers?
RQ6 What are the major causes of attacks addressed in the To identify the causes of attacks on SDN planes.
literature on SDN planes?
RQ7 What proposed solutions have been implemented to To identify the proposed solutions for security attacks on
address security attacks on SDN planes? SDN planes addressed in the literature.
4.2. Search Strings
The search was conducted by applying the search string to different databases. Another researcher
applied the search string via the Boolean operators “ANDs” and “ORs” as follows: (“Software
Defined Networks” OR “SDN”) AND (“SDN security” OR “SDN threats”) OR (“SDN Security
Solutions” OR “SDN Layers”).

4.3. Data Sources

The next phase was to search for the source references. In this phase, multiple search terms were
implemented, such as search keyword, search source, relevant papers selection, and filtering. The
main research was carried out by looking at the keywords, paper titles, and abstracts for each
paper or journal. There were four types of publication, namely journals, conferences,
symposiums, and reports. The digital search process was carried out by implementing the search
query in seven different databases. The chosen databases were:
IEEE Xplore (ieeexplore.ieee.org).
Science Direct (sciencedirect.com).
Springer (springerlink.com).
Hindawi (hindawi.com).
MDPI (mdpi.com).
Plos (plos.org).
Wiley (onlinelibrary.wiley.com).

5.Analysis
Regarding the objective of this research, the findings of SLR are explained in this section. After
the screening and selection processes, selected studies were used to identify the answers of each
research question. This analysis formulates a fundamental contribution to identifying the security
challenges in SDN along with their proposed solutions to make the network system more secure
in the future.

5.1. Results Selection

The state-of-the-art analysis of multiple security threats on SDN planes is a key challenge due to
their integration into multiple technologies, including cloud computing, IoT, big data, machine
learning, blockchain, etc. However, according to the defined RQs, we focused only on three SDN
planes (application plane, control plane, and data plane) and gathered 6 studies. The classification
results of the selected studies are shown in Table 3.
 Table 3. Classification of security challenges on SDN planes.

Attack
Causes

Solution
e
Referenc

P Year

Layers
Target
Research

Attack
Slow TCAM
A solution has been
exhaustion attacks
and saturation designed to slow down
[43] 2020 proposed solution application plane
attacks originate the DDoS attacks on the SDN
DDoS attacks. application plane

Attack detection in A robust self-protection

the application plane framework has been
[17] 2020 framework application plane is difficult due to proposed which mitigates
their stealthy nature DDoS attacks on the
and a potential application layer.
increase in DDoS
attacks

Malicious packets Investigated DDoS attack

overload the secure methods and developed a
[44] 2019 proposed method data plane channel, software Dos Defender to filter
control agent, and malicious packets.
controller to inject
DDoS.

Unsteadiness between A security design approach

security features and has been proposed to prevent
[40] 2016 proposed system data plane network performance the controller and network
generates DDoS attacks from attacks

An attack happens due SDN-Guard is a novel

to malicious traffic, scheme developed to protect
[39] 2016 proposed system control plane flow rules, and flow the network from DDoS
timeouts. attacks

The attack occurs Proposed SDN-Guard

due to weak system to detect and
[38] 2017 proposed system control plane authentication and mitigate the attacks
malicious flow rule. against SDN rootkits.

Proposed Method and System

Different methods and systems have been investigated to detect and mitigate security attacks on
SDN planes. As the decoupling of control and data plane provides centralized control,
programmability, and flexibility, on the other hand, there are also many vulnerabilities due to
communication conflicts between these planes. These vulnerabilities are leveraged due to the
saturation of the control plane and buffer overflow attacks, which are introduced via TCP SYN
flooding. To detect and mitigate the TCP SYN flooding attack, the SAFETY solution is
presented, which determines the flow data randomness [50]. Additionally, another
countermeasure, SLICOTS, also mitigates the TCP SYN flooding attack at the control plane by
taking the advantage of the SDN’s dynamic programmability nature [14].
4.1.5. Assessment of RQ5: What Are the Major Types of Attacks on SDN Planes Identified by
Researchers?
In this section, I discuss the security threats that threaten SDN architecture. Moreover, Table 3
presents the classification of major security attacks that affect the SDN planes, i.e., application
plane, control plane, and data plane. For more clarity on the taxonomy of attacks on SDN planes,
see Figure 7.
DDoS Attacks
DoS/DDoS is the most challenging attack for SDNs. These attacks are intentional attempts to
make network resources available to illegitimate users. In SDN architecture, the controller plays a
vital role to determine the overall functionalities of the SDN network; therefore, the controller has
become the central target for DoS/DDoS attacks. Some controllers that attract DoS/DDoS attacks
have been identified, such as flood light-based controllers [56,57]. Shin et al. [58] described a
DoS attack that exploits the separation logic of the control and data planes. Moreover, Fonseca et
al. [59] suggested a secondary controller to deal with this problem, but the secondary controller is
also vulnerable to these threats. Thus, multi-controller implementation is not a solution for DDoS
because it leads to the failure of all controllers if the single controller fails [60].
Flooding Attack
Whenever an unmatched flow arrives at the virtual switch, it will send a request to the centralized
controller to generate a forwarding rule for the new flow through the southbound interface.
Attackers will send multiple packets to the virtual switch with spoofed IPs and compel the virtual
switch to forward packet-in messages to the controller. The overflow of these fake flow requests
overloads the controller and makes it inaccessible to legitimate users [61].
Flow Rule Conflicts
When open flow sends a request to the controller for a new flow rule, in response, the controller
sends a new flow rule that is stored in the flow table of the switch. There is a time- out value for
every flow rule and after that specified time, the switch evicts the old rules from the flow table
[62]. Ternary content addressable memory has a very limited capacity to store flow table entries
due to its high cost and power consumption [63]. Attackers overcome the switch by taking the
advantage of this feature and sending fake flows to the switch. These fake flows cause the flow
table of the switch to run out of memory and store only fake rules, which erase the legitimate
entries and degrade the performance.
Cyber Attacks
SDN is one of the most exciting domains for cyber-attacks due to the programmability and
centralized nature of these networks. Therefore, cyber security has become a major challenge in
the SDN environment for ensuring the continuity of required service [53–55].
 IP Source Address Validation
Packet Inspection Approach
COPY
Dataset Method
STRIDE Threat Model
ArOMA Framework
Solutions For
Fingerprint Hoping Method
Application Plane U-TRI technique Technique
FS-OpenSecurity architecture
Payless framework
FRESCO
IDS
Flover system
OFRewind

SDN-GUARD

SLICOTS Solution
FloodGuard Framework
LineSwitch Solution
SDNShield Solution
Safe-GUard Solution
PackedChecker System
Solutions For
ArOMA Framework
Control Plane Bayes based protocol

U-TRI technique Technique

OverWatch
ASLB Architecture
FS-OpenSecurity architecture
Controller-to-controller protocol
McNettle
HyperFlow
• OFMTL-SEC
• SAFETY Solution
• PackedChecker System
• DosDefender
• STRIDE Threat Model
Solutions For • ArOMA Framework
• U-TRI technique Technique
Data Plane • FS-OpenSecurity architecture
• IEEE 802.1X port-based
• FortNox
• FlowChecker
• VeriFlow

Figure 7. Proposed solutions for SDN planes.

4.1.6. Assessment of RQ6: What Are the Major Causes of Attacks on SDN Planes Addressed in
the Literature?
Researchers and security experts believe that typical SDN security threats involved are controller
vulnerabilities, malicious applications, data leakage and modification, legality and consistency of
flow rules, scalability, and configuration issues. I analyze the identified security threats and attack
causes. The results of security analysis with respect to their affected SDN planes are shown in
Table 3. From classification Table 3, it can be noted that the attack challenges of different planes
are different.
4.1.7. Assessment of RQ7: What Proposed Solutions Have Been Implemented to Address
Security Attacks on SDN Planes?
SDNs provide a dynamic security rule to define the security policy, implement the defined policy
to network elements, and minimize the misconfiguration chances and policy conflicts. Due to the
nature of global network visibility, multiple security systems, such as intrusion
detection/prevention systems and firewalls, are implemented on specified traffic. In this section,
we discussed the security measures, platforms, architectures, and proposed solutions for the
application plane, control plane, and data plane. The identified security solutions from selected
studies are shown in Figure 7.

Security Solutions on the Application Plane

In SDN architecture, a controller acts as a middleman between applications and network

hardware, simplifying network complexity for applications. To secure communication devices in
technologies like IoT and SDN, post-quantum cryptographic (PQC) methods are recommended.
Post-quantum networking enhances communication network security, assesses existing protocols,
and improves performance through new designs. Payless is a cost-effective application-
monitoring framework for SDN, using an efficient algorithm for flow statistics collection.
FRESCO, an open-flow security application framework, allows modular composition of security
services to protect against evolving attacks. Intrusion detection systems and anomaly-based
intrusion architecture are proposed for malicious traffic detection. Cloud-based solutions and
systems like Flover check for DDoS attacks and ensure consistency with security policies.
Frameworks like ndb and OFRewind help debug and trace network anomalies. While these
approaches enhance security, there's limited effort in securing application data, distinguishing
between user and network applications, and defining access controls for nested applications in
SDNs [64-75].
Security Solutions on Control Plane
In SDN architecture, it's crucial to secure the control plane through which applications access
network resources. The SE floodlight controller, an extended version of the floodlight controller,
offers robust security by introducing a secure northbound API and an open flow verification
module. To handle the high load on controllers caused by numerous client connections, solutions
like McNettle with multiple CPU cores and parallelism through multi-core processors are
proposed. The DISCO solution facilitates communication between controllers in overlay
networks. HyperFlow, a distributed control platform, enables local decision-making, improving
control scalability. To mitigate DDoS attacks, Braga et al. propose a three-component system
involving a flow collector, feature extractor, and classifier.
However, the literature suggests that separating the control and data planes may not be practical
for implementing security services on a large scale, especially in cloud environments and data
centers. Large-scale networks with high-volume traffic may face performance bottlenecks when
forwarding all flows to the controller. Additionally, security applications like stateful firewalls
require historical network information to avoid communication overhead [76-82].

Security Solutions on Data Plane

In the data plane, we need to protect against harmful applications that might mess with the flow
rules. We use fine-grained mechanisms like authorization and authentication to safeguard data
from these applications. FortNox is a platform that uses NOX open flow controllers to check for
flow rule conflicts and authorize applications. It adds security constraints and role-based
authentication through digital signatures. Another tool, FlowChecker, spots inconsistencies in
open flow rules within a switch or data path elements. It works as a master controller or an open
flow application during runtime to analyze and validate configurations.

VeriFlow helps identify faulty rules injected by malicious apps, preventing anomalous network
behavior. The open flow protocol allows configuring a backup controller if the primary one fails,
ensuring better system performance and content availability. Shorter paths between controllers
and switches, as shown by Zhang et al., enhance system performance and security analysis. The
SPHINX framework detects known and unknown attacks on the data plane without assuming
trust in forwarding devices. It isolates network operations using flow graphs and predefined
security rules.

Proper segmentation and network planning improve switch resilience and controller connectivity
in the data plane. Studies explore how consistent connectivity between the controller and
OpenFlow switch can protect against saturation attacks. This not only boosts system performance
but also facilitates fast restoration and security analysis [83-86].
6. Discussion
After an extensive review, we identified multiple research gaps and suggested future research
directions by considering these research gaps.
6.1. Research Gaps
In order to secure SDN architecture, a number of security solutions have been proposed by
researchers to secure the networks, but there are still many security challenges in SDNs that need
to be addressed.
6.2. Future Directions
Although a number of security solutions have been proposed to make SDN architecture more
secure, but further extension of proposed solutions is possible. In this section, we recommended
the directions for future work.
After presenting a detailed discussion on threats to SDNs’ security in Section 4, we investigated
whether the security problem in SDN is a single-tier problem. Security threats exist on each layer
in SDN architecture; therefore, to perform research on each layer individually is far from enough.
Hence, a perspective system is needed to make the entire network robust and secure.
The frequency of DDoS attacks in SDN architecture is at the top of all other security challenges.
Therefore, it is highly recommended to develop a solution for DDoS attack detection and
mitigation to minimize the overall overheads of a centralized controller.
Transport layer security (TLS) alleviates multiple security threats with mutual verification on the
control switch. Therefore, TLS specification is mandatory between controllers and switches to
secure transmitted data and links. The integrity verification of software applications protects the
network from malicious software attacks. Additionally, for integrity verifications, unambiguous
malware detection approaches must also be developed. Moreover, malicious applications also
introduce significant security risks. Hence, third-party applications must be scanned to protect
the network from malicious code and other vulnerabilities. Thus, security solutions for third-party
applications are an ongoing challenging research area.

7. Conclusion
A systematic review has been presented by providing a comprehensive discussion based on
collected studies available in the field of SDN security and privacy issues. In this research, I
highlighted the security issues of the application plane, control plane, and data plane of SDNs and
presented a taxonomy of attacks. We also identified the causes of attacks on the basis of their
impacts. Thereafter, we summarized the existing security solutions for these planes that were
proposed by researchers. Based on the identified security issues and solutions, a collaborative
security model was proposed. Then, we presented some ongoing security challenges and gaps on
SDN planes. Lastly, we provided suggestions for future research that may be beneficial for
researchers to mitigate security attacks on SDN layers. Such an extensive systematic review will
surely help researchers and policymakers to provide more reliable and robust security solutions in
SDNs.
References
1. Raghavan, B.; Casado, M.; Koponen, T.; Ratnasamy, S.; Ghodsi, A.; Shenker, S. Software-
defined internet architecture: Decoupling architecture from infrastructure. In Proceedings of the
11th ACM Workshop on Hot Topics in Networks, Redmond, WA, USA, 29–30 October 2012;
pp. 43–48.
2. Jain, S.; Kumar, A.; Mandal, S.; Ong, J.; Poutievski, L.; Singh, A.; Venkata, S.; Wanderer, J.;
Zhou, J.; Zhu, M.; et al. B4: Experience with a globally-deployed software defined WAN. ACM
SIGCOMM Comput. Commun. Rev. 2013, 43, 3–14. [CrossRef]
3.Natarajan, S.; Ramaiah, A.; Mathen, M. A software defined cloud-gateway automation system
using OpenFlow. In Proceedings of the 2013 IEEE 2nd International Conference on Cloud
Networking (CloudNet), San Francisco, CA, USA, 11–13 November 2013; IEEE: Piscataway,
NJ, USA, 2013; pp. 219–226.
4.Patel, P.; Bansal, D.; Yuan, L.; Murthy, A.; Greenberg, A.; Maltz, D.A.; Kern, R.; Kumar, H.;
Zikos, M.; Wu, H.; et al. Ananta: Cloud scale load balancing. ACM SIGCOMM Comput.
Commun. Rev. 2013, 43, 207–218. [CrossRef]
5.Yungaicela-Naula, N.M.; Vargas-Rosales, C.; Pérez-Díaz, J.A.; Zareei, M. Towards security
automation in software defined networks. Comput. Commun. 2022, 183, 64–82. [CrossRef]
6. Jammal, M.; Singh, T.; Shami, A.; Asal, R.; Li, Y. Software defined networking: State of the
art and research challenges. Comput. Netw. 2014, 72, 74–98. [CrossRef]
7.Hong, S.; Xu, L.; Wang, H.; Gu, G. Poisoning network visibility in software-defined networks:
New attacks and countermeasures. In Proceedings of the NDSS, San Diego, CA, USA, 8–11
February 2015; Volume 15, pp. 8–11.
8.Kreutz, D.; Ramos, F.M.; Verissimo, P.E.; Rothenberg, C.E.; Azodolmolky, S.; Uhlig, S.
Software-Defined Networking: A Comprehensive Survey; IEEE: Piscataway, NJ, USA, 2014;
Volume 103, pp. 14–76
9.Lee, S.; Yoon, C.; Lee, C.; Shin, S.; Yegneswaran, V.; Porras, P.A. DELTA: A Security
Assessment Framework for Software-Defined Networks. In Proceedings of the NDSS, San
Diego, CA, USA, 26 February–1 March 2017.
10.Lee, S.; Kim, J.; Woo, S.; Yoon, C.; Scott-Hayward, S.; Yegneswaran, V.; Porras, P.; Shin, S.
A comprehensive security assessment framework for software-defined networks. Comput. Secur.
2020, 91, 101720. [CrossRef]
11.Voellmy, A.; Kim, H.; Feamster, N. Procera: A language for high-level reactive network
control. In Proceedings of the First Workshop on Hot Topics in Software Defined Networks,
Helsinki, Finland, 13 August 2012; pp. 43–48.
12.Dhamecha, K.; Trivedi, B. SDN Issues A Survey. 2013. Available online:
https://www.researchgate.net/publication/269667437_ SDN_Issues_A_Survey (accessed on 5
June 2023).
13.Kreutz, D.; Ramos, F.M.; Verissimo, P. Towards secure and dependable software-defined
networks. In Proceedings of the Second ACM SIGCOMM Workshop on Hot Topics in Software
Defined Networking, Hong Kong, China, 16 August 2013; pp. 55–60.
14.Deepa, V.; Sudar, K.M.; Deepalakshmi, P. Detection of DDoS attack on SDN control plane
using Hybrid Machine Learning Techniques. In Proceedings of the 2018 International Conference
on Smart Systems and Inventive Technology (ICSSIT), Tirunelveli, India, 13–14 December
2018; IEEE: Piscataway, NJ, USA, 2018; pp. 299–303.
15.Aladaileh, M.A.; Anbar, M.; Hasbullah, I.H.; Chong, Y.W.; Sanjalawe, Y.K. Detection
Techniques of Distributed Denial of Service Attacks on Software-Defined Networking
Controller—A Review. IEEE Access 2020, 8, 143985–143995. [CrossRef]
17.Benzaïd, C.; Boukhalfa, M.; Taleb, T. Robust Self-Protection Against Application-Layer
(D)DoS Attacks in SDN Environment. In Proceedings of the 2020 IEEE Wireless
Communications and Networking Conference (WCNC), Seoul, Korea, 25–28 May 2020; IEEE:
Piscataway, NJ, USA, 2020; pp. 1–6.
18.Priya, P.M.; Manjula, K.R. Cog-SDN: Mitigation Mechanism for Distributed Denial of
Service Attacks in Software Defined Networks. In Proceedings of the International Conference
on Applications and Techniques in Information Security, Tamil Nadu, India, 22–24 November
2019; Springer: Singapore, 2019; pp. 202–215.
19.Hameed, S.; Ahmed Khan, H. SDN based collaborative scheme for mitigation of DDoS
attacks. Future Internet 2018, 10, 23.
[CrossRef]
20.Novaes, M.P.; Carvalho, L.F.; Lloret, J.; Proença, M.L., Jr. Adversarial Deep Learning
approach detection and defense against DDoS attacks in SDN environments. Future Gener.
Comput. Syst. 2021, 125, 156–167. [CrossRef]
21.Schehlmann, L.; Abt, S.; Baier, H. Blessing or curse? Revisiting security aspects of Software-
Defined Networking. In Proceedings of the 10th International Conference on Network and
Service Management (CNSM) and Workshop, Rio de Janeiro, Brazil, 17–21 November 2014;
IEEE: Piscataway, NJ, USA, 2014; pp. 382–387.
22.Abdulkarem, H.S.; Dawod, A. DDoS Attack Detection and Mitigation at SDN Data Plane
Layer. In Proceedings of the 2020 2nd Global Power, Energy and Communication Conference
(GPECOM), Izmir, Turkey, 20–23 October 2020; IEEE: Piscataway, NJ, USA, 2020; pp. 322–
326.
23.Pradhan, A.; Mathew, R. Solutions to Vulnerabilities and Threats in Software Defined
Networking (SDN). Procedia Comput. Sci.
2020, 171, 2581–2589. [CrossRef]
24.Hu, T.; Guo, Z.; Yi, P.; Baker, T.; Lan, J. Multi-controller based software-defined networking:
A survey. IEEE Access 2018, 6, 15980–15996. [CrossRef]
25.Al-Shaer, E.; Al-Haj, S. FlowChecker: Configuration analysis and verification of federated
OpenFlow infrastructures. In Proceedings of the 3rd ACM Workshop on Assurable and Usable
Security Configuration, Chicago, IL, USA, 4 October 2010; pp. 37–44.
26.Nara, R.; Satoh, K.; Yanagisawa, M.; Ohtsuki, T.; Togawa, N. Scan-based side-channel attack
against RSA cryptosystems using scan signatures. IEICE Trans. Fundam. Electron. Commun.
Comput. Sci. 2010, 93, 2481–2489. [CrossRef]
27.Ristenpart, T.; Tromer, E.; Shacham, H.; Savage, S. Hey, you, get off of my cloud: Exploring
information leakage in third-party compute clouds. In Proceedings of the 16th ACM Conference
on Computer and Communications Security, Chicago, IL, USA, 9–13 November 2009; pp. 199–
212.
28.Xu, J.; Hong, H.; Lin, G.; Sun, Z. A New Inter-Domain Information Sharing Smart System
Based on ABSES in SDN. IEEE Access
2018, 6, 12790–12799. [CrossRef]
29.Canto, A.C.; Kaur, J.; Kermani, M.M.; Azarderakhsh, R. Algorithmic Security is Insufficient:
A Comprehensive Survey on Implementation Attacks Haunting Post-Quantum Security. arXiv
2023, arXiv:2305.13544.
30.Oktian, Y.E.; Lee, S.; Lee, H.; Lam, J. Secure your northbound SDN API. In Proceedings of
the 2015 Seventh International Conference on Ubiquitous and Future Networks, Sapporo, Japan,
7–10 July 2015; IEEE: Piscataway, NJ, USA, 2015; pp. 919–920.
31.Vasconcelos, C.R.; Gomes, R.C.; Costa, A.F.; da Silva, D.D. Enabling high-level network
programming: A northbound API for Software-Defined Networks. In Proceedings of the 2017
International Conference on Information Networking (ICOIN), Da Nang, Vietnam, 11–13
January 2017; pp. 662–667.
32.Feng, M.; Xu, Z.; Wang, C. SDN-based Satellite Networks and Southbound Interface Protocol
Extension. Radio Commun. Technol.
2017, 43, 19–23.
33.Hyun, S.; Kim, J.; Kim, H.; Jeong, J.; Hares, S.; Dunbar, L.; Farrel, A. Interface to network
security functions for cloud-based security services. IEEE Commun. Mag. 2018, 56, 171–178.
[CrossRef]
34.Giesen, F.; Kohlar, F.; Stebila, D. On the security of TLS renegotiation. In Proceedings of the
2013 ACM SIGSAC Conference on Computer & Communications Security, Berlin, Germany, 4–
8 November 2013; pp. 387–398.
35.Tschofenig, H.; Fossati, T. Transport layer security (tls)/datagram transport layer security
(dtls) profiles for the internet of things. In RFC 7925; Internet Engineering Task Force: Fremont,
CA, USA, 2016.
36.Scott-Hayward, S.; Natarajan, S.; Sezer, S. A survey of security in software defined networks.
IEEE Commun. Surv. Tutor. 2015, 18,623–654. [CrossRef]
37.Ahmad, I.; Namal, S.; Ylianttila, M.; Gurtov, A. Security in software defined networks: A
survey. IEEE Commun. Surv. Tutor. 2015,
17, 2317–2346. [CrossRef]
38. Tatang, D.; Quinkert, F.; Frank, J.; Röpke, C.; Holz, T. SDN-Guard: Protecting SDN
controllers against SDN rootkits. In Proceedings of the 2017 IEEE Conference on Network
Function Virtualization and Software Defined Networks (NFV-SDN), Berlin, Germany, 6–8
November 2017; IEEE: Piscataway, NJ, USA, 2017; pp. 297–302.
39. Dridi, L.; Zhani, M.F. SDN-Guard: DoS Attacks Mitigation in SDN Networks. In
Proceedings of the 2016 5th IEEE International Conference on Cloud Networking
(Cloudnet), Pisa, Italy, 3–5 October 2016; pp. 212–217
40. Hussein, A.; Elhajj, I.H.; Chehab, A.; Kayssi, A. SDN Security Plane: An Architecture for
Resilient Security Services. In Proceedings of the 2016 IEEE International Conference on Cloud
Engineering Workshop (IC2EW), Berlin, Germany, 4–8 April 2016; pp. 54–59.
41. Chen, K.Y.; Junuthula, A.R.; Siddhrau, I.K.; Xu, Y.; Chao, H.J. SDNShield: Towards
more comprehensive defense against DDoS attacks on SDN control plane. In Proceedings of
the 2016 IEEE Conference on Communications and Network Security (CNS), Philadelphia,
PA, USA, 17–19 October 2016; IEEE: Piscataway, NJ, USA, 2016; pp. 28–36.
43. Pascoal, T.A.; Fonseca, I.E.; Nigam, V. Slow denial-of-service attacks on software
defined networks. Comput. Netw. 2020, 173, 107223. [CrossRef]
44. Deng, S.; Gao, X.; Lu, Z.; Li, Z.; Gao, X. Dos vulnerabilities and mitigation strategies in
software-defined networks. J. Netw. Comput. Appl. 2019, 125, 209–219. [CrossRef]
46. Wu, X.; Liu, M.; Dou, W.; Yu, S. DDoS attacks on data plane of software-defined
network: Are they possible? Secur. Commun. Netw. 2016, 9, 5444–5459. [CrossRef]
53.Yu, Z.; Zhu, H.; Xiao, R.; Song, C.; Dong, J.; Li, H. Detection and defense against network
isolation attacks in software-defined networks. Trans. Emerg. Telecommun. Technol. 2020, 32,
e3895. [CrossRef]
54.Xie, R.; Cao, J.; Li, Q.; Sun, K.; Gu, G.; Xu, M.; Yang, Y. Disrupting the SDN Control
Channel via Shared Links: Attacks and Countermeasures. IEEE/ACM Trans. Netw. 2022, 30,
2158–2172. [CrossRef]
55.Calle, E.; Martínez, D.; Mycek, M.; Pióro, M. Resilient backup controller placement in
distributed SDN under critical targeted attacks. Int. J. Crit. Infrastruct. Prot. 2021, 33, 100422.
[CrossRef]
56.Ambrosin, M.; Conti, M.; De Gaspari, F.; Poovendran, R. Lineswitch: Efficiently managing
switch flow in software-defined networking while effectively tackling dos attacks. In Proceedings
of the 10th ACM Symposium on Information, Computer and Communications Security,
Singapore, 14 April–17 March 2015; pp. 639–644.
57.Dover, J.M. A Denial of Service Attack against the Open Floodlight SDN Controller; Dover
Networks LCC: Edgewater, MD, USA, 2013.
58.Shin, S.; Gu, G. Attacking software-defined networks: A first feasibility study. In Proceedings
of the Second ACM SIGCOMM Workshop on Hot Topics in Software Defined Networking,
Hong Kong, China, 16 August 2013; pp. 165–166.
59.Fonseca, P.; Bennesby, R.; Mota, E.; Passito, A. A replication component for resilient
OpenFlow-based networking. In Proceedings of the 2012 IEEE Network Operations and
Management Symposium, Maui, HI, USA, 16–20 April 2012; IEEE: Piscataway, NJ, USA, 2012;
pp. 933–939.
60.Yao, G.; Bi, J.; Guo, L. On the cascading failures of multi-controllers in software defined
networks. In Proceedings of the 2013 21st IEEE International Conference on Network Protocols
(ICNP), Goettingen, Germany, 7–10 October 2013; IEEE: Piscataway, NJ, USA, 2013; pp. 1–2.
61.Akhunzada, A.; Ahmed, E.; Gani, A.; Khan, M.K.; Imran, M.; Guizani, S. Securing software
defined networks: Taxonomy, requirements, and open issues. IEEE Commun. Mag. 2015, 53, 36–
44. [CrossRef]
62.Kandoi, R.; Antikainen, M. Denial-of-service attacks in OpenFlow SDN networks. In
Proceedings of the 2015 IFIP/IEEE International Symposium on Integrated Network
Management (IM), Ottawa, ON, Canada, 11–15 May 2015; IEEE: Piscataway, NJ, USA, 2015;
pp. 1322–1326.
63.David, E.S.; Taylor, D.; Turner, J. Packet classification using extended TCAMs. In
Proceedings of the 11th IEEE International Conference on Network Protocols, Atlanta, GA, USA,
4–7 November 2003.
64.Anastasova, M.; Azarderakhsh, R.; Kermani, M.M.; Beshaj, L. Time-Efficient Finite Field
Microarchitecture Design for Curve448 and Ed448 on Cortex-M4. In International Conference on
Information Security and Cryptology; Springer Nature: Cham, Switzerland, 2022; pp. 292–314.
65.Anastasova, M.; Azarderakhsh, R.; Kermani, M.M. Fast strategies for the implementation of
SIKE round 3 on ARM Cortex-M4.
IEEE Trans. Circuits Syst. I: Regul. Pap. 2021, 68, 4129–4141. [CrossRef]
66.Bisheh-Niasar, M.; Azarderakhsh, R.; Mozaffari-Kermani, M. Cryptographic accelerators for
digital signature based on Ed25519.
IEEE Trans. Very Large Scale Integr. (VLSI) Syst. 2021, 29, 1297–1305. [CrossRef]
67.Mozaffari-Kermani, M.; Azarderakhsh, R.; Aghaie, A. Reliable and error detection
architectures of Pomaranch for false-alarm- sensitive cryptographic applications. IEEE Trans.
Very Large Scale Integr. (VLSI) Syst. 2015, 23, 2804–2812. [CrossRef]
68.Mozaffari-Kermani, M.; Reyhani-Masoleh, A. Reliable hardware architectures for the third-
round SHA-3 finalist Grostl bench- marked on FPGA platform. In Proceedings of the 2011 IEEE
International Symposium on Defect and Fault Tolerance in VLSI and Nanotechnology Systems,
Vancouver, BC, Canada, 3–5 October 2011; IEEE: Piscataway, NJ, USA, 2011; pp. 325–331.
69.Aghaie, A.; Kermani, M.M.; Azarderakhsh, R. Fault diagnosis schemes for low-energy block
cipher Midori benchmarked on FPGA. IEEE Trans. Very Large Scale Integr. (VLSI) Syst. 2016,
25, 1528–1536. [CrossRef]
70.Sanal, P.; Karagoz, E.; Seo, H.; Azarderakhsh, R.; Mozaffari-Kermani, M. Kyber on
ARM64: Compact implementations of Kyber on 64-bit ARM Cortex-A processors. In
Proceedings of the Security and Privacy in Communication Networks: 17th EAI International
Conference, SecureComm 2021, Virtual, 6–9 September 2021; Springer International Publishing:
Cham, Switzerland, 2021; pp. 424–440.
71.Shin, S.W.; Porras, P.; Yegneswara, V.; Fong, M.; Gu, G.; Tyson, M. Fresco: Modular
composable security services for software- defined networks. In Proceedings of the 20th Annual
Network & Distributed System Security Symposium, San Diego, CA, USA, 27 February–3
March 2023.
72.Seeber, S.; Stiemert, L.; Rodosek, G.D. Towards an SDN-enabled IDS environment. In
Proceedings of the 2015 IEEE Conference on Communications and Network Security (CNS),
Florence, Italy, 28–30 September 2015; IEEE: Piscataway, NJ, USA, 2015; pp. 751–752.
73.Nygren, A.; Pfaff, B.; Lantz, B.; Heller, B.; Barker, C.; Beckmann, C.; Cohn, D.; Malek, D.;
Talayco, D.; Erickson, D. Openflow Switch Specification; Version 1.5. 1.; Technical Report;
Open Networking Foundation: Palo Alto, CA, USA, 2015.
74.Akila, J.; Vetripriya, M.; Brigetta, A.; Magesh Kumar, K. Dynamic network security
protection on cloud computing. Int. Educ. Res. J. (IERJ) 2016, 2.
75.Brooks, M.; Yang, B. A Man-in-the-Middle attack against OpenDayLight SDN controller. In
Proceedings of the 4th Annual ACM Conference on Research in Information Technology,
Chicago, IL, USA, 30 September–3 October 2015; pp. 45–49.
76.Scott-Hayward, S.; O’Callaghan, G.; Sezer, S. SDN security: A survey. In 2013 IEEE SDN for
Future Networks and Services (SDN4FNS); IEEE: Piscataway, NJ, USA, 2013.
77.Switch, B. Developing Floodlight Modules. Floodlight OpenFlow Controller. 2012. Available
online: https://scholar.google. com.hk/scholar?hl=zh-
CN&as_sdt=0%2C5&q=Switch%2C+B.+Developing+floodlight+modules.+Floodlight+OpenFlo
w+
controller%2C%E2%80%9D+2012.&btnG=#d=gs_cit&t=1689313192518&u=%2Fscholar%3Fq
%3Dinfo%3AnBUnnVPlp5YJ%
3Ascholar.google.com%2F%26output%3Dcite%26scirp%3D0%26hl%3Dzh-CN (accessed on 13
July 2023).
78.Voellmy, A.; Wang, J. Scalable software defined network controllers. In Proceedings of the
ACM SIGCOMM 2012 Conference on Applications, Technologies, Architectures, and Protocols
for Computer Communication, Helsinki, Finland, 13–17 August 2012; pp. 289–290.
79.Cai, Z.; Cox, A.L.; Maestro, T.E.N. Maestro: A System for Scalable OpenFlow Control;
Technical Report TR10-08; Rice University:
Houston, TX, USA, 2010.
80.Phemius, K.; Bouet, M.; Leguay, J. Disco: Distributed multi-domain sdn controllers. In
Proceedings of the 2014 IEEE Network Operations and Management Symposium (NOMS),
Krakow, Poland, 5–9 May 2014; IEEE: Piscataway, NJ, USA, 2014; pp. 1–4.
81.Tootoonchian, A.; Ganjali, Y. Hyperflow: A distributed control plane for openflow. In
Proceedings of the 2010 Internet Network Management Conference on Research on Enterprise
Networking, San Jose, CA, USA, 27 April 2010; Volume 3.
82.Braga, R.; Mota, E.; Passito, A. Lightweight DDoS flooding attack detection using
NOX/OpenFlow. In Proceedings of the IEEE Local Computer Network Conference, Denver, CO,
USA, 10–14 October 2010; IEEE: Piscataway, NJ, USA, 2010; pp. 408–415.
83.Kohonen, T. The Self-Organizing Map; IEEE: Piscataway, NJ, USA, 1990; Volume 78, pp.
1464–1480.
84.Porras, P.; Shin, S.; Yegneswaran, V.; Fong, M.; Tyson, M.; Gu, G. A security enforcement
kernel for OpenFlow networks. In Proceedings of the First Workshop on Hot Topics in Software
Defined Networks, Helsinki, Finland, 13 August 2012; pp. 121–126.
85.Khurshid, A.; Zou, X.; Zhou, W.; Caesar, M.; Godfrey, P.B. Veriflow: Verifying network-
wide invariants in real time. In Proceedings of the First Workshop on Hot Topics in Software
Defined Networks, Helsinki, Finland, 13 August 2012; pp. 15–27.
86.Zhang, Y.; Beheshti, N.; Tatipamula, M. On resilience of split-architecture networks. In
Proceedings of the 2011 IEEE Global Telecommunications Conference—GLOBECOM 2011,
Houston, TX, USA, 5–9 December 2011; IEEE: Piscataway, NJ, USA, 2011; pp. 1–6.