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

[Les Leposo <[e-mail]>]

On Aug 18, 2014, at 5:44 PM, Tero Kivinen <[e-mail]> wrote:

> 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.
> 

have you overlooked the issue of nat mappings?

ipsec nat keepalives are very useful for keeping nat mappings alive, and in a world full of all sorts of nat devices (some behaving reliably and others not), one would have to use low keepalive interval... like 10-60s.

Now, today's client devices need to be energy efficient - so the device sleeps/hibernates to save battery.
Sleeping past the nat keepalives is bound to happen (either by design or error).
At some point the device will wake from sleep and need to test reachability using dpd.

And in some cases (if the sleep was more than a certain threshold), rather than wait for dpd to failover, the choice is to go for rekey.

For many implementors and admins (and probably the protocol designers), the end primary goal has always been a reliable tunnel that is reliable, but this has come at the expense of battery consumption.

The battery consumption of iphone ike is probably better than other devices, but as a whole the protocol probably needs to emphasise energy efficient implementation/design (while ensuring that parts of the spec that are energy efficient (or performance boosting) are MUST and not SHOULD for servers).


> 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. 
ok, that sounds like a misconfig or bug in the IKE SA rekey.

> 

>> 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]