Network Working Group V. Smyslov Internet-Draft ELVIS-PLUS Updates: 7296 (if approved) 5 December 2024 Intended status: Informational Expires: 8 June 2025 Renaming Extended Sequence Number (ESN) Transform Type in the Internet Key Exchange Protocol Version 2 (IKEv2) draft-ietf-ipsecme-ikev2-rename-esn-00 Abstract This documents clarifies and extends the meaning of transform type 5 in IKEv2. It updates RFC 7296 by renaming the transform type 5 from "Extended Sequence Numbers (ESN)" to "Sequence Numbers Properties (SNP)". It also renames two currently defined values for this transform type: 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 Numbers". Status of This Memo This Internet-Draft is submitted in full conformance with the 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 8 June 2025. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components Smyslov Expires 8 June 2025 [Page 1] Internet-Draft Renaming ESN in IKEv2 December 2024 extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Problem Description . . . . . . . . . . . . . . . . . . . . . 3 3. Extending the Semantics of Transform Type 5 . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction IP Security (IPsec) Architecture [RFC4301] defines a set of security services provided by IPsec protocols Authentication Header (AH) [RFC4302] and Encapsulating Security Payload (ESP) [RFC4303]. One of these services is anti-replay protection. In IPsec the anti-replay protection service is optional, each receiver of AH and ESP packets individually selects whether to enable it. The anti-replay protection in AH and ESP is achieved by means of a monotonically increasing counter that never wraps around, which is sent in each AH or ESP packet in the Sequence Number field. The receiver maintains sliding window that allows to detect duplicate packets. Both AH and ESP allow to use either a 32-bit counter or a 64-bit counter. The latter case is referred to as Extended Sequence Numbers (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 the high-order 32 bits of the counter are not transmitted and are instead deducted on the receiver based on previously received packets. Since the decision whether to enable anti-replay protection is ultimately taken by the receiver, the sender in accordance with AH ([RFC4302] Section 3.3.2) and ESP ([RFC4303] Section 3.3.3) specifications should always assume that the replay protection is enabled on receiving side. Thus the sender should always send the increasing counter values and should take care that the counter never wraps around. AH and ESP specifications also discuss situations when anti-replay protection is not possible to achieve even if senders do all as prescribed -- like in multicast Security Associations (SAs) with multiple unsynchronized senders. Both AH and ESP specifications Smyslov Expires 8 June 2025 [Page 2] Internet-Draft Renaming ESN in IKEv2 December 2024 allow the sender to relax their duties of maintaining the counter if there is a way to notify the sender that the anti-replay protection is disabled by the receiver or is not possible to achieve. AH and ESP rely on the Internet Key Exchange protocol version 2 (IKEv2) [RFC7296] for establishing Security Associations. The process of SA establishment includes calculation of a shared key and negotiation of various SA parameters, such as cryptographic algorithms. This negotiation in IKEv2 is performed via so called transforms (see Section 3.3.2 of [RFC7296]). The type of transform determines what parameter is being negotiated. Each transform type has an associated list of possible values (called Transform IDs), that determine the possible options for negotiation. See [IKEV2-IANA] for the list of transform types and associated transform IDs. Transform type 5 "Extended Sequence Numbers (ESN)" is used in IKEv2 to negotiate the way sequence numbers for anti-replay protection are generated, transmitted and processed in the context of an SA. For this transform type two values are defined -- "No Extended Sequence Numbers" and "Extended Sequence Numbers". 2. Problem Description IKEv2 currently has no means to negotiate the case when both peers agree that anti-replay protection is not needed. Even when both peers locally disable anti-replay service as receivers, they still need to maintain increasing sequence numbers as senders, taking care that they never wrap around (see [I-D.pan-ipsecme-anti-replay-notification]). There is also no way to inform receivers that anti-replay protection is not possible for a particular SA (for example in case of a multicast SA with several unsynchronized senders). Future IPsec security protocols may provide more options for the handling of anti-replay protection counters, like sending full 64-bit sequence numbers or completely omitting them in packets (see [I-D.klassert-ipsecme-eesp]). These options will require means to be negotiated in IKEv2. Transform type 5 looks like an appropriate candidate for addressing these issues: it is already used for negotiation of how sequence numbers are handled in AH and ESP and it is possible to define additional transform IDs that could be used in the corresponding situations. However, the current definition of transform type 5 is too narrow -- its name implies that this transform can only be used for negotiation of using ESN. Smyslov Expires 8 June 2025 [Page 3] Internet-Draft Renaming ESN in IKEv2 December 2024 3. Extending the Semantics of Transform Type 5 This document extends the semantics of transform type 5 in IKEv2 to the following definition. Transform type 5 defines the set of properties of sequence numbers of IPsec packets of a given SA when these packets enter the network. This definition requires some clarifications. * By "sequence numbers" here we assume logical entities (like counters) that can be used for anti-replay protection on receiving sides. In particular, these entities are not necessary the content of the Sequence Number field in the IPsec packets, but may be constructed using some information, that is not necessary transmitted. * 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 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. * 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., break sequence numbers uniqueness by packet duplication). * The properties of sequence numbers are interpreted in a broad sense, that includes the case when sequence numbers are absent. Given this definition, transform type 5 in the IANA registries for IKEv2 [IKEV2-IANA] is renamed from "Extended Sequence Numbers (ESN)" to "Sequence Numbers Properties (SNP)". Smyslov Expires 8 June 2025 [Page 4] Internet-Draft Renaming ESN in IKEv2 December 2024 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] for the case of multicast SAs). Documents defining new transform IDs should include description of the properties the sequence numbers would have if the new transform ID is selected. In particular, this description should include discussion whether these properties allow to achieve anti-replay protection. Some existing protocols (like Implicit IV in ESP [RFC8750] or Aggregation and Fragmentation for ESP [RFC9347]) rely on properties that are guaranteed for the currently defined transform IDs, but this might not be true for other transform IDs. The description of the sequence numbers properties for a new transform ID should also include discussion whether these protocols can be used if this transform ID is selected. The two currently defined transform IDs for this transform type have the following sequence numbers properties. * Transform ID 0 defines sequence numbers as monotonically increasing 32-bit counters that are transmitted in the Sequence Number field of AH and ESP packets. They never wrap around and are guaranteed to be unique, thus they are suitable for anti- 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. * Transform ID 1 defines sequence numbers as monotonically 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 anti-replay protection. They can also be used with 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 anti-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. * Transform ID 0 is renamed from "No Extended Sequence Numbers" to "32-bit Sequential Numbers". Smyslov Expires 8 June 2025 [Page 5] Internet-Draft Renaming ESN in IKEv2 December 2024 * Transform ID 1 is renamed from "Extended Sequence Numbers" to "Partially Transmitted 64-bit Sequential Numbers". Note, that the above descriptions do not change the existing semantics of these transform IDs, they only provide clarification. Note also, that ESP and AH packet processing for these transform IDs is not affected, and bits on the wire do not change. 4. Security Considerations This document clarifies and extends the meaning of Transform Type 5 in the IKEv2 IANA registries and also renames it to reflect the new definition. It also renames two currently allocated values for this transform type to better reflect their existing semantics, which this document preserves. These actions do not affect security of the AH, ESP and IKEv2 protocols. 5. IANA Considerations This document makes the following changes in the "Internet Key Exchange Version 2 (IKEv2) Parameters" IANA registries [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 is renamed to "Sequence Numbers Properties (SNP)". * Appended [RFCXXXX] to the Reference column of Transform Type 5 in the "Transform Type Values" registry. * Added this note to the "Transform Type Values" registry: "Sequence Numbers Properties (SNP)" transform type was originally named "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" registry is renamed to "Transform Type 5 - Sequence Numbers Properties Transform IDs". * The existing Transform ID 0 "No Extended Sequence Numbers" in what was the "Transform Type 5 - Extended Sequence Numbers Transform IDs" registry is renamed to "32-bit Sequential Numbers". Smyslov Expires 8 June 2025 [Page 6] Internet-Draft Renaming ESN in IKEv2 December 2024 * The existing Transform ID 1 "Extended Sequence Numbers" in what was the "Transform Type 5 - Extended Sequence Numbers Transform IDs" registry is renamed to "Partially Transmitted 64-bit Sequential Numbers". * Appended [RFCXXXX] to the Reference column of Transform ID 0 and 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 Sequence Numbers Transform IDs" registry: 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 [RFCXXXX], which gave it the current title. "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 [RFCXXXX], which gave it the current title. "Partially Transmitted 64-bit Sequential Numbers" transform ID was 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. 6. 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. 7. References 7.1. Normative References [IKEV2-IANA] IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters", . [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . Smyslov Expires 8 June 2025 [Page 7] Internet-Draft Renaming ESN in IKEv2 December 2024 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, . [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, . [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, . 7.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-17, 19 November 2024, . [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-01, 14 October 2024, . [I-D.pan-ipsecme-anti-replay-notification] Pan, W., He, Q., and P. Wouters, "IKEv2 Support for Anti- Replay Status Notification", Work in Progress, Internet- Draft, draft-pan-ipsecme-anti-replay-notification-01, 21 October 2024, . [RFC8750] Migault, D., Guggemos, T., and Y. Nir, "Implicit Initialization Vector (IV) for Counter-Based Ciphers in Encapsulating Security Payload (ESP)", RFC 8750, DOI 10.17487/RFC8750, March 2020, . [RFC9347] Hopps, C., "Aggregation and Fragmentation Mode for Encapsulating Security Payload (ESP) and Its Use for IP Traffic Flow Security (IP-TFS)", RFC 9347, DOI 10.17487/RFC9347, January 2023, . Smyslov Expires 8 June 2025 [Page 8] Internet-Draft Renaming ESN in IKEv2 December 2024 Author's Address Valery Smyslov ELVIS-PLUS Russian Federation Email: svan@elvis.ru Smyslov Expires 8 June 2025 [Page 9]