Internet DRAFT - draft-liu-ipsecme-ikev2-rekey-redundant-sas
draft-liu-ipsecme-ikev2-rekey-redundant-sas
ipsecme D. Migault, Ed.
Internet-Draft D. Liu, Ed.
Intended status: Standards Track C. Zhang
Expires: 25 April 2023 Ericsson
22 October 2022
IKEv2 Count Based SA Extension
draft-liu-ipsecme-ikev2-rekey-redundant-sas-02
Abstract
This document describes an IKEv2 extension that enables a more
rational use of count based SA. This includes preventing the
creation of redundant SAs resulting from simultaneous rekeys.
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 April 2023.
Copyright Notice
Copyright (c) 2022 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.
Migault, et al. Expires 25 April 2023 [Page 1]
Internet-Draft IKEv2 Count Based SA Extension October 2022
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Protocol Description . . . . . . . . . . . . . . . . . . . . 4
4.1. Considerations regarding acceptable values for Count Based
SA Life Time Value . . . . . . . . . . . . . . . . . . . 6
4.2. Special values for the Rekey Value . . . . . . . . . . . 6
5. Payload Description . . . . . . . . . . . . . . . . . . . . . 6
5.1. COUNT_BASED_SA_PROPOSED Notification Data . . . . . . . . 8
5.2. COUNT_BASED_SA_SELECTED Notification Data . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7.1. Acknowledgements . . . . . . . . . . . . . . . . . . . . 10
8. Normative References . . . . . . . . . . . . . . . . . . . . 10
Appendix A. Illustrative Example: . . . . . . . . . . . . . . . 11
A.1. IKE_SA_INIT Stage . . . . . . . . . . . . . . . . . . . . 11
A.2. IKE_AUTH Stage . . . . . . . . . . . . . . . . . . . . . 11
A.3. Rekeying: CREATE_CHILD_SA Stage . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
As per [RFC4301] IPsec systems must support the count based SA
lifetime mechanism, but managing such type of SAs results in a high
level of duplicated SAs due to simultaneous IKEv2 rekey. Systems
constrained to a limited number of SAs - such as hardware module with
a fixed number of table entries - the creation of such extra
temporary duplicated SAs result into a large underutilisation of the
available resources. This document defines the IKEv2 [RFC7296] Count
Based SA extension that defines how IPsec peers can significantly
increase the utilization of the available resource by reducing the
generation of redundant SAs.
Cryptographic key life time are usually expressed in term of bytes to
be encrypted as opposed to time. In fact, when key life time is
expressed in second, the underlying assumption is that the key is
expected to encrypt a number of bytes that does not exceeds the
maximum bytes the key can securely encrypt. Such maximum value is
known as the count based life time.
On the other hand, count based SA life time presents some challenges
over the use of time based SA life time. One reason is that time is
highly predictable and orthogonal to the traffic pattern. As a
consequence, when the SAs are regularly checked every T seconds,
IKEv2 can easily determine a time t, whether or not a given SA will
expire by time t + T. This is not the case for count based SA
Migault, et al. Expires 25 April 2023 [Page 2]
Internet-Draft IKEv2 Count Based SA Extension October 2022
lifetime as IKEv2 at time t will not be able to determine whether the
SA will expire at time t + T. Expiration will depend on the amount
of traffic between t and t + T, which can be non-predictable. In
case of traffic burst, a SA not being expired a time t may happen to
have largely exceeds its lifetime ate time t + T. This may lead to
traffic interruption as well as simultaneous rekeys. Simultaneous
rekeys result in the creation of additional SAs until these are
detected by IKEv2 as duplicated SA. This becomes an issue when the
IPsec tale entries are limited by hardware constraints, in which
case, some SAs cannot be created, the rekey is aborted and the
traffic is interrupted.
It is worth mentioning that IKEv2 does not negotiates the life time
of the SA and these are managed independently by each peer. In many
deployment the peers share some configuration parameters are thus
likely to assign the same (or equivalent) life time to their
negotiated SA. Our operations considers T in the order of 2 seconds,
and the traffic variation over T seconds prevents randomization of
the count based life time to address efficiently duplicated SAs.
Randomisation of SA life time works efficiently with time based SA
lifetime, as different life time often differ by more than T, thus
making SA on each peer expire at different time slot. With count
based SA, the traffic that occurs during T seconds is too large to
rely on randomisation to have the SA expired at different time slots.
This document describes an IKEv2 extension that enables a more
rational use of count based SA. This includes preventing the
creation of redundant SAs resulting from simultaneous rekeys.
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.
3. Terminology
* count based SA life time : the life time of the SA expressed in
term of the maximum number of bytes to be encrypted.
Migault, et al. Expires 25 April 2023 [Page 3]
Internet-Draft IKEv2 Count Based SA Extension October 2022
4. Protocol Description
This document specifies how two peers agree on how count based SA
will be rekeyed. The agreement happens during the CREATE_CHILD_SAs
exchange via the exchange of one or more COUNT_BASED_SA_PROPOSED
Notification payload and a single COUNT_BASED_SA_SELECTED
Notification payload.
SA life time depends on the cryptography algorithm used as well as
the key length. Transform ID designates the cryptographic algorithm
of Transforms of Type 2 in the SA payload (see [RFC7296] section
3.3.2). For any proposed Transform ID of Transforms of Type 2 in the
SA payload, the initiator determine if it is willing to handled SA
life time as described in this document. If so, it insert a Count
Based SA Proposal structure to the COUNT_BASED_SA_PROPOSED
Notification payload in its CREATE_CHILD_SA exchange.
Each Count Based SA Proposal structure contains the Transform ID that
characterizes the transform the remaining parameters will apply.
Follows a Rekey Value that will determine the role each peer will
have when the currently negotiated SA will be rekeyed. Unless, some
specific values are used as described in more details in Section 4.2,
the Rekey Value is randomly generated. Additionally, the initiator
provides the acceptable range for the count based SA life time -
defined with a count based SA life time Minimum Value and a count
based SA life time Maximum Value.
The responder proceeds to the selection of a Transform type 2 as
defined in [RFC7296]. If the responder supports the Count Base Life
Time extension, it checks the COUNT_BASED_SA_PROPOSED Notification
payload for a Count Based SA Proposal structure with a matching
Transform ID. If the number of matching Count Based SA Proposal
structure is different from 1, the COUNT_BASED_SA_PROPOSED
Notification payload are ignored. If the proposed count based SA
life time range is acceptable to the responder, the responder selects
a Count Based SA Life Time Value within the proposed range, generates
a Rekey Value, and returns these two values in a
COUNT_BASED_SA_SELECTED Notification payload.
Upon receiving the COUNT_BASED_SA_SELECTED, the initiator checks the
returned SA Count Life Time Value fits the SA Count Life Time Value
Range. In case of mismatch the initiator ignores the
COUNT_BASED_SA_SELECTED.
Migault, et al. Expires 25 April 2023 [Page 4]
Internet-Draft IKEv2 Count Based SA Extension October 2022
Upon a successful COUNT_BASED_SA_PROPOSED and COUNT_BASED_SA_SELECTED
exchange both peers determine their respective role in next rekey as
well as the count based soft (S) and hard (H) SA life time. The peer
with the greatest Rekey Value is designated to initiate the next
rekey. In case of equality, the current initiator remains the
initiator.
The designated initiator of the next rekey sets S and H respectively
to:
* S = X_i Count Based SA Life Time Value + rand( 0, 5% Count Based
SA Life Time Value )
* H = Count Based SA Life Time Value
The initiator of the next rekey MAY take a lower value than 80%.
The designated responder of the next rekey sets S and H respectively
to:
* S = X_r Count Based SA Life Time Value + rand( 0, 5% Count Based
SA Life Time Value )
* H = Count Based SA Life Time Value
With:
rand( x, y ) designating a random number between x and y.
X_i representing the initiator percentage that MUST be less or equal
than 80%. A lower value will simply trigger earlier the rekey
from the initiator, which has no influence on the responder.
X_r representing the responder percentage that MUST greater than
95%. A greater value will only delay the rekey by the responder if
the initiator has failed to perform the rekey. The value MUST
permit a rekey to occur before the expiration of the Count Based
SA Life Time Value.
It is worth noticing that the peer will be responsible to monitor
both inbound and outbound SAs agreed by the selected transform.
Migault, et al. Expires 25 April 2023 [Page 5]
Internet-Draft IKEv2 Count Based SA Extension October 2022
4.1. Considerations regarding acceptable values for Count Based SA Life
Time Value
Let T_sad be the time interval in second between two consecutive
checks for the counter. This time is usually around 2 seconds. Let
T_ike the necessary time to perform an IKEv2 rekey. An upper bound
of 30 seconds is reasonable. Let also M be the maximum expected rate
in byte per second of data transmitted between the two peers on the
given SA. This may be limited by the link capacity or by the traffic
associated to the service. Acceptable Count Based SA Life Time Value
MUST ensure the amount of traffic received between two SAD checks
will not trigger a simultaneous rekey from both peers. The worst
case is that the limit is reached right after a SAD check and is
noticed T_sad second later. The IKEv2 negotiation needs to be
performed before the life time is reached from the responder's
perspective.
M * ( T_sad + T_ike ) << ( X_r - ( X_i + 5 ) ) * Count Based SA Life
Time Value
The condition becomes:
Count Based SA Life Time Value >> M * ( T_sad + T_ike ) / ( X_r - (
X_i + 5 ) )
With T_sad = 2 sec, T_ike = 30 sec, X_r - ( X_i + 5 ) > 0.1
4.2. Special values for the Rekey Value
A Rekey Value set to zero indicates the peer does not support rekey.
Although disabling the rekeying is not recommended (as per [RFC7296]
section 2.8), disabling rekeying is implemented by most of the
products.
A peer supporting the Count Based SA Extension SHOULD NOT set the
Rekey Value to zero unless it does not support rekey.
5. Payload Description
Figure 1 illustrates the Notify Payload packet format as described in
Section 3.10 of [RFC7296]. This format is used for both the
COUNT_BASED_SA_PROPOSED and COUNT_BASED_SA_SELECTED notifications
that are used in the IKEv2 exchange of type CREATE_CHILD_SA.
Migault, et al. Expires 25 April 2023 [Page 6]
Internet-Draft IKEv2 Count Based SA Extension October 2022
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 1: COUNT_BASED_SA Notify Message Format
The fields Next Payload, Critical Bit, RESERVED, and Payload Length
are defined in [RFC7296]. Specific fields defined in this document
are:
Protocol ID (1 octet): Set to zero. Security Parameter Index (SPI)
Size (1 octet):
Set to zero. Notify Message Type (2 octets):
Specifies the type of notification message. It is set to TBD1 for
the COUNT_BASED_SA_PROPOSED notification or TBD2 for the
COUNT_BASED_SA_SELECTED notification. Notification Data:
The actual payload data defined in Section 5.1 for the
COUNT_BASED_SA_PROPOSED notification and in Section 5.2 for the
COUNT_BASED_SA_SELECTED notification.
The COUNT_BASED_SA notifications are inserted in an IKEv2 exchange of
type CREATE_CHILD_SA with the following Notify Message Types:
+=======+========================================+
| Value | NOTIFY MESSAGES - STATUS TYPES |
+=======+========================================+
| TBD1 | COUNT_BASED_SA_PROPOSED |
+-------+----------------------------------------+
| TBD2 | COUNT_BASED_SA_SELECTED |
+-------+----------------------------------------+
Figure 2: COUNT_BASED_SA Notify Message Type Value
Migault, et al. Expires 25 April 2023 [Page 7]
Internet-Draft IKEv2 Count Based SA Extension October 2022
5.1. COUNT_BASED_SA_PROPOSED Notification Data
The COUNT_BASED_SA_PROPOSED Notification Data depicted in Figure 4
contains one or multiple Count Based SA Proposal structures depicted
in Figure 3.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transform ID | Rekey Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count Based SA Life Time Minimum Value |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count Based SA Life Time Maximum Value |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Count Based SA Proposal structure
Transform ID (2 bytes) : The specific instance of the Transform Type
being proposed. as defined in section 3.3.2 of [RFC7296]. Rekey
Value (2 bytes):
that determines the roles of each peers for the next rekey of the
currently negotiated Child SA will be rekeyed. Count Based SA
Life Time Minimum Value (8 bytes):
The lower bound for a count based SA life time to be selected by
the responder. Count Based SA Life Time Maximum Value (8 bytes):
The upper bound for a count based SA life time to be selected by
the responder.
Migault, et al. Expires 25 April 2023 [Page 8]
Internet-Draft IKEv2 Count Based SA Extension October 2022
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transform ID | Rekey Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count Based SA Life Time Minimum Value |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count Based SA Life Time Maximum Value |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transform ID | Rekey Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count Based SA Life Time Minimum Value |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count Based SA Life Time Maximum Value |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: COUNT_BASED_SA_PROPOSED Notification Data
5.2. COUNT_BASED_SA_SELECTED Notification Data
The COUNT_BASED_SA_SELECTED Notification Data is depicted in Figure 4
and contains:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rekey Value | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Count Based SA Life Time Value |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rekey Value is defined in Section 5.1.
Count Based SA Life Time Maximum Value (8 bytes): The selected count
based SA life time by the responder.
Migault, et al. Expires 25 April 2023 [Page 9]
Internet-Draft IKEv2 Count Based SA Extension October 2022
6. Security Considerations
IKEv2 does not negotiate SA life time and leave it to the
configuration of each peer. This document provides a mean to agree
between peer which SA life time value is being set. The agreed
values S and H MUST remain acceptable to the peer. An initiator MUST
NOT propose values that will not be acceptable to him if agreed by
the responder. A responder MUST ignore the COUNT_BASED_SA_PROPOSED
notification payload in case these SA life time are not acceptable.
The negotiation of the SA life time between the peers results in the
peers actually disclosing that information. While IKEv2 does not
disclose such information, IKEv1 used to disclosed it. Such
disclosure is not expected to have major security implications. At
first a peer is likely to discover the life time of a SA by
monitoring when a rekey occurs. As a result, the extension only
reveals information that were relatively easy to observe.
Alternatively, a peer that would used such information remains
authenticated via IKEv2 and as such action can be taken if an attack
by the peer were observed.
7. 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 |
+=======+========================================+
| TBD1 | COUNT_BASED_SA_PROPOSED |
+-------+----------------------------------------+
| TBD2 | COUNT_BASED_SA_SELECTED |
+-------+----------------------------------------+
Figure 5
7.1. Acknowledgements
We would like to thank Paul Wouters, Valery Smirnov and Tero Kivinen
for their feed backs.
8. Normative References
Migault, et al. Expires 25 April 2023 [Page 10]
Internet-Draft IKEv2 Count Based SA Extension October 2022
[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>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[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>.
Appendix A. Illustrative Example:
A.1. 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 6:
Initiator Responder
-------------------------------------------
HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
Figure 6: IKE_SA_INIT Exchanges
A.2. IKE_AUTH Stage
When IKE_SA_INIT is completed, the IKE_AUTH message exchanges will
take place and the NOTIFY message "COUNT_BASED_SA" should be added to
IKE_AUTH, as shown below:
Migault, et al. Expires 25 April 2023 [Page 11]
Internet-Draft IKEv2 Count Based SA Extension October 2022
Initiator Responder
-----------------------------------------------
HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2,
TSi, TSr, N(COUNT_BASED_SA_PROPOSED)} -->
<-- HDR, SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr, N(COUNT_BASED_SA_SELECTED)}
Figure 7: 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.
Thanks to the Rekey Value and the Count Based SA Life Time Value the
Initiator and the Responder are able to:
* Determine who is in charge of performing the rekey.
* Set their respective count based SA life time H and S
A.3. Rekeying: CREATE_CHILD_SA Stage
The peer designated as the initiator for the rekey realizes the soft
SA life time has been reached. That initiator could have been the
Initiator or the Responder when the current SA has been established.
The CREATE_CHILD_SA request for rekeying an IKE SA is:
Initiator Responder
----------------------------------------------
HDR, SK {SA, Ni, [KEi,]
N(COUNT_BASED_SA_PROPOSED)} -->
<-- HDR, SK {SA, Nr, [KEr,],
N(COUNT_BASED_SA_SELECTED)
Figure 8: CREATE_CHILD_SA Exchanges for IKE SA Rekeying
Authors' Addresses
Daniel Migault (editor)
Ericsson
Email: daniel.migault@ericsson.com
Daiying Liu (editor)
Ericsson
Email: harold.liu@ericsson.com
Migault, et al. Expires 25 April 2023 [Page 12]
Internet-Draft IKEv2 Count Based SA Extension October 2022
Congjie Zhang
Ericsson
Email: congjie.zhang@ericsson.com
Migault, et al. Expires 25 April 2023 [Page 13]
