Re: [IPsec] FW: New Version Notification for draft-ponchon-ipsecme-anti-replay-subspaces-00.txt

Hi Paul,

This is an interesting draft. I feel there is room for this and  
pwouters-ipsecme-multi-sa-performance:)

How would a receiver, a NIC in a typical X86 scenario, steer IPsec packets 
to different CPUs? The document mentions the following text and I would like 
to read more details.

"On reception, the 5-tuple based packet steering would provide a
      decent level of load-balancing between threads, since different IP
      paths would use different 5-tuples."

What would be the 5 tuple to steer an ESP packet?

Would the sender use ESP in UDP? In that case would the different subspace 
send with different UDP port to get entropy for the NIC?

Would the ESP sequence number, the first 8 bits be used for steering the 
flow?

Another possibility I imagine is a hardware that decapsulate ESP and then 
use 5 tuple of the inner packet to steer to CPUs.

regards,
-antony

On Mon, Oct 24, 2022 at 02:56:47PM +0000, Paul Ponchon (pponchon) wrote:
> Hello ipsecme,
> 
> We would like to notify the list that we just published a new draft (ieft-draft-pponchon-ipsecme-anti-replay-subspaces) and would kindly ask for the opportunity to present it in London in person.
> 
> We (the authors of this draft) are currently involved in the performance optimization of an IPsec stack deployed in some large SD-WAN networks. We have been observing performance and scalability challenges related to anti-replay, and believe the working group could propose a solution.
> 
> We recently became aware that the working group was investigating similar issues in the multi-sa draft (draft-pwouters-ipsecme-multi-sa-performance-04). We are very enthusiastic about that work, but believe that we have additional requirements, as well as operational experience, which might challenge the currently proposed solution. To summarize: We do need anti-replay to scale to multiple cores (as detailed in the multi-sa draft), but we also need packets to be sent across multiple paths and multiple QoS policies.
> 
> These problems add-up in showing anti-replay limitations. And using more Child SA comes with a significant performance degradation. We believe that the anti-replay mechanism itself could be improved to support all these use-cases. And that's what this draft is about.
> 
> We would appreciate any feedback and, again, would love to have the opportunity to present that work in London.
> 
> Thanks,
> 
> Paul, Mohsin, Pierre and Guillaume.
> 
> From: internet-drafts@ietf.org <internet-drafts@ietf.org>
> Date: Monday, 24 October 2022 at 16:50
> To: Guillaume Solignac (gsoligna) <gsoligna@cisco.com>, Mohsin Shaikh (mohsisha) <mohsisha@cisco.com>, Paul Ponchon (pponchon) <pponchon@cisco.com>, Pierre Pfister (ppfister) <ppfister@cisco.com>
> Subject: New Version Notification for draft-ponchon-ipsecme-anti-replay-subspaces-00.txt
> 
> A new version of I-D, draft-ponchon-ipsecme-anti-replay-subspaces-00.txt
> has been successfully submitted by Paul Ponchon and posted to the
> IETF repository.
> 
> Name:           draft-ponchon-ipsecme-anti-replay-subspaces
> Revision:       00
> Title:          IPsec and IKE anti-replay sequence number subspaces for multi-path tunnels and multi-core processing
> Document date:  2022-10-24
> Group:          Individual Submission
> Pages:          11
> URL:            https://www.ietf.org/archive/id/draft-ponchon-ipsecme-anti-replay-subspaces-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-ponchon-ipsecme-anti-replay-subspaces/
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ponchon-ipsecme-anti-replay-subspaces
> 
> 
> Abstract:
>    This document discusses the challenges of running IPsec with anti-
>    replay in environments where packets may be re-ordered (e.g., when
>    sent over multiple IP paths, traffic-engineered paths and/or using
>    different QoS classes) as well as when processed on multiple cores.
>    Different approaches to solving this problem are discussed, and a new
>    solution based on splitting the anti-replay sequence number space
>    into multiple different sequencing subspaces is proposed.  Since this
>    solution requires support on both parties, an IKE extension is
>    proposed in order to negotiate the use of the Anti-Replay sequence
>    number subspaces.
> 
> 
> 
> 
> The IETF Secretariat
> 

> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec