SGuard: A Lightweight SDN Safe-Guard Architecture for DoS Attacks

National Digital Switching System Engineering and Technological Research Center, Zhengzhou 450002, China

I. INTRODUCTION

Software Defined Networking (SDN) has quickly emerged as a new networking paradigm that greatly changes the traditional network architecture. With the help of the concept of decoupling the control plane from data plane [1], SDN uses logically centralized controller to maintain a network-wide view and performs forwarding decisions to support finegrained network management policies, which gives our full programming flexibility. The logically centralized controller communicates with switches that it controls by using open and standardized protocols such as OpenFlow[2]. What’s more, switches can be made lighter and cheaper since there is no need for them to perform forwarding decisions [3], which greatly reduces the complexity of network configuration and operation.

In OpenFlow, a switch performs packet forwarding by consulting its flow table and determining the output port on which the packet is sent. Each entry in the flow table (called a flow rule or flow entry) consists of the packet header fields to match, the actions to apply on matched packets and the corresponding counters to update (see Fig.1). When a switch receives a packet which cannot be matched to any installed flow rule, the OpenFlow switch will first buffer it and then send it to the controller to request a new flow entry usingPacket Inmessage. In the meanwhile, controller responds with aFlow Modmessage, containing the action to be performed on the data packet and the duration for which to keep the flow rule in its flow table.

The authors design and implement SGuard, a security application on top of the NOX controller.

However, it’s obvious to see that the centralized controller carries considerable overhead and would be easy to become a bottleneck. This leads to issues in both scalability and security. While there are many studies and solutions on the scalability issue [4][5], there is very little research on even more challenging security issue. On the one hand SDN gives us an unprecedented opportunity to completely solve the defects in traditional design, but on the other hand it gives rise to new security problems [6]. For example, attackers may simply mount saturation attacks towards SDN controller by sending massive useless packets,as a consequence, controller will handle every useless new packet for flow entry creation,which greatly occupies compute resource and overwhelms the controller.

In our paper, two kinds of DoS attacks are considered in SDN networks. In the first attack, the switch receives massive new packets in a remarkably short period of time and then sends packets to the controller to request flow entries, which greatly consumes the control plane bandwidth and causes high latency of inserting flow entries. Additionally, the DoS attacks usually include combination of other attacks such as IP or MAC spoofing to make attacks hard to be detected. When the control plane bandwidth is exhausted, the switch can’t receiveFlow Modmessages and may directly drop the new packets instead of forwarding them normally. In the second attack, the switch can only store a certain amount of flow entries due to limited memory, so if the attacker aims to saturate the memory [7], as the switch cannot insert the new flow entry, it will respond with error message to the controller and then simply drop the packets.

To defend against these attacks, we have two research challenges as follows:

? How to discover the true origin of a packet,and then trace the attacker’s location and avoid spoofing attacks.

? How to identify whether the traffic is legitimate or not, and then take effective measures to defend against attacks.

For the first problem, we propose a novel access control mechanism to know the true origin of packets. We can also use the authorization information to track the attacker’s location and take some preventive measures as soon as possible. For the second problem,we must admit that it is hard to distinguish aggressive packets from normal packets by analyzing a huge number of packets, so we create a classification module on top of the NOX controller [8], extracting six the most representative characters as the features from the flow entries of all switches. In order to make the classifier have a high accuracy and efficiency, we introduce novel feature ranking and selecting algorithms to process these features. To the best of our knowledge, such feature processing algorithms have not been adopted before. Our classifier is based on Self Organizing Maps (SOM) [9], which is a suitable way to classify network traffic. All the above constitutes the basic content of SGuard.

The rest of paper is organized as follows.Section II describes the related work. Section III proposes the detailed design of SGuard.The implementation and evaluation of SGuard are in Section IV. A conclusion is drawn in Section V.

Fig. 1 Openflow network and attack process

II. RELATED WORK

As SDN has recently emerged as a novel networking prototype, there are more and more projects related to security, one important aspect of which is the prevention against the DoS attacks. Yan [10] argues that, although SDN itself is vulnerable, it’s easy to detect and mitigate DoS attacks with the help of global state views of the network especially in cloud computing environments. Moreover, it’s more flexible to detect DoS attacks by decoupling control plane from the data plane.

DoS is also considered to be one of the most important threats as well as one of the hardest problems in traditional networks. Client puzzles approaches [11][12] have been proposed by several researchers so as to avoid denial of service attacks in traditional networks. However, such techniques wouldn’t be appropriate for SDN, because SDN controller is more likely to be overloaded by additional malicious requests. The puzzle distribution process and puzzle solution transmission process may generate new packets, so malicious clients will use the trait to initialize a large number of new flows simultaneously inside the network. Since by definition all new flows should be sent to the controller to find routing paths, a large number of simultaneous packet-in requests can easily overload the controller.

In general, the DoS attacks are usually combined with other attack like MAC/IP spoofing.Hence, detecting such attached attacks is essential to mitigate the DoS attacks. [13] introduces a mechanism called BASE to detect spoofing attacks by marking packets with an identification of its path, but the mechanism is too sophisticated to identify the attacker on the network for us, so SGuard proposes a relatively lightweight mechanism to avoid address spoofing.

Avant-Guard [14] introduces two modules into the SDN architecture to solve the SYN Flood attack challenge: Connection Migration and Actuating Triggers. Using SYN proxy and monitoring the rate of SYN request can effectively defend against TCP based saturation attacks, but it doesn’t work to other DoS attacks in SDN. Of course, our approach attempts to mitigate all kinds of DoS attacks. [15] presents ROSEMARY controller, which implements a network application containment and resilience strategy based around the notion of spawning applications independently within a micro-NOS. Silva et al. [16] introduce a novel architecture to trigger the congestion event and respond against these events. [17][18]propose a mechanism called XenFlow, which implements on Xen hypervisor and OpenFlow to guarantee the quality of service for each virtual machine. FortNox [19] proposes a security enforcement kernel to enhance the SDN controller to mitigate attacks.

Previous works, such as [20][21][22], also employed Self Organizing Maps (SOM) to classify whether the traffic is normal or not.However, the overhead of the classification is too high to be used in real time, while our approach is quite different from that by using improved feature vector and forward selection algorithm, SGuard can easily extract the features of interest for detection with lower overhead.

III. DESIGN

In order to solve the security problems discussed above, we propose a novel defense framework SGuard for SDN networks. SGuard can control access to the networks to prevent from spoofing attacks, and can also classify and defend against malicious traffic. In the meanwhile, its high efficiency, flexibility, scalability and lightweight method characteristics will attract more researchers to use and develop it. Then, we present the detailed design of SGuard in this section.

3.1 System architecture

In our design, we introduce three novel functional modules to existing NOX controller:1)access controlmodule 2)classificationmodule 3)data plane cache. The main functionality of the access control module is to know the true origin of packets and track the attacker’s location so as to take the mitigation measures as soon as possible. The classification module is designed to identify whether the traffic is legitimate or not and next to take effective measures to defend against attacks.Fig. 2 shows the conceptual architecture of SGuard. All of these modules are implemented as SDN controller applications based on the controller platform. It’s also worth noting that the data plane cache component sits between the SGuard and the data plane, and this data plane cache plays an incomparable role during the saturation attack. The final point I’ll make is that, to defend against DoS attacks, we only need to make the SGuard be incorporated into frame without any modification to existing OpenFlow infrastructure, and so it is of high practical and popularization value.

We maintain a finite-state machine to manage the whole SGuard system. Fig. 3 shows the state machine. When the network has been set up and run, SGuard will receive packets from switches and come to theInitial State.After the preparation work, SGuard comes to thePrimary Detection State, access control module will first inspect the identity of each node and then classification module will distinguish abnormal flow traffic from normal traffic. If malicious attacks are detected,SGuard will come to theDefense Stateand timely notify the controller of the relevant information including attacker’s MAC, IP, etc(see section 3.2 in detail). And then controller can use the relevant information to generate Flow Mod messages to the switch so that the subsequent packets will not be sent to controller. That is to say, packets that match the specific flow table entry that reside in the switch are considered as malicious packets and will be directly dropped to block attackers. With the termination of an attack, SGuard comes to theSafe Mode State, and then forwards normal packets and adds the corresponding flow entry to the switch.

3.2 Access cntrol module

In most case, the DoS attacks are always combined with other attacks, such as IP or MAC Spoofing. Therefore, it’s necessary to know the identity [23] of each user in the network.When a new user connects to the network,access control module collects its relevant information (such as MAC, IP, Port and Switch ID) and binds them together into Hashtable,as Fig.4 shows, which brings enormous con-venience to track the location [24] of hosts.By inspecting over source MAC/IP and looking up the Hashtable, SGuard can decide to forward the legal packets or drop the spoofed packets. However, if the identified spoofed attackers continue to send packets to controller,switch will not forward the subsequent packet and directly drop it.

Fig. 2 Conceptual architecture

Fig. 3 State of SGuard

Fig. 4 Work process of access control module

Fig. 5 Work process of classification module

3.3 Classification module

Classification module runs as an application above the control platform and consists of three main parts: 1)data collector2)feature extractor3)classifier, as depicted in Fig.5.Initially, data collector periodically requests flow entries from flow tables of OpenFlow switches through secure channel, and then feature extractor immediately extracts existing features from the data set. Each sample is then passed to classifier module to classify it either as normal traffic or attack traffic. In order to optimize classification, we apply novel algorithms to rank and select the features according to a set of rules based on a comparison of performance.

3.3.1 Data Collector

In order to detect DoS attack as soon as possible, data collector collects flow entries at predetermined time intervals. During such intervals, data collector first sends a request command to the OF switch, then the data plane returns results through secure channel.We can classify traffic as normal or as an attack by using the features extracted from the data set, and with the help of access control module, we can easily identify and locate the attacker. In the meanwhile, data collector also obtains the global state views of registered OF switch and information of network traffic.What’s more, the definition of the time interval will have a great influence on performance of the system. If we choose an infrequent time interval, there will be additional latency to identify the attacker and take corresponding measures to defend against the attack. But if the time interval is too short, there will be an increase of packets requesting flows which will lead to an increase in the overhead of our detection mechanism, so we should determine a suitable time interval according to the actual network conditions.

3.3.2 Feature Extractor

The module extracts features vectors from the data set and transfers the feature vectors to the classifier which is capable of efficiently distinguishing attack from normal traffic. But before the process, we must determine how to choose the features that directly reflect whether the system is under attack or not. This is also one of the most important innovations in our paper. We introduce six novel features based on characteristics of DoS attacks [25], these features are sensitive to the network security environment. A more detailed description follows.

(1) Percentage of flows with a small number of packets (PFSP)

As we all know, DoS attacks can generate flows continuously and effectively in a short time, one of the main features is the large number of flows, and small amount packet in per flow, i.e. about 1～3 packets per flow. Considering normal traffic tends to have a larger number of packets per flow, neither average value nor the median value of packets per flow can precisely indicate whether our network is under attack or not. What’s more, the summation and sorting can increase the extra overhead of the system. However, it’s relatively easy to compute the values of PFSP by the following Equation.

(2) Percentage of flows with small average bytes (PFSB)

In order to increase the efficiency of DoS attacks, its payload size is usually small. That is to say, flooding packets consists of little useful bytes, so the average of bytes per flow is small (for example, some TCP flooding packets are about 120 bytes).system is under DoS attack.

(4) Percentage of reversible flows (PRF)

Given any two flows (i.e.flowx andflowy), if two flows meet the following three conditions, then we call both flows are reversible.

a) SrcIP X = DstIP Y

b) DstIP X = SrcIP Y

c) Protocol X = Protocol Y

Another feature of DoS attacks is the obviously increasing number of irreversible flows,due to the fake IP address. In order to compute PRF, we use Equation 4.

(5) Growth rate of irreversible flows (GRIF)

Both DoS attacks and busy time can cause the sharply increase of traffic, so it’s difficult to distinguish which is the true reason leading to this phenomenon. To solve the problem,GRIFis proposed.that the value of PFSB will exceed 0.75 when system is under DoS attack.

(3) Percentage of flows with short time duration (PFSD)

It’s well known that each flow rule in flow table has two associated timeout values. One is an idle timeout value, which is triggered when the flow rule is seldom being used. The other is a hard timeout, which is triggered at the timer expiry. During attack, it won’t be long before most of the flow rules are idle,since attackers usually randomly send large amounts of useless packets. As a consequence,the values ofPFSDwill increase in a short time. The following Equation is employed for this computation.

GRIFcan not only precisely reflect the generating speed of irreversible flows, but also indicate the characteristic of DoS. Typically,when the system is under DoS attack, the value ofGRIFis about 1000 packets/s, which is several orders of magnitude higher than that in normal condition.

(6) Growth rate of ports (GRP)

During DoS attacks, attacker usually generates large amount of flows using fake IP address, in the meanwhile, ports are generated too. Therefore, we computeGRPas follows.

The experiment shows that the value of GRP is about over thousands when system is under DoS attack, whileGRPin normal condition is not bigger than 200.

In this way, SOM is able to create a topo-logical map where different regions represent each kind of traffic.

3.3.3 Classifier

According to the feature vectors as mentioned above, we use Self Organizing Maps (SOM)classifier to classify traffic as normal or as an attack. SOM is a part of artificial neural network that is just like human brain, it has the ability to abstract and acquire knowledge through unsupervised learning, to seek out the regularities and properties of the samples automatically and then to change the parameters and structure of the network adaptively. It consists of input layer and competitive layer.Input layer plays a role of observer, which is in charge of accepting outside information and passing the input pattern to the competitive layer. The competitive layer is responsible for analyzing and comparing the input pattern to find the regularities in them, and then classifying them. We can refer to [9] for more specific steps.

The statistical characteristics of flows varygreatly from one switch to another, so directly using all of the features without reprocessing this data will have bad effect on the accuracy and efficiency of classifier. Therefore, we introduce novel feature ranking and selecting algorithms to improve the current situation.It is an iterative algorithm, where each iteration consists of two steps: feature ranking and feature selecting. The general methodology shows as follows.

Algorithm 1 The feature ranking algorithm

First, features ranking, evaluated by accuracy to rank each specified candidate feature.We first calculate the global accuracy using all of the above features, and thenis calculated by using each featureWe next sort the features set in descending order based on

Then, feature selecting, FS is to select the features according to a set of rules based on a comparison of performance. It starts by picking the first feature from the features set (T)as an initial features set. Repeatedly, add next featurewith the highest classification accuracy to, we will getand calculateThrough this process, we need to do two comparisons: one compares the accuracy ofwith that ofand if it’s less, remove the featurefromotherwise, assignin another comparison, the global accuracy is compared with, and if it’s less, assigntois the target features set.

3.4 Data plane cache

Data plane cache is a machine/device that temporarily caches table-miss packets during the saturation attack. It sits between the control plane and data plane, and plays an incomparable role in data cache and backup during the saturation attack. Each part of the memory space has its own function and contributes in a large way to the overall functionality. As Fig.6 shows, we can divide them into four simple categories from the point of view of function.

Packet Buffer Queue Block: During the saturation attacks, most of the flooding traffic will be redirected to data plane cache instead of flooding the OpenFlow infrastructure,by this way, the data plane will avoid DoS attacks. When a migrated table-miss packet arrives in data plane cache, the data plane cache system attaches it in the corresponding packet buffer queue. Then scheduler of data plane cache adopts round-robin scheduling algorithm to serve the packet buffer queues for generatingPacket Inmessages, by this way, we can control the rate ofPacket Inmessages sent to controller, so the control plane will avoid DoS attacks. Therefore, the control plane bandwidth and the data plane memory space will not be totally exhausted by the possible DoS attacks.

NetLog Block: the NetLog stores and maintains compressed flow tables of every switch attached to the SGuard so as to improve the overall system fault tolerance in SDN.

Classification Results Block: we use Self Organizing Maps (SOM) classifier to classify traffic as normal or as an attack. Additionally,all of the policy-making refers to the results,so in view of its great significance, we specially set the classification results storage area.

Access Control List Block: In order to defend against IP or MAC spoofing attack,each user needs to be authenticated by SGuard which gathers MAC, IP, Port information of all hosts and bind them together into the list.

IV. EVALUATION

In this section, we introduce the implementation of SGuard and evaluate the performance and the overhead of our framework.

4.1 Implementation

We implement SGuard and use Mininet [26]to emulate the OpenFlow network environment. SGuard is a security application running on top of the NOX controller [8], which gives us full programming flexibility. The detailed design is stated in section III. Fig.7 describes the topology for our experiments. The experiments are done by three physical servers, all of which host virtual machines and run Debian Linux 3.2.0-4-amd64 with Intel(R) Xeon(R)processors CPU X5690 3.47GHz. Attackeris implemented on the first server. The client,server, OF switch, SGuard and NOX controller are implemented on the second server.SGuard and the NOX controller are attached to the management ports, and the others are attached to the data ports. We implement the data plane cache as a software system in approximately 1,500 lines of C++ code on an external server which is connected with both the switches and the controller. The bandwidth of shared link is allocated 50 Mb/s. We use hping3, a commonly used network attack tool,to generate attacking traffic, such as TCP SYN floods with IP address spoofing. A tool called iperf is used to measure network performance,such as network bandwidth.

Algorithm 2 The feature selecting algorithm

Fig. 6 Data plane cache

We perform three sets of experiments. In the first experiment, we measure the bandwidth received by a legitimate client during DoS attacks, with and without the SGuard defense, as a way of validating the framework.We also use Httperf to measure the latency for a client to establish the HTTP connections with the server under a DoS attack instead of simply measuring the number of dropped packets, with and without the SGuard defense.In the second experiment, we measure the overhead of SGuard. We keep monitoring the utilization of CPU and Cache and also evaluating the average time consumption of each module. In the last experiment, we collect the training time and classification time respectively when we use feature ranking and selecting algorithms or not, so as to evaluate the efficiency of classifier. Our implementation of classifier includes 50*50 matrix of nodes,initial neighborhood radius, initial learning rate and iterative time limit are 30, 0.5, 4000,respectively.

4.2 SGuard defense effects

We first use Mininet to build up the network topology as Fig.7 shows. The attacker launches different rates of DoS attacks to the Open-Flow SDN networks, and in the meanwhile,the client and the server keep normal communication with each other. In this experiment,iperf is used to measure the bandwidth obtained by the client under different attack rates with or without use of SGuard. What’s more,we also set 3 different time intervals (1s, 5s and 20s) for the detection loop to study the laws as well as the relationship between the performance of SGuard and interval.

Fig. 7 Experiment’s topology

The results of average bandwidth obtained by the legitimate client are shown in Fig. 8(a).The results show that, when there is no attack, the bandwidth of using SGuard is a little smaller than that of without using SGuard, and not surprisingly, this is owing to the design of SGuard. SGuard is responsible for inspectingpacket inmessages and classifying the packets into normal traffic or an attack, so it will have a little impact on the data plane, but this impact is still within our desired tolerance.Next, we will gradually increase attack rate.It’s obvious to see that the bandwidth decreases sharply without using SGuard. It’s also important to note that the bandwidth declines by half at the attack rate of 100 Mb/s, and the NOX controller loses the control ability so as to break down the whole network after an attack rate of about 480 Mb/s. By contrast, it’s noteworthy that the bandwidth remains roughly unchanged under the same attack rate with the use of SGuard. From this point of view,SGuard can protect the OpenFlow switch well.

However, from the results we can see that the definition of the time interval to collect flow entries is of great importance, if collection is made at infrequent time intervals, such as 20s, then there will be a delay to detect an attack and consequently a reduction of the time available for a possible mitigation, the bandwidth decreases sharply with the increase of attack rate. On the other hand, if the time interval for collection is short, such as 1s,there will be an increase of packets requesting flows which will lead to an increase in the overhead of our detection mechanism, for example, when there is no attack, the bandwidth of SGuard (interval=1s) is a little smaller than that of SGuard (interval=5s,20s), but the metric of SGuard (interval=1s) shows a relatively stable performance when the attack occurs.

We also use Httperf to measure the latency for a client to establish the HTTP connections with the server under a DoS attack, with and without the SGuard defense. As Fig. 8(b)shows, when there is no attack, the average reply time of using SGuard is a little greater than that of without using SGuard. This is because when we use SGuard, every packet needs to go through several stages, such as authorization, migration, classification, features selection and policy implementation, which will increase some time delay. However, the additional time delay is still within our desired tolerance. If SGuard is not used, the time delay will increase sharply with the increase of attack rate, reaching approximately 500 ms,when the attack rate is 480 Mb/s, as the size of the requested content is only 1 KB, so the reply time is too long. By contrast, with SGuard,time slightly increases. This is because that SGuard is not only responsible for providing services to client, but also identifying the attacker and shutting down it. SGuard shows better protection results again. As for the relationship between reply time and interval is similar to the relationship between bandwidth and interval, and this is because time increases drastically as bandwidth speed falls.

Fig. 8 SGuard defense effect

Fig. 9 CPU and cache utilization under different rates of DoS attack

4.3 Overhead analysis

In this section, we present our analysis on the overhead of the SGuard (interval=1s). First,we use CPU and Cache utilization to indicate the overhead of the system. Next, we separately launch attack at rate of 100 Mb/s, 200 Mb/s,300 Mb/s and 400 Mb/s. Meanwhile, we keep measuring the CPU utilization and Cache utilization. The evaluation results are presented in Fig. 9.

Fig. 10 Overhead of each component of SGuard

It’s obvious to see that the overall utilization (either CPU or Cache) is relatively low,which indicates SGuard is with highly scalability and able to provide security services for more network devices. At the beginning of the DoS attack, the utilization of CPU and Cache increases slowly. This is because the main tasks in this stage are to implement the authorization functions. For example, in Fig. 9(b),while at about 8 ms, the utilization of Cache begins to increase quickly because of migration flows, and there is also some increase in corresponding CPU utilization. Owing to computing the values of feature vectors, at about 13 ms, the CPU utilization increases quickly.Classifier seems to be time-consuming component, which indicates whether this information corresponds to normal traffic or an attack, and stores the results, as a result, from 23 ms to 33 ms, both CPU and Cache utilization reaches a peak of the whole process. After classification, at about 37 ms, the CPU utilization decreases, but a bit later, SGuard will insert flow rules to block the attacker, so the utilization will have a slight fluctuation and then go back to the initial level. Of course, with the increase of attack rate, the overall utilization will also slightly increase. Owing to the relatively small-scale experiment, the CPU utilization is below 30%, while Cache utilization is below 20%. All in all, we can conclude from the results that SGuard can defend against attack with lower overhead.

In order to verify the performance of different main parts of SGuard, i.e., authorization and migration, classification, feature selection and policy implementation, we measure the delay of each component when the attack rate is ramped up from 100 Mb/s up to 400 Mb/s.We can see from Fig.10, the classification is the most time-consuming component, and not surprisingly, as it enforces the major functionality of SGuard, all of the policy settings are based on classification results. It can also be observed that all the delay times for each component are in a reasonable range.

4.4 Classification performance

To evaluate the classification performance of SGuard (interval=1s), we generate a data set which is used for training and testing. The data set contains 10000 samples, of which 4700 samples (47%) are collected during normal traffic and the other (53%) are attack samples. The evaluation is done by using traditional SOM and improved SOM classifier(withAlgorithm 1, 2). Each experiment is repeated three times and by randomly selecting the training and the testing data with different splitting ratios which are ((training%)/ (testing%): 30/70, 50/50, 70/30) to avoid either accidentally or intentionally introducing bias into the sample. As Table 1 shows, the comparison between the different classifiers is done by respecting to different performance factors: number of selected features, detection rate (DR), training time and testing time.

Table 1 shows the results of the classification performance and the SOM classifier performance is surely improved by using Algorithm 1 2, such as the detection rate and testing time, and the feature selection module leads to a significant contribution to the great performance. Feature selection seeks to reduce the number of attributes in the dataset,unlike simple dimensionality reduction, our feature selection methods include and exclude attributes present in the data without changing them. So when we classify a given sample,feature selection module can guarantee the accuracy of the classification, reducing the amount of calculation and the testing time at the maximum degree. However, it’s noteworthy that the training time increases slightly owing to the feature selection, our algorithms can be seen as the combination of a search technique for proposing new feature subsets,along with an evaluation measure which scores the different feature subsets. They are to test each possible subset of features finding the one which minimizes the error rate, so the overall training time is increase slightly by additional computation, but this should not be problems, because the training time is still within normal ranges and we also make the training phase in offline mode.

V. CONCLUSIO N

With the development of Software Defined Networking (SDN), the network security becomes critical. This paper describes DoS attacks combined with IP/MAC spoofing attacks in detail. To mitigate such attacks in the Open-Flow networks, we design and implement SGuard, a security application on top of the NOX controller. When the network has been set up and run, SGuard will gather MAC, IP,Port information of all hosts and bind them together into Hashtable for access control. Then the classifier will extract features and classify the traffic flows as normal or abnormal. Final-ly, according to the results, NOX controller will install flow rules to block the attackers.We also experimentally use Mininet to evaluate SGuard in a software environment. The results demonstrate SGuard is lightweight, efficient and with a relatively low overhead. As a future work, we plan to implement SGuard with larger experiment topologies to obtain more convincing results.

Table I Performance comparison between different classifier

ACKNOWLEDGEMENT

This work is partly supported by the National key Research and Development Program of China (No.2016YFB0800100,2016YFB0800101) and the National Natural Science Fund for Creative Research Groups Project(No.61521003) and the National Natural Science Fund for Youth Found Project(-No.61602509). We gratefully acknowledge anonymous reviewers who read drafts and made many helpful suggestions.

[1] Mckeown N, Anderson T, Balakrishnan H, et al. “OpenFlow: enabling innovation in campus networks.”,Acm Sigcomm Computer Communication Review, vol. 38, no. 2, pp 69-74, 2008.

[2] O.N.Foundation, “Openflow switch specification(v1.3.0)”. [Online]. Available: https://www.opennetworking.org/

[3] Antikainen M, Aura T, S?rel? M. “Spook in Your Network: Attacking an SDN with a Compromised OpenFlow Switch.”,Secure IT Systems.Springer International Publishing, pp 229-244.2014.

[4] Curtis A R, Mogul J C, Tourrilhes J, et al. “Devo-Flow: Scaling flow management for high-performance networks.”,Acm Sigcomm Computer Communication Review,vol. 41, no. 4, pp 254-265, 2011.

[5] Yu M, Rexford J, Freedman M J, et al. “Scalable flow-based networking with DIFANE.”,Acm Sigcomm Computer Communication Review, vol.40, no. 4, pp 351-362, 2010

[6] Kreutz D, Ramos F M V, Verissimo P. “Towards secure and dependable software-defined networks.”,ACM SIGCOMM Workshop on Hot Topics in Software Defined NETWORKING,pp 55-60,2013.

[7] Kloti R, Kotronis V, Smith P. “OpenFlow: A Security Analysis.”,IEEE International Conference on Network Protocols, pp 1-6. 2013.

[8] Gude N, Koponen T, Pettit J, et al. “NOX: towards an operating system for networks.”,Acm Sigcomm Computer Communication Review, vol.38, no. 3, pp 105-110, 2008.

[9] Kohonen T. “The self-organizing map.”,Proceedings of the IEEE, vol. 21, no. 3, pp 1-6, 1990.

[10] Yan Q, Yu F. “Distributed denial of service attacks in software-defined networking with cloud computing.”,IEEE Communications Magazine, vol. 53, no. 4, pp 52-59, 2015.

[11] Waters B, Juels A, Halderman J A, et al. “New Client Puzzle Outsourcing Techniques for DoS Resistance.”ACM Conference on Computer and Communications Security, CCS 2004, Washington, Dc, Usa, pp 246-256, October. 2004.

[12] Michalas A, Komninos N, Prasad N R, et al. “New client puzzle approach for DoS resistance in ad hoc Networks.”,IEEE International Conference on Information Theory and Information Security,pp 568-273, 2010.

[13] Kwon J, Seo D, Kwon M, et al. “An incrementally deployable anti-spoofing mechanism for software-defined networks.”,Computer Communications, vol. 64, pp 1-20, 2015.

[14] Shin S, Yegneswaran V, Porras P, et al. “AVANTGUARD: scalable and vigilant switch flow management in software-defined networks.”,ACM Sigsac Conference on Computer & Communications Security. pp. 413-424, 2013.

[15] Shin S, Song Y, Lee T, et al. “Rosemary: A Robust, Secure, and High-performance Network Operating System.”,ACM Conference on Computer and Communications Security, pp 78-89,2014.

[16] Delgado J S S, Pe?uela D J M, Medina L V M, et al. “Automatic network reconfiguration because of security events.”,IEEE Communications and Computing, pp 1-6, 2014.

[17] Mattos D M F, Duarte O C M B. “XenFlow:Seamless migration primitive and quality of service for virtual networks.”,IEEE Global Communications Conference, pp 2326-2331, 2014.

[18] Mattos D M F, Ferraz L H G, Duarte O C M B.“Virtual Machine Migration.”,Wiley-IEEE Press,pp 49-72, 2015.

[19] Porras P, Shin S, Yegneswaran V, et al. “A Security Enforcement Kernel for OpenFlow Networks.”,ACM SIGCOMM Workshop on Hot Topics in Software Defined NETWORKING, pp 121-126, 2012.

[20] Yang Y H, Jiang D B, Shen Q N, et al. Research on intrusion detection based on an improved GHSOM[J].Journal on Communications, 2009,1(1): 400-403.

[21] Alsulaiman M M, Alyahya A N, Alkharboush R A, et al. “Intrusion Detection System Using Self-Organizing Maps.”,International Conference on Network & System Security. IEEE Computer Society, pp 397-402, 2009.

[22] Braga R, Mota E, Passito, “A Lightweight DDoS flooding attack detection using NOX/Open-Flow.”,IEEE Local Computer Networks, vol. 8, no.11, pp 408-415, 2010.

[23] Kim H J, Basescu C, Jia L, et al. “Lightweight source authentication and path validation.”Acm Sigcomm Computer Communication Review, vol.44, no. 4, pp 271-282, 2014.

[24] Yao G, Bi J, Vasilakos A V. “Passive IP Traceback:Disclosing the Locations of IP Spoofers From Path Backscatter.”,IEEE Transactions on Information Forensics & Security, vol. 10, no. 3, pp 471-484, 2015.

[25] Feng Y, Guo R, Wang D, et al. “Research on the Active DDoS Filtering Algorithm Based on IP Flow.”,International Journal of Communications Network & System Sciences, vol. 2, no. 7, pp 628-632, 2009.

[26] Mininet. “Mininet”. [Online]. Available: http://mininet.org/