Limiting Denial of Service Using Client Puzzles Presented by Ed Kaiser

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

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

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

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

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

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

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

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

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

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

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

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

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

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

TLS Protocol Modification

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

Puzzle Triggering Function Low and high water marks

Experimentation Without PuzzlesWith Puzzles Outstanding Server Workload During DoS Attack