Firewall Wizards mailing list archives
Re: client puzzle protocol
From: "Michael B. Rash" <mbr () math umd edu>
Date: Thu, 17 Feb 2000 12:47:42 -0500 (EST)
On Wed, 16 Feb 2000, daN. wrote: : The reason (in most cases) that SYN flooding works is not that it takes up : your entire bandwidth like smurf or something would do. SYN flooding works : because when a machine accepts a SYN packet it has to take CPU time and : memory to setup an internal state of that packet (ie it assigns a chunck of : memory and puts things like RemoteIP/RemotePort/timestamp etc in it...) so : a SYN flood can usually either gobble up all availible memory or all CPU : time long before it eat's up the pipe... Precisely. : I'm assuming (although I haven't : had a chance to read the literature on thier page yet) that when they talk : about using a client puzzlesit works something like this.. : client --SYN---> Server : server --Puzzle/ID--> client : client --Puzzle Result/ID--> Server : <server set's up internal socket state> : the server would build a table of puzzles and ID's when it had free CPU : time, when a client sends a SYN the server would send Puzzle/ID and not : create an internal state for that connection, when it received it's : response form the client it would erase that puzzle/id from it's list and : create a new state... The RSA paper seems not to place any restriction on how many *legitmate* connections that a single client can setup since the overhead in solving the crypto puzzle would limit the number of connections the client can setup anyway. But, as you say above, a normal SYN flood attack works by causing the server to max out its memory through the creation of the packet state tables for each incoming SYN packet. So-- how is the RSA scheme any different? The server still must maintain state for each connection request to know if any subseqent response solved the crypto puzzle correctly... hence we can DoS such a server in exactly the same way as the normal SYN flood; by maxing out this state table. In addition, even if there were a server-side limit on the number of connection requests made by a single client (which RSA does not seem to do) it would be easy to spoof packets from *many* different IP's in the same manner as the DDoS attacks and so this would be useless too. --Michael B. Rash | "...the whole aim of practical politics is | to keep the populace alarmed (and hence http://www.math.umd.edu/~mbr | clamorous to be led to safety) by an | endless series of hobgoblins..." -Mencken
Current thread:
- client puzzle protocol Michael B. Rash (Feb 15)
- Re: client puzzle protocol daN. (Feb 17)
- Re: client puzzle protocol Michael B. Rash (Feb 17)
- Re: client puzzle protocol Paul Cardon (Feb 20)
- Re: client puzzle protocol Michael B. Rash (Feb 19)
- Re: client puzzle protocol Ge' Weijers (Feb 21)
- Re: client puzzle protocol daN. (Feb 24)
- Re: client puzzle protocol Todd Joseph (Feb 20)
- Re: client puzzle protocol daN. (Feb 17)
- Re: client puzzle protocol Shafik Yaghmour (Feb 17)
- <Possible follow-ups>
- Re: client puzzle protocol Antonomasia (Feb 17)
- Re: client puzzle protocol Tommy Ward (Feb 19)
- Re: client puzzle protocol Gregory Stark (Feb 20)
- Re: client puzzle protocol Michael B. Rash (Feb 19)