1. Portcullis: Protecting Connection Setup from Denial-of-Capability Attacks Paper by: Bryan Parno et al. (CMU) Presented by: Ionut Trestian Gergely Biczók (Slides in courtesy of: Bryan Parno)

2. Network-Level Distributed Denial of Service Attacks Distributed DoS attack exhausts bandwidth of links leading to victim Recent example: Estonian government and bank sites attacked by Russian hackers (dispute over Soviet statue) Key issue: receiver has no control over incoming traffic! Several capability systems are proposed to alleviate this problem [e.g. SIFF, TVA, … ]

3. Capability system basics 1. Client C sends a best-effort request packet to server S. Packet accumulates a capability. 2. If S wants to allow C to send privileged traffic, S sends capability back to C 3. Packets with a capability are given priority over non- privileged packets R

4. Denial-of-Capability Attack That is nice but … … DDoS can block request packets too! So to prevent DDoS attacks … … capability systems need a DDoS defense mechanism !

5. Our starting claim Capability setup is fundamentally different from normal data traffic If one request goes through we succeed It can sustain more losses and higher cost (of any kind) Portcullis exploits this difference Setup is worth a reasonable cost to be safe from DDoS Cost is spread over all packets between source and destination Recall the definition of capability from [TVA]

6. Design Goals Network cannot distinguish attackers from defenders Best feasible solution: allocate bandwidth fairly Also, we need to bound the capability setup delay Setup time still depends on number of users/attackers and network capacity

7. How to Allocate Bandwidth Fairly? Identity-based fairness Per-source (e.g., IP address) NATs, spoofed addresses Per-path SIFF: hurting legitimate senders TVA: coarse-grained (per-interface) Per-destination Attacker can flood all destinations sharing the victm’s bottleneck link Legitimate user send packets only to single host Actually amplifies the power of attacker! We need something better!

8. Proof-of-Work Schemes Demonstrate the use of a limited resource Access to network resources proportonal to work done Per-bandwidth fairness Only demonstrated on end-host resources, and on an uncongested network Large disparities bw legitimate users (modem vs. fibre) Per-computation fairness Probability of request packet delivery ~ computational effort of sender

9. Per-computation fairness – puzzles Measure work with solving puzzles Work is performed at the end-host, not in the network Smaller disparities in computational power (PC vs. cellphone) Work is verifiable, unlike identifiers Our work addresses limitations of previous puzzle systems Clients can create and solve variable-difficulty puzzles without contacting the victim Each router on the path can independently verify the work performed

10. Portcullis Overview Client Router Server

11. Portcullis Overview Client Router Server

12. Portcullis Overview Client Router Server

13. Portcullis Overview Client Router Server Capability Setup

14. Portcullis Overview Client Router Server Capability Setup

15. Portcullis Overview Client Router Server Capability Setup

16. Portcullis Overview Client Router Server Capability Setup Capability Setup

17. Portcullis Overview Client Router Server Capability Setup Capability Setup

18. Portcullis Overview Client Router Server Capability Setup Capability Setup

19. Portcullis Overview Client Router Server Capability Setup Capability Setup Full Queue

20. Portcullis Overview Client Router Server

21. Portcullis Overview Client Router Server

22. Portcullis Overview Client Router Server

23. Portcullis Overview Client Router Server Capability Setup

24. Portcullis Overview Client Router Server Capability Setup

25. Portcullis Overview Client Router Server Capability Setup Capability Setup

26. Portcullis Overview Client Router Server Capability Setup Capability Setup

27. Portcullis Overview Client Router Server Capability Setup Capability Setup

28. Key Insight Fundamental asymmetry favors a legitimate client The client only needs one packet to succeed, but the adversary must keep the victim’s pipe full at all times A few hard puzzles will not congest the victim’s link Many easy puzzles can be bypassed by a legitimate client who solves a single hard puzzle

29. Puzzle Generation Client computes a flow-specific puzzle as: p H( Server IP || S || R || L || X) Where: – H is a hash function – S is the current puzzle seed – R is a randomly chosen 64-bit number – L is the puzzle difficulty level The solution X is chosen so that p = 0 mod 2 L Expected # of operation to find X is 2 L

30. Router Verification and Scheduling Verify puzzle solution with a single hash H( Server IP || S || R || L || X ) = 0 mod 2 L Prioritize packets with harder puzzles (larger L) Prevent local puzzle reuse with a Bloom Filter - Only records correct puzzle solutions

31. Legitimate Client Strategy Double the computational work included in each subsequent request Continue doubling until a request succeeds Our results show that this strategy succeeds regardless of attacker’s resources Knowledge of network congestion levels or attacker’s resources allows optimization

32. Puzzle Seed Creation and Distribution

35. Request

36. Puzzle Seed Creation and Distribution Request

37. Seed Generation and Verification Trusted seed generator releases a new puzzle seed every 5 minutes Puzzle seeds must be: – Unpredictable – Easily verified by hosts and routers Naïve implementation: – Seed generator: Picks a random number for the puzzle seed Uses a public key to sign the seed – Hosts and routers verify each signature

38. Seed Distribution Service Takes puzzle seeds and makes them available to clients Requires distributed, well-provisioned Servers E.g., CDN or DNS

39. Evaluation Theoretical Result #1 Proof that legitimate clients succeed in time O(M) M = Number of malicious machines Intuition Attacker can either fill the victim’s pipe or solve hard puzzles A legitimate client quickly sends a request at a level higher than the attacker can "afford"

40. Evaluation Theoretical Result #2 Proof that for any routing policy, the time needed for capability setup is O(M) Intuition Subverted machines can behave just like legitimate machines

41. Evaluation Simulation based on real Internet topology CAIDA Skitter map of over 174,000 networks Randomly placed legitimate clients and attackers at the edges Victim placed at the root Attackers establish DDoS by flooding at max uplink capacity We measure the time needed for 1000 legitimate clients to establish a capability

42. Portcullis Attacker Strategies Evaluate various adversarial strategies Naïve attacker simply floods without solving puzzles Puzzle solver: Chooses a flooding rate Pools all computational resources to solve the hardest puzzles possible while maintaining the chosen sending rate

43. Portcullis Attacker Strategies

44. Comparative Simulations Points of comparison: Per-bandwidth fairness (Speak up) [Walfish et al. 2006] Legitimate clients send requests at maximum uplink capacity Per-path fairness (TVA) [Yang et al. 2005] Packets queued based on previous Autonomous System (AS) Legacy (Random) Routers randomly select packets to forward and drop excess packets

45. Comparative Results

48. Conclusions Portcullis mitigates DoC attacks by allocating bandwidth based on per-computation fairness Novel puzzle mechanism strictly bounds the setup delay imposed by a given number of attackers Supported by proofs and simulations Makes capability systems a robust defense against DDoS attacks