|Main Archive Page > Month Archives > ipsec archives|
Thanks Tero. Some more specifics on my scenario and a couple more questions
are included below.
> Tero Kivinen <firstname.lastname@example.org> wrote on 02/12/2009 05:30:52 AM:
> 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
> > closed), it should reply with NO_PROPOSAL_CHOSEN. And if a host
> > receives a request to close a CHILD_SA after it has started
> > the IKE_SA, it should reply with an empty Informational response.
> > This ensures that at least the other peer will eventually notice
> > 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
> > the IKE SA and needs to retry that operation. Is it acceptable for
> > to retransmit the CCSA request with the same message ID even though it
> > 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.
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.
Should host A do something special when it receives the empty
message? Is there any reason why it shouldn't close it's child SA since it
got a response?
> 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.
> 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.