Hi Antony, Thanks for your comment, it's a good proposal and I'm happy to see it.
The changes may be caused by the administrator modifying the configuration of the IPSec devices. For example, if the device has been patched with an update of supporting a new algorithm, then the administrator might change the configuration to use this new algorithm. There is always the possibility of changes. So we need to consider how to process. I agree with you that the current process defined in the draft is complicated, and I have no objection to your proposal. And I have some more considerations, so combined with your proposal, I think there are three ways of handling: 1) Changes are allowed, and the rekeying needs to consider this situation. This is the idea of the current draft, and I agree with you that it's complicated. 2) Changes are allowed, but they won't be applied to the existing IKE SAs and Child SAs, i.e., the rekeying of existing SAs won't be affected, and the newly established IKE SAs and Child SAs will apply for the new configuration. 3) Changes are not allowed, this may be reflected at the user perception level, e.g., administrator configuration modifications failure, patch loading failure, etc. I think all the above three approaches are viable, and actually I don't have a special preference. I'm happy to see your and others' opinions. Regards & Thanks! Wei Pan > -----Original Message----- > From: Antony Antony [mailto:antony.ant...@secunet.com] > Sent: Wednesday, June 9, 2021 8:01 PM > To: Panwei (William) <william.pan...@huawei.com> > Cc: ipsec@ietf.org > Subject: Re: [IPsec] FW: I-D Action: > draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-04.txt > > Hi, > I am happy to see this draft progressing. I am wonder why allow changes > once both sides agreed to minimal rekey? > > The draft currently allow changes to cryptographic suite and TS even when > MINIMAL_REKEY_SUPPORTED is negotiated. While this is a more inclusive > and flexible approach, I feel it increase chance of interruption when the > responder send NO_PROPOSAL_CHOSEN response and initiator does not > support changing parameters. Also if the initiator send a rekey with > changes and the responder only support MINIMAL_REKEY_SUPPORTED > rekey will not be smooth. Such issues are hard to debug because, it only > show up when rekeying not when establishing IKE or Child SA. > > I prefer decide at the beginning to allow changes during rekey or not. > > My proposal is once both sides negotiated MINIMAL_REKEY_SUPPORTED > no changes should be allowed during a rekey, in case of both the IKE SA > and the Child SA. Rekey should be a simple refreshing the keying materials > and nothing else. > > If you make this change, you can remove the notifiers *UNCHANGED and > also remove section. > '3.2.2. Rekeying IKE SAs When Responder's Cryptographic Suites Changed' > > regards, > -antony > > > On Wed, Apr 21, 2021 at 08:11:14 +0000, Panwei (William) wrote: > > Hi Chairs, folks, > > > > I've updated a new version of > draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt. It's not a big update. I've > received many good comments online/offline before. I tried to address > some of them, and there are still several comments under consideration. > > > > This draft tries to optimize the unnecessary payloads at the time of > rekeying IKE SAs and Child SAs. If there is no changes of configuration on > the peers, they usually reuse the same crypto suites when rekeying the IKE > SAs and Child SAs, so the SA and TS payloads will remain the same as the > ones of last rekeying. Therefore, the SA and TS payloads can be omitted at > such condition. This optimization can save the bandwidth and power > consumption. > > > > This draft was presented at IETF105 and IETF106, and received many good > comments and supports. Paul also presented this topic at IETF110 (many > thanks to Paul) and mentioned that he wanted to implement it. After > IETF110, Meiling Chen from China Mobile contacted to me privately, she > believes this draft is valuable and can be used by them, thanks to her > support and help of editing the draft. > > > > To chairs: I feel many people are interested in this work and I wonder > whether I can ask for an adoption call for this draft? > > To folks: any comments or feedbacks are very welcome. > > > > Regards & Thanks! > > Wei Pan > > > > > -----Original Message----- > > > From: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] On > Behalf > > > Of internet-dra...@ietf.org > > > Sent: Wednesday, April 21, 2021 2:34 PM > > > To: i-d-annou...@ietf.org > > > Subject: I-D Action: > > > draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-04.txt > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > > > > > > > Title : IKEv2 Optional SA&TS Payloads in Child > > > Exchange > > > Authors : Sandeep Kampati > > > Wei Pan > > > Meduri S S Bharath > > > Meiling Chen > > > Filename : > > > draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-04.txt > > > Pages : 13 > > > Date : 2021-04-20 > > > > > > Abstract: > > > This document describes a method for reducing the size of the > > > Internet Key Exchange version 2 (IKEv2) exchanges at time of > rekeying > > > IKE SAs and Child SAs by removing or making optional of SA & TS > > > payloads. Reducing size of IKEv2 exchanges is desirable for low > > > power consumption battery powered devices. It also helps to > avoid IP > > > fragmentation of IKEv2 messages. > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-kampati-ipsecme-ikev2-sa-ts-p > > > ayloa > > > ds-opt/ > > > > > > There are also htmlized versions available at: > > > https://tools.ietf.org/html/draft-kampati-ipsecme-ikev2-sa-ts-payloa > > > ds-opt > > > -04 > > > https://datatracker.ietf.org/doc/html/draft-kampati-ipsecme-ikev2-sa > > > -ts-p > > > ayloads-opt-04 > > > > > > A diff from the previous version is available at: > > > https://www.ietf.org/rfcdiff?url2=draft-kampati-ipsecme-ikev2-sa-ts- > > > paylo > > > ads-opt-04 > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > _______________________________________________ > > > I-D-Announce mailing list > > > i-d-annou...@ietf.org > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
