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

[Daniel Xu <[e-mail]>]

Hi Pierre,

On Mon, Dec 04, 2023 at 08:52:52AM +0000, Pierre Pfister (ppfister) wrote:
> 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.

[...]

I'm pretty new to this space, so apologies if my question is backwards
or irrelevant. 

How do subspaces interact with modern-ish hardware features like RSS?
IIUC in the literature they would say this protocol extension is not
self describing on the wire. So HW would not be able to look at the ESP
packet and be able to consistently map subspace flows to NIC queues. Unless
it starts intercepting IKE messages, right? Or control plane programs
the NIC in-band.

Also I'm wondering about cloud use cases like with AWS where AWS places
per-flow throughput limits. Currently all ESP flows (regardless of SPI
value) are accounted towards a single flow limit. They could (in theory)
have separate flow limits differentiated by SPI. But IIUC with subspaces
it would again mix the flows. And it would be odd if AWS allowed you to
inform their fabric of subspace usage.

So IMO (ignoring the IKE overhead conversation which I have no opinion on)
subspaces does not completely solve all the problems in this space where
from my PoV the multi-sa approach does.

Sorry again if this question is backwards -- maybe the point of
standardizing through IETF is to get entities like AWS or HW vendors to
do things differently.

Thanks,
Daniel