1 / 27

On the Prevention of Service Flooding in the Internet

On the Prevention of Service Flooding in the Internet. Virgil D. Gligor gligor@umd.edu Electrical and Computer Engineering Department University of Maryland College Park, Maryland 20742 WADIS Academia Sinica Taipei, Taiwan December 5, 2003. Outline. I. Application-Service Flooding:

orli
Télécharger la présentation

On the Prevention of Service Flooding in the Internet

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. On the Prevention of Service Flooding in the Internet Virgil D. Gligor gligor@umd.edu Electrical and Computer Engineering Department University of Maryland College Park, Maryland 20742 WADIS Academia Sinica Taipei, Taiwan December 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. I. Application-Service Flooding • Internet • public services: application and infrastructure (e.g., security, naming) • allclients 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, increaseover time • Economic Analogy of Service Flooding • - “tragedy of commons”

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

  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 % (Isn’t Sloppy Application Design and Programming Worse ?) * Flooding attacks have not had specific economic targets

  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. III. What Types of Solutions ? Layer m - 1 DoS freedom • Typical Layering : • DoS freedom at layer m-1 • cannot be implemented • from layer m Layer m DoS freedom (1) DoS freedom at layer m ==>DoS freedom at layer m-1 (not an E2E solvable problem, even if the “Ends” cooperate) (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) Challenge: Is A Single, Cross-Layer Solution Practical?

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

  9. RTS/VP RTS/VP RTS/VP Rate Rate Rate RTS/VP RTS/VP RTS/VP Capability Verification: check hashK seq. no. and Rate in each packet vs. <IPc, IPs, Rate, hashK><seq. no.> entry in each VP along request path RTS/VP RTS/VP Alternate Paths are Ignored 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) Client Small IBP Host BGP BGP BGP Server ISP BGP Dominant IBP Host BGP BGP Medium IBP BGP BGP

  10. Barriers to Single, Cross-Layer Solutions - Technical - • Design-complexity distribution [IEEE TSE, 1979] • 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 Amdahl’s 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) • 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

  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 IBP’s 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: IBP’s should have an“off-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. IV. Application-Layer Solutions • 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

  13. Access Guarantees offered to Clients For all client requests, • MWTr – maximum waiting time ([IEEE S&P ‘83, TSE’84, ICDE ‘86]) • client request is accepted for service in time T, • where T is known at the time of the request. 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. 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 serviceeventually] p, where p =/= 0. WPWT – wPWT w/o the constraint that p =/= 0. Similar definitions for Per-Service Waiting Times

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

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

  16. Example 1. “Client Puzzles” based on Hash Functions Example Challenge: given k, find X Verification: h(Message X) Response: Message X 00…0 don’t care m-k k bits bits 1 k  64 m = 128 Average Latency per Client: 2ksteps

  17. A Client-Puzzle Model [WR03] A d v e r s a r y C l i e t Pu z z l e Client 1 Server preempt . . . yes k1 < ki < kr ... ... S bid ki+1 kr k1 ki > k1 ? Client Z S L > Z/2 no . . . drop drop Client n weakPWT Pr [any client C’s request is accepted for service in timeT] = Pr [any client C’s request is accepted for service in R+1 rounds k0, k1,…,kr] =1-Pr [any client C’s request is denied at round R+1] 2ko-1L/Z-s (2ki-1 - 2ki-1-1)L/Z = p > 0 1 - (1 - 2-ko) • Ri=1 (1 - 2-ki) Dependency on attack parameter Z

  18. Enter Puzzle Mode Exit Puzzle Mode Intuition for Client Puzzle Use: Request-Rate Control (WPWT) N = Max. net. (“line”) Rate req._rateX S = Max. Server Rate k0 < k1 <. . . .< kr Min. Server Rate time t0 t1 tr

  19. m Pr [client req. is accepted within m retries] < p i=0 (1- p)i = 1-(1- p)1+m < 1 Adversary Goal: Deny Strong Guarantees dropped request dropped retry dropped retry dropped retry retry accepted dropped request Nzk0 Nzk2 Nzk1 Nzk3 Aggr. Req. Rate Aggr. Req. Rate N N S S k1 k0 k2 k4 (= k0) k1 k3 k0 k2 k3 p 1-p Coord. req. Coord. req. Coord. req. t1L t2L t3L   t0  t1 t3 t2 Time Time L/Nzki <  < Z/S Coordinated Attackfor a k0 < k1 < k2 < k3 sequence p = max(pi), i = 1,…,m

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

  21. Example 2: Random L of N (w/o preemption) A d v e r s a r y R e q. R e t r y Client 1 Server . . . random L req./retry S ... ... ... ... r1 rN rj rm rk Client Z L = S . . . drop N - L Client n weakPWT (but inexpensive) ni /S= no. of requests received / processed at roundi; S/N  min {S/ni}, 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 Dependency on attack parameter r

  22. Example 3: Random L = S (with Preemption) A d v e r s a r y R e q. R e t r y Client 1 Server 0 (1  i  L) . . . preempt rand. no. [0, L] req./retry ... S ... r1 rL ri Client Z L = S . . . = 0 drop drop Client n PWT 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”).

  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. Phase 1: Client-Proliferation Control Cookie / RCS Server Client1 Req . . . 1. Request Cookie CAPTCHA Challenge-Response • - operate at • network • “line” rate • share key • - time. sync. 3. Request Ticket, Cookie Untrusted Hosti 2. Cookie Clienti 4. Ticket Req . . . Req Service TKT Verifier 5. Req, Ticket Clientn Req Phase 2: Time-Slot Reservation Cookie / Ticket duplication by Clients ? theft, replay by Clients ?

  25. Phase 2:Time-Slot Reservation T1 user1 cookie T2 1 tkt1-k . . . t3 t2 t1 t1 ti tj k tickets 1  wi/k L/k L/s  t = ti+1 - ti L/S . . . t*MAC1 tkt11 = t1, t2, cnt1 IPaddrC1 w1 tkt21 = t1, t2, t*MAC2 cnt2 wi IPaddrC2 . . . w2 = tktk1 t1, t2, t* MACk cntk IPaddrCk = w1 L k t1-t2 = t  L/S client requests =  wi  * t = time at server

  26. Simple Optimization: wopt, topt Ctotal = Cclient + Cserver = c1Ar/w + c2(1-r)w, where w = total number of requests in a window (for all that window’s tickets) c1= communication cost for getting a ticket from RCS c2= server-utilization cost of waiting for a request not issued within w Ar = average number of Application Requests (Client -> Server requests) r = percentage of legitimate clients ( 0  r < 1) c1 Ar c2(1-r)  Ctotal/ w = 0 => wopt = , constrain: 1  wopt  min(L,Ar) L/S topt = wopt/S  L/Smin Simulations Parameters: c1/c2, r, Ar Processes:client request,service response Attack characterization: low inter-arrival times of client requests to TGS, lowr, high Ar

  27. 4. General Request Constraints ? • Additional constraints on Client Requests • Example • MWT for coordinated requests from Clients toServers under attack • • Client requests to multiple Servers • • application-related Clients requests to Servers • (e.g., is  MWTifor Clienti requests to Serveri within T ? in [t1, t1] ?)

More Related