Flow Cookies Bandwidth Amplification as Flooding Defense Martin

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 v v v CNN and Slashdot say so “E-commerce Firm 2 Checkout Reports DDo. S Extortion Attack” (netcraft news) “DDo. Sers attack Double. Click” (the register) “DDo. S 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 v v Web site, by itself, can’t do much about it Link can be flooded by legitimate SYN packets Ø Win. XP/SP 2 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 v 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 v Capability: link Ø Ø Ø good guys have priority on the network 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 v. A magic way to tell bad guys from good guys v Bad guys cannot hurt good guys under any circumstance v Without requiring the network to keep states v Without changes to client hosts v Without changes to many routers 2005 Stanford Computer Systems Lab

Our Approach: A Practical Solution v The Web site tells bad guys from good guys v Stop bad guys from flooding the egress link So that: Web site stays “ON” during an attack v Requires a network device to keep some states v Without changes to client hosts v Without changes to many routers 2005 Stanford Computer Systems Lab

Our Approach: Bandwidth Amplification 2005 Stanford Computer Systems Lab

Our Approach: Bandwidth Amplification v v 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 • Validatefor Flow Blacklist • Check SYN Cookie ACK+DATA+SYN_Cookie+FS SYN DATA+SYN_Cookie ACK+DATA+Flow Cookie SYN_ACK+SYN_Cookie+FS Cookie ACK+Data+Flow Cooperating router ACK+Data Web Server 2005 Stanford Computer Systems Lab

Our Approach: Flow Cookies as TCP Timestamps v All hosts echo TCP timestamps set by sender Ø Ø v 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 1 ms timer, then eliminate bottom 4 bits and reduce RTT resolution to multiples of 16 ms Stanford Computer Systems Lab

Our Approach: Flow Cookies v v v 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 v RESETs don’t carry timestamps Ø v Persistent connections could idle longer than cookie lifetime Ø Ø v 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 v v à 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 v Non-spoofable Ø SYN cookie and flow cookie authenticate the sender v 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 v Line-rate 2005 computation Stanford Computer Systems Lab

Our Approach: Flow Cookies vs. Other Capability Schemes v Partial path protection vs. complete path protection Ø Trust v v 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 v Implemented in VNS v Tested against public web sites v Tested against multiple Windows and Linux client versions 2005 Stanford Computer Systems Lab

Our Approach: Summary v Use bandwidth amplification to defend against flooding DDo. S Ø Allow services such as “protected up to OC-192” Ø Can any botnet saturate the tier-1 ISP’s links? v Use both filtering and capabilities v 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 v Assumptions about end-hosts: Ø End-hosts follow TCP Ø End-hosts can do anything v Assumptions about relationships among ISPs Ø Fair queueing among peers? Ø Can botnets flood OC-192 links? 2005 Stanford Computer Systems Lab