Re: [IPsec] IPsecME WG Adoption call for draft-pwouters-ipsecme-multi-sa-performance

[Paul Wouters <[e-mail]>]

[speaking as individual]

On Wed, Nov 23, 2022 at 9:32 AM Daniel Migault <[e-mail]> wrote:

> I agree but in my opinion the draft has some scalability limitation and to
> be useful needs to be combined with something else
>

That is not true. Perhaps for your use case, but not other people's use
cases, such as highspeed (eg 10gbs+) DC interconnects with devices with
multiple CPUs. It is very much "useful" without "something else" as we
presented in the past with our benchmarks.

- at least this is my understanding. Maybe I am biased as the use case it
> may address is not the one we have. Do not get me wrong, I think the work
> has been useful and should be documented. But I think that the alternative
> that limits the number of SA is very attractive, especially for our
> hardware implementations with a limited number of SA.
>

That is a very different use case.

I agree that the advantage of the draft is that it is a very ow
> hanging fruit but on the other hand - at least as I see it -
> -ponchon-ipsecme-anti-replay-subspaces provides a complete solution to the
> scalability concern we have.
>

See my previous posting to the list. There might be IPR issues to address
first before a solution like that draft can be adopted to the WG.
Regardless, it is a different solution that does change the security
properties and the Child SA properties. I believe this work does fall under
the "ESP update" work, independently of this draft, that requires no update
to ESP.

I agree ESP-v4 should be considered natively, but I would like
> -ponchon-ipsecme-anti-replay-subspaces to be implemented with the current
> ESP mostly so we do not wait ESP-v4 to have it. Actually at Ericsson we
> would like to implement the standard version of
> -ponchon-ipsecme-anti-replay-subspaces in a reasonable delay -- i.e. next
> year.
>

Provided the IPR issues are resolved, the WG surely can look at this.
Although as has been pointed out, if anti-reply is your only issue, then
perhaps the easiest thing to deploy right now would be ESP without replay
protection enabled? And trust that the application layer (TCP, QUIC, UDP
applications) handle out-of-order or duplicate packets themselves.

To clarify my position I am not opposed to the adoption of the draft. My
> position is that it gets published as soon as possible as an experiment
> that paves the way for a more complete solution. In other words, I think we
> should not have the document being discussed for years in the WG.
>

That is generally true for every document in every WG :)

I think people in the WG have shown that there is some urgently to
addressing ESP performance issues. But the WG is all of us, so all of us
need to keep the speed going on this. I think it would be good to get a
problem statement doc out as Steffen indicated, so that we know all the
issues we want to address in ESP.

Paul