> -----Original Message----- > From: IPsec <ipsec-boun...@ietf.org> On Behalf Of Michael Rossberg > Sent: Thursday, December 7, 2023 12:14 PM > To: Paul Wouters <p...@nohats.ca> > Cc: Pierre Pfister (ppfister) <ppfister=40cisco....@dmarc.ietf.org>; > ipsec@ietf.org > Subject: Re: [IPsec] Why ipsecme-anti-replay-subspaces is needed. > > > >> I would actually like to refrain from writing 2 * 1.024 keys from the > >> control plane to the data plane, just because a single IKE SA rekeyed... > > > > If you rekey the IKE SA, there is no change to the Child SA's. The new > > IKE SA inherits the existing Child SAs. So no 2 * 1024 new keys. > > May be I did not use the correct terms, but if I want to have PFS, I’d still > need > reestablish all of these 2048 keys. This may happen using CREATE_CHILD_SA > messages or reestablishing the IKE-SA altogether (Reauthentication in > strongSwan slang). With a 1000 peers, I’d had to write 2 million keys instead > of 2000 every reauth period and such operations tend to be not uniformly > distributed.
It's not clear what definition of PFS you are using. The standard definition is "the compromise of keys from some SAs do not compromise the security of other SAs". If the IKE SA is rekeyed, it is hard to see how that could compromise the security of existing IPsec SAs (and so generating fresh SAs would appear to be unnecessary). _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
