Valery Smyslov writes: > > 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. So after verifying that cookie is valid, and suitable work is done, server can put the client to associated queue. Each queue could be limited to exactly n clients, for example 100 clients for different queues, i.e. for 6 queues (20-, 19, 18, 17, 16, -15) that would mean 600 entries in queues. If associated queue is full, the request is dropped. After collecting entries to queue for some time (for example 0.5 seconds), the server will sort each queue create one combined queue out from all the queues using suitable algorithms (weighting in the work done by the client, whether that ip-address as tried before or not, whether that ip-address is know, whether that ip-address has been server in last n seconds in such way it didn't result in successfull authentication etc), and truncate that queue to something manageable. I.e. if server thinks he can do about 100 request per second, he might take 100 first from the combined queue, and process them for 0.5 seconds, and then throw rest away. During that 0.5 seconds he will be collecting new queues as before, and after 0.5 seconds he will again take those queues and sort them and create next combined queue. 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. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
