1 / 18

Flow Cookies Bandwidth Amplification as Flooding Defense

Martin Casado, Pei Cao Niels Provos Flow Cookies Bandwidth Amplification as Flooding Defense Problem Overview : Bandwidth Exhaustion (aka Flooding) is a Problem CNN and Slashdot say so “E-commerce Firm 2Checkout Reports DDoS Extortion Attack” (netcraft news)

oshin
Télécharger la présentation

Flow Cookies Bandwidth Amplification as Flooding Defense

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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?

More Related