1 / 26

Adaptive Selective Verification

This research conducted by Sanjeev Khanna, Santosh Venkatesh, Omid Fatemieh, Fariba Khan, and Carl A Gunter from UPenn and UIUC presents an adaptive protocol for DDoS defense. The protocol uses selective verification to distinguish legitimate clients from attackers and efficiently allocate bandwidth resources. The study includes a simulation study to evaluate the protocol's effectiveness.

dooley
Download Presentation

Adaptive Selective Verification

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. Adaptive Selective Verification Sanjeev Khanna, Santosh Venkatesh, UPenn Omid Fatemieh, Fariba Khan, Carl A. Gunter, UIUC IEEE INFOCOM 2008

  2. Problem • Legitimate clients and attackers indistinguishable • IPs may be spoofed • Distinct hosts may share an IP (NAT boxes in ISPs) • Examples: IKE key exchanges, digitally signed DNS, capability request channel, etc Processes Requests Legitimate Clients Responses Server Requests Overloaded (CPU, memory, etc.) Attackers

  3. Outline • Introduction and Related Work • Solution Overview • Omniscient Protocol • Adaptive Protocol • Simulation Study • Summary

  4. Service-level DDoS Defense • Denial of service are still a threat to availability in Internet • A classification of defense approaches • Filtering / rate limiting based on profiling [Srivatsa et al. Middleware 06, Ranjan et al. INFOCOM 06, Khattab et al. INFOCOM 08, etc] • Filtering / rate limiting based on Reverse Turing Tests [Morein et al. CCS 03, Gligor IWSP 03, Kandula et al. NSDI 05, etc] • Capability-based [Yaar et al. S&P 04, Yang et al. SIGCOMM 05, etc] • Currency-based: money [Mankins et al. ACSAC 01], CPU cycles [Wang et al. S&P 03, Parno et al. SIGCOMM 07, etc]bandwidth[Gunter et al. NDSS 04, Sterr et al. NPSec 05, Walfish et al. SIGCOMM 06] • Protection has costs: • Need to understand costs and trade-offs • Need adaptation strategy

  5. Bandwidth as Currency • Intuition: Attackers are already maxed-out, whereas clients can use additional bandwidth to get access • Assumptions: • Attack traffic hard to filter / rate limit explicitly • Botnet not much larger than good clients • Server has a lot of bandwidth • Selective Verification [Gunter et al. NDSS 04, Sterr et al. NPSec 05]: • Clients send a fixed number of extra requests • Server probabilistically selects (processes) a fixed portion of requests • No adaptation strategy • Bandwidth Auctions [Walfish et al. SIGCOMM 06]: • Clients build credit by sending bytes to an accounting system • Server takes requests from clients that have built the most credit • Adaptive in nature, but potentially requires significant server state • Question: Is there a good adaptive stateless bandwidth scheme?

  6. Solution Overview • Shared channel model:Attack and client rates varywithin fixed bounds • Clients respond to an attack by boosting request rates • Server performs probabilistic random sampling • Theoretically and experimentally shown to be efficient in terms of bandwidth consumption • Requires limited state on the server

  7. Analytical Setting • Time-out window T known to clients and server • In each window: • REQ factor (per sec):(number of REQs)/(server capacity S) • ρ:Agg. client REQ factor: 0 ≤ ρ ≤ ρmax; ρmax << 1 • α:Agg. attack REQ factor: 0 ≤ α ≤ αmax; αmax >> 1 REQ Clients (REQ Factor=ρ) ACK REQ Attackers (REQ Factor=α) Server (capacity=S) ACK

  8. Omniscient Protocol • Attack and client factors in each window (α and ρ) are made known to all clients and the server • Benefits: • Unrealistic, but simple to analyze • “Total bandwidth consumption” and “client success probability” easily calculated • Provides benchmarks for comparisons in more realistic settings • Client Protocol: • Transmit α/ρ copies of the REQ • If no ACK in T seconds, quit • Server Protocol: • Accept an arriving REQ packet with probability • Send an ACK for each accepted REQ

  9. Adaptive Selective Verification (ASV) • Server Protocol • Store the first ST REQs in a reservoir • If the number of packets (in a round) exceeds ST, perform reservoir-based random sampling on the incoming REQs • At the end of the window: process the REQs in the reservoir and send ACKs accordingly • Empty the reservoir and go back to step 1 Adaptive Client Protocol • Start with sending one REQ • Calculate J as the retrial span: • Double REQ rates after not getting service (i.e. ACK) in a round (T seconds) for up to J rounds

  10. Theoretical Analysis Results • We no longer assume attack and client factors in each window (α and ρ) are made known to clients or the server • Theoretically obtain the following under variable rate attacksbounded by αmax: • Lower bound on client success ratio • Tight upper bound on expected client bandwidth consumption • The expected bandwidth consumption for ASV is only times larger than the bandwidth consumed by the omniscient protocol • This would be for a non-adaptive SV which stays in high protection mode at all times

  11. Extended ASV • What if the server is temporarily down? • Server replies dropped REQs with Drop ACKs (DACK) • Lossy network could cause the clients to quit: • If no DACK received for K consecutive packets then quit • Serves as a crude congestion control mechanism • Server bandwidth concerns • Trade-off client success probability for bandwidth • Client bandwidth concerns • The server notifies clients of the success probability function, based on which the clients choose theappropriate retrial spanJ

  12. Simulation Setup • NS-2 network simulator • Each attacker sends 400 REQ/s • 50 clients join every sec • ρmax = 0.08 • αmax = 66 • Attack factor = 66 / 0.08 = 825 • RTT = 60ms • T = 400ms

  13. Adaptive vs. Non-adaptive • Client behaviors: • Naive: Send one REQ every T seconds. Quit if an ACK is received or JT seconds pass. • Aggressive (Non-Adaptive):Send 2J REQs. Quit if an ACK is received or JT seconds pass. • ASV: Implement ASV for one REQ (which means for a maximum of JT seconds).

  14. Adaptive vs. Non-adaptive (cont’d)

  15. Pulse and Variable Rate Attacks (ASV) • Pulse attacks: The system fully adapts itself to attack conditions (and recovers to pre-attack conditions when the attack stops) in less than 2s • Highly variable rate attacks:“Time to Service” and “Aggregate Client BW Usage” remain within reasonable bounds at all times • Attackers do not gain any advantage by sharply varying attack rates

  16. Effect on TCP Cross Traffic • Server S2 is a back-up server • Client C aims to back-up data on S2 over TCP at 512kbps • In parallel, S is experiencing an DoS attack and employs ASV • Communications to S over UDP • Bottleneck capacity: 10Mbps • We measure C’s success in terms of the amount of data it can upload to S2 in 30s • ASV minimally affects TCP cross traffic

  17. Summary of Contributions • We have introduced a stateless adaptive bandwidth currency algorithm called Adaptive Selective Verification (ASV) • We have developed a novel analysis technique asserting an optimality property and proved that ASV is optimal • We have added practical features to ASV and demonstrated its effectiveness in NS-2 simulations

  18. Questions

  19. Outline • Introduction and Related Work • Solution Overview / Setting • Omniscient Protocol • Adaptive Protocol • Simulation Study • Summary

  20. Outline • Introduction and Related Work • Solution Overview / Setting • Omniscient Protocol • Adaptive Protocol • Simulation Study • Summary

  21. Outline • Introduction and Related Work • Solution Overview / Setting • Omniscient Protocol • Adaptive Protocol • Simulation Study • Summary

  22. Outline • Introduction and Related Work • Solution Overview / Setting • Omniscient Protocol • Adaptive Protocol • Simulation Study • Summary

  23. Adaptive Selective Verification (ASV) Server Protocol

  24. Bandwidth as Currency • Intuition: Attackers are already maxed-out, whereas clients can use additional bandwidth to get access • Two general strategies • Selective Verification [Gunter et al. NDSS ‘04, Sterr et al. NPSec ’05]: • Clients send a fixed number of extra requests • Server selects (processes) some probabilistically • No adaptation strategy • Bandwidth Auctions [Walfish et al. SIGCOMM ‘06] : • Clients build credit by sending bytes to an accounting system • Server takes requests from clients that have built the most credit • Adaptive in nature, but potentially requires significant server state • Is there a good adaptive stateless bandwidth scheme? ρ Gunter Khanna Tan Venkatesh 04Sherr Greenwald Gunter Khanna Venkatesh 05 Walfish Balakrishnan Karger Shenker 06

  25. Pulse and Variable Rate Attacks (ASV) • Pulse attack results: The system fully adapts itself to attack conditions (and recovers to pre-attack conditions when the attack stops) in less than 2s • Variable rate attacks:

  26. Outline • Introduction and Related Work • Solution Overview / Setting • Omniscient Protocol • Adaptive Protocol • Simulation Study • Summary

More Related