2008 Second International Conference on Future Generation Communication and Networking
Joint application and network defense against DDoS
flooding attacks in the future Internet
Roger P. Karrer Ulrich Kuehn
Deutsche Telekom Laboratories Sirrix AG
TU Berlin, Germany Bochum, Germany
roger.karrer@telekom.de ukuehn@acm.org
Abstract— The threat of Denial of Service flooding attacks in
the Internet is rapidly increasing. Especially the use of techniques
that allow attackers to hide their attack traffic raises concerns:
attack distribution and rotation in botnets to obfuscate senders,
low-rate bandwidth attacks, and attacks that mimic realistic
patterns such as flash crowds. The defense against such attacks
is limited due to a deadlock: the attacks must be stopped inside
the network, but the network is unable to distinguish legitimate
and unsolicited traffic. In contrast, end systems may distinguish
legitimate users from bots, but are unable to stop the attacks
inside the network. This paper advocates for a joint end system
- network defense to address such attacks in the future. Edge-
based Capabilities (EC) is a novel framework that combines end-
to-end authentication with network-based control. Applications
authenticate legitimate senders and issue capabilities to tag their
packets, and the network filters out untagged packets. This paper
describes the mechanisms that make EC a secure, efficient, and
scalable solution. Moreover, we argue that EC is an attractive
solution because it can be incrementally deployed and because it
provides the right incentives to users, servers, and ISPs.
I. I NTRODUCTION
The Internet has been built on several design goals and
principles [2], among them that (i) all parties can be trusted
and (ii) the end-to-end argument. This argument advocates for
placing functionality at the end systems rather than into the
network. The combination of these two principles has resulted
in a purely end-user control over the end-to-end resources, of
which TCP implements the concept of sharing the resources.
Unfortunately, a plethora of end systems emerged who can no
longer be trusted and who deliberately abuse the power over
resource control. One of these results are Denial of Service
(DoS) attacks.
DoS attacks today are a severe threat to the Internet. A
study estimated that a massive attack on critical Internet
elements for one week will produce an economic damage
on an entire national economy of 5.83 billion Swiss Franc,
or 1.2% of the GDP 1 . Even though a recent survey on
DoS attacks [8] shows that DoS attacks may take different
forms, target different resources and be launched at different
levels, we notice one particular trend in the history of DoS
attacks: that towards stealthy attacks. Originally, DoS attacks
were brute force attacks, launched from a single machine. As
defense mechanisms against such attacks were put in place
1 source: www.mi2g.com
978-0-7695-3431-2/08 $25.00 © 2008 IEEE
DOI 10.1109/FGCN.2008.168
Authorized licensed use limited to: VELLORE INSTITUTE OF TECHNOLOGY. Downloaded on July 09,2010 at 09:50:55 UTC from IEEE Xplore. Restrictions apply.
Thomas Huehn
Deutsche Telekom Laboratories
TU Berlin, Germany
thomas@net.t-labs.tu-berlin.de
and improved, attackers had to find new ways to defy these
mechanisms. As a result, modern DoS attacks are typically
originating from large botnets, launching a Distributed Denial
of Service (DDoS) that overwhelms the resources. Moreover,
the attack pattern aims at creating either non-suspicious traffic
patterns, such as mimicking high-rate legitimate user traffic
(e.g. flash crowds), or to create low-rate attacks like the
Shrew attack [7] that exploit protocol-specific weaknesses. As
a result, modern DDoS attacks are sophisticated and therefore
virtually undetectable by a defender.
Given these threats, we argue that we must address the root
cause of the DDoS attacks, not try to find yet another clutch -
and the root cause lies in the design principles of the Internet:
trust and end-to-end control. But what alternative principles
could be defined? Simply turning by 180 degrees and claiming
that (i) all end users are by default untrusted and (ii) resource
control should be controlled by the network does not seem to
be an appealing solution either: now all control is given to the
network, and all users would permanently be required to proof
their identity and confirm their non-abusive behavior.
Thus, we argue that in a future network, a joint control must
be established between end users and the network to defy those
DDoS attacks that target networking resources, i.e. flooding
attacks on links and routers. A joint control might even solve
one of the biggest dilemmas in today’s DDoS flooding attacks:
the attacks occur inside the network and thus a mechanism
must contain and limit the attack traffic - but how can the
network distinguish legitimate from unsolicited packets? In
fact, all a router sees is IP packets. It has no knowledge
of the sender, its legitimacy. In contrast, the application has
the potential to make the distinction between legitimate and
unsolicited users, but has no chance to defy the attack because
it occurs inside the network, i.e. before the packets reach the
client.
This paper proposes Edge-based Capabilities (EC), a frame-
work that provides the basic mechanisms for a joint application
and network defense. EC provides abstractions and protocols
that cryptographically tag legitimate traffic and control the
behavior and resource consumption of non-tagged and wrongly
tagged traffic. Senders in EC can generate tags when they
obtain a permission to send (a capability [1], in our case a
cryptographic key) from the intended receiver. At the network
edge, a network element termed gate enforces that only tagged
11
 traffic is forwarded directly, whereas untagged or wrongly-
tagged traffic is treated as potentially malicious traffic. The
gate therefore creates a differentiation that prioritizes legiti-
mate traffic.
The contributions of this paper are three-fold. First, we
develop the EC framework. The main challenge is to derive a
distributed mechanism for a secure and efficient information
exchange among gates, senders, and receivers to identify,
tag and control legitimate traffic. This paper defines the key
building blocks upon which a joint control can be built. Being
a framework that emphasizes design reuse, we show how
currently known protocols and solutions, such as CAPTCHAs,
can be integrated into EC.
Second, we discuss the relationship between the need to
find a technically sound solution to defy DDoS attacks on one
hand and the deployability on the other. We show that EC
(i) aligns the deployment cost with benefit and control, (ii) is
deployable by a single ISP (i.e. does not need collaboration
with other ISPs and/or all end systems), and (iii) does not
shut out users that do not participate in EC. We argue that
these incentives make EC an appealing solution, in contrast to
previous proposals, such as IP traceback systems [9], [11], that
never got deployed in reality because they lacked the above
incentives.
Finally, we briefly assess the effectiveness of EC in a local
testbed with a linux-based implementation.
This paper is organized as follows. Section II gives an
overview of unsolicited traffic and the concept of EC. Sec-
tion III provides details on the EC architecture and discusses
the deployment benefits, in particular the incentives to all
parties. Next, we briefly highlight the effectiveness of EC
using a Linux-based implementation of EC in a local testbed
in Section IV. Then, after comparing EC against related work
in Section V, Section VI concludes the paper.
II. BACKGROUND
We consider the frequently occurring DDoS attacks from
botnets onto a single target as depicted in Figure 1. The
coordinated attack traffic converges in the access network of
the aggregated traffic overwhelms the bottleneck link there.
Due to the overload, legitimate packets are unable to reach
the destination. Thus, the service of the server is denied to
legitimate users. This denial is devastating for servers that offer
online transactions, such as banks, travel agencies.
These DDoS attacks are hard to defend against for four
reasons. First, the capacity of the access link is several orders
of magnitude lower than that of the core links. The access link
is therefore a ”natural” bottleneck. Second, today’s BotNets
may be as large as a million zombies. Each bot can send traffic
at an unsuspiciously low rate. Third, modern DDoS attacks are
by far more sophisticated than initial attacks. Modern low-rate
DoS attacks, such as the Shrew [7] attack, exploit protocol
properties to reduce the sending rate. Other attacks disguise
the attack traffic by mimicking e.g. flash crowds [5]. This
sophistication adds to the difficulties in detecting attack traffic.
Finally, the server or user behind the access link has no means
12
Authorized licensed use limited to: VELLORE INSTITUTE OF TECHNOLOGY. Downloaded on July 09,2010 at 09:50:55 UTC from IEEE Xplore. Restrictions apply.
zombies
core
network service
denied
legitimate
client edge
X target server
network
zombies
Fig. 1. DDoS attack on an access network.
to counter the attack because it has no influence on the access
link.
To counter modern flooding attacks on the network infras-
tructure, the following challenges have to be addressed:
• Identification: Unsolicited traffic must be reliably identi-
fied inside the network.
• DDoS mitigation: Unsolicited traffic must be isolated and
filtered out.
• Efficiency: The overhead of identifying and filtering traf-
fic must be negligible. It must not depend on the number
of flows.
• Technical deployability: The solution must be easily,
readily and partially deployable. Changes in protocols
(e.g. TCP), architectural changes (e.g. modifications in In-
ternet routers), or collaborations of multiple entities (e.g.,
multiple ISPs) should be avoided. Necessary changes
should be coupled with incentives.
• Economic incentives: The solution must have a direct
benefit for all involved parties.
III. EC A RCHITECTURE
Our approach to confine and mitigate the effects of DDoS
attacks, termed edge-based capabilities (EC), leverages and
combines the strengths of end-to-end authentication and net-
work-based packet control mechanisms.
A. Overview
EC introduces a network element termed gate, as depicted
in Figure 2. The gate protects the server-side bottleneck
from flooding attacks by filtering unsolicited traffic. To define
legitimate traffic, the receiver (or simply “server”) issues a
capability to those senders (“clients”) that are considered
legitimate. These capabilities contain keys that allows the
clients to produce cryptographic tags that are included in every
packet. The gate verifies the tags and forwards only success-
fully verified packets, or gives legitimate packets priority over
untagged packets.
Gate, server, and client must share the key to tag pack-
ets and to verify the tags. For this purpose, EC requires
secure protocols and key management procedures with high
performance and scalability. Moreover, a secure information
exchange among the three components is needed.

Fig. 2. EC components and their interactions.
For the following exposition we make a set of assumptions
but will discuss how to relax them in Section III-E. First,
we assume that the gate possesses sufficient processing power
to avoid becoming a bottleneck itself, i.e., its resources must
exceed the link capacities of both links (to the core and to
the server respectively). Second, we limit the exhibition to
the case of protecting access networks against traffic from
the core. However, our solution can also be applied in the
reverse direction, e.g. to prevent traffic from leaving the access
network. Third, we assume that only one path exists between
the gate and an associated server. That is, all traffic towards
a server flows exactly through one gate. This assumption can
be ensured by placing the gate close to the server.
The first challenge, i.e. secure information exchange, re-
quires an identification of the roles of each component. The
gate, server, and client are likely to belong to different
administrative domains - so who is considered trustworthy
in the information exchange? The gate is the most crucial
component in EC. It is therefore the most trusted entity, as
it offers the service to control and block traffic. We decided
to build the information exchange around the gate. Servers
are semi-trusted: they usually can be trusted, but there is
no guarantee. Moreover, servers are directly in touch with
potentially malicious clients and are therefore easier subject to
compromise. Finally, clients are only minimally trusted. This
trust model is also reflected in the key management discussed
below, where the gate is the logical center of a hierarchy of
cryptographic keys.
For solving the second challenge, designing efficient and
scalable protocols and procedures, we break the communica-
tion and computation in EC into three architectural building
blocks:
• Keying scheme: defines how cryptographic keys are de-
rived, managed, and used at the gate, the server, and the
client.
• Tagging scheme: defines how tags are computed and
verified given a cryptographic key.
• Key transport scheme: specifies how the keys are ex-
changed among gate, server, and client.
In the remainder of this section, we describe a possible
implementation for these blocks. Note, however, that these
schemes and their parameters can be customized and extended
13
Authorized licensed use limited to: VELLORE INSTITUTE OF TECHNOLOGY. Downloaded on July 09,2010 at 09:50:55 UTC from IEEE Xplore. Restrictions apply.
to meet application- or scenarios-specific requirements or to
trade off security and efficiency.
B. Keying Scheme
The keying scheme defines how cryptographic keys are
derived, managed, and used at the gate, the server, and
the client. We propose a three-level key hierarchy for EC,
corresponding to the trust hierarchy of the component’s roles
outlined above. The root of the key hierarchy is the master
or gate key kG , which is kept secret at the gate and is never
conveyed to the outside.
Second level keys are server keys derived from the gate
key at the gate. This derivation can include server-specific
information, such as the IP address of server S, denoted as
IP(S). Thus, using a secure keyed one-way function kdf 1 we
compute kS ← kdf 1 (kG , IP(S)). This prevents a malicious
server from obtaining the gate key. The communication of
server keys from the gate to the respective servers is done us-
ing a secure channel, e.g. protected by transport-layer security
(TLS). Server keys are never revealed to any third party.
Third-level client keys or tagging keys are derived from
the corresponding server key based on session-specific in-
formation. Using a secure keyed one-way function kdf 2 we
compute the tagging key as kT ← kdf 2 (kS , IP(C), IP(S)),
where IP(C) denotes the client’s IP address. Here a malicious
client is prevented from obtaining the server key. The server
transmits kT to the client.
The design of the keying scheme has three important
properties. First, the hierarchy is based and maintained using
symmetric cryptographic methods, and does not resort to
a PKI. Thus it is very light-weight regarding performance
impact.
Second, the trust-based three-level hierarchy ensures that the
least trusted components receive the most specific keys, i.e.
the tagging keys are valid for exactly one client-server pair.
Further, the scheme provides key separation, it does not allow
to compute other client’s keys from one’s own client key, and
likewise for server keys. If a server key is compromised and
an attack is launched, the gate may choose to filter all packets
targeted to that server to ensure that at least other servers
attached to the same access network continue their service.
Third, EC allows a stateless gate and key separation, i.e. all
lower-level keys can be derived from the the central master
key kG on demand. Therefore, the keying scheme scales to an
arbitrary number of servers and clients. To reduce per-packet
calculations, keys may be cached at the gate.
Finally, an ISP that installs a gate should protect the gate
as efficiently as possible. The gate itself can be deployed
as a separate entity that does not need to be visible to the
traffic. Gate manipulations, including server management, can
be restricted to a single machine that runs within the same ISP
network. The ability to control the root of the keying hierarchy
is also coupled to the main incentives behind EC. Therefore,
maintaining control at the gate is important to react to potential
break-ins.
 C. Tagging Scheme
The tagging scheme describes how the tag for a packet is
computed given the cryptographic key kT and how the tag
is verified at the gate. It is the protocol part of EC that is
prominently visible on the IP layer. The main challenge here
is to prevent an adversary from forging tags based on observed
correct tags, or even recovering a tagging key. Moreover, the
tag verification must be scalable, i.e. not have a severe impact
on gate performance even when a large number of concurrent
flows passes through the gate.
To fulfill these requirements, EC employs a cryptographi-
cally secure message authentication code (MAC) to authen-
ticate certain header fields of the packet. Formally, a MAC
scheme is a pair of (possibly) randomized algorithms Mac :
{0, 1}k × {0, 1}∗ → {0, 1}t for tagging and Ver : {0, 1}k ×
{0, 1}∗ × {0, 1}t → {0, 1} verification with parameters k and
t for key and tag lengths.
The data of a packet P that is included in the tag compu-
tation and verification consists of the tuples2
Mhdr (P ) ← (IPsrc (P ), IPdst (P ), Len(P ), Ident(P ))
from the IP header, and for a TCP packet we additionally
include
Mtcp (P ) ← (Portsrc (P ), Portdst (P ), Seq(P ), Ack(P )) (2)
(or Mtcp (P ) ← () for non-TCP packets) to set up the input
to the tagging and verification operations as
M (P ) ← (Mhdr (P ), Mtcp (P )).
The maximal total size of M (P ) is 192 bits. Now the tag
handling is as follows:
Client:The client tries to retrieve the tagging key kT from
its internal key storage for each packet P it sends to
the server S. If no key is available, the packet is sent
untagged. Otherwise the client computes τ (P ) ←
Mac(k, M (P )) and includes τ (P ) in P .
Gate: For each packet P , the gate maintains a la-
bel λ(P ) ∈ {Untagged, Invalid, Valid} for further
queuing decisions: if a packet P is not tagged
λ(P ) ← Untagged. In contrast, if P carries a
tag, the gate obtains kT from its keying subsystem
using (IPsrc (P ), IPdst (P )). The gate extracts the
(alleged) tag τ ′ (P ) and M (P ), computes b ←
Ver(k, M (P ), τ ′ (P )), and sets λ accordingly. Based
on the label, the gate decides whether the packet
should be forwarded with high or low priority, or
dropped entirely.
D. Key Transport Scheme
The key transport scheme defines how the cryptographic
keys are exchanged between gate and server resp. server and
client.
2 This is IPv4-specific. Changes for IPv6 are straight-forward, with the flow
identifier instead of the ident field.
Authorized licensed use limited to: VELLORE INSTITUTE OF TECHNOLOGY. Downloaded on July 09,2010 at 09:50:55 UTC from IEEE Xplore. Restrictions apply.
For the communication between the gate and the server,
EC requires that each server registers itself at the gate or
the ISP, respectively, typically on the basis of a contractual
relationship. The server key is then transmitted to the server
over a secure connection. Key updates can be made at regular
intervals and/or on demand.
The key exchange between server and client for the crypto-
graphic tagging key kT must ensure that only legitimate users
are able to easily obtain the tagging key. The definition of a
legitimate client depends on the scenario or the application
preferences. Therefore, EC provides a framework that defines
the basic key exchange, but allows a customization towards the
scenario. In particular, the application defines which clients are
considered legitimate and how they have to prove their legit-
imacy. Here, we describe a potential implementation of a key
transport scheme between server and client that authenticates
a human, but otherwise anonymous user. This scheme makes
use of differential workfactors.
We cannot rely on the usual means of cryptographic authen-
tication, as the user might be a first-time user. Nevertheless,
(1) we must be able to distinguish a human from a machine
operating without a human user and might be part of a BotNet,
perpetrating a DDoS attack.
A popular end-to-end authentication for this purpose are
CAPTCHAs [10]. CAPTCHAs are designed to distinguish
humans from bots by AI problems that are easy to solve
for humans but are hard to solve with computational means
only. Besides this primary use, we additionally transport
information to a human via the CAPTCHA.
(3) Unfortunately, CAPTCHAs have the drawback of annoying
the user, in particular if the string to be entered is too long. We
therefore propose a method of combining CAPTCHAs with
a variant of client puzzles [3]. This method requires only a
low-entropy input from the CAPTCHA, but still allows good
strength against bots. We see this as a reasonable trade-off
between user annoyance and authentication strength.
On a high level, the combination works as follows. A client
puzzle works by requiring the client to invert a one-way
function, e.g. finding the input that hashes to a given value,
and can thus be scaled very easily. Our method now places
part of the solution into a CAPTCHA, so that the human that
can solve the CAPTCHA does actually help his/her machine
to faster solve the puzzle. On the other hand, the puzzle can
be scaled in such a way that BotNets are prevented from
discovering solutions automatically at a large scale.
The key point here is that the client puzzle allows that the
whole scheme can be adapted to compensate for increased
processing speed due to general technical development, so that
the rather short user input from the CAPTCHA can make a
real difference.
E. Discussion
The cryptographic tagging – packet-specific tags computed
from a client-server-specific key – binds packet header infor-
mation to the corresponding tagging key. This binding pre-
vents adversaries from including correct tags in packets with
14
 arbitrary IP addresses (without knowing the corresponding
key). Nevertheless, attackers can still eavesdrop on packets to
obtain IP headers with matching tags, and use them in spoofed
packets (replay attacks). However, replay attacks with EC
create pathological traffic patterns that can be easily detected
and isolated at the gate. Thus the success potential is low. A
similar argument applies to the case that any client misbehaves
(e.g. after being corrupted by an attacker) and sends large
amounts of data streams towards the server: the gate can
mitigate the attack by blocking the single client and/or re-issue
new server keys.
The keying scheme of EC is stateless to provide scalability.
However, a stateful keying scheme that generates new random
keys for each new flow is an alternative design option. A
stateful scheme eliminates the need for gate and server keys,
but requires that per-flow keys are generated and stored by
the gate and communicated to the server in real-time. Stateful
schemes therefore should only be applied if memory and real-
time communication overhead can be tolerated. Furthermore,
a combined stateful-stateless scheme can help to reduce the
impact of a key change on long-lived flows.
The implementation of EC in the current Internet architec-
ture is not straightforward. EC requires an initial permission
to send. TCP, the dominant transport-layer protocol, requires
an initial handshake. Thus, usually SYN packets will not be
tagged. At this stage, we will treat SYN packets in the gate as a
separate class of packets. Furthermore, SYN packets must not
carry payload. Therefore, the authentication exchange cannot
be embedded into the SYN packets. We expect, however, that
solutions will arise on how to deal with SYN packets, either
as part of the current or the future Internet architecture.
Similarly, a large number of protocols in the Internet do not
match the above client-server communication type, e.g. the
exchange of routing information or ICMP packets. In a real
deployment, these packets may also be treated separately at the
gate, at least at the current state of development. However, it
might be interesting to extend the concepts of EC to control
traffic in the Internet.
The current Internet architecture employs a set of hacks that
may pose obstacles to EC deployment. For example, NATs
modify the IP address in transit. In the presence of NATs,
the key transport must use the translated address to calculate
the tag. Eventually, we hope that the clean slate approaches
to the Internet design remedy some of the temporary Internet
patches.
F. Incentives
Besides the purely technical challenges, the question arises
how the deployment of EC could be motivated. Obviously,
the deployment requires some changes in the infrastructure.
However, EC provides the following incentives to the partic-
ipants. First, EC takes into account that not all parties can
be trusted equally. The three-level key hierarchy reflects this
trust hierarchy. Important is that the ISP which deploys the
gate is in control via the gate and the cryptographic keys. It
decides which and when keys are issued and can immediately
15
Authorized licensed use limited to: VELLORE INSTITUTE OF TECHNOLOGY. Downloaded on July 09,2010 at 09:50:55 UTC from IEEE Xplore. Restrictions apply.
react to a DDoS attack. Server providers have the incentive
to participate in EC because they receive protection from
the gate and because they receive higher priority from the
gate during a DDoS attack if their traffic is tagged. Finally,
clients also have the incentive to participate by receiving a
higher priority. However, the participation is not mandatory
for servers or clients - their traffic just receives lower priority.
Another incentive for ISPs is the business opportunity by
selling the protection to server providers. By installing and
controlling a gate, they can offer a protection that can not be
implemented at the end systems.
IV. E VALUATION
We implemented a proof-of-concept prototype of edge-base
capabilities to assess the efficiency and scalability of EC
and tested the gate in a lab setting as well as in a wireless
mesh network. We therefore implemented the keying and the
tagging scheme as part of the Linux netfilter framework of
the 2.6 kernel. Here, we only report one result to confirm the
efficiency of EC.
We set up a testbed that of four Pentium 4 PCs running
Linux 2.6 and connected via 100 Mbit/s full-duplex links.
Two hosts act as clients (legitimate and malicious), one as
gate and one as server. The legitimate client generates tagged
packets, the malicious client untagged packets. The gate is
equipped with a multiport ethernet card so that the traffic
to/from the clients does not affect each other on the wire. In its
basic configuration, the gate gives tagged packets strict priority
over wrongly or untagged packet. To generate traffic, we have
enhanced iperf to generate tagged and untagged traffic on
demand. Clients and gate are equipped with the tagging and
tag-verification kernel modules. The server is running both the
apache web server and iperf in server mode.
We assess EC’s ability to isolate attack traffic in the gate
and to mitigate its impact on legitimate traffic. The legitimate
client machines generates TCP traffic and we vary the attack
traffic from 10 to 94 Mbit/s in steps of 10 Mbit/s.
Figure 3 shows the average throughput of legitimate and
attack on the gate-server link, measured at the server network
interface. Without EC, Figure 3(a) shows that the ”gate” is not
able to distinguish legitimate and unsolicited traffic. Therefore,
the rates of the legitimate sender drop as a function of the
attack traffic.
In contrast, with EC (Figure 3(b)), the gate is able to
isolate the attack traffic. Since the gate gives strict priority
to legitimate traffic, the attack traffic is only able to use the
capacity unused by the legitimate traffic. Since TCP is able to
use the bandwidth most of the time, no attack traffic passes
the gate.
V. R ELATED WORK
Over the past years, several approaches have been presented
to address DDoS attacks. First, defense mechanisms at the
network layer have been developed against spoofed sources,
such as SIFF [12] and IP traceback schemes [9], [11]. Simi-
larly, TVA [13] builds a capability based on the path between
 User traffic Attack traffic VI. C ONCLUSIONS
100
This paper presents Edge-based Capabilities, an architecture
90

80
to mitigate DDoS attacks inside the network. The defense is
enabled by combining end-to-end authentication to identify
Throughput [Mbit/s]

70

60
legitimate users with a capability approach to tag and filter
50
unsolicited traffic inside the network. We argue that only a
40
joint defense is feasible to counter modern DDoS attacks
30
with sophisticated attack patterns launched from thousands of
20 distributed zombies.
10 From a deployment’s perspective, many previous ap-
0 proaches failed because they did not provide incentives. EC,
0 20 40 60 80 100
Injected attack traffic [Mbit/s] in contrast, provides the right incentives to all participants.
(a) Without EC.
In particular, EC offers ISPs a novel protection service that
can be commercially exploited. Moreover, since EC does not
User traffic Attack traffic require a coordination among multiple ISPs or a change of
100
multiple routers, EC can efficiently be deployed.
90
EC is also a step forward into the direction of a future
80
Internet design. Instead of asking binary questions on who
Throughput [Mbit/s]

70
should control the resources in the Internet and how and
60
where end systems and networks should be separated, EC
50

40
emphasizes the need for collaboration towards a joint defense.
30
We believe that a next generation Internet architecture must
20
combine technical, economical and social components because
10
each component is no longer suited to individually address
0
future security threats. Instead, joint solutions, as the one
0 20 40 60 80 100
Injected attack traffic [Mbit/s] described in this paper, are a much promising way to build
a secure future Internet.
(b) With EC.

Fig. 3. DDoS attack mitigation: TCP traffic

sender and receiver. Unfortunately, these approaches are not
suited to defend against modern botnets because the zombies
are hijacked end systems that generate the traffic, but do not
spoof traffic. Moreover, from a deployment point of view, they
require that a significant fraction of the Internet router must
be changed by different ISPs to be effective. In contrast, EC
already achieves its protection by deploying a single gate by
a single ISP or enterprise.
In parallel to network layer DDoS protection, mechanisms
to protect end system resources, e.g. for Web servers, have
been developed [5], [4]. Unfortunately, end system protection
is inefficient when packets are dropped before they reach the
end system.
EC has only limited similarity to IPsec. The authentication
header AH [6] of IPsec can ensure the integrity of the packet.
The overhead of IPsec is significant as it authenticates the
whole payload. Furthermore, it is a stateful, as it needs to
store a security association for each pair of communicating
machines. Both factors lead to a poor scalability. EC, in
contrast, is stateless, and our evaluation shows that EC has
a significantly lower computational overhead. Further, the key
exchange (IKE) of IPsec uses asymmetric cryptographic means
and thus has a rather large impact on connection setup times.
R EFERENCES
[1] T. Anderson, T. Roscoe, and D. Wetherall. Preventing internet denial-
of-service with capabilities. In HotNets II, 2003.
[2] D. Clark. The design philosophy of the darpa internet protocols. In
ACM SIGCOMM, Sept. 1988.
[3] D. Dean and A. Stubblefield. Using client puzzles to protect TLS. In
USENIX Security Symposium, 2001.
[4] W. Feng, E. Kaiser, W. Feng, and A. Luu. The design and implemen-
tation of network puzzles. In IEEE INFOCOM, 2005.
[5] S. Kandula, D. Katabi, M. Jacob, and A. Berger. Botz-4-sale: surviving
organized DDoS attacks that mimic flash crowds. In Proc. of NSDI,
2005.
[6] S. Kent and R. Atkinson. IP Authentication Header. Internet Request
for Comment RFC 2402, Internet Engineering Task Force, Nov. 1998.
[7] A. Kuzmanovic and E. Knightly. Low-rate TCP-targeted denial of
service attacks (the shrew vs. the mice and elephants). In Proc. of
ACM SIGCOMM, 2003.
[8] J. Mirkovic and P. Reiher. A taxonomy of DDoS attack and DDoS
defense mechanisms. ACM SIGCOMM Computer Communications
Review, 34(2):39–54, 2004.
[9] S. Savage, D. Wetherall, A. Karlin, and T. Anderson. Network support
for IP traceback. Transactions on Networking, 9(3):226–237, 2001.
[10] L. von Ahn, M. Blum, N. J. Hopper, and J. Langford. CAPTCHA:
Using Hard AI Problems for Security. In Eurocrypt, 2003.
[11] A. Yaar, A. Perrig, and D. Song. Pi: a path identification mechanism to
defend against DDoS attacks. In Proc. of IEEE Symposium on Security
and Privacy, 2003.
[12] A. Yaar, A. Perrig, and D. Song. SIFF: a stateless Internet flow filter
to mitigate DDoS flooding attacks. In Proc. of the IEEE Symposium on
Security and Privacy, 2004.
[13] X. Yang, D. Wetherall, and T. Anderson. A DoS-limiting network
architecture. In ACM SIGCOMM, 2005.

16

Authorized licensed use limited to: VELLORE INSTITUTE OF TECHNOLOGY. Downloaded on July 09,2010 at 09:50:55 UTC from IEEE Xplore. Restrictions apply.