Keith Welter writes: > RFC 4718 section 5.11.8. Collisions with IKE_SA Rekeying says: > The case where CHILD_SAs are being closed is even worse. Our > recommendation is that if a host receives a request to rekey the > IKE_SA when it has CHILD_SAs in "half-closed" state (currently being > closed), it should reply with NO_PROPOSAL_CHOSEN. And if a host > receives a request to close a CHILD_SA after it has started rekeying > the IKE_SA, it should reply with an empty Informational response. > This ensures that at least the other peer will eventually notice that > the CHILD_SA is still in "half-closed" state and will start a new > IKE_SA from scratch. > > Say that host A sends the response with NO_PROPOSAL_CHOSEN and host B > receives it. What should host B do next? Host B was attempting to rekey > the IKE SA and needs to retry that operation. Is it acceptable for host B > to retransmit the CCSA request with the same message ID even though it has > received a response?
If B retransmits the CCSA request with same message ID, then host A will retransmit its NO_PROPOSAL_CHOSEN reply, so there is no point of retransmitting old CCSA request with same message ID. If IKE SA is in half-closed state and B does not know that yet, then it means that A has already sent out delete notification for the IKE SA, and then B sent CCSA before receiving that delete notification, and that was the reason A replied with NO_PROPOSAL_CHOSEN. So B does not really need to do anything, it should receive delete notification very soon. It can install timer (for example 60 seconds or so), and retry the operation after that (or it can wait until the hard lifetime is reached, and delete the old child SA then and then next packet will trigger new child sa creation). If it still fails, it knows there is something wrong with the syncronization of the both ends, and in that case it should delete the IKE SA and start from the scratch. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
