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. Let me give a small example: Assume we have tenant with 10,000 VMs in a data center, all VMs are coupled over VXLANs, which are in turn IPsec encrypted. Each of the machine may have 16 cores or so. Having SAs for each possible multicast sender being proactively installed requires 16,000 SAs. If we had 8 potential QoS classes, that problem becomes worse. If another VM pops up, a group controller needs to push 8*16 SAs to each of the potential receivers, before communication may take place. Having on-demand replay windows using the same key material, would make the approach much more scalable - without compromising security (people tend to simply disable replay protection, use a single SA and split up IV room). We only had one SA for that tenant, and if there are multicast packets we can direct them to any of our cores for decryption (as long as we do so consistently). This is most likely a kind of odd view on IPsec, but I am pretty sure people will do much more L2 in L3 encapsulation and still want security (zero trust is just one of the buzzwords here). There may be other ways to achieve the same properties, eg creating entire SAs blocks on demand by deriving them locally from a master secret, but the SPI space will get exhausted pretty quickly when we leave room for more CPUs, multicast members etc. @William: The 16-bit sender ID is something we already get from protocols like GDOI to do IV space partitioning (details in https://tools.ietf.org/html/rfc6054). So the mistake is already there. I hope you have more fuel to get a little more heat (in good sense :)
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
