In a recent report by Gartner , 20.4 billion Internet of things (IoT) devices are expected to be in use by 2020, an increase of 219% from 2016. These devices have become popular in whole market segments, including consumer applications, cross-industry business, and vertical-specific industry.
This IoTization boom poses several challenges for IoT networks, including access connectivity, offloading computation, and security. In particular, lightweight IoT devices, which are typically characterized by low computing power, are exploited by attackers to generate flooding traffic in distributed denial-of-service (DDoS) attacks. For instance, a swarm of IoT devices, hijacked by Mirai malware, generated about 1 Tbps of DDoS traffic to a French webhost in September 2016 . These vulnerabilities pose serious challenges to IoT systems.
Consequently, networking infrastructures are evolving into heterogeneous IoT (H-IoT) networks, which are characterized by diverse IoT devices, multiple access technologies, and powerful computation provided at the edge tier, referred to as mobile edge computing (MEC) . Along with the softwarization capability of emerging technologies, such as software-defined network function virtualization (SDNFV), MEC-enabled H-IoT networks support a promising framework for H-IoT security. Security-as-a-service (SaaS) can be deployed with the support of MEC technology to prevent internal/external attacks from/to the H-IoT networks.
Based on the above analysis, we propose a DDoS prevention framework, called MECshield. MECshield utilizes MEC technology to provide localized smart filters against malicious threats at the edge of relevant attack-source/destination networks. A central controller orchestrates the cooperation among the smart filters through policy dispatches. The policies are generated based on attack-behavior analyses conducted at an attack analyzer in the central controller, before being dispatched to the corresponding smart filters at the attack-source sites. In each smart filter, a self-organizing map (SOM) component  is trained simultaneously using local traffic, under the supervision of the dispatched policy. The trained SOM detects malicious IoT traffic by matching the traffic features into the SOM map in order to identify whether it represents a DDoS attack.
Accordingly, the MECshield framework is characterized by:
Cooperation, where the central controller distributes the features of malicious traffic analyzed at the victim sites to the corresponding smart SOM filters at the attack-source sites via policy dispatches.
Distribution, where malicious threats are handled simultaneously at multiple attack-source sites and at the attack-destination sites. In other words, bottleneck problems, which are a crucial issue in DDoS attacks, are mitigated.
Local adaptation, where each smart SOM filter is trained using local traffic features collected from the H-IoT on which the smart SOM filter has been deployed.
There are three benefits of the MECshield framework:
Intermediate traffic reduction: Since smart SOM filters are deployed in front of the attack source, malicious traffic generated by H-IoT devices is typically blocked at the edge.
Detection and accuracy improvement: This is the result of two main features of MECshield: (i) continuous localized training, and (ii) implementation in proximity to the attack source and destination. The first feature adapts the smart SOM filter to time/position-varying H-IoT traffic. Meanwhile, the second feature provides two protection layers against malicious traffic.
Prevention performance increase: Owing to its distributed architecture, MECshield avoids the bottleneck problem typical in DDoS attacks. Moreover, the two protection layers at the attack-source/destination sites are supervised by the central controller for traffic handling orchestration.
Ii MEC-enabled Heterogeneous IoT Networks
This section describes the features of MEC-enabled H-IoT networks for determining their vulnerabilities (V1, V2, and V3) and resistance (R1, R2, and R3) to DDoS attacks; see Fig. 1 for the reference model. MEC-enabled H-IoT networks consist of various local IoT networks distributed at the edge and interconnected via the core infrastructure. The following features are derived from two distinguishing facets of the network: the heterogeneity of IoT devices, and external computation served by MEC.
Power-constrained devices (V1): Although IoT does not exclude high-power devices, those with constrained power in terms of computing resources and memory typically occupy the dominant position . Owing to their lack of computational power, these IoT devices may not support complex and evolving security algorithms, such as effective encryption for data transfer and endpoint protection against local security attacks. Furthermore, the weak security implemented on these devices (e.g., default and hard-coded passwords) means exploiting and recruiting them into botnets and injecting different types of malware are trivial tasks for even unskilled attackers (script kiddies).
Massive connections (V2): Billions of connected IoT devices generate massive volumes of data. This is an important ingredient for effective DDoS attacks. The traffic is usually generated from many constrained H-IoT devices. However, the same amount of traffic might also be generated from fewer powerful devices in other networks. These factors make H-IoT traffic containing malicious DDoS flows more difficult to handle than other network traffic.
Heterogeneous group-specific traffic (V3): H-IoT traffic is considered heterogeneous from a macro perspective, but group-specific from the perspective of each local network 
. In particular, IoT devices serving individual applications may be separately connected in different virtual local area networks (VLANs), which can be managed at the edge of the H-IoT networks. In general, each IoT application transfers data in its own way. As such, the generated traffic can be identified via a tuple of flow parameters, such as protocols, ports, transmission rates, and transmission contiguity. From a security viewpoint, the aggregated traffic at the attack-destination site is classified into a heterogeneous category, while the outgoing traffic from the attack-source sites is divided into a group-specific category. This classification is meaningful for the adaptive development of security strategies against malicious traffic.
Edge cloudization (R1): MEC technology provides cloudization capabilities at the edge of the H-IoT network. This is characterized by ultra-low execution latency and context-aware computation 
. This environment enables services such as resource scheduling, and security protection to be scalably deployed in proximity to the IoT devices. Therefore, comprehensive DDoS prevention, facilitated by the MEC, can be implemented in collaboration with advanced techniques such as machine learning and big data mining in a local context.
Service execution offloading (R2): Edge cloudization has enabled the increasingly popular service execution offloading in H-IoT. While lightweight IoT devices lack the powerful computation capability necessary for the timely execution of complex services, the networks are equipped with sufficient computational resources to provide tailored service execution on demand. This trend has resulted in traffic behavior that prioritizes local processing at the edge, rather than on Internet servers. Tracking this traffic behavior of each local network might help to detect security threats when abnormal traffic behavior occurs.
Contextual information fusion (R3): Although the traffic properties can be distinguished among local IoT networks, applications running at the edge may need to merge contextual IoT data to obtain comprehensive information. The relationships among contextual IoT data can be considered a criterion for abnormal traffic detection when individual partners defect . For instance, standard images are transferred from cameras to a surveillance system during the day, while thermographic images and motion detection signals are more useful at night. The traffic is considered abnormal when, for example, thermographic images are sent during the day, or standard images are sent at night.
Iii Security Problem Statement
This section analyzes the adversary models of two DDoS attack scenarios (a volumetric DDoS attack and an application layer attack) in terms of the attack objectives, initial capabilities, and process.
Objective: The objectives of the scenarios are as follows:
Scenario 1 – A volumetric DDoS attack on the infrastructure between users on the Internet and a data center. The objective is to send lots of bogus traffic generated from compromised H-IoT devices so that total malicious traffic size exceeds the capacity of the network. This is the most prevalent type of DDoS attack, constituting 73% of all DDoS attacks experienced in 2016 .
Scenario 2 – An application layer DDoS attack on a server. The objective is to flood the server with seemingly legitimate, but bogus requests in order to exhaust the ability of the application to serve legitimate users. This is a more sophisticated type of DDoS attack, and is difficult to detect because the attack traffic is not easily distinguishable from benign traffic. The number of such attacks increased by 95% between 2015 and 2016. .
Initial capabilities: In order to execute the attacks, we assume the adversary has the following capabilities:
Botnet: Access to a group of compromised IoT devices (H-IoT botnet). The adversary may be the owner of the botnet (botmaster), or may have access to it through a third party (e.g., a DDoS-for-hire service).
Command and Control (C2): A command and control infrastructure (C2), which is used to control the compromised devices and, possibly to recruit additional devices.
System Knowledge: Some knowledge about the victim, such as IP addresses, domain names, existing vulnerabilities, and so on.
Amplifiers: Poorly configured network services (e.g., Open DNS resolver), which the attacker can exploit to increase the volume of the generated botnet traffic. This capability is crucial for the attack in scenario 1.
IP Spoofing: Ability to spoof the source IP address of the botnet traffic. This capability reflects the amplified botnet traffic by sending it to the victim rather than the real source.
Attack process: The attack process in each scenario is described as follows:
Iii-1 Scenario 1
Botnet Activation: The attacker uses a controller to send commands to the H-IoT botnet. The instructions may include the victim’s IP address, attack rate, target service (DNS, NTP, and SSDP etc.).
Traffic Generation: The botnet is used to generate traffic using the above parameters.
Amplification: Some UDP-based network protocols have a high bandwidth amplification factor, which simply means they return very large responses for much smaller requests. For example, DNS has an amplification factor of 28 to 54, NTP has a factor of 556.9, and SSDP has a factor of 30.8 . This property is exploited by attackers in volumetric DDoS attacks, in which a large H-IoT botnet is used to send requests to these services in order to generate an enormous amount of traffic as a response.
Reflection: The source IP address of the botnet packets is spoofed and replaced with the IP address of the victim. Therefore, the amplified traffic is sent to the victim rather than to the attacker.
Network Disruption/Degradation: The network capacity is eventually exceeded by the amplified and reflected traffic, thereby degrading or disrupting the operations of the network.
Iii-2 Scenario 2
Botnet Activation: This process is the same as that in scenario 1.
Traffic Generation: At this stage, traffic is generated from each compromised device in the H-IoT botnet. The intent of the attacker is not easily discernible because the traffic conforms to all protocols.
Flooding: At this stage, the attacker floods the server with requests from each compromised device in the H-IoT botnet. There are three types of application layer flooding attacks: session flooding, where each device sends sessions at higher rates than those of non-malicious users; request flooding, where each attack session involves sending higher requests than those of non-malicious users; and an asymmetric attack, where each attack session contains requests with much higher workloads than those of non-malicious sessions.
Service Disruption/Degradation: The capacity of the server to respond to user requests is eventually exceeded, thus making the server unavailable.
Iv MECshield Framework
Based on the previously mentioned security problems, we propose MECshield, a novel DDoS prevention framework.
Iv-a Design Rationale
The rationale behind the MECshield framework design includes (i) utilizing MEC technology to provide distributed security agents in front of the attack-source/destination sites; (ii) well-adaptation to local traffic of the SOM filter at each agent with purpose of abnormal detection improvement; and (iii) cooperation among the agents, supervised by a central controller. The smart SOM filter in each MECshield agent simultaneously classifies outgoing traffic from IoT devices and is trained by local traffic, monitored in real-time.
Iv-B Self-Organizing Map algorithm
The SOM algorithm is one of the most effective unsupervised learning solutions in Artificial Neural Networks, which converts a higher-dimensional input space into a lower-dimensional representation called a SOM as illustrated on the left side of Figure2
. The SOM classifies a new input vector based on two main modes: training and mapping. The former builds the map using input samples, while the latter classifies new input vectors by finding a winning neuron which has the smallest Euclidean distance in the map. In this work, we utilize ak-neuron two-dimensional SOM, where the j-th neuron has a weight vector , within a dimension m, equal to the number of considered traffic features. Initially, the weight vector of each neuron in the SOM is generated randomly and the feature values in a training vector is always formed into an range. Thereafter, whenever an i-th training vector = arrives, the winning neuron is selected by finding the minimum Euclidean distance between the training vector and the neurons, as follows:
The weights of the winning neuron and its neighboring neurons (determined by a neighborhood radius function) are then updated to make them closer to the training vector.
Iv-C MECshield Framework
Figure 2 illustrates the proposed MECshield framework. Logically, the MECshield framework consists of a central controller and multiple agents located at the edge of each local network. The communication between the central controller and the distributed agents is facilitated via secure channels/protocols supported by the H-IoT networks (e.g., Openflow protocol on secure management channels in SDNFV technology).
MECshield controller: The main purpose of the central controller is to orchestrate operations among the distributed agents. A local network might act as the source or destination of DDoS attacks. Therefore, each local network requires a different smart SOM filtering strategy, based on its position in the attack scenario. For instance, an attack-destination site that suffers extreme flooding traffic should deploy an appropriate SOM training strategy to focus on the traffic protocol, port number, and flow number, including the IP address classes of the incoming traffic. Alternatively, the source site(s) of the attack should be more concerned with features of its outgoing traffic for individual sources, such as the protocol, port number, flow number, packet number per flow, and transmission contiguity. Thus, only the attack-source sites participate in DDoS defense. Therefore, cooperation among the distributed local agents is crucial for an effective defense. The components of the MECshield controller are described as follows:
Report collector: This component gathers traffic reports from distributed agents including traffic protocols, port ranges, volume or traffic flow quantity, source IP address ranges, and destination IP address(es). Adopting the requirements of the detection mechanism applied in the attack analyzer, the collected information is pre-processed and updated at the report collector before being transferred to the attack analyzer. For instance, to analyze the characteristics of a spoofed DDoS flooding attack, protocol, port range and volume are necessary for attack investigation.
Attack analyzer: First, DDoS attack detection techniques  are utilized to identify the attack symptom based on the processed information from the report collector. Once the attack is identified, further information is then considered to recognize attack targets, attack methods. For example, Smurf and fraggle attacks produce tremendous numbers of packets on some flows to exhaust the capability of the victim, while TCP SYN attacks establish large numbers of connections to the victim during a short period .
Policy generator: Once the DDoS attack is identified, primary policies are generated and forwarded to the MECshield agents located at the edges of the source and destination sites of the attack. The policies contain summary information of the attack (target, attack method and possible mitigation policies) and desired features. The feature information will be delivered to the feature extractor module via the local policy conductor at both source and destination site agents in order to request for desired extraction, which is used in the SOM classification process.
MECshield agent: The primary purpose of MECshield agents is to mitigate the DDoS traffic and the components of MECshield agent are as follows:
Traffic monitor: The main function supported by this component is to make the traffic statistics report. It regularly captures statistics of incoming traffic, including traffic protocols, service ports, volumes and source/destination IP addresses. This information is delivered to the report collector in the central controller. In addition, incoming traffic is also forwarded to the feature extractor in order to make the SOM map’s inputs.
Local policy conductor: Based on the primary policy dispatched from the controller, the local policy conductor informs the feature extractor about prominent features in order to make a tuple of features for each input vector in the SOM map classification procedure. Moreover, the local policy conductor will send mitigation information to the smart SOM filter agent to apply appropriate policies for attack traffic. For example, a drop action should be given to TCP SYN flooding attack flows because of the number of flow is huge and the packet per flow is tiny, meanwhile a blocking action should be applied for attack flows transferring a large amount of packet in a flow.
Feature extractor: This component extracts the features of traffic delivered from the traffic monitor and make tuples for the SOM inputs based on requirements of the local policy conductor. Then, it forwards these tuples to the smart filter agent for classifying and training.
Smart SOM filter: First, the SOM is trained continuously by input vectors transferred from the feature extractor. Second, when a vector of DDoS attack traffic is recognized at the SOM, the smart SOM filter notifies the switching/routing component. Consequently, a protection mode is activated and the outgoing traffic is switched through the filter. The protection mode is deactivated if the SOM does not receive a training vector of a DDoS attack within a pre-defined duration. Finally, mitigating the DDoS attack by dropping the traffic is classified by the SOM as malicious.
Switching/Routing: This is a basic function of edges used to handle incoming/outgoing traffic.
Iv-D Operational Workflow
To describe the operational workflow of MECshield, we consider a normal and a DDoS attack.
Under normal conditions, the protection mode is deactivated; that is, outgoing traffic from IoT devices bypasses the smart SOM filter to improve the networking performance. In this case, the traffic is still captured by the traffic monitor to extract features for smart SOM training and for traffic statistics reports (yellow lines in Figure 2). Whenever a DDoS symptom is detected by the attack analyzer in the controller or by the smart SOM filter in the local agent, the protection mode is activated.
In the DDoS attack condition, the outgoing traffic from IoT devices should go through the smart SOM filter. Depending on the classification provided by the filter, detected DDoS traffic is dropped. The traffic monitor collects statistics on the DDoS traffic, which it reports to the controller. After identifying the attack targets and attack methods, the controller dispatches primary policies to all agents distributed at the edge of the corresponding local networks. The local policy conductor in each MECshield agent assigns requirements to the feature extractor to generate appropriate training vectors, and it also informs the smart SOM filter about possible mitigation policies to tackle attack traffic flows. During attack time, the smart SOM filter still transfers incoming attack traffic (red lines in Figure 2) to the traffic monitor and the feature extractor to generate statistics and make training samples, respectively.
The security performance of the proposed framework is achieved through two layers of protection given by the MECshield agents at the attack-source and destination sites.
V Performance Evaluation
This section describes the experiment setup, and then provide an in-depth performance analysis of the DDoS defense system.
V-A1 Training data sets for the smart SOM filter
Initially, the smart SOM filters are trained using data sets of DDoS attack and normal traffic. The DDoS-attack training sets are obtained from three data sets: CAIDA-attack-traffic , NSL-KDD , and DARPA 2009 Intrusion Detection . The normal-traffic training set is derived from CAIDA-normal-traffic . Statistics of these data sets are provided in Table I.
|back, land, neptune,||45927||7458||41|
|pod, smurf, teardrop|
|Attack types||Attack source||Attack time|
|SYN flooding||100 different IPs||6 minutes|
Owing to the wide variety of H-IoT devices, we generalize the types of traffic into three categories:
Sensor traffic: This traffic is generated by sensor devices in a fixed period, with a low number of packets per flow.
Monitor traffic: This involves real-time traffic, characterized by a small number of flows and a significant number of packets per flow (e.g., camera).
Alarm traffic: This traffic type is not easily discernible because alarm IoT devices only generate traffic when an abnormal event occurs. However, we assume the alarm traffic has both moderate flows and a moderate number of packets per flow.
Therefore, only samples that belong to the three categories mentioned above are extracted from the CAIDA, NSL-KDD, and DARPA data sets to train the SOM filters. Accordingly, a tuple (protocol, port number, flow number) is applied for SOM training in the MECShield agent at the destination-site; at the source-site, a tuple (protocol, port number, flow number, packet/flow, transmission contiguity) is used. Then, each traffic type is trained by a set of 10000 samples. And, key parameters of the SOM map are as follows: neuron number is 400, learning rate is set to 0.1, and output dimension is 2.
V-A2 Emulation Setup
To emulate a distributed MEC network, we set up a SDNFV-enabled network of four physical servers. This comprises the MECshield controller and three MECshield agents directly connected to three IoT networks (sensor, monitor, and alarm) comprising both SOM filtering and switching/routing features. For convenience, we implement the MECshield agent as a software-based box including SOM, OpenvSwitch functionality and other modules. Furthermore, we can configure the OpenvSwitch agent to forward local traffic to a smart SOM filter before leaving the machine . Applications in MEC servers store IoT incoming traffic and send back to IoT clients a simple response message confirming receipt of the data.
V-A3 Testing Process
To assess the proposed framework, a test is carried out, along with two other schemes (a Centralized-SOM and a Distributed-SOM ). In the Centralized-SOM solution, a SOM filter is placed at the controller, and all H-IoT traffic is forwarded to the controller for analysis. Meanwhile, in the Distributed-SOM mechanism, the SOM maps trained by all agents are merged at the controller after the training period. Afterward, the merged SOM is returned to the agents for local traffic handling . Note that all solutions use the same training data sets. For each local IoT network, we use the BoNeSi simulator tool to generate different levels of attack traffic (50, 100, 200, and 300 Mbps) in all schemes.
V-B Emulation Results and Analysis
V-B1 Attack Reaction Performance
The first criterion is the attack reaction time at each edge agent. In this measurement, we record four different attack traffic levels, as depicted in Figure 3. These results can be explained as follows:
In the Centralized-SOM, there is a considerable delay because traffic is forwarded to the controller from the edge devices for attack investigation. Afterwards, policies are sent back to edges for appropriate traffic-handling operations.
In the other schemes, if the smart SOM filter at an edge agent detects malicious patterns, it immediately applies the determined policies to the attack traffic by preventing it from entering the distribution network. Therefore, the time taken to react to attack patterns of the MECshield framework and the Distributed-SOM solution are lower for all traffic levels.
V-B2 Detection rate and Accuracy Improvements
As a second criterion, we measure the detection rate and accuracy of three schemes. Figure 4 presents the detection rate and accuracy of the three approaches. In both criteria, the MECshield performed better than the other schemes. This is because SOM maps in the MECshield agents are separately trained by different local IoT traffic. Hence, these filters find it easier to recognize patterns or they are well-adapted to local IoT traffic in other word. Conversely, with a fixed and limited number of neurons in a smart SOM agent, if there are many traffic types trained for a SOM map (Centralized-SOM case), or several merging times in the case of a Distributed-SOM mechanism, the weights of each neuron in the SOM map will change considerably. This leads to the degradation of both the detection rate and the accuracy of these schemes.
V-B3 Bottleneck-Handling Performance
To assess the robustness of the schemes, we investigate the problem of bottlenecks occurring in the controller during our experiments. The results are shown in Figure 5. A major difference is observed between distributed and centralized solutions. Both MECshield and the Distribued-SOM show acceptable CPU usage of around 35%. However, the Centralized-SOM mechanism shows a high usage of the controller’s CPU (83%, on average); this is because edge node traffic is always forwarded to the controller for processing, which becomes the bottleneck during DDoS attacks.
V-B4 Overall CPU Resource Consumption
Finally, we assess the MECshield framework’s overall CPU resource consumption in the case of DDoS attacks coming from several IoT networks. We record the CPU usage of all machines and evaluate the average system resource consumption. The CPU usage of MECshield, the Distributed-SOM, and the Centralized-SOM are 36%, 43%, and 46%, respectively. As discussed in Section IV-C, we consider the IP ranges of incoming traffic. Therefore, depending on the IP ranges, the MECshield controller can inform dedicated agents to enable the SOM filter function in the case of attacks. As a result, the MECshield framework can save resources because of the limited number of running SOM filters. In contrast, the Distributed-SOM and Centralized-SOM schemes always have to enable all SOM filter agents. Hence, the computing resources are consumed, even if there is no incoming traffic.
In this study, we propose MECshield, a DDoS prevention framework that leverages MEC power to deploy multiple smart filters at the edge of attack-source/destination networks. MECshield enables the network to defend against malicious traffic from H-IoT devices through smart SOM filters deployed in front of the attack source. Experimental results show that the detection rate and accuracy are improved because of the well-adaptation to local traffic at the SOM filters. Moreover, the distributed architecture and control scheme of the MECshield avoids the bottleneck occurring in DDoS attacks, and saves around 10% resource consumption in terms of CPU usage compared to other methods. Finally, MECshield introduces an efficient and feasible security framework for an H-IoT environment.
-  Gartner, Inc., “Gartner says 8.4 billion connected ”things” will be in use in 2017, up 31 percent from 2016,” (cited Oct. 10, 2017). [Online]. Available:http://www.gartner.com/newsroom/id/3598917
-  C. Kolias, G. Kambourakis, A. Stavrou, and J. Voas, “DDoS in the IoT: Mirai and other botnets,” IEEE Computer, vol. 50, no. 7, pp. 80–84, 2017.
-  X. Sun and N. Ansari, “EdgeIoT: Mobile edge computing for the Internet of things,” IEEE Communications Magazine, vol. 54, no. 12, pp. 22–29, 2016.
-  T. Kohonen, “Essentials of the self-organizing map,” Neural networks, vol. 37, pp. 52–65, 2013.
-  J. Lin, W. Yu, N. Zhang, X. Yang, H. Zhang, and W. Zhao, “A survey on Internet of things: architecture, enabling technologies, security and privacy, and applications,” IEEE Internet of Things Journal, vol. 4, no. 5, pp. 1125–1142, 2017.
-  F. Alam, R. Mehmood, I. Katib, N. Albogami, and A. Albeshri, “Data fusion and IoT for smart ubiquitous environments: A survey,” IEEE Access, vol. 5, pp. 9533–9554, 2017.
-  Y. C. Hu, M. Patel, D. Sabella, N. Sprecher, and V. Young, “Mobile edge computing – A key technology towards 5G,” ETSI White Paper No. 11, 2015.
-  A. Aleroud and G. Karabatis, “Contextual information fusion for intrusion detection: a survey and taxonomy,” Knowledge and Information Systems, vol. 52, no. 3, pp. 563–619, 2017.
-  D. Anstee, P. Bowen, C. F. Chui, and G. Sockrider, “Worldwide infrastructure security report,” Arbort Networks special report – Volume XII, 2017.
E. Leverett and A. Kaplan, “Towards estimating the untapped potential: a global malicious DDoS mean capacity estimate,”Journal of Cyber Policy, vol. 2, no. 2, pp. 195–208, 2017.
-  S. T. Zargar, J. Joshi, and D. Tipper, “A survey of defense mechanisms against distributed denial of service (ddos) flooding attacks,” IEEE Communications Surveys Tutorials, vol. 15, no. 4, pp. 2046–2069, Fourth 2013.
-  T. V. Phan, N. K. Bao, and M. Park, “Distributed-SOM: A novel performance bottleneck handler for large-sized software-defined networks under flooding attacks,” Journal of Network and Computer Applications, vol. 91, pp. 14–25, 2017.
-  CAIDA, “The CAIDA datasets of anonymized Internet traces and DDoS attack,” (cited Sep. 10, 2017). [Online]. Available: https://data.caida.org/datasets/
-  NSL-KDD, “Data set for network-based intrusion detection systems,” (cited Sep. 10, 2017). [Online]. Available:https://data.caida.org/datasets/security/ddos-20070804/
-  LANDER, “LANDER:DARPA DDoS attack-20091105,” (cited Sep. 10, 2017). [Online]. Available:https://ant.isi.edu/datasets/readmes/DARPA-2009-DDoS-attack-20091105.README.txt