SDN Security Review: Threat Taxonomy, Implications, and Open Challenges

Software-Defined networking (SDN) is a networking paradigm to enable dynamic, flexible, and programmatically efficient configuration of networks to revolutionize network control and management via separation of the control plane and data plane. The SDN technology has evolved in response to the demands from large data centers toward all types of networks, from IoT, enterprise, to ISP networks. On the one hand, SDN has provided solutions for high-demand resources, managing unpredictable data traffic patterns, and rapid network reconfiguration. It is further used to enhance network virtualization and security. On the other hand, SDN is still subject to many traditional network security threats. It also introduces new security vulnerabilities, primarily due to its logically centralized control plane infrastructure and functions. In this paper, we conduct a comprehensive survey on the core functionality of SDN from the perspective of secure communication infrastructure at different scales. A specific focus is put forward to address the challenges in securing SDN-based communications, with efforts taken up to address them. We further categorize the appropriate solutions for specific threats at each layer of SDN infrastructures. Lastly, security implications and future research trends are highlighted to provide insights for future research.


I. INTRODUCTION
The Software-Defined Networking (SDN) infrastructure primarily aims to make networks programmable, thereby supporting them with higher flexibility and agility in terms of configuration, monitoring, and performance [1]. Before the evolution of SDN, data centers possessed challenges in coping with unpredictable data traffic patterns. Those data traffic patterns cause higher demands for resources that could not be met with conventional network infrastructures. The data center management experts had two choices: i) Scale up the network infrastructure, which is very expensive, and the majority of the networks are underutilized most of the The associate editor coordinating the review of this manuscript and approving it for publication was Sedat Akleylek . time. ii) The Build a reconfigurable network that could automatically cope with the demands of the users and allocate computing resources to meet their appropriate demands. This is where the SDNs come to their rescue as a powerful tool for customizing the networks on the fly. In addition to providing various security supports, as shown in Figure 1, SDN enhances networking control functions for routing and policy definitions in an automated way.
SDN provides a new level of programmability and abstraction to a network layer, which plays a leading role in automating the network. SDN ensures network reachability at a faster rate by addressing the challenges in IP allocation, routing changes, bandwidth allocation, and policy openings. SDN allows system administrators to manage and control their network dynamically. Further, SDN infrastructures are highly correlated with Network Function Virtualization (NFV), enabling the building of virtual platforms [2]. They help to virtualize networking functions by allowing specialized hardware to be replaced with software applications that could run on universal devices. Efficient management of Internet of Things (IoT) security threats with the aid of SDN and NFV are reviewed by Farris et al. [3] for enhancing and addressing the cybersecurity challenges in IoT systems. Security issues in the control plane of SDN are addressed by comparisons with the conventional network models [4]. The authors also developed effective consistency checks and incorporated fault tolerance in their proposed SDN security architecture for the control plane. Another potential research prospect of SDN security is meeting its Quality of Service (QoS) requirements and dealing with heterogeneous networks [5], [6]. Authors in [7] developed a framework for transforming the SDN controllers into homogeneous groups and enhanced their security concerns by maintaining the robust security features in the SDN. Encryption schemes are developed for addressing the trade-off between the link security and communication performance [8]. Its effectiveness and validity are tested on SDN/OpenFlow platform in the security gateways.
The widespread adoption of SDNs is also prone to challenges in providing authentication, data privacy, and access control in networking routing. Sallam et al. [9] proposed a Software-Defined Perimeter (SDP) framework for restricting unauthorized access to the network as well as establishing an orchestration of network connections. Such integration of SDP with SDN enables handling bandwidth attacks through proper Denial of Service (DoS) and it could also be examined through virtual network testbeds. Integration of SDN and blockchain for handling cyberattacks in Industrial IoT (IIoT) devices are proposed by authors in [10]. They focused on developing a security architecture comprising intrusion detection system and integrity checking strategies using blockchain, thereby avoiding tampering of SDN-based IIoT systems. Authors in [11] exploited the capabilities of SDN with trusted agents for detection and denial of Rogue Access Points (RAPs) by utilizing hidden subnets, a network emulator, and a modular programming platform.
As an extension of the popular INET framework, Tiloca et al. [12] simulated SDN-based anomaly detection. They have also evaluated the performance of the architecture for managing the cyber-physical attacks in SDN and performed design optimization based on the analysis. IoT devices are most prone to attacks, and attackers easily target such devices unless they are secured and access by unauthorized hackers is restricted. Matheu et al. [13] developed the Manufacturer Usage Description (MUD) model for security policy enforcement with the aid of SDN techniques. This technique helps to protect the devices shared through blockchain-based platforms.
Abdou et al. [14] have made a comparative security analysis of control plane security in SDN and other conventional networks. Their analysis strategy supports fault tolerance and checks on consistency issues as well as the potential of applying robust security features in SDN systems. Zhong et al. [15] addressed load balancing and failure recovery approaches in SDN using a smart cooperative platform. While this secure communication mechanism is enforced using the cooperative platform and distributed controllers, the effectiveness of the authentication code plays a significant role. Distributed denial of service (DDoS) is one of the common issues that may occur in networks that lack robust security features. Prior research has examined its impact to a larger extent. Furthermore, the impacts of DDoS with its security implications in SDN frameworks are highlighted by the authors in [16] along with the recent research trends.
Furthermore, security becomes more critical in the underlying SDN infrastructure and the rapid increase in the number of smart devices connected to the SDN networks has not only increased the data traffic in the network, but also raised concerns on security aspects of SDN communications. For instance, SDN has been used as a backbone framework to effectively address and protect the information and communication infrastructure in ships, reported as CyberShip-IoT in [17]. The authors used a translation mechanism and higher-level policy language of higher level for evaluating the security metrics. Here, the performance is validated on different use cases. SDN-based vehicular networks are gaining momentum as key enablers with the support of 5G services to establish Intelligent Transportation Systems (ITS). The security issues in such vehicular networks are addressed at all the layers of the SDN, providing effective transmission of data packets through the data plane [18]. Moreover, countermeasures to the security attack on SDN-based vehicular networks are well addressed in [19]. Routing protocols addressing the security issues in SDN-based vehicular networks are dealt with in [20], in which the latency and secure connections are analysed. Vehicles communicating with each other in ITS can be attacked by unauthorized vehicles in the network. So, vehicular ad hoc networks are integrated with SDN-based solutions for ensuring reliable vehicle-to-vehicle (V2V) VOLUME 10, 2022 communication [21]. Here, through a single remote controller, the load on the network is controlled, and attacks on the vehicles are almost nullified. Therefore, in this paper, we survey the core functionality of SDN from the perspective of secure communication infrastructure at different scales. A specific focus is put forward to address the challenges involved in securing SDN environments, with efforts taken up to address them. Building upon this, the appropriate solutions for specific threats at each layer of SDN infrastructure are reviewed along with their research and practical implications.

A. CONTRIBUTION OF THIS SURVEY AND COMPARISON WITH RELATED PAPERS
The objective of this paper is to provide a comprehensive view of the state-of-the-art security issues, security implications, and security enhancement practices in SDN communications.
Contributions of this survey include highlighting the roles of the entities involved in SDN communication security, while integrating their corresponding application domains. This survey also discusses recent research efforts to solve, key security-related challenges in SDN communication and open-end research directions for future work. Table 1 shows comparisons between our paper and existing ones in the literature. Specifically, our paper contributes to the existing literature by adding an up-to-date review of security challenges in SDN infrastructure, discussion of current practices towards security enhancements per SDN plane, induction of research and practical implications of the reviewed security aspects. Although there are several variants of SDN technologies and protocols, in this paper, we mainly focus on OpenFlow, the most dominant SDN-enabled communications protocol. A summary of the contributions of this survey is enlisted as follows: 45822 VOLUME 10, 2022 TABLE 1. Comparison of existing survey papers about SDN environment security. , , and ,indicate that the topic is well covered, uncovered, and partially covered, respectively.
• A discussion on the SDN architectural layers and their operations and functionalities.
• Motivations (with SDN use cases) towards awareness of the security attacks and vulnerabilities that affect the SDN infrastructure and communication.
• Review on the recently evolved SDN-enabled applications with security enhancements in emerging areas as use cases (e.g., Internet of Things, LTE and 5G communications, Blockchain technology, time sensitive networks, software defined WAN, etc.) • An up-to-date review on the security challenges and threats in SDN infrastructure.
• Review of existing solutions and practices towards enhancing security in SDN infrastructures. The solutions are reviewed in accordance with SDN planes with a categorization of threat detection and mitigation techniques.
• Induction of research and practical implications by the reviewed security aspects.
• Discussion of the future research directions and open challenges hindering resiliency and security in SDNenabled systems. Different from existing papers, this paper provides an up-to-date discussion about security issues in SDN environments. The presented taxonomy covers security threats ranging from topology discovery, network and app manipulation, flow diversion, teleportation & rootkits, controller placement, access control and authorization, to conventional networking threats. Further, in addition to reviewing existing security solutions and related implications, this paper provides key use cases of SDN technology implementation in smart communication systems. This layout is aimed to enable researchers to focus on the challenges that breach security in SDN communications. Ultimately, this work will provide further insights for future research in the SDN security domain.

B. PAPER STRUCTURE
The rest of the paper structure is shown in Figure 2 and organized as follows. Section II provides a background of the SDN that is enabled by other supporting technologies that drive its implementation and integration towards end applications. Section III discusses the security attacks and vulnerabilities that do exist in the underlying SDN infrastructure and communication. Section IV further covers security challenges hindering security enhancement in SDN infrastructure. Section IV also reviews and classifies existing SDN-enabled solutions and implementations to thwart the different security threats in the underlying planes of SDN. Detection and mitigation techniques are also reviewed in Section IV. In Section V, learned lessons are induced in accordance with the presented review in this paper. Moreover, this Section V projects the research and practical implications of SDN security along with future research directions and open challenges in this area. Last, Section VI concludes the survey.

II. SDN BACKGROUND, IMPLEMENTATIONS, AND APPLICATIONS
In this section, we introduce the key features of SDN and discuss the related literature in detail. The main aspects of integrating SDN into use cases highlighted here include smart cities as one of the key technologies. SDN is an evolving paradigm of networking technology aiming at superseding the limitations of conventional (i.e., legacy) networks [1]. The primary worth of SDN lies in its capability to provide and assure coherent policy enforcement, network programmability, enhanced scalability, and holistic visibility via VOLUME 10, 2022 centralized management. Table 2 summarizes the existing SDN controller software and their specifications. SDN infrastructural components are depicted in Figure 3 and their detailed descriptions are discussed next.

A. ARCHITECTURAL LAYERS
In this section, we characterize the architectural layers of SDN in terms of their roles and key functionalities that could be tweaked for a diversified range of use cases.

1) APPLICATION PLANE
The application plane handles the services and applications request network functions from the data and the control planes. In the standard network configurations, the monitoring and the control of devices occur in this layer [59]. Although the devices' functions are similar to the SDN networks, the delivery modes are often virtualized, centralized, and abstracted. Furthermore, the attributes, services, and rules are also defined in this layer, where network information about the device's topology and the appliances is needed to implement a broad range of end-to-end SDN-enabled services efficiently. Additionally, applications, through this layer, can make timely decisions depending on the network changes [60]. Overall, the scope of the application layer includes security enforcement and largely considers the access policies while providing load balancing, traffic engineering, network management, and monitoring [31], [40].

2) CONTROL PLANE
Unlike the traditional network architecture with integrated control and data planes, SDN enables a decoupled architecture to feature a distinct control plane that defines network management/control and traffic routing. The control plane is a layer dedicated to managing, monitoring, and configuring forwarding processes (e.g., flow forwarding decision) across the network stack [59]. The separation of control from the data plane in SDN enhances agility in the automation, monitoring, management, maintenance, extension, provision, and troubleshooting of network infrastructure [40]. Based upon a centralized control, the controller, via the control plane, sends necessary and appropriate information to the forwarding devices (e.g., OpenFlow switch) as flow rules for effective decision-making. This is achieved through explicit forwarding information base (FIB) and MAC programming [31], [40], [61].

3) DATA PLANE
SDN addresses the limitation of the network architecture by instituting flexibility in scaling and supporting dynamic computing environments as speed and efficiency decline with an increase in forwarding devices and connected devices in conventional networks. The SDN data plane executes programmable algorithms (controlled by the control plane) that coordinate and enhance management processes and device configurations. As a result, networks were capable of efficiently accommodating the dynamics of changing configurations without constraining the efficiency [62]. The data plane entails numerous network constituents that allow uninterrupted connectivity. This plane oversees the transfer of data flows between end hosts [31], [38].
The data plane also fosters network integration and interoperability across all traffic engineering (TE) processes, including device management and configuration [41]. In this context, the architecture provides neutrality for optimizing infrastructure investments to foster commercial and nominal requirements. Data plane provides standard protocols for instituting a typical software environment, where devices from different vendors can communicate. Moreover, it manages open and modular dimensions by standardizing network applications, systems, and policies [38]. Open network management or orchestration simplifies deployment, creating a highly scalable network with enhanced performance optimization capability.

B. REPRESENTATIVE SDN SOLUTIONS 1) OpenFlow
OpenFlow is an open interface protocol for remotely controlling the forwarding tables in the network switches, routers, and access points. By setting up the virtual machines tools and providing the hubs as Ethernet switches, the Open-Flow helps modify the network flows and enables multiple switch support. Further, it enables the switch to handle IP forwarding, run the switch on a real network as well as add firewall capabilities to the switch [63]. According to OpenFlow protocol specifications, security aspects need to be incorporated over the SDN control layer, and the SDN controller must grant a network view that is unified and clear to render security threats and violations, which are easy to spot as well as ensure security policies installment [64]. Further, the OpenFlow protocol are also bpound to few limitations, including the disallowance to choose specific functions (when not all functions are needed), and a new OpenFlow version typically requires hardware with rich functionalities [65].

2) SEGMENT ROUTING (SR)
SR is a data plane technology that provides a control solution for the SDN flow path. SR is simpler and more scalable than conventional SDN protocols such as OpenFlow. Security in SDN can be well-comprehended with SR. It chooses an optimized path and encodes it in the packet's header, and transmits as an ordered sequence of segments. The segment holds identification for instructions such as context, locator, and services. These services can be leveraged through multiprotocol label switching (MPLS) in conjunction with the Internet protocol for listing the segments in the routing extension header [66].
Further protocols and solutions for traffic engineering and management that can be integrated into SDN technology are summarized as follows: • Path Computation Element (PCE): PCE is a controller that computes the network's paths. By applying  • Abstraction & Control of Transport Networks (ACTN): They are involved in creating abstract topology for each application or based on the demand from each user. This multi-domain network topology is responsible for addressing a diversified range of customers through its physical network control that can be implemented with the services offered by PCE [69]. Such frameworks enable logical application overlays and abstraction in the management of network traffic with optimized control plane disaggregation and simplify the SDN controller's operations.
• Interface to Routing System (I2RS): I2RS agents in the network router are capable of coordinating with the topology, events, policies, I2RS clients, as well as routing and signaling protocols [70]. The data encoding mechanisms implemented in the I2RS agents aim to provide secure use cases, predominantly applied for traffic steering, traffic classification, DDoS mitigation, topology control, and service chaining. It offers a unified interfacing solution to the routing system in order to achieve better monitoring and routes for data transmission in SDN networks.

3) PROGRAMMING PROTOCOL-INDEPENDENT PACKET PROCESSORS (P4)
P4, being one of the domain-specific programming languages, specifies the process of forwarding the packets by the data plane. SDN control protocols like OpenFlow could be operated in conjugation with the P4 for imparting reconfigurability, make the switches operate independently of the vendor, and enable programmers to describe the processing functionality independent of the target and underlying hardware [71]. At present, the capabilities of P4 could also be leveraged to program end-to-end multi-layer information in IP-enabled optical networks for provisioning flexible multilayer in-band network telemetry [72].

4) APPLICATION DRIVEN SDN
• Application Layer Traffic Optimization (ALTO): ALTO protocol provides abstract and useful network information and ensures efficient network usage with better traffic optimization. It is developed on top of existing REST APIs [73]. Moreover, its service-aware parameters are highly useful for real-time communication, live media streaming, and peer-to-peer (P2P) file sharing. Indeed, the ALTO could also be integrated with PCE for establishing data center interconnect, which ensures joint optimization of resources. Further, through a metaheuristic clustering mechanism with coordination of ALTO [74], they could be helpful in the implementation of dynamic frameworks for the detection of DDoS in the SDN services.
• REST API: For establishing communication with the network switches, REST API (aka RESTful API) is one of the popular choices over OpenFlow. The controller applications with the REST modules supports towards the insertion of flow entries and flow tables in the SDN switches. REST design approaches assists in addressing the challenges normally encountered in the northbound API of SDN. The truly RESTful approach makes the SDN a pure service-oriented data networking platform. Further, in an SDN-enabled cloud environment, REST API access control mechanisms are sensitive to pave the way towards the provision of secure application management in the prescribed framework [75].

C. SDN APPLICATIONS
To realize the benefits of SDN in different applications, efficient implementation of technologies such as IoT, wireless communication, blockchain, etc., are key requirements. This section outlines the core concepts under the aforementioned supporting services for SDN integrated smart applications.

1) DATA CENTERS
In an enterprise, by placing computing power closer to the sources of data, such as routers, WAN, and IoT devices, the use of edge computing makes the data travel less distance compared to a distance cloud infrastructure. Edge computing eases the strain on resources by processing data close to the source and only sending valuable data to the cloud services. Computing terminals demanding reduced response time, conserving network bandwidths, and reduced data bottlenecks could be reasonably addressed using edge computing. However, as it's a distributed architecture, they are prone to security challenges and opens up for possible attacks. Reasonable trade-offs in choosing cloud or edge computing with the support of SDN frameworks could address the security threats on such computing. In [76], improved Quality of Experience (QoE) is guaranteed with the support of SDN that provides dynamic configuration and mobile edge orchestration of the network with enhanced services and the security aspects imparted through network intelligence. Data security and privacy issues in a pervasive edge computing paradigm can be addressed through SDN-enabled blockchain services, which could provide secure deviceto-device communication with flexible operations [77]. The work by Li et al. [78] demonstrated the means of addressing the security issues in IoT-enabled healthcare systems using a secured framework implemented using SDN-based edge computing services. Here, the simulations highlight the load balancing and network optimizations authenticated through the edge servers connected to the SDN controllers. Recently, SDN-based mobile edge computing was proposed in [79], where the authors focused on dynamic service migration and joint edge caching through deep Q-learning. This approach considerably reduces the transmission cost and several other service migrations.
In most healthcare and industrial networks, real-time critical communication is highly relevant for forwarding vital data for processing. At present, however, the devices are becoming more intelligent and transmitting not only real-time capable data, but also other data for predictive maintenance and energy optimization. Time-Sensitive Networking (TSN) ensures delivery of real-time relevant data in the network, even despite increased data load. They can be used to control data communication in the form of time synchronization and prioritization of data streams. This ensures that an application neither interferes with the other communication nor is disturbed by them. For time-sensitive industrial IoT applications, the authors in [80] proposed an SDN architecture based on online strategies. It ensures optimized routing, scheduling, and admission control along with the guaranteed allocation of secure transmission time-slots.
Further, the work in [81] focuses on failure handling for time-Sensitive networks using SDN and source routing, which are evaluated by integrating into Mininet using Linux-based TSN scheduling. In another recent work by Kong et al. [82], failure analysis of time-triggered traffic and its run time recovery is demonstrated in time-sensitive networks. IHSF [83] was proposed as an intelligent solution for providing reliable and time-sensitive flows in hybrid SDN-based IoT systems, which ensures improved performance and secured means of data communication. Also, it provides a better end-to-end delay in terms of optimized network observability time, with an excellent packet delivery ratio. In [84], SDN-based self-configuration strategies for time-sensitive IoT networks are developed for different numbers of end-hosts and network sizes. Such strategies provide guaranteed and secured means of real-time data transfer without prior knowledge of the flow rates.

2) SOFTWARE DEFINED WIDE AREA NETWORK (SD-WAN)
The ultimate objective of Wide Area Network (WAN) is to connect users to their applications from anywhere across the globe anytime, and from any device with the appropriate interface. In most cases, it adds up delay that degrades application performance, and it consumes costly leased line bandwidth. More intelligent ways of reaching the application through the Internet are driven by the software-defined model for the WAN. Instead of routing traffic solely based on addresses, an SD-WAN is an application-aware access mechanism that uses software to more intelligently route or steer traffic across the WAN based on the business requirement for an application in a secure manner. The SD-WAN has revolutionized WAN services through application-driven networking to meet the demands of customers and services. Usually, this makes a close connection to the security and cloud computing for easy management of the resource regardless of the connectivity provider [85]. IoTSim-SDWAN [86] was developed as a simulation framework for interconnecting distributed data centers over SD-WAN for dynamic computation of the best and secure route for the network flow. Further, this work proposes a coordination scheme to link the SDN controllers and the SD-WAN.
Further, energy and network performance issues were evaluated using the IoTSim-SDWAN simulator and compared with the classical WAN services. The authors in [87] evaluated the dynamic traffic management for SD-WAN intercloud communication. It minimizes the internal linkages, ensures secure communication, and reduces traffic costs by operating in a distributed manner. Further, SD-WAN has found its application in healthcare services as one of the recent works reported in [88]. Here, with SD-WAN as a backbone network, the healthcare systems are evaluated in terms of latency, jitters, communication bandwidth, security, privacy, and trust in the systems to ensure their reliable services.

3) WIRELESS COMMUNICATIONS: LTE AND 5G
The role of SDN in LTE and 5G makes the network more agile and flexible by carefully designing, managing the networks, and programming the control plane. SDN further provides an intelligent architecture for LTE and 5G networks. It also plays a crucial role in creating multiple network hierarchies and intelligent frameworks for LTE and 5G network programmability. For integrating the SDN with the LTE and 5G services, the forwarding device with embedded control will be linked with the firewall and the traditional network with distributed cloud services for establishing secured means of communication. An SDN controller driven through the software control establishes the communication link between forwarding devices and decoupled network control. The authors in [89] demonstrated the performance of aggregated LTE and WiFi with open-source frameworks by testing them on UDP and TCP services, considering three types of policies for securing the communication in the network. Further, in [90], the authors used blockchain for building secure and trustworthy IoT services in SDN-enabled 5G vehicular ad-hoc networks (VANETs).

4) SMART CITY a: INTERNET OF THINGS (IoT)
Some predominant communication and security issues in IoT can be addressed with the support of SDN technology, thereby assisting in making efficient IoT services. Integrating SDN with IoT enables the deployment of intelligent routing decisions for IoT communications [91]. It also simplifies the information collection mechanisms and helps to make better analysis and decision making [92]. Further, the network management services can be simplified based on the IoT device, user specifications, application-specific requirements, and enhanced visibility of network resources are guaranteed using SDN technology. While the IoT devices communicate with VOLUME 10, 2022 other devices or cloud services, the SDN delivers intelligent traffic pattern analysis and coordinated decision-making.

b: SMART GRIDS AND POWER GRIDS
The ever-changing and rising energy demands for household and industrial appliances require the implications of smart power grids. They can introduce a two-way dialogue to exchange electricity and information between the customers and the utility service providers. Smart grids have evolved as a developing network of communications, control, and automation with the support of new technologies like SDN, working together to make the grids more efficient, reliable, and more secure [93]. These smart grids assists in the integration of renewable energy sources such as solar and wind and are also capable of plug-in electric vehicle charging. A security framework for SDN-enabled smart power grids is developed by the authors in [94], to provide a robust and secure smart grid architecture. It is experimented on multiple SDN controllers with lightweight identity-based cryptography to protect smart grid networks from external attacks. The authors in [95] introduced the best features of SDN for supervisory control and data acquisition (SCADA) networks deployed in smart grid applications. Here, the resiliencyaware SDN, plans and executes the best alternate paths during network congestion and addresses the threat issues in the network. Recently, Mahmood et al. [96] demonstrated the effectiveness of an SDN-based DDoS protection system for smart grids by employing a lightweight defense mechanism. Further, the performance measures such as detection rate, resource utilization, DDoS protection focusing on various attacks are evaluated.

c: CONNECTED AND AUTONOMOUS VEHICLES (CAVs)
Through connected services and protocols, autonomous vehicles can talk to each other and transform the current transportation by enabling safe and interoperable networked wireless communications among them. Connected vehicles provide drivers with 360-degree awareness of the environment and keep personal information private. The drivers will receive warnings and will be informed about potential hazards through a visual display, seat vibration, or tones. The role of SDN in such use cases is supported through the SDN controllers to provision better resource management and resource allocation for the autonomous vehicles [97]. Here, multi-access edge computing along with SDN enhances resource utilization and resource management. MobQoS [98] is the mobility aware and QoS-driven SDN framework for autonomous vehicles, which incorporates distributed mobility management and provides improved routing decisions in the network. Further, this approach facilitates mobility-aware SDN frameworks for autonomous vehicles addressing the QoS challenges. In [99], the authors proposed an energy-efficient SDN controller placement strategy for SDN-based connected autonomous vehicles. Here, an efficient composite architecture is used to manage the underlying SDN communications by deploying multiple controllers.

d: ROBOTICS AND SMART MANUFACTURING
Robots used for smart manufacturing tasks are designed to carry out specific repetitive processes with minimum human intervention and high degree of precision. Robots were employed to save labor, enhance productivity, and avoid human error that may cost millions in smart manufacturing. Further, autonomous guided vehicles are also getting increasingly popular in industrial automation tasks. Establishing communication among the machines/robots and collaborating on their tasks are centralized challenges faced by industrialists and researchers. In [100], the authors proposed a dedicated communication channel using SDN controlled visible light communication to collaborate the tasks among multiple autonomous guided vehicles in a secure way. This approach considerably reduces the communication overhead and handovers, and the SDN paradigm makes communication much more secure for collaborative tasks among robots. SMOTE [101] is employed as an SDN-based multi-objective traffic engineering approach for performing telesurgery with the aid of robots. It was deployed to provide secure remote access to surgeons with better QoE. In [102], the authors used mobile edge cloud-based industrial IoT to improve the edge intelligence with the support of hierarchical SDN controllers. The authors proposed distributed and centralized control schemes to enhance the security aspects of smart industries' with improved edge intelligence.

e: BLOCKCHAIN TECHNOLOGY
As SDN communication is evolving from proprietary hardware to virtual software to ensure effective management of security in the networks, developers have started depending on the advances of blockchain technology. A blockchainbased security framework is developed by the authors in [90] to provide a secure and trustworthy IoT infrastructure in SDN-enabled 5G vehicular ad-hoc networks. Here, the blockchain-enabled scheduling procedures arrest the entry of malicious nodes that could be largely used in a vehicular IoT environment providing secure and trustworthy communication through the incorporated SDN architecture. Further, in another work by Derhab et al. [10], a blockchain-based integrity checking system is incorporated into the backbone of SDN-enabled industrial IoT systems. This system defends industrial IoT devices against cyber-attacks and provides an effective security solution. As energy-efficient SDN controller are of primary importance in large scale deployment, their security aspects in delivering enhanced services could be efficiently addressed through blockchain services [103]. Here, an efficient authentication method is incorporated through distributed trust services, ensuring lower energy consumption with lower delay and improved throughput in the routing protocol.
In the edge cloud infrastructure for IoT services, the incorporation of a blockchain-enabled security framework is addressed in [104]. In this framework, the dynamic network traffic flow management, which means a root cause for the security attacks, is recognized through the hindering doubtful flows. Further, data confidentiality issues are carefully addressed through the integration of blockchain in the SDN and the edge cloud services. SmartBlock-SDN [105] is developed as an optimized blockchain-based SDN framework for resource management in the IoT ecosystem. Here, a layered hierarchical architecture is presented, including a blockchainenabled SDN-IoT framework providing an efficient selection of cluster-head and ensuring secure communication in the SDN network via the isolation of rouge switches through proper identification. The blockchain technology can further be leveraged to enforce tamper resistance and integrity of SDN data such as log files for forensics purposes [106].
Further, substantial hardware differences, communication standards disparity, and vendor-based software specifications restrain the successful attainment of Information and Communication Technologies (ICTs) and its services. Fortunately, the virtualization and softwarization progress in the transportation and network layers, in particular, can resolve some of such challenges. Some of the key softwarization technologies include SDN, NFV, and cloud computing [107], [108]. These softwarization enabling technologies are leveraged to integrate smart devices into SDN infrastructure and simplify information management in the underlying communication network [109]. Furthermore, NFV and SDN can jointly enable various data management services, including all the L2-L7 services and applications [110]. While several research studies focused on traffic engineering enhancement and service provisioning in SDN using NFV features [111], [112], NFV and SDN can also be leveraged to implement location-aware network virtualization and reconfiguration for the LTE networks [113].

III. SECURITY THREATS AND VULNERABILITIES
This section highlights the security threats and vulnerabilities in the emerging SDN technology, aiming to provide secure manipulation of the network, topology, flow rules, and access mechanisms. The security attacks and their implications are discussed and analyzed for each SDN layers.

A. CONTROL PLANE 1) HOST LOCATION HIJACKING
Resources allotted for the controller, particularly in the data to control plane, are prone to host location hijacking attacks. The attacker involved in this task typically slows down the network by consuming the resources allotted for the controller or even making the network inaccessible for the end-user. In SDN architecture, the intelligence of the whole network state and resources management reposes behind the centralized controller that could be a single point of failure in some cases, making it feasible to bring the entire networking system down from the adversaries' point of view by saturating the SDN control plane. This basically could establish a DDoS/DoS threat on the SDN data layer by utilizing host location hijacking attacks [116] as depicted in Figure 4. Furthermore, in the current implementations of different SDN controllers, there are few security restrictions on host location updates. Therefore, adversaries may easily impersonate any network identity with its index of host profile (MAC address) as shown in Table 3.
In each layer of SDN, the possible threats due to topology discovery are highlighted by the authors in [117]. Further, with the centralized and decentralized SDN controller setup, the robustness of the learning model against location hijacking attacks is assessed [116]. Here, it is assessed to mitigate the attacks with less resource overhead. With the programmable capability and adaptability in the control plane of SDN, it is capable of mitigating most of the vulnerabilities in the SDN topology [118]. Multi-layered intrusion detection and protection strategies are developed by the authors in [119] to mitigate IP Spoofing, control plane saturation as well as location hijacking issues in SDN. Microgrids connected to the SDN network are prone to cyber-attacks based on their topology. Active synchronous detection methods developed by Li et al. [120] help safeguard the network of microgrids.

2) LINK FABRICATION
An attacker in SDN involved in introducing a new malicious link over the network to gain control over the traffic is known as link fabrication attack (LFA). Due to the scalability concerns of SDN and the complexity of the network, the determination of the origin of LFA is highly challenging. The authors in [121] performed a statistical analysis on link latencies by undergoing a vetting period. Also, in comparison with the baseline models, relay-based LFA are assessed. Based on the assessment, the results concluded that relying on userspace increases the latency with fewer samples than the kernel space. For the examination of LFA in SDN, Khan et al. [122] proposed a formal strategy with a case VOLUME 10, 2022 study. Here, the SDN that utilizes Higher-Order Logic (HOL) is considered along with the entire system liability, dependencies, host vulnerabilities, and service information. This helps to analyze the performance metrics in the attack. A secure and efficient OpenFlow topology discovery protocol [123] requires minimum changes in the design of switches and eliminates vulnerabilities to a larger extent in the process of topology discovery. During the evaluation process, the Floodlight controller considerably reduces the topology discovery time compared to the original OpenFlow topology discovery protocol. It provides improved performance with reduced discovery time by several orders of magnitude.
Further, Huang et al. [124] developed a lightweight topology verification scheme for establishing efficient SDN topology discovery with a higher level of trustworthiness. Here, the security threat model for SDN controller link and host location verification strategies are carried out. Also, the implemented TrustTopo in the SDN controller (Floodlight) helps to secure the network against topology attacks.

3) PORT AMNESIA
Defense strategies on the topology attack are gaining popularity in SDN networks. Port amnesia-based attacks bypass the port labels, impersonating the hosts and becoming actively involved as a drop in network flow rates. The authors in [125] developed an effective defense against port amnesia with the extension to TopoGuard. This mechanism helps the SDN to be more resilient against such attacks. Further, with the accurate view of the SDN states, the classification of poisoning attacks is addressed in [126]. Also, more emphasis was given to their impacts than other attacks and port amnesia attacks' bypassing nature.

4) PORT PROBING
Port probing is also one of the prominent attacks on the SDN topology, in which the attacker sidesteps the mechanisms used in the guards. Moreover, it baffles the host location by making the host of the victim move to a new network location, leading to host hijacking attacks. In conjugation with the amnesia attacks, the authors in [126] also emphasized the impact of port probing in SDN frameworks. Moving Target Defense (MTD) introduced in [127] helps to prevent the SDN from inside and outside attacks. Here, the MTD mechanism helps to positively reduce the poisoning attacks by integrating MTD with the SDN environment by utilizing the virtual IP addresses of the hosts.

5) PERSONA HIJACKING
In the SDN network stack, the bindings of the layers are prone to attacks leading to Persona Hijacking. Such an adversarial attack fools the SDN infrastructure by trusting the attacker as the owner, significantly driving access to the network resources. Persona hijacking exploits the weakness in the identifier binding mechanisms of SDN and involves the IP takeover phase and flow poisoning phase in the network. With the experiments carried out using the OpenDaylight cluster, the impact of the Persona hijacking is evaluated [128]. In this hijacking, the attacker tends to increase the CPU consumption on the nodes in the cluster, causing inconsistency for a period when the events are flooded.
The Persona hijacking also leads to Worm-Hole Attack in the SDN, which triggers flow misleading in the network [129]. Its impact on packet loss rate and transmission delay is significantly increased by a reasonable range. Also, appropriate countermeasures for overcoming the hindrance due to Persona hijacking are elaborated in a wireless sensor networking scenario. In another work by authors in [130], by using source address validation and stateful packet supervision, the DoS attacks leading to Persona hijacking a lightweight, deployable SDN defense framework known as FloodShield was designed. It provides an effective shield against such attacks with less resource consumption in data and control planes.

6) REVERSE LOOP
The controller's view of the SDN network is highly exploited with the reverse loop attacks in the network. The controller can infer whether a reverse link exists considering the dynamic characteristics of the network. Within the stipulated time interval, the existing inter-switch links are removed in these attacks by reversing the links. Nisar et al. [35] summarised the impact of reverse loop attacks in SDN with their issues and challenges. With the analysis of six different vulnerabilities, the exploitation of the reverse loop introduces attacks during topology discovery mechanisms in SDN [131].

7) TOPOLOGY FREEZING
This kind of attack also affects the controller's perspective visualization of the network. It exploits the weakness of the topology services providing modules in the controllers. This kind of attack freezes the topology view of the controller and resists it from updating the dynamic changes in the network. A more detailed analysis on the impact of topology freezing is summarised in [35]. During the practical countermeasures applied to the SDN topology discovery, the impact of topology freezing resists updates of the network changes [131]. Furthermore, in another study, the vulnerabilities exposed on the control plane of SDN and its data dependencies are explored [132].

8) NETWORK MANIPULATION
Typically, network manipulation attacks against SDN occur in the control plane. In the network manipulation attack, the adversary introduces fake data in the network by compromising the controller and trying to introduce other attacks to the whole network [133]. Ubale and Jain [134] summarized the impact of DDoS attacks in SDN driven through the process of fake data injection in the network. Such exploitation of fake data predominantly affects the quality of decisions made by the models deployed for SDN-native big data applications [135]. In the work reported by Sallam et al. [9], the authors presented a Software-Defined Perimeter (SDP) framework and examined the impact of network manipulation attacks through virtualized network testbeds. The testing results of this framework have proven the framework to provide a flexible shield against DoS bandwidth and port scanning attacks with the established orchestration of connections. Xiao et al. [136] reported data dependency creation and chaining attacks due to the network manipulation in SDN. Here, using the SVHunter tool, the vulnerabilities of the attacks are effectively identified. Moreover, it could also report remote network exploitation through arbitrary commands, exfiltration, and crashing of SDN services.

9) TRAFFIC SNIFFING
Traffic sniffing in SDN permits the attacker to eavesdrop on the data in the network and snoop on vital information by capturing and analyzing the communication interface. In the case of consistent traffic scenarios of the network, they are likely to be exploited if the traffic sniffing attack is successful [9]. In an SDN environment, an attacker can exploit data that are not encrypted to block traffic from and to the controller. Using robust encryption schemes and strong passwords could suppress the impact of traffic sniffing in SDN [137].

10) MAN-IN-THE-MIDDLE (MITM) ATTACKS
Benton et al. [138] and Brooks et al. [139] present the way MITM attacks can be very severe in OpenFlow environments compared to the legacy networking environment because of the lack of authentication enforcement over the plaintext OpenFlow TCP control layer. In an SDN environment, the adversary can potentially take advantage of downstream OVS (Open vSwitch) switching devices to establish advanced eavesdropping attacks, as shown in Figure 5.
Furthermore, a fraudulent inter-link injection might trouble and impact the Shortest Path Selection (SPS) service process. An attacker has the ability to establish LLDP relay-based channels to mislead an SDN device with the illusion of a non-existing link (i.e., internal link) that connects the potentially targeted OpenFlow switching device [140]. Once the SDN device observes a link-up, it will immediately search for the shortest path utilizing compromised and infectious networking topology information. Thus, all the networking traffic crossing the fake computed path will go to the attacker's trap.
B. DATA PLANE 1) FRAUDULENT FLOW RULES SDN controller is responsible for a typical flow rules-driven networking environment. Therefore, it must instruct and command the entire networking traffic behaviors, including the configuration of OpenFlow switching devices with flow rules, to provide consistent and valid flow rules. For this reason, the SDN controller imposes valid, secure, and dynamic mechanisms to better authenticate all flow rules between the application layer and control layer of SDN [141]. Figure 6 depicts an attack scenario where the adversary deploys an application on server B to inject/insert a flow rule in the SDN device, which then permits the OVS device to directly forward the adversary traffic to Host C. Therefore, the security application in the SDN controller is bypassed and thus rendered worthless.

2) FLOODING ATTACKS
The rate of DDoS and DoS attacks occurrence in environments of SDN-based communication systems has tremendously risen because of the on-demand self-service and various accesses to network services [142], [143]. When a network packet mismatches the flow rules of OpenFlow, it is still transmitted to the SDN controller by the OpenFlow switch as depicted by Figure 7. Regardless of decoupling data from the control plane, protocol rules are still insecure. They enable adversaries to tamper with data plane forwarding and network topology that are critical and sensitive to the appropriate operation of SDN environments. Particularly, malignant devices can form and send a fake packet to be relayed VOLUME 10, 2022 by an SDN switch as a genuine data packet (i.e., packet-in) and forward it to the SDN controller, launch a DoS/DDoS attack on the SDN controller and SDN switches, or even elicit useful information of flow rules based on side-channel mechanisms.
Furthermore, to block the broadcast storm and economize energy, the SDN controller fits Spanning Tree Service (STS). Once an update in the topology takes place, STS prevents redundant ports. Anywise, this ability could be leveraged by an attacker to trigger a DoS raid. Also, an attacker can disable the OpenFlow switch ports by grouting fake links into SDN topology. Thus, DoS/DDoS is one of the most harmful and menacing attacks on the SDN controller, as Shin et al. [144] have demonstrated through a proposed scanning tool. The developed tool is capable of characterizing DoS/DDoS threats based on the response time of network flows.
• SYN flooding attacks: On the one hand, since an SDN controller permits for routing of the network flows via a centralized firewall in order to protect and secure the SDN data layer, this type of operation may lead to exhausting the resources of the OpenFlow switching devices (through fraudulent flow rules) as handling the communication traffic between the SDN controller and OVS devices may take significantly a long time [145].
On the other hand, installing (i.e., insert/push) flow rules by an SDN controller may be challenging with regard to traffic flow inspection, authorization, and authentication throughout security software and implementations.
• TCP-based flooding attacks: These typical attacks can be established by transmitting a large amount of TCP-based traffic with only the SYN flags set, which leads to clogging the network bandwidth. Additionally, the fact that OpenFlow switching devices need to buffer traffic flows while the SDN controller is issuing the flow rules renders the SDN data plane vulnerable to TCP-based saturation attacks. The OVS possesses constrained resources to buffer stop the unsolicited TCP and UDP-based traffic.

3) TRAFFIC DIVERSION
In the data plane of the SDN framework, the network elements are prone to traffic diversion issues that can be introduced by adversaries. It leads to eavesdropping by exploiting the network elements and redirecting the network traffic flow. A Dynamic Traffic Diversion (DTD) [146] algorithm was utilized to test traffic diversion issues in network emulation using Mininet and Cisco equipment. It was observed from the experimental results of test cases that the dynamic diversion of traffic helps to prevent the jitters and reduces the packet losses in the network. Further, the authors in [147] proposed a support vector machine (SVM)-based Internet traffic identification and classification mechanism that could be effectively employed for identifying the application traffic in the network. Here, the experimentation is carried out on social media traffic, and the classification accuracy of application traffic in different social media platforms was presented and analyzed.

4) ARP SPOOFING ATTACK
Address Resolution Protocols (ARP) are meant for identifying the MAC address associated with the IP address. ARP spoofing attacks take advantage of this process and enable the attacker to transmit fake ARP messages to the LAN in an attempt to associate their MAC address with the IP address of different hosts [148]. This attack is also limited to local network segments, and it can facilitate MITM attacks. In this process, two SDN hosts think they are communicating with each other, but they pass through a third party network module [149]. The authors in [150] proposed three different strategies for the detection of ARP spoofing attacks. This includes signature-based, ML-based, and Wireshark-based packet analysis techniques. Further, an accuracy analysis was elaborated based on the strategies for detecting ARP spoofing attacks, better protection against spoofing was observed.

5) SIDE CHANNEL ATTACKS
The weaknesses associated with cryptographic algorithms that lack strong mathematical aspects can be exploited by side channel attacks during their implementation. Moreover, these kinds of attacks are mostly non-invasive and passive (i.e., they will not leave any traces of the attack). They normally use the leaked signals from side channels during the normal operations of the channels for revealing the data in SDN. Side channel attacks typically make use of the delay encountered in the network to guess the network configurations. Introduction of time our proxies could reduce the response time for countering the side channel attacks [151]. Also, dynamic adjustments of workloads in the control plane are required to cope with such attacks. Authors in [152] developed an elliptic curve Diffie-Hellman (ECDH) based key exchange mechanism and incorporated strong countermeasures to thwart the effects of side channel attacks. It was experimented on low footprint embedded devices using FourQ, which ensures providing rich arithmetic operations and a secure implementation for the low power devices.

C. APPLICATION PLANE 1) APP MANIPULATION
In the application plane of SDN, the applications are prone to App manipulation attacks. In these attacks, the attacker may gain access to an SDN application, cause malfunction, eavesdrop on the data involved, and disrupt the services. Also, the attacker could gain higher privileges to perform illegal operations on the SDN applications.

2) API EXPLOITATION
Application Programming Interface (API) of specific software components linked with SDN systems are prone to be exploited by attackers, leading to unapproved exposure of vital data. This ends up with API exploitation, which may lead to the destruction of the flow of information in the network. Proper updates on the patches of applications running on SDN nodes are mandatory to avoid such exploitation.

3) PASSWORD GUESSING AND BRUTE FORCE
Through a brute force attack, the hackers attempt to find the user credentials by trying out various possible credentials through all possible combinations and permutations of passwords and usernames. This attack guesses the password through the trial and error method.

4) AUTHENTICATION AND AUTHORIZATION
Kreutz et al. [153] introduced vulnerability vectors in the SDN environment. It is demonstrated that the SDN controller does not impose any compulsory enforcement for instituting a trusted relationship among applications (i.e., SDN applications, networking service applications, security applications, etc.) and the SDN controller. As a result, malignant user applications could establish severe damage to the entire SDN-enabled environment as the SDN controller allows for layers abstraction, which is explicitly interpreted into configuration commands of the SDN infrastructure by different applications.
Furthermore, the credentials of users in a particular application could be compromised if an application server containing the specifics of these users is compromised. These compromised credentials might lead adversaries to insert counterfeit traffic that is regarded as authorized into the network. To defend against such threats, a centralized security method needs to be installed in SDN. However, there is no such mechanism developed yet. In OpenFlow specifications, the SDN applications make use of a broad range of features, characteristics, and networking services provided by the SDN controller. These SDN applications could be implemented by any third party rather than the SDN controller vendors only. Therefore, the access privileges and authentication mechanisms should be imposed in such a programmable SDN environment as described in [154]. However, it is very challenging to accomplish so due to the remarkable growth of SDN and security applications.

5) ACCESS CONTROL AND ACCOUNTABILITY
As an SDN controller allows for implementing/installing a broad range of applications to better utilize the network and SDN services, these applications are granted quietly powerful access authorities, rendering the entire SDN environment insecure [155]. For this reason, constrained access control and authority enforcement mechanisms need to be imposed on the implemented applications in order to guarantee the security of the networking environment. To better comprehend the security vulnerabilities associated with authority and access control of SDN applications, Figure 8 depicts some security weaknesses in the application plane of the SDN controller. The applications impacting the SDN environment security are classified into three main categories based on [155]: • Applications that are networking-sensitive, demanding specific network advantages/features (e.g., cost of the path.) • Applications that deliver network servings (e.g., IDS/ IDPS services, packet/flow content inspection, etc.) • Tinned applications that integrate/merge other applications from categories one and two (i.e., giant applications that require instantiating a particular virtual component in the networking environment.) Threatening security applications can lead to network traffic skipping authority and access control imposed by the SDN via the use of one or multiple of the aforementioned category application. Thus, a compromised SDN application might establish a gateway for illegitimate and unauthorized applications to access the control layer of SDN.

6) UNAUTHORIZED ACCESS AND SCALABILITY THREATS
As the SDN creators aimed to attain nimbleness and scalability from the network management perspective, SDN components gradually utilize an elastic cloud infrastructure and a flexible allocation of resources. However, the SDN and networking applications built in the control layer could cause dangerous vulnerabilities to this layer [155]. Furthermore, the authentication and authorization capabilities are a remarkable challenge in SDN environments due to the weaknesses posed by the controller when it comes to separating varied security applications of various implementations' implications: • Different applications have different functional requirements from the underlying SDN, and data paths should qualify for various security requirements. (1) Applications may need network statistics (e.g., bytes or packets counter information) from the switching device to proceed with load balancing processing [156]. (2) IDS/IDPS implementations could require an inspection of packet header information.
• The need to authenticate and authorize third parties which may apply an auditing operation for each implemented application. • Authenticating and authorizing resources deployed by various applications with an appropriate tracking and isolation.
• Network providers and networking operators need to possess a variety of higher-level privileges in order to gain access to networking resources. Typical user applications need to acquire a partial role in the network configurations and management [157]. Therefore, these applications need to be appropriately inspected prior to granting end-users privileged access to resources in the network. Based on the challenges mentioned above in the control layer with regard to control applications, a careful and customized enforcement of security policies is needed in different sorts and levels of implemented applications (i.e., could be achieved via SDN northbound API). However, this has not been expounded and addressed yet.
Moreover, from the perspective of controller availability, when the amount of traffic flows considerably increases in a networking environment managed by only one SDN controller, the overall processing time may become significantly impacted, leading to a typical point of failure. Yao et al. [158] have also tested multi-domain SDN controllers and multi-SDN controllers in a single domain and proven this typical point of failure is feasible. Furthermore, scalability in SDN controller renders DDoS/DoS attacks even more feasible because an SDN controller in a high-speed environment can quickly get a bottleneck while inserting rules of network flows into OpenFlow switching devices through the data-path [159]. This scalability challenge might plausibly lead to control layer saturation threats [160].

D. CROSS-LAYER ATTACKS 1) CrossPath ATTACK
The control channels of the SDN are prone to CrossPath attacks, in which the attacker exploits the shared paths among the data and control signal traffic. The attacker may introduce hand-crafted data for imparting disruption in the control traffic, particularly among the shared links of the network. However, the attack is highly sneaky, and the controller could not easily perceive them, as the data traffic is not effectively combined with the control channel signals. Cao et al. [161] experimented using an SDN testbed to study the impact of the CrossPath attacks on network applications. Its impact primarily leads to network-wide DoS, routing blackhole, and flow table resetting. These anomalies significantly degrade the performance of the network applications. In another work by authors in [136], a novel tool named SVHunter is developed to evaluate the unexpected data chaining and data dependency created due to the Crosspath attacks. A Fast recovery Saturation attack Detection and Mitigation framework (FSDM) [162] enables a novel functional module to help the network to recover from the attacks much more quickly.

2) TELEPORTATION ATTACKS
As discussed earlier, the decoupling of the control-data plane in SDN grants a reliable programmable network. However, such a promising paradigm enables various teleportation vulnerabilities (switch and host-based attacks) in SDN environments [163]. These vulnerabilities are summarized as follows.
• Network functions bypassing and policy conflicts evading: Exploitation of teleportation to avoid middleboxes that enforce security checks, billing, or QoS policies.
• Rendezvous and malicious switch discovery: Malignant or Trojan switching devices such as OpenFlow switches that hold a hardware/software backdoor can exploit teleportation as a rendezvous protocol to identify each other and coordinate a security attack.
• Exfiltration: Exploitation of teleportation to exfiltrate critical data within networks without data layer connectivity.

3) ROOTKITS THREATS
The application-controller interaction is one of the advantages that the SDN architecture offers to ensure the network operability [164] in the context of reliability and networking automation. However, recent studies [164]- [166] have demonstrated that existing solutions for security and policy enforcement in SDN control lack efficient security properties. Particularly, SDN rootkits can permit adversaries to control an entire SDN-enabled environment by compromising one or multiple controllers [164]. This is feasible due to the lack of network policies enforcement for application implementations to detect and prevent malignant network programming attempts [166].

4) CONTROLLER PLACEMENT THREATS
In an SDN environment, a controller is in charge of enforcing security policies. Thus, incompatible or inappropriate configurations of multiple controllers in both single-domain and multi-domain environments may cause internal conflicts (e.g., there is no guarantee that all deployed SDN controllers will obtain information about network state and resources once a network change or update takes place [167]. Moreover, when more than one SDN controller is deployed in a networking environment, this splits the entire networked system among the multiple controllers, consequently creating sub networking domains. Therefore, preserving and attaining security policies and applications in each individual SDN domain could be challenging or even infeasible. Table 4 gives a classification of key security attacks in SDN infrastructure. The attacks are classified per SDN plane. The worth of SDN lies in its capability to guarantee coherent policy enforcement and better scalability due to its centralized management and network programmability [31], [168]. The future generation of security solutions will benefit from the richness of network usage information available in SDN to enhance security policies enforcement, network anomaly revelation, and attenuation [8].

E. LESSONS LEARNED
For simplicity reasons, in our paper, we discuss security threats associated with each of the three SDN layers, control layer, application layer, and infrastructure layer, separately. However, as SDN technology is widely and gradually growing, the catalog of security vulnerabilities is anticipated to evolve in the near future vastly. Based on Figure 9, a summary of security threats and challenges related to the three planes of SDN is presented as follows.

1) CONTROL LAYER
• Unauthorized controller access: No compelling mechanisms for enforcing access control on applications.
• Availability and scalability: Centralizing intelligence in one entity will most likely have scalability and availability challenges.
• DoS/DDoS attack: Visible nature, centralized intelligence, and limited resources of the control plane are the main reasons for attracting DoS/DDoS attacks.
• Distributed control layer: When multiple SDNs are deployed into control a tremendous number of devices (i.e., through splitting the network to various subdomains), the ingathering of information and aggregation of flow rules within each sub-domain is a challenge.

2) INFRASTRUCTURE LAYER
• TCP-based attack: Transport Layer Security (TLS) is susceptible to TCP-level attacks.
• Flood-based attack: Flow tables of OpenFlow switching devices could hoard/save a fixed or limited amount of flow rules.
• Fake traffic/flow rules: Data plane is dumb and therefore more susceptible to fraudulent flow rules.
• Hijack of the controller: The infrastructure layer in SDN is solely dependent on the control plane, making its reliability dependent on controller security [169].
• MITM attack: Due to optional use of TLS and complexity of configuration in TLS.

3) APPLICATION LAYER
• Accountability and access control vulnerabilities: It is challenging to carry out accountability and access control policies on third-party applications and nested applications that consume network resources.
• Authentication vulnerabilities: No compelling authentication and authorization mechanisms for applications and more threatening in case of a large number of thirdparty applications.
• Fake insertion of traffic/flow rules: Malignant or compromised applications could create false flow rules, and it is troublesome and challenging to verify whether a particular application is compromised.

IV. SECURITY FRAMEWORKS AND IMPLEMENTATIONS
In this section, we first overview the security frameworks behind developing SDN solutions and address the challenges associated with their implementations. Then, we introduce the security enhancement strategies at each layer of SDN.
In particular, we discuss how to impart robust security features with the aid of other supporting technologies. In SDN architecture, the control layer is logically detached from the data plane to elaborate decisions in a decentralized manner due to a holistic view of the global network environment. Moreover, the centralized architecture of the SDN controller grants a reactive control and analysis of security and alteration of security policies [170], and therefore facilitates efficacious alteration of security policies to implement/insert security policies and drive them into the network entities and components. This minimizes the risk of improper policies configurations and policy conflicts over the SDN environment.
Despite the fact that SDN architecture preserves a grand promise to flexibly facilitate network management and deployment about lowering the overall cost of network management, numerous security challenges need to be addressed. This section presents and discusses common security measures, existing research proposal advances, and solutions dedicated to resolving the security challenges in the control, applications, and data layers of SDN.

A. CONTROL PLANE SECURITY ENHANCEMENT
The control layer is in charge of granting unified and consistent management of the OpenFlow-enabled forwarding devices and higher-level applications that carry out networking features-based service calls (e.g., link discovery service, entry tables, etc.). Therefore, the SDN control layer needs to be secure against the following key threats: • DDoS/DoS threats • Mal-replacement of SDN controller, which threatens the availability • Anomalous applications • The fudging activities that threaten the scalability of the control layer As the SDN controller grants applications access to different networking inputs and resources via its control layer, it becomes of a great substantiality to protect the control layer from potential anomalous applications and enforce controlled access to the SDN-enabled applications. Table 5 shows existing solutions (e.g., proposals, platforms, and frameworks) proposed to address security threats and challenges in the SDN control layer.
SDx [171] provides a Floodlight-based SDN controller [42] extension. The designed framework [171] is a security-enhanced (SE) version of the control layer in Floodlight controller [42] that offers various methods for prerogative decoupling through a flexibly programmable northbound interface. Additionally, the mechanism allows the SDN controller to behave as a medium between SDN applications and the SDN infrastructure layer using checking techniques for legitimizing the class module responsible for managing networking flows. According to OpenFlow specifications, the SDN controller must insert various flow rules for all customer entities' connections. As a result, this causes a bushy load in the SDN due to the massive amount of flow rules that the controller needs to install in the switching devices. For this reason, several proposals and mechanisms were presented to reduce the SDN load and/or divide it between the control layer elements and functionalities.
In [172], Fernandez presented comparisons between pro-active and re-active models of SDN scalability. While a pro-active SDN installs the networking flow rules before the traffic arrival in the Open vSwitch (OVS) using specific predefined transmission rules, a re-active SDN first extradites the packet and then inserts the flow rule in the OVS for this particular packet. Fernandez [172] also showed that the re-active SDN is significantly less scalable in contrast to the pro-active one. Because the pro-active SDN must be informed about all networking flows beforehand, which is infeasible, Fernandez [172] proposed a hybrid SDN that behaves interactively to set the paths while comprehending the flow conduct to determine the route beforehand proactively.
In [48], Tootoonchian et al. proposed HyperFlow, as an event-based distributed but logically centralized controller framework. The proposed platform warrants network administrators to increase the SDN scalability while decreasing the time needed to configure networking flows. In [175], Heller et al. proposed SDN placement in a way that lowers the flows latency through the use of a load-balancing approach to distributing the load on multiple SDNs. However, the proposed approach stipulates a trade-off between the state allocation and SDN elements availability. In [173] and [174], a physically distributed SDN control layer named DISCO is introduced to transit the operations of the SDN control layer in distributed and overlay networks. The proposed framework can be configured on top of Floodlight [42] SDN controller and deploys AMPQ [190] specifications.
Furthermore, there have been several proposals in the past addressing the SDN processing power and engaging the charge split between multiple SDNs, such as [191], which is an extended version of SDN with multiple CPUs designated to boost control algorithms at-scale. The presented framework demands a holistic view of networking state alteration VOLUME 10, 2022 incurring at the incoming traffic rate. Additionally, the framework is much more scalable than its counterpart NOX and it could be extended through high-level programming and scripting languages.
Besides, the DoS/DDoS threats could be practically alleviated through the network conduct dissection or traffic statistics saved in OVS devices. Although the network behavior characteristics are facilely purported and extracted from OVS switching devices, fetching them might be costly because of the low overhead support in these OpenFlow switching devices. In [178], Braga et al. proposed a lightweight mechanism to detect DDoS threats based on self-organizing maps (SOM) [192] to identify the concealed associations and connections between network flows crossing the environment. A Self-Organizing Map is a neural network for an n-dimensional pattern of data transformation into one or two-based dimensional maps. Here, the procedure of data transformation provides a gathering of data patterns that has identical statistical behavior for additional processing.
As load-balancing is another vital method to mitigate DDoS attacks, Belyaev et al. [193] proposed an approach to mitigate DDoS threats by considering the load-balancing problem in the SDN controller. In [178], the proposed technique for DDoS attacks capture employs three main components; classifier, which classifies the data extracted by other components according to the corresponding flow (malicious or benign flow) using SOM [192], feature extractor that collects statistics and characteristics that are vital for DDoS occurrence, and the flow collector module that collects traffic entries from the OVS flow tables. The collected characteristics include, but are not limited to, the average time interval and the number of packets per incoming flow.
SPHINX, which is presented in [194], aims to detect attacks that contravene the learning-based flow modules by designing a network flow graphs-based prototype. TopoGuard [140] is an extension to the security side on SDN controllers, which captures attacks that attempt to poison SDN environments (i.e., holistic visibility of network environment/topology) based on security omission's fixation. However, TopoGuard's prototype evaluation was based on the Mininet emulator, not on a real networking testbed. RAID [195] is another control prototype to passively monitor the network systems and target operational exploitation in a large-scale environment. However, the effectiveness of the prototype was assessed only through OpenFlow-backed connecting to three hardware switches.
Furthermore, several recent advances in SDN security have primarily targeted only one type of threat and proposed a security enforcement framework to mitigate it. Significant studies have extended the controller software for security enhancement against DoS threats such as [196], [197], and [198]. Most notably, SDNScanner [144] and AVANT-GUARD [160] provide a solution to mitigate and solve the problem of saturation attacks (data-to-control layer saturation) by altering flow management at the switch level. However, the presented design [160] is limited to TCP saturation attacks and exposes only the flows that complete the TCP handshake. Since this design is based on an SYN proxy implementation, it is unsuitable for different protocols.
VeriFlow [199] detaches a holistic network environment into sub-classes that have exactly similar forwarding behaviors exploiting a multi-dimensional prefix tree so that all forwarding policies will be checked in a live time whenever a network update occurs. NetPlumber [183] is a real-time policy verification tool based on Header Space Analysis (HSA). VeriFlow [199] and NetPlumber [183] assume the data plane is threat-free while checking the policies' constraints, and therefore do not consider investigating a broad class of inter OpenFlow switch-controller packets to refine the behavior and performance of the networking environment. In [200], Chung et al. introduced NICE, an approach to detecting network software bugs in OpenFlow-enabled applications based on symbolic execution and model checking.
In [175], Heller et al. discuss the SDN controller placement challenge. At the same time, they demonstrate the quantity of SDNs is one of the main defiances to establishing a resilient and scalable SDN environment. Thus, the controller placement problem has gained remarkable attention from the networking industry and researchers, and various mechanisms have been suggested and evaluated, such as [176], [177]. Bari et al. [201] proposed probabilistic-based Simulated Annealing (SA) algorithms to solve the controller placement problem optimally. In [176], Hu et al. portrayed the problem of controller placement as an NP-hardness problem as one way to enhance the SDN reliability in terms of functionality. In contrast, the quality of time responsiveness is preserved. Although the presented solution enhances the network behavior and operation reliability by reducing the anticipated rate of control-path loss, several recent algorithms for solving the same problem are eventually evaluated in real networking topologies, and trade-offs between reliability and response time are discussed.
Additionally, the dynamic controller provisioning problem (DCPP) was targeted by Bari et al. [201]. A platform is presented in this work for a real-time adoption of multi-SDN controllers in a WAN. Here, the locations and quantity of deployed controllers are regulated based on network mobility. Besides formulating the DCPP as a linear problem, which utilizes the networking flow paradigm and characteristics to reduce the OVS state collection expense (i.e., communication overhead), the authors demonstrated trade-offs between communication cost and the time required for flow configurations. In [202], Hock et al. introduced a lightweight mechanism for SDN placement based on Pareto to improve the controller availability. Based on [202], while a single SDN can be sufficient to fulfill the latency requirements, additional SDN devices must be deployed to satisfy the network resiliency specifications.
The OpenFlow SDN procures the topology state datums through LLDP, a link layer protocol to collect information about OVS devices connected to the SDN controller (e.g., the status of connection, switch information, connection port information, etc.) [203]. To solve the problem of SDN involvement in all LLDP packets that might lead to scalability challenges in SDN controller, Kempf et al. [204] present a practical design that offloads the potency of topology monitoring from the SDN to the OVS. Although the proposed platform provides a generic message simulator for OVS devices, its monitoring features and modules are compatible only with OpenFlow protocol version 1.1. In [205], Monsanto et al. introduce NetCore, a high-level language to describe flow rules and policies in the OpenFlow controller using a dynamic compilation-based mechanism to split the charge of flow handling between the SDN and OVS devices.
In [206], Mogul et al. benefited from the intrinsic trade-off between the OVS devices and the controller to enhance the availability of SDN infrastructure to design DevoFlow. The DevoFlow mechanism adjusts the OpenFlow architecture to reduce the cooperative computations and communications between the infrastructure and control layers. Because the holistic visibility of all network traffic is not indispensable, Mogul et al. designed the DevoFlow to incline certain control operations back to the OVS device while only preserving the centralized control operations in the SDN controller.
In [164], Tatang et al. presented SDN-Guard, a mechanism to detect and prevent SDN rootkits that permit adversaries to control the network in an SDN-enabled environment via compromising a controller and thus, subverting the network operating systems [166]. SDN-Guard [164] performs a dual-view comparison to identify malignant network programming attempts and hence block them. Moreover, Melis et al. [186] gave an SDN-enabled toolkit to identify and prevent various threats aiming to compromise and exploit the forwarding operations. The addressed threats include bogus injected flow rules-based compromised network boxes, inner loops, and black holes that are uneasy to identify using normal network scans.
Furthermore, Wang et al. presented SECOD [207], [208], an SDN secure control and data plane algorithm, which deploys new triggers to identify and prevent DoS attacks in both control and data layers of SDN. SECOD [207] is implemented on SDN-enabled hardware switches. In [187], Varadharajan et al. introduced a security architecture for policy enforcement in SDN. The architecture is based on a language technique to design security policies for protecting SDN services and control flows in a multi-domain SDN. Last, In [130], FloodShield is presented by Zhang et al. to solve the DoS-enabled data-to-control saturation attacks. Flood-Shield [130] is a deployable and lightweight IDPS solution to thwart dedicated saturation attacks through leveraging source address validation and stateful packet supervision according to evaluation scores and resource utilization.

B. DATA PLANE SECURITY ENHANCEMENT
The SDN data/forwarding layer is eventually in charge of assuring and guaranteeing the appropriate transit of network flows from an input port (i.e., ingress point) to a destined output port (i.e., egress point). Specifically, this transit follows the match : action rules inhibited in networking-enabled entity forwarding tables or FIB. The forwarding layer needs to be protected from anomalous applications capable of inserting new flow rules or even adjusting existing rules within the forwarding layer. Therefore, earnest enforcement VOLUME 10, 2022 solutions of security (e.g., authentication mechanisms) need to be implemented against these anomalous applications that tend to modify the valid flow rules. Table 6 depicts a list of existing solutions to enhance security in SDN controllers by addressing security threats residing in the data layer.
FlowChecker [167] is a verification and configuration solution that distinguishes and sets apart the malicious flow rules in an individual OVS device or internally-federated elements of the datapath. This security tool can also be utilized to check and examine the OpenFlow configurations at run-time for the OpenFlow applications and the master SDN controller. VeriFlow [199] is another mechanism for networking debugging and utilized to identify erroneous flow rules that were pushed by particular SDN-enabled applications and prohibit them from occasioning malicious network demeanors. Monsanto et al. [209] proposed FortNox, a framework that uses a real-time engine for flow rules examination. The proposed solution allows a NOX-based SDN controller to verify any discrepancies in networking flow rules asynchronously and dynamically at a run time. It also grants the newly implemented SDN applications the necessary authorization before modifying any flow rules in OpenFlow-enabled switching devices. Additionally, the proposed platform [209] delivers authorizations for OpenFlow applications based on the role via NOX OpenFlow controller software-based extension.
More studies have primarily concentrated on securing the infrastructure layer from malignant applications. Among these works, FortNOX [209], which addresses the SDN tunneling attack and solves the rule conflicts that contravene the security policies by designing a security enforcement kernel for SDN that aims to identify rule conflicts and resolution. Rosemary [220] is another solution that adopts a practical approach to address the issue of control layer resilience through an extension of a Network Operating System (NOS) design.
Moreover, as the SDN controller is lusty in terms of functionality of OpenFlow switching devices connectivity, the superfluous connectivities need to be consistent at a run time for the inter-communication between the SDN controller and OpenFlow-enabled switches. Further, the network access control applications demand intensive network state information in the SDN environment, which implies limitations in terms of network services support. Han et al. [221] presented STATEMON, an OpenFlow extension for programming the stateful SDN infrastructure layer. The proposed solution is a connection tracking based that provides a global state-awareness to enhance the access management in SDNs.
Furthermore, the OpenFlow protocol grants the easiness to set a subaltern connectivity with a backup SDN device to utilize if the primary SDN comes off. Fonseca et al. [211] presented a replication mechanism for the SDN controller to preserve the functionality of the switching device in case the primary SDN comes off. In this solution, the OVS will recurrently transmit probing packets to the controller. If the controller does not respond within a limited time frame, the OVS device will switch (e.g., reconnect) to the backup SDN controller based on the assumption that the primary SDN is no longer in-line.
Besides, the appropriate fragmentation and planning in a networking environment are of significant importance when enhancing the security of OVS devices, leading to the optimization of the controller and connectivity efficiency. Based on the actuality that an OVS device continuously connected to the SDN will be unlikely to experience a saturation threat as it is not imposed to save the unsought networking flows for a prolonged time frame. In [222], Zhang et al. show the route extent within an SDN and OVS entity is eventually proportionate to connectivity loss. Based on this assumption, Zhang et al. proposed that a route extent within the SDN and OVS device need to be minimally shortened to have an efficient functionality about latency qualifications and constraints and rapid analysis of security applications.
Additionally, Shaghaghi et al. [223] propose WedgeTail, an IPS dedicated to improving the security in the SDN infrastructure layer. The threat detection in their proposed solution is based on prioritizing OpenFlow switching devices before inspecting the networking flows using an unsupervised trajectory-based sampling mechanism where the switches are considered points within a geometric space.
Further, in [217], Scott and Arumugam presented OFTML-SEC, a state-based security solution for preventing the exploitation of network function implementations and configuration-based attacks (e.g., topology and path update, as well as ARP) at the data plane level. OFTML-SEC [217] is placed in the SDN switch and does not require the controller intervention. Particular virtualized security services often require complex configurations, leading to bandwidth drain and packet delay constraints. To address such a challenge, Park et al. [218] introduced DPX, as one of the security extension architecture that uses action-based abstraction for security services and translates them to OpenFlow rule sets.
Dedicated DoS attacks aim to saturate the control-to-data channel (i.e., control-to-data saturation attack), where adversaries flood bursty traffic to trigger massive packet-in messages and table-misses in the infrastructure layer, exhausting the TCAM and buffer memory. To alleviate the control-data saturation attacks, Zhang et al. [130] developed FloodShield, a solution that leverages a filtering approach to filter forged packets and a monitoring technique to monitor flow states of addresses before performing dynamic countermeasures using resource utilization and evaluation scores.

C. APPLICATION PLANE SECURITY ENHANCEMENT
Since the SDN controller grants flexibility for applications, while behaving as a medium bridge between the networking hardware and SDN-enabled applications, it becomes easier to implement applications that take advantage of network traffic characteristics and statistics to carry out sophisticated security features and services. Numerous languages have been introduced to design and integrate new security applications in SDN controllers, such as NetCore [205] and FRESCO [224] that allows the development of security applications complying with OpenFlow standards specifications. Table 7 presents existing platforms/solutions to enforce different types of security issues in the SDN application layer and to assure applications' compliance with OpenFlow standardization. In this subsection, we present a variety of security solutions and proposals that were introduced to verify the compliance of SDN-enabled applications with the security policies specifications.
The application layer provides various applications and networking-enabled services, including, but not limited to, Deep Packet Inspector (DPI), IDS/IDPS, and security monitoring services. Therefore, a proper level of authorization and controlled access should be enforced for these SDN applications. Guaranteeing commands and inquiries from an application that is not modified or rigged is necessary for SDN environments. However, steadying and maintaining a reliable trust between the control layer and application layer is a substantial challenge in SDN security. For this purpose, the OpenFlow-enabled devices need to be permitted to communicate and collaborate with the SDN controller at run time but without enduring a mistrusting relationship.
In [154], Wen et al. introduced PermOF, an accurate authorization mechanism that allows for restricted access to OpenFlow-enabled SDN as well as data path to OpenFlow-based applications. The proposed solution in [154] establishes controlled access according to a combination of isolation and authorization techniques (e.g., system-based authorizations) to carry out an authorized and controlled access. However, the proposed security mechanism was not experimentally evaluated.
As the implemented applications in SDN controller need to fulfill the global network view to keep up with the network updates and changes, Beckett et al. in [225], suggest a mechanism to check, belay and rectify SDN-based applications to keep up (e.g., be alerted) with the network changes. The proposed assertion-based mechanism grants a program bugs detection. It utilizes a probing language to allow network operators to examine and rectify dynamic attributes and characteristics of SDN applications.
Flover [226] is an OpenFlow checking system-based framework to assure the flow policies aggregations do not breach the security policies of a particular network. Flover is designed as an OpenFlow-based application running on the SDN to ensure flow rules inserted by the controller are harmonious with the specified properties. Further, VeriFlow, which is presented in [199], is a dynamic mechanism behaving as an inter-layer between the networking devices and the SDN controller. It examines and verifies the network configuration dynamically at run time. The proposed solution facilitates finding bugs using an incremental data structure-based algorithm with minimal impact on network performance.
Other solutions such as [227] and [229] provide an autonomous testing mechanism to find OpenFlow-based applications bugs. In [229], Handigol et al. proposed a platform to rectify network applications and identify the root cause of application bugs. Like [229], OFRewind [230] is another security platform to identify anomalous network behaviors. OFRewind permits logging and replaying particular traffic to identify abnormal traffic and activities in a networking environment.
Moreover, Li et al. [168] presented CCD, a covert channel defender solution to thwart rule conflicts generated by VOLUME 10, 2022  SDN-enabled applications. Li et al. [168] first investigated the rule conflict problem before detecting covert channel attacks caused by policy and rule conflicts in applications. The proposed CCD [168] protects the SDN infrastructure from covert channel attacks by validating and resolving rule conflicts. The proposed CCD traces modification messages and rule injection by SDN applications. CCD also analyzes the correlation pattern within inserted rules using fields of the packet header and solves malicious rules conflict in real-time before they are installed.
Although several solutions have been proposed to assist with designing and implementing security applications in SDN about protecting the SDN control layer from anomalous and threatening applications, there is still a scarce potential effort to improve the SDN applications' security. The remaining significant challenges can be summarized as follows: • There is no proposed solution to distinguish between the user applications, third-party applications, or even service-based applications.
• accountability mechanisms and access control techniques for nested SDN applications are not proven efficient yet. Last, to summarize the key points, Table 9 gives a taxonomic overview of security solutions and platforms discussed in this section for each SDN layer, control, data, and application layers.

D. THREAT DETECTION & PREVENTION TECHNIQUES
SDN allows the controller to be in an isolated network segment, and we have the management interface in the management network and the data communicated through the data network. However, even though we have the flexibility of isolating them, we have a high-value target in operating the controller to control the entire network. The attack surface targeting the SDN network could either attack the data through the data plane or the control signals through the control plane. However, the SDN controllers are also exposed to threats and attacks via the data plane. In SDN, it is possible for the attackers to traverse from the data plane to the control plane. For instance, when the OpenFlow protocol is used in SDN controllers to control switches, it facilitates the flow rules communication and data packet processing (e.g., checks incoming packets against all rules in the flow table) and switching. If it does not match any of the rules provided by the controller, it forwards a copy of that packet to the SDN controller and requests its assistance. In such scenarios, if there are some vulnerabilities in the processing logic of the SDN controller, then we cannot reverse from the data plane to the control plane. Table 8 summarizes the list of threats in SDN application and their detection and prevention techniques.
For mitigating the threats in SDN architectures, the authors in [231] developed an algorithm to thwart the DoS and malware attacks, and it was tested and evaluated on multiple adversarial settings. In [39], the authors surveyed the SDN-based intrusion detection and prevention mechanisms from the context of security in IoT services, which was incorporated based on the manufacturer usage description. Han et al. [40] summarized the possible security threats and possible solutions for mitigating them in SDN controllers, primarily focusing on the threat impacts on the SDN control layer. In one of the recent works by Yurekten et al. [41], the authors presented SDN-based cyber defense types, techniques, strategies, and their deployment for assessing the impact of common attacks.
A fog-assisted SDN-driven intrusion detection and prevention system was developed by the authors in [232] for anomaly detection in IoT networks. Further, the solution granted mitigation of the identified threats with minimum computation resources compared to traditional approaches. Malik et al. [233] used a hybrid deep learning approach for the implementation of timely and efficient detection of multi-vector attacks and threats in SDN. Here, the evaluation was performed to detect accuracy and analyze the speed as well as efficiency of using deep neural networks in SDN. Ahmad et al. [234] summarized the impact and benefits of ML techniques for securing the SDN from DoS and DDoS attacks, which addresses the vulnerabilities in fingerprinting security.
Node replication attacks or clone attacks are more prominent in wireless sensor networks (WSNs), where the attackers make multiple nodes with the same identity and deploy them at various places across the network. In [235], the authors proposed a hybrid clone node detection mechanism enabled through SDN to protect the WSN. This helps thwart attacks by removing the clones occupying the network, thereby improving the performance through better detection mechanisms. Bhayo et al. [236] proposed an SDN-based timeefficient and secure IoT framework for addressing the DDoS attacks, which was carried out by analyzing various classes of parameters observed from the large volume of traffic in the SDN communication. Further, it was also reported to provide higher detection accuracy with lower false positive rates. Similarly, in [237], the DDoS attacks in IoT networks are addressed using the SDN-based honeypots. It was implemented using the moving target defense architecture, where the SDN-based honeypots mimic the IoT devices and safeguard the original IoT devices from malware and attackers.
TILAK [238] was introduced as a token-based prevention technique for the detection of possible threats in SDN. Here, the flooding, poisoning, and replay attacks of the layer discovery protocol were comprehensively analyzed. Further, this approach also confirms mitigating the threats that possess lower resource penalties. The authors in [239] deployed a machine learning (ML)-enabled threat detection mechanism for securing SDN-based networks, which was also experimented with mitigating multiple attacks under various scenarios, thereby providing secure data sharing in the network. A hybrid deep neural network architecture was developed [240] for SDN orchestration targeted toward combating the impact of cyber threats on the Internet of Medical Things (IoMT). Here, the testing efficiency and detection accuracy are assessed and observed to provide efficient and timely detection and mitigation of malware in the network.

E. SECURITY AUTOMATION AND REACTION IN VIRTUALIZED NETWORKS
In complex and large-scale networks, manual security operations may significantly delay or even hinder the detection and mitigation of increasing security attacks [248]. Therefore, as SDN's primary benefit is to facilitate the management and operation of networks with reduced human intervention, security automation in these networks using SDN technology has become intrinsic [249].
Security automation in SDN-enabled environments can be categorized into several complexity levels. The automation level can be measured based upon key qualitative properties; self-optimization, self-healing, self-configuration, and selfadaptation. Further, the complexity automation level can be measured based on two parameters such as, implementation requirements and the amount of storage and processing resources [250].
Automated security and policy tools have been remarkably studied and explored to enhance network-based security services and minimize human interventions and errors. Moreover, the agility needed for security automation tools can be facilitated by integrating SDN & NFV capabilities and transitioning network security management from the hardware to the software level. Notable works such as [251] present an SDN framework to optimally and autonomously allocate and configure security features in virtualized networks. The proposed framework provides a formal verification of the security functions and direct integration into cloud orchestrators.
The authors in [252] developed a zero-touch framework for security automation and orchestration through SDN & NFV. The proposed framework addresses security functions and policy configuration in SDN-enabled UAV systems. It optimizes security orchestration based on a broad range of contextual factors associated with software and hardware conditions. SDN and NFV technologies introduce modern security enablers to IoT and industrial networks, providing them with higher flexibility and scalability degrees needed to cope with the ever-increasing security automation and configuration requirements [253]. Many studies in the literature considered integrating or leveraging SDN infrastructure to enhance security in industrial and IoT networks [254]. However, only a few deploy SDN and NFV technologies to improve or automate security configurations in these networks. Notably, the authors in [255] specifically enhanced the IoT honeynets using SDN and NFV technologies by optimizing the security automation process. The proposed solution adopts a security policy-based mechanism to enforce honeynets orchestration and facilitate IoT network management. The authors in [256] propose an SDN architecture to enhance security automation in smart grids. The architecture comprises three layers, risk assessment, threat detection, and self-healing to dynamically evaluate the threat level, detect and correlate threat events, and thwart the potential threats.
Although security and policy automation tools for virtualized networks are feasible and help thwart cybersecurity threats, there are limited set of automatic security orchestration tools providing a direct integration into SDN-supported cloud orchestrators with minimal human intervention. Moreover, comprehensive automation architectures fulfilling detection and mitigation of multi-vector attacks, mutual trustworthiness of entities in proportionally unknown topologies, access control and identity management are still missing in virtualized SDN systems [257].

V. LEARNED LESSONS AND OPEN CHALLENGES
In this survey, we have covered the recent contributions of SDN research made toward secure communication systems. While securing the SDN has excellent potential in establishing a robust communication infrastructure, it is not feasible without its inherent limitations that need to be addressed. In this section, we summarize and reiterate the insight we have explored among various areas of SDN that impact the security of SDN communication systems, as discussed in this survey. The reviewed research contributions utilize the inherent virtues of the infrastructure and its defense mechanisms in these areas of securing SDN communication and specific mechanisms discussed in previous sections.

A. THE SCALE OF SDN COMMUNICATION SYSTEMS
A clear lesson learned from the recent works is that security threats for SDN systems are in almost all infrastructural layers. Moreover, based on the scale of the network, there is a proportionate increase in the probability of the attacks. Risk assessment of safety data link and SDN network communication requires adaptive quantitative schemes and frameworks. Further, fault-tolerant algorithms ensure the reliability VOLUME 10, 2022  of SDN data by assessing the safety of data links and network risks. Also, in large-scale SDN communication systems, the performance analysis for multi-priority data flow scheduling is crucial for guaranteed risk assessment of safety-critical data communication in the digital safety feature control systems. Moreover, intelligent traffic management and load balancing can be achieved by predicting the packet flow in the network, helping in reducing the congestion in the SDN communication scenario.

B. INTELLIGENT AND SECURED SDN CONTROLLERS
The centralized means of SDN control facilitates network programmability for adaptive and automated control. However, intelligence in forwarding and processing incoming packets at a single point could be addressed through various deployment models that ensure secure handling and processing of data. The secured SDN controllers can enable control through physically centralized, distributed, or hybrid architectures. Moreover, various performance parameters and security measures must be balanced without compromising consistency, scalability, and reliability. The intelligent SDN controllers should provide a trustworthy forwarding of data in the communication system and adequately address all the performance parameters with the secure communication framework. Further, networking, operating, and accessing the resources in the cloud environment through the secure SDN services need additional intelligence at the controller with the compromise on the performance parameters.

C. RESEARCH AND PRACTICAL IMPLICATIONS 1) NETWORK POLICIES
The worth of SDN lies in its capability to guarantee coherent policy enforcement and better scalability due to its centralized management and network programmability [31]. The future generation of security solutions will benefit from the richness of network usage information available in SDN to enhance security policies enforcement, network anomaly revelation, and attenuation.

2) CONTROLLER COMPROMISE
In [29], a survey was conducted on how to improve network security using the characteristics of the SDN architecture, and what vulnerabilities and security issues the SDN architecture may introduce. However, the existing knowledge on SDN attacks is quietly limited. The current systems and solutions imposed on carrying out SDN functions may be prone to malignant security threats. Adversaries will inevitably exploit these SDN systems if a successful network compromise is feasible through exploiting SDN infrastructure vulnerabilities. A susceptible SDN environment could therefore undermine the security and availability of the entire networking system [26].

3) THREAT ANTICIPATION
To secure SDN environments, all of the potential security threats need to be anticipated before adversaries exploit their vulnerabilities [198], [258]. Moreover, an efficient threat mitigation model has to consider looking at SDN from the attacker's perspective to highlight potential threats/anomalies on SDN at the architectural level, regardless of whether these threats can be successfully carried out.

4) INTRUSION DETECTION AND PREVENTION
In an SDN infrastructure, the mitigation scheme aims to resist a certain attack(s) on networks attached to the Internet (i.e., interconnecting) network by securing the target and relay networks. This could be achieved by passing network traffic to the attacked network through high capacity networks with traffic scrubbing filters (e.g., DDoS mitigation demands an appropriate identification of incoming traffic to distinguish human-like bots from human traffic and hijacked web browsers) [209]. Based on the threat model, risk speculation can be further elaborated to define what threats are likely to pose realistic dangers to a specific SDN deployment, thus, designing a more feasible mitigation scheme. For each attack to be mitigated, security requirements should be identified, outlining a group of goals to attain the desired SDN security. Hence an optimal way of threat mitigation using the benefits of SDN infrastructure needs to be elaborated.

5) LACK OF TLS ADOPTION
TLS and Datagram Transport Layer Security (DTLS) are quietly complex to implement and configure in SDN-enabled devices from the technical perspective [138] (e.g., requires the creation of global certificates including SDN and OVS devices certificates, generation of appropriate keys and certificates for all networking devices in the SDN environment, etc.). Hence, networking operators and vendors have ignored TLS deployment in OpenFlow switching devices and made it optional. However, even with the adoption of TLS specifications in an SDN-enabled environment, the OpenFlow switches are still vulnerable to TCP level threats due to the lack of TCP level protection in TLS implementations. In [138] and [259], Benton et al. and Dierks highlight TLS as well as DTLS specifications for OpenFlow protocol deployment. Nevertheless, the recent OpenFlow versions (i.e., version 1.3 and above) do not enforce TLS adoption and render it optional.

6) CONTROL PLANE PERSPECTIVE
As the SDN controller provides logically centralized-based control decisions through its control plane, this renders the entire SDN infrastructure vulnerable and hence targeted when proceeding with anomalous networking actions and activities.

7) DATA PLANE PERSPECTIVE
In SDN technology, if OpenFlow switching devices do not extradite any instructions about flow forwarding rules from the SDN controller, this implies that the SDN control layer is disconnected or there is a control layer failure at some point. Therefore, this scenario renders the link off-line and allows for its exploitation by an adversary that could insert new flow rules to serve their goals. The separation of the management layer from the infrastructure layer can present new threats such as teleportation, where an adversary attempts to send information via the control layer bypassing pre-defined network functions at the data layer level [163]. Thus, the security of the control layer has an explicit effect on the data layer [160]. This implies that if an SDN controller is compromised, all data layer entities will be compromised.

8) APPLICATION PLANE PERSPECTIVE
The application plane in SDN is decomposed of implemented applications, which interactively program the network with the control plane of SDN. These various applications could be autonomous and possessed by multiple network users.
As SDN fulfills the networking foundation specifications, it guarantees to manage the entire networking environment by software through logically centralized control mechanisms [153]. However, SDN architecture does not provide mechanisms and specifications to expedite the use of open APIs for applications to manage, control, and monitor network services and features via the SDN control layer [155]. Hence, this limitation renders the SDN infrastructure and networking devices and resources vulnerable to attacks by malicious applications. These security challenges are evolving while the OpenFlow protocol does not offer any compulsory security mechanisms to enforce the access control and authentication for implemented SDN-enabled applications. VOLUME 10, 2022

D. FUTURE RESEARCH TRENDS
The SDN controller allows developers and network administrators to implement advanced and efficient networking architectures, models, and operational network applications. This flexibility eventually carries out creative inventions as well as presents security threats, and challenges in the networking industry and research [260]. This subsection discusses open research problems and future research opportunities for secure integration of SDN architecture in smart city communication systems. The key research directions are summarized and discussed in detail as follows.
• Examination of the controller software implementations prior to integration into smart city communication systems to identify possible exposures to common pitfalls and design vulnerabilities.
• Exploration of policy integration complexity and policy collision in the distributed SDN control plane.
• Enforcement of authorization and access control of SDN-enabled applications according to the distinguished operations' demands while preserving the networking overhead constraints.
• Enhancement of scalability to prevent adversaries from elaborating on attacks based on the immersing controller-to-data channel communication.
• Addressing the cascading deficiency caused by multi-SDN controllers deployment.
• Enhancement in SDN-enabled business intelligent decision making and imparting robust security shield through intent-based networking (IBN) and blockchain deployment.

1) IMPLEMENTATION
A broad range of OpenFlow implementations have been examined to investigate their exposure to common sets of pitfalls and design weaknesses (e.g., [261]), which allow for an intensive amount of security threats. Thus, the SDN-enabled independent applications may utilize the functionalities of various SDN elements at a time, introducing severe security vulnerabilities. Besides, when an SDN application (i.e., whether a user or administrator-based) is implemented in the control plane in a detached networking environment, the SDN can be prone to further security challenges, such as policy integration complexity and policies collision.
The vast majority of networking operations are perceived to be installed as networking-enabled applications in software within the SDN control plane (i.e., control-application layer level). While particular implementations in SDN software may require network statistics about load-balancing, other applications could require flow samples, etc. Thus, each particular type of SDN application must have a reasonable and safe authorization and access control according to its specific operation demands in order to maintain a determined jurisdiction and utilize a reliable traffic route while preserving the networking overhead constraints.
Furthermore, a categorization of applications impacting the SDN resiliency is needed based upon specific criteria; packaged services of network, services for the network system, and critical networking applications. Authorization and access control mechanisms in this context should not be unified for all SDN applications; otherwise, the control layer may experience a bottleneck as a result of the large quantity of arriving requests to gain entry to networking elements and resources.

2) SCALABILITY
Scalability is another considerable challenge in the centralized SDN controller, where the quantity of control flows augments as the topology scale increases. As a result, the response time of the flow rules setup significantly increases. Furthermore, the scarcity of SDN scalability can allow adversaries to establish attacks based on the immersing controller-to-switch communication to saturate the SDN control layer, thus compromising the exhausted switching devices. Although several studies proposed the employment of multiple SDNs to resolve the availability challenges in SDN, such a mechanism typically leads to a cascading deficiency. Therefore, the corresponding scalability to SDN resiliency must be taken into consideration in order to grant reliable SDN availability.

3) CONTROLLER AND SWITCH RESPONSE TIME
The SDN controller offers control and application layer-based services for a broad range of traffic forwarding entities. Such an SDN capability can lead to a controller-to-switch and switch-to-switch latency increase when reciprocating the network state and resources inquiries, introducing new vulnerabilities related to SDN availability. It is also feasible that the larger the number of connected switching devices becomes, the higher the controller response time of installing traffic rules is since more incoming traffic requires more setup demands from the controller. Hence, a smart trade-off among the infrastructure and control layers is recommended as an eventual solution to optimize the switch reliance on the SDN and improve scalability and delay through internal decision-making abilities.

4) POLICIES DEPLOYMENT
The security of a network environment is a key structural component of network management, and resilient policy adoptions demand a comprehensive analysis of policies' configurations in order to avert policy conflicts, minimize the risks of security vulnerabilities, and maintain the network flows alive when a security breach occurs. Like in traditional networks, flow characteristics, features, and statistics are deployed to capture flooding threats. Although several studies (e.g., [178], [198], [262]) addressed the controlto-data layer saturation attacks in reactive controllers via lightweight implementations for independent detection and mitigation mechanisms. However, SDN's holistic and centralized networking view and its infrastructure layer's flexible programmability are likely to allow for interdependent and mutual policies deployment. Thus, it is recommended to design interdependent policies for security and flow forwarding that guarantee a secure forwarding of data flows.

5) AUTOMATED RECOVERY
SDN further allows for introducing languages and controllers that have the ability to react under the network state alterations dynamically. SDN controllers provide a framework for efficient automation and monitoring of the network state, rendering the design of new tasks in automation-based applications simple. Consequently, the communication and SDN operations costs must be minimized through dedicated automation mechanisms. Such mechanisms can be designed and developed based on platforms dedicated to automated policies and autonomous control implementations. However, no practical mechanism for policy automation has been tested in SDN yet.
The logical centralization of the SDN brings in more charges for network operators as the paucity of the operator's awareness, and familiarity could render the networking environment prone to bottleneck threats. Thus, autonomous recovery applications and automated, flexible, and advanced security mechanisms are recommended to be placed on top of the SDN controller so that operators only need to provide minimal involvement to secure the communication system.

6) FLOW TRACKING
Future network security defense mechanisms are recommended to extend current tracking techniques of data flows on each host for specific network-level defenses. As such, the SDN paradigm may be leveraged with data flow tracking techniques to capture a broad range of cyber threats utilized by knowledgeable attackers targeting both network and application layer protocols. Current network traffic monitoring and attack detection practices still mainly rely on simple statistics, suffering from poor performance and low accuracy. Future developments can employ more advanced ML techniques for analyzing large-scale testbed traffic data as it is currently challenging to scale to the volume, velocity, and complexity of the traffic data from large-scale networks.

7) BUSINESS INTELLIGENCE
To meet the business demands enabled through SDN technology and provide effective network management, the network can be made more intelligent through IBN. This framework allows us to capture the business intent, check the integrity, and translate it to policies. Further, continuous network alignment will be guaranteed with assurance on continuous verification, insights, and corrective actions through AI-enabled service assurance capabilities in the network. The primary role of SDN in the IBN is to orchestrate the policies and automate secured system configuration targeted for QoE-driven business models [263].

8) RESILIENCY
SDN-based communication systems are vulnerable to different network resiliency incidents, including energy outages, connectivity disruption, and controller crashes. Such incidents are more likely to occur when the network is under specialized attack scenarios. The vast majority of existing research studies in SDN security focus on predicting, preventing, detecting, and mitigating attacks, but limited number studies address network state recovery after successful attacks. Complete security solutions can be developed based upon a combination of proactive and active approaches to simultaneously act as a front-line shield against security attacks and enforce the network state recovery once the SDN infrastructure is successfully compromised.

9) BLOCKCHAIN INTEGRATION
Lastly, a further future direction is the integration of blockchain technology and SDN into smart city applications. An integration example can be blockchain as-a-Service [264]. In this direction, a permissioned blockchain can be deployed to prevent malware injection against not only the SDN planes, but also the intermediate communication paths. Further, efficient authentication methods can be incorporated through distributed trust services, ensuring lower energy consumption with lower delay and improved throughput in the SDN routing decisions.

VI. CONCLUSION
SDN architecture provides a flexible and agile experience for the end-users in a wide range of applications. The SDN market has evolved in response to the demands from large data centers toward the aggregation of multiple types of network connections. SDN has further enabled solutions for high-demand resources, managing unpredictable data traffic patterns, and rapid network reconfiguration. It is used to virtualize the network by separating the control plane from the data plane, where data flows are separated from control flows. However, the rapid increase in the number of smart devices connected to the network has increased the data traffic in the network and raised security issues in SDN-enabled communication systems. In this paper, we conducted a comprehensive survey on the core functionality of SDN from the perspective of secure communication at different scales. A specific focus is given to address the challenges of securing SDN infrastructure. We further categorized the appropriate solutions for specific threats at each layer of the SDN communication framework. Lastly, security implications and future open research challenges are presented to help the community gain further insights into the domain of SDN security.