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
