Keith Welter writes: > Actually the IKE SA is open. Host A sent NO_PROPOSAL_CHOSEN because it > received a request to rekey the IKE SA when it had a child SA in > half-closed state. Here is the specific scenario I'm interested in: > 1) Host A initiates rekey of a child SA. > 2) Host B processing of CCSA request triggers rekey of IKE SA due to > local lifesize policy. > 3) Host B sends CCSA response for child SA. > 4) Host B sends CCSA request to rekey IKE SA. > 5) Host A receives CCSA response for child SA. > 6) Host A sends delete for prior child SA. > 7) Host A receives CCSA request to rekey IKE SA but child SA is > half-closed. Host A sends NO_PROPOSAL_CHOSEN in CCSA response. > 8) Host B receives delete for prior child SA. And responds with > empty informational message since it is rekeying the IKE SA. > 9) Host B receives CCSA response with NO_PROPOSAL_CHOSEN. > 10) Host A receives empty informational message.
I think B should send delete for the old child SA immediately when the IKE SA failed, i.e. when A replied with NO_PROPOSAL_CHOSEN, as after that it is no longer rekeying IKE SA. When host A receives that the old child SA has been deleted completely, and after that host B can restart IKE SA rekey. > Should host A do something special when it receives the empty > informational message? Yes, it should mark down it has half-closed child SA, and if the situation is not fixed in next few minutes, then it should delete whole IKE SA and start over. > Is there any reason why it shouldn't close it's child SA since it > got a response? It got response, but other end didn't close his end of the child SA. It should wait for the other end to close down the child SA. If the other end closes it, then it will return back to normal. If other end does not close it in few minutes (say 5 minutes), then it should delete IKE SA and start over. See section 1.4 of RFC4306: A node SHOULD regard half-closed connections as anomalous and audit their existence should they persist. Note that this specification nowhere specifies time periods, so it is up to individual endpoints to decide how long to wait. A node MAY refuse to accept incoming data on half-closed connections but MUST NOT unilaterally close them and reuse the SPIs. If connection state becomes sufficiently messed up, a node MAY close the IKE_SA; doing so will implicitly close all SAs negotiated under it. It can then rebuild the SAs it needs on a clean base under a new IKE_SA. I.e. MUST NOT unilaterally close, and if state beecomse sufficiently messed up, MAY close IKE SA. > > 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). > > Since this sort of retry isn't a retransmit I suppose an exponential > back-off of any subsequent retries isn't required but might be nice. I do not think there will be that many retries. If the second try fails again, it usually means there is something messed up, so it might be better to delete old IKE SA and start over as I said here: > > 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
