Subject: Re: [IPsec] Some comments on draft-mglt-ipsecme-keep-old-ike-sa-00

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 25 Jul 2013 11:27:11 +0400

Hi,

some comments on the draft-mglt-ipsecme-keep-old-ike-sa-00.

1. Draft makes some suggestions that IKEv2 allows IKE SA to
    be silently deleted after successfull rekey. From my understanding
    of IKEv2, it is wrong, as RFC5996 states several times that
    IKE SA may be silently deleted only in case of fatal error,
    like SYNTAX_ERROR, or when peer doesn't respond.
    In all other cases, including rekey, SA must be deleted
    explicitly, by sending Delete Payload to the peer.
    From my understanding, it is initiator of rekey, who is
    responsible for sending Delete Payload after rekey succeeded.
    If it doesn't send Delete Payload, old IKE SA will be kept,
    even without special notifications. So, the name KEEP_OLD_IKE_SA
    for the notification is probably a bit misleading, as old IKE SA
    will be kept in any case untill initiator of rekey explicitly deletes 
it.
    I think that the real purpose of this notification is to tell responder,
    that this is not a rekey, but a request to clone old IKE SA,
    and that in this case responder must not move all child SAs
    from old IKE SA to the new one. Maybe the better name would be
    CLONE_IKE_SA.

2. Is there a real value for "Code Values" field? There are two possible
    values listed - "Keep Old IKE_SA" and "Unused Old IKE_SA".
    As far as I understand, the former is used if initiator wants
    to keep SA, and the latter - if it doesn't. But this may be
    indicated by the precence of notification (keep) or the absence
    of it (normal rekey, don't keep).

3. What is the purpose of "Question Bit"?

4. I very much don't like the idea to combine this notification
    with IKE_AUTH exchange, described in Appendix B.5.
    First, IKE_AUTH is already very complex due to a lot of
    options and making it more complex must be very well
    justified. I don't think that reducing a round trip is
    good justification here. And second, it will not be
    backward compatible, as initiator doesn't know yet if
    responder supports this extension, but already uses
    modified IKE_AUTH exchange. As result - unsupporting
    responder will be choked by the presense of extra SA, N, KE
    payloads and most probably returns INVALID_SYNTAX.

5. Typo in the first sentence of B.2 - two "the' and extra "set" (or 
"establish").

Regards,
Valery Smyslov.

---

From: Daniel Migault <[email-masked]>
Date: Fri, 26 Jul 2013 10:16:57 +0200

Hi Valery,

Thank you for the remarks. See my comments in the text.

On Thu, Jul 25, 2013 at 9:27 AM, Valery Smyslov <[email-masked]> wrote:

> Hi,
>
> some comments on the draft-mglt-ipsecme-keep-old-**ike-sa-00.
>
>    even without special notifications.

That is right. My understanding of RFC5996 is also that it is wrong, and my
understanding is that if removed, the IKE_SA MUST be removed with a Delete
Payload. However, I am not sure all implementations do so. We tested with
Strongswan, and when an (IKE_SA + CHILD_SA). It looks that all CHILD_SA
attached to the IKE_SA are rekeyed and removed with Delete Payload, but the
IKE_SA does not seem to be deleted with Delete Payloads. On the other hand
ipsec statusall does not show the old IKE_SA. We thus assumed the old
IKE_SA has been deleted. We have asked to the Strongswan ML for
confirmation.

> So, the name KEEP_OLD_IKE_SA

Absolutely right CLONE_IKE_SA is much better in all senses. I am buying it!

>    of it (normal rekey, don't keep).

The main purpose of the "Code Values" was to mention there is room for
other actions and see if there are. The draft only concerns the IKE_SA, but
we may extend it in the future to CHILD_SA for example. But I agree that
for the current use, it only clarify the default default behavior.

> The Question / response is handled in the IKE header, so we can remove it.

> Your feedback is very important, thanks. I will add it to the next
version. This also convinces me to have a CLONE_IKE_SA_SUPPORTED Notify
Payload.

> ok thanks

> Regards,
> Valery Smyslov.
>
> ______________________________**_________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/ipsec<https://www.ietf.org/mailman/listinfo/ipsec>
>

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58