Encountering distributed denial of service attack utilizing federated software defined network

ABSTRACT


INTRODUCTION
The use of online services is increasing, making it easier for attackers to find targets to achieve their goals.A very effective attack on online services is the denial-of-service attack (DoS) or the distributed form of it (DDoS).This attack can last for days, weeks, or even months, and can cost companies in average about $1.6 Million USD and others about $20,000 USD per day.DoS and DDoS attacks aim to prevent employees and customers from reaching services provided by the servers and can have catastrophic consequences if the attack takes place in servers providing healthcare services or emergency services [1].On October 21, 2016, a stream of distributed denial of service (DDoS) attacks involving tens of millions of internet protocol (IP) addresses had been noted and attacked dynamic domain name system (DNS).The magnitude of the attack was claimed to be 1.2 Tbps and it involved internet of things (IoT) devices.To restore trust, researchers should investigate different methodologies to limit the consequences of the attack on victims and providers [1], [2].The following is a summary of some techniques used to mitigate the danger of DDoS.Some studies categorized the attacks by the nature of the targeted part of the system, such as cisco, where it classified the attacks into: i) volume-based DDoS attacks: the attack targets server resources and facility bandwidth, networking equipment; ii) application DDoS attacks: this type of attack overwhelms services (i.e.voice over  ISSN: 2088-8708 Int J Elec & Comp Eng, Vol.14, No. 1, February 2024: 574-588 576 combined them in a "time-efficient, lightweight system" (DETPro) that incorporates both methodologies.DETPro can detect DDoS attacks accurately in the early stages, defend against DDoS attacks effectively, and safeguard the network, according to the testing results from the research they presented.
Sanjeetha et al. [16] focused in their research on DDoS attacks on primary victim servers flooded by high traffic.DDoS attack can be instigated on a primary server present in SDN during high traffic scenarios.The purpose of their research is to show how attackers can use a mechanism designed to deal with flow table space exhaustion in high-traffic conditions to conduct a DDoS attack on a primary server via the controller.They next attempted to detect and separate the assault flow from normal traffic.
Finally, they safeguard the core server against controller-initiated attacks and resource risks.Their work is mostly focused on improving DDoS categorization methods, with the following contributions: First, after being trained by a self-organizing map (SOM).They offer two approaches with different trade-off priorities for classifying normal and DDoS attack traffic a SOM distributed-center classification approach that is employed when SOM training is complete.This heuristic technique achieves a quick processing time while maintaining an acceptable level of accuracy.Second, they offer an SDN-based DDoS attack detection platform that has been built in a testbed utilizing SDN switches.This testbed allows the system to estimate the accuracy and processing time of several algorithms, as well as compare them.
Nam et al. [17] focused in their study on identifying DDoS attacks, which have been a long-standing issue in network security.They used two approaches with distinct tradeoff priorities to categorize regular and DDoS attack traffic.To have a faster processing time and a more precise detecting method, as well as to assign different priority than existing detecting algorithms, they included four new SDN controller modules: monitor, algorithm, alert, and DDoS mitigation, as well as a lightweight SDN-based DDoS detection and mitigation architecture.The entropy of the source IP address (etpSrcIP), the entropy of the source port (etpSrcP), the entropy of the destination port (etpDstP), the entropy of the packet protocol (etpProtocol), and the total number of packets were then examined and categorized to detect distinct types of DDoS assaults (totalPacket).When given different priorities, traditional detection algorithms have been demonstrated to perform worse than the proposed techniques.They addressed some of the issues that researchers investigating DDoS attacks encounter, such as the similarities between DDoS attack and regular traffic patterns, the spread of big DDoS attacks powered by IoT bots, and the attributes that are manually picked for each type of host and each type of attack.
Ubale and Jain [18] investigated the SDN centralized functionality issue, which makes it vulnerable to TCP SYN flood attacks, which degrade server resources and transform the controller into a single point of failure by exhausting controller resources.Additionally, it causes a data plane saturation attack.The researchers used two functional modules: the hashing module and the flow aggregator module, to avoid TCP SYN flood DDoS attacks in SDN settings, address security issues such as ternary content addressable memory (TCAM) exhaustion attacks, and overcome the disadvantages of standard SDN, and the (OPERETTA and SLICOTS) modules that is implemented in the controller to investigate SYN flood attack.They addressed the problem by first proposing their (SRL) hashing module, a competent and streamlined framework for mitigating TCP SYN flood attacks that is implemented in the controller, then installing permanent forwarding for requested connections and after handshake completion SRL moves user to Whitelist and using hashing module to replace flow rules from flow table according to priority of hash value.A flow aggregator was used to stop the malicious connection requests.They were able to detect a slow rate DDoS attack by limiting TCP connection requests.Finally, SRL was implemented in the Floodlight controller under various attacking and usual traffic scenarios.According to their research, SRL has only a minor impact on SDN controller operations.If there was a difficulty, it permitted real users to connect, as well as recognizing malicious users who conducted a complete TCP handshake before beginning an attack.Using a prototype implementation of SLR, SRL performance and efficiency are compared to SLICOTS, OPERETTA, and standard SDN, revealing that SLR has a lower service delivery time for requests under attack, lower CPU utilization caused by regular traffic with many users, a lower number of real entries getting replaced before the attack, and the lowest DDoS attack detection rate.The main challenge is determining the threshold value; if it is too high, attack detection may be slowed, and if it is too low, erroneous findings may occur.
Aryal et al. [19] proposed a model for detecting DDoS attacks in 5G networks using SDN.A hybrid method is used, with five separate machine learning classifiers used to calculate a dynamic threshold.The proposed strategy is a hybrid approach that combines statistical analysis and machine learning.In an iterative process, data sets are evaluated and compared to a dynamic threshold.Sixteen features are retrieved, and correlation values between the features are examined using machine learning.With the deployment of SDN, the system provided dynamic configuration with software defined security (SDS).The traffic is constantly evaluated to improve the controller's efficacy in terms of task handling capacity.In terms of accuracy, precision, and efficiency, the suggested method outperforms current conventional approaches.In terms of Encountering distributed denial of service attack utilizing federated software defined … (Rima Abdelhadi) 577 outcomes, machine learning is also being used to improve detection precision.This improves accuracy from nearly 87% to 99.86% while lowering the false positive rate (FPR).The findings achieved using experimental data sets outperformed previous methods.Different machine learning techniques were employed for poor outcomes, and the findings showed that their model surpassed others in terms of accuracy and precision.Sharma [20] research discussed that configuring detection and prevention strategies were the current remedies for the DDoS attack.All solutions require pre-configuration and cannot be modified or accepted in response to changes in the network or the nature of the attack.This study attempts to propose a DDoS solution based on SDN architecture.Their goals were to allow networks to regulate their behavior and take appropriate measures when they were attacked, to measure efficiency and resilience against DDoS attacks and false policy-based attacks by comparing the architecture to filter-based intrusion prevention architectures, and to provide real-time monitoring and reactive service by combining management applications at the control plane in SDN with multi-agent system (MAS) and statistical modeling.Then it aimed to use the programmatic interface of SDN coupled with MAS to represent and reason knowledge about network topology and state, then to identify and avoid potential threats by using data flows rather than individual packets, and finally to control and manage large-scale networks with the least amount of downtime.The authors outlined the difficulties encountered during the research as follows: it is hard to recognize a real-world example in which an attack was discovered in SDN networks due to a lack of availability.Comparative research employing a common benchmark that has yet to be developed or established.The suggested agent-based self-mitigating architecture takes use of trade-offs between the timeliness and volume of load data exposed, as well as the efficiency and granularity of the control input required for quick reconfiguration.
Hyun et al. [21] maintain server stability by limiting the number of packets entering the server per second, without discriminating between legitimate users and botnets.Per the findings, network administrators and web administrators can use the SDN controller to adjust network packet flow based on the company's overall environment and specific network environment.Kalliola et al. [22] studied the DDoS flooding attack and the method to mitigate it with SDN by managing traffic.They established an approach based on learning traffic values and allocating appropriate resources to withstand the attack.The proposed approach is designed to protect both end hosts and network links from packet and bandwidth flooding assaults.The technique in this study allows optional input from external signature-based blacklist sources, as well as traffic management.The report stated that even when confronted with an overwhelming attack, the efficacy in preserving service was in the range of (50% to 80%).Blacklist integration and level of protection are two of the research's challenges: the method permits the integration of fixed or dynamic blacklists consisting of particular IP addresses.Because the defensive mechanism functions at the IP layer, attacks targeting higher levels are not covered.
Manso et al. [23] develop and deploy a software-defined intrusion detection system (IDS) that identifies and mitigates attacks at their source, assuring network infrastructure availability and sustaining the QoS even while an online service is already under attack.Their IDS detects DDoS-based cyber-attack scenarios automatically and limits them at the client level, reducing the negative repercussions of the attack's wider effect for possible victims, and then notifies SDN controller as soon as an attack is discovered.Their method additionally sends from the SDN controller to network devices some essential traffic forwarding decisions.An event is created whenever a substantial change in the traffic trend is noticed; if an event linked with a DDoS attack is triggered, an SDN controller produces flow rules to restrict the malicious traffic.According to the findings, their method right away detects a variety of DDoS-based cyber-attacks, mitigates their negative impacts on network performance, and ensures that normal traffic is delivered correctly while neutral traffic is protected.Their defensive technique would be most successful if it was installed as near to the attack source that creates rogue traffic as feasible, which would need coordination among many service providers to authenticate packet source addresses and apply other flow-based filtering capabilities.This analysis might be carried out by a federation of SDN controllers, one for each service provider.
Mousavi and St-Hilaire [24] focused on the hypothesis that SDN could be a single point of failure that could be attacked by DDoS.Such controller attacks will deplete the resources of the intended victim.
The proposed solution is a potential tool for early detection (when more than 500 packets are assumed as attack traffic threshold).The researchers relied on incoming traffic's randomness, where entropy refers to the probability of an event occurring given the total number of events, which in this case is incoming packets.
The proposed method is based on assessing the network's randomness; if one machine receives more traffic (regardless of the source of the traffic), the entropy will fall due to a lack of randomness on the network.The following two factors influenced their methodology; the Windows definition: where either the number of packets or the time interval were described as Windows, and the Threshold: within this window, entropy is calculated to determine the degree of uncertainty in the incoming packets.According to the study, the proposed method can detect DDoS attacks within the first 500 packets of attack traffic and can recognize both the controller and the targeted host.In a dynamic environment, human involvement is essential.Each time the network configuration changes, a new threshold and entropy must be calculated.The threshold is chosen experimentally, which implies that if the threshold is incorrectly set, several attacks may succeed, or legitimate traffic may be blocked.
Sahay et al. [25] proposed an automatic DDoS attack mitigation utilizing SDN.Customers can request DDoS mitigation services from ISPs using a distributed collaborative framework.ISPs can modify the label of aberrant traffic and divert it to security middle boxes upon request, while attack detection and analysis modules are deployed at the customer's end, avoiding privacy breaches and other legal issues.

PROBLEM FORMULATION
The network is illustrated using conceptual representation of SDN box (controller and switches).Connection between controllers does not mean a direct hard wire between them, but it represents a communication ability.Network representation or topology did not follow one common network architecture or design such as star or tree or any single architecture.
The representation will be a mix between them to show the problem with many possible complications.As shown in Figure 1, a victimized server located in network (v) is being attacked by bots located in networks (A) and (B).There are many possible routes between attacking bots and victimized server.Traffic oriented to victimized server will go through many SDN nodes that have enough capabilities to process traffic and communicate.Despite that all routers are transferring malicious traffic from bots to victim (v), routers can do nothing but passing the traffic if not classified as malicious traffic (traffic to drop).In one hand, the installed firewall on the victimized side must deal with all incoming traffic.On the other hand, network must be busy with malicious traffic (  ) that should not be transmitted through the network.The traffic directed to the victim machine (  ) is explained in (1), where the (  ) is the attack traffic from network x and (  ) is the legitimate traffic from any link l.
) + (  ) ∶    ℎ        "" The machine will be under attack when the sum of illegal traffic (  ) is much more than the legitimate traffic (  ) as shown in (2).although, it worth noticing that the legitimate traffic effect might be high in some applications, such as video broadcasting.However, attackers still send a very high volume of traffic to overwhelm victim servers.
) ≫ (  ): (  )  ℎ      "" (2) Our goal will be minimizing the total (  ) to maximize the chance of (  ), which is the legal traffic, to reach its destination (v).If that goal achieved, then the risk of the attack is minimized, and the victim (v) will have enough time to heal and recover from the attack while continue to provide service.The following section will explain the problem when SDN components used rather than regular switches and routers.If the distance between any group of bots attacking the victim (v) is given by (db) measured by number of hubs or controllers, traffic (t) will be much higher when getting closer to the victim (v), as explained in (3).
where (tx) is the malicious traffic toward (v) from bots (b), db-n is the distance getting less when (n) increase.The reason for this accumulation of traffic is the fact that many nodes will start to join traffic in the nodes close to the victim.We will be using this phenomenon to trace back the malicious traffic to the source.

PROPOSED SOLUTION
In our proposed solution, detection and prevention for DDoS attacks can be initiated either from the server side or from the controller side.Figure 2 shows the flow chart for both cases of detection and prevention.To coordinate and manage the attack mitigation process, we provided software called "agent".The agent job is to take discissions based on statistics provided by controllers.In the server-side agent, depends on frequent readings for metrics (CPU utilization, memory consumption and network traffic).If measurements showed that utilization levels are near to the maximum available resources' utilization with a very high network use, it will be an indication of DDoS attack, then the victimized server agent will notify the edge SDN controller by a flag representing possible positive diagnosis.Figure 2(a) shows the flowchart for detection and the stage where the server asks for the prevention process to be started by edge SDN controller.Servers normally suffer from the DDoS attack before getting detected by the network since the attack is coming from several sources.
The edge SDN controller is capable of doing diagnosis by measuring external traffic and bandwidth consumption against maximum known history.If there was a high traffic rate much higher than the usual known behavior or close to the maximum bandwidth available, then the controller is suspecting a DDoS attack and asking the server to initiate self-evaluation process and waits for its response, this detection flow can work effectively when victimized servers are powerful enough and detect the attack late.Figure 2(b) shows the flow chart for the designed detection process.However, the edge SDN controller will ask the victimized server to confirm the result the controllers found regarding the potential attack.
The evaluation process on the victim server (VSe) is expressed by (4), since the DOS attack goal is to prevent the server from providing service, we specified a threshold for each studied metric considered as the upper boundary for resource utilization before considered over-utilized.

ALGORITHM
Algorithm 1 shows the victimized server-side agent.The server agent job is to evaluate the victimized server status and communicate with the edge SDN controllers (the controllers whose job is to manage the routers and switches connected to the server or servers subject to attack "victimized").Lines (1-6) sets the acceptable thresholds on the simulated network.Each network has its own settings based on the nature of services running on the network; for example, gaming network has higher CPU usage than a network with database servers.However, a network with video streaming services will consume memory and network more than CPU.The variable "maxRound" in line 5 sets the maximum number of evaluations allowed for the server before sounding alters regarding a possible DoS attack.In line 12, the algorithm for the server agent tests the current CPU utilization, memory utilization, and network utilization against the maximum values expected.If either CPU or memory are highly consumed with a high network usage, the algorithm will count that as a positive sign (line 12.1). in line (12.2) if the total positive checks exceed the maximum allowed threshold, the line (12.2.2) will set the flag for possible attack to (TRUE) to indicate a possible attack.The algorithm will stop the evaluation for a while (line 12.2.6)after the controller managing the local network routers and switches.This "wait time" assumes that the controller will take an action and allow that action enough time to reflect on the server status.This time is adjustable as well.
In line (12.2.3) the server will get a feedback form the controller.The received feedback represents the network status of the outer network (outside the facility network).If the outer network has no high traffic and the server still getting high traffic from somewhere, then the server will raise a flag for a possible Internal DoS attack.In such case, the server must check for data theft (or very high information transfer rate) and investigate its legality.
Algorithm 2 describes the agent that runs on the SDN controllers participating in the network detection and prevention process.The edge SDN controller agent's algorithm checks the network traffic status by calling the predict high traffic algorithm (Algorithm 3) in line 2. If there was high traffic, the edge SDN controller agent's algorithm asks the victimized server if there was a possible attack alert due to a continuous increase in traffic detected and waits for its response.This notification will trigger the process of attack detection by calling the C2C algorithm (Algorithm 4) in line 3.1 which calls NDPA algorithm (Algorithm 5).Algorithm 3 predicts if there was unusual high traffic referring to network device traffic history and pre-set traffic threshold.Lines 1-6 of the algorithm is setting the initial values; each network can be configured based on its nature.For example, if the network is designed to carry backups at a certain time, then traffic tolerance factor (line 4) can be adjusted dynamically to avoid wrong detections.The maxSampleCount parameter controls the sampling lifecycle.The MaxTotal parameter keeps track of the maximum traffic known and detected in the history of the detection cycle for all devices the controller manages.The algorithm in line 8 iterates over each managed networking device (i.e.routers and switches) the controller manages and get the maximum traffic passed through the device and store it regardless the source or the destination.Lin1e 9 checks the maxTotal for the current round of sampling in addition to a pre-defined tolerance factor with the maximum known history.If the new readings are bigger than the history, then the algorithm starts counting that towards a cycle of detection (lines 9.1 and 9.2).Algorithm 4 calls the predict high traffic algorithm (Algorithm 3), if the return value was true which means high traffic detected, C2C algorithm will  The two previous algorithms (the server agent algorithm and the controller agent algorithm) collectively build a common opinion and negotiate it to predict the possible attack based on the traffic nature and the server status.If they predict an attack is about to happen or happening then the victimized server can call the C2C algorithm which starts the NDPA algorithm, and the edge controller can call C2C algorithm in line (3) which starts NDPA algorithm in line (2.1.1).The NDPA works by negotiating the maximum traffic allowed to pass reconfiguring switches and routers.

Algorithm 5. Network detection and prevention agent (NDPA)
The NDPA algorithm calls the predict high traffic algorithm (Algorithm 3).A "TRUE" returned value means high traffic detected.Thus, NDPA will start reducing the throughput of the ports by the limit ratio of 25% initially in line 4.1.1 or any other ratio specified by the engineers.As long as the high traffic is "TRUE" the throughput reduction will be increased by 25% each round as shown in line 4.2.NDPA will contact its neighboring controllers to check their network devices for high traffic by calling C2C algorithm line 4.3.1.
If the predict high traffic algorithm return value was "FALSE", which means traffic is not high or high traffic reduced; NDPA starts the network recovery to normal throughput levels as shown in lines 5-5.2.1 by increasing ports throughput gradually adding 25% back to the port each time.The NDPA algorithm will update the history list to new values.
It is worth mentioning that the NDPA algorithm, which is a network throughput reduction policy, applies only to a network connection that produces the highest traffic only in abnormal rates compared to its history.Other links and nodes in the network will not suffer from any reduction in throughput and will be served normally.This guarantees that only abnormal sub-networks or nodes causing undesired behavior will be affected by the reduction.

RESULTS
Algorithm simulation results showed the ability of the proposed algorithm to detect possible DDoS attacks in a tree topology network.As shown in Table 1, after observing the incremental nature of traffic volume causing the CPU to suffer high utilization, the server started negotiating traffic with the edge controller.At time 20 through 24 the utilization became very high, and the traffic throughput reached the maximum allowed amount.At that point the server started a positive detection process in collaboration with the edge controller.The detection process lasted for 4 cycles.In time 25 the controller started reducing the maximum amount of traffic by 25% to become 75% of the original throughput.Figure 3 shows the growing traffic flow toward the victim server, and the area between dashed lines A and B in Figure 3 shows approximately where the proposed algorithm started detecting a possible attack.Figure 4 shows the throughput of traffic in the local victim server network, where the dashed line A approximates the time when the NDPA algorithm decided to run a throughput reduction policy to reduce the possible malicious traffic.The area after dashed line B in both figures represents the drop in resource consumption due to throughput reduction enforced by the prevention algorithm (NDPA).
The zigzag behavior in Figure 4 indicates the areas where the algorithm assumes a possible recovery in server resources and tries to restore normal traffic gradually, however, when continuity in attack is detected, the algorithm enforces the throughput reduction again to insure providing service and server not to crash.The detection process lasted for 4 cycles.In time 25 the controller started reducing the maximum amount of traffic by 25% to become 75% of the original throughput.However, the problem is not solved because the server reported back a high utilization.The controller takes further steps to mitigate the high traffic by reducing another 25% of throughput and so on-going from 100% throughput to 75%, then 56.25%, 42.19%, 31.64%,23.73%, to 17.79%, and finally 13.35% of the original throughput which allows 11,676 kilobytes per second to be passed to the server.
In the second experiment, Table 2, it is assumed that the victim server and the edge controller have no previous experience with attack, no traffic history available for server or edge controller.However, the server will start working using the pre-set metrics or default and thresholds.The edge controller will assume that the server will be able to detect any abnormal levels of utilization and report it back through the controller agent.The controller then starts with the NDPA algorithm to limit the traffic after making sure that the reported metrics form the server are not due to internal attack from the server side.As shown in Table 2, the server reported back to the controller with attack detected in time slice 7. The controller started the process of limiting the traffic throughput to acceptable levels.In time 20, it is noticeable from the traffic amount that the attack stopped by the attacker.The detection and prevention method stopped and most importantly it restored the network ability to transfer more information by gradually increase the upper limit allowed throughput.and 6 show the analysis of the victim server and NDPA algorithm response to a temporary attack during normal high demand on server resources.This detection process in this scenario started from the controller agent side.The detection and prevention algorithm detected that before that and started reducing the network traffic to a level that the server can continue providing service as shown in Figure 5 in area A. in area B, the system was stable until the attack stopped around time 23.NDPA restored network throughput since the server is not suffering from over-utilization to normal levels as shown in Figure 5 area C. As shown in Figure 6, in time 13 the server was suffering from a potential DDoS attack, and server resources are over-utilized.In time 23 the NDPA algorithm was able to lower the throughput lowering the CPU utilization to acceptable ratio.Simulation results demonstrated that the proposed algorithms were able to detect and prevent the server from crashing and continued providing services despite the DDoS attack because the throughput reduction applied to all network routes that generate high traffic only.In the 3 rd experiment; we assume an attack traffic initiated from the neighboring network, then the attacker stops the attack.What is assumed that the NDPA should be able to detect the attack, limit the throughput, then when the attack is over, NDPA must restore the network throughput to its original values.This behavior must protect the sever form the bad traffic.As shown in Table 3, first router (Router0) managed by (Controller 2) is passing safe traffic.However, (Router1) is passing very large traffic and causing a DDoS attack symptom.However, traffic is coming from different sources and other networks.
At time 4, (Router1) experienced limitations imposed by the managing controller based on the commination and negotiation with the edge controller.From the table, it is observable that (Router0) did not suffer any reduction in the throughput due to NDPA control of traffic on the network.The edge-router throughput was reduced to be able to prevent any local high traffic on the incoming uplinks, though, the good about that is the local traffic will not be affected by the reduction since the new throughput will be more sufficient to pass the safe traffic through towards the server.Users might experience some delay, but the server will not crash due to high traffic.As shown in Figure 7, controller 2 monitoring and managing network 2 concluded that the routers in the network are passing very high traffic through.Meanwhile server is suffering the high traffic and reported it back to the edge-controller agent.In its turn, the edge-controller initiated a controller-to-controller communication (C2C) to track down traffic. it is noticeable Figure 7, in cycle 11, that controller 2 and just after implementing NDPA started observing lower traffic than before.This new traffic is a direct result of controllers implementing throughput reduction policy in routers they manage.

CONCLUSION
Software defined networks can be used to provide a variety of services, such as security, with a sophisticated design and separation of duties between components to prevent DDoS attacks.Basic assumptions made for this solution to work as intended are: The ability for controllers to communicate efficiently, controllers have some computational power, routers and switches throughput can be reconfigured, and controllers can get statistics about routers' traffic.As shown by experiments designed, the proposed solution and its algorithms managed to detect and the proposed solution was able to prevent a DDoS attack from overwhelming the server, orchestrate its work with controllers, detect if the attack was over, and restore throughput to its original values to elevate the QoS provided to customers and networks.

Figure 1 .
Figure 1.Scenario of DDoS attack in SDN managed network

Figure 2 .
Figure 2. Prediction and detection process starting, (a) from the victim side, (b) from edge SDN controllers


ISSN: 2088-8708Int J Elec & Comp Eng, Vol.14, No. 1, February 2024: 574-588 582 call the network detection and prevention agent's algorithm NDPA (Algorithm 5) and it will return a report of the network device's ID that has the high traffic to the calling algorithm.

Figure 3 .
Figure 3. Resources utilization before and during continuous attack

Figure 4 .
Figure 4. Throughput before and after attack detection

Figure 5 .Figure 6 .
Figure 5. Throughput recovery to normal after temporary DDoS attack

Table 1 .
However, the problem is not solved because the server reported back a high utilization.The controller takes further steps to mitigate the high traffic by reducing another 25% of throughput and so on -going form 100% throughput to 75%, then 56.25%, 42.1875%, 31.640625%,23.730469%, till 17.797852%, and finally 13.348389% of the original throughput which allows 11,676 kilobytes per second to be passed to the server.Very high normal traffic followed by attack traffic ISSN: 2088-8708  Encountering distributed denial of service attack utilizing federated software defined … (Rima Abdelhadi) 583

Table 2 .
Sudden attack with no previous history records of traffic