rfc9827.original		rfc9827.txt
	Network Working Group V. Smyslov		Internet Engineering Task Force (IETF) V. Smyslov
	Internet-Draft ELVIS-PLUS		Request for Comments: 9827 ELVIS-PLUS
	Updates: 7296 (if approved) 16 March 2025		Updates: 7296 August 2025
	Intended status: Standards Track		Category: Standards Track
	Expires: 17 September 2025		ISSN: 2070-1721
	Renaming Extended Sequence Number (ESN) Transform Type in the Internet		Renaming the Extended Sequence Numbers (ESN) Transform Type in the
	Key Exchange Protocol Version 2 (IKEv2)		Internet Key Exchange Protocol Version 2 (IKEv2)
	draft-ietf-ipsecme-ikev2-rename-esn-05
	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 IKEv2. It updates RFC 7296 by renaming the transform type 5 from		in Internet Key Exchange Protocol Version 2 (IKEv2). It updates RFC
	"Extended Sequence Numbers (ESN)" to "Sequence Numbers (SN)". It		7296 by renaming Transform Type 5 from "Extended Sequence Numbers
	also renames two currently defined values for this transform type:		(ESN)" to "Sequence Numbers (SN)". It also renames two currently
	value 0 from "No Extended Sequence Numbers" to "32-bit Sequential		defined values for this Transform Type: value 0 from "No Extended
	Numbers" and value 1 from "Extended Sequence Numbers" to "Partially		Sequence Numbers" to "32-bit Sequential Numbers" and value 1 from
	Transmitted 64-bit Sequential Numbers".		"Extended Sequence Numbers" to "Partially Transmitted 64-bit
			Sequential Numbers".
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 7841.
	This Internet-Draft will expire on 17 September 2025.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			https://www.rfc-editor.org/info/rfc9827.
	Copyright Notice		Copyright Notice
	Copyright (c) 2025 IETF Trust and the persons identified as the		Copyright (c) 2025 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents
	license-info) in effect on the date of publication of this document.		(https://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document. Code Components		carefully, as they describe your rights and restrictions with respect
	extracted from this document must include Revised BSD License text as		to this document. Code Components extracted from this document must
	described in Section 4.e of the Trust Legal Provisions and are		include Revised BSD License text as described in Section 4.e of the
	provided without warranty as described in the Revised BSD License.		Trust Legal Provisions and are provided without warranty as described
			in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction
	2. Problem Description . . . . . . . . . . . . . . . . . . . . . 3		2. Problem Description
	3. Extending the Semantics of Transform Type 5 . . . . . . . . . 4		3. Extending the Semantics of Transform Type 5
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 6		4. Security Considerations
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		5. IANA Considerations
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7		6. References
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		6.1. Normative References
	7.1. Normative References . . . . . . . . . . . . . . . . . . 7		6.2. Informative References
	7.2. Informative References . . . . . . . . . . . . . . . . . 8		Acknowledgements
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9		Author's Address
	1. Introduction		1. Introduction
	IP Security (IPsec) Architecture [RFC4301] defines a set of security		The IP Security (IPsec) Architecture [RFC4301] defines a set of
	services provided by IPsec protocols Authentication Header (AH)		security services provided by the Authentication Header (AH)
	[RFC4302] and Encapsulating Security Payload (ESP) [RFC4303]. One of		[RFC4302] and Encapsulating Security Payload (ESP) [RFC4303]. One of
	these services is replay protection, which is referred to as "anti-		these services is replay protection, which is referred to as "anti-
	replay" in these documents. In IPsec the anti-replay service is		replay" in these documents. In IPsec, the anti-replay service is
	optional, each receiver of AH and/or ESP packets can choose whether		optional; each receiver of AH and/or ESP packets can choose whether
	to enable it on a per Security Association (SA) basis. The replay		to enable it on a per Security Association (SA) basis. The replay
	protection in AH and ESP is achieved by means of a monotonically		protection in AH and ESP is achieved by means of a monotonically
	increasing counter that never wraps around, which is sent in each AH		increasing counter that never wraps around and is sent in each AH or
	or ESP packet in the Sequence Number field. The receiver maintains a		ESP packet in the Sequence Number field. The receiver maintains a
	sliding window that allows to detect duplicate packets.		sliding window that allows duplicate packets to be detected.
	Both AH and ESP allow using either a 32-bit counter or a 64-bit		Both AH and ESP allow use of either a 32-bit counter or a 64-bit
	counter. The latter case is referred to as Extended Sequence Numbers		counter. The latter case is referred to as Extended Sequence Numbers
	(ESN) in AH and ESP specifications. Since the Sequence Number field		(ESN) in AH and ESP specifications. Since the Sequence Number field
	in both AH and ESP headers is only 32 bits in size, in case of ESN		in both AH and ESP headers is only 32 bits in size, in case of ESN
	the high-order 32 bits of the counter are not transmitted and are		the high-order 32 bits of the counter are not transmitted and are
	determined by the receiver based on previously received packets.		determined by the receiver based on previously received packets.
	Since the decision whether to enable the anti-replay service is taken		The receiver decides whether to enable the anti-replay service based
	by the receiver based only on the receiver's local policy, the sender		only on the receiver's local policy, so the sender, in accordance
	in accordance with the specifications for AH ([RFC4302]		with the specifications for AH ([RFC4302], Section 3.3.2) and ESP
	Section 3.3.2) and ESP ([RFC4303] Section 3.3.3) should always assume		([RFC4303], Section 3.3.3), should always assume that the replay
	that the replay protection is enabled on receiving side. Thus, the		protection is enabled on the receiving side. Thus, the sender should
	sender should always send the increasing counter values and should		always send the increasing counter values and should take care that
	take care that the counter never wraps around. AH and ESP		the counter never wraps around. AH and ESP specifications also
	specifications also discuss situations when replay protection is not		discuss situations in which replay protection is not possible to
	possible to achieve even if senders do all as prescribed -- like in		achieve, even if senders do all as prescribed -- like in multicast
	multicast Security Associations with multiple unsynchronized senders.		Security Associations with multiple unsynchronized senders. Both AH
			and ESP specifications allow the sender to avoid maintaining the
	Both AH and ESP specifications allow the sender to avoid maintaining		counter if the sender has been notified that the anti-replay service
	the counter if the sender has been notified somehow that the anti-		is disabled by the receiver or is not possible to achieve.
	replay service is disabled by the receiver or is not possible to
	achieve.
	AH and ESP Security Associations are usually established using the		AH and ESP Security Associations are usually established using IKEv2
	Internet Key Exchange protocol version 2 (IKEv2) [RFC7296]. The		[RFC7296]. The process of SA establishment includes calculation of a
	process of SA establishment includes calculation of a shared key and		shared key and negotiation of various SA parameters, such as
	negotiation of various SA parameters, such as cryptographic		cryptographic algorithms. This negotiation in IKEv2 is performed via
	algorithms. This negotiation in IKEv2 is performed via transforms		transforms (see Section 3.3.2 of [RFC7296]). The type of transform
	(see Section 3.3.2 of [RFC7296]). The type of transform determines		determines what parameter is being negotiated. Each Transform Type
	what parameter is being negotiated. Each transform type has an		has an associated list of possible values (called Transform IDs) that
	associated list of possible values (called Transform IDs), that
	determine the possible options for negotiation. See [IKEV2-IANA] for		determine the possible options for negotiation. See [IKEV2-IANA] for
	the list of transform types and associated transform IDs.		the list of Transform Types and associated Transform IDs.
	Transform type 5 "Extended Sequence Numbers (ESN)" is used in IKEv2		Transform Type 5 ("Extended Sequence Numbers (ESN)") is used in IKEv2
	to negotiate the way sequence numbers for replay protection are		to negotiate the way sequence numbers for replay protection are
	generated, transmitted and processed in the context of an SA. For		generated, transmitted, and processed in the context of an SA. There
	this transform type two values are defined -- "No Extended Sequence		are two values are defined for this Transform Type -- "No Extended
	Numbers" and "Extended Sequence Numbers".		Sequence Numbers" and "Extended Sequence Numbers".
	This document updates IKEv2 specification [RFC7296] by renaming		This document updates the IKEv2 specification [RFC7296] by renaming
	transform type 5 and two associated transform IDs.		Transform Type 5 and the two associated Transform IDs.
	2. Problem Description		2. Problem Description
	IKEv2 currently has no means to negotiate the case when both peers		IKEv2 currently has no means to negotiate the case when both peers
	agree that replay protection is not needed. Even when both peers		agree that replay protection is not needed. Even when both peers
	locally disable anti-replay service as receivers, they still need to		locally disable anti-replay service as receivers, they still need to
	maintain increasing sequence numbers as senders, taking care that		maintain increasing sequence numbers as senders, taking care that
	they never wrap around (see		they never wrap around (see [ANTIREPLAY]).
	[I-D.pan-ipsecme-anti-replay-notification]).
	There is also no way to inform receivers that replay protection is		There is also no way to inform receivers that replay protection is
	not possible for a particular SA (for example in case of a multicast		not possible for a particular SA (for example in case of a multicast
	SA with several unsynchronized senders).		SA with several unsynchronized senders).
	Future IPsec security protocols may provide more options for the		Future IPsec protocols may provide more options for the handling of
	handling of anti-replay counters, like sending full 64-bit sequence		anti-replay counters, like sending full 64-bit sequence numbers or
	numbers or completely omitting them in packets (see		completely omitting them in packets (see [EESP]). These options will
	[I-D.klassert-ipsecme-eesp]). These options will require means to be		require means to be negotiated in IKEv2.
	negotiated in IKEv2.
	Transform type 5 is the best candidate for addressing these issues:		Transform Type 5 is the best candidate for addressing these issues:
	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 necessaryly		wire into account.
	transmitted.
	* The properties are interpreted as a characteristic of IPsec SA		* The properties are interpreted as characteristics of IPsec SA
	packets, and not as a result of a sender actions. For example, in		packets rather than the results of sender actions. For example,
	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.,
	break sequence numbers uniqueness by packet duplication).		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, that includes the case when sequence numbers are absent.		sense, which includes the case when sequence numbers are absent.
	Given this definition, transform type 5 in the IANA registries for		Given this updated definition, Transform Type 5 in the "Transform
	IKEv2 [IKEV2-IANA] is renamed from "Extended Sequence Numbers (ESN)"		Type Values" registry [IKEV2-IANA] has been renamed from "Extended
	to "Sequence Numbers (SN)" with the meaning, that it defines the		Sequence Numbers (ESN)" to "Sequence Numbers (SN)" in the sense that
	properties the sequence numbers would have.		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 future (like in G-IKEv2 [I-D.ietf-ipsecme-g-ikev2]		Transform Type in the future (like in G-IKEv2 [G-IKEv2] for the case
	for the case of multicast SAs). Documents defining new transform IDs		of multicast SAs). Documents defining new Transform IDs should
	should include description of the properties the sequence numbers		include descriptions of the properties the sequence numbers would
	would have if the new transform ID is selected. In particular, this		have if the new Transform ID was selected. In particular, the
	description should include discussion whether these properties allow		descriptions should include discussion of whether these properties
	achieving replay protection.		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
	Aggregation and Fragmentation for ESP [RFC9347]) rely on properties		Aggregation and Fragmentation for ESP [RFC9347]) rely on properties
	that are guaranteed for the currently defined transform IDs, but this		that are guaranteed for the currently defined Transform IDs; however,
	might not be true for future transform IDs. When a new transform ID		this might not be true for future Transform IDs. When a new
	is defined, its description should include a discussion about the		Transform ID is defined, its description should include discussion
	possibility of using this transform ID in protocols, that rely on		about the possibility of using the Transform ID in protocols that
	some particular properties of sequence numbers.		rely on some particular properties of sequence numbers.
	The two currently defined transform IDs for this transform type		The two currently defined Transform IDs for Transform Type 5 define
	define the following properties of sequence numbers.		the following properties of sequence numbers.
	* Value 0 for transform type 5 defines sequence numbers as		* Value 0 defines sequence numbers as monotonically increasing
	monotonically increasing 32-bit counters that are transmitted in		32-bit counters that are transmitted in the Sequence Number field
	the Sequence Number field of AH and ESP packets. They never wrap		of AH and ESP packets. They never wrap around and are guaranteed
	around and are guaranteed to be unique, thus they are suitable for		to be unique, thus they are suitable for replay protection. They
	replay protection. They can also be used with protocols that rely		can also be used with protocols that rely on sequence number
	on sequence numbers uniqueness (like [RFC8750]) or their monotonic		uniqueness (e.g., [RFC8750]) or monotonically increasing sequence
	increase (like [RFC9347]). The sender and the receiver actions		numbers (e.g., [RFC9347]). The sender and the receiver actions
	are defined in Sections 3.3.2 and 3.4.3 of [RFC4302] for AH and in		are defined in Sections 3.3.2 and 3.4.3 of [RFC4302] for AH and in
	Sections 3.3.3 and 3.4.3 of [RFC4303] for ESP.		Sections 3.3.3 and 3.4.3 of [RFC4303] for ESP.
	* Value 1 for transform type 5 defines sequence numbers as		* Value 1 defines sequence numbers as monotonically increasing
	monotonically increasing 64-bit counters. The low-order 32 bits		64-bit counters. The low-order 32 bits are transmitted in the
	are transmitted in the Sequence Number field of AH and ESP packets		Sequence Number field of AH and ESP packets, and the high-order 32
	and the high-order 32 bits are implicitly determined on receivers		bits are implicitly determined on receivers based on previously
	based on previously received packets. The sequence numbers never		received packets. The sequence numbers never wrap around and are
	wrap around and are guaranteed to be unique, thus they are		guaranteed to be unique, thus they are suitable for replay
	suitable for replay protection. They can also be used with		protection. They can also be used with protocols that rely on
	protocols that rely on sequence numbers uniqueness (like		sequence number uniqueness (e.g., [RFC8750]) or their monotonic
	[RFC8750]) or their monotonic increase (like [RFC9347]). To be		increase (e.g., [RFC9347]). To correctly process the incoming
	able to correctly process the incoming packets on receivers the		packets on receivers, the packets must be authenticated (even when
	packets must be authenticated (even when the replay protection is		the replay protection is not used). The sender and the receiver
	not used). The sender and the receiver actions are defined in		actions are defined in Sections 3.3.2 and 3.4.3 of [RFC4302] for
	Sections 3.3.2 and 3.4.3 of [RFC4302] for AH and in Sections 3.3.3		AH and in Sections 3.3.3 and 3.4.3 of [RFC4303] for ESP.
	and 3.4.3 of [RFC4303] for ESP.
	Given the descriptions above and the new definition of transform type		Given the descriptions above and the new definition of Transform Type
	5, the two currently defined transform IDs are renamed to better		5, the two currently defined Transform IDs are renamed to better
	reflect the properties of sequence numbers they assume.		reflect the properties of sequence numbers they assume.
	* Transform ID 0 is renamed from "No Extended Sequence Numbers" to		* Transform ID 0 is renamed from "No Extended Sequence Numbers" to
	"32-bit Sequential Numbers".		"32-bit Sequential Numbers".
	* Transform ID 1 is renamed from "Extended Sequence Numbers" to		* Transform ID 1 is renamed from "Extended Sequence Numbers" to
	"Partially Transmitted 64-bit Sequential Numbers".		"Partially Transmitted 64-bit Sequential Numbers".
	Note, that the above descriptions do not change the existing		Note that the above descriptions do not change the existing semantics
	semantics of these transform IDs, they only provide clarification.		of these Transform IDs, they only provide clarification. Also note
	Note also, that ESP and AH packet processing for these transform IDs		that ESP and AH packet processing for these Transform IDs is not
	is not affected, and bits on the wire do not change.		affected, and bits on the wire do not change.
	4. Security Considerations		4. Security Considerations
	This document does not affect security of the AH, ESP and IKEv2		This document does not affect security of the AH, ESP, and IKEv2
	protocols.		protocols.
	5. IANA Considerations		5. IANA Considerations
	This document makes the following changes in the "Internet Key		This document makes changes to registries within the "Internet Key
	Exchange Version 2 (IKEv2) Parameters" IANA registries [IKEV2-IANA].		Exchange Version 2 (IKEv2) Parameters" registry group [IKEV2-IANA].
	It is assumed that RFCXXXX refers to this specification.
	* The existing transform type 5 "Extended Sequence Numbers (ESN)" in		The "Transform Type Values" registry has been updated as follows:
	the "Transform Type Values" registry is renamed to "Sequence
	Numbers (SN)".
	* Appended [RFCXXXX] to the Reference column of Transform Type 5 in		* renamed Transform Type 5 from "Extended Sequence Numbers (ESN)" to
	the "Transform Type Values" registry.		"Sequence Numbers (SN)".
	* Added this note to the "Transform Type Values" registry:		* added as a reference to this RFC for Transform Type 5.
	"Sequence Numbers (SN)" transform type was originally named		* added the following note:
	"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.
	* The "Transform Type 5 - Extended Sequence Numbers Transform IDs"		| The "Sequence Numbers (SN)" Transform Type was originally named
	registry is renamed to "Transform Type 5 - Sequence Numbers		| "Extended Sequence Numbers (ESN)" and was referenced by that
	Transform IDs".		| name in a number of RFCs published prior to [RFC9827], which
			| gave it the current title.
	* The "Reserved" (2-65535) range of numbers in what was the		The "Transform Type 5 - Extended Sequence Numbers Transform IDs"
	"Transform Type 5 - Extended Sequence Numbers Transform IDs"		registry has been updated as follows:
	registry is split into the "Unassigned" (2-1023) and the "Reserved
	for Private Use" (1024-65535) ranges, as shown below.
	Number Name Reference		* renamed the registry from "Transform Type 5 - Extended Sequence
	-------------------------------------------------		Numbers Transform IDs" to "Transform Type 5 - Sequence Numbers
	2-1023 Unassigned		Transform IDs" and added this document as a reference.
	1024-65535 Reserved for Private Use [RFCXXXX]
	* The existing Transform ID 0 "No Extended Sequence Numbers" in what		* split the "Reserved" (2-65535) range of numbers as shown below.
	was the "Transform Type 5 - Extended Sequence Numbers Transform
	IDs" registry is renamed to "32-bit Sequential Numbers".
	* The existing Transform ID 1 "Extended Sequence Numbers" in what		+============+==========================+===========+
	was the "Transform Type 5 - Extended Sequence Numbers Transform		| Number | Name | Reference |
	IDs" registry is renamed to "Partially Transmitted 64-bit		+============+==========================+===========+
	Sequential Numbers".		| 2-1023 | Unassigned |
			+------------+--------------------------+-----------+
			| 1024-65535 | Reserved for Private Use | [RFC9827] |
			+------------+--------------------------+-----------+
	* Appended [RFCXXXX] to the Reference column of Transform ID 0 and		Table 1
	Transform ID 1 in what was the "Transform Type 5 - Extended
	Sequence Numbers Transform IDs" registry.
	* Added these notes to what was the "Transform Type 5 - Extended		* renamed Transform ID 0 from "No Extended Sequence Numbers" to
	Sequence Numbers Transform IDs" registry:		"32-bit Sequential Numbers".
	This registry was originally named "Transform Type 5 - Extended		* renamed Transform ID 1 from "Extended Sequence Numbers" to
	Sequence Numbers Transform IDs" and was referenced using that name		"Partially Transmitted 64-bit Sequential Numbers".
	in a number of RFCs published prior to [RFCXXXX], which gave it
	the current title.
	"32-bit Sequential Numbers" transform ID was originally named "No		* added a reference to this RFC for Transform ID 0 and Transform ID
	Extended Sequence Numbers" and was referenced by that name in a		1.
	number of RFCs published prior to [RFCXXXX], which gave it the
	current title.
	"Partially Transmitted 64-bit Sequential Numbers" transform ID was		* added the the following registry notes:
	originally named "Extended Sequence Numbers" and was referenced by
	that name in a number of RFCs published prior to [RFCXXXX], which
	gave it the current title.
	Numbers in the range 2-65535 were originally marked as "Reserved"		| This registry was originally named "Transform Type 5 - Extended
	and were re-classified as "Unassigned" and "Reserved for Private		| Sequence Numbers Transform IDs" and was referenced using that
	Use" by [RFCXXXX].		| name in a number of RFCs published prior to [RFC9827], which
			| gave it the current title.
	6. Acknowledgements		| The "32-bit Sequential Numbers" Transform ID was originally
			| named "No Extended Sequence Numbers" and was referenced by that
			| name in a number of RFCs published prior to [RFC9827], which
			| gave it the current title.
	This document was created as a result of discussions with Russ		| The "Partially Transmitted 64-bit Sequential Numbers" Transform
	Housley, Tero Kivinen, Paul Wouters and Antony Antony about the best		| ID was originally named "Extended Sequence Numbers" and was
	way to extend the meaning of the Extended Sequence Numbers transform		| referenced by that name in a number of RFCs published prior to
	in IKEv2.		| [RFC9827], which gave it the current title.
	7. References		| Numbers in the range 2-65535 were originally marked as
			| "Reserved" and were reclassified as "Unassigned" and "Reserved
			| for Private Use" by [RFC9827].
	7.1. Normative References		6. References
			6.1. Normative References
	[IKEV2-IANA]		[IKEV2-IANA]
	IANA, "Internet Key Exchange Version 2 (IKEv2)		IANA, "Internet Key Exchange Version 2 (IKEv2)
	Parameters", <http://www.iana.org/assignments/ikev2-		Parameters",
	parameters/ikev2-parameters.xhtml>.		<http://www.iana.org/assignments/ikev2-parameters>.
	[RFC4301] Kent, S. and K. Seo, "Security Architecture for the		[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
	Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,		Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
	December 2005, <https://www.rfc-editor.org/info/rfc4301>.		December 2005, <https://www.rfc-editor.org/info/rfc4301>.
	[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,		[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
	DOI 10.17487/RFC4302, December 2005,		DOI 10.17487/RFC4302, December 2005,
	<https://www.rfc-editor.org/info/rfc4302>.		<https://www.rfc-editor.org/info/rfc4302>.
	[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",		[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
	RFC 4303, DOI 10.17487/RFC4303, December 2005,		RFC 4303, DOI 10.17487/RFC4303, December 2005,
	<https://www.rfc-editor.org/info/rfc4303>.		<https://www.rfc-editor.org/info/rfc4303>.
	[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.		[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
	Kivinen, "Internet Key Exchange Protocol Version 2		Kivinen, "Internet Key Exchange Protocol Version 2
	(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October		(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
	2014, <https://www.rfc-editor.org/info/rfc7296>.		2014, <https://www.rfc-editor.org/info/rfc7296>.
	7.2. Informative References		6.2. Informative References
	[I-D.ietf-ipsecme-g-ikev2]
	Smyslov, V. and B. Weis, "Group Key Management using
	IKEv2", Work in Progress, Internet-Draft, draft-ietf-
	ipsecme-g-ikev2-21, 10 February 2025,
	<https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-
	g-ikev2-21>.
	[I-D.klassert-ipsecme-eesp]
	Klassert, S., Antony, A., and C. Hopps, "Enhanced
	Encapsulating Security Payload (EESP)", Work in Progress,
	Internet-Draft, draft-klassert-ipsecme-eesp-02, 26
	February 2025, <https://datatracker.ietf.org/doc/html/
	draft-klassert-ipsecme-eesp-02>.
	[I-D.pan-ipsecme-anti-replay-notification]		[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
			Encapsulating Security Payload (EESP)", Work in Progress,
			Internet-Draft, draft-ietf-ipsecme-eesp-01, 3 July 2025,
			<https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-
			eesp-01>.
			[G-IKEv2] Smyslov, V. and B. Weis, "Group Key Management using
			IKEv2", Work in Progress, Internet-Draft, draft-ietf-
			ipsecme-g-ikev2-23, 31 July 2025,
			<https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-
			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,
	DOI 10.17487/RFC9347, January 2023,		DOI 10.17487/RFC9347, January 2023,
	<https://www.rfc-editor.org/info/rfc9347>.		<https://www.rfc-editor.org/info/rfc9347>.
			Acknowledgements
			This document was created as a result of discussions with Russ
			Housley, Tero Kivinen, Paul Wouters, and Antony Antony about the best
			way to extend the meaning of the Extended Sequence Numbers transform
			in IKEv2.
	Author's Address		Author's Address
	Valery Smyslov		Valery Smyslov
	ELVIS-PLUS		ELVIS-PLUS
	Russian Federation		Russian Federation
	Email: svan@elvis.ru		Email: svan@elvis.ru
End of changes. 63 change blocks.
	232 lines changed or deleted		220 lines changed or added
This html diff was produced by rfcdiff 1.48.