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

[Aseem Choudhary <[e-mail]>]

Hi Paul,

Further to this discussion, section 4.2 “Sender Behavior” doesn’t talk about how subspace ID will be calculated. Like, for QoS, how a unique subspace-id can be mapped to a queue-id with some of QoS pipeline (classification, shaping etc) procedures. I think section 4.2 should describe it a bit. But, if not in section 4.2, can it be described in section 6 and for the Implementation, in some more details in section 6.2?
For some of the QoS solutions (like local video CAC<https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k-r6-4/qos/configuration/guide/b-qos-cg-asr9000-64x/b-qos-cg-asr9000-64x_chapter_01010.html> with redirect), queue may be selected based on availability of bandwidth.


Also, section 4.6 talks about per-QoS-queue, per-path and per-core but section 6 only mention multi-path and multi-core.

Describing more on QoS behavior will certainly help.



-thanks,

Aseem


From: Aseem Choudhary <[e-mail]>
Date: Monday, August 14, 2023 at 10:55 AM
To: Paul Ponchon (pponchon) <[e-mail]>, [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: Questions for draft-ponchon-ipsecme-anti-replay-subspaces
Thanks Paul, appreciate your response!

From: Paul Ponchon (pponchon) <[e-mail]>
Date: Monday, August 14, 2023 at 10:00 AM
To: Aseem Choudhary <[e-mail]>, [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: Questions for draft-ponchon-ipsecme-anti-replay-subspaces

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