DDoS Defense by Offense

1. DDoS Defense by Offense Michael Walfish, Mythili Vutukuru, Hari Balakrishnan, David Karger, and Scott Shenker, SIGCOMM ‘06 Presented by Karl Deng, Zhaosheng Zhu DDoS: Defense by Offense

2. Outline • Introduction • Design • Implementation • Evaluation • Concerns • Conclusions DDoS: Defense by Offense

3. Introduction DDoS: Defense by Offense

4. Basic Idea • Defense against application level DDoS attacks • Way of dealing with attack as it occurs, not a prevention scheme DDoS: Defense by Offense

5. Application-level attacks • Attacker sends legitimate-looking requests to waste server’s resources • Overwhelms server, not access links • Cheaper than link-level attacks (for the attacker) • Attack traffic is harder to identify DDoS: Defense by Offense

6. Application-level attacks Current defenses focus on slowing down attackers/stopping the attack. But good clients are totally drowned out in these defense systems – it’s time for them to speak-up. DDoS: Defense by Offense

7. 3 Types of Defenses • Overprovision computation resources massively • Detect and block attackers Rate-limit, filter, capability • Charge all clients a currency (scare resource) Such resources can be: • Digital payment (micro-payment) • Computational work (proof of work) e.g, solving a puzzle • Human attention (proof of humanity) e.g., CAPTCHA (Completely Automated Public Turing Test to Tell Computers and Humans Apart) DDoS: Defense by Offense

8. Speak-up • It’s a currency-based defense that uses bandwidth as the currency • Claim: attackers use most of their available bandwidth during attacks, victims don’t • Use encouragementto make victims send more traffic so they are better represented at the server DDoS: Defense by Offense

9. Two conditions to make it work… • Adequate Link Bandwidth: there must be enough spare bandwidth to allow for speak-up inflated traffic • Adequate Client Bandwidth: the aggregate bandwidth of all good clients must be on the same order as the attackers’ DDoS: Defense by Offense

10. Three conditions where it wins… • No predefined clientele: Makes filtering impossible, so use speak-up. • Non-human clientele: Makes “human” tests (type in the word, etc) impossible, so use speak-up. • Unequal requests orspoofing orsmart bots: No method for dealing with the first, can’t use methods for the second two… use speak-up!!! DDoS: Defense by Offense

11. Design DDoS: Defense by Offense

12. Design Goal Allocate resources to competing clients in proportion to bandwidth [math] DDoS: Defense by Offense

13. 3 Required Mechanisms 1. Way to limit the total requests to the server to its max, c 2. Mechanism to reveal available bandwidth/provide encouragement 3. Proportional allocation mechanism – let clients in proportional to delivered bandwidth Hence, the thinner appears. DDoS: Defense by Offense

14. Explicit Payment Channel Thinner pads client traffic with dummy bytes, but how many should we pad with? We don’t need to know that information! DDoS: Defense by Offense

15. Explicit Payment Channel • When server is overloaded, thinner asks clients to open separate payment channels (virtual auction) • Client sends bytes on this channel, becomes a contender • Thinner tracks how much each contender sends • When server is free, thinner admits the highest bidder and closes the channel DDoS: Defense by Offense

16. Heterogeneous requests Charging the same amount for unequal requests gives unfair advantage to attacker So charge per time chunk instead of per request DDoS: Defense by Offense

17. Heterogeneous requests Charge ongoing request • Instead of closing the bid channel after accepting a client, keep it open until request is served • Every unit of service time, reopen the auction DDoS: Defense by Offense

18. Heterogeneous requests • At time t, v is active connection, u is the highest contender • u > v, SUSPEND v, ADMIT (RESUME) u • v > u, let v continue sending, but reset its payment counter for time t+1 • ABORT requests that have been suspended too long DDoS: Defense by Offense

19. Implementation DDoS: Defense by Offense

20. Implementation DDoS: Defense by Offense

21. Evaluation DDoS: Defense by Offense

22. Evaluation • Validating the thinner’s allocation • Latency and byte cost • Adversarial advantage • Heterogeneous network conditions • Good and bad clients sharing bottlenecks • Impact of speak-up on other traffic DDoS: Defense by Offense

23. Validating the thinner’s allocation Question 1: Do groups get service in proportion to bandwidth? Setup: 50 clients over 100 Mb/s LAN Each gets 2Mb/s c = 100 req/s Vary f, the fraction of good clients DDoS: Defense by Offense

24. Validating the thinner’s allocation DDoS: Defense by Offense

25. Validating the thinner’s allocation • Speak-up defended clients are always a little behind ideal • Always fare better than undefended DDoS: Defense by Offense

26. Validating the thinner’s allocation Question 2: What happens when we vary the capacity of the server? Setup: 25 good clients, 25 bad clients cid = 100 c = 50, 100, 200 DDoS: Defense by Offense

27. Validating the thinner’s allocation DDoS: Defense by Offense

28. Validating the thinner’s allocation DDoS: Defense by Offense

29. Validating the thinner’s allocation • Good clients do best when the server has ability to process all requests (i.e., large c) • Service proportional to bandwidth even when server can’t process all requests DDoS: Defense by Offense

30. Latency cost • Same setup as last experiment • Measures the length of time clients spend uploading dummy bytes DDoS: Defense by Offense

31. Latency cost DDoS: Defense by Offense

32. Latency cost • With a large c, cost isn’t very high • Even with a small c, worst added delay is 1s. • Pretty bad, but not as bad as getting no service during an attack, right? DDoS: Defense by Offense

33. Byte Cost • Still the same setup • Measure the average number of bytes uploaded for served requests DDoS: Defense by Offense

34. Byte Cost DDoS: Defense by Offense

35. Byte Cost • Bad clients do end up paying more than good clients DDoS: Defense by Offense

36. Heterogeneous Network Conditions • First, look at varied bandwidth • 5 client categories, 10 clients in each category • Bandwidth for category i = 0.5i Mbps (1 <= i <= 5) • All clients are good clients • c = 10 DDoS: Defense by Offense

37. Heterogeneous Network Conditions DDoS: Defense by Offense

38. Heterogeneous Network Conditions • Roughly proportional to bandwidth of clients • Close to ideal DDoS: Defense by Offense

39. Heterogeneous Network Conditions • Now look at effect of varied RTT • 5 client categories, with 10 clients in each • RTT for category i = 100i ms (1 <= i <= 5) • Bandwidth per client = 2 Mbps • c = 10 • Run with all good or all bad clients DDoS: Defense by Offense

40. Heterogeneous Network Conditions DDoS: Defense by Offense

41. Heterogeneous Network Conditions • Good clients with long RTTs do worse than any bad clients DDoS: Defense by Offense

42. Good and Bad Sharing a Bottleneck • 30 clients, each with 2 Mbps, connect to thinner through link l • l‘s bandwidth = 40 Mbps • 10 good, 10 bad clients, each with 2Mbps, connect directly to thinner • C = 50 req/s • Vary number of good/bad behind l DDoS: Defense by Offense

43. Good and Bad Sharing a Bottleneck DDoS: Defense by Offense

44. Good and Bad Sharing a Bottleneck • Clients behind lcapture half of the server’s capacity • Good behind l suffer some, especially with greater number of bad clients • Effect on good clients greater when bottleneck is smaller DDoS: Defense by Offense

45. Impact of speak-up on other traffic • Bottleneck, m, shared between speak-up clients and TCP endpoint, H • Run with H as a sender, m is shared fairly • Run with H as a receiver, H’s ACKs will get lost, H’s requests will be delayed DDoS: Defense by Offense

46. Impact of speak-up on other traffic • Experimented specifically with H as a receiver • 10 good speak-up clients, 1 HTTP client downloading with wget • m = 1Mbps, rest = 2Mbps • c = 2 DDoS: Defense by Offense

47. Impact of speak-up on other traffic DDoS: Defense by Offense

48. Impact of speak-up on other traffic • Huge impact on H • “Pessimistic” result according to authors • Only happens during attack, might be worth it to help “defend the Internet” DDoS: Defense by Offense

49. Concerns DDoS: Defense by Offense

50. Concerns/Cautions/Objections • Does speak-up hurt small sites? • Yes, for current sized botnets • But this might get better with smaller botnets • Does speak-up hurt the whole Internet? • Not really • Only for servers under attack • Core over-provisioning dampens the effect • Congestion control will keep speak-up under control DDoS: Defense by Offense