563.3.3 DoS Defense by Proof

1. 563.3.3 DoS Defense by Proof Computer Security II CS463/ECE424 University of Illinois

2. Proof Concept • Require some proof that service for a client is desired or some evidence that would make it easier to eliminated unwanted requests. • Authentication is the most obvious type of proof, but it has its limitations. • A variety of practical alternatives and extensions have been proposed.

3. Proof Strategies Cookies verify that a request from a client comes from a given address and delay the creation of state on the server until there is a level of commitment from the client. Capabilities provide a potentially practical way to let servers inform the network that traffic is wanted without a global authentication system. Proof-of-work based on puzzles or bandwidth cause clients to prove they are willing to work to obtain service.

4. Cookies

5. Idea of a DoS Defense Cookie • Assure, to a reasonable degree of certainty, that a client can receive a packet at its claimed source address • This is done by sending a hard-to-guess value, the cookie, to the client in response to its initial request. • This makes spoofing of source addresses difficult. • The idea is used in many contexts: TCP, IKEv2.

6. SYN Cookies Usual 3-way handshake Handshake with cookie SYN SYN Calculate and Issue Cookie SYN+ACK SYN+ACK Include Cookie in ACK ACK ACK Verify Cookie and Allocate Server State <Data Flow> <Data Flow> Server Server Client Client Time Counter MSS md5(caddr, cport, saddr, sport, time counter) 5 bits 24 bits 3 bits [BernsteinS96]

7. SYN Cookies are Easy to Deploy • Backwards compatible • Transparent to clients • Conform to RFC requirements for TCP • No performance impact until SYNs become a problem • Good performance under attack • Limited drawbacks: hangs if ACK is lost, cannot use large window sizes

8. IKE DoS Vulnerability • Basic premise: calculating a Diffie-Hellman (DH) shared secret is computationally expensive • Attacker initiates a large number of IPSec connections and passes garbage as the DH Public Key • Same situation as a SYN flood, except the attacker is exhausting CPU cycles rather • IKEv2 RFC adds optional initial cookie exchange to its base protocol.

9. Limits of Cookies • Exhaustion: TCP SYN Cookies offer 24 bits of protection, Photuris Cookies offer 128 bits • Stale cookies: Once issued, a cookie is valid for some period of time (each 64s a new one under Linux) • Eves dropping: Cookies rely on the unsecured confidentiality of the Internet path between client and server.

10. Capabilities

11. Basic Idea of Capabilities • Openness of Internet: any node / app can send anything to another point in the network. • New Internet apps can be introduced without changing the routing • Lower cost • Capability: tokens, representing one-time temporary leases or capabilities to send • Authenticates that the packet is desired by the destination.

12. TVA Alice PreCapability (Pi)= hash(srcIP, destIP, time, secret) RTS Pre1 • RTS rate limited • 1-5% of bandwidth • Pi Queue at Router • Fair queued on Pi Pre1, Pre2 CNN [YangWA05]

13. TVA Alice Capability1 = timestamp || Hash (N, T, PreCap1) Capability2 = timestamp || Hash (N, T, PreCap2) CAP Cap1, Cap2 • Server offers: N bytes, T seconds • Stateless server • Does not store N, T • Router state • (Per destination Q) • Input link C, minimum sending rate N/T • C/(N/T) records CAP Cap1, Cap2 CAP Cap1, Cap2 CNN

14. Limits of TVA • Legacy traffic suffers highly • Requires updating edge routers (pre-caps, capability, per flow queuing) • Changed network stack with capability packets • Assumes a certain knowledge of path capacities on server side to assign capabilities to flows

15. Proof of Computing Power

16. Basic Idea of Client Puzzles Pricing: attach a small cost to protocol initiation (processor time, memory, …) The cost is much higher for attackers than for a legitimate client Attacks are rate limited by puzzle cost Resource request Puzzle parameters Server Client Puzzle solution Resource

17. Hashcash Puzzles g, h: non-invertible hash functions. The server chooses a number x = g (secret, time, …), its hash y=h(x) and a level of difficulty k. It sends bits x[k+1,l] and y – asks the client to find bits x[1,k] by brute force. x[1,k] x[k+1,l] x y= h(x) y y

18. Proof of Bandwidth

19. Bandwidth as a Resource • Valid clients have more bandwidth available to them than attackers; attackers are “maxed out” on bandwidth during attack but valid clients have reserves. • If valid clients increase their communications with a server they will tend to overwhelm attackers. • Realizations of this strategy: Selective Verification and Bandwidth Auctions

20. Attack Profile A R A loads this channel with bad packets S requires low b/w channel with high processing cost at R S

21. Selective Verification A R S [GunterKTV04]

22. S adds redundancy Selective Verification A gets reduced channel R makes channels lossy A R Tradeoff: bandwidth vs. processing S

23. Bandwidth Auctions • Server keeps a record of bytes sent by potential clients • Service is provided to clients who have sent the most bytes • Feedback mechanism can be implemented by using HTTP posts with an indication of how many bytes might be required to get service [WalfishVBKS06]

24. Adaptive Selective Verification • Client starts with sending a REQ • Doubles REQ rates after not getting service (i.e. ACK) in a round (T seconds) for up to J rounds • Server performs probabilistic random sampling of requests • Theoretically and experimentally shown to be efficient in terms of bandwidth consumption • Requires limited state on the server KhannaVFKG08]

25. Proof of Humanity Reverse Turing Tests (RTTs)

26. Challenges with Proof of Computation and Bandwidth • Limited deployment of protocols • Intrinsic differences between the capabilities of hosts • High availability of computational resources on a botnet • Diversified origins in botnet allows bots to look normal • Strategy: prove a human is responsible for each request

27. RTTs and CAPTCHAs • Turing Test: interview a principal and decide if the principal is a computer • Reverse Turing Test (RTT): find out if they are a human • Naor proposed RTTs as a defense against DoS • Idea used for Alta Vista in 1997 • Gained recent popularity through use by Yahoo! Under the rubric of Completely Automated Public Turing test to tell Computers and Humans Apart (CAPTCHA) [Naor96] [AhnBL04]

28. Types of CAPTCHAs • Text based • Gimpy, ez-gimpy • Gimpy-r, Google CAPTCHA • Simard’s HIP (MSN) • Graphic based • Bongo • Pix • Audio based

29. Text Based CAPTCHAs • Gimpy, ez-gimpy • Pick a word or words from a small dictionary • Distort them and add noise and background • Gimpy-r, Google’s CAPTCHA • Pick random letters • Distort them, add noise and background • Simard’s HIP • Pick random letters and numbers • Distort them and add arcs

30. Text Based CAPTCHAs

31. Graphic Based CAPTCHAs • Bongo • Display two series of blocks • User must find the characteristic that sets the two series apart • User is asked to determine which series each of four single blocks belongs to Difference? thick vs. thin lines

32. Graphic Based CAPTCHAs • PIX • Create a large database of labeled images • Pick a concrete object • Pick four images of the object from the images database • Distort the images • Ask the user to pick the object for a list of words

33. Graphic Based CAPTCHAs Pool Dog

34. Audio Based CAPTCHAs • Pick a word or a sequence of numbers at random • Render them into an audio clip using a TTS software • Distort the audio clip • Ask the user to identify and type the word or numbers

35. Breaking CAPTCHAs • Most text based CAPTCHAs have been broken by software • OCR • Segmentation • Other CAPTCHAs were broken by streaming the tests for unsuspecting users to solve.

36. Killbot • Requires the client to solve a graphical puzzle (CAPTCHA) to access the service. • The server keeps track of successful and failed authentication attempts and allows access using that information. • When the server is at capacity, it drops new authentication requests. [KandulaKJB05]

37. Reading • [BernsteinS96] SYN Cookies, D. J. Bernstein and Eric Schenk. http://cr.yp.to/syncookies.html, 1996. • [YangWA05] A DoS-Limiting Network Architecture, Xiaowei Yang, David Wetherall, and Thomas Anderson, SIGCOMM 2005. • [JuelsB99] Client puzzles: a cryptographic countermeasure against connection depletion attacks, Ari Juels and John Brainard. ISOC NDSS 1999. • [GunterKTV04] DoS Protection for Reliably Authenticated Broadcast, Carl A. Gunter, SanjeevKhanna, Kaijun Tan, and SantoshVenkatesh. NDSS 2004. • [WalfishVBKS06] DDoS Defense by Offense, Michael Walfish, MythiliVutukuru, HariBalakrishnan, David Karger, and Scott Shenker. SIGCOMM 2006. • [KhannaVFKG08] Adaptive Selective Verification, SanjeevKhanna, Santosh S. Venkatesh, OmidFatemieh, Fariba Khan, and Carl A. Gunter. IEEE INFOCOM 2008 . • [KandulaKJB] Botz-4-Sale: Surviving Organized DDoS Attacks That Mimic Flash Crowds, SrikanthKandula, Dina Katabi, Matthias Jacob, Arthur W. Berger. NSDI 2005

38. Discussion • Could the Internet be designed differently to thwart DoS? • Which resource is best for an adversary to prove: valid address,  computational power, bandwidth access, humanity, or something else? • Does the end-to-end argument apply to DDoS defense?