Hello, I've read the draft and support its adoption.
Specifically, we (at Red Hat) have use cases where customer to data center links see performance penalties for enabling IPsec on these connections. We've been looking at how to fix this and this draft seems to be a solution for our use case. Thank you, Regards, Sahana Prasad On Sun, Nov 12, 2023 at 10:15 PM Yoav Nir <[email protected]> wrote: > Hi. > > I’ve read the draft. Overall, it’s similar to a non-standardized solution > we did at Check Point several years ago, so I agree that it is a solution > that works. Of course, since there *are* a bunch of working > implementations, that is not particularly insightful. > > With a lot of flows, it’s likely that in most situations the number of > parallel SAs is going to be about the same as the number of “resources”. > The text in section 4 does mention the issue of having peers with a > different number of CPUs. In practice these can be very different. It’s not > unheard of to have a center office with dozens of CPUs working with a > branch office machine with one. The way this protocol seems to work is that > the center office will attempt to create dozens of SAs, only to be stopped > by the branch office which at some point will return the TS_MAX_QUEUE > notification. I’m not a big fan of creating as many SAs as you can until > the peer fails you, but the alternative would be to pre-negotiate the > ts_max_queue value. > > A couple of editorial comments: > - Although it is implied, it should be stated explicitly that TS_MAX_QUEUE > does not mean no more child SAs with these TS ever. As some child SAs get > deleted and perhaps not rekeyed if they’re idle, if traffic picks up again, > new child SAs with these TS can be created until the peer again blocks you > with a TS_MAX_QUEUE. > - With a single SA pair per TS, implementations can expect that all > packets in a flow (such as a TCP connection) will go through the same SA > pair. This is especially important in implementations that are combined > with firewalls. I think we need explicit text that says packets for any > flow may come on any of the SAs from the logical group of child SAs. > Perhaps: > > “implementations MUST NOT assume that all packets of a particular flow > will be encrypted with a particular SA in the logical group of child SAs.” > > Yoav > > > > On 25 Oct 2023, at 1:40, Tero Kivinen <[email protected]> wrote: > > This will start three week working group laste call for > draft-ietf-ipsecme-multi-sa-performance. The working group last call > will end at 2023-11-15. > > Please review the document and send comments to the list if you think > it is ready for publication. > -- > [email protected] > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec > > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
