To clarify: I am NOT suggesting that the responder should generate 8
puzzles (8 cookies). I am suggesting that the initiator should send 8
different solutions to the same puzzle, using something like Tero's
proposal.
It is true that the execution time (a.k.a. client-side cost) will
average out among many clients, so we would be fine WRT DoS protection.
But it is still worthwhile to reduce the variance, in order to have a
more deterministic user experience (for VPN clients) and to avoid
client-side timeouts.
Thanks,
Yaron
On 01/30/2015 02:04 PM, Tero Kivinen wrote:
Valery Smyslov writes:
I also had some concerns on the variance of the times. But then
another thought came to me. Let's look on this issue from the other side.
The responder will use puzzles only when it feels that it is under attack.
It means, that there are a lot of (thouthands, tens of thouthands)
half-open connections. If responder requests that number of puzzles,
then some of them will appear to be easier to solve than the others.
Every initiator is different from another in terms of computing power and
each of them may receive more or less hard puzzle.
It's like an exam - some tasks are more easy to solve, some are harder.
Some clients will be more lucky, some less. That's a lottery.
But all those differences will be averaged for the responder, so why bother?
Yes, it is lottery, as the execution time is randomly distributed over
some max time. I agree that it does not really matter for this case,
as we are protecting server sending the puzzles, and clients do not
have way of knowing which puzzles are hard and which are easy.
Also if client decides it will only try to solve the puzzle for 0.5
seconds and then get new one, that will not help it, as the one he
already has might have been solved by just doing one more try, and the
re is no guarantee that the new one he got is easier.
Also if we require initiator to solve several puzzles, than it will need
to send back all the solutions, that will noticeably increase
IKE message size.
Not that much. The client could find number where:
0x01 + cookie + count1
0x02 + cookie + count2
0x03 + cookie + count3
0x04 + cookie + count4
and send back count cookie + count1-4 or something. The counters
should be smaller than cookie, most likely something that can be
expressed in 32 or 64 bits...
The execution time of the above should be not randomly over the whole
time, but binomial distribution over the time (or something like that,
it is way too long when I have been doing anything like this).
So, while the idea is interesting, I think that the problem it solves
is not important, so why should we bother?
Agree.
But it would be nice, if Yoav (as a person who already has
test bed) could check, that if we solve puzzle for 100
(or better 1000) different cookies, and average the times,
that the results will be less erratic (it would also be great
to measure the deviation of times for each level, not only average).
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
