On Thu, 7 Dec 2023, Pierre Pfister (ppfister) wrote:
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.
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.
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
