flow cookies bandwidth amplification as flooding defense

2005 Stanford Computer Systems Lab

Flow CookiesBandwidth Amplification as

Flooding DefenseMartin Casado, Pei Cao

Niels Provos


Problem Overview:

Bandwidth Exhaustion (aka Flooding) is a

Problem

CNN and Slashdot say so “E-commerce Firm 2Checkout Reports DDoS Extortion Attack”

(netcraft news) “DDoSers attack DoubleClick” (the register) “DDoS Extortion Attempts On the Rise” (yahoo news) Etc… you already know all this

Web SiteWeb Site


Problem Overview:

Flooding is a Network Problem

Web site, by itself, can’t do much about it Link can be flooded by legitimate SYN packets

WinXP/SP2 places no limit on connections to the same destination● can generate approx. 3000 legal SYN packets/second

Large botnet (100,00 nodes) can generate traffic approaching Gb/s

Web Site


Problem Overview:

Existing Approaches Haven’t Solved the

Problem Filtering: identifying the bad guys and

propagate the info (e.g. PUSHBACK, AITF) PUSHBACK: “Who the bad guys are” are determined by

the network AITF: needs Route Record implemented

Capability: good guys have priority on the network link Needs a “capability establishment” step Need change to routers along the path Public web sites can’t identify bad guys before-hand


Problem Overview:

The Ideal Solution

A magic way to tell bad guys from good guys Bad guys cannot hurt good guys under any

circumstance

Without requiring the network to keep states Without changes to client hosts Without changes to many routers


Our Approach:

A Practical Solution

The Web site tells bad guys from good guys Stop bad guys from flooding the egress linkSo that: Web site stays “ON” during an attack

Requires a network device to keep some states Without changes to client hosts Without changes to many routers


Our Approach:

Bandwidth Amplification


Our Approach:

Bandwidth Amplification

Does not guarantee any particular user’s access to the web site

Web site remains accessible to users who can reach the tier-1 ISP


Our Approach:

Flow Cookies

Cooperatingrouter

Web Server

SYN

SYN_ACK+SYN_Cookie+FS

ACK+DATA+SYN_Cookie+FS

•Check IP Revocation List•Validate SYN Cookie?

DATA+SYN_Cookie

ACK+DataACK+Data+Flow Cookie

•Validate Flow Cookie•Check for Flow Blacklist

ACK+DATA+Flow Cookie

ACK+Data


Our Approach:

Flow Cookies as TCP Timestamps

All hosts echo TCP timestamps set by sender Linux: default TCP timestamp option is on Windows 2000 and XP: default TCP timestamp option is off, but

if the sender sends TCP timestamps, the host will echo them!

But, what if web site needs TCP timestamps to measure RTT? Solution 1: web site avoids it if site is under attack Solution 2: only use the top 24 bits for cookie

● Router saves latest timestamp, TS, from web site● Before forwarding packet to web site, change

timestamp[8:32] to stored TS[8:32]● If server use 1ms timer, then eliminate bottom 4 bits and

reduce RTT resolution to multiples of 16ms


Our Approach:

Flow Cookies

Cookie = UMAC(Sr, Cr|srcip|dstip|srcprt)

Sr A secret only known to the router (128 bits)

Cr A counter incremented periodically to age cookies


RESETs don’t carry timestamps Set aside some bandwidth for RESETs

Persistent connections could idle longer than cookie lifetime Solution 1: No persistent connections when under

attack Solution 2: web site sends keep-alives at interval

smaller than cookie lifetime What about multi-homing?

Requires course grained synchronization between two (or more) cooperating routers

Our Approach:

More Complications


Our Approach:

The Web Site’s Job

Identify IPs that are attempting to establish too many connections and add them to router’s “IP” blacklist

Identify flows that are misbehaving and add them to router “Flow” blacklist

Router state consumption determined by the trusted web siteCan be made proportional to attacker IPs


Our Approach:

Properties of This Solution

Non-spoofable SYN cookie and flow cookie authenticate the

sender Router state bounded by the trusted web

site and proportional to # of attackers Bad IP list only applied for SYN packets,

doesn’t have to be in TCAM Line-rate computation


Our Approach:

Flow Cookies vs. Other Capability Schemes

Partial path protection vs. complete path protection Trust the victim web site

Use filtering to block connection establishment/capability acquisition

Use filtering to handle misbehaving flows vs. use other means, e.g. TVA’s (N,T), to handle misbehaving flows


Our Approach:

Implementation and Experience

Implemented in VNS

Tested against public web sites

Tested against multiple Windows and Linux client versions


Our Approach:

Summary Use bandwidth amplification to defend

against flooding DDoS Allow services such as “protected up to OC-192” Can any botnet saturate the tier-1 ISP’s links?

Use both filtering and capabilities Filtering for connection establishment and

stopping misbehaving flows Capabilities allow router not to keep per-flow

state Capabilities stored as TCP timestamps

It works!


Discussions

Assumptions about end-hosts: End-hosts follow TCP End-hosts can do anything

Assumptions about relationships among ISPs Fair queueing among peers? Can botnets flood OC-192 links?

flow cookies bandwidth amplification as flooding defense

Documents