Subject: Re: [IPsec] FW: I-D Action: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-04.txt

From: Antony Antony <[email-masked]>
Date: Wed, 9 Jun 2021 14:01:12 +0200

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:[email-masked]] On Behalf
> > Of [email-masked]
> > Sent: Wednesday, April 21, 2021 2:34 PM
> > To: [email-masked]
> > 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-payloa
> > ds-opt/
> > 
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-kampati-ipsecme-ikev2-sa-ts-payloads-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
> > [email-masked]
> > 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Panwei (William)" <[email-masked]>
Date: Wed, 9 Jun 2021 13:10:07 +0000

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

> From: Antony Antony [mailto:[email-masked]]
> Sent: Wednesday, June 9, 2021 8:01 PM
> To: Panwei (William) <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [IPsec] FW: I-D Action:
> 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.
> 
> 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.
> 
> > 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?
> > > Subject: I-D Action:

---

From: "Panwei (William)" <[email-masked]>
Date: Thu, 10 Jun 2021 11:13:27 +0000

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:
> Cc: [email-masked]; [email-masked]
> 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.
> 
> 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