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. >> 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
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
