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 protected]> wrote: > 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. 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 > 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. > Absolutely right CLONE_IKE_SA is much better in all senses. I am buying it! > > 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). > 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. > > 3. What is the purpose of "Question Bit"? > > The Question / response is handled in the IKE header, so we can remove it. > 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. > > 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. 5. Typo in the first sentence of B.2 - two "the' and extra "set" (or > "establish"). > > ok thanks > Regards, > Valery Smyslov. > > ______________________________**_________________ > IPsec mailing list > [email protected] > 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
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
