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

["Valery Smyslov" <[e-mail]>]

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.