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/2003 1 On the Prevention of Service Flooding in the Internet Virgil D. Gligor Electrical and Computer Engineering Department University of Maryland College Park, Maryland 20742 WADIS Academia Sinica Taipei, Taiwan December 5, 2003

2 VDG 12/5/2003 2 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/2003 3 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/2003 4 Time... Service Flooding Cannot Be Prevented by ISPs (e.g., over 500 K pps *) (e.g., 20 - 40 K pps*) * packets per second (Moore, Voelker, Savage, Usenix Security 2001) * requests (= packet) per second N = Max. network line rate Req. Rate @ 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/2003 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 - 38 - 46%, over 14,000 pps - 0.3 - 2.4 % 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/2003 6 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/2003 7 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/2003 8 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/2003 9 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/2003 10 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/2003 11 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. 433-472.] 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/2003 12 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/2003 13 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/2003 14 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/2003 15 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/2003 16 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/2003 17 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 - (1 - 2 -k o ) 2 k o -1 L/Z- s R i=1 (1 - 2 -k i ) (2 k i -1 - 2 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/2003 18 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/2003 19 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/2003 20 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/2003 21 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/2003 22 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/2003 23 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/2003 24 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/2003 25 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/2003 26 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/2003 27 4. 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