OverWatch: A Cross-Plane DDoS Attack Defense Framework ...downloads.hindawi.com/journals/scn/2018/9649643.pdf · ResearchArticle OverWatch: A Cross-Plane DDoS Attack Defense Framework

Research ArticleOverWatch A Cross-Plane DDoS Attack Defense Frameworkwith Collaborative Intelligence in SDN

Biao Han Xiangrui Yang Zhigang Sun Jinfeng Huang and Jinshu Su

College of Computer National University of Defense Technology Changsha China

Correspondence should be addressed to Xiangrui Yang yangxiangrui11nudteducn

Received 28 September 2017 Accepted 18 December 2017 Published 24 January 2018

Academic Editor Chengchen Hu

Copyright copy 2018 BiaoHan et alThis is an open access article distributed under the Creative Commons Attribution License whichpermits unrestricted use distribution and reproduction in any medium provided the original work is properly cited

Distributed Denial of Service (DDoS) attacks are one of the biggest concerns for security professionals Traditional middle-boxbased DDoS attack defense is lack of network-wide monitoring flexibility With the development of software-defined networking(SDN) it becomes prevalent to exploit centralized controllers to defend against DDoS attacks However current solutions sufferwith serious southbound communication overhead anddetection delay In this paper we propose a cross-planeDDoS attack defenseframework in SDN called OverWatch which exploits collaborative intelligence between data plane and control plane with highdefense efficiency Attack detection and reaction are two key procedures of the proposed framework We develop a collaborativeDDoS attack detection mechanism which consists of a coarse-grained flow monitoring algorithm on the data plane and a fine-grainedmachine learning based attack classification algorithm on the control planeWe propose a novel defense strategy offloadingmechanism to dynamically deploy defense applications across the controller and switches by which rapid attack reaction andaccurate botnet location can be achieved We conduct extensive experiments on a real-world SDN network Experimental resultsvalidate the efficiency of our proposed OverWatch framework with high detection accuracy and real-time DDoS attack reactionas well as reduced communication overhead on SDN southbound interface

1 Introduction

Distributed Denial of Service (DDoS) attacks in TCPIPnetworks are typically explicit attempts to disrupt legitimateusers access to services which are often launched by botnetcomputers that are simultaneously and continuously sendinga large number of service requests to the victims [1] The vic-tims either respond so slowly as to be unusable or crash com-pletely According to Arbor Networks which offers servicesto protect against DDoS attacks they observed over 124000DDoS attacks per week since 2016 and they believe thisnumber is growing rapidly [2] Besides since breaking the100Gbps barrier in 2010 DDoS attacks are also increasing insize making themmore and more difficult to defend againstTherefore protecting network-wide resources from thesefrequent and large volume DDoS attacks necessitates theresearch community to focus on developing high-efficient de-fense frameworks that can be appropriately deployed in time

Former DDoS attack defense in traditional networks in-volves the use of middle-box devices which are generally

complicated integration of customized hardware and soft-ware [3ndash6] Although they are superior in defense perfor-mance it is found that middle-box based DDoS attack detec-tion is inflexible with network evolution for example hard tosupport new network architectures or protocols Moreoverthese devices are usually independently deployed in a net-work and have different communication interfaces This hin-ders them from a holistic perception of network status whichis becoming extremely critical for network-wide defenseagainst increasingly frequent and large volume DDoS attacks[7]

Recently extensive research efforts have been conductedto apply software-defined networking (SDN) in diagnosingand defending DDoS attacks in a global point of view [8ndash12]Different from traditional networks and information-centricnetworks (ICN) [13] in which the forwarding and routingdecision can only be made locally the centralized controllerin SDN can quickly install reaction rules on switches andrun DDoS attack defense applications without additionalcost of middle-box devices In this context DDoS attacks

HindawiSecurity and Communication NetworksVolume 2018 Article ID 9649643 15 pageshttpsdoiorg10115520189649643

2 Security and Communication Networks

can be detected and defeated in an early stage Howeverexisting approaches which build DDoS attack defense appli-cations upon the control plane are challenging to providehigh defense performance On the one hand DDoS attackdetection methods often require analysis techniques that aremore advanced than de facto SDN data plane allows Thusthe controller needs to poll flow statistics or packets fromdata plane switches frequently for attack detection and botnetlocation [8 10 14 15] which increases southbound overheadand detection delay significantly On the other hand thepotential advantages in exploiting collaborative intelligenceof SDN have not been well investigated as effective DDoSattack defense requires extremely accurate detection and rap-id reaction in bothOtherwise itmay result in SDNcontrollersaturation attack in the worst case as discussed in [16 17]

In this paper in order to protect hosts and servers fromhigh volume DDoS attacks inside a particular network (egautonomous system) we design and implement a high-efficient cross-plane DDoS attack defense framework withcollaborative intelligence in a pure SDN environment calledOverWatch OverWatch overcomes the aforementionedproblems of existing SDN-based methods by collaborativelysplitting defense functionalities across data plane and controlplane and enabling both planes with abilities to intelligentlydetect and react to DDoS attacks in cooperation The maindifference between traditional frameworks in SDN andOverWatch is that we take the data plane into considerationfor cross-plane optimization In the proposed OverWatchframework defense procedure is divided into two phasesdetection phase and reaction phase

In the detection phase a lightweight flow monitoringalgorithm is proposed to serve the data plane as DDoS attacksensor We focus on two key features of DDoS attack trafficvolume feature and asymmetry feature The proposed flowmonitoring algorithm captures DDoS attack traffic in acoarse-grained manner by polling the values of SDN switchcounters On the control plane a machine learning basedDDoS attack classifier and a botnet tracking algorithm areutilized to locate a DDoS attack in finer granularity for exam-ple attack type and botnet locations Specifically featuresextracted from attack traffic and holistic information of thenetwork are fed into DDoS attack classifier and botnettracker respectively to determine the attack type and botnetlocations

In the reaction phase based on the results obtained fromthe detection phase a novel defense strategy offloadingmech-anism is proposed to enable DDoS attack defense actuators tobe executed on the SDN switches automatically Thus SDNcontroller can be free from conducting specific defensiveactions resulting in a dynamic attack reaction efficiencyMore specifically we concentrate on exploiting the com-putational resources of switch CPUs and the flexibility ofsouthbound interface in order to deploy defense actuators onthe switches which are closest to the botnet

The main contributions of this paper can be summarizedas follows

(i) We design a cross-plane DDoS attack defense frame-work in SDN that exploits collaborative intelligence

between data plane and control plane with highdefense efficiency

(ii) We develop a collaborative DDoS attack detectionmechanism which consists of a coarse-grained flowmonitoring algorithm on the data plane and a fine-grained machine learning based attack classificationalgorithm on the control plane

(iii) We propose a novel defense strategy offloadingmech-anism to dynamically deploy defense applicationsacross the controller and switches by which rapidattack reaction and accurate botnet location can beachieved

(iv) We conduct extensive experiments on a real-worldnetwork with a FPGA-based OpenFlow switch proto-type a Ryu controller and laptops generating DDoSattack traffic Experimental results validate the effi-ciency of our proposed OverWatch framework withhigh detection accuracy and real-time DDoS attackdefending reaction as well as reduced communica-tion overhead on SDN southbound interface

The rest of this paper is organized as follows Section 2covers background and motivation of this paper Section 3presents the architecture of our proposed OverWatch frame-work Sections 4 and 5 are mechanisms of two phases (detec-tion phase and reaction phase) in OverWatch Section 6presents the experimental results Finally this paper is con-cluded in Section 7

2 Background and Motivation

21 Middle-Boxes Based Defense Mechanisms Characteris-tics of DDoS attacks have been widely studied and research-ers have proposed various methods to detectdefend DDoSattacks Traditionally DDoS attack defense applications aredeployed on middle-box devices [3 4 19] which are special-ized equipment or software that detects and reacts to DDoSattacks from a single spot on the network The middle-boxescan provide high DDoS attack detection performance How-ever due to various interfaces provided by them differentmiddle-boxes seldom share information causing them andnetwork operators to lack holistic view of DDoS attacks [20]Mahimkar et al in [19] proposed amethod to deploy middle-boxes dynamically in the protected network but without theglobal perspective of a network where deploying them couldbe a nerve-racking problem For example assuming an attackis detected on multiple middle-boxes alone the attack tracethe most effective defense strategy would be processing mali-cious packets on the devices close to the source sideHoweverattack trace-back could not be accomplished without globalinformation of network

22 SDN-Based Defense Mechanisms SDN provides a stan-dard interface for a centralized controller to manage eachswitch under control remotely This enables the SDN con-troller to obtain the entire network information and to makedefense strategies in holistic views [8ndash11 15 18 21] In thefield of network monitoring many researches focus on how

Security and Communication Networks 3

to reduce monitoring overhead while ensuring accuracy [1114 22ndash24] Among them Braga et al in [8] proposes usingSupport Vector Machine (SVM) to detect DDoS attacks onthe SDNcontroller Chowdhury et al in [14] proposes Paylesswhich includes an OpenFlow monitoring method based onan adaptive statistics collection algorithm It can reduce thebandwidth of southbound channel but the accuracy is alsoreduced Xu and Liu in [9] proposes a method to controlgranularity of flowbyutilizing prefixmasks to reduce the con-sumption of Ternary Content-AddressableMemory (TCAM)[25] resources while detecting DDoS attacks Zhang in [11]proposes a prediction-based method to control the granular-ity of measurement while detecting abnormal traffic in orderto reduce the monitoring overhead

Moreover many DDoS attack defense methods and sys-tems are proposed based on SDN [26 27] Fresco [26] is a typ-ical SDN-based security framework It can poll statistics fromdata plane to detect different attacks Once malicious behav-iors are detected it pushes the defense logic by installingforwarding rules on data plane switches For example if SYNflood attacks are detected by the defense application thecontroller modifies switch rules to redirect suspected flowonto control plane to filter outmalicious packets fromnormalones

23 Motivation of Cross-Plane Collaborative Defense Al-though significant achievements have been made along thisline for example Shin et al in [16] enable SDN switcheswith more functionalities in detecting and defending SYNfloods to eliminate the bottleneck between data plane andcontrol plane two critical problems of the existing SDN-based DDoS attack defense methods need to be pointed outhere First both of detection and reaction process for DDoSattacks require to upload malicious traffic to the centralizedcontroller which introduces large amount of overhead forsouthbound interface andworkload to the controller Secondthe controller-based DDoS attack defense mechanism breaksthe initial idea of the separation of the control plane fromdataplane devices as it requires the controller to process mali-cious packets directly Such issues prevent SDN controllerto be an intelligent centre while conducting DDoS attackdefense

Ideally the controller in a well-defined DDoS attackdefense framework should concentrate on attack analysis(eg attack classification and traffic trace-back) Thus in-stead of implementing certain defense applications the con-troller should be responsible for conducting fine-grainedattack detection and making high level defense strategiesleveraging its global view of the whole network and abundantcomputational resources Moreover as data plane is wherepackets are proceeded the switches in SDN should be enabledwith new packets processing functions for DDoS attackdetection and reaction which are not implemented by cur-rent SDN-based DDoS attack defense approaches so far For-tunately most SDN switches (eg OpenFlow switches) con-sist of one or more CPUs running an operating system withabundant computational resource that is currently far fromutilized [28 29] This inspires us to liberate the controller

from heavy traffic and exploit the underutilized computingcapabilities in switches to perform specific DDoS attackdefense functions Therefore this goal could be achievedby modifying existing SDN devices Sonchack et al in [30]proposed a framework enabling security mechanisms to beloaded from controller to switches dynamically Motivatedby their work of leveraging computational resources on SDNswitch CPUs to conduct defense mechanisms we aim todesign a collaborative DDoS attack defense framework Byexploiting the intelligence of the central controller we focuson designing fine-grained attack detection mechanisms andautomatic defense reaction by analyzing the detected DDoSattack traffic

3 Proposed OverWatch Framework

31 Architecture Overview As illustrated in Figure 1 thearchitecture of our proposed OverWatch framework is in-spired by Knowledge Plane [31] In OverWatch DDoS attacksensors and defense actuators run on data plane switchesMeanwhile DDoS attack classifier (responsible for classifyingattacks) a botnet tracker (responsible for locating sources ofattack traffic) and the library for defense actuators are locatedover the control plane

Once OverWatch starts running DDoS attack sensorskeep monitoring every flow on the data plane constantly Ifany abnormal flow is captured (ie DDoS attack traffic) thespecific switch notifies control planewith information includ-ing an alert message and occurring attack features Over thecontrol plane OverWatch leverages uploaded attack featuresto find out DDoS attack types and its global perspective tolocate the attack sources Next the controller requests defenseactuator library to implement specific defense actuators onthe switches that are close to botnet Last but not leastthe loaded actuator will be executed on the specific switchdefending against certain DDoS attacks in the first placeAfter the attack is eliminated the defense actuators used fordefense will be removed from certain switches

Our ultimate objective is that the network can detectDDoS attack threats accurately and react to them automat-ically To achieve this defense ability needs to be introducedboth into control plane and data plane We introduce designof the data plane and control plane in the following subsec-tions respectively

32 Data Plane Design The data plane in OverWatch is notjust a group of forwarding entities inside which there is agroup of software sensors and actuators to detect and reactto DDoS attacks This leads to our three key functionalitiesto enhance the SDN switches First the data plane switchesshould be capable of capturingmain features ofDDoS attacksSecond after the reaction strategies are made by the controlplane reaction functionalities should be loaded from controlplane to data plane dynamically Finally these actuators canbe executed on data plane to filter out attack packets Weintroduce these key functionalities below

321 DDoS Attack Sensor We propose an algorithm whichruns on the data plane devices to detect DDoS attacks as a


Control plane

Data plane

Botnet tracker DDoS classifier

SDN controllerHistorystorageDefense

library

Actuator

Southbound interface (eg OpenFlow)

Victim

Switch 1DDoS sensor

Switch 3DDoS sensor

Switch 2DDoS sensor

Actuator

Actuator

Botnet1

Botnet2

1

1

5

3

22

4

Figure 1 The architecture and workflow of OverWatch

Actuator chain

Match

Match

whereTo

DDoSactuator

1

DDoSactuator

2

DDoSactuator

N

Egresspackets

IngresspacketsExecute Lookup Parse

SDN switch HW

Metadata Packet body

middot middot middot

Figure 2 The process procedure of actuator chain when multiple actuators are loaded on the same switch

DDoS attack sensor Generally there are plenty of approachesthat are able to capture key features of DDoS attacks forexample large volume of traffic and asymmetry in two-waytraffic However in the context of SDN the limitation of low-endCPUon SDN switch comparedwithmiddle-boxes causesmost of them to be inappropriately deployed

Thus we propose a lightweight flow monitoring algo-rithm which recognizes DDoS attacks through readinghardware counters to server as DDoS attack sensors inOverWatch The details of this algorithm are illustrated inSection 4 Here we only list the two functions that can becompleted by DDoS attack sensors (1) capturing changesin flow characteristics without inspecting packets and (2)recording the DDoS attack traffic by physical port or flow IDBy this means the sensors on the data plane are capable ofcapturing DDoS attacks in the first place

322 DDoS Attack Defense Actuator The DDoS defenseactuators to be specific are a set of switch software tools toconduct various defense mechanisms independently Differ-ent from traditional SDN switches which are only capableof performing basic match-action processes switches inOverWatch are enabled with different packet processingmechanisms by using software resources

Various types of DDoS attacks may be conducted simul-taneously to maximize the attack effect On this occasionmultiple actuators are required to run on a single switchThus we design the actuator chain which aims to enablemultiactuators to work independently as shown in Figure 2When a SDN switch startup the agent process initializes anempty linked list Once an recently loaded actuator is com-piled it is added to the tail of the listWhenmultiple actuatorslink into the list a chain of actuators forms Packets fromhardware firstly enter the head of the chain If the metadatacontains a packet that matches the specific ID of the currentactuator this actuator will process the packet and send it backto hardware with a modified metadata (revealing the specifichardware module sent to) Otherwise the packet will bypassthe current actuator until a matched actuator ID is found Bythis means defense actuators in the same switch are able towork independently

323 Defense Strategy Enabling Once attacks are identifiedthe control plane makes a set of strategies to react Enablingdefense actuators on the data plane dynamically is a key stepfor executing these strategies

The enabling procedure is inspired by the work of OFXbut there are some key differences between them First there


SDN controller

Southbound interface (OpenFlow eg)

Switch CPU

(1) Download

(3) Register(4) Assign ID

(7) Send Pkt

(5) Add rule

(2) Compile

(6) Receive Pkt(Metadata = ID)

Agent process

Sourcecode Actuator

NICPCIe driver

Switch hardware

MetadataPkt

Figure 3 The procedure of defense enabling in typical SDNswitches

is no flow table maintained on the software so not all thepackets need to be redirected to the software Second thepackets redirected to the software will be processed by a spe-cific actuator according to a metadata The defense strategyenabling mechanism can be illustrated as Figure 3 Firstlysource code of a defense actuator is loaded from controllerto local memory of a designated switch Then the code iscompiled in the embedded operating system (usually Linux-based) Afterwards the actuator registers to the agent processduring which an exclusive ID is assigned to the actuatorFurthermore before the startup function of the actuator isexecuted it sends a standard message to the agent processindicating the specific packet types it processes The agentprocess adds a high priority rule to the hardware matchtable accordingly In this way packets that match such ruleare polled from hardware with metadata navigating to thespecific actuator Once the above steps are completed theactuator is executed to perform specific DDoS attack defensefunction

33 Control Plane Design The control plane is brain toOverWatch It inspects the current DDoS attack (eg attacktypes and its traces) and makes proper strategy to defend itAccording to our overall objective the heart of the controlplane is its intelligence ability to inspect current DDoS attackand reason proper strategies which means the control planeshould be able to (1) classify DDoS attacks and (2) track thebotnets To be specific on the one hand the control planeshould determine exact attack types (SYN flood UDP floodDNS flood etc) On the other hand it should also locatesources of occurring attack so as to defendDDoS attacks fromthe source which proves to be more effective than defendingfrom the destination This argues that the control plane isresponsible for the following three functionalities

331 Attack Classification As we use different defense actu-ators according to particular attack types in order to performdefense mechanism more effectively OverWatch is requiredto identify attack types firstly

To achieve this when DDoS attack traffic is firstlycaptured by data plane sensors the abnormal trafficmatchinga specific rule is mirrored (by sampling) for traffic featureextraction In order to reduce overhead of southboundinterface in OverWatch to a greater extent feature extractionis conducted on the switch software rather than on thecontroller Then the features are polled to the controller forclassification On the controller there runs a DDoS attackclassification module that leverages the extracted trafficfeatures as input to verify the attack type To guarantee theaccuracy and reduce the false-positive rate during classifica-tion a machine learning method is utilized in this modulewhich we will demonstrate in Section 4

332 Botnet Tracking Botnet tracking is another key issuein DDoS attack defense as it determines where the defenseactuators should be deployed Generally DDoS attack isconducted by several botnets As attack flows travel closerto the victim the malicious traffic becomes larger dueto traffic merger This prevents us from effective defensemeasurements In order to process attack traffic effectivelyactuators should be deployed at positions close to botnetsThis argues that the controller inOverWatch is ought to locateswitches that are close to botnets

Fortunately this can be accomplished by leveragingholistic info of the network topology maintained by thecontroller and data from malicious packets received fromdata plane switches In the next section we propose a flexiblebotnet tracking algorithm suitable to be deployed on the SDNcontroller which is able to locate the group of switches thatare in the upstream of attack traffic

333 Attack Reaction When attack types and botnet loca-tions of a DDoS attack are both determined the controlplane needs to perform highly automatic defense reactionimmediately In OverWatch the control plane reacts byloading specific defense actuators onto directed data planedevices

As shown in Figure 4 the reaction procedure for attacksin a typical SDN controller is quite straightforward Thedefense library module which contains various sourcecodes of DDoS attack defense actuators firstly registersto event listener Once an attack is determined a 2-tupleDPID AttackType (DPID [32] is used to represent DataPath IDentity in the context of SDN) is sent to the eventmanager indicating the defense strategy made by the built-in applications This tuple is then received by the defenselibrary The defense library loads source code of specificactuator which matches AttackType in the received 2-tupleand notifies defense enabler Finally the actuator is loaded todesignated switches through southbound channel In order tosupport such mechanisms certain modifications need to bedone for existing SDN controllers which we will describe inSection 5

4 Detection Phase of OverWatch

As OpenFlow [32] is the leading reference implementation ofthe SDN paradigm it is reasonable to implement OverWatch


Application layer

DDoS classifier Botnet tracker Defense library

Service layer

Event manager Listener

Defense enabler

Southbound layer

3 1

25

outputs4info

Send Poll Register

Deploy actuatorsUpload data

Figure 4 Workflow of attack reaction in a general SDN controller(ie Ryu controller) Be noted that this is only a sketch map forthree-layer structured SDN controller

in such an environment Therefore in this section we in-troduce how we implement OverWatch into a typical SDNcontroller (Ryu controller [33]) and FPGA-based OpenFlowswitches [18] To describe the workflow of our OverWatchprototype clearly we divide the working process of Over-Watch into two phases detection phase and reaction phaseThe main goal in detection phase is to classify attack types aswell as locate the botnets We describe this phase in detail asfollows

41 Cross-Plane Attack Detection The workflow in detectionphase is shown in Figure 5 Firstly the DDoS attack sensorconstantly monitors data plane traffic by reading counter-values of each flow periodically If attack flows are capturedthe sensor notifies the OpenFlow switch agent of the specificflow ID to indicate the abnormal flow Then the switchagent modifies the action of hardware lookup table by aOFPT FLOW MODmessage (defined in OpenFlow specificationsince 10) to mirror the sample packets from the abnormalflows onto local memory The buffered packets have twouses First they are copied by the software-defined featureextraction module (SDFE) which extracts key features ofdifferent packets for attack classification on the control planeSecond the packets themselves are also obtained by switchagent and sent to the controller for botnet tracking

After the DDoS attack data (ie abnormal flow IDsampled packets and traffic features) is sent to the controlplane encapsulated in a OFPT PKT IN message (also definedin OpenFlow specification since 10) it is firstly received bythe OpenFlow control agent Then this agent extracts packetpayload and passes it to the eventmanager (NB In Ryu eventmanager is responsible for distributing messages receivedfrom data plane) Afterward the data is split into two partswhich are data related to traffic features and data related tobotnet tracking (ie a DPID FLOW ID Pkt Buff three-tuple) The above two kinds of data are polled by DDoSattack classifier and botnet tracker respectively inside which

the DDoS attack type and first-hop-switch of current DDoSattack are both determined

From aforementioned the detection phase is dividedinto two stages a coarse-grained data plane detection stageand a fine-grained control plane detection stage We discussapproaches we applied in both stages below

42 Coarse-Grained Detection on Data Plane As aforemen-tioned the data plane is where packets are forwarded lever-aging computing resources on the data plane to determine anattack coarsely and locally is quite reasonable Therefore onthe data plane we first present a lightweight flow monitoringalgorithm that we utilize as a DDoS attack sensor on switchesIt runs on the switch software as a monitor thread Unlikemany other monitoring methods this algorithm aims toextract the key features of DDoS attack traffic by means ofpolling countervalues from an OpenFlow switch

Generally there are fundamental differences between atypical DDoS attack and normal network behaviors that weleverage to monitor DDoS attacks Large traffic rate is oneimportant feature for DDoS attacks Moreover during anattack there is also huge rate difference between flows cominginto a victim server and flows out of the server They aredefined as volume feature and asymmetry feature Numerousresearches have drawn the fact that typical DDoS attackscould be determined by verifying the above two features fromtraffic

Fortunately the above two features can be determinedby polling switch countervalues from hardware pipeline Wedefine119862Byte

119905119899and119862Pkt

119905119899as the byte and packet count of a specific

flow at time 119905119899 The two features can be expressed as follows

Byte Count per Second (119861119905119899) at Time 119905119899 It describes the averagebyte rate of a flow port or switch between time 119905119899minus1 and 119905119899

119861119905119899 =119862Byte119905119899

minus 119862Byte119905119899minus1

119905119899 minus 119905119899minus1 (1)

Packet Count per Second (119875119905119899) at Time 119905119899 It describes theaverage packet rate of a flow port or switch between time119905119899minus1 and 119905119899

119875119905119899 =119862Pkt119905119899

minus 119862Pkt119905119899minus1

119905119899 minus 119905119899minus1 (2)

Byte Count Asymmetry (119860Byte119905119899

) at Time 119905119899 It describes theaverage byte rate asymmetry of pair-flow or port betweentime 119905119899minus1 and 119905119899

119860Byte119905119899

=119861in119905119899

119861out119905119899

(3)

Packet Count Asymmetry (119860Pkt119905119899

) at Time 119905119899 It describes theaverage packet rate asymmetry of pair-flow port or switchbetween time 119905119899minus1 and 119905119899

119860Pkt119905119899

=119875in119905119899

119875out119905119899

(4)


Our proposed module

Basic module

Botnet tracker

Event managerOF control agent

OpenFlow channel

OF switch agent

NIC driver

DDoS classifier

DDoS dataOF header

ParsePkt flow

ExecuteLookup

Metadata Pkt body

Pkt Buffer

SDFEFeatureFeature pre-

extractorprocessor

DDoSsensorCounterreader

Monitorthreads

Trackingthread

topologyviewer

3

41

value

7features

52

8

9

10features

11

6

Modify rule

Mirror PktCounter

Pkt buffPkt Buff

FlowID

Traffic

DDoS data

Pkt_in

Traffic

DPID FlOW_ID PktBuff

Figure 5 Implementation and workflow of OverWatch in detection phase

We present our prediction-based algorithm to capturegreat changes of the above four metrics This algorithmleverages previous metric samples from a specific flow toestimate a future value range If the actual values of the fourmetrics fall into the range we predict this indicates that thecurrent flow is normal Otherwise the deviation between thepredicted values and observed values indicates an abnormalflow caused by a DDoS attack

Specifically we leverage WMA (Weighted Moving-Average) to calculate prediction value for each metric AndPauta criterion in Gaussian distribution is also utilized toget a reasonable prediction range The pseudocode of thisalgorithm is shown in Algorithm 1

43 Fine-Grained Detection on Control Plane As a cen-tralized and often high-performance platform the controlplane holds advantages of abundant computing resources andholistic info of the whole networkThus on the control planetwo functionalities are developed DDoS attack classificationand botnet tracking Both of them are essential for attackreaction as they determine which actuator is to be deployedand on which data plane switch it is to be deployed Weintroduce our machine learning based classificationmodel aswell as a lightweight botnet tracking algorithm below

431 Autoencoder-Based Attack Classification Machinelearning has gained much attention in the community ofnetwork security as it improves the accuracy and reduces

globals V[119899] Vector List of DDoS attack feature metrics119905119899 Current time119899 Number of Vectors in the list

while 1 doif 119905119899 = 119905119899minus1 + Δ119905 then

Update the list V[119899] of history recordsfor all 119894 isin 1 2 3 4 doUse WMA to calculate the prediction value Vpredict

119899+1

for next time interval

Vpredict119899+1 =

119899

sum119894=1

120582119894Vactual119894

119899

sum119894=1

120582119894 = 1

Use ratio metric 119877predict to compare predictionvalue and actual valueCalculate ideal value Videal119894 and standard deviation120590 for ratio metricUse Pauta criterion to calculate the prediction range

119877119906 larr997888 Videal119894 + 3 times 120590119877119897 larr997888 Videal119894 minus 3 times 120590

end forif each 119877predict is out of the (119877119897 119877119906) range thenTrigger alert to controller

elseContinue

end ifend if

end while

Algorithm 1 Lightweight flow monitoring algorithm


X1 X2 XN

X1 X2 XM

y1 y2 yN

y1 y2 yM

U b1

U b1U b1

V b2

V b2

V b2

W b3

X1 X2 XN

y1 y2 yS

Input layer

Hidden layer 1

Hidden layer 2

Output layer

(a)

(b)

(c)

Figure 6 Schematic representation of autoencoder and DDoS attack classifier model (a) autoencoder for 1198601 (b) autoencoder for 1198602 (c)the model of DDoS attack classifier

false-positive rate while classifying different types of abnor-mal traffic To determine the attack type from real-time ex-tracted traffic features amachine learningmethod combinedwith autoencoder [34] and softmax classifier [35] is utilizedin the module of DDoS attack classifier

As shown in Figure 6 each autoencoder contains threelayers input layer hidden layer and output layer Two autoen-coders (1198601 and 1198602) are stacked with each other in a way thatthe outputs of first hidden layer are fed into the inputs of thesecond Then the outputs of the second hidden layer are fedinto a softmax classifier Finally all layers stacked togetherforming the DDoS attack classifier Generally if the extractedtraffic features are fed into the input layer the output vector ofthe model indicates to which attack type the features belongWe introduce the structure below

The autoencoder has three layers an input layer of 119873nodes for a record of 119873 features (ie 119883 = 1199091 1199092 119909119873)a hidden layer of 119872 nodes for learning key patterns of inputrecord and a output layer of 119873 nodes for reconstruction ofthe input (ie 119883 = 119883) The network finds optimal values ofweight matrix (ie 119880 isin 119877119873times119872 and 1198801015840 isin 119877119872times119873) and biasvector (ie 1198871 isin 119877119873times1 and 11988710158401 isin 119877119872times1) together while trying tolearn the key patterns of an input record (eg a DDoS attackrecord)The second autoencoder feeds the outputs of the firstone as its input It uses the same methods to calculate theoptimal weight matrix 119881 isin 119877119875times119873 and bias vector 1198872 isin 119877119875times1

Then a softmax classifier builds a mapping relationshipbetween the hidden layer of the former autoencoder (ie119867 = ℎ1 ℎ2 ℎ119872) and 119878 types of DDoS attacks (ie119884 = 1199101 1199102 119910119878) Similarly This network finds optimalvalues of weight matrix (ie119882 isin 119877119872times119878) and bias vector (ie1198873 isin 119877119878times1) too while polling the output close to the labelvalue which indicates the real DDoS type Before this modelis able to classify any record collected fromDDoS traffic each

layer needs to be trained with backpropagation algorithm[36] separately Then they are stacked together and fine-tuned to improve the performance of the entire model Thebrief training process for the first autoencoder is shown inAlgorithm 2 and the other two layers share similar trainingprocess

After the training process with historical DDoS attackdataset this model can be utilized to perform attack classi-fication with run traffic records

432 Collaborative Botnet Tracking Thecollaborative botnettracking aims to locate the switches close to the botnets thusmaking the defense actuators more effective in defendingDDoS attacks We propose a botnet tracking algorithm basedon the collaboration of the data and control plane andimplement it in the controller as a built-in module calledbotnet tracker

Before diving into the details of the algorithm twoprerequisites need to be stressed out The first one is thatthe whole network info (link state topology info forward-ing rule etc) is maintained on the controller The secondprerequisite is that the info maintained by the controller canbe accessed by other built-in applications on the controllerFortunately both prerequisites can be satisfied by leveragingan enhanced topology viewer [37] a built-in module inRyu More specifically the key procedure in the algorithmis to obtain the last hop of a sampled packet This could beachieved by extracting the source MAC address of the packetand leveraging the network info on the controller to locatethe last hop switch

Based on above we propose our botnet tracking algo-rithm Specifically we consider a set 119860 consisting a set ofswitches that have captured DDoS attacks on themselves119860 =1198861 1198862 119886119898 And 119878 is the total set of data plane switches a


Require Weight matrix of the hidden layer 119880Bias vector of the hidden layer 1198871

Ensure Training dataset 119890for all number of training iterations do

Train the single layer autoencoder using back-propagation1198831 1198832 119883119898 larr Sample minibatch of 119890 get batchesof traffic recordsUpdate 1198801198801015840 119887 1198871015840 by using gradient descent method tominimize the loss function

Loss = ( 12119898

119898

sum119894=1

119883119894 minus 1198831198942) + 1205822

119899119897minus1

sum119897=1

119904119897

sum119894=1

119904119897+1

sum119895=1

(119882119897119895119894)2

end for

Algorithm 2 DDoS attack classifier training process

Our proposed module

Basic module

Defense library

SYN proxyDDoS

classifierBotnettracker


3

Source codeOF header OpenFlow channel

A1 A2 An

Actuator chainOF switch agent

NIC driver

Execute Lookup Parse Pkt flow

Metadata Pkt body

5

6

8

79

4

AttackType DPID2 1 1

Send Pkt

Send DPIDSend AttackTypePollDownload actuator

Pkt_out

Register

Load code

Redirect pkt

Modify rule

Figure 7 Implementation and workflow of OverWatch in response phase

controller maintains 119878 = 1199041 1199042 119904119899 We take one element119886119894 from set119860 at a time and use the sampled packets collectedfrom 119886119894 to determine the last hop switch 119904119896 If 119904119896 isin 119860 then weeliminate 119886119894 from set 119860 Otherwise 119886119894 is one of the switcheswe are searching forWe use this method to traverse set119860 andobtain a subset 119861 (119861 sube 119860) consisting of all 119886119894 whose last hopis not included in 119860 In this way we are able to locate all theswitches which are likely close to botnets

5 Reaction Phase of OverWatch

In this section we express how we design and implementthe reaction phase of OverWatch After the attack type and

switches that are close to botnets are addressed in the formerphase OverWatch is supposed to react to the occurringattack efficiently Thus first we illustrate the workflow ofthe reaction phase in our prototype Then two reactionapplications are introduced in the second part

51 Attack Mitigation The workflow of reaction phase inOverWatch is depicted in Figure 7 From aforementioned thespecific attack type and the most close-in switches can bedetermined in the detection phase respectively Then bothresults are sent back to the event manager This triggers thedefense library which has registered to the event manager topoll up the messages This module firstly leverages the attack


type tomatch a particular actuator so as to indicate the sourcecode which is required to be loaded onto data plane Thenit invokes functions provided by OpenFlow control agent todownload the specific source code onto the switch whoseDPIDmatches the received message from the event manager

In OverWatch the source code of designated actua-tor is encapsulated inside a OFPT EXPERIMENTER message(defined in OpenFlow specification since 11) and sent tothe specific switch through OpenFlow channel The corre-sponding switch agent running on that switch receives themessage and loads the codes of the actuator in the runningspace Then the source code is compiled to an executablefile and then registered back to the switch agent which laterallocates an exclusive ID to the specific actuator so that itcould be added to the actuator chainMeanwhile the actuatoralso notifies the switch agent of the packet type it processesOnce this is received by the agent the agent generates ahigh priority flow rule and adds it to the flow table using aOFPT FLOW MODmessage

After the rule modification takes effect packets thatmatch the higher priority rule are redirected to the actuatorchain with metadata that could match a certain ID of theactuator in which they are going to be processed In additionpackets sent back to the hardware are also allocated withmetadata to match the lower priority rule so that they can beforwarded by the switchrsquos original rules

52 Intelligent Reaction Applications We develop two sampleapplications of DDoS defense actuators to exemplify thefeasibility of OverWatch This includes SYN proxy and DNSreflection filter These two actuators are motivated by (1) thefunctionality that Avant-Guard [16] proposed as a data planeextension to defend SYN flood and (2) the example DNSfilter proposed in SDPA [38] to filter out DNS refection attackpackets on OpenFlow switches

521 SYN Proxy In a SYN flood attackers send numerousSYN packets to exhaust memory resources of victim byenforcing it maintaining a large number of semiconnectedstates so the victim will not respond to affirmed connectionrequest To filter out these malicious SYN requests anOpenFlow rule is preloaded to lookup table so that all SYNpackets will be polled onto an actuator called SYN proxy If aSYN packet is received by it firstly to prevent multiple SYNrequests sending to the victim it calculates a cookie to recordthe request using harsh table and then the actuator generatesa response packet sent back to the source and drops theinitial SYN request packet If during a certain time intervalan affirmed ACK packet is received from a source that hasbeen recorded in the harsh table the proxy will generate TCPhandshake packets to build up validation between the legalsource and its destination Otherwise the proxy simply dropsthe malicious packets In this way the proxy eliminates thethreat of SYN flood

522 DNS Filter Botnets in a DNS reflection attack sendDNS requests to name servers using the victim hostrsquos IPaddress Thus the victim will be flooded by these massiveDNS responses To filter out these unsolicited DNS response

Figure 8 Diagram of our testbed network

once the actuator (DNS filter) is loaded on the data planetwo high priority OpenFlow lookup rules which redirectthe packets whose UDP source or destination port equals53 are loaded as well After the redirected DNS packets arereceived by the filter each DNS request packet is recorded bya five-tuple (source IP destination IP source port destinationport protocol) in memory If the upcoming packet is a DNSresponse packet and matches one of the tuples of request itis sent to hardware pipeline to match a lower priority rulefor forwarding On the contrary the filter drops the packetto protect the victim

6 Experiment and Evaluation

61 Experiment Setup To evaluate the performance of ourproposedOverWatch frameworkwemodified a FPGA-based(Altera EP4SGX180) OpenFlow switch [28] to support theaforementioned data plane functions We also modified Ryucontroller to enable proposed controller-based mechanisms(including the adding of three built-in applications DDoSattack classifier botnet tracker and defense library)

Figure 8 illustrates the testbed of our experiment Itconsists of a FPGA-based OpenFlow switch prototype with8 Gigabit ports a 199GHz Intel Celeron J1900 CPU and a2GBmemory that runsUbuntu 1404 on it a control platformwith a quad-core Intel i7 CPU and a dual NVIDIA-GTX1080GPU (used for training machine learning based classifier)with 16GB of RAM running Ryu controller and up to eightlaptop hosts which represent DDoS attackers victims andnormal traffic generators respectively

62 Efficiency of Coarse-GrainedDetection In order to evalu-ate the performance of the algorithm running as DDoS attacksensors we firstly add two rules to enable traffic forwardingfrom 1198671 and 1198672 to 1198678 (1198671 1198672 rarr 1198678) Then Stacheldraht[39] is utilized to conduct DDoS attacks from 1198671 and 1198672to 1198678 within 20 seconds The detection results in the DDoSattack sensor together with volume and asymmetry featuresof attack flow (1198671 rarr 1198678) are depicted in Figure 9 Thesedepicted results demonstrate that the four metrics in theDDoS attack sensor are able to capture great changes involume and asymmetry features as soon as the attack occurswhich also evidently shows the effectiveness of the algo-rithm


Abnormal flow detected

Bytes count per second of monitored flowVolume metric of byte in proposed algorithm

50

0

15 20 2510

Time (second)

Byte

rate

(Bps

)

25 times 106

20 times 106

15 times 106

10 times 106

5 times 106

8

10

12

14

16

18

20

Met

ric v

alue

(a)


Packet count per second of monitored flowVolume metric of packet in proposed algorithm

500

15 20 2510

Time (second)

Pack

et ra

te (p

ps)

80 times 103

60 times 103

40 times 103

20 times 103

0

1

2

3

4

5

6

Met

ric v

alue

140 times 103

120 times 103

100 times 103

(b)


Byte count asymmetry of monitored pair-flowAsymmetry metric of byte in proposed algorithm

50 15 20 2510

Time (second)

0

2

4

6

8

Met

ric v

alue

0

50

100

150

200

250

Byte

coun

t asy

mm

etry

(c)


50 15 20 2510

Time (second)

0

2

4

6

8

10

Met

ric v

alue

0

20

40

60

Pack

ets c

ount

asym

met

ry

Packets count asymmetry of monitored pair-flowPackets asymmetry metric in proposed algorithm

(d)

Figure 9The coarse-grained detection results during a SYN flood attack [18] (a) byte rate and volume metric of byte in monitored flow (b)packet rate and volume metric of packet in monitored flow (c) byte count asymmetry and asymmetry metric of byte in monitored pair-flow(d) packet count asymmetry and asymmetry metric of packet in monitored pair-flow

Next we use FTP to transfer a 4GB data block from 1198671to 1198678 The detection results of four metrics are shown inFigure 10 It is found that even though three of the metricsdramatically change in the algorithm result the asymmetryfeature of packet count barely changesThis is because duringthe data transfer the receiver1198678 keeps sending ACK packetsto 1198671 which ensures a rough equivalence of packet countin both directions This explanation can be testified by usingWireshark to capture packets from1198671 or1198678 Therefore suchmechanisms in the proposed algorithm enable the DDoSattack sensor to reduce the misjudgment rate of DDoS attackdetection

To demonstrate the advantage of communication over-head reduction in OverWatch we move the DDoS attacksensor to the controller side and use the same algorithm topoll switch countervalues through OpenFlow channel Weset this typical controller-based DDoS detection method as abaseline method Besides we also implement another mech-anism which optimizes the baseline method by utilizing

an adaptive polling algorithm proposed in Payless [14] toreduce communication overhead of southbound interfaceThen we implement these three methods in a scenario wheredifferent times of DDoS attacks are conducted from randomhosts within 1 minute Wireshark is utilized to capture all thepackets of southbound interface during the experiment Thetotal amount of southbound overhead is shown in Figure 11It is found that OverWatch has orders of magnitude lessoverhead than the other two methods This is achieved byoffloading the DDoS attack sensor onto data plane Andcomparedwith Avant-Guard which can reach similar resultsthere is no modification introduced in the switch hardware

63 Efficiency of Fine-Grained Detection To demonstrate theperformance of the DDoS attack classifier in OverWatchwe collected network traffic from the testbed as trainingdataset Specifically we use 1198671 and 1198672 to send DDoS attacktraffic to 1198678 Hosts from 1198673 to 1198676 communicated with eachother randomly for web browsing video transferring and


Volume metric of byte in proposed algorithmVolume metric of packet in proposed algorithmAsymmetry metric of byte in proposed algorithm

Changes detected

0

2

4

6

8

10

12

14

Met

ric v

alue

50 15 20 2510

Time (second)

(a)

Barely change

Packets count asymmetry of monitored pair-flowAsymmetry metric of packet in proposed algorithm

50 15 20 2510

Time (second)

0

2

4

6

8

10

Met

ric v

alue

0

1

2

3

4

5

Pack

et co

unt a

sym

met

ry(b)

Figure 10 The coarse-grained detection results during big data block transferring using FTP [18] (a) the changes of three metric valuesexcept asymmetry metric of packet (b) the changes of packet count asymmetry and asymmetry metric of packet in monitored pair-flow

100 times 103

10 times 103

1 times 103

100 times 100

Com

mun

icat

ion

over

head

(byt

esm

in)

Number of abnormal flows1 2 3

OverWatchBaseline methodBaseline method optimized by Payless

Figure 11 Overhead of southbound interface in OverWatch base-line method and baseline method optimized by Payless within 1minute [18]

online gaming which led to background traffic variationWemirrored all the traffic to 1198677 by tcpdump so that the trafficcan be leveraged as dataset We collected 12 hours of trafficdata in total including 6 hours of normal traffic and 6 hoursof attack traffic DDoS attacks in the conducted experimentconsist of 6 types UDP flood SYN flood ICMP flood andtheir permutations They are all generated by StacheldrahtAnd Table 1 shows the distribution of records in the datasetThe features we extracted from traffic flows during the classi-fication are listed in Table 2 while Table 3 lists the parametersin our experiment In the training and evaluation process the

Table 1 Number of records in training dataset

Traffic class Records numberTraining Test

Normal traffic 17539 9824Attack traffic

SYN flood 2831 1566UDP flood 2706 1591ICMP flood 2519 1630SYN amp UDP flood 3054 1321UDP amp ICMP flood 2936 1729SYN amp ICMP flood 3144 1538

features are real-valued positive numbers by digitization andmax-min normalization to improve accuracy

We evaluate the performance of the classifier usingparameters including confusion matrix precision recalland 119891-measure In a confusion matrix each row of thematrix represents the instances in a predicted class whileeach column represents the instances in an actual class Inbinary classification precision is the fraction of relevantinstances among the retrieved instances while recall is thefraction of relevant instances that have been retrieved overthe total amount of relevant instances Both of them indicatethe performance of the classifier 119865-measure considers bothparameters above to compute a score which is the harmonicaverage of the parameters where 119891-measure reaches its bestvalue at 1 and worst at 0 Figure 12 illustrates the confusionmatrix of our evaluation It is observed that our DDoS attackclassifier has fairly good accuracy for detecting single type ofDDoS attacks reaching about 96 The detection accuracyfor mixed attacks is lower but still reaches around 83


Table 2 Features extracted from different packets

Packet type Feature description

TCP

1 Fraction of TCP packets with SYNflag set

2 Fraction of TCP packets with ACKflag set

3 Entropy of src IP addresses4 Entropy of dst IP addresses5 Entropy of src ports6 Entropy of dst ports7 Entropy of TCP sequences

UDP

8 Fraction of dst port le 1024 UDPpackets

9 Fraction of dst port gt 1024 UDPpackets

10 Entropy of src IP addresses11 Entropy of dst IP addresses12 Entropy of length for UDP packets

ICMP

13 Entropy of src IP addresses14 Entropy of dst IP addresses15 Entropy of TTL values16 Fraction of ICMP packets in total

Table 3 Autoencoder training parameters

Parameter ValueLearning rate 01Batch size 5Epoch limit 3500

More specifically we demonstrate the precision recall and119891-measure for 8 types of traffic in Figure 13 Except the mixedtraffic of SYN andUDP flood as well as SYN and ICMP floodthe 3 parameters for classification of all types traffic reachabove 90 which is quite acceptable in classifying DDoSattacks in real network

We claim that the performance of the autoencoder-based classifier is not necessarily better than other machinelearning approaches but these results demonstrate the greatfeasibility of leveragingmachine learning approaches to serveOverWatch as a DDoS attack classifier which is the mainpurpose of the evaluation above

64 Performance of Attack Reaction We also evaluated theperformance of defense actuators on the data plane We seta scenario where we redirected packets from a certain portto a defense actuator which performs no operations to thepackets and then send the packets back to a designated portWe compare this forwarding path with another two baselinemethods The first one is direct hardware forwarding thesecond one is redirecting the packets to the Ryu controllerand then sending them back to a designated port The maingoal here is to evaluate how much performance gain isintroduced by the defense actuator in OverWatch comparedwith traditional SDN-based defense mechanisms According

09

08

07

06

05

04

03

02

01

00

9270 011 000 012 019 000 067 412

093 9458 039 059 232 412 000 159

105 084 9443 081 431 087 332 164

000 075 142 9771 502 665 267 163

091 134 133 011 7722 473 003 190

040 143 092 000 387 7665 120 255

000 039 116 043 393 161 9074 409

000 056 035 023 314 538 138 8648

No

SYN

UDP

ICMP

SampU

SampI

UampI

All

No

Pred

icte

d

Actual

SYN

UD

P

ICM

P

SampU

SampI

Uamp

I

All

Figure 12 Confusion matrix for DDoS attack classifier in Over-Watch

PrecisionRecallF-measure

Valu

e (

)

0

20

40

60

80

100

120

Al

Uamp

I

SampI

SampU

ICM

P

UD

P

SYN

Nor

mal

Figure 13 Precision recall and 119891-measure for the DDoS attackclassifier in OverWatch

to the evaluation result shown in Figure 14 defense actuatorsin OverWatch perform several orders of magnitude betterthan the controller-based reaction mechanisms Moreoverthough the forwarding performance for actuators is evidentlylower compared with hardware path this could be improvedif high-efficient data path (eg DPDK [40]) is utilized forthe communication between software and hardware on theswitch

7 Conclusion

To overcome the challenges of southbound bottleneck andthe lack of collaborative intelligence in SDN-based DDoSattack defense mechanisms in this paper we introducedOverWatch a SDN-based high-efficient cross-plane DDoS


Control pathOverWatch pathData plane path

128 256 512 102464Packet size

100

101

102

103

104

Num

ber o

f bits

per

seco

nd (M

bps)

Figure 14 Different bits rate according to packet size using differentpaths in the testbed

attack defense framework with collaborative intelligence Itis collaboratively splitting defense functionalities across dataand control plane and enabling both planes to detect anddefend against DDoS attacks on different levels Throughexperiments it can be concluded that OverWatch is capableof high accuracy detection and real-time defending reactionMeanwhile the communication overhead on SDN south-bound interface is also greatly reduced All these outcomesdemonstrate the feasibility of OverWatch in large-scale net-works We anticipate that OverWatch becomes a buildingblock in the SDN-based network security applications

Conflicts of Interest

The authors declare that they have no conflicts of interest

Acknowledgments

This research was supported in part by Chinese NationalPrograms for High Technology Research and Development(863 Programs) (Grant no 2015AA016103) the project ofNational Science Foundation of China (Grant no 61601483)and Startup ResearchGrant of National University of DefenseTechnology (Grant no JC15-06-01)

References

[1] S Yu Y Tian S Guo andD OWu ldquoCan we beat DDoS attacksin cloudsrdquo IEEE Transactions on Parallel and DistributedSystems vol 25 no 9 pp 2245ndash2254 2014

[2] D Bisson ldquoThe 5 most significant ddos attacks of 2016rdquo httpswwwtripwirecomstate-of-securitysecurity-data-protectioncyber-security5-significant-ddos-attacks-2016

[3] D Geneiatakis G Portokalidis and A D Keromytis ldquoA mul-tilayer overlay network architecture for enhancing IP services

availability against DoSrdquo in Proceedings of the InternationalConference on Information Systems Security vol 7093 2011

[4] X Liu X Yang and Y Lu ldquoTo filter or to authorize Network-layer DoS defense against multimillion-node botnetsrdquo in Pro-ceedings of the ACM SIGCOMM 2008 Conference on DataCommunication SIGCOMMrsquo08 pp 195ndash206 August 2008

[5] P Mittal D Kim Y-C Hu and M Caesar Mirage TowardsDeployable Ddos Defense for Web Applications 2011

[6] H Wang Q Jia D Fleck W Powell F Li and A Stavrou ldquoAmoving target DDoS defense mechanismrdquo Computer Commu-nications vol 46 pp 10ndash21 2014

[7] S T Zargar J Joshi and D Tipper ldquoA survey of defense mech-anisms against distributed denial of service (DDOS) floodingattacksrdquo IEEE Communications Surveys amp Tutorials vol 15 no4 pp 2046ndash2069 2013

[8] R Braga E Mota and A Passito ldquoLightweight DDoS floodingattack detection using NOXOpenFlowrdquo in Proceedings of the35th Annual IEEE Conference on Local Computer Networks(LCN rsquo10) pp 408ndash415 Denver Colo USA October 2010

[9] Y Xu and Y Liu ldquoDDoS attack detection under SDN contextrdquoin Proceedings of the 35th Annual IEEE International Conferenceon Computer Communications IEEE INFOCOM 2016 pp 1ndash9April 2016

[10] S M Mousavi and M St-Hilaire ldquoEarly detection of DDoSattacks against SDN controllersrdquo in Proceedings of the 2015International Conference on Computing Networking and Com-munications ICNC 2015 pp 77ndash81 February 2015

[11] Y Zhang ldquoAn adaptive flow counting method for anomalydetection in SDNrdquo in Proceedings of the 2013 9th ACM Inter-national Conference on Emerging Networking Experiments andTechnologies CoNEXT 2013 pp 25ndash30 December 2013

[12] Y Cui L Yan S Li et al ldquoSD-Anti-DDoS Fast and efficientDDoS defense in software-defined networksrdquo Journal of Net-work and Computer Applications vol 68 pp 65ndash79 2016

[13] S Oueslati J Roberts and N Sbihi ldquoFlow-aware traffic controlfor a content-centric networkrdquo in Proceedings of the IEEEConference on Computer Communications INFOCOM 2012 pp2417ndash2425 March 2012

[14] S R Chowdhury M F Bari R Ahmed and R Boutaba ldquoPay-Less A low cost network monitoring framework for softwaredefined networksrdquo in Proceedings of the IEEEIFIP NetworkOperations and Management Symposium Management in aSoftware Defined World NOMS 2014 pp 1ndash9 May 2014

[15] J Seo C Lee T Shon K-H Cho and J Moon ldquoA new DDoSdetectionmodel usingmultiple SVMs and TRArdquo in Proceedingsof the EUCWorkshops 2005

[16] S Shin V Yegneswaran P Porras and G Gu ldquoAVANT-GUARD Scalable and vigilant switch flow management insoftware-defined networksrdquo in Proceedings of the 2013 ACMSIGSACConference on Computer and Communications SecurityCCS 2013 pp 413ndash424 November 2013

[17] M Ambrosin M Conti F De Gaspari and R PoovendranldquoLineSwitch Tackling Control Plane Saturation Attacks inSoftware-Defined Networkingrdquo IEEEACM Transactions onNetworking vol 25 no 2 pp 1206ndash1219 2017

[18] X Yang B Han Z Sun and J Huang ldquoSdn-based ddos attackdetection with cross-plane collaboration and lightweight flowmonitoringrdquo in Proceedings of the Global CommunicationsConference 2017


[19] A Mahimkar J Dange V Shmatikov H M Vin and Y Zhangldquodfence Transparent network-based denial of service mitiga-tionrdquo in Proceedings of the USENIX Symposium on NetworkedSystems Design and Implementation 2007

[20] B Wang Y Zheng W Lou and Y T Hou ldquoDDoS attack pro-tection in the era of cloud computing and Software-DefinedNetworkingrdquo Computer Networks vol 81 pp 308ndash319 2015

[21] K Kalkan G Gur and F Alagoz ldquoDefenseMechanisms againstDDoS Attacks in SDN Environmentrdquo IEEE CommunicationsMagazine vol 55 no 9 pp 175ndash179 2017

[22] M Moshref M Yu and R Govindan ldquoResourceaccuracytradeoffs in software-defined measurementrdquo in Proceedings ofthe 2013 2nd ACM SIGCOMMWorkshop on Hot Topics in Soft-ware DefinedNetworking HotSDN 2013 pp 73ndash78 August 2013

[23] P Phaal S Panchen and N McKee ldquoInMon CorporationrsquossFlowAMethod forMonitoringTraffic in Switched andRoutedNetworksrdquo RFC Editor RFC3176 2001

[24] M Aslan and A Matrawy ldquoOn the impact of network state col-lection on the performance of SDN applicationsrdquo IEEE Com-munications Letters vol 20 no 1 pp 5ndash8 2016

[25] Z Cai Z Wang K Zheng and J Cao ldquoA Distributed TCAMcoprocessor architecture for integrated longest prefixmatchingpolicy filtering and content filteringrdquo IEEE Transactions onComputers vol 62 no 3 pp 417ndash427 2013

[26] S Shin P A Porras V Yegneswaran M W Fong G Gu andM Tyson ldquoFresco Modular composable security services forsoftware-defined networksrdquo in Proceedings of the Network andDistributed System Security 2013

[27] ldquoDefense4alltutorialrdquo httpswikiopendaylightorgviewDe-fense4AllTutorial

[28] J Mao B Han Z Sun X Lu and Z Zhang ldquoEfficient mis-matched packet buffer management with packet order-preserv-ing for OpenFlow networksrdquo Computer Networks vol 110 pp91ndash103 2016

[29] L BoeroMCello CGaribottoMMarchese andMMongellildquoBeaQoS Load balancing and deadline management of queuesin an OpenFlow SDN switchrdquo Computer Networks vol 106 pp161ndash170 2016

[30] J Sonchack J M Smith A J Aviv and E Keller ldquoEnablingpractical software-defined networking security applicationswith ofxrdquo in Proceedings of the Network and Distributed SystemSecurity vol 16 pp 1ndash15 2016

[31] D D Clark C Partridge J C Ramming and J T WroclawskildquoA knowledge plane for the internetrdquo in Proceedings of the2003 Conference on Applications Technologies Architecturesand Protocols for Computer Communications pp 3ndash10 ACM2003

[32] O S S Version Openflow Switch Specification 15 1 (ProtocolVersion 0x06) 2014

[33] F Tomonori ldquoIntroduction to ryu sdn frameworkrdquo in Proceed-ings of the Open Networking Summit April 2013

[34] J Schmidhuber ldquoDeep learning in neural networks anoverviewrdquo Neural Networks vol 61 pp 85ndash117 2015

[35] R Gens and P Domingos ldquoDeep symmetry networksrdquo in Pro-ceedings of the 28th Annual Conference on Neural InformationProcessing Systems 2014 NIPS 2014 pp 2537ndash2545 December2014

[36] L Wang Y Zeng and T Chen ldquoBack propagation neuralnetwork with adaptive differential evolution algorithm for timeseries forecastingrdquo Expert Systems with Applications vol 42 no2 pp 855ndash863 2015

[37] Y Hideki ldquoTopology viewerrdquo httpsgithubcomosrgryublobmasterdocsourceguirst

[38] S Zhu J Bi C Sun CWu andHHu ldquoSDPA Enhancing state-ful forwarding for software-defined networkingrdquo in Proceedingsof the 23rd IEEE International Conference on Network ProtocolsICNP 2015 pp 323ndash333 November 2015

[39] D Dittrich The ldquoStacheldrahtrdquo Distributed Denial of ServiceAttack Tool 1999

[40] D Intel Data Plane Development Kit 2015

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018


Active and Passive Electronic Components

VLSI Design



Shock and Vibration


Civil EngineeringAdvances in

Acoustics and VibrationAdvances in



Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of



Journal ofEngineeringVolume 2018

SensorsJournal of



RotatingMachinery


Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018


Chemical EngineeringInternational Journal of Antennas and

Propagation




Navigation and Observation


Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom


can be detected and defeated in an early stage Howeverexisting approaches which build DDoS attack defense appli-cations upon the control plane are challenging to providehigh defense performance On the one hand DDoS attackdetection methods often require analysis techniques that aremore advanced than de facto SDN data plane allows Thusthe controller needs to poll flow statistics or packets fromdata plane switches frequently for attack detection and botnetlocation [8 10 14 15] which increases southbound overheadand detection delay significantly On the other hand thepotential advantages in exploiting collaborative intelligenceof SDN have not been well investigated as effective DDoSattack defense requires extremely accurate detection and rap-id reaction in bothOtherwise itmay result in SDNcontrollersaturation attack in the worst case as discussed in [16 17]

In this paper in order to protect hosts and servers fromhigh volume DDoS attacks inside a particular network (egautonomous system) we design and implement a high-efficient cross-plane DDoS attack defense framework withcollaborative intelligence in a pure SDN environment calledOverWatch OverWatch overcomes the aforementionedproblems of existing SDN-based methods by collaborativelysplitting defense functionalities across data plane and controlplane and enabling both planes with abilities to intelligentlydetect and react to DDoS attacks in cooperation The maindifference between traditional frameworks in SDN andOverWatch is that we take the data plane into considerationfor cross-plane optimization In the proposed OverWatchframework defense procedure is divided into two phasesdetection phase and reaction phase

In the detection phase a lightweight flow monitoringalgorithm is proposed to serve the data plane as DDoS attacksensor We focus on two key features of DDoS attack trafficvolume feature and asymmetry feature The proposed flowmonitoring algorithm captures DDoS attack traffic in acoarse-grained manner by polling the values of SDN switchcounters On the control plane a machine learning basedDDoS attack classifier and a botnet tracking algorithm areutilized to locate a DDoS attack in finer granularity for exam-ple attack type and botnet locations Specifically featuresextracted from attack traffic and holistic information of thenetwork are fed into DDoS attack classifier and botnettracker respectively to determine the attack type and botnetlocations

In the reaction phase based on the results obtained fromthe detection phase a novel defense strategy offloadingmech-anism is proposed to enable DDoS attack defense actuators tobe executed on the SDN switches automatically Thus SDNcontroller can be free from conducting specific defensiveactions resulting in a dynamic attack reaction efficiencyMore specifically we concentrate on exploiting the com-putational resources of switch CPUs and the flexibility ofsouthbound interface in order to deploy defense actuators onthe switches which are closest to the botnet

The main contributions of this paper can be summarizedas follows

(i) We design a cross-plane DDoS attack defense frame-work in SDN that exploits collaborative intelligence

between data plane and control plane with highdefense efficiency

(ii) We develop a collaborative DDoS attack detectionmechanism which consists of a coarse-grained flowmonitoring algorithm on the data plane and a fine-grained machine learning based attack classificationalgorithm on the control plane

(iii) We propose a novel defense strategy offloadingmech-anism to dynamically deploy defense applicationsacross the controller and switches by which rapidattack reaction and accurate botnet location can beachieved

(iv) We conduct extensive experiments on a real-worldnetwork with a FPGA-based OpenFlow switch proto-type a Ryu controller and laptops generating DDoSattack traffic Experimental results validate the effi-ciency of our proposed OverWatch framework withhigh detection accuracy and real-time DDoS attackdefending reaction as well as reduced communica-tion overhead on SDN southbound interface

The rest of this paper is organized as follows Section 2covers background and motivation of this paper Section 3presents the architecture of our proposed OverWatch frame-work Sections 4 and 5 are mechanisms of two phases (detec-tion phase and reaction phase) in OverWatch Section 6presents the experimental results Finally this paper is con-cluded in Section 7

2 Background and Motivation

21 Middle-Boxes Based Defense Mechanisms Characteris-tics of DDoS attacks have been widely studied and research-ers have proposed various methods to detectdefend DDoSattacks Traditionally DDoS attack defense applications aredeployed on middle-box devices [3 4 19] which are special-ized equipment or software that detects and reacts to DDoSattacks from a single spot on the network The middle-boxescan provide high DDoS attack detection performance How-ever due to various interfaces provided by them differentmiddle-boxes seldom share information causing them andnetwork operators to lack holistic view of DDoS attacks [20]Mahimkar et al in [19] proposed amethod to deploy middle-boxes dynamically in the protected network but without theglobal perspective of a network where deploying them couldbe a nerve-racking problem For example assuming an attackis detected on multiple middle-boxes alone the attack tracethe most effective defense strategy would be processing mali-cious packets on the devices close to the source sideHoweverattack trace-back could not be accomplished without globalinformation of network

22 SDN-Based Defense Mechanisms SDN provides a stan-dard interface for a centralized controller to manage eachswitch under control remotely This enables the SDN con-troller to obtain the entire network information and to makedefense strategies in holistic views [8ndash11 15 18 21] In thefield of network monitoring many researches focus on how














Control plane

Data plane



library

Actuator


Victim

Switch 1DDoS sensor

Switch 3DDoS sensor

Switch 2DDoS sensor

Actuator

Actuator

Botnet1

Botnet2

1

1

5

3

22

4


Actuator chain

Match

Match

whereTo

DDoSactuator

1

DDoSactuator

2

DDoSactuator

N

Egresspackets


SDN switch HW











SDN controller


Switch CPU

(1) Download


(7) Send Pkt

(5) Add rule

(2) Compile


Agent process

Sourcecode Actuator

NICPCIe driver

Switch hardware

MetadataPkt













Application layer


Service layer


Defense enabler

Southbound layer

3 1

25

outputs4info

Send Poll Register











119905119899and119862Pkt




119861119905119899 =119862Byte119905119899


119905119899 minus 119905119899minus1 (1)


119875119905119899 =119862Pkt119905119899

minus 119862Pkt119905119899minus1

119905119899 minus 119905119899minus1 (2)



119860Byte119905119899

=119861in119905119899

119861out119905119899

(3)



119860Pkt119905119899

=119875in119905119899

119875out119905119899

(4)


Our proposed module

Basic module

Botnet tracker


OpenFlow channel

OF switch agent

NIC driver

DDoS classifier

DDoS dataOF header

ParsePkt flow

ExecuteLookup

Metadata Pkt body

Pkt Buffer


extractorprocessor


Monitorthreads

Trackingthread

topologyviewer

3

41

value

7features

52

8

9

10features

11

6

Modify rule

Mirror PktCounter

Pkt buffPkt Buff

FlowID

Traffic

DDoS data

Pkt_in

Traffic










119899+1


Vpredict119899+1 =

119899

sum119894=1

120582119894Vactual119894

119899

sum119894=1

120582119894 = 1




elseContinue

end ifend if

end while



X1 X2 XN

X1 X2 XM

y1 y2 yN

y1 y2 yM

U b1

U b1U b1

V b2

V b2

V b2

W b3

X1 X2 XN

y1 y2 yS

Input layer

Hidden layer 1

Hidden layer 2

Output layer

(a)

(b)

(c)















Loss = ( 12119898

119898

sum119894=1

119883119894 minus 1198831198942) + 1205822

119899119897minus1

sum119897=1

119904119897

sum119894=1

119904119897+1

sum119895=1

(119882119897119895119894)2

end for


Our proposed module

Basic module

Defense library

SYN proxyDDoS



3


A1 A2 An


NIC driver


Metadata Pkt body

5

6

8

79

4


Send Pkt


Pkt_out

Register

Load code

Redirect pkt

Modify rule























50

0

15 20 2510

Time (second)

Byte

rate

(Bps

)

25 times 106

20 times 106

15 times 106

10 times 106

5 times 106

8

10

12

14

16

18

20

Met

ric v

alue

(a)



500

15 20 2510

Time (second)

Pack

et ra

te (p

ps)

80 times 103

60 times 103

40 times 103

20 times 103

0

1

2

3

4

5

6

Met

ric v

alue

140 times 103

120 times 103

100 times 103

(b)



50 15 20 2510

Time (second)

0

2

4

6

8

Met

ric v

alue

0

50

100

150

200

250

Byte

coun

t asy

mm

etry

(c)


50 15 20 2510

Time (second)

0

2

4

6

8

10

Met

ric v

alue

0

20

40

60

Pack

ets c

ount

asym

met

ry


(d)








Changes detected

0

2

4

6

8

10

12

14

Met

ric v

alue

50 15 20 2510

Time (second)

(a)

Barely change


50 15 20 2510

Time (second)

0

2

4

6

8

10

Met

ric v

alue

0

1

2

3

4

5

Pack

et co

unt a

sym

met

ry(b)


100 times 103

10 times 103

1 times 103

100 times 100

Com

mun

icat

ion

over

head

(byt

esm

in)














TCP




UDP




ICMP







09

08

07

06

05

04

03

02

01

00

9270 011 000 012 019 000 067 412

093 9458 039 059 232 412 000 159

105 084 9443 081 431 087 332 164

000 075 142 9771 502 665 267 163

091 134 133 011 7722 473 003 190

040 143 092 000 387 7665 120 255

000 039 116 043 393 161 9074 409

000 056 035 023 314 538 138 8648

No

SYN

UDP

ICMP

SampU

SampI

UampI

All

No

Pred

icte

d

Actual

SYN

UD

P

ICM

P

SampU

SampI

Uamp

I

All



Valu

e (

)

0

20

40

60

80

100

120

Al

Uamp

I

SampI

SampU

ICM

P

UD

P

SYN

Nor

mal



7 Conclusion




128 256 512 102464Packet size

100

101

102

103

104

Num

ber o

f bits

per

seco

nd (M

bps)





Acknowledgments


References













































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia















Control plane

Data plane



library

Actuator


Victim

Switch 1DDoS sensor

Switch 3DDoS sensor

Switch 2DDoS sensor

Actuator

Actuator

Botnet1

Botnet2

1

1

5

3

22

4


Actuator chain

Match

Match

whereTo

DDoSactuator

1

DDoSactuator

2

DDoSactuator

N

Egresspackets


SDN switch HW











SDN controller


Switch CPU

(1) Download


(7) Send Pkt

(5) Add rule

(2) Compile


Agent process

Sourcecode Actuator

NICPCIe driver

Switch hardware

MetadataPkt













Application layer


Service layer


Defense enabler

Southbound layer

3 1

25

outputs4info

Send Poll Register











119905119899and119862Pkt




119861119905119899 =119862Byte119905119899


119905119899 minus 119905119899minus1 (1)


119875119905119899 =119862Pkt119905119899

minus 119862Pkt119905119899minus1

119905119899 minus 119905119899minus1 (2)



119860Byte119905119899

=119861in119905119899

119861out119905119899

(3)



119860Pkt119905119899

=119875in119905119899

119875out119905119899

(4)


Our proposed module

Basic module

Botnet tracker


OpenFlow channel

OF switch agent

NIC driver

DDoS classifier

DDoS dataOF header

ParsePkt flow

ExecuteLookup

Metadata Pkt body

Pkt Buffer


extractorprocessor


Monitorthreads

Trackingthread

topologyviewer

3

41

value

7features

52

8

9

10features

11

6

Modify rule

Mirror PktCounter

Pkt buffPkt Buff

FlowID

Traffic

DDoS data

Pkt_in

Traffic










119899+1


Vpredict119899+1 =

119899

sum119894=1

120582119894Vactual119894

119899

sum119894=1

120582119894 = 1




elseContinue

end ifend if

end while



X1 X2 XN

X1 X2 XM

y1 y2 yN

y1 y2 yM

U b1

U b1U b1

V b2

V b2

V b2

W b3

X1 X2 XN

y1 y2 yS

Input layer

Hidden layer 1

Hidden layer 2

Output layer

(a)

(b)

(c)















Loss = ( 12119898

119898

sum119894=1

119883119894 minus 1198831198942) + 1205822

119899119897minus1

sum119897=1

119904119897

sum119894=1

119904119897+1

sum119895=1

(119882119897119895119894)2

end for


Our proposed module

Basic module

Defense library

SYN proxyDDoS



3


A1 A2 An


NIC driver


Metadata Pkt body

5

6

8

79

4


Send Pkt


Pkt_out

Register

Load code

Redirect pkt

Modify rule























50

0

15 20 2510

Time (second)

Byte

rate

(Bps

)

25 times 106

20 times 106

15 times 106

10 times 106

5 times 106

8

10

12

14

16

18

20

Met

ric v

alue

(a)



500

15 20 2510

Time (second)

Pack

et ra

te (p

ps)

80 times 103

60 times 103

40 times 103

20 times 103

0

1

2

3

4

5

6

Met

ric v

alue

140 times 103

120 times 103

100 times 103

(b)



50 15 20 2510

Time (second)

0

2

4

6

8

Met

ric v

alue

0

50

100

150

200

250

Byte

coun

t asy

mm

etry

(c)


50 15 20 2510

Time (second)

0

2

4

6

8

10

Met

ric v

alue

0

20

40

60

Pack

ets c

ount

asym

met

ry


(d)








Changes detected

0

2

4

6

8

10

12

14

Met

ric v

alue

50 15 20 2510

Time (second)

(a)

Barely change


50 15 20 2510

Time (second)

0

2

4

6

8

10

Met

ric v

alue

0

1

2

3

4

5

Pack

et co

unt a

sym

met

ry(b)


100 times 103

10 times 103

1 times 103

100 times 100

Com

mun

icat

ion

over

head

(byt

esm

in)














TCP




UDP




ICMP







09

08

07

06

05

04

03

02

01

00

9270 011 000 012 019 000 067 412

093 9458 039 059 232 412 000 159

105 084 9443 081 431 087 332 164

000 075 142 9771 502 665 267 163

091 134 133 011 7722 473 003 190

040 143 092 000 387 7665 120 255

000 039 116 043 393 161 9074 409

000 056 035 023 314 538 138 8648

No

SYN

UDP

ICMP

SampU

SampI

UampI

All

No

Pred

icte

d

Actual

SYN

UD

P

ICM

P

SampU

SampI

Uamp

I

All



Valu

e (

)

0

20

40

60

80

100

120

Al

Uamp

I

SampI

SampU

ICM

P

UD

P

SYN

Nor

mal



7 Conclusion




128 256 512 102464Packet size

100

101

102

103

104

Num

ber o

f bits

per

seco

nd (M

bps)





Acknowledgments


References













































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



Control plane

Data plane



library

Actuator


Victim

Switch 1DDoS sensor

Switch 3DDoS sensor

Switch 2DDoS sensor

Actuator

Actuator

Botnet1

Botnet2

1

1

5

3

22

4


Actuator chain

Match

Match

whereTo

DDoSactuator

1

DDoSactuator

2

DDoSactuator

N

Egresspackets


SDN switch HW











SDN controller


Switch CPU

(1) Download


(7) Send Pkt

(5) Add rule

(2) Compile


Agent process

Sourcecode Actuator

NICPCIe driver

Switch hardware

MetadataPkt













Application layer


Service layer


Defense enabler

Southbound layer

3 1

25

outputs4info

Send Poll Register











119905119899and119862Pkt




119861119905119899 =119862Byte119905119899


119905119899 minus 119905119899minus1 (1)


119875119905119899 =119862Pkt119905119899

minus 119862Pkt119905119899minus1

119905119899 minus 119905119899minus1 (2)



119860Byte119905119899

=119861in119905119899

119861out119905119899

(3)



119860Pkt119905119899

=119875in119905119899

119875out119905119899

(4)


Our proposed module

Basic module

Botnet tracker


OpenFlow channel

OF switch agent

NIC driver

DDoS classifier

DDoS dataOF header

ParsePkt flow

ExecuteLookup

Metadata Pkt body

Pkt Buffer


extractorprocessor


Monitorthreads

Trackingthread

topologyviewer

3

41

value

7features

52

8

9

10features

11

6

Modify rule

Mirror PktCounter

Pkt buffPkt Buff

FlowID

Traffic

DDoS data

Pkt_in

Traffic










119899+1


Vpredict119899+1 =

119899

sum119894=1

120582119894Vactual119894

119899

sum119894=1

120582119894 = 1




elseContinue

end ifend if

end while



X1 X2 XN

X1 X2 XM

y1 y2 yN

y1 y2 yM

U b1

U b1U b1

V b2

V b2

V b2

W b3

X1 X2 XN

y1 y2 yS

Input layer

Hidden layer 1

Hidden layer 2

Output layer

(a)

(b)

(c)















Loss = ( 12119898

119898

sum119894=1

119883119894 minus 1198831198942) + 1205822

119899119897minus1

sum119897=1

119904119897

sum119894=1

119904119897+1

sum119895=1

(119882119897119895119894)2

end for


Our proposed module

Basic module

Defense library

SYN proxyDDoS



3


A1 A2 An


NIC driver


Metadata Pkt body

5

6

8

79

4


Send Pkt


Pkt_out

Register

Load code

Redirect pkt

Modify rule























50

0

15 20 2510

Time (second)

Byte

rate

(Bps

)

25 times 106

20 times 106

15 times 106

10 times 106

5 times 106

8

10

12

14

16

18

20

Met

ric v

alue

(a)



500

15 20 2510

Time (second)

Pack

et ra

te (p

ps)

80 times 103

60 times 103

40 times 103

20 times 103

0

1

2

3

4

5

6

Met

ric v

alue

140 times 103

120 times 103

100 times 103

(b)



50 15 20 2510

Time (second)

0

2

4

6

8

Met

ric v

alue

0

50

100

150

200

250

Byte

coun

t asy

mm

etry

(c)


50 15 20 2510

Time (second)

0

2

4

6

8

10

Met

ric v

alue

0

20

40

60

Pack

ets c

ount

asym

met

ry


(d)








Changes detected

0

2

4

6

8

10

12

14

Met

ric v

alue

50 15 20 2510

Time (second)

(a)

Barely change


50 15 20 2510

Time (second)

0

2

4

6

8

10

Met

ric v

alue

0

1

2

3

4

5

Pack

et co

unt a

sym

met

ry(b)


100 times 103

10 times 103

1 times 103

100 times 100

Com

mun

icat

ion

over

head

(byt

esm

in)














TCP




UDP




ICMP







09

08

07

06

05

04

03

02

01

00

9270 011 000 012 019 000 067 412

093 9458 039 059 232 412 000 159

105 084 9443 081 431 087 332 164

000 075 142 9771 502 665 267 163

091 134 133 011 7722 473 003 190

040 143 092 000 387 7665 120 255

000 039 116 043 393 161 9074 409

000 056 035 023 314 538 138 8648

No

SYN

UDP

ICMP

SampU

SampI

UampI

All

No

Pred

icte

d

Actual

SYN

UD

P

ICM

P

SampU

SampI

Uamp

I

All



Valu

e (

)

0

20

40

60

80

100

120

Al

Uamp

I

SampI

SampU

ICM

P

UD

P

SYN

Nor

mal



7 Conclusion




128 256 512 102464Packet size

100

101

102

103

104

Num

ber o

f bits

per

seco

nd (M

bps)





Acknowledgments


References













































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



SDN controller


Switch CPU

(1) Download


(7) Send Pkt

(5) Add rule

(2) Compile


Agent process

Sourcecode Actuator

NICPCIe driver

Switch hardware

MetadataPkt













Application layer


Service layer


Defense enabler

Southbound layer

3 1

25

outputs4info

Send Poll Register











119905119899and119862Pkt




119861119905119899 =119862Byte119905119899


119905119899 minus 119905119899minus1 (1)


119875119905119899 =119862Pkt119905119899

minus 119862Pkt119905119899minus1

119905119899 minus 119905119899minus1 (2)



119860Byte119905119899

=119861in119905119899

119861out119905119899

(3)



119860Pkt119905119899

=119875in119905119899

119875out119905119899

(4)


Our proposed module

Basic module

Botnet tracker


OpenFlow channel

OF switch agent

NIC driver

DDoS classifier

DDoS dataOF header

ParsePkt flow

ExecuteLookup

Metadata Pkt body

Pkt Buffer


extractorprocessor


Monitorthreads

Trackingthread

topologyviewer

3

41

value

7features

52

8

9

10features

11

6

Modify rule

Mirror PktCounter

Pkt buffPkt Buff

FlowID

Traffic

DDoS data

Pkt_in

Traffic










119899+1


Vpredict119899+1 =

119899

sum119894=1

120582119894Vactual119894

119899

sum119894=1

120582119894 = 1




elseContinue

end ifend if

end while



X1 X2 XN

X1 X2 XM

y1 y2 yN

y1 y2 yM

U b1

U b1U b1

V b2

V b2

V b2

W b3

X1 X2 XN

y1 y2 yS

Input layer

Hidden layer 1

Hidden layer 2

Output layer

(a)

(b)

(c)















Loss = ( 12119898

119898

sum119894=1

119883119894 minus 1198831198942) + 1205822

119899119897minus1

sum119897=1

119904119897

sum119894=1

119904119897+1

sum119895=1

(119882119897119895119894)2

end for


Our proposed module

Basic module

Defense library

SYN proxyDDoS



3


A1 A2 An


NIC driver


Metadata Pkt body

5

6

8

79

4


Send Pkt


Pkt_out

Register

Load code

Redirect pkt

Modify rule























50

0

15 20 2510

Time (second)

Byte

rate

(Bps

)

25 times 106

20 times 106

15 times 106

10 times 106

5 times 106

8

10

12

14

16

18

20

Met

ric v

alue

(a)



500

15 20 2510

Time (second)

Pack

et ra

te (p

ps)

80 times 103

60 times 103

40 times 103

20 times 103

0

1

2

3

4

5

6

Met

ric v

alue

140 times 103

120 times 103

100 times 103

(b)



50 15 20 2510

Time (second)

0

2

4

6

8

Met

ric v

alue

0

50

100

150

200

250

Byte

coun

t asy

mm

etry

(c)


50 15 20 2510

Time (second)

0

2

4

6

8

10

Met

ric v

alue

0

20

40

60

Pack

ets c

ount

asym

met

ry


(d)








Changes detected

0

2

4

6

8

10

12

14

Met

ric v

alue

50 15 20 2510

Time (second)

(a)

Barely change


50 15 20 2510

Time (second)

0

2

4

6

8

10

Met

ric v

alue

0

1

2

3

4

5

Pack

et co

unt a

sym

met

ry(b)


100 times 103

10 times 103

1 times 103

100 times 100

Com

mun

icat

ion

over

head

(byt

esm

in)














TCP




UDP




ICMP







09

08

07

06

05

04

03

02

01

00

9270 011 000 012 019 000 067 412

093 9458 039 059 232 412 000 159

105 084 9443 081 431 087 332 164

000 075 142 9771 502 665 267 163

091 134 133 011 7722 473 003 190

040 143 092 000 387 7665 120 255

000 039 116 043 393 161 9074 409

000 056 035 023 314 538 138 8648

No

SYN

UDP

ICMP

SampU

SampI

UampI

All

No

Pred

icte

d

Actual

SYN

UD

P

ICM

P

SampU

SampI

Uamp

I

All



Valu

e (

)

0

20

40

60

80

100

120

Al

Uamp

I

SampI

SampU

ICM

P

UD

P

SYN

Nor

mal



7 Conclusion




128 256 512 102464Packet size

100

101

102

103

104

Num

ber o

f bits

per

seco

nd (M

bps)





Acknowledgments


References













































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



Application layer


Service layer


Defense enabler

Southbound layer

3 1

25

outputs4info

Send Poll Register











119905119899and119862Pkt




119861119905119899 =119862Byte119905119899


119905119899 minus 119905119899minus1 (1)


119875119905119899 =119862Pkt119905119899

minus 119862Pkt119905119899minus1

119905119899 minus 119905119899minus1 (2)



119860Byte119905119899

=119861in119905119899

119861out119905119899

(3)



119860Pkt119905119899

=119875in119905119899

119875out119905119899

(4)


Our proposed module

Basic module

Botnet tracker


OpenFlow channel

OF switch agent

NIC driver

DDoS classifier

DDoS dataOF header

ParsePkt flow

ExecuteLookup

Metadata Pkt body

Pkt Buffer


extractorprocessor


Monitorthreads

Trackingthread

topologyviewer

3

41

value

7features

52

8

9

10features

11

6

Modify rule

Mirror PktCounter

Pkt buffPkt Buff

FlowID

Traffic

DDoS data

Pkt_in

Traffic










119899+1


Vpredict119899+1 =

119899

sum119894=1

120582119894Vactual119894

119899

sum119894=1

120582119894 = 1




elseContinue

end ifend if

end while



X1 X2 XN

X1 X2 XM

y1 y2 yN

y1 y2 yM

U b1

U b1U b1

V b2

V b2

V b2

W b3

X1 X2 XN

y1 y2 yS

Input layer

Hidden layer 1

Hidden layer 2

Output layer

(a)

(b)

(c)















Loss = ( 12119898

119898

sum119894=1

119883119894 minus 1198831198942) + 1205822

119899119897minus1

sum119897=1

119904119897

sum119894=1

119904119897+1

sum119895=1

(119882119897119895119894)2

end for


Our proposed module

Basic module

Defense library

SYN proxyDDoS



3


A1 A2 An


NIC driver


Metadata Pkt body

5

6

8

79

4


Send Pkt


Pkt_out

Register

Load code

Redirect pkt

Modify rule























50

0

15 20 2510

Time (second)

Byte

rate

(Bps

)

25 times 106

20 times 106

15 times 106

10 times 106

5 times 106

8

10

12

14

16

18

20

Met

ric v

alue

(a)



500

15 20 2510

Time (second)

Pack

et ra

te (p

ps)

80 times 103

60 times 103

40 times 103

20 times 103

0

1

2

3

4

5

6

Met

ric v

alue

140 times 103

120 times 103

100 times 103

(b)



50 15 20 2510

Time (second)

0

2

4

6

8

Met

ric v

alue

0

50

100

150

200

250

Byte

coun

t asy

mm

etry

(c)


50 15 20 2510

Time (second)

0

2

4

6

8

10

Met

ric v

alue

0

20

40

60

Pack

ets c

ount

asym

met

ry


(d)








Changes detected

0

2

4

6

8

10

12

14

Met

ric v

alue

50 15 20 2510

Time (second)

(a)

Barely change


50 15 20 2510

Time (second)

0

2

4

6

8

10

Met

ric v

alue

0

1

2

3

4

5

Pack

et co

unt a

sym

met

ry(b)


100 times 103

10 times 103

1 times 103

100 times 100

Com

mun

icat

ion

over

head

(byt

esm

in)














TCP




UDP




ICMP







09

08

07

06

05

04

03

02

01

00

9270 011 000 012 019 000 067 412

093 9458 039 059 232 412 000 159

105 084 9443 081 431 087 332 164

000 075 142 9771 502 665 267 163

091 134 133 011 7722 473 003 190

040 143 092 000 387 7665 120 255

000 039 116 043 393 161 9074 409

000 056 035 023 314 538 138 8648

No

SYN

UDP

ICMP

SampU

SampI

UampI

All

No

Pred

icte

d

Actual

SYN

UD

P

ICM

P

SampU

SampI

Uamp

I

All



Valu

e (

)

0

20

40

60

80

100

120

Al

Uamp

I

SampI

SampU

ICM

P

UD

P

SYN

Nor

mal



7 Conclusion




128 256 512 102464Packet size

100

101

102

103

104

Num

ber o

f bits

per

seco

nd (M

bps)





Acknowledgments


References













































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



Our proposed module

Basic module

Botnet tracker


OpenFlow channel

OF switch agent

NIC driver

DDoS classifier

DDoS dataOF header

ParsePkt flow

ExecuteLookup

Metadata Pkt body

Pkt Buffer


extractorprocessor


Monitorthreads

Trackingthread

topologyviewer

3

41

value

7features

52

8

9

10features

11

6

Modify rule

Mirror PktCounter

Pkt buffPkt Buff

FlowID

Traffic

DDoS data

Pkt_in

Traffic










119899+1


Vpredict119899+1 =

119899

sum119894=1

120582119894Vactual119894

119899

sum119894=1

120582119894 = 1




elseContinue

end ifend if

end while



X1 X2 XN

X1 X2 XM

y1 y2 yN

y1 y2 yM

U b1

U b1U b1

V b2

V b2

V b2

W b3

X1 X2 XN

y1 y2 yS

Input layer

Hidden layer 1

Hidden layer 2

Output layer

(a)

(b)

(c)















Loss = ( 12119898

119898

sum119894=1

119883119894 minus 1198831198942) + 1205822

119899119897minus1

sum119897=1

119904119897

sum119894=1

119904119897+1

sum119895=1

(119882119897119895119894)2

end for


Our proposed module

Basic module

Defense library

SYN proxyDDoS



3


A1 A2 An


NIC driver


Metadata Pkt body

5

6

8

79

4


Send Pkt


Pkt_out

Register

Load code

Redirect pkt

Modify rule























50

0

15 20 2510

Time (second)

Byte

rate

(Bps

)

25 times 106

20 times 106

15 times 106

10 times 106

5 times 106

8

10

12

14

16

18

20

Met

ric v

alue

(a)



500

15 20 2510

Time (second)

Pack

et ra

te (p

ps)

80 times 103

60 times 103

40 times 103

20 times 103

0

1

2

3

4

5

6

Met

ric v

alue

140 times 103

120 times 103

100 times 103

(b)



50 15 20 2510

Time (second)

0

2

4

6

8

Met

ric v

alue

0

50

100

150

200

250

Byte

coun

t asy

mm

etry

(c)


50 15 20 2510

Time (second)

0

2

4

6

8

10

Met

ric v

alue

0

20

40

60

Pack

ets c

ount

asym

met

ry


(d)








Changes detected

0

2

4

6

8

10

12

14

Met

ric v

alue

50 15 20 2510

Time (second)

(a)

Barely change


50 15 20 2510

Time (second)

0

2

4

6

8

10

Met

ric v

alue

0

1

2

3

4

5

Pack

et co

unt a

sym

met

ry(b)


100 times 103

10 times 103

1 times 103

100 times 100

Com

mun

icat

ion

over

head

(byt

esm

in)














TCP




UDP




ICMP







09

08

07

06

05

04

03

02

01

00

9270 011 000 012 019 000 067 412

093 9458 039 059 232 412 000 159

105 084 9443 081 431 087 332 164

000 075 142 9771 502 665 267 163

091 134 133 011 7722 473 003 190

040 143 092 000 387 7665 120 255

000 039 116 043 393 161 9074 409

000 056 035 023 314 538 138 8648

No

SYN

UDP

ICMP

SampU

SampI

UampI

All

No

Pred

icte

d

Actual

SYN

UD

P

ICM

P

SampU

SampI

Uamp

I

All



Valu

e (

)

0

20

40

60

80

100

120

Al

Uamp

I

SampI

SampU

ICM

P

UD

P

SYN

Nor

mal



7 Conclusion




128 256 512 102464Packet size

100

101

102

103

104

Num

ber o

f bits

per

seco

nd (M

bps)





Acknowledgments


References













































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



X1 X2 XN

X1 X2 XM

y1 y2 yN

y1 y2 yM

U b1

U b1U b1

V b2

V b2

V b2

W b3

X1 X2 XN

y1 y2 yS

Input layer

Hidden layer 1

Hidden layer 2

Output layer

(a)

(b)

(c)















Loss = ( 12119898

119898

sum119894=1

119883119894 minus 1198831198942) + 1205822

119899119897minus1

sum119897=1

119904119897

sum119894=1

119904119897+1

sum119895=1

(119882119897119895119894)2

end for


Our proposed module

Basic module

Defense library

SYN proxyDDoS



3


A1 A2 An


NIC driver


Metadata Pkt body

5

6

8

79

4


Send Pkt


Pkt_out

Register

Load code

Redirect pkt

Modify rule























50

0

15 20 2510

Time (second)

Byte

rate

(Bps

)

25 times 106

20 times 106

15 times 106

10 times 106

5 times 106

8

10

12

14

16

18

20

Met

ric v

alue

(a)



500

15 20 2510

Time (second)

Pack

et ra

te (p

ps)

80 times 103

60 times 103

40 times 103

20 times 103

0

1

2

3

4

5

6

Met

ric v

alue

140 times 103

120 times 103

100 times 103

(b)



50 15 20 2510

Time (second)

0

2

4

6

8

Met

ric v

alue

0

50

100

150

200

250

Byte

coun

t asy

mm

etry

(c)


50 15 20 2510

Time (second)

0

2

4

6

8

10

Met

ric v

alue

0

20

40

60

Pack

ets c

ount

asym

met

ry


(d)








Changes detected

0

2

4

6

8

10

12

14

Met

ric v

alue

50 15 20 2510

Time (second)

(a)

Barely change


50 15 20 2510

Time (second)

0

2

4

6

8

10

Met

ric v

alue

0

1

2

3

4

5

Pack

et co

unt a

sym

met

ry(b)


100 times 103

10 times 103

1 times 103

100 times 100

Com

mun

icat

ion

over

head

(byt

esm

in)














TCP




UDP




ICMP







09

08

07

06

05

04

03

02

01

00

9270 011 000 012 019 000 067 412

093 9458 039 059 232 412 000 159

105 084 9443 081 431 087 332 164

000 075 142 9771 502 665 267 163

091 134 133 011 7722 473 003 190

040 143 092 000 387 7665 120 255

000 039 116 043 393 161 9074 409

000 056 035 023 314 538 138 8648

No

SYN

UDP

ICMP

SampU

SampI

UampI

All

No

Pred

icte

d

Actual

SYN

UD

P

ICM

P

SampU

SampI

Uamp

I

All



Valu

e (

)

0

20

40

60

80

100

120

Al

Uamp

I

SampI

SampU

ICM

P

UD

P

SYN

Nor

mal



7 Conclusion




128 256 512 102464Packet size

100

101

102

103

104

Num

ber o

f bits

per

seco

nd (M

bps)





Acknowledgments


References













































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia






Loss = ( 12119898

119898

sum119894=1

119883119894 minus 1198831198942) + 1205822

119899119897minus1

sum119897=1

119904119897

sum119894=1

119904119897+1

sum119895=1

(119882119897119895119894)2

end for


Our proposed module

Basic module

Defense library

SYN proxyDDoS



3


A1 A2 An


NIC driver


Metadata Pkt body

5

6

8

79

4


Send Pkt


Pkt_out

Register

Load code

Redirect pkt

Modify rule























50

0

15 20 2510

Time (second)

Byte

rate

(Bps

)

25 times 106

20 times 106

15 times 106

10 times 106

5 times 106

8

10

12

14

16

18

20

Met

ric v

alue

(a)



500

15 20 2510

Time (second)

Pack

et ra

te (p

ps)

80 times 103

60 times 103

40 times 103

20 times 103

0

1

2

3

4

5

6

Met

ric v

alue

140 times 103

120 times 103

100 times 103

(b)



50 15 20 2510

Time (second)

0

2

4

6

8

Met

ric v

alue

0

50

100

150

200

250

Byte

coun

t asy

mm

etry

(c)


50 15 20 2510

Time (second)

0

2

4

6

8

10

Met

ric v

alue

0

20

40

60

Pack

ets c

ount

asym

met

ry


(d)








Changes detected

0

2

4

6

8

10

12

14

Met

ric v

alue

50 15 20 2510

Time (second)

(a)

Barely change


50 15 20 2510

Time (second)

0

2

4

6

8

10

Met

ric v

alue

0

1

2

3

4

5

Pack

et co

unt a

sym

met

ry(b)


100 times 103

10 times 103

1 times 103

100 times 100

Com

mun

icat

ion

over

head

(byt

esm

in)














TCP




UDP




ICMP







09

08

07

06

05

04

03

02

01

00

9270 011 000 012 019 000 067 412

093 9458 039 059 232 412 000 159

105 084 9443 081 431 087 332 164

000 075 142 9771 502 665 267 163

091 134 133 011 7722 473 003 190

040 143 092 000 387 7665 120 255

000 039 116 043 393 161 9074 409

000 056 035 023 314 538 138 8648

No

SYN

UDP

ICMP

SampU

SampI

UampI

All

No

Pred

icte

d

Actual

SYN

UD

P

ICM

P

SampU

SampI

Uamp

I

All



Valu

e (

)

0

20

40

60

80

100

120

Al

Uamp

I

SampI

SampU

ICM

P

UD

P

SYN

Nor

mal



7 Conclusion




128 256 512 102464Packet size

100

101

102

103

104

Num

ber o

f bits

per

seco

nd (M

bps)





Acknowledgments


References













































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia


















50

0

15 20 2510

Time (second)

Byte

rate

(Bps

)

25 times 106

20 times 106

15 times 106

10 times 106

5 times 106

8

10

12

14

16

18

20

Met

ric v

alue

(a)



500

15 20 2510

Time (second)

Pack

et ra

te (p

ps)

80 times 103

60 times 103

40 times 103

20 times 103

0

1

2

3

4

5

6

Met

ric v

alue

140 times 103

120 times 103

100 times 103

(b)



50 15 20 2510

Time (second)

0

2

4

6

8

Met

ric v

alue

0

50

100

150

200

250

Byte

coun

t asy

mm

etry

(c)


50 15 20 2510

Time (second)

0

2

4

6

8

10

Met

ric v

alue

0

20

40

60

Pack

ets c

ount

asym

met

ry


(d)








Changes detected

0

2

4

6

8

10

12

14

Met

ric v

alue

50 15 20 2510

Time (second)

(a)

Barely change


50 15 20 2510

Time (second)

0

2

4

6

8

10

Met

ric v

alue

0

1

2

3

4

5

Pack

et co

unt a

sym

met

ry(b)


100 times 103

10 times 103

1 times 103

100 times 100

Com

mun

icat

ion

over

head

(byt

esm

in)














TCP




UDP




ICMP







09

08

07

06

05

04

03

02

01

00

9270 011 000 012 019 000 067 412

093 9458 039 059 232 412 000 159

105 084 9443 081 431 087 332 164

000 075 142 9771 502 665 267 163

091 134 133 011 7722 473 003 190

040 143 092 000 387 7665 120 255

000 039 116 043 393 161 9074 409

000 056 035 023 314 538 138 8648

No

SYN

UDP

ICMP

SampU

SampI

UampI

All

No

Pred

icte

d

Actual

SYN

UD

P

ICM

P

SampU

SampI

Uamp

I

All



Valu

e (

)

0

20

40

60

80

100

120

Al

Uamp

I

SampI

SampU

ICM

P

UD

P

SYN

Nor

mal



7 Conclusion




128 256 512 102464Packet size

100

101

102

103

104

Num

ber o

f bits

per

seco

nd (M

bps)





Acknowledgments


References













































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia





50

0

15 20 2510

Time (second)

Byte

rate

(Bps

)

25 times 106

20 times 106

15 times 106

10 times 106

5 times 106

8

10

12

14

16

18

20

Met

ric v

alue

(a)



500

15 20 2510

Time (second)

Pack

et ra

te (p

ps)

80 times 103

60 times 103

40 times 103

20 times 103

0

1

2

3

4

5

6

Met

ric v

alue

140 times 103

120 times 103

100 times 103

(b)



50 15 20 2510

Time (second)

0

2

4

6

8

Met

ric v

alue

0

50

100

150

200

250

Byte

coun

t asy

mm

etry

(c)


50 15 20 2510

Time (second)

0

2

4

6

8

10

Met

ric v

alue

0

20

40

60

Pack

ets c

ount

asym

met

ry


(d)








Changes detected

0

2

4

6

8

10

12

14

Met

ric v

alue

50 15 20 2510

Time (second)

(a)

Barely change


50 15 20 2510

Time (second)

0

2

4

6

8

10

Met

ric v

alue

0

1

2

3

4

5

Pack

et co

unt a

sym

met

ry(b)


100 times 103

10 times 103

1 times 103

100 times 100

Com

mun

icat

ion

over

head

(byt

esm

in)














TCP




UDP




ICMP







09

08

07

06

05

04

03

02

01

00

9270 011 000 012 019 000 067 412

093 9458 039 059 232 412 000 159

105 084 9443 081 431 087 332 164

000 075 142 9771 502 665 267 163

091 134 133 011 7722 473 003 190

040 143 092 000 387 7665 120 255

000 039 116 043 393 161 9074 409

000 056 035 023 314 538 138 8648

No

SYN

UDP

ICMP

SampU

SampI

UampI

All

No

Pred

icte

d

Actual

SYN

UD

P

ICM

P

SampU

SampI

Uamp

I

All



Valu

e (

)

0

20

40

60

80

100

120

Al

Uamp

I

SampI

SampU

ICM

P

UD

P

SYN

Nor

mal



7 Conclusion




128 256 512 102464Packet size

100

101

102

103

104

Num

ber o

f bits

per

seco

nd (M

bps)





Acknowledgments


References













































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia




Changes detected

0

2

4

6

8

10

12

14

Met

ric v

alue

50 15 20 2510

Time (second)

(a)

Barely change


50 15 20 2510

Time (second)

0

2

4

6

8

10

Met

ric v

alue

0

1

2

3

4

5

Pack

et co

unt a

sym

met

ry(b)


100 times 103

10 times 103

1 times 103

100 times 100

Com

mun

icat

ion

over

head

(byt

esm

in)














TCP




UDP




ICMP







09

08

07

06

05

04

03

02

01

00

9270 011 000 012 019 000 067 412

093 9458 039 059 232 412 000 159

105 084 9443 081 431 087 332 164

000 075 142 9771 502 665 267 163

091 134 133 011 7722 473 003 190

040 143 092 000 387 7665 120 255

000 039 116 043 393 161 9074 409

000 056 035 023 314 538 138 8648

No

SYN

UDP

ICMP

SampU

SampI

UampI

All

No

Pred

icte

d

Actual

SYN

UD

P

ICM

P

SampU

SampI

Uamp

I

All



Valu

e (

)

0

20

40

60

80

100

120

Al

Uamp

I

SampI

SampU

ICM

P

UD

P

SYN

Nor

mal



7 Conclusion




128 256 512 102464Packet size

100

101

102

103

104

Num

ber o

f bits

per

seco

nd (M

bps)





Acknowledgments


References













































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia





TCP




UDP




ICMP







09

08

07

06

05

04

03

02

01

00

9270 011 000 012 019 000 067 412

093 9458 039 059 232 412 000 159

105 084 9443 081 431 087 332 164

000 075 142 9771 502 665 267 163

091 134 133 011 7722 473 003 190

040 143 092 000 387 7665 120 255

000 039 116 043 393 161 9074 409

000 056 035 023 314 538 138 8648

No

SYN

UDP

ICMP

SampU

SampI

UampI

All

No

Pred

icte

d

Actual

SYN

UD

P

ICM

P

SampU

SampI

Uamp

I

All



Valu

e (

)

0

20

40

60

80

100

120

Al

Uamp

I

SampI

SampU

ICM

P

UD

P

SYN

Nor

mal



7 Conclusion




128 256 512 102464Packet size

100

101

102

103

104

Num

ber o

f bits

per

seco

nd (M

bps)





Acknowledgments


References













































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia




128 256 512 102464Packet size

100

101

102

103

104

Num

ber o

f bits

per

seco

nd (M

bps)





Acknowledgments


References













































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



























RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia




RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia


Documents

OverWatch: A Cross-Plane DDoS Attack Defense Framework ...downloads.hindawi.com/journals/scn/2018/9649643.pdf · ResearchArticle OverWatch: A Cross-Plane DDoS Attack Defense Framework