martin casado pei cao niels provos l.
Skip this Video
Loading SlideShow in 5 Seconds..
Flow Cookies Bandwidth Amplification as Flooding Defense PowerPoint Presentation
Download Presentation
Flow Cookies Bandwidth Amplification as Flooding Defense

Loading in 2 Seconds...

play fullscreen
1 / 18

Flow Cookies Bandwidth Amplification as Flooding Defense - PowerPoint PPT Presentation

  • Uploaded on

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)

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
problem overview bandwidth exhaustion aka flooding is a problem
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

problem overview flooding is a network problem
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

problem overview existing approaches haven t solved the problem
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
problem overview the ideal solution
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
our approach a practical solution
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
our approach bandwidth amplification8
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
our approach flow cookies
Our Approach:Flow Cookies


  • Check IP Revocation List
  • Validate SYN Cookie
  • Validate Flow Cookie
  • Check for Flow Blacklist




ACK+DATA+Flow Cookie


ACK+Data+Flow Cookie




Web Server

our approach flow cookies as tcp timestamps
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
our approach flow cookies11
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

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
our approach the web site s job
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
our approach properties of this solution
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
our approach flow cookies vs other capability schemes
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
our approach implementation and experience
Our Approach:Implementation and Experience
  • Implemented in VNS
  • Tested against public web sites
  • Tested against multiple Windows and Linux client versions
our approach summary
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!
  • 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?