On Wed, 30 Jul 2014, Yoav Nir wrote:
Suppose our half-open SA table can hold 100,000 entries and we clear them out
after 10 seconds. That allows 10,000 entries per
second. More realistic number are 18 bits for the iPhone and 20 bits for the
attacker, so to block out those iPhones, the attacker
would have to perform 10,000 * 2^20 SHA-256 hashes per second, or about 10
billion hashes. That’s about 400 server-class hardware
working full-time, or a 10,000-way botnet. The draft is all about increasing
the work for the attacker, and I believe this is doing
it well. The baseline is sending 20,000 packets per second while only copying
the cookie (no PK or hash operations at all).
It is possible to do as in the current draft, and set a single difficulty level
(say, 18 bits). This allows the attacker a nice and
deterministic way to keep the half-open SA table full, which blocks out all
clients, not just the iPhones.
The iphone (which is only rumored to do IKEv2 with iOS8 likely to be
released in September this year) currently has a
terrible record of continuously re-establishing connections. Like
whenever the screen saver hits it will tear down the tunnel. With
an always-on profile, that means if I unblanc the screen, it will
start a new IKE session.
A scheme like this would drain the battery on top of the current
re-establishing draining, that already prevents me from using an
always-on profile - my iphone won't last for 4 hours.
Perhaps we should look at other types of puzzles that do not depend on
raw CPU power?
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
