No firestorm on the previous message, so here's more fuel....
On 7/22/20 6:26 AM, Michael Rossberg wrote:
* Allow multiple windows per SA to allow for scaling over CPUs, windows
per QoS
class & replay protection in multicast groups
In the SIPP (IPv6) IPng WG, where we were designing IPsec circa 1993, one of the
principal authors was Steve Deering, a/the father of multicast. Some multicast
issues were known and discussed at that time.
I'm not sure that including a number for the sender is the best way to achieve
this goal. We already have the IP sender's address, and in IPv6 the Flow Label,
so that's duplicate information.
OTOH, I'm very sure that duplicating TCP sliding window functionality is unwise.
The proposed field is much too short for large bandwidth-delay products.
Perhaps
you want it for UDP?
However, we were also aware of the need for multiple concurrent SPI flows. We
need to keep each CPU working as long as possible on the same data.
(When I was at university in the 70s, we had a CDC 6500: 2 main CPUs, and 10
peripheral CPUs. Multi-processing was part of the curriculum, as was OS
design, plus a year-long compiler design and implementation class.)
Therefore, I'd recommend that IPsec instead implement a block of related SPIs.
Each SPI should have its unique session-key as usual, but all would have the
same next protocol header and TCP/UDP port associated with the same flow.
In the Photuris Extended Attributes internet-draft circa July 1997, we defined
the SPI-Block option. Without the overhead of multiple negotiations, a single
exchange could generate a list of many related SPIs.
You could send on several SPIs concurrently.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
