IKEv2 Rekey Priority Extension

The IKEv2 protocol supports rekey mechanism for IKE Security Association (SA) and Child SA, but may result in redundant SAs (, section 2.8.1) when both peers start rekeying at the same time. In such case IKEv2 selects the SA created with the lowest of the four nonces and the redundant SA SHOULD be deleted by the endpoint that created it. Among the standards, frequent rekeying is highly recommended, but such an approach can be non optimal when SA are frequently rekeys as SAs are unnecessary computed and adds an additional IKEv2 exchange. So this document defines the Rekeying Priority in IKEv2 extension which enables to agree roles for rekeying of child SAs and optimize IKEv2 rekey negotiation.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

Figure 2 illustrates the Notify Payload packet format as described in Section 3.10 of with a 4 byte Rekeying Priority value as Notification Data used for the REKEY_PRI notification. The REKEY_PRI notification is used in an IKEv2 exchange of type IKE_AUTH and CREATE_CHILD_SA.

Next Payload - N(41), indicate this is Notify payload. Protocol ID - 0, indicate this payload is not concerning the SPI. SPI Size - 0, indicate this payload is not concerning the SPI. Notify Message Type - REKEY_PRI(16441). Notification Data - 4 octets for REKEY_PRI, see :

A peer supporting rekey SHOULD put a randomly selected value that is non null for the Rekeying Priority value. For example, the random value could be generated from some local unique information like hardware serial number or MAC. A random value insure an uniform distribution of the roles. A value set to zero indicates the peer does not support rekey. Although disabling the rekeying is not recommended in section 2.8, disabling rekeying is implemented by most of the products. A peer supporting the Rekeying Priority Extension SHOULD NOT set the Rekeying Priority value to zero unless it does not support rekey. An initiator supporting the Rekeying Priority Extension SHOULD send a Priority Notify Payload in its IKE_AUTH and CREATE_CHILD_SA message. A responder supporting the Rekeying Priority Extension receiving a Priority Notify Payload SHOULD respond with a Priority Notify Payload. When initiator and responders have received the Rekeying Priority Extension, the sender of the highest Rekeying Priority value is expected to be assigned the initiator role of the next rekey. The rekey is expected to be performed as recommended in a reasonable value is to perform the rekey at XXX % of the SA life time. When that trigger has been reach the peer being assigned the responder role MAY proceed to a rekey as defined in . Maybe section 4 and 5 could be example.

No changes have been made to IKE_SA_INIT in this document. IKE_SA_INIT is described here (see Section 1.2) for the sake of logical coherence and completeness and to make it easier for the reader to understand. The initial exchanges are shown as :

<-- HDR, SAr1, KEr, Nr, [CERTREQ] ]]>

When IKE_SA_INIT is completed, the IKE_AUTH message exchanges will take place and the NOTIFY message "REKEY_PRI" should be added to IKE_AUTH, as shown below:

<-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr, N(REKEY_PRI)} ]]> The initiator begins negotiation of a Child SA using the SAi2 payload, and the responder completes negotiation of a Child SA with the additional fields. At this point, the two endpoints get the Rekeying Priority of the opposite end via the IKE_AUTH message, and can decide which endpoint to trigger rekeying using the mechanism described in .

If creating the Child SA during the IKE_AUTH exchange fails for some reason, the IKE SA is still created as usual and use CREATE_CHILD_SA message to create new Child SA ( Section 1.2), the exchanges are as follow:

<-- HDR, SK {SA, Nr, [KEr,], N(REKEY_PRI) ]]> The Rekeying Priority configuration may be changed after the SA is set up. In this case, the Rekeying Priority should be added to the CREATE_CHILD_SA message in order to renegotiate which end to trigger rekeying. This allows both sides to renegotiate the Rekeying Priority the next time they exchange the CREATE_CHILD_SA message (for example, rekeying will be processed by the CREATE_CHILD_SA message). The CREATE_CHILD_SA request for rekeying an IKE SA is:

<-- HDR, SK {SA, Nr, [KEr,], N(REKEY_PRI) ]]> The CREATE_CHILD_SA request for rekeying an Child SA is:

<-- HDR, SK {SA, Nr, [KEr,], TSi, TSr, N(REKEY_PRI) ]]>

This document defines new IKE Notify message types that are naturally protected by the IKE encryption mechanism when the payloads are applied. So there is no security problem or potential risk.

ANA need to update the "IKEv2 Notify Message Types - Status Types" registry (available at https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-16) with the following definition:

This document reproduces some parts of the similar IKEv2 document ().