Hi Michael, > > 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.
You can get replay protection in multicast environment using unmodified ESP and modified receiver's logic (with the same limitations as in your design). You don't need multiple SAs (one per sender). All you need to do - allow GMs to know where to look for Sender ID, which is located in the higher order bits of IV. Of course, it will only work with counter-based ciphers, (as well as in your proposal). > 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... Just for clarification - I'm not unhappy with 16-bit (in fact I think it's enough in _most_ cases), I'm unhappy with this limit hardcoded into the design. Regards, Valery. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
