Anda di halaman 1dari 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

Queen’s University

Kingston, Ontario, Canada


August 2007

c Yonghua You, 2007


Copyright °
Abstract

Distributed denial of service (DDoS) attacks are widely regarded as a major threat

to 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
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 the

defense 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
Acknowledgments

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

through 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
Table of Contents

Abstract i

Acknowledgments iii

Table of Contents iv

List of Tables vii

List of Figures viii

Chapter 1: Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Objective and Scope of the Research . . . . . . . . . . . . . . . . . . 3
1.3 Overview of the Defense Framework . . . . . . . . . . . . . . . . . . . 4
1.4 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5 Organization of the Thesis . . . . . . . . . . . . . . . . . . . . . . . . 6

Chapter 2: Distributed Denial-of-Service Attacks . . . . . . . . . . 7


2.1 Distributed Cooperative Architecture of DDoS . . . . . . . . . . . . . 8
2.2 IP Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Flooding DDoS Attack Mechanisms . . . . . . . . . . . . . . . . . . . 11
2.3.1 Smurf: ICMP Flooding-based Attack . . . . . . . . . . . . . . 14
2.3.2 TCP SYN Flooding-based Attack . . . . . . . . . . . . . . . . 15
2.3.3 Trinoo: UDP Flooding-based Attack . . . . . . . . . . . . . . 16
2.3.4 DNS Amplification Attack . . . . . . . . . . . . . . . . . . . . 17
2.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Chapter 3: Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 20


3.1 DDoS Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.1 IP Attributes-based DDoS Detection . . . . . . . . . . . . . . 22
3.1.2 Traffic Volume-based DDoS Detection . . . . . . . . . . . . . 23
3.2 DDoS Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

iv
3.2.1 Packet Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.2 Rate Limiting . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 DDoS Defense Framework . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.1 Victim-end Defense . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.2 Source-end Defense . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3.3 Distributed Defense . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Chapter 4: Distance-based Defense Framework . . . . . . . . . . . . 42


4.1 Overview of Defense Framework . . . . . . . . . . . . . . . . . . . . 42
4.2 Detection Component . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.1 Calculating Distance Using a Single-Bit Field . . . . . . . . . 47
4.2.2 Average Distance Estimation DDoS Detection . . . . . . . . . 49
Estimating Mean Distance . . . . . . . . . . . . . . . . . . . . 49
Estimating Mean Absolute Deviation (MAD) . . . . . . . . . 50
DDoS Detection Algorithm . . . . . . . . . . . . . . . . . . . 51
4.2.3 Distance-Based Traffic Separation DDoS Detection . . . . . . 52
Estimating Arrival Rate . . . . . . . . . . . . . . . . . . . . . 53
Estimating Deviation . . . . . . . . . . . . . . . . . . . . . . . 53
DDoS Detection Algorithm . . . . . . . . . . . . . . . . . . . 54
4.2.4 Integration of Two Detection Techniques . . . . . . . . . . . . 55
4.3 Traceback Component . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.4 Traffic Control Component . . . . . . . . . . . . . . . . . . . . . . . . 57
4.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Chapter 5: Experiments and Results . . . . . . . . . . . . . . . . . . 62


5.1 Overview of the Pushback Technique . . . . . . . . . . . . . . . . . . 63
5.2 Simulation Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.2.1 Simulating Internet Topology . . . . . . . . . . . . . . . . . . 66
Topology for Detection Evaluation . . . . . . . . . . . . . . . 66
Topology for Framework Evaluation . . . . . . . . . . . . . . . 67
5.2.2 Simulating Internet Data Traffic . . . . . . . . . . . . . . . . . 67
HTTP Traffic for Detection Evaluation . . . . . . . . . . . . . 68
HTTP Traffic for Framework Evaluation . . . . . . . . . . . . 68
5.2.3 Simulating Attack Traffic . . . . . . . . . . . . . . . . . . . . . 68
Attack Traffic for Detection Evaluation . . . . . . . . . . . . . 68
Attack Traffic for Framework Evaluation . . . . . . . . . . . . 69
5.2.4 Performance Metrics . . . . . . . . . . . . . . . . . . . . . . . 69
Metrics for Detection Evaluation . . . . . . . . . . . . . . . . 70
Metrics for Framework Evaluation . . . . . . . . . . . . . . . . 70

v
5.3 Detection Performance . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.3.1 Adjustment of the Parameters . . . . . . . . . . . . . . . . . . 72
5.3.2 Results: Average Distance Estimation DDoS Detection . . . . 72
5.3.3 Results: Distance-based Traffic Separation DDoS Detection . . 74
5.4 Defense Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.4.1 Average Latency of HTTP Transactions . . . . . . . . . . . . 77
5.4.2 Failure Rate of HTTP Transaction . . . . . . . . . . . . . . . 78
5.4.3 Throughput of Legitimate Traffic . . . . . . . . . . . . . . . . 79
5.4.4 Bandwidth Allocation of Traffic . . . . . . . . . . . . . . . . . 83
5.4.5 Drop Rate of Attack Traffic . . . . . . . . . . . . . . . . . . . 85
5.4.6 Drop Rate of Legitimate Traffic . . . . . . . . . . . . . . . . . 86
5.5 Discussions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.5.1 Different DDoS Attacks . . . . . . . . . . . . . . . . . . . . . 88
5.5.2 IP Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Chapter 6: Conclusion and Future Work . . . . . . . . . . . . . . . . 90


6.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

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

vi
List of Tables

4.1 Symbols used in the listing are . . . . . . . . . . . . . . . . . . . . . . 51


4.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 . . 74


5.2 Performance of The Distance-based Traffic Separation DDoS Detection 76
5.3 Average Latency of HTTP Transactions . . . . . . . . . . . . . . . . 77
5.4 Failure Rates of HTTP Transactions . . . . . . . . . . . . . . . . . . 79
5.5 Drop Rate of Attack Traffic . . . . . . . . . . . . . . . . . . . . . . . 85
5.6 Drop Rate of Legitimate Traffic . . . . . . . . . . . . . . . . . . . . . 87

vii
List of Figures

2.1 Typical architecture of a DDoS attack . . . . . . . . . . . . . . . . . 9


2.2 Architecture of a DDoS attack using reflectors . . . . . . . . . . . . . 10
2.3 A direct flooding-based DDoS attack . . . . . . . . . . . . . . . . . . 12
2.4 A reflector flooding-based DDoS attack . . . . . . . . . . . . . . . . . 13
2.5 Comparison between Smurf broadcast amplification and DNS amplifi-
cation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.6 A DNS amplification DDoS attack . . . . . . . . . . . . . . . . . . . 18

4.1 Distance-based distributed DDoS defense framework . . . . . . . . . . 43


4.2 Illustration of distance-based distributed DDoS defense operation . . 45
4.3 Conceptual architecture of the defense system . . . . . . . . . . . . . 46
4.4 IP header [83] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.5 FIT marking field diagram. Frag# is the fragment number field. [15] 48

5.1 A DDoS attack in progress [79] . . . . . . . . . . . . . . . . . . . . . 63


5.2 DDoS detection based on average distance estimation when thr = 7.0,
w = 0.7, and r = 0.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.3 ROC curves of the average distance estimation DDoS detection technique 75
5.4 DDoS detection based on the traffic separation for distance = 2 . . . 75
5.5 No DDoS defense with ratio (9:1) . . . . . . . . . . . . . . . . . . . . 80
5.6 Pushback with ratio (9:1) . . . . . . . . . . . . . . . . . . . . . . . . 80
5.7 Distance-based DDoS defense with ratio (9:1) . . . . . . . . . . . . . 80
5.8 No DDoS defense with ratio (5:5) . . . . . . . . . . . . . . . . . . . . 81
5.9 Pushback with ratio (5:5) . . . . . . . . . . . . . . . . . . . . . . . . 81
5.10 Distance-based DDoS defense with ratio (5:5) . . . . . . . . . . . . . 81
5.11 No DDoS defense with 1 attacker . . . . . . . . . . . . . . . . . . . . 82
5.12 Pushback with 1 attacker . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.13 Distance-based DDoS defense with 1 attacker . . . . . . . . . . . . . 82
5.14 Bandwidth allocation at the congested link during a DDoS attack with
ratio (9:1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.15 Bandwidth allocation at the congested link during a DDoS attack with
ratio (5:5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

viii
5.16 Bandwidth allocation at the congested link during a DDoS attack with
1 attacker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

ix
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
CHAPTER 1. INTRODUCTION 2

large-scale DDoS attack occurred in August, 1999, against the University of Min-
nesota [58]. This attack shut down the victim’s 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 DNS

servers 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
CHAPTER 1. INTRODUCTION 3

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.
CHAPTER 1. INTRODUCTION 4

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)
CHAPTER 1. INTRODUCTION 5

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.


CHAPTER 1. INTRODUCTION 6

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.
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 victim’s 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
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 victim’s 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.
CHAPTER 2. DISTRIBUTED DENIAL-OF-SERVICE ATTACKS 9

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 victim’s address to replace the real agents’ addresses. Then, the
CHAPTER 2. DISTRIBUTED DENIAL-OF-SERVICE ATTACKS 10

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 attacker’s task of launching
an attack because it just needs to compromise a small number of agents and find a

sufficient number of reflectors.


CHAPTER 2. DISTRIBUTED DENIAL-OF-SERVICE ATTACKS 11

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 victim’s 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 traffic
because 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
CHAPTER 2. DISTRIBUTED DENIAL-OF-SERVICE ATTACKS 12

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
CHAPTER 2. DISTRIBUTED DENIAL-OF-SERVICE ATTACKS 13

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
CHAPTER 2. DISTRIBUTED DENIAL-OF-SERVICE ATTACKS 14

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 when

implementing 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.


CHAPTER 2. DISTRIBUTED DENIAL-OF-SERVICE ATTACKS 15

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 of

memory. 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 system’s tolerance for the attack instead of on TCP SYN flooding traffic
CHAPTER 2. DISTRIBUTED DENIAL-OF-SERVICE ATTACKS 16

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 victim’s 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 the

spoofed 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.


CHAPTER 2. DISTRIBUTED DENIAL-OF-SERVICE ATTACKS 17

2.3.4 DNS Amplification Attack

According to VeriSign’s 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 victim’s 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
CHAPTER 2. DISTRIBUTED DENIAL-OF-SERVICE ATTACKS 18

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 victim’s address to reflectors.
CHAPTER 2. DISTRIBUTED DENIAL-OF-SERVICE ATTACKS 19

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 DDoS

defense. In the next chapter, we summary those efforts related to our studies.
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
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.
CHAPTER 3. RELATED WORK 22

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 technique’s 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 increase

the 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.


CHAPTER 3. RELATED WORK 23

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 for

real-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.
CHAPTER 3. RELATED WORK 24

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, and

the 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. Mölsä 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
CHAPTER 3. RELATED WORK 25

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
CHAPTER 3. RELATED WORK 26

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 on

address 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


CHAPTER 3. RELATED WORK 27

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 the

maximum 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
CHAPTER 3. RELATED WORK 28

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. Mölsä

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 flow’s reputation

will 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
CHAPTER 3. RELATED WORK 29

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 directly

connected 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 victim’s 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,
CHAPTER 3. RELATED WORK 30

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


CHAPTER 3. RELATED WORK 31

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
CHAPTER 3. RELATED WORK 32

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
CHAPTER 3. RELATED WORK 33

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 transmission

of 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
CHAPTER 3. RELATED WORK 34

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 traffic

into 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
CHAPTER 3. RELATED WORK 35

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 is

still 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.


CHAPTER 3. RELATED WORK 36

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 Yaar’s [15] explanation. Finally, spoofing

attacks 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
CHAPTER 3. RELATED WORK 37

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 DefCOM’s 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


CHAPTER 3. RELATED WORK 38

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 COSSACK’s
CHAPTER 3. RELATED WORK 39

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 damage

for 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
CHAPTER 3. RELATED WORK 40

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 victim to a source-end defense system. The procedure is very time
consuming. In contrast, our framework can directly send alert messages to source-end

defense systems because we use the FIT technique. The FIT technique can directly
find the attack sources after analyzing attack traffic received at the victim. “Pushback
is considered one of most promising techniques to defend against DDoS attacks” [70].

Therefore, we compare our framework with the pushback technique in this thesis.

3.4 Summary

Existing DDoS detection techniques are mainly categorized into two types: DDoS

detection based on analysis of IP attributes and DDoS detection based on traffic

volume. The problems in current detection techniques are as follows:


1. The weak connections between selected attributes and DDoS attacks make
CHAPTER 3. RELATED WORK 41

the detection schemes ineffective.


2. The time to reveal the anomalous conditions is too long due to complex

computations.
To respond to a DDoS attack, packet filtering tries to filter out attack traffic
based on DDoS attack signatures. However, it is hard to get attack signatures for

current DDoS attacks because attack traffic is similar to normal traffic. Another

problem with packet filtering techniques is collateral damage for legitimate traffic.

In contrast, recent studies show that rate limit techniques can mitigate an attack
effectively by setting up fitting rate limits on attack traffic. At the same time, it will
not lead to serious collateral damage for legitimate traffic.

After analyzing existing frameworks, we have found three types of DDoS frame-

works: victim-end defense frameworks, source-end defense frameworks, and distributed


defense frameworks. It is too late for victim-end defense frameworks to respond to
DDoS attacks. A source-end defense framework cannot achieve good performance

due to lack of attack information. In contrast, a distributed framework can achieve


better performance by cooperating among distributed multiple defense subsystems.
A number of studies show that distributed DoS problem indeed needs a distributed

solution.

In the next chapter, we will present in detail our proposed distance-based DDoS
defense framework.
Chapter 4

Distance-based DDoS Defense


Framework

In this chapter, we present our distance-based DDoS defense framework. The con-
ceptual architecture and the operation of the distance-based DDoS defense system
are introduced in Section 4.1. Section 4.2 introduces an approach to calculate the

distance value of a packet based on a single bit field in the IP identification field
and two different distance-based DDoS detection techniques. Section 4.3 describes an
approach to find the source-end edge routers. Finally, we propose a distance-based
rate limit mechanism in Section 4.4.

4.1 Overview of Defense Framework

The current network systems can simply be divided into two domains. The first

domain is the core network. A core network usually consists of high-speed core

routers. It is the backbone network which is in charge of transferring traffic among

42
CHAPTER 4. DISTANCE-BASED DEFENSE FRAMEWORK 43

Figure 4.1: Distance-based distributed DDoS defense framework


CHAPTER 4. DISTANCE-BASED DEFENSE FRAMEWORK 44

multiple edge networks. The edge network is another domain which connects to a core
network through edge routers. A edge network usually represents a single customer

network. Usually, there does not exist a huge volume of traffic which needs to be

forwarded by edge routers.


As Fig. 4.1 shows, our distance-based DDoS defense system is deployed in each

edge router of the protected network. While distributed denial of service (DDoS)

attack traffic is being transmitted across the network towards the victim, the defense

system in the victim-end edge network can easily detect the attack because attack
traffic creates a larger set of anomalies at the victim end than at the source ends. How-
ever, it is impossible for the defense system to react to the attacks in the victim-end

edge network when the attacks are heavy. As mentioned in Section 3.3.1, it is too late

to respond to attacks because incoming links are full of attack traffic. Therefore, we
propose to set up a second line of defense in the source-end edge networks to react to
the attacks. In our framework, the detection of and response to DDoS attacks happen

at edge routers. An edge router has enough resources because traffic is relatively lower
in the edge network. The distance-based DDoS detection techniques detect DDoS at-
tacks in the victim-end edge network by recognizing anomalous changes of average

distance values or traffic volumes. To drop attack packets effectively, a distance-based

attack traffic rate limit control will be triggered in the source-end edge network after

receiving an alert message from the defense system of the victim-end edge network.

To find all source-end edge networks, we use the Fast Internet Traceback (FIT) tech-

nique [15]. In the distributed framework, all edge routers should mark the distance
from the victim and their IP address into the 16 bit IP identification field of the IP

header. The distance-based detection and response techniques and the FIT technique
CHAPTER 4. DISTANCE-BASED DEFENSE FRAMEWORK 45

Figure 4.2: Illustration of distance-based distributed DDoS defense operation

will use this information.

Fig. 4.2 illustrates the whole operation of defending in the event of a DDoS attack.

Alert messages between a victim end and a source end include three types: Request
messages, Update messages, and Cancel messages. These messages are used in dif-

ferent phases of defeating a DDoS attack. At the beginning of an attack, a request

message from a victim end will provide a suggested rate limit value to a source end. If
the volume of attack traffic still increases aggressively, an update message will be sent
CHAPTER 4. DISTANCE-BASED DEFENSE FRAMEWORK 46

Figure 4.3: Conceptual architecture of the defense system

to the source end again. Based on the requirements in the message, the source-end
defense system will decrease the rate limit value exponentially. After the traffic at the
victim end has returned to normal for a while, an update message sent to the source

end asks it to increase the rate limit value linearly. Finally, if the defense system
has not found any anomalous changes in the victim end since the update message, a
cancel message to remove the rate limit at the source end is sent.

The internal conceptual architecture of a distance-based defense system is illus-

trated in Fig. 4.3. As previously mentioned, it is structured into three components:


a distance-based DDoS detection component, a remote routers traceback component,

and a traffic control component. After analyzing the information (the separated

traffic rates, the average distance values) from a victim edge router (Router 2), the
CHAPTER 4. DISTANCE-BASED DEFENSE FRAMEWORK 47

detection component will report the ongoing DDoS attack to the traceback compo-
nent. The traceback component implements the FIT technique. By grouping enough

packets from the source edge router (Router 1), the traceback component will get the

IP address of Router 1. Finally, the traffic control component sends an alert message
which carries attack traffic information and rate limits to the source-end defense sys-

tem. Based on this information, the traffic control components at the source end set

the rate limit for the traffic sent to victim in Router 2.

4.2 Detection Component

4.2.1 Calculating Distance Using a Single-Bit Field

Our distance metric calculates the number of hops which a packet has traversed from
one edge router to a victim. In [15], the FIT technique uses only 1 bit in the IP

Identification field to mark the distance as described below. In the IP protocol, the

IP Identification field is assigned by sender to help receiver assemble the fragmented


packets. Fig. 4.4 shows the place of the IP identification field in an IP protocol
header. Fig. 4.5 shows the FIT marking field in an IP identification field. b is the 1

bit distance filed in Fig. 4.5. Other two parts are used for carrying hash fragments of
a router address. Further explanations for these two parts are available in Section 4.3.

A TTL (Time to Live) is an 8-bit field to specify the maximum lifetime of an IP


packet. During transit, each router decrements the TTL value of an IP packet by

one. To get the correct distance at the victim end, the FIT technique separates the

work into two parts. First, a marking edge router sets the 5 least-significant bits of
CHAPTER 4. DISTANCE-BASED DEFENSE FRAMEWORK 48

Figure 4.4: IP header [83]

Figure 4.5: FIT marking field diagram. Frag# is the fragment number field. [15]

the packet’s TTL field to a global constant c. Furthermore, it stores the sixth bit of

the TTL in the first bit of the IP identification field. The FIT technique calls this
new, single-bit field the distance field. Second, an equation is used for calculating
distance when a packet arrives at the victim end. The equation is defined as follows:

d = (b|c − T T L[5..0] ) mod 64, (4.1)

where d is distance, b is distance field, and c is global constant. T T L[5..0] denotes

the six least significant bits of the TTL. b|c means concatenation of the values b and c.
Empirical investigations in [15] suggest that 22 is an appropriate value for the global

constant c. To show how it works, we give a simple example as follows. Assuming


that the initial TTL of an IP packet is 32, the marking router will change the TTL to

be 54 using the above marking method. At the same time, the marking mechanism
CHAPTER 4. DISTANCE-BASED DEFENSE FRAMEWORK 49

will set 1 to distance bit. After the packet goes through two hops, it reaches the
victim. The final TTL will be 52 while the result of b|c calculation is 54. Therefore,

the distance d calculated from the equation is 2, which is number of hops made by

the packet.

4.2.2 Average Distance Estimation DDoS Detection

The average distance estimation DDoS detection technique detects anomalous changes
of mean distance values based on the exponential smoothing estimation technique.
The exponential smoothing estimation technique predicts the mean value of distance

and the mean absolute deviation (MAD) value at the next time interval. Therefore,
we can provide a clear scope for a legal value at the next time interval. Any values
which are out of the legal scope can be thought as anomalous.

Estimating Mean Distance

Since we are dealing with a large volume of traffic, the applied techniques should not

require high computational time and space. The exponential smoothing estimation

technique is chosen because of its successful application in real-time measurement of


the round trip time of IP traffic [17]. The exponential smoothing estimation model

predicts the mean value of distance dt+1 at time t+1 using the following equation:

dt+1 = dt + w ∗ (Mt − dt ). (4.2)

Here, dt is the distance value at time t predicted at time t-1, Mt is the measured
distance value at time t, w is a smoothing gain (0 < w < 1), and Mt − dt is the error

in that prediction at time t. If w is higher, the latest prediction error has more weight

in determining the next distance value. As a result, the predicted values represent the
CHAPTER 4. DISTANCE-BASED DEFENSE FRAMEWORK 50

actual distance value fluctuations more closely. The model then reflects short-term
changes in the distance value. If w is relatively low, the model reflects long-term

changes of the distance value. By adjusting this parameter value, we can modify the

sensitivity of the prediction to the actual distance value fluctuations.

Estimating Mean Absolute Deviation (MAD)

To determine whether the current distance value is anomalous or not, mean absolute

deviation (MAD) can be utilized, given by


n
1 X
M AD = ∗ |et |, (4.3)
n t=1
where n is the number of all errors, and et is the prediction error at time t. However,

it is not realistic to maintain all past errors. Therefore, we use the exponential
smoothing technique to calculate MAD based on the approximation equation:

M ADt+1 = r ∗ |et | + (1 − r) ∗ M ADt , (4.4)

where M ADt is the MAD value at time t and r is a smoothing gain (0 < r < 1). In
a real application, the parameter r is configured manually.

Based on the predicted distance value dt+1 , M ADt , and a user input option thr,

the legal scope for real distance values at the next moment is defined as:

(dt+1 − thr ∗ M ADt ) <= Mt+1 <= (dt+1 + thr ∗ M ADt ), (4.5)

where thr is an adjustable threshold parameter to define the scope of the distance

values. If the real value at the next moment is out of the legal scope, an anomaly
situation is detected. Based on the above equation, high values of the parameter thr

will decrease the anomaly detection rate. In contrast, lower values of thr will increase

the false positive rate.


CHAPTER 4. DISTANCE-BASED DEFENSE FRAMEWORK 51

DDoS Detection Algorithm

For the sake of completeness, we provide pseudo code for the average distance esti-

mation DDoS detection algorithm. The symbols used in the algorithm are described
in Table 4.1. Attack traffic can block victims from their network in less than 14

seconds [32]. Therefore, the time interval of detection (γ) should be less than 14 sec-

onds. However, too short interval of detection may waste various resources. During a

time interval of detection, Lines 3-5 just collect distance information of each incoming

packet. Lines 8-9 calculate the real average value and the prediction error for this
interval. The prediction error is the difference between the real average value and the

predicted average value. The real average value is anomalous if it does satisfy the
condition presented in Line 10. Lines 12-13 calculate the predicted average (Eq. 4.2)
and deviation (Eq. 4.4) value for the next interval based on the current real average
value and the prediction error.

Table 4.1: Symbols used in the listing are


Parameters Description
p Packet
γ Time interval of detection
d Distance value
Avg Current average distance value
e Current prediction error
AvgP Predicted average distance value
M DP Predicted MAD value
C Collection
CHAPTER 4. DISTANCE-BASED DEFENSE FRAMEWORK 52

Listing 4.1 The pseudo-code of the average distance estimation DDoS detection
1 On receiving packet p;
2 Calculate the interval;
3 If (interval <γ) {
4 Put d of p into a collection C for this interval;
5 }
6 Else
7 {
8 Calculate Avg of C;
9 Calculate e;
10 If ((Avg >(AvgP + thr* M DP )) OR (Avg <(AvgP - thr* M DP )))
11 Set anomaly flag;
12 Calculate AvgP for the next γ;
13 Calculate M DP for the next γ;
14 }

4.2.3 Distance-Based Traffic Separation DDoS Detection

The distance-based traffic separation DDoS detection technique detects anomalous

changes of separated traffic rates based on the MMSE (Minimum Mean Square Er-

ror) linear estimation technique. As mentioned in Section 3.1.2, we separate traffic


based on distance values. The traditional DDoS detection techniques always focus
on detecting an attack from aggregate traffic. We think that these techniques cannot

detect trivial anomalous changes of traffic at the beginning of an attack. In contrast,

it is much easier to detect these anomalous changes using our traffic separation strat-
egy. In our proposed detection technique, the MMSE is used to predict the traffic
arrival rates of separated traffic on each distance value. The same MAD deviation

model as in the detection technique from the previous section defines the legal scope

for a traffic rate at any moment.


CHAPTER 4. DISTANCE-BASED DEFENSE FRAMEWORK 53

Estimating Arrival Rate

The MMSE technique is applied for separating traffic with different distance values.

Let Xt denote a linear stochastic process and assume that the next Xt+1 can be
expressed as a linear combination of the current and previous observations. It can be
described as a matrix so that

Xt+1 = W ∗ X T + εt , (4.6)

where W is the weight vector (wm , wm−1 , · · ·, w1 ), X = (Xt , Xt−1 , · · ·, Xt−m+1 ), εt is


the difference between Xt+1 and W ∗ X T , and m is the order of regression. The higher

the value of m is, the more accurate the computation is. The appropriate balance
point between computational complexity and accuracy can be determined through
experimentation. Let Ŵ denote the estimated weight vector; then the predicted

value X̂t+1 of Xt+1 can be expressed as:

X̂t+1 = Ŵ ∗ X T + εt . (4.7)

Moreover, an approximation approach called NMMSE (Normalized MMSE) [20] is

used to compute the weight vector Ŵ defined as follows:


X
Ŵt+1 = Ŵ + η ∗ ∗ et . (4.8)
||X||2
Here, ||X||2 = X T ∗X, and η is an adaptation constant. η determines the convergence

speed and is usually assigned a value within the range 0 < η < 2.

Estimating Deviation

We use the previously designed MAD-based deviation model as average distance

estimation technique. Therefore, the legal scope of Xt+1 is

(X̂t+1 − thr ∗ M ADt ) <= Xt+1 <= (X̂t+1 + thr ∗ M ADt ), (4.9)
CHAPTER 4. DISTANCE-BASED DEFENSE FRAMEWORK 54

DDoS Detection Algorithm

To summarize, we present the pseudo code of the distance-based traffic separation

DDoS detection algorithm in Listing 4.2. The symbols used in Listing 4.2 are designed
in Table 4.2. During a time interval of detection, Lines 3-5 just collect information
of incoming traffic. In Lines 8-19, we calculate the real traffic rate and deviation for

each separated traffic based on distance d. The deviation is the difference between
the real traffic rate and the predicted traffic rate. Then we decide whether the real

traffic volume is anomaly or not based on the condition presented at Line 13. Finally,

Lines 16-17 calculate the predicted traffic rate (Eq. 4.8 and Eq. 4.7) and deviation
(Eq. 4.4) for next time interval of detection.

Table 4.2: Symbols used in the distance-based traffic separation DDoS detection al-
gorithm
Parameters Description
p Packet
γ Time interval of detection
d Distance value
Rd Current arrival rate from distance d
Md Current MAD of arrival rate prediction from distance d
RPd Predicted arrival rate from distance d
M Pd Predicted MAD from distance d
CHAPTER 4. DISTANCE-BASED DEFENSE FRAMEWORK 55

Listing 4.2 The pseudo-code of the distance-based traffic separation DDoS detection
1 On receiving packet p;
2 If (interval <γ) {
3 For (each d) {
4 Collect information of incoming traffic from distance d;
5 }
6 }
7 Else
8 {
9 For (each d) {
10 Calculate Rd ;
11 Calculate Md ;
12 For (each d) {
13 If ((Rd >(RPd + thr* M Pd )) OR (Rd <(RPd - thr* M Pd )))
14 Set anomaly flag;
15 }
16 Calculate RPd for the next γ;
17 Calculate M Pd for the next γ;
18 }
19 }

4.2.4 Integration of Two Detection Techniques

We propose two distance-based DDoS detection techniques. They work together

in the following way. The average distance estimation technique detect an attack

based on estimating average distance values. It is a quick detector because it uses


efficient distance estimation technique. However, it cannot help the victim to separate
potential attack traffic from the whole traffic. Therefore, it cannot provide further

information to help the victim response the attack. To separate traffic, we rely on the

distance-based traffic separation technique. This technique categorizes whole traffic


into a number of small groups based on distance values. Then, it decides whether

each group of traffic is anomalous or not. The response mechanism at the victim

will control each group of traffic whose rate is anomalous. To summarize the above

explanation, both distance-based detection techniques work independently to detect


CHAPTER 4. DISTANCE-BASED DEFENSE FRAMEWORK 56

an attack in our framework. The average distance estimation technique just works
as a quick DDoS detector, while the distance-based traffic separation technique can

separate traffic to help further responses to the attack.

4.3 Traceback Component

After the distance-based traffic separation technique finds a potential group of attack
traffic successfully, another important step is to find the source-end edge routers

which has forwarded that group of attack traffic. We use the FIT technique in the

framework. The FIT technique will find the IP addresses of all source-end edge routers
based on marked information in attack packets. In Section 4.2.1, we described how
the FIT technique marks the distance information into 1 bit of the IP Identification
field. To reconstruct the IP address, the FIT technique needs to put the edge router

IP address into the remaining bits of the IP identification field. The number of bits
left is 15 because the whole length of the IP identification field is 16 bits. Therefore, it
is impossible to store all 32 bits of the edge router IP address in one IP identification
field. The FIT technique pre-calculates a hash of edge router IP addresses and splits

the hash into n fragments of bf rag -bits each, where n is a global constant. How many
fragments the splitting operation can get depends on the hash algorithm used by a

special defense system. To summarize the above explanation, the FIT packet marking

mechanism divides the IP Identification field into three fields, as shown in Fig. 4.5.

The fragment number field is two bits allowing four distinct fragments. Therefore,

the marking edge router can divide the hash IP address into four fragments and store

them into four different IP packets in the hash fragment field (the remaining 13 bits).
In the framework, only edge routers need mark the packets. We do not add any
CHAPTER 4. DISTANCE-BASED DEFENSE FRAMEWORK 57

defense functions into core routers.


After marking, 16-bits of IP identification field carries enough information to

be used for finding a source-end edge router. At the victim-end edge network, the
distance-based traffic separation DDoS detection will detect anomalous traffic from
distance d. The proposed rate limit mechanism will work on those edge routers which

are d hops from the victim. Therefore, the next task of the FIT technique is to

reconstruct the IP addresses of these edge-routers. This task can be done based on

the fact that an endhost can group together packets that traverse the same path
during a TCP connection. After receiving enough marked packets from the same
distance d and TCP connection, a defense system at the victim-end edge network

concatenates the 4 pieces of hash fragments together, and then scans the hash table

to find out the real IP address of a source-end router.

4.4 Traffic Control Component

The purpose of the rate limit is to protect the victim-end edge network from the
situation that aggregated incoming traffic exceeds its capacity [26]. In the scenario

of a DDoS attack, the purpose of a rate limit is not only to lower the aggregated

traffic under the bottleneck link’s bandwidth, but also to decrease the percentage
that attack traffic represents of the whole of aggregated traffic. To control attack

traffic, we should set up the rate limit on the routers which are close to the attackers.

In the framework, the distance-based traffic separation DDoS detection technique

cooperates with the FIT technique to find the source-end edge routers. We propose

a distance-based Max-Min fair share rate limit algorithm to allocate the bandwidth
among all incoming traffic from the routers which are forwarding attack traffic. It is
CHAPTER 4. DISTANCE-BASED DEFENSE FRAMEWORK 58

not fair to penalize all routers at a distance equally by setting the same rate limit
for them. Therefore, the algorithm differentiates rate limits based on the packet drop

histories of individual routers. In the algorithm, the drop rate will affect the final the

value of rate limit for each router. The pseudo code of the algorithm is illustrated
in Listing 4.3. Lines 4 to 10 of the algorithm in Listing 1 check if current traffic

volume is greater than load limit of the bottleneck link. When the traffic volume is

greater than load limit and an attack is detected, Lines 6-8 exponentially decrement

the rate limits. When the traffic volume is found to be less than the load limit of
the bottleneck link, Lines 13-15 remove all existing rate limits if the change in traffic
volume is less than a constant small value ε. At this moment, we consider that the

attack has finished. Therefore, we remove the rate limits to allow legitimate traffic

fully utilize network resources. Lines 18-20 linearly increase the rate limits when
change in traffic volume exceeds ε but the traffic volume is still less than load limit
of the bottleneck link. Line 23 is a operation to keep the current traffic rate into

variable Rprv .

Table 4.3: Symbols used in the rate limit algorithm


Parameters Description
d Distance value
Us Load limit
RCv Current traffic rate at the victim end
RCi Current traffic rate at router i
RLi Rate limit for router i
Rprv Previous traffic rate at victim end
Rateinc Increase rate factor
hfi Drop rate for the router i
fdec Decrease rate factor
ε A configurable small constant
CHAPTER 4. DISTANCE-BASED DEFENSE FRAMEWORK 59

Listing 4.3 The pseudo-code of distance-based rate limit


1 While(1){
2 Send current rate limit information to source-end routers;
3 Monitor current traffic rate at the victim end;
4 If(RCv > Us ){
5 If(An attack is detected originating from distance d){
6 For(each router i at distance d){
7 RLi = RCi ∗ fdec ∗ (1 − hfi );
8 }
9 }
10 }
11 Else
12 {
13 If((RCv − Rprv ) < ε){
14 Remove all rate limits;
15 }
16 Else
17 {
18 For(each router i which has rate limits){
19 RLi = RCi + Rateinc ∗ (1 − hfi );
20 }
21 }
22 }
23 Rprv = RCv ;
24 }

Basically, the distance-based rate limit algorithm includes two phases during the
defeat of a DDoS attack. At the early stage of an attack (the first phase) the al-
gorithm exponentially decreases the traffic sending rate from the source-end routers.

The sending rates of the source-end routers are restricted according to the following
formula.

RLi = RCi ∗ fdec ∗ (1 − hfi ). (4.10)

The size of the fraction is specified by the configuration parameter fdec . hfi is a
CHAPTER 4. DISTANCE-BASED DEFENSE FRAMEWORK 60

parameter which reflects the drop rate of traffic at a source-end router i. We can
calculate the hfi for the router i based on the following equation.

Droppedi
hfi = ; (4.11)
Senti + Droppedi
Senti is the byte amount of flow traffic forwarded to the victim from router i, and
Droppedi is the byte amount of flow traffic dropped from router i. According to the

above equation for the calculation of rate limits, more aggressive attack traffic can be

penalized by a relatively lower rate limit value because the hfi of the attack traffic is
higher. In general, fast exponential decrease of the sending rates attempts to quickly

lessen the impact of an attack on the victim.

The second phase is called recovery phase. It happens after the victim thinks that
the attack is at an end. However, it may not be true because it is highly possible that
a DDoS attack itself may happen periodically. Like IP traffic control, the speed of
recovery is slow at the early stage of the recovery phase. The sending rate for router

i is increased linearly as follows:

RLi = RCi + Rateinc ∗ (1 − hfi ). (4.12)

Here, Rateinc is a configuration parameter and hfi is as defined above. Moreover,


the drop rate also affects the speed of recovery too. After detecting that the traffic is

stable enough at the victim end, the last step of the recovery phase will remove rate
limit at all source-end routers. This lets routers serve legitimate traffic fully.
CHAPTER 4. DISTANCE-BASED DEFENSE FRAMEWORK 61

4.5 Summary

We introduce our novel distance-based distributed DDoS defense framework. In the


framework, both source-end and victim-end defense systems cooperate with each

other in order to detect and respond to DDoS attacks effectively. At the victim
end, we propose two distance-based DDoS detection techniques to detect an attack

by observing anomalous changes of average distance values and separated traffic rates.

After the attack has been detected, the traceback component at the victim-end defense

system analyzes the attack traffic to find the addresses of remote routers forwarding
attack traffic. An alert message will be sent to the source-end defense systems which
are in charge of these routers. Instead of traditional traffic filtering, we propose
distance-based rate limiting to control attack traffic from these source-end routers.

In the next chapter, we evaluate the framework on the NS2 simulator by using

six proposed metrics on three layers. Moreover, we demonstrate that the framework

improves on the pushback technique when it comes to defeating DDoS attacks.


Chapter 5

Experiments and Results

In this chapter, we first examine and evaluate the distance-based DDoS detection
technique presented in the last chapter. More experiments are then set up to evaluate
the whole distance-based DDoS defense framework. The results of the framework

evaluation are compared with the results from the pushback technique [30].

This chapter is organized as follows: At the beginning, Section 5.1 illustrates


the pushback technique from an implementation point of view. In Section 5.2, we
introduce simulations based on Internet traffic and topology approximation techniques
and define the metrics to measure detection and defense performance. Section 5.3

presents the evaluation of distance-based detection techniques. Finally, we evaluate

the performance of distance-based DDoS defense in Section 5.4 which also contain

a direct comparison between the distance-based DDoS defense framework and the
pushback technique.

62
CHAPTER 5. EXPERIMENTS AND RESULTS 63

Figure 5.1: A DDoS attack in progress [79]

5.1 Overview of the Pushback Technique

The pushback technique mitigates a DDoS attack by identifying aggregated traffic

responsible for congestion, and preferably dropping that traffic at the routers [79]. To
illustrate the operation of the pushback technique under a DDoS attack, we consider

the network in Fig. 5.1 as the one which supports the pushback technique. The server
V is the victim of an ongoing DDoS attack. The thick lines show the links for attack

traffic flow. In contrast, the thin lines mean the links are in normal status. Especially,

the last link between router R 8 and the victim V is the bottleneck link which is

congested by attack traffic. In this situation, the local aggregate congestion control

(ACC) at router R 8 detects incoming aggregated traffic. R 8 therefore immediately


starts to drop packets belonging to the aggregated traffic. Because there are more

than one aggregated traffic flows from different links, the pushback technique punishes
CHAPTER 5. EXPERIMENTS AND RESULTS 64

them equally. Moreover, the router R 8 will attempt to cooperate with its upstream
routers (R 5 and R 6) by sending pushback messages to them if the ongoing congestion

is still severe. In fact, the operation can be recursive. This means that router R 5 or
R 6 will send pushback messages to their upstream routers. The recursive operation
will not end until congestion of the whole network is relieved. As mentioned in

Section 3.3.3, collateral damage for legitimate traffic is a issue which the pushback

technique cannot avoid.


In our evaluation, we run simulations of the pushback technique which have the
same attack ratio between attack and legitimate nodes, traffic features, and topologies

of the networks as the simulations of distance-based defense. The results are directly

compared with each other based on six metrics.

5.2 Simulation Setup

The cost of building a real distributed testing defense environment is high. Simulation
is an important method in network research, as simulations can be used to analyze
network-related problems under different protocols, cross traffic, and topologies with

much less cost [71]. Perhaps, the most well known network simulator is NS2 [7].
Therefore, we use NS2 simulator to evaluate our proposed detection techniques and
the defense framework. NS2 is a widely recognized packet level discrete event simula-

tor. It is implemented in C++ to support fast and relatively large scale simulations.

To allow easy and flexible configuration, NS2 supports configuration scripts written in

the TCL language. A user can use simple TCL scripts to construct a complex network

environment without engaging in C++ programming. Another important feature of


NS2 is that it is extensible. Therefore, users can add and modify the simulator to
CHAPTER 5. EXPERIMENTS AND RESULTS 65

support new features in their experiments.


In the literature, NS2 is widely used for performance evaluation. Q. Li et al. [71]

think that NS2 is good at the simulation of large-scale DDoS attacks and suitable for
research on IP traceback after they evaluated a number of IP traceback techniques on
NS2. Y.-K. Kwok et al. use NS2 to evaluate a distributed DDoS pushback framework.

They add two new classes into NS2 to support complex data statistical operations.

C. Sangpachatanaruk et al. [72] modify NS2 to support the new TCP features used in

their DDoS mitigation solution. In addition, they create a FTP application on NS2
to demonstrate the effectiveness of their solution. In [50], Y.-H. Hu et al. evaluate
a proposed window-based packet filtering scheme implemented in NS2 as a new type

of queue management. Y. Chen et al. demonstrate the effects of a proposed collab-

orative DDoS detection schemes on NS2. During evaluation, they create a simulated
network with a same topology as a real ISP network. F. Lau et al. [73] analyze the
influence for various current queue management schemes based on NS2 simulations.

In [27] and [28], NS2 is used to evaluate two distributed DDoS defense frameworks.
According to a number of NS2 simulations in [44], J. Mölsä reaches a conclusion
that a rate-limiting mechanism can be used as a fast, automatic response mechanism

to defeat flooding DDoS attacks. J. Kong et al. [21] analyze the effects of different

flooding DDoS defense mechanisms based on a random flow model implemented on

NS2. To summarize, NS2 has been demonstrated as a good simulator to use in the

evaluation of DDoS detection, IP traceback, and mitigation techniques. Therefore,

we think NS2 is relatively good platform to evaluate our proposed distance-based


DDoS defense framework.

To achieve more realistic simulation results, Kong et al. [21] suggest that the
CHAPTER 5. EXPERIMENTS AND RESULTS 66

simulation should include two aspects: an Internet-like topology approximation and


an Internet-like traffic approximation. To set up a satisfactory simulation, we should

consider three factors: topology, legal background traffic, and attack traffic.

In all experiments, we create HTTP traffic which is a typical traffic in the current
Internet network using the Web cache model. We randomly generate a network

consisted of intermediate routers and HTTP clients. A group of server hosts are

connected to these routers. In each simulation scenario, the number of regular clients

is defined to be a percentage of all the HTTP clients.

5.2.1 Simulating Internet Topology

Based on extensive data analyses and studies, Faloutsos et al. [22] discover some
surprisingly simple power laws of the Internet topology. Though Internet topology
approximation is still an open question, there exist several topology generators which

match very well with the real Internet based on power laws (e.g., Inet, Brite, etc.). We
use the Inet software package [23] to generate two Internet-like topologies used in our
experiments testing the distance-based detection and distributed defense framework.

Topology for Detection Evaluation

In the simulation network, 20 routers randomly connect with each other. Among

the 100 clients, 60% of them are normal HTTP clients and the remaining nodes

are DDoS attackers. The rest of them 40% are attacker nodes which are chosen
randomly [21]. It simulates a real situation that DDoS attack traffic usually comes

from many attackers. Of course, we also perform the experiments for different ratios
between attackers and normal clients. In the server pool, 20 Web server nodes are
CHAPTER 5. EXPERIMENTS AND RESULTS 67

generated. An aggregate traffic bottleneck link exists between the Web server pool
and the others. The bandwidth is set as 10Mbps for all links. Our detection system

monitors the bottleneck link to detect anomalous changes of the mean distance value

and the traffic arrival rate from different distances.

Topology for Framework Evaluation

In the simulation network, 120 nodes randomly connect with each other. The band-

width of all links is 10Mbps and the delay of each link is set randomly. Without

losing generality, only two servers exist in the server pool in order to easily produce

statistical data. One of them is the victim. Moreover, there is a bottleneck link
between the server pool and other parts of this simulated network too. Among the

120 nodes, the ratio between normal and malicious HTTP clients is adjusted in a
number of experiments. Different ratios have no significant influence on the results of
the evaluation after we analyze the results. Therefore, we just show the results based
on the ratios (9:1) and (5:5), and only one attacker in this chapter.

5.2.2 Simulating Internet Data Traffic

In our two types of experiments, HTTP traffic needs to be created as legitimate

traffic on our simulation network. Among several Web traffic models of NS2, the Web

caching model matches real traffic produced by Web application very well, modeling

the behaviors of Web browsers and Web servers. In simulations, a Web client node
randomly generates a sequence of page requests. A number of Web server nodes

connect with the page pool and wait for any incoming requests. The page pool models
traffic features based on extensive analyses of real Internet Web page request traffic.
CHAPTER 5. EXPERIMENTS AND RESULTS 68

The NS2 page pool generates all page information that includes statistical traffic
features (page size, page life time, etc.). The Pareto model is relatively accurate

representation of Internet traffic [21]. Research has discovered that Pareto model

with shape parameter α ∈ [1..2] is a relatively accurate representation of Internet


traffic [21].

HTTP Traffic for Detection Evaluation

In simulations, normal HTTP clients create 50 sessions and follow the Pareto model [25]

with Pareto shape parameter α 1.4 in HTTP data transmission.

HTTP Traffic for Framework Evaluation

In simulations, normal HTTP clients create 10,000 sessions with the same Pareto
shape parameter α 1.4.

5.2.3 Simulating Attack Traffic

The attacker nodes do not follow any statistical distribution and congestion control

schemes. They pump as much traffic as possible until the attack traffic overwhelms

the targeted HTTP servers. A simple simulation of attack traffic can be achieved by

randomly generating many pairs of Constant Bit Rate (CBR) UDP flows in NS2 [21].

Attack Traffic for Detection Evaluation

For the evaluation of detection, UDP flooding attacks will happen 10 times in each

experiment. Each attack lasts 10 seconds. The interval between attacks is 40 seconds.
CHAPTER 5. EXPERIMENTS AND RESULTS 69

The first attack will be triggered in the first 100 seconds after the experiment is
started.

Attack Traffic for Framework Evaluation

We create a UDP attack which lasts long enough to test performance of our framework
in attack traffic control. For the evaluation of the framework, UDP flooding attacks

will happen once in each experiment. It is triggered in the first 60 seconds and lasts

50 seconds in order to monitor traffic control behaviors and collect data in three

situations as follows:

1. the situation in which both the distance-based DDoS defense framework and

the pushback technique are not enabled;


2. the situation in which only the pushback technique has been enabled; and
3. the situation in which only the distance-based DDoS defense framework has
been enabled.

5.2.4 Performance Metrics

Common performance measures of intrusion detection techniques are detection rate,

false positive rate, and the ratio between these two. In our detection evaluation, we
adopt these metrics for the same purposes. Nevertheless, there exist no group of stan-

dard measurements for the evaluation of a DDoS defense system. In the literature,

“individual research efforts and commercial products utilize a variety of metrics to


measure and assesses the results of their respective techniques, products and technolo-

gies” [74]. In developing our approach to evaluate our distance-based DDoS defense

framework, we define the metrics from different levels of abstraction. Based on the
CHAPTER 5. EXPERIMENTS AND RESULTS 70

suggestions in [76], two metrics at the application level are defined to indicate whether
normal HTTP traffic receives an acceptable level of service or not. Metrics at the two

other levels reflect the performance at relatively lower levels: aggregate and packet

level.

Metrics for Detection Evaluation

To evaluate the performance of our two distance-based DDoS detection techniques,

two metrics (detection rate and false positive rate) are used. The detection rate is

the ratio of the number of detected attacks to the number of actual attacks. The false

positive rate measures the ratio between the number of normal traffic events being
wrongly detected as attacks and the total number of normal traffic events.

Metrics for Framework Evaluation

On three levels, we define six metrics. For the purposes of our explanation, an HTTP
transaction means the whole HTTP process including an HTTP Request message

from a client and an HTTP Response message from a server.

1. Application Level

Failure Rate of HTTP Transaction: An HTTP transaction is a failure when the


client has not received any response messages from the server within 10 seconds [75].

The failure rate is the ratio of the number of failed HTTP transactions to successful

HTTP transactions.

Average Latency of HTTP Transaction: The latency of an HTTP transaction


means the delay between sending the HTTP Request and receiving the HTTP Re-

sponse. The average latency is an average value of all successful HTTP transactions.
CHAPTER 5. EXPERIMENTS AND RESULTS 71

2. Aggregate Level
Throughput of Normal HTTP Traffic: In communication networks, throughput

is the total number of bits transmitted within a given amount of time [82]. The
general throughput of all legitimate traffic reflects the performance of our distance-
based attack traffic control directly.

Bandwidth of Normal HTTP Traffic: In communication networks, Bandwidth

denotes the amount of data a link can carry [82]. This is a metric which directly

reflects the allocation of bandwidth in the three situations.


3. Packet Level

Attack Packet Drop Rate: The defense framework attempts to lower the amount

of attack traffic in order to protect the bandwidth by dropping as many attack packets

as possible. The attack drop rate is the ratio of the number of dropped attack packets
to the number of total attack packets in a network. Therefore, the attack packet drop
rate represents the ability of the framework to perform attack traffic control.

Legitimate Packet Drop Rate: The goal of the framework is to maintain QoS for
legitimate traffic when attacks happen. It does its best to protect the bandwidth from
congestion due to attacks in order to forward as many legitimate packets as possible.
The legitimate packet drop rate is the ratio of the number of dropped legitimate

packets to the number of total legitimate packets in the network.

5.3 Detection Performance

In this section, we first discuss the general rules to adjust the parameters in our

two distance-based detection techniques. Then we present the results for the aver-
age distance estimation DDoS detection and distance-based traffic separation DDoS
CHAPTER 5. EXPERIMENTS AND RESULTS 72

detection technique individually.

5.3.1 Adjustment of Parameters

The two detection algorithms work based on a number of parameters. The perfor-

mance of the techniques rely on choosing appropriate parameters for a specific victim
network. In general, there exist a few rules to help adjust the parameters. We can

separate the changes of traffic into two cases when attacks happen. For the first case,

traffic rate varies very slowly. For the second case, we observe that traffic rate changes
very fast. When the first case happens, we should choose relatively higher values of

the parameters r in the average distance estimation DDoS detection technique and
η in the traffic separation DDoS detection technique, and lower the parameter thr
for both techniques. In contrast, relatively lower values for parameters r and η, and
higher thr should be chosen under the second case.

In a real deployment, we should adjust these parameters based on legitimate traffic


data collected from the victim. Legitimate traffic data should not be collected when
the victim is being attacked. We do not use the previous general rules to adjust
these parameters of the two detection techniques until the number of false positive

detection results is 0 or very small.

5.3.2 Results: Average Distance Estimation DDoS Detection

The average distance estimation detection technique works on the variation of the

average distance values. In Fig. 5.2, we present the traffic as it evolves, as well as

the dynamic upper and lower thresholds. As can be seen in Fig. 5.2, the average
distance value changes when an attack is triggered at time index 100s. Obviously,
CHAPTER 5. EXPERIMENTS AND RESULTS 73

3.5
Real Distance
Upper Threshold
3
Lower Threshold

2.5
Average Distance Value

1.5

0.5

0
99.6 99.7 99.8 99.9 100 100.1 100.2
Time Index (second)

Figure 5.2: DDoS detection based on average distance estimation when thr = 7.0,
w = 0.7, and r = 0.5
CHAPTER 5. EXPERIMENTS AND RESULTS 74

Table 5.1: Performance of The Average Distance Estimation DDoS Detection


thr w r Detection Rate False Positive
5.0 0.08 0.08 1 0.0023
5.5 0.08 0.08 0.9 0.0023
6.0 0.08 0.08 0.5 0.0018
7.0 0.08 0.08 0.2 0.0010
5.0 0.5 0.7 1 0.0360
5.5 0.5 0.7 1 0.0343
6.0 0.5 0.7 1 0.0332
7.0 0.5 0.7 1 0.0179

the average estimation detection technique detects the anomalous values around time

100.1s that cross the dynamic upper thresholds. Some chosen experimental results
shown in Table 5.1 indicate that the detection technique can effectively detect attacks
with a high detection rate and a low false positive rate when the parameters thr, w,

and r are optimized. To directly display the relationship between the false positive
rate and the detection rate, we use Receiver Operation Characteristic (ROC) curves.

To draw a better ROC curve, we do not only use results in Table 5.1 but also other
results which are not shown in Table 5.1. Fig. 5.3 shows that the average estimation
DDoS detection technique detects all the attacks with a false positive rate of less than

0.4%.

5.3.3 Results: Distance-based Traffic Separation DDoS De-

tection

We set the threshold thr = 10 and the smoothing gain r = 0.4 and observed detection
rates equal to 1 for all the experiments. Therefore, our analysis just concentrates on

the false positive rates. In Fig. 5.4, we present separated traffic with distance = 2 as it
CHAPTER 5. EXPERIMENTS AND RESULTS 75

1.5

w=0.08, r=0.08
w=0.7, r=0.5

1
Detection Rate

0.5

0
0 0.02 0.04 0.06 0.08 0.1 0.12
False Positive Rate

Figure 5.3: ROC curves of the average distance estimation DDoS detection technique

800
Real Traffic
Upper Threshold
600 Lower Threshold
Traffic Intensity (packet/sec)

400

200

−200

−400
99.7 99.8 99.9 100 100.1 100.2 100.3 100.4 100.5
Time Index (second)

Figure 5.4: DDoS detection based on the traffic separation for distance = 2
CHAPTER 5. EXPERIMENTS AND RESULTS 76

Table 5.2: Performance of The Distance-based Traffic Separation DDoS Detection


η m thr r Detection Rate False Positive
0.1 6 10 0.4 1 0.0042
0.01 6 10 0.4 1 0.0044
0.001 6 10 0.4 1 0.0044
0.0001 6 10 0.4 1 0.0043
0.001 3 10 0.4 1 0.0083
0.001 5 10 0.4 1 0.0043
0.001 10 10 0.4 1 0.0045
0.001 16 10 0.4 1 0.0046

evolves, as well as the dynamic upper and lower thresholds when parameters η = 0.001

and m = 6. The figure shows that the technique succeeds in detecting the anomalous
traffic rates that are over the dynamic upper thresholds. More experimental results
are provided in Table 5.2.

The false positive rates are very low for all the experiments (less than 0.009). It
can detect all the DDoS attacks without increasing the false positive rate significantly.

5.4 Defense Performance

In this section, we present the results of defense performance evaluating our distance-
based distributed DDoS framework. To demonstrate the improvements of the frame-
work in defeating DDoS attacks, we compare results in three situations. In the first

situation, we start the attack on NS2 simulation network without enabling any DDoS
defense mechanisms. The edge router at the victim end just drops all packets which

it cannot handle. In the second situation, we deploy the pushback technique in the

NS2 simulation network. Each router will detect the aggregate of its local traffic and

attempt to lower traffic in cooperation with upstream routers. In the final situation,
CHAPTER 5. EXPERIMENTS AND RESULTS 77

Table 5.3: Average Latency of HTTP Transactions


(a) Average Latency of HTTP Transactions with Ratio (9:1)
Situations Avg Latency Before Attack Avg Latency During Attack
No defense 1.685 7.7412
Pushback 2.023 2.495
Distance-based framework 1.8512 2.2377
(b) Average Latency of HTTP Transactions with Ratio (5:5)
Situations Avg Latency Before Attack Avg Latency During Attack
No defense 1.778 6.290
Pushback 1.867 3.307
Distance-based framework 1.747 2.1663
(c) Average Latency of HTTP Transactions with only 1 attacker
Situations Avg Latency Before Attack Avg Latency During Attack
No defense 1.202 7.168
Pushback 1.2852 2.292
Distance-based framework 1.411 2.034

we deploy the distance-based DDoS defense framework in the same NS2 simulation
network. The edge router at the victim end has the ability to detect the DDoS at-
tacks. Edge routers lower the sending rate after receiving the alert messages from the

victim end. Six metrics are used to measure the effects in these three situations, com-
paring our approach both with the control situation where there is no DDoS defense
and with the pushback technique.

5.4.1 Average Latency of HTTP Transactions

Each application has its own quality of service needs. For HTTP applications, one

need is to minimize the delay to finish an HTTP transaction. According to research


in [75], an HTTP transaction is considered a successful one if the overall transac-

tion completes in less than 10 seconds. Therefore, we calculate the average latency
CHAPTER 5. EXPERIMENTS AND RESULTS 78

based on HTTP transactions which finish in 10 seconds. The results are presented in
Tables 5.3(a), 5.3(b), and 5.3(c).

According to the three tables, the average latency is increased almost 5 times
during the attack compare to one before the attack when no defense is activated. This
demonstrates that current networks cannot prevent the QoS from going down if there

is no effective DDoS defense system. For the second situation, the pushback technique

significantly improves the QoS of the HTTP application. The differences between

average latencies before and after the attack are small in all three tables. This denotes
that attack traffic does not greatly affect the latency of HTTP transactions in case
of the pushback technique. In the last situation, the results show that distance-based

framework has even better performance than the pushback technique. The average

latencies of the framework during the attack are lower than that of the pushback
technique in all three tables. Moreover, the differences between average latencies
before and after the attack in the framework are smaller than them in the pushback

technique too.

5.4.2 Failure Rate of HTTP Transaction

The failure rates are presented in Table 5.4(a), 5.4(b), and 5.4(c). For the network

without deployment of any DDoS defense systems, failed HTTP transactions are
greatly larger than successful HTTP transactions during the attack. This is why the

rate values are greatly higher than 1. For the other two situations, the rate values
are greatly lower than 1. This means that both the pushback technique and the

distance-based framework work well to make sure most of HTTP transactions can be

accomplished in less than 10 seconds. It is worth mentioning that the failure rates in
CHAPTER 5. EXPERIMENTS AND RESULTS 79

Table 5.4: Failure Rates of HTTP Transactions


(a) Failure Rates of HTTP Transactions with Ratio (9:1)
Situations Fail Rate Before Attack Fail Rate During Attack
No defense 0.073 17.8
Pushback 0.072 0.0349
Distance-based framework 0.0512 0.0297
(b) Failure Rates of HTTP Transactions with Ratio (5:5)
Situations Fail Rate Before Attack Fail Rate During Attack
No defense 0.0582 2.2162
Pushback 0.042 0.1174
Distance-based framework 0.0571 0.0361
(c) Failure Rates of HTTP Transactions with only 1 attacker
Situations Fail Rate Before Attack Fail Rate During Attack
No defense 0.0252 7.5
Pushback 0.0282 0.0217
Distance-based framework 0.0756 0.0037

the distance-based framework are even lower than ones in the pushback technique.

5.4.3 Throughput of Legitimate Traffic

During a DDoS attack, attack traffic fills the bottleneck link in order to force the
edge router at the victim end to drop most legitimate packets. In the following

explanations, we just concentrate on the attack period which is started at 60s and

stopped at 110s. The throughput figure is used by us to show the performance


of a DDoS detection technique during the attack period. Figs. 5.5, 5.8, and 5.11

demonstrate their ability to detect DDoS attacks.

The throughput of attack traffic is very high while the throughput of legitimate

traffic is very low during the attack. The pushback technique shows good performance
in protecting legitimate traffic in three figures. However, it seems to make no effort
CHAPTER 5. EXPERIMENTS AND RESULTS 80

250

200
Throughput (Kbps)

150

100

Attack Traffic
Legitimate Traffic
50

0
50 60 70 80 90 100 110 120
Time (seconds)

Figure 5.5: No DDoS defense with ratio (9:1)


250

200
Throughput (Kbps)

150

100

Attack Traffic
Legitimate Traffic
50

0
50 60 70 80 90 100 110 120
Time (seconds)

Figure 5.6: Pushback with ratio (9:1)


250

200
Throughput (Kbps)

150

100

Attack Traffic
Legitimate Traffic
50

0
50 60 70 80 90 100 110 120
Time (seconds)

Figure 5.7: Distance-based DDoS defense with ratio (9:1)


CHAPTER 5. EXPERIMENTS AND RESULTS 81

250

200
Throughput (Kbps)

150

100

Attack Traffic
Legitimate Traffic
50

0
50 60 70 80 90 100 110 120
Time (seconds)

Figure 5.8: No DDoS defense with ratio (5:5)


250

200
Throughput (Kbps)

150

100

Attack Traffic
Legitimate Traffic
50

0
50 60 70 80 90 100 110 120
Time (seconds)

Figure 5.9: Pushback with ratio (5:5)


250
Attack Traffic
Legitimate Traffic
200
Throughput (Kbps)

150

100

50

0
50 60 70 80 90 100 110 120
Time (seconds)

Figure 5.10: Distance-based DDoS defense with ratio (5:5)


CHAPTER 5. EXPERIMENTS AND RESULTS 82

250

200
Throughput (Kbps)

150

100

Attack Traffic
Legitimate Traffic
50

0
50 60 70 80 90 100 110 120
Time (seconds)

Figure 5.11: No DDoS defense with 1 attacker


250

200
Throughput (Kbps)

150

100

Attack Traffic
Legitimate Traffic
50

0
50 60 70 80 90 100 110 120
Time (seconds)

Figure 5.12: Pushback with 1 attacker

250
Attack Traffic
Legitimate Traffic
200
Throughput (Kbps)

150

100

50

0
50 60 70 80 90 100 110 120
Time (seconds)

Figure 5.13: Distance-based DDoS defense with 1 attacker


CHAPTER 5. EXPERIMENTS AND RESULTS 83

to control attack traffic once the legitimate traffic has been served properly. The
reason is that the pushback technique lacks the ability to distinguish between attack

and legitimate traffic when a diffused DDoS attack happens [30]. Therefore, the

pushback technique attempts to forward as much traffic as possible in order to lower


the collateral damage for legitimate traffic.

Comparing the pushback technique with our distance-based DDoS defense frame-

work, the obvious difference is that the framework succeeds in lowering attack traffic

while maintaining QoS for legitimate traffic. This demonstrates that the distance-
based DDoS defense framework is able to differentiate between attack and legitimate
traffic. The distance-based rate limit mechanism penalizes routers with different

rate limit values. More aggressive attack traffic will be dropped more often because

source-end edge routers have a lower rate limit value. However, we found a minor
disadvantage in the distance-based rate limit mechanism during the process of traffic
recovery. In Fig. 5.7, 5.10 and 5.13, attack traffic recovers a couple of times. The phe-

nomenon happens because the distance-based rate limit mechanism tries to remove
the rate limit while an attack is still going. One of our future solutions is to let the
source-end defense systems control traffic recovery instead of the victim-end system.

This solution needs additional cooperation between source ends and the victim end.

In the experiments, the distance-based DDoS defense framework achieves even


better performance than the pushback technique. It successfully maintains QoS of

legitimate traffic by using the distance-based rate limit mechanism, while throttling

back the amount of attack traffic.


CHAPTER 5. EXPERIMENTS AND RESULTS 84

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

Figure 5.15: Bandwidth allocation at the congested link during a DDoS attack with
ratio (5:5)

Figure 5.16: Bandwidth allocation at the congested link during a DDoS attack with
1 attacker
CHAPTER 5. EXPERIMENTS AND RESULTS 85

5.4.4 Bandwidth Allocation of Traffic

In Fig. 5.14, 5.15, and 5.16, the ratio between attack and legitimate traffic bandwidth

are displayed. The fraction of attack traffic bandwidth is the value of attack traffic
bandwidth over sum of attack and legitimate traffic bandwidth. Basically, these
figures confirm the effectiveness of our distance-based DDoS defense framework in

controlling attack traffic.

5.4.5 Drop Rate of Attack Traffic

Table 5.5: Drop Rate of Attack Traffic


(a) Drop Rate of Attack Traffic with Ratio (9:1)
Situations DropRate
No defense 0.833
Pushback 0.841
Distance-based framework 0.974
(b) Drop Rate of Attack Traffic with Ratio (5:5)
Situations DropRate
No defense 0.538
Pushback 0.560
Distance-based framework 0.906
(c) Drop Rate of Attack Traffic with 1 attacker
Situations DropRate
No defense 0.747
Pushback 0.76
Distance-based framework 0.987

The drop rate of attack traffic has been used for the purpose of evaluating the

effectiveness of a DDoS defense system before [76]. However, J. Mirkovic et al. think
it fails to capture whether legitimate service continues during the attack [76]. For

example, even if all attack traffic can be dropped by the edge router at the victim end,
CHAPTER 5. EXPERIMENTS AND RESULTS 86

legitimate traffic may not be delivered properly simply because the edge router has
no resources left to serve it. In fact, the edge router might be completely busy just in

dropping attack traffic during the attack. In our experiments, we use the drop rate as

a metric of the packet level to evaluate the distributed DDoS defense system. If we can
demonstrate that the framework can effectively drop attack traffic at the source ends,

it indirectly demonstrates that the framework can sustain QoS for legitimate traffic at

the victim end. After we compare results in the three situations in Table 5.5(a), 5.5(b),

and 5.5(c), we find the distance-based DDoS defense framework drops most of the
attack traffic in edge routers at source end. In contrast, in the network without DDoS
defense, attack traffic is only dropped in the edge router at the victim end due to a

lack of resources. This shows that the normal congestion control mechanism cannot

protect QoS for legitimate traffic from going down. Pushback drops attack traffic at
upstream routers. However, its drop rate is almost the same as the previous situation.
The reason is its lack of ability to differentiate between legitimate and attack traffic

in a DDoS attack, and the consequent decision to throttle attack traffic just enough
to maintain QoS for legitimate traffic.

5.4.6 Drop Rate of Legitimate Traffic

The drop rate of legitimate traffic is a direct metric which reflects the collateral
damage for legitimate traffic. A good DDoS defense system always attempts to

reduce collateral damage while lowering attack traffic as much as possible. In Ta-
ble 5.6(a), 5.6(b), and 5.6(c), we present the drop rates of legitimate traffic in the

three situations. The network without DDoS defense drops a large number of legit-
CHAPTER 5. EXPERIMENTS AND RESULTS 87

Table 5.6: Drop Rate of Legitimate Traffic


(a) Drop Rate of Legitimate Traffic with Ratio
(9:1)
Situations DropRate
No defense 0.834
Pushback 0.067
Distance-based framework 0.056
(b) Drop Rate of Legitimate Traffic with Ratio
(5:5)
Situations DropRate
No defense 0.122
Pushback 0.065
Distance-based framework 0.020
(c) Drop Rate of Legitimate Traffic with 1 At-
tacker
Situations DropRate
No defense 0.115
Pushback 0.029
Distance-based framework 0.023

imate packets due to congestion at the bottleneck link. Pushback and the distance-
based DDoS defense framework show a much better performance to sustain QoS for

legitimate traffic, meaning that collateral damage is very low. The collateral damage
of the distance-based DDoS framework is a little lower than that of the pushback
technique in Table 5.6(a), 5.6(b), and 5.6(c).

5.5 Discussions

This discussion will answer two questions. The first question is how our framework

handles different types of DDoS attacks. The second question is how our framework
deals with IP spoofing. Based on the two questions, we divide this discussion into
CHAPTER 5. EXPERIMENTS AND RESULTS 88

two parts.

5.5.1 Different DDoS Attacks

In Chapter 2, we introduced a number of types of flooding-based DDoS attacks. From

an attack mechanism point of view, they can create attack traffic by either their agents
or a number of reflectors. From a network protocol point of view, a flooding-based

DDoS attack can utilize multiple flaws existing in a number of Internet protocols.

However, there are a common feature for all types of flooding-based DDoS attacks.
The common feature is that all type of flooding-based DDoS attacks will finally create

a huge volume of anomalous attack traffic to block the link between the victim and the
network. In our framework, our proposed distance-based DDoS detection, traceback,
and response techniques are totally based on anomalous attack traffic. Therefore,
their performances will not be affected by different types of flooding-based attacks.

5.5.2 IP Spoofing

Usually, a DDoS attacker will use IP spoofing when creating attack packets. As

illustrated in Section 2.2, an attacker can compromise any attributes in an IP packet.

To discuss about the possible influence for the distance-based defense framework, we

analyze the problem from three phases of the DDoS defense: DDoS detection, DDoS

traceback, and DDoS response.


1. DDoS Detection: Our two proposed DDoS detection techniques detect a DDoS

attack directly or indirectly based on distance values. Both techniques could run into

trouble if an attacker can spoof distance information. However, this situation will not
happen because the calculation of distance values is based on the information marked
CHAPTER 5. EXPERIMENTS AND RESULTS 89

by each edge router. Obviously, an attacker usually cannot control a router in the
current network. Therefore, both DDoS detection techniques are IP spoofing free.

2. Traceback: We use the FIT technique which works on the information marked
by each edge router. Therefore, IP spoofing can do nothing to influence the accuracy
of the FIT traceback technique.

3. DDoS Response: We propose a distance-based rate limit mechanism and no

operations of the mechanism have any relation to IP attributes. As already men-

tioned, even for the calculation of distance values, we do not use methods based on
IP attributes.
In summary, different types of flooding-based DDoS attacks have no negative

influence on our framework. Moreover, the framework can still work properly even

under IP spoofing DDoS attacks.

5.6 Summary

In this chapter, we evaluate the distance-based DDoS defense framework based on


the simulations using NS2. The results of six metrics indicate that the framework can

control attack traffic to protect the victim effectively. At the same time, performance

of the framework is better than that of the pushback technique as seen by directly
comparing the results with each other.

In the next chapter, we summarize the whole thesis and discuss future research.
Chapter 6

Conclusion and Future Work

6.1 Conclusion

After analyzing many existing DDoS detection and response techniques and defense

frameworks in Chapter 3, we find that the major challenges of DDoS defense are to

detect attacks quickly and with high effectiveness and to control attack traffic so as
to sustain QoS for legitimate traffic. To address these challenges, we have proposed
distance-based DDoS detection and response techniques integrated into a framework
that detects attacks at the victim end and responds to them at source ends while

incurring very little communication overhead. Basically, the process of defense can

be divided into three phases. At the beginning of an attack, distance-based detection

techniques can detect the attack if there are anomalous variations of average distance

values and traffic rates at different distances at the victim end. Then the defense

system at the victim end attempts to find all edge routers that are forwarding attack
traffic aggressively. During finding the source-end edge routers, the defense system at

the victim end utilizes the FIT [15] to reconstruct the remote edge router addresses.
90
CHAPTER 6. CONCLUSION AND FUTURE WORK 91

Finally, a series of alert messages will be sent to the source-end defense systems,
which set up rate limits on each edge router based on the received information and

its own drop rate. The recovery process will be triggered if traffic at the victim end

has returned to normal.


This thesis makes four major contributions:

1. The distance-based framework that utilizes distance-based DDoS defense sys-

tems coordinates between the system at the victim end and systems at the source

ends using a highly efficient cooperative communication mechanism. Furthermore,


we integrate the FIT traceback into a framework to support fast source finding.

2. The average distance estimation DDoS detection technique works on distance

values directly. For normal traffic at the victim end, the average value at next mo-
ment should belong to a legitimate scope determined by the exponential smoothing

technique, whose effectiveness has been demonstrated by experiments.


3. The distance-based traffic separation DDoS detection technique detects an

attack by analyzing the variation of traffic rates at different distance values. The
MMSE is used for the first time in the DDoS detection algorithm to help find traffic
being sent at anomalous rates; experiments also demonstrate the effectiveness of this

technique.

4. The distance-based rate limit mechanism differentiates source-end edge routers

in order to drop as much attack traffic as possible. The historic drop rate in an

edge router is a very important factor during the calculation of its rate limit for the

router. Using distance and history information to calculate the rate limit is a unique
contribution of this mechanism. The experiments demonstrate that the performance

of our mechanism is better than the pushback technique.


CHAPTER 6. CONCLUSION AND FUTURE WORK 92

6.2 Future Work

In future, we will evaluate our framework for more internet topologies. In particular,
we plan to investigate the following issues in more detail.

1. For both detection techniques, we adopt the MAD-based deviation model. A


key parameter of which is the threshold thr. How best to optimize this parameter

for a network is still an open question. In fact, the optimization of thr relies on the
study of statistical features of the prediction error. Therefore, our future studies will

center on the statistical distribution of prediction error in our average distance and

separated traffic rate prediction techniques.


2. During the defeat of a DDoS attack, an important phase is the recovery of
traffic. The distance-based DDoS defense framework borrows this idea from classi-
cal TCP/IP traffic congestion control, leading the recovery process to be very slow.

Therefore, legitimate traffic cannot utilize resources quickly and effectively during
recovery. In future studies, we will focus on proposing a more appropriate recovery
mechanism for DDoS attacks.

3. During the attack, the distance-based DDoS defense framework does not
perform well to decide whether an attack has finished or not. This leads the recovery

mechanism to be triggered at a moment when the attack is still running. Future

studies should provide a more effective solution.


Bibliography

[1] K. Xu, Z.-L. Zhang, and S. Bhattacharyya, “Reducing unwanted traffic in a back-

bone network,” in Steps to Reducing Unwanted Traffic on the Internet Workshop


(SRUTI), 2005, pp. 9–15.

[2] Y. Chen and K. Hwang, “Collaborative change detection of DDoS attacks on com-
munity and ISP networks,” in the IEEE International Symposium on Collaborative
Technologies and Systems (CTS’06), 2006, pp. 401–410.

[3] R. Mahajan, S. Floyd, and D. Wetherall, “Controlling high-bandwidth flows at

the congested router,” in Proceedings of ACM 9th International Conference on


Network Protocols (ICNP), 2001, pp. 192–201.

[4] T. Peng, C. Leckie, and R. Kotagiri, “Proactively detecting DDoS attack using

source ip address monitoring,” in Proceedings of the Third International IFIP-TC6


Networking Conference, 2004, pp. 771–782.

[5] R. R. Talpade, G. Kim, and S. Khurana, “NOMAD: traffic based network mon-

itoring framework for anomaly detection,” in the Fourth IEEE Symposium on


Computers and Communications, 1999, pp. 442–451.

93
BIBLIOGRAPHY 94

[6] G. Carl, G. Kesidis, R. Brooks, and S. Rai, “Denial-of-service attack detection


techniques,” IEEE Internet Computing, vol. 10, no. 1, January 2006, pp. 82–89.

[7] VINT Project U. C. Berkeley/LBNL, “NS2: network simulator,” Available at


http://www.isi.edu/nsnam/ns, 2006.

[8] Y. Kim, J.-Y. Jo, and K. K. Suh, “Baseline profile stability for network anomaly
detection,” in Proceedings of the 3rd International Conference On Information

Technology: New Generations, 2006, pp. 720–725.

[9] J. Jung, A. Berger, and H. Balakrishnan, “Modeling TTL-based internet caches,”


in Proceedings of the Twenty-Second Annual Joint Conference of the IEEE Com-
puter and Communications Societies, 2003, pp. 417–426.

[10] L. Feinstein, D. Schnackenberg, R. Balupari, and D. Kindred, “Statistical ap-

proaches to DDoS attack detection and response,” in Proceedings of DARPA In-

formation Survivability Conference and Exposition, 2003, pp. 303–314.

[11] T. Gil and M. Poleto, “Multops: a data-structure for bandwidth attack detec-

tion,” in Proceedings of 10th Usenix Security Symposium, 2001, pp. 23–38.

[12] J. Jiang and S. Papavassiliou, “Detecting network attacks in the internet via

statistical network traffic normality prediction,” Journal of Network and System

Management, vol. 12, no. 1, 2004, pp. 51–72.

[13] S. Lee, H. Kim, J. Na, and J. Jang, “Abnormal traffic detection and its im-

plementation,” Advanced Communication Technology, vol. 1, February 2005, pp.


246–250.
BIBLIOGRAPHY 95

[14] W. Gao, J. Wang, J. Chen, and S. Chen, “PFED: a prediction-based fair active
queue management algorithm,” in Proceedings of the IEEE International Confer-

ence on Parallel Processing (ICPP), 2005, pp. 485–491.

[15] A. Yaar, A. Perrig, and D. Song, “FIT: fast internet traceback,” in Proceedings
of the 24th Annual Joint Conference of the IEEE Computer and Communications

Societies (INFOCOM), 2005, pp. 1395–1406.

[16] The Swiss Education and Research Network, “Default TTL values in TCP/IP,
”Available at http://secfr.nerim.net/docs/fingerprint/en/ttldefault.html, 2002.

[17] V. Jacobson, “Congestion avoidance and control,” in Proceedings of SIG-


COMM’88, ACM, 1988, pp. 314–329.

[18] P. Brockwell and R. Davis., Time Series: Theory and Methods. Springer-Verlag,

1991.

[19] Y. Shu, L. Wang, and L. Zhang, “Internet traffic modeling and prediction using

FARIMA models,” Chinese Journal of Computers, vol. 1, no. 24, 2001, pp. 46–54.

[20] P. S. R. Diniz, Adaptive Filtering: Algorithms and Practical Implementation.

Kluwer Academic, 2002.

[21] J. Kong, M. Mirza, J. Shu, C. Yoedhana, M. Gerla, and S. Lu, “Random flow

network modeling and simulations for DDoS attack mitigation,” Communications,

vol. 1, May 2003, pp. 487–491.

[22] M. Faloutsos, P. Faloutsos, and C. Faloutsos, “On power-law relationships of the

internet topology,” in SIGCOMM, 1999, pp. 251–262.


BIBLIOGRAPHY 96

[23] Topology Project University of Michigan, “Inet: Internet Topology Generator,”


Available at topology.eecs.umich.edu/inet/, 2006.

[24] C. Jin, H. Wang, and K. G. Shin, “Hop-count filtering: an effective defense


against spoofed DDoS traffic,” in Proceedings of the 10th ACM Conference on

Computer and Communications Security, 2003, pp. 30–41.

[25] V. Paxson and S. Floyd, “Wide-area traffic: the failure of poisson modeling,” in

IEEE/ACM Transactions on Networking, vol. 3, no. 3, June 1995, pp. 226-244.

[26] Y. Jing, Z. Xiao, X. Wang, and G. Zhang, “O2 -DN: an overlay-based dis-
tributed rate limit framework to defeat DDoS attacks,” in Proceedings of

ICN/ICONS/MCL, 2006, pp. 79–79.

[27] K. K. K. Wan and R. K. C. Chang, “Engineering of a global defense infrastruc-


ture for DDoS attacks,” in Proceedings of the IEEE International Conference on
Networks, Auguest 2002, pp. 419–427.

[28] H.-Y. Lam, C.-P. Li, S.-T. Chanson, and D.-Y. Yeung, “A coordinated detection

and response scheme for distributed Denial-of-Service attacks,” in Proceedings of

the IEEE International Conference on Communications, June 2006, pp. 2165–


2170.

[29] J. Mirkovic, M. Robinson, P. Reiher, and G. Oikonomou, “A framework for

collaborative DDoS defense,” in Proceedings of ACSAC, December 2006.

[30] R. Mahajan, S. M. Bellovin, S. Floyd, J. Inannidis, V. Paxson, and S. Shenker,

“Controlling high bandwidth aggregates in the network,” Technical Report, AT&T

Center for Internet Research at ICSI, July 2001.


BIBLIOGRAPHY 97

[31] G. Zhang and M. Parashar, “Cooperative mechanism against DDoS attacks,”


in Proceedings of the 2005 International Conference on Security Management

(SAM.05), June 2005.

[32] C. Papadopoulos, R. Lindell, J. Mehringer, A. Hussain, and R. Govinda, “COS-


SACK: Coordinated suppression of simultaneous attacks,” in Proceedings of the

DARPA Information Survivability Conference and Exposition III, April 2003, pp.

2–13.

[33] T. Peng, C. Leckie, and K. Ramamohanarao, “Protection from distributed denial


of service attacks using history-based IP filtering,” in Proceedings of the IEEE

International Conference on Communications, May 2003, pp. 482–486.

[34] R.B. Blazek, H. Kim, B. Rozovskii, and A. Tartakovsky, “A novel approach to de-
tection of “ denial-of-service” attacks via adative sequential and batch-sequential
change-point detection methods,” in Proceedings of the 2nd Annual IEEE Sys-
tems, Man, and Cybernetices Information Assurance Workshop, West Point, NY,

June 2003.

[35] R. Thomas, B. Mark, T. Johnson, and J. Croall, “NetBouncer: client-legitimacy-

based high-performance DDoS filtering,” in Proceedings of the DARPA Informa-


tion Survivability Conference and Exposition, vol. 1, April 2003, pp. 14–25.

[36] P. Ferguson and D. Senie, “Network ingress filtering: defeating denial of service

attacks which employ IP source address spoofing,” IETF RFC2267 RFC 2267,

January 1998.
BIBLIOGRAPHY 98

[37] J. Yan, S. Early, and R. Anderson, “The XenoService: a distributed defeat for
distributed denial of service.” in Proceedings of ISW, October 2000.

[38] Cs3. Inc., “MANAnet DDoS white papers.” Available at http://www.cs3-


inc.com/mananet.html, 2007.

[39] J. Mirkovic and P. Reiher, “D-WARD: a source-end defense against flooding


denial-of-service attacks.” in Dependable and Secure Computing, IEEE Transac-

tions, vol. 2, no. 3, July 2005, pp. 216-232.

[40] Y. Fan, H. Hassanein, and P. Martin, “Proactively defeating distributed denial of


service attacks.” in Canadian Conference on Electrical and Computer Engineering,

2003., vol. 2, May 2003, pp. 1047-1050.

[41] H. Luo and M.-L. Shyu, “The protection of QoS for multimedia transmission
against denial of service attacks.” in Seventh IEEE International Symposium on
Multimedia, December 2005.

[42] Y. Kim, J.-Y. Jo, F. Merat, M. Yang, and Y. Jiang, “Mitigating distributed

denial-of-service attack with deterministic bit marking, International Journal of

Information Technology, vol. 11, no. 2, 2005, pp. 62–82

[43] A. Yaar, A. Perrig, and D. Song, “SIFF: a stateless Internet flow filter to miti-

gate DDoS flooding attacks.” in Proceedings of IEEE Symposium on Security and

Privacy, May 2004, pp. 130–143.

[44] J. Mölsä, “Effectiveness of rate-limiting in mitigating flooding DoS attacks.” in

Proceedings of the Third IASTED International Conference on Communications,

Internet, and Information Technology, November 2004, pp. 155–160.


BIBLIOGRAPHY 99

[45] D. K. Y. Yau, J. C. S. Lui, F. Liang, and Y. Yam, “Defending against dis-


tributed denial-of-service attacks with max-min fair server-centric router throt-

tles.” IEEE/ACM Transactions on Networking, vol. 13, no. 1, February 2005, pp.

29–42.

[46] T. Dübendorfer, M. Bossardt, and B. Plattner, “Adaptive distributed traffic

control service for DDoS attack mitigation.” in Proceedings of 19th IEEE Inter-

national Parallel and Distributed Processing Symposium, April 2005.

[47] S. Tanachaiwiwat and K. Hwang, “Differential packet filtering against DDoS


flood attacks.” in Proceedings of ACM Conference on Computer and Communi-

cations Security (CCS), October 2003.

[48] Y. Manzano, “Filtering, and content distribution approaches to mitigate the


effects of DOS attacks and flash crowds on network performance.” in Proceedings
of the 7th World Multiconference on Systemics, Cybernetics and Informatics, July
2003.

[49] Q. Li, E.-C. Chang, and M. C. Chan, “On the effectiveness of DDoS attacks

on statistical filtering” in Proceedings of the IEEE 24th Annual Joint Conference

of the IEEE Computer and Communications Societies (INFOCOM), vol. 2, 2005,


pp. 1373–1383.

[50] Y.-H. Hu, H. Choi, and H.-A. Choi, “Packet filtering to defend flooding-based

DDoS attacks.” IEEE/Sarnoff Symposium on Advances in Wired and Wireless

Communication, April 2004, pp. 39–42.


BIBLIOGRAPHY 100

[51] L. Feinstein, D. Schnackenberg, R. Balupari, and D. Kindred, “Statistical ap-


proaches to DDoS attack detection and response.” in Proceedings of the DARPA

Information Survivability Conference and Exposition, vol. 1, April 2003, pp. 303–

314.

[52] J. Mölsä, “Effectiveness of rate-limiting in mitigating flooding DoS attacks.” in

Proceedings of the Third IASTED International Conference on Communications,

Internet, and Information Technology, November. 2004, pp. 155–160.

[53] D. Sterne, K. Djahandari, B. Wilson, B. Babson, D. Schnackenberg, H. Holliday,


and T. Reid, “Autonomic response to distributed denial of service attacks.” in

Proceedings of Recent Advances in Intrusion Detection, 4th International Sympo-

sium, 2001, pp. 134–149.

[54] Y. Xiang, W. Zhou, and M. Chowdhury, “A survey of active and passive de-
fence mechanisms against DDoS attacks.” Technical Report, TR C04/02, School
of Information Technology, Deakin University, Australia, March 2004.

[55] J. Mirkovic, P. Reiher, “A taxonomy of DDoS attack and DDoS defense mecha-

nisms.” ACM SIGCOMM Computer Communication Review, vol. 34, no. 2, 2004,

pp. 39–53.

[56] P. Ferguson and D. Senie, “Network ingress filtering: defeating

denial-of-service attacks which employ IP source address spoofing.”

http://www.ietf.org/rfc/rfc2827.txt, 2000.

[57] CERT Coordination Center, “Denial of service attacks.”Available at

http://www.cert.org/tech tips/denial of service.html, March 2007.


BIBLIOGRAPHY 101

[58] L. Garber, “Denial-of-service attacks rip the Internet.” IEEE Computer, vol. 33,
no. 4, April 2000, pp. 12–17.

[59] D. Moore, G. M. Voelker, and S. Savage, “Inferring Internet denial-of-service


activity.” in Proceedings of the 10th USENIX Security Symposium, August 2001.

[60] CAIDA, “Nameserver DoS attack October 2002.” Available at


http://www.caida.org/funding/dns-analysis/oct02dos.xml, March 2007.

[61] ZDNet, “New denial-of-service threat emerges.” Available at


http://news.zdnet.com/2100-1009 22-6050688.html, March 2007.

[62] J. Mölsä, “Mitigating denial of service attacks in computer networks”. PhD


thesis, Helsinki University of Technology, Espoo, Finland, June 2006.

[63] V. Paxson, “An analysis of using reflectors for distributed denial-of-service at-
tacks.” ACM SIGCOMM Computer Communication Review, vol. 31, no. 3, July
2001.

[64] S. M. Specht and R. B. Lee, “Distributed denial of service: taxonomies of attacks,

tools and countermeasures.” in Proceedings of the 17th International Conference

on Parallel and Distributed Computing Systems, September 2004, pp. 543–550.

[65] R. K. Chang, “Defending against flooding-based distributed denial-of-service at-

tacks: A tutorial.” IEEE Commun. Mag., vol. 40, no. 10, October 2002, pp.

42–51.

[66] Cisco Systems, Inc., “Characterizing and tracing packet floods using cisco

routers.” May 2005.


BIBLIOGRAPHY 102

[67] R. Vaughn and G. Evron, “DNS amplification attacks.” Available at


http://www.isotf.org/news/DNS-Amplification-Attacks.pdf, March 2007.

[68] CERT Coordination Center. “CERT advisory CA-98.01 smurf IP denial-of-


service attacks.” Available at http://www.cert.org/advisories/CA-1998-01.html,

March 2007.

[69] CERT Coordination Center. “CERT advisory CA-1996-01: UDP port denial-of-

service attack.” Available at http://www.cert.org/advisories/CA-1996-01.html.

[70] Y. Fan, “Defeating ing Denial of Service attacks with source router preferential
dropping”. Master thesis, Queens’s University, Kingston, Canada, June 2003.

[71] Q. Li, H. Zhu, M. Zhang, and J. Ju, “Simulating and improving probabilistic
packet marking schemes using NS2.” in Sixth International Conference on Parallel
and Distributed Computing, Applications and Technologies, December 2005, pp.
348–352.

[72] C. Sanetachatanaruk, S. M. Khattab, T. Znati, R. Melhem, D. Mosse, “A simula-

tion study of the proactive server roaming for mitigating denial of service attacks.”

in 36th Annual Simulation Symposium, April 2003, pp. 7–14.

[73] F. Lau, S. H. Rubin, M. H. Smith, L. Trajkovic, “Distributed denial of service

attacks.” in IEEE International Conference on Systems, Man, and Cybernetics,

2000, vol. 3, pp. 2275–2280.

[74] A. Hussain, S. Schwab, R. Thomas, S. Fahmy, and J. Mirkovic, “DDoS experi-

ment methodology.” in Proceedings of DETER Community Workshop, June 2006,

pp. 8–14.
BIBLIOGRAPHY 103

[75] C. Ko, A. Hussain, S. Schwab, R. Thomas, and B. Wilson, “Towards systematic


IDS evaluation.” in Proceedings of DETER Community Workshop, June 2006, pp.

20–23.

[76] J. Mirkovic, E. Arikan, S. Wei, R. Thomas, S. Fahmy, and P. Reiher, “Bench-

marks for DDoS defense evaluation.” in Proceedings of DETER Community Work-


shop, June 2006, pp. 15–18.

[77] N. Farrell, “New DoS attack a real killer.” Available at

http://www.theinquirer.net/default.aspx?article=30361, March 2007.

[78] Y. You, M. Zulkernine, and A. Haque, “Detecting flooding-based DDoS attacks”

in Proceedings of IEEE International Conference on Communications, June 2007,


pp. 1229–1234.

[79] Y. Ioannidis and S. Bellovin, “Implementing pushback: router-based defense


against DDoS attacks” in Proceedings of the Network and Distributed System Se-
curity Symposium, February 2002.

[80] P. Ferguson and D. Senie, “Network ingress filtering: defeating

Denial-of-Service attacks with employ IP source address spoofing.”

http://www.ietf.org/rfc/rfc2267.txt, 1998.

[81] J. Evans and C. Filsfils., Deploying IP and MPLS QoS for Multiservice Networks:

Theory and Practice. Morgan Kaufmann, 2007.

[82] W. Feibel, The Network Press Encyclopedia of Networking. Sybex, 2000.

[83] C. M. Kozierok, The TCP/IP Guide. No Starch Press, 2005.