FastPass: Availability Tokens to Defeat DoS

Presented at CMU Systems Seminar by: Dan Wendlandt

Work with: David Andersen & Adrian Perrig

Bandwidth exhaustion attacksrequire infrastructure support

Loss at router buffers, before reaching endhost

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.

Stateless Router-based Capabilities:A useful building block

SourceDestination

xx xx xx 92 xx xx 92 34 xx 92 34 14

92 34 14 Give priority?

Problem: Denial-of-Capability

First packet is sent without capability This request channel is subject to packet

floods (DoC).

Back where we started?

NO!

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.

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

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

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

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

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

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

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.

A flavor of three schemes

Public Key Scheme Iterative Capability Discovery Hash-Chain Scheme

WARNING!Important Details Omitted due to time-constraints

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.

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.

Iterative Discovery (1)

SourceDestination

4 x x 4 6 x

4 6 x

Encrypted with Dest. Public key

Returned to Source

Congestion!

Iterative Discovery (2)

4 6 xSource Akamai+ Proof of

Work / Identity

4 6 x Unencrypted

Capability

Iterative Discovery (1)

SourceDestination

4 6 x

Congestion!

Partial Capability works as token to get request through congested router

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?

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 CAS BAS A

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.

Thanks!

Interested in chatting or reading a SIGCOMM draft? Let me know!

danwent@gmail.com

http://www.cs.cmu.edu/~dwendlan/