Download pdf - A Defense Framework for Flooding-Based DDoS Attacks

8/14/2019 A Defense Framework for Flooding-Based DDoS Attacks

1/113

A Defense Framework

for Flooding-based DDoS Attacks

by

Yonghua You

A thesis submitted to the

School of Computing

in conformity with the requirements for

the degree of Master of Science

Queens University

Kingston, Ontario, Canada

August 2007

Copyright c Yonghua You, 2007


2/113

Abstract

Distributed denial of service (DDoS) attacks are widely regarded as a major threatto the Internet. A flooding-based DDoS attack is a very common way to attack

a victim machine by sending a large amount of malicious traffic. Existing network-

level congestion control mechanisms are inadequate in preventing service quality from

deteriorating because of these attacks. Although a number of techniques have been

proposed to defeat DDoS attacks, it is still hard to detect and respond to flooding-

based DDoS attacks due to a large number of attacking machines, the use of source-

address spoofing, and the similarities between legitimate and attack traffic. In this

thesis, we propose a distributed framework which will help to improve the quality of

service of internet service providers (ISP) for legitimate traffic under DDoS attacks.

The distributed nature of DDoS problem requires a distributed solution. In this

thesis, we propose a distance-based distributed DDoS defense framework which de-

fends against attacks by coordinating between the distance-based DDoS defense sys-

tems of the source ends and the victim end. The proposed distance-based defense

system has three major components: detection, traceback, and traffic control. In the

detection component, two distance-based detection techniques are employed. The

distance value of a packet indicates the number of hops the packet has traversed from

i


3/113

an edge router to the victim. First, an average distance estimation DDoS detec-

tion technique is used to detect attacks based on the average distance values of the

packets received at the victim end. Second, a distance-based traffic separation DDoS

detection technique applies a traffic rate forecasting technique for identifying attack

traffic within traffic that is separated based on distance values. For the traceback

component, the existing Fast Internet Traceback (FIT) technique is employed to find

remote edge routers which forward attack traffic to the victim. Based on the proposed

distance-based rate limit mechanism, the traffic control component at the victim end

requests the source-end defense systems to set up rate limits on these routers in order

to efficiently reduce the amount of attack traffic.

We evaluate the DDoS defense framework on a network simulation platform called

NS2. We also evaluate the effectiveness of the two DDoS detection techniques in-

dependent of the proposed defense framework. The results demonstrate that both

detection techniques are capable of detecting flooding-based DDoS attacks, and thedefense framework can effectively control attack traffic in order to sustain the quality

of service for legitimate traffic. Moreover, the framework shows better performance in

defeating flooding-based DDoS attacks compared to the pushback technique, which

uses a local aggregate congestion control mechanism to detect and control traffic flows

that create congestion in a network.

ii


4/113

Acknowledgments

I am highly thankful to my supervisor, Dr. Mohammad Zulkernine, for guiding methrough my research.

I would also like to thank Dr. Scott Knight of the Royal Military College of

Canada for his comments on the DDoS detection techniques.

I am also grateful to my labmates for numerous discussions I have had with them.

I am grateful to my wife, my two sons, and my parents for having faith in me and

providing me the background motivation all through my life.

This research is partially supported by Bell Canada and MITACS (Mathematics of

Information Technology and Complex Systems), Canada. Mr. Anwar Haque and his

colleagues in Bell Canada provided very valuable advices in designing this framework.

iii


5/113

Table of Contents

Abstract i

Acknowledgments iii

Table of Contents iv

List of Tables vii

List of Figures viii

Chapter 1: Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Objective and Scope of the Research . . . . . . . . . . . . . . . . . . 31.3 Overview of the Defense Framework . . . . . . . . . . . . . . . . . . . 41.4 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.5 Organization of the Thesis . . . . . . . . . . . . . . . . . . . . . . . . 6

Chapter 2: Distributed Denial-of-Service Attacks . . . . . . . . . . 72.1 Distributed Cooperative Architecture of DDoS . . . . . . . . . . . . . 82.2 IP Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3 Flooding DDoS Attack Mechanisms . . . . . . . . . . . . . . . . . . . 11

2.3.1 Smurf: ICMP Flooding-based Attack . . . . . . . . . . . . . . 142.3.2 TCP SYN Flooding-based Attack . . . . . . . . . . . . . . . . 152.3.3 Trinoo: UDP Flooding-based Attack . . . . . . . . . . . . . . 16

2.3.4 DNS Amplification Attack . . . . . . . . . . . . . . . . . . . . 172.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Chapter 3: Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 203.1 DDoS Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1.1 IP Attributes-based DDoS Detection . . . . . . . . . . . . . . 223.1.2 Traffic Volume-based DDoS Detection . . . . . . . . . . . . . 23

3.2 DDoS Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

iv


6/113

3.2.1 Packet Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2.2 Rate Limiting . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.3 DDoS Defense Framework . . . . . . . . . . . . . . . . . . . . . . . . 313.3.1 Victim-end Defense . . . . . . . . . . . . . . . . . . . . . . . . 313.3.2 Source-end Defense . . . . . . . . . . . . . . . . . . . . . . . . 343.3.3 Distributed Defense . . . . . . . . . . . . . . . . . . . . . . . . 36

3.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Chapter 4: Distance-based Defense Framework . . . . . . . . . . . . 424.1 Overview of Defense Framework . . . . . . . . . . . . . . . . . . . . 424.2 Detection Component . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.2.1 Calculating Distance Using a Single-Bit Field . . . . . . . . . 47

4.2.2 Average Distance Estimation DDoS Detection . . . . . . . . . 49Estimating Mean Distance . . . . . . . . . . . . . . . . . . . . 49Estimating Mean Absolute Deviation (MAD) . . . . . . . . . 50DDoS Detection Algorithm . . . . . . . . . . . . . . . . . . . 51

4.2.3 Distance-Based Traffic Separation DDoS Detection . . . . . . 52Estimating Arrival Rate . . . . . . . . . . . . . . . . . . . . . 53Estimating Deviation . . . . . . . . . . . . . . . . . . . . . . . 53DDoS Detection Algorithm . . . . . . . . . . . . . . . . . . . 54

4.2.4 Integration of Two Detection Techniques . . . . . . . . . . . . 554.3 Traceback Component . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.4 Traffic Control Component . . . . . . . . . . . . . . . . . . . . . . . . 574.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Chapter 5: Experiments and Results . . . . . . . . . . . . . . . . . . 625.1 Overview of the Pushback Technique . . . . . . . . . . . . . . . . . . 635.2 Simulation Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.2.1 Simulating Internet Topology . . . . . . . . . . . . . . . . . . 66Topology for Detection Evaluation . . . . . . . . . . . . . . . 66Topology for Framework Evaluation . . . . . . . . . . . . . . . 67

5.2.2 Simulating Internet Data Traffic . . . . . . . . . . . . . . . . . 67HTTP Traffic for Detection Evaluation . . . . . . . . . . . . . 68HTTP Traffic for Framework Evaluation . . . . . . . . . . . . 68

5.2.3 Simulating Attack Traffic . . . . . . . . . . . . . . . . . . . . . 68Attack Traffic for Detection Evaluation . . . . . . . . . . . . . 68Attack Traffic for Framework Evaluation . . . . . . . . . . . . 69

5.2.4 Performance Metrics . . . . . . . . . . . . . . . . . . . . . . . 69Metrics for Detection Evaluation . . . . . . . . . . . . . . . . 70Metrics for Framework Evaluation . . . . . . . . . . . . . . . . 70

v


7/113

5.3 Detection Performance . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.3.1 Adjustment of the Parameters . . . . . . . . . . . . . . . . . . 725.3.2 Results: Average Distance Estimation DDoS Detection . . . . 725.3.3 Results: Distance-based Traffic Separation DDoS Detection . . 74

5.4 Defense Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . 765.4.1 Average Latency of HTTP Transactions . . . . . . . . . . . . 775.4.2 Failure Rate of HTTP Transaction . . . . . . . . . . . . . . . 785.4.3 Throughput of Legitimate Traffic . . . . . . . . . . . . . . . . 795.4.4 Bandwidth Allocation of Traffic . . . . . . . . . . . . . . . . . 835.4.5 Drop Rate of Attack Traffic . . . . . . . . . . . . . . . . . . . 855.4.6 Drop Rate of Legitimate Traffic . . . . . . . . . . . . . . . . . 86

5.5 Discussions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

5.5.1 Different DDoS Attacks . . . . . . . . . . . . . . . . . . . . . 885.5.2 IP Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

5.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Chapter 6: Conclusion and Future Work . . . . . . . . . . . . . . . . 906.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

vi


8/113

List of Tables

4.1 Symbols used in the listing are . . . . . . . . . . . . . . . . . . . . . . 514.2 Symbols used in the distance-based traffic separation DDoS detection

algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.3 Symbols used in the rate limit algorithm . . . . . . . . . . . . . . . . 58

5.1 Performance of The Average Distance Estimation DDoS Detection . . 745.2 Performance of The Distance-based Traffic Separation DDoS Detection 765.3 Average Latency of HTTP Transactions . . . . . . . . . . . . . . . . 775.4 Failure Rates of HTTP Transactions . . . . . . . . . . . . . . . . . . 795.5 Drop Rate of Attack Traffic . . . . . . . . . . . . . . . . . . . . . . . 855.6 Drop Rate of Legitimate Traffic . . . . . . . . . . . . . . . . . . . . . 87

vii


9/113

List of Figures

2.1 Typical architecture of a DDoS attack . . . . . . . . . . . . . . . . . 92.2 Architecture of a DDoS attack using reflectors . . . . . . . . . . . . . 102.3 A direct flooding-based DDoS attack . . . . . . . . . . . . . . . . . . 12

2.4 A reflector flooding-based DDoS attack . . . . . . . . . . . . . . . . . 132.5 Comparison between Smurf broadcast amplification and DNS amplifi-

cation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.6 A DNS amplification DDoS attack . . . . . . . . . . . . . . . . . . . 18

4.1 Distance-based distributed DDoS defense framework . . . . . . . . . . 434.2 Illustration of distance-based distributed DDoS defense operation . . 454.3 Conceptual architecture of the defense system . . . . . . . . . . . . . 464.4 IP header [83] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.5 FIT marking field diagram. Frag# is the fragment number field. [15] 48

5.1 A DDoS attack in progress [79] . . . . . . . . . . . . . . . . . . . . . 635.2 DDoS detection based on average distance estimation when thr = 7.0,

w= 0.7, and r = 0.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 735.3 ROC curves of the average distance estimation DDoS detection technique 755.4 DDoS detection based on the traffic separation for distance = 2 . . . 755.5 No DDoS defense with ratio (9:1) . . . . . . . . . . . . . . . . . . . . 805.6 Pushback with ratio (9:1) . . . . . . . . . . . . . . . . . . . . . . . . 805.7 Distance-based DDoS defense with ratio (9:1) . . . . . . . . . . . . . 805.8 No DDoS defense with ratio (5:5) . . . . . . . . . . . . . . . . . . . . 815.9 Pushback with ratio (5:5) . . . . . . . . . . . . . . . . . . . . . . . . 81

5.10 Distance-based DDoS defense with ratio (5:5) . . . . . . . . . . . . . 815.11 No DDoS defense with 1 attacker . . . . . . . . . . . . . . . . . . . . 825.12 Pushback with 1 attacker . . . . . . . . . . . . . . . . . . . . . . . . . 825.13 Distance-based DDoS defense with 1 attacker . . . . . . . . . . . . . 825.14 Bandwidth allocation at the congested link during a DDoS attack with

ratio (9:1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845.15 Bandwidth allocation at the congested link during a DDoS attack with

ratio (5:5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

viii


10/113

5.16 Bandwidth allocation at the congested link during a DDoS attack with

1 attacker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

ix


11/113

Chapter 1

Introduction

1.1 Motivation

All Internet Service Providers (ISPs) face the problem of increasing amounts of un-

wanted traffic. Unwanted traffic is the data packets which consume limited resources

like bandwidth and decrease the performance of the network, thus lowering the ser-

vice quality of the network. Unwanted traffic can be produced by user misbehavior or

explicit attacks like flooding-based Distributed Denial of Service (DDoS). A flooding-

based DDoS attack is a very common way to attack a victim machine by sending a

large amount of unwanted traffic. Network level congestion control can successfully

throttle peak traffic to protect the whole network. However, it cannot prevent the

quality of service (QoS) for legitimate traffic from going down because of attacks.

DDoS is one of the major threats for the current Internet because of its ability

to create a huge volume of unwanted traffic [1]. The primary goal of these attacks

is to prevent access to a particular resource like a Web site [57]. The first reported

1


12/113

CHAPTER 1. INTRODUCTION 2

large-scale DDoS attack occurred in August, 1999, against the University of Min-

nesota [58]. This attack shut down the victims network for more than two days. In

the year 2000, a DDoS attack stopped several major commercial Web sites, including

Yahoo and CNN, from performing their normal activities [58]. In [59], D. Moore

et al. used backscatter analysis on three week-long datasets to assess the number,

duration and focus of DDoS attacks, and to characterize their behavior. They found

that more than 12,000 attacks had occurred against more than 5,000 distinct victims

in February, 2001. In October, 2002, the Domain Name Systems (DNS) in the Coop-

erative Association for Internet Data Analysis (CAIDA) network became the victim

of a heavy DDoS attack. Many legitimate users could not access web sites because

their DNS requests were not able to reach root DNS servers. The congestion caused

by the DDoS attack forced routers to drop these requests [60].

A more serious DNS-based DDoS attack was reported in March, 2006 [61]. Instead

of attacking DNS servers directly, this new type of DDoS attack just used DNSservers as reflectors to create a stronger attack. This kind of DDoS is harder to be

stopped than normal DDoS attacks due to complicated DNS protocols and interaction

among multiple DNS servers. During two months, 1,500 individual Internet protocol

addresses were attacked using this approach.

Since the first reported DDoS happened in the summer of 1999, a large number

of detection and response techniques have been proposed [58]. However, none of

them gives reliable protection [62] for the victim. Two features of DDoS hinder the

advancement of defense techniques. The first one is that it is hard to distinguish

between DDoS attack traffic and normal traffic. The detection of the DDoS attack is


13/113


very hard under this situation. There is a lack of an effective differentiation mecha-

nism that results in minimal collateral damage for legitimate traffic. The second one

is that the sources of DDoS attacks are hard to be found out in a distributed network.

A DDoS attack is difficult to be stopped quickly and effectively.

1.2 Objective and Scope of the Research

The objective of this research is to help ISPs to control unwanted traffic by miti-

gating flooding-based DDoS attacks in IP-based networks. This thesis concentrates

especially on the following objectives:

1. A detection technique should detect a DDoS attack with high reliability and

at an early stage of the attack.

2. A response technique should drop most of the attack packets without sacri-

ficing the QoS for legitimate traffic.

3. The defense framework should work effectively in distributed network envi-

ronments.

This thesis studies flooding-based DDoS attacks in computer networks using the

Internet Protocol (IP). In fact, another type of DDoS attack, called a logic DDoS

attack, can crash a victim without creating flooding-based traffic. It attacks the

victim based on the exploitation of vulnerabilities in the victim [62]. A victim can

counter these attacks by fixing its flaws after scanning vulnerabilities in its network. A

logic DDoS attack does not create anomalous congestion in the network. This research

focuses on flooding-based DDoS attack which is still one of the major threats for the

current Internet.


14/113


1.3 Overview of the Defense Framework

In this thesis, we propose a distributed cooperative DDoS defense framework. In-

stead of deploying a defense system at a particular node in a network, we deploy our

proposed distance-based defense system at each edge router in a network. Compared

with routers in a backbone network, edge routers have enough resources (computing

cycles, memory, etc.) to support a defense system because they have less traffic [33].

The defense system consists of three major components: detection, traceback, and

traffic control. The detection component implements two proposed distance-based

DDoS detection techniques (average distance estimation and distance-based traffic

separation). The distance value of a packet indicates the number of hops the packet

has traversed from an edge router to the victim. The trip of a packet from a router to

another in the network is called a hop. The traceback component mainly focuses on

analyzing incoming traffic in order to find out the addresses of the source-end edge

routers. The traffic control component is triggered to set up fitting rate limits for

attack traffic after receiving alert messages from other defense systems at the victim

end.

In a DDoS attack scenario, the proposed distributed framework defends against

attacks by coordinating between the distance-based DDoS defense systems at the

source ends and the victim end. A victim-end defense system detects unusual changes

of incoming traffic in order to ferret out hidden attacks. When it finds that an attack

is in progress, the following sequence of events follow:

1. Source finding: To find source-end edge routers, traditional methods rely on

the topological knowledge in each node and iterative communication among nodes.

In contrast, source finding in our framework uses the Fast Internet Traceback (FIT)


15/113


technique [15] which just needs edge routers to mark distance and their addresses

into IP packets. Furthermore, source finding can be accomplished by the traceback

component of the defense system at the victim end.

2. Broadcasting alert messages: The defense system at the victim end would

only send alert messages to source-end nodes.

3. Rate Limiting: The traffic control component of a source-end defense system

rules out attack traffic based on the information from the victim end. A distance-

based rate limit mechanism is triggered to drop attack traffic at the source ends.

Instead of penalizing each source-end router equally, the mechanism sets up different

rate limits for routers based on how aggressively they are forwarding attack traffic to

the victim.

1.4 Contributions

The key contributions of this thesis include the following.

1. A distributed DDoS defense framework based on the proposed distance-based

DDoS defense systems is presented. The response at the source ends and the detection

at the victim end detect and erase attack traffic effectively.

2. An average distance estimation-based DDoS detection and a traffic separation-

based DDoS detection techniques are proposed [78]

3. A distance-based attack traffic control mechanism is presented.

4. The proposed framework and the techniques are evaluated on a network

simulation platform called NS2.


16/113


1.5 Organization of the Thesis

This thesis is organized as follows. In Chapter 2, a comprehensive description of

DDoS is given, and both general attack mechanisms and some typical flooding-based

DDoS attacks are discussed in detail. In Chapter 3, related techniques existing in

the literature are compared and contrasted with our proposed techniques. Chapter 4

describes the proposed distance-based DDoS defense framework. Chapter 5 demon-

strates the effectiveness of the proposed framework in a number of simulations using

NS2. Finally, we conclude with a summary of contributions and discuss future work

in Chapter 6.


17/113

Chapter 2

Distributed Denial-of-Service

Attacks

As one of the major security problems in the current Internet, a denial-of-service

(DoS) attack always attempts to stop the victim from serving legitimate users. A

distributed denial-of-service (DDoS) attack is a DoS attack which relies on multiple

compromised hosts in the network to attack the victim. There are two types of DDoS

attacks. The first type of DDoS attack has the aim of attacking the victim to force it

out of service for legitimate users by exploiting software and protocol vulnerabilities

of the system [62]. The second type of DDoS attack is based on a huge volume of

attack traffic, which is known as a flooding-based DDoS attack. A flooding-based

DDoS attack attempts to congest the victims network bandwidth with real-looking

but unwanted IP data. As a result, legitimate IP packets cannot reach the victim due

to a lack of bandwidth resource. To amplify the effects and hide real attackers, DDoS

attacks can be run in two different distributed coordinated fashions. In the first one,

the attacker compromises a number of agents and manipulates the agents to send

7


18/113

CHAPTER 2. DISTRIBUTED DENIAL-OF-SERVICE ATTACKS 8

attack traffic to the victim. The second method makes it even harder to determine

the attack sources because it uses reflectors. A reflector is any host that will return a

packet if it receives a request packet [63]. For example, a Web server can be reflector

because it will return a HTTP response packet after receiving a HTTP request packet.

The attacker sends request packets to severs and fakes victims address as the source

address. Therefore, the servers will send back the response packets to the real victim.

If the number of reflectors is large enough, the victim network will suffer exceptional

traffic congestion.

Before we introduce the DDoS attack architectures and mechanisms, we give two

basic definitions. First, the DDoS attack traffic is the traffic which is produced or

triggered by the compromised agents. Second, the legitimate traffic is the traffic which

is produced by the normal hosts. In this chapter, we analyze two basic distributed

architectures of flooding-based DDoS attacks and common IP spoofing techniques

used by DDoS attacks. Furthermore, we specify the basic mechanism of flooding-based DDoS attacks and list three typical flooding-based DDoS attacks.

2.1 Distributed Cooperative Architecture of DDoS

Before real attack traffic reaches the victim, the attacker must cooperate with all its

DDoS agents. Therefore, there must be control channels between the agents and the

attacker [62]. This cooperation requires all agents send traffic based on commands

received from the attacker. The network which consists of the attacker, agents, and

control channels is called the attack networks. In [64], attack networks are divided

into three types: the agent-handle model, the Internet Relay Chat (IRC)-based model,

and the reflector model.


19/113


Figure 2.1: Typical architecture of a DDoS attack

The agent-handler model consists of three components: attacker, handlers, and

agents. Fig. 2.1 illustrates the typical architecture of the model. One attacker sends

control messages to the previously compromised agents through a number of han-

dlers, instructing them to produce unwanted traffic and send it to the victim. The

architecture of IRC-based model is not that much different than that of the agent-

handler model except that instead of communication between an attacker and agents

based on handlers, an IRC communication channel is used to connect the attacker to

agents [64].

Fig. 2.2 illustrates the architecture of an attack network in the reflector model.

The reflector layer makes a major difference from the typical DDoS attack architec-

ture. In the request messages, the agents modify the source address field in the IP

header using the victims address to replace the real agents addresses. Then, the


20/113


Figure 2.2: Architecture of a DDoS attack using reflectors

reflectors will in turn generate response messages to the victim. As a result, the

flooding traffic which reaches the victim is not from a few hundred agents, but from

a million reflectors [63]. An exceedingly diffused reflector-based DDoS attack raises

the bar for tracing out the real attacker by hiding the attacker behind a large number

of reflectors. Unlike some types of DDoS attacks, the reflector does not need to

serve as an amplifier [63]. This means that reflectors still can serve other legitimate

requests properly even when they are generating attack traffic. The attacker does not

need to compromise reflectors to control their behaviors in the way that agents need

to be compromised. Therefore, any host which will return a response if it receives a

request can be a reflector. These features facilitate the attackers task of launching

an attack because it just needs to compromise a small number of agents and find a

sufficient number of reflectors.


21/113


2.2 IP Spoofing

IP spoofing is used in all DDoS attacks as a basic mechanism to hide the real address

of agents or the attacker. In a classical DDoS attack, the agents randomly spoof

the source addresses in the IP header. In a reflector-based DDoS attack, agents

must put the victims address in the source address field. The spoofed addresses can

be addresses of either existing or non-existing hosts. To avoid ingress filtering, the

attacker can use addresses that are valid in the internal network because non-existing

addresses have a high possibility of being filtered out.

In the real-world, it is possible to launch an attack without IP spoofing if the

attacker can compromise enough hosts. For this situation, the attacker would consider

how to avoid to be traced out. Usually, the attacker will use a chain of compromised

hosts. Tracing a chain which extends across multiple countries is very hard to be

achieved. Furthermore, to compromise poorly monitored hosts in a network will

make tracing more difficult due to a lack of information. In these situations, IP

spoofing is not a necessary step for hiding the attacker.

2.3 Flooding DDoS Attack Mechanisms

Flooding-based DDoS attacks involve agents or reflectors sending a large volume of

unwanted traffic to the victim. The victim will be out of service for legitimate trafficbecause its connection resources are used up. Common connection resources include

bandwidth and connection control in the victim system. Generally, flooding-based

DDoS attacks consist of two types: direct and reflector attacks [65]. Fig. 2.3 is

another view of the process of a direct flooding-based DDoS attack. The architecture


22/113


Figure 2.3: A direct flooding-based DDoS attack

of the direct attack is same as the typical DDoS attack illustrated in Fig. 2.1. The

agents send the Transmission Control Protocol/Internet Protocol (TCP), the Internet

Control Message Protocol (ICMP), the User Datagram Protocol (UDP), and other

packets to the victim directly. The response packets from the victim will reach the

spoofed receivers due to IP spoofing. In a reflector attack, presented in Fig. 2.4,

the response packets from reflectors truly attack the victim. No response packets

need be sent back to reflectors from the victim. The key factors to accomplishing a

reflector attack include: setting the victim address in the source field of the IP header

and finding enough reflectors. Basically, an attacker can utilize any protocol as the

network layer platform for a flooding-based attack [62].

Direct attacks usually choose three mechanisms: TCP SYN flooding, ICMP echo

flooding, and UDP data flooding [66]. The TCP SYN flooding mechanism is different

from the other two mechanisms. It causes the victim to run out of all available TCP

connection control resources by sending a large number of TCP SYN packets. The

victim cannot accept a new connection from a legitimate user without new available


23/113


Figure 2.4: A reflector flooding-based DDoS attack

control resources. ICMP echo flooding-based attacks will consume all available band-

width as a large number of ICMP ECHO REPLY packets arrive at the victim. UDP

data flooding-based attacks achieve the same result as ICMP echo attacks by sending

a large number of UDP packets to either random or specified ports on the victim [64].

Reflector attacks rely on protocol features in the victim. Any protocol which will

send a response message to the victim can be utilized for a reflector attack. To create a

stronger reflector attack, the attacker can utilize the packet amplification technique.

An amplifier is used between the agents and the real reflectors. It broadcasts the

request packets from agents to all reflectors address of which are within the broadcast

address range. Most routers support the IP broadcast feature in current network [64].

Therefore, there exist a large number of potential amplifiers. This helps an attacker

increase the volume of an attack with a lesser reflectors-finding cost.

For attacks which target the bandwidth of the victim, the architecture of the

victim network decides how large a volume of attack traffic is needed. Increasing

the bandwidth of links and erasing bottleneck links in its own network can increase


24/113


the ability of a victim to tolerate flooding-based attacks. An attack which target

connection control resources usually relies on flaws of the control mechanism of the

operating system of the victim. Regularly updating software patches for the operating

system can fix these problems and avoid being effectively attacked in future.

In the following subsections, we present some of typical flooding-based DDoS

attacks.

2.3.1 Smurf: ICMP Flooding-based Attack

A Smurf attack is a typical attack using amplifiers. ICMP is the protocol platform for

this attack [68]. Usually, ICMP REQUEST and ECHO REPLY messages are used for

carrying control information. For example, a network management system can use

ICMP messages to fetch the status of a router. In a Smurf attack, the source address

field of a ICMP ECHO REQUEST message is set as the victim address. Therefore,

the ICMP ECHO REPLY message will be sent to the victim instead of the real

request message sender (the attack agent). In fact, it is a kind of reflector attack

illustrated in Fig. 2.4. To amplify the effect, the ECHO REQUEST messages could

be sent to an amplifier which can broadcast messages to all IP addresses in its subnet.

If there are n hosts in the subnet, the victim will receive n ECHO REPLY messages.

A large number of ICMP ECHO REPLY messages will consume all bandwidth in

the victim. A Smurf attack can happen because of poor security considerations whenimplementing an ICMP protocol. Turning off the IP broadcast function in a router

can lower the risk to trigger attacks. However, it is not a realistic solution to discard

all the benefits of IP broadcast.


25/113


2.3.2 TCP SYN Flooding-based Attack

During the construction of a normal TCP connection, the client should accomplish a

negotiation process with the server. First, the client sends a TCP SYN packet to the

server carrying client information to request a connection. Then, the server dispatches

a connection block in the memory and sends back a TCP SYS-ACK packet which

contains a sequence number and other server information. Finally, the client will

confirm it has received the server information by sending a TCP ACK packet back to

the server again. This is called the 3-way handshake mechanism. After a connection

has been constructed, the actual TCP data communication can be started.

During the 3-way handshake, an important feature is that the number of received

TCP SYN packets at the server decides the number of memory blocks used for TCP

connection control. Therefore, the server will run out of memory if it receives a large

number of TCP SYN packets in a short period of time. Eventually, this situation

leads the server to be unreachable by other clients. This is the basic mechanism of

TCP SYN attacks. In a real TCP SYN attack, the attacker will use the IP spoofing

technique. The victim will receive a large number of TCP SYN packets with the

spoofed addresses of non-existing hosts [62]. However, the victim cannot receive any

TCP ACK packets because no hosts will respond to its TCP SYN ACK packets.

Thus, the attack will result in a number of half-open connections in server memory.

As a result, the server cannot serve new connection requests because it is out ofmemory. In a worse situation, the server will be crashed.

One of the proposed solutions is to lower the TCP timeout in order to increase

the speed of memory recycling. However, most solutions just focus on improvements

to victim systems tolerance for the attack instead of on TCP SYN flooding traffic


26/113


control.

2.3.3 Trinoo: UDP Flooding-based Attack

A UDP flooding-based attack attacks the victim using UDP, a sessionless computer

networking protocol. When a UDP flood attack happens, the victim will receive a

large number of UDP packets at a number of random ports. As a result, the victim

will try to determine the application listening at that port. If no application is found,

the victim should reply with an ICMP Destination Unreachable packet. Usually, a

UDP flooding-based attack fills the bandwidth of the connection at the victim end.

Therefore, the connection will not be available for legitimate traffic. Basically, a

UDP flooding-based attack is a direct attack. However, it can be a reflector attack

for another victim if the attacker sets another victims address in the source address

field instead of a random address. As the illustration in Fig. 2.3 shows, the spoofed

receiver becomes another victim.

Unlike in the TCP protocol, UDP-based communication between sender and re-

ceiver has no built-in mechanisms to maintain flows when the network conditions are

changing. In fact, there do not exist any flow control mechanisms to deal with the

congestion created by UDP. Moreover, spoofed UDP traffic is even harder to be de-

tected at the victim end than a spoofed TCP traffic. To construct a TCP connection,

there is a 3-way handshake negotiation mechanism and the victim can detect thespoofed packets during negotiation. In contrast, UDP does not have a negotiation

mechanism because it is a connectionless protocol. Therefore, an attacker can spoof

a packet easily. To deal with UDP attacks, the victim needs to rely on the defense

systems in its upstream network to stop malicious UDP packets.


27/113


2.3.4 DNS Amplification Attack

According to VeriSigns security chief, they were attacked in March 2006 by a DNS

amplification attack which was significantly larger than any normal DDoS attack [77].

A DNS amplification attack is a relatively new kind of reflector attack. It uses re-

cursive name servers to create an amplification effect similar to the now-aged Smurf

attack [67]. A direct comparison between Smurf and DNS amplification is presented

in Fig. 2.5. A Smurf attacker sends a packet to an amplifier to broadcast the packet

Figure 2.5: Comparison between Smurf broadcast amplification and DNS amplifica-tion

to all hosts in the subnet, each of whom will respond with a response packet. In DNS

amplification, the sender sends a packet of very small size. However, the DNS sever

sends back a response packet with a much larger size. Another important feature of

a DNS amplification attack is that it must forge the victims address in the source

address field in a DNS query packet. Therefore, the DNS server will send a response

packet to the victim. The basic process is illustrated in Fig. 2.6. Specifications of


28/113


even more complex DNS amplification attacks are available in [67].

Figure 2.6: A DNS amplification DDoS attack

It is even harder to defend against DNS amplification attacks than to defend

against normal DDoS attacks because of the complex interactive mechanisms between

clients and DNS server, and among the DNS servers themselves.

2.4 Summary

We presented a survey of flooding-based DDoS attacks in this chapter. In a typical

DDoS attack network, an attacker sends commands to compromised agents and ask

them send a large volume of traffic to overwhelm the bottleneck link in the victim

network. To hide the attacker itself more deeply, a DDoS attack can construct an

attack network with a reflector-based architecture. In the network, an attacker sends

a packet whose source address has been set as the victims address to reflectors.


29/113


The response messages will be sent to the victim as attack traffic. IP spoofing is a

common feature of DDoS attacks by spoofing the real addresses in the IP packet. To

avoid ingress filtering, IP spoofing can use valid addresses in the internal network.

There are two basic mechanisms for flooding-based attacks. In the first mechanism,

an agent creates attack traffic which directly heads to the victim. In contrast, the

second mechanism relies on the response traffic from reflectors to overwhelm the

victim. A few typical flooding-based DDoS attacks show that a DDoS attacker can

create attack traffic by using multiple existing protocols (TCP, ICMP, UDP, etc.).

Moreover, the newly evolved DDoS attacks can create attack traffic based on the

current DNS mechanism.

Recently reported events indicate that flooding-based DDoS attacks is still one of

the major threats for current Internet security. In the literature, there are a number of

DDoS detection, traceback, and response techniques invented to deal with the threat.

In addition, a number of frameworks are proposed to achieve more effective DDoSdefense. In the next chapter, we summary those efforts related to our studies.


30/113

Chapter 3

Related Work

In this chapter, we compare and contrast our work with some related work. As we

mentioned before that our proposed framework has three major components, the re-

lated work are divided based on the following three issues: DDoS detection, DDoS

response, and DDoS defense framework. In Section 3.1, we focus on comparing and

contrasting the two proposed distance-based DDoS techniques with other detection

techniques. The other detection techniques mainly include IP attributes-based DDoS

detection and traffic volume-based DDoS detection. Current DDoS response tech-

niques can mainly be divided into two types: packet filtering and rate limiting. We

summarize the studies of the above two types and contrast the proposed distance-

based Max-Min fair share rate limit algorithm with other rate limit algorithms in

Section 3.2. Defense frameworks can be categorized into three types based on the lo-

cation of the defense system in the network: victim-end defense, source-end defense,

and distributed defense. In Section 3.3, we introduce some existing frameworks and

compare them to our proposed DDoS defense framework.

20


31/113

CHAPTER 3. RELATED WORK 21

3.1 DDoS Detection

DDoS detection is usually the first step in the battle for DDoS attacks. Any DDoS

detection technique always attempts to detect an attack by observing anomalous

changes in IP attributes or traffic volume because there do not exist clear DDoS attack

signatures. From a network topology point of view, DDoS attack traffic comes from

a number of routers. It will definitely change the statistical distribution of the traffic

topology. Traffic topology for a host is a map of upstream routers that are traversed by

the traffic sent to the receiving host (victim). As mentioned in Section 1.3, a distance

value of a packet is the number of hops the packet has traversed from one edge

router to a victim host. We think that distance-based DDoS detction techniques can

detect the anomalous changes of traffic topology led by DDoS attack traffic. For this

propose, we propose two distance-based DDoS detection techniques: average distance

estimation and distance-based traffic separation. The average distance estimation

DDoS detection technique works on distance metric directly. It detects an attack

based on the fact that the changes of traffic topology will lead to the changes of average

distance values. The distance-based traffic separation DDoS detection technique uses

distance metric indirectly. The technique needs to work on separated traffic based on

distance values. It detects an attack based on the fact that the changes of separated

traffic correlate to the changes of traffic topology. In the following two subsections, we

analyze some current DDoS detection techniques based on IP attributes and traffic

volume, and specify the improvements gained by our two distance-based detection

techniques.


32/113


3.1.1 IP Attributes-based DDoS Detection

A number of works treat anomalies as deviations in a number of IP attributes, e.g.,

source IP address [4], TTL [5], and the combination of multiple attributes [8]. In [4],

a simple scheme is proposed to detect DDoS attacks by monitoring the increase of

new IP addresses. TTL is used by Jung et al. for the analysis of Internet Website

load performance [9]. A DDoS attack usually creates network congestion and changes

the statistical distribution of the TTL attribute in traffic. Based on this idea, Tal-

pade et al. [5] propose a TTL-based statistical model to detect anomalies created by

DDoS attacks. Unfortunately, the techniques performance is not satisfactory because

the changes in final TTL values cannot reflect the anomalous changes in the traffic

topology directly. In our distance-based techniques, we use TTL to compute distance

value. We believe that the changes in distance values directly represent the changes

of traffic topology when DDoS attacks happen.

To achieve better performance, some studies combine multiple IP attributes to-

gether. In [8], Kim et al. construct a baseline profile on a number of attribute

combinations, such as IP protocol-type and packet-size, source IP prefix and TTL

values, as well as server port number and protocol-type, etc. However, these com-

binations cannot improve performance if the combined attributes are not related to

the anomalous changes created by the DDoS attacks. Moreover, a combination of

the attributes definitely will make computation more complex and possibly increasethe false positive rate. Feinstein et al. [10] design a DDoS detection technique by

computing entropy and frequency-sorted distributions of the selected attributes in-

stead of using IP attributes directly. However, this performance still depends on the

attribute used for the computation of the entropy.


33/113


We believe that the key issue is to identify an indicator which reflects anoma-

lous changes very well. Distance is a relatively better choice based on our studies.

Therefore, we construct our average estimation DDoS detection technique based on

the distance values directly.

3.1.2 Traffic Volume-based DDoS Detection

A large number of traffic volume-based anomaly detection works exist in the literature.

In [11], Gil and Poletto propose a heuristic data structure MULTOPS (Multi-Level

Tree for Online Packet Statistics). They use a multi-level tree that keeps packet

rate statistics for subnet prefixes at different aggregate levels. Normal traffic usually

has a proportional rate to or from hosts and subnets. Therefore, an attack will be

detected when MULTOPS observes a disproportional rate of traffic. To directly detect

anomalies in traffic rate, Jiang et al. [12] develop an anomaly-tolerant nonstationary

traffic prediction technique. Network anomalies can be detected as deviations in

overall traffic volume. A similar idea is used by Lee et al. [13] except that they use

the exponential smoothing technique to predict traffic rate and the mean absolute

deviation (MAD) model to detect anomalous changes of traffic rate. Unfortunately,

they do not get satisfactory results because the exponential smoothing technique is

too simple to accurately predict complex and dynamic traffic rate.

On the other hand, some highly accurate prediction techniques are not suitable forreal-time traffic volume prediction due to the high computational complexity. For ex-

ample, FBM [18] and FARIMA [19] are not appropriate for this purpose because both

include lots of complex calculation [24]. In contrast, the computational complexity

of the Minimum Mean Square Error (MMSE) prediction technique is not very high.


34/113


MMSE prediction technique predict the traffic volume using a linear combination of

the current and previous values of traffic volume. In addition, the performance of

MMSE is almost as good as FBM or FARIMA based on Wenyu et al. study in [24].

Therefore, we believe that the MMSE technique is very suitable for computing traffic

volume in real-time.

Another problem with existing studies is that they apply their techniques for

anomaly detection of aggregate traffic. However, it is very hard to detect the trivial

anomalous changes of aggregate traffic rate during the early stages of a DDoS attack

because the attack traffic is actually still a small partition of the entire traffic at the

victim end. To deal with this situation, we propose a new strategy based on traffic

separation, where traffic is categorized based on distance values. If we analyze each

traffic flow separately, it is much easier to distinguish anomalous traffic from normal

traffic. Gao et al. [24] show that MMSE is efficient traffic rate prediction technique.

We use MMSE to predict the normal traffic rate on each separated traffic flow, andthe MAD-based deviation model helps detect attacks. This distance-based separation

strategy and its combination with the MAD-based deviation model is a unique feature

of our distance-based traffic separation DDoS detection technique.

3.2 DDoS Response

After a DDoS attack has been detected, response techniques attempt to control in-

coming traffic by packet filtering or rate limit techniques. Based on the studies done

by J. Molsa et al. [44], packet filtering techniques can cause more damage to legitimate

traffic than rate limit techniques because it is difficult to distinguish DDoS traffic from

normal traffic [53]. Therefore, in our framework, we propose a distance-based rate


35/113


limit technique. In the following two subsections, we discuss packet filtering and rate

limit techniques separately. In addition, we will compare and contrast our rate limit

technique with other rate limit techniques.

3.2.1 Packet Filtering

To counter DDoS attacks, one of the most straightforward methods is to filter out

malicious traffic flows. Packet filtering is usually accomplished at routers based on

clearly-defined attack signatures, such as obviously wrong source addresses. However,

DDoS attack traffic cannot be filtered out if it uses packets that request legitimate

services [54]. Another common drawback of packet filtering is that it usually needs

to be deployed widely in order to protect the victim.

Ingress filtering was initially proposed in RFC2267 [80], which has been replaced

by a newer version RFC2827 [56]. Ingress filtering enables a router to check a packet

for its source address, and drop packets which carry invalid addresses. To distinguish

between valid and invalid addresses, the best place to deploy it is at edge routers

where address ownership is relatively simple and clear. If ingress filtering is widely

deployed, spoofed IP address DDoS attack traffic has fewer opportunities to enter

into the Internet. However, it cannot work if an attacker spoofs a IP address which is

valid in the local internal network. In addition, it does not help the victim to defend

against attacks which are not using spoofed IP addresses.Y.-H. Hu et al. propose a time-window-based packet filtering mechanism in [50].

It works before the regular queue management operation in a router. Based on a

sliding time-window size of which is dynamically changed, it identifies and drops

malicious and aggressively increasing attack flows. However, collateral damage for


36/113


legitimate traffic is unavoidable because it does not distinguish between attack and

legitimate packets.

T. Peng et al. propose a history-based IP filtering mechanism to stop attack

packets from entering into the Internet at edge routers [33]. After analyzing normal

IP traffic, they find that most IP addresses in legitimate packets arriving at a server

reappear regularly. Edge routers save all IP addresses which have been proved to

be legitimate in its previous connection history. Then, when the victim is suffering

from a high level of congestion, routers will drop packets which do not exist in the

database. A drawback of the mechanism is that it cannot work if an attacker uses

the addresses which are stored in the database.

Hop-Count filtering is a mechanism proposed by C. Jin et al. to counter spoofed IP

address DDoS attacks [24]. After analyzing attack tools used at the time, they found

that all tools do not change the TTL field in the IP header. Therefore, the hop number

can be inferred from the TTL field. This mechanism classifies the packets based onaddress prefixes and builds an accurate IP to hop-count mapping table. Then, when

the network experiences a high level of congestion, the mechanism will drop those

packets whose hop number does not match the mapping table. An obvious drawback

of the mechanism is that it can be tricked if an attacker spoofs the initial value of the

TTL field, and spoofing the TTL field is not more difficult than spoofing other fields

in the IP header. Another drawback is still collateral damage for legitimate traffic.

Under a high level of congestion, congestion control mechanisms will often reroute

legitimate packets, which may change their hop numbers. Then, they will be dropped

because they no longer match the mapping table.

In [51], L. Feinstein et al. propose a statistical mechanism to defend against


37/113


DDoS attack by analyzing the entropy and calculating the chi-square statistic of

IP attributes. The mechanism divides source addresses into a few bins based on

their frequency. During detection, the chi-square statistic detection component finds

out source addresses which belong to bins in which distributions of frequencies are

anomalous. Then, a number of static filtering rules will be set up to filter out packets

from these bins. An obvious drawback of the mechanism is that it does not provide

good performance on attacks with no spoofed packets. For this kind of attacks, the

frequency of source address variation is small and not easily detectable. In addition,

one bin of source addresses may include a number of legitimate addresses, and the

static filtering rules will harm them too.

S. Tanachaiwiwat et al. propose an adaptive packet filtering mechanism [47] to

defend against DDoS attacks by providing differential QoS for attack and legitimate

traffic. The mechanism requires the routers to store a packet before forwarding it.

In routers, the mechanism increases the IP counter by one and resets the time to themaximum value in the active IP table based on the address in the packet. The routers

decide QoS for this packet based on the current IP counter value. Usually, legitimate

packets get higher IP counter values because legitimate addresses often appear regu-

larly. In contrast, a large number of spoofed IP addresses will turn up when attacks

happen. Of course, their IP counter values will be very low. The mechanism does not

distinguish between legitimate and attack packets. It just attempts to sustain high

QoS for legitimate traffic. However, it cannot protect a new legitimate connection

during an attack because their IP counter values are low too. Furthermore, it can be

tricked to forward attack traffic with high QoS when an attacker uses IP addresses

which have high IP counter values. In this situation, the router will help attack traffic


38/113


reach the victim because this particular attack traffic will receive high QoS.

3.2.2 Rate Limiting

In computer networks, rate limiting is used to control the rate of traffic sent or

received on a network interface. Traffic that is less than or equal to the specified rate

is sent, whereas traffic that exceeds the rate is dropped or delayed [81]. J. Molsa

demonstrates the effectiveness of rate limiting to defend DDoS attacks in [52]. Rate

limiting can be used as a fast, automatic reaction mechanism to mitigate an attack

without any undue penalties for legitimate traffic [52]. In contrast, collateral damage

for legitimate traffic is unavoidable in packet filtering because DDoS traffic cannot be

easily distinguished from legitimate traffic [53].

The Max-Min fair share algorithm is usually used for resource management in IP

network research. A traditional Max-Min share algorithm is to allow all routers to

share the capacity of the victim equally. For example, the max-min share for each

router among 5 routers is 2Mbps if the available bandwidth of the victim is 10Mbps.

In [26], Y. Jing et al. treat DDoS attacks as a resource management problem [45]. To

achieve better control under DDoS attacks, they modify the traditional Max-Min fair

share algorithm by adding the reputation of monitored flows. If a monitored traffic

flow is identified as an attack flow in a refresh time period, its reputation value will

be degraded exponentially. During the next refresh time period, the flows reputationwill be equal to one if the flow returns back to normal. When an attack happens,

reputation will influence the calculation of the rate limit value for the flow. Based on

NS2 simulations, better performance can be achieved than the traditional Max-Min

algorithm. Furthermore, the volume of aggregated traffic is always below the limit of


39/113


the victim-end network. However, the flow-based algorithm is not useful for spoofed

DDoS attacks and the rate limit algorithm relies on highly accurate flow-based DDoS

detection. Unfortunately, flow-based DDoS detection is difficult due to the similarity

between legitimate traffic and attack traffic [53]. Finally, a more serious problem is

that the reputation score does not represent the real history information of a flow very

well. For example, an attack flow returns to normal for the victim after a rate limit

works on it. Based on the algorithm, the reputation will be increased to one. In fact,

there may still be a large number of dropped attack packets. Therefore, variation of

the drop rate of a flow has no direct relationship with its reputation. In contrast,

our proposed rate limit algorithm works on distance-based separated traffic instead

of flow and directly combines the drop rate into its calculation of rate limit values.

To defend DDoS attacks, D. K. Y. Yau et al. propose a level-k Max-Min fair rate

limit algorithm [45]. The algorithm can achieve level-k Max-Min fairness among the

routers that are less than or equal to k hops away from the victim but are directlyconnected to a host. This means that allowed forwarding rate of traffic for the victim

at each router among these routers is the Max-Min fair share of the victims capacity.

The algorithm works based on the fact that the traffic rate at the victim end is normal

if traffic rates forwarded to the victim by all level-k routers are normal. When attacks

happen, the algorithm will set up an equal rate limit on all level-k routers to protect

the victim. In particular, the algorithm gives better protection for the victim than

the pushback rate limit algorithm proposed by R. Mahajan et al. [30]. One drawback

of the algorithm is that the same rate limit for all level-k routers is unfair for these

routers which forward little or no attack traffic. Collateral damage for legitimate

traffic will be unavoidable in these routers. In our proposed rate limit algorithm,


40/113


different rate limits are used for different routers at distance d based on their own

drop rates. Lower rate limit values will be applied on the routers which are forwarding

a large amount of attack traffic. Higher rate limit values will be applied on the routers

which are forwarding little attack traffic. The algorithm will drop more attack packets

while collateral damage for legitimate packets is less than level-k Max-Min fair rate

limit algorithm.

Based on different attack flow features on different network protocols, J. Mirkovic

et al. propose a flow-based rate limit algorithm [39]. When a flow is identified as an

attack flow for the first time, its sending rate is exponentially decreased. This means

that attack flows are quickly restricted to a very slow rate. Fast protection for the

victim can be achieved. After attacks have gone, the recovery phase is divided into

slow-recovery and exponential fast-recovery. In the beginning, the algorithm linearly

increases rate limit values in order to limit the effectiveness of repeated attacks. After

the network is stable enough, the algorithm increases rate limit values exponentially.As soon as the rate limit values reach the maximum value, the rate limit values will

be removed. Like other flow-based rate limit algorithms, it cannot detect and react

to current DDoS attacks fast and effectively because DDoS attack flows are hard to

be distinguished from normal traffic flows. Another drawback of the algorithm is

that the source-end rate limit algorithm cannot easily control attack traffic without

information from the victim end. In our rate limit algorithm, calculation of rate limit

values is based on information from the victim end. An better decision can be reached

based on abundant information.

In [30], R. Mahajan et al. propose a recursive pushback rate limit algorithm

which is implemented as a built-in component in each router. When a router detects


41/113


that it is under heavy congestion, it identifies upstream routers which are sending

offending aggregates. Usually, a aggregate is a subset of traffic with an identifiable

attribute [79]. After an aggregate is detected, the pushback on the router calculates

rate limit values based on the total arrival rate at its output queue and its drop

history. The same limit value will be applied for each aggregate. The drawback

of the algorithm is that it does not differentiate among aggregates. In fact, it just

punishes them equally. In contrast, our rate limit algorithm can set up different rate

limit values based on the drop rate of each aggregate in each router.

3.3 DDoS Defense Framework

DDoS defense frameworks can be categorized into three types based on the deploy-

ment of the defense systems in the network: victim-end defense framework, source-end

defense framework, and distributed defense framework. In the next subsections, we

introduce some of the existing frameworks of above three types and compare our

distributed framework with the existing distributed frameworks.

3.3.1 Victim-end Defense

Historically, most defense systems are deployed at the victim end. Few source-end

defense systems exist in real-world because the direct benefit of the system is achieved

by the victim, but not by the source-end network [54]. Therefore, source-end ISPs

lack the motivation to deploy source-end defense systems. In contrast, the victim

has strong motivation to deploy DDoS defense system since it suffers the greatest

impact of the attack [55]. However, victim defense systems cannot provide complete


42/113


protection from DDoS attacks because it is too late to respond to heavy DDoS attacks.

Even though the victim-end defense system can drop all incoming attack traffic,

legitimate traffic still cannot go through congested links between the victim and the

other parts of the network. This is a common drawback for all victim-end defense

systems.

In [42], Y. Kim et al. propose a path signature (PS)-based victim-end defense

system. The system requires all routers to flip selected bits in the IP identification

field for all incoming packets. Based on these marking bits, a unique PS can be

generated for all packets from the same location. At the victim end, the defense

system separates traffic based on the PS of each packet and detects DDoS attacks

by monitoring anomalous changes of traffic amount from a PS. Then, a rate limit

value will be set up on this traffic. However, there are a few drawbacks of the system.

First, it is hard to detect DDoS attacks if PS diversity is much greater than real

router diversity of incoming traffic. Second, the PS of a route changes dynamically.It is possible that a PS has been changed after an attack has been detected. For this

situation, collateral damage for legitimate traffic cannot be avoided.

H. Luo et al. propose a victim-end DDoS defense system to maintain QoS for a

multimedia server when it becomes the victim of a DDoS attack [41]. The system

detects DDoS attacks by using a data mining technique. After an anomaly in incoming

traffic is found, the system asks the server to adjust the sending rate of multimedia

data based on the congestion status created by DDoS attacks. A serious drawback of

the system is that there is not an effective rate limit algorithm to throttle offending

traffic. In addition, the DDoS detection technique based on data mining can only

work after enough training has been done on normal data. Once underlying traffic


43/113


pattern changes, the technique needs to be retrained to avoid false positives. During

retraining, it has higher risk to be mistrained by an attacker to regard attack traffic

as legitimate one.

NetBouncer [35] is an end-point-based solution to throttle traffic as close to the

victim as possible. To distinguish legitimate traffic from illegitimate traffic, a Net-

Bouncer needs to maintain a large legitimate list of clients that have been proven to

be legitimate by a series of tests. These tests are done at three layers for different

purposes. At the network layer, a test determines the validity of a host or router as

identified by its IP address. At the transport layer, a test tries to validate a TCP

connection. At the application layer, a test determines the validity of an application

session, an user process, and an identifier. Through this approach, NetBouncer is

likely to accurately detect legitimate clients. However, there are a few problems for

its application in the real-world. First, it cannot find attack packets which include

addresses from legitimate client list. Second, a congested link delays the transmissionof test response messages from clients to NetBouncer. Therefore, NetBouncer cannot

react to an attack in time.

The approaches we have discussed thus far attempt to protect the victim by throt-

tle incoming malicious traffic. Other approaches try to increase the availability of the

victim to resist DDoS attacks by using resource multiplication and content distribu-

tion approach [37] [48]. Both these approaches essentially raise the bar on how huge

DDoS attacks must be to stop the victim from providing regular services. Resource

multiplication approaches provide an abundance of resources. The straightforward

instance is a system which connects to the network with multiple high bandwidth

links and deploys a server pool with a load balancer. In [37], J. Yan et al. propose a


44/113


resilient platform - XenoService - for web service. XenoService can acquire resources

from network dynamically once a victim is under attack. In [48], content distribution

is supported by the Web Caching and Mirror Server techniques. Both techniques

replicate whole or part of the content in the server and serve client requests on behalf

of the server. Resource multiplication is too expensive to be afforded by most web

server owners. In addition, maintaining data consistency among distributed content

storage servers is still an open question which should be taken into account when

using the content distribution approach. In general, both approaches are sufficient.

However, they do not provide perfect protection because no measures are taken to

decrease attack traffic.

3.3.2 Source-end Defense

DDoS attacks put the victim out of business by consuming the bandwidth at the

victim end. To protect the victim from a flooding-based DDoS attack, the response

mechanism should be as close to the attack source as possible. The source-end re-

sponse mechanism has a few advantages over the victim-end response mechanism [39].

First, it can control and avoid congestion more effectively. Second, source-end edge

routers can support complex and multiple-level defense strategies because they relay

relatively less traffic.

D-WARD [39] is a typical source-end DDoS defense system. It classifies the trafficinto flows on different protocols. Based on TCP, ICMP, UDP normal traffic model,

and connection classification, D-WARD can identify malicious flows at a source end.

Once an attack flow is found, it will be controlled under a rate limit value. Although

D-WARD can detect some attacks at a source end, the detection may be error prone


45/113


due to lack of communication between the source and the victim end, and coordination

among source-end defense systems [54]. Moreover, the UDP model used by D-WARD

is ineffective because UDP does not require any reverse response packets from the

victim. Therefore, J. Mirkovic et al. suggest that a better way to use D-WARD is to

integrate it into a distributed system as a source-end defense system.

Y. Fan et al. [40] propose a Source Router Preferential Dropping (SRPD) mech-

anism to defeat DDoS attacks. In fact, it is not a pure source-end DDoS defense

system because it needs the output queue occupancy rate at the victim end to help

detect DDoS attacks. The source-end SRPD queries this information by sending a

newly designed ICMP request message. In an ICMP response message, the victim

provides its queue occupancy rate to SRPD. After SRPD has identified a high-rate

flow, the malicious flow will be dropped with a probability which is calculated based

on the average response time of packets. Although SRPD tries to utilize coordination

between the source ends and the victim end to defend against DDoS attacks, it isstill a source-end defense system because most defense information and strategies are

from source ends except for the output queue occupancy rate. It is obvious that only

the victim can precisely describe the attack status. Moreover, SRPD does not work

when UDP DDoS attacks happen.

In general, attack traffic control should be as close to the source end as possible

in order to quickly and effectively respond to DDoS attacks. DDoS detection should

take place at the victim end because of abundant information about attack traffic.

Furthermore, any defense strategies should be based on information from the vic-

tim end too. For example, the calculation of rate limit values should be based on

congestion status on the victim end.


46/113


3.3.3 Distributed Defense

Exiting research on DDoS falls into three categories: detection of attack, source find-

ing, and attack traffic control. In fact, these are three phases to an attack defense

for an efficient DDoS defense system. In this section, we compare and contrast tech-

niques used in our framework with other existing distributed frameworks based on

the above three phases.

Y. Jing et al. [26] recently proposed an overlay-based distributed defense frame-

work when attacks are detected at the victim end. Unfortunately, the authors do

not explain the detection technique very clearly. During source finding, the Source

Path Isolation Engine (SPIE) traceback technique is used. To control attack traffic

at source ends, the authors try to combine the history of a flow into a rate limit

calculation by defining a reputation argument. This framework has a few obvious

faults. The realization of the framework needs a relatively huge modification of cur-

rent networks. The complex communication mechanism between the over-layer and

physical network, and frequent data commutation between a data center (Defense

Service Provider) and the victim end to support SPIE traceback are not realistic

when the victim is under a heavy attack. Moreover, a spoofing DDoS attack can

make the flow-based rate limit algorithm out of work. In our framework, a smaller

extension of routers is needed and only for the FIT technique. The FIT technique is

a much better choice than SPIE based on Yaars [15] explanation. Finally, spoofingattacks have no deleterious effects on our distance-based rate limit algorithm.

A distributed detection and response scheme is proposed by H.-Y Lam et al. [28].

A Stub Agent (SA) deployed in a local ISP network detects anomalous changes of

the traffic rate by using the cumulative sum (CUSUM) [34]. Source-end SAs and


47/113


transit network agents (TA) lower attack traffic in the network by setting different

rate limits. Unfortunately, DDoS detection based on disproportionate TCP packet

rates cannot cover proportional attacks, attacks with randomized forged IP addresses

originating from a single machine, and attacks that use many agents. Furthermore,

rate limiting at core routers definitely lowers the performance of the whole network.

The entire scheme lacks an effective method to reconstruct the attack path when a

spoofing attack happens. A more serious problem is collateral damage for legitimate

traffic. The two distance-based DDoS detection techniques of our framework work

well under these DDoS attacks in the distance-based DDoS defense system at the

victim end. Based on the distance-based rate limit mechanism, distance-based DDoS

defense systems at the source ends can efficiently control attack traffic to maintain

QoS for legitimate traffic with less collateral damage .

DefCOM [29] is a distributed cooperative system for DDoS defense developed

by J. Mirkovic et al.. In DefCOMs dynamically-built overlay peer-to-peer network,nodes communicate with each other to defend an attack cooperatively. The DefCOM

overlay consists of three types nodes: alert generators, classifiers, and rate-limiters.

Alert generator nodes collect detection information from physical nodes and flood

alert messages to all other overlay nodes. Classifier nodes differentiate between le-

gitimate and attack packets. Rate-limiter nodes control attack traffic at source-end

routers. While fighting a DDoS attack, all nodes communicate with each other by

flooding messages every six seconds. Frequent communication among a huge number

of defense nodes has very high risk to be utilized by attackers to attack the DefCOM

system itself. Furthermore, the classifier will not work for current DDoS attack traffic

because of no distinct signature. In contrast, we use a relatively simple cooperative


48/113


mechanism between the distance-based DDoS defense system and ones at source ends

to avoid unnecessary message broadcasting. Our distance-based attack traffic control

mechanism provides higher performance on traffic with more coarse granularity in the

situation where flow-based DefCOM classifier nodes may not work.

G. Zhang and M. Parashar [31] propose and evaluate a novel distributed frame-

work on the overlay network. In the new scheme, an attack defense system is deployed

in intermediate networks. A intermediate network is a network to connect multiple

autonomous systems. To forward a huge volume of traffic among multiple autonomous

systems, an intermediate network usually consists of high-speed routers. After these

routers spend their most resources to forward traffic, they do not have enough re-

sources to support complex DDoS defense strategies. Furthermore, the framework

reacts to a DDoS attack slowly due to lack of efficient source finding techniques. In

our framework, the FIT technique supports fast reaction in source-end edge routers

after detecting DDoS attacks at the victim end. Relatively complex defense mecha-nisms can get enough resources at edge routers because of light traffic load.

COSSACK [32], proposed by Christos Papadopoulos et al., is a cooperative DDoS

suppression framework. Rather than observing traffic in the core network, COSSACK

focuses on detecting the changes of traffic at the egress/ingress point of an individual

edge network. An watchdog forwards attack information over an overlay distribution

tree spanning all the participant watchdog systems. Source-end watchdog systems use

the existing technique (D-WARD [39]) to set rate limit for attack traffic. One of the

serious disadvantages of COSSACK is that spoofing DDoS attacks are not addressed.

Unfortunately, spoofing source addresses is a basic feature for current DDoS attacks.

Second, multicast mechanism used for alert message broadcasting limits COSSACKs


49/113


scalability. Last, COSSACK uses different detection techniques at the source and

victim ends. This definitely makes the cooperative mechanism more complex and its

reaction slower because detection results from the source-end detection technique have

no connection to attack reality at the victim end. In our framework, relatively clear

functional separation between victim-end and source-end systems helps expedite the

reaction to a DDoS attack. The simple cooperative mechanism makes the framework

scale to a large network with less cost.

Unlike other distributed DDoS defense systems, T. Pang et al. [33] propose a

distributed framework which works well under high-distributed DDoS attacks. A

history-based IP filtering scheme is globally deployed in edge routers, and history

information decides whether to admit a packet. However, there does not exist an

effective cooperative mechanism among the edge router filtering systems. Therefore,

efficient reaction is not possible. Furthermore, the filtering-based scheme works badly

under current attacks due to an unclear attack signature. Therefore, collateral damagefor legitimate traffic will be inflicted at edge routers. Our framework can quickly react

to DDoS attacks based on an efficient cooperative mechanism. The distance-based

rate limit mechanism decreases collateral damage for legitimate traffic.

K.K.K. Wan et al. [27] propose a global defense infrastructure (GDI). Fully con-

figured local detection systems (LDSes) are deployed where most cross-domain traffic

will pass through. After receiving alert messages, LDSes decide whether to filter

a packet. Unfortunately, the multiple-level traffic filtering mechanism definitely in-

creases the risk of inflicting collateral damage on legitimate traffic. In addition, the

attack detection process at cross-domain slows down the sending rate of legitimate

traffic. Finally, GDI needs huge memories at routers to store huge traffic data. In


50/113


contrast, our distance-based detection techniques and rate limit mechanism do not

need to save huge history data.

In the pushback technique proposed by Floyd et al. [30], a downstream router

coordinates with upstream routers and requires them to control attack traffic which

is leading to downstream router congestion. Basically, the pushback technique is di-

vided into two parts: a local aggregate congestion control (ACC) and a cooperative

pushback mechanism. A local ACC detect and control flows that create congestion

of traffic using its own rate limit technique. Under a severe attack, a local ACC will

send pushback messages to upstream routers to require them to control their traffic.

As we mentioned in Section 3.2.2, in our framework, distance-based rate limit mecha-

nism creates less collateral damage for legitimate traffic than the pushback technique.

Furthermore, the pushback technique needs to broadcast pushback messages along an

attack path from a vict