563.9.3 DoS Overview DoS Countermeasures

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?