Pierre Pfister \(ppfister\) writes: > "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. 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). > We need to establish peerings with 10k peers. All our control-plane > daemons, routing protocols, IKEv2, must run on one or two cores to > leave room for the actual data-plane features. Create IKE SA is much more expensive than create Child SAs, thus create 10000 IKE SAs will take quite a lot of time and CPU than doing the additional Child SAs for them. How fast can you create those 10000 IKE SA in your system now? How long does it take to create 100 Child SAs using window size of 64 on one IKE SA? > What exactly did you mean by "big systems" ? The big systems we used for testing are most likely slower than the modern phones, so there is no point of me trying to remember what your big systems are. I would assume you have some systems you can run some tests on, so can you (or someone else, Valery?) do those and come back with numbers so we know what are the numbers on current hardware. The important thing is to make sure you set the IKE window size to large enough value, i.e., something like 32 or 64, otherwise your performance is going to be really slow. > To give a more concrete example: > > One of the reasons for IKEv2 design was to support multiple traffic > selectors per SA (See point 9 in > https://www.rfc-editor.org/rfc/rfc7296#appendix-A). In IKEv1, the > design was also to throw more SAs at the problem. Someone who needed > multiple different traffic selectors would create multiple SAs. We > are repeating the same historical mistake now but with cores instead > of traffic selectors. Actually the point 9 is completely different. IKEv1 shared the ID payload for the traffic selectors, thus it was hard to express the policies people wanted with the very limited structure of the ID payload (i.e., either exactly one IP, IP subnet or IP range was possible, no protocol or port). In IKEv1 you could not throw more SAs on the problem, as people had different understanding whether the new SA will replace or not replace the previous SA. On the other hand there was a way to create multiple SAs with one Quick Mode exchange, with exactly same "traffic selectors" but different algorithms and SPIs, but I do not know if anybody implemented this feature ever (even my implementation did not implement that if I remember right). The reason for point 9 is that we wanted to separate the ID payload and traffic selector payload, so we can have things like protocols and ports there too, on the other hand we simplified it by removing everything else than address ranges. The reason it support list of ranges is because the decorrelated policy from RFC4301 will quite often generate multiple ranges for the same policy rule, because of how the decorrelation works, i.e., it punches holes on the rules by removing IP address ranges covered by higher priority rules. We did not think this completely through, as we should have included protocol ranges too, as now you can't easily express everything else except TCP port 25 using traffic selectors. > The multi-sa draft is not bad and surely solves some of the > problems. However, it also emphasizes that we're back to the same > issues as IKEv1 trying to solve our modern performance problems by > adding more SAs. I do not think we are going anywhere to the direction of IKEv1. IKEv1 implementations did not try to solve issues by creating multiple SAs, as this would have cause interoperability issues, as different implementations deleted overlapping SAs at will. That is one of the reason why IKEv2 specifications says that SAs with same traffic selectors are ok: Note that IKEv2 deliberately allows parallel SAs with the same Traffic Selectors between common endpoints. One of the purposes of this is to support traffic quality of service (QoS) differences among the SAs (see [DIFFSERVFIELD], [DIFFSERVARCH], and Section 4.1 of [DIFFTUNNEL]). Hence unlike IKEv1, the combination of the endpoints and the Traffic Selectors may not uniquely identify an SA between those endpoints, so the IKEv1 rekeying heuristic of deleting SAs on the basis of duplicate Traffic Selectors SHOULD NOT be used. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
