On Thu, Nov 28, 2024 at 03:15:36PM +0300, Valery Smyslov wrote: > Hi Antony, > > > 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? > > The draft doesn't change ESP header format, so the SN field will be there. > The meaning of "Not Used" is: the receiver should not expect that the SN > field uniquely identifies the packet > (in other words, it can repeat). As a consequence - it can wrap, decrement, > be constant. This also means > that ESN, as defined in RFC 4303, when the upper 32 bits are not transmitted, > cannot be used with this option. > > This situation is common with multicast group SAs, when there are multiple > senders, > each sending packets without any synchronization with the other senders. > See Section 3.3.3 and 3.4.3 of RFC 4303. > > > 2. Since 7296 is updated by this document shouldn't also update RFC 7815 > > "Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation". > > I don't think it is needed. We are going to include the following text in the > IANA Considerations to be added to the IANA IKEv2 registry page: > > "Anti-Replay Protection (ARP)" transform type was originally named > "Extended Sequence Numbers (ESN)" and was referenced by that name > in a number of RFCs published prior to [RFCXXXX], which gave it > the current title. > > Do you think this is not enough? > > > 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] > > Correct. > > > It is hard to distinguish option 0 and 2, especially thinking of ESP. > > Does "Not Used" mean it is not part ESP Integrity check? > > No, it doesn't change ESP processing, except that it informs > receivers that SN is not guaranteed to be unique in the received packets for > a given SA. > Thus, anti-replay protection service in ESP cannot be achieved. > > Perhaps, it would be more clear if we also rename the two existing entries. > For example: > > Transform Type 5 - Anti-Replay Protection Transform IDs > > Number Name Reference > 0 Used with 32-bit SN [RFC7296] > 1 Used with 64-bit ESN [RFC7296] > 2 Note Used [this ID] > 3-65535 Reserved [RFC7296]
Here is another proposal just trying to make it easier to read. Number Name Reference 0 32-bit SN [RFC7296] [this ID] 1 64-bit ESN [RFC7296] [this ID] 2 32-bit Not Used [this ID] 3-65535 Reserved [RFC7296] > > Value 0 means that receivers will receive packets with unique 32-bit SN. > Value 1 means that receivers will receive packets with unique 64-bit ESN, > when the upper 32 bits are not transmitted > Value 2 meant that receivers are expected to receive packets with non-unique > 32-bit SN, ESN is not applicable. I propose the following change. "which means that anti-replay protection is not applicable for the SA." "which means that a 32-bit number is sent in the ESP/AH Sequence Number(SN) field of the packet. It is included as part of the packet integrity check when an Integrity Algorithm is chosen. However, on the receiver side, the SN might not be strictly monotonic, as specified in Section 3.3.3 of RFC 4303. Therefore, it SHOULD not be used for anti-replay protection." > > The first two cases are identical to what RFC 4303 and RFC 7296 specify. > > Any opinions? Any suggestions for better names? Here is another proposal"Not Used" -> '32-bit Unspecified' My concern with 'Not Used' is that it would still be part of the integrity check, meaning it is not entirely 'Not Used.' > > 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". > > No, it also renames the transform type (Page 62): > > This document makes the following changes to the "Transform Type > Values" registry: > > [...] > > * Renames existing transform type "Extended Sequence Numbers (ESN)" > to "Anti-Replay Protection (ARP)"; I guess that covers all changes to the registry. > > 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. > > Do you have some proposals how to make it clearer? ESP with full 64 bit SN, and no SN! I am asking becuse x-mas is coming:) I’m sympathetic to the time it takes for shorter documents to progress in our WG :) > > Just as a thought, would it be better addressed in a separate document? > > I suspect that this would make things worse. The renaming itself is a tiny > portion of the draft needed to be able to add one more value into the > registry. > If we put it into the separate document the readers of this draft would be > confused, IMHO. > > > 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! > > I think, once the transform type is renamed and generalized, we can add > a new values in the future, e.g. as you proposed. yes. Thanks. -antony _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
