>>> 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.
A key advantage of the replay window approach is that there is no need to setup every window proactively. That is there is no overhead at all as long as a replay window is not used. In a multicast environment it would require reliably pushing a key to every possible sender, which may become a fairly large group. That is IMHO a non-negligible overhead. We could also solve this by adding some kind of associated SA that is automatically set up on-demand, but then we need to subdivide the SPI space somehow. As Valery and William are “unhappy" with only 16-bit sender IDs (perhaps for a good reason), we would require larger SPI fields...
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
