Flow Cookies Bandwidth Amplification as Flooding Defense

1. Martin Casado, Pei Cao Niels Provos Flow CookiesBandwidth Amplification as Flooding Defense

2. 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 Web Site 

3. 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. 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. 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. 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. Our Approach:Bandwidth Amplification 

8. 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. Our Approach:Flow Cookies ? • Check IP Revocation List • Validate SYN Cookie • Validate Flow Cookie • Check for Flow Blacklist ACK+DATA+SYN_Cookie+FS SYN DATA+SYN_Cookie ACK+DATA+Flow Cookie SYN_ACK+SYN_Cookie+FS ACK+Data+Flow Cookie Cooperatingrouter ACK+Data ACK+Data Web Server

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

12. Our Approach:More Complications • 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

13. 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. 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. 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. Our Approach:Implementation and Experience • Implemented in VNS • Tested against public web sites • Tested against multiple Windows and Linux client versions

17. 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. 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?