On Thu, Dec 07, 2023 at 04:43:44PM +0100, Michael Rossberg wrote: > 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?
I percive a few hidden implementation details here. Those hound me when thinking about large number of SubSAs. Yes, you can create 1024 SubSAs! In the context of typical x86 implementations, when dealing with, let's say, 1024 Sub SAs all using the same key, I'm curious about how many copies of the key you need for high performance on multi core CPU? Specifically, I wonder if all CPUs would share the same key from a single memory location. My limited understanding is that you may need a local copy on each CPU to mitigate potential data cache misses and performance penalties. When there is a significant difference in the number of SubSAs and the number of CPUs, keeping a copy of the key per CPU would appear excessivea. How would sub-space sequence number implement replay protection for each sub-space? I'm wondering about the complexity of such an implementation! When you have 1024 SubSAs, are you keeping track of 1024 replay windows separately? How do you enforce a byte or packet limit per SA? How do you obtain a global byte and packet counter from 1024 SubSAs? I feel there are many implementation details to consider for high performance. Would typical commands like "ip xfrm state" show the byte and packet count across all SubSAs? _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
