Paul Wouters writes: > 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.
Not with IKEv2. If the IKE SA lifetime is gone, then you REKEY the IKE SA. This cannot cause INITIAL_CONTACT notifications. Also when IKE SA is expired, or deleted all the IPsec SAs are also deleted automatically, so there is also no problem for INITIAL_CONTACT. > > 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? Both IKE and IPsec SAs. > 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. There is nothing in the RFC5996 that says you should do or need to do that. Nothing there prevents peer to create multiple IKE SAs with same ID payloads with the peer. In some cases it is even needed. For example in some high availibitity environments the peer is using same ID payload, but different IP addresses, and each node in cluster might create separate IKE SA to the other peer and all of them have identical ID. You implementation will prevent that from working. > > 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. We are not talking IKEv1 here. IKEv1 has lots of problems with reliability and state syncronization, so the issues with it are completely different. The subject was about INITIAL_CONTACT in IKEv2. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
