Valery Smyslov <[email protected]> wrote: > Can we make the process more flexible? > For example - the server may indicate two difficulty levels in puzzle > request - the desired one and the acceptable one. > For example, the desired level is 20 bits and the acceptable level is 16 > bits.
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.
If one further creates various queues based upon initiator IP, it seems like
one can rather effectively adjust to situations of attack or not.
One concern: is the gateway, in selecting the complexity of the puzzle giving
out information about it's current state of health? (Do we care?)
> The advantage of such approach is that it makes the whole process
> more adjustable to varying factors, including the wide variety of
> clients and their computational power. The disadvantage is the higher
> server load (it needs to prepare and verify more puzzles) and
> the higher network bandwidth consumption. But unlike the previously
> suggested approaches it doesn't increase the size of a single message,
> that is very good as it decreases the chance for IP fragmentation.
Over time Internet protocols seem to evolve towards the pseudo-technology
of William Gibson's Neuromancer series... which he wrote on a typewriter in
the 1980s :-)
{In this case: bad guys need bigger computers to pull off bigger scams :-)}
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
