IPSECME Working Group S. Kampati
Internet-Draft W. Pan
Intended status: Standards Track Huawei
Expires: January 5, 2022 M. Bharath
Mavenir
M. Chen
CMCC
July 04, 2021
IKEv2 Optional SA&TS Payloads in Child Exchange
draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05
Abstract
This document describes a method for reducing the size of the
Internet Key Exchange version 2 (IKEv2) exchanges at time of rekeying
IKE SAs and Child SAs by removing or making optional of SA & TS
payloads. Reducing size of IKEv2 exchanges is desirable 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 January 5, 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
Kampati, et al. Expires January 5, 2022 [Page 1]
Internet-Draft IKEv2 Optional Child SA&TS Payloads July 2021
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 . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Negotiation of Support for Optimizing Payloads at
Rekeying IKE SAs and Child SAs . . . . . . . . . . . . . 4
3.2. Payload Optimization at Rekeying IKE SAs . . . . . . . . 4
3.3. Payload Optimization at Rekeying Child SAs . . . . . . . 6
4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. MINIMAL_REKEY_SUPPORTED Notification . . . . . . . . . . 7
4.2. REKEY_OPTIMIZED Notification . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
8. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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 Security Association (SA) parameters negotiation and
authenticated key exchange. The protocol uses UDP as the transport
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 SAs should
be used only for a limited amount of time and to protect a limited
amount of data. When the lifetime of an SA expires or is about to
expire, the peers can rekey the SA to reestablish a new SA to take
the place of the old one.
For security gateways/ePDG in 4G networks and cRAN/Cloud in 5G
networks, they will support more than 100,000 IKE/IPSEC tunnels. So
on an average, for every second there may be hundreds or thousands of
IKE SAs and Child SAs that are rekeying. This takes huge amount of
bandwidth, packet fragmentation and more processing resources. For
these devices, these problems can be solved by introducing the
solution described in this document.
Kampati, et al. Expires January 5, 2022 [Page 2]
Internet-Draft IKEv2 Optional Child SA&TS Payloads July 2021
This is also useful in Internet of Things (IoT) devices which
utilizing lower power consumption technology. For these devices,
reducing the length of IKE/Child SA rekeying messages can save the
bandwidth consumption. At the same time, it can also save the
computing processes by less payload are included.
Most devices don't prefer to change cryptographic suites frequently.
By taking this advantage the SA and TS payloads can be made optional
at the time of rekeying IKE SAs and Child SAs. In such situation,
only a new SPI value is needed to create the new IKE SA and Child SA.
So a new Notify payload which contains the needed SPI value can be
sent instead of the SA 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, the SA and TS payloads can be optimized if there is no
change of cryptographic suites and ACL configuration.
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 for the other peer. To prevent this
failure from happening, the first step is to negotiate the support of
this optimization between the two peers. There are two specific
rekeying SAs cases: rekeying IKE SAs and rekeying Child SAs. After
the negotiation, the initiator can optimize the rekeying message
payloads 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 responder can react based on the received rekeying
message.
Kampati, et al. Expires January 5, 2022 [Page 3]
Internet-Draft IKEv2 Optional Child SA&TS Payloads July 2021
3.1. Negotiation of Support for Optimizing Payloads at Rekeying IKE SAs
and Child SAs
The initiator indicates its support for optimizing payloads at
rekeying IKE SAs and Child SAs by including 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, it
includes the MINIMAL_REKEY_SUPPORTED notification in the
corresponding response message. After receiving the response
message, the initiator can also know the support of this extension of
the responder side.
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,
N(MINIMAL_REKEY_SUPPORTED)}
If the responder doesn't support this extension, it MUST ignore the
MINIMAL_REKEY_SUPPORTED notification sent by the initiator and MUST
NOT respond error to the initiator. With no MINIMAL_REKEY_SUPPORTED
notification in the response message, the initiator can deduce that
the responder doesn't support this extension. In this case, the IKE
SAs and Child SAs rekeyings happen as the usual way without 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
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.
Kampati, et al. Expires January 5, 2022 [Page 4]
Internet-Draft IKEv2 Optional Child SA&TS Payloads July 2021
At the time 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 payload instead of the SA payloads in the rekeying
request message. In this REKEY_OPTIMIZED notification, it contains
the initiator's new Security Parameter Index (SPI) used for creating
the new IKE SA.
After receiving the initiator's rekeying request message with 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 responder MUST send the rekeying respond message to the
initiator with the REKEY_OPTIMIZED notification payload instead of
the SA payloads. In this REKEY_OPTIMIZED notification, it contains
the responder's new SPI used for creating the new IKE SA.
According to the initiator's new SPI and the responder's new SPI, the
initiator and the responder can rekey the IKE SA on both sides.
The CREATE_CHILD_SA message exchange in this case is shown below:
Initiator Responder
--------------------------------------------------------------------
HDR, SK {N(REKEY_OPTIMIZED),
Ni, KEi} -->
<-- HDR, SK {N(REKEY_OPTIMIZED),
Nr, KEr}
The initiator sends a REKEY_OPTIMIZED notification payload, a Nonce
payload and a Diffie-Hellman value in the KEi payload. A new
initiator SPI is supplied in the SPI field of the REKEY_OPTIMIZED
notification payload. These messages also follow the original
Perfect Forwarding Secrecy (PFS) with the signature and encryption
algorithms used as last message.
The responder replies (using the same Message ID to respond) with a
REKEY_OPTIMIZED notification payload, a Nonce 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 no SA payloads
included. When the REKEY_OPTIMIZED notification payload is included,
the SA payload MUST NOT be included.
Kampati, et al. Expires January 5, 2022 [Page 5]
Internet-Draft IKEv2 Optional Child SA&TS Payloads July 2021
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 of this extension by
using the negotiation method described in Section 3.1.
At the time of rekeying a Child SA, when the initiator determines
there is no change in its cryptographic suites and ACL configuration
since this Child SA was created or last rekeyed, it MUST send the
REKEY_OPTIMIZED notification payload instead of the SA and TS
payloads in the rekeying request message. In this REKEY_OPTIMIZED
notification, it contains the initiator's new Security Parameter
Index (SPI) used for creating the new Child SA.
After receiving the initiator's rekeying request message with the
REKEY_OPTIMIZED notification and no SA and TS 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 and ACL configuration, the responder MUST 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 for creating the new Child SA.
According to the old SPIs included in the REKEY_SA payloads and the
new SPIs included in the REKEY_OPTIMIZED payloads, the initiator and
the responder can rekey the Child SA on both sides.
The CREATE_CHILD_SA message exchange in this case is shown below:
Initiator Responder
--------------------------------------------------------------------
HDR, SK {N(REKEY_SA), N(REKEY_OPTIMIZED),
Ni, [KEi,]} -->
<-- HDR, SK {N(REKEY_OPTIMIZED),
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.
4. Payload Formats
Kampati, et al. Expires January 5, 2022 [Page 6]
Internet-Draft IKEv2 Optional Child SA&TS Payloads July 2021
4.1. MINIMAL_REKEY_SUPPORTED Notification
The MINIMAL_REKEY_SUPPORTED notification is used by the initiator and
responder to inform their ability of optimizing payloads at the time
of rekeying IKE SAs and Child SAs to the peers. It is formatted as
follows:
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(=0)| SPI Size (=0) | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Protocol ID (1 octet) - MUST be 0.
o SPI Size (1 octet) - MUST be 0, meaning no SPI is present.
o Notify Message Type (2 octets) - MUST be <Need to get value from
IANA>, the value assigned for the MINIMAL_REKEY_SUPPORTED
notification.
This notification contains no data.
4.2. REKEY_OPTIMIZED Notification
The REKEY_OPTIMIZED notification is used to replace the SA payloads
at the time of rekeying 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 Child SAs when
there is no change of cryptographic suites and ACL configuration in
initiator and responder. It is formatted as follows:
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) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Protocol ID (1 octet) - MUST be 1.
Kampati, et al. Expires January 5, 2022 [Page 7]
Internet-Draft IKEv2 Optional Child SA&TS Payloads July 2021
o SPI Size (1 octet) - MUST be 8 when used at the time of rekeying
IKE SAs and be 4 when used at the time of rekeying Child SAs.
o Notify Message Type (2 octets) - MUST be <Need to get value from
IANA>, the value assigned for the REKEY_OPTIMIZED notification.
o SPI (4 octets or 8 octets) - Security Parameter Index. The
initiator sends initiator SPI. The responder sends responder SPI.
5. 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 Considerations
When using the payload optimization defined in this document, the
rekeying of IKE SAs and Child SAs are using the same cryptographic
suites. If changes to the configurations are wanted, such as
supporting a new cryptographic algorithm, the rekeying won't apply
these changes. The initiator or responder should start a new IKE SA
or Child SA to apply the new changes.
7. Acknowledgments
Special thanks go to Paul Wouters, Valery Smyslov, and Antony Antony.
8. 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>.
Kampati, et al. Expires January 5, 2022 [Page 8]
Internet-Draft IKEv2 Optional Child SA&TS Payloads July 2021
Authors' Addresses
Sandeep Kampati
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
Email: sandeepkampati@huawei.com
Wei Pan
Huawei Technologies
101 Software Avenue, Yuhuatai District
Nanjing, Jiangsu
China
Email: william.panwei@huawei.com
Meduri S S Bharath
Mavenir Systems Pvt Ltd
Manyata Tech Park
Bangalore, Karnataka
India
Email: bharath.meduri@mavenir.com
Meiling Chen
China Mobile
32 Xuanwumen West Street, West District
Beijing, Beijing 100053
China
Email: chenmeiling@chinamobile.com
Kampati, et al. Expires January 5, 2022 [Page 9]