Hello Paul, thank for the reply, > It's not really an issue of cores. You do not need to do that many DH > exchanges, and those are the only real expensive operation.
> As Tero explained, to get PFS on many Child SAs, you create an IKE SA, > then create thousands of tunnels without PFS, and then rekey the IKE SA. > Now all your thousands of tunnels have PFS. This only costs 2 DH Key > Exchanges. 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. > With 10k peers, and 2 cores, multi-sa vs ipsecme-anti-replay-subspaces > is only twice as expensive (20k Child SAs vs 10k Child SAs). I doubt > that this is your real issue, so I am left wondering, what else is > going on that you haven't shared with us ? :) We have been over our use-case in the draft and during our presentations. ;-) 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. 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. - Pierre Pfister
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
