| IPSECME | S. Kampati |
| Internet-Draft | M. Bharath |
| Intended status: Standards Track | W. Pan |
| Expires: November 22, 2019 | Huawei |
| May 21, 2019 |
IKEv2 Optional SA&TS Payloads in Child Exchange
draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01
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.
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 November 22, 2019.
Copyright (c) 2019 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 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.
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 kBytes.
In 4G networks security gateways/ePDG and in 5G networks cRAN/Cloud 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. And it can be solved by introducing the solution described in this document.
This is useful in Internet of Things (IoT) devices which utilizing lower power consumption technology. The appendix A of [I-D.mglt-6lo-diet-esp-requirements] gives some estimate data.
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.
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.
This section provides protocol details and contains the normative parts.
The initiator indicates its support for optimizing optional payloads at rekeying IKE SAs and Child SAs by including a Notify payload of type MINIMAL_REKEY_SUPPORTED in the IKE_AUTH request message. If the responder also supports this extension, it includes the MINIMAL_REKEY_SUPPORTED notification in the response message. 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.
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)}
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. If the initiator or responder decides to use this payload optimization, then it includes the SA_UNCHANGED notification in its CREATE_CHILD_SA exchange message at the time of rekeying IKE SAs. This SA_UNCHANGED notification MUST be included in a CREATE_CHILD_SA exchange message when there is no SA payloads included. The new IKE SA is created with the SPI value in the SA_UNCHANGED notification.
At the time of rekeying IKE SAs, the initiator MAY send the SA_UNCHANGED notification payload instead of the SA payloads when there is no change in its cryptographic suites since last negotiation. After receiving the initiator's request message with the SA_UNCHANGED notification, the responder MAY respond to the initiator with the SA_UNCHANGED notification payload instead of the SA payloads if there is also no change in its cryptographic suites since last negotiation.
The CREATE_CHILD_SA message exchange in this case is shown below:
Initiator Responder
--------------------------------------------------------------------
HDR, SK {N(SA_UNCHANGED), Ni, KEi} -->
<-- HDR, SK {N(SA_UNCHANGED), Nr, KEr}
The initiator sends a SA_UNCHANGED 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 SA_UNCHANGED notification payload.
The responder replies (using the same Message ID to respond) with a SA_UNCHANGED 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 SA_UNCHANGED notification payload.
When the SA_UNCHANGED notification payload is included, the SA payload MUST NOT be included.
At the time of or before rekeying IKE SAs, the initiator's cryptographic suites may be changed while there is no change of responder's cryptographic suites. New cryptographic suites may be added to the initiator, or some outdated cryptographic suites may be deleted from the initiator.
In this situation, the initiator MUST send the SA payloads in the CREATE_CHILD_SA request message at the time of rekeying IKE SAs.
If the responder selects a different cryptographic suite than which was previously negotiated, then the rekeying MUST be conducted in the original way defined in [RFC7296], the responder sends the SA payloads with the selected cryptographic suite in the CREATE_CHILD_SA response message.
If the responder selects the previously negotiated cryptographic suite to rekey the IKE SA, it MAY send the SA_UNCHANGED notification payload instead of the SA payload in the CREATE_CHILD_SA response message, and the initiator MUST use the cryptographic suite negotiated previously to create the new IKE SA. The CREATE_CHILD_SA message exchange in this case is shown below:
Initiator Responder
--------------------------------------------------------------------
HDR, SK {SA, Ni, KEi} -->
<-- HDR, SK {N(SA_UNCHANGED), Nr, KEr}
At the time of or before rekeying IKE SAs, the responder's cryptographic suites may be changed while there is no change of initiator's cryptographic suites. New cryptographic suites may be added to the responder, or some outdated cryptographic suites may be deleted from the responder.
In this situation, the initiator sends the SA_UNCHANGED notification payload instead of the SA payloads in the CREATE_CHILD_SA request message at the time of rekeying IKE SAs.
If the responder decides to continue using the previously negotiated cryptographic suite to rekey the IKE SA, it MAY send the SA_UNCHANGED notification payload in the CREATE_CHILD_SA response message, then the rekeying is conducted like Section 3.2.1.
If the responder decides to re-negotiate the cryptographic suite, it MUST send NO_PROPOSAL_CHOSEN notification payload in the CREATE_CHILD_SA response message. After receiving this error notification, the initiator MUST retry the CREATE_CHILD_SA exchange with the SA payloads. Then the rekeying is conducted in the original way defined in [RFC7296]. The CREATE_CHILD_SA message exchange in this case is shown below:
Initiator Responder
--------------------------------------------------------------------
HDR, SK {N(SA_UNCHANGED), Ni, KEi} -->
<-- HDR, SK {N(NO_PROPOSAL_CHOSEN),
Nr, KEr}
HDR, SK {SA, Ni, KEi} -->
<-- HDR, SK {SA, Ni, KEi}
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. If the initiator or responder decides to use this payload optimization, then it includes the SA_TS_UNCHANGED notification in its CREATE_CHILD_SA exchange message at the time of rekeying Child SAs. This SA_TS_UNCHANGED notification MUST be included in a CREATE_CHILD_SA exchange message when there is no SA and TS payloads included. The new Child SA is created with the SPI value in the SA_TS_UNCHANGED notification.
At the time of rekeying Child SAs, the initiator MAY send the SA_TS_UNCHANGED notification payload instead of the SA and TS payloads when there is no change in its cryptographic suites and ACL configuration since last negotiation. After receiving the initiator's request message with the SA_TS_UNCHANGED notification, the responder MAY respond to the initiator with the SA_TS_UNCHANGED notification payload instead of the SA and TS payloads if there is also no change in its cryptographic suites and ACL configuration since last negotiation.
The CREATE_CHILD_SA message exchange in this case is shown below:
Initiator Responder
--------------------------------------------------------------------
HDR, SK {N(REKEY_SA), N(SA_TS_UNCHANGED),
Ni, [KEi,]} -->
<-- HDR, SK {N(SA_TS_UNCHANGED),
Nr, [KEr,]}
At the time of or before rekeying Child SAs, the initiator's cryptographic suites or ACL configuration may be changed while there is no change of responder's cryptographic suites and ACL configuration.
In this situation, the initiator MUST send the SA and TS payloads in the CREATE_CHILD_SA request message at the time of rekeying Child SAs.
If the responder selects a different cryptographic suite or different Traffic Selectors than which were previously negotiated, then the rekeying MUST be conducted in the original way defined in [RFC7296], the responder sends the SA payloads with the selected cryptographic suite and the TS payloads in the CREATE_CHILD_SA response message.
If the responder selects the previously negotiated cryptographic suite and Traffic Selectors to rekey the Child SA, it MAY send the SA_TS_UNCHANGED notification payload instead of the SA and TS payloads in the CREATE_CHILD_SA response message, and the initiator MUST use the cryptographic suite and Traffic Selectors negotiated previously to create the new Child SA. The CREATE_CHILD_SA message exchange in this case is shown below:
Initiator Responder
--------------------------------------------------------------------
HDR, SK {N(REKEY_SA), SA, Ni, [KEi,]
TSi, TSr} -->
<-- HDR, SK {N(SA_TS_UNCHANGED),
Nr, KEr}
At the time of or before rekeying Child SAs, the responder's cryptographic suites or ACL configuration may be changed while there is no change of initiator's cryptographic suites and ACL configuration.
In this situation, the initiator MAY send the SA_TS_UNCHANGED notification payload instead of the SA and TS payloads in the CREATE_CHILD_SA request message at the time of rekeying Child SAs.
If the responder decides to continue using the previously negotiated cryptographic suite and Traffic Selectors to rekey the Child SA, it MAY send the SA_TS_UNCHANGED notification payload in the CREATE_CHILD_SA response message, then the rekeying is conducted like Section 3.3.1.
If the responder decides to re-negotiate the cryptographic suite or Traffic Selectors, it MUST send NO_PROPOSAL_CHOSEN notification payload in the CREATE_CHILD_SA response message. After receiving this error notification, the initiator MUST retry the CREATE_CHILD_SA exchange with the SA and TS payloads. Then the rekeying is conducted in the original way defined in [RFC7296]. The CREATE_CHILD_SA message exchange in this case is shown below:
Initiator Responder
--------------------------------------------------------------------
HDR, SK {N(SA_TS_UNCHANGED), Ni, KEi} -->
<-- HDR, SK {N(NO_PROPOSAL_CHOSEN),
Nr, KEr}
HDR, SK {N(REKEY_SA), SA, Ni, [KEi,]
TSi, TSr} -->
<-- HDR, SK {SA, Nr, [KEr,]
TSi, TSr}
The MINIMAL_REKEY_SUPPORTED notification is used by the initiator and responder to inform their ability of optimizing optional payload 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This notification contains no data.
The SA_UNCHANGED 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 or 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) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The SA_TS_UNCHANGED notification is used 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 or 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 (=4) | Notify Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameter Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 SA_UNCHANGED TBD SA_TS_UNCHANGED TBD
TBD
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [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. |
| [RFC8174] | Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. |
| [I-D.mglt-6lo-diet-esp-requirements] | Migault, D., Guggemos, T. and C. Bormann, "Requirements for Diet-ESP the IPsec/ESP protocol for IoT", Internet-Draft draft-mglt-6lo-diet-esp-requirements-02, July 2016. |