Re: [IPsec] IPR confirmations for draft-ietf-ipsecme-multi-sa-performance
Hi Tero, On Thu, Mar 14, 2024 at 19:54:56 +0200, Tero Kivinen wrote: > Are any authors of the draft-ietf-ipsecme-multi-sa-performance (or > anybody else) aware of any IPRs related to this draft? No, I'm not aware of any related IPR. > > Are authors willing to be listed as authors? Yes. I am willing to be listed as an author. thanks, -antony > > I will require response from author, and also updated version of the > draft based on my review comments, before I will hit publication > requested. > -- > kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-00.txt
On Wed, Jan 10, 2024 at 05:07:55PM +0100, Jen Linkova wrote: > Hello, > > Jen here, a new co-author of this undoubtedly useful draft. > I'm working on addressing comments received after -00 was submitted, > and I have a question.. Thanks, Jen. I'm glad to seee this ID will be updatead soon, before it expire this month! > Antony Antony wrote: > > >> If we want to implement Antony's suggestion of doing this ping on real ESP > >> sessions as well, then that would require the ping packet to be valid ESP, > >> i.e., properly encrypted, with valid padding and next header fields. In > >> that case, maybe we can use Next Header 59 per RFC 4303 section 2.6? > > >Here is a proposed text for the I-D. > > >"Upon completing an IKE negotiation, an IPsec peer wishing to ascertain the > >viability of the path for ESP packets MAY initiate an ESP Echo Request > >packet to the other peer. The ESP Echo Request packet MAY be encrypted. If > >encrypted, it SHOULD utilize an SPI value previously negotiated through IKE > >and set the Next Header value to 59 (No Next Header). The receiving IPsec > >peer, having established ESP through IKE, MAY issue an ESP Echo Response. > >When replying to an encrypted ESP Echo Request, the ESP Echo Response MUST > >be encrypted and utilize the corresponding negotiated SPI." > > As I'm not really an IPSec expert, I'm not sure I understand how it would > work. > Let's say a device A sends an ESP echo request packet using an > existing negotiated SPI. > Then it receives an ESP packet back, and that packet uses the > negotiated SPI and has the next header set to no next header. > How would that device A differentiate between: > - an Echo Reply sent in response to its Echo request; > - an Echo Request sent by the peer independently; > - just some garbage (or shall the device assume that any packet with > next header = 59 is a valid ESP ping packet? For a basic use case, any response would suffice. The essential requirement is the ability to send a request and receive a response from the IPsec peer, which is why I proposed the minimal solution to begin with. However, following several discussions and [1] , there's interest in developing a more generic approach. I am hopping the Internet Draft would define a more detailed payload, similar to how ICMP defines packet payload in RFC 792. > In the original proposal it was clear, as the reserved SPI values were > used. > Am I missing anything? For a minimal use case it may work; however, for more generic use cases, such as sending multiple requests simultaneously from multiple applications, would it work? How would ESP Ping responses correlate to multiple instances sending ESP Ping from a sender? I feel the document might need to define a specific payload format. This format would help us correlate responses with their respective requests, the ESP ping ID and sequnce number proposed in [1] Proposal to add ID , seq. https://mailarchive.ietf.org/arch/search/?q=%22draft-colitti-ipsecme-esp-ping%22 Also the SAs are unidiectional and posisbly there would be multiple SAs same direction too. I just saw a response from Michael brinigin up similar point . Let's start with defining a simple message format to gain hands-on experience of ESP Ping. Based on our learnings, we can then detail out the ESP echo message. This approach aligns with our discussions at the last IPsec workshop on generic ESP socket, and ping message implementation for Linux. I noticed the initial draft created a lot of interest and I feel There is clear interest in pinging specific SAs usin encrypted ESP ping. However, I/we currently lack the practical experience to fully define IPsec ping message format. I am hopping we can comeup with minimal spec. regards, -antony ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Why ipsecme-anti-replay-subspaces is needed.
On Thu, Dec 07, 2023 at 06:47:35PM -0500, Paul Wouters wrote: > On Thu, 7 Dec 2023, Michael Rossberg wrote: > > > > > I would actually like to refrain from writing 2 * 1.024 keys from the > > > > control > > > > plane to the data plane, just because a single IKE SA rekeyed... > > > > > > If you rekey the IKE SA, there is no change to the Child SA's. The new > > > IKE SA inherits the existing Child SAs. So no 2 * 1024 new keys. > > > > May be I did not use the correct terms, but if I want to have PFS, I’d still > > need reestablish all of these 2048 keys. > > No. PFS means that if you are compromised now, your keys from the past > cannot be calculated. This assumes those keys are also no longer in > memory. A typical way of multiple child SA with PFS is: > > T=00:00 Establish IKE SA with 1st Child SA (lifetime 1h for IKE SA, 8h for > Child SA) > T=00:01 Establish 2nd Child SA using DH (lifetime 8h) > T=01:00 Rekey IKE SA > T=02:00 Rekey IKE SA > [...] > T=08:00 Rekey Child SAs with DHs > > What we are saying is do this: > > T=00:00 Establish IKE SA with 1st Child SA (lifetime 1h for IKE SA, 8h for > Child SA) > T=00:01 Establish 2nd Child SA using DH (lifetime 8h) > T=01:00 Rekey IKE SA > T=02:00 Rekey IKE SA > [...] > T=07:00 Rekey IKE SA > T=08:00 Rekey all Child SAs without DH > T=08:01 Rekey IKE SA > > At this point all these Child SAs gained PFS because the old IKE SA and > its KEYMAT are no longer in memory and a compromise now could not > recalculate the Child SAs anymore. Has anyone implemented this yet? This concept sounds intriguing; however, I am afraid interoperating various combinations of PFS could become complex to configure as an admin. Often, we end up creating a new protocol instead of discussing implemenation details. I herd this idea before, a few times at IETF, and wonder if CFRG would agree what is written here. It might worth clarifing with crypto people may be write it down. > > This may happen using > > CREATE_CHILD_SA messages or reestablishing the IKE-SA altogether > > (Reauthentication in strongSwan slang). With a 1000 peers, I’d had to > > write 2 million keys instead of 2000 every reauth period and such operations > > tend to be not uniformly distributed. > > Re-authentication is not rekeying! See > https://datatracker.ietf.org/doc/html/rfc7296#section-2.8.3 > >IKEv2 does not have any special support for reauthentication. >Reauthentication is done by creating a new IKE SA from scratch (using >IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA Notify >payloads), creating new Child SAs within the new IKE SA (without >REKEY_SA Notify payloads), and finally deleting the old IKE SA (which >deletes the old Child SAs as well). > > re-auth in your case causes 10k new child SAs (or 2x or 64x that if you > would do multi-sa of some kind). > > However, if you do 10k+ Child SAs, you should not do a DH for each of > those ever. You should use: > > T=00:00 Establish IKE SA with 1st Child SA (lifetime 1h for IKE SA, 8h for > Child SA) > T=00:01 Establish 10k Child SA WITHOUT using DH (lifetime 8h) > T=00:02 Rekey IKE SA > > This costs 2 DH exchanged independent on the number of Child SAs, while > keeping PFS for all Child SAs. > > > > I guess I'm insure how you would deal with QoS related issues when you > > > have two cores, but one uplink bandwidth. How would the cores not stomp on > > > each other? It seems you need to synchronise things on the client router > > > onto a single entity that determines which packet goes out first to keep > > > the stream complying with QoS settings. > > > > Ensuring QoS policies is not the task of the IPsec encryption. In our case > > it > > either happens using an external router or by using hardware offloads of > > the black NIC. However, I also know cases where shaping does not happen > > at all and DSCP fields are just mapped to different hardware queues. > > As QoS is not critical from a confidentiality perspective, it is much easier > > to realize in untrustworthy hardware (and without CPU coordination). > > Whatever subsystem is doing this, if there are multiple CPUs it has to > know how many packets are in all CPUs network queues to coordinate > proper QoS, or else CPU 1 with a queue of priority traffic, and CPU 2 > with a queue of bulk unimportant traffic would both send traffic? > > Anyway, whether 2 or 64 Child SAs, I don't think it matters much, > because the number of Child SAs is unrelated to the number of DHs > you need to do. > > Paul > > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Why ipsecme-anti-replay-subspaces is needed.
On Thu, Dec 07, 2023 at 04:43:44PM +0100, Michael Rossberg wrote: > Hi Paul, > > >> My understanding is that when PFS is enabled, the first CHILD_SA leverages > >> the IKE SA key, but any further CREATE_CHILD_SA (which is the case when > >> setting up more “sub-SAs”) would use separate keys. > >> >From RFC5996: > >> Although ESP and AH do not directly include a Diffie-Hellman > >> exchange, a Diffie-Hellman group MAY be negotiated for the Child SA. > >> This allows the peers to employ Diffie-Hellman in the CREATE_CHILD_SA > >> exchange, providing perfect forward secrecy for the generated Child > >> SA keys. > > > > PFS comes from the back that if the IKE peer is compromised, you cannot > > copy and use the KEYMAT from which the Child SAs were derived. So yes, > > using a DH per Child seperates that from the IKE SA DH. But the exact > > same is achieved if you derive 1000 Child SAs from the IKE SA KEYMAT > > and then rekey the IKE SA for a new KEYMAT where you wipe the old KEYMAT > > from memory. Now if your IKE SA is compromised, the old KEYMAT is not > > there and so there is no way to recreate the CHILD SA keys. > > > > In short: IKE SA -> many Child SA's -> IKE SA REKEY gives you PFS for all > > Child SAs. > > >> With 10k peers, we would have more than 2 cores. On top of which we > >> also want to use subpaces to avoid re-ordering issues over multiple > >> traffic-engineered paths (MPLS, QoS, uplinks, etc…). > >> That’s how we got to the number of 64+ subspaces for a single tunnel. > > > > I wonder if this works at all in practise. > > Just fine. Pierre is here a little conservative with his setting. We have a > different setting with 1.024 Sub-SAs as of today… > I would actually like to refrain from writing 2 * 1.024 keys from the control > plane to the data plane, just because a single IKE SA rekeyed... > > Any reasons to strengthen your believe? I percive a few hidden implementation details here. Those hound me when thinking about large number of SubSAs. Yes, you can create 1024 SubSAs! In the context of typical x86 implementations, when dealing with, let's say, 1024 Sub SAs all using the same key, I'm curious about how many copies of the key you need for high performance on multi core CPU? Specifically, I wonder if all CPUs would share the same key from a single memory location. My limited understanding is that you may need a local copy on each CPU to mitigate potential data cache misses and performance penalties. When there is a significant difference in the number of SubSAs and the number of CPUs, keeping a copy of the key per CPU would appear excessivea. How would sub-space sequence number implement replay protection for each sub-space? I'm wondering about the complexity of such an implementation! When you have 1024 SubSAs, are you keeping track of 1024 replay windows separately? How do you enforce a byte or packet limit per SA? How do you obtain a global byte and packet counter from 1024 SubSAs? I feel there are many implementation details to consider for high performance. Would typical commands like "ip xfrm state" show the byte and packet count across all SubSAs? ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-antony-ipsecme-beet-mode-00.txt
Thanks, Bob, for pointing this out! I overlooked the Appendix where BEET mode was defined, so I really appreciate the heads-up. I noticed we still need to get an IKEv2 notifier to use BEET mode with IKEv2. This draft will focus on that and refer to RFC 7402 for the BEET mode ESP protocol specifications. -antony On Mon, Nov 06, 2023 at 05:45:44AM -0500, Robert Moskowitz wrote: > I should point out that BEET mode is defined in > > rfc 7402 > > This is the basis for the BEET code in the Linux kernel. > > It should incorporate everything in Pekka's older drafts. > > Note that I am a co-author of 7402, but the Ericsson team did all the heavy > lifting. > > As defined in 7402 it is used in a few products. Some implementations, I > have been told, are in US military use. > > Bob > > On 10/27/23 06:17, Antony Antony wrote: > > Hi, > > > > We've submitted a draft proposal to revive and standardize IPsec BEET mode, > > which is widely used but had its previous ID expire in 2009. This proposal > > also includes a suggestion for introducing IKE Notification for negotiation > > purposes. > > > > We'd appreciate your feedback on this ID. If you're aware of any more use > > cases for BEET mode, please share them. I would like to add a few more to > > the ID. The original ID emphasized mobility as use case, and we're > > considering whether to keep those aspects in the new proposal. If you use or > > likely to use BEET mode with mobility please share your thoughts. > > > > I'll be discussing these points at the upcoming IETF 118 meeting in Prague. > > > > -antony > > > > > > On Mon, Oct 23, 2023 at 09:08:05AM -0700, internet-dra...@ietf.org wrote: > > > Internet-Draft draft-antony-ipsecme-beet-mode-00.txt is now available. > > > > > > Title: A Bound End-to-End Tunnel (BEET) mode for ESP > > > Authors: Antony Antony > > > Steffen Klassert > > > Name:draft-antony-ipsecme-beet-mode-00.txt > > > Pages: 21 > > > Dates: 2023-10-23 > > > > > > Abstract: > > > > > > This document specifies a new mode for IPsec ESP, known as Bound End- > > > to-End Tunnel (BEET) mode. This mode complements the existing ESP > > > tunnel and transport modes, while enhancing end-to-end IPsec usage. > > > It offers the characteristics of the tunnel mode but without its > > > usual overhead. The BEET mode is designed to accommodate evolving > > > applications of ESP, such as minimalist end-to-end tunnel, mobility > > > and multi-address multi-homing. Additionally, this document proposes > > > a new Notify Message, USE_BEET_MODE, for the Internet Key Exchange > > > Protocol Version 2 (IKEv2) specified in [RFC7296], to facilitate BEET > > > mode Security Association negotiation. > > > > > > The IETF datatracker status page for this Internet-Draft is: > > > https://datatracker.ietf.org/doc/draft-antony-ipsecme-beet-mode/ > > > > > > There is also an HTML version available at: > > > https://www.ietf.org/archive/id/draft-antony-ipsecme-beet-mode-00.html > > > > > > Internet-Drafts are also available by rsync at: > > > rsync.ietf.org::internet-drafts > > > > > > > > ___ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-antony-ipsecme-beet-mode-00.txt
Hi, We've submitted a draft proposal to revive and standardize IPsec BEET mode, which is widely used but had its previous ID expire in 2009. This proposal also includes a suggestion for introducing IKE Notification for negotiation purposes. We'd appreciate your feedback on this ID. If you're aware of any more use cases for BEET mode, please share them. I would like to add a few more to the ID. The original ID emphasized mobility as use case, and we're considering whether to keep those aspects in the new proposal. If you use or likely to use BEET mode with mobility please share your thoughts. I'll be discussing these points at the upcoming IETF 118 meeting in Prague. -antony On Mon, Oct 23, 2023 at 09:08:05AM -0700, internet-dra...@ietf.org wrote: > Internet-Draft draft-antony-ipsecme-beet-mode-00.txt is now available. > >Title: A Bound End-to-End Tunnel (BEET) mode for ESP > Authors: Antony Antony > Steffen Klassert >Name:draft-antony-ipsecme-beet-mode-00.txt >Pages: 21 >Dates: 2023-10-23 > > Abstract: > >This document specifies a new mode for IPsec ESP, known as Bound End- >to-End Tunnel (BEET) mode. This mode complements the existing ESP >tunnel and transport modes, while enhancing end-to-end IPsec usage. >It offers the characteristics of the tunnel mode but without its >usual overhead. The BEET mode is designed to accommodate evolving >applications of ESP, such as minimalist end-to-end tunnel, mobility >and multi-address multi-homing. Additionally, this document proposes >a new Notify Message, USE_BEET_MODE, for the Internet Key Exchange >Protocol Version 2 (IKEv2) specified in [RFC7296], to facilitate BEET >mode Security Association negotiation. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-antony-ipsecme-beet-mode/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-antony-ipsecme-beet-mode-00.html > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-00.txt
On Fri, Jul 28, 2023 at 01:01:39PM -0700, Lorenzo Colitti wrote: > On Fri, Jul 28, 2023 at 11:36 AM Tero Kivinen wrote: > > > Sequence number is just 32-bit sequence number (always present, can > > be used when correlating request to response). > > > > Antony yesterday suggested to me that some stateful firewalls/middleboxes > might be happier if these numbers started from 1 and counted upwards. I'm > not sure if this is possible though - the first time you run the esping (or > espping?) binary it can send packets 1, 2, 3, ...42, but the second time > you run it, how will it know that it needs to start with 42? > > By comparison, ping uses both an ID and a sequence number, and the sequence > number is scoped to a particular ID. We could do something like this by > deciding that the first 16 bits of the ESP sequence number are the ID and > the bottom 16 bits are the sequence number. > > Payload data/padding is can be any length in reqeust and is always > > copied in response, i.e., it can be used as nonce/cookie to make sure > > nobody out side the path can fake responses. > > > > There would not be padding or next header fields, and the ICV field > > would be zero length. > > > > SGTM. Hopefully middleboxes won't be too unfriendly to this. Generally I > would assume that when a middlebox looks at ESP packets, other than the > sequence number, it's not going to look into the payload because it will > assume it's encrypted. > > If we want to implement Antony's suggestion of doing this ping on real ESP > sessions as well, then that would require the ping packet to be valid ESP, > i.e., properly encrypted, with valid padding and next header fields. In > that case, maybe we can use Next Header 59 per RFC 4303 section 2.6? Here is a proposed text for the I-D. "Upon completing an IKE negotiation, an IPsec peer wishing to ascertain the viability of the path for ESP packets MAY initiate an ESP Echo Request packet to the other peer. The ESP Echo Request packet MAY be encrypted. If encrypted, it SHOULD utilize an SPI value previously negotiated through IKE and set the Next Header value to 59 (No Next Header). The receiving IPsec peer, having established ESP through IKE, MAY issue an ESP Echo Response. When replying to an encrypted ESP Echo Request, the ESP Echo Response MUST be encrypted and utilize the corresponding negotiated SPI." Feel free to adopt the text as you see fit. I have also attached it as xml for your convenience. -antony draft-colitti-ipsecme-esp-ping-00.xml Description: XML document IP Security Maintenance and ExtensionsL. Colitti Internet-DraftGoogle Intended status: Standards Track6 September 2023 Expires: 9 March 2024 ESP Echo Protocol draft-colitti-ipsecme-esp-ping-00 Abstract This document defines an ESP echo function which can be used to detect whether a given network path supports IPv6 ESP packets. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 9 March 2024. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Colitti Expires 9 March 2024 [Page 1] Internet-Draft esp-ping September 2023 Table of Contents 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 2. Problem statement . . . . . . . . . . . . . . . . . . . . . . 2 3. Protocol Specification . . . . . . . . . . . . . . . . . . . 3 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 6.
Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-00.txt
On Tue, Jul 25, 2023 at 07:06:47PM -0700, Lorenzo Colitti wrote: > Dear ipsec WG, > > When working on a VPN implementation we found that it's very difficult to > rely on IPv6 ESP packets because many networks drop them, so even if IKE > negotiation succeeds, the data plane might be broken. Worse, this can > happen on migrate, blackholing an existing session until the problem is > detected and fixed with another migration. > > In many cases, I think a simple "pre-flight check" to see if ESP is > supported on a given network path could solve this problem. So after a few > conversations with folks here I put together this draft. It provides the > equivalent of an ESP ping packet. Comments and feedback appreciated. Thanks Lorenzo for this ID. I believe this is a great idea. Perhaps we could consider allowing a non-zero ESP payload size? This would facilitate correlating responses upon arrival at the sender. Then I would add an ESP message, format similar to ICMP message. For instance, incorporating an identifier, like ICMP ping has, would enable initiating multiple ESP pings from the same client and receiving corresponding responses without mixing them up. We could utilize common denominator payloads resembling ICMP and ICMPv6 ECHO and ECHO responses, as defined in rfc4443#section-4.1 and rfc792. And may be add a couple ESP specific values, especially for encrypted message use case proposed bellow. Additionally, it would be advantageous to support ESP Ping using encrypted ESP messages too. This would be especially useful to send ESP pings from an IPsec gateway that may or may not have an IP address from the tunnel range negotiated by it. The encrypted ESP Ping would allow us to verify if the full path is functional. I've encountered several cases where IKE gets established, but ESP is filtered. In such situations, beside the pre-flight check having encrypted ESP ping functionality would be invaluable. However, for encrypted messages, we may need specify additional payloads, such as SPI and ESP sequence number, for both sending and receiving. > https://datatracker.ietf.org/doc/draft-colitti-ipsecme-esp-ping/ -antony ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IPsecME WG Adoption call for draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt
I have read draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt. I support adoption of the document and its publication. -antony On Wed, Nov 09, 2022 at 07:39:42PM +0200, Tero Kivinen wrote: > This is two week working roup adoption call for he > draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt. If you support > adoption of this document to the IPsecME WG send email to the list > before the 2022-11-24. > > Note, that this is starting point for the document, so if you have any > comments send them to list also. > > This should be part of our charter section call us to work better on > constrained networks: > > A growing number of use cases for constrained networks - but not > limited to those networks - have shown interest in reducing ESP (resp. > IKEv2) overhead by compressing ESP (resp IKEv2) fields. The WG will > define extensions of ESP and IKEv2 to enable ESP header compression. > -- > kivi...@iki.fi > > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
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 +, 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-dra...@ietf.org > Date: Monday, 24 October 2022 at 16:50 > To: Guillaume Solignac (gsoligna) , Mohsin Shaikh > (mohsisha) , Paul Ponchon (pponchon) > , Pierre Pfister (ppfister) > 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 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Comments on draft-pwouters-multi-sa-performance
Hi Paul, Let me try once more to explain how to use draft-pwouters-multi-sa-performance for load balancing paths. At the moment, the draft and Linux XFRM code only cover per CPU queuing. So forget the CPU use case for now! Let’s focus on network path diversity. Just like you said, the IPsec peers must be configured with the number of paths. Let’s say there are 4 paths. Configure that in the IKE daemon. IKE daemon will add 4 paths to the policy, SP. The IKE initiator will send perPath Child SAs, 4(4 + 1 the fallback SA). And negotiate 4 perPath Child SA. IKE initiator should force UDP encapsulation for the load balancing switches to work. First the IKE initiator setup a Fallback SA. The fallback SA will be using UDP port 4500 to 4500, with an additional attribute 4 perPath SAs. The data plane, SAD, will hash the clear text traffic using ntuple. The clear text ntuple for TCP and UDP are using source IP + source port + destination IP + destination port. All other traffic, think of ICMP..., hash using source IP + destination IP. This hashing is an example. Any other hash based on clear text flows to choose IPsec SA paths would work too. When traffic arrives, IPsec gateway compute the hash. If there is no SA for that hash index, use the Fallback SA and send a SADB_ACQUIE to IKE daemon. IKE daemon will negotiate a new perPath SA for that index. Once a perPath SA is installed, the traffic will use that SA. The perPath SA use UDP encapsulation, a unique src port + destination port. The IKE initiator initiates with source port other than 4500, and the IKE responder should respond to the new source port(and not to port 4500) Since the perPath SA has different UDP source port + destination port the switches or load balancers should find enough entropy. Can the load balancers forward the IPsec traffic via different paths based 4 tuple? When rekeying keep the same source port + destination port. This will also support NATs and also sending DPD using per Path SA UDP ports, using NON-ESP-UDP encapsulation. I can imagine you feel this solution is complex, and changes to IKE negotiations, however, I think the result is more flexible and clean design. The UDP flows behave as symmetric UDP flow. It is friendly to RSS as well. Thanks for your feedback. I hope, I didn't waste your time with another long e-mail:) Cheers, -antony On Mon, Nov 15, 2021 at 08:10:25PM +, Bottorff, Paul wrote: > Hi Antony: > > Per path SA is completely inadequate for load balanced systems especially > within the data center. Load balanced systems are being used to separate mice > from elephant flows and to dynamically re-arrange flows on paths based on > load measures. The number of flows on any particular path is selected by the > network and may change both hop-by-hop and on the fly. For the network to > operate properly we want to identify every flow allowing the network to > allocate those flow to paths. For load balance to work properly we need many > more flows than paths. Current data center encapsulations support these > operations by loading the source port with a flow identifier. Saying that > IPsec will provide an inferior and cumbersome solution becomes a barrier to a > wider deployment of IPsec in these environments. > > Even for cases where the network is doing simple hash distribution switches > don't normally distribute based on SPI, instead they typically identify flows > based on the outer 5-tuple. Some of the switches could parse the IPsec > packets and build a special hash for them, however some of the switches some > of the time is not a satisfying solution. Identifying the flow in source port > is a perfect solution since it works for all the switches all the time, > supports all the advanced modes of load balancing, and is an already well > established technique. > > Further the server interfaces where IKE would run don't know how many paths > exist deep in the network and so don't know how to build for particular > paths. If SA was used the only reasonable solution is to build and SA per > flow (not per path) which is information available to IKE. There are many > flows for each CPU. > > Cheers, > > Paul > > -Original Message- > From: Antony Antony [mailto:antony.ant...@secunet.com] > Sent: Wednesday, November 10, 2021 12:11 AM > To: Bottorff, Paul > Cc: Paul Wouters ; Panwei (William) > ; ipsec@ietf.org; > draft-pwouters-ipsecme-multi-sa-performa...@ietf.org > Subject: Re: [IPsec] Comments on draft-pwouters-multi-sa-performance > > Hi Paul, > > I think our draft is a better solution for the network multipath problem too, > definitely for a few per Path SAs. Larger number of paths, say 32 or more > paths, may cause scaling issues in SPD or/and SAD lookup; the data path > lookup. However, data pat
Re: [IPsec] Comments on draft-pwouters-multi-sa-performance
Hi Paul, I think our draft is a better solution for the network multipath problem too, definitely for a few per Path SAs. Larger number of paths, say 32 or more paths, may cause scaling issues in SPD or/and SAD lookup; the data path lookup. However, data path lookup speed would depend on the implementation. Creating a SA per path would decrease chance out of order delivery, ESP sequence number issues will be minimal. To create per path SA the IKE negotiations would be like the current draft, perCPU. The SAD/SPD lookup code path will differ from the prototype code we have for Linux/XFRM. The multi path will be a property of SPD. Use the multip path attribute to lookup in SAD. Each SA can be created dynamically based on traffic; actually path. First, create the Fallback SA and install the policy with the new flag, perPath SADB_ACQUIRE flag. And when there is traffic and no SA matching packet's path, the policy should trigger an SADB_ACQUIRE and IKE negotiation follows. After a successful IKE negotiation install the new per Path SA. While IKE negotiates the path SA, use the Fallback SA. So there won’t be any packet drop. I am working on a draft, how to deal with UDP encapsulation. Each SA with a different UDP port. My idea is to make UDP encapsulated IPsec SA a pair of SAs. IKE negotiator will choose source port. In one direction source port will change and in the other direction destination port will change, based on path entropy. This solution is generic and will work with the common NAT gateways. With a limitation, IKE peer which is not behind NAT must initiate new SA. RSS/ntuple would use UDP source port plus destination port for entropy. Would this work for network switches/routers along the path? My guess it will! Are you seeing out of order delivery because ESP packets take of multiple paths or at the sender? I noticed multiple CPU ESP sender can send the packets out of order. I think if you install an SA per path, out-of-order issues due paths will be resolved. There may be corner cases when there are multiple CPUs and multiple paths. In those cases, you may need CPU x paths SAs. CPU x Paths SAs will add lookup complexity. Out of order sending and delivery seems to be a problem with multiple CPUs on the sender. Even with IPsec offload NICs in Linux out of order sending could be an issue. Using per-CPU would reduce it considerably. On Wed, Nov 10, 2021 at 08:32:13AM +0100, Antony Antony wrote: > Hi Paul, > > I think our draft is a better solution for the network multipath problem, > definitely for small number of per Path SAs. Larger number of paths, say 16 > or more paths, may cause scaling issues in SPD or/and SAD lookup; the data > path. However, data path lookup speed would depend on the implementation. > Creating an SA per path would increase chance in order delivery, ESP sequence > number issues will be minimal. > > To create per path SA the IKE negotiations would be similar to current draft, > perCPU. The SAD/SPD code path will be different from the prototype we have > for Linux/XFRM. The path will be a property of SPD. When looking up SAD use > the path attribute and the correct SA will be used. > > Each SA can be created dynamically if and when necessary. First create > the Fallback SA and install the policy with new flag, per-Path SADB_ACQUIRE > flag. > And when there is traffic and no SA matching per path SAD entry, the > policy should trigger IKE negotiations and install a new per Path SA. > While per path SA is negotiated use the Fallback SA. So there won't be > any packet drop. > > I am working a draft, how to deal with UDP encapsulation. Each SA with > different UDP port. > My idea is make UDP encapsulated IPsec SA a pair of SAs. In one direction > source port will change and in the other direction destination port will > change based on path entropy. This solution is generic and will work with the > common NAT gateways too. > RSS/ntuple would use source port plus destination port for entropy. > Would this work for network switches/routers along the path? > > Are you seeing out of order delivery because ESP packets take of multiple > paths or multiple CPUs on the ESP sender? > I think if you install an SA per path, out of order issues due to path > will mostly solved. There may be corner cases when there are multiple CPUs > and multiple paths. In those cases you may need CPU x paths SAs. > CPU x Paths SAs will add lookup complexity. I have no operational experience > yet. > Out of order delivery/sending seems to be a problem when there are multiple > CPUs on the sender. Even when using IPsec offload NICs in Linux. Using > per-CPU would reduce it considerably. > > > -antony > > On Fri, Nov 05, 2021 at 21:39:05 +, Bottorff, Paul wrote: > > Hi Paul: > > >
Re: [IPsec] FW: I-D Action: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-04.txt
Hi, I am happy to see this draft progressing. I am wonder why allow changes once both sides agreed to minimal rekey? The draft currently allow changes to cryptographic suite and TS even when MINIMAL_REKEY_SUPPORTED is negotiated. While this is a more inclusive and flexible approach, I feel it increase chance of interruption when the responder send NO_PROPOSAL_CHOSEN response and initiator does not support changing parameters. Also if the initiator send a rekey with changes and the responder only support MINIMAL_REKEY_SUPPORTED rekey will not be smooth. Such issues are hard to debug because, it only show up when rekeying not when establishing IKE or Child SA. I prefer decide at the beginning to allow changes during rekey or not. My proposal is once both sides negotiated MINIMAL_REKEY_SUPPORTED no changes should be allowed during a rekey, in case of both the IKE SA and the Child SA. Rekey should be a simple refreshing the keying materials and nothing else. If you make this change, you can remove the notifiers *UNCHANGED and also remove section. '3.2.2. Rekeying IKE SAs When Responder's Cryptographic Suites Changed' regards, -antony On Wed, Apr 21, 2021 at 08:11:14 +, Panwei (William) wrote: > Hi Chairs, folks, > > I've updated a new version of draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt. > It's not a big update. I've received many good comments online/offline > before. I tried to address some of them, and there are still several comments > under consideration. > > This draft tries to optimize the unnecessary payloads at the time of rekeying > IKE SAs and Child SAs. If there is no changes of configuration on the peers, > they usually reuse the same crypto suites when rekeying the IKE SAs and Child > SAs, so the SA and TS payloads will remain the same as the ones of last > rekeying. Therefore, the SA and TS payloads can be omitted at such condition. > This optimization can save the bandwidth and power consumption. > > This draft was presented at IETF105 and IETF106, and received many good > comments and supports. Paul also presented this topic at IETF110 (many thanks > to Paul) and mentioned that he wanted to implement it. After IETF110, Meiling > Chen from China Mobile contacted to me privately, she believes this draft is > valuable and can be used by them, thanks to her support and help of editing > the draft. > > To chairs: I feel many people are interested in this work and I wonder > whether I can ask for an adoption call for this draft? > To folks: any comments or feedbacks are very welcome. > > Regards & Thanks! > Wei Pan > > > -Original Message- > > From: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] On Behalf > > Of internet-dra...@ietf.org > > Sent: Wednesday, April 21, 2021 2:34 PM > > To: i-d-annou...@ietf.org > > Subject: I-D Action: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-04.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : IKEv2 Optional SA Payloads in Child > > Exchange > > Authors : Sandeep Kampati > > Wei Pan > > Meduri S S Bharath > > Meiling Chen > > Filename: > > draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-04.txt > > Pages : 13 > > Date: 2021-04-20 > > > > Abstract: > >This document describes a method for reducing the size of the > >Internet Key Exchange version 2 (IKEv2) exchanges at time of rekeying > >IKE SAs and Child SAs by removing or making optional of SA & TS > >payloads. Reducing size of IKEv2 exchanges is desirable for low > >power consumption battery powered devices. It also helps to avoid IP > >fragmentation of IKEv2 messages. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-kampati-ipsecme-ikev2-sa-ts-payloa > > ds-opt/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt > > -04 > > https://datatracker.ietf.org/doc/html/draft-kampati-ipsecme-ikev2-sa-ts-p > > ayloads-opt-04 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-kampati-ipsecme-ikev2-sa-ts-paylo > > ads-opt-04 > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at > > tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > ___ > > I-D-Announce mailing list > > i-d-annou...@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >
Re: [IPsec] draft-xu-ipsecme-esp-in-udp-lb-07
On Wed, Mar 31, 2021 at 23:38:01 +, Bottorff, Paul wrote: > Hi Antony: > > Below, > > Cheers, > > Paul > > > > -Original Message- > From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Antony Antony > Sent: Wednesday, March 31, 2021 3:32 AM > To: Bottorff, Paul ; IPsec > Cc: antony.ant...@secunet.com > Subject: Re: [IPsec] draft-xu-ipsecme-esp-in-udp-lb-07 > > Hi, > > This is an interesting draft. I would love to see a generic solution for > network paths and receiver use cases, such as RSS. > > PB>> Can you explain your use case for RSS a little more? I'd guess you are > looking at LB around the RSS queues to get better distribution for the > decodes. > << We are using muliple SAs, with identical Traffic Selectors, to load balance IPsec traffic between IPsec peers. https://datatracker.ietf.org/doc/draft-pwouters-multi-sa-performance/ This should improve multi-core-cpu utilization and IPsec throughput. The receiver should distribute the flows, based on SPI, to different CPUs for decryption. Ideally the NIC should support a ntuple flow distribution using SPI. It is not yet widely supported, and also not compatible with older NICs. Now we are thinking of ESP in UDP with different source ports. Just like the draft proposed for ECMP and LAG. When implementing it I ran into issues with NAT and SAD remapping messages which update IKE. I am using strongSWAN for IKE and Linux XFRM for ESP. > The RFC3948 specifies one pair of UDP ports 4500-4500. > Both the IKE flow and the ESP in UDP flow should use the same UDP flow. > The draft seems to suggest new destination port and source ports are only for > ESP? How would this change work with IKE? > May you are not intending to use IKE? PB> Our use cases use IKE, however as stated in RFC3948 ESPinUDP does not have to be PB> tied to IKE, it is just advantageous to do so for the NAT case since this allows PB> a single mapping for both at the NAT rather than two mappings. PB> I've wondered why we could not use the RFC3948 encoding for ESPinUDP, but allow PB> the source port to be chosen differently than IKE. Perhaps Xu has some thoughts on this. In my experience it would work well when there is no NAT. When there there is NAT the IKE and ESP in UDP should use same ports, otherwise IKE will get established and ESP packets could get dropped in one direction. When there is NAT it would look more like a client-to-server than a peer-to-peer. > How would the new ESP flow work when there is a NAT gateway along the path? > I ran into issues with both sides choosing different source ports. > It would cause SADB mapping changes which force changes IKE flows. One coul > disable > SADB mapping changes. However, that would break real NAT changes. > PB> We are mostly interested in data centre use cases which don't have intervening NATs, PB> however I believe SD-WAN cases could have NAT and FW traversals between tunnel end PB> points. As it stands draft-xu-ipsecme-esp-in-udp-lb does not specify how the source port PB> value is determined. It seems like it could be based on a hash value within the ESP or PB> based on the SPI and IPs. I implemented a proof concept - UDP source port set to 16bit hash of out going SPI. Then it occurred to me the hash could collide with other well known UDP ports e.g. hash of an SPI or/and IP address could be 53(DNS). Some admins may not be happy to see source port 53 for ESP in UDP traffic. If you choose ephemeral source ports both sides should know the source ports otherwise SADB remap will be generated. If we disable that real NAT would break... So far I don't have a clean solution which would work with NAT and without NAT for our use case. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-xu-ipsecme-esp-in-udp-lb-07
Hi, This is an interesting draft. I would love to see a generic solution for network paths and receiver use cases, such as RSS. The RFC3948 specifies one pair of UDP ports 4500-4500. Both the IKE flow and the ESP in UDP flow should use the same UDP flow. The draft seems to suggest new destination port and source ports are only for ESP? How would this change work with IKE? May you are not intending to use IKE? How would the new ESP flow work when there is a NAT gateway along the path? I ran into issues with both sides choosing different source ports. It would cause SADB mapping changes which force changes IKE flows. One coul disable SADB mapping changes. However, that would break real NAT changes. Should both sides use the same source port? Or can each peer choose its own source port independently? If both have to use the same port how do peers negotiate on the ephemeral source port. I ran into issues with or without NAT. Or do you disable SADB mapping completely? When the source port is chosen independently the flow will be asymmetric. The NAT gateway drops the ESP flow in one direction. A typical NAT gateway only allows symmetric UDP flows. And this flow must be initiated from one side, the side behind the NAT. So, I wonder how changing the source port alone would work. regards, -antony On Fri, Mar 26, 2021 at 18:07:37 +, Bottorff, Paul wrote: >Hi Xu: > > >We’ve got a lot of interest in your draft. Are you going to move this >forward to a working group draft and RFC? We would be happy to help >where needed. > > >Cheers, > > >Paul Bottorff > >Aruba a Hewlett Packard Enterprise Company > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec On Fri, Mar 26, 2021 at 18:07:37 +, Bottorff, Paul wrote: >Hi Xu: > > >We’ve got a lot of interest in your draft. Are you going to move this >forward to a working group draft and RFC? We would be happy to help >where needed. > > >Cheers, > > >Paul Bottorff > >Aruba a Hewlett Packard Enterprise Company > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
