DDoS Defense by Offense

1. DDoS Defense by Offense Presented by: Matthew C.H. Ma Damon Chan

2. Introduction • Offense is the best defense? • This principle often applies to sports, military strategy, etc. Examples: • Phoenix Suns (Basketball) • WWII Germany (Blitzkrieg) • Does this apply to Internet? • When and how?

3. Motivation • Denial-of-Service (DoS, DDoS) attacks cost companies billions of dollars each year. • Service level must be maintained for mission-critical work. • Need to protect against such attacks. • Aim to provide better service to good clients in the event of a DDoS attack.

4. Summary of Paper • Presents a method to defend against application-level DDoS attacks, through counter-attack. • Method is called Speak-Up. • Describes idea, design, implementation. • Prototype, evaluate and analyze effectiveness of method in a simulation environment.

5. What is Speak-up? • When server is under DDoS attack, encourage all clients to send more traffic: • DEMONSTRATION

6. Why should this Work? • Assumption: Bad clients already using most of their upload bandwidth. • All clients encouraged. • Bad clients are also encouraged but they are unable to send more. • Good clients make up larger proportion of total traffic. • Result: Good clients receive better service.

7. Compare with Other Methods (1) • Massively Overprovision • Provide enough resources to serve both attackers and good clients • Detect and Block • Profile IP addresses. • block/limit unauthorized access. • Cannot easily handle heterogeneous requests.

8. Compare with Other Methods (2) • Currency Based • Allow service only after client pays a currency. • No need to discriminate, harder requests pay more. • Speak-Up is a currency based method: • Currency = Bandwidth

9. Applicability (1) • Bandwidth • Speak-Up helps good clients in proportion to their available bandwidth • Attackers need more resources to do the same damage • Protection for Good Clients • Possible for good clients to maintain full service. • Depends on the server's spare capacity: • (One minus utilization)

10. Applicability (2) • Effect on Network • More overall traffic does not damage network. Additional traffic shares fairly with other traffic (congestion control). • Only a very small fraction of all servers will be under attack at any one time. • Conditions • Required: • C1: Adequate link bandwidth • C2: Adequate client bandwidth • Optional (Speak-Up offers advantage when): • C3: No pre-defined clientele • C4: Non-human clientele • C5: Unequal requests, spoofing, smart bots

11. Design (1) • Three Required Mechanisms: • Limit number of requests to server. • Allocation method that reveals the bandwidth. • Perform encouragement to clients. • Thinner • Placed in front of the server to implement the 3 mechanisms:

12. Design (2) • Random Drop, Aggressive Retries • Separate Payment Channel • Give server access to client who has sent the most bits through the payment channel. • Handling Heterogeneous Requests • More realistic case • Thinner can break a hard request into equal sized chunks. • Take an ongoing payment until request completes.

13. Examining the Design • Effect on Network • Internet ‘core’ at low utilization. • Adequate bandwidth except at bottleneck links. • Shared (bottleneck) Links • Good & Bad clients share same link. Good client loses out with/without Speak-Up. • Provisioning the Thinner • Needs enough bandwidth & processing power. • Easier than provisioning the server itself (since the thinner does less).

14. Thinner: Implementation • Prototype built using JavaScript • When server is not free (under attack): • JavaScript tells web client to re-send • Actual request • HTTP POST containing dummy data (large) • Track the amount of dummy data. • Payment = deducting the amount of data sent. • Used to simulate environment to test the theory.

15. Experimental Evaluation (1) • Allocation to good clients: • Speak-up improves service to good clients Fig 2. Server allocation to Good Clients

16. Experimental Evaluation (2) • Comparison with/without speak-up: • Speak-Up offers advantage when turned on. Fig 3. Server allocation to Good vs. Bad Clients when Aggregate Good Client bandwidth = 50, 100, and 200 Mbits/s

17. Experimental Evaluation (3) • Payment Time (Latency) • Speak-up introduces little latency for clients to send extra data through payment channel. Fig 4. Time needed to make payment

18. Experimental Evaluation (4) • Average Payment • Good clients pay almost nothing when server is not overloaded. Fig 4. Average Payment: ‘Price’ of served requests

19. Disadvantages • Unfair allocation • Clients with higher bandwidth receive better service. • Clients may have to pay for extra bandwidth. • Incentives for ISPs to encourage botnets • Flash crowds treated like an attack (whenever the server is overloaded).

20. Conclusion • Speak-up offers a special brand of protection against DDoS attacks. • Based on the design and analysis of the prototype, speak-up seems to be a practical design • But still at a very early stage, needs much future work and investigation. • Needs a ‘market survey’ • Will ISPs be willing to implement this as a service? • Who needs it?

21. Our Opinion of Speak-Up: What We Like • Achieves Aim. • improves service level of good clients during attack • Concept is ‘elegant’. • Simple idea; Exploits weakness of attackers. • Effect/Cost on the network seems to be acceptable. • Get more out of spare server utilization.

22. Our Opinion of Speak-Up: What We Don’t Like • Effect of low-rate attack not addressed • Bad client also has spare bandwidth. • Aggressive retries could make things worse in the event of severe network failures • Assumptions hold because of nature of current network characteristics • How to detect when these assumptions break? • Switch off speak-up (automatically?) under these conditions. • Effect of various traffic patterns? (i.e. heavy-tail distribution)