VDG 12/5/20031

On the Prevention of Service Flooding in the

Internet

Virgil D. Gligorgligor@umd.edu

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%

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

VDG 12/5/20036

So, Is Flooding a Major Problem ?maybe not, but plenty of economic targets will change thisTarget 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

VDG 12/5/20037

Layer mDoS freedom

Layer m - 1DoS 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?

VDG 12/5/20038

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

Host

BGP

BGPBGP

BGP

BGP

BGP

BGP

BGP

RTS/VPRTS/VP

RTS/VP

RTS/VP

RTS/VP

RTS/VP

RTS/VP

RTS/VP

rtsrts

rts

Capability Distribution: hash value (hK); seq. no. (s0) included in each client packet

*Cable & Wireless, Sprint, MCI-WorldCom, Verizon, AT&T: 5 of approx. 50** approx. 7,500 ISPs

VDG 12/5/20039

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.

For all client requests,

Similar definitions for Per-Service Waiting Times

WPWT – wPWT w/o the constraint that p =/= 0.

VDG 12/5/200314

Relationships Among Access Guarantees

Legend: = implies

FWTs

PWTs

wPWTsMWTs

“some client

access”

client puzzles[DN92,JB99,

ANL00,DS01]

client puzzles +

assumptionexample 1

simpleexample 2

simpleexample 3

explicit rate-control agreements

wPWTrMWTr

FWTr

PWTr

FWTr <=/=>PWTr

WPWT

VDG 12/5/200315

Service (layer m)

guaranteed request-delivery path(layer m-1)

dependencies

U

s

e

r

A

g

r

mn

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

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.

VDG 12/5/200325

t1 t2 ti tj

1 wi/k L/k

L/s t = ti+1 - ti L/S

t1 t3

w1

w2wi

. . .

Phase 2:Time-Slot Reservation

tkt11

tkt21

tkt1-k

tktk1

==

=

t1, t2,t1,

t1,

cnt1

t2, cnt2

t2, cntk

. . .

. . .

1

client requests = wi

IPaddrC1

IPaddrC2

IPaddrCk

t*MAC1

* t = time at server

t*MAC2

t* MACk

user1 cookieT1 T2

= w1 L k

t1-t2 =t L/S

k tickets

VDG 12/5/200326

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

Ctotal/ w = 0 => wopt = , constrain: 1 wopt min(L,Ar)

c1 Ar c2(1-r)

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] ?)