On Aug 18, 2014, at 8:23 PM, Les = Leposo <leposo@gmail.com> = wrote:

On Aug 18, 2014, at 5:44 PM, = Tero Kivinen <kivinen@iki.fi> = 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=92ve implemented. If you=92ve implemented QCD (RFC 6290), then DPD = fails or succeeds immediately as long as you have connectivity, and it = doesn=92t make sense to go directly to a new Initial = exchange.