Re: [IPsec] Comments to draft-mglt-ipsecme-clone-ike-sa-00.txt

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

Hi Tero,

Thanks for reading and commenting the draft.
As I'm now a co-author of the draft, I'll try to answer.


> In the section 4. Protocol Overview, the draft says:
>
>   The current IKE_SA becomes the old IKE_SA and the newly negotiated
>   IKE_SA becomes the new IKE_SA.
>
> What the draft does not specify what happens to the Child SAs present
> on the old IKE SA. Are they moved to the new IKE SA or are they
> staying at the old. I would expect them to stay, as we just create
> clone of the IKE SA, but as in normal IKE SA rekey they move, this
> needs to be specified.

This is important and it is clarified in the next version (not yet 
published).
You are right, Child SAs stay with old IKE SA.

> Also in the sentence:
>
> If the Initiator does not want or
>   does not care that two parallel IKE SA exists, the CLONE_IKE_SA
>   Notify Payload SHOULD be omitted.
>
> Remove the useless SHOULD. If initiator does not want to create IKE SA
> clone, of course it does not include the notify specifying that it
> wants clone. I.e change text to:
>
> If the Initiator does not want or
>   does not care that two parallel IKE SA exists, it will not include
>   CLONE_IKE_SA Notify Payload in the IKE SA rekey exchange.

Agree.

> In the next sentence there is text:
>
>                 The CLONE_IKE_SA Notify Payload is
>   always part of a CREATE_CHILD_SA IKEv2 exchange.
>
> I think it would be good to specify here too that it is always part of
> a CREATE_CHILD_SA IKEv2 exchange rekeying IKE SA.

It is clarified in the next version.

> In the same section there is text saying:
>
>   The responder supports the CLONE_IKE_SA Notify Payload as it provided
>   a CLONE_IKE_SA_SUPPORTED Notify Payload. If the CREATE_CHILD_SA
>   request concerns a IKE_SA rekey. The responder MUST proceed to the
>   IKE_SA rekey, create the new IKE_SA, and keep the old IKE_SA and
>   respond with a CLONE_IKE_SA Notify Payload as represented below:
>
> I would expect there are situations where the responder does not want
> to allow IKE SA to be cloned, for example when it is running out of
> IKE SAs (i.e. too many clones). This text says the responder MUST do
> that... also the first two sentences should be connected to the later
> ones, i.e:
>
>   The responder has already indicated its support to the CLONE_IKE_SA
>   Notify Payload as it provided a CLONE_IKE_SA_SUPPORTED Notify
>   Payload earlier. When the CREATE_CHILD_SA request with the
>   CLONE_IKE_SA notify is received by the responder, it can either
>   return error (for example NO_ADDITIONAL_SAS) or proceed with the
>   IKE_SA cloning, create the new IKE_SA, and keeping the old IKE_SA
>   and respond with a CREATE_CHILD_SA exchange reply with CLONE_IKE_SA
>   Notify Payload as represented below:
>
> Other option would for the responder to just ignore the CLONE_IKE_SA
> notify and return normal IKE SA rekey packet without doing the
> cloning, but doing normal IKE SA rekey instead. I think it is better
> to return NO_ADDITIONAL_SAS in error cases, than to do IKE SA rekey
> (which initiator didn't want).

Actually, this part is redesigned in the next version along the lines you 
suggest.

> In section 5, the text about the critical bit could be clarified
> (there are lots of misunderstanding about it already), i.e. change:
>
>   - Critical Bit (1 bit):  Indicates how the responder handles the
>         Notify Payload.  In this document the Critical Bit is not set.
>
> to:
>
>   - Critical Bit (1 bit):  Indicates how the responder handles the
>         Notify Payload.  As notify payload is mandatory to support in
>         IKEv2, the Critical Bit is not set.

OK.

> In section 7.  IANA Considerations, change the:
>
>   The new fields and number are the following:
>
> to
>
>   This document allocates two new values from the "IKEv2 Notify
>   Message Types - Status Types" registry:
>
> The security considerations section requires some fixes and more text:
>
>   The protocol defined in this document does not modifies IKEv2.  It
>   signalizes what has been implementation dependent on how to manage an
>   old IKE_SA after a rekey.
>
> s/modifies/modify/

Thanks.

> Also I do not think the RFC5996 said that it is implementation
> dependent on how to manage an old IKE_SA after rekey. It says in
> section 2.8 that old IKE SA is deleted (RFC5996):
>
>     After the new equivalent IKE SA is created, the initiator
>   deletes the old IKE SA, and the Delete payload to delete itself MUST
>   be the last request sent over the old IKE SA.
>
> It does not give any indication how much you should wait after the
> creating new IKE SA, but the text saying "initiator deletes the old
> IKE SA" is quite clear...
>
> So I would fix the second sentence to be something better. The
> security considerations section should also list other attacks, i.e.
> this method could allow creating more IKE SAs or Child SAs between
> peers than what would be possible with single IKE SA (for example
> there might be Child SA limit per IKE SA, and this can be used to
> bypass that limit or similar). It also might affect auditing and
> accounting, as now for example only the first IKE SA might cause the
> account start event to be called, but it might be possible that each
> IKE SA destroy even will stop accounting. Also accounting might be
> interested how many clones the IKE SA has, or it might only be
> interested of the very first and very last IKE SA for the same ID.

Agree, this section needs more words.

> In appendix B.1 the text:
>
>   The exchange is completely described in [RFC4555].  First the
>   negotiates the IKE_SA.  In the figure below peers also proceed to NAT
>   detection because of the use of MOBIKE.
>
> Is missing some words in the second sentence (First the negotiates).

Thanks.

> In section B.3 fix:
>
>      Alternatively, the VPN End User MAY uses a different IP
>   address for each interface
>
> s/MAY uses/MAY use/

Thanks again.

> The exchange B.5 is not accoding to the draft, as it has
> N(CLONE_IKE_SA) inside the IKE_AUTH exchange, and the draft says it
> can only be in the CREATE_CHILD_SA exchange doing IKE SA rekey. So
> that kind of optimized negotiation is not possible with current draft.
>
> Also I think adding that kind of complexity in the IKE_AUTH is bad
> idea, so I would simply remove the B.5 example.

Agree and this "reduced" exchanges are already completely removed from the 
draft.

Thanks,
Valery.

> -- 
> [e-mail]
>
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec