1. DDoS Defense by Offense Michael Walfish, Mythili Vutukuru, Hari Balakrishnan, David Karger, and Scott Shenker Presented by: Boris Kurktchiev and Kimberly Yonce

2. Overview ➲ What is a Distributed Denial of Service attack? ● DoS – attacker cripples a server by sending legitimate looking requests that consume computational resources (e.g. CPU and disk space). This type of an attack is usually performed on the application layer. ● DDoS – is the same thing as DoS but instead of having a single point of attack the victim is bombarded from different locations on the Internet. ● Examples - Bots attacking websites by: requesting large files, making queries of search engines, and issuing computationally expensive requests.

3. Overview

4. ➲ Speak-Up – a victimized server encourages all clients, resources permitting, to automatically send higher volumes of traffic. ➲ Why do we want to do this? ● The good clients crowd out the bad ones, thereby capturing a much larger fraction of the server's resources than before.

5. The Present Situation ➲ Over-provision Massively – a company can theoretically purchase enough computational power in order to withstand such massive attacks. However, in most cases they purchase large link capacity and try to conserve computation. ● Companies are going to 3 rd party providers and are paying $12,000 and upwards a month for DDoS protection. ● Companies such as AT&T, MCI and Prolexic absorb the bandwidth/computational costs of a DDoS.

6. The Present Situation ➲ Detect and Block – this approach tries to distinguish between good and bad clients. The techniques employed in this category are powerful because they seek to block or explicitly limit unauthorized users, but their discrimination can err. For example, they cannot handle heterogeneous requests easily. ● The three most commonly used techniques are IP profiling, CAPTCHAs and capabilities.

7. The Present Situation ➲ Detect and Block ● IP Profiling is used by Cisco to protect from distributed denial-of-service (DDoS) attacks by performing per-flow- level attack analysis, identification and mitigation to block specific attack traffic. ● CAPTCHA an acronym for "Completely Automated Public Turing test to tell Computers and Humans Apart" is a type of challenge-response test used in computing to determine whether or not the user is human by usually using distorted images. ● A capability refers to a value that references an object along with an associated set of access rights. A capability is a communicable, unforgeable token of authority. A capability is typically implemented as a privileged data structure that consists of a section that specifies access rights, and a section that uniquely identifies the object to be accessed.

8. The Present Situation ➲ Charge all clients in a currency – here an attacked server gives a client service only after it pays in some currency (e.g. CPU, memory cycles or money). ● Speak-Up is such a service and we are going to be discussing it exclusively for the rest of the presentation.

9. Speak-Up ➲ Speak-Up implements the Charge all clients in a currency method of protection. In order to do this Speak-Up utilizes a server front end called the Thinner. ➲ Thinner – protects the server from overload and performs encouragement. This is achieved by: ● Virtual auction – when the server is overloaded the Thinner causes each new client to automatically send a congestion controlled stream of dummy bytes on a separate payment channel. When the server is ready to process the request the thinner selects the client that has sent the most bytes.

10. Speak-Up

11. ➲ In order to achieve this Virtual Auction Speak-Up implements the Thinner as a web front end. The Thinner performs encouragement by giving JavaScript to unmodified web clients that makes them send large HTTP POSTs. The POSTs are the bandwidth payment used in the Virtual Auction. ➲ Note that Speak-Up relies on the availability of upload bandwidth of the clients.

12. Speak-Up ➲ How much bandwidth does a client need in order to be serviced? ● Speak-up helps good clients no matter how much bandwidth they have. It either ensures that the good clients get all the service they need or increases the service they get (compared to an attack without speak- up), by the ratio of their available bandwidth to their current usage, which is expected to be extremely high.

13. Speak-Up ➲ How much bandwidth do we need in order to be unharmed by the attack? ● This depends on the server's spare capacity when not attacked. For example, if a server has 50% spare capacity then the legitimate clients can retain full service if they have the same aggregate bandwidth as the attacking clients. On the other hand, if the spare capacity is 90% then the legitimate clientèle needs only 1/9 of the aggregate bandwidth of the attacking clients.

14. Speak-Up ➲ Won't small Web sites still be harmed? ● Yes, they will. However, the idea is that since we have good prevention methods for defending against large but dumb bot net attacks, the attackers will start using smaller but smarter bot nets in order to achieve their goals, thus making speak-up applicable for small websites as well.

15. Speak-Up ➲ If we are using so much bandwidth won't we damage the network as a whole? ● It inflates traffic only to servers that are currently under attack, which is a very small fraction of servers, thus the increase in total traffic is minimal.

16. Speak-Up ➲ What are the minimal conditions for Speak- Up to work to our advantage? ● Adequate link bandwidth – the protected service needs enough link bandwidth to handle the incoming request stream. ● Adequate client bandwidth – the good clients must have in total roughly the same order magnitude (or more) bandwidth as the attacking clients.

17. Speak-Up ➲ What are the ideal conditions for Speak-Up? ● No predefined clientèle – otherwise the server can install filters or use capabilities to permit traffic only from their clients. ● Non-human clientèle – if the clientèle is exclusively human, one can use proof of humanity tests. ● Unequal requests – we can charge clients more/less depending on the requests.

18. Robustness to Cheating ➲ A theorem that describes Speak-Up in action. Note that the theorem assumes that requests are served in a perfect regularity pattern (i.e. every 1/c seconds): ● In a system with regular service intervals, any client that continuously transmits an ε fraction of the average bandwidth received by the thinner gets at least an ε/2 fraction of the service, regardless of how the bad clients time or divide up their bandwidth.

19. Robustness to Cheating ➲ In order to explain the theorem we’re going to use the following notations: ● X = a client ● t = number of auctions X must wait ● k = number of auctions X wins ● t 1 = number of auctions that occur until X’s first win, t 2 = number of auctions that occur until X’s second win, etc. ● Think of the bandwidth that X delivers for every auction as dollars. ➲ Thus, ● This is due to the fact that in the first auction 1 dollar is spent to defeat it, in the next auction 2 dollars is spent to defeat it, etc. This continues until t i -1 dollars are spent to defeat it.

20. Robustness to Cheating ➲ Therefore, dollars are spent to defeat X before it wins. ➲ Also, the total dollars spent by the other clients over the t auctions is at least: ➲ Adding the t dollars spent by X, the total number of dollars spent is at least

21. Robustness to Cheating ➲ Thus the fraction of the total spent by X, which we called ε, is at most ➲ It follows that i.e. X receives at least an ε/2 fraction of the service.

22. Robustness to Cheating ➲ One weakness of the theorem is that it is an unreasonable assumption that requests are served with perfect regularity. ● An example of this would be if many request fulfillments are bunched in a tiny interval during which X has not yet paid much, bad clients can cheaply outbid it during this interval.

23. Robustness to Cheating ➲ Also, the theorem assumes that a good client pays at a constant currency rate. This is not true. ● First the payment channel is implemented in TCP which means that the client has to accommodate TCP's slow start before it gets a bigger chunk of bandwidth. ● Second the payments are made using a series of large HTTP POSTs during which there is an inactive period of time which amounts to two RTTs between the Thinner and the client.

24. Robustness to Cheating ➲ The theorem can account for this behavior due to the fact that if a good client has a small fraction of the total bandwidth (causing it to spend a lot of time paying), and if the HTTP POST is big compared to the bandwidth-delay product, then the client's fraction of service is not noticeably affected (because the waiting periods are smaller than the time spent paying at full rate).

25. Robustness to Cheating ➲ So why is the theorem good? We make no assumptions about the attacker's behavior. ● The fact that the theorem depends only on the total bytes sent (in an interval) by other clients. ● Also, the theorem assumes that we are dealing with “smart” attackers, who know exactly when to send more traffic to the auction. (e.g. When a good client's bid is small).

26. Robustness to Cheating ➲ So what does this mean for us? - It means that we have to increase the amount of provisioning we have to do in order to be able to absorb such “smart” behavior. However, the amount which is required is still far less than without the use of Speak- Up.

27. Setup & Implementation ➲ The Thinner is written in C++ as an OKWS (Web server, specialized for building fast and secure Web services) service using the SFS toolkit (a secure, global network file system with completely decentralized control). All of this was run on top of a Linux 2.6 kernel bed.

28. Setup & Implementation ➲ When the server becomes overloaded the Thinner starts issuing requests to the clients using JavaScript ● This causes the client to send two HTTP requests: (1) the actual request to the server, and (2) a 1mb HTTP POST that is dynamically constructed by the browser and holds dummy data (the 1MB limit ensures compatibility with most browsers) ● The second request is the payment channel ● If the client wins the auction, request (2) is terminated and request (1) is given to the server. ● Otherwise (2) completes, thus no service is provided yet and the Thinner continues to issue JavaScript to the browser making it send more POSTs. ● The process continues until the client wins an auction. ● The Thinner correlates the client's payments with its request via an “id” field in both HTTP requests.

29. Setup & Implementation ➲ All of the experiments are run on the Emulab testbed (experimental network environment of clustered PCs). ➲ The tests were run on a 3 Ghz Xeon processor with 2GB of RAM. ➲ The clients used a custom Python Web client to connect to the Thinner using various network topology setups.

30. Setup & Implementation ➲ All of the experiments run for 600 seconds ➲ All the clients are connecting from different hosts in the Emulab environment ➲ Each client’s requests are driven by a Poisson process of rate λ requests/s. ➲ A client never allows more than a configurable number w (the window) of outstanding requests. ➲ This is used to model good (G) vs. bad (B) clients. ● Bad clients send requests faster than good clients, and bad clients send requests concurrently. (λ=40 w=20 for bad vs. λ=2 w=1 for good)

31. Speak-Up in Action ➲ The following figure shows how Speak-Up allocates the server's resources in proportion to its aggregate bandwidth. ➲ There are 50 clients which are connecting to the Thinner over a 100Mbits/s LAN. ➲ Each client has 2 Mbits/s of bandwidth ➲ Also the amount of good clients is changed periodically.

32. Speak-Up in Action ➲ Server allocation when c = 100 requests/s as a function of G/(G+B) where G = good and B = bad clients ➲ Results with using Speak-Up turn out close to the ideal line. ➲ Without Speak-Up, bad clients capture more of the server.

33. Speak-Up in Action ➲ The next figure investigates the different provisioning regimes. ➲ G (good clients) and B (bad clients) are fixed and we measure the server's allocation when its capacity c is than the minimum value of c at which all good clients get serviced.

34. Speak-Up in Action ➲ Server allocation to good and bad clients and the fraction of good requests that are served when Speak- Up is “OFF” or “ON”. ➲ As c increases the number of good requests served also increases with all good requests being served when c=200.

35. Speak-Up in Action ➲ The following figure shows us Speak-Up's performance when good and bad clients share a bottleneck link (ℓ) vs. the bandwidth proportional ideals. ➲ There are 30 clients, each with c = 2 Mbits/s and they are connected through ℓ. ➲ Where the bandwidth of ℓ = 40Mbits/s ➲ Also, there are 10 good and 10 bad clients that connect directly through a LAN. ➲ The server's capacity is c = 50 requests/s

36. Speak-Up in Action ➲ “Bottleneck service” refers to the portion of the server captured by all of the clients behind ℓ. ➲ The left bar which is the actual break down is worse for the good clients than the middle bar which shows the bandwidth-proportional allocation. ➲ This is because the bad clients hog ℓ and crowd out the good clients.

37. Problems ➲ The research seems to focus primarily on Web traffic and its properties (e.g. HTTP) and does not mention if it will be useful for any other situation or protocol. (They do mention the availability of some tools that allow UDP to be protected, but do not go in depth as to whether that is true or not). ➲ The researchers have not done a market survey, thus all their findings are theoretical.

38. Problems ➲ There is no good way to accommodate clientèle (good and bad) coming from the same location. ➲ There is extra hardware (the Thinner) that has to sit in front of any server we want to protect by Speak- Up.

39. Recommendation ➲ Based on the figures shown earlier, we can recommend Speak-Up for use by bigger companies who can afford the extra bandwidth capacity it requires and also, does not have clientèle coming from the same sources. A good example would be Yahoo! or MSN web portals.