I support the draft to be moved forward. some nits:
""" 2. Performance bottlenecks There are a number of practical reasons why most Implementations have ... """ """ As per RFC 7296 """ Should we move section 8 into the appendix instead of removing the section ? I am also interested in the performance benchmark if it is available. Yours, Daniel On Mon, Nov 13, 2023 at 5:32 AM Sahana Prasad <sahana.prasa...@gmail.com> wrote: > 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 <ynir.i...@gmail.com> 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 <kivi...@iki.fi> 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. >> -- >> kivi...@iki.fi >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- Daniel Migault Ericsson
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
