Adaptive Selective Verification

26
Adaptive Selective Verification Sanjeev Khanna, Santosh Venkatesh, UPenn Omid Fatemieh, Fariba Khan, Carl A. Gunter, UIUC IEEE INFOCOM 2008

description

Adaptive Selective Verification. Sanjeev Khanna, Santosh Venkatesh, UPenn Omid Fatemieh , Fariba Khan, Carl A. Gunter, UIUC IEEE INFOCOM 2008. Problem. Legitimate clients and attackers indistinguishable IPs may be spoofed Distinct hosts may share an IP (NAT boxes in ISPs) - PowerPoint PPT Presentation

Transcript of Adaptive Selective Verification

Page 1: Adaptive Selective Verification

Adaptive Selective Verification

Sanjeev Khanna, Santosh Venkatesh, UPenn

Omid Fatemieh, Fariba Khan, Carl A. Gunter, UIUC

IEEE INFOCOM 2008

Page 2: Adaptive Selective Verification

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

Server

Requests Legitimate Clients

Attackers Overloaded (CPU, memory, etc.)

Requests

Processes

Responses

2

Page 3: Adaptive Selective Verification

Outline

• Introduction and Related Work

• Solution Overview

• Omniscient Protocol

• Adaptive Protocol

• Simulation Study

• Summary

3

Page 4: Adaptive Selective Verification

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

4

Page 5: Adaptive Selective Verification

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?5

Page 6: Adaptive Selective Verification

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

6

Page 7: Adaptive Selective Verification

Analytical Setting

REQ

ACK

• 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

Server (capacity=S)

REQ

ACK

Clients (REQ Factor=ρ)

Attackers(REQ Factor=α)

7

Page 8: Adaptive Selective Verification

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

8

Page 9: Adaptive Selective Verification

Adaptive Selective Verification (ASV)

Adaptive Client Protocol

1. Start with sending one REQ

2. Calculate J as the retrial span:

3. Double REQ rates after not getting service (i.e. ACK) in a round (T seconds) for up to J rounds

)2log(/log

max

max

Server Protocol

1. Store the first ST REQs in a reservoir

2. If the number of packets (in a round) exceeds ST, perform reservoir-based random sampling on the incoming REQs

3. At the end of the window: process the REQs in the reservoir and send ACKs accordingly

4. Empty the reservoir and go back to step 1

9

Page 10: Adaptive Selective Verification

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 attacks bounded 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

10

Page 11: Adaptive Selective Verification

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 the appropriate retrial span J

11

Page 12: Adaptive Selective Verification

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

12

Page 13: Adaptive Selective Verification

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).

13

Page 14: Adaptive Selective Verification

Adaptive vs. Non-adaptive (cont’d)

14

Page 15: Adaptive Selective Verification

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

15

Page 16: Adaptive Selective Verification

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 traffic16

Page 17: Adaptive Selective Verification

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

17

Page 18: Adaptive Selective Verification

Questions

18

Page 19: Adaptive Selective Verification

Outline

• Introduction and Related Work

• Solution Overview / Setting

• Omniscient Protocol

• Adaptive Protocol

• Simulation Study

• Summary

19

Page 20: Adaptive Selective Verification

Outline

• Introduction and Related Work

• Solution Overview / Setting

• Omniscient Protocol

• Adaptive Protocol

• Simulation Study

• Summary

20

Page 21: Adaptive Selective Verification

Outline

• Introduction and Related Work

• Solution Overview / Setting

• Omniscient Protocol

• Adaptive Protocol

• Simulation Study

• Summary

21

Page 22: Adaptive Selective Verification

Outline

• Introduction and Related Work

• Solution Overview / Setting

• Omniscient Protocol

• Adaptive Protocol

• Simulation Study

• Summary

22

Page 23: Adaptive Selective Verification

Adaptive Selective Verification (ASV)

Server Protocol

23

Page 24: Adaptive Selective Verification

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 04 Sherr Greenwald Gunter Khanna Venkatesh 05 Walfish Balakrishnan Karger Shenker 06

ρ

24

Page 25: Adaptive Selective Verification

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:

25

Page 26: Adaptive Selective Verification

Outline

• Introduction and Related Work

• Solution Overview / Setting

• Omniscient Protocol

• Adaptive Protocol

• Simulation Study

• Summary

26