Download presentation
Presentation is loading. Please wait.
1
2005 Stanford Computer Systems Lab Flow Cookies Bandwidth Amplification as Flooding Defense Martin Casado, Pei Cao Niels Provos
2
2005 Stanford Computer Systems Lab 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 Site
3
2005 Stanford Computer Systems Lab 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
4
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
5
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
6
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
7
2005 Stanford Computer Systems Lab Our Approach: Bandwidth Amplification
8
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
9
2005 Stanford Computer Systems Lab Our Approach: Flow Cookies Cooperating router Web Server SYN SYN_ACK+SYN_Cookie+ FS ACK+DATA+SYN_Cookie+ FS Check IP Revocation List Validate SYN Cookie ? DATA+SYN_Cookie ACK+Data ACK+Data+Flow Cookie Validate Flow Cookie Check for Flow Blacklist ACK+DATA+Flow Cookie ACK+Data
10
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 ● 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
11
2005 Stanford Computer Systems Lab Our Approach: Flow Cookies Cookie = UMAC(S r, C r |src ip |dst ip |src prt ) S r A secret only known to the router (128 bits) C r A counter incremented periodically to age cookies
12
2005 Stanford Computer Systems Lab 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
13
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 be made proportional to attacker IPs
14
2005 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 computation
15
2005 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
16
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
17
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 Filtering for connection establishment and stopping misbehaving flows Capabilities allow router not to keep per-flow state Capabilities stored as TCP timestamps It works!
18
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?
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.