> You are describing a situation where the server simply has
> multiple queues, I think. One for 20 bits, and probably one for
> each of 19,18,17,16, and then one for all solutions <16, including
> not supporting puzzles at all.
Yes, but the queues are virtual, the server is still stateless.
The server just takes a desicion on each request based on the
number of zero bits the client was able to get, the amount of time
it took the client, the number of puzzles the client has already
solved and the current server load.
No, server does NOT need to be stateless when it is collecting which
clients to serve. This is already after the checking the cookie, so
client has already proven the point that he is reachable, and is
willing to do work.
We need to be stateless as long as clients do not commit real
resources for the attack. After that it is better to have some limited
state so we can do smart decisions.
I think this is implementation dependant. You may have these
queues and be statefull, or you may store all the needed
information in the cookies and have some kind of distributed
queue. Both approaches are possible, and RFC should not
mandate any of them. But I agree that some guidance
for implementers should be given.
Valery.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
