DDoS Defense by Defense by DDoS Offense Offense Published in ACM - - PDF document

1

DDoS DDoS Defense by Defense by Offense Offense

Published in ACM SIGCOMM’06

Presented By: Marwa K. Elteir

Outline Outline

Problem definition Problem definition Related Work Related Work Speak Speak-

• up

up

• Model

Model

• How far it is applicable?

How far it is applicable?

• Model constraints

Model constraints

Thinner Thinner

• Random drops and Aggressive reties

Random drops and Aggressive reties

• Explicit payment channel

Explicit payment channel

Handling heterogeneous requests Handling heterogeneous requests Performance evaluation Performance evaluation

2

Problem Definition Problem Definition

DDoS DDoS : Application level Distributed Denial : Application level Distributed Denial

• f Services.
• f Services.

computer criminals mimic legitimate client behaviour by sending proper-looking requests via compromised and commandeered hosts The attacker forces the victim server to spend much of its resources on spurious requests

Related Work Related Work

Over-provision massively.

Purchase enough computational resources to serve attackers

and good clients.

• Web sites try to conserve computation by detecting and

denying access to bots

Detect and block.

Distinguish between good and bad clients like profiling

techniques.

• They cannot easily handle heterogeneous requests

Charge all clients in a currency.

Gives a client service only after it pays in some currency. + There is no need to discriminate between good and bad clients + A client to pay more for hard requests

• Good users must in aggregate have more of the currency than

the attackers.

3

Speak up Speak up

An attacked server, B + g > c, (a) without speak-up (b) with speak-up.

Speak up Speak up

How much aggregate bandwidth does the legitimate clientele need for speak-up to leave them unharmed by an attack? Today’s botnets are less than 100,000 hosts average bot has roughly 100 Kbits/s of bandwidth – 500 Mbits/s assuming half bandwidth is used The average good client also has 100 Kbits/s of bandwidth. For spare capacity is 90%, speakup can fully defend the server against a 10,000-host if the good clients number is 1,000 n * 100 kbits/s = 1/9 (10,000 * 100 kbits/s) n =1,000

4

Speak up Speak up

How much aggregate bandwidth does the legitimate clientele need for speak-up to leave them unharmed by an attack? Assume that the number of served good clients Assume that the number of served good clients are proportional to their aggregate bandwidth. are proportional to their aggregate bandwidth. For a server with spare capacity 90%, the legitimate clientele needs only 1/9th of the aggregate bandwidth of the attacking clients

Thinner Thinner

Random Drops and Aggressive Retries Proportional allocation: by dropping requests at random to reduce the rate to c. Encouragement: for each request that it drops, immediately asks the client to retry. Please retry again now signal Problem : A good client sends only one packet per round-trip time (RTT). the clients send repeated retries in a congestion- controlled stream.

5

Thinner Thinner

Explicit payment channel Asks clients to pad their requests with dummy bytes. When the server is overloaded, the thinner asks a requesting client to open a separate payment channel. Contending client :The client then sends a congestion controlled stream of bytes on this channel. When the thinner receives such a notification from the server that it is ready, it holds a virtual auction: serve the client and terminate the channel

Handling heterogeneous requests Handling heterogeneous requests

Thinner breaks time into quanta. Each request is composed of equal-sized chunks. Thinner holds a virtual auction for each quantum. If a client’s request is made of x chunks, the client must win x auctions for its request to be fully served.

6

Handling heterogeneous requests Handling heterogeneous requests

Rather than terminate the payment channel once the client’s request is admitted:

Performance Evaluation Performance Evaluation

Validating the thinner allocation Validating the thinner allocation

7

Performance Evaluation Performance Evaluation

Validating the thinner allocation Validating the thinner allocation

Performance Evaluation Performance Evaluation

Latency Latency

8

Performance Evaluation Performance Evaluation

Byte cost Byte cost

Performance Evaluation Performance Evaluation

Heterogeneous network conditions (client Heterogeneous network conditions (client bandwidth) bandwidth)

9

Performance Evaluation Performance Evaluation

Heterogeneous network conditions (client Heterogeneous network conditions (client RTT) RTT)

Thank you Thank you