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