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). -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
