>> 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. >>> On your big router that connects 10k clients, there is no point in using >>> multi-sa to gain speed. It has enough SAs that it can just leave them >>> all on a single CPU for each client. So you only need to have a multi-sa >>> child sa per client core (which you say is 2) and not 64 because your >>> server has 64 cores. With 10k clients, you already have 156 clients per >>> core. You gain nothing by splitting those into 64. >> >> You are right about scaling for the black to red path, but for the other >> way around, one had to determine the right core when the unencrypted >> packet enters the VPN box. So either the NIC in the red side “knows” >> about the core allocation or, if you would use RSS, you will stick with >> inter-CPU-core communication in most cases, unless you have one >> SA per Core (or even more "for MPLS, QoS, uplinks, etc…”) >> >> Sub-SA would of course completely resolve that issue... > > I guess I'm insure how you would deal with QoS related issues when you > have two cores, but one uplink bandwidth. How would the cores not stomp on > each other? It seems you need to synchronise things on the client router > onto a single entity that determines which packet goes out first to keep > the stream complying with QoS settings. Ensuring QoS policies is not the task of the IPsec encryption. In our case it either happens using an external router or by using hardware offloads of the black NIC. However, I also know cases where shaping does not happen at all and DSCP fields are just mapped to different hardware queues. As QoS is not critical from a confidentiality perspective, it is much easier to realize in untrustworthy hardware (and without CPU coordination). Michael
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
