Using Capability to prevent Internet DenialofService attacks

1
Using Capability to prevent Internet
Denial-of-Service attacks

• Tom Anderson
• Timothy Roscoe
• David Wetherall
• Offense Team
• Khoa To
• Amit Saha

2
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
3
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.

4
RTS Servers vulnerable to DoS
BW (z W)/k Mbps
BW W Mbps
F
G
B
E
A
D
C
gt X gtgt Y
5
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.

Compromised clients
Compromised clients
Compromised clients
Compromised clients
6
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.

7
RTS-Server attacks only affect new flows?

• Yes, but how long can existing flows last?
• Example A Web server
• Most clients are unknown untrusted
• gt 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.

8
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

9
Other (minor) problems
10
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

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

12
Backup slides
13
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