VDG 12/5/2003 1 On the Prevention of Service Flooding in the Internet Virgil D. Gligor [email protected]Electrical and Computer Engineering Department University of Maryland College Park, Maryland 20742 WADIS Academia Sinica Taipei, Taiwan December 5, 2003
27
Embed
VDG 12/5/2003 1 On the Prevention of Service Flooding in the Internet Virgil D. Gligor [email protected] Electrical and Computer Engineering Department University.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Electrical and Computer Engineering Department University of Maryland
College Park, Maryland 20742
WADISAcademia SinicaTaipei, Taiwan
December 5, 2003
VDG 12/5/20032
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 SolutionAccess guaranteesApproach: User Agreements and GuaranteesA proposal
VDG 12/5/20033
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”
VDG 12/5/20034
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” rateReq. 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
SF = 14 K pps*
Persistent Rate Gap
VDG 12/5/20035
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 hoursRates: over 500 pps - 38 - 46%, over 14,000 pps - 0.3 - 2.4 %Duration: under 10 min. - 50%
A Potential Single, Cross-Layer SolutionUpstream Control: early confinement of fewer flowsRepeated Control on Path: prevention of control circumvention
(by source IP addr. Spoofing)
Dominant IBP
Small IBP
Medium IBP
ISP Server
Client
Host
Host
BGP
BGPBGP
BGP
BGP
BGP
BGP
BGP
RTS/VPRTS/VP
RTS/VP
RTS/VP
RTS/VP
RTS/VP
RTS/VP
RTS/VP
Rate Rate
Rate
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
Alternate Paths are Ignored
VDG 12/5/200310
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 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)
VDG 12/5/200311
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
VDG 12/5/200312
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 timeFWT - finite waiting timePWT - probabilistic waiting time
IV. Application-Layer Solutions
VDG 12/5/200313
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.
FWTr – finite waiting time ( [IEEE S&P ‘88]) client request is accepted for service eventually
wPWTr – weak probabilistic waiting timePr [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.
(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
VDG 12/5/200316
Example 1. “Client Puzzles” based on Hash Functions
Example Challenge: given k, find X
00…0
h(Message X)
k bits
Response: Message XVerification:
bits m-k
don’t care
1 k 64 m = 128
Average Latency per Client: 2k steps
VDG 12/5/200317
C
l
i
e
t
Pu
z
z
l
e
Client 1
Client Z
Client n
. . .
Adversary
Sk1 ... kr
SL > Z/2
Server
...
. . .
weak PWTPr [any client C’s request is accepted for service in time T]= 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]
1 - (1 - 2-ko)2ko-1L/Z-s
Ri=1 (1 - 2-ki)
(2ki-1 - 2ki-1-1)L/Z= p > 0
A Client-Puzzle Model [WR03]
Dependency on attack parameter Z
ki
k1 < ki < kr
bid ki+1 > k1 ?
drop
no
yespreempt
drop
VDG 12/5/200318
time
k0 < k1 <. . . . < kr
req._rateX
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)
t0 t1 tr
VDG 12/5/200319
Time
k0
Time
k1
droppedrequest
retry accepted
Coord.req.
Coord.req.
Aggr.Req. Rate
Aggr.Req. Rate
Coordinated Attack for a k0 < k1 < k2 < k3 sequence
t1L
t1 t0 t3 t2
t3L t2
L
N
S
Nzk2 Nz
k3Nzk1
k0 k1 k2 k3 k2
N
S
Nzk0
k3
Coord.req.
k4 (= k0)
droppedrequest
droppedretry
droppedretry
droppedretry
Adversary Goal: Deny Strong Guarantees
L/Nzki < < Z/S
p 1-p
p = max(pi), i = 1,…,m
Pr [client req. is accepted within m retries] < p i=0 (1- p)i = 1-(1- p)1+m < 1m
VDG 12/5/200320
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.
VDG 12/5/200321
Example 2: Random L of N (w/o preemption)
ni /S = no. of requests received / processed at round i; 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
weak PWT (but inexpensive)
Dependency on attack parameter r
R
e
q.
R
e
t
r
y
Client 1
Client Z
Client n
. . .
Adversary
Srm ... rj
L = S
Server
...
. . .
rk
drop N - L
random Lreq./retry rN ... r1...
VDG 12/5/200322
R
e
q.
R
e
t
r
y
Client 1
Client Z
Client n
. . .
Adversary
SrL ... r1
L = S
Server
...
. . .
PWT
rirand. no.
[0, L]
= 0drop
preempt0 (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
VDG 12/5/200323
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 scalePhase 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”)
VDG 12/5/200324
Phase 1: Client-Proliferation Control
Clienti
Cookie / RCS Server
1. Request Cookie
2. Cookie
Req
Untrusted Hosti
CAPTCHA Challenge-Response
ServiceTKT VerifierReq
Phase 2: Time-Slot Reservation
3. Request Ticket, Cookie
4. Ticket
5. Req, Ticket
Client1 Req
Clientn Req
. . .
. . .
Cookie / Ticket duplication by Clients ? theft, replay by Clients ?
- operate at network “line” rate- share key- time. sync.
w = total number of requests in a window (for all that window’s tickets)c1 = communication cost for getting a ticket from RCSc2 = server-utilization cost of waiting for a request not issued within wAr = average number of Application Requests (Client -> Server requests)r = percentage of legitimate clients ( 0 r < 1)
SimulationsParameters: c1/c2, r, Ar Processes: client request, service responseAttack characterization: low inter-arrival times of client requests to TGS, low r, high Ar
L/S topt = wopt/S L/Smin
VDG 12/5/200327
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 MWTi for Clienti requests to Serveri within T ? in [t1, t1] ?)