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

[Daniel Migault <[e-mail]>]

Hi Steffen,


I think I mostly agree with you. Please see inline,

Yours,
Daniel

On Wed, Nov 23, 2022 at 1:36 AM Steffen Klassert <
[e-mail]> wrote:

> On Tue, Nov 22, 2022 at 04:58:55PM -0500, Daniel Migault wrote:
> > This draft is missing an important part which is the actual negotiation
> > of the multiple SAs. A peer willing to set these multiple SAs will have
> to
> > negotiate them anyway. Some implementations can
> > handle parallel CREATE_CHILD_SA others cannot and the negotiation of
> > multiple SAs might take a very long time, at least a time that is not
> > acceptable to high performance tunnels. Since these child SAs need to be
> > created, the one willing to the multiple SAs can simply start and stop
> when
> > the responder says stop. In terms of IKEv2 the gains are minimal. The
> > document may add a mechanism similar to address that:
> > https://datatracker.ietf.org/doc/draft-mglt-ipsecme-multiple-child-sa/
>
> I'm one of the authors of the above mentioned draft and the draft
> we are discussing here.
>
> Speaking as an author of the above mentioned draft:
>
> This draft was a first attempt so solve the multi cpu SA case.
> The mechanism to install all child SAs once that was used there
> was seen as as too complex, given that the number of cpus are
> not too high. So it should be possible to either create
> separate parallel child SAs, or creating them on demand when
> traffic pops up an a certain cpu.
>
The draft we discuss here takes this into account and
> reduces the complexity to a minimum.

I agree but in my opinion the draft has some scalability limitation and to
be useful needs to be combined with something else - 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.


> > However, draft-ponchon-ipsecme-anti-replay-subspaces addresses all of
> these
> > issues nicely and provides a much more scalable solution. It basically
> > makes -IMO - both -multiple-child-sa and -multi-sa-performance obsolete.
>
> I disagree here. The multi-sa-performance draft just adds two IKE
> notifications, so no achitectural changes. This is the 'low hanging
> fruit', it can be done independent of any changes to ESP.
>
> The anti-replay-subspaces draft does architectural changes to ESP,
> this needs more work.
>
> 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.


> > My suggestion is that -multi-sa-performance is being moved to
> experimental
> > and almost shipped as it is so the work being achieved is documented.
> This
> > has been some interesting work, but today, I would like the group to
> spend
> > more cycles on draft-ponchon-ipsecme-anti-replay-subspaces that I
> consider
> > more promising.
>
> I already proposed to work on a ESP-v4 version, and this draft should
> definitely be considered there. But the discussion about ESP-v4 should
> be open, and not focused on this particular proposal.
>
> 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.

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.

-- 
Daniel Migault
Ericsson