Using Capability to prevent Internet Denial-of-Service 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. F G B A C DoS requires: Y compromised hosts to choke bandwidth (z% * W) / k << W DoS requires: X compromised hosts to choke bandwidth W RTS Servers vulnerable to DoS BW = (z% * W)/k Mbps F G BW = W Mbps B E A D C => X >> 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 • => 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. 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 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