A Novel STRIDE Model for Improved Security and DDoS Mitigation for Software-Defined Networking

Substantial studies on security issues in SDN have resulted in a substantial body of literature. Schehlmann et al. [10] weighed the security benefits and downsides of SDN and determined that the benefits outweighed the risks, making SDN a security boon. Balarezo et al. [11] examined the novel security benefits offered by SDN and how it can address longstanding network security issues. The authors also identified SDN's new security threats and suggested ways to prevent and mitigate them. Ahmad et al. [12] examined the security vulnerabilities of SDN's application, control, and data planes, as well as the security platforms that protect each.

Numerous techniques have been proposed in the literature for enhancing security in SDN networks, but it is challenging to determine which of these mechanisms is superior. For instance, a lightweight method for detecting DDoS attacks using a low-overhead approach over the NOX platform was proposed in the study by Braga et al. [13], but the NOX platform is no longer being maintained and has been superseded by the POX controller. Moreover, the evaluation was conducted on the KDD-99 dataset, which is not ideal for real-time evaluations. Wang et al. [14] proposed an entropy-based lightweight DDoS flooding attack detection model running in the OpenFlow edge switch. However, using only entropy as a means of flow detection is insufficient in normal networks, and SDN is likely to face similar challenges.

Researchers have investigated multiple approaches for leveraging SDN to effectively block large-scale DDoS attacks that appear legitimate. One such method proposed in the study by Lim et al. [15] is to enhance the functionality of the SDN controller using flow statistics to detect anomalies and help allocate network resources. However, this approach may not be practical for high-traffic scenarios. Another approach proposed in the study by Giotis et al. [16] is a distributed collaborative framework that allows customers to request DDoS mitigation services from their ISPs. While this alternative provides a way to detect and mitigate DDoS attacks, its scalability and operational costs in large-scale deployments are questionable.

In addition, Dayal and Srivastava [17] identified various possible DDoS attacks in the SDN environment using an attack tree and model. They suggested using an SVM-based architecture for the SDN network to defend against and detect the attack source, which is known as the FLGUARD system [18]. However, this method may generate a large number of data packets sent to the controller, which can impact network security and risk range.

Authentication is also a significant concern in SDN networks. One study proposed by Guodong et al. [19] used cipher identification information during packet flow to verify their source. Nevertheless, because this technique does not verify users when packets enter or exit the network, network security and risk range are limited. Aladaileh et al. [20] presented an early detection technique to allow remedial steps to be taken at the right moment. Nevertheless, this strategy necessitates strong coordination among multiple network components, making it difficult to adjust networking device behavior and achieve coordination in traditional networks.

Hadi et al. [21] developed a security system that is both simple and fully customizable, making use of SDN to achieve a high level of security with minimal latency costs. However, the implementation of strict policies may lead to an increase in controller rejections, potentially impacting performance. Ilyas and Khondoker [22] conducted a Security Analysis of various SDN controllers, including Beacon, ZeroSDN FloodLight, and POX, concluding that SE-FloodLight is the most secure controller, while the POX controller is the most configurable. This paper did not focus on attack detection models but rather on the selection of an appropriate controller for SDN, prompting us to adopt the POX controller for our STRIDE framework.

Several approaches have been proposed to address DDoS attacks in SDN networks. However, most of these approaches have limitations that make them less practical in real-world scenarios. To this end, we present a statistical defense mechanism against DDoS attacks for SDN networks in this work. Our mechanism relies on statistical analysis of network traffic to identify abnormal patterns indicative of DDoS attacks. Specifically, we use the entropy-based approach [14, 15] as the foundation of our mechanism, extending it to incorporate packet header information and flow size, allowing us to detect DDoS attacks more accurately while minimizing false positives. Unlike entropy-based schemes [14, 15] and FLGUARD, which primarily focus on detecting Denial-of-Service (DoS/DDoS) attacks, P-STRIDE provides comprehensive protection across all STRIDE threat categories, including Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privileges. This holistic security coverage is achieved through a tight integration of OpenFlow table rules and controller-level logic, rather than relying solely on traffic statistics or machine learning classifiers.

This section presents our proposed DDoS detection model during attacks in the SDN network. In DDoS attacks, the attacker forges its IP address or uses zombies to attack the target server it also changes port numbers to hide where the attack is coming from. Thus, from the point of view of the target network, there can be multiple input flows to the SDN Controller switch. We need to perform the flow aggregation from the IP Address to detect the attack. Flow aggregation helps identify the sources from which the expected attack might come.

4.1 Software-defined networking flow aggregation

During an attack, the attacker targets the victim's servers within the SDN network. The incoming traffic originates from various IPsrc, and to manage multiple flows directed toward the same target address (IPdst), the controller initiates a flow aggregation process. Figure 2 illustrates this aggregation mechanism, where the destination is overwhelmed with packets, simulating an attack scenario. To mitigate this, the proposed SDN controller employs a hashing table to efficiently aggregate Source-Destination IP pairs, as shown in Table 2.

Figure 2. Flow aggregation

Table 2. Flow entries used for enabling STRIDE functionality in software-defined networking (SDN)

Applying statistical evaluations, such as counting total active IP addresses with packet count during the specified time window. We can isolate IP Addresses such that the packet count of the incoming packets sent by the source IP addresses in each timeframe T exceeds the specified threshold .

$H\left(I P_j, C\right)=\sum_{j=1}^N \sum_{t=1}^T$ PacketCount $\left(I P_j\right)$          (1)

where, H is the hash table with size N.

$I P_j$ represents any active IP address during the time frame t $\in T$ .

$H\left(I P_j, C\right)$ represents the hash table with IP address

C is the packet count.

‘t’ represents the time span ‘t’.

For all the ‘N’ nodes, an entry about incoming traffic is maintained in the hash table to detect the attack.

The Proposed SDN controller then identifies the IP address which exceeds the predefined threshold $\partial$. The threshold $\partial$ can be identified by knowing the network bandwidth. The IP addresses which exceed the threshold $\partial$ are put in a blocking basket such that if $H\left(I P_j, C\right)>\partial$, block the IP address $I P_j$ using OpenvSwitch (OVS) flow entries. The detection method checks packet count per IP. If an attack is detected, then traffic is diverted to a black hole. To reduce false positives, PSTRIDE distinguishes between legitimate high-traffic flows and malicious traffic. Instead of using a fixed value, thresholds are dynamically adjusted based on real-time network conditions. The proposed algorithm was implemented in POX Controller. The Controller works in independent mode, the SDN switch works in parallel, doing the forwarding for normal packets and retaining the normal flow of the SDN mechanism, as shown in Figure 3.

Figure 3. Working procedure of the P-STRIDE controller

In the first part of our experiment, we selected a controller to use. We chose POX [24] because it is popular for experiments, is fast and lightweight, and is designed as a platform for building custom controllers. POX is an improved version of NOX [25], written in Python and used in many SDN papers mentioned in our paper. However, NOX is no longer being developed [26], which is why we opted to use POX instead. We developed a custom POX controller that uses statistical evaluation on the flows to identify DDoS attacks from incoming packets in the OpenFlow network.

Existing entropy-based methods [14, 15] rely mainly on statistical measures (e.g., entropy of flow distributions) computed at switches or the controller, which can suffer from high false positives under legitimate traffic surges. FLGUARD uses a centralized SVM-based classifier, resulting in increased control-plane communication overhead. In contrast, P-STRIDE introduces a hybrid co-design, where:

• Lightweight threat prevention (e.g., ARP spoofing, repudiation, privilege escalation) is enforced directly at OpenFlow tables,
• Computationally intensive DDoS detection is handled by a custom statistical POX controller, minimizing unnecessary packet-in events and reducing controller overload.

The experiments were conducted using Iperf [27] and the custom DDoS Scripts written in Python for simulating the DDoS attack. Traffic flows were generated during the normal and attack periods. The POX implementation, P-SRIDE, is compared with the Native OpenFlow architecture for comparison. During the testing, 50% of flows were collected during the attack period, and the other half were collected during normal traffic periods. Attacks were performed at the rate of 200 packets per second (PPS) on a 50Mb/s base network bandwidth. It is clear from Figure 5 that the P-STRIDE framework reduces network traffic, i.e., unwanted network traffic, significantly.

Figure 5. Traffic during the 200 PPS attack traffic

P-STRIDE possesses the potential to discover the abrupt and abnormal flow of traffic, as the modified POX controller has been trained to compare the traffic flowing at a point from a particular host with the predefined traffic flow. If it is not below the specified threshold, the modified POX Controller detects and notifies of the attack [28, 29]. Normal traffic, as depicted in red, is allowed to pass to the network hosts being the normal traffic flow. The Traffic peaks are visible for the case of OpenFlow in blue.

Figure 6. Network connectivity test 200 PPS attack traffic

The results depict that the native OpenFlow controller is unsuitable for handling DDoS traffic. Results for 6 test cases, as depicted in Figure 6, have been generated at different amounts of time to check the connectivity and reach through the “ping” command.

At heavy load time, at an interval of every 0.025 seconds, a new packet is sent, and results are generated after every 120 seconds. To ensure that the hosts in the network are connected and data can be transferred between them, the "pingall" statement is used to check the connectivity. For transferring files between reachable hosts, the Linux "wget" feature is used. The experiments showed that the modified P-STRIDE Controller was able to handle attacks more effectively compared to the OpenFlow POX Controller, which failed to detect the attack and resulted in the SDN Controller going down. It controls legitimate users from connecting. The entire network service is hampered due to the attack on the SDN Controller.

In the case of P-STRIDE, timely detection and handling avoid such problems. Legitimate users can connect and continue with the services.

Assessing bandwidth usage is a common step in determining the quality of service (QoS) in a network. A network's maximum data transmission rate is referred to as its bandwidth, and excessive use might result in alarms. An additional advantage of P-STRIDE is that it can measure bandwidth use. We can clearly understand the network's bandwidth consumption by calculating the ratio of regular traffic to the network's overall capacity, and it can be calculated using Eq. (2).

BWUtil $=\frac{\text {Normal Traffic Bandwidth}}{\text {Total Capacit }}$             (2)

where,

BWUtil represents Bandwidth Utilization Ratio, which represents the proportion of the available network bandwidth currently consumed by legitimate (normal) traffic. It is a dimensionless value ranging from 0 to 1.

Normal Traffic Bandwidth represents the bandwidth consumed by normal traffic, denoting the amount of network bandwidth used by legitimate, non-malicious flows during the observation interval. This parameter is typically measured in bits per second (bps) or megabits per second (Mbps) and is derived from flow-level statistics collected at the SDN switches.

Total Capacity represents total available network bandwidth, which refers to the maximum bandwidth capacity of the network link or aggregate links under consideration, expressed in the same units as Normal Traffic Bandwidth.

The bandwidth utilization depicts how much normal traffic is flooded in the network. During the DDoS attack, as seen clearly from Figure 7, the bandwidth utilization of the OpenFlow implementation keeps on decreasing. However, as P-STRIDE works by eliminating illegitimate network traffic, the bandwidth utilization remains close to normal. Bandwidth usage at a particular time has been calculated using “Iperf”.

Figure 7. Bandwidth utilization during different traffic rates

OpenFlow struggles to handle adaptive attack patterns in the environment, resulting in excessive consumption of network resources. P-STRIDE is dynamically adapting to filter the attack traffic, which is preventing disruptions in bandwidth usage.

The number of flow entries made in the OpenFlow tables acts as a great measures that affect the network's bandwidth usage. This fact can also be realized by studying the No. of flow entries in the Open Flow Controller table, as shown in Figure 8. During an attack and even in normal traffic mode, the P-STRIDE helps in removing unwanted entries in Open Flow tables as much as 19%. Due to a large number of flow entries that need to be written at the time of the attack in the OpenFlow POX, the performance of the OpenFlow in terms of bandwidth utilization and latency is badly affected.

Figure 8. Number of flow entries during the attack at different times

Delay time refers to the time elapsed between when a request is generated and when the data is delivered. An increase in delay time can indicate significant performance issues. Figure 9 shows that the presence of many flow tables in the OpenFlow implementation can degrade the network's latency.

Figure 9. Expected latency in the network with P-STRIDE vs. OpenFlow – given the normal mode delay at 10 ms

We use the ping command to measure packet loss and latency, which checks the connectivity between virtual machines and measures their performance. The Latency can be calculated using Eqs. (3) and (4). In real-time traffic, high jitter can degrade performance even if average latency remains within acceptable limits. P-STRIDE actively reduces jitter by prioritizing critical traffic and uses traffic shaping.

Latency $=$ Round TripTime $($ RTT $)$            (3)

$\begin{array}{r}\text { Latency }=\text { Message Sent Time } \text { Host } l \rightarrow \text { Host } 2 + \text { Response Time } \text { Host } 2 \rightarrow \text { Host }^4\end{array}$           (4)

where,

Latency is the total time delay experienced by a data packet to travel from the source host to the destination host and back. It reflects end-to-end communication delay in the network and is typically measured in milliseconds (ms).

Round Trip Time (RTT) is the time interval between sending a request packet from the source host and receiving the corresponding response packet. RTT captures both forward and return path delays, including transmission, propagation, processing, and queuing delays.

Message Sent Time $_{\text {Hostl} \rightarrow \text {Host} 2}$ is the time taken for a message or data packet to travel from Host 1 (source) to Host 2 (destination). This includes transmission delay, propagation delay, and any intermediate processing or queuing delays along the forward path.

Response Time ${ }_{\text {Host} 2 \rightarrow \text {Host} 1}$ is the time required for the response packet to travel from Host 2 back to Host 1, encompassing response generation time at Host 2 as well as transmission, propagation, and queuing delays along the return path.

Ping sends "echo request" and "echo reply" packets over ICMP. The user considers high latency to be an undesirable quality. In an ideal world, latency is limited by the speed of light in that fiber. P-STRIDE supports real-time traffic. The suggested P-STRIDE architecture has a delay of 11.7 ms when the nodes in the network have a typical traffic latency of 10 ms, when there is no assault.

Measuring the packet drop ratio is crucial for both network operators and application users as it indicates the performance of the network. The ratio shows the number of packets sent by the source in relation to the number of packets received by the destination. Analyzing such measures can offer valuable information for enhancing the network's performance. It can be calculated using Eqs. (5) and (6).

PDR $(\%)=\frac{\text { No.of Packets Received by Receiver }}{\text { No.of Packets Sent by Receiver }}$           (5)

where,

Packets Received is the number of data packets successfully delivered to the receiver.

Packets Sent is the total number of data packets transmitted by the sender.

It also measures the number of packets dropped by nodes due to various reasons.

Packet Loss $=$ No.of PacketsSent No. of Packets Received              (6)

where,

Packets Sent is the total number of packets transmitted by the sender.

Packets Received is the number of packets successfully received at the destination.

It has been observed that in the proposed P-STRIDE data, in the case of a normal connection, which is near 100%, the initial 2% loss is due to path selection and connection delay, and Time-To-Live (TTL) parameters common in all the networks; it is an ideal state. As the traffic is increasing, OpenFlow POX fails to generate the ideal results as depicted in Figure 10, and due to late or poor detection of attacks, it falls at a rapid rate.

Throughput (T) is the count of data packets successfully delivered from source to destination per unit of time, as visualized in Figure 11, and it is calculated using Eq. (7).

$T=\frac{1}{n} \sum_{i=1}^n \frac{b_i}{t_i}$           (7)

where,

b_i = Total amount of data.

t_i = time taken for a destination to get the final packet.

n = total no of application traffic.

The equation calculates the average throughput across multiple application traffic flows, where each flow may have different data sizes and transmission times. It provides an overall measure of how efficiently data is being transmitted in a system with multiple applications.

A high ratio of unsuccessful message delivery in the existing method also degrades performance in terms of throughput. Figure 12 represents the throughput at different times with varying network traffic rates. As the packet sending rate increases, the traffic rises, and throughput on account of P-STRIDE has minimal impact on the attack.

Figure 10. Packet delivery ratio (%) m PSTRIDE with OpenFlow POX

Figure 11. Throughput

Figure 12. Throughput rate in PSTRIDE with OpenFlow POX

Our maximum achievable data transfer rate, even under network congestion conditions with an increased packet load, exhibited only a marginal decrease in throughput from 0.67 to 0.58 when the data rate was increased from 80 to 100. However, under the same conditions, OpenFlow POX experienced a substantial throughput drop from 0.51 to 0.32. Additionally, in scenarios with higher packet loss due to congestion, the necessity for retransmissions consumes extra bandwidth, leading to a significant degradation in throughput.

It is defined as the average time taken by data packets to propagate from source to destination across the network and is calculated using Eq. (8).

$\begin{aligned} \text { End End Delay } & =\sum(\text { Arrived Time } - \text { Sent Time })\end{aligned}$         (8)

where, Arrived Time is the time at which a packet reaches the destination.

Sent Time is the time at which the packet is transmitted by the source.

The average delay, as shown in Figure 13 are calculated based on the following Eq. (9).

Average Delay $=\frac{1}{(\mu-\delta)}$          (9)

where,

$\mu$: Packet service rate of the system (packets per unit time).

$\delta$: Packet arrival rate to the system (packets per unit time).

where, μ is the number of PPS and δ is the average at which packets are arriving. End-to-end delay is observed to be initially the same with a marginal difference in the case of P-STRIDE and existing, but with the increase in traffic and attack rate, delay margins in both increase. P-STRIDE has given better results in terms of reduced delay time, even at heavy load timings.

Figure 13. Average delay in PSTRIDE with OpenFlow POX

OpenFlow POX works well when there is no attack, and normal average traffic, too, is comparable to P-STRIDE, as shown in Figure 14. The average Normal flow is less in P-STRIDE due to flow rules modifications in the OpenFlow Table Flow entries. TTL and flood policies control the flow entries in P-STRIDE.

OpenFlow works well when there is no attack; however, during an attack, flow table entries in OpenFlow rise significantly. As the P-STRIDE POX controller protects network hosts during the attack, the traffic in the network utilizes 25% flow tables, as depicted in Figure 15. Timely action on the part of the P-STRIDE Controller controls the network's unnecessary traffic flow and congestion.

CPU usage refers to the business of the CPU in performing the network traffic-related issues. The more CPU Usage by any process, the lower the performance. The CPU will be busy solving the process-related task and will have less time for other processes. In the case of P-STRIDE, due to the low number of flow entries in the OpenFlow table during normal traffic, CPU usage is low, which in turn means better utilization of the CPU as reflected in Figure 16.

CPU utilization is effective in P-STRIDE even in the case of attacks. P-STRIDE does not consume all the CPU time for its operations. The CPU gets free and can execute several other processes. On the other hand, OpenFlow POX consumes almost 59% of CPU time as depicted in Figure 17 in detecting the attack and maintaining flow table entries, which badly affects the CPU's overall performance.

Network usage refers to the business of Network resources, such as paths, firewall, router, etc., in performing network traffic-related issues. The more network resources usage by any process, the lower the performance is. Network resources will be busy solving the attack-related task and have less time for other processes. In the case of P-STRIDE, due to early detection of an attack and a low number of flow entries in the OpenFlow table during normal traffic, Network usage is low, which in turn means better utilization of Network resources as reflected in Figure 18.

Network Resource utilization is effective in P-STRIDE even in the case of attacks. P-STRIDE does not consume all the network resources for its operations and activities. Network resources are easily available and can work on correct and authenticated traffic. On the other hand, OpenFlow POX consumes almost 56% of Network resources as depicted in Figure 19 in detecting the attack and routing flow table entries, which badly affects the network's overall performance.

A comparative analysis of average delay under different types of flooding attacks (TCP/SYN, UDP, and ICMP) has been conducted between OpenFlow POX and P-STRIDE. The results, presented in Table 3, demonstrate that P-STRIDE operates in real-time detection mode, significantly reducing the average delay compared to OpenFlow POX, which incurs noticeable delays, thereby impacting network performance. Furthermore, OpenFlow POX does not address certain STRIDE threats, such as Spoofing, Repudiation, Information Disclosure, and Elevation of Privileges, whereas P-STRIDE efficiently mitigates these threats using OpenFlow table entries.

Figure 14. Average traffic flows during normal flows

Figure 15. Average traffic flows during the attack

Figure 16. CPU usage for average traffic flows during normal traffic

Further, we have compared P-STRIDE with Self-Organizing Map (SOM), a widely used approach for DDoS detection that classifies attack patterns using 4-tuple and 6-tuple feature extraction from OpenFlow table entries. A dynamic adaptive behaviour to handle the adversaries is noted for cross-validation techniques in terms of 6-tuple SOM with parameters source IP, destination IP, source Port, destination port, protocol, and port size, and 4-tuple SOM with parameters source IP, destination IP, source Port, and destination port. As shown in Table 4, P-STRIDE achieves the fastest detection time (135 ms), significantly outperforming 4-tuple SOM (271 ms) and 6-tuple SOM (352 ms), demonstrating its efficiency in detecting and mitigating DDoS attacks in SDN environments.

Figure 17. CPU usage for average traffic flows during the attack

Figure 18. Network usage for average traffic flows during normal traffic

Figure 19. Network usage for average traffic flows during the attack

The more time a method takes to detect the attack, the poorer the performance in terms of utilization of network resources, CPU usage, network traffic, latency, etc. Renowned 4-tuple and 6-tuple SOM classification takes more time, i.e., 271 ms and 352 ms, respectively, compared to 135 ms in P-STRIDE as depicted in Figure 20. This detection time has improved other quality measures and has proved its suitability in terms of various STRIDE attacks.

Table 3. STRIDE threats used in existing and proposed work

Note: Transmission Control Protocol (TCP); Synchronization (SYN); User Datagram Protocol (UDP); Internet Control Message Protocol (ICMP).

Table 4. DDOS detection time of P-STRIDE with 4-tuple and 6-tuple SOM classifications

Table 5 defines the complete detection rate for P-STRIDE and various SOM classifiers with 3 different OpenFlow switches. The Detection Rate is a measure of the accuracy parameter, how well the method identifies the attack if it prevails. False positives give a measure when the attack was not prevailing, and it was detected, which is an undesirable property.

The performance variations observed in Table 5 are attributed to dynamic traffic conditions and attack intensity differences across experimental scenarios. Specifically, higher packet loss and delay values occur during peak attack injection intervals, reflecting transient controller congestion before mitigation rules are fully enforced. These behaviors are consistent with SDN control-plane dynamics reported in prior studies.

An important measure in choosing is how well a method can detect the attack and how well on time. It accounts for the reliability and accuracy of a method. Various OpenFlow switch levels have been created to identify the rate at which a model can identify the attack. P-STRIDE in any situation with any number of switch levels has proven to be the best choice with a 98.76% detection rate in comparison to a detection rate of 67.08% and 66.86% with 6-tuple and 4-tuple, respectively, as depicted in Figure 21.

False positives are a measure that defines the detection of an attack in the absence of an attack. The accuracy of a method. 3 OpenFlow switch levels have been created to measure the correctness of the method. P-STRIDE in any situation with any number of switch levels has proven to be the best choice, with at least 0.34% false positives compared to false positives of 0.39% and 0.41% with 6-tuple and 4-tuple, respectively, as depicted in Figure 22.

Figure 20. DDoS detection time

Figure 21. DDoS detection rate

Figure 22. Distributed Denial-of-Service (DDoS) accuracy false positives

Table 5. DDoS detection time of P-STRIDE with 4-tuple and 6-tuple SOM classifications

Note: Distributed Denial-of-Service (DDoS); Self-Organizing Map (SOM).