Graham Bartlett (grbartle) <grbar...@cisco.com> wrote:
> Now the only issue I can see is alluded to in the draft, where a VPN
> headend is serving clients with varying resource. So say a botnet
> attacks this headend and the puzzle is enabled, you have some clients
> with a lot of resource (that require a hard puzzle) and some mobile
> devices with minimal (that require an easier puzzle). How do you
> identify each? The only way I can think is you must do this once the
> device has authenticated itself - else how do you know who they are?I have two observations here. The first is that while the botnet can pull in potentially hundreds of teraflops of computation in order to solve a harder puzzle, it has communication overhead in order to do that; The second observation is that the puzzle has to be trivially parallelizable in order for the botnet (or even the multi-core mobile phone!) to do better than a single CPU. The question is: can we design puzzles and the puzzle parameters such that multiple threads of execution do not benefit a single client system? The second part is, can we design the time limit to solve the puzzle such that there becomes very little budget for multi-processor botnet communication. I suspect that this second part is impossible and/or easily spoofed, as we don't know the actual RTT between client and gateway. (Or rather, any RTT estimation could be spoofed by a botnet to give itself more time) -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
pgp4KWbFWEy_5.pgp
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
