On Thu, 11 Apr 2013, Tero Kivinen wrote:
First of all INITIAL_CONTACT is never sent rekeying so that is not a problem. It is only sent when the end does not have any IKE or IPsec SAs with the other end.
But this can happen in various scenarios where your IKE's lifetime passed but not the IPsec SA lifetime. Then you might have one or more IPsec SA' open to the other end but without the corresponding IKE SA you might not realise these SA's are to the same peer.
Note, that it should not be considered a problem to have multiple IKE SAs between two peers. The INITIAL_CONTACT notification is not supposed to be preventing that, it is supposed to clear out old unused IKE SAs the other end might have.
You mean unused IPsec SA's right? Because clearing out old IKE SA's is easy - if the IDs match and you establish the IKE SA, loop through all existing IKE SA's and if the credentials/IDs match (and this is not some group PSK kind of setup) then delete the old IKE SA. Openswan/libreswan never used initial contact to determine that.
INITIAL_CONTACT was much more important in the IKEv1 world where there was no reliable deletes, or other ways of knowing whether the other end was alive or not. In IKEv2 there is less need for it, so leaving it out does not cause that much problems.
I really only see the need for initial contact to interop with Cisco, who can refuse to replace an existing IKE SA without the latest incoming IKE request carrying the INITIAL_CONTACT payload - at least for IKEv1. Paul _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
