1 / 21

563.9.3 DoS Overview DoS Countermeasures

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)

cleantha
Download Presentation

563.9.3 DoS Overview DoS Countermeasures

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 563.9.3 DoS OverviewDoS Countermeasures Presented by: Omid Fatemieh DoS Group: Fariba Khan, Omid Fatemieh, Roger Fliege University of Illinois Spring 2006

  2. 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

  3. 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

  4. 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?

  5. 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.

  6. 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

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

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

  13. 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

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

  15. 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

  16. 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

  17. 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

  18. 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

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

  20. 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

  21. Thanks Questions?

More Related