Hi Paul, Thanks for sharing your opinion.
I agree with you that the configuration changes should not apply to the existing SAs. I can explicitly add some text to elaborate this in the draft and remove the related sections to keep the solution simple. Regards & Thanks! Wei Pan Sent from Paul Wouters On Wednesday, June 9, 2021: > To: Panwei (William) <william.pan...@huawei.com> > Cc: antony.ant...@secunet.com; ipsec@ietf.org > Subject: Re: [IPsec] FW: I-D Action: > draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-04.txt > > On Wed, 9 Jun 2021, Panwei (William) wrote: > > > > The changes may be caused by the administrator modifying the > configuration of the IPSec devices. > > You can find this exact discussion in the list archive two years back I think > :) > > Like Antony, I would like to see this feature removed. IKEv2 does not really > allow you to change the algorithms on rekey anyway, and if you want that > you must start a new IKE SA from scratch. I do think that allowing all these > parameters in IKEv2 was a mistake, which is why I like the concept of the > draft so much. But simpler is better. > > > There is always the possibility of changes. So we need to consider how to > process. > > As I said in the past, you start a new IKE SA in those cases. You cannot > guarantee that the peer will accept your new algorithm, so you must also > always offer the existing one, but then you are not performing your > "configuration change". And logically, I think this configuration change > would be part of re-authenticating the connection more than it would be > part of re-keying the existing crypto key material. And re-authentication is > the same as starting a new IKE SA. > > Do you really have a use case where it is prohibitively expensive an > operation to upgrade the IKE or ESP algorithm without doing a restart of > the entire IKE connection? And how do you know the remote peers are > ready for this change? When do you start refusing the old/current > algorithm if your configuration is updated? > > I think keeping this proposal super simple with only doing rekey and > getting new SPI's and keys and possibly new KE for DH would be best. > Anything else, just fallback to restarting IKE from scratch. > > Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
