Novel Approach to detect Anomalies using Defensive Algorithm in SDN flows

The exponential growth of network users has to lead to poor management of networks that use the traditional networking approach. Traditional networking approaches have become an overhead in terms of flexibility, innovations, complexity, and programmability among the network. SDN guarantees a holistic approach to network flexibility and programmability. Network visibility in SDN gives scope for rapid innovation. SDN being a new paradigm, less work has been done towards security. Security is one of the biggest concerns in SDN. Separation of control and data plane in SDN has to lead to the emergence of Denial of Service (DoS) attack. The centralized controller in SDN makes it the best target for attackers and acts as a single point of failure. Attacks on the SDN controller can bring the entire network down. This paper presents an approach to monitor traffic and we propose a novel method to mitigate these anomalies and attacks in the network. We believe that the DoS attack can be toned down using this new technique.


Introduction
Software Defined Networks is one of the prominent topics in the market these days. SDN is not only an academic dream and but also has tapped a strong foundation in the industry. SDN offers numerous opportunities like flexibility, scalability, monitoring, and fine-grained control for network management. Even though SDN can have physically distributed architecture but it still represents a network which is logically centralized controlled. SDN has a centralized console that manages the network traffic [23] dynamically as per the demands and requirements of the user. Traditional networking is built on a weak foundation and control plane 3 layers of abstraction. Networks need to be simple and SDN has made this possible. SDN architecture offers abstraction by decomposing network functioning into 3 different layers: Application, Control, and Data plane. The Data plane acts merely as a forwarding plane. The forwarding interface shields higher layers from forwarding hardware. The Control plane is the console controller that sets the rules in the flow table stored at a forwarding device. The application plane is responsible for load management, security, etc. problems. DoS disrupt the availability of services even to legitimate users. DoS is an attempt to overload the server by consuming its entire resources CPU, memory, or available bandwidth of the network. We have tried and believe that the DoS attack on the SDN controller can be detected and mitigated using an effective algorithm.
Some well known DoS attacks are: Types of DoS Data Plane DoS: This category of attack is done on the forwarding machine. It overwhelms the victim machine with a large number of messages leading to machine failure by exhausting its resources. UDP Flood: A large number of UDP framework packets are transferred to a random port on the victim machine to bring down the server. The attacker sends a stream of UDP packets to the target machine. Due to the low queue capacity of the victim machine; it overflows. The target machine will go down and won't be able to connect to the legitimate user. Mostly in these attacks, the IP address of UDP packets is spoofed to hide its identity. SYN Flood: In contrast to connectionless UDP, this attack uses TCP connection-oriented message to the target machine. A stream of SYN packets is sent to the victim. In this case, no ACK is returned to the target machine which causes the breakdown of the machine. HTTP Flood: A web server is flooded with a huge number of requests to a level where it is not able to respond to legitimate users. ICMP Flood: This attack exhausts the resources of the target machine by flooding it with a huge number of ICMP request packets, it keeps the server occupied in replying to fake echo requests. Control Plane DoS: In this attack, the attacker exhausts the bandwidth of the control plane. The Control plane is compromised by flooding of fake messages of an attacker. This flooding of fake messages paralyzes the controller and in turn, brings down the entire network. The paper is organized in the various sections as follows: Section II discusses an overview of related work done in SDN for anomaly detection and DoS attack. Section III of this paper describes the setup used and simulation DoS. Next Section IV illustrates the proposed model and open flow table management. Section V depicts a comparison between the existing and proposed model in terms of performance metrics. Conclusion and future aspects are drawn in section VI.

Related Work
DDоS аttасks and its detection methods have huge implications in terms of security of any network. Still, this area requires more exploration in context to SDN environments. Several recent pаpers [3][4] [5] also listed оut thаt the SDN соntrоller is а central tаrget оf DDоS аttасks аnd various measures are required to validate and verify the packets transmitted to SDN controller.
Also, very algorithms and techniques have been proposed for intrusion detection and DoS attack. For example, [1] focused on DoS attacks on switches, central console controller, northbound API, and southbound API, and [7] discussed decomposition of control and data plane & how SDN opens security challenges such as MITM, DoS, and saturation attacks. An evaluation of assertions on the flow table and its impact in terms of inconsistencies concerning a network security policy was done in [8]. How to develop a detailed security architecture that can offer security services in terms of enforcement of correct mandatory network policy for SDN [9] has been answered.
The art of SDN security and analysis of security issues concerning 3 layers was done by Zhaonang et al. [10]. They discussed several preventive and mitigation techniques. Many techniques [11] [12] provide flow detection & validation schemes but do not provide any confidence in them. An application that can block and detect DDoS to SDN [13] requires a two-way communication channel between DDoS blocking application and SDN controller server seeking protection. Various flow detection defects have been solved recently and its security architecture which can detect anomalies in the flow and an SDN environment was proposed namely [14] [15].
In summаry, Use rises, and capacity is denser in SDNs so basically SDN, in its full fulfillment, expels the gobetween layers, making the product what is organized. SDN has affected the OpenStack open-source cloud programming just as virtualization stages like VMware's, and now SDN is coming snappy and quick to holders. Solving the issue of DDoS and taking full use of SDN has become a challenging task. The existing аttack deteсtiоn аlgоrithms fоr SDN аre сhаrасterized by lоw accurate results аnd are pооr in timeliness.
Despite various work in SDN anomalies has been done still this area needs exploration as there is no strict solution to defend against DDoS attack on SDN. Our proposed algorithm is based on statistical analysis that has tried to select an apt feature for the attack.

Experimental Setup and Dos Simulation
For simulation purposes, mininet hypervisor installed on Ubuntu 14.04.4 OS, Secure Shell (SSH) is tunneled using putty for communication via windows platform to support secure network Graphical User Interface. Figure 4 illustrates the simple tree topology used for simulation purposes and Table 1 defines the used experimental setting for evaluating the performance of our proposed customized POX controller [25] [26].  Figure 5 shows where an ip address is spoofed and it generates traffic on port 80 for ip "10.10.1.3" with a view to overload the target with multiple messages which will exhaust the network bandwidth and will also lead to buffer overflow of a target in turn causing DoS.  Figure 6 shows the impact of the DoS attack which leads to a 97% packet drop rate and low or no connectivity.

. Defensive Algorithm and Ddos Switch
It's an automatic approach that ensures accuracy. Traffic statistics are collected, analyzing those statistics help in anomaly detection and to generate the plan of action to mitigate that attack. A controller handles the blocking and nonblocking flow table entries by the result analysis. Our algorithm works in two phases: Statistics Collection Module: Traffic statistics on the network are gathered. Traffic behavior is observed and compared with what is expected traffic by an IP i.e. its normal profile. In case of any deviation, a mitigation step is launched.
Mitigation and Report Management Module: Next step is launched with 2 things in mind: i) DoS on Controller ii) DoS on Data Plane i.e. a measure is found to identify either the attacker or the target who is the actual victim. Entries are made into blocking and non-blocking tables accordingly and appropriate action is taken to discard the incoming packets and shifting of the inappropriate load to the black hole.
Firstly, the controller initializes the Hash Flow Tables for blocking 'M' and nonblocking 'H' with entries. Custom DDoS_Switch [21] has been designed which is based on a customized POX controller [22] which upgrades the entries and smooth the functioning of the network. Figure 7 shows the blocking and nonblocking flow table entries set up by the controller on DDoS_Switch [24] after carefully analyzing the traffic and observing the normal flow from an IP.     11. Expected Latency in-network with the customized controller and Open Flow Controller Noted Facts: DOS: Packet Loss in the customized controller is low. We calculated the traffic at different amounts of time once there was a 16% drop rate. And later hardly 1% drop rate found. Bandwidth Utilisation: In the case of the customized controller is high as the drop rate is less. Latency Rate: low in the customized controller as found hardly 12 ms. Network Utilisation is high in the customized controller.