| Main Archive Page > Month Archives > ipsec archives |
Re: [IPsec] Question on RFC 4718 section 5.11.8. Collisions with IKE_SA Rekeying
From: Keith Welter <welterk_at_nospam>Date: Thu Feb 12 2009 - 15:58:29 GMT
To: ipsec@ietf.org
Thanks Tero. Some more specifics on my scenario and a couple more
questions
are included below.
> Tero Kivinen <kivinen@iki.fi> 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
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.
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
informational
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.
> --
> kivinen@iki.fi
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec