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?