wdiff draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.txt draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-06.txt

IPSECME Working Group S. Kampati
Internet-Draft W. Pan
Intended status: Standards Track Huawei
Expires: 13 January 5, 2022 M. Bharath
Mavenir
M. Chen
CMCC
12 July 04, 2021

IKEv2 Optional SA&TS Payloads in Child Exchange
draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05
draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-06

Abstract

This document describes a method for reducing the size of the
Internet Key Exchange version 2 (IKEv2) CREATE_CHILD_SA exchanges at time of
used for rekeying of the IKE SAs and or Child SAs SA by removing or making optional of replacing the SA & and TS
payloads.
payloads with a Notify Message payload. Reducing size and complexity
of IKEv2 exchanges is desirable especially useful for low power consumption
battery powered devices. It also helps to avoid IP
fragmentation of IKEv2 messages.

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 13 January 5, 2022.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) (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 Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
3. Protocol Details Negotiation of Support for OPTIMIZED REKEY . . . . . . . . . 3
4. Optimized Rekey of the IKE SA . . . . . . . . . . . . . 3
3.1. Negotiation . . . 4
5. Optimized Rekey of Support for Optimizing Payloads at
Rekeying IKE SAs and Child SAs . . . . . . . . . . . . . 4
3.2. . . . 5
6. Payload Optimization at Rekeying IKE SAs Formats . . . . . . . . 4
3.3. Payload Optimization at Rekeying Child SAs . . . . . . . 6
4. Payload Formats . . . . . . . . 5
6.1. OPTIMIZED_REKEY_SUPPORTED Notify . . . . . . . . . . . . 5
6.2. OPTIMIZED_REKEY Notify . . . 6
4.1. MINIMAL_REKEY_SUPPORTED Notification . . . . . . . . . . 7
4.2. REKEY_OPTIMIZED Notification . . . . 6
7. IANA Considerations . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . 6
8. Operational Considerations . . . . . . . . . . 8
6. . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. 7
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
8. 7
11. Normative References . . . . . . . . . . . . . . . . . . . . 8 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 7

1. Introduction

The Internet Key Exchange protocol version 2 (IKEv2) specified in [RFC7296] is
used in the IP Security (IPSec) architecture for the
purposes of to negotiate Security Association (SA) parameters negotiation for the IKE SA
and
authenticated key exchange. The protocol uses UDP as the transport Child SAs. Cryptographic key material for its messages, which size varies from less than one hundred bytes
to several kilobytes.

According to [RFC7296], the secret keys used by IKE/IPSec these SAs should
be used only for have a
limited amount of time and lifetime before it needs to protect be refreshed, a limited
amount of data. process referred
to as "rekeying". IKEv2 uses the CREATE_CHILD_SA exchange to rekey
either the IKE SA or the Child SAs.

When rekeying, a full set of previously negotiated parameters are
exchanged. However, most of these parameters will be the lifetime same, and
some of an these parameters MUST be the same.

For example, the Traffic Selector (TS) negotiated for the new Child
SA expires or is about to
expire, MUST cover the peers can rekey Traffic Selectors negotiated for the old Child SA.
And in practically all cases, a new Child SA would not need to reestablish cover
more Traffic Selectors. In the rare case where this would be needed,
a new Child SA to take could be negotiated instead of the current Child SA
being rekeyed. Similarly, IKEv2 states that the cryptographic
parameters negotiated for rekeying SHOULD NOT be different. This
means that the place security properties of the old one. IKE or Child SA in practise
do not change during a typical rekey.

This document specifies a method to omit these parameters and replace
them with a single Notify Message declaring that all these parameters
are identical to the originally negotiated parameters.

For security gateways/ePDG in 4G networks and or cRAN/Cloud gateways in
5G networks, they will gateways typically support more than 100,000 IKE/IPSEC IKE/IPSec
tunnels. So
on an average, for every second At any point in time, there may will be hundreds or thousands
of IKE SAs and Child SAs that are rekeying. being rekeyed. This takes huge a large
amount of
bandwidth, packet fragmentation bandwidth and more processing resources. For
these devices, these problems can be solved by introducing the
solution described in this document.

This is also useful CPU power and any protocol simplification or
bandwidth reducing would result in an significant resource saving.

For Internet of Things (IoT) devices which
utilizing lower utilize low power
consumption technology. For these devices, technology, reducing the length size of IKE/Child SA rekeying messages can save rekey exchange reduces
its power consumption, as sending bytes over the
bandwidth consumption. At air is usually the same time, it can
most power consuming operation of such a device. Reducing the CPU
operations required to verify the rekey exchanges parameters will
also save power and extend the
computing processes by less payload are included.

Most devices don't prefer to change cryptographic suites frequently.
By taking this advantage lifetime for these devices.

When using identical parameters during the IKE or Child SA rekey, the
SA and TS payloads can be made optional
at the time of rekeying omitted. For an IKE SAs and Child SAs. In such situation, SA rekey, instead of
the (large) SA payload, only a Key Exchange (KE) payload and a new
Notify Type payload with the new SPI value is needed to create required. For a Child SA
payload, instead of the new IKE SA or TS payloads, only an optional Nonce
payload (when using PFS) and Child SA.
So a new Notify Type payload which contains with the needed new
SPI value can be
sent instead of is needed. This makes the SA rekey exchange packets much smaller
and TS payloads.

In case of rekeying IKE SAs, the SA payloads can be optimized if
there is no change of cryptographic suites. In case of rekeying
Child SAs, peers do not need to verify that the SA and or TS payloads can be optimized if there is no
change of cryptographic suites and ACL configuration. parameters are
compatible with the old SA.

2. Conventions Used in This Document

2.1. 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. Protocol Details

This section provides protocol details and contains the normative
parts.

Before using this new optimization, the IPSec implementation who
supports it has to know that the peer also supports it. Without the
support on both sides, the optimized rekeying messages sent by one
peer may be unrecognizable Negotiation of Support for the other peer. OPTIMIZED REKEY

To prevent this
failure from happening, the first step is to negotiate the indicate support of
this optimization between the two peers. There are two specific
rekeying SAs cases: rekeying IKE SAs and rekeying Child SAs. After for the optimized rekey negotiation, the
initiator can optimize includes the rekeying message
payloads OPTIMIZED_REKEY_SUPPORTED Notify payload in both cases. In other words, once
the negotiation of
support for optimizing payloads at rekeying IKE SAs and Child SAs is
complete, both IKE SAs and Child SAs rekeying are supported by the
two sides. The IKE_AUTH exchange request. A responder can react based on that supports the received rekeying
message.

3.1. Negotiation of Support for Optimizing Payloads at Rekeying IKE SAs
and Child SAs

The initiator indicates
optimized rekey exchange includes the OPTIMIZED_REKEY_SUPPORTED
Notify payload in its response. Note that the notify indicates
support for optimizing payloads at
rekeying optimized rekey for both IKE SAs and Child SAs by including SAs.

When a Notify payload of type
MINIMAL_REKEY_SUPPORTED in the IKE_AUTH request message. By
observing the MINIMAL_REKEY_SUPPORTED notification in the received
message, the responder can deduce the initiator's support of this
extension. If the responder also supports this extension, peer wishes to rekey an IKE SA or Child SA, it
includes the MINIMAL_REKEY_SUPPORTED notification in MAY use the
corresponding response message. After receiving
optimized rekey method during the response
message, CREATE_CHILD_SA exchange. A
responder MUST accept that the initiator can also know the support of this extension of
the responder side. uses a regular or optimized
rekey.

The IKE_AUTH message exchange in this case is shown below:

Initiator Responder
--------------------------------------------------------------------
HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2, TSi, TSr,
N(MINIMAL_REKEY_SUPPORTED)}
N(OPTIMIZED_REKEY_SUPPORTED)} -->
<-- HDR, SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr,
N(MINIMAL_REKEY_SUPPORTED)}
N(OPTIMIZED_REKEY_SUPPORTED)}

If the responder doesn't does not support this extension, as per regular
IKEv2 processing, it MUST ignore the
MINIMAL_REKEY_SUPPORTED notification sent by the unknown Notify payload. The
initiator and MUST
NOT respond error to the initiator. With no MINIMAL_REKEY_SUPPORTED
notification in the response message, will notice the initiator can deduce that lack of the responder doesn't support this extension. In this case, OPTIMIZED_REKEY_SUPPORTED
Notify in the IKE
SAs reply and Child SAs rekeyings happen as thus know it cannot use the usual way without optimized rekey
method.

4. Optimized Rekey of the
optimizations defined in this document.

The IKE_AUTH message exchange in this case is shown below:

Initiator Responder
--------------------------------------------------------------------
HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2, TSi, TSr,
N(MINIMAL_REKEY_SUPPORTED)} -->
<-- HDR, SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr}

3.2. Payload Optimization at Rekeying IKE SAs SA

The payload optimization at rekeying IKE SAs MUST NOT be used unless
both peers have indicated their support of this extension by using
the negotiation method described in Section 3.1.

At the time initiator of rekeying an IKE SA, when the initiator determines
there is no change on its cryptographic suites since this IKE SA was
created or last rekeyed, it MUST send the REKEY_OPTIMIZED
notification optimized rekey request sends a CREATE_CHILD_SA
payload instead of the SA payloads in with the rekeying
request message. In this REKEY_OPTIMIZED notification, it contains OPTIMIZED_REKEY notify payload containing the initiator's new
Security Parameter Index (SPI) used for creating the new IKE SA.

After receiving the initiator's rekeying request message with It omits the
REKEY_OPTIMIZED notification and no SA payloads, the responder knows
that the initiator wants to optimize the rekeying
payload. Then when
it determines that there is also no change in its cryptographic
suites, the

The responder MUST send the rekeying respond message to the
initiator with the REKEY_OPTIMIZED notification payload instead of an optimized rekey request performs the SA payloads. In this REKEY_OPTIMIZED notification, it contains
the responder's new SPI used for creating same
process. It includes the OPTIMIZED_REKEY notify with its new IKE SA.

According to the initiator's new SPI
and omits the responder's new SPI, the
initiator SA payload.

Both parties send Nonce and the responder can rekey the KE payloads just as they would do for a
regular IKE SA on both sides. rekey.

The CREATE_CHILD_SA message exchange in this case is shown below:

Initiator Responder
--------------------------------------------------------------------
HDR, SK {N(REKEY_OPTIMIZED), {N(OPTIMIZED_REKEY),
Ni, KEi} -->
<-- HDR, SK {N(REKEY_OPTIMIZED), {N(OPTIMIZED_REKEY),
Nr, KEr}

5. Optimized Rekey of Child SAs

The initiator of an optimized rekey request sends a REKEY_OPTIMIZED notification payload, a Nonce CREATE_CHILD_SA
payload and a Diffie-Hellman value in the KEi payload. A new
initiator SPI is supplied in with the SPI field of OPTIMIZED_REKEY notify payload containing the REKEY_OPTIMIZED
notification payload. These messages also follow new
Security Parameter Index (SPI) for the original
Perfect Forwarding Secrecy (PFS) with new Child SA. It omits the signature SA
and encryption
algorithms used as last message.

The responder replies (using TS payloads. If the same Message ID to respond) current Child SA was negotiated with Perfect
Forward Secrecy (PFS), a
REKEY_OPTIMIZED notification payload, a Nonce KEi payload and a Diffie-
Hellman value in the KEr payload. A new responder SPI is supplied in
the SPI field of the REKEY_OPTIMIZED notification payload.

This REKEY_OPTIMIZED notification MUST be included in a
CREATE_CHILD_SA exchange message when there is as well. If no SA payloads
included. When the REKEY_OPTIMIZED notification payload is included,
PFS was negotiated for the SA current Child SA, a KEi payload MUST NOT
be included.

3.3. Payload Optimization at Rekeying Child SAs

The payload optimization at rekeying Child SAs MUST NOT be used
unless both peers have indicated their support responder of this extension by
using the negotiation method described in Section 3.1.

At an optimized rekey request performs the time of rekeying a Child SA, when same
process. It includes the initiator determines
there is no change in OPTIMIZED_REKEY notify with its cryptographic suites new IKE SPI
and ACL configuration
since this Child SA was created or last rekeyed, it MUST send the
REKEY_OPTIMIZED notification payload instead of omits the SA and TS
payloads in the rekeying request message. In this REKEY_OPTIMIZED
notification, it contains payloads. Depending on the initiator's new Security Parameter
Index (SPI) used for creating PFS negotiation
of the new current Child SA.

After receiving the initiator's rekeying request message with the
REKEY_OPTIMIZED notification and no SA and TS payloads, SA, the responder
knows that the initiator wants to optimize the rekeying includes a KEr payload.
Then when it determines that there is also no change in its
cryptographic suites and ACL configuration, the responder MUST

Both parties send
the rekeying respond message to the initiator with the
REKEY_OPTIMIZED notification payload instead of the SA and TS
payloads. In this REKEY_OPTIMIZED notification, it contains the
responder's new SPI used Nonce payloads just as they would do for creating the new a regular
Child SA.

According to SA rekey.

Using the received old SPIs included in SPI from the REKEY_SA payloads payload and the new SPIs included in the REKEY_OPTIMIZED payloads, the initiator and SPI
received from the responder OPTIMIZED_REKEY payload, both parties can rekey perform
the Child SA on both sides. rekey operation.

The CREATE_CHILD_SA message exchange in this case is shown below:

Initiator Responder
--------------------------------------------------------------------
HDR, SK {N(REKEY_SA), N(REKEY_OPTIMIZED), N(OPTIMIZED_REKEY),
Ni, [KEi,]} -->
<-- HDR, SK {N(REKEY_OPTIMIZED), {N(OPTIMIZED_REKEY),
Nr, [KEr,]}

This REKEY_OPTIMIZED notification MUST be included in a
CREATE_CHILD_SA exchange message when there is no SA and TS payloads
included at the time of rekeying Child SAs. When the REKEY_OPTIMIZED
notification payload is included, the SA and TS payloads MUST NOT be
included.

6. Payload Formats
4.1. MINIMAL_REKEY_SUPPORTED Notification

6.1. OPTIMIZED_REKEY_SUPPORTED Notify

The MINIMAL_REKEY_SUPPORTED OPTIMIZED_REKEY_SUPPORTED Notify Message type notification is
used by the initiator and responder to inform indicate their ability of optimizing payloads at the time
of rekeying IKE SAs and Child SAs to support for the peers. It is formatted as
follows:
optimized rekey negotiation.

* Protocol ID (1 octet) - MUST be 0.

* SPI Size (1 octet) - MUST be 0, meaning no SPI is present.

* Notify Message Type (2 octets) - MUST be <Need set to get value from
IANA>, the value assigned for the MINIMAL_REKEY_SUPPORTED
notification. [TBD1].

This notification Notify Message type contains no data.

4.2. REKEY_OPTIMIZED Notification

6.2. OPTIMIZED_REKEY Notify

The REKEY_OPTIMIZED notification OPTIMIZED_REKEY Notify Message type is used to replace the SA payloads
at the time of rekeying perform an
optimized IKE SAs when there is no change of
cryptographic suites in initiator and responder, and to replace the SA payloads and TS payloads at the time of rekeying or Child SAs when
there is no change of cryptographic suites and ACL configuration in
initiator and responder. It is formatted as follows: SA rekey.

0 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 (=8) | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameter Index (SPI) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

* Protocol ID (1 octet) - MUST be 1.

* SPI Size (1 octet) - MUST be 8 when used at the time of rekeying an IKE SAs and SA. MUST be 4
when used at the time of rekeying a Child SAs.

o SA.

* Notify Message Type (2 octets) - MUST be <Need set to get value from
IANA>, the value assigned for the REKEY_OPTIMIZED notification.

o [TBD2].

* SPI (4 octets or 8 octets) - Security Parameter Index. The
initiator sends initiator SPI. The responder sends responder peer's
new SPI.

7. IANA Considerations

This document defines two new Notify Message Types in the "IKEv2
Notify Message Types - Status Types" registry. IANA is requested to
assign codepoints in this registry.

NOTIFY messages: status types Value
----------------------------------------------------------
MINIMAL_REKEY_SUPPORTED TBD
REKEY_OPTIMIZED TBD

6. Security
OPTIMIZED_REKEY_SUPPORTED TBD1
OPTIMIZED_REKEY TBD2

8. Operational Considerations

When using the payload optimization defined

Some implementations allow sending rekey messages with a different
set of Traffic Selectors or cryptographic parameters in response to a
configuration update. IKEv2 states this document, the SHOULD NOT be done. Whether
or not optimized rekeying of IKE SAs and Child SAs are using the same cryptographic
suites. If is used, a configuration change that
changes to the configurations are wanted, such as
supporting a new Traffic Selectors or cryptographic algorithm, parameters MUST NOT
use the rekeying won't apply
these changes. The initiator or responder should start optimized rekey method. It SHOULD also not use a regular
rekey method but instead start an entire new IKE SA
or and Child SA to apply
negotiation with the new changes.

7. parameters.

9. Security Considerations

The optimized rekey removes sending unnecessary new parameters that
originally would have to be validated against the original
parameters. In that sense, this optimization enhances the security
of the rekey process.

10. Acknowledgments

Special thanks go to Paul Wouters, Valery Smyslov, and Antony Antony.

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

Authors' Addresses

Sandeep Kampati
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka
Bangalore 560066
Karnataka
India

Email: sandeepkampati@huawei.com
Wei Pan
Huawei Technologies
101 Software Avenue, Yuhuatai District
Nanjing, Jiangsu
Nanjing
Jiangsu,
China

Email: william.panwei@huawei.com

Meduri S S Bharath
Mavenir Systems Pvt Ltd
Manyata Tech Park
Bangalore,
Bangalore
Karnataka
India

Email: bharath.meduri@mavenir.com

Meiling Chen
China Mobile
32 Xuanwumen West Street, West District
Beijing,
Beijing
Beijing, 100053
China

Email: chenmeiling@chinamobile.com