Re: [IPsec] IPsec Digest, Vol 123, Issue 21

[Tero Kivinen <[e-mail]>]

Les Leposo writes:
> > 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.
> > 
> ikev2 "session resumption" promised some improvements over ikev1 -
> frankly that is part of the spec that needs to be 'MUST' and not
> 'SHOULD', for all servers.

You do not need session resumption for that. You just need properly
done implementation. Unfortunately lots of IKEv2 implementations use
dead peer detection as periodic keepalive messages, instead of just
using it to verify whether the other end is alive or not.

If dead peer detection is implemented properly, as is described in the
rfc5996, the device can safely go to sleep if there is no traffic
going between the client and server, and when it wakes up from the
sleep the IKEv2 connection will still be there, and the other end has
not teared down the IKE SA (provided there was nothing that would have
caused it to try to send traffic to the sleeping node).

Unfortunately lots of devices send dead peer messages all the time
every n seconds, and if device is sleeping during that time, they will
tear down the IKE SA. This is broken implementation, not problem in
the protocol.

Yes, session resumption is even better, as it will allow telling the
other end, that don't even bother trying to send to me anything, I am
sleeping, but quite a lot can also be done if the implementations are
done properly.

If course if the device is not really sleeping, i.e. you just blank
the screen, and are still able to receive and send packets, then there
is no point of tearing down the IKE SA. 

> imho, if the hash calculations (and ike) are a big enough culprits,
> then perhaps the mobile SoC folks should consider bringing onboard
> IP that accelerates/offloads the hash calculations (and other
> aspects of ike) to more energy efficient component/sub-system?
> 
> Or, a crazier idea... find ways to permit/standardise some types of
> cheating at the peers. 
> e.g. By allow "scripted/seeded" connections to be established and
> policed. i.e. peers are negotiating using a "scripted" sequence of
> nonces, hashes, e.t.c, 
> As follows:
> - The client 1st connects to a trusted entity, gets the
> "script/seeds", which is also (concurrently) pushed down to the
> ikev2 server (may be the same machine).  
> 	- The peers need to store these "scripts/seeds" securely (i.e.
> sandboxing is a must). 
> 	- The trusted entity needs to be very fast (probably with
> hardware acceleration) at generating these "scripts/seeds". Perhaps
> a new product category for servers. 
> - Then the client and server do the scripted dance all day - which
> is more energy efficient but results in a tunnel should be policed
> (as less secure than "unscripted" connections). 

And of course you log in to the trusted entity using IPsec :-)

I mean if you are going to add very fast trusted entity providing the
scripts/seeds to devices, it is much better to just add more hardware
to your SGW device, so it can process 10,000 requests per second
instead of 100.

Also add some extra memory, so you can use it store hash table of
recent connections. I.e. when connection comes in you check whether it
is in on the recent connections table. If so you drop connection,
otherwise you send cookie/puzzle. When it comes back with proper
cookie/puzzle, you put it on the recent connections hash table and
continue IKEv2. When the IKEv2 connection finishes with
authentication, you remove the entry from the recent connections
table. If the authentication fails with IKEv2 authentication failure,
you slow down the response for the next time for 1 seconds, for the
second time 2 seconds, and so on.

I.e. the recent connections table has list of IP-address who have
tried to connect to you, but have not yet authenticated, i.e. either
real devices in the middle of authentication, or attackers. The real
devices in the middle of authentication will not try to reconnect, as
they are still continuing the process.

This means attacker needs one new routable IP-address for each attack.
So to send 100 new IKEv2 connection attacks to the SGW for an hour,
the attacker needs 30,000 botnet machines. To keep the same attack up
for 24 hours, it needs 720,000 machines etc. To keep it up for week
they need 5 million botnet machines. At that point the server need few
tens of megabytes of memory to keep the list of blacklisted
IP-addresses.

On the other hand 100 connections seconds should not yet cause DoS on
the SGW (that would be normal monday morning problem rate, and server
should be able to cope with that without dropping connections), so for
attacker to be able to block real users out, would most like 100 times
more connections per second. I.e. to block server for hour, they would
need 10,000 connections per second, and 3 million separate botnet
machines. 

Of course with IPv6 you most likely want to keep the /64 prefix in the
hash table, not for the whole IP-address, and for the IPv4 you can
mask out the lower 4 bits or something.

And of course you most likely you can also keep whitelist of known
IP-addresses which have done successfull authentication against the
SGW in last week or so, and those would always be allowed to be
processed first. This way even with those kind of DoS attacks, the
employees home machine, which have stable IP-address would still be
able to connect.
-- 
[e-mail]