Subject: [IPsec] Issue (resumption): Resumptions vs. the old IKE_SA

From: <[email-masked]>
Date: Tue, 17 Mar 2009 11:19:26 +0100

<not wearing hats>

In TLS session resumption, resumption basically creates a new TLS
"connection" (using information from local session cache, or ticket in
case of RFC5077), and does *not* really resume the old connection.
The old connection can still exist (and the session resumption
handshake won't cause it to be closed), or it could have been
interrupted earlier, or it could have been cleanly closed earlier.

The current ikev2-resumption draft, on the other hand, seems to assume
a quite different model, where resumption replaces the old connection,
and can be done only if the old connection was interrupted.

This would seem to preclude one case discussed earlier: I close my
laptop (cleanly) at work, commute, and reconnect at home (without
having to do EAP again; e.g. type in one-time password).  Or "switch
off my phone (cleanly), fly to IETF meeting, and switch it back on".

In case of IKEv2, having multiple parallel IKE connections is probably
less common than with TLS (where it's very common), but to me it seems
using the IKE_SESSION_RESUME handshake when the old IKE_SA was cleanly
closed would be quite useful, and should be supported. (And making the
"new connection" completely independent of the old one might simplify
the protocol anyway.)

Best regards,
Pasi