1. FastPass: Availability Tokens to Defeat DoS Presented at CMU Systems Seminar by: Dan Wendlandt Work with: David Andersen & Adrian Perrig

2. Bandwidth exhaustion attacks require infrastructure support Loss at router buffers, before reaching endhost

3. Basic Idea: Availability tokens Allow Internet destinations to provide clients with an “availability token” through an arbitrary out-of-band mechanism that guarantees Internet availability regardless of host resource capacity OR the number of attackers.

4. Stateless Router-based Capabilities: A useful building block Source Destination xx 92xx 9234xx923414 923414 Give priority?

5. Problem: Denial-of-Capability First packet is sent without capability This request channel is subject to packet floods (DoC). Back where we started? NO!

6. New Requirement: One packet Instead of protecting a flow that can be adversely affected by even low loss percentages, we now must only get ONE PACKET through.

7. Possible Approaches “Dumb” Routers: Best-effort traffic, rely on probability… “Fair” Routers: Try to give everyone an equal chance… “Informed” Routers: Infrastructure is told by destinations what packets to prioritize

8. Availability in a Next-Gen architecture ( m2m ) ? Many more hosts Diverse end-host resources (bandwidth & computation) Greater cost of being unreachable More stringent requirements for time to establish a connection

9. How to compare? Time-to-Capability (TTC) Robustness to uncooperative infrastructure Cost/complexity to deploy Assumptions about topology or client resources Scalability & nature of collateral damage

10. Today: Incremental Improvements All previous schemes increase the number of attacker resources needed to totally deny availability to a destination, but do not offer fundamentally secure availability.

11. Goal: Setting a Higher Bar We want arbitrary hosts to be able to communicate without delay regardless of their location in the Internet topology or their local resources. Subject only to provisioning the purchase from their network service provider. Total Network Capacity Control

12. Availability Tokens Extra data in the capability header that proves to forwarding routers that the destination wishes to accept the request packet Link Header IP Header Capability & Token Transport Level Header & Data Request Packet

13. Examples Destinations outsource token distribution to Akamai, which requires proof-of-work, etc to provide token. Protected by bandwidth & geographic diversity An online brokerage uses a one-time- password tool to generate tokens. Small company provides private key to employees along with VPN software.

14. A flavor of three schemes Public Key Scheme Iterative Capability Discovery Hash-Chain Scheme WARNING! Important Details Omitted due to time-constraints

15. Public Key Scheme Private key generates token as a signature, public key distributed to all routers. Routers verify signature and check for duplicate or expired tokens. Main Challenge: Crypto cannot be DoS-able.

16. Iterative Capability Discovery Use partial router capabilities to protect “discovered” portions of the path. At congested points, encrypt capabilities THROUGH congested router with public key of destination, “punt” it back to client. Dest. authorizes client by decrypting these capabilities. Iterate.

17. Iterative Discovery (1) Source Destination 4xx46x 46x Encrypted with Dest. Public key Returned to Source Congestion!

18. Iterative Discovery (2) 46x Source Akamai+ Proof of Work / Identity 46x Unencrypted Capability

19. Iterative Discovery (1) Source Destination 46x Congestion! Partial Capability works as token to get request through congested router

20. Lightweight Hash-Chain Scheme Idea: Replace public key crypto with symmetric, using a shared router + destination secret. This comes at the cost of robustness to compromised routers. How to make this work in today’s architecture & routers?

21. Lightweight Hash-Chain Scheme D H_1 = Hash(H_0) Destination has secret H0 H_2 = Hash(H_1) AS X AS Y AS DAS C AS B AS A

22. Hash-Chain tokens Destination can compute all H_i, and provides source S with sequence of Hash(S-address, H_i) pairs. Compromised of key H_i only impacts routers at a radius >= i from the source.

23. Thanks! Interested in chatting or reading a SIGCOMM draft? Let me know! danwent@gmail.com http://www.cs.cmu.edu/~dwendlan/