Subject: [Ipsec] IKEv2 CHILD_SA handling after rekeying IKE_SA

From: Fukumoto Atsushi <[email-masked]>
Date: Tue, 15 Nov 2005 18:11:28 +0900

I want a confirmation or clarification about CHILD SA handling after
rekeying the parent IKE SA.

IKEv2 draft-17 section 1.4 states:
   Control messages that pertain to an IKE_SA MUST be sent under that
   IKE_SA. Control messages that pertain to CHILD_SAs MUST be sent under
   the protection of the IKE_SA which generated them (or its successor
   if the IKE_SA was replaced for the purpose of rekeying).

After rekeying IKE SA, there may be redundant IKE SAs, according to
section 2.8.  Thus, I suppose, an implementation MUST be able to
accept any one of successors of IKE_SA to be used to control CHILD_SA.

Deleting IKE_SA implicitly closes all associated CHILD_SAs (draft
section 2.4).  I suppose it must be only if the children are not
shared with other IKE_SAs.

Am I right with this interpretation?

					FUKUMOTO Atsushi
					[email-masked]

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Tue, 15 Nov 2005 10:28:01 +0100

> accept any one of successors of IKE_SA to be used to control CHILD_SA.

Section 2.8 says:
        << To rekey an IKE_SA, establish a new equivalent IKE_SA (see
        section 2.18 below) with the peer to whom the old IKE_SA is
        shared using a CREATE_CHILD_SA within the existing IKE_SA. An
        IKE_SA so created inherits all of the original IKE_SA's
        CHILD_SAs.  Use the new IKE_SA for all control messages needed
        to maintain the CHILD_SAs created by the old IKE_SA, and delete
        the old IKE_SA. The Delete payload to delete itself MUST be the
        last request sent over an IKE_SA. >>

My interpretation is: After rekeying an IKE_SA, the new one is the only
one that controls the CHILD_SAs created by the old IKE_SA. The is no
CHILD_SA sharing, because they are "transferred" from old to new IKE_SA.

> shared with other IKE_SAs.

Hence, when the old IKE_SA is deleted, it hasn't any associated
CHILD_SA.

Alejandro Perez Mendez
Pedro J. Fernandez Ruiz

---

From: Fukumoto Atsushi <[email-masked]>
Date: Tue, 15 Nov 2005 18:56:22 +0900

> CHILD_SA sharing, because they are "transferred" from old to new IKE_SA.

Let me clarify my point: you are correct if rekeying does not collide,
but draft-17 section 2.8 states:

   If the two ends have the same lifetime policies, it is possible
   that both will initiate a rekeying at the same time (which will
   result in redundant SAs)."

and,

   This form of rekeying may temporarily result in multiple similar SAs
   between the same pairs of nodes. When there are two SAs eligible to
   receive packets, a node MUST accept incoming packets through either
   SA. If redundant SAs are created though such a collision, the SA
   created with the lowest of the four nonces used in the two exchanges
   SHOULD be closed by the endpoint that created it.

Thus, redundant IKE_SAs are created, and the implementation MUST be
able to accept this, if rekeying IKE_SA is supported, if I understand
correctly.

					FUKUMOTO Atsushi

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 15 Nov 2005 13:17:50 +0200

> able to accept this, if rekeying IKE_SA is supported, if I understand

That does not say anything about where the child SAs are moved. My
interpretation has been that child SAs are always moved to the winning
IKE SA, and the loosing IKE SA is closed after small timeout. Also the
old IKE SA is closed, so after short time there will be only one IKE
SA that has all child SAs.

The text do say that "temporarily" so it is not supposed to be
situation lasting longer.

I would also consider that the loosing IKE SA is not supposed to be
used for the traffic, although there are cases where this cannot be
avoided. In the end all child SAs should still end up only in the
winning IKE SA, thus they are always only part of one IKE SA (no
sharing of child SAs between multiple IKE SAs).
-- 
[email-masked]

---

From: Fukumoto Atsushi <[email-masked]>
Date: Wed, 16 Nov 2005 14:03:00 +0900

> SA that has all child SAs.

I'll be happy to implement along that way, but I think it is hard to
deduce that interpretation from the spec, in fact I think it doesn't
conform to specification, since it states quite explicitly that "a
node MUST accept incoming packets through either SA.".  Spec needs
amendment for that.

					FUKUMOTO Atsushi

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 16 Nov 2005 16:26:20 +0200

> node MUST accept incoming packets through either SA.".  Spec needs

All of the IPsec SA moved are still accepting incoming packets. The
old IKE SA is still accepting incoming packets, but specs say that
only packet coming to that is delete payload.

The new winning IKE SA is of course accepting incoming packets and
continues processing them. The only question is what happens to the
loosing IKE SA.

If the initator detects before the loosing IKE SA is finished that
there is simultaneous IKE rekey he will delete the loosing IKE SA and
not use it at all, so there is no problem. The responder will of
course accept packets for the loosing IKE SA, but assumes it will be
deleted and it can fail all child SA negotiations on the SA.

If the initiator gets the IKE SA finished and starts child SA
negotiation on that IKE SA and only after that notices that there was
actually simulatenous rekey (this can and will happen) it should not
be suprised if the create child SA was failed by the responder
(responder will know when that child SA creation was starting that
there was simultaneous rekey, but it might not yet know which IKE SA
is going to be winning one).

On the other hand after the child SA is created he is supposed to
delete the IKE SA, and my interpretation is that the created child SA
is also deleted along the IKE SA, as it was created after rekey took
place.

So all SAs will still accept incoming packets as long as they are
there, but each end can at will anyways delete any SAs, and they are
assumed to be deleting the loosing SAs, and after that there is only
one SA getting incoming packets.

I agree that the document does not explain all possible combinations
of what can happen during the simulatenous IKE SA rekey, but the basic
rule (i.e. the one IKE SA is the winning and other loosing, and the
initiator of the loosing IKE SA will delete the loosing IKE SA, and
either end can delete the old IKE SA).
-- 
[email-masked]