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 July 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 Number (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. the following definition.
Transform type 5 defines the set of properties of sequence numbers of Transform Type 5 defines the set of properties of sequence numbers of
IPsec packets of a given SA when these packets enter the network. IPsec packets of a given SA when these packets enter the network.
This definition requires some clarifications. This definition requires some clarifications.
* By "sequence numbers" here we assume logical entities (like * By "sequence numbers" here we assume logical entities (like
counters) that can be used for replay protection on receiving counters) that can be used for replay protection on receiving
sides. In particular, these entities are not necessarily the sides. In particular, these entities are not necessarily the
content of the Sequence Number field in the IPsec packets, but may content of the Sequence Number field in the IPsec packets, but may
be constructed using some information, that is not necessaryly be constructed using some information, that is not necessarily
transmitted. 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)".
properties the sequence numbers would have.
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
define the following properties of sequence numbers.
* Value 0 for transform type 5 defines sequence numbers as The two currently defined Transform IDs for Transform Type 5 define
monotonically increasing 32-bit counters that are transmitted in the following properties of sequence numbers.
the 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 numbers uniqueness (like [RFC8750]) or their monotonic
increase (like [RFC9347]). The sender and the receiver actions
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.
* Value 1 for transform type 5 defines sequence numbers as * Value 0 defines sequence numbers as monotonically increasing
monotonically increasing 64-bit counters. The low-order 32 bits 32-bit counters that are transmitted in the Sequence Number field
are transmitted in the Sequence Number field of AH and ESP packets of AH and ESP packets. They never wrap around and are guaranteed
and the high-order 32 bits are implicitly determined on receivers to be unique, thus they are suitable for replay protection. They
based on previously received packets. The sequence numbers never can also be used with protocols that rely on sequence number
wrap around and are guaranteed to be unique, thus they are uniqueness (e.g., [RFC8750]) or their monotonic increase (e.g.,
suitable for replay protection. They can also be used with [RFC9347]). The sender and the receiver actions are defined in
protocols that rely on sequence numbers uniqueness (like
[RFC8750]) or their monotonic increase (like [RFC9347]). To be
able 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 3.3.2 and 3.4.3 of [RFC4302] for AH and in Sections 3.3.3 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. and 3.4.3 of [RFC4303] for ESP.
Given the descriptions above and the new definition of transform type * Value 1 defines sequence numbers as monotonically increasing
5, the two currently defined transform IDs are renamed to better 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 used with protocols that rely on
sequence number uniqueness (e.g., [RFC8750]) or their monotonic
increase (e.g., [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 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.
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 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] [ANTIREPLAY]
Smyslov, V. and B. Weis, "Group Key Management using Pan, W., He, Q., and P. Wouters, "IKEv2 Support for Anti-
IKEv2", Work in Progress, Internet-Draft, draft-ietf- Replay Status Notification", Work in Progress, Internet-
ipsecme-g-ikev2-21, 10 February 2025, Draft, draft-pan-ipsecme-anti-replay-notification-01, 21
<https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme- October 2024, <https://datatracker.ietf.org/doc/html/
g-ikev2-21>. draft-pan-ipsecme-anti-replay-notification-01>.
[I-D.klassert-ipsecme-eesp] [EESP] Klassert, S., Antony, A., and C. Hopps, "Enhanced
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-klassert-ipsecme-eesp-02, 26
February 2025, <https://datatracker.ietf.org/doc/html/ February 2025, <https://datatracker.ietf.org/doc/html/
draft-klassert-ipsecme-eesp-02>. draft-klassert-ipsecme-eesp-02>.
[I-D.pan-ipsecme-anti-replay-notification] [G-IKEv2] Smyslov, V. and B. Weis, "Group Key Management using
Pan, W., He, Q., and P. Wouters, "IKEv2 Support for Anti- IKEv2", Work in Progress, Internet-Draft, draft-ietf-
Replay Status Notification", Work in Progress, Internet- ipsecme-g-ikev2-22, 16 March 2025,
Draft, draft-pan-ipsecme-anti-replay-notification-01, 21 <https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-
October 2024, <https://datatracker.ietf.org/doc/html/ g-ikev2-22>.
draft-pan-ipsecme-anti-replay-notification-01>.
[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. 62 change blocks. 
224 lines changed or deleted 211 lines changed or added

This html diff was produced by rfcdiff 1.48.