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

[Les Leposo <[e-mail]>]

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

> 
> On Aug 19, 2014, at 5:48 PM, Les Leposo <[e-mail]> wrote:
> 
>>>> 
>>>> 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’.
> 
> I think that a remote access gateway that services battery-sensitive devices should allow a lot of time before initiating its own DPD. Unfortunately, there is no way for a gateway to communicate to the client “if you’ve been silent for X seconds, you can assume that I’ve started a DPD and probably killed your IKE SA”.
> 
>>> 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.
> 
> Under IKEv2 rules, the rekey failed and the old IKE SA is gone. It’s OK that it happened, It’s only a matter of detecting this efficiently.

yup

> 
>>> 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?
> 
> If that’s what it is called on an iPhone (I don’t have one). I mean whatever makes the screen go blank so that you need to press a button and swipe the screen in some direction, optionally including a code. 
> 
Not the official term. It is a screen lock because  the user was logged out and you would have to log back in.

I haven't used ios vpn in almost 2 years.
I believe that can be tweaked either by a setting on the Gateway policies or on ios provisioning profile.
But it sounds like a system level security policy/decision. Not necessarily directly related to the ike daemon (perhaps another part of the system).
I hate to keep theorising on Paul's issue, but it might be that the Screen lock/unlock is indirectly triggering a signal/crash on the ike daemon.

> Yoav
> 
>