Hi Paul, Thanks very much for your suggestion. I've updated the 06 version based on your changes. The draft looks much simpler now.
Regards & Thanks! Wei Pan > -----Original Message----- > From: Paul Wouters [mailto:paul.wout...@aiven.io] > Sent: Monday, July 12, 2021 11:35 AM > To: Panwei (William) <william.pan...@huawei.com> > Cc: ipsec@ietf.org > Subject: Re: [IPsec] I-D Action: > draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.txt > > On Mon, 5 Jul 2021, Panwei (William) wrote: > > Hi Wei Pan, > > > According to the discussion on the mailing list, I update the draft to > version 05. In this version, I deleted the unnecessary considerations for the > configuration changes. For now, the solution is very simple and just > includes the negotiation at creating IKE SAs and optimization at rekeying > IKE and Child SAs. > > > > Comments and feedbacks are more than welcome. > > It is lookger much better and simpler, but I still had a few issues and wanted > to make the document a bit shorter and clearer. I made some changes for > your consideration. I've attached an updated xml and txt file in case you > would like to use my changes. The changes are: > > - Reduced the text that was used to explain a lot of IKEv2 basics. > > Instead, a reference to IKEv2 should be enough. This greatly simplifies the > text. > > - Remove the parts about "changed configuration". > > If the crypto parameters have changed, you SHOULD NOT use REKEY. RFC > 7296 says this: > > In Section 2.8, "Note that, when rekeying, the new Child SA MAY have > different Traffic Selectors and algorithms than the old one" was > changed to "Note that, when rekeying, the new Child SA SHOULD NOT > have different Traffic Selectors and algorithms than the old one". > > So if the configuration has changed, you should not do any kind of REKEY, > whether it is OPTIMIZED or not. You should do a re-authentication (in other > words, a new IKE from scratch) > > - IKE REKEY MUST contain KE, because RFC 7296 says: > > The main reason for rekeying the IKE SA is to ensure that the > compromise of old keying material does not provide information > about > the current keys, or vice versa. Therefore, implementations MUST > perform a new Diffie-Hellman exchange when rekeying the IKE SA. In > other words, an initiator MUST NOT propose the value "NONE" for the > Diffie-Hellman transform, and a responder MUST NOT accept such a > proposal. This means that a successful exchange rekeying the IKE SA > always includes the KEi/KEr payloads. > > - Removed: It also helps to avoid IP fragmentation of IKEv2 messages > > I don't think this is actually true, since on rekey there are no required CERT > payloads, which is the vast majority of the payload size in IKE_AUTH that > causes fragmentation. > > - Changed MINIMUM_REKEY{_SUPPORTED} to > OPTIMIZED_REKEY{_SUPPORTED} > > This matches better with the OPTIMIZED_REKEY notify. Also, I find that > "minimum" is a little confusing. It could mean "minimum lifetime" or > "minimum of the previous one". I find "optimized" covers this better than > "minium". > > - Shortened titles > > For improved readability of Table of Contents > > - Some grammar and style > > Open questions to the working group: > > 1) Should the SUPPORTED notify mean that peers MAY use this method or > MUST > use this method? There could be a use for making it MUST, as a peer > could then eventually stop supporting the "old method". Initiators > would know by the lack of the notify that they might not be able to > rekey in the old way, and must add/delete or re-auth the SA. > > 2) Alternatively, the SUPPORTED notify could have a payload that signifies > whether the old method is supported or not. > > 3) Should we look at supporting rekeying multiple Child SAs at once? Or > should we tell people they should have used additional Traffic > Selectors and combined the Child SAs into one ? > > 4) When a Child SA was negotiated with PFS, what should an optimized > rekey > do when there is no KE payload? Send INVALID_KE_PAYLOAD ? > > > Paul > > > > > > > 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: Monday, July 5, 2021 12:24 PM > >> To: i-d-annou...@ietf.org > >> Subject: I-D Action: > >> draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.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-05.txt > >> Pages : 9 > >> Date : 2021-07-04 > >> > >> 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-pa > >> yloa > >> ds-opt/ > >> > >> There is also an htmlized version available at: > >> https://datatracker.ietf.org/doc/html/draft-kampati-ipsecme-ikev2-sa- > >> ts-p > >> ayloads-opt-05 > >> > >> A diff from the previous version is available at: > >> https://www.ietf.org/rfcdiff?url2=draft-kampati-ipsecme-ikev2-sa-ts-p > >> aylo > >> ads-opt-05 > >> > >> > >> 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
