On Tue, Nov 30, 2021 at 8:21 AM Daniel Migault <mglt.i...@gmail.com> wrote:
> > Thank you all for the comments. I believe there is a misunderstanding of > the resource issue we are facing, so please find below a more detailed > description. > > The resource in question is neither related to the CPU nor the memory, nor > the bandwidth as comments seem to suggest but instead related to the number > of table entries that perform the IPsec processing that varies between 720 > to 4000 depending on the hardware chip. > Okay. Randomizing the SA lifetime is a probabilistic approach we - and our customers - do not want to rely on even if the probability of collision decreases with the SA lifetime. So now I am a bit confused. If you are mostly concerned able table length, then 1 double IPsec SA won't hurt you, but 4000 will. So removing a random percentage amount of seconds from the initiator would actually probabilistic fix your issue. 4000 connections with a lifetime of 3600s, that all start at the same time with a 20% fuzz on initiator would cause you an extra 5 or 6 SAs. If your code recognises the new SA traffic, and there is frequent traffic, these double SAs would go away in seconds. So on a unit that can do 4000 SAs, you can now do only 3994 SAs. Am I making a mistake here ? Paul
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
