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