> On 24 Jul 2020, at 23:42, Michael Rossberg <[email protected]> > wrote: > > Wiliam, Yoav, > > thanks for the comments, I’ll try to elaborate in a single mail as you are > heading in a similar direction. > >> RFC 6311 allows multiple members in a cluster of IPsec gateways to have >> independent parallel SAs so as to solve the problem of synchronization and >> counter re-use among nodes. >> >> While the focus there is on different nodes, the synchronization problem >> also exists between cores of a single node. There is no reason to think RFC >> 6311 could not be adapted to multi-core nodes. >> >> So I’m wondering if we really need multi-window logic to scale over CPUs, or >> whether it would be simpler to just generate multiple SAs for multiple CPUs. > > If one just has a couple of IPsec gateways happening to be many-core systems, > I totally agree that > multiple SAs would be the way to go. IMHO there are still a couple > differences in protocol handling > that may be an advantage here and there, but nothing which justifies a > protocol change in the data > plane. > > Now our believe is that the many-core issue is just a special case of a > broader issue. There are more > reasons to have unsynchronised replay windows.
Right. And my question is, why not have multiple SAs instead of multiple windows within an SA. The advantage of multiple SAs is that you don’t really need to change the other side of the IPsec connection (especially if the peer already supports 6311). So if you have 30 cluster members, or 30 CPUs, or 30 virtual LANs, or 30 QoS classes, you can generate 30 SAs rather than 30 windows within 1 SA. An SA is rather cheap: It requires a value out of a 32-bit space. It requires at a minimum saving the key and current counter. Usually also a 64-bit replay bitmap at the receiver. Add metadata and we’re talking about a few dozen bytes. Add an expanded key for performance, and we’re still under a kilobyte. I’m not saying it’s a better design, but a new design should come with an explanation of why it’s better. Yoav _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
