Transcript A Hands-On Environment for Teaching Networks

Flow Cookies
Bandwidth Amplification as Flooding
Defense
Martin Casado, Pei Cao
Niels Provos
2005
Stanford Computer Systems Lab
Problem Overview:
Bandwidth Exhaustion (aka
Flooding) is a Problem
Web Site






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
2005
Stanford Computer Systems Lab
Problem Overview:
Flooding is a Network
Problem
Web Site



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
2005
Stanford Computer Systems Lab
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
2005
Stanford Computer Systems Lab
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
2005
Stanford Computer Systems Lab
Our Approach:
A Practical Solution
 The
Web site tells bad guys from good guys
 Stop bad guys from flooding the egress link
So 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
2005
Stanford Computer Systems Lab
Our Approach:
Bandwidth Amplification

2005
Stanford Computer Systems Lab
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
2005
Stanford Computer Systems Lab
Our Approach:
Flow Cookies
?
•Check IP Revocation List
•Validate Flow Cookie
•Validate SYN Cookie
•Check for Flow Blacklist
ACK+DATA+SYN_Cookie+FS
SYN
DATA+SYN_Cookie
ACK+DATA+Flow Cookie
ACK+Data+Flow
Cookie
SYN_ACK+SYN_Cookie+FS
Cooperating
router
ACK+Data
ACK+Data
Web Server
2005
Stanford Computer Systems Lab
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
●
●
●
2005
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
Stanford Computer Systems Lab
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
2005
Stanford Computer Systems Lab
Our Approach:
More Complications

RESETs don’t carry timestamps


Persistent connections could idle longer than cookie
lifetime



Set aside some bandwidth for RESETs
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
2005
Stanford Computer Systems Lab
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 site
 Can
2005
be made proportional to attacker IPs
Stanford Computer Systems Lab
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
2005
computation
Stanford Computer Systems Lab
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
2005
Stanford Computer Systems Lab
Our Approach:
Implementation and
Experience

Implemented in VNS

Tested against public web sites

Tested against multiple Windows and Linux
client versions
2005
Stanford Computer Systems Lab
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

Capabilities stored as TCP timestamps
 Filtering
for connection establishment and stopping
misbehaving flows
 Capabilities allow router not to keep per-flow state
 It
works!
2005
Stanford Computer Systems Lab
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?
2005
Stanford Computer Systems Lab