Presentation is loading. Please wait.

Presentation is loading. Please wait.

VDG 12/5/2003 1 On the Prevention of Service Flooding in the Internet Virgil D. Gligor Electrical and Computer Engineering Department University.

Similar presentations

Presentation on theme: "VDG 12/5/2003 1 On the Prevention of Service Flooding in the Internet Virgil D. Gligor Electrical and Computer Engineering Department University."— Presentation transcript:

1 VDG 12/5/ On the Prevention of Service Flooding in the Internet Virgil D. Gligor Electrical and Computer Engineering Department University of Maryland College Park, Maryland WADIS Academia Sinica Taipei, Taiwan December 5, 2003

2 VDG 12/5/ Outline I. Application-Service Flooding: A Fundamental and Persistent Vulnerability II. Is This Vulnerability a Major Problem ? Maybe not, but soon it could become one... III. What Types of Solutions ? Single, cross-business-layer vs. per-layer solution? IV. An Example of an Application-Layer Solution Access guarantees Approach: User Agreements and Guarantees A proposal

3 VDG 12/5/ I. Application-Service Flooding Internet - public services: application and infrastructure (e.g., security, naming) - all clients are legitimately authorized to access a public service => cannot distinguish legitimate clients vs. adversaries, and flash crowds vs. DDoS - bounds on number of clients are practically unknown Flooding Vulnerability of Public Servers - persists after all other types of DDoS attacks are handled - cause: rate gap (network line rate >> public server rate at access pt.) - E2E Argument => rate-gap persistence, increase over time Economic Analogy of Service Flooding - tragedy of commons

4 VDG 12/5/ Time... Service Flooding Cannot Be Prevented by ISPs (e.g., over 500 K pps *) (e.g., K pps*) * packets per second (Moore, Voelker, Savage, Usenix Security 2001) * requests (= packet) per second N = Max. network line rate Req. Server - ISPs: no unusual traffic in 01 cnn, ebay, yahoo! flooding attacks - Public-service pricing model =/= access model S = Max. Server Rate * firewalls for TCP SYN flood protection S F = 14 K pps* Persistent Rate Gap

5 VDG 12/5/ II. Is Flooding a Major Problem ? Internet Measurements [MVS2001] Spread: 12,805 attacks against 5,000 hosts in 2,000 orgs* Period: 3 weeks => 1 attack per host in 200 hours Rates: over 500 pps %, over 14,000 pps % Duration: under 10 min. - 50% 30 min. - 80% 1 hour - 90% => 0.5 % loss of host perf. 5 hours - 98% => 2.5 % 10 hours - 99% => 5 % (Isnt Sloppy Application Design and Programming Worse ?) * Flooding attacks have not had specific economic targets

6 VDG 12/5/ So, Is Flooding a Major Problem ? maybe not, but plenty of economic targets will change this Target 1: Application Servers providing Voice over IP Widespread [Washington Post, Nov. 29, 2003]: - local providers : 30% lower network costs - long-distance providers: bypass local access charges - carriers: 50% lower capital investment costs Target 2: Internet-connected Base Stations of WiFi networks Network Effect: Flooding Access Points => Denied Network Access Economic Reason: Targeted Degradation of Connectivity in a Highly Competitive Applications Market

7 VDG 12/5/ Layer m DoS freedom Layer m - 1 DoS freedom (1) DoS freedom at layer m ==> DoS freedom at layer m-1 (not an E2E solvable problem, even if the Ends cooperate) - Typical Layering : DoS freedom at layer m-1 cannot be implemented from layer m (2) DoS freedom at layer m <=/= DoS freedom at layer m-1 (need a solution for layer m defense even if layer m-1 is DoS free) (3) Solution at layer m-1 cannot always be replicated at layer m (likely to need a distinct solution; e.g., no server pushback of clients) III. What Types of Solutions ? Challenge: Is A Single, Cross-Layer Solution Practical?

8 VDG 12/5/ A Potential Single, Cross-Layer Solution Capability-Based Internet: … a complete, open, secure solution to DoS attacks [ARW03] Dominant IBP* Small IBP Medium IBP ISP** Server Client Host BGP RTS/VP rts Capability Distribution: hash value (h K ); seq. no. (s 0 ) included in each client packet *Cable & Wireless, Sprint, MCI-WorldCom, Verizon, AT&T: 5 of approx. 50 ** approx. 7,500 ISPs

9 VDG 12/5/ A Potential Single, Cross-Layer Solution Upstream Control: early confinement of fewer flows Repeated Control on Path: prevention of control circumvention (by source IP addr. Spoofing) Dominant IBP Small IBP Medium IBP ISP Server Client Host BGP RTS/VP Rate Capability Verification: check hash K seq. no. and Rate in each packet vs. entry in each VP along request path Alternate Paths are Ignored

10 VDG 12/5/ Barriers to Single, Cross-Layer Solutions - Technical - Design-complexity distribution [IEEE TSE, 1979] Upstream & Repeated Control of all Internet paths to App. Servers Barrier: Limited Path Diversity among ISPs vs. current Internet Example: CAIDA topology => 64% of all monitor pairs [TMSV03] > 1 partially disjoint path across the Internet Barrier: Poor interaction with application-level communication patterns (viz., also E2E Argument) Example: application-multicast overhead => high in IBP, low in application servers - if a new function must be implemented with existing mechanisms, its overhead must be apportioned to those mechanisms in a inverse relationship with their frequency of use [consistent with Amdahls law] Example of new function: prevention of application service (infrequent) flooding - rate gap => huge difference in frequency of layer use (IP vs. Application) Barrier: IP layer changes must be minimal at best (e.g., perf., ex. conds)

11 VDG 12/5/ Barriers to Single, Cross-Layer Solutions - Economic - Status: Internet Backbone Providers (IBP) and ASP markets are highly competitive and (largely) unregulated Theory: Dominant IBP targets smaller IBP for degraded connectivity (e.g., deny/delay services, lower transit capacity in contracted connectivity) => lowers small IBPs market power [J. Cramer, P. Rey and J. Tirole, J. of Ind. Econ. v. 48, (2000), pp ] Barrier: single, cross-layer solutions accelerate targeted degradation additional service dependencies on the dominant IBP => upstream & repeated control will move downstream Theory: IBPs should have anoff-the-net pricing structure =/= per-path, on-the-net, telephony-style pricing [J-J. Laffont, S. Marcus, P. Rey, and J. Tirole, IDEI, U. of Toulouse, France] Potential Barrier: single, cross-layer solution => per-path resource allocation in IBPs) -> different IBP access pricing

12 VDG 12/5/ Guarantees offered to Clients ? Server Protection WPWT - weakest Guarantee: server responds to some requests Access Guarantees => Server Protection - waiting-time bounds for access to Server - scope: per request, per service - bound quality: variable-dependent, -independent of attack, constant - assumption: IP-layer flooding is handled by a separate solution MWT - maximum waiting time FWT - finite waiting time PWT - probabilistic waiting time IV. Application-Layer Solutions

13 VDG 12/5/ MWTr – maximum waiting time ([IEEE S&P 83, TSE84, ICDE 86]) client request is accepted for service in time T, where T is known at the time of the request. FWTr – finite waiting time ( [IEEE S&P 88]) client request is accepted for service eventually wPWTr – weak probabilistic waiting time Pr [client request is accepted for service eventually] p, where p =/= 0. Access Guarantees offered to Clients PWTr – probabilistic waiting time (weaker than [Millen, IEEE S&P 92]) Pr [client request is accepted for service in time T], where T is known at the time of the request, =/= 0 and is independent of attack. For all client requests, Similar definitions for Per-Service Waiting Times WPWT – wPWT w/o the constraint that p =/= 0.

14 VDG 12/5/ Relationships Among Access Guarantees Legend: = implies FWTs PWTs wPWTs MWTs some client access client puzzles [DN92, JB99, ANL00, DS01] client puzzles + assumption example 1 simple example 2 simple example 3 explicit rate-control agreements wPWTr MWTr FWTr PWTr FWTr PWTr WPWT

15 VDG 12/5/ Service (layer m) guaranteed request-delivery path (layer m-1) dependencies U s e r A g r m n t. s (2) User Agreements [IEEE S&P 88] counter undesirable dependencies, (1) Rate Gap => Undesirable Dependencies among Clients [IEEE S&P 83]: (viz., the tragedy of commons) Client 1 Client i Client n Basic Idea: User Agreements

16 VDG 12/5/ Example 1. Client Puzzles based on Hash Functions Example Challenge: given k, find X 00…0 h(Message X) k bits Response: Message X Verification: bits m-k dont care 1 k 64 m = 128 Average Latency per Client: 2 k steps

17 VDG 12/5/ ClietPuzzleClietPuzzle Client 1 Client Z Client n... AdversaryAdversary S k1k1 krkr S L > Z/2 Server... weak PWT Pr [any client Cs request is accepted for service in time T] = Pr [any client Cs request is accepted for service in R+1 rounds k 0, k 1,…,k r ] = 1- Pr [any client Cs request is denied at round R+1] 1 - ( k o ) 2 k o -1 L/Z- s R i=1 ( k i ) (2 k i k i-1 -1 )L/Z = p > 0 A Client-Puzzle Model [WR03] Dependency on attack parameter Z kiki k 1 < k i < k r bid k i+1 > k 1 ? drop no yes preempt drop

18 VDG 12/5/ time k 0 < k 1 <.... < k r req._rate X N = Max. net. (line) Rate Enter Puzzle Mode S = Max. Server Rate Exit Puzzle Mode Min. Server Rate Intuition for Client Puzzle Use: Request-Rate Control (WPWT) t0t0 t1t1 trtr

19 VDG 12/5/ Time k 0 Time k 1 dropped request retry accepted Coord. req. Coord. req. Aggr. Req. Rate Aggr. Req. Rate Coordinated Attack for a k 0 < k 1 < k 2 < k 3 sequence t1Lt1L t1t1 t 0 t3t3 t 2 t3Lt3L t 2 L N S Nzk2Nzk2 Nzk3Nzk3 Nzk1Nzk1 k 0 k 1 k 2 k 3 k 2 N S Nzk0Nzk0 k 3 Coord. req. k 4 (= k 0 ) dropped request dropped retry dropped retry dropped retry Adversary Goal: Deny Strong Guarantees L/N z k i < < Z/S p 1-p p = max(p i ), i = 1,…,m Pr [client req. is accepted within m retries] < p i=0 (1- p) i = 1-(1- p) 1+m < 1 m

20 VDG 12/5/ What Do Client Puzzles Achieve ? Client Guarantees ? WPWT wPWT (with assumption L > Z/2) no PWT, no FWT => no MWT … very weak client guarantees at high … random scheduling (with preemption) achieves wPWT (PWT) … and unnecessary request overhead.

21 VDG 12/5/ Example 2: Random L of N (w/o preemption) n i /S = no. of requests received / processed at round i; S/N min {S /n i }, i = 1,…, r Pr [client request is accepted for service eventually] Pr [client request is accepted for service in r rounds] = 1- Pr [client request delayed to round r] p = 1- (1- S/N) r -> 1 weak PWT (but inexpensive) Dependency on attack parameter r R e q. R e t r y Client 1 Client Z Client n... AdversaryAdversary S rmrm rjrj L = S Server... rkrk drop N - L random L req./retry r N... r1r1

22 VDG 12/5/ R e q. R e t r y Client 1 Client Z Client n... AdversaryAdversary S rLrL r1r1 L = S Server... PWT riri rand. no. [0, L] = 0 drop preempt 0 (1 i L) req./retry Pr[req./retry is accepted by Server in T + ] = Pr[req_buffer[1…L] req./retry in ] x Pr[req./retry not dropped in ] [1-1/(L+1)] x [1/(L+1)+(L-1)/(L+1)] n = [L/(L+1)] 1+n [S /(S +1)] 1+N = =/= 0 (independent of the number and aggregate request rate of zombies). Example 3: Random L = S (with Preemption) drop

23 VDG 12/5/ Explicit Control of Client Request Rate Phase 1: Client-Proliferation Control (Stateless Session) Cookie => Reverse Turing Test passed => Trusted Path use by human (TCPA + host PK registration) - forces human-level collusion and coordination on global scale Phase 2: Request-Rate Control for Individual Clients Service Req. => Valid Rate-Control Ticket => Valid Cookie - ticket: time-slot reservation, total ordering (e.g., a Bakery Mechanism)

24 VDG 12/5/ Phase 1: Client-Proliferation Control Client i Cookie / RCS Server 1. Request Cookie 2. Cookie Req Untrusted Host i CAPTCHA Challenge-Response Service TKT Verifier Req Phase 2: Time-Slot Reservation 3. Request Ticket, Cookie 4. Ticket 5. Req, Ticket Client 1 Req Client n Req... Cookie / Ticket duplication by Clients ? theft, replay by Clients ? - operate at network line rate - share key - time. sync.

25 VDG 12/5/ t1t1 t2t2 titi tjtj 1 w i /k L/k L/s t = t i+1 - t i L/S t1t1 t3t3 w1w1 w2w2 wiwi... Phase 2:Time-Slot Reservation tkt 1 1 tkt 2 1 tkt 1-k tkt k 1 = = = t1,t1,t2,t2, t1,t1, t1,t1, cnt 1 t2,t2, cnt 2 t2,t2, cnt k... 1 client requests = w i IPaddrC 1 IPaddrC 2 IPaddrC k t* MAC 1 * t = time at server t* MAC 2 t* MAC k user 1 cookieT1T1 T2T2 = w 1 L k t 1 -t 2 = t L/S k tickets

26 VDG 12/5/ Simple Optimization: w opt, t opt C total = C client + C server = c 1 A r /w + c 2 (1-r)w, where w = total number of requests in a window (for all that windows tickets) c 1 = communication cost for getting a ticket from RCS c 2 = server-utilization cost of waiting for a request not issued within w A r = average number of Application Requests (Client -> Server requests) r = percentage of legitimate clients ( 0 r < 1) C total / w = 0 => w opt =, constrain: 1 w opt min(L,Ar) c 1 A r c 2 (1-r) Simulations Parameters: c 1 /c 2, r, A r Processes: client request, service response Attack characterization: low inter-arrival times of client requests to TGS, low r, high A r L/S t opt = w opt /S L/S min

27 VDG 12/5/ General Request Constraints ? Additional constraints on Client Requests Example -MWT for coordinated requests from Clients to Servers under attack Client requests to multiple Servers application-related Clients requests to Servers (e.g., is MWT i for Client i requests to Server i within T ? in [t 1, t 1 ] ?)

Download ppt "VDG 12/5/2003 1 On the Prevention of Service Flooding in the Internet Virgil D. Gligor Electrical and Computer Engineering Department University."

Similar presentations

Ads by Google