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

[Les Leposo <[e-mail]>]

On Aug 19, 2014, at 5:32 PM, Yoav Nir <[e-mail]> wrote:

> 
> On Aug 18, 2014, at 8:23 PM, Les Leposo <[e-mail]> wrote:
> 
>> 
>> 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.
> 
> It depends which standards you’ve implemented. If you’ve implemented QCD (RFC 6290), then DPD fails or succeeds immediately as long as you have connectivity,
RFC 6290 is ikev2 2011, Pauls complaint is regarding ikev1/ikev2... not sure. If ikev1, then we're beating a dead horse.
But if ikev2, then my point still stands that the appropriate use of 'MUST'.

> and it doesn’t make sense to go directly to a new Initial exchange. 
> 

What if the IKE SA was nearing expiry, and/or the server initiated a rekey while you were asleep.


> AFAIK racoon doesn’t have that. Maybe it has session tickets, which make the Initial exchange lighter.
> 
> Of course, wiping all state every time you blank the screen is (if true) a very weird implementation choice. 
Do you mean screen lock?


> 
> Yoav
>