> On 7/24/20 2:28 PM, William Allen Simpson wrote: >> 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. > > Although there has been some pushback, have we agreed that instead of multiple > windows (however defined), a more general solution is multiple SPIs?
Sorry, I have not caught up with answering all mails yet. For each of the cases multicast, multicore & QoS there have been a lot of people arguing for such a solution. However, I still see the argument, that enabling all of these features will lead to a combinatorial explosion of SAs, which are brought up proactively, even though perhaps never used. Somehow associated SAs would perhaps allow us to derive/install a key locally on demand. However, due to the combinatorial explosion, these blocks of SAs may easily become pretty large, ie. with a reservation for multicast senders and QoS groups SPIs may be a little short. > Who is going to write the SPI block/group extension for IKEv2? I am afraid there are more things affected with such a way to go, e.g. g-ike. There are still other things uncovered: Explicit 64 bit sequence numbers, implicit IVs for group communication, the whole trailer discussion. All in all these changes make raise the complexity even further, a thing we tried to reduce by unifying things for the multi/unicast case. Allowing people to use the same dataplane configuration to encap L2 frames. > Would it be best to add to an existing draft already in the pipeline? I would volunteer to perhaps write things together in a longer argumentation over this fall.
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
