Ending up with two IKE SAs, may not be an issue in terms of functionality, but can be seen as an issue in terms of scalability.
Can we come up with a "standard" way of discarding the extraneous IKE SA, so that both peers will discard the "same" extraneous SA? Any non standard method to discard, may end up in two peers discarding both the SAs. It may also be just plain confusing to the end user, as you mentioned below, in a scenario with two CHILD SAs negotiated from two IKE SAs can continue to rekey forever, and then one peer may use one CHILD SA for its outgoing traffic whereas other peer use the "other" CHILD SA for its outgoing traffic. Again not a functionality issue, but could be seen as an usability issue. thanks, -suresh On Fri, Dec 16, 2011 at 05:55:09AM -0800, Tero Kivinen wrote: > Prashant Batra (prbatra) writes: > > I have a question on possible collision that can occur during initial > > exchange (INIT). > > > > If two peers send INIT_REQ at the same time, > > > > maybe because of some data which matches the traffic_selector on both > > the peers, how a peer should decide whether it has to drop > > > > the request and wait for the response or send the response for this > > request. > > This is not collision, as there is no way to detect this at > IKE_SA_INIT phase. We do not know wheter the identities used are going > to be the same. > > Implementations should simply continue processing both requests and > create two separate IKE SAs. > > > This is similar to collision in case of IKE_REKEY, but I could not find > > any text in RFC 5996 to handle this scenario. > > This is different from IKE_REKEY collision, as here we create two > overlapping IKE (and most likely also Child) SAs. This is completely > valid and allowed by the RFC5996, and there is no need to delete > either one of them. The reason IKE_REKEY etc needs special checks for > the collisions is to ensure that Child SAs are moved to the correct > IKE SA after the rekey, and that the number of IKE SAs would not > multiply after each rekey (i.e. if each IKE SA rekey could potentially > create 2 new IKE SAs, which each of them could again be rekeyed and > potentially create 2 more (in total of 4) IKE SAs etc). > > In the initial connection case there is no possiblity for that as > after the peers do have IKE SAs up they use normal rekey procedure > which does include collision detection, so the worst case scenario is > that those two IKE SAs stay up and both of them will get rekeyed as > normally. > > Note, that INITIAL_CONTACT notification can also make situation > different. In this kind of situation where both ends does simultaneous > connect, both ends are likely to include INITIAL_CONTACT notification > too. > > Now if one of the IKE_AUTH exchanges finishes first, then when the > later exchange will notice that there is old IKE SA between the same > authenticated identities, and will silently remove that older first > IKE SA (and Child SA) and create new second one. This will cause the > first peer to send packets to SAs which have already been deleted, > which will cause the receiving peer to send INVALID_SPI message inside > the surviving 2nd IKE SA, thus deleting the first Child SA. In this > case the first peer will then most likely move its traffic to the > surving 2nd Child SA, and later also delete the IKE SA when it times > out. > > If first peer is sending IKE packets to the IKE SA which have already > been deleted, then second peer will reply with INVALID_IKE_SPI outside > the IKE SAs, and then first peer will delete its IKE SA (after > timeout) and will most likely move to use the surviving IKE SA and > Child SA. > > If the IKE_AUTH exchanges are processed simultaneously then neither > end has IKE SAs between the peers, as both of the IKE SAs are still in > the process of being created. Neither end deleteds IKE SAs, thus this > will cause two IKE SAs to be created (which again is not a problem). > It is important that INITIAL_CONTACT processing do not remove half > created IKE SAs, only fully connected IKE SAs, as otherwise in this > case the both ends would delete the IKE SAs and then the whole process > would start over. > -- > kivi...@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
