slide1
Download
Skip this Video
Download Presentation
On the Prevention of Service Flooding in the Internet

Loading in 2 Seconds...

play fullscreen
1 / 27

On the Prevention of Service Flooding in the Internet - PowerPoint PPT Presentation


  • 87 Views
  • Uploaded on

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. Outline. I. Application-Service Flooding:

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' On the Prevention of Service Flooding in the Internet' - orli


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

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

slide2

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

slide3

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”
slide4

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

slide5

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

slide6

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

slide7

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?

slide8

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

slide9

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

slide10

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

slide11

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
slide12

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
slide13

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

slide14

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

slide15

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,

slide16

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

slide17

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

slide18

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

slide19

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

slide20

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

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

slide22

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

slide23

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

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 ?

slide25

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

slide26

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

slide27

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