martin casado pei cao niels provos l.
Download
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


  • 273 Views
  • 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)

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

PowerPoint Slideshow about 'Flow Cookies Bandwidth Amplification as Flooding Defense' - oshin


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+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

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
slide12

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!
discussions
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?