Software Defined Network (SDN) is vulnerable to TCP-SYN flooding attacks due to its centralized architecture. These attacks overload the controller by generating excessive fake packets, leading to performance degradation and increased energy consumption. Existing solutions often focus on improving security but overlook the energy implications. In this work, we analyze energy consumption patterns of SDN controllers and switches under attacks. We propose SYN-Monitor, an energy-efficient approach to mitigate TCP-SYN flooding attacks using selective processing of benign traffic at the controller level. SYN-Monitor identifies compromised switch ports using an address mapping technique and employs a SYN-proxy approach at these ports, filtering out fake SYN packets without burdening the controller, while still allowing legitimate traffic. Legitimate SYN packets from trusted ports are processed normally. The proposed approach reduces the controller’s energy consumption by 20-50% and the energy usage of OpenFlow switches by 60-70%, compared to an SDN without security solution under attack. Additionally, SYN-Monitor significantly lowers the False Positive Rate and improves the response time for legitimate traffic compared to existing solutions. We have implemented SYN-Monitor in Floodlight controller and present experimental results to show its effectiveness in both security and energy efficiency.
1 Introduction
Software-Defined Networking (SDN) provides efficient configuration and management of network resources by decoupling control logic from data forwarding logic [14]. When a switch does not have a corresponding flow rule for an incoming packet, it sends a packet_in message to the controller. The controller then generates and installs the necessary flow rules in the switches through the South Bound API (SBI), enabling vendor-independent switches in the network. This centralized control also offers a comprehensive view of the network topology, including switch interconnections and the location of each host (referred to as switch host_port) [13]. However, frequent communication between the controller and switches for each new request exposes SDN to Distributed Denial of Service (DDoS) attacks, particularly TCP-SYN flooding attacks [17]. In these attacks, malicious applications generate excessive fake SYN packets by spoofing the source MAC and IP addresses (as shown in Fig. 1), overloading the controller and victim servers. This results in substantial energy consumption as network resources are drained to process the fake packets, hindering timely responses to legitimate traffic. Furthermore, the incomplete TCP connections caused by the fake SYN packets consume server resources, preventing the server from responding efficiently to legitimate packets. While several defense mechanisms have been developed to mitigate TCP-SYN flooding attacks, they often suffer from drawbacks such as increased response time for legitimate traffic [12],[15], buffer saturation [15], and high False Positive Rates (FPR) [8], [11], [10],[16], [9], [7]. Moreover, none of these solutions consider the energy overhead introduced by handling fake traffic. To address these challenges, we propose SYN-Monitor, an energy-efficient solution designed to defend against TCP-SYN flooding attacks in SDN environments. SYN-Monitor reduces energy consumption by selectively processing benign traffic at the controller level while filtering out fake SYN packets at compromised switch ports. This approach not only improves security but also optimizes the energy usage of both controllers and switches.
The organization of the paper is as follows. Section II presents the Related Works. Section III outlines the Problem Statement, Section IV presents the proposed DDoS Defense System, and Section V presents the experimental results and discussions. Finally, Section VI concludes the paper.
2 Related Works
Various defense solutions have been proposed to mitigate SYN flooding attacks in SDN, but many overlook their impact on energy consumption. One common approach involves implementing an SYN-proxy at either the controller [12] or at SDN edge switches [15]. This mechanism forwards TCP-SYN packets to the server only after the completion of the 3-way TCP handshake, either with the switch [15] or the controller [12]. While this solution is effective in preventing attacks, it introduces significant processing overhead for both the controller and the switches, leading to increased energy consumption in both benign and attack scenarios. Deng et al. introduced Packet_Checker [11], which quickly identifies the compromised switch port when there is an unexpected change in the MAC or IP address without a corresponding port status change message (e.g., port down or port up). However, this approach blocks the entire port, causing both legitimate and malicious traffic to be dropped. While this reduces some packet processing load, it also causes legitimate packets to be needlessly blocked. The entropy-based approach detects attack traffic by measuring the randomness of packet_in messages with respect to packet header fields [8], [16]. Although this method effectively identifies malicious traffic, it suffers from high FPR as it blocks both legitimate and malicious traffic destined for the server during an attack at the destination switch. Though the solution blocks the attack traffic at the destination switch, the attack traffic enters the network which results in high energy consumption of the controller and switches along the path from the source switch to destination switch. Machine learning (ML)-based methods have also been used to detect attacks in packet_in traffic by utilizing models such as Self-Organizing Map (SOM) [9], hybrid ML methods [10], Random forest [7]. While these ML techniques can enhance detection accuracy, they often require intensive computation, resulting in higher energy consumption for both training and real-time traffic analysis. Continuous monitoring and classification of the network traffic can significantly increase the controller’s CPU usage, leading to greater energy expenditure. Based on the analysis of the existing works, which motivates the current work with the objective to design an energy efficient defense solution against SYN-flooding attack with minimal false positive rate. The overall comparison of different defense solutions is illustrated in Table 1.
Selective dropping of fake packets from compromised switch ports
✗
✔
Table 1: Comparison of Detection and Mitigation Approaches with Energy Factor Analysis
3 Problem Statement
The SDN architecture as shown in Fig. 1 consists of one controller and one SDN switch. The SDN switch S1 is directly connected to the controller through SBI. S1 has four ports; port 1 and port 2 are connected to compromised hosts, port 3 is connected to a legitimate host and port 4 is connected to the server.
In a compromised host, an attacker installs a malicious application, therefore, the compromised host sends both benign packets from legitimate applications and fake packets from malicious applications to the network (Fig. 1(a)). When an application from a host wants to communicate with the server, it sends SYN packets for the server to its source switch (Fig. 1(b)). If the matching flow rules for these SYN packets are not in the flow table of the switch, the switch forwards the \(packet\_in\) s to the controller (Fig. 1(c)) w.r.t SYN packets, and the controller generates and installs flow rules in the flow table of the switch w.r.t the \(packet\_in\) s (Fig. 1(d)). Thereafter, SYN packets are forwarded to the server using the flow rules (Fig 1(e)).
The consequence of the fake SYN packets are unnecessary CPU consumption of switches and controller, congestion in SBI and overflow in the flow table of switches. The legitimate SYN packets create complete TCP connections with the server. However, fake SYN packets do not complete TCP connections with the server, and deplete the server’s resources.
Energy Model: The energy consumption of an SDN controller and its connected switches can be modeled as follows:
The energy consumption EC of the controller is a function of the number of packet_in messages PI processed by the controller :
Here, \(E_{F_T}\) represents the energy consumed by a switch to search the respective flow rule for a packet_in in the flow table which is directly proportional to the number of flow rules in the flow table.
Now, our goal is to minimize both EC and ES during TCP-SYN flooding attacks by reducing unnecessary packet processing and flow rule installations with the following objectives.
(1)Objective-1: Identification of compromised hosts’ switch ports (e.g., port1 and port2 of switch S1 in Fig. 1).
(2)Objective-2: Fake SYN packets from malicious applications are be dropped, SYN packets from legitimate applications of compromised hosts are to be processed.
(3)Objective-3: Packets from legitimate hosts are to be processed normally as in the case of SDN without any security module under a benign scenario.
Figure 1:
Figure 1: TCP-SYN based Flooding attacks in SDN
(a) Attacker installs malicious application in compromised hosts (b) Fake packets with spoofed header field from compromised hosts to switch (c) Packet_ins from switch to controller (d) Flow rules from controller to switch (e) Fake packets forwarded to Server
4 Proposed Solution: SYN-Monitor
The SYN-Monitor is designed at the control layer of SDN and consists of two modules such as detection and mitigation module as shown in Fig. 2. The detection module finds the switch ports of compromised hosts using an address mapping technique, addressing objective 1 of our study. The mitigation module applies a SYN-proxy approach at the switch ports of compromised hosts, dropping malicious SYN packets and processing legitimate SYN packets, aligning with objective 2 of our study. Traffic from legitimate ports is processed normally which addresses the objective-3 of our study.
Figure 2:
Figure 2: Flowchart of SYN-Monitor
4.1 Detection Module
The proposed detection module relies on an address mapping method based on the premise that there exists an one-to-one mapping between a host’s IP address, its MAC address, and its corresponding switch host_port until the host migrations to another location [13]. To implement this concept, this module maintains a mapping table which consists of three attributes such as network location (i.e., switch host_port), MAC address and IP address. The network location is the primary key of the table. When a SYN packet_in arrives at the controller from a switch host_port i, the detection module checks the port i information in the mapping table. If the information is not present in the table, it is updated into the table. If the information of port i is present in the table and MAC and IP address of port i in the mapping table and in the packet_in are same, then the port i satisfies the address mapping method and it is a legitimate port. If the information of port i in the packet_in and in the mapping table are different without port status change information from port i, it implies that port i does not satisfy the address mapping method. Hence, port i is considered compromised port. Detection module sends the compromised port information to mitigation module. Therefore, the mitigation module selectively processes the legitimate packets from the compromised host_ports without processing the malicious traffic, which reduces the unnecessary energy consumption of both the controller and switches.
To deal with the dynamic scenario (like hosts migrating from one location to another), the mapping table is updated as follows. When a host is detached from its port, a port_Down message from the port arrives at the controller and detection module deletes the port information from the mapping table. When a host is attached to a port, a port_UP message of the port and subsequently a SYN packet arrives at the controller, the detection module updates the MAC and IP address of the host in the mapping table using the information in the SYN packet_in message.
Time and Space Complexity Analysis. The proposed mapping table is constructed using a direct hashing method which offers the expected time complexity to search, add or remove the MAC and IP information of a switch host_port in the mapping table is O(1). The mapping table’s space complexity scales linearly with the total number of switch host_ports in the network, denoted by N, making it O(N).
4.2 Mitigation Module
After getting a compromised switch port information c from detection module, the mitigation module applies a SYN-proxy approach at the port c as shown in Fig. 3. When a SYN packet_in arrives at the controller from the compromised port c, the mitigation module creates a cookie using the information present in the SYN packet; subsequently, the SYN-ACK and the cookie are sent to the client. If the SYN packet sent by the client is valid, the client sends the ACK with the valid cookie to the controller in respond to the SYN-ACK. The controller sends RST to the client for reestablishing the TCP connection with the server after receiving the ACK with the valid cookie from the client. Additionally, the controller installs the corresponding flow rule for this SYN packet into the switch’s flow table, enabling subsequent SYN packets to be forwarded directly to the server without further interaction with the controller. This avoids unnecessary communication with the controller, reducing the energy overhead. This strategy forwards each legitimate SYN packet from compromised ports which leads to almost zero FPR. For fake SYN packets, which do not elicit an ACK from the client in response to the SYN-ACK, the controller does not install any flow rule, thus avoiding unnecessary energy consumption. The fake SYN packets are dropped immediately, which leads to almost zero False Negative Rate (FNR). By preventing the forwarding of fake packets and limiting the processing to the necessary minimum, the controller conserves energy during attack scenarios. SYN packets arriving from legitimate ports are processed as usual by the controller, bypassing the SYN-proxy mechanism. This ensures that normal traffic operates efficiently, reducing unnecessary energy expenditure during benign network conditions.
Figure 3:
Figure 3: Flowchart of Mitigation module
Time and Space Complexity Analysis. The time complexity of the mitigation module to validate a SYN packet is O(1) as it performs only a three way TCP-handshaking. This module does not use any database so its space complexity is O(1).
5 Experimental Evaluation and Discussion
5.1 Experimental setup and Implementation
The main components of our experiment setup are Mininet emulator [1] and Floodlight [5] controller and this setup is run on a PC with CPU Intel Core i7-1165G7-2.80GHz and 8 GB RAM. We have created the network topology named Geant Internet Zoo topology [4] using mininet emulator. Geant Internet Zoo topology is a real-world topology designed to support research and education activities consisting of 40 SDN switches [6], and 122 links between the switches; each switch consists of 10 hosts. Out of these 400 hosts, 50 are servers, and the rest are used as attackers or legitimate hosts. All the switches of the network are connected to the controller through OpenFlow SBI protocol [6]. The proposed SYN-Monitor is implemented as an extension of the packet_in handler module of Floodlight controller.
To evaluate the performance of SYN-Monitor, we have considered half of the host of the network as legitimate and rest half as compromised host. A malicious application is installed in each compromised host which generates 100 packets per second by spoofing the MAC and IP address of each packet using scapy tool[2]. The legitimate applications from both legitimate hosts and compromised hosts generate 20 to 25 SYN packets per sec using iperf tool[3].
We have conducted two experiments. Experiment-1:In the first experiment, We have evaluated the energy consumption of the system in the present of the proposed solution (SYN_Monitor) and without the proposed solution under varying attack traffic. Experiment-2:In the second experiment, we have compared the performance of Syn-Monitor with ADAM [10], packet_checker[11] and DDoSSourceTracker[7] in term of False Positive Rate (FPR), False Negative Rate (FNR), CPU consumption of the controller, and response time of legitimate traffic.
5.2 Experiment-1
1. Energy Consumption by Controller: The energy consumption of the controller under different scenarios is shown in Fig. 4. When the controller gets started it consumes about 30 to 39watts. However, when the controller is in on stage but does not process any packet_in request from the host, it consumes the energy about 5 to 6 watt. When the controller gets started to process the request, the power consumption of the controller is increased with the increasing requests from the end hosts. The SDN without any security solution (Normal SDN) consumes more power as compared to SDN with SYN-Monitor. This is because Normal SDN processes each fake packets from the compromised application, however, SYN-Monitor selectively processes only legitimate traffic and drops the malicious traffic without processing.
2. Energy Consumption by switches: The energy consumption of a switch under varying attacking load is shown in Fig. 6. The energy consumption of the switch is directly proportional to the number of flow rules in the flow table as illustrated in equation(2). Under attack, the controller without security solution generates the flow rules for each fake packets which increases the size of the flow table as shown in Fig. 5. Therefore the energy consumption of Normal SDN increases with increasing attack traffic. However, SYN-Monitor selectively drops the malicious packets without generating the fake flow rules, which results in no flow rule in the flow table and the energy consumption of the switch remains consistently lower compared to Normal SDN.
Figure 4:
Figure 4: Power Consumption of Controller under Varying Attack Traffic Requests
Figure 5:
Figure 5: Number of Flow rules in Flow table under varying attack requests
Figure 6:
Figure 6: Power consumption by an OpenFlow switch under varying Attack Traffic
5.3 Experiment-2
1) FPR Vs. FNR: FPR is defined as the percentage of legitimate packets that are dropped. FNR is defined as the percentage of malicious packets that are processed. The FPR and FNR of defense solutions are shown in Table 2. During attacks, Packet_Checker finds out the compromised hosts’s ports and blocks the entire ports therefore, both fake and legitimate SYN packets are dropped, resulting in 100% FPR and 0%FNR. ADAM blocks all the traffic during attacks directed towards victim servers, therefore FPR of both compromised and legitimate ports is 100%. DDoSSourceTracker finds out the compromised ports using the ML approach and blocks the entire ports, therefore, similar to Packet_Checker, it results in 100% FPR and 0% FNR for the compromised host ports. In the case of SYN-Monitor, the compromised host_ports and legitimate host_ports are determined using an address mapping technique discussed in section-IV.A. Packets from legitimate host_ports are processed normally without applying the mitigation module, resulting 0% FPR and FNR for legitimate ports. However, SYN-Monitor applies the SYN-proxy approach for the compromised host_ports which selectively processes legitimate traffic in the meanwhile, it drops the malicious traffic as discussed in section-IV.B.
b) Controller Overhead(%): It is defined as the percentage of CPU consumption of the controller to mitigate the attacks in the presence of a defense solution. The controller overhead of defense solutions is shown in Table 3. The CPU utilization of the controller in the presence of Packet_Checker is very minimal because it blocks the entire compromised ports to mitigate the attacks. Both ADAM and DDoSSourceTracker are based the ML approach which continuously monitors the network traffic to detect the attack, which results in a high CPU utilization of the controller. The SYN-Monitor, while exhibiting slightly higher CPU consumption compared to Packet_Checker because it employs an SYN-proxy approach for compromised ports. This approach effectively mitigates the attacks by dropping fake SYN packets and processing legitimate SYN packets from compromised ports, resulting in a 0% FPR a notable improvement over existing solutions.
Table 3: Controller Overhead in presence of Defense Solutions
(3) Response time of legitimate traffic: In benign conditions, the response time of legitimate traffic remains consistent across various defense solutions and is comparable to that of SDN without any security measures. However, during an attack, ADAM blocks all traffic directed to victim servers, leading to a complete lack of response for legitimate traffic. Packet_Checker blocks entire compromised hosts during an attack, resulting in no response for legitimate traffic originating from these hosts. Conversely, SYN-Monitor employs a more sophisticated strategy: it identifies and drops malicious SYN packets while permitting legitimate SYN packets from compromised hosts using a SYN-Proxy mechanism. Additionally, packets from legitimate host_ports are processed normally under SYN-Monitor, resulting in an improved response time for legitimate traffic. The response times of legitimate traffic in the presence of defense solutions are detailed in Table 4.
Table 4: Response Time of Legitimate traffic in presence of Defense Solutions
6 Conclusion
In this paper, we introduce SYN-Monitor, an energy-efficient defense solution against TCP-SYN flooding attacks from malicious applications in SDN. SYN-Monitor effectively identifies the switch ports associated with compromised hosts and strategically applies a SYN-proxy approach at these ports, achieving zero FPR and FNR. By focusing mitigation efforts only on compromised ports, SYN-Monitor minimizes the energy expenditure of the controller and switches, as legitimate SYN packets from unaffected ports are processed normally, without invoking additional security mechanisms. This targeted processing leads to significantly lower energy consumption compared to systems that indiscriminately handle all traffic. The proposed solution also reduces response times for legitimate packets, both in benign and attack scenarios, by avoiding unnecessary packet processing and flow rule generation. Furthermore, SYN-Monitor enhances the security and energy efficiency of the SDN by not generating flow rules for fake SYN packets, thus preventing unnecessary resource usage and protecting the system from memory saturation attacks. By addressing key security challenges in centralized SDN architectures, SYN-Monitor provides a balanced approach that enhances both security and performance while reducing energy overhead, making it a robust and energy-efficient solution for dynamic network environments.
In future work, we aim to expand our proposed DDoS defense solution to address hybrid SDN environments, where the network integrates both SDN and traditional switches. In this setup, the SDN controller will have a limited view of the network topology, focusing only on SDN-managed switches.
M. Aladaileh et al. 2021. Entropy-Based Approach to Detect DDoS Attacks on Software Defined Networking Controller. Computers, Materials & Continua 69, 1 (2021), 373–391.
Tianyang Cai et al. 2023. ADAM: An Adaptive DDoS Attack Mitigation Scheme in Software-Defined Cyber-Physical System. IEEE Transactions on Industrial Informatics 19, 6 (2023), 7802–7813.
Deng et al. 2018. Packet Injection Attack and Its Defense in Software-Defined Networks. IEEE Transactions on Information Forensics and Security 13, 3 (2018), 695–705.
Silvia Fichera et al. 2015. OPERETTA: An OPEnflow-based REmedy to mitigate TCP SYNFLOOD Attacks against web servers. Computer Networks 92 (2015), 89–100.
Eduard Marin et al. 2019. An In-depth Look Into SDN Topology Discovery Mechanisms: Novel Attacks and Practical Countermeasures. Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security (2019). https://api.semanticscholar.org/CorpusID:207959749
Bruno Astuto A. Nunes, et al. 2014. A Survey of Software-Defined Networking: Past, Present, and Future of Programmable Networks. IEEE Communications Surveys & Tutorials 16, 3 (2014), 1617–1634.
Mitali Sinha. 2024. SynFloWatch: A Detection System against TCP-SYN based DDoS Attacks using Entropy in Hybrid SDN. In Proceedings of the 25th International Conference on Distributed Computing and Networking, ICDCN, India, January 4-7, 2024. ACM, 359–364.
ICDCN '24: Proceedings of the 25th International Conference on Distributed Computing and Networking
The emergence of hybrid software-defined networks (SDNs) that combine traditional network infrastructure with SDN creates new security challenges, particularly regarding TCP-SYN-based Distributed Denial-of-Service (DDoS) attacks. These attacks flood ...
Distributed denial of service (DDoS) attacks seriously threaten Internet services yet there is currently no defence against such attacks that provides both early detection, allowing time for counteraction, and an accurate response. Traditional detection ...
Cloud Computing provides an auto-scaling feature for dynamic resource utilization to cope with their customers’ requirements and charge as ‘pay-per-use’. Attackers get the benefit of this auto-scaling feature by flooding DDoS attacks ...
Indian Institute of Technology, Bhubaneswar, Bhubaneswar, Odisha, India and Computer Science and Engineering, Parala Maharaja Engineering College, Berhampur, Odisha, India [email protected]
