rfc9827.original.xml		rfc9827.xml
	<?xml version="1.0" encoding="US-ASCII"?>		<?xml version='1.0' encoding='UTF-8'?>
	<?rfc toc="yes"?>
	<?rfc tocompact="no"?>
	<?rfc tocdepth="3"?>
	<?rfc symrefs="yes"?>
	<?rfc sortrefs="yes"?>
	<rfc category="std" submissionType="IETF" docName="draft-ietf-ipsecme-ikev2-rena
	me-esn-05" ipr="trust200902" updates="7296" >
	<front>
	<title abbrev="Renaming ESN in IKEv2">Renaming Extended Sequence Number (ESN
	) Transform Type in the Internet Key Exchange Protocol Version 2 (IKEv2)</title>
			<!DOCTYPE rfc [
			<!ENTITY nbsp "&#160;">
			<!ENTITY zwsp "&#8203;">
			<!ENTITY nbhy "&#8209;">
			<!ENTITY wj "&#8288;">
			]>
			<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" submissionType="I
			ETF" docName="draft-ietf-ipsecme-ikev2-rename-esn-05" number="9827" consensus="t
			rue" ipr="trust200902" updates="7296" obsoletes="" tocInclude="true" tocDepth="3
			" symRefs="true" sortRefs="true" version="3" xml:lang="en">
			<front>
			<title abbrev="Renaming ESN in IKEv2">Renaming the Extended Sequence Number
			(ESN) Transform Type in the Internet Key Exchange Protocol Version 2
			(IKEv2)</title>
			<seriesInfo name="RFC" value="9827"/>
	<author fullname="Valery Smyslov" initials="V." surname="Smyslov">		<author fullname="Valery Smyslov" initials="V." surname="Smyslov">
	<organization>ELVIS-PLUS</organization>		<organization>ELVIS-PLUS</organization>
	<address>		<address>
	<postal>		<postal>
	<street></street>
	<city></city>
	<code></code>
	<region></region>
	<country>Russian Federation</country>		<country>Russian Federation</country>
	</postal>		</postal>
	<phone></phone>
	<email>svan@elvis.ru</email>		<email>svan@elvis.ru</email>
	</address>		</address>
	</author>		</author>
			<date month="July" year="2025"/>
	<date />		<area>SEC</area>
			<workgroup>ipsecme</workgroup>
	<area>Security Area</area>		<!-- [rfced] Please insert any keywords (beyond those that appear in
			the title) for use on https://www.rfc-editor.org/search.
			-->
			<keyword>example</keyword>
	<abstract>		<abstract>
	<t> This document clarifies and extends the meaning of transform type 5 in		<t> This document clarifies and extends the meaning of Transform Type 5 in
	IKEv2.		Internet Key Exchange Protocol Version 2 (IKEv2).
	It updates RFC 7296 by renaming the transform type 5 from "Extended Sequen		It updates RFC 7296 by renaming Transform Type 5 from "Extended Sequence N
	ce Numbers (ESN)"		umbers (ESN)"
	to "Sequence Numbers (SN)". It also renames two currently defined values f		to "Sequence Numbers (SN)". It also renames two currently defined values f
	or this transform type:		or this Transform Type:
	value 0 from "No Extended Sequence Numbers" to "32-bit Sequential Numbers" and value 1 from		value 0 from "No Extended Sequence Numbers" to "32-bit Sequential Numbers" and value 1 from
	"Extended Sequence Numbers" to "Partially Transmitted 64-bit Sequential Nu mbers".		"Extended Sequence Numbers" to "Partially Transmitted 64-bit Sequential Nu mbers".
	</t>		</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<section title="Introduction">		<section>
	<t> IP Security (IPsec) Architecture <xref target="RFC4301" /> defines a s		<name>Introduction</name>
	et of security services provided by IPsec protocols		<t>The IP Security (IPsec) Architecture <xref target="RFC4301"/> defines a
	Authentication Header (AH) <xref target="RFC4302" /> and Encapsulating Sec		set of security services provided by the
	urity Payload (ESP) <xref target="RFC4303" />.		Authentication Header (AH) <xref target="RFC4302"/> and Encapsulating Secu
	One of these services is replay protection, which is referred to as "anti-		rity Payload (ESP) <xref target="RFC4303"/>.
	replay" in these documents. In IPsec the anti-replay service is optional,		One of these services is replay protection, which is referred to as "anti-
			replay" in these documents. In IPsec, the anti-replay service is optional;
	each receiver of AH and/or ESP packets can choose whether to enable it on a per Security Association (SA) basis.		each receiver of AH and/or ESP packets can choose whether to enable it on a per Security Association (SA) basis.
	The replay protection in AH and ESP is achieved by means of a monotonicall		The replay protection in AH and ESP is achieved by means of a monotonicall
	y increasing counter that never wraps around,		y increasing counter that never wraps around and
	which is sent in each AH or ESP packet in the Sequence Number field. The r		is sent in each AH or ESP packet in the Sequence Number field. The receive
	eceiver maintains a sliding window that allows		r maintains a sliding window that allows
	to detect duplicate packets.		duplicate packets to be detected.
	</t>		</t>
			<t> Both AH and ESP allow use of either a 32-bit counter or a 64-bit count
	<t> Both AH and ESP allow using either a 32-bit counter or a 64-bit counte		er.
	r.
	The latter case is referred to as Extended Sequence Numbers (ESN) in AH an d ESP specifications.		The latter case is referred to as Extended Sequence Numbers (ESN) in AH an d ESP specifications.
	Since the Sequence Number field in both AH and ESP headers is only 32 bits in size,		Since the Sequence Number field 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 a nd are determined by the receiver		in case of ESN the high-order 32 bits of the counter are not transmitted a nd are determined by the receiver
	based on previously received packets.		based on previously received packets.
	</t>		</t>
			<t>The receiver decides whether to enable the anti-replay service based on
	<t> Since the decision whether to enable the anti-replay service is taken		ly on the receiver's local policy, so
	by the receiver based only on the receiver's local policy,		the sender, in accordance with the specifications for AH (<xref target="RF
	the sender in accordance with the specifications for AH (<xref target="RFC		C4302" sectionFormat="comma" section="3.3.2"/>) and ESP (<xref target="RFC4303"
	4302" /> Section 3.3.2) and ESP (<xref target="RFC4303" /> Section 3.3.3)		sectionFormat="comma" section="3.3.3"/>),
	should always assume that the replay protection is enabled on receiving si		should always assume that the replay protection is enabled on the receivin
	de. Thus, the sender should always send the increasing counter values		g side. Thus, the sender should always send the increasing counter values
	and should take care that the counter never wraps around. AH and ESP speci		and should take care that the counter never wraps around. AH and ESP speci
	fications also discuss situations when		fications also discuss situations in which
	replay protection is not possible to achieve even if senders do all as pre		replay protection is not possible to achieve, even if senders do all as pr
	scribed -- like in multicast		escribed -- like in multicast
	Security Associations with multiple unsynchronized senders. Both AH and ES P specifications allow the sender to		Security Associations with multiple unsynchronized senders. Both AH and ES P specifications allow the sender to
	avoid maintaining the counter if the sender has been notified somehow that the anti-replay service		avoid maintaining the counter if the sender has been notified that the ant i-replay service
	is disabled by the receiver or is not possible to achieve.		is disabled by the receiver or is not possible to achieve.
	</t>		</t>
			<t> AH and ESP Security Associations are usually established using IKEv2
	<t> AH and ESP Security Associations are usually established using the Int		<xref target="RFC7296"/>.
	ernet Key Exchange protocol version 2 (IKEv2) <xref target="RFC7296" />.
	The process of SA establishment includes calculation of a shared key and n egotiation of various SA parameters,		The process of SA establishment includes calculation of a shared key and n egotiation of various SA parameters,
	such as cryptographic algorithms. This negotiation in IKEv2 is performed v		such as cryptographic algorithms. This negotiation in IKEv2 is performed v
	ia transforms (see Section 3.3.2 of <xref target="RFC7296" />).		ia transforms (see <xref target="RFC7296" sectionFormat="of" section="3.3.2"/>).
	The type of transform determines what parameter is being negotiated. Each		The type of transform determines what parameter is being negotiated. Each
	transform type has an associated list of possible values		Transform Type has an associated list of possible values
	(called Transform IDs), that determine the possible options for negotiatio		(called Transform IDs) that determine the possible options for negotiation
	n. See <xref target="IKEV2-IANA" /> for the list of transform types		. See <xref target="IKEV2-IANA"/> for the list of Transform Types
	and associated transform IDs.		and associated Transform IDs.
	</t>		</t>
			<t> Transform Type 5 ("Extended Sequence Numbers (ESN)") is used in IKEv2
	<t> Transform type 5 "Extended Sequence Numbers (ESN)" is used in IKEv2 to		to negotiate the way sequence numbers
	negotiate the way sequence numbers		for replay protection are generated, transmitted, and processed in the con
	for replay protection are generated, transmitted and processed in the cont		text of an SA. There are
	ext of an SA. For this transform type		two values are defined for this Transform Type -- "No Extended Sequence Nu
	two values are defined -- "No Extended Sequence Numbers" and "Extended Seq		mbers" and "Extended Sequence Numbers".
	uence Numbers".
	</t>		</t>
			<t> This document updates the IKEv2 specification <xref target="RFC7296"/>
	<t> This document updates IKEv2 specification <xref target="RFC7296" /> by		by renaming Transform Type 5 and the
	renaming transform type 5 and		two associated Transform IDs.
	two associated transform IDs.
	</t>		</t>
	</section>		</section>
			<section anchor="problem">
	<section anchor="problem" title="Problem Description">		<name>Problem Description</name>
	<t> IKEv2 currently has no means to negotiate the case when both peers a		<t> IKEv2 currently has no means to negotiate the case when both peers agr
	gree that replay protection is not needed.		ee that replay protection is not needed.
	Even when both peers locally disable anti-replay service as receivers, t hey still need to maintain increasing sequence numbers		Even when both peers locally disable anti-replay service as receivers, t hey still need to maintain increasing sequence numbers
	as senders, taking care that they never wrap around (see <xref target="I		as senders, taking care that they never wrap around (see <xref target="I
	-D.pan-ipsecme-anti-replay-notification" />).		-D.pan-ipsecme-anti-replay-notification"/>).
	</t>		</t>
			<t> There is also no way to inform receivers that replay protection is not
	<t> There is also no way to inform receivers that replay protection is n		possible for a particular SA
	ot possible for a particular SA
	(for example in case of a multicast SA with several unsynchronized sende rs).		(for example in case of a multicast SA with several unsynchronized sende rs).
	</t>		</t>
			<t>Future IPsec protocols may provide more options for the handling of ant
	<t> Future IPsec security protocols may provide more options for the han		i-replay counters,
	dling of anti-replay counters,		like sending full 64-bit sequence numbers or completely omitting them in
	like sending full 64-bit sequence numbers or completely omitting them in		packets (see <xref target="I-D.klassert-ipsecme-eesp"/>).
	packets (see <xref target="I-D.klassert-ipsecme-eesp" />).
	These options will require means to be negotiated in IKEv2.		These options will require means to be negotiated in IKEv2.
	</t>		</t>
			<t> Transform Type 5 is the best candidate for addressing these issues:
	<t> Transform type 5 is the best candidate for addressing these issues:		it is already used for negotiation of how sequence numbers are handled i
	it is already used for negotiation of how sequence numbers are handled i		n AH and ESP, and
	n AH and ESP and		it is possible to define additional Transform IDs that could be used in
	it is possible to define additional transform IDs that could be used in		the corresponding situations.
	the corresponding situations.		However, the current definition of Transform Type 5 is too narrow -- its
	However, the current definition of transform type 5 is too narrow -- its		name implies that
	name implies that
	this transform can only be used for negotiation of using ESN.		this transform can only be used for negotiation of using ESN.
	</t>		</t>
	</section>		</section>
			<section anchor="clarification">
			<name>Extending the Semantics of Transform Type 5</name>
			<!-- [rfced] Is the second paragraph the current definition? The first paragrap
			h makes us think the definition is current. However, the third paragraph (indic
			ating it needs clarification) makes us think it is the old definition. Please c
			onsider adding text to indicate whether it is the old or new definition.
	<section anchor="clarification" title="Extending the Semantics of Transform		Original:
	Type 5">		3. Extending the Semantics of Transform Type 5
	<t> This document extends the semantics of transform type 5 in IKEv2 to
	the following definition.
	</t>
	<t> Transform type 5 defines the set of properties of sequence numbers o		This document extends the semantics of transform type 5 in IKEv2 to
	f IPsec packets of a given SA when these packets enter the network.		the following definition.
	</t>
	<t> This definition requires some clarifications.		Transform type 5 defines the set of properties of sequence numbers of
	</t>		IPsec packets of a given SA when these packets enter the network.
	<ul>		This definition requires some clarifications.
	<li>
	<t> By "sequence numbers" here we assume logical entities (like
	counters) that can be used for replay protection
	on receiving sides. In particular, these entities are not necess
	arily the content of the Sequence Number field in the IPsec packets,
	but may be constructed using some information, that is not neces
	saryly transmitted.
	</t>
	</li>
	<li>
	<t> The properties are interpreted as a characteristic of IPsec
	SA packets, and not as a result of a sender actions.
	For example, in multicast SA with multiple unsynchronized sender
	s, even if each sender ensures the uniqueness of sequence numbers it generates,
	the uniqueness of sequence numbers for all IPsec packets is not
	guaranteed.
	</t>
	</li>
	<li>
	<t> The properties are defined for the packets just entering the
	network and not for the packets that receivers get.
	This is because network behavior may break some of these propert
	ies (e.g., break sequence numbers uniqueness by packet duplication).
	</t>
	</li>
	<li>
	<t> The properties of sequence numbers are interpreted in a broa
	d sense, that includes the case when sequence numbers are absent.
	</t>
	</li>
	</ul>
	<t> Given this definition, transform type 5 in the IANA registries for I		Perhaps:
	KEv2 <xref target="IKEV2-IANA" /> is renamed from		3. Extending the Semantics of Transform Type 5
	"Extended Sequence Numbers (ESN)" to "Sequence Numbers (SN)" with the me
	aning, that it defines the properties the sequence numbers would have.
	</t>
	<t> It is expected that new transform IDs will be defined for this trans		This document extends the semantics of Transform Type 5 in IKEv2 to
	form type in future		be defined as follows:
	(like in G-IKEv2 <xref target="I-D.ietf-ipsecme-g-ikev2" /> for the case
	of multicast SAs).
	Documents defining new transform IDs should include description of the p
	roperties the sequence numbers
	would have if the new transform ID is selected. In particular, this desc
	ription should include discussion whether these properties
	allow achieving replay protection.
	</t>
	<t> Some existing protocols (like Implicit IV in ESP <xref target="RFC87		Transform Type 5 defines the set of properties of sequence numbers
	50" /> or		of IPsec packets of a given SA when these packets enter the network.
	Aggregation and Fragmentation for ESP <xref target="RFC9347" />) rely on
	properties that are guaranteed
	for the currently defined transform IDs, but this might not be true for
	future transform IDs.
	When a new transform ID is defined, its description should include a di
	scussion about the possibility
	of using this transform ID in protocols, that rely on some particular pr
	operties of sequence numbers.
	</t>
	<t> The two currently defined transform IDs for this transform type defi		The updated definition is clarified as follows:
	ne the following properties of sequence numbers.		-->
	</t>
	<ul>		<t> This document extends the semantics of Transform Type 5 in IKEv2 to th
	<li>		e following definition.
	<t> Value 0 for transform type 5 defines sequence numbers as mon		</t>
	otonically increasing 32-bit counters that are transmitted in the Sequence Numbe		<t> Transform Type 5 defines the set of properties of sequence numbers of
	r		IPsec packets of a given SA when these packets enter the network.
	field of AH and ESP packets. They never wrap around and are guar		</t>
	anteed to be unique, thus they are suitable for replay protection.		<t> This definition requires some clarifications.
	They can also be used with protocols that rely on sequence numbe		</t>
	rs uniqueness (like <xref target="RFC8750" />) or their		<ul>
	monotonic increase (like <xref target="RFC9347" />). The sender		<li>
	and the receiver actions are defined		<!-- [rfced] We are having trouble parsing this sentence. Please provide an upd
	in Sections 3.3.2 and 3.4.3 of <xref target="RFC4302" /> for AH		ate if our suggested text is incorrect.
	and in Sections 3.3.3 and 3.4.3 of <xref target="RFC4303" /> for ESP.
	</t>
	</li>
	<li>
	<t> Value 1 for transform type 5 defines sequence numbers as mon
	otonically increasing 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 bits are implicitly determined on receivers
	based on previously received packets. The sequence numbers never
	wrap around and are guaranteed to be unique,
	thus they are suitable for replay protection. They can also be u
	sed with protocols that rely on sequence numbers uniqueness
	(like <xref target="RFC8750" />) or their monotonic increase (li
	ke <xref target="RFC9347" />). To be able to correctly
	process the incoming packets on receivers the packets must be au
	thenticated (even when the replay protection is not used).
	The sender and the receiver actions are defined in Sections 3.3.
	2 and 3.4.3 of <xref target="RFC4302" /> for AH
	and in Sections 3.3.3 and 3.4.3 of <xref target="RFC4303" /> for
	ESP.
	</t>
	</li>
	</ul>
	<t> Given the descriptions above and the new definition of transform typ		Original:
	e 5, the two currently defined transform IDs		* By "sequence numbers" here we assume logical entities (like
	are renamed to better reflect the properties of sequence numbers they as		counters) that can be used for replay protection on receiving
	sume.		sides. In particular, these entities are not necessarily the
	</t>		content of the Sequence Number field in the IPsec packets, but may
			be constructed using some information, that is not necessaryly
			transmitted.
	<ul>		Perhaps:
	<li><t> Transform ID 0 is renamed from "No Extended Sequence Numbers		* The use of "sequence numbers" implies that logical entities (like
	" to "32-bit Sequential Numbers".</t></li>		counters) can be used for replay protection on receiving
	<li><t> Transform ID 1 is renamed from "Extended Sequence Numbers" t		sides. In particular, these entities are not necessarily the
	o "Partially Transmitted 64-bit Sequential Numbers".</t></li>		content of the Sequence Number field in the IPsec packets, as they
	</ul>		may be constructed using some information that is not transmitted.
			-->
	<t> Note, that the above descriptions do not change the existing semanti		<t> By "sequence numbers" here we assume logical entities (like
	cs of these transform IDs, they only provide clarification.		counters) that can be used for replay protection on receiving
	Note also, that ESP and AH packet processing for these transform IDs is		sides. In particular, these entities are not necessarily the content
	not affected, and bits on the wire do not change.		of the Sequence Number field in the IPsec packets, but may be
	</t>		constructed using some information, that is not necessarily
	</section>		transmitted.
			</t>
			</li>
			<li>
			<!-- [rfced] We have updated this sentence as described below. Please let us kn
			ow if any corrections are needed.
	<section title="Security Considerations">		Original:
	<t> This document does not affect security of the AH, ESP and IKEv2 prot		* The properties are interpreted as a characteristic of IPsec SA
	ocols.		packets, and not as a result of a sender actions.
	</t>
	</section>
	<section anchor="IANA" title="IANA Considerations">		Current:
	<t> This document makes the following changes in the "Internet Key Exchang		* The properties are interpreted as characteristics of IPsec SA
	e Version 2 (IKEv2) Parameters" IANA registries		packets rather than the results of sender actions.
	<xref target="IKEV2-IANA" />. It is assumed that RFCXXXX refers to this sp		-->
	ecification.
			<t> The properties are interpreted as characteristics of IPsec SA
			packets rather than the results of sender actions. For example, in
			multicast SA with multiple unsynchronized senders, even if each
			sender ensures the uniqueness of sequence numbers it generates, the
			uniqueness of sequence numbers for all IPsec packets is not
			guaranteed.
			</t>
			</li>
			<li>
			<t> The properties are defined for the packets just entering the
			network and not for the packets that receivers get. This is because
			network behavior may break some of these properties (e.g., packet dupl
			ication would break sequence number uniqueness).
			</t>
			</li>
			<li>
			<t> The properties of sequence numbers are interpreted in a broad
			sense, which includes the case when sequence numbers are absent.
			</t>
			</li>
			</ul>
			<!-- [rfced] For readability, we have updated the sentence as shown below. Plea
			se let us know if any corrections are needed. In addition, please consider whet
			her the abbreviated form of "SN" should be plural (i.e., Sequence Numbers (SNs)
			- we recognize that ESN was singular even though "Numbers" was plural).
			Original:
			Given this definition, transform type 5 in the IANA registries for
			IKEv2 [IKEV2-IANA] is renamed from "Extended Sequence Numbers (ESN)"
			to "Sequence Numbers (SN)" with the meaning, that it defines the
			properties the sequence numbers would have.
			Current:
			Given this updated definition, Transform Type 5 in the "Transform Type
			Values" registry [IKEV2-IANA] has been renamed from "Extended Sequence
			Numbers (ESN)" to "Sequence Numbers (SN)".
			-->
			<t> Given this updated definition, Transform Type 5 in the "Transform Type
			Values" registry <xref target="IKEV2-IANA"/> has been renamed from
			"Extended Sequence Numbers (ESN)" to "Sequence Numbers (SN)".
			</t>
			<t> It is expected that new Transform IDs will be defined for this Transfo
			rm Type in the future
			(like in G-IKEv2 <xref target="I-D.ietf-ipsecme-g-ikev2"/> for the case
			of multicast SAs).
			Documents defining new Transform IDs should include descriptions of the
			properties the sequence numbers
			would have if the new Transform ID was selected. In particular, the desc
			riptions should include discussion of whether these properties
			allow replay protection to be achieved.
			</t>
			<t> Some existing protocols (like Implicit IV in ESP <xref target="RFC8750
			"/> or
			Aggregation and Fragmentation for ESP <xref target="RFC9347"/>) rely on
			properties that are guaranteed
			for the currently defined Transform IDs; however, this might not be true
			for future Transform IDs.
			When a new Transform ID is defined, its description should include disc
			ussion about the possibility
			of using the Transform ID in protocols that rely on some particular prop
			erties of sequence numbers.
			</t>
			<t>The two currently defined Transform IDs for Transform Type 5 define the
			following properties of sequence numbers.
	</t>		</t>
	<ul>		<ul>
	<li><t>The existing transform type 5 "Extended Sequence Numbers (ESN)"		<li>
	in the "Transform Type Values" registry		<!-- [rfced] "their monotonic increase" is not easily parsed. May we update as f
	is renamed to "Sequence Numbers (SN)".		ollows for readability?
	</t></li>		Note that this text appears in the definitions for values 0 and 1.
	<li><t>Appended [RFCXXXX] to the Reference column of Transform Type 5
	in the "Transform Type Values" registry.</t></li>
	<li><t>Added this note to the "Transform Type Values" registry:</t>		Original:
			They can also be used with protocols that rely
			on sequence numbers uniqueness (like [RFC8750]) or their monotonic
			increase (like [RFC9347]).
	<t>"Sequence Numbers (SN)" transform type was originally named "Extend		Perhaps:
	ed Sequence Numbers (ESN)" and was referenced by that name		They can also be used with protocols that rely
	in a number of RFCs published prior to [RFCXXXX], which gave it the cu		on sequence numbers uniqueness (e.g., [RFC8750]) or monotonically
	rrent title.		increasing sequence numbers (e.g., [RFC9347]).
	</t>		-->
	</li>
	<li><t>The "Transform Type 5 - Extended Sequence Numbers Transform IDs		<t> Value 0 defines sequence numbers as
	" registry is renamed to		monotonically increasing 32-bit counters that are transmitted in the
	"Transform Type 5 - Sequence Numbers Transform IDs".		Sequence Number field of AH and ESP packets. They never wrap around
			and are guaranteed to be unique, thus they are suitable for replay
			protection. They can also be used with protocols that rely on
			sequence number uniqueness (e.g., <xref target="RFC8750"/>) or their
			monotonic increase (e.g., <xref target="RFC9347"/>). The sender and
			the receiver actions are defined in Sections <xref target="RFC4302"
			sectionFormat="bare" section="3.3.2"/> and <xref target="RFC4302"
			sectionFormat="bare" section="3.4.3"/> of <xref target="RFC4302"/>
			for AH and in Sections <xref target="RFC4303" sectionFormat="bare"
			section="3.3.3"/> and <xref target="RFC4303" sectionFormat="bare"
			section="3.4.3"/> of <xref target="RFC4303"/> for ESP.
	</t>		</t>
	</li>		</li>
			<li>
	<li><t>The "Reserved" (2-65535) range of numbers in what was the "Tran		<t> Value 1 defines sequence numbers as
	sform Type 5 -		monotonically increasing 64-bit counters. The low-order 32 bits are
	Extended Sequence Numbers Transform IDs" registry is split into the		transmitted in the Sequence Number field of AH and ESP packets, and
	"Unassigned" (2-1023) and the "Reserved for Private Use" (1024-65535)		the high-order 32 bits are implicitly determined on receivers based
	ranges, as shown below.		on previously received packets. The sequence numbers never wrap
			around and are guaranteed to be unique, thus they are suitable for
			replay protection. They can also be used with protocols that rely on
			sequence number uniqueness (e.g., <xref target="RFC8750"/>) or their
			monotonic increase (e.g., <xref target="RFC9347"/>). To
			correctly process the incoming packets on receivers, the packets must
			be authenticated (even when the replay protection is not used). The
			sender and the receiver actions are defined in Sections <xref
			target="RFC4302" sectionFormat="bare" section="3.3.2"/> and <xref
			target="RFC4302" sectionFormat="bare" section="3.4.3"/> of <xref
			target="RFC4302"/> for AH and in Sections <xref target="RFC4303"
			sectionFormat="bare" section="3.3.3"/> and <xref target="RFC4303"
			sectionFormat="bare" section="3.4.3"/> of <xref target="RFC4303"/>
			for ESP.
	</t>		</t>
			</li>
			</ul>
			<t> Given the descriptions above and the new definition of Transform Type
			5, the two currently defined Transform IDs
			are renamed to better reflect the properties of sequence numbers they as
			sume.
			</t>
	<figure align="center">		<ul>
	<artwork align="left"><![CDATA[		<li>
	Number Name Reference		<t> Transform ID 0 is renamed from "No Extended Sequence Numbers" to
	2-1023 Unassigned		"32-bit Sequential Numbers".</t>
	1024-65535 Reserved for Private Use [RFCXXXX]		</li>
	]]></artwork>		<li>
	</figure>		<t> Transform ID 1 is renamed from "Extended Sequence Numbers" to
	</li>		"Partially Transmitted 64-bit Sequential Numbers".</t>
			</li>
			</ul>
			<t> Note that the above descriptions do not change the existing
			semantics of these Transform IDs, they only provide clarification. Also n
			ote that ESP and AH packet processing for these Transform IDs is not
			affected, and bits on the wire do not change.
			</t>
			</section>
			<section>
			<name>Security Considerations</name>
			<t> This document does not affect security of the AH, ESP, and IKEv2 proto
			cols.
			</t>
			</section>
			<section anchor="IANA">
			<name>IANA Considerations</name>
			<!-- [rfced] Note that we have updated the IANA Considerations to reduce redunda
			ncy throughout. Please review carefully and let us know if any updates are need
			ed.
	<li><t>The existing Transform ID 0 "No Extended Sequence Numbers" in w		You can review the changes by looking through a diff of the IANA Considerations
	hat was the "Transform Type 5 - Extended Sequence Numbers Transform IDs" registr		section:
	y		https://www.rfc-editor.org/authors/rfc9827-diff.html
	is renamed to "32-bit Sequential Numbers".		https://www.rfc-editor.org/authors/rfc9827-rfcdiff.html (side-by-side view)
	</t></li>		-->
	<li><t>The existing Transform ID 1 "Extended Sequence Numbers" in what		<t> This document makes changes to registries within the "Internet Key Exc
	was the "Transform Type 5 - Extended Sequence Numbers Transform IDs" registry		hange Version 2 (IKEv2) Parameters" registry group
	is renamed to "Partially Transmitted 64-bit Sequential Numbers".		<xref target="IKEV2-IANA"/>.
	</t></li>		</t>
	<li><t>Appended [RFCXXXX] to the Reference column of Transform ID 0 an		<t>The "Transform Type Values" registry has been updated as follows: </t>
	d Transform ID 1 in what was the		<ul>
	"Transform Type 5 - Extended Sequence Numbers Transform IDs" registry.		<li>
	</t></li>		<t>renamed Transform Type 5 from "Extended Sequence Numbers (ESN)"
			to "Sequence Numbers (SN)".
			</t>
			</li>
			<li>
			<t>added as a reference to this RFC for Transform Type 5.</t>
			</li>
			<li>
			<!-- notify IANA regarding the changes to the notes displayed in the registries.
			-->
			<t>added the following note:</t>
			<blockquote><t>The "Sequence Numbers (SN)" Transform Type was origin
			ally named
			"Extended Sequence Numbers (ESN)" and was referenced by that name
			in a number of RFCs published prior to [RFC9827], which gave it
			the current title.</t></blockquote>
			</li>
			</ul>
			<t>The "Transform Type 5 - Extended Sequence Numbers Transform IDs" registry has
			been updated as follows: </t>
	<li><t>Added these notes to what was the "Transform Type 5 - Extended Sequence Numbers Transform IDs" registry:</t>		<ul>
	<t>This registry was originally named "Transform Type 5 - Extended Seq		<li>
	uence Numbers Transform IDs" and		<t>renamed the registry from "Transform Type 5 - Extended Sequence Num
	was referenced using that name in a number of RFCs published prior to		bers Transform IDs" to
	[RFCXXXX], which gave it the current title.		"Transform Type 5 - Sequence Numbers Transform IDs" and added this doc
			ument as a reference.
	</t>		</t>
			</li>
			<li><t>split the "Reserved" (2-65535) range of numbers as shown below.</
			t>
	<t>"32-bit Sequential Numbers" transform ID was originally named "No E		<table>
	xtended Sequence Numbers" and was referenced by that name		<thead>
	in a number of RFCs published prior to [RFCXXXX], which gave it the cu		<tr>
	rrent title.		<th>Number</th>
	</t>		<th>Name</th>
			<th>Reference</th>
			</tr>
			</thead>
			<tbody>
			<tr>
			<td>2-1023</td>
			<td colspan="2">Unassigned</td>
			</tr>
			<tr>
			<td>1024-65535</td>
			<td>Reserved for Private Use</td>
			<td>[RFC9827]</td>
			</tr>
			</tbody>
			</table>
			</li>
	<t>"Partially Transmitted 64-bit Sequential Numbers" transform ID was		<li>
	originally named "Extended Sequence Numbers" and was referenced by that name		<t>renamed Transform ID 0 from "No Extended Sequence Numbers"
	in a number of RFCs published prior to [RFCXXXX], which gave it the cu		to "32-bit Sequential Numbers".
	rrent title.
	</t>		</t>
			</li>
	<t>Numbers in the range 2-65535 were originally marked as "Reserved" a		<li>
	nd were re-classified		<t>renamed Transform ID 1 from "Extended Sequence Numbers"
	as "Unassigned" and "Reserved for Private Use" by [RFCXXXX].		to "Partially Transmitted 64-bit Sequential Numbers".
	</t>		</t>
	</li>		</li>
			<li>
			<t>added a reference to this RFC for Transform ID 0 and Transform ID 1
			.</t>
			</li>
			<li>
			<t>added the the following registry notes:</t>
			<blockquote><t>This registry was originally named "Transform Type 5 -
			Extended
			Sequence Numbers Transform IDs" and was referenced using that name
			in a number of RFCs published prior to [RFC9827], which gave it the
			current title.
			</t></blockquote>
			<blockquote><t>The "32-bit Sequential Numbers" Transform ID was origin
			ally 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.
			</t></blockquote>
			<blockquote><t>The "Partially Transmitted 64-bit Sequential Numbers" T
			ransform ID
			was originally named "Extended Sequence Numbers" and was referenced
			by that name in a number of RFCs published prior to [RFC9827], which
			gave it the current title.
			</t></blockquote>
			<blockquote><t>Numbers in the range 2-65535 were originally marked
			as "Reserved" and were reclassified as "Unassigned" and "Reserved
			for Private Use" by [RFC9827].
			</t></blockquote>
			</li>
	</ul>		</ul>
	</section>		</section>
			</middle>
	<section anchor="Acknowledgements" title="Acknowledgements">		<back>
	<t>This document was created as a result of discussions with Russ Housley,		<displayreference target="I-D.ietf-ipsecme-g-ikev2" to="G-IKEv2"/>
	Tero Kivinen, Paul Wouters and Antony Antony		<displayreference target="I-D.klassert-ipsecme-eesp" to="EESP"/>
	about the best way to extend the meaning of the Extended Sequence Numbers		<displayreference target="I-D.pan-ipsecme-anti-replay-notification" to="ANTIREPL
	transform in IKEv2.		AY"/>
			<references>
			<name>References</name>
			<references>
			<name>Normative References</name>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
			301.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
			302.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
			303.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
			296.xml"/>
			<reference anchor="IKEV2-IANA" target="http://www.iana.org/assignments/i
			kev2-parameters">
			<front>
			<title>Internet Key Exchange Version 2 (IKEv2) Parameters</title>
			<author>
			<organization>IANA</organization>
			</author>
			<date/>
			</front>
			</reference>
			</references>
			<references>
			<name>Informative References</name>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
			750.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
			347.xml"/>
			<!-- [I-D.ietf-ipsecme-g-ikev2]
			draft-ietf-ipsecme-g-ikev2-21
			-->
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
			ietf-ipsecme-g-ikev2.xml"/>
			<!-- [I-D.klassert-ipsecme-eesp]
			draft-klassert-ipsecme-eesp-02
			-->
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
			klassert-ipsecme-eesp.xml"/>
			<!-- [I-D.pan-ipsecme-anti-replay-notification]
			draft-pan-ipsecme-anti-replay-notification-01
			expired -->
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
			pan-ipsecme-anti-replay-notification.xml"/>
			</references>
			</references>
			<section anchor="Acknowledgements" numbered="false">
			<name>Acknowledgements</name>
			<t>This document was created as a result of discussions with <contact
			fullname="Russ Housley"/>, <contact fullname="Tero Kivinen"/>, <contact
			fullname="Paul Wouters"/>, and <contact fullname="Antony Antony"/> about
			the best way to extend the meaning of the Extended Sequence Numbers
			transform in IKEv2.
	</t>		</t>
	</section>		</section>
	</middle>		</back>
	<back>		<!-- [rfced] Throughout the text, the following terminology appears to be used
	<references title="Normative References">		inconsistently. We updated to use the form on the left to align with RFC 7296.
	<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.43		Please let us know any objections.
	01.xml"?>
	<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.43		Transform Type vs transform type
	02.xml"?>		Transform ID vs transform ID
	<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.43		-->
	03.xml"?>
	<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.72		<!-- [rfced] Please review the "Inclusive Language" portion of the online
	96.xml"?>		Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
	<reference anchor="IKEV2-IANA"		and let us know if any changes are needed. Updates of this nature typically
	target="http://www.iana.org/assignments/ikev2-parameters/ikev2-		result in more precise language, which is helpful for readers.
	parameters.xhtml">
	<front>		Note that our script did not flag any words in particular, but this should
	<title>Internet Key Exchange Version 2 (IKEv2) Parameters</title>		still be reviewed as a best practice.
	<author>		-->
	<organization>IANA</organization>
	</author>
	<date />
	</front>
	</reference>
	</references>
	<references title="Informative References">
	<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.87
	50.xml"?>
	<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.93
	47.xml"?>
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference
	.I-D.ietf-ipsecme-g-ikev2.xml"?>
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference
	.I-D.klassert-ipsecme-eesp.xml"?>
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference
	.I-D.pan-ipsecme-anti-replay-notification.xml"?>
	</references>
	</back>
	</rfc>		</rfc>
End of changes. 63 change blocks.
	340 lines changed or deleted		489 lines changed or added
This html diff was produced by rfcdiff 1.48.