Using Capability to prevent
Internet Denial-of-Service attacks
 Tom Anderson
 Timothy Roscoe
 David Wetherall
 Offense Team
– Khoa To
– Amit Saha
What is a DoS attack?
“An incident in which a user or organization is deprived of
the services of a resource they would normally expect to
have. Typically, the loss of service is the inability of a
particular network service, such as e-mail, to be available
or the temporary loss of all network connectivity and
services”
Fundamental Idea of the Proposal
 A destination can grant as much incoming
traffic as it wants.
 By being able to
control the rate of
incoming traffics,
DoS at the destination
can be prevented.
RTS Servers vulnerable to DoS
F
BW =
(z% * W)/k Mbps
G
BW = W Mbps
B
E
A
D
C
DoS requires:
DoS requires:
Y compromised hosts to choke bandwidth
(z% * W) / k << W
=> X >> Y
X compromised hosts to choke
bandwidth W
Distributed DoS attack
 Even if the number of hosts behind an RTS
(nodes in an AS) is too small to choke RTS
bandwidth, distributed attacks are possible
from other RTS servers.
Compromise
d clients
Compromise
d clients
Compromise
d clients
Compromise
d clients
Effect of DoS attack on RTS
servers
 Even though the data channel is free no new
connections are allowed since the RTS
channel is choked up.
RTS-Server attacks only affect
new flows?
 Yes, but how long can existing flows last?
– Example: A Web server
• Most clients are unknown & untrusted
• => Should only grant limited bandwidth for a short
time (i.e. short hash chains), on the order of minutes
• After RTS servers are attacked, existing clients can
only serve the web for 20 minutes. All new requests
are denied.
What data rate should a
destination grant each client?
 Is traffic rate determined per hash chain? Or each
key of all chains have the same values, only
changed by BGP advertisements?
– Not clear from the paper
 If rate is changed by BGP advertisements
– Too slow to keep up with dynamic traffic loads
 If rate is determined per hash chain
– Duration of each chain for each client can still make
rate adjustment too slow
Other (minor) problems
Not all clocks run at the same
rate:
=> VP might decides that a
token expires before the client
thinks so.
Even small packets have to
carry 64-bit overhead
Unnecessary requirement
 Why does the paper assume that an attacker
cannot snoop the values sent to the source?
– If the attacker is not on the same network with the
source, then it cannot spoof packets because of
ingress/egress filtering.
– If the attacker is on the same network as the source,
then it can launch other more effective DoS against that
client.
 If the assumption is valid, then how do you
achieve that?
– Encrypt packets? – Too expensive, not scalable
Policy management problem
 Where are the policies maintained?
– RTS servers?
• Too many server applications (millions) to manage.
• Problems with updating policies
– Each application?
• Applications (client & server) need to be changed.
Backup slides
RTS Servers vulnerable to DoS
Attackers need to compromise lesser percent of
nodes in the “node pool” to compromise RTS servers
Compromised
Uncompromised
100x
Nodes in the Internet
30x
Nodes in an AS