rfc9827v3.txt   rfc9827.txt 
Internet Engineering Task Force (IETF) V. Smyslov Internet Engineering Task Force (IETF) V. Smyslov
Request for Comments: 9827 ELVIS-PLUS Request for Comments: 9827 ELVIS-PLUS
Updates: 7296 August 2025 Updates: 7296 November 2025
Category: Standards Track Category: Standards Track
ISSN: 2070-1721 ISSN: 2070-1721
Renaming the Extended Sequence Numbers (ESN) Transform Type in the Renaming the Extended Sequence Numbers (ESN) Transform Type in the
Internet Key Exchange Protocol Version 2 (IKEv2) Internet Key Exchange Protocol Version 2 (IKEv2)
Abstract Abstract
This document clarifies and extends the meaning of Transform Type 5 This document clarifies and extends the meaning of Transform Type 5
in Internet Key Exchange Protocol Version 2 (IKEv2). It updates RFC in Internet Key Exchange Protocol Version 2 (IKEv2). It updates RFC
skipping to change at line 178 skipping to change at line 178
network and not for the packets that receivers get. This is network and not for the packets that receivers get. This is
because network behavior may break some of these properties (e.g., because network behavior may break some of these properties (e.g.,
packet duplication would break sequence number uniqueness). packet duplication would break sequence number uniqueness).
* The properties of sequence numbers are interpreted in a broad * The properties of sequence numbers are interpreted in a broad
sense, which includes the case when sequence numbers are absent. sense, which includes the case when sequence numbers are absent.
Given this updated definition, Transform Type 5 in the "Transform Given this updated definition, Transform Type 5 in the "Transform
Type Values" registry [IKEV2-IANA] has been renamed from "Extended Type Values" registry [IKEV2-IANA] has been renamed from "Extended
Sequence Numbers (ESN)" to "Sequence Numbers (SN)" in the sense that Sequence Numbers (ESN)" to "Sequence Numbers (SN)" in the sense that
it defines the properties of the sequence numbers in a broad sense. it defines the properties of the sequence numbers in general.
It is expected that new Transform IDs will be defined for this It is expected that new Transform IDs will be defined for this
Transform Type in the future (like in G-IKEv2 [G-IKEv2] for the case Transform Type in the future (like in G-IKEv2 [RFC9838] for the case
of multicast SAs). Documents defining new Transform IDs should of multicast SAs). Documents defining new Transform IDs should
include descriptions of the properties the sequence numbers would include descriptions of the properties the sequence numbers would
have if the new Transform ID was selected. In particular, the have if the new Transform ID was selected. In particular, the
descriptions should include discussion of whether these properties descriptions should include discussion of whether these properties
allow replay protection to be achieved. allow replay protection to be achieved.
Some existing protocols (like Implicit IV in ESP [RFC8750] or Some existing protocols (like Implicit IV in ESP [RFC8750] or
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; however, that are guaranteed for the currently defined Transform IDs; however,
this might not be true for future Transform IDs. When a new this might not be true for future Transform IDs. When a new
skipping to change at line 348 skipping to change at line 348
[ANTIREPLAY] [ANTIREPLAY]
Pan, W., He, Q., and P. Wouters, "IKEv2 Support for Anti- Pan, W., He, Q., and P. Wouters, "IKEv2 Support for Anti-
Replay Status Notification", Work in Progress, Internet- Replay Status Notification", Work in Progress, Internet-
Draft, draft-pan-ipsecme-anti-replay-notification-01, 21 Draft, draft-pan-ipsecme-anti-replay-notification-01, 21
October 2024, <https://datatracker.ietf.org/doc/html/ October 2024, <https://datatracker.ietf.org/doc/html/
draft-pan-ipsecme-anti-replay-notification-01>. draft-pan-ipsecme-anti-replay-notification-01>.
[EESP] Klassert, S., Antony, A., and C. Hopps, "Enhanced [EESP] Klassert, S., Antony, A., and C. Hopps, "Enhanced
Encapsulating Security Payload (EESP)", Work in Progress, Encapsulating Security Payload (EESP)", Work in Progress,
Internet-Draft, draft-ietf-ipsecme-eesp-01, 3 July 2025, Internet-Draft, draft-ietf-ipsecme-eesp-02, 19 October
<https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme- 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
eesp-01>. ipsecme-eesp-02>.
[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>.
[RFC9838] Smyslov, V. and B. Weis, "Group Key Management Using the
Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 9838, DOI 10.17487/RFC9838, November 2025,
<https://www.rfc-editor.org/info/rfc9838>.
Acknowledgements Acknowledgements
This document was created as a result of discussions with Russ This document was created as a result of discussions with Russ
Housley, Tero Kivinen, Paul Wouters, and Antony Antony about the best Housley, Tero Kivinen, Paul Wouters, and Antony Antony about the best
way to extend the meaning of the Extended Sequence Numbers transform way to extend the meaning of the Extended Sequence Numbers transform
in IKEv2. in IKEv2.
Author's Address Author's Address
Valery Smyslov Valery Smyslov
 End of changes. 5 change blocks. 
12 lines changed or deleted 11 lines changed or added

This html diff was produced by rfcdiff 1.48.