DDoS Defense by Offense

NIBIN MATHEW
S7 CS,
ROLL NO:20
OUTLINE
Introduction
Design
Implementation
Evaluation
Concerns
Conclusions
Introduction
•DDoS means application-level Distributed
Denial of Service
• a particularly noxious attack in which
computer criminals mimic legitimate client behavior.

•Attacker sends proper looking requests to waste

server’s resources
•Attack traffic is harder to identify
Introduction(cont.)
•Current defenses focus on slowing down
attackers/stopping the attack.

•But good clients are totally drowned out in

these defense systems – authors say it’s time
for them to speak-up.
Taxonomy of Defenses
Overprovision computation resources
massively
Detect and block attackers
Charge all clients a currency
Overview of Speak up
Currency-based defense
bandwidth as the currency
The central mechanism is the server
front-end, the thinner
Thinner
protects the server from overload
Applicability of Speak Up
How much aggregate bandwidth does the
legitimate clientele need for speak-up to be
effective?

Couldn’t small Web sites, even if defended by

speak-up, still be harmed?

Because bandwidth is a communal resource,

doesn’t the encouragement to send more traffic
damage the network?
Conditions to Make it Work

Adequate link bandwidth

Adequate client bandwidth

DESIGN
One of the limiting factors of attackers is bandwidth.
Good clients are using only small portion of their
available bandwidth.
Speakup is using bandwidth as the currency.

Without Speak up With Speak up

Design Goal
Allocate resources to competing clients in proportion to
their bandwidths
Required Mechanisms.
• Limiting requests to the server to c per second
• Revealing the available bandwidth
• Proportional Allocation
Variations of Speak-up
Random Drops and Aggressive Retries
Dropping requests at random to reduce the rate
to c
Clients send repeated retries
Thinner admits incoming requests with some
probability p
Price for access, r, is the number of retries
Variations of Speak-up
Explicit Payment Channel
 When server is overloaded, a requesting client
opens a separate payment channel
 A contending client sends stream of bytes on this
channel
 Thinner tracks how many bytes each contending
client sends
Server notifies thinner when ready for a new
request
Thinner holds a virtual auction
Heterogenous Requests
If all requests are treated equally, an
attacker can get a disproportionate share of
the server by sending only the hardest
requests
 “Hardness” of a computation
The thinner breaks time into quanta
Each request is seen as comprising equal-
sized chunks
Heterogenous Requests(cont.)
If a client’s request is made of x chunks, the client
must win x auctions for one request
The thinner extracts an on-going payment until
the request completes
The thinner can SUSPEND, RESUME, and ABORT
requests
Heterogeneous Requests(cont.)
The thinner holds a virtual auction for every
quantum
v is the currently active request and u is the
contending request that has paid the most
If u has paid more than v
If v has paid more than u
Time-out and ABORT any request that has been
SUSPENDED for some period
 Implementation
Any JavaScript-capable Web browser
can use the system
Thinner returns HTML to the client
with server’s response
When the server is not free, the thinner
returns JavaScript to the Web client that
causes it to automatically issue two
HTTP requests
Experimental Evaluation

Validating the thinner’s allocation

Heterogeneous network
conditions
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
Validating the thinner’s allocation
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
Validating the thinner’s allocation
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
Heterogeneous Network Conditions
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
Heterogeneous Network Conditions
Concerns
Bandwidth envy
Variable bandwidth costs
Solving the wrong problem
Flash crowds
Advantages
Main advantages
Network elements don’t need to
change
Only need to modify servers and add
thinners
Conclusion

Not sure who wants/needs speak-up

Survey to find out
Speak-up does what it proposes to do
References
http://www.cypherspace.org
http://www-static.cc.gatech.edu
http://www.spy.org.uk
http://doi.ieeecomputersociety.org/10.1109