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]
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.
The first two cases are identical to what RFC 4303 and RFC 7296 specify.
Any opinions? Any suggestions for better names?
> 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 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?
> 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.
Regards,
Valery.
> 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
