Michael Walfish, Mythili Vutukuru, Hari Balakrishnan, David Karger, and Scott Shenker Presented by Sunjun Kim, Donyoung Koo 1DDoS Defense by Offense

Introduction – Application-level DDoS Attack – Applicability of Speak-up Design of Speak-up – Design approaches – Two approaches Implementation Experimental Evaluation Objections Conclusion DDoS Defense by Offense 2

3

Defense against application-level DDoS – After occurrence – No prevention – Slow down attacks For savvy attacker – Requirement of far less bandwidth – “in-band”, harder to identify & more potent Example – Bots attacking Web sites  Requests for large files  Requests issuing computationally expensive cost DDoS Defense by Offense 4

Purpose – For exhaustion of server’s resources – No access, just for overwhelming Characteristics – Cheaper – Proper-looking – Hard to identify DDoS Defense by Offense 5

6 Good Bad B server c g g

Over-provision – Additional resource purchase Detect and Block – Profiling by IP address – CAPTCHA-based – Capabilities Charge in a currency – No need for discremination DDoS Defense by Offense 7

Bad Clients are already exhausted – Already Full-bandwidth usage – Cannot respond to encouragement by Speak-up Application-level DDoS attacks server resources – Not attacking network linkage – Total bandwidth may sufficient even with DDoS attack DDoS Defense by Offense 8

Currency-based approach – Bandwidth for Currency Central mechanism – Thinner, Server front-end Thinner – Front-end to server – Protection of server from overload – Encouragement of clients  In the form of “Virtual auction” DDoS Defense by Offense 9

10 Good Bad B server c thinner

How much aggregate Bandwidth by legitimate clientele? – If 90% spare capability : 1/9 th than attacker – If 50% spare capability : same as attacker For small site? (when legitimate clientele are small) – With combination of other defense mechanisms – Smaller botnets(but smarter) in the future Possibility of damage to communal resources – Inflation only to servers under attack, very small fraction – “core”, absorption through over-provision DDoS Defense by Offense 11

Adequate Link Bandwidth for Server – To handle inflated speak-up traffic – Common deployment to be ISPs Adequate Client Bandwidth – To be unharmed during an attack – In total, the same or more order of magnitude bandwidth No pre-defined clientele Non-human clientele Unequal request, spoofing, or smart bots DDoS Defense by Offense 12

13DDoS Defense by Offense

gB c In a request-response server – Cheap for clients to issue – Expensive for server to provide Variables for Modeling – Server capacity: c requests/sec – Demands from good clients: g requests/sec – (Max.) demands from bad clients: B requests/sec – Max. demands of good clients: G requests/sec – g << B – Server process  min( g, ) DDoS Defense by Offense 14 gGB thinner c g gB c

Modest over-provisioning is enough for good clients – Good client demand is satisfied when – From the equation above, – If B=G, c = 2g  50% spare capability required – If B=9*G, c=10g  90% spare capability require DDoS Defense by Offense 15

Encouragement – Cause client to send more traffic Proportional Reduction – Rate limiting  Way to limit requests to server  c requests/sec – Proportional Allocation  Admission of clients  At rates proportional to incoming bandwidth DDoS Defense by Offense 16

Random dropping of requests to the rate to c Encouragement for dropped request – Immediate request for client to retry  “please-retry” signal  Taxing easier than identifying – Modification of scheme  Request pipelining  Pipe to the thinner full Price r = 1/p – Client with affordable price,rate g as required – Client without affordable price, DDoS Defense by Offense 17

Choosing client – Paying more price in “Payment auction” Separate “Payment” channel – Thinner requests client to open Payment channel – Clients send congestion-controlled byte sequence to Thinner – Tracking # bytes by thinner  In virtual auction, # bytes = price – When server is available, thinner admits the winner, and terminates the payment channel. Average price = DDoS Defense by Offense 18

DDoS Defense by Offense 19 Approach I  Thinner should determine (which means, expect B,G)  Pays in-band Approach II  Simply select winning bidder  Pays on a separate channel - depends on application

Approach II cannot claim that good clients get Theorem – If any client transmit ε fraction of average bandwidth it can get at least ε/2 fraction of service – Key idea : one client should spend their bandwidth to defeat other clients, so it’s hard to win forever. Over-provision by factor of 2 – 100% more provision than ※ 15% in evaluation DDoS Defense by Offense 20

Generalization of design – More realistic case with unequal requests Attacker may request only “Hardest” requests Assumptions – “hardness” is counted by how long it takes to compute – Server provides an interface to Thinner SUSPEND, RESUME, and ABORT requests DDoS Defense by Offense 21

DDoS Defense by Offense 22 Request 1 Request 2 Request 3 Server Thinner Request 1 Request 2 Request 3 RESUME request 1 SUSPEND request 1 RESUME request 2 SUSPEND request 2 RESUME request 1 RESUME request 3 SUSPEND request 1 ABORT request 3 SUSPENT request 3 RESUME request 1 Time-out Done

Explicit Payment Channel 23DDoS Defense by Offense

Running on – Linux 2.6 kernel – Exporting well-known URL Thinner – Prototype implemented in C++ – Requested from clients – Decide when to send requests to the server – Received responses from the server, and forward to clients – Classify each client by “id” field in HTTP request DDoS Defense by Offense 24

Thinner’s Decision – When to send request to server – Using “Explicit Payment Channel” Server “processes” – With “Service Time” selected randomly between 0.9/c and 1.1/c – Respond to requests Thinner’s Return – HTML to client with server’s response DDoS Defense by Offense 25

JavaScript sent from thinner (Encouragement) – Automatically issuing two requests – One for actual request – One for 1MB HTTP POSTs  Dynamic construction by browser  Dummy data inclusion  Payment channel Client’s win – Termination of HTTP POST request – Submission of actual request to server Client’s lose – JavaScript from thinner – Trigger process continuation DDoS Defense by Offense 26

Explicit Payment Channel 27DDoS Defense by Offense

On Emulab testbed – Python Web clients connected to Python Thinner in various topology Requests by Poisson process – Rateλ requests/sec Server – Processing at rate c request/sec 50 clients – With 2 Mbits/sec each – B + G = 100 Mbits/sec – Good client: λ = 2w = 1 – Bad client: λ = 40w = second experiments – 1451 Mbps (stdev 38Mbps) for payment bytes – 379 Mbps (stdev 24Mbps) for regular requests(both from good and bad) DDoS Defense by Offense 28

DDoS Defense by Offense 29 Server allocation with c = 100 requests/sec

In different “provisioning” regimes DDoS Defense by Offense 30

Mean time to upload dummy bytes for good requests DDoS Defense by Offense 31

Average number of bytes sent on the payment channel DDoS Defense by Offense 32

Heterogeneous client bandwidth with 50 all good clients DDoS Defense by Offense 33

Two sets of heterogeneous clients RTT DDoS Defense by Offense 34

50 Clients – 30 Clients behind bottleneck – 10 Good Clients connected to Thinner directly – 10 Bad Clients connected to Thinner directly DDoS Defense by Offense 35 60Mbps 20Mbps 40Mbps 2Mbps/client

DDoS Defense by Offense 36

DDoS Defense by Offense 37

38DDoS Defense by Offense

Under speak-up – More good clients “better off” – High-bandwidth good clients “more better off” Unfairness with speak-up – Only under attack – Unfortunate, but not fatal Possible solution for ISPs – Offering low-bandwidth customer to high-bandwidth proxy that “Pay bandwidth” to thinner DDoS Defense by Offense 39

In some countries – Payment for “per-bit” – Under speak-up, more actual payment Possible solutions – Proxies provided by ISPs – Exposition of “going rate” in bytes by thinner  Translation of rate to money and report  Up to customer whether to pay DDoS Defense by Offense 40

Incentive to encourage botnets – In many commercial relationships Trust in – Regulation – Professional norms – Reputation to limit harmful conduct DDoS Defense by Offense 41

Problem caused by bots – Isn’t this approach too mess? – Encouraging more traffic ?! Cannot clean up whole – Even if bots are reduced by order of magnitude – Bots can still do effective attack (smart bots)  Speak-up is still useful DDoS Defense by Offense 42

Overload from good clients alone – Treat like application-level DDoS Not applicable case for low bandwidth service – Find another solution, please DDoS Defense by Offense 43

44DDoS Defense by Offense

Who needs speak-up? – Survey to find out But we can say that, it works. Main advantages – No need to change network elements – Only need for server modification & Thinner addition – Client also should be modified little bit Main disadvantages – Possibility of edge network hurt – Assumptions may not hold in many cases DDoS Defense by Offense 45

Distributed Thinner – Problem : Thinner should aggregate all “encouraged” traffic, may results in congestion – Solution : Distribute Thinner to regulate traffic step-by-step One approach – Paper in ICC 2008 [ Combining Speak-up with DefCOM for Improved DDoS Defense ] – DefCOM : Distributed DDoS Defense System  Combine speak-up as its rate-limiter  As a result, thinner is distributed DDoS Defense by Offense 46

Any question? DDoS Defense by Offense47