On Aug 19, 2014, at 6:11 PM, Yoav Nir <[email protected]> wrote: > > On Aug 19, 2014, at 5:48 PM, Les Leposo <[email protected]> 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 > >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
