Pierre Pfister (ppfister) writes: > > 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.
If you are considering all of those Child SAs to be one real SA, which is just split to separate Child SAs because of the multiple cores, then I think you should only do one PFS for them. Of course if you assume someone can hack into only one of the CPUs and can't access other cpus then there might be need to do separate Diffie-Hellman for each of the cpus, but then subspaces draft does not fullfill that requirement either, thus you need to do separate Diffie-Hellman for each of them also. Instead of just having single flag for PFS, you should have better control for when to do Diffie-Hellman for Child SAs than just yes/no. > > 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. SET_WINDOW_SIZE will have huge difference in the overall time to set up the SAs. I mean if setting up one SA takes less than millisecond vs tens or hundreds of millisecods, there is ten or hundered times performance penalty for not using it. Window time DOES NOT help when setting up one SA for each 10000 peers, but it helps a lot when setting up 100 SAs for 100 peers. You do not need subspaces if you only have one SA for each peer. To implement subspaces with multiple SAs, you will need create multiple Child SAs with each peer, and there window size will help a lot during the startup phase. > That being said, I agree SET_WINDOW_SIZE is a desirable feature, > unfortunately not available in Strongswan. So that should be first target to do, instead of trying to add new protocol features. I mean it is no suprise you are getting bad performance if you do not even implement the basic features of IKEv2. Yes, the RFC7296 do say that "The following are features that can be omitted in a minimal implementation", and that list includes things like window sizes greater than one, EAP authentication, NAT-traverseal, establishing multiple Child SA with single IKE SA, rekeying SAs... > 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. So what kind of limits the current hardware have? And do you think those hardwares are able to implement subspaces in such way that they share keys? I mean sequence number generation on the AEAD ciphers are usually considered to be inside the crypto boundary, so to implement different counters for each different core, might still require multiple hardware keys to be installed if each key includes sequence number also. Can you give some real world examples which kind of limits there are on specific hardware? -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
