Re: [IPsec] Why ipsecme-anti-replay-subspaces is needed.

[Ben Schwartz <[e-mail]>]

As I've mentioned previously, I think this draft is valuable for "network-to-network" tunneling, where the sender and receiver are both represented by a large (and evolving) collection of gateways (perhaps sharing IPs via anycast).  This situation requires O(N^2) SAs in the current protocol, but with sequence number subspaces it can be arranged with O(N) or even O(1) SAs.

--Ben Schwartz
________________________________
From: IPsec <[e-mail]> on behalf of Pierre Pfister (ppfister) <ppfister=[e-mail]>
Sent: Monday, December 4, 2023 3:52 AM
To: [e-mail] <[e-mail]>
Subject: [IPsec] Why ipsecme-anti-replay-subspaces is needed.

Hi all, I'd like to encourage a discussion here around why the solution described in draft-ponchon-ipsecme-anti-replay-subspaces is needed, and why draft-ietf-ipsecme-multi-sa-performance is not sufficient for us. So far, we have received feedback
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender

ZjQcmQRYFpfptBannerEnd

Hi all,



I'd like to encourage a discussion here around why the solution described in draft-ponchon-ipsecme-anti-replay-subspaces is needed, and why draft-ietf-ipsecme-multi-sa-performance is not sufficient for us.



So far, we have received feedback from people supporting our work, and sharing the same need. I'd like to encourage those people to take part in this thread.



We have received pushbacks from Tero. But I am curious to know if other people share the same opinion, or not.



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. IPsec hardware is pretty much limited today by how many keys you can store. And IKEv2 by how many SAs you must negotiate (Big concern when PFS is enabled).



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.

What exactly did you mean by "big systems" ?



To give a more concrete example:



One of the reasons for IKEv2 design was to support multiple traffic selectors per SA (See point 9 in https://www.rfc-editor.org/rfc/rfc7296#appendix-A<https://www.rfc-editor.org/rfc/rfc7296#appendix-A>). In IKEv1, the design was also to throw more SAs at the problem. Someone who needed multiple different traffic selectors would create multiple SAs. We are repeating the same historical mistake now but with cores instead of traffic selectors.



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 solve our modern performance problems by adding more SAs.