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

[Yoav Nir <[e-mail]>]

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.

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

Yoav