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

DDoS Defense by Defense by DDoS 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 1

Problem Definition Problem Definition DDoS : Application level Distributed Denial : Application level Distributed Denial DDoS of Services. of 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. 2

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 3

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

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

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 6

Performance Evaluation Performance Evaluation Validating the thinner allocation Validating the thinner allocation Performance Evaluation Performance Evaluation Latency Latency 7

Performance Evaluation Performance Evaluation Byte cost Byte cost Performance Evaluation Performance Evaluation Heterogeneous network conditions (client Heterogeneous network conditions (client bandwidth) bandwidth) 8

Performance Evaluation Performance Evaluation Heterogeneous network conditions (client Heterogeneous network conditions (client RTT) RTT) Thank you Thank you 9