1. Limiting Denial of Service Using Client Puzzles Presented by Ed Kaiser

2. Papers [1] Towards Network Denial of Service Resistant Protocols Jussipekka Leiwo, Tumoas Aura, Pekka Nikander [2] Hashcash – A Denial of Service Counter-Measure Adam Back [3] Using Client Puzzles to Protect TLS Drew Dean, Adam Stubblefield

3. Overview Paper [1] is a survey of principles used to prevent Denial of Service (DoS) Paper [2] describes a system to prevent DoS of general services Paper [3] describes an implementation for preventing DoS of a specific service – the Transport Layer Security (TLS) protocol

4. Breakdown of Survey [1] Terminology Attack Methods Protocol Design Principles

5. Terminology Availability: a service can be accessed within a reasonable amount of time from the time of request Denial of Service: the result of a intentional attack against availability Network Denial of Service: DoS caused by an attack through the service’s communication interface

6. Attack Methods Tolerable Attacks: poor protocol design Deviation from Message Sequence: sending unexpected or not sending expected messages Deviation from Message Syntax: falsified data Deviation from Message Semantics: hiding the client’s identity Fabrication of Protocol Messages: falsified routing or error messages Fatal Attacks: physical or administrative control over part of the communication path

7. Protocol Design Principles Do easy attack detection before client authentication –Is the message timestamp recent? –Is the nonce-timestamp pair unused? Allocate memory only after client authentication Client workload should be higher than server workload Client workload should be easily definable

8. Breakdown of HashCash [2] Concept Properties of work HashCash system Non-interactive Interactive

9. HashCash Concept Clients must do work before they can get service Clients spend the proof of their labour like cash in order to get service

10. Properties of Work Publicly auditable Cost Fixed cost Probabilistic cost –Bounded –Unbounded Trapdoor free Parallelizability

11. HashCash System Servers follow one of two models; Non-interactive Interactive

12. Non-interactive HashCash Useful for protocols where there is no channel / session established Publicize a function with many solutions hash function with partial hash collisions Slowly change the function clients cannot stockpile solutions Requires keeping track of solutions used

13. Interactive HashCash Useful for channel / session protocols Can fairly and gracefully degrade service during DoS attack Dynamic throttling Requires the server to create a challenge

14. Breakdown of TLS Paper [3] Rationale TLS Protocol modification Implementation Puzzle triggering function Experimentation

15. Rationale Volume based DoS attacks stand out Transport Layer Security (TLS) server is a weak point that requires much less volume Create a puzzle option in the TLS protocol which can be turned on and off as needed

16. TLS Protocol Modification

17. Implementation Modification of OpenSSL library for querying server load Requires modified server that tells OpenSSL to send a puzzle Why? No state kept in the OpenSSL library Server might need to wait for a puzzle or not

18. Puzzle Triggering Function Low and high water marks

19. Experimentation Without PuzzlesWith Puzzles Outstanding Server Workload During DoS Attack