Hi Paul, >> My understanding is that when PFS is enabled, the first CHILD_SA leverages >> the IKE SA key, but any further CREATE_CHILD_SA (which is the case when >> setting up more “sub-SAs”) would use separate keys. >> >From RFC5996: >> Although ESP and AH do not directly include a Diffie-Hellman >> exchange, a Diffie-Hellman group MAY be negotiated for the Child SA. >> This allows the peers to employ Diffie-Hellman in the CREATE_CHILD_SA >> exchange, providing perfect forward secrecy for the generated Child >> SA keys. > > PFS comes from the back that if the IKE peer is compromised, you cannot > copy and use the KEYMAT from which the Child SAs were derived. So yes, > using a DH per Child seperates that from the IKE SA DH. But the exact > same is achieved if you derive 1000 Child SAs from the IKE SA KEYMAT > and then rekey the IKE SA for a new KEYMAT where you wipe the old KEYMAT > from memory. Now if your IKE SA is compromised, the old KEYMAT is not > there and so there is no way to recreate the CHILD SA keys. > > In short: IKE SA -> many Child SA's -> IKE SA REKEY gives you PFS for all > Child SAs.
>> With 10k peers, we would have more than 2 cores. On top of which we >> also want to use subpaces to avoid re-ordering issues over multiple >> traffic-engineered paths (MPLS, QoS, uplinks, etc…). >> That’s how we got to the number of 64+ subspaces for a single tunnel. > > I wonder if this works at all in practise. Just fine. Pierre is here a little conservative with his setting. We have a different setting with 1.024 Sub-SAs as of today… 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... Any reasons to strengthen your believe? >> The sad part is that this doesn’t even depend on remote peers being >> big or small. One big device connecting to 10k small devices will need >> many subspaces to account for all its cores and traffic-engineered paths. >> Storing keys in hardware is already challenging today. Often it requires >> actually storing only some of the keys and using software slow-path for >> certain peers. But dividing by 64 the numbers of tunnels we can support >> in the fast-path is not acceptable. > > 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... Michael
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
