IKEv2 Support for Anti-Replay Status Notification
draft-pan-ipsecme-anti-replay-notification-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Wei Pan , Qi He , Paul Wouters | ||
| Last updated | 2024-10-21 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-pan-ipsecme-anti-replay-notification-01
IPSECME Working Group W. Pan
Internet-Draft Q. He
Intended status: Standards Track Huawei
Expires: 24 April 2025 P. Wouters
Aiven
21 October 2024
IKEv2 Support for Anti-Replay Status Notification
draft-pan-ipsecme-anti-replay-notification-01
Abstract
Although RFC 4302 and RFC 4303 don't prohibit using Extended Sequence
Number (ESN) when the anti-replay function is not enabled, many IPsec
implementations require ESN to be used only with anti-replay.
Therefore, failing to negotiate the use of ESN when the anti-replay
is disabled will cause the sequence numbers to exhaust rapidly in
high-traffic-volume scenarios, leading to the frequent rekey of Child
SAs.
This document defines the REPLAY_PROT_AND_ESN_STATUS Notify Message
Status Type Payload in the Internet Key Exchange Protocol Version 2
(IKEv2) to inform the peer of its replay protection status and
capability of using ESN without anti-replay when creating the Child
SAs, to address the above problem.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-pan-ipsecme-anti-replay-
notification/.
Discussion of this document takes place on the ipsec Working Group
mailing list (mailto:ipsec@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/ipsec/. Subscribe at
https://www.ietf.org/mailman/listinfo/ipsec/.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Pan, et al. Expires 24 April 2025 [Page 1]
Internet-Draft Anti-Replay Notification in IKEv2 October 2024
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 24 April 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
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
1.2. Possible Solutions . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Notifying the Anti-replay and ESN Status . . . . . . . . . . 5
4. REPLAY_PROT_AND_ESN_STATUS Notify Payload Format . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
Pan, et al. Expires 24 April 2025 [Page 2]
Internet-Draft Anti-Replay Notification in IKEv2 October 2024
1. Introduction
IPsec Authentication Header (AH) [RFC4302] and Encapsulating Security
Payload (ESP) [RFC4303] are used to provide security for IP
communications. Both AH and ESP support the anti-replay function to
prevent an attacker from resending the packets received by the IPsec
peer before. Each IPsec packet is sent with a unique sequence
number, which the IPsec receiver checks to see whether the sequence
number is duplicated.
RFC 4302 and RFC 4303 specify the details of sequence number
generation and verification. When anti-replay is enabled on the
receiver, the sender must monitor the sequence number counter and
increment the counter with every message sent. The sender must
ensure that the counter does not cycle, and trigger the creation and
use of a new Child SA before the counter is about to cycle. When
anti-replay is disabled on the receiver, the sender does not need to
monitor or reset the counter. The sender only increments the counter
and rolls it over back to zero when it reaches the maximum value.
It is specified in both RFC 4302 and RFC 4303 that, during SA
establishment, IPsec implementation should notify the peer if it will
not provide anti-replay protection, to avoid having the peer do
unnecessary sequence number monitoring and SA setup. However,
currently, IKEv2 [RFC7296] does not have the notification of anti-
replay status when negotiating the creation of a Child SA. As a
result, IPsec implementations must always assume that the peer has
anti-replay enabled. Even though anti-replay is disabled on both
ends, they still have to monitor the sequence numbers. And this will
lead to an unexpected problematic scenario as described in
Section 1.1.
1.1. Problem Statement
When anti-replay is enabled on the peer, the IPsec implementation
needs to monitor the sequence number of outbound packets, and trigger
a rekey to generate and use a new Child SA when the sequence number
counter is about to cycle. In high-performance scenarios, high-speed
traffic causes the 32-bit sequence number to be consumed rapidly,
resulting in frequent rekeying of Child SAs. For this reason, IPsec
defines the Extended Sequence Number (ESN) function, extending the
available space for sequence numbers from 32 to 64 bits.
Although ESN is good for avoiding the sequence number running out in
a short period, there is a prerequisite for using ESN - RFC 4302 and
RFC 4303 both state that ESN should be used in conjunction with the
anti-replay function. The high-order 32 bits of the sequence number
are not transmitted in the wire and should be determined by the
Pan, et al. Expires 24 April 2025 [Page 3]
Internet-Draft Anti-Replay Notification in IKEv2 October 2024
receiver. RFC 4302 and RFC 4303 describe a window scheme for both
detecting replayed packets and determining the high-order bits. And
many IPsec implementations require the ESN to be used only with anti-
replay.
In the high-performance scenario, operators may turn off anti-replay
for QoS, performance, and other reasons. For example, the high-level
QoS packets arriving first may cause a large number of low-level QoS
packets to be dropped if the disordered packets exceed the anti-
replay window size. However, for the reasons mentioned above,
disabling anti-replay corresponds to implicitly disabling ESNs,
eventually resulting in IPsec peers failing to successfully negotiate
the use of ESNs. The end result is that neither IPsec peer enables
anti-replay, but neither can use ESN, forcing the Child SAs to rekey
frequently due to the rapid exhaustion of the 32-bit sequence number.
1.2. Possible Solutions
The solution to the problem (Section 1.1) can be approached in two
ways.
One option is to support the continued use of the ESN when anti-
replay is disabled. Because IPsec packets currently carry only the
low-order 32 bits of the sequence number, the ESN has a need for the
receiver to manage the anti-replay window in order to determine the
correct value for the high-order 32 bits. To use ESN when anti-
replay is disabled, the IPsec implementations need to create and
maintain a separate window for ESN as well.
The other option is to add a notification of anti-replay status in
IKEv2. Section 3.4.3 of both RFC 4302 and RFC 4303 specify that the
IPsec receiver should notify the sender during SA establishment that
the receiver will not provide anti-replay protection. Adding the
anti-replay status notification in IKEv2 can fulfill this
requirement. When anti-replay is disabled on both peers, neither
peer needs to monitor the sequence number counter, thus avoiding
frequent rekey of Child SAs.
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Pan, et al. Expires 24 April 2025 [Page 4]
Internet-Draft Anti-Replay Notification in IKEv2 October 2024
3. Notifying the Anti-replay and ESN Status
When creating a Child SA, the REPLAY_PROT_AND_ESN_STATUS notification
payload can be used by the initiator and the responder to inform each
other of their own replay protections status (enabled or disabled)
regarding this SA and the support of using ESN without anti-replay.
The initiator includes the REPLAY_PROT_AND_ESN_STATUS notification
payload in the IKE_AUTH exchange request for creating the initial
Child SA or the CREATE_CHILD_SA exchange request for creating the
subsequent Child SAs.
A responder that does not support the anti-replay and ESN status
notification processes the request as normal, and does not include
the new Notify in the response. As per regular IKEv2 processing, a
responder that does not recognize this new Notify, MUST ignore it.
As required in RFC 4302 and RFC 4303, this responder should assume
the anti-replay is enabled in the initiator. The absence of the
Notify in the response indicates to the initiator that the responder
doesn't support the anti-replay and ESN status notification. The
initiator continues the IKEv2 negotiation as usual, and also assumes
the anti-replay is enabled in the responder.
A responder that supports the anti-replay and ESN status notification
can understand whether the initiator provides the anti-replay
protection for this Child SA and/or supports using ESN without anti-
replay. The responder will include the REPLAY_PROT_AND_ESN_STATUS
notification payload in the response to inform its anti-replay and
ESN status about this Child SA.
The IKE_AUTH message exchange in this case is shown below:
Initiator Responder
-------------------------------------------------------------------
HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2,
TSi, TSr,
N(REPLAY_PROT_AND_ESN_STATUS)} -->
<-- HDR, SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr,
N(REPLAY_PROT_AND_ESN_STATUS)}
The CREATE_CHILD_SA message exchange in this case is shown below:
Pan, et al. Expires 24 April 2025 [Page 5]
Internet-Draft Anti-Replay Notification in IKEv2 October 2024
Initiator Responder
-------------------------------------------------------------------
HDR, SK {SA, Ni, [KEi,]
TSi, TSr,
N(REPLAY_PROT_AND_ESN_STATUS)} -->
<-- HDR, SK {SA, Nr, [KEr,]
TSi, TSr,
N(REPLAY_PROT_AND_ESN_STATUS)}
When the Child SA is successfully established with the
REPLAY_PROT_AND_ESN_STATUS notification payloads mutually exchanged,
the initiator and responder understand each other's anti-replay and
ESN status.
The IPsec implementation can choose not to monitor the sequence
number counter of outbound packets if the peer's anti-replay is
disabled, and therefore does not need to create and use a new Child
SA before the counter is about to cycle.
Knowing the anti-replay and ESN status of each peer can help them in
the negotiation of using ESN. If both peers enable the anti-replay,
the ESN negotiation is performed as usual. If both peers support
using ESN without anti-replay, they can propose and accept to use ESN
regardless of the anti-replay status. Suppose one peer disables
anti-replay and supports using ESN without anti-replay, and the other
peer enables anti-replay and doesn't support using ESN without anti-
replay. In that case, both peers support to use ESN and ESN can also
be successfully negotiated. If one peer disables anti-replay and
doesn't support using ESN without anti-replay, it means that this
peer won't propose or accept to use ESN, then the ESN won't be
successfully negotiated.
4. REPLAY_PROT_AND_ESN_STATUS Notify Payload Format
The REPLAY_PROT_AND_ESN_STATUS Notify Message type notification is
used by the initiator and responder to indicate their own anti-replay
status to each other when creating the Child SAs.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+-+-------------+-------------------------------+
| Next Payload |C| RESERVED | Payload Length |
+---------------+-+-------------+-------------------------------+
|Protocol ID(=0)| SPI Size (=0) | Notify Message Type |
+---------------+---------------+-------------------------------+
| REPLAY_PROT | ESN_WITH_RP | Reserved |
+---------------+---------------+-------------------------------+
Pan, et al. Expires 24 April 2025 [Page 6]
Internet-Draft Anti-Replay Notification in IKEv2 October 2024
* Protocol ID (1 octet) - this field MUST contain either (2) to
indicate AH or (3) to indicate ESP.
* SPI Size (1 octet) - MUST be 0.
* Notify Message Type (2 octets) - MUST be set to the value TBD1.
* REPLAY_PROT (1 octet) - this field MUST be 0 to indicate the
replay protection is enabled or 1 to indicate the replay
protection is disabled.
* ESN_WITH_RP (1 octet) - this field MUST be 0 to indicate that ESN
is used with the replay protection enabled or 1 to indicate that
ESN can be used without enabling the replay protection.
The Critical bit MUST be 0. A non-zero value MUST be ignored.
5. IANA Considerations
This document defines a new Notify Message Type in the "IKEv2 Notify
Message Types - Status Types" registry. IANA is requested to assign
the codepoint in this registry.
NOTIFY messages: status types Value
----------------------------------------------------------
REPLAY_PROT_AND_ESN_STATUS TBD1
6. Security Considerations
TBD
7. Acknowledgments
TBD
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[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, <https://www.rfc-editor.org/rfc/rfc7296>.
Pan, et al. Expires 24 April 2025 [Page 7]
Internet-Draft Anti-Replay Notification in IKEv2 October 2024
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
8.2. Informative References
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/rfc/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/rfc/rfc4303>.
Authors' Addresses
Wei Pan
Huawei Technologies
Email: william.panwei@huawei.com
Qi He
Huawei Technologies
Email: archibald.heqi@huawei.com
Paul Wouters
Aiven
Email: paul.wouters@aiven.io
Pan, et al. Expires 24 April 2025 [Page 8]