On Mon, 4 Dec 2023, Pierre Pfister (ppfister) wrote:
We have received pushbacks from Tero. But I am curious to know if other people share the same opinion, or not.
I think I do. At least, I see a use case for this, but I don't see it based on your current explanations.
To bootstrap the conversation, I'd like to answer Tero's comment (from the recording, with little paraphrasing): "Creating 144 IPsec SA should take less than tenth of a second. IKEv2 have windowing mode. With really big systems, creating more SAs is not an issue." We unfortunately cannot afford to throw more cores at every scaling issue that we have.
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.
IPsec hardware is pretty much limited today by how many keys you can store.
Sure, but in these scenarios, it doesn't seem that this is an issue? eg surely you can have between 1-16 crypto keys? I don't think your explained use cases would require more?
And IKEv2 by how many SAs you must negotiate (Big concern when PFS is enabled).
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.
We need to establish peerings with 10k peers. All our control-plane daemons, routing protocols, IKEv2, must run on one or two cores to leave room for the actual data-plane features.
From reading the draft, I do not understand this use case and how it
relates to the draft. Talking to 10k peers, you need 10k DH key exchanges even if only using one tunnel, I think this would be very (unacceptably?) slow for you. Or, if you can do 10k DH's, are you sure you cannot do 20k of them using the above scheme ? It seems also you need to have at least 10k IPsec SA keys, so if your hardware is limited in keys, then surely this will be a problem for you, unless you are doing something else, eg share the IKE SA or somehow re-use the same IPsec SA key for all tunnels.
The multi-sa draft is not bad and surely solves some of the problems. However, it also emphasizes that we're back to the same issues as IKEv1 trying to so lve our modern performance problems by adding more SAs.
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 ? :) Again, I don't think ipsecme-anti-replay-subspaces is bad. I do worry about it having been inventing at least 4 times and has various IPRs filed on it. I also feel that anti-replay is in fact not that big a deal as TCP or application level detection is required anyway, but I can understand there are silly tickboxes for compliances that insist on this by mistake. So I'm okay with standardizing this common hack, even if I might be very warry implementing it due to the IPR concerns. But as I said, I feel this is not your entire story :) Paul _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
