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: