An Overview of SDN Issues—A Case Study and Performance Evaluation of a Secure OpenFlow Protocol Implementation

Abstract

Software-Defined Networking (SDN) is a network architecture that decouples the control plane from the data plane, enabling centralized, programmable management of network traffic. SDN introduces centralized control and programmability to modern networks, improving flexibility while also exposing new security vulnerabilities across the application, control, and data planes. This paper provides a comprehensive overview of SDN security threats and defenses, covering recent developments in controller hardening, trust management, route optimization, and anomaly detection. Based on these findings, we present a comparative analysis of SDN controllers in terms of performance, scalability, and deployment complexity. This culminates in the introduction of the Cloud-to-Edge Layer Two (CELT)-Secure switch, a virtual OpenFlow-based data-plane security mechanism. CELT-Secure detects and blocks Internet Control Message Protocol flooding attacks in approximately two seconds and actively disconnects hosts engaging in Address Resolution Protocol-based man-in-the-middle attacks. In comparative testing, it achieved detection performance 10.82 times faster than related approaches.

1. Introduction

Traditional networks rely on physical modems, routers, and switches to provide intranet and internet connectivity. These networks typically have distributed controllers, while routers include multiple interfaces and configuration options that must be managed individually by a network administrator. Configuring each router separately can be time-consuming unless proprietary automation tools are used.

In contrast, a Software-Defined Network (SDN) uses a centralized programmable controller to manage packet forwarding and policy enforcement across the entire network [1,2]. By separating the data and control planes, SDNs enable administrators to apply network-management applications globally through a single controller [1]. These applications can dynamically select optimal network paths based on current traffic loads, minimize disruptions during routing changes, give customer networks more control over traffic flows, and detect or block suspicious traffic [3]. SDNs have been widely adopted in Internet Service Provider (ISP) networks and data centers, where their centralized management capability offers significant advantages [2,3]. While larger enterprises often rely on proprietary router and switch vendors, smaller organizations can use open protocols such as OpenFlow to implement centralized control with minimal cost [4].

SDNs operate over the same Internet Protocol (IP)-based packet communication used across the internet. IP-based data transmission divides messages into packets, each containing metadata such as source and destination addresses, sequencing information, and error-checking codes. These packets are then reassembled upon arrival to reconstruct the original data.

Key components of IP-based communication include:

• IP Addresses: Unique numerical identifiers assigned to each device on a network.
• Routers (Layer 3—Network Layer): Devices that forward packets between networks based on destination IP addresses.
• Protocols: Communication rules such as the Transmission Control Protocol (TCP) for reliable delivery and the User Datagram Protocol (UDP) for faster connectionless transmission.

Layer 3 and IP-based technologies offer several advantages. Packet-based routing helps to reduce congestion, while reliable protocols such as TCP ensure accurate and ordered delivery. The architecture is also highly scalable. However, challenges include varying packet transmission times due to independent routing paths, potential for data loss or corruption, and the complexity of managing distributed controllers in large-scale networks.

SDNs have emerged in the context of addressing these challenges and improving network management. This paper focuses on the OpenFlow protocol, as it is the common link between all of the controllers in the literature reviewed for the southbound Application Programming Interface (API) in SDNs. Switches that support the OpenFlow protocol can be used by an SDN to create centralized control over the packet flow, which can lead to more efficient management of network traffic. Additionally, virtual switches such as open vSwitch can be used [5]. With SDNs, new security mechanisms can be implemented as network applications enabled by centralized control, allowing for more efficient and dynamic security management. However, SDNs also introduce some new security concerns. As a network-wide packet traffic controller, the SDN represents a single point of failure and becomes the natural target for Denial of Service (DoS) attacks; furthermore, the critical role of the centralized controller in policy enforcement and flow rule dissemination makes it a prime target for Man-in-the-Middle (MITM) attacks, potentially allowing an adversary to intercept or manipulate control plane communications. A primary concern is that compared to traditional networking, fewer centralized controllers must be compromised in order to compromise the network [6].

While research into SDNs has produced a range of security mechanisms, including SDN-specific intrusion detection systems, the field is still maturing [7,8]. The use of a unified data model simplifies assumptions for algorithm designers and facilitates the development of SDN applications [1]. These applications can run at either the controller level or via the controller’s Northbound Interface (NBI). The NBI allows network applications to interact with the SDN controller. NBI allows integration with external logic and services (see Section 5.3 for details). Network functionality that was previously embedded in firmware, such as the Open Shortest Path First (OSPF) protocol, can now be implemented in software running on the controller. This flexibility is a major distinction of SDNs in comparison to traditional networks. Many SDN publications focus either on specific use cases or provide high-level survey analyses of performance and security.

This paper aims to synthesize both perspectives. It presents a broad conceptual review alongside implementation-based insights to provide a comprehensive overview of SDN security and performance. The key contributions of this paper are as follows: (1) a detailed analysis of SDN security models, with a focus on vulnerabilities, authentication mechanisms, and advanced techniques for routing and anomaly detection; (2) a comparison of SDN controllers by performance, scalability, and ease of deployment; and (3) a case study of a Layer 2 secure SDN controller implementation (CELT-Secure) tested in virtualized simulations of DoS and MITM attacks.

The remainder of this paper is organized as follows: Section 3 reviews related work and highlights the distinct contribution of this study; Section 4 outlines key SDN components and the OpenFlow protocol; Section 5 analyzes security challenges in SDN; Section 6 discusses ML-based SDN applications; Section 7 presents the CELT-Secure switch implementation and experimental results; and Section 8 outlines future directions and concluding remarks.

2. Methodology

This research follows a structured methodology designed to bridge gaps in the SDN literature by not only analyzing current challenges but also building and validating a practical architectural solution. The process is outlined in Figure 1 and is composed of four key phases: literature identification, gap analysis, design and implementation of the proposed system, and empirical validation.

We began with a comprehensive literature search across leading academic databases, including IEEE Xplore, ACM Digital Library, SpringerLink, MDPI, Elsevier, Wiley, Taylor & Francis, and Nature, among others. Our focus was on peer-reviewed publications related to SDN security and performance, preferring papers from the past 5–7 years. Search keywords included combinations of “SDN security”, “DoS mitigation”, “MITM detection”, “SDN scalability”, “controller placement”, “reliable and resilient architectures”, “network functions in SDN”, and “machine learning in SDN”.

Inclusion criteria emphasized papers that addressed architectural design, security enforcement mechanisms, and performance considerations. Exclusion criteria filtered out non-peer-reviewed works or works that focused solely on theoretical frameworks.

2.1. Gap Analysis

There are many strong existing studies across a broad range of issues, from comprehensive surveys to works on scalability, control plane optimization, or specific attack vectors. However, we found limited efforts that integrated multiple security features into a modular, real-time, and responsive SDN component. Through this review, we identified a gap relating to the lack of lightweight architectures that can provide localized mitigation at the switch level while interfacing with the SDN controller. These findings informed our decision to design and implement a controller-assisted intelligent switch—CELT-Secure—capable of local detection and immediate response.

We developed CELT-Secure as an intelligent switch designed to respond to traffic anomalies in real time. The switch integrates detection logic for DoS and ARP-spoofing-based MITM attacks, operating in conjunction with a Ryu SDN controller.

2.2. Contribution and Added Value

The methodology followed a logical progression from literature evaluation through architecture design and experimental validation, all focused on addressing practical deployment challenges in SDN environments. The CELT-Secure switch provides a lightweight deployable module that can be extended to additional attack types and is complementary to existing SDN security tools. Unlike prior works, our system enforces early-stage local mitigation without relying solely on centralized controller logic.

3. Related Works

To ensure a comprehensive and critical understanding of the current landscape in SDN security and performance, we adopted a systematic approach to the literature review process, as illustrated in Figure 1. This methodology guided the identification, screening, and evaluation of relevant works across leading academic publishers, including IEEE, Springer, ACM, and MDPI. Our search focused on key topics such as scalability, routing, controller placement, and security threats such as DoS and MITM attacks. Through this process, we observed that while many studies have addressed specific concerns in isolation, few of these offer an integrated architectural perspective. Building on these insights, we developed the CELT-Secure switch and validated it using simulated attack scenarios. The following sections summarize the key methodologies we reviewed, critical findings from our evaluation, and gaps that our proposed model aims to address.

The survey by Zhao et al. [9] provides a comprehensive overview of how machine learning techniques are integrated with SDNs to enhance performance and resilience. It highlights the use of ML for traffic prediction, routing optimization, and anomaly detection in real-time. Other applications include forecasting resource demands to optimize allocation and identifying faults to improve network resiliency.

A foundational study by Kreutz et al. [10] describes the architectural evolution of SDN and its potential to simplify traditional IP network complexity by separating the control and data planes. It also identifies several technical challenges that SDNs must overcome, namely, resiliency, scalability, performance, and security. Opportunities for applying SDNs in cloud and carrier-grade environments are also discussed, underscoring the need for ongoing development. Other survey papers have expanded on these themes, addressing infrastructure scalability, controller distribution, and SDN usage in Internet of Things (IoT) contexts [11,12,13,14,15,16].

Several application-focused works provide case studies of ML deployed in emulated SDN environments. For instance, Huang et al. [17] designed an ML approach for classifying social media traffic using Support Vector Machine (SVM), decision tree, and neural network approaches. Their work resulted in improved traffic identification and better overall network management. Similarly, Bhardwaj et al. [18] applied ML for fault detection in real-time video streaming to ensure service continuity.

Deep learning has also been explored. Aldweesh et al. [19] reviewed the use of deep learning models for tasks such as traffic classification, intrusion detection, and automated policy enforcement in SDNs. These techniques show promise in managing complex traffic patterns and large datasets. Chen et al. [20] examined how ML can help to scale SDN infrastructures by dynamically managing flow rules and optimizing resource use in growing networks.

Overall, these studies demonstrate the transformative potential of combining SDNs with ML. However, most works have focused on isolated aspects such as security, scalability, or routing, without synthesizing the architectural implications with implementation or deployment practices. In this paper, we address this gap by presenting a unified perspective linking SDN architecture, security challenges, ML applications, and controller performance. We also include a demonstration of the CELT-Secure controller, a lightweight SDN security application tested in a virtualized setting. While not exhaustive, the case study offers a practical complement to our conceptual research. Section 4 continues with a discussion of SDN architectural elements, OpenFlow communication, controller structures, and hardware limitations.

4. Components of SDN

The terminology of some main components of SDN is defined in the following list.

• OpenFlow Protocol: A communication protocol that enables separation of the control plane from the data plane in SDNs, allowing for direct manipulation of network devices by SDN controllers.
• Software-Defined Networking (SDN): A networking approach that decouples the network control and forwarding functions, enabling programmable and dynamic network management.
• SDN Controller: A centralized software application that manages and controls network behavior by communicating with network devices using protocols like OpenFlow.
• SDN Data Plane: The part of the network that is responsible for forwarding packets based on rules set by the control plane.
• SDN Control Plane: The part of the network that makes decisions about where traffic should be sent and instructs the data plane accordingly.
• SDN Northbound API: Interfaces that allow communication between the SDN controller and the applications and services running above it.
• SDN Southbound API: Interfaces that enable the SDN controller to communicate with the network devices below it, such as switches and routers.
• SDN East and Westbound APIs: Interfaces that facilitate communication and coordination between multiple SDN controllers, ensuring interoperability and policy sharing across different network segments.
• Network operating system: A software platform that runs on an SDN controller and provides the necessary functions to manage and control the network.
• Open vSwitch: A virtual switch designed to enable network automation while supporting standard management interfaces.

4.1. OpenFlow Protocol Messages

OpenFlow protocol messages serve critical roles in establishing connections, collecting network statistics, managing switch behavior, and facilitating data plane-to-controller communication. An OpenFlow packet includes several components: the version indicates the OpenFlow version; the hltype identifies the message function (e.g., type 0 is Hello, type 10 is PacketIn); the length specifies the message size; and the transaction ID links requests to responses [10,21,22,23]. A fundamental role of the SDN controller is configuring a switch’s forwarding behavior by installing flow rule entries in its flow table. Switches may include multiple flow tables, each capable of applying custom actions such as header modification, packet dropping, or forwarding [4,24]. The OpenFlow protocol is developed and maintained by the Open Networking Foundation (ONF), which oversees the specification’s evolution.

Figure 2 illustrates the general structure of an OpenFlow message. The match field defines the conditions a packet must meet to match a particular flow, including parameters such as the ingress port, Ethernet (MAC) source and destination addresses, IP addresses, transport layer protocols (TCP, UDP, ICMP), and additional fields such as VLAN tags or MPLS labels [12,24].

After a match is determined, the action field specifies how the packet should be handled. Typical actions include forwarding to a specified port, modifying headers, dropping the packet, enqueuing it for Quality of Service (QoS), or forwarding it to the SDN controller. These programmable actions allow OpenFlow switches to support advanced and adaptive traffic management [10,24].

Each flow entry includes a counter to track usage metrics such as the number of packets and bytes processed and the flow’s active duration. These counters support performance monitoring, traffic analysis, and optimization [12]. If multiple flow entries match a packet, the priority field determines which rule takes precedence. Higher-priority rules override lower-priority ones, enabling precise traffic management and conflict resolution [10]. Flow entries can expire based on their timeout values. An idle timeout removes a rule if no packets match it for a set duration, while a hard timeout removes it after a fixed period regardless of activity. Additionally, flow entries can be deleted upon session termination, helping to conserve memory and improve switch performance [12].

In addition to individual flow rules, OpenFlow also supports groups, categorized as Indirect, All, Select, and Fast-Failover. These allow switches to implement collective actions across multiple packets. Each group contains buckets, which are packet buffers with associated actions. A packet may be processed by one or more buckets depending on the group type, supporting capabilities such as load balancing and fault tolerance [10,25]. Feamster et al. [4] note that OpenFlow switches can be programmed to emulate a wide range of network functions depending on the installed rules, including routers, switches, firewalls, and NAT devices.

4.2. SDN Controller Structure

The SDN controller provides a centralized monitor and network controller through a single interface. Controller implementations operate as servers and support a visual dashboard with a user interface that displays the current topology, including hosts and switches, flow tables, and various network utility pages. Centralization also implies a target controller host machine where Application Programming Interface (API) calls that affect the network can be directed. With a dynamic data plane, it is possible to adapt the network topology as far as the physical links allow. Figure 3 shows two networks: on the left, Figure 3a shows a traditional network, while on the right, Figure 3b shows an SDN-managed network.

In a traditional network, the control and data planes are tightly integrated within network devices such as routers, firewalls, and distribution switches. At the network border, a router and firewall are installed as embedded firmware on devices, enforcing security policies and managing external traffic. Within the local network, multiple distribution switches handle traffic forwarding and network segmentation, relying on distributed control logic embedded in each device. Network policies such as routing and access control are manually configured on individual devices, leading to complex and static configurations. This decentralized control structure contrasts with SDN, where a centralized controller manages network policies and traffic flow, emphasizing programmability.

An SDN controller contains core modules commonly found in various implementations. These modules are located in the control plane. The topology manager and link detection module maintain the topology information of Network Elements (NEs). The packet streamer captures and processes packets and forwards them to various SDN applications or monitoring tools. It operates at the data plane level, typically in SDN switches, and works in conjunction with the SDN controller to facilitate real-time network visibility, analytics, and decision-making. A decision-making module determines optimal paths through the network. A storage manager stores network state information, while a flow manager module accesses the data plane through the southbound interface to update flow tables. Some SDN controllers also include a statistics collector, a queue manager, and a module manager plane to collect network statistics, manage queues, and orchestrate other modules [26].

Centralization complicates the scalability of SDN, as two controllers will compete with each other if they are managing the same switches. Bidirectional Forwarding Detection (BFD) is a protocol that can be integrated with SDN to quickly detect a failure in a path and trigger the controller to switch traffic towards a backup pathway. The BFD protocol can be used by an SDN in conjunction with OpenFlow group tables (which are used for complex packet forwarding actions) to facilitate automatic SDN network reconfiguration [27].

In the literature, a solution to SDN scalability has been proposed by separating individual SDN networks into neighboring networks [24,28]. This means that multiple SDNs would be used for inter-networking. While this is reminiscent of the distributed controller model in traditional networking routers, it is important to remember that a single controller could still manage a larger number of devices. Connecting multiple SDNs across wider networks could take the form of a hierarchy of SDN controllers or an equally shared plane of controllers. SDN controller scalability has been addressed in great detail in the work by [26], which considers many implementations of network control. To connect different controllers of neighboring networks, the eastbound and westbound interfaces of a controller are engaged; however, there is no unifying standard for these interfaces. An extensive survey of eastbound and westbound APIs can be found in [29].

A link between adjacent network controllers is only required if routing must be coordinated across at least two separate SDNs. If this level of coordination is not required, then there may only need to be a link between switches, as shown in Figure 3b. A large topology would require many controllers to distribute the computational load appropriately. Generally speaking, the scalability bottleneck for SDNs is the control plane.

Proposed solutions to controller scalability include controller contracting through a pool of available controllers, delegating more functions to the data plane, and controller relocation [24]. One optimization used in SDN controllers is called proactive mode, which creates flow rules before traffic is ingested into the network. An example of such proactive mode optimization is the modification of flow tables to initialize with flow rules before traffic begins, thereby reducing controller–switch communication.

Another optimization approach is Network Function Virtualization (NFV). Network functions are used in a network to provide services that can involve inspecting packets, analyzing and routing traffic to reduce congestion, and managing the load that reaches destination servers. Examples from these categories include firewalls, video transcoding, DNS caching, session border controllers, ad insertion, and header enrichment [30]. These technologies exist as part of a service chain that packets may traverse through a network. At times, a service may be idle for long periods. With NFV, a video transcoder server can later become a VPN gateway. Virtualizing services on demand to meet the network’s needs can optimize resource usage, reduce server idle time, and improve overall network performance.

Backup controllers can be used to increase SDN reliability and availability. Some SDN controller implementations support this as part of a high-availability module. Before the network is started, properties are declared that enable multiple controller hosts to communicate. This allows the controllers to elect a leader upon startup and then update state information between the leader and followers during network operations. A generic model for the scalability and reliability of SDNs utilizes westbound and eastbound APIs to orchestrate between controllers, as simplified in Figure 4. Three non-overlapping SDNs are connected with inter-SDN communication protocols for inter-network coordination. Connections between the data planes are established by switch links, and each network domain has multiple controllers to ensure high availability to the switches.

4.3. Hardware Limitations, Development Platforms, and Related Technologies

Although virtual switch technology such as Open vSwitch can perform flow entry installations at a rate of tens of thousands per second, the rate of hardware flow entry writing is much slower. Flow rule writing rates on hardware switches are limited to a few thousand flows per second written to flow tables. This limitation is due to the scarcity of resources on a typical switch, which lacks support for high-frequency communication between the controller CPU and the switch chipset. This forwarding table update latency is a primary source of latency on the data plane. However, it is expected that switches will eventually overcome this hardware limitation [28].

To increase the processing power of the controller, the work in [8] introduced a heterogeneous-computing-based controller that uses the CPU for managing flow rule creation and a Graphics Processing Unit (GPU) and Field-Programmable Gate Array (FPGA) for accelerating machine learning-based cybersecurity. The GPU and FPGA are used in parallel processes for prevention of Distributed DoS (DDoS) attacks by implementing both signature-based and anomaly-based identification of distributed DoS attacks. As part of the controller, these additional processors significantly accelerate computing speed; for instance, in [8] the authors reported that ANN training was 14 times faster on GPU than on CPU.

A development platform for SDN can be created using a network emulator to develop, test, and prototype SDN applications and architectures. Such a system emulates a large network of hosts, switches, and links on a single machine, providing a test environment for developers to experiment with SDN controllers and applications. By integrating with SDN controllers such as OpenDaylight (ODL) or Floodlight, developers can dynamically deploy and manage network topologies, test new routing algorithms, and implement innovative network policies. The platform can be enhanced with additional modules for traffic generation, network monitoring, and performance analysis, enabling comprehensive testing and evaluation of SDN solutions. This development platform facilitates rapid iteration and validation of SDN concepts, reduces the need for expensive physical hardware, and accelerates the development of scalable, flexible, and efficient network infrastructures. By providing a controlled, reproducible, and versatile environment, such platforms can significantly contribute to advancing research on and deployment of SDN technologies [10,31]. In the following Section 5, different aspects of SDN security issues and vulnerabilities are introduced and specific suggestions for securing an SDN controller are presented.

5. Securing SDNs Against Known Threats

Although SDNs provide numerous benefits in network management and control, they also introduce several security concerns that must be addressed. This section examines various vulnerabilities in SDNs as well as mitigation strategies to enhance network security.

Opinions differ on whether SDNs improve security or create new attack vectors that increase network exposure. Some argue that security risks associated with SDNs are manageable and that SDNs can even enhance network protection [32]. For example, in the case of a DoS attack, SDNs provide a global view of the network, enabling the collection and analysis of traffic statistics. This visibility allows for the rapid identification of compromised network elements, facilitating a faster defensive response compared to traditional networks. In a traditional network (Figure 3a), network monitoring is frequently located near the edge of the network near the firewall.

However, critics of SDNs contend that SDN architectures are too complex and difficult to secure effectively [32]. Flow rules governing network traffic must be configured for all network devices, including routers and switches. In large-scale deployments, the sheer volume of flow rules can introduce rule conflicts and unanticipated traffic behavior, thereby creating security vulnerabilities. Furthermore, the SDN control plane dynamically adjusts flow rules in response to network conditions, making it challenging to differentiate between legitimate modifications and malicious alterations. This dynamic nature increases the risk of control plane attacks, as the SDN controller centrally manages all flow rules and network devices [5,32].

In contrast, traditional networks distribute control functionality across individual network devices, requiring attackers to compromise multiple isolated control planes to gain full access. In SDNs, compromising the centralized control plane grants an attacker control over the entire network. Despite this risk, the centralized architecture of SDNs enables the enforcement of uniform security policies across the entire network, ensuring consistent security implementation [33].

The consequences of these threats extend beyond security breaches and directly affect the scalability and performance of SDN architectures. For example, a control plane DoS attack not only disrupts communication between the controller and switches but also saturates the controller’s processing capacity, limiting its ability to respond to legitimate traffic demands [34,35]. Gupta et al. reported that during a simulated DDoS, the RYU controller experienced a 38% increase in packet loss and a 25% drop in throughput, while ODL saw a 40% rise in latency under load [35]. Similarly, Zhu et al. found that when controllers handled over 500 flow setups per second, CPU utilization exceeded 90% and latency increased by up to 60% in burst conditions [36]. This performance degradation shows that SDN threats are not only functional risks but also introduce scalability bottlenecks. Additionally, frequent rule updates in dynamic or reactive SDN defenses further stress controller-switch communication, especially under high-volume attack scenarios. These findings underscore the importance of designing lightweight, adaptive, and resource-aware SDN security mechanisms to ensure that defense strategies scale effectively alongside the network.

5.1. Data Security

As with traditional networks, there are certain processes to be considered when it comes to upholding the confidentiality, integrity, and availability (CIA) of an SDN as well as ensuring its proper performance. First among these are authentication and authorization, that is to say, making sure that only properly authenticated users are able to gain access to the various SDN components and limiting those users’ rights and privileges to the absolute minimum necessary for their needs [24,37]. Furthermore, any traffic through the network must be properly authenticated in order to prevent fraudulent data from passing through. The authentication and authorization methods employed in an SDN must be granular enough to limit the consequences of incidents such as stolen credentials or identity hijacking. An example of a potential consequence would be an unauthorized user modifying flow rules to forward traffic to locations where it is not supposed to go or to block legitimate traffic. A possible technique to ensure proper authentication and authorization of users would be to implement proper role-based access controls that grant users no more privileges than they need. For network traffic, encryption protocols such as Transport-Layer Security (TLS) and Internet Protocol Security (IPsec) can be used to maintain the integrity of the data passing through the network [37].

5.2. Resiliency Techniques

Resiliency is a critical aspect of network security, ensuring that the network can recover from interruptions, attacks, or component failures with minimal manual intervention [24,37]. When disruptions occur, the network should either restore functionality autonomously or adapt to maintain operations despite the affected components. In an SDN, where network control is centralized, a successful attack on the control plane, for instance a DoS or Distributed DoS attack, can significantly impact network operability and, by extension, business continuity. This concern is particularly crucial in cloud-based network services, where customers expect high availability and minimal downtime.

One approach to improving SDN resilience against DoS/DDoS attacks is to limit the bandwidth and resource consumption of network elements to the minimum required for proper functionality [37]. By preventing compromised elements from monopolizing resources, the network can maintain near-optimal performance. Another technique to improve resiliency is dynamic routing, which allows network traffic to be immediately redirected through alternate routers in the event of a router failure or compromise. Additionally, redundancy plays a vital role in improving network resilience. Given the potential for hardware or software failures, Version 1.2 and later versions of the OpenFlow protocol include a primary–secondary controller configuration, ensuring that backup controllers can take over if the primary controller fails [24].

In addition to these strategies, other essential resiliency mechanisms include multi-domain isolation and repudiation [37]. Multi-domain isolation ensures proper separation of resources and traffic between tenants, preventing one tenant from inadvertently or maliciously interfering with another’s network traffic or resource usage. Such interference may arise from a misconfigured controller application with excessive privileges or an attack on one tenant’s network that propagates due to the shared infrastructure. Meanwhile, repudiation involves maintaining detailed logs of all actions performed by system actors, including tenants and administrators. These logs facilitate the identification of suspicious behavior and support forensic analysis in the event of a security breach. While understanding resiliency techniques is crucial for maintaining SDN security, identifying and mitigating potential attack vectors is equally important for ensuring robust network protection.

5.3. SDN Secure Architecture

In order to better examine the issues concerning SDN security, the overall architecture of an SDN must first be examined. A simplified example of a hierarchical SDN deployment is considered, as shown in the lower part of Figure 5. This architecture typically involves an infrastructure provider who leases network resources to tenants. In cloud computing, for instance, companies provide cloud services, and their clients, referred to here as tenants, utilize virtual networks established within the provider’s SDN. These tenants can provide configuration and policy information to their virtual networks through network applications [24]. These applications are used to send commands to the controller in order to dynamically configure the network. This enables tenants to customize the network with specific flow rules, which the controller then propagates to the routers and switches. However, utilizing applications to send commands to the controller introduces a new potential avenue for launching attacks or compromising the network [24,37]. This is because software is rarely fully secure; the presence of bugs or other vulnerabilities within the applications can be exploited, creating vulnerabilities within the SDN due to the interconnectedness of the applications and the network.

After the application plane comes the control plane, which is responsible for sending forwarding rules (flow rules) to the network elements; Figure 3b can be referred to here. Applications on this plane send instructions to the controller with rule entry definitions. This mechanism provides a centralized view and means of controlling the network, which also creates a valuable attack target [32,37]. By compromising this plane, an attacker could have free rein over the SDN. The control plane communicates with the Network Elements (NEs), which reside in the data plane. These NEs are the routers, switches, servers, and so forth, which make up the network. The last of the planes is the management plane, which deals with device administration. This comes in the form of updates, patches, or physical device management as well as other administrative tasks performed by various management modules or administrators. Communication exists between all the planes, which leaves open the possibility of compromising the entire network by successfully compromising one portion of it [24,37]. It also means that an attack that affects one plane could potentially affect the others above and below it. This is why it is of utmost importance to implement proper isolation techniques, as mentioned earlier, such that communication between planes is kept to a necessary minimum and that any attacks on one will have minimal effects on the others. In the following sections, some examples of threats to each portion of the architecture are highlighted along with possible measures for mitigating these threats.

5.3.1. SDN Security: Control Plane

Rootkits are yet another concern for the control plane. Rootkits such as the ODL rootkit can provide remote control access to an attacker. This allows the attacker to create fraudulent flow rules to block or redirect legitimate traffic while allowing malicious traffic to flow through. In addition, rootkits can hide these changes from the controller, making the network appear to be operating correctly from the controller’s viewpoint when the reality is quite different [24]. Various prevention methods have been proposed to protect against rootkits; one such method is called SDN-Guard.

SDN-Guard is a proposed tool implemented in research to protect SDNs against rootkit attacks that aim to gain control of the SDN flow rules and obscure the fact that the attacker is modifying the network. SDNs have been found to be vulnerable to rootkit attacks [32,38]. These rootkits base their functionality on a support mechanism in the Java programming language for runtime modification of code. The mechanism is known as reflection. By leveraging Java reflection, the rootkit can inspect objects, create objects, and invoke call methods. This feature of the language facilitates malicious control acquisition of SDNs along with a cover-up mechanism that disguises maliciously created flow rules.

Figure 6 shows a general overview of the functionality of SDN-Guard. The approach SDN-Guard takes to counter this attack is to create a dual view of the network; by comparing these views, it detects malicious flow rules. Using this approach, one of the deadlier aspects of the planned attack—the obfuscation of changed flow rules—becomes a feature that enables the dual-view comparison to detect such attacks. In this way, SDN-Guard leverages the flexibility of SDNs and the attacker’s design to defeat the attack. The control plane connector adjusts the coupling for different SDN controllers. The proxy unit then forwards flow rule modifications to the decision unit, which detects malicious flow modification commands. The decision unit compares the network’s actual state as observed from the flow modification messages with the controller’s perceived network state obtained via the controller’s northbound interface. By identifying discrepancies between these two views, the decision unit can detect unauthorized changes to flow rules. Operating independently of the SDN controller, SDN-Guard protects the network from a compromised host or SDN controller.

5.3.2. SDN Security: Data Plane

The data plane forms the lower layer of the SDN architecture and comprises the underlying network infrastructure, including switches, routers, and servers. Although the data plane operates independently of the control plane, consistent with the SDN paradigm, communication between the two layers remains essential. This interaction introduces potential vulnerabilities that make the data plane particularly susceptibility to DoS attacks. Effective countermeasures include robust resource isolation and mechanisms that enhance network resilience, such as dynamic routing and redundancy [24,32,37]. Section 7 provides a detailed examination of DoS scenarios.

In addition to DoS threats, the data plane is exposed to risks such as unauthorized rule insertion or modification [24,37]. Similar to rootkit threats at the control layer, adversaries may manipulate flow entries to enable malicious traffic while suppressing or redirecting legitimate data. Furthermore, the optional use of TLS in OpenFlow creates an avenue for MITM attacks, which can compromise data confidentiality and integrity [24]. To mitigate these risks, administrators must enforce encryption standards and configure SDN systems to utilize secure protocols.

Additional risks in the data plane stem from flow rule conflicts and misconfigurations. Because data plane elements depend on the controller to receive flow instructions, any errors or policy conflicts may result in service disruption, data loss, or operational failure.

A specific DoS vector arises when packets with undefined flows are injected into the network at a high rate, triggering excessive communication between switches and the controller’s southbound interface. This saturation increases controller processing load and reduces available bandwidth for legitimate traffic [24,32,39]. Mitigation techniques include applying rate-limiting policies and dropping traffic based on volume. Additionally, anomaly detection via flow statistics can be leveraged by the flow manager module to identify and neutralize suspicious traffic patterns.

5.4. SDN Security: Application Plane

The application plane of the SDN architecture deals with infrastructure management, physical device management, and platform management issues (firmware and software upgrades). Essentially, this plane deals with the overall administration of the SDN; thus, security on this plane is critically important. A major concern for this specific plane is administrator impersonation. Should an attacker successfully impersonate an administrator, they could push through harmful updates, which could further compromise the entire SDN, leaving it open to even worse attacks [37]. Because this plane also deals with the physical devices comprising the SDN, an impersonator could physically sabotage the servers, routers, switches, and other NEs that comprise the network; this would in turn result in loss of functionality of the network. Much as with tenants, proper authentication can help to mitigate the threat of administrator impersonation, as can strict policies concerning access to and maintenance of the infrastructure and physical devices of the network.

The application plane has interfaces for the applications and APIs used to program the network; these may be independent and owned by different tenants.

Table 1. SDN applications.

Application Area	Description	Key Techniques Used	Refs.
Traffic Classification	ML algorithms are applied to classify traffic, including encrypted traffic, improving resource allocation and network management.	Supervised learning, SVM, Decision Trees, Neural Networks	[18,19,20,40,41,42,43]
Traffic Engineering	ML techniques predict traffic patterns, optimize routing, balance loads, and reduce congestion for efficient network management.	Predictive analytics, optimization algorithms	[10,44,45,46,47,48]
Anomaly Detection	Real-time detection of network intrusions and anomalies to enhance SDN security and mitigate potential threats.	Anomaly detection algorithms, statistical analysis, ML	[10,11,34,47,49,50,51,52]
Resource Management	ML-based predictions of resource demands enable dynamic and efficient allocation of network resources, enhancing performance and scalability.	Demand forecasting, resource optimization	[12]
Fault Detection	Identification and diagnosis of network faults improve network resiliency and reliability.	Diagnostic algorithms, ML, network monitoring	[13,14,52,53,54]

lists the types of network applications that can operate in the application plane. These applications may be used by tenants to configure the controller and the flow rules that it provides to the NEs; however, there are potential issues of coherency conflicts between applications, that is to say, rules or configurations set by two different applications can conflict with each other, causing problems with the traffic flow in the network. As with any software application, bugs and vulnerabilities can be present in its code which may subsequently result in vulnerabilities in the SDN. These can include cases where the application obtains elevated privileges to perform configurations beyond its intended scope [24].

Securing the NBI: The NBI is not secure by default in many SDN controllers. For instance, the Floodlight controller lacks built-in security for its Representational State Transfer (REST) NBI; similarly, Open Network Operating System (ONOS), Ryu, and Python-based OpenFlow controller (POX) also have unsecured NBI implementations. In contrast, the ODL SDN controller has basic authentication on its REST NBI. This authentication involves sending a username and password with each request, which is not ideal; a better solution is token-based authentication [24,55]. While ODL by default supports only basic authentication, it also includes mechanisms for token-based security integration. Thus, while improvements are still necessary in default configurations, ODL has the potential for more advanced security setups, including encrypted TLS sessions and token-based access controls, which should be leveraged in production deployments. For most controllers, Advanced Encryption Standard (AES)-encrypted TLS sessions need to be implemented by modification of existing controllers to secure their NBIs.

5.5. Implementation of SDN Controllers and Common Challenges

In the following, we look at three popular controllers: Floodlight, ODL, and Ryu.

5.5.1. Floodlight Controller Implementation Steps

1.

Install Java and Maven: Floodlight is a Java-based controller, so installing JDK (Java Development Kit) and Maven (build automation tool) is essential.

2.

Clone Floodlight Repository: Fetch the source code from the official GitHub, Floodlight version 1.2.

3.

Build the Controller: Use Maven to build Floodlight.

4.

Configure Floodlight: Modify the configuration file to define the network topology, including the switch and host details.

5.

Run Floodlight: Start the Floodlight controller using the Java command line or through Maven.

6.

Integrate with switches: Connect the Floodlight controller to the test environment, either emulation or actual switches.

5.5.2. ODL Implementation Steps

1.

Install Java: Like Floodlight, ODL is a Java-based controller requiring JDK.

2.

Download ODL Distribution: Obtain the ODL version 0.21.2 distribution from its official website or GitHub.

3.

Start ODL using the Karaf shell.

4.

Install Required Features: Use the Karaf console to install desired ODL features like odl-l2switch-switch for basic network operations.

5.

Integrate with switches: Set up an emulation environment or connect existing switches to ODL to control the network.

6.

REST API and Configuration: ODL provides REST APIs for interaction and configuration, which allow users to control and program the network dynamically [35].

5.5.3. Ryu Implementation Steps

1.

Install Python: Ryu is a Python-based OpenFlow controller; install the programming language on the controller system.

2.

Install Ryu version 4.34: With the Python pip tool install Ryu, accessed 2 July 2025 by running the command pip install ryu.

3.

Verify Installation: Of Ryu by the command ryu-manager–version.

4.

Create a Controller: Create a Ryu controller script in Python, utilizing the Ryu API to control and manage the OpenFlow switches.

5.

Run the Controller: Start your Ryu controller by executing

ryu-manager <controller-script.py> from the command line.

6.

Integrate with Mininet: Launch a Mininet topology and set Ryu as the controller by using the –controller=remote option and specifying the Ryu controller’s IP and port.

7.

Use Ryu REST API: Ryu provides a REST API for monitoring and managing the network, allowing dynamic network control and configuration.

Table 2. Some currently-implemented SDN controllers are listed in the table. OS-Ken is a SDN controller development that supersedes Ryu, and is still maintained; ODL is also actively maintained as of this writing.

Controller	Supporting Organization	Source Code Updates in Past Year
ODL 1	LF Networking	Yes
Floodlight 2	Community support	No
ONOS 3	Linux Foundation	No
Trema 4	Community support	No
Ryu/OS-Ken 5	Fortinet/Openstack	Yes
NOX/POX 6	Community support	No

¹ OpenDaylight: available at https://www.opendaylight.org/ (accessed on 2 July 2024). ² Project Floodlight: available at https://floodlight.atlassian.net/wiki/spaces/floodlightcontroller/overview (accessed on 2 July 2024). ³ ONOS: available at https://opennetworking.org/onos/ (accessed on 2 July 2024). ⁴ Trema: available at https://trema.github.io/virtual-network-platform/README.html (accessed on 2 July 2024). ⁵ Ryu: available at https://ryu-sdn.org/ (accessed on 2 July 2024). ⁶ NOX: https://github.com/noxrepo/nox; POX: https://github.com/noxrepo/pox (accessed on 2 July 2024).

lists some main SDN controller implementations in open-source code; ODL is the only controller actively being publicly updated as of this writing.

5.6. Implementation Challenges and Controller Comparison

Implementing and evaluating SDN controllers in a testbed environment presents a number of practical challenges, particularly regarding deployment complexity, software compatibility, and performance under load. As described in the documentation, controllers implemented directly from source code require careful management of software dependencies, often across different versions of Python, Java, or other frameworks. Many controllers require specific runtime environments or packages, and inconsistencies between system configurations have been noted to lead to deployment delays and increased debugging efforts. For instance, due to its modular and extensible architecture, ODL is reported to introduce added complexity during setup, particularly in resource-constrained virtual environments. In contrast, Ryu’s lightweight design is documented to enable a smoother installation process, making it better suited for experimental ML integration and educational purposes.

Controller interoperability with network hardware is also a major concern. OpenFlow version mismatches and inconsistent support across switch models are known to create compatibility issues. In cases where switches only partially support OpenFlow, limited functionality or fallback behavior must be accounted for. Reported stability issues under high load include scenarios in which controllers become unresponsive when managing numerous concurrent flow entries or frequent flow updates, exposing potential bottlenecks in control plane performance. These concerns underscore the importance of benchmarking latency, throughput, and failover resilience in simulated large-scale networks, as shown in [36].

Security is another critical dimension where controller behavior diverges significantly. Each controller exhibits unique vulnerabilities and protocol support, which necessitate individualized configurations to secure controller interfaces (e.g., REST APIs, OpenFlow channels). These concerns are discussed in more detail in Section 5. To mitigate such risks, recommendations in the literature include implementing access control rules and isolating control-plane traffic wherever possible.

To systematically evaluate these controllers, Floodlight, ODL, and Ryu are compared across several categories, including latency, security features, encryption support, and implementation effort, summarized in

Table 3. Comparative ranking of SDN controllers.

Controller	Latency	Secure Controller Interfaces	Encryption	Controller Features	Testbed Environment	Reliability
Floodlight	2	2	2	2	2	2
ODL	1	1	1	1	3	1
Ryu	3	3	3	3	1	3

. Rankings (1 = best, 2 = second best, 3 = last) reflect practical tradeoffs drawn from existing benchmarks and documentation. For example, while ODL ranks highest in terms of security and reliability [25], it is the most resource-intensive and is reported to require the longest setup time. Ryu scores highest for ease of deployment and integration with ML libraries [9,56], but its limited built-in security mechanisms reduce its suitability for multi-tenant or high-assurance environments [35]. Floodlight falls between the two, offering a balance of functionality and deployability [25].

5.7. Network Sharing by Tenants

As mentioned before, SDNs allow for the same physical network to be shared among several tenants. Each tenant has access to their own virtual networks, which share the same physical infrastructure. This setup allows for better overall network resource utilization; however, the shared structure introduces the potential issue of interference between tenants, whether accidental or intentional. Such interference can be mitigated by properly isolating tenant traffic and resources to prevent tenants from tampering with each other’s configurations [37].

Another security concern in this context is tenant impersonation. Given the architectural design of SDNs, a successful impersonation could grant an attacker control over a tenant’s virtual network, or in some cases the entire infrastructure. Implementing robust user authentication mechanisms is essential to preventing such breaches. Additionally, abuse of APIs or SDN applications remains a risk; tenants with misconfigured or malicious applications can alter traffic flows in a way that impacts others, again underscoring the importance of strong isolation techniques and access controls [24,37].

There are many considerations to securing SDN controllers, and the security of the controller API is of high importance. Redundancy of the controller server may help to securely scale an SDN, and specialized systems such as SDN-Guard can provide security against the malicious alteration of flow rules. In the following Section 6, a collection of ML functions designed for SDNs is presented.

6. ML Applied to Network Functions in SDNs

ML is uniquely applicable to SDNs, as an ML algorithm has access to the complete network topology through the controller and can be deployed in the application layer to have effects on routing, traffic classification, and anomaly detection, among others. Routing in an SDN is determined by the SDN controller software that is running a network topology model in fast random-access memory. The SDN controller computes routing paths, spanning trees, etc., using centralized algorithms. The centralized control approach of SDN facilitates traffic engineering and bandwidth management. The programmable interface of the controller enables it to change traffic behavior dynamically and at the request of the network management. Services such as load balances, changes, and policy enforcement can be installed on the network dynamically. Traditional dynamic routing handles congestion by periodically monitoring data flow status, but struggles with determining the optimal monitoring period and cannot learn from past routing decisions to avoid ineffective routes. Traffic engineering is another aspect of SDN functionality. The benefit of ML-based approaches is that they can recognize traffic and encrypted traffic with much lower computational cost than other approaches [47,57].

6.1. ML-Driven Routing in SDNs

In traditional routing, there are challenges for network security management around maintaining control and visibility in the environment. This is largely due to the wide distribution of control and visibility access in traditional routing. SDN-based routing can address these challenges by providing centralized control and visibility. The SDN architecture encourages link-state routing algorithms, as the full network topology is abstracted in the memory of the controller and available to routing applications. Access to the network state in the application layer that facilitates ML-based applications is shown in Figure 3b. In

Table 4. Comparison of SDN ML algorithms vs. traditional routing

Algorithm	Latency	Throughput, Advantages and Limitations
TBPPO [59]	Reduction of average delay by 20% and 50% reduction in variation	Throughput: N/A Advantages: Reduced latency, better load balancing Disadvantages: Increased complexity
ANN [58]	10% lower latency compared to OSPF	Throughput: 15% increase over BGP Advantages: Faster decision-making Disadvantages: Requires large datasets
Q-Learning [60]	Reduced average packet loss by 30%	Throughput: Multi-path routing reduced individual path throughput Advantages: Improved routing efficiency Disadvantages: Higher computational overhead
Deep Q- Networks [61]	N/A	Throughput: 14.13% improvement in moderate traffic, 20.29% in heavy traffic Advantages: Improved throughput Disadvantages: Higher computational overhead
Genetic Algorithm [62]	Comparable latency to traditional methods	Throughput: 24.72% increase in throughput Advantages: Better resource optimization Disadvantages: Longer convergence time
ACO [63]	Reduced packet loss 0.38%	Throughput: Higher throughput by 12% Advantages: Real-time decision making Disadvantages: Increased training complexity
Reinforcement Learning [64]	63% lower latency over OSPF	Throughput: N/A Advantages: High routing accuracy Disadvantages: High memory requirements
Reinforcement Learning [65]	22% lower latency than traditional methods	Throughput: 8% improved throughput Advantages: Adaptive to dynamic changes Disadvantages: Convergence issues
Genetic Algorithm [66]	N/A	Throughput: Improves throughput by approximately 10% over the BGP Advantages: Scalable Disadvantages: High computational cost
Multi-agent Reinforcement Learning [67]	N/A	Throughput: Improved the network performance up to 41.21% compared to OSPF by utilizing more paths in the network Advantages: Adaptability to fluctuating traffic demands Disadvantages: Higher memory and computing overhead

, a comparison of various ML-based algorithms is listed by throughput, latency, and the advantages and disadvantages of each algorithm. In [58], an Artificial Neural Network (ANN)-based application for SDN routing was developed. This application, installed on the SDN application plane, receives input from the SDN’s statistics collector module and link detection module. The ANN is trained to reconfigure routing paths through the SDN based on minimizing congestion. If the congestion probability is found to be lower while sending packets through another path, the ANN outputs this reconfiguration. The controller is then responsible for forwarding the updated rules through the southbound interface to the OpenFlow switches in the data plane. The application was tested in emulation. The average throughput, packet loss ratio, and packet delay across various data rates and monitoring periods were validated, demonstrating that the approach outperformed traditional routing, resulting in a 19.3% reduction in latency [58].

Supervised learning, unsupervised learning, and reinforcement learning, all of which are ML approaches, have been examined as potential candidates for the routing process of a controller. For instance, the authors of [56] concluded that deep reinforcement learning is the most promising area for ML-based routing in SDN. A generalized algorithm for the use of ML-based routing in an SDN application is provided in Algorithm 1. In this algorithm, the ML model is already trained to detect and assign the best routes through the network. Within this context, $pat{h}_x$ refers to one of the candidate optimal routes identified by the trained ML model. In the generalized algorithm, a lower path rating represents a more optimal route through the network. Reinforcement Learning (RL) is an ML paradigm in which an agent learns through interaction to maximize cumulative reward. An action is a decision made by the agent at a given state. The reward is a scalar feedback signal from the environment indicating the value of an action. Convergence criteria define when the learning process is complete, and are often based on performance stability. The convergence criteria (as seen in Algorithm 2) are specific values, for instance reward improvement or network metrics. An episode is a complete sequence of agent-environment interactions from start to end. The work in [60] implemented a reinforcement learning-based agent to optimize routes. The agent considers the available link bandwidth, delay, and loss ratio in its processing of the reward function. Specifically, the reward is inversely proportional to the available link bandwidth and directly proportional to the link delay. The authors concluded that Dijkstra’s algorithm, while it converged faster, was not significantly better, and that the agent produced a larger number of shorter paths, which led to lower mean delay and loss values. In [60], a generalized RL-based routing algorithm was synthesized, which is presented in Algorithm 2. The focus of Algorithm 2 is to train the RL agent in the task of best path selection.

Algorithm 1 Generalized ML-based Routing Path Selection Algorithm

1: Update path threshold is $\delta$ 2: Current path is $pat{h}_{cur}$ 3: Load a pre-trained ML model to select best path 4: Collect current network data: latency, traffic loads, path configurations, etc. 5: while network traffic conditions change do 6:       Input network statistics to the ML model 7:       collect output best path configurations 8:       for $pat{h}_x\in$ best paths do 9:             if $pat{h}_{cur}.rating-pat{h}_x.rating>\delta$ then 10:                Update the flow tables with $pat{h}_x$ 11:             end if 12:       end for 13: end while

Algorithm 2 Generalized RL-Based Routing Training Algorithm

1: Initialize the RL agent with an initial policy and environment 2: Initialize the convergence criteria 3: while not converged do 4:       for each episode do Collect state representation of the network 5:             Agent Action (Path selection, packet forwarding strategies, etc.,) 6:             Calculate the reward based on the network state 7:             Update agent’s policy using the reward and observed state 8:       end for 9: end while

6.2. Wireless Sensor Network Optimization

To implement a wireless sensor network, a network planning and resource management strategy must be considered. The considerations in network planning are sensor placement, location optimization, and the design of a minimized deployment that meets the network’s needs. Resource management considerations include energy consumption minimization, data transmission bandwidth flexibility, and energy buffer/thresholds.

In [68], the authors studied two wireless network coverage optimization algorithms based on Voronoi diagrams to reduce energy consumption in Software-Defined Sensor Networks (SDSNs). The first algorithm, called the Minimax Radius Algorithm (MRA), aims to reduce the sensing radius of each node to just cover the farthest vertex of its Voronoi polygon. The second, named the Sleeping-based Algorithm (SLA), determines which nodes can be put into sleep mode by verifying whether their Voronoi polygons are covered by their neighbors, thereby preserving the network’s original coverage while maximizing the number of sleeping nodes. Simulation results demonstrated that both algorithms can significantly reduce energy consumption, with the reduction rate increasing as the sensing radii and number of nodes increase. The study emphasizes that these methods are effective at optimizing energy usage in SDSNs, providing a means to extend the operational lifetime of these networks [68]. As shown in Figure 7a, the total energy saved in the simulation of the wireless network increased as the distance between nodes increased, reaching over 20% at larger distances. In [69], the authors investigated issue of optimal placement of SDN controllers in wireless networks. The optimization aimed to reduce the overall latency of the communication between nodes and the controllers by creating separate sub-networks with centrally located controllers. The physical locations of the controllers, shown in Figure 7b, was optimized using k-means clustering.

6.3. Traffic Engineering

Traffic classification plays a crucial role in network management by enabling precise control over different types of traffic flows. Through effective traffic classification, network operators can manage various services and allocate resources more efficiently. Common traffic classification methods include port-based techniques, Deep Packet Inspection (DPI), and ML-based approaches. The port-based method identifies applications by examining TCP and UDP port numbers. While it was effective when many applications used well-known ports, such as TCP port 80 for HTTP, the current trend of most applications using dynamic ports has rendered this approach less effective [47].

DPI works by matching the payload of traffic flows against predefined patterns, often using regular expressions, in order to identify those applications that are generating traffic. Although DPI can achieve high classification accuracy, it has several drawbacks. First, it can only identify applications with known patterns, and it is challenging to update the detectable patterns due to the rapid increase in the number of online applications. Second, DPI involves high computational costs, as every traffic flow must be inspected. Lastly, DPI cannot classify encrypted traffic, which is increasingly prevalent on the internet [47].

ML-based approaches can effectively identify encrypted traffic while requiring significantly less computational power compared to DPI-based methods. As a result, ML-based techniques have been widely researched and applied. These approaches involve the collection of a large volume of traffic flows, followed by the application of ML algorithms to extract insights from the collected data. In the SDN context, the controller’s network view simplifies the collection and analysis of traffic data, making it an ideal location for implementing ML-based methods. Numerous studies have explored traffic classification from various angles, including extremely large traffic flow-aware, application-aware, and QoS-aware classification [47].

6.4. Anomaly Detection

Malicious network activity is a common occurrence, especially in large targeted networks. Many factors drive networks to receive malicious network activity, such as data theft or disruption of online systems. These malicious activities include DoS, intrusion, MITM, and ransomware attacks [70,71,72]. One active defensive measure that organizations take is to monitor network traffic and detect anomalies. An SDN controller is a target for malicious activity and is highly sensitive to DoS. When a new packet is received by the data plane without an existing flow entry, it is encapsulated in a ‘packet_in’ message and sent to the controller for a decision. The absence of a source traffic validation mechanism in default SDN controllers allows malicious traffic to exploit this functionality and overwhelm the controller. TCP-Synchronize (SYN) is used in the transport layer to initiate secure encrypted data transmission between two hosts. Because it requires a response from the server, the TCP-SYN interaction behavior appears in some DoS attacks.

Techniques have been developed to detect and mitigate malicious TCP-SYN traffic by validating the source IPs and port numbers. Various DoS attack models, such as those requiring a high level of new flow rule creation, reduce the controller’s reliability and availability due to an influx of ‘packet_in’ messages. To overcome the challenge of DoS, a number of similar anomaly detection methods have been developed [7,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89]. These models utilize port mirroring to send incoming traffic to a detection module, leveraging ML-based classification in the detection module, which is designed to distinguish between malicious and genuine source IPs [90]. A general representation of this is shown in Figure 8b. The models used in these works include Random Forest, Support Vector Machine, k-Nearest Neighbors, Naive Bayes, Logistic Regression, and model output combinations with ensemble voting algorithm classifiers. In these studies, the models were trained on environment-specific datasets that were either experimentally created or obtained from open-source datasets. In either case, the datasets were composed of captured packet traffic flows in the network where the flows represented DoS attacks or other malicious activity.

Recent works have explored more advanced ML approaches such as Generative Adversarial Networks (GANs) for anomaly detection in SDNs. GAN-based methods enhance detection accuracy by learning the distribution of normal network behavior and identifying deviations that signify malicious activity. In [91], a GAN framework was used to detect stealthy attacks and rare anomalies with improved sensitivity compared to traditional classifiers. The GAN approach is particularly useful for imbalanced datasets where genuine traffic dominates, as the generator creates synthetic anomalies that help the discriminator to improve its detection ability over time. These methods show promise for future SDN deployments where attack patterns evolve rapidly and labeled data is scarce. Other recent approaches have applied Temporal-Convolutional Networks (TCNs) to model the sequential nature of network traffic and detect subtle anomalies over time [77].

Recent work in Industrial Control System (ICS) networks has highlighted the critical challenge of anomaly detection in the presence of imbalanced and multi-class datasets. For instance, the ICS-IDS framework proposed in [92] combines normalization, Fisher discriminant analysis, and k-nearest neighbor techniques to preprocess data and improve multi-class detection in SCADA-based intrusion detection systems. Other studies have combined convolutional and recurrent layers to build hybrid ML models capable of identifying stealthy scan behaviors in early stages [87]. In [70,71], DoS attacks were detected quickly based on features extracted from the network state in the control layer. The authors were able to extract up to 57 features from the network state, and implemented a Gaussian mixture model to successfully detect DoS attacks with 98% accuracy and a false negative rate below 0.5%. Some percentage accuracy results for anomaly detection in SDNs obtained with ML are shown in Figure 8a. The following Section 7 presents an experimental setup and case study implementing an SDN controller and evaluating its capability to block both MITM and DoS attacks.

6.5. Tradeoffs and Scalability of ML in SDN Environments

While ML techniques offer significant improvements in routing accuracy, traffic classification, and anomaly detection within SDN environments, their integration introduces tradeoffs that must be carefully considered, especially in large-scale deployments. High-performing algorithms such as Deep Q-Networks and Multi-Agent Reinforcement Learning have demonstrated throughput improvements exceeding 20–40% in controlled environments [61,67]; however, these gains often come at the cost of increased memory consumption and longer training times. For example, reinforcement learning methods typically require high-dimensional state representations and sustained interaction with the environment, which can lead to elevated controller CPU utilization and latency when deployed in production. Additionally, as network size and complexity grow, the scalability of ML models can become a bottleneck. A study by Casas et al. [60] observed that while RL agents reduced packet loss by 30%, they incurred higher overhead due to continual model updates. In edge environments or resource-constrained SDN deployments, these computational costs can limit real-time applicability. Therefore, careful analysis of the tradeoff between ML model complexity and controller responsiveness is essential for sustainable and scalable integration of intelligent functions into SDN.

7. Experimental Setup of CELT-Secure Switch on Ryu SDN Controller

This section describes a secure switch implemented on an SDN controller for specific use cases involving the remote administration of a local area network with peer-to-peer interaction and no host isolation. In this case, a secure access point that prevents malicious interaction between hosts would be beneficial. The CELT-Secure switch is developed and presented in this section to address this use case.

For the experimental setup, the CELT-Secure switch was tested using a simulated LAN environment with ten virtual hosts (h1–h10) interconnected via a virtual Access Point (AP) managed by the Ryu SDN controller. Each host was assigned a unique static IP address in the 10.0.0.x range and emulated using Mininet, a popular SDN emulation platform. The controller and AP ran on a macOS system with a 2.8 GHz Quad-Core Intel i7 CPU and 16 GB of RAM, using Python 3.11 to implement the Ryu controller logic. Two primary attack types were emulated: (1) a Denial-of-Service (DoS) attack implemented using ICMP flood traffic sent from h3 to h1, and (2) a Man-in-the-Middle (MITM) attack using ARP spoofing initiated from h2 to impersonate h5 and intercept traffic from h3. The controller maintained internal tables of MAC-to-IP mappings and per-host packet rates to detect anomalies. Flow rules were dynamically inserted using OpenFlow 1.3 to mitigate threats in real time. Assumptions for the testing phase included a stable LAN topology without link failures, no packet encryption, and minimal legitimate background traffic.

7.1. Introducing the CELT-Secure Switch

The CELT-Secure switch is a virtual switch on an edge NE. This secure switch is implemented using the Ryu SDN controller. Ryu was selected due to the high testbed rating it received, as indicated in Table 3. It is capable of detecting and preventing ARP spoofing and DoS attacks. The specific part of the SDN architecture that this switch secures is the data plane, discussed in Section 5.3.2. This involves exposing components such as switches and routers to network traffic. The attack detection and mitigation algorithms are integrated within the control plane.

Several unique challenges and considerations arise when integrating the CELT-Secure switch into public WiFi networks such as those found in cafes, airports, or other open-access environments. Public networks are typically designed for convenience, but often lack the robust security measures that are standard in private or enterprise networks. As a result, implementing Address Resolution Protocol (ARP) spoofing detection and prevention becomes more difficult yet increasingly crucial, as public networks are common targets for various types of attacks.

In open networks like those found in public WiFi environments, ARP spoofing (or ARP poisoning) is one such type of attack. In this scenario, a malicious device sends false ARP messages within the network. This causes its MAC address to be incorrectly mapped to the IP address of another device (such as the router). As a result, network traffic can be redirected through the attacker’s device, enabling them to intercept, modify, or drop packets. In publicly accessible open networks, there are many connections and disconnections of unique hosts. This dynamic environment makes it challenging for the edge switch to maintain accurate ARP tables, MAC addresses, and IP address mappings. Unlike private networks, where devices are generally more stable, the ever-shifting nature of public networks can lead to stale or inconsistent ARP tables.

7.2. Attack Emulation Experiment and Results

The following subsections first demonstrate the controller’s response to a DoS attack and then evaluate its effectiveness in mitigating a MITM attack, including a comparative case where the security mechanism is not applied.

7.2.1. Dataset Generation and Attack Emulation Experiment Methodology

A simple local area network model was created for the simulation of the CELT SDN controller to test local detection and prevention of DoS and MITM attacks. A model with ten hosts connected in the LAN was simulated while the AP was running the CELT switch. In the following section, a computer on the local network is referred to as a host; for instance, host3 is referred to as h3 and host5 is referred to as h5. Each host has an IP address associated with it, such as h3 (10.0.0.3). In the DoS attack, the attack was launched from one host h3 to one victim h1 via an ICMP flood. In the MITM attack, the attack was launched via ARP spoofing from one host h2, with hosts h3 and h5 as victims. In this attack emulation experiment, the dataset was generated by capturing packets. The captured packets were stored as PCAP files, which is a common format for storing packet captures. The actual packets were transmitted in the data plane, and the controller implemented in Ryu managed the packet flow rules and monitored the packet flows by following the algorithm. The protection mechanism involves monitoring network traffic for anomalies such as ARP spoofing by validating IP to MAC records in the ARP table. DoS attacks are detected by tracking packet rates against a predefined threshold; upon detection, blocks are implemented via flow rules, as shown in Figure 9.

7.2.2. Mitigating DoS Attacks

In this scenario, a DoS network attack is launched from host h3 toward host h5 (10.0.0.5). The attacker uses an ICMP flood initiated via the command ping -f 10.0.0.5. The CELT-Secure controller monitors per-host traffic in real time by using a configured packet-per-second threshold to identify abnormal traffic behavior.

The test proceeds through the following steps:

1.

The CELT-Secure switch is launched.

2.

Hosts h1 through h6 connect to the network.

3.

Host h3 begins flooding h5 with ICMP packets.

4.

The controller detects that h3’s traffic exceeds the PPS threshold and installs a high-priority drop rule targeting h3’s IP address.

When the rule is active, h3 continues to send ICMP packets at roughly 90 packets per second, but receives no replies, as seen in Figure 10. The command-line output on the attacker’s interface confirms the lack of responses, with repeated “no reply” messages. In parallel, controller logs print an alert noting that the packet threshold has been exceeded and that a blocking rule is being enforced.

This mitigation is further confirmed through packet inspection; ICMP request packets continue outbound, but no ICMP replies are captured. The entire detection and defense process takes place within approximately two seconds of flood initiation, demonstrating the responsiveness of the CELT-Secure controller to volumetric attacks.

7.2.3. Mitigating MITM Attacks

In the second test scenario, a Man-in-the-Middle (MITM) attack is carried out using ARP spoofing. Host h1 attempts to position itself between two victim hosts, in this case h3 (10.0.0.4) and h5 (10.0.0.6), by sending falsified ARP replies that claim h1’s MAC address corresponds to h5’s IP.

Within the LAN controlled by CELT-Secure, the controller checks incoming ARP traffic against its maintained table of known IP-to-MAC mappings. When a conflicting mapping is detected, the controller identifies it as an ARP spoofing attempt and promptly blocks the malicious host.

The spoofing sequence is as follows:

1.

The attacker h1 announces itself as h5, poisoning the ARP caches of other hosts.

2.

The controller detects the duplicated mapping for IP 10.0.0.6 and blocks h1.

3.

Post-mitigation, hosts h3 and h5 resume direct ICMP communication, bypassing the attacker.

To illustrate the importance of the CELT-Secure controller, the same MITM attack was repeated on a non-secured controller setup. In that case, the ARP spoof succeeds; the target victim h5 associates the attacker’s MAC address with its peer h3 and begins to route traffic through the attacker. This confirms that without host isolation and ARP table inspection, traditional SDN controllers are vulnerable to basic spoofing methods.

In contrast, CELT-Secure successfully prevents interception and restores legitimate communication between peers. The attack is blocked automatically and without disruption to the rest of the network.

7.2.4. Discussion of Observed Outcomes

After the ARP spoofing attack begins, the controller detects conflicts in MAC-IP mappings, identifying h1 as malicious. The controller blocks the attacker, mitigating disruptions. Wireshark confirms that victims h4 and h6 communicate successfully and that their MAC addresses in the captured packets are correct. In comparison, when using a non-secured controller without proper measures, the attacker is able to intercept communications between the two victims. Packet captures show the success of the MITM, with spoofed ARP responses allowing unauthorized data access. Events leading to the attack include the attacker sending fraudulent ARP replies, associating its MAC with the victims’ IPs, and gaining access to their communications. This comparison highlights the critical role of ARP conflict detection and blocking mechanisms in mitigating MITM attacks within SDN environments.

Many other works on DoS detection have proposed time-window classification [24,52,78,82,83,84,85]. A time-window approach analyzes network traffic over time. Instead, the CELT-Secure switch analyzes packets in real time and calculates a continuously updated metric. This metric can surpass a threshold and trigger a host ignore rule from the controller. A running metric has the potential for faster DoS detection than time-window methods, which must wait for the window to complete. In our test, the CELT-Secure switch wrote drop flow rules for the malicious host only 2 s after the attack started.

Table 5. DoS detection times in comparison to the CELT-Secure switch.

Time for Detection	Proportional Detection Time	Model	Reference
Detection in 2 s	Reference	CELT-Secure algorithm	-
Time window of 5 s	2.64 × slower	Random Forest	[84]
Time window of 60 s	31.57 × slower	Deep Learning	[83]
Detection in 0.907 s	2.09 × faster	Deep Neural Network	[85]
Window of 30 s	15.78 × slower	Ensemble Model	[82]
Window of 15 s	7.89 × slower	SVM	[78]
Window of 20 s	10.52 × slower	Deep Learning	[52]
Detection after 10 s	5.26 × slower	Decision Tree	[24]

compares the detection time to related works using CELT-Secure’s detection time as the reference time.

An assumption of this security mechanism is that the threshold can be applied to all managed network traffic. One drawback is its fixed packet rate threshold. The implementation of ARP spoofing detection and DoS blocking mechanisms in the CELT-Secure switch demonstrates a way to deploy secure LAN peer-to-peer environments without host isolation. As a secure access point, it uses an SDN controller to monitor and mitigate malicious interactions such as ARP spoofing and DoS attacks, thereby ensuring robust data plane protection. It could support public WiFi networks in addressing open access vulnerabilities, including MITM attacks and dynamic user activity. The attack emulation experiments in Section 7.2.2 and Section 7.2.3 show that an SDN controller can secure access points, highlighting the efficacy of proactive defenses which address the concerns from Section 5.1. The switch is not coded in Java, meaning that it is not vulnerable to the reflection issue discussed in Section 5.3.1. However, further study of the controller is needed in order to fully understand its security implications. To improve the CELT-Secure switch, optimal placement of the rate limit and classification of traffic by rate limit category should be implemented.

7.2.5. Comparison with Existing SDN Security Tools

Several tools have been developed to enhance SDN security, including FortNOX [93], SE-Floodlight, AVANT-Guard, vSwitchGuard [94], and FlowGuard [95]. FortNOX introduces role-based and permission-based security by enforcing policies within the controller to prevent rule conflicts and privilege escalation. SE-Floodlight extends the Floodlight controller by integrating authentication, authorization, and accounting mechanisms into the flow rule setup process. FlowGuard focuses on real-time policy conflict detection and resolution by monitoring flow updates and controller decisions.

In contrast to these controller-focused solutions, the CELT-Secure switch emphasizes immediate data-plane protection by implementing real-time flow rule blocking in response to attack behaviors such as ICMP flooding and ARP spoofing. Unlike FortNOX and FlowGuard, which rely on centralized policy engines, CELT-Secure operates directly at the edge with minimal latency and does not require host isolation or extensive predefined policies. This makes it particularly suitable for open and dynamic environments.

While CELT-Secure can coexist with controller-layer tools such as SDN-Guard or anomaly classifiers described in Section 6.4, its key novelty lies in the combination of threshold-triggered local enforcement and real-time packet monitoring. These design choices enable rapid response to threats, offering a lightweight yet effective layer of security complementary to existing frameworks.

While the CELT-Secure switch demonstrates effective mitigation of ARP spoofing and DoS attacks in simulations, its deployment in real-world networks presents practical challenges. First, adapting the Ryu-based controller to commercial hardware may require customization, especially for proprietary firmware or hardware acceleration. Second, public WiFi introduces high user churn and device diversity, complicating ARP mapping consistency and increasing false positive risks. Maintaining low-latency control in dynamic networks also demands strong computational resources and optimized flow rule management. Security policies must balance sensitivity and false detection, especially in networks with bursty traffic. Lastly, ensuring resilience and reliability of the control plane is critical to prevent single points of failure, particularly under attack or segmentation. This challenge is often underexplored in virtualized testbeds. Addressing these hurdles is essential for moving from experimental validation to operational deployment.

8. Conclusions and the Future of Security Issues and Challenges for SDNs

The SDN model has transformed network management and optimization. Further research into OpenFlow-based SDNs should focus on addressing the security limitations of existing open-source implementations. Additional exploration is warranted to evaluate the suitability of SDNs across diverse network environments. Another area of interest is improving the performance of centralized SDN controllers through compute acceleration using heterogeneous architectures such as GPUs or FPGAs.

Limitations of this Work

While our proposed CELT-Secure switch offers effective localized mitigation against two low-sophistication fast-paced attacks in the form of ICMP floods and ARP spoofing, its current implementation and validation remain constrained to virtualized environments. As with many simulated systems, real-world deployment introduces several challenges. The first challenge for CELT-Secure is the requirement for the switch to support the OpenFlow specification, which might imply a network component upgrade and as such incur additional costs. Furthermore, it requires computing power (the SDN controller) that must be economically justified, which might make it cost-inefficient and consequently prohibitive for practical usage. Highly dynamic network environments with constantly changing hosts, such as campus or public WiFi networks, may degrade ARP-based detection due to inconsistent mapping and raise the likelihood of false positives. Additionally, its reliance on fixed threshold triggers may limit adaptability against more nuanced or stealthy adversarial behaviors. Finally, resilience of the overall control plane, particularly under scenarios of controller segmentation or failure, remains a critical area that warrants deeper architectural hardening and redundancy planning.

Understanding and Mitigating SDN-Specific Attack Vectors

Future work should focus on redundant SDN strategies to mitigate the controller being a single point of failure. While this paper has primarily addressed DoS as a rapid packet flooding attack, slow DoS attacks (such as Slowloris-style starvation) may evade detection by the proposed mechanism. Thus, the CELT-Secure switch must incorporate techniques to detect and respond to such slow-paced threats. Further development is also needed to incorporate northbound applications managed through cloud interfaces. This would allow anomaly detection techniques such as those outlined in Section 6.4 to operate at scale, correlating data across geographically distributed sites. These methods, including ensemble models and statistical classifiers, can identify both high-volume and low-rate attacks with increased accuracy when supported by larger datasets.

Resilience and Recovery in SDN Security

Future work should demonstrate the use of OpenFlow 1.2 or later to enable primary-secondary controller configurations and conduct case studies on controller fail-over during security incidents or outages. These studies should highlight protocol-level features for high availability, for instance those in ODL, to validate controller redundancy mechanisms. Distributed control architectures can further reduce recovery time and support load balancing under attack or fault conditions. Techniques from Section 5, including flow timeouts and packet validation, should be integrated into these distributed models to prevent stale or spoofed flows from persisting.

Securing Inter-Domain Communications and Controller Federation

Security concerns related to inter-domain communication must also be addressed. The current generic model described in Section 4.2 should be expanded with concrete examples of eastbound and westbound API frameworks. These APIs must ensure message integrity, authentication, and secure coordination of policy and routing information across SDN controller domains.

Convergence of SDN and Software-Defined Radio (SDR)

The convergence of SDN and SDR represents a promising direction for dynamic programmable wireless communication networks. Merging SDR’s signal agility with SDN’s centralized control can enable real-time routing, adaptive spectrum usage, and cognitive networking, which are critical for 5G, 6G, and IoT contexts; however, this flexibility also expands the attack surface. Future research should focus on mitigating risks such as spectrum jamming, spoofing, and command injection. This includes ensuring the integrity of control messages and developing lightweight anomaly detection schemes that can operate within SDR environments.

Toward Practical and Scalable SDN Security

The use of SDNs can provide networks with programmability and adaptability, enabling centralized interfaces for dynamic control. Applications can modify packet forwarding rules in real time, creating opportunities for innovation and optimization. This paper has analyzed key security threats for SDNs and introduced strategies such as DoS mitigation, access control, and ML-based anomaly detection for defending against them. Our CELT-Secure switch prototype demonstrates these concepts within a local network context. However, for broader applicability, future systems should integrate cloud-based traffic analysis to detect complex attack patterns such as distributed MITM or coordinated flooding attacks. As discussed in Section 5, flow expiration mechanisms can help to invalidate obsolete or spoofed IP-MAC bindings, and their application across distributed control architectures warrants further investigation. The continued development of resilient and adaptive SDN security mechanisms will be essential to realizing the full promise of SDNs in dynamic and large-scale deployments.