Hi Valery, While skimming through the draft, I noticed (partial) renaming of ESN to ARP, including the proposed IKEv2 IANA registry changes. I have a few concerns about this.
ESN is a widely recognized term, but admittedly a confusing one, especially since it applies to both IKEv2 negotiation and ESP packets (which transmit only the lower 32 bits, particularly what does disabling ESN means?). The abstract and introduction state that Transform ESN is now updated to ARP. Additionally, someone mentioned there’s a precedent for renaming terms, like "Diffie-Hellman Group" to "Key Exchange Method" in RFC 9370. However, that change seemed straightforward, while ESN to ARP appears more complex to me. I would like hear more clarification on the following aspects ESN -> ARP. 1. Section 4.4.2.1.3 "This transform allows to specify whether the 64-bit Extended Sequence Numbers (ESN) are to be used in ESP and AH." The draft introduces a new "Not Used" value for the IKEv2 ESN/ARP transform. When this is negotiated would the ESP packets still have to send sequence numbers. Why transmit them when not used? If 32 bit SN is used would it wrap the 32 bit number? 2. Since 7296 is updated by this document shouldn't also update RFC 7815 "Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation". 3. The proposed IANA changes are not clear to me I think the extended table https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-9 will become Transform Type 5 - Anti-Replay Protection Transform IDs Number Name Reference 0 No Extended Sequence Numbers [RFC7296] 1 Extended Sequence Numbers [RFC7296] 2 Note Used [this ID] 3-65535 Reserved [RFC7296] It is hard to distinguish option 0 and 2, especially thinking of ESP. Does "Not Used" mean it is not part ESP Integrity check? What about the entry in "Transform Type Values"? https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-3 that one has an entry "5 Extended Sequence Numbers (ESN) (AH and ESP) [RFC7296]" my confusion is the I.D. is only renaming the registry name the "Transform Type Values". I appreciate the significant effort that has gone into this I.D., which has been in development for a long time. However, I find that including the renaming within such a lengthy document can be confusing. Just as a thought, would it be better addressed in a separate document? Additionally, would it make sense to allow the transmission of the full 64-bit ESN number, or even consider omitting the sequence number entirely in ESP when ARP is disabled! thanks, -antony On Tue, Nov 19, 2024 at 04:09:14PM +0300, Valery Smyslov wrote: > Hi, > > the new version addresses comments from AD review and also contains some > clean-ups: > - as suggested by AD and WG members, AH + ESP is now "MUST NOT" > - the negotiation of Key Wrap Algorithm is done via IKEv2 transforms (instead > of transform attributes) - > this is to follow the protocol model when all enumerated via IANA > registries parameters are negotiated via transforms > - initial filling for Key Wrap Algorithm registry is fixed to take into > considerations several possible key sizes for AES > - few clarifications of using key wrapping are added > - "group-wise policy" is changed to "group-wide policy" > - contributors' and authors' addresses are cleaned up > - found typos and grammar issues are fixed > > Regards, > Valery & Brian. > > > Internet-Draft draft-ietf-ipsecme-g-ikev2-17.txt is now available. It is a > > work item of > > the IP Security Maintenance and Extensions (IPSECME) WG of the IETF. > > > > Title: Group Key Management using IKEv2 > > Authors: Valery Smyslov > > Brian Weis > > Name: draft-ietf-ipsecme-g-ikev2-17.txt > > Pages: 72 > > Dates: 2024-11-19 > > > > Abstract: > > > > This document presents an extension to the Internet Key Exchange > > version 2 (IKEv2) protocol for the purpose of a group key management. > > The protocol is in conformance with the Multicast Security (MSEC) key > > management architecture, which contains two components: member > > registration and group rekeying. Both components are required for a > > GCKS (Group Controller/Key Server) to provide authorized Group > > Members (GMs) with IPsec group security associations. The group > > members then exchange IP multicast or other group traffic as IPsec > > packets. > > > > This document obsoletes RFC 6407. This documents also updates RFC > > 7296 by renaming a transform type 5 from "Extended Sequence Numbers > > (ESN)" to the "Anti-Replay Protection (ARP)" and by renaming IKEv2 > > authentication method 0 from "Reserved" to "NONE". > > > > The IETF datatracker status page for this Internet-Draft is: > > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-g-ikev2/ > > > > There is also an HTMLized version available at: > > https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-g-ikev2-17 > > > > A diff from the previous version is available at: > > https://author-tools.ietf.org/iddiff?url2=draft-ietf-ipsecme-g-ikev2-17 > > > > Internet-Drafts are also available by rsync at: > > rsync.ietf.org::internet-drafts > > > > > > _______________________________________________ > > IPsec mailing list -- ipsec@ietf.org > > To unsubscribe send an email to ipsec-le...@ietf.org > > _______________________________________________ > IPsec mailing list -- ipsec@ietf.org > To unsubscribe send an email to ipsec-le...@ietf.org _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
