IKEv2 Rekey Priority Extension
draft-liu-ipsecme-ikev2-rekey-redundant-sas-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Daiying Liu , Daniel Migault , Congjie Zhang | ||
| Last updated | 2021-11-21 | ||
| RFC stream | (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-liu-ipsecme-ikev2-rekey-redundant-sas-00
Network Working Group D. Liu, Ed.
Internet-Draft D. Migault, Ed.
Intended status: Informational C. Zhang
Expires: 25 May 2022 Ericsson
21 November 2021
IKEv2 Rekey Priority Extension
draft-liu-ipsecme-ikev2-rekey-redundant-sas-00
Abstract
This document defines the Internet Key Exchange Version 2 (IKEv2)
Rekeying Priority extension that enables to agree roles for the next
rekey of the child SAs and as such optimize IKEv2 rekey negotiation.
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 25 May 2022.
Copyright Notice
Copyright (c) 2021 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.
Liu, et al. Expires 25 May 2022 [Page 1]
Internet-Draft IKEv2 Rekey Priority Extension November 2021
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2
3. Rekeying Priority Notify Message Types . . . . . . . . . . . 2
4. IKE_SA_INIT Stage . . . . . . . . . . . . . . . . . . . . . . 4
5. IKE_AUTH Stage . . . . . . . . . . . . . . . . . . . . . . . 4
6. CREATE_CHILD_SA Stage . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
The IKEv2 protocol supports rekey mechanism for IKE Security
Association (SA) and Child SA, but may result in redundant SAs
([RFC7296], 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.
2. Requirements Language
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 [RFC2119] [RFC8174].
3. Rekeying Priority Notify Message Types
Figure 2 illustrates the Notify Payload packet format as described in
Section 3.10 of [RFC7296] 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.
Liu, et al. Expires 25 May 2022 [Page 2]
Internet-Draft IKEv2 Rekey Priority Extension November 2021
+=======+========================================+
| Value | NOTIFY MESSAGES - STATUS TYPES |
+=======+========================================+
| 16441 | REKEY_PRI |
+-------+----------------------------------------+
Figure 1: REKEY_PRI Notify Message Type Value
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 | SPI Size | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Notification Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: REKEY_PRI Notify Message Format
* 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 Figure 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| P = Rekeying Priority value |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Notification Data for REKEY_PRI
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.
Liu, et al. Expires 25 May 2022 [Page 3]
Internet-Draft IKEv2 Rekey Priority Extension November 2021
A value set to zero indicates the peer does not support rekey.
Although disabling the rekeying is not recommended in [RFC7296]
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 [RFC7296] 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 [RFC7296].
Maybe section 4 and 5 could be example.
4. IKE_SA_INIT Stage
No changes have been made to IKE_SA_INIT in this document.
IKE_SA_INIT is described here (see [RFC7296] 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 Figure 4:
Initiator Responder
-------------------------------------------------------------------
HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
Figure 4: IKE_SA_INIT Exchanges
5. IKE_AUTH Stage
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:
Liu, et al. Expires 25 May 2022 [Page 4]
Internet-Draft IKEv2 Rekey Priority Extension November 2021
Initiator Responder
-------------------------------------------------------------------
HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2,
TSi, TSr, N(REKEY_PRI)} -->
<-- HDR, SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr, N(REKEY_PRI)}
Figure 5: IKE_AUTH Exchanges
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 Section 3.
6. CREATE_CHILD_SA Stage
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 ([RFC7296] Section 1.2), the exchanges
are as follow:
Initiator Responder
-------------------------------------------------------------------
HDR, SK {SA, Ni, [KEi,]
TSi, TSr,
N(REKEY_PRI)} -->
<-- HDR, SK {SA, Nr, [KEr,],
N(REKEY_PRI)
Figure 6: CREATE_CHILD_SA Exchanges for Create Child SA
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:
Liu, et al. Expires 25 May 2022 [Page 5]
Internet-Draft IKEv2 Rekey Priority Extension November 2021
Initiator Responder
-------------------------------------------------------------------
HDR, SK {SA, Ni, [KEi,]
N(REKEY_PRI)} -->
<-- HDR, SK {SA, Nr, [KEr,],
N(REKEY_PRI)
Figure 7: CREATE_CHILD_SA Exchanges for IKE SA Rekeying
The CREATE_CHILD_SA request for rekeying an Child SA is:
Initiator Responder
-------------------------------------------------------------------
HDR, SK {N(REKEY_SA),
SA, Ni, [KEi,],
TSi, TSr,
N(REKEY_PRI)} -->
<-- HDR, SK {SA, Nr, [KEr,],
TSi, TSr,
N(REKEY_PRI)
Figure 8: CREATE_CHILD_SA Exchanges for Child SA Rekeying
7. Security Considerations
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.
8. IANA Considerations
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:
+=======+========================================+
| Value | NOTIFY MESSAGES - STATUS TYPES |
+=======+========================================+
| 16441 | REKEY_PRI |
+-------+----------------------------------------+
Figure 9
Liu, et al. Expires 25 May 2022 [Page 6]
Internet-Draft IKEv2 Rekey Priority Extension November 2021
9. Acknowledgements
This document reproduces some parts of the similar IKEv2 document
([RFC7296]).
10. References
10.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/info/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/info/rfc7296>.
[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/info/rfc8174>.
10.2. Informative References
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>.
Authors' Addresses
Daiying Liu (editor)
Ericsson
Email: harold.liu@ericsson.com
Daniel Migault (editor)
Ericsson
Email: daniel.migault@ericsson.com
Congjie Zhang
Ericsson
Email: congjie.zhang@ericsson.com
Liu, et al. Expires 25 May 2022 [Page 7]