Hello Tero, thanks for the reply. > > "Creating 144 IPsec SA should take less than tenth of a second.
> > IKEv2 have windowing mode. With really big systems, creating more > > SAs is not an issue." > > > > We unfortunately cannot afford to throw more cores at every scaling > > issue that we have. IPsec hardware is pretty much limited today by > > how many keys you can store. And IKEv2 by how many SAs you must > > negotiate (Big concern when PFS is enabled). > > Sending 144 small encrypted packets, and receiving 144 small encrypter > packets should not take lots of CPU power. The CREATE_CHILD_SA does > NOT need to do any Diffie-Hellman, and there is no public key crypto > on them, so it is just encrypting those packets, sending them out and > getting responses back. The only thing why it might take long is that > if you do not implement SET_WINDOW_SIZE. AFAIK, per CHILD_SA DH is needed when PFS is enabled. > > I.e., if you used window size lets say 64, that means that you can > send 64 CREATE_CHILD_SA requests out, meaning symmetric encrypting few > kB worth of data, so that should not take more than few milliseconds. > Then you need to wait for the responses, and if the server is far > away, you might need to wait for lets say 100ms for responses, and > then decrypting and processing responses takes again few milliseconds. > > Then you repeat this 3 times, and you should be able to create those > 144 SAs in about 300-500 ms, using less than 100 ms of CPU time. > > All my test results are from more than 10 years back, and we did run > them mostly on single CPU machines, but I do not think modern CPUs are > that much more slower than those ones (and I do not remember exact > results from that far back). I don’t think SET_WINDOW_SIZE would really help reducing the overall time when it gets to scaling up to 10000 peers, since the CPU will remain mostly busy processing and sending packets all the time. That being said, I agree SET_WINDOW_SIZE is a desirable feature, unfortunately not available in Strongswan. The other issue I mentioned above is even more of a problem, and it’s about how many keys can be stored in the crypto hardware. Of course that number depends on how much money you are willing to spend on the hardware, but in the high-end boxes I work on, that number doesn’t go beyond a few thousands. Dividing by 64+ the number of tunnels we can operate in hardware (vs slow-path in software) is not an option. - Pierre Pfister
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
