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

EB

C

A

D

DoS requires:

X compromised hosts to choke bandwidth W

BW = W Mbps

BW = (z% * W)/k Mbps

DoS requires:

Y compromised hosts to choke bandwidth (z% * W) / k << W

=> X >> Y

F G

A

B

C

GF

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

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

Nodes in the Internet

Nodes in an AS

30x

100x

Attackers need to compromise lesser percent of nodes in the “node pool” to compromise RTS servers

Compromised

Uncompromised