Subject: [Ipsec] Deleting IKE_SA and CHILD_SA

From: Kimihiro OHKI <[email-masked]>
Date: Wed, 27 Sep 2006 17:16:30 +0900

Hi All,

Could you tell me the correct interpretation of IKEv2 specification
regarding following my basic question?

Precondition: There is a set of an IKE_SA and the corresponding
CHILD_SA pair between a node A and a node B.

Question: If the node A wants to normally delete the set of
connections (both the IKE_SA and CHILD_SA pair), is it enough for the
node A to send an INFORMATIONAL request which contains a DELETE
payload for the IKE_SA only (and then the node B responds via an empty
INFORMATIONAL response and both nodes implicitly and immediately close
the corresponding CHILD_SA pair), or does the node A need to send an
INFORMATIONAL request which contains 2 DELETE payloads (one for
IKE_SA, the other for CHILD_SA)?

Although I recognize Sec2.4 of rfc4306 says "Closing the IKE_SA
implicitly closes all associated CHILD_SAs.", it seems for me this
section does not mention normal termination case (active deletion) but
does just some cases such as timeout.

It seems sending DELETE payloads for both IKE_SA and CHILD_SA itself
does not violate the rfc, but I'd like to know whether it is:
(a) required or mandated behavior,
(b) recommended behavior, or
(c) some verbose behavior (not recommended),
and the rationale for the interpretation.

Another related consideration is, if the node B receive a DELETE
payload for the IKE_SA only, is the node B required whether:
(d) to close the corresponding CHILD_SA immediately (so the above (c)
is correct), or
(e) to wait some internal trigger to close the corresponding CHILD_SA
(so the above (c) causes unnecessary remained resources and (a) or (b)
is correct)?

Best Regards,
Kimihiro Ohki

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

---

From: Yoav Nir <[email-masked]>
Date: Wed, 27 Sep 2006 11:46:38 +0300

My comments inline

> CHILD_SA pair between a node A and a node B.

This is a special case.  There could be many child SA pairs.

> IKE_SA, the other for CHILD_SA)?

You can send more than 1 DELETE payloads, but since sending the IKE  
SA delete alone accomplishes the same goal, the others are redundant.

> does just some cases such as timeout.

It mentions timeouts because its focus is on site2site connections  
where it is not "normal" to terminate tunnels.  A "disconnect" event  
is normal for remote access, but deleting the IKE SA accomplishes the  
same thing.

> and the rationale for the interpretation.

I'd go with (c).  An RFC-compliant implementation should still work  
if you send multiple DELETE payloads, but it's just not needed.   
Sending one DELETE payload sends the message that you don't want to  
talk to the peer any more on any of the established SAs.  Note that  
what you're suggesting is sending a DELETE for all ESP and AH SAs  
that you have.  Seems wasteful.

> (so the above (c) causes unnecessary remained resources and (a) or (b)

Like it says in section 2.4: "Closing the IKE_SA implicitly closes  
all associated CHILD_SAs."  So (d) is correct.  This really is the  
cleanest way to "disconnect"

Besides, deleting the IKE SA is equivalent to revoking the  
authorization, so you shouldn't accept or send traffic without  
authorization.

---

From: Kimihiro OHKI <[email-masked]>
Date: Wed, 27 Sep 2006 18:28:44 +0900

Thank you for your quick reply and detailed comment.
As you may know, 3GPP and 3GPP2 are making standards for remote VPN 
access which refer this rfc. So IKE_SA creating only one CHILD_SA pair 
and the "disconnect" event are not special in such environment.
Anyway, it becomes clear for me.

Best Regards,
Kimihiro Ohki

> You can send more than 1 DELETE payloads, but since sending the IKE SA 
> delete alone accomplishes the same goal, the others are redundant.
> 
>>
> It mentions timeouts because its focus is on site2site connections where 
> it is not "normal" to terminate tunnels.  A "disconnect" event is normal 
> for remote access, but deleting the IKE SA accomplishes the same thing.
> 
> I'd go with (c).  An RFC-compliant implementation should still work if 
> you send multiple DELETE payloads, but it's just not needed.  Sending 
> one DELETE payload sends the message that you don't want to talk to the 
> peer any more on any of the established SAs.  Note that what you're 
> suggesting is sending a DELETE for all ESP and AH SAs that you have.  
> Seems wasteful.
> 
>>
> Like it says in section 2.4: "Closing the IKE_SA implicitly closes all 
> associated CHILD_SAs."  So (d) is correct.  This really is the cleanest 
> way to "disconnect"
>