In this section, the vulnerabilities of SDN to LDDoS attacks are discussed. We have observed that papers of existing work discuss LDDoS attack detection mechanisms for specific SDN layers. For example, References [17,76] discussed LDDoS detection mechanisms for SDN application layer. References [77,78,79,80] discussed LDDoS detection mechanisms for the SDN’s control layer. References [81,82,83,84] discussed LDDoS detection mechanisms for SDN infrastructure Layer. Based on this observation, we developed a classification of SDN vulnerabilities for LDDoS attacks. In the following subsections, we describe vulnerabilities according to SDN architecture.

The malicious program might allow the attacker to gain illegal entry and cause wreak destruction by sending backflow requests to the SDN controller in an uncontrollable manner. The attack might cause connection loss between apps and controllers, bringing the entire network down in the worst-case state. The lack of standardization in security methods raises the likelihood of LDDoS attacks while also reducing the reliability and confidence between SDN controllers and the applications [76].

The application layer is vulnerable to various attacks carried out by dedicated tools such as DDoSSim [85], GouldenEye [86], H.U.L.K [87], Slowloris [88], and CloudFlare [89]. The success rate of IDS in detecting LDDoS attack from these tools is not high [17]. The threat from these tools needs ML algorithms that do not only look for forms to classify streams as legitimate or illegitimate. Rather, the kind of LDDoS attacks needs to use features such as connection periods and memory marks to obtain a more accurate classification.

SDN fosters creativity and programmability with northbound APIs that connect the SDN controller to applications operating across the network. It enables software designers in creating apps that allow the network to be programmable. This produces northbound APIs without widely accepted standards [90]. This gap is thought to offer vulnerabilities to a variety of security risks originating from trust concerns, app authorizations, and illegal application gain access. Because of these defense concerns, LDDoS attacks directed against the controller may produce congestion on the northbound interface. For instance, the LDDoS attack will utilize a bandwidth on the northbound channel; if a traffic inspection application listens in on Packet-In arriving from the switch in the direction of the controller, the network over time is overwhelmed [91].

LDDoS attacks are classified in this section into bandwidth saturation attacks and resource saturation attacks against the control layer. In this layer, attackers seek to consume SDN controller resources (e.g., CPU and memory). On the other hand, this consumes the bandwidth capacity of its channel. It is known to target an SDN architecture’s control channel, which is the southbound API, data channel, and northbound channel [92].

As mentioned in background section for SDN, the controller is a centralized component in SDN. Although this offers many advantages of SDN, it represents a single point of failure [93]. An LDDoS attack can cause significant damage across the SDN by targeting the controller with a resource overload attack. This attack, similarly to the control channel bandwidth saturation attack, achieves its goal by taking advantage of a vulnerability in the standard SDN design. In order to deal with spurious packets, the SDN controller sends rules and policies packets to network elements such as OpenFlow switches to drop these packets and track the sources of the sent IP addresses, thus draining the controller’s resources, such as CPU processing capabilities, RAM, physical memory, etc. [94].

The Control Channel, or Southbound API, connects the SDN controller to OpenFlow switches using the OpenFlow protocol. The controller provides network switches with decision-making capabilities for routing and regulating network traffic [95,96]. An LDDoS attack can target the control channel by making it always occupied since OpenFlow switches are dumb devices and rely on the controller for routing decisions and regulating traffic. Increasing the motivation of the switch to send query messages will lead to an increase in decision-making messages from the controller to the switch, which causes a control channel bottleneck [97].

Multiple controllers are used to extending the network when a single central controller is not sufficient to control network traffic due to the increase in the number of network adapters. These multiple distributed SDN controllers will connect through East–West APIs as interfaces. East–West API has no defined interface, and each controller must implement its policies and routing protocols [98]. As a result of this restriction, the interoperability area between many SDN controllers is constrained, making them vulnerable to an LDDoS attack by inducing multiple controllers to send recursive synchronous messages and, thus, flooding the east–west bound API channel.

This section describes the vulnerabilities of OpenFlow switches to LDDoS attacks. OpenFlow switch has issues such as flow table overfilling, packet buffer overflow, and flow entries timeout length. Because an LDDoS attack may target and exploit many vulnerabilities simultaneously, they are all inextricably connected.

A data channel is a connection that allows transferring the traffic between two or more OpenFlow switches. The data channel has a larger capacity than the control channel and has a large bandwidth [99]. Despite this, even though the impact of an LDDoS attack on data channel performance is currently unknown, an LDDoS attack can target it in several ways. An LDDoS attack may traverse through many switches before reaching the controller and entering the victim’s network. Various data channels or links between switches will be blocked by rogue packets, making them more or less busy as a result.

When the switch receives a new packet, it buffers the packet before forwarding only the header to the controller through a Packet_In message. The SDN controller determines the best path for evaluating the packets and sends them back to the switch as an output packet. The OpenFlow agent (OFA) receives the packet and adds new flow rules to the packet buffer flow and the flow table depending on the controller’s response. OpenFlow switches contain a low-capacity packet buffer flow [74]. Because of this limitation, LDDoS attackers may keep sending new packets to induce the OpenFlow switch to send the Packet_In message, which will consume and fill the packet’s buffer flow.

In the OpenFlow switch, each flow table has a flow entrance timeout process. A timeout specifies the lifespan, or period, of a flow account in the switch. Idle and hard timeouts are the two sorts of timeouts associated with flow entry. The flow entry will expire if no traffic is collected earlier than the idle timeout rate is reached if the idle timeout value is not zero [100]. Based on this, LDDoS attackers can exploit the lifetime of flow entries by analyzing the behavior of the flow table in flood attacks and then execute LDDoS attacks that continuously send a flow over a long time to mimic the behavior of a regular flow. Therefore, this malicious flow can pass without being detected by traditional detection mechanisms. The impact of the attack is limited to the switch because it exploits the timeout mechanism within the switch [78].

In the OpenFlow switch design, the flow table rules are stored in a high-cost memory known as TCAM (Three Content Addressable Memory), which is also restricted to holding only 2000–3000 flow rules in OpenFlow switches [101,102]. This shortcoming in the size of the flow tables attracts the attention of potential LDDoS attackers and makes them vulnerable to flooding. The switch sends an Opet_Flow_Mod_Failed error message with the fault code Ofpfmfc_Table_Full when there is not enough room in the flow table for more entries [103]. A study in [104] dubbed this vulnerability as a “TCAM exhaustion attack”. It examines the slow TCAM exhaustion technique, a one-of-a-kind variant of this method. Once compared to the TCAM over tiredness attack, this attack proceeds with UDP flow, which is much slower, while still filling the flow table and interrupting essential client services.

In summary, this section presented SDN vulnerabilities to LDDoS attacks at all SDN layers, including the application layer, north interface, control layer, south interface, and infrastructure layer, in the classification shown in Figure 5. Recent working papers [17,76,77,78,79,80,81,82,83,84] discuss SDN vulnerabilities for LDDoS attacks in specific SDN layers, but none of these papers provides a comprehensive and detailed analysis of all SDN layers. As a result, we found that SDN layers are vulnerable to LDDoS attacks that can exploit one or more of these vulnerabilities, including exploiting malicious applications, using offensive tools, saturating northbound saturation, saturating controller resources, overloading control channels, and overflowing OpenFlow switches.

We observed that machine learning is the most effective proposed LDDoS detection mechanism after investigating numerous LDDoS detection techniques. This part will discuss machine learning methods for detecting LDDoS attacks. We categorized machine learning-based LDDoS detection mechanisms into classification-based used algorithms. Such as (SVM, KNN, FCM, J48, RT, RF, MLP, FM, and NB) and deep learning-based use algorithms such as (CNN, RNN, and LSTM).

Classifying algorithms are frequently used as classifiers to identify LDDoS attacks in SDN for LDDoS detection. According to our findings, SVM, Random Tree, J48, REP Tree, MLP, SVM, and RF are the most often utilized classification algorithms in SDN for identifying LDDoS attacks.

An LDDoS Detection framework based on classification may be placed at a crucial node of an SDN, such as the SDN controller or the OpenFlow switch [105]. The framework consists of four main stages: data collection, feature extraction, classification model, and output. In the first stage, data collection consists of packet capturing, packet filtering, and dataset preprocessing steps. In the second stage, the feature selection and selection policy will be generated based on the previous stage; the feature value can be divided into stateless and stateful. In the third stage, the model is trained for the classification process to detect an LDDoS attack using several binary classification methods such as RF, SVM, J48, and test datasets. In the final stage, the user decision is made based on user-defined feedback, which is continuously taken to support periodic learning and testing of the model prediction process, correlation, and recognition of LDDoS attacks from regular traffic.

In [81], Zhijun et al. presented a protection mechanism based on dynamic flow rule deletion. They investigate the mechanism of LDDoS attacks on the SDN data layer to increase detection accuracy and then offer a multi-feature LDDoS attack detection method based on Factorization Machine (FM). The authors employ AUC (area under the curve) [106] as the primary metric of recognition performance, with recall rate, accuracy, and precision as supplementary indicators, to assess the impact of machine learning classification FM. The samples were separated into two groups: one for anomalous traffic and the other for regular traffic. The indicators were developed using the number of true/false positive and true/false negative groups. The dwell time is gathered and computed when the window function’s size is set to 20 s; the number of packets, RDMB, and RDPI to save every flow rule in the flow table by the window function; and the variance of the dwell time are calculated. To define the difference between attack and regular traffic, the data were identified based on the attacked port, and a total of 140,000 feature datasets were obtained. A total of 100,000 feature datasets were chosen as training datasets, with 40,000 feature datasets chosen as test datasets. The hidden vector dimension and the learning rate are the two parameters that most influence the machine learning algorithm FM’s performance. As a result, four different parameter settings with an average attack rate of 2.2 Mbps were chosen for the experiment.

The testing revealed that the approach could successfully detect LDDoS attacks on the SDN data layer, with a detection accuracy of 95.80%. The FM approach produces a stable environment for guarding against LDDoS attacks since it can identify fine-grained LDDoS attacks. With a 97.85% success rate in forwarding regular packets, it uses experimental simulation and analysis to demonstrate the defensive strategy’s efficacy. The NSL-KDD, DARPA98, and CAIDA datasets were used to assess performance in a simulated environment.

In [76], Phan et al. proposed Q-MIND: a machine-learning-based defense framework in SDN to defeat LDDoS attacks. The authors begin by looking at the adversary model for LDDoS attacks, as well as critical weaknesses in SDNs and characteristics of LDDoS attack. They describe Q-MIND, which includes the optimal strategy of the Q-learning proxy to defend against LDDoS attacks in SDN effectively. Throughout the training phase, the authors require a collection of labeled traffic data that includes both anomalous and benign samples. The authors use the Markov Decision Process (MDP) approach [107] to realize the optimal combination of a given feature set and performance for AI/machine learning algorithm detection. The MDP architecture allows AOS (Application Operator and Scheduler) to choose the best action (a mixture of features and AI/ML algorithm) based on its inputs to extend its immediate incentive in each loop. They have implemented ten features, including average packet size per stream, stream change percentage, port extension, etc. These characteristics are calculated for each source IP address using a traffic dataset with 8000 samples divided 50% for regular traffic and 50% for attack traffic. As a result, the Q-learning agent must train the detection mechanism and conduct validation tests. They design an optimization problem to find the best policies in scenarios where the immediate reward increases in each loop, using Q-learning to solve it. This method allows AOS to make the best choice without knowing a collection of features or the associated AI/ML technique beforehand. The Q-MIND framework provides results close to those obtained during the cross-validation phase with the optimal policy (close to 98%). To assess attack mitigation performance, the authors look at a fraction of malicious stream rules rejected in the switch and the web server’s request-response time when the network is under attack. Q-MIND achieves a high proportion of correctly downed attack streams because it enforces rules when it recognizes a source IP address emanating from an attacker.

In [17], JESS et al. proposed a modular architecture for detecting and mitigating LDDoS attack in SDN environments. They used six machine learning models (SVM, J48, Random Tree, REP Tree, MLP, and RF) to train their design and used the CIC (Canadian Institute of Cybersecurity) DDoS dataset with implementing ONOS controller running on the Mininet simulator [108]. Despite the challenges of detecting LDDoS attacks, the evaluation findings reveal that the approach has a 95% detection rate. The interface-based classification technique provides a classify object that defines a stream property with a classifier. The identification API offers a way for trained robots to interact with process flows. The classifier is a collection of learned machine learning models available in IDS. A sophisticated stream object gathers stream information from OpenFlow switches to determine if the traffic is an attack or a normal one. This flow complicated object’s properties are based on the flow table. IDS obtains a collection of stream parameters from the input request with traffic flow parameters and the output response with flow classification and then creates the model provided in the request. If the stream is considered to be anomalous, it uses the specified form to classify the input parameters before determining the type of attack. Finally, it generates an attack-type 1 data response or an attack-type 0 response, which it transmits to the IPS.

In [78], Cheng et al. proposed a learning-based technique for detecting LDDoS attacks on SDN control and OpenFlow switches in an IoT network context. The suggested approach is based on two characteristics derived from the OpenFlow package (stateless and stateless features). Learning techniques are used in the detection system to construct classifiers that distinguish between normal and attack flows. The approach trial’s evaluation architecture includes an LDDoS attack module, data flow collection, and feature extraction model. They put several learning algorithms to the test and distributed each feature in the raw data based on the platform. Two sets of stateless vectors and stateless features are created. A training set and test set are created from the produced feature vector dataset. The learning and detection phases of classification-based learning are then separated. Part of the dataset created in the preceding phase is used in each of these work steps. There is no intersection between the two datasets. The typical quantitative ratio for test datasets and the training dataset is 20% for the test and 80% for the training. The procedure employs binary classification methods such as SVM, NB, and RF. The experimental results showed that the model accuracy of detecting LDDoS attacks is 97% from the controller view of the network traffic.

In [77], Khamkar et al. proposed a framework to identify and defend against LDDoS attacks based on machine learning for the campus network. The framework consists of two phases: the network traffic acquisition module and the LDDoS attack identification module. The traffic acquisition module extracts network traffic features to prepare traffic identification for SDN network. They used the SVM algorithm and traffic features obtained from statistical flow table data to identify the attack traffic, demonstrating how LDDoS attacks may deplete controller sources and providing a way out to detect attacks with the changing of the target IP address. Traffic data were obtained from entries in the traffic flow tables. The traffic dataset includes traffic that denotes a TCP connection with eight features. These features are divided into two categories: Host-based and Time-based network traffic. The SVM model is built using LKF (Linear Kernel Function) and a decision function is obtained in order to determine how the packets should be sent. It is an LDDoS attack packet if the output of the function is −1; otherwise, it is a normal packet. The experiment yielded an accuracy of 0.998, indicating the effectiveness of the model. The model has a high detection rate for recognizing LDDoS attacks and is implemented as an LDDoS detection module in a simulated SDN context of a campus network. The controller drops packets that match the configured rule when an attack flow is selected.

In [79], Wencheng et al. proposed DIAMOND as a structured coevolution method to optimize features for LDDoS attack detection in SDN-enabled IoT networks. The method aims to find the optimal features to improve the detection performance of LDDoS attack detection methods. DIAMOND consists of a clustering algorithm to sort the achievable number, a commutation strategy, a group structuring method, and a co-crossover strategy. By analyzing the information about SDN-enabled IoT network features in the solution space, the relationship between various SDN-enabled IoT network features and the optimal solution is investigated in DIAMOND. Then, the individuals with the related SDN-IoT network features are divided into different subpopulations, resulting in a structure tree. Moreover, multiple structure trees evolve in coordination with each other. The evaluation results show that DIAMOND can effectively select optimal low-dimensional feature sets and improve the performance of the LDDoS detection method in terms of detection accuracy and response time.

DIAMOND is implemented on the SDN controller and collects network traffic by sending aggregated traffic instructions to the OpenFlow switches. It works as follows: Once the SDN controller receives the instructions, it sends OFPT_STATS_ REQUEST messages to the switches to obtain flow entry statistics. The switches respond to the SDN controller with OFPT_STATS_ REPLY messages. These messages contain stream data in the flow entries for the switches. After the controller receives OFPT_STATS_ REPLY messages, it deletes them and sends the collected statistical data to DIAMOND. The statistical data of the stream entries collected from the switches are used to calculate the initial SDN-enabled IoT network features. Then, these features are encoded using the binary coding method to generate the initial community, which consists of some individuals. The population is divided into several subpopulations by BONNET. The structuring factor is calculated based on the fitness and membership factors, which assemble the individuals in the subpopulation into a skeleton tree. Multiple skeletal trees evolve cooperatively with each other through mutation. After evaluation and selection, the dominant individuals are retained in the next generation. After several iterations, the individual with maximum fitness is identified as the best individual. Then the best individual in the corresponding feature set is decoded. Furthermore, to verify the detection ability of the optimized feature subset, eight different classifiers have been applied to evaluate the feature optimization methods (SVM, NB, LR, DT, C4.5, RF, and AB). The experimental results showed that DIAMOND has 92% accuracy in detecting LDDoS attacks from the controller view of network traffic and can effectively identify low-dimensional feature groups to improve the performance of the LDDoS detection method.

In [83], Tang et al. proposed a lightweight real-time Performance and Features framework to detect and mitigate LDoS attacks in an SDN environment. They implemented LDoS attacks in SDN, extracted traffic features using OpenFlow, divided all extracted traffic features into attack performance and attack features, and classified them into two categories. By analyzing the performance of normal traffic in the attack state, performance-based detection determines whether LDoS attacks will be effective by building machine learning models with normal and abnormal network state traffic features. Feature-based detection attempts to figure out the LDoS attack flow based on time-frequency analysis. Potential attack flows can be found by analyzing the morphological characteristics of LDoS attack flows with OpenFlow messages and flow table queries. Once the performance and features model ensures that the attack will take effect while the performance and features model detects the LDoS attack flow, the mitigation method is activated. The Performance and Features model locates the attackers’ source IP and the victims’ ports. Then it sends a defense rule according to the location result to filter the LDoS attack traffic. The authors conduct online and offline experiments to mitigate attacks on the SDN controller. The experimental results show that the proposed method achieves 96% accuracy in detecting LDoS attacks. The proposed framework can also mitigate LDoS attacks in real-time in an average time of 9.39 s with 0.02 to 0.04 CPU and low memory consumption.

In [80], Sudar et al. proposed a flow-based detection and mitigation framework using machine learning as a classifier to detect LDDoS attacks. The authors extracted the basic attack detection features such as flow duration, number of packets, the relative distribution of packet interval, and relative distribution of matched bytes using a flow management module. The mitigation phase is then performed, where the attack flow information is processed and mitigation rules are checked to avoid an LDDoS attack from the same source. To detect LDDoS attacks by examining the features extracted from the stream management module, the authors applied a machine learning model with SVM, Naïve Bayes, and a Decision Tree. They used the Scikit-Learn 0.23 library to classify the malicious traffic by using the output of the flow management module as input to the model. The mitigation phase is alerted to further process the attack packets when attacks are detected. After analyzing the traffic characteristics, the machine learning models return a value of 0 for regular traffic and 1 for attack traffic. The model forwards the corresponding source IP address to the blocklist table via the detection module as soon as the traffic is identified as malicious, i.e., when it is assumed that it might be an attacker. The mitigation module then alerts the OpenFlow switch to prevent the given stream by immediately creating a port blocking rule. In this manner, the authors hope to match the source IP address of each data stream with the entries in the blocking list table before redirecting them for further operation so that the installed traffic control rules remove them from the flow table after seven days. This process should help to analyze and update the data flow on a regular basis. Since data flow management and analysis are already part of the SDN architectural design, this model is unlikely to increase network traffic complexity. The accuracy of the performance evaluation was 93% for the classification of the traffic by the proposed machine learning model.

This section presents the implementation and deployment of classification-based LDDoS attack detection methods as well as the analysis of traffic and datasets used.

In [81], the authors carried out the experiment using a Mininet simulator and Ryu controller to set up an SDN network simulation platform. Under the simulation stage, the server targets the data layer with LDDoS attacks. Two actual hosts are utilized in this experiment. One of the hosts is in charge of operating Mininet. The other host is in charge of running the Ryu controller. The OpenFlow protocol, version 1.3, was employed as the southbound interface protocol in the experiment. The topology of the experimental simulation network uses a tree network design with 4 OpenFlow switches and nine hosts. The link bandwidth is set to 10 Mbps for all hosts linked with a delay of 5 ms, link loss is 0, and the maximum queue size is 1000. The experiment employs the D-ITG (distributed Internet traffic generator) to produce traffic in the background using The ITGSend, and ITGRecv commands on each host node to send and accept traffic. The authors used the CAIDA dataset and injected 100 flows into the network topology as a background flow. Among the 100 background flows, TCP streams account for 80%, ICMP 15%, and UDP 5%, with an average background traffic rate of roughly 1.3 Mbps.

In [76], the experiment uses MaxiNet [109] as a simulation platform and ONOS as the SDN controller. The authors established a simple SDN-based network with a web server and eight hosts. There are four malicious hosts and four benign hosts. All hosts and the webserver run in Linux containers connected by an OpenFlow switch. The authors consider three machine learning-based classifiers (SVM, RF-, and SOM). The feature used is created from 10 convenient features. These features are extracted from a traffic dataset containing 4000 normal traffic samples and 4000 attack samples for each source IP address. The dataset was generated from the conducting simulation experiment for stealthy DoS attacks and the CAIDA dataset. Accordingly, the Q-Learning agent is instructed to train the detection engine and perform cross-validation tests.

In [17], the authors implemented their scenario with one ONOS controller [110], three OpenFlow switches, five hosts, and one web server as a victim. The scenario implies that the attacker hosts have been infiltrated and are now part of the botnet, with each attacking computer capable of generating malicious traffic using the SlowHTPTest tool [111]. Legitimate hosts generate regular traffic with a pseudo-random function using curl targeting the webserver. The authors used the CIC DoS dataset, including regular traffic and eight low rate attack variations. They used the Flowtbag function to convert the packet data as traffic to adapt the dataset for SDN environments. It takes 44 features as input set and 44 features as output flows.

In [78], the experiment is conducted in a heterogeneous IoT network deployed on a Mininet simulator. The network topology consists of one physical switch, three OpenFlow virtual switches, and forty virtual nodes. All switches are connected to the Floodlight controller, and the nodes are connected to the switches; 10 nodes are normal nodes, and 30 nodes are attacking nodes. The link bandwidth between the nodes and the switches is 100 Mb/s. The dataset is generated in real-time during the experimental simulation collected on the Floodlight controller and the OpenFlow switches. The classifier was trained with 80% of the combined dataset of regular and attacking traffic, and classification accuracy was tested with a test set from the remaining dataset. The regular traffic includes HTTPS, HTTP, MQTT, ping messages, etc., while the attacking traffic includes a large number of TCP-syn and TCP-retransmission messages in addition to those included in the regular traffic.

In [77], the authors simulated the SDN environment to develop the detection model running on the Ryu controller and network topology with two OpenFlow switches and a web server used as a website. The KDD99 [112] dataset was used in the experiment. The dataset is divided into five key categories, regular, attack, Probe, U2R, and R2L, and utilizes 41 features to describe a connection. The authors’ primary focus is on HTTP flood attacks. As a result, data are represented using attack and regular traffic. As a data collection, TCP network connections are employed. The raw dataset is divided into a training dataset and a test dataset. Then the training dataset is used to build the attack detection model. Moreover, the best parameters are determined by repeated testing. The decision function is used to decide how to forward packets. If the output of the process is −1, it is an attack packet. Otherwise, it is a regular packet.

In [79], the authors used Mininet-Wifi to verify DIAMOND (the logic of the program) and evaluate its performance by implementing it on the Ryu controller. Mininet-Wifi is used to simulate an SDN-enabled IoT network consisting of eighty IoT endpoints, eight access points, and eight links. They simulated the background traffic of the IoT network, which includes 10% HTTP, 40% HTTPS, 10% TCP, 5% DNS, 10% SSDP, and 5% NTP. Attack traffic consists of traffic generated by 20 IoT endpoints to launch LDDoS attacks against IoT servers and accounts for 20% of regular traffic.

In [83], the authors set up the experimental topology on the Mininet simulator and built a topology with one Ryu controller connected to two OpenFlow switches (OpenvSwitch) and six hosts. The authors create a 10 Mbps bottleneck link between switch S1 and S2. For comparison, the bandwidth of the rest of the links is 100 Mbps with a delay of 20 ms. They used a Python socket to create five long TCP connections for a regular user group and used the Iperf tool to measure the bandwidth of the bottleneck link created by a short connection. They used two hosts as attackers and a UDP background generator. They considered LDoS attacks initiated by both TCP and UDP as a dataset. In a TCP-based attack, the attacker uses the TCP raw socket to create sudden congestion in the network. In a UDP-based attack, the attacker initiates UDP pulses and uses this protocol without congestion control to affect TCP directly. The duration of each set of experiments is 720 s, including LDoS attacks based on TCP and UDP for 3 min each. The default detection window is set to 10 s, and the sampling interval is 0.5 s. The construction of the detection window overlaps, and the subsequent detection window is created from a temporary sampling interval behind the previous detection window. Each set of data contains about 1440 detection windows. The training set includes two-thirds of the detection windows, and the rest are used as a test set.

In [80], the authors use Mininet to simulate the network topology with nine hosts and four OpenFlow switches. The hosts are configured as legitimate devices and offensive devices. All hosts are connected to the switches with a bandwidth of 10 Mbps. All switches are connected to the POX Python controller to simulate the control plane. To construct LDDoS attacks, they used the Scapy program [113,114] to generate a low rate attack by spoofing packet fields and a transmission rate of 1.6 to 2.2 Mbps. The CIC DOS 2019 dataset was used to train the machine learning model, with 80 features that provide statistical information about the streams. The Flowtbag method [17] is used in this work to convert traditional traffic states to flow states with the same set of features.

This section will present some of the challenges and limitations in classification-based LDDoS attack detection methods. In [81], the authors presented a protection mechanism based on the dynamic deletion of flow rules. They applied the mechanism of LDDoS attacks to the SDN data layer to increase the detection accuracy and provide multiple functions based on FM. Although the proposed mechanism has acceptable accuracy (95%) in detecting an LDDoS attack, it was derived from a small network simulation (four switches and nine hosts). Although the model targets the data layer, it does not consider the synchronization process at the data layer and the scenario of connecting to more than one SDN controller. Therefore, the proposed model may fail in large-scale networks where more than one SDN controller is deployed in the absence of a mechanism based on synchronization between SDN controllers and data layer devices. In [76], the authors proposed Q-MIND to detect LDDoS attacks using a reinforcement learning technique based on Q-learning. Throughout the training phase, the authors require a collection of labeled traffic data that includes both anomalous and benign samples. These characteristics are calculated for each source IP address using a traffic dataset with 4000 regular traffic samples and 4000 attack samples. As a result, the Q-learning agent must train the detection engine and conduct validation tests. They design an optimization problem to find the best policies in scenarios where the immediate reward increases in each loop, using Q-learning to solve it. However, compared to similar models, the cost of this method for implementation and training is very high. In [17,78], the authors have used various machine learning techniques to detect and identify LDDoS attacks and have indeed achieved high accuracy.

Nevertheless, these methods can increase controller overhead and decrease response efficiency when used on an extensive network. Analyzing the work [77], where the authors developed an SDN framework based on machine learning to identify and mitigate LDDoS attacks. They utilized two aspects of the system (traffic collecting and flow table delivery). They used the SVM algorithm and traffic characteristics obtained from statistical flow table data to identify the attack traffic. However, the method identification process of determining the feature obtained from the flow table allows the SDN controller to write effective new rules to prevent LDDoS attacks is not addressed, which is essential for efficiency and network connectivity. In [79], the authors proposed DIAMOND as a structured coevolution feature optimization method to detect LDDoS for SDN enabled IoT networks. They used the group structuring method, counting strategy, and the intersection strategy to sort the count. The authors presented the method’s shortcomings, as it does not provide a solution for forming sub-populations that build the individuals into a hierarchical tree. Moreover, the excessive load on OpenFlow switches by querying statistical data from flow entries increases switching overhead and decreases responsiveness to regular traffic. In [83], the authors proposed a detection and mitigation framework for LDoS attacks in SDN. The performance and features framework considers both attack performance and attacks flow features for LDoS attack detection decision. They performed a joint detection approach based on two aspects and implemented a real-time mitigation system to defend against LDoS attacks based on an SDN controller. However, the authors testify that feature classification and selection still need improvement. In addition, the framework forces the controller not to install new rules for the upcoming traffic during LDoS attacks, which results in the legitimate user experiencing more delays when the network is attacked. In [80] the authors proposed their detection mechanism uses four features (duration of the flow, number of packets, relative distribution of matched bytes, and relative distribution of the packet interval) of the network flow. Once the module detects the LDDoS attack, it adds specific details of the attack flow to the blocklist table. It warns the controller to remove a particular flow from the flow table by entering mitigation rules. Although this model reduces resource consumption, it has a high false-positive rate for traffic flows such as ICMP.

Although the discussed methods show high accuracy in detecting LDDoS attacks, no work indicates the implementation steps and the feature selection process. Therefore, there is still a need to exploit the characteristics of the SDN against LDDoS attacks and to develop detection models based on machine learning with a high true-positive rate and a low false-positive rate for all traffic features. In addition, an effective extracting feature model must be provided for SDN traffic and dynamically updated to improve LDDoS detection mechanisms.

CNN (Convolutional Neural Network), RNN (Recurrent Neural Network), LSTM (Long Term Memory), and other deep learning models have been applied to increase SDN protection against LDDoS threats [82,84]. Feature extraction is automatic in deep learning models [115]. The general structure framework for deep learning-based LDDoS attack detection mechanisms is similar to the machine learning classification-based framework. However, in the case of a deep learning-based model, selecting features is performed automatically.

In [82], B. Nugraha et al. present an ensemble convolutional neural network solution for LDDoS attack based on deep learning. To detect LDDoS attack in SDN-based networks, the authors suggest CNN-LSTM, a hybrid Convolutional Neural Network-Long-Short Term Memory model. Custom datasets are utilized to evaluate the strategy’s effectiveness. The results are impressive; all of the studied performance metrics have a value greater than 99%. The hybrid model CNN-LSTM outperforms traditional deep learning approaches comparable to MLP (MultiLayer Perceptron) [116] or 1-class SVM [117]. The detector unit in this deep learning-based model evaluates the extractor unit’s output and determines whether the entries are classed as harmful or harmless traffic. As a result, it functions as a binary classifier, classifying malicious traffic as “1” and non-malicious traffic as “0”. The labels are connected with the original IP address since a single host might be authentic or fraudulent. In depicting the hybrid CNNLSTM model used in the detector module, the pointers ×1, ×2.., ×n relate to the features associated with each entry.

In [84], W. Sun et al. developed a technique for detecting LDoS attacks based on the hybrid CNN-GRU model: Convolutional Neural Network (CNN) and Gated Recurrent Unit (GRU). This work is based on the three main stages of the LDoS attack detection process. The values of variables such as n packets and n bytes are retrieved from the base traffic flow in the first stage, and the average number of packets and bytes is gathered as input data for the combined model. The model enhances detection performance in the second phase by refining the Sailfish method to automatically adjust the CNN and GRU hyperparameters throughout the training process. In the last step, the model employs the CNN hyperparameters and the improved GRU to extract the input data’s deeper spatial and temporal aspects to identify LDoS attacks accurately. These stages gradually improve the manual setup approach to automatically identify the CNN and GRU metaparameters before introducing the Sailfish optimization algorithm to optimize CNN-GRU metaparameters. In addition to the nine field values collected from the flow rule. Given that LDoS data have the property of integrating Spatio-temporal features, the authors employ CNN and GRU to extract the spatio-temporal aspects of the data in order to detect attack flows.

The feature selection technology of the CNN-GRU model-based LDoS attack detection method is divided into three stages: feature selection, structure and parameter optimization, and attack detection. Feature selection is performed by requesting flow table information from the switch; the controller sends a flow status request to the switch and selects and develops input features for LDoS attack detection. In the second stage, the syntax is optimized using the ASFO method to optimize the CNN-GRU hyperparameters automatically. The individual population mode of the CNN-GRU model is a form of combining hyperparameters. In the final stage, the optimized CNN-GRU hyperparameter model is used to detect the attacks. Suppose the result of detection is an attack. In that case, the model sends instructions to the controller to change the flow table to the switch and change the configuration of matching elements in the flow table that discards the attack data packet to avoid risks. The most significant value of this model’s accuracy detection findings was 99.5%, with a false positive rate of 0.07%.

This section presents the implementation and deployment of LDDoS detection mechanisms based on deep learning as well as the analysis of traffic and datasets used.

In [82], the authors experimented with Minnet in a simulated environment where they created a small SDN topology and generated regular traffic and an LDDoS attack. They build a network topology scenario with one ONOS controller, two OpenFlow switches, a web server victim, six regular hosts and four malicious hosts. The authors used the Flow Collector module to generate regular traffic flows (which is responsible for requesting the flow statistics periodically through the REST API from the SDN controller). For generating LDDoS attacks traffic, they used an open-source tool Slowloris-HTTP [118]. In total, they generated 468,002,403 traffic flows, consisting of 355,758,086 regular flows and 112,244,317 LDDoS attack flows. The collected data are divided into 20% test data and 80% training data. The training datasets are then split into 20% validation data and 80% training data.

In [84], the authors used Mininet to design and simulate the network. The network topology contains 1 Python-based Ryu controller, 6 OpenFlow switches, and 21 hosts. They performed experiments using two datasets. The first dataset was collected from the network topology traffic, and the second dataset is CAIDA. Each data collection contains both the training and test sets. The Hping3 tool creates the attack traffic in the first dataset. The idle timeout is set to 10 s, and the attack period is set to 9 s. The data from the network traffic dataset are used to construct the regular flow. The second dataset comprises normal traffic and LDoS attack traffic, with a total of 79 parameters and an 80% to 20% training set to test set ratio.

This section provides an overview of the limitations of LDDoS detection mechanisms based on deep learning. According to our findings, the number of LDDoS detection mechanisms based on deep learning is lower than those based on classification. This could be due to the fact that classification-based LDDoS detection mechanisms have reasonable detection accuracy with lower computational complexity.

In any case, LDDoS detection mechanisms based on deep learning perform better than classification-based LDDoS. This is because learning-based LDDoS detection approaches have a more profound ability to extract traffic than classification-based techniques. Therefore, it can improve detection accuracy in identifying LDDoS attacks and obfuscation.

Various drawbacks or limits must be addressed when utilizing deep Learning to identify LDDoS. The first is that a deep learning model’s training period might be exceedingly long. As a result of the lengthy training period, the deep learning unit may have significant hardware needs. The second barrier is that several parameters must be given when developing a deep learning module. Using CNN as an example, the user should pick the optimal or sub-optimal parameters, such as the number of layers, neurons, filters, epochs, learning rate, objective function, and the weight configuration.

Analyzing the work in [82], we note that it has an apparent shortcoming in the use of test parameters since the evaluation of the detection framework was performed with offline datasets in a small SDN topology. There is also a limitation in traffic diversity as the regular traffic flows are limited to UDP and HTTP, and LDDoS attack traffic flows are HTTP only. Moreover, since the work uses CNN-LSTM based on deep learning, the training performance requires a long time when we compare it with classification-based methods. This is because the hybrid CNN-LSTM model requires a 3D data format as input [119], so the dataset needs to be transformed accordingly.