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). 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.
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
