Re: [IPsec] Questions for draft-ponchon-ipsecme-anti-replay-subspaces

["Paul Ponchon (pponchon)" <[e-mail]>]

Hi Aseem,
Thanks for your questions.

1. Yes, you're correct there is still reordering potentially happening between the endpoints of the tunnel. However, the intention behind using the subspace is to limit the potential reordering of packets at the tunnel endpoints. By assigning packets to specific subspaces based on factors such as CPU core or QoS, the aim is to manage and mitigate the reordering within each subspace, thereby improving the utilisation of multiple cores and QoS classes at the endpoint. The reordering happening in between the endpoint is less easily controllable and just like with using an SA today, would be handled by the replay window of each subspaces but they don’t need to be very big.

2. At the moment, we are leaning towards not splitting the subspace for CPU and QoS, as this could introduce unnecessary complexity and overhead in maintaining and managing unused subspaces. We however don’t impose any constraint on how to use the subspace IDs as long as they are between 0 and <max negotiated subspaces> - 1. We are actively exploring the best approach to distributing the subspaces between sender and receiver. Any insights or suggestions from the community on this matter would be highly appreciated.

3. While we haven't implemented this solution with strongSwan, we are currently working on an implementation for the IPsec stack of VPP. We have updated the latest version of the draft to reflect what we found during the implementation. While the main focus remains on defining a proper way to distribute subspaces to maximise the performance and compatibility aspects in the open-source implementation.

Thank you for your feedback and questions. We appreciate your interest and welcome any additional input or insights you may have.
Paul

Aseem Choudhary <[e-mail]> writes:

Hello Authors,

Thanks for writing the document. It is good work!

Few questions:


1.       Looks like packet mapping to subspaces either for the CPU core or QoS or combination is tunnel source local decision. Since packet along the path can be marked/remarked reclassified, mapped to different queues, reordering is still possible.

2.       Since subspace is 16 bit, any plan/suggestion favor/against to split space for CPU and QoS?

3.       Any implementation experience/plan with  strongSwan?

-thanks,
Aseem