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.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
