Keywords

1 Introduction

Many network applications, now-a-days are real time in nature. In a real time application, a good response time (efficient) and high latency rate of users requests are expected. Meeting the users expectations and needs of efficient response time is a major issue to be addressed in real time networks, where the traffic rate is also high, but it becomes really difficult to maintain a reasonable traffic flow in such applications when the unwanted software attacks are thrown to the system. These unwanted attacks make a network system slow or sometimes totally unavailable for its intended users. Our research objective is to address this Distributed Denial of Service (DDoS) problem in Software Defined Network (SDN) architecture.

Software Defined Network (SDN) has emerged in last two decades since 1990. Researchers were eager to make network programmable. In start, from 1990 to 2000, many small functions/scripts were developed to automate the network. From 2000 to 2007, researchers focused on separating control plane and data plane. In 2006, Martin Casado, PhD student at Stanford University in Silicon Valley developed something called Ethan. Later on, Stanford and University of California, Berkeley did a joint research and standardize protocol with the name of OpenFlow [1].

OpenFlow is an open standard that enables researchers to run experimental protocols in the campus networks. OpenFlow is used at commercial level and implemented by different vendors. It is embedded in different Ethernet switches, routers and wireless access points. It provides a research platform to run experiments without exposing the networks internal details. OpenFlow facilitates the researchers to innovate routing and switching protocols in networks. OpenFlow commercially being utilized in many applications like virtual machine mobility, high security networks and next generation IP based mobile networks [2].

2 Literature Review

Yao et al., proposed Virtual Source Address Validation Edge (VAVE), a method for securing network from spoofed IPs. They propose the use of OpenFlow devices rather than SAVI devices [3]. They pointed out that SAVI devices are good to detect spoofed IPs but each SAVI device is working independently without collaborating or using other device knowledge because they cannot communicate with each other, eventually which cause recalculation on each device again and again. In their solution, they were used OpenFlow devices with central controller and form a perimeter, when packets enter to perimeter, first OpenFlow device apply validation filters on packet using NOX controller, remaining all just used that information. Shin et al., proposed CloudWatcher, another network security solution that differ from VAVE. They proposed a simple scripting language to help network operators in defining policies. In this design, OpenFlow controller does not have any security module; instead they used other appliance for network security such as intrusion detection system. In this system, OpenFlow captures incoming network packets and forwards them to security appliances that inspect all of them [3]. Instead of OpenFlow controller, Kumar et al., proposed an OpenFlow switch for intrusion detection by adding two more tables for attacker IP (IDS IP) and signatures of malicious attacks. First they look into IDS IP table, if they found packet IP there then they simply drop the packet. If match is not found they look into IDS signatures table for checking its packet malicious or not. If packet found malicious they add it to IDS IP table for future use [4]. This solution greatly helps in: (1) Real-time packet inspection and validation, (2) Real-time attack mitigation, (3) Secure and intelligent network. On the other hand, this solution also impacts on: (1) Number of packets processing per second, (2) Traffic flow per second, (3) Cause bottle-neck in the network, (4) Significant impact on network performance.

Li et al. proposed DrawBridge, based on the assumption that if customer’s controller can communicate with ISP controller. This enables customers to subscribe for ISP’s traffic engineering service. Customer express its traffic engineering policies to DrawBridge controller in ISP, the DrawBridge controller further pushes these policies to SDN switches deployed in ISP network to filter traffic or another DrawBridge controller in the ISP upstream [6]. They preferred to throttle traffic rather than block attacking node and also suggest to install rules on ISP hosted OpenFlow controller. They are throttling traffic using OpenFlow protocol instead of dropping useless traffic. By this way useless traffic will be still coming in network and will be making resources busy in useless work. Based on same assumptions as DrawBridge, Sahay et al. proposed autonomic DDoS mitigation using software defined network. They proposed that DDoS mitigation can be autonomous application, as a service which can be consumed by customer network and multiple ISP networks. Both customer and ISP should have their own DDoS detection engine, can alert each other about attacks and use middle box mitigation application [7]. They proposed a novel change in the framework; this can greatly reduce the effort of developing mitigation application individually. But there will be chances of one-point failure.

Mousavi, researched on attack detection using controller rather than network because OpenFlow controller is back bone of SDN architecture. If someone targets OpenFlow controller by spoofed IP packets, then controller resources will be consumed by spoofed IP, it may cause out of service and by this way SDN architecture can be collapsed easily. He proposed entropy based light weight solution in the controller by just adding two code functions. But he does not focus on network. If someone attack all hosts in the network then this system will not be able to detect attack [8]. Mehdi et al., proposed traffic anomaly detection on SDN environment. They used multiple anomaly detection algorithms for validating their suitability in small office/home office environment. Author suggests that the decentralized control of distributed low-end network devices using OpenFlow, can efficiently detect network anomalies and limit network security problems. They left mitigation of detected network anomalies on their future work [9].

Braga et al., proposed a light weight DDoS flooding attack detection using NOX/ OpenFlow. They used Self Organizing Map (artificial intelligence) algorithm for dynamically identifying DDoS attack [10]. Proposals for secure SDN are not limited. Shin et al., focused on solution for developing and deploying complex OpenFlow security applications in much easier and rapid way [11]. Phaal et al., demonstrates commercially available network monitoring tool sFlow; which is helpful for monitoring traffic in data network containing switches and routers. sFlow uses sampling techniques for continuous monitoring site-wide traffic for high speed switched and routed network [12]. Rehman et al., has proposed a flow monitoring tool OF@TIEN for network wide traffic visibility using sFlow monitoring tool. SDN flow monitoring application gets slice flow definitions from OpenFlow controller, loads them into sFlow-RT, fetches summary statistics and feeds them to Graphite real-time charting tool. Our monitoring system also enables us to monitor GRE tunnels which are used to isolate traffic of tenant networks [13].

Looking at all above identified limitations, we have experimented an architecture with a combination of OpenFlow Northbound API, Kinetic (OpenFlow) Controller and sFlow (efficient network monitoring tool) with much higher network traffic up to 130,000 packets per seconds.

3 Proposed Solution

We propose real time traffic monitoring mechanism entering to customer network from ISP provider or internet exchange (IX). It monitors the statistics of traffic, passing through OpenFlow enabled switches, checks for anomalies and only forwards those packets which are from authentic users. If any malicious user found, it blocks the source and make it inaccessible for all.

Our proposed solution for DDoS attacks detection and their mitigation is based on: (1) Separation of network monitoring, attack detection and attack mitigation, (2) Compatibility with any OpenFlow-enabled switches, (3) Efficient network monitoring for attack detection, (4) Real-time attack detection, (5) Real-time attack mitigation, (6) Scalability with varying traffic.

4 Architecture Overview

Our system comprises of three major components as shown in Fig. 1.

Fig. 1.
figure 1

DDOS mitigation solution using sflow-rt and OpenFlow.

Full size image

4.1 Network Monitor

This module is responsible for real-time network monitoring and managing statistics which are prerequisite of DDoS detection. We used sFlow-RT as traffic statistics collector and analytics engine. It receives a continuous stream of data grams from network devices and converts them into actionable metrics that are accessible through REST APIs. REST APIs makes it easy for each application to configure flows, retrieve metrics, set thresholds, and receive notifications.

We have utilized sFlow-rt REST API for implementing sampling technique to continuous monitor site-wide traffic for high speed switched and routed network. DDoS mitigation application registers flows and specify threshold for generating alerts from sFlow-rt analytics engine using following curl commands described in Sect. 4.3.

4.2 Network State Manager

This module is responsible for managing traffic flows over the network and mitigating the identified attack. We have chosen Kinetic (OpenFlow) Controller due to its concise, intuitive way of expressing dynamic network policies. This is an event driven OpenFlow controller that allows to dynamically changing network behavior based on various types of network events. Kinetic controller manages network state based on Finite State Machine (FSM) mechanism, which gives a concise logical understanding for making the policies [14]. We have specified two network states and two policies i.e. Infected, Not Infected, identity and drop respectively. Infected or not infected specifies, whether source of coming request is infected or not and should we treat this packet as normal or simply drop because it’s from infected source as shown in Fig. 2.

Fig. 2.
figure 2

Finite state machine (FSM) of network.

Full size image

4.3 DDoS Mitigation Application

This module has a key responsibility for real-time DDoS detection and its real-time mitigation. This module communicates with both sFlow and Kinetic Controller using their REST APIs. It registers flows and threshold in sFlow-rt using its REST API. Multiple flows can be registered for different types of attacks with their corresponding thresholds. sFlow-rt generates events if traffic meets specified threshold. This module update network by passing Kinetic Controller about host and their status. Kinetic Controller drops all the packets coming from that specific host. Our system is implemented in python with the combination of node.js using JavaScript. Following steps demonstrates REST commands used to monitor and control the network:-

Define Flows

figure a

Define Thresholds

figure b

Receive Threshold Event

figure c

Monitor Flow

figure d

Deploy Control

figure e

5 Results

In this experiment we are using Ping Flood attack to elaborate execution of our system. First, we had built a virtual network topology; having one switch with three hosts (i.e. h1, h2, h3). Then we flood h2 with Ping Flood (100,000 packets per second), sFlow-RT Fig. 3 shows that ping flood attack generates around 80,000 packets per second traffic rate.

Fig. 3.
figure 3

Network on attack without presence of our application.

Full size image
Fig. 4.
figure 4

Attack detection and mitigation in presence of our application.

Full size image

Then we started our mitigation application in mininet and again generate Ping Flood attack, sFlow-RT quickly detected ping flood attack and notified the mitigation application. The mitigation application cross verified attack with specified threshold and sent notification to Kinetic controller.

Kinetic controller pushes rule to Open vSwitch using OpenFlow which instantly starts dropping packets. Figure 4 shows, our system quickly detected when traffic exceeds specified threshold and immediately mitigated attack in the tenth part of second rather than reaching a peak of 80,000 packets per second. Attack is limited to a peak of 550 packets per second. We choose 500 packets per second threshold for demonstration purpose. This can be changed as per network traffic flow.

Attack detection time is inversely proportional to attack flow size and directly proportional to threshold. Attack mitigation is independent of threshold and attack size. It is responsible for blocking attacking source within a second. In addition, we have applied multiple control functions in parallel based, on the sFlow data feed, to detect multiple types of DDoS attacks such as Ping Flood, SYN and Ping of Death. The Table 1 summarizes detection and mitigation time vs. flow size of our experiment:

Table 1. Flow detection and mitigation time
Full size table

The detection times shown in Table 1 with different sampling values are shown in Table 2.

Table 2. sFlow sampling statistics
Full size table

6 Discussion and Comparison

There are various kinds of DDoS attacks; Ping Flood, Ping of Death and SYN Flood are most famous attacks in recent history. Many researchers have worked on different ways to identify DDoS attacks but most of them keep their focus on just attack detection rather than mitigating the attack source as well. Mitigation of attack source is also as important as its identification. Mostly they have focused on the attack detection without Worrying about the performance of the network [3,4,5,6].

Table 3. Comparison with literature work
Full size table

Braga et al., proposed a novel solution for identifying network anomalies using self-organizing map but didn’t focus on attack mitigation [10]. FRESCO provided a full development framework for developing network security applications which can be easily deployed over OpenFlow enabled network [11]. Mehdi et al. also proposed a solution using different algorithms using OpenFlow. They monitor and process each packet for identifying whether it is malicious or not? This approach processes 600 packets per second [9]. If someone attacks whole network, then controller will not be able to detect the attack effectively as shown in Table 3.

Our System monitors network asynchronously and gather all traffic statistics using sFlow-RT. Our system identifies three most famous DDoS attacks; Ping Flood, Ping of Death and SYN Flood on real time with performance varying from 80,000-130,000 packets per second.

7 Conclusion

In this paper, we have evaluated Software Defined Network (SDN) for mitigating a huge network threat by DDoS attacks using OpenFlow protocol. Our study demonstrated that entire network monitoring - on periodic basis including tenth of thousands of flows - does not scale for high traffic environment. Moreover, using this technique a small medium flood attack may cause denial of service. We proposed a solution which: (1) reduces data gathering overhead by using sampling technique implemented through sFlow protocol, (2) detects anomalies using sFlow-rt analytics engine events, handled in most efficient JavaScript language (3) mitigates anomalies using OpenFlow protocol. We have offloaded OpenFlow for network monitoring with sFlow-rt, it have/leaves impact on network traffic speed. Our system performance is not only comparable with that of OpenFlow technique for low traffic rate but also reliable for high traffic networks as well. Our Proposed and implemented system handles real time traffic more efficiently than the prevailing techniques.