On the Prevention of Service Flooding in the Internet
Download
1 / 27

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


  • 86 Views
  • Uploaded on

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:

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

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:

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


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”


- 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


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


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


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?


    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


    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


    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


    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


  • 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


  • 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


    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


    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,


    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


    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


    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


    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


    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)


    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


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


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


    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 ?


    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


    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


    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