Documente Academic
Documente Profesional
Documente Cultură
Ajay Mahimkar, Jasraj Dange, Vitaly Shmatikov, Harrick Vin, Yin Zhang
Department of Computer Sciences, The University of Texas at Austin
{mahimkar,jasraj,shmat,vin,yzhang}@cs.utexas.edu
changes to the existing router software, and is thus in- (a) During Normal Operation (b) During DDoS Attack
crementally deployable by Internet service providers.
• On-demand invocation: dFence middleboxes are dy- Figure 1: dFence Architecture: (a) During normal op-
namically introduced into the data path of network eration, the ingress routers forward the traffic towards
connections whose destinations are experiencing de- the corresponding egress routers. (b) Under a large-scale
nial of service, and removed when the attack subsides. DoS attack, traffic is re-directed via the middlebox. The
The small performance cost of filtering is paid only by middlebox applies mitigation policies and filters out ille-
the attacked hosts, and only for the duration of the at- gitimate traffic.
tack. mitigation techniques that were previously considered
• Scalability: The dynamic nature of dFence allows unsuitable for network-based defenses. The main techni-
ISPs to multiplex the same defense infrastructure to cal novelty is the network-based implementation of de-
protect a large number of customers (who are not all fenses that previously required modifications to server
under attack at the same time), and thus more effi- or client software. For example, “outsourcing” SYN
ciently utilize their network and computing resources. cookie generation to dFence middleboxes enables us to
protect legacy end hosts whose TCP/IP implementations
• Minimal impact on legitimate connections: Each
do not support SYN cookies. Other mitigation tech-
dFence middlebox manages the state of active, legiti-
niques include defenses against spoofed and unspoofed
mate connections to the customers who are simultane-
data floods, against clients opening and abandoning a
ously under attack. Malicious flows do not occupy any
large number of connections, and against distributed bot-
memory at the middlebox. Therefore, legitimate flows
net attacks.
can be processed with very low latency cost. The cost
for the flows to the destinations not experiencing an Key challenges. The combination of transparent on-
attack is zero. demand defense, two-way traffic interception, and state-
• Versatility: Because dFence middleboxes dynami- ful mitigation presents several interesting challenges: (i)
cally intercept both directions of TCP connections to how to deal with middlebox transitions, i.e., how to intro-
DoS-affected hosts, they can apply stateful mitigation duce and and remove middleboxes on selected data paths;
policies to defend against the entire spectrum of DoS (ii) how to dynamically bootstrap, manage, and remove
attacks. connection state at the middleboxes; (iii) how to handle
network behavior such as route changes and failures of
• Economic incentive: We envision dFence middle- network elements; and (iv) how to handle overload con-
boxes being deployed within a single ISP. The ISP can ditions and DoS attacks on the middleboxes themselves.
then charge a premium to customers who subscribe for We present practical solutions to all of these chal-
a dFence-based “insurance service.” dFence middle- lenges. Our main contribution is a careful integration
boxes are turned on only when one or more paying of several network mechanisms leading to a completely
customers are experiencing an attack. As more cus- transparent, scalable and effective DoS mitigation sys-
tomers subscribe to the service, the ISP can incremen- tem. We evaluate our design using a prototype implemen-
tally scale up the deployment. tation based on Intel’s IXP2400 network processors, and
demonstrate that mitigation of a broad range of DoS at-
System architecture. Figure 1 depicts the overall sys-
tacks, including spoofed SYN floods and unspoofed data
tem architecture. The two guiding design principles be-
floods, can be achieved with minimal performance degra-
hind dFence are dynamic introduction and stateful mit-
dation. We also note that the focus of this paper is on
igation. We implement dynamic introduction by using
mitigation, rather than detection of denial of service ac-
intra-domain routing and tunneling mechanisms to trans-
tivity.
parently insert dFence middleboxes into the data path of
traffic destined to hosts experiencing a DoS attack. This Organization. The rest of the paper is organized as fol-
is done only when DoS activity is detected in the net- lows. In Section 2, we describe the mechanisms for dy-
work. Due to dynamic introduction, our solution has namically introducing dFence middleboxes in the data
zero impact on normal network operations, and can be path of attack traffic. Section 3 describes the architec-
deployed incrementally. ture of the dFence middleboxes and the mitigation poli-
The middleboxes intercept both directions of network cies that defend against a broad range of spoofed and un-
traffic (to and from attacked hosts), which enables many spoofed attacks. Our prototype implementation and its
performance evaluation are presented in Sections 4 and 5, tination IP addresses and port numbers in the TCP/IP
respectively. Section 6 outlines the related work. Sec- packet header. If the flow is intercepted by a foreign
tion 7 summarizes our contributions. middlebox, it is simply forwarded to the home mid-
dlebox, achieving reasonable load balancing of flows
2 Transparent Middlebox Invocation across the middleboxes. In the future, we plan to inves-
A key design principle for dFence middleboxes is com- tigate more sophisticated flow pinning mechanisms.
plete transparency to the end hosts. This is achieved
through dynamic invocation of middleboxes by standard • Dynamic state management. Dynamic middlebox in-
intra-domain routing mechanisms and tunneling. A few vocation also poses interesting challenges for state
dFence middleboxes are introduced into the network to management. The first question is how to handle ex-
provide focused protection to the subset of the end hosts isting connections when the middlebox is inserted into
that are currently experiencing a DoS attack. Protected the data path. For instance, our policy for defending
hosts do not need to modify their software, nor access against spoofed data flooding can drop a data packet if
the network through special overlay points, nor set up IP it is not in the Bloom filter summary of ongoing con-
tunnels, nor even be aware that dFence middleboxes have nections. But an existing legitimate connection may
been deployed inside their ISP. not be present in the Bloom filter if it had been es-
Dynamic middlebox invocation is critical for deploy- tablished before the middlebox was introduced. We
ability because it ensures that during peace time (i.e., would like to minimize the number of packets dropped
when there is no ongoing DDoS activity) customer traf- for such connections.
fic does not have to pay the penalty of triangular routing Besides filtering, some of our advanced mitigation
through the middleboxes. Dynamic middlebox invoca- policies perform operations that change the content of
tion is also important for the defense system itself be- the traffic. For example, the “outsourced” SYN cookie
cause it focuses all defense resources only on the connec- policy requires the splicing of TCP connections and
tions whose destinations are under attack, leaving other sequence number translation to be performed at the
customers unaffected. The defense system can thus ben- middlebox. What happens to the spliced connections
efit from statistical multiplexing and potentially protect when the middlebox is removed from the data path?
many more customer networks with the same available
resources. • Middlebox failure recovery. A dFence middlebox may
Combining dynamic middlebox invocation with state- fail due to software or hardware errors, or traffic over-
ful attack mitigation raises several technical challenges. load. Protecting the overall defense system from mid-
dlebox failures is an important challenge.
• Bidirectional traffic interception. Many of our mitiga-
tion policies require the defense system to capture both Our solution is based on standard BGP/IGP routing,
directions of customer traffic. For example, to protect tunneling, and policy-based routing (PBR) [7], which is
against spoofed data floods from remote hosts to a cus- available in almost all existing routers. Therefore, our
tomer network under protection, we maintain a Con- solution is easy to deploy in today’s Internet. In ad-
nection table to summarize on-going TCP connec- dition, we implement a simple hash-based mechanism
tions. Bidirectional traffic interception is difficult in for pinning each individual connection to the same home
general because Internet routing is destination-based middlebox. This ensures that both directions of the con-
by default; intercepting traffic from the customer net- nection traverses the same middlebox (even in the pres-
work, however, requires the ability to perform source- ence of route changes that may result in different ingress
based routing. points). Below we present our approach for bidirectional
• Flow pinning. In addition to intercepting both direc- traffic interception, dynamic state management, middle-
tions of protected traffic, stateful mitigation also re- box failure recovery and load balancing.
quires that both directions pass through the same mid-
dlebox (where the state of the connection is main- 2.1 Dynamic Traffic Interception
tained), even after routing changes have caused the in- While there exist several academic and industrial solu-
tercepted traffic to use different ingress points. This tions for traffic interception [1, 8, 11], none of them,
requires a mechanism for pinning each flow, defined to the best of our knowledge, can simultaneously (i) in-
by the TCP/IP packet header, to a particular middle- troduce middleboxes dynamically, (ii) intercept both in-
box. Flow pinning also provides security against an bound and outbound traffic, and (iii) ensure that both di-
attacker who attempts to disrupt external routing while rections of a connection go through the same home mid-
launching an attack. dlebox. As a result, no single existing technique is suf-
We use a simple hash-based flow pinning method. ficient for stateful attack mitigation. It is possible, how-
Each flow is associated with a home middlebox, whose ever, to use existing techniques to substitute some of the
identity is determined by a hash h(f ) of the flow iden- individual components of our solution (e.g., our mecha-
tifier f . The flow identifier consists of source and des- nism for inbound traffic interception).
Internet Service Provider (ISP)
Customer identity of the home middlebox is determined by the
Network S
R
6 hash value of the flow identifier. The home middle-
M2
R4
Rn
box M3 then applies mitigation policies described in
previous R
3 M
section 3.2 to process the packet.
R R9 4
best 7
next−hop
M
1
3. Go to the real egress router: After the middleboxes
M
R
1
3 R
10
advertised routes to S, the intermediate routers’ for-
R
2 R
8 warding tables point towards middleboxes for all pack-
Remote ets whose destination is S. To avoid routing loops,
Client C
regular IP routing tunneled traffic
we tunnel the packet from the home middlebox M3 to
(a) Inbound Traffic Interception
the true egress router Rn . When Rn receives the tun-
neled packet, it decapsulates the packet and, because
Customer
Internet Service Provider (ISP) Network S it matches ACL-to-S, forwards it to the customer net-
M2
R
6
Rn
work S.
R4
Observe that the traffic arriving on the external in-
R3
R7 R
9
M
4 terfaces of Rn (other than the interface connecting it
M
1
M
3 R
to S) will be first re-routed to the middlebox for fil-
R1 10
R2
tering, because the middleboxes’ iBGP route advertise-
R8
ments change the forwarding table at Rn , too.
Remote
Client C 2.1.2 Outbound traffic interception
regular IP routing tunneled traffic
nique and apply several hash functions until a vacant en- Client Return Cookie
Because the dFence middlebox is in the data path of all Exhausting the connection state. To prevent the at-
connections to and from the servers that are being pro- tacker from filling up the Connection table, we use the
tected, it is critical to ensure that per-packet processing Src-Dest table to limit the number of connections from
complexity is low and can scale to high link speeds. In any single host. For protection from botnets, we use
particular, we want to avoid blindly applying different source-prefix whitelisting as described in section 3.2.2.
mitigation policies one after another regardless of the In general, resource exhaustion is prevented because the
packet type. middlebox keeps state only for unspoofed sources that
On receipt of a packet, the middlebox first classi- have complied with traffic control measures (i.e., whose
fies it using TCP flag types. Depending on which flag network-level behavior is similar to legitimate sources).
is set (SYN, SYN+ACK, FIN, RST, etc.), it is sent to Adaptive traffic variation. The attacker may employ
the respective processing function. For a SYN packet an ON/OFF attack pattern. On attack detection, the mid-
from client during the bootstrap or active phases, a SYN dlebox is introduced on the data path. As soon as mid-
cookie is generated and SYN-ACK sent back to the dlebox is introduced, the attacker stops sending attack
client. For SYNs from server, the Bloom filter is updated. traffic. All legitimate traffic goes via the middlebox and
For SYN-ACKs from the server during the bootstrap or suffers minor degradation due to triangular routing. After
active phases, the Connection table is updated with the some time interval (the attacker assumes that the middle-
right offset value (difference between the seq/ack num- box is now removed from data path), he starts sending
bers on the middlebox-source and middlebox-server con- attack traffic again, and so on. To provide a partial de-
nections). During the removal phase, SYNs and SYN- fense against this attack, we avoid rapid introduction and
ACKs are simply forwarded without updating the data removal of middleboxes. Once the middlebox is intro-
structures at the middlebox. duced, it remains in the data path for some period even
For a data packet, its 4-tuple flow ID (IP addresses and after the attack subsided. The duration of this interval is
port numbers) is looked up and checked against the Con- randomized.
nection table and the Bloom filter to verify that it be-
Werewolf attack. The attacker starts by behaving legiti-
longs to an established connection. If in the Bloom filter,
mately, gets established in the Connection table, com-
the packets are forwarded. If in the Connection table,
plies with congestion control requests, and then starts
the pre-existing bit is checked and splicing performed,
bombarding the server with attack traffic. We deal with
if needed. During the bootstrap phase, packets whose
this attack by periodically re-measuring traffic sending
flow ID does not belong to both the Bloom filter and the
rates and source-prefix whitelisting.
Connection table are forwarded and middlebox state up-
dated. During the active phase, they are assumed to be Multiple attacks. The attacker can try to overwhelm the
spoofed and dropped. During the removal phase, they are dFence infrastructure by launching multiple attacks on
Yes
Penalize using
SYN Data / ACK congestion signals
Outbound
No Yes No
No Is Flow in Is Flow in To apply Forward and
Removal Update book−keeping
Direction Bloom filter Table penalty
Phase Bloom Filter
Yes No
Forward Send Cookie Forward Is Cookie Create state and
Collision in
Correct Table send SYN to server
SYN−ACK No Yes
No No Yes Yes
Update Forward and update Replace entry
Removal Bootstrap Bootstrap Can replace
Phase Bloom Filter Connection table entry and forward
Yes Yes No No
No
Outbound
Forward Yes Drop packet
Forward if in Removal
Direction Forward
Bloom filter Phase
Inbound
(in milli−seconds)
With Middlebox (10 concurrent connections)
Connection Time
SYN SYN Cookie and 205 401 467 10000
SYN-ACK Genera-
tion 1000
Bloom filter update 530 1041 1041
Forward 1041 1041 1041
100
Inbound Data Present in Bloom filter 507 1011 1041
Present in Connection 264 525 781
Table - splice 10
Absent in both - for- 326 652 974
ward (removal phase) 1
1 10 100
Outbound Present in Bloom filter 507 1011 1041 Attack Rate (in Kpps)
Data Present in Connection 259 515 766 (a)
Table
Middlebox Bootstrapped Middlebox Removed
Absent in both - for- 318 637 1029 Middlebox Introduced Attack Stopped
ward (removal phase) Attack Started
Absent in both - up- 326 653 951
date (bootstrap phase) 1000
Maximum TCP Throughput (Mbps)
Attack Traffic Rate (Mbps)
Table 2: Throughput benchmarks in Kilo Packets Per
Second (Kpps). Maximum input rate from IXIA (one 100
fiber port) is 1041 Kpps with packet size = 100 bytes.
checksum computation) is more expensive than checking 10
the Bloom filter, updating, or simple forwarding.
Throughput. Table 2 presents our throughput bench-
1
marks. Throughput scales linearly as more micro- 1 10 100 1000
engines are allocated to the PPFs for all packet types and Experimental Time (in seconds)
processing functionalities, except for SYN cookie gener- (b)
ation. For the latter, maximum throughput supported by Figure 7: (a) End-to-end latency for one and ten con-
a single IXP is 467 Kpps. current HTTP connections to a Web server. Attack traf-
fic rate is increased up to 490 Kpps (100-byte packets);
5.2 End-to-end benchmarks (b) End-to-end maximum TCP throughput. Attack traffic
For end-to-end measurements, our server is a 1 GHz In- rate, and TCP throughput are in Mbps.
tel P-III processor with 256 MB RAM, 256 KB cache,
running an Apache Web Server on Linux 2.4.20 kernel. As seen from Figure 7(a), connection time with no
Legitimate traffic is generated using the httperf [23] tool middlebox on the data path increases as attack traffic rate
which issues HTTP requests to the Web server. Both the grows. After around 14 Kpps, the Web server can no
client and the server are connected to a Gigabit Ethernet longer handle the traffic and httperf client times out. The
switch. Spoofed attack traffic is generated using IXIA, timeout interval is set to be 10 seconds. At this moment,
which is connected to the fiber optical port of the switch. the server dies. With the middlebox on the data path, con-
All traffic goes via a routing element running XORP. For nection time for legitimate clients remains constant even
our prototype, we do not include attack detection and use as attack rate increases all the way to 450 Kpps.
a trigger to install the middlebox on the data path. Throughput. Fig. 7(b) shows end-to-end performance
Our evaluation metrics are connection time, measured (measured using iperf) over time as the server is attacked,
using httperf, and max TCP throughput attainable be- middlebox enters dynamically into the data path, boot-
tween a legitimate client and the server, measured using straps, filters out attack traffic, and, after the attack sub-
iperf [14]. sides, is removed from the data path.
Latency. In Figure 7(a), X axis represents the attack Before the attack starts, maximum TCP throughput be-
rate in Kilo packets per second (100-byte packets), Y- tween client and server is 94.3 Mbps. As the attack be-
axis represents connection time in milliseconds. For gins, it drops to 3.88 Mbps. After t = 10 seconds, the
server content, we used www.amazon.com homepage middlebox is dynamically introduced on the data path.
(copied on April 17, 2006). Its size is 166 KB. During the 6-second bootstrap phase, the middlebox es-
For one legitimate connection, no attack traffic and no tablishes state for ongoing connections, and throughput
middlebox on the data path, connection time is 16.4 ms. slowly increases to 21.7 Mbps (the increase is due to
With the middlebox on the data path, but still no attack, dropping of spoofed SYN requests - these packets do not
connection time increases to 16.5 ms. For ten concurrent get to the server, because the TCP handshake between the
connections, total connection time increases from 121.1 attacker and the middlebox is not completed). All data
ms to 121.5 ms. packets, whether spoofed or legitimate, are forwarded to-
wards the server during the bootstrap phase (note, how- cause high collateral damage). In contrast, our scheme
ever, that the attack traffic rate stays below 14 Kpps). At intercepts both directions of traffic and supports both
t = 16, the middlebox enters its active mode, and starts stateless and stateful policies to enable better differen-
aggressively profiling and filtering traffic. All spoofed tiation between benign and malicious traffic.
traffic is dropped in this phase. Throughput now in- Several designs for re-engineering the Internet in-
creased to 87.3 Mbps. At t = 1500, the attack stops, frastructure have resistance to denial of service attacks
and the middlebox remains on the data path for the next among their objectives [30, 31]. With indirection as the
300 seconds. This interval (pre-determined) is used to first-class principle of packet routing, these networks can
time out the state for connections that were established easily reroute attack traffic to filtering devices by chang-
via the middlebox during the active phase. At t = 1800, ing the mappings between identifiers and hosts. The
throughput returns to the normal (no attack, no middle- scheme proposed in this paper is incomparable, because
box) 94.3 Mbps level. our goal is a solution that is fully compatible with and
transparent to the existing Internet infrastructure.
6 Related Work Other network-based defenses, all requiring router
Defenses against denial of service have been a subject modification, include route-based packet filtering [25],
of very active research, and the survey in this section statistical analysis of incoming packets [18] and router
is necessarily incomplete. Unlike previously proposed throttles [38]. An evaluation of router-based defense sys-
network-based defenses, dFence is completely transpar- tems can be found in [34].
ent to the existing Internet infrastructure. Unlike proxy- Victim- and source-based mitigation. These defenses
based solutions, dFence uses novel dynamic introduction are deployed either at the servers, or at the ingress
mechanisms to provide on-demand protection only when routers, and thus necessarily require substantial modifi-
needed. dFence middleboxes can be quickly re-deployed cations to the existing software base. Server-based solu-
to protect a different subset of end hosts without any tions also tend to be ineffective against last-mile band-
modifications. width flooding attacks.
Network-based mitigation. Defenses based on secure Kill-Bots [16] uses client legitimacy tests such as re-
overlays [2, 17] assume that all packets enter the net- verse Turing tests to differentiate between benign and
work through the overlay’s access points. The overlay malicious requests. In [32], victim servers encourage le-
checks each packet’s legitimacy and filters out attack traf- gitimate clients to “crowd out” malicious flows by send-
fic. This method requires that the destinations’ true IP ing higher volumes of traffic. In Pi [35], routers insert
addresses remain secret, and is thus difficult to combine path identifiers into unused spaces within IP packet head-
with the existing Internet infrastructure. Similarly, Fire- ers; servers then drop packets arriving on known attack
break [11] assumes that the attacker does not know the paths. This requires modifications to both routers and
targets’ IP addresses, and that packets are tunnelled to the servers, and may cause collateral damage if a legitimate
destinations by proxies deployed at edge routers. This re- source shares the route with an attacker. D-WARD [22]
quires software modification at legacy routers. uses anomaly detection and compliance with traffic man-
Defenses based on capabilities such as SIFF [36] and agement measures to differentiate benign and malicious
TVA [37] require that (i) destinations issue unforgeable flows. Malicious flows are then blocked or rate-limited at
tokens to legitimate sources, and (ii) routers filter out source routers. Deployment requires wide-scale modifi-
packets that do not carry these tokens. Both router and cation of router software. Ingress filtering [10] is limited
server software must be modified to support capabilities, to spoofing attacks, and also requires router modification.
and servers must be able to differentiate benign and ma- Many methods have been proposed for detecting de-
licious traffic. Flow Cookies [6] use the timestamp field nial of service activity [12, 33, 28] and tracing back the
in packets to insert cookies, and require server modifica- sources of the attack [27, 29]. Our focus in this paper
tions to differentiate benign and malicious flows. is on transparent, scalable mitigation rather than detec-
Pushback [21] rate-limits flows responsible for traf- tion, and our solution is compatible with most proposed
fic congestion, and pushes filters upstream towards the detection and traceback mechanisms.
sources of these flows. Router software must be mod-
ified. Rate-limiting is a coarse technique that does not 7 Conclusions and Future Work
differentiate between benign and malicious traffic, and We described the design and prototype implementation
may thus cause high collateral damage. of dFence, a novel network-based system for transpar-
Cisco Guard [8] is a commercial product that dynam- ently mitigating denial of service attacks. The main ad-
ically redirects traffic to “cleaning centers” within the vantages of the dFence middleboxes are their compati-
network. Traffic interception is not bi-directional; only bility with the existing Internet infrastructure—they are
traffic from client to server is intercepted. Cisco Guard introduced into the network using standard routing mech-
applies several stateless filtering policies, and uses rate- anisms, and their operation is completely transparent to
limiting to reduce traffic volume (which may potentially the protected end hosts—and their ability to support a
broad range of effective anti-DoS techniques. Control [12] T. Gil and M. Poletto. MULTOPS: A data-structure for bandwidth
over both directions of TCP connections and efficient attack detection. In Proc. USENIX Security, 2001.
data structures for managing partial connection state en- [13] M. Handley, E. Kohler, A. Ghosh, O. Hodson, and P. Radoslavov.
Designing extensible IP router software. In Proc. NSDI, 2005.
able several new defenses against denial of service, and
make possible on-demand deployment of defenses in the [14] Iperf. The TCP/UDP bandwidth measurement tool. http://
dast.nlanr.net/Projects/Iperf/, 2003.
middle of the network. Our experimental evaluation
[15] IXIA. http://www.ixiacom.com, 2006.
demonstrates that dFence provides effective protection
[16] S. Kandula, D. Katabi, M. Jacob, and A. Berger. Botz-4-Sale:
against distributed DoS attacks at a minimal performance Surviving organized DDoS attacks that mimic flash crowds. In
cost. Moreover, there is no impact whatsoever on traffic Proc. NSDI, 2005.
to servers that are not experiencing DoS attacks. [17] A. Keromytis, V. Misra, and D. Rubenstein. SOS: Secure Overlay
Future work includes investigation of mechanisms for Services. In Proc. SIGCOMM, 2002.
configuration and management of dFence middleboxes, [18] Y. Kim, W. Lau, M. Chuah, and J. Chao. PacketScore: Statistics-
as well as design and implementation of an extensible based overload control against distributed denial-of-service at-
tacks. In Proc. INFOCOM, 2004.
scripting language for rapid development of new anti-
[19] R. Kokku, U. Shevade, N. Shah, A. Mahimkar, T. Cho, and
DoS policies. Another research objective is a better un- H. Vin. Processor scheduler for multi-service routers. In Proc.
derstanding of adaptive attacker behavior and designing RTSS, 2006.
defenses against attackers who are aware of the anti-DoS [20] J. Lemon. Resisting SYN flood DoS attacks with a SYN cache.
middleboxes and deliberately craft their attack patterns to In Proc. BSDCon, 2002.
evade mitigation policies. This includes game-theoretic [21] R. Mahajan, S. Bellovin, S. Floyd, J. Ioannidis, V. Paxson, and
modeling of adversarial interaction between the middle- S. Shenker. Controlling high bandwidth aggregates in the net-
boxes and the attackers. Finally, we would like to extend work. CCR, 32(3), 2002.
dFence to environments with multiple ISPs. [22] J. Mirkovic, G. Prier, and P. Reiher. Attacking DDoS at the
source. In Proc. ICNP, 2002.
8 Acknowledgements [23] D. Mosberger and T. Jin. httperf: A tool for measuring web server
performance. Performance Evaluation Review, 26(3), 1998.
We are grateful to the anonymous NSDI reviewers and
[24] D. Pappalardo and E. Messmer. Extortion via DDoS on the rise.
our shepherd Eugene Ng for insightful comments. Their Network World, May 16 2005.
suggestions have significantly improved our paper. We [25] K. Park and H. Lee. On the effectiveness of route-based packet
thank Tae Won Cho and Upendra Shevade for helpful dis- filtering for distributed DoS attack prevention in power-law inter-
cussions. Finally, we thank National Science Foundation nets. In Proc. SIGCOMM, 2001.
for sponsoring the research under grant CNS-0546720. [26] Prolexic. The Prolexic Zombie Report. http://www.
prolexic.com/zr/, 2007.
References [27] S. Savage, D. Wetherall, A. Karlin, and T. Anderson. Network
[1] S. Agarwal, T. Dawson, and C. Tryfonas. DDoS mitigation via support for IP traceback. IEEE/ACM Trans. Netw., 9(3), 2001.
regional cleaning centers. Sprint ATL Research Report RR04- [28] V. Sekar, N. Duffield, K. van der Merwe, O. Spatscheck, and
ATL-013177, January 2004. H. Zhang. LADS: Large-scale automated DDoS detection sys-
tem. In Proc. USENIX, 2006.
[2] D. Andersen. Mayday: Distributed filtering for Internet services.
In Proc. USITS, 2003. [29] A. Snoeren, C. Partridge, L. Sanchez, C. Jones, F. Tchakountio,
S. Kent, and W. Strayer. Hash-based IP traceback. In Proc. SIG-
[3] ANML. DDoS attack tools. http://anml.iu.edu/ddos/ COMM, 2001.
tools.html, 2001.
[30] I. Stoica, D. Adkins, S. Zhuang, S. Shenker, and S. Surana. Inter-
[4] D. Bernstein. SYN cookies. http://cr.yp.to/ net indirection infrastructure. In Proc. SIGCOMM, 2002.
syncookies.html, 1996.
[31] M. Walfish, J. Stribling, M. Krohn, H. Balakrishnan, R. Morris,
[5] A. Broder and M. Mitzenmacher. Network applications of Bloom and S. Shenker. Middleboxes no longer considered harmful. In
filters: A survey. Internet Mathematics, 1(4), 2004. Proc. OSDI, 2004.
[6] M. Casado, A. Akella, P. Cao, N. Provos, and S. Shenker. Cook- [32] M. Walfish, M. Vutukuru, H. Balakrishnan, D. Karger, and
ies along trust-boundaries (CAT): Accurate and deployable flood S. Shenker. DDoS defense by offense. In Proc. SIGCOMM, 2006.
protection. In Proc. SRUTI, 2006. [33] H. Wang, D. Zhang, and K. Shin. Detecting SYN flooding attacks.
[7] Cisco. Policy-based routing. http://www.cisco.com/ In Proc. INFOCOM, 2002.
warp/public/732/Tech/plicy_wp.htm, 1996. [34] Y. Xu and R. Guerin. On the robustness of router-based denial-
[8] Cisco. Cisco Guard DDoS mitigation appliances. http:// of-service (DoS) defense systems. CCR, 35(3), 2005.
www.cisco.com/en/US/products/ps5888/, 2007. [35] A. Yaar, A. Perrig, and D. Song. Pi: A path identification mecha-
nism to defend against DDoS attacks. In Proc. IEEE S&P, 2003.
[9] D. Dagon, C. Zou, and W. Lee. Modeling botnet propagation
using time zones. In Proc. NDSS, 2006. [36] A. Yaar, A. Perrig, and D. Song. SIFF: A stateless Internet flow
filter to mitigate DDoS flooding attacks. In Proc. IEEE S&P,
[10] P. Ferguson and D. Senie. Network ingress filtering: De- 2004.
feating denial of service attacks which employ IP source ad-
dress spoofing. http://www.faqs.org/rfcs/rfc2827. [37] X. Yang, D. Wetherall, and T. Anderson. A DoS-limiting network
html, 2000. architecture. In Proc. SIGCOMM, 2005.
[38] D. Yau, J. Lui, F. Liang, and Y. Yam. Defending against dis-
[11] P. Francis. Firebreak: An IP perimeter defense ar- tributed denial-of-service attacks with max-min fair server-centric
chitecture. http://www.cs.cornell.edu/People/ router throttles. IEEE/ACM Trans. Netw., 13(1), 2005.
francis/hotnets-firebreak-v7.pdf, 2004.