Re: client puzzle protocol

["daN." <dan () nesmail com>]

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...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 problem with this is that it will not happen overnite...it would
require a new TCP/IP stack...
This is somewhat along the lines of what someone was talking about on the
list earlier where server sends back SYN-ID only it adds another layer of
work, so not only does the from IP have to be legit, it also has to do some
work...

At 11:36 PM 2/14/00 -0500, Michael B. Rash wrote:
> http://www.rsasecurity.com/rsalabs/staff/ajuels/papers/clientpuzzles.pdf 
>
> So basically RSA seems to think that this technology could be used to help
> stop the recent DoS attacks that gained so much media attention, but
> either I am not understanding something, or they have made a mistake in
> their architecture.
>
> The technology can be summarized by the following excerpt from the
> paper's abstract: 
>
> "...TCP SYN flooding is an example of a connection depletion attack in
> which an attacker... <snip>.  We introduce a countermeasure
> that we refer to as a client puzzle protocol.  When a server comes under
> attack, it distributes small cryptographic puzzles to clients making
> service requests.  To complete its request, a client must solve its puzzle
> correctly..."
>
> OK.  First of all, "distributes puzzles" implies that the attacking
> machine is listening for them in the first place, which most likely it 
> will not be (the TCP SYN packets would most likely be spoofed 
> anyway... where do they think they are going to "send the puzzle"?).  An
> attacking machine simply needs to create a bunch of SYN packets and get
> them to the target, who will then begin generating the corresponding
> SYN-ACK packets thereby overflowing its connection buffers.  That's
> it... that is the whole attack.  The only advantage in doing something
> like the client puzzle protocol would be to limit the number of
> *legitimate* connections that a machine could make since the 
> computationally expensive cryptographic puzzles would start eating lots of
> compute cycles if it tried to initiate 10,000 connections.  If I'm an
> attacker I don't care about legitimate connections... I don't even care if
> I see *any* packet return from the target.
>
> What am I missing?  How would the CPP help to prevent DoS attacks?
>
> (Note of course that we are talking about both a client and server side 
> modification to make all of this possible in the first place... sounds
> like an upcoming product from RSA).
>
>
> --Mike                        | "...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
mutated / aka daN.
ph33r my l@me newBi3 sKillz