[IPsec] AD Review of draft-ietf-ipsecme-multi-sa-performance-05
Hi I performed an AD review of draft-ietf-ipsecme-multi-sa-performance-05. I have a mostly editorial feedback below: ** Abstract. Editorial. s/crypto/cryptography/ ** Section 1. Most IPsec implementations are currently limited to using one queue or CPU resource for a Child SA. -- (Editorial) What kind of queue? Should it be “network queues”? -- Why couldn’t implementations be changed to use multiple CPUs? ** Section 1. Editorial. An unencrypted link of 10Gbps or more is commonly reduced to 2-5Gbps when IPsec is used to encrypt the link using AES-GCM. By using the implementation specified in this document, aggregate throughput increased from 5Gbps using 1 CPU to 40-60 Gbps using 25-30 CPUs -- Will this text age well? -- Can these statistics be cited? ** Section 1. Editorial. While this could be (partially) mitigated by setting up multiple narrowed Child SAs, for example using Populate From Packet (PFP) as specified in IPsec Architecture [RFC4301], this IPsec feature would cause too many Child SAs (one per netflow) Is it “netflow” or “network flow”? “netflow” is a logging format. ** Section 1. Editorial. When an IKEv2 peer is receiving more additional Child SA's It is “more additional Child SA’s” or “additional Child SA’s”? ** Section 3. If this initial Child SA will be tied to a specific resource, it MAY indicate this by including an identifier in the Notification Data. How does one tie the Child SA to the specific resource if the identifier is NOT included in the Notification data? Wouldn’t it be mandatory to include this identifier? ** Section 4. Is this section normative? Why are RFC2119 key words used in an example? ** Section 4. Doesn’t the example in the paragraph starting with “A simple distribution could be to install one additional Child SA on each CPU” violate the situation described in Section 2 (i.e., coordination across CPUs)? ** Section 5. The diagrams in Section 5.* show “Next Payload”, a fields flags and a “Payload length”. Where are those defined? ** Section 5.1. Editorial. The diagram says “optional resource identifier”. The description of the fields says “Optional Payload Data” ** Section 5.1 The opaque data SHOULD be a unique identifier within all the Child SAs with the same TS payloads and the peer SHOULD only use it for debugging purposes. -- Why is normative guidance being provided on the contents or semantics of an “opaque data” blob? -- I don’t understand how to read the “SHOULD” in this text. If not intended to be a unique identifier, what else should this opaque data be used for? -- When and why should this be used for “non-debugging purposes”? ** Section 6. Peers SHOULD be lenient with the maximum number of Child SAs they allow for a given TSi/TSr combination to account for corner cases. What does “lenient” mean here? ** Section 6. As additional Child SAs consume little additional overhead, allowing at the very least double its intended CPUs is RECOMMENDED. Can this language please be clarified? I don’t understand. “Double” relative to what baseline? Is this recommending the number Child SAs per CPU? ** Section 6. An implementation MAY limit the number of Child SAs only based on its resources - that is only limit these based on regular denial of service protection. Why can’t an implementation limit SAs based on any policy? ** Section 7. Similar to how an implementation should limit the number of half-open SAs to limit the impact of a denial of service attack, an implementation SHOULD limit the maximum number of additional Child SAs allowed per unique TSi/TSr. Is it a SHOULD or RECOMMENDED? ** Section 7. Editorial. Using multiple resource specific child SAs makes sense for high volume IPsec connections on IPsec gateway machines where the administrator has a reasonable trust relationship with the peer's administrator and abuse is unlikely and easilly escalated to resolve. -- What makes a trust relationship “reasonable”? Would it be clear to omit that word? -- Typo. s/easilly/easily/ ** Section 7. Typo. s/identifer/identifier/? ** Section 9. Typo. The registry names is incorrect (i.e., s/... Notify Messages/... Notify Messages Types/) OLD This document defines one new registration for the IANA "IKEv2 Notify Messages - Status Types" registry. NEW This document defines one new registration for the IANA "IKEv2 Notify Messages Types - Status Types" registry. OLD This document defines one new registration for the IANA "IKEv2 Notify Messages - Error Types" registry. NEW This document defines one new registration for the IANA "IKEv2 Notify Messages Types - Error Types" registry. Regards, Roman ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] [IANA #1361470] expert review for draft-ietf-ipsecme-ikev2-auth-announce (ikev2-parameters)
David Dong via RT writes: > Dear Tero Kivinen, Valery Smyslov (cc: ipsecme WG), > > As the designated experts for the IKEv2 Notify Message Types - > Status Types registry, can you review the proposed registration in > draft-ietf-ipsecme-ikev2-auth-announce-06 for us? Please see > > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-auth-announce/ > > The due date is April 1st. > > If this is OK, when the IESG approves the document for publication, > we'll make the registration at: > > https://www.iana.org/assignments/ikev2-parameters/ The allocation in draft-ietf-ipsecme-ikev2-auth-announce is ok. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] I-D Action: draft-ietf-ipsecme-ikev2-diet-esp-extension-00.txt
Internet-Draft draft-ietf-ipsecme-ikev2-diet-esp-extension-00.txt is now available. It is a work item of the IP Security Maintenance and Extensions (IPSECME) WG of the IETF. Title: Internet Key Exchange version 2 (IKEv2) extension for the ESP Header Compression (EHC) Authors: Daniel Migault Tobias Guggemos David Schinazi Name:draft-ietf-ipsecme-ikev2-diet-esp-extension-00.txt Pages: 8 Dates: 2024-03-18 Abstract: This document describes an IKEv2 extension of for the ESP Header Compression (EHC) to agree on a specific ESP Header Compression (EHC) Context. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-diet-esp-extension/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-diet-esp-extension-00 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] I-D Action: draft-ietf-ipsecme-diet-esp-00.txt
Internet-Draft draft-ietf-ipsecme-diet-esp-00.txt is now available. It is a work item of the IP Security Maintenance and Extensions (IPSECME) WG of the IETF. Title: ESP Header Compression Profile Authors: Daniel Migault Tobias Guggemos Carsten. Bormann David Schinazi Name:draft-ietf-ipsecme-diet-esp-00.txt Pages: 27 Dates: 2024-03-18 Abstract: ESP Header Compression Profile (EHCP) defines a profile to compress communications protected with IPsec/ESP. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-diet-esp/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-diet-esp-00 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] I-D Action: draft-mglt-ipsecme-diet-esp-12.txt
Internet-Draft draft-mglt-ipsecme-diet-esp-12.txt is now available. It is a work item of the IP Security Maintenance and Extensions (IPSECME) WG of the IETF. Title: ESP Header Compression Profile Authors: Daniel Migault Tobias Guggemos Carsten. Bormann David Schinazi Name:draft-mglt-ipsecme-diet-esp-12.txt Pages: 27 Dates: 2024-03-18 Abstract: ESP Header Compression Profile (EHCP) defines a profile to compress communications protected with IPsec/ESP. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-mglt-ipsecme-diet-esp-12 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-mglt-ipsecme-diet-esp-12 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] Publication has been requested for draft-ietf-ipsecme-multi-sa-performance-05
Tero Kivinen has requested publication of draft-ietf-ipsecme-multi-sa-performance-05 as Proposed Standard on behalf of the IPSECME working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-ipsecme-multi-sa-performance/ ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] [IANA #1361470] expert review for draft-ietf-ipsecme-ikev2-auth-announce (ikev2-parameters)
Dear Tero Kivinen, Valery Smyslov (cc: ipsecme WG), As the designated experts for the IKEv2 Notify Message Types - Status Types registry, can you review the proposed registration in draft-ietf-ipsecme-ikev2-auth-announce-06 for us? Please see https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-auth-announce/ The due date is April 1st. If this is OK, when the IESG approves the document for publication, we'll make the registration at: https://www.iana.org/assignments/ikev2-parameters/ Unless you ask us to wait for the other reviewer, we’ll act on the first response we receive. With thanks, David Dong IANA Services Sr. Specialist ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-ietf-ipsecme-multi-sa-performance-04.txt
On Mon, 18 Mar 2024, Tero Kivinen wrote: Internet-Draft draft-ietf-ipsecme-multi-sa-performance-04.txt is now This seems to cover my comments until section 5, but does not cover the changes for section 5.1, 6, and 9. Is there some issues with those comments? that was an operator error on my side, -05 fixes the remaining issues. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] I-D Action: draft-ietf-ipsecme-multi-sa-performance-05.txt
Internet-Draft draft-ietf-ipsecme-multi-sa-performance-05.txt is now available. It is a work item of the IP Security Maintenance and Extensions (IPSECME) WG of the IETF. Title: IKEv2 support for per-resource Child SAs Authors: Antony Antony Tobias Brunner Steffen Klassert Paul Wouters Name:draft-ietf-ipsecme-multi-sa-performance-05.txt Pages: 13 Dates: 2024-03-18 Abstract: This document defines two Notify Message Type Payloads for the Internet Key Exchange Protocol Version 2 (IKEv2) to support the negotiation of multiple Child SAs with the same Traffic Selectors used on different resources, such as CPUs, to increase bandwidth of IPsec traffic between peers. The SA_RESOURCE_INFO notification is used to convey information that the negotiated Child SA and subsequent new Child SAs with the same Traffic Selectors are a logical group of Child SAs where most or all of the Child SAs are bound to a specific resource, such as a specific CPU. The TS_MAX_QUEUE notify conveys that the peer is unwilling to create more additional Child SAs for this particular negotiated Traffic Selector combination. Using multiple Child SAs with the same Traffic Selectors has the benefit that each resource holding the Child SA has its own Sequence Number Counter, ensuring that CPUs don't have to synchronize their crypto state or disable their packet replay protection. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-multi-sa-performance/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-multi-sa-performance-05 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-ipsecme-multi-sa-performance-05 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] WG Call adoption for draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-diet-esp-extension passed
I just now noticed that I never announced or marked the result of adoptionc alls for these two docments, mostly because they expired, and because that they did not show up in the IPsecME WG document page, so when I searched all documents in Call for Adoption state, they did not show up. Now when Daniel has sent out new versions of those drafts, I can mark them as being adopted. There was quite a lot of non-ipsec people showing up support for these drafts, but I think there was also enough ipsec people saying they are interesed, that we should be able to finish these documents in the WG. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] I-D Action: draft-mglt-ipsecme-ikev2-diet-esp-extension-04.txt
Internet-Draft draft-mglt-ipsecme-ikev2-diet-esp-extension-04.txt is now available. It is a work item of the IP Security Maintenance and Extensions (IPSECME) WG of the IETF. Title: Internet Key Exchange version 2 (IKEv2) extension for the ESP Header Compression (EHC) Authors: Daniel Migault Tobias Guggemos David Schinazi Name:draft-mglt-ipsecme-ikev2-diet-esp-extension-04.txt Pages: 8 Dates: 2024-03-18 Abstract: This document describes an IKEv2 extension of for the ESP Header Compression (EHC) to agree on a specific ESP Header Compression (EHC) Context. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-mglt-ipsecme-ikev2-diet-esp-extension/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-mglt-ipsecme-ikev2-diet-esp-extension-04 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-mglt-ipsecme-ikev2-diet-esp-extension-04 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] I-D Action: draft-mglt-ipsecme-diet-esp-11.txt
Internet-Draft draft-mglt-ipsecme-diet-esp-11.txt is now available. It is a work item of the IP Security Maintenance and Extensions (IPSECME) WG of the IETF. Title: ESP Header Compression Profile Authors: Daniel Migault Tobias Guggemos Carsten. Bormann David Schinazi Name:draft-mglt-ipsecme-diet-esp-11.txt Pages: 27 Dates: 2024-03-18 Abstract: ESP Header Compression Profile (EHCP) defines a profile to compress communications protected with IPsec/ESP. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-mglt-ipsecme-diet-esp-11 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-mglt-ipsecme-diet-esp-11 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] I-D Action: draft-ietf-ipsecme-multi-sa-performance-04.txt
internet-dra...@ietf.org writes: > Internet-Draft draft-ietf-ipsecme-multi-sa-performance-04.txt is now > available. It is a work item of the IP Security Maintenance and Extensions > (IPSECME) WG of the IETF. > >Title: IKEv2 support for per-resource Child SAs This seems to cover my comments until section 5, but does not cover the changes for section 5.1, 6, and 9. Is there some issues with those comments? -- In section 5.1 you say that Protocol id MUST contain either 2 for AH and 3 for ESP, but on the RFC7296 says that "If the SPI field is empty, this field MUST be sent as zero and MUST be ignored on receipt." and as this notify is sent with empty SPI field, then the Protocol ID field MUST be 0 also. -- In section 5.1 add text saying that SPI Size MUST be zero. -- In section 5.1 fix s/opague/opaque/ twice. -- In section 6 there is text saying: If the IKEv2 extension defined in this document is negotiated with the peer, an implementation which does not support receiving per-CPU packet trigger messages MAY initiate all its Child SAs immediately upon receiving the (only) packet trigger message it will receive from the IPsec stack. On the other hand there is no negotiation of the this extension. What is this text trying to say? Perhaps simply remove change to say "If an implementation does not support ... it MAY ..." -- Section 9 the correct heading for the IANA registries 2nd column are Notify Messages - Status Types and Notify Messages - Error Types Currently the figure 2 is using status type header and even that does not match iana registry. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] I-D Action: draft-ietf-ipsecme-multi-sa-performance-04.txt
Internet-Draft draft-ietf-ipsecme-multi-sa-performance-04.txt is now available. It is a work item of the IP Security Maintenance and Extensions (IPSECME) WG of the IETF. Title: IKEv2 support for per-resource Child SAs Authors: Antony Antony Tobias Brunner Steffen Klassert Paul Wouters Name:draft-ietf-ipsecme-multi-sa-performance-04.txt Pages: 13 Dates: 2024-03-18 Abstract: This document defines two Notify Message Type Payloads for the Internet Key Exchange Protocol Version 2 (IKEv2) to support the negotiation of multiple Child SAs with the same Traffic Selectors used on different resources, such as CPUs, to increase bandwidth of IPsec traffic between peers. The SA_RESOURCE_INFO notification is used to convey information that the negotiated Child SA and subsequent new Child SAs with the same Traffic Selectors are a logical group of Child SAs where most or all of the Child SAs are bound to a specific resource, such as a specific CPU. The TS_MAX_QUEUE notify conveys that the peer is unwilling to create more additional Child SAs for this particular negotiated Traffic Selector combination. Using multiple Child SAs with the same Traffic Selectors has the benefit that each resource holding the Child SA has its own Sequence Number Counter, ensuring that CPUs don't have to synchronize their crypto state or disable their packet replay protection. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-multi-sa-performance/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-multi-sa-performance-04 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-ipsecme-multi-sa-performance-04 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
