> I think this data proves the idea that the difference between
> computation power of different clients is significant and
> no single puzzle difficulty level would be reasonable for all.
> I think we should proceed with the proposal that
> client is allowed to return less zero bits than requested.
It’s simpler and safer code to get a request from the initiator, mark it
as solved/not-solved,
and process if solved or discard if not. Then you don’t have to do any
queueing beyond
what the UDP stack is doing anyway.
The real queueing is not necessary. You may act exactly the same way,
as you described - get a request, analyze it and either process,
or issue a new request, or discard. The only difference is what
does the word "analyze" mean. In suggested approach it means:
- Check whether puzzle was ever tried to be solved.
If not - mark the request with the lowest priority.
- Check how many zero bits are returned, how much time
did it take the client (the latter can be learned if
the cookie was timestamped) and how many puzzles
it has already been asked (also can be encoded in cookie).
Mark the request with the priority, that is calculated as
(zero bits) * (spent time) * (number of solved puzzles)
- Take a decision whether to process request or not.
The decision should take into account the server's load and
the priority of the request, and it should be probabilistic,
so that even low-priority requests have a chance to be served.
- If low-priority request is not served than give new puzzle
for that client. The more puzzles client solve the higher
would be its request priority.
> And in this case we may go further.
> The server may even not indicate to the client
> how many zero bits it wants to get. The server
> could just give the puzzle to the client and
> the client would return the best solution that it can
> get for a reasonable (from client's point of view) time.
> Some clients would be able to get more zero bits, some less.
> Then the server would sort all the requests, as described
> in Tero's e-mail and serve them accordingly.
This would allow a sufficiently powerful botnet to flood the queues and
deny service to phones.
It is always possible. If you require all the clients to solve puzzle with
a single difficulty, then sufficiently powerful botnet would quickly
rase the bar so high, that phone's just won't be able to solve the puzzle
for reasonable time (and reasonable battery consumption).
And the proposed solution tries to avoid this, giving them a chance.
Suppose it turns out that phones like to work for 0.5 seconds and usually
come up with
15-, 16-, or 17- bit solutions, it should be easy for a botnet to work far
less time on each
puzzle and solve hundreds of puzzles at these bit lengths. That would
effectively block the phones
that take a whole half second to calculate just one such solution.
Not really. As the decision on whether to serve request
should be probabilistic, than any such request (including phone's)
should have a chance to be processed.
BTW - the formula for priority includes spent time,
so if you get only 16 bits, but spent 0.5 secs for this,
then you will get better chances than somebody,
who solved these 16 bits for 5 ms.
Valery.
Yoav
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
