On Aug 19, 2014, at 5:32 PM, Yoav Nir <[email protected]> wrote: > > On Aug 18, 2014, at 8:23 PM, Les Leposo <[email protected]> wrote: > >> >> On Aug 18, 2014, at 5:44 PM, Tero Kivinen <[email protected]> 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 >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
