563 9 3 dos overview dos countermeasures
Download
Skip this Video
Download Presentation
563.9.3 DoS Overview DoS Countermeasures

Loading in 2 Seconds...

play fullscreen
1 / 21

563.9.3 DoS Overview DoS Countermeasures - PowerPoint PPT Presentation


  • 155 Views
  • Uploaded on

563.9.3 DoS Overview DoS Countermeasures. Presented by: Omid Fatemieh DoS Group: Fariba Khan, Omid Fatemieh, Roger Fliege University of Illinois Spring 2006. Previous Presentations . Taxonomy of DoS attacks (Roger Fliege, Mar 10) Overview of DoS countermeasures (Fariba Khan, Mar 10)

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 '563.9.3 DoS Overview DoS Countermeasures' - cleantha


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
563 9 3 dos overview dos countermeasures

563.9.3 DoS OverviewDoS Countermeasures

Presented by: Omid Fatemieh

DoS Group: Fariba Khan, Omid Fatemieh, Roger Fliege

University of Illinois

Spring 2006

previous presentations
Previous Presentations
  • Taxonomy of DoS attacks
    • (Roger Fliege, Mar 10)
  • Overview of DoS countermeasures
    • (Fariba Khan, Mar 10)
  • Focus of this presentation:
    • Guaranteeing access in spite of distributed service-flooding attacks
    • Mainly focused on Gligor 03 paper.

Gligor 03

end to end argument
End-to-end Argument
  • Open networks deigned using end-to-end argument
    • Network performs common simple functions
    • End-servers implement complex functions required by fewer applications
  • Great technical idea for assuring network performance in large scale
  • Causes a gap between network line rate and application server rates
    • Will this gap be closed?

Saltzer Reed Clark 84

end to end argument cont d
End-to-end Argument (cont’d)
  • Enables flooding attacks that cannot be detected and handled within the network
  • A Potential solution
    • User agreements: Constraints placed on the behavior of clients to help guarantee access
      • Pricing mechanism: solve cryptographic puzzles
  • Given a specification of request scheduling, what is the weakest user agreement that supports a desired guarantee of client access?
  • If the scheduling specification could be changed, what change would assure a desired guarantee for a given user agreement?
assumptions
Assumptions
  • DoS attacks at and below the transport layer are handled
  • Application later protocol/server flaws or DoS enabling features are removed
  • We identified the problem as an end-to-end problem:
    • We need end-to-end solutions for it, no matter how effective IP layer flooding countermeasures are.
client guarantees
Client Guarantees
  • Guarantees which specify bounded waiting time on a per-request basis are of practical interest
  • Maximum Waiting Time (MWT)
    • A client’s request is accepted in time T
  • Finite Waiting Time (FWT)
    • A client’s request is accepted for service eventually

Gligor 83Millen 92

client guarantees7
Client Guarantees
  • Probabilistic Waiting Time (PWT):
    • The probability that a client’s request is accepted for service in time T is not less than p (p is independent of attack).
  • Weak Probabilistic Waiting Time (wPWT):
    • The probability that a request is accepted for service eventually is not less than p.
relationship between guarantees
Relationship between Guarantees
  • AB means that if guarantee A is satisfied so is B.
  • MWTPWTwPWT
  • MWTFWTwPWT
  • No such relationship between PWT and FWT
client puzzles
Client Puzzles
  • Each client solves a challenge puzzle as a proof of work
  • Servers schedule requests on the basis of strength of puzzles (k)
    • Server accepts a range of levels (e.g. 14 to 19)
    • All requests that solved the puzzle incorrectly or not at all are dropped
    • Pre-emptive scheduler
    • At max level k, if aggregate request rate is high, the server drops extra requests and changes the level range
client puzzles based on hash functions
Client Puzzles Based on Hash Functions
  • The cost of a puzzle solution to a client is exponential in k
    • Ex. Finding a hash function output that has k consecutive zeros in the higher order bits
  • A puzzle is a Bernoulli experiment with probability 2-k of success

i

h(i) = 0…0hk+1…hm

h

hash based client puzzles guarantees
Hash-based Client Puzzles Guarantees
  • It is proven that user agreements based on client puzzles can provide the wPWT guarantee
  • wPWT guarantee: for any number of retries R that is fixed at the time of request

Pr [any client C’s request is accepted in time T] >0

and is dependent on the attack parameters (i.e. number of clients Z controlled by the adversary)

Wand Reiter 03

limitations of hash based puzzles
Limitations of Hash-based Puzzles
  • Weak access guarantees
    • Attack coordination:
      • The ability to distinguish client requests based on puzzle levels is lost (since all people have the same level)
      • A legitimate client’s best chance of access is at the highest level
    • Can not guarantee PWT or FWT
  • High request overhead
simple user agreement
Simple User-Agreement
  • Client agrees to resubmit a dropped request or retry
  • No constraint on clients’ behavior
  • Adversary keeps the aggregate rate of all its clients under N
simple user agreement without preemption
Simple User-Agreement without Preemption
  • Random L requests without preemption
    • Service scheduler buffers up to M > L requests (L = length of server’s queue)
    • Picks up to L of them at random
    • Places them in an L-entry queue
    • Drops the rest

Pr [any client C’s request is accepted eventually] p ≠ 0

  • The guarantee provided is still only wPWT at the same request overhead or lower than puzzle auctions (no FWT)
simple user agreement with preemption
Simple User-Agreement with Preemption
  • Random L requests without preemption
    • If the server’s queue is full, picks a uniform random number in [0, L]
    • If the number is zero, drops the new request
    • If not, frees a slot by dropping the client’s request

Pr [any client C’s request is accepted in time T] p ≠ 0

  • It has PWT guarantee (p is independent of any attack parameters)
  • The lower bound is very small
rate control agreements for mwt guarantees
Rate-Control Agreements for MWT Guarantees
  • A rate-control service (RCS) is associated with each application service
  • Each client obtains an access ticket from RCS
  • Ticket validity is checked by a Verifier
  • Verifier and RCS are synchronized and share a symmetric key K
  • K used for creating a MAC on the ticket
rate control agreements for mwt guarantees17
Rate-Control Agreements for MWT Guarantees
  • MAC generation and verification is cheap
  • RCS and Verifier can execute operations at rates that far exceed the network line rate
  • Ticket includes: start time, end time, count of the max number of accesses, sender IP, issue time

Ticket Request

Request + Ticket

Response

Ticket

Request

Verifier

RCS

Server

discussion questions
Discussion Questions
  • Requires ingress filtering at network edges
    • “Approximately one-quarter of the observed addresses, netblocks and autonomous systems (AS) permit full or partial spoofing.”
  • Is it really solving the problem? What if the attackers ask for a lot of tickets?
    • Use Reverse Turing Tests to make sure a human is behind the machine
    • “Verify human activated, hardware implemented, trusted path on trusted computing equipped client machine that is registered with designated internet servers”
  • What if the application does not need a human behind it?

Beverly Bauer 05vonAhn Blum Hopper Langford 03Pearson et al. 03

performance considerations
Performance Considerations
  • Assuming the typical round trip delay of 140ms
  • Per-request overhead:
    • For a request that otherwise would take one second
      • 14% (as opposed to 170% for the 5-bit sequence of the hash based puzzle)
    • For a protocol requiring two to ten accesses of 100ms each
      • Between 14% to 70% (as opposed to over 1000% for the 5-bit sequence of the hash based puzzle)
conclusions
Conclusions
  • Gligor 03:
    • Looked at A new perspective on DoS by separating it from lower layer
    • Focused on DoS from the end-to-end perspective
    • Analyzed end-to-end approaches using defined guarantees
  • None of the approaches really solves the problem unless human interaction involved
  • Raising the bar approach seems to be promising in practice but not in theory
thanks
Thanks

Questions?

ad