Taxonomy of Distributed Denial of Service Mitigation

Approaches for Cloud Computing

Alireza Shameli-Sendi1, Makan Pourzandi2, Mohamed Fekih-Ahmed3 andMohamed Cheriet3

1School of Computer Science, McGill University, Montreal2Ericsson Security Research, Ericsson, Montreal, Canada

3 Synchromedia Lab, Ecole de Technologie Superieure (ETS), University ofQuebec, Montreal, Canada

Emails: alireza.shameli-sendi@cs.mcgill.ca, makan.pourzandi@ericsson.com,mohamed.fekih.ahmed@synchromedia.ca, mohamed.cheriet@etsmtl.ca

Abstract

Cloud computing has a central role to play in meeting today’s businessrequirements. However, Distributed Denial-of-Service (DDoS) attacks canthreaten the availability of cloud functionalities. In recent years, many ef-fort has been expended to detect the various DDoS attack types. In thissurvey paper, our concentration is on how to mitigate these attacks. Webelieve that cloud computing technology can substantially change the waywe respond to a DDoS attack, based on a number of new characteristics,which were introduced with the advent of this technology. We first presenta new taxonomy of DDoS mitigation strategies to organize the work. Then,we go on to discuss the main features of existing DDoS mitigation strategiesand explain their functionalities in the cloud environment. Afterwards, weshow how the existing DDoS mechanisms fit into the network topology ofthe cloud. Finally, we discuss some of these DDoS mechanisms in detail, andcompare their behavior in the cloud. Our objective is to show how thesecharacteristics bring a novel perspective to existing DDoS mechanisms, andso give researchers new insights into how to mitigate DDoS attacks in thecloud computing.

Keywords:Distributed Denial of Service (DDoS), DDoS detection, DDoS mitigation,Defense system, Cloud computing, Software-Defined Networking (SDN)

Preprint submitted to Journal of Network and Computer Applications October 28, 2015

1. Introduction

Cloud computing has a central role to play in meeting today’s businessrequirements. Following the lead of early cloud providers (Amazon, Google,IBM, etc.), organizations such as banks, corporations, hospitals, and medicalcenters have begun to rely on cloud services. However, DDoS attacks can be amajor threat to the availability of these services (Zissis, 2012; Subashini, 2011;Bhadauria, 2011; Zhang, 2012). According to the Cooperative Associationfor Internet Data Analysis (CAIDA), over 5000 DDoS attacks occur on theInternet every week (Zargar, 2013).

DDoS attacks, as the name implies, involve a large number of distributedhosts generating traffic that is directed at a selected target (Huici, 2007).Attack vectors can be categorized into two groups (Ranjan, 2009; Walfish,2010; Spyridopoulos, 2013), brute-force and semantic. Brute-force attacks,also known as ”flooding attacks”, focus on bandwidth consumption by invok-ing vast numbers of bogus requests, aggregating the traffic of a large numberof distributed hosts, and overwhelming the target (Argyraki, 2009). Thesetargets can be applications, hosts, or infrastructure. An example of a brute-force application attack would be a large number of SSH login attempts onall elements of a provider’s network (McPherson, 2010). A brute-force at-tack, because of its distributed nature, can be massive. The biggest botnetscurrently hold over a million bots, and estimates of the number of bots in-volved in any particular DDoS range from a few thousand to upwards of10,000 (NetworkWorld, 2009).

In contrast, semantic attacks, also known as ”vulnerability attacks”, focuson resource starvation by exploiting protocol weaknesses (Mirkovic, 2004).The latest trend is to carry out an application-level attack, based on HTTP,HTTPS, or DNS, for example. This type of attack does not cause majorcongestion, but it is harder to detect and so more challenging to fight. Asemantic attack attempts to exploit a weakness, rather than exhausting band-width/resources, and generally targets a protocol or an application. A DDoSon a protocol does not necessarily involve the characteristic of flooding bymassive amounts of traffic. A well-known example would be the TCP SYNattack, which exploits the allocation of a connection context in the server(Moore, 2006; Argyraki, 2009).

As Figure 1 illustrates, the DDoS defense life-cycle consists of four phases:

2

Prevention

Monitoring

Detection

Mitigation

monitor

analyze mitigate

update

Figure 1: Defense life-cycle.

prevention, monitoring, detection, and mitigation. In the prevention phase,appropriate security appliances are put in place at different locations to se-cure services and data against DDoS attack. In the monitoring phase, toolsare deployed to gather useful host or network information to follow the ex-ecution of the system. The detection phase involves analysis of the systemsthat are running, in order to find the source of malicious traffic or mali-cious attempts to cause DDoS (Abliz, 2011; Shin, 2013). The final phase,mitigation, completes the defense life-cycle by evaluating the severity of theattack and selecting the right response (Shameli-Sendi, 2013) at the righttime (Shameli-Sendi, 2012). In the mitigation phase, a response system se-lects appropriate countermeasures to effectively handle a DDoS attack orslow down the malicious clients (Walfish, 2010).

Existing defense mechanisms against DDoS attacks have limited successbecause they cannot meet the considerable challenge of achieving simultane-ously efficient detection, effective response, acceptable rate of false alarms,and the real-time transfer of all packets (Zargar, 2013; PC World, 2013).Prevention and poor detection alone have resulted in huge financial losses toleading businesses around the world (Alomari, 2012). Strategies and heuris-tics for DDoS detection have been researched extensively (Yu, 2009). In real

3

world, it is not possible to detect attacks with 100% accuracy (Yu, 2012).Therefore, there is need to concentrate on more efficient mitigation mecha-nisms. The cloud by its very nature is more exposed to DDoS attack, but italso provides us with additional means to protect applications against DDoSattacks. Therefore, in this work, we mean by DDoS detection the implemen-tation of mechanisms designed to identify the source of malicious traffic ormalicious flows, and we define DDoS mitigation as the implementation ofmechanisms designed to eliminate the malicious traffic.

Several taxonomies of DDoS defense techniques have been proposed inthe literature (Zargar, 2013; Geng, 2002; Wood, 2004; Mirkovic, 2004; Peng,2007; Abliz, 2011). Mirkovic and Reiher (Mirkovic, 2004) and Taghavi etal. (Zargar, 2013) propose taxonomies for classifying DDoS attacks anddefense techniques, while Peng et al. (Peng, 2007) propose a taxonomy foridentifying the impact of different types of DDoS attacks. Abliz (Abliz,2011) presents a taxonomy of a number of defense mechanisms and providessuggestions to address the shortcomings of some defense frameworks. Inthis paper, we concentrate on DDoS mitigation techniques and how effectivethey are against such attacks in the cloud. Research and development onframeworks for DDoS defense in the cloud environment are still at an earlydevelopment stage (Yu, 2014). Our work differs from other similar works,in that it concentrates on the ways in which cloud computing is exposed toDDoS attacks and how the essential characteristics of cloud computing canadd a new dimension to DDoS defense. DDoS mitigation in Data CenterNetworks (DCNs) has long been a goal of network security research andindustrial community. DDoS protection implementation is not limited toonly the cloud providers. It must be implemented end-to-end, from user’sequipment through the access and core network to the servers running in thecloud. In this paper, we consider all different DDoS mitigation mechanismsand attempt to map them to different locations in the network, as well ashow these various mechanisms can be affected by the characteristics of thecloud.

The main contributions of this survey are the following: first, we providea taxonomy of the DDoS mitigation strategies applied in cloud computing;second, we extensively review the literature on DDoS mitigation in cloudcomputing; third, we provide a comprehensive discussion about deployingDDoS mitigation strategy in the cloud; and finally, we provide suggestionsfor eliminating the current weaknesses of DDoS mitigation and defense mech-anisms.

4

The rest of this paper is organized as follows: In Section 2, the boundariesand scope of the survey are introduced and a methodology to extract the lit-erature is illustrated. In Section 3 and 4, we present a taxonomy of DDoSprevention and detection techniques respectively. In Section 5, we present ournew taxonomy of DDoS mitigation mechanisms for cloud computing. A re-view of recently developed DDoS mitigation mechanisms for cloud computingis presented in Sections 6 and 7. Section 8 provides a general representationof our proposed deployment strategy of DDoS mitigation mechanisms. InSection 9, we provide some discussion about the current weaknesses of DDoSmitigation and defense frameworks and how they can be remedied by futureresearch. Finally, in Section 10, we present our conclusions.

2. Scope and Assumptions of the Survey

2.1. Inclusion and exclusion criteria

This paper covers conference papers, journal papers, and doctoral dis-sertations. Other publication forms such as magazines or newspapers werenot included. A total of 98 papers from 2001 to May 2015 were obtainedand reviewed. Papers were found via computerized search of the informationsecurity risk assessment. The papers were searched according to the on-line databases: Science Direct, IEEE Xplore, Springer Link Online Libraries,ACM Digital Library, Wiley InterScience, and Ingenta Journals. The paperswere carefully reviewed to select those that considered DDoS defense modelsas the core part. In this paper, the approaches which presented a new andgenuine DDoS defense approaches based on a concrete and scientific researchapproach are selected. The reviewed DDoS mitigation approaches are classi-fied based on proposed taxonomy. They are filtered based on novelty, strongcontent, and aligning with cloud specific characteristics.

2.2. Methodology

The previous widely accepted classifications for DDoS mitigation were of-ten based around filtering and rate-limiting. These classifications could notanswer the following questions to classify the DDoS mitigation approaches:(1) whether multiple nodes cooperate to mitigate the DDoS attack or not?,(2) whether the defense strategy is dynamic (adapted to the attack) or static,(3) does the mitigation mechanism adjust the defense architecture respectto the DDoS attack severity?, (4) is the network services or topology re-configured in mitigation process?. In this paper, we will introduce a new

5

classification which will remove many ambiguities created by previous clas-sification. To reach a new taxonomy of DDoS mitigation mechanisms fordeployment in the cloud, we went through comprehensive studying of 98 pa-pers and observing the characteristics of the DDoS attacks and those of thecloud environment. At the time of writing, we are not aware of any otherclassification which could answer all the questions mentioned above.

3. DDoS Prevention

Prevention involves the implementation of a set of defenses, practices, andconfigurations prior to any kind of DDoS attack, with the aim of reducingthe impact of such an attack. The following broad categories can be used toclassify most DDoS prevention approaches.

3.1. Over Provisioning

Until recently, this approach, which is based on preventing an attack ona site by preparing in advance for far more traffic than would be expectedduring normal operation, was the main prevention mechanism used, althoughnow, with the increasing size of DDoS attacks, this is clearly not sustainable(e.g. in 2009, Arbor reported the largest DDoS to be around 49 Gbps; in2013, the largest attack was in size, to 300 Gbps (CloudFlare, 2014); and theaverage DDoS size went from 1.5 Gbps in 2012 to 3.5 Gbps in 2013).

3.2. Modifying Scheduling Algorithms

The aim of this approach is to favor legitimate traffic over malicioustraffic. For example, Ranjan et al. (Ranjan, 2006) propose a mechanismfor suspicion assignment and scheduler for DDoS-resilient. This frameworkmaps suspicion value into its scheduling decision. The suspicion assignmentmechanism uses the arrivals, request arrivals, and workload profiles sessionsas input. Then, two scheduling policies were proposed: Least SuspicionFirst and Proportional to Suspicion Share. Notably, tests have shown thatsuspicion-aware policies reduce the impact on response time of a DDoS attackto 0.1 s, as opposed to 10 s with suspicion-agnostic policies.

3.3. QoS and Resource Accounting

The aim of resource accounting is to keep track of resources (e.g. networkbandwidth, processor time) across protected domains (Mirkovic, 2004). It isuseful in preventing DDoS attacks, since we require guaranteed bandwidth,

6

priority, and QoS under a DDoS attack (Goldstein, 2008). These resourcesare protected using QoS mechanisms, such as traffic shaping, scheduling,and congestion avoidance, to enforce traffic class priorities and guaranteefair service to legitimate users. Typically, the objective is to control metricslike dropped packets, delay, and jitter (Mirkovic, 2009; Matrawy, 2005). QoSis not a universal solution, however, as the attackers could target gold-classclients, which is where these threats to network use hurt the most.

4. DDoS Detection

The next step in defense life-cycle, after DDoS attack prevention, is attackdetection. Attack detection algorithms can be categorized into two maingroups: signature-based and behavior-based.

4.1. Signature-Based Detection

In the signature-based detection technique, the captured traffic is com-pared with well-defined attack patterns (Douligeris, 2004). This techniquemay be useful to extract the communication between attackers and their”zombie” computers (Peng, 2007). This technique will be ineffective if thecommunication is encrypted.

4.2. Behavior-Based Detection

The main idea here is to define what is normal behavior for the traffic,based on the traffic pattern (Shiaeles, 2012), so that any deviation fromthat behavior can be considered to be malicious (Chen, 2007). Generally,thresholds are set to make the deviation more configurable and adaptable todifferent conditions. Normal behavior can be defined based on the following:

• Comparing forward and reverse traffic: The traffic is measuredin both directions, i.e. uplink traffic and downlink traffic (Gil, 2001;Mirkovic, 2002). The two should be proportional. If they are not,this is interpreted as an downloading large files in a repetitive way.The disadvantage of this approach is that stealth attacks based onlegitimate traffic cannot be detected.

• Statistics on connections characteristics: The statistics for dif-ferent destinations (Liu, 2011), for example, the number of connectionsetups and teardowns per second, the duration of sessions, and the

7

number of sessions involving clients, can be used. In (Kompella, 2004;Wang, 2002), statistics on TCP session setups and teardowns are mon-itored and used to define abnormal behaviors.

• Aggregate traffic behavioral monitoring: The incoming or outgo-ing traffic from a network node is divided into different traffic aggre-gates and analyzed to detect patterns (Kuzmanovic, 2003). The meanttraffic should share the same attribute, for example HTTP, encryption,or UDP connection.

• Flow traffic behavioral monitoring: The flow of traffic on the net-work is monitored, in order to enable fine-grained control of the behav-ior of different flows (Mahajan, 2002). The machine learning algorithmsare used to learn the normal behavior of network traffic and then detectthe abnormal behaviours (Kline, 2008; Bernaille, 2007).

5. Taxonomy of DDoS Mitigation Mechanisms

DDoS Mitigation-Tactic

Rate-limiting

Flow-based

Aggregate-based

Filtering

Address-based

Signature-based

Behavior-based

Figure 2: A taxonomy of mitigation tactics against DDoS attack.

To draw up a taxonomy of DDoS mitigation mechanisms for deploymentin the cloud, we observe the characteristics of the DDoS attacks and thoseof the cloud environment. In this section, we briefly introduce our DDoSmitigation mechanisms taxonomy, and in the next section, we discuss each

8

DDoS Mitigation-Strategy

Collaborative

Cooperative FWs

Pushback

Blackholing

Non-Collaborative

Static

Dynamic

Redirectingand Shunting

Reconfiguration

Service

Network

Defense

Figure 3: A taxonomy of mitigation strategies against DDoS attack.

element of this taxonomy in detail, as well as the existing DDoS mitiga-tion approaches in relation to the proposed taxonomy. As Figures 2 and 3illustrate, we base our taxonomy on two concepts: Mitigation Tactic andMitigation Strategy. We define these two concepts as follows:

Definition 1 (Mitigation Tactic). A mitigation tactic is a local ap-proach implemented in one network component.

There are two categories of mitigation tactic: rate-limiting and filtering.Mitigation tactics will be explained in more details in the next section.

Definition 2 (Mitigation Strategy). A mitigation strategy describesthe overall strategy deploying different means at different locations of thenetwork in order to mitigate attacks.

9

Table 1: Classification of existing DDoS mitigation approaches in cloud based on proposedtaxonomy.

Approach Mitigation Strategy Strategy Model Mitigation Tactic

Network Protection PointT

radition

al

SD

N-b

ased

Sou

rce-end

Core

Victim

-end

Robinson et al. (Robinson, 2003) Collaborative Cooperative Firewalls Rate-limiting√ √

Dubendorfer et al. (Dubendorfer, 2005) Non-Collaborative Static Filtering√ √

Mirkovic et al. (Mirkovic, 2005) Collaborative Cooperative Firewalls Rate-limiting√ √

Chu et al. (Chu, 2010) Non-Collaborative Static Rate-limiting√ √

Braga et al. (Braga, 2010) Non-Collaborative Static Filtering√ √

Suh et al. (Suh, 2010) Non-Collaborative Static Rate-limiting√ √

Sathyanarayana (Sathyanarayana, 2011) Collaborative Pushback Rate-limiting√ √

Lua and Yow (Lua, 2011) Non-Collaborative Network Reconfiguration Filtering√ √

Yao et al. (Yao, 2011) Non-Collaborative Static Filtering√ √

Dou et al. (Dou, 2012) Non-Collaborative Static Filtering√ √

NEC and Radware (NEC, 2013) Non-Collaborative Redirecting & Shunting Filtering√ √

Yu et al. (Yu, 2014) Non-Collaborative Service and Defense (hybrid) Reconfiguration Filtering√ √

Shin et al. (FRESCO) (Shin-FRESCO, 2013) Non-Collaborative Defense Reconfiguration Filtering√ √

Zargar and Joshi (Zargar, 2010, 2013) Collaborative Cooperative Firewalls Rate-limiting√ √ √

Lee et al. (Lee, 2013) Collaborative Pushback Rate-limiting√ √

There are two categories of mitigation strategy:

• Collaborative: Multiple nodes cooperate to mitigate the DDoS attackand defend the victim effectively. We can distinguish three cooperativedefense mechanisms: Firewall, Pushback, and Blackholing.

• Non-Collaborative: There is no collaboration between services, securityappliances, or network elements though these strategies still involveseveral nodes in the network. This strategy can be dynamic or static.A dynamic strategy acts like an adaptive model, in that the mitigationmechanism automatically adjust the defense architecture respect tothe DDoS attack severity. In this case, we can either reconfigure theservices, security appliances, or network elements, or redirect the trafficto a center to be cleaned. In contrast, in static approaches, the defensemechanisms are not adapted to the attack.

The strategy needs to be supported in at least one node that does someform of policy enforcement. For example, a threshold-based rate-limitingapproach can be implemented in a static or a dynamic way. Similarly, afiltering based on an IP address tactic can be used as a tactic by variouscooperating firewalls, or in a pushback or blackholing strategy.

Cloud, SDN, and DDoS protection: Software-Defined Networking(SDN) has been a new paradigm for the network virtulization in which thecontrol and data planes of a network switch are separated form each other(McKeown, 2008), the idea being to physically pull the control plane function

10

away from the switch and move it to a PC-based application. Thus, the SDNparadigm allows to deploy a range of control functions from a single controlplatform. The control functions can be access control, routing, or virtual ma-chine migration in a variety of contexts (e.g. enterprises, datacenters, WANs)(Jarraya, 2014; Koponen, 2010; Mehdi, 2011). SDN enables dynamic config-uration of an entire network using logically centralized control brain in anopen approach. This flexibility is beneficial for cloud DCNs, which are madeup of numerous virtual switches/routers, computing nodes, and virtual usermachines. In short, the SDN paradigm offers the authors of complex networksecurity applications a way to dramatically simplify their designs, particu-larly in the area of DDoS defense (Shin-AVANT-GUARD, 2013; Jafarian,2012; Fonseca, 2012; Lara, 2013). Our proposed taxonomy is independentof any approach to computer networking. But, SDN is extensively used incollaboration with virtualization in the cloud context (Drutskoy, 2013). Aswe will see in the next sections, where the most relevant research works withrespect to the taxonomy presented, SDN makes it much more efficient inanswering DDoS at run-time (Vizvary, 2014). This is why we believe SDNis so important in the DDoS mitigation for the cloud and special attentionhas been paid to SDN in the following sections.

In continuation, we focus on the most relevant research works with respectto the taxonomy presented in Figures 2 and 3. Section 6 briefly describes theDDoS mitigation tactics and reviews some of the related works. Then, Sec-tion 7 briefly presents the most significant mitigation strategies and comparesthe most relevant reviewed works based on the proposed taxonomy.

6. DDoS Mitigation Tactics

There are two categories of mitigation tactic: rate-limiting and filtering.

6.1. Rate-limiting

This is the most common way to mitigate a DDoS attack, and perhapsone of the most efficient. It does so by discarding a fraction of the incomingattack packets, in order to reach a manageable number (Molsa, 2004). Thereare two rate-limiting models (Mirkovic, 2003): flow and aggregate.

• Flow rate-limiting: This approach considers the individual flows andlimits the traffic flows transmission rate to a level below a predeter-mined rate for each one of those individual flows (Chen, 2004).

11

• Aggregate rate-limiting: This approach is based on restricting thebandwidth consumption for aggregate traffic. The aggregate trafficcan be based on source/destination application or address, transportprotocol or other criteria. For example, Mahajan et al. (2001) proposesto rate limit based on a specific protocol (e.g. TCP) or traffic pattern.Another example can be to use the application traffic type (e.g. theHTTP protocol) for defining aggregate traffic, i.e. application trafficexceeding a predefined threshold is rate-limited. The application trafficcan be defined through traffic analysis or using the ”type of service”field in the IP header (Price, 2002).

6.2. Filtering

This is the most basic approach to mitigating a DDoS attack, and involveseliminating attack traffic. Note that the use of pure filtering mechanisms intransit routers is dependent on the application environment. Filtering canbe applied without a problem in an enterprise, however its use for the benefitof the general public can be subject to legal constraints.

Static filters are often used in commercial solutions (Cisco Anomaly Guard,2007) as a first line of defense. Dynamic rules are only applied when ananomaly is detected in a zone (defined as the network subnets to be de-fended against DDoS attacks). The resource costs of filtering vary accordingto the type of filtering. Filtering based on an IP (or MAC) address can bevery efficient, and can be performed in line cards with minimal impact fromthe point of view of resources (El Defrawy, 2007). There are three filteringmodels: address, signature, and behavior.

• Address-based filtering: This approach is based on 5-tuple filtering(Source IP address, Source Port, Destination IP address, DestinationPort, Protocol) (Gupta, 2001), or on the MAC address. It is a quick,simple, and effective, technique for dropping attack traffic aimed at avictim.

• Signature-based filtering: This is the most commonly used methodof filtering attacks. It is based on the predefinition of signatures thatcan recognize malicious traffic. The traffic is then analyzed to detectbinary or text patterns that match the signatures of DDoS attacks, and,if they do, the attack traffic is dropped (Jiang, 2003). The efficiencyof this approach depends on the update rate for the signatures and

12

the availability of the signature. Because of the changing nature ofthe attacks virus polymorphism and metamorphism (Polychronakis,2009), finding the appropriate signatures can become more and morechallenging, which makes keeping the date-based malware signature upto date a difficult task. Moreover, a high update rate can decreaseperformance dramatically, because of the number of interruptions itcauses in the routing process.

• Behavior-based filtering: This approach looks for detours from apre-defined normal behavior. There are numerous methods for achiev-ing this, such as data mining, artificial neural networks, and artificialimmunological systems (Scepanovic, 2011).

7. Mitigation Strategies

In this section, we describe in more detail the mitigation strategies aspresented in our taxonomy and discuss the most relevant works classifiedaccording with the used strategy. Table 1 presents a comparison of themost relevant works in accordance to the mitigation strategy, the mitigationtactic, the network architecture, and the protection point. Two categoriesare considered for the network architecture: traditional networking and SDN.The protection point of defense deployment can be the edge router on theattacker side (source-end defense), the routers on the path (core defense), orthe edge router on the victim side (victim-end defense).

7.1. Collaborative Strategy

Depending on the type of cooperation and our network security architec-ture, this mitigation strategy can be categorized as Firewalls, Pushback, orBlackholing cooperative defense.

7.1.1. Firewall Cooperative Defense

The main idea here is to position a number of firewalls in the cloud,and have them communicate and work together to stop a DDoS attack fromthe nearest available firewall node. In this model, a firewall broadcasts itssecurity policy to the surrounding firewalls (Sterne, 2001; El-Soudani, 2003).

El-Soudani and Eissa (El-Soudani, 2003) propose a firewall cooperativedefense protocol for traditional networks. The group of firewalls is dividedinto two sections: Defender Firewalls (DFWs) and Assistant Firewalls (AFWs).

13

A defender firewall is connected to the target network and is responsible forinspecting every incoming packet. If a violation occurs, the DFW broadcastsits security policy to the surrounding firewalls (AFWs) to stop the attackeras close to the source as possible.

Mirkovic et al. (Mirkovic, 2005; Robinson, 2003) moved away from iso-lated defense architectures and introduced a distributed framework, DEF-COM, to enable collaboration among all defense nodes. It relies on coopera-tion between heterogeneous nodes in overlay networks to mount an effectivedefense. They classify the defense nodes based on their performance. Forexample, the detection and response defense nodes are most effective nearthe victim and the source of the attack respectively. In this framework, therate-limiting tactic has been used to drop malicious packets.

Zargar and Joshi (Zargar, 2010, 2013) propose a distributed and collabo-rative defense mechanism, called DiCodefense, for detecting and respondingto the DDoS flooding attacks. This approach is a hybrid defense, deployedat multiple points, including sources, destinations, and networks. They in-troduce what they call a DiCoTraM monitoring component, which is used tomonitor traffic flows on each Autonomous System (AS), and mitigate the highattack volume closer to the source of attack. Their central Task AssignmentServers (TASs) are responsible for monitoring coordination and distributionamong all the routers in each AS. The mitigation decision is made by theDiCoRes component, which responds by distributing the defense against thereported flows by rate-limiting at individual routers in each AS.

7.1.2. Pushback Cooperative Defense

In this case, the collaboration is between routers (Ioannidis, 2001; Ma-hajan, 2002; Peng, 2002). The term ”pushback” refers to the fact that asecurity appliance or network element pushes the information about mali-cious traffic to other security or network devices. The receiving devices aregenerally ahead of the source of the malicious traffic in the communicationpath to the target (Chen, 2004). Information such as congestion signature,bandwidth limit, and expiration time is sent to upstream routers in order torate-limit the traffic closest to the source as possible.

Sathyanarayana (Sathyanarayana, 2011) demonstrates that SDN can beleveraged to mitigate DDoS attacks efficiently using the pushback techniquewith their Frenetic mechanism. Two daemons are implemented in the Open-Flow controller: a pushback daemon and a rate-limiter daemon. The useof the OpenFlow controller prevents pushback messages from being sent by

14

the routers, and all communications are handled by the central controller.The pushback messages are the (defense) rules that would be added to theswitches by the controller. The ”Preferential Dropping phase of the Push-back” mentioned by Ioannidis et al. (Ioannidis, 2001) is implemented in thiswork, in which anomalous nodes are removed first from the flow table of theswitch next to the victim, and then successively on all the switches, one afterthe other, from the victim node to the malicious node.

Lee et al. (Lee, 2013) propose a collaborative defense model, called coDef,against large scale link-flooding attacks. CoDef consists of two complemen-tary mechanisms: collaborative routing and collaborative rate control. Theyintroduce a specialized server, called the route controller, into each partici-pating AS, which has complete knowledge of the network topology by partic-ipating in the intra-domain routing protocol (i.e. IGP). The route controlleris implemented in an SDN architecture. In collaborative routing, a congestedrouter sends a congestion notification message to its route controller. Then, areroute control message is exchanged between route controllers placed in in-dividual ASs to instruct the source ASs to reroute their traffic, which relievescongestion at that router. The collaborative rate control mechanism helpsto distinguish between bot-contaminated and uncontaminated ASs. In thiscase, a router that is subject to a flooding attack sends rate-control requeststo all the ASs to establish the service priorities of their out-going flows (i.e.high-priority flows, low-priority flows, and flows to be filtered).

7.1.3. Blackholing Cooperative Defense

Also referred to as blackhole filtering, this is a quick and simple techniquefor dropping attack traffic at the routing level. It forwards the malicioustraffic to a virtual interface known as Null0 (Glenn, 2003; Tanase, 2003;Morrow, 2003; Marques, 2003). Traffic routed to Null0 is essentially droppedand in case of heavy traffic, the rest of the network remains stable (Tanase,2003). Blackholing is a cooperative defense mechanism, as it involves DDoSdetection mechanisms and routers. These mechanisms instruct the routersto blackhole traffic from the various bots.

7.2. Non-Collaborative-Static Strategy

The static strategy is neither collaborative nor reconfigurable. The miti-gation appliance has already been configured, and we only apply a mechanismto mitigate attack when a detection component detects a DDoS.

15

Chu et al. (Chu, 2010) propose an OpenFlow-based DDoS defender torealize the autonomic self-defense concept. This approach is an aggregate-based rate-limiting mitigation strategy in which a DDoS defender monitorsall the flows of an OpenFlow switch and detects the DDoS attack via volumecounting. They consider two static thresholds for this mechanism. The firstis 3000 packets every five seconds. Once the traffic has passed this threshold,the second threshold is activated to verify 800 packets per second 5 timesover. When these two thresholds meet, the controller realizes that a DDoSattack is occurring, and drops incoming packets until the system registers areturn to normal traffic volume.

Suh et al. (Suh, 2010) propose their Content-Oriented Networking Ar-chitecture (CONA), which figures out what content is being requested andcan launch a countermeasure against resource-exhausting attacks like DDoS.The architecture is based on an OpenFlow Switch on the NetFPGA platform,which was first proposed by Naous et al. (Naous, 2008). This architectureperforms very well in terms of flow processing and insertion rate. The pro-posed model captures the packets containing the content name, extracts therequested content from the packet fields, and then it concatenates them. Fi-nally, a flow limiter blocks the DDoS attack flows by limiting the rate ofarrival of content request messages.

Braga et al. (Braga, 2010) propose a lightweight method based on trafficflow features for DDoS attack detection and mitigation. They use an unsu-pervised artificial neural network, Self Organizing Maps (SOM), trained withthose features. The approach retrieves traffic data for predetermined timeintervals, and then it classifies network packets (as either malicious or not)using self-organizing maps. The information is extracted first from the flowentries of all OpenFlow tables by the NOX controller and then transferredto a classifier module to be analyzed. Three main modules are implementedas OpenFlow-enabled application extending the NOX controller: Flow Col-lector, Feature Extractor, and SOM Classifier. The Flow Collector moduleperiodically sends requests to all OpenFlow switches’ tables. The FeatureExtractor module is responsible for extracting important features for attackdetection. The Classifier module parses and analyzes the collected informa-tions and finally alerts the matching flows corresponding to DDoS floodingattack. The proposed framework is scalable, so, old module can be updatedand new modules can easily added to address other vulnerabilities. The Clas-sifier module analyzes whether the information from the Feature Extractormodule can determine legitimate or DDoS flooding attack. The proposed

16

approach can be updated in order to detect new types of attacks.Dou et al. (Dou, 2012) propose a Confidence-Based Filtering (CBF) ap-

proach for cloud computing. The model generates a nominal profile in thenon-attack period. Each packet is then evaluated based on different corre-lation factors. This evaluation results in a score for each packet definingwhether it must be considered malicious or not. The malicious packets areconsequently discarded. Correlation characteristics are used to detect mali-cious flows. First, six single attribute candidates are selected (protocol type,total length, source IP address, flag, time to live (TTL), destination portnumber). Then, these six attributes are paired (no two pairs the same), re-sulting in 15 attribute pairs. The profile is built through measures in smalltime intervals. The CBF method counts the number of times the 15 attributepairs appear. These numbers of appearances in turn define the confidencevalues which are used to score the packets. The packets going beyond thediscarding threshold are considered as malicious and then discarded.

Dubendorfer et al. (Dubendorfer, 2005) propose an adaptive traffic con-trol service for DDoS attack mitigation which delegates partial network man-agement capabilities to network tenants using adaptive traffic processing de-vice as an extension to the data plane. The authors compare reactive andproactive mitigation, and point out the drawbacks of reactive mitigation inthe face of a reflector DDoS attack, as well as the benefits of the proactiveapproach. For this, they chose proactive mitigation in overlay networks andbuilt a defense system based on distributed control delegation to the networktenants based on their own address IP. Their model can accommodate a dis-tributed firewall; for example, it can filter traffic close to the source of theattack and has a traceback service for the entire network.

Yao at al. (Yao, 2011) propose Virtual source Address Validation Edge(VAVE), which extends the SDN NOX controller to check flow entries on thevirtual switches. The NOX controller consists of on-demand filtering, val-idation, and rule adaptor mechanisms designed to prevent a DDoS attack.They use OpenFlow devices to form a protection zone to validate the in-coming packet from outside, and redirect the traffic to the controller to takedecisions using the VAVE modules.

7.3. Non-Collaborative-Dynamic Strategy

7.3.1. Redirecting and Shunting

In Redirecting and Shunting strategy, instead of the traffic being dropped,it is sent out to a different physical interface (Gonzalez). A data scrubber

17

residing on the alternate data path can then filter out the attack trafficand send the clean traffic to the customer. Recently, the SDN has beenused to redirect suspect traffic to these scrubbing centers (Radware, 2013;OpenContrail, 2014).

Several commercial solutions are based on this approach. For example,Riverhead Guard and Cisco Guard are data scrubbers that use this techniqueto prevent DoS/DDoS attacks. The Cisco DDoS mitigation solution redirectsDDoS traffic to the Cisco Guard appliance, which is in charge of cleaning thetraffic and forwarding the legitimate traffic to the destination (Cisco AnomalyGuard data sheet, 2007). Alternatively, the traffic can be sent to the cloudto be cleaned and then returned to the target. Verisign is proposing to usethis approach (Verisign, 2013).

Recently, new solutions have been developed in the industry for a com-prehensive and cost-effective solution for SDN hardware DDOS attacks atthe core router (NEC, 2013). The attack detection mechanism is a behavior-based detection algorithm, which compares recently collected tenant networkactions to the usual behavior. The algorithm needs to recognize both ex-pected behavior and any serious deviation in that behavior. In case of aDDoS attack, traffic is diverted to the DDoS mitigation device for cleaning,and then the clean traffic is forwarded to its original destination. The pro-posed model considers response deactivation over time, as the defense systemconfirms that there is no attack traffic, at which point it alerts the controllerto redirect the traffic to its normal path.

7.3.2. Reconfiguration

The reconfiguration strategy changes the topology or defense mechanismof the victim or the intermediate network, in order to prevent the DDoSattack (Mirkovic, 2003). Depending on the level of reconfiguration, thismitigation strategy can be categorized as service reconfiguration, networkreconfiguration, or defense reconfiguration.

• Service Reconfiguration: This strategy can be classified into twocategories: 1) service cloning, and 2) service regeneration. In a servicecloning strategy, new instances of the service are created in differentlocations, and then flows are distributed among them (Yau, 2005). Ser-vice cloning works well in the cloud, since it can pool a large amountof resources to handle a rapid increase in service demand and cloneVMs very quickly (Yu, 2014; Peng, 2012; Armbrust, 2009). In con-

18

trast, service regeneration tries to fix service vulnerabilities, and thenneutralizes the attackers control of compromised services. It can pre-vent future attacks that have the same vulnerabilities (Wang, 2005).

• Network Reconfiguration: In this strategy, network topology is re-configured to prevent a DDoS attack by providing alternative routesvia many IP addresses assigned to protected resources, or via alterna-tive gateways (Cai, 2008; Lua, 2011). Unlike the service reconfigurationapproach, in which extra resources are allocated, in this approach, thenetwork topology is changed. For example, the VM location may bechanged from one data center (DC) to another in which location infor-mation exposed by attacks is invalid.

• Defense Reconfiguration: This strategy offers the following two op-tions: 1) the defense system configuration is altered; or 2) the capacityof the defense system is increased. With the first option, the defensesystem is connected to the victim network. In this case, a default de-fense mechanism is considered for a cloud application or service. Then,as the volume of DDoS attack packets increases, the defense mecha-nism is automatically reconfigured to be more robust in the face of theattack. With the second option, as with the service reconfigurationstrategy, the defense system (e.g. virtual firewall) can be cloned tomitigate the attack when a new instance of the service is created in adifferent location (Yu, 2014).

Yu et al. (Yu, 2014) present a service reconfiguration mitigation approachto counter DDoS attacks for individual cloud customers. The main idea iswhen under attack use the elastic nature of the cloud to clone new serviceVMs in order to continue providing service to the legitimate users. Simulta-neously, new IPSes are cloned through out the system to filter the malicioustraffic. To summarize, no matter how efficient the detection and filteringalgorithms are, there remains the task of allocating sufficient resources toaddress the attack, which this model achieves using queueing theory, basedon its estimation of the resource demands and QoS required to support le-gitimate users commensurate with strength of the attack.

Also Yu et al. (2014) present a defense reconfiguration mitigation ap-proach considering multiple parallel IPSs, in addition to service reconfigu-ration mitigation, to take into account the rate of the DDoS attack. Toidentify the malicious traffic and guarantee the QoS, multiple parallel IPSes

19

are cloned. The number of IPSes and service VMs is decreased when themalicious DDoS traffic reduces. This model, with its IPS activation anddeactivation capability, is the only elastic defense system that has been pro-posed to date.

Lua and Yow (Lua, 2011) propose a network reconfiguration mitigationbased on an intelligent fast-flux swarm network. When under attack, the net-work is reorganized in order to provide the maximum availability for serversand clients. This fast-flux technique has been used in DNSs to marshal a largenumber of nodes, in order to greatly enhance the availability of a particularresource. As a result, an attacker must target more than one IP address. Aparallel optimization algorithm, for example the Intelligent Water Drop, isused to constantly reconfigure the swarm network (Shah-Hosseini, 2009).

Shin et al. (Shin-FRESCO, 2013) present a defense reconfiguration frame-work called FRESCO. Fresco framework is provided with an application de-velopment environment to help prototyping of detection and mitigation se-curity modules. The framework is based on Openflow. These modules arecombined into security services that can be efficiently deployed to producecomplex network defense applications. FRESCO framework provides the de-velopers with an API to access network flows and statistics. It then mitigatesthe attack by pushing new flow constraint rules to the controller.

8. Mitigation Deployment

A new taxonomy of DDoS mitigation strategies to combat DDoS attacksin cloud computing has been proposed in this paper. Figure 4 depicts ageneral representation of the deployment scenario for the described DDoSmitigation strategies, which is based on a simple 3-tier cloud computing ar-chitecture. The discussion in this section is based on the deployment of asimple 3-tier web application in the cloud computing architecture. Actually,to better describe the possible deployment, we consider a 3-tier web applica-tion and how it could be deployed in the cloud. We then use this scenario asan illustrative example to show the possible deployment of DDoS mitigationmechanisms.

Note that we describe the deployment scenario in this section for purelyinformative purposes, our main goal being to help the reader to better graspthe deployment options, and not to provide guidelines or an exhaustive study.The access and aggregation networks connect cloud tenants to the core net-work that have high capacity to process tenants’ packets to different cloud

20

service providers. In Table 2, we show the possible deployment locations formitigating a DDoS attack in cloud computing for each strategy, in order tobetter explain the deployment scenario depicted in Figure 4.

Access, aggregation, and core networks DDoS mitigation de-ployments: Generally, the access and aggregation networks connect cloudtenants to the core network that have high capacity to carry tenants’ traf-fic to different cloud service providers. Even though, the large cloud ser-vice providers support high bandwidth traffic inside their data centers, thebandwidth at core network is often much higher than the traffic inside thedata center. From security point of view, it is important to eliminate theDDoS traffic as early as possible in the access, aggregation and core net-works. Based on our literature study, the filtering and rate limiting are theprincipal means used in these networks. The rate-limiting and filtering mit-igation tactics are positioned all over the architecture, and can be deployedin all routers, switches, and firewalls (FWs). In some deployments, it is pos-sible additionally for the network operators to deploy the scrubbing centers.The scrubbing center is a cleaning station where inter/intra network trafficis analyzed and malicious DDoS packets are removed. The traffic is typicallyredirected using Domain Name Servers (DNSs) or Border Gateway Protocol(BGP) routers, where the attack mitigation strategy drops attack traffic andreturns clean traffic to the network for delivery.

Cloud service provider DDoS mitigation deployments: Gener-ally, the access to the cloud service provider data center is protected byFWs. FWs are placed between external networks and internal virtual datacenters (VDCs) and cloud service provider infrastructure to filter and dropunauthorized traffic. In today’s large data centers, up to 75% of traffic canbe between different servers inside the data center, i.e. east-west traffic (Ju-niper, 2011). Therefore, a DDoS attack inside these large data centers is apossibility. We then assume that virtual FWs are placed between hypervi-sors and virtual networks in addition to the entrance to each virtual datacenter to protect a tenants’ VMs and eliminate malicious traffic as early aspossible. As all these security appliances are in the same administrative do-main, collaborative mitigation can be now implemented through cooperationbetween these security appliances. Additionally, the deployment of thesedifferent security appliances is orchestrated by cloud management, which,through knowledge of network topology and orchestration capabilities, candeploy different DDoS mitigation mechanisms in different places in the cloudservice provider’s infrastructure. Furthermore, the cloud management can

21

Table 2: DDoS mitigation deployment location in cloud computing

Access, Aggr. Cloud Service Provider& Core Networks

Hosts

DDoS Mitigation Models

Rou

ters

Sw

itches

FW

s

Scru

bbin

gC

enter

Rou

ters

Sw

itches

FW

s

Scru

bbin

gC

enter

Clou

dM

gmt

&O

rch.

virtu

alSw

itches

virtu

alF

W

Hyp

ervisor

Rate-limitingFlow

√ √ √ √ √ √ √ √

Aggregate√ √ √ √ √ √ √ √

FilteringAddress

√ √ √ √ √ √ √ √

Signature√ √ √ √

Behavior√ √ √ √

Non-Collaborative

Network Reconfiguration√ √ √ √ √ √

Service Reconfiguration√

Defense Reconfiguration√ √ √

Redirecting & Shunting√ √ √

CollaborativePushback

√ √ √ √ √

Cooperative FWs√ √ √

Blackholing√ √ √ √ √ √

orchestrate reconfiguration mitigation strategies leveraging the pre-definedwork-flows to deploy adequate DDoS mitigation mechanisms.

9. Discussion

9.1. DDoS Mitigation Strategies and Tactics: advantages and disadvantages

The advantages and disadvantages of each DDoS mitigation tactic andstrategy are summarized in Tables 3 and 4 respectively.

As far as mitigation tactics are concerned, rate-limiting and filtering canbe efficiently implemented through access rules inserted into routers or FWs;however, they prevent the DDoS attack in different ways. Rate-limiting iseasy to deploy and provision across network nodes, and is flexible, throughdynamic threshold setting. Rate-limiting is used when the DDoS detec-tion algorithm is congestion-based, and legitimate traffic cannot be preciselydistinguished from attack traffic (Chen, 2004). Since the congestion-basedDDoS detection algorithm yields many false positives, applying rate-limitingto the traffic would be preferable to using the filtering approach (Abliz, 2011).

22

Acc

ess

& A

ggre

gati

on

Ne

two

rks

Clo

ud

Use

rsC

lou

d U

sers

Co

re N

etw

ork

Clo

ud

Se

rvic

e P

rovi

de

r

FWFW FWFW

FWFWFWFW

Scru

bb

ing

Ce

nte

rR

ed

ire

ct T

raff

ic

12

U

3 U

5 U

1 U

6 U

VM

vFW

vFW

vDC

N

9 U

12

U

Rat

e-L

imit

ing

FFl

ow

-bas

ed

Agg

rega

te-b

ase

dG

Filt

eri

ng

Ad

dre

ss-b

ase

d

Sign

atu

re-b

ase

d

A

Bla

ckh

olin

gB

eh

avio

r-b

ase

d

SN

on

-Co

llab

ora

tive

Ne

two

rk R

eco

nfi

gura

tio

n

Serv

ice

Re

con

figu

rati

on

De

fen

se R

eco

nfi

gura

tio

n

SN DC

olla

bo

rati

ve

Pu

shb

ack

Co

op

era

tive

FW

s

P C

Re

dir

ect

ion

g an

d S

hu

nti

ng

VM

VM

VM

Hypervisor

VM

vFW

vFW

vDC

N

VM

VM

VM

vDC

FW

vDC

FW

vDC

FW

vDC

FW

HO

ST

Hypervisor

HO

ST

VM

vFW

vFW

vDC

N

VM

VM

VM

P

PF

F

F

F

F

F

F

F

F

FG

G

GG

G

G

GG

G

G

G

G

G

G

A

AA

A

A

AA

A

A

A

A

A

SS

SS

S

S

S

Clo

ud

Man

age

me

nt

& O

rch

est

rati

on

CC

D

D

D

Clo

ud

C

on

tro

ller

DC

FW

S

H

HH

HH

H

H

H H

G

N

Tactic

BR

Strategy

R

BB

BB

B B

BBB

BB

Figure 4: General representation of different mitigation strategies against DDoS attacksin cloud computing.

23

Table 3: Summary of advantages and disadvantages of DDoS mitigation tactics

Mitigation Tactic Advantages Disadvantages

Rate-limiting• Easy to deploy and provisionacross network nodes• Flexible through dynamicthreshold setting• Useful when detection hasmany false positives

• Coarse grain filtering also hit-ting legitimate traffic• Cannot completely eliminatethe malicious traffic

Filtering• Easy to deploy and provisionacross network node• Flexible through adding andremoving addresses

• Cannot distinguish betweenmalicious and legitimate trafficassociated to the same sources• Difficult to detect all mali-cious addresses

Table 4: Summary of advantages and disadvantages of DDoS mitigation strategies

Mitigation Strategy StrategyModel

Advantages Disadvantages

Collaborative

CooperativeFirewalls,Pushback,Blackholing

• Containing the attackclose the attack sources• Considering distributedmitigation architecture(robust against attack)

• Difficult to put in placethe collaboration• Difficult to put in placetrust and secure interac-tions between different do-mains• Dependent on networktopology

Non-Collaborative

Static• Easy to deploy and putin place

• Inability to automaticallyadjust the defense architec-ture based on severity ofDDoS attack

Reconfiguration(Service, Net-work, Defense)

• Efficient defense as it iselastic• Distributed solutiontherefore more reliable asit could create instancesin different DCs• Scalable solution as itcould divide the attackinto smaller chunks

• Deploy at victim side• Need for some orches-tration and precise infor-mation about resources andnetwork topology in orderto put in place the defensemechanisms

Redirectingand Shunting

• Shield completely thetarget

• More difficult to put inplace

24

Filtering, like rate-limiting, is easy to deploy and flexible enough, throughadding/removing addresses or updating the detection algorithm, to cover newkinds of attacks (e.g. improving the classifier in behavior-based detection,or adding a new signature in signature-based detection). So, in fact, filter-ing works better with a DDoS detection algorithm that detects attacks byverifying packet headers (Chen, 2004). However, the disadvantage of thistactic is that it cannot distinguish between malicious and legitimate trafficassociated with the same sources. In practice, it is challenging to use, as ithas difficulty detecting all malicious addresses or attack types.

A collaborative mitigation strategy has a distributed DDoS preventionarchitecture. Its distributed nature makes it more resilient to DDoS attacks.The great advantage of this strategy, if it is applied properly, is that itcontains the attack close to the attack sources. Pushback cooperative defensecreates a new requirement for routers, which is to support a protocol thatenables communication between two routers so that they can coordinate therate-limiting or filtering tactics. Their deployment depends on the abilityof the downstream router to determine what fraction of the attack trafficcomes from up- stream routers. Except for the case of simple point-to-pointconnections between routers, when the router can only see which line cardsthe traffic is coming from and not the corresponding routers, then there isneed for additional mechanisms to find out how much attack traffic is beingsent over by upstream routers. Unfortunately, pushback can inflict collateraldamage when the attackers are co-located with the legitimate users and thefiltering rules are not precise enough to filter only bad traffic. In addition, theexpiration time of the rate-limiting tactic must be carefully managed to avoidaffecting the legitimate traffic of an unsuspecting victim of a botnet. Themain disadvantage of pushback is that all routers upstream must implementit, if it is to be effective against a large-scale DDoS. Also, it is difficult toimplement in practice. Moreover, core routers have little incentive to deploypushback. In general, collaborative mitigation is completely dependent onnetwork topology, and it is difficult to establish the collaboration. Anotherlimitation of this approach is the difficulty of establishing secure connectionsbetween routers from different domains. The cloud environment changes thispicture in a major way, as different routers can be controlled and managedby cloud orchestration mechanisms, which SDN helps to implement.

Non-collaborative strategies can be static or dynamic. A static strategyis easy to deploy, since all mitigation appliances have already been configuredand we only apply rate-limiting or filtering to mitigate an attack when an

25

attack occurs. Moreover, it can either be a source-end, a core defense, ora victim-end defense. The main disadvantage of the static strategy is thatit is non-adaptive. The mitigation mechanism does not have the ability toautomatically readjust the defense architecture respect to the severity of aDDoS attack.

A dynamic strategy acts like an adaptive model, as the mitigation mecha-nism can automatically readjust the defense architecture respect to the DDoSattack severity. Dynamic strategies can be classified into two groups: (1) re-configuration; and (2) redirecting and shunting. A reconfiguration mitigationstrategy is an efficient model, since it leads to an elastic defense. The clearadvantage of the reconfiguration mitigation strategy in the cloud environ-ment is that it provides a distributed solution, which makes it more reliableas it can create instances in different DCs. In terms of disadvantages, thisstrategy needs some orchestration, along with precise information about re-sources and network topology in order to put the defense mechanisms inplace. Also, it cannot be applied to all scenarios, and sometimes it is notpossible to reconfigure it, because of deployment or resource constraints.

Redirecting and shunting mitigation shields the target completely, so thatit does not see any malicious traffic. This means that its resources are notconsumed to fight the attack. Another advantage of this model is that it out-sources the work to the security providers who can aggregate more resourcesto fight a DDoS attack.

9.2. Evaluation of Existing Proposals

In the following we enumerate some of significant characteristics for DDoSmitigation strategies and discuss them in the context of cloud computing:

Static defense: The current DDoS mitigation approaches are oftenbased on static defense postures, i.e. hardware-type security appliances withpredefined security capabilities deployed in pre-defined places in the networktopology. The dynamic mechanisms such as cooperative firewalls (Section7.1.1) and reconfiguration (Section 7.3.2) are considered in only few refer-ences. Pushback approach is more widely cited (see Section 7.1.2) thoughboth cooperative defense and pushback, have been considered unrealisticbecause the various security appliances, e.g. firewalls or routers, were con-trolled by different administrative authorities ((Ioannidis, 2001; Mahajan,2002; Peng, 2002; Sathyanarayana, 2011; Lee, 2013)). The practical diffi-culty of establishing any degree of cooperation between these authorities wascited as the major obstacle beyond technical reasons. However, in the cloud

26

computing context, many of these firewalls and routers inside and at the edgeof the data centers are now under the same administrative control, i.e. cloudservice provider. Therefore, cooperation between these security appliancescan now be enforced through cloud service provider orchestration and man-agement components making cooperative defense mechanisms now a viablesolution.

On the contrary, the blackholing and redirecting have received wide cov-erage and many industry wide implementations of these latters are available.To the best of our knowledge, we have not seen any industry implementationof cooperative firewalls or pushback approaches.

We can also see from Table 1 that, although cooperative firewalls havebeen proposed in (Zargar, 2010, 2013; Mirkovic, 2005; Robinson, 2003), co-operative virtual firewalls have not yet received much attention (we havenot found any reference to any virtual proposal). The ease of creation ofthe virtual firewalls inside the same virtual data center by the cloud serviceprovider opens new opportunity for deploying cooperative firewalls at will indifferent points in the data center. In light of changes highlighted above, thecooperative defense mechanisms should receive renewed interest in the cloudcomputing context and deserve receiving more attention.

Strongly dependent on deployment location in network topol-ogy: The current approaches strongly depend on where the DDoS defensemechanisms are deployed in the network topology. We see three types of lo-cation: source-end defense (e.g. the edge router) closer to the attacker side,the core defense (e.g. core router), and victim-end defense (e.g. the edgerouter) closer to the victim side (Douligeris, 2004; Singh, 2013; Dubendorfer,2005; Mirkovic, 2003). Source-end defense systems are often inaccurate, sincethe source of the attacks can be spoofed or distributed in different domainsin order to hide the sources (the volume of traffic from any one source maynot be significant to permit differentiation between legitimate and malicioustraffic) (Seo, 2013; Oikonomou, 2006). Core defense needs complete cover-age, since a single location cannot capture all attacks. In addition, the highvolume of traffic in these nodes needs large DDoS mitigation deploymentswhich are costly 1. Victim-end defense suffers from high flood rate, and isitself vulnerable to DDoS attacks. These drawbacks motivate a decentralized

1Note that the high costs are to be considered as major obstacles for their deploymetnsby ISPs

27

and collaborative approach (Zargar, 2013; Singh, 2013; Shi, 2005). The cloudenvironment by its flexible, scalable and elastic nature is a perfect fit for de-ploying distributed nodes deployed throughout the data center. However, adistributed and collaborative DDoS defense system requires many messageexchanges between these nodes, and suffers from high overhead and delaysin detection and response (El-Soudani, 2003).

As we have seen in Table 1, the majority of existing traditional mitiga-tion frameworks are of the victim-end defense type. The reason for this isthat all the traffic can be easily observed on the victim side, which max-imizes detection accuracy (Oikonomou, 2006). The advent of SDN givesus a new paradigm, offering a dramatically simplified design for complexnetwork security applications, especially in fighting DDoS (Shin-AVANT-GUARD, 2013; Jafarian, 2012; Fonseca, 2012; Lara, 2013). SDN-based so-lution using middle boxes created dynamically (Qazi, 2013; Anderson, 2012;Rajagopalan, 2013; Sekar, 2012; Shin-AVANT-GUARD, 2013; Fayazbakhsh,2013) with DDoS mitigation mechanisms using SDN as described in (Open-Contrail, 2014; DDoS-Defense4all, 2013) can deal with attacks in source andcore networks very efficiently 2. This architecture makes it easier to efficientlycapture and analyze data collected at a single point, and provides great flexi-bility in terms of adding (defense) rules to SDN switches, and removing themfrom the switches. SDN also gives a new perspective to pushback mechanisms(collaborative mitigation). As a matter of fact, since the SDN controller isin charge of many switches in the network, it can filter the malicious trafficclosest to the source, thereby eliminating any difficulties that arise due tothe collaboration between different switches ((OpenContrail, 2014; DDoS-Defense4all, 2013)).

Note that east-west traffic in today’s data centers is as important as north-south traffic, sometimes even more, which means that counteracting internalDDoS attacks beyond data center gateways in a (virtual) data centers shouldbe a high priority. A strategy based on dynamic creation of virtual securityappliances in different real or virtual network topology orchestrated by cloudmanagement can be a promising approach to prevent internal attacks.

Application context-free: None of the defense mechanisms refered inthis study are application context-aware, i.e. there is no means for adapting

2An extension of these mechanisms by cloud service providers can easily extend theseworks to be considered for victim-end defense

28

DDoS defense mechanisms to the type of applications, or further more foradapting the defense to the type of attacks on the target application. Thisapproach contributes to a one-size-fits-all type of approach where DDoS de-fense mechanisms are deployed independently from the applications theyneed to protect or attacks on them. This generic approach is not effi-cient and resource consuming. In the contrary, the cloud provides necessarymeans to implement an application aware defense through deployment at runtime, dynamic modifications of defense mechanisms or security policy com-position/decomposition (Shin-AVANT-GUARD, 2013; Shin-FRESCO, 2013;Qazi, 2013; Anderson, 2012; Rajagopalan, 2013; Sekar, 2012; Fayazbakhsh,2013). This defense can be adapted for each application deployed in thecloud. Therefore, the cloud based DDoS defense mechanism can explore newmitigation strategies to protect against different DDoS attack types for dif-ferent application types instead of a uniform and generic approach for allapplications running in the cloud.

Application context-free: Even though, the application context isused more and more often when it comes to DDoS attack detection andprevention, the defense mechanisms for mitigation are often not applicationcontext-aware, i.e. there is no means for adapting DDoS mitigation mecha-nisms to the type of applications, or further more for adapting the defenseto the type of attacks on the target application. This approach contributesto a one-size-fits-all type of approach where DDoS mitigation mechanismsare deployed independently from the applications they need to protect orattacks on them. This generic approach is not efficient and resource consum-ing. In the contrary, the cloud provides necessary means to implement anapplication aware defense through deployment of application aware mitiga-tion mechanisms at run time, dynamic modifications of defense mechanismsto tune in the mitigation to the specific attack on specific components ofthe application or through security policy composition/decomposition (Shin-AVANT-GUARD, 2013; Shin-FRESCO, 2013; Qazi, 2013; Anderson, 2012;Rajagopalan, 2013; Sekar, 2012; Fayazbakhsh, 2013). This defense can beadapted for each application deployed in the cloud. Further, as this is al-ready the case for scaling in/out of the applications deployed in the cloud,one can imagine the deployment of pre-defined work flows for deploying dy-namically DDoS mitigation mechanisms targeting specific components of theapplications. Therefore, the cloud based DDoS defense mechanism can ex-plore new mitigation strategies to protect against different DDoS attack typesfor different application types instead of a uniform and generic approach for

29

all applications running in the cloud.Network/service/defense reconfiguration: As described in Section

7.3.2, the reconfiguration of networks/defense/service is a new and efficientway of addressing DDoS attacks. The cloud management of virtual resources(e.g. network, computing, storage) makes it possible to easily reconfigure atrun time the network/service/defense to meet the specific threat posed bythe DDoS attacks (Yu, 2014; Lua, 2011; Shin-FRESCO, 2013). Therefore,the reconfiguration in the cloud context takes much more central role thanin the hardware deployements.

End-to-end DDoS defense: At the end, pervasive DDoS mitigationmechanisms, i.e. end-to-end defense from access point up to the serversrunning in the cloud are often not considered. This scenario has becomeinteresting for the servers running in data centers installed in Telecom op-erators network. In this latter, the access network, core network, and datacenters are managed by the same administrative authorities. Further, theTelecom networks characterized by a strong identification of different userscombined with the end-to-end control described above can drastically im-prove the mitigation of DDoS attacks close to the sources.

10. Conclusion

Recently, the number and volume of DDoS attacks have been increasedrapidly. The cloud by its open nature is exposed to DDoS attacks. Atthe same time, ever changing nature and type of DDoS attacks has made theappropriate and efficient detection and response to these attacks a challengingtask. Many research activities concentrate on DDoS detection though recentexperience and the repetitive occurrences of DDoS attacks have shown thatDDoS detection has its limits. Therefore, in addition to the research onDDoS detection, there is need for additional research on more efficient DDoSmitigation strategies in order to create a stronger defense.

A comprehensive survey of DDoS mitigation techniques for cloud comput-ing has been presented in this paper. The key finding of this work is that SDNhas brought a new perspective to DDoS mitigation in the cloud. The newaspects have been embraced by academic research on two main directions:first, more efficient implementations of known techniques. These implemen-tations use SDN centralized control to better implement rate limiting andfiltering techniques or to steer suspect traffic into security appliances to beanalyzed and cleansed. Second, SDN has helped to enhance the collaborative

30

approaches such as push backs in SDN switches. We consider though thatthe cloud flexibility and the usage of SDN in cloud environment can bringmore DDoS mitigation strategies. Cloud and SDN combined allow reconfig-uration at run time of virtual services, networks, and defense mechanisms.This opens new directions in the research and makes possible new strategiesin the cloud significantly different from the existing DDoS mitigation defenseapproaches deployed today.

Based on our study, we believe that further research can be conductedin the following areas: (i) Adequate defense: creating context-aware defensemechanisms in the cloud based on the application security attributes andprofiles. Virtual security appliances advent and their fast on demand de-ployment in the cloud open the door to deploy application specific securitymechanisms for different virtual data centers, or even further extend this tofurther deploy specific security mechanisms per virtual applications basedon new attacks targeting these applications (ii) Elastic defense system: theorchestration capabilities of the cloud brings the possibility of activating,scaling up and down, and scaling in and out the appropriate security mecha-nisms according to the rate of attack or cloud risk tolerance. In addition, thecloud creates the possibility of dynamically and automatically re-configuringvirtual data centers in order not only to duplicate or clone the services in thesame data centers or different data centers but also to re-organize the virtualnetworks to re-direct the suspect traffic (iii) Cloud-based defense system: thepossibility for the defense mechanisms to be orchestrated by the cloud man-agement among different virtual data centers in order to consolidate differentsecurity mechanisms making DDoS attack mitigation more efficient and eco-nomic but also benefiting from the possibility of sharing different securitymechanisms specialized hardware among different cloud tenants.

Acknowledgment

This work is partly funded by Natural Sciences and Engineering ResearchCouncil of Canada Research Chair on Sustainable Smart Eco-Cloud, NSERC-950-229052, and by the NSERC CRDPJ 424371-11: ECOLOTIC Sustainableand Green Telco-Cloud. In addition, the authors would like to thank Dr.Mats Naslund at Ericsson Sweden Research and Dr. Yosr Jarraya at EricssonCanada Research for their constructive comments and helpful feedback.

31

References

D. Zissis and D. Lekkas, ”Addressing cloud computing security issues,” Fu-ture Generation Computer Systems, vol. 28, no. 3, pp. 583-592, 2012.

S. Subashini and V. Kavitha, ”A survey on security issues in service deliverymodels of cloud computing,” Journal of Network and Computer Applica-tions, vol. 34, no. 1, pp. 1-11, 2011.

R. Bhadauria, R. Chaki, N. Chaki, and S. Sanyal, ”A survey on securityissues in cloud computing,” CoRR, vol. abs/1109.5388, 2011.

C. Zhang, Z. Cai, W. Chen, X. Luo, and J. Yin, ”Flow level detection andfiltering of low-rate DDoS,” Computer Networks, vol. 56, no. 15, pp. 3417-3431, 2012.

S. T. Zargar, J. Joshi, and D. Tipper, ”A Survey of defense MechanismsAgainst Distributed Denial of Service (DDoS) Flooding Attacks,” IEEECommunications Surveys & Tutorials, vol. PP, no. 99, pp. 1-24, 2013.

S. Ranjan, R. Swaminathan, M. Uysal, A. Nucci, and E. Knightly, ”DDoS-shield: DDoS-resilient scheduling to counter application layer attacks,”IEEE/ACM Transactions on Networking (TON), vol. 17, no. 1, pp. 26-39,2009.

M. Walfish, M. Vutukuru, H. Balakrishnan, D. Karger, and S. Shenker,”DDoS defense by offense,” ACM Transactions on Computer Systems(TOCS), vol. 28, no. 1, 2010.

PC World, http://www.pcworld.com/article/2035407/ddos-attacks-

have-increased-in-number-and-size-this-year-report-says.html

[Accessed July 2015].

E. Alomari, S. Manickam, B. B. Gupta, S. Karuppayah, and R. Alfaris,”Botnet-based Distributed Denial of Service (DDoS) Attacks on WebServers: Classification and Art,” International Journal of Computer Ap-plications, vol. 49, no. 7, pp. 24-32, 2012.

X. Geng, Y. Huang, and A. B. Whinston, ”Defending wireless infrastructureagainst the challenge of DDoS attacks,” Mobile Networks and Applications,vol. 7, no. 3, pp. 213-223, 2002.

32

A. D. Wood, and J. A. Stankovic, ”A Taxonomy for Denial-of-Service Attacksin Wireless Sensor Networks,” Handbook of Sensor Networks: CompactWireless and Wired Sensing Systems, pp. 739-763, 2004.

J. Yu, C. Fang, L. Lu, and Z. Li, ”A lightweight mechanism to mitigateapplication layer DDoS attacks,” In Scalable Information Systems, pp.175-191, 2009.

S. Yu, S. Guo, and I. Stojmenovic, ”Can we beat legitimate cyber behaviormimicking attacks from botnets?” in Proceedings of the INFOCOM, 2012.

J. Mirkovic and P. Reiher, ”A taxonomy of DDoS attack and DDoS defensemechanisms,” ACM SIGCOMM Computer Communication Review, vol.34, no. 2, pp. 39-53, 2004.

T. Peng, C. Leckie, and K. Ramamohanarao, ”Survey of network-based de-fense mechanisms countering the DoS and DDoS problems,” ACM Com-puting Surveys (CSUR), vol. 39, no. 1, 2007.

D. McPherson, 5th Edition of the Worldwide Infrastructure Security Reportby Danny McPherson, 2010. http://asert.arbornetworks.com/2010/

01/5th-edition-of-the-worldwide-infrastructure-security-

report [Accessed July 2015].

America’s 10 most wanted botnets, NetworkWorld, http://www.

networkworld.com/news/2009/072209-botnets.html [Accessed July2015].

S. Ranjan, R. Swaminathan, M. Uysal, and E. Knightly, ”DDoS-ResilientScheduling to Counter Application Layer Attacks Under Imperfect Detec-tion,” Proceedings of 25th IEEE International Conference on ComputerCommunications, pp. 1-13, 2006.

M. Goldstein, M. Reif, A. Stahl, T. Breuel, ”High performance traffic shapingfor DDoS mitigation,” Proceedings of the 2008 ACM CoNEXT Conference,2008.

J. Mirkovic, A. Hussain, S. Fahmy, P. Reiher, and R. K. Thomas, ”Accu-rately measuring denial of service in simulation and testbed experiments,”Dependable and Secure Computing, IEEE Transactions on, vol. 6, no. 2,pp. 81-95, 2009.

33

M. Abliz, ”Internet Denial of Service Attacks and defense Mechanisms,” Uni-versity of Pittsburgh, Department of Computer Science, Technical Report.TR-11-178, 2011.

S. Yu, Y. Tian, S. Guo, and D. Wu, ”Can We Beat DDoS Attacks inClouds?,” IEEE Transactions on Parallel and Distributed Systems, vol.9, no. 9, pp. 2245-2254, 2014.

S. Shin, V. Yegneswaran, P. Porras, and G. Gu, ”AVANT-GUARD: scal-able and vigilant switch flow management in software-defined networks,”In Proceedings of the 2013 ACM SIGSAC conference on Computer & com-munications security, pp. 413-424, 2013.

J. H. Jafarian, E. Al-Shaer, and Q. Duan, ”Openflow random host mutation:transparent moving target defense using software defined networking,” InProceedings of the first workshop on Hot topics in software defined net-works, pp. 127-132, 2012.

P. Fonseca, R. Bennesby, E. Mota, and A. Passito, ”A replication compo-nent for resilient OpenFlow-based networking,” In Network Operationsand Management Symposium (NOMS), pp. 933-939, 2012.

A. Lara, A. Kolasani, and B. Ramamurthy, ”Network innovation using open-flow: A survey,” IEEE Communications Surveys and Tutorials, 2013.

CloudFlare, https://www.cloudflare.com/ddos [Accessed July 2015].

A. Shameli-Sendi and M. Dagenais, ”ARITO: Cyber-attack response systemusing accurate risk impact tolerance,” International Journal of InformationSecurity, DOI: 10.1007/s10207-013-0222-9, 2013.

A. Shameli-Sendi, N. Ezzati-Jivan, M. Jabbarifar, and M. Dagenais, ”Intru-sion Response Systems: Survey and Taxonomy,” International Journal ofComputer Science and Network Security, vol. 12, no. 1, pp. 1-14, 2012.

T. Spyridopoulos, G. Karanikas, T. Tryfonas, and G. Oikonomou, ”A GameTheoretic defense Framework Against DoS/DDoS Cyber Attacks,” Com-puters & Security, vol. 38, pp. 39-50, 2013.

S. N. Shiaeles, V. Katos, A. S. Karakos, and B. K. Papadopoulos, ”Real timeDDoS detection using fuzzy estimators,” Computers & Security, vol. 31,no. 6, pp. 782-790, 2012.

34

D. Moore, C. Shannon, D. J. Brown, G. M. Voelker, and S. Savage, ”Infer-ring internet denial-of-service activity,” ACM Transactions on ComputerSystems, vol. 24, no. 2, pp. 115-139, 2006.

T. M. Gil and M. Poletto, ”MULTOPS: a data-structure for bandwidth at-tack detection,” Proceedings of 10th Usenix Security Symposium, 2001.

J. Mirkovic, G. Prier, and P. Reiher, ”Attacking DDoS at the source,” Pro-ceedings of 10th IEEE International Conference on Network Protocols, pp.312-321, 2002.

R. R. Kompella, S. Singh, and G. Varghese, ”On scalable attack detectionin the network,” Proceedings of IMC 2004, pp. 187-200, 2004.

H. Wang, D. Zhang, and K. G. Shin, ”Detecting SYN flooding attacks,”Proceedings of IEEE INFOCOM 2002, pp. 1530-1539, 2002.

Y. Jarraya, T. Madi, and M. Debbabi, ”A Survey and a Layered Taxonomyof Software-Defined Networking,” vol. 16, no. 1, 2014.

A. Kuzmanovic and E. W. Knightly, ”Low-rate TCP-targeted denial of ser-vice attacks: the shrew vs. the mice and elephants,” Proceedings of the2003 conference on Applications, technologies, architectures, and protocolsfor computer communications, pp. 75-86, 2003.

Y. Chen, K. Hwang, and W. S. Ku, ”Collaborative detection of ddos at-tacks over multiple network domains,” IEEE Transaction on Parallel andDistributed Systems, vol. 18, no. 12, pp. 1649-1662, 2007.

R. Mahajan, S. Floyd, D. Wetherall, ”Controlling High-Bandwidth Flows atthe Congested Router,” Proceedings of the Ninth International Conferenceon Network Protocols, pp. 192-201, 2001.

R. Mahajan, S. Bellovin, S. Floyd, V. Paxson, and S. Shenker, ”Controllinghigh bandwidth aggregates in the network,” ACM Computer Communica-tions Review, vol. 32, no. 3, 2002.

J. Kline, S. Nam, P. Barford, D. Plonka, and A. Ron, ”Traffic anomalydetection at fine time scales with bayes nets,” The Third InternationalConference on Internet Monitoring and Protection, pp. 37-46, 2008.

35

L. Bernaille and R. Teixeira, ”Early recognition of encrypted applications,”In Proceedings of the Eighth Passive and Active Measurement Conference(PAM07), 2007.

K. Argyraki, and D. R. Cheriton, ”Scalable network-layer defense againstinternet bandwidth-flooding attacks,” IEEE/ACM Transactions on Net-working (TON), vol. 17, no. 4, pp. 1284-1297, 2009.

A. Matrawy, P. C. van Oorschot, and A. Somayaji, ”Mitigating networkdenial-of-service through diversity-based traffic management,” In AppliedCryptography and Network Security, pp. 104-121, 2005.

M. Polychronakis, K. G. Anagnostakis, E. P. Markatos, ”An empirical studyof real-world polymorphic code injection attacks,” In USENIX Workshopon Large-Scale Exploits and Emergent Threatsm, 2009.

D. Drutskoy, E. Keller, and J. Rexford, ”Scalable network virtualization insoftware-defined networks, Internet Computing, IEEE, vol. 17, no. 2, pp.20-27, 2013.

M. Vizvary and J. Vykopal, ”Future of DDoS Attacks Mitigation in SoftwareDefined Networks,” In Monitoring and Securing Virtualized Networks andServices, pp. 123-127, 2014.

J. Molsa, ”Effectiveness of rate-limiting in mitigating flooding DOS attacks,”In International Conference on Communications, Internet, and InformationTechnology, pp. 155-160, 2004.

J. Mirkovic, G. Prier, and P. Reiher, ”Source-end DDoS defense,” In theSecond IEEE International Symposium on Network Computing and Ap-plications, pp. 171-178, 2003.

H. I. Liu, and K. C. Chang, ”Defending systems Against Tilt DDoS attacks,”In 6th International Conference on Telecommunication Systems, Services,and Applications (TSSA), pp. 22-27, 2011.

R. Mahajan, S. Bellovin, S. Floyd, J. Ioaannidis, V. Paxson, and S. Shenker,”Aggregate-Based Congestion Control,” Computer Communication Re-view, vol. 32, no. 3, 2002.

36

Y. Chu, M. Tseng, Y. Chen, Y. Chou, and Y. Chen, ”A novel design for futureon-demand service and security,” in 12th IEEE International Conferenceon Communication Technology (ICCT), 2010.

Cisco Anomaly Guard, http://www.cisco.com/en/US/prod/collateral/modules/ps2706/ps6235/product_data_sheet0900aecd80220a7c.html

[Accessed July 2015].

J. Suh, H. Choi, W. Yoon, T. You, T. Kwon, and Y. Choi, ”Implementationof a Content-oriented Networking Architecture (CONA): A Focus on DDoSCountermeasure,” in European NetFPGA Developers Workshop, 2010.

P. D. Price, ”Toward an Internet Service Provider (ISP) Centric SecurityApproach,” M.Sc. Thesis, Naval Postgraduate School, 2002.

Y. Cai, ”A ddos defense mechanism with topology reconfiguration,” Journalof Engineering, Computing and Architecture, vol.2, no.1 , pp. 65-78, 2008.

J. Naous, D. Erickson, G.A. Covington, G. Appenzeller, and N. McKeown,”Implementing an openow switch on the netfpga platform,” in: Proceed-ings of the Fourth ACM/IEEE Symposium on Architectures for Network-ing and Communications Systems (ANCS08), pp. 1-9, 2008.

M. Glenn, ”A summary of dos/ddos prevention, monitoring and mitigationtechniques in a service provider environment,” SANS Institute, 2003.

M. Tanase, ”Closing the Floodgates: DDoS Mitigation Techniques,”http://www.symantec.com/connect/articles/closing-floodgates-

ddos-mitigation-techniques [Accessed July 2015].

S. Scepanovic, ”Mitigating DDoS attacks with cluster-based filtering”, M.Sc.Thesis, Aalto University, 2011.

J. Wang, ”Tolerating Denial-of-Service Attacks A System Approach,” Ph.D.Thesis, University of California, 2005.

P. Gupta and N. McKeown, ”Algorithms for packet classification”, IEEENetwork, vol. 15, no. 2, pp 24-32, 2001.

B. Jiang and B. Liu, ”High-speed discrete content Sensitive pattern matchalgorithm for deep packet filtering,” Proceedings of the 2003 International

37

Conference on Computer Networks and Mobile Computing, pp. 149-156,2003.

K. El Defrawy, A. Markopoulou, and K. Argyraki, ”Optimal Allocation ofFilters against DDoS Attacks,” In Information Theory and ApplicationsWorkshop, pp. 140-149, 2007.

R. Braga, E. Mota, and A. Passito, ”Lightweight DDoS flooding attack de-tection using NOX/OpenFlow,” in 2010 IEEE 35th Conference on LocalComputer Networks (LCN), 2010.

W. Dou, Q. Chen, and J. Chen, ”A confidence-based filtering method forDDoS attack defense in cloud environment,” Future Generation ComputerSystems, vol. 29, no. 7, pp. 1838-1850, 2012.

D. Sterne, K. Djahandari, B. Wilson, B. Babson, D. Schnackenberg, H. Hol-liday, and T. Reid, ”Autonomic response to distributed denial of serviceattacks,” In Recent Advances in Intrusion Detection, pp. 134-149, 2001.

C. Morrow and B. Gemberling, ”How to Allow Customers to BlackHoletheir own traffic,” 2003, http://www.twdx.net/CustomerBlackHole/

[Accessed July 2015].

P. Marques, N. Sheth, R. Raszuk, B. Greene, J. Mauch, and D. McPherson,”Dissemination of flow specification rules,” The Internet Engineering TaskForce, Internet-Drafts, 2003.

R. Lua and K. C. Yow, ”Mitigating DDoS attacks with transparent andintelligent fast-flux swarm network,” Network, IEEE, vol. 25, no. 4, pp.28-33, 2011.

M. M. El-Soudani and M. A. Eissa, ”Cooperative defense Firewall Protocol,”In Security and Privacy in the Age of Uncertainty, pp. 373-384, 2003.

L. C. Chen, T. A. Longstaff, and K. M. Carley, ”Characterization of defenseMechanisms against Distributed Denial of Service Attacks,” Computers &Security, vol. 23, no. 8, pp. 665-678, 2004.

J. Ioannidis and S. M. Bellovin, ”Pushback: Router-Based defense AgainstDDoS Attacks,” In Proceedings of NDSS, 2001.

38

R. Mahajan, S. M. Bellovin, S. Floyd, J. Ioannidis, V. Paxson, and S.Shenker. ”Controlling high bandwidth aggregates in the network,” ACMSIGCOMM Computer Communication Review, vol. 32, no. 3, pp. 62-73,2002.

T. Peng, C. Leckie, and K. Ramamohanarao, ”Defending against distributeddenial of service attacks using selective pushback,” Proceedings of the 9thIEEE International Conference on Telecommunications (ICT), pp. 411-429,2002.

F. Huici and M. Handley, ”An edge-to-edge filtering architecture againstDoS,” ACM SIGCOMM Computer Communication Review, vol. 37, no.2, pp. 39-50, 2007.

S. M. Sathyanarayana, ”Software defined network defense,” M.Sc. Thesis,University of Pennsylvania, 2011.

J. M. Gonzalez, V. Paxson, and N. Weaver, ”Shunting: a hardware/softwarearchitecture for flexible, high-performance network intrusion prevention,”In Proceedings of the 14th ACM conference on Computer and communi-cations security, pp. 139-149, 2007.

Cisco Anomaly Guard data sheet http://www.cisco.com/en/

US/prod/collateral/modules/ps2706/ps6235/product_data_

sheet0900aecd80220a7c.html [Accessed July 2015]

Verisign Internet defense network, http://www.

verisigninternetdefensenetwork.com [Accessed July 2015].

Denial of Service protection in a Programmable Network, http:

//www.nec.com/en/global/prod/pflow/images_documents/

GartnerReport_2013.pdf [Accessed July 2015].

N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J.Rexford, S. Shenker, and J. Turner, ”OpenFlow: Enabling Innovation inCampus Networks,” ACM SIGCOMM Computer Communication Review,vol. 38, no. 2, pp. 69-74, 2008.

C. Douligeris and A. Mitrokotsa, ”DDoS attacks and defense mechanisms:classification and state-of-the-art,” Computer Networks, vol. 44, no. 5, pp.643-666, 2004.

39

K. Singh, N. Kaur, and D. Nehra, ”A Comparative Analysis of Various De-ployment Based DDoS defense Schemes,” In Quality, Reliability, Securityand Robustness in Heterogeneous Networks, pp. 606-616, 2013.

W. Shi, Y. Xiang, and W. Zhou, ”Distributed defense against distributeddenial-of-service attacks,” In Distributed and Parallel Computing, pp. 357-362, 2005.

S. B. Lee, M. S. Kang, and V. D. Gligor, ”CoDef: collaborative defenseagainst large-scale link-flooding attacks,” In Proceedings of the ninth ACMconference on Emerging networking experiments and technologies, pp. 417-428, 2013.

S. Shin, P. Porras, V. Yegneswaran, M. Fong, G. Gu, and M. Tyson,”FRESCO: Modular Composable Security Services for Software-DefinedNetworks,” In Proceedings of the 20th Annual Network and DistributedSystem Security Symposium (NDSS), 2013.

T. Koponen, M. Casado, N. Gude, J. Stribling, L. Poutievski, M. Zhu, R.Ramanathan, Y. Iwata, H. Inoue, T. Hama, and S. Shenker, ”Onix: A Dis-tributed Control Platform for Large-scale Production Networks,” In TheSymposium on Operating Systems Design and Implementation (NSDI),2010.

S. A. Mehdi, J. Khalid, and S. A. Khayam, ”Revisiting Traffic AnomalyDetection Using Software Defined Networking,” In Proceedings of RecentAdvances in Intrusion Detection, 2011.

S. Shin, Z. Xu, and G. Gu, ”EFFORT: A New Host-Network CooperatedFramework for Efficient and Effective Bot Malware Detection,” ComputerNetworks, vol. 57, no. 13, pp. 2628-2642, 2013.

S. T. Zargar and J. Joshi, ”A collaborative approach to facilitate intrusiondetection and response against DDoS attacks,” In 6th International Con-ference on Collaborative Computing: Networking, Applications and Work-sharing (CollaborateCom), pp. 1-8, 2010.

S. T. Zargar and J. Joshi, ”DiCodefense: Distributed Collaborative defenseagainst DDoS Flooding attacks,” IEEE Symposium on Security and Pri-vacy, 2013.

40

T. Dubendorfer, M. Bossardt, and B. Plattner, ”Adaptive distributed trafficcontrol service for DDoS attack mitigation,” In 19th IEEE Internationalon Parallel and Distributed Processing Symposium, 2005.

Radware, http://www.radware.com/ [Accessed July 2015].

OpenContrail, DDoS, http://www.sdncentral.com/channel/juniper/

[Accessed July 2015].

C. Peng, M. Kim, Z. Zhang, and H. Lei, ”Vdn: Virtual machine imagedistribution network for cloud data centers,” in INFOCOM, pp. 181-189,2012.

D. K. Yau, J. Lui, F. Liang, and Y. Yam, ”Defending against distributeddenial-of-service attacks with max-min fair server-centric router throttles,”IEEE/ACM Transactions on Networking (TON), vol. 13, no. 1, pp. 29-42,2005.

Juniper, ”Network Fabrics for the Modern Data Center”, 2011.

M. Armbrust, A. Fox, R. Griffith, A. D. Joseph, R. H. Katz, A. Konwinski,G. Lee, D. A. Patterson, A. Rabkin, I. Stoica, and M. Zaharia, ”Above theclouds: A berkeley view of cloud computing,” EECS Department, Univer-sity of California, Berkeley, Tech. Rep. UCB/EECS-2009-28, 2009.

D. Seo, H. Lee, and A. Perrig, ”APFS: Adaptive Probabilistic Filter Schedul-ing against distributed denial-of-service attacks,” Computers & Security,vol. 39, pp. 366-385, 2013.

G. Yao, J. Bi, and P. Xiao, ”Source address validation solution with Open-Flow/NOX architecture,” In 19th IEEE International Conference on Net-work Protocols (ICNP), pp. 7-12, 2011.

J. Mirkovic, M. Robinson, P. Reiher, and G. Oikonomou, ”Distributed de-fense Against DDOS Attacks,” University of Delaware CIS DepartmentTechnical Report CIS-TR-2005-02, 2005.

M. Robinson, J. Mirkovic, S. Michel, M. Schnaider, and P. Reiher, ”DefCOM:defensive cooperative overlay mesh,” In DARPA Information SurvivabilityConference and Exposition, pp. 101-102, 2003.

41

J. Mirkovic, ”D-WARD: source-end defense against distributed denial-of-service attacks,” Ph.D. thesis, University of California Los Angeles, 2003.

G. Oikonomou, J. Mirkovic, P. Reiher, and M. Robinson, ”A framework fora collaborative DDoS defense,” In 22nd Computer Security ApplicationsConference, pp. 33-42, 2006.

H. Shah-Hosseini, ”The intelligent water drops algorithm: a nature-inspired swarm-based optimization algorithm,” International Journal ofBio-Inspired Computation, vol. 1, no. 1, pp. 71-79, 2009.

Z. A. Qazi, C. C. Tu, L. Chiang, R. Miao, V. Sekar, and M. Yu, ”SIMPLE-fying middlebox policy enforcement using SDN,” In Proceedings of theACM SIGCOMM 2013 conference on SIGCOMM, pp. 27-38, 2013.

J. W. Anderson, R. Braud, R. Kapoor, G. Porter, and A. Vahdat, ”xOMB:Extensible open middleboxes with commodity servers,” In Proceedings ofthe eighth ACM/IEEE symposium on Architectures for networking andcommunications systems, pp. 49-60, 2012.

S. Rajagopalan, D. Williams, H. Jamjoom, and A. Warfield, ”Split/Merge:System Support for Elastic Execution in Virtual Middleboxes,” In NSDI,pp. 227-240, 2013.

V. Sekar, N. Egi, S. Ratnasamy, M. K. Reiter, and G. Shi, ”Design andImplementation of a Consolidated Middlebox Architecture,” In NSDI, pp.323-336, 2012.

S. K. Fayazbakhsh, V. Sekar, M. Yu, and J. C. Mogul, ”FlowTags: enforcingnetwork-wide policies in the presence of dynamic middlebox actions,” InProceedings of the second ACM SIGCOMM workshop on Hot topics insoftware defined networking, pp. 19-24, 2013

DDoS-Defense4all, https://wiki.opendaylight.org/images/d/d1/

Defense4All_Proposal_Overview_-_130718.pdf [Accessed July 2015].

42