On Fri, 18 Feb 2000, Gregory Stark wrote:
: When a client tries to open a TCP connection the server hands him a puzzle
: (via UDP so we do not care if they get it, they'll just have to ask again if
: they don't). The client must solve the puzzle and send it back to the server
: (via UDP so if the client becomes impatient it can send it again). If the
: server receives a correctly completed puzzle, suitably fresh, it reallocates
: the state and completes the TCP connection with the client. The server must
: be able to cheaply discard bogus solutions so we cannot use public key
: cryptography.
:
: Please explain where/why the server must retain state information which
: makes it susceptible to DoS?
Ahh, this is the crux of the problem. Reading the paper more carefully,
the CPP specifies that when a server comes under attack, the following
exchange takes place (Mi=i_th message, t=time, P=puzzle):
Client Server
-----Mi, "Puzzle?"--->
<--"Yes, Puzzle",P,t---
------ solution -----> verify bunch of things
<------ Mi ------>
connection established
Note the the puzzle, P, does not depend on Mi. It only depends on the
time t. Hence the puzzle solution can be verified independent of any
state w.r.t. the requesting IP. They also say in the paper that one
underlying assumption is that an attacker cannot saturate the network
bandwidth, which seem to be a reasonable assumption. (If you take away
soneones bandwidth completely then they win... no amount of cleverness
with CPP or anything else would make a difference.) So the question
simply comes down to "whether the server can farm out puzzles fast
enough", instead of "whether the server can farm out puzzles and maintain
state fast enough"... hmm... seems like it would be an advantage but it is
certainly no longer TCP.
--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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:05:04 PDT