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
