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