IKEv2 Support for Anti-Replay Status Notification

Introduction IPsec Authentication Header (AH) and Encapsulating Security Payload (ESP) 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 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 .

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 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.

Possible Solutions The solution to the problem () 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.

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 when, and only when, they appear in all capitals, as shown here.

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: <-- 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: <-- 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.

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.

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.

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.

Security Considerations TBD

Acknowledgments TBD