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 < [email protected]> 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
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
