Diff: rfc9827v1.txt - rfc9827.txt

	rfc9827v1.txt	rfc9827.txt

	Internet Engineering Task Force (IETF) V. Smyslov	Internet Engineering Task Force (IETF) V. Smyslov
	Request for Comments: 9827 ELVIS-PLUS	Request for Comments: 9827 ELVIS-PLUS

	Updates: 7296 July 2025	Updates: 7296 August 2025
	Category: Standards Track	Category: Standards Track
	ISSN: 2070-1721	ISSN: 2070-1721


	Renaming the Extended Sequence Number (ESN) Transform Type in the	Renaming the Extended Sequence Numbers (ESN) Transform Type in the
	Internet Key Exchange Protocol Version 2 (IKEv2)	Internet Key Exchange Protocol Version 2 (IKEv2)

	Abstract	Abstract

	This document clarifies and extends the meaning of Transform Type 5	This document clarifies and extends the meaning of Transform Type 5
	in Internet Key Exchange Protocol Version 2 (IKEv2). It updates RFC	in Internet Key Exchange Protocol Version 2 (IKEv2). It updates RFC
	7296 by renaming Transform Type 5 from "Extended Sequence Numbers	7296 by renaming Transform Type 5 from "Extended Sequence Numbers
	(ESN)" to "Sequence Numbers (SN)". It also renames two currently	(ESN)" to "Sequence Numbers (SN)". It also renames two currently
	defined values for this Transform Type: value 0 from "No Extended	defined values for this Transform Type: value 0 from "No Extended
	Sequence Numbers" to "32-bit Sequential Numbers" and value 1 from	Sequence Numbers" to "32-bit Sequential Numbers" and value 1 from

	skipping to change at line 146 ¶	skipping to change at line 146 ¶
	it is already used for negotiation of how sequence numbers are	it is already used for negotiation of how sequence numbers are
	handled in AH and ESP, and it is possible to define additional	handled in AH and ESP, and it is possible to define additional
	Transform IDs that could be used in the corresponding situations.	Transform IDs that could be used in the corresponding situations.
	However, the current definition of Transform Type 5 is too narrow --	However, the current definition of Transform Type 5 is too narrow --
	its name implies that this transform can only be used for negotiation	its name implies that this transform can only be used for negotiation
	of using ESN.	of using ESN.

	3. Extending the Semantics of Transform Type 5	3. Extending the Semantics of Transform Type 5

	This document extends the semantics of Transform Type 5 in IKEv2 to	This document extends the semantics of Transform Type 5 in IKEv2 to

	the following definition.	be defined as follows:


	Transform Type 5 defines the set of properties of sequence numbers of	Transform Type 5 defines the set of properties of sequence numbers
	IPsec packets of a given SA when these packets enter the network.	of IPsec packets of a given SA when these packets enter the
		network.


	This definition requires some clarifications.	This updated definition is clarified as follows:


	* By "sequence numbers" here we assume logical entities (like	* "Sequence numbers" in this definition are not necessarily the
	counters) that can be used for replay protection on receiving	content of the Sequence Number field in the IPsec packets; they
	sides. In particular, these entities are not necessarily the	may also be some logical entities (e.g., counters) that could be
	content of the Sequence Number field in the IPsec packets, but may	constructed taking some information that is not transmitted on the
	be constructed using some information, that is not necessarily	wire into account.
	transmitted.

	* The properties are interpreted as characteristics of IPsec SA	* The properties are interpreted as characteristics of IPsec SA
	packets rather than the results of sender actions. For example,	packets rather than the results of sender actions. For example,
	in multicast SA with multiple unsynchronized senders, even if each	in multicast SA with multiple unsynchronized senders, even if each
	sender ensures the uniqueness of sequence numbers it generates,	sender ensures the uniqueness of sequence numbers it generates,
	the uniqueness of sequence numbers for all IPsec packets is not	the uniqueness of sequence numbers for all IPsec packets is not
	guaranteed.	guaranteed.

	* The properties are defined for the packets just entering the	* The properties are defined for the packets just entering the
	network and not for the packets that receivers get. This is	network and not for the packets that receivers get. This is
	because network behavior may break some of these properties (e.g.,	because network behavior may break some of these properties (e.g.,
	packet duplication would break sequence number uniqueness).	packet duplication would break sequence number uniqueness).

	* The properties of sequence numbers are interpreted in a broad	* The properties of sequence numbers are interpreted in a broad
	sense, which includes the case when sequence numbers are absent.	sense, which includes the case when sequence numbers are absent.

	Given this updated definition, Transform Type 5 in the "Transform	Given this updated definition, Transform Type 5 in the "Transform
	Type Values" registry [IKEV2-IANA] has been renamed from "Extended	Type Values" registry [IKEV2-IANA] has been renamed from "Extended

	Sequence Numbers (ESN)" to "Sequence Numbers (SN)".	Sequence Numbers (ESN)" to "Sequence Numbers (SN)" in the sense that
		it defines the properties of the sequence numbers in general.

	It is expected that new Transform IDs will be defined for this	It is expected that new Transform IDs will be defined for this
	Transform Type in the future (like in G-IKEv2 [G-IKEv2] for the case	Transform Type in the future (like in G-IKEv2 [G-IKEv2] for the case
	of multicast SAs). Documents defining new Transform IDs should	of multicast SAs). Documents defining new Transform IDs should
	include descriptions of the properties the sequence numbers would	include descriptions of the properties the sequence numbers would
	have if the new Transform ID was selected. In particular, the	have if the new Transform ID was selected. In particular, the
	descriptions should include discussion of whether these properties	descriptions should include discussion of whether these properties
	allow replay protection to be achieved.	allow replay protection to be achieved.

	Some existing protocols (like Implicit IV in ESP [RFC8750] or	Some existing protocols (like Implicit IV in ESP [RFC8750] or

	skipping to change at line 203 ¶	skipping to change at line 204 ¶
	rely on some particular properties of sequence numbers.	rely on some particular properties of sequence numbers.

	The two currently defined Transform IDs for Transform Type 5 define	The two currently defined Transform IDs for Transform Type 5 define
	the following properties of sequence numbers.	the following properties of sequence numbers.

	* Value 0 defines sequence numbers as monotonically increasing	* Value 0 defines sequence numbers as monotonically increasing
	32-bit counters that are transmitted in the Sequence Number field	32-bit counters that are transmitted in the Sequence Number field
	of AH and ESP packets. They never wrap around and are guaranteed	of AH and ESP packets. They never wrap around and are guaranteed
	to be unique, thus they are suitable for replay protection. They	to be unique, thus they are suitable for replay protection. They
	can also be used with protocols that rely on sequence number	can also be used with protocols that rely on sequence number

	uniqueness (e.g., [RFC8750]) or their monotonic increase (e.g.,	uniqueness (e.g., [RFC8750]) or monotonically increasing sequence
	[RFC9347]). The sender and the receiver actions are defined in	numbers (e.g., [RFC9347]). The sender and the receiver actions
	Sections 3.3.2 and 3.4.3 of [RFC4302] for AH and in Sections 3.3.3	are defined in Sections 3.3.2 and 3.4.3 of [RFC4302] for AH and in
	and 3.4.3 of [RFC4303] for ESP.	Sections 3.3.3 and 3.4.3 of [RFC4303] for ESP.

	* Value 1 defines sequence numbers as monotonically increasing	* Value 1 defines sequence numbers as monotonically increasing
	64-bit counters. The low-order 32 bits are transmitted in the	64-bit counters. The low-order 32 bits are transmitted in the
	Sequence Number field of AH and ESP packets, and the high-order 32	Sequence Number field of AH and ESP packets, and the high-order 32
	bits are implicitly determined on receivers based on previously	bits are implicitly determined on receivers based on previously
	received packets. The sequence numbers never wrap around and are	received packets. The sequence numbers never wrap around and are
	guaranteed to be unique, thus they are suitable for replay	guaranteed to be unique, thus they are suitable for replay
	protection. They can also be used with protocols that rely on	protection. They can also be used with protocols that rely on
	sequence number uniqueness (e.g., [RFC8750]) or their monotonic	sequence number uniqueness (e.g., [RFC8750]) or their monotonic
	increase (e.g., [RFC9347]). To correctly process the incoming	increase (e.g., [RFC9347]). To correctly process the incoming

	skipping to change at line 347 ¶	skipping to change at line 348 ¶

	[ANTIREPLAY]	[ANTIREPLAY]
	Pan, W., He, Q., and P. Wouters, "IKEv2 Support for Anti-	Pan, W., He, Q., and P. Wouters, "IKEv2 Support for Anti-
	Replay Status Notification", Work in Progress, Internet-	Replay Status Notification", Work in Progress, Internet-
	Draft, draft-pan-ipsecme-anti-replay-notification-01, 21	Draft, draft-pan-ipsecme-anti-replay-notification-01, 21
	October 2024, <https://datatracker.ietf.org/doc/html/	October 2024, <https://datatracker.ietf.org/doc/html/
	draft-pan-ipsecme-anti-replay-notification-01>.	draft-pan-ipsecme-anti-replay-notification-01>.

	[EESP] Klassert, S., Antony, A., and C. Hopps, "Enhanced	[EESP] Klassert, S., Antony, A., and C. Hopps, "Enhanced
	Encapsulating Security Payload (EESP)", Work in Progress,	Encapsulating Security Payload (EESP)", Work in Progress,

	Internet-Draft, draft-klassert-ipsecme-eesp-02, 26	Internet-Draft, draft-ietf-ipsecme-eesp-01, 3 July 2025,
	February 2025, <https://datatracker.ietf.org/doc/html/	<https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-
	draft-klassert-ipsecme-eesp-02>.	eesp-01>.

	[G-IKEv2] Smyslov, V. and B. Weis, "Group Key Management using	[G-IKEv2] Smyslov, V. and B. Weis, "Group Key Management using
	IKEv2", Work in Progress, Internet-Draft, draft-ietf-	IKEv2", Work in Progress, Internet-Draft, draft-ietf-

	ipsecme-g-ikev2-22, 16 March 2025,	ipsecme-g-ikev2-23, 31 July 2025,
	<https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-	<https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-

	g-ikev2-22>.	g-ikev2-23>.

	[RFC8750] Migault, D., Guggemos, T., and Y. Nir, "Implicit	[RFC8750] Migault, D., Guggemos, T., and Y. Nir, "Implicit
	Initialization Vector (IV) for Counter-Based Ciphers in	Initialization Vector (IV) for Counter-Based Ciphers in
	Encapsulating Security Payload (ESP)", RFC 8750,	Encapsulating Security Payload (ESP)", RFC 8750,
	DOI 10.17487/RFC8750, March 2020,	DOI 10.17487/RFC8750, March 2020,
	<https://www.rfc-editor.org/info/rfc8750>.	<https://www.rfc-editor.org/info/rfc8750>.

	[RFC9347] Hopps, C., "Aggregation and Fragmentation Mode for	[RFC9347] Hopps, C., "Aggregation and Fragmentation Mode for
	Encapsulating Security Payload (ESP) and Its Use for IP	Encapsulating Security Payload (ESP) and Its Use for IP
	Traffic Flow Security (IP-TFS)", RFC 9347,	Traffic Flow Security (IP-TFS)", RFC 9347,

End of changes. 11 change blocks.
	22 lines changed or deleted	23 lines changed or added
This html diff was produced by rfcdiff 1.48.