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

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?

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.

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.

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

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. Why should this Work?

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.

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

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)

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

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

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.

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).

Thinner: Implementation Prototype built using JavaScript When server is not free (under attack): –JavaScript tells web client to re-send 1.Actual request 2.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.

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

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

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

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

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).

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?

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.

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)