Subject: [IPsec] Question on RFC 4718 section 5.11.8. Collisions with IKE_SA Rekeying

From: Keith Welter <[email-masked]>
Date: Wed, 11 Feb 2009 14:56:23 -0800

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? 

Keith Welter
IBM Enterprise Networking Solutions
1-415-545-2694 (T/L: 473-2694)

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 12 Feb 2009 15:30:52 +0200

> to retransmit the CCSA request with the same message ID even though it has 

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.
-- 
[email-masked]

---

From: Keith Welter <[email-masked]>
Date: Thu, 12 Feb 2009 07:58:29 -0800

Thanks Tero.  Some more specifics on my scenario and a couple more 
questions
are included below.

> Tero Kivinen <[email-masked]> wrote on 02/12/2009 05:30:52 AM:
>
> 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.

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?

> 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.

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 13 Feb 2009 15:37:19 +0200

> 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. 

> 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.

> 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

-- 
[email-masked]