< draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01.txt   draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-02.txt >
IPSECME S. Kampati IPSECME S. Kampati
Internet-Draft M. Bharath Internet-Draft M. Bharath
Intended status: Standards Track W. Pan Intended status: Standards Track W. Pan
Expires: November 22, 2019 Huawei Expires: May 7, 2020 Huawei
May 21, 2019 November 4, 2019
IKEv2 Optional SA&TS Payloads in Child Exchange IKEv2 Optional SA&TS Payloads in Child Exchange
draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01 draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-02
Abstract Abstract
This document describes a method for reducing the size of the This document describes a method for reducing the size of the
Internet Key Exchange version 2 (IKEv2) exchanges at time of rekeying Internet Key Exchange version 2 (IKEv2) exchanges at time of rekeying
IKE SAs and Child SAs by removing or making optional of SA & TS IKE SAs and Child SAs by removing or making optional of SA & TS
payloads. Reducing size of IKEv2 exchanges is desirable for low payloads. Reducing size of IKEv2 exchanges is desirable for low
power consumption battery powered devices. It also helps to avoid IP power consumption battery powered devices. It also helps to avoid IP
fragmentation of IKEv2 messages. fragmentation of IKEv2 messages.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 22, 2019. This Internet-Draft will expire on May 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 14 skipping to change at page 2, line 14
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Negotiation of Support for Optimizing Optional Payload at 3.1. Negotiation of Support for Optimizing Optional Payload at
Rekeying IKE SAs and Child SAs . . . . . . . . . . . . . 3 Rekeying IKE SAs and Child SAs . . . . . . . . . . . . . 4
3.2. Optional Payload Optimization at Rekeying IKE SAs . . . . 4 3.2. Payload Optimization at Rekeying IKE SAs . . . . . . . . 5
3.2.1. Rekeying IKE SAs When No Change of Initiator and 3.2.1. Rekeying IKE SAs When No Change of Initiator and
Responder's Cryptographic Suites . . . . . . . . . . 4 Responder's Cryptographic Suites . . . . . . . . . . 5
3.2.2. Rekeying IKE SAs When Initiator's Cryptographic 3.2.2. Rekeying IKE SAs When Responder's Cryptographic
Suites Changed . . . . . . . . . . . . . . . . . . . 5 Suites Changed . . . . . . . . . . . . . . . . . . . 6
3.2.3. Rekeying IKE SAs When Responder's Cryptographic 3.3. Payload Optimization at Rekeying Child SAs . . . . . . . 7
Suites Changed . . . . . . . . . . . . . . . . . . . 5
3.3. Optional Payload Optimization at Rekeying Child SAs . . . 6
3.3.1. Rekeying Child SAs When No Change of Initiator and 3.3.1. Rekeying Child SAs When No Change of Initiator and
Responder's Cryptographic Suites and ACL Responder's Cryptographic Suites and ACL
Configuration . . . . . . . . . . . . . . . . . . . . 6 Configuration . . . . . . . . . . . . . . . . . . . . 7
3.3.2. Rekeying Child SAs When Initiator's Cryptographic 3.3.2. Rekeying Child SAs When Responder's Cryptographic
Suites or ACL Configuration Changed . . . . . . . . . 7 Suites or ACL Configuration Changed . . . . . . . . . 8
3.3.3. Rekeying Child SAs When Responder's Cryptographic 4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 9
Suites or ACL Configuration Changed . . . . . . . . . 7 4.1. MINIMAL_REKEY_SUPPORTED Notification . . . . . . . . . . 9
4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. SA_UNCHANGED Notification . . . . . . . . . . . . . . . . 10
4.1. MINIMAL_REKEY_SUPPORTED Notification . . . . . . . . . . 8 4.3. SA_TS_UNCHANGED Notification . . . . . . . . . . . . . . 10
4.2. SA_UNCHANGED Notification . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
4.3. SA_TS_UNCHANGED Notification . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The Internet Key Exchange protocol version 2 (IKEv2) specified in The Internet Key Exchange protocol version 2 (IKEv2) specified in
[RFC7296] is used in the IP Security (IPsec) architecture for the [RFC7296] is used in the IP Security (IPsec) architecture for the
purposes of Security Association (SA) parameters negotiation and purposes of Security Association (SA) parameters negotiation and
authenticated key exchange. The protocol uses UDP as the transport authenticated key exchange. The protocol uses UDP as the transport
for its messages, which size varies from less than one hundred bytes for its messages, which size varies from less than one hundred bytes
to several kBytes. to several kilobytes.
In 4G networks security gateways/ePDG and in 5G networks cRAN/Cloud According to [RFC7296], the secret keys used by IKE/IPSec SAs should
will support more than 100,000 IKE/IPSEC tunnels. So on an average, be used only for a limited amount of time and to protect a limited
for every second there may be hundreds or thousands of IKE SAs and amount of data. When the lifetime of an SA expires or is about to
Child SAs that are rekeying. This takes huge amount of bandwidth, expire, the peers can rekey the SA to reestablish a new SA to take
packet fragmentation and more processing resources. And it can be the place of the old one.
solved by introducing the solution described in this document.
This is useful in Internet of Things (IoT) devices which utilizing For security gateways/ePDG in 4G networks and cRAN/Cloud in 5G
lower power consumption technology. The appendix A of networks, they will support more than 100,000 IKE/IPSEC tunnels. So
[I-D.mglt-6lo-diet-esp-requirements] gives some estimate data. 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.
This is also 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. 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. Most devices don't prefer to change cryptographic suites frequently.
By taking this advantage the SA and TS payloads can be made optional 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, 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. 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 So a new Notify payload which contains the needed SPI value can be
sent instead of the SA and TS payloads. sent instead of the SA and TS payloads.
In case of rekeying IKE SAs, the SA payloads can be optimized if In case of rekeying IKE SAs, the SA payloads can be optimized if
there is no change of cryptographic suites. In case of rekeying there is no change of cryptographic suites. In case of rekeying
skipping to change at page 3, line 40 skipping to change at page 3, line 47
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Protocol Details 3. Protocol Details
This section provides protocol details and contains the normative This section provides protocol details and contains the normative
parts. 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 stop 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, it's up to the initiator to decide at which case to
optimize the rekeying messages. The initiator can optimize the
rekeying message payloads in both cases, or just in one case. The
responder can react based on the received rekeying message.
3.1. Negotiation of Support for Optimizing Optional Payload at Rekeying 3.1. Negotiation of Support for Optimizing Optional Payload at Rekeying
IKE SAs and Child SAs IKE SAs and Child SAs
The initiator indicates its support for optimizing optional payloads The initiator indicates its support for optimizing optional payloads
at rekeying IKE SAs and Child SAs by including a Notify payload of 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 type MINIMAL_REKEY_SUPPORTED in the IKE_AUTH request message. By
responder also supports this extension, it includes the observing the MINIMAL_REKEY_SUPPORTED notification in the received
MINIMAL_REKEY_SUPPORTED notification in the response message. If the message, the responder can deduce the initiator's support of this
responder doesn't support this extension, it MUST ignore the extension. If the responder also supports this extension, it
MINIMAL_REKEY_SUPPORTED notification sent by the initiator and MUST includes the MINIMAL_REKEY_SUPPORTED notification in the
NOT respond error to the initiator. 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: The IKE_AUTH message exchange in this case is shown below:
Initiator Responder Initiator Responder
-------------------------------------------------------------------- --------------------------------------------------------------------
HDR, SK {IDi, [CERT,] [CERTREQ,] HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2, TSi, TSr, [IDr,] AUTH, SAi2, TSi, TSr,
N(MINIMAL_REKEY_SUPPORTED)} --> N(MINIMAL_REKEY_SUPPORTED)} -->
<-- HDR, SK {IDr, [CERT,] AUTH, <-- HDR, SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr, SAr2, TSi, TSr,
N(MINIMAL_REKEY_SUPPORTED)} N(MINIMAL_REKEY_SUPPORTED)}
3.2. Optional Payload Optimization at Rekeying IKE SAs 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 The payload optimization at rekeying IKE SAs MUST NOT be used unless
both peers have indicated their support of this extension by using both peers have indicated their support of this extension by using
the negotiation method described in Section 3.1. If the initiator or the negotiation method described in Section 3.1. If the initiator
responder decides to use this payload optimization, then it includes decides to optimize the payloads at the time of rekeying IKE SAs,
the SA_UNCHANGED notification in its CREATE_CHILD_SA exchange message then it includes the SA_UNCHANGED notification in its CREATE_CHILD_SA
at the time of rekeying IKE SAs. This SA_UNCHANGED notification MUST exchange message. If the initiator decides not to do the
be included in a CREATE_CHILD_SA exchange message when there is no SA optimization, then it just sends the rekeying request message as the
payloads included. The new IKE SA is created with the SPI value in original way, the rekeying is conducted as [RFC7296] defined.
the SA_UNCHANGED notification.
3.2.1. Rekeying IKE SAs When No Change of Initiator and Responder's 3.2.1. Rekeying IKE SAs When No Change of Initiator and Responder's
Cryptographic Suites Cryptographic Suites
At the time of rekeying IKE SAs, the initiator MAY send the At the time of rekeying an IKE SA, when the initiator determines
SA_UNCHANGED notification payload instead of the SA payloads when there is no change on its cryptographic suites since this IKE SA was
there is no change in its cryptographic suites since last created or last rekeyed, it MAY send the SA_UNCHANGED notification
negotiation. After receiving the initiator's request message with payload instead of the SA payloads in the rekeying request message.
the SA_UNCHANGED notification, the responder MAY respond to the In this SA_UNCHANGED 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
SA_UNCHANGED 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 MAY send the rekeying respond message to the
initiator with the SA_UNCHANGED notification payload instead of the initiator with the SA_UNCHANGED notification payload instead of the
SA payloads if there is also no change in its cryptographic suites SA payloads. In this SA_UNCHANGED notification, it contains the
since last negotiation. 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: The CREATE_CHILD_SA message exchange in this case is shown below:
Initiator Responder Initiator Responder
-------------------------------------------------------------------- --------------------------------------------------------------------
HDR, SK {N(SA_UNCHANGED), Ni, KEi} --> HDR, SK {N(SA_UNCHANGED), Ni, KEi} -->
<-- HDR, SK {N(SA_UNCHANGED), Nr, KEr} <-- HDR, SK {N(SA_UNCHANGED), Nr, KEr}
The initiator sends a SA_UNCHANGED notification payload, a Nonce The initiator sends a SA_UNCHANGED notification payload, a Nonce
payload and a Diffie-Hellman value in the KEi payload. A new payload and a Diffie-Hellman value in the KEi payload. A new
initiator SPI is supplied in the SPI field of the SA_UNCHANGED initiator SPI is supplied in the SPI field of the SA_UNCHANGED
notification payload. notification payload.
The responder replies (using the same Message ID to respond) with a The responder replies (using the same Message ID to respond) with a
SA_UNCHANGED notification payload, a Nonce payload and a Diffie- SA_UNCHANGED notification payload, a Nonce payload and a Diffie-
Hellman value in the KEr payload. A new responder SPI is supplied in Hellman value in the KEr payload. A new responder SPI is supplied in
the SPI field of the SA_UNCHANGED notification payload. the SPI field of the SA_UNCHANGED notification payload.
When the SA_UNCHANGED notification payload is included, the SA This SA_UNCHANGED notification MUST be included in a CREATE_CHILD_SA
payload MUST NOT be included. exchange message when there is no SA payloads included. When the
SA_UNCHANGED notification payload is included, the SA payload MUST
3.2.2. Rekeying IKE SAs When Initiator's Cryptographic Suites Changed 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}
3.2.3. Rekeying IKE SAs When Responder's Cryptographic Suites Changed 3.2.2. Rekeying IKE SAs When Responder's Cryptographic Suites Changed
At the time of or before rekeying IKE SAs, the responder's At the time of or before rekeying IKE SAs, the responder's
cryptographic suites may be changed while there is no change of cryptographic suites may be changed while there is no change of
initiator's cryptographic suites. New cryptographic suites may be initiator's cryptographic suites. New cryptographic suites may be
added to the responder, or some outdated cryptographic suites may be added to the responder, or some outdated cryptographic suites may be
deleted from the responder. deleted from the responder. In this situation, the initiator MAY
send the SA_UNCHANGED notification payload instead of the SA payloads
In this situation, the initiator sends the SA_UNCHANGED notification in the CREATE_CHILD_SA request message at the time of rekeying IKE
payload instead of the SA payloads in the CREATE_CHILD_SA request SAs.
message at the time of rekeying IKE SAs.
If the responder decides to continue using the previously negotiated If the responder decides to continue using the previously negotiated
cryptographic suite to rekey the IKE SA, it MAY send the SA_UNCHANGED cryptographic suite to rekey the IKE SA, it MAY send the SA_UNCHANGED
notification payload in the CREATE_CHILD_SA response message, then notification payload in the CREATE_CHILD_SA response message, then
the rekeying is conducted like Section 3.2.1. the rekeying is conducted like the way described in Section 3.2.1.
If the responder decides to re-negotiate the cryptographic suite, it If the responder decides to re-negotiate the cryptographic suite, it
MUST send NO_PROPOSAL_CHOSEN notification payload in the MUST send NO_PROPOSAL_CHOSEN notification payload in the
CREATE_CHILD_SA response message. After receiving this error CREATE_CHILD_SA response message. After receiving this error
notification, the initiator MUST retry the CREATE_CHILD_SA exchange notification, the initiator MUST retry the CREATE_CHILD_SA exchange
with the SA payloads. Then the rekeying is conducted in the original with the SA payloads. Then the rekeying is conducted in the original
way defined in [RFC7296]. The CREATE_CHILD_SA message exchange in way defined in [RFC7296]. The CREATE_CHILD_SA message exchange in
this case is shown below: this case is shown below:
Initiator Responder Initiator Responder
-------------------------------------------------------------------- --------------------------------------------------------------------
HDR, SK {N(SA_UNCHANGED), Ni, KEi} --> HDR, SK {N(SA_UNCHANGED), Ni, KEi} -->
<-- HDR, SK {N(NO_PROPOSAL_CHOSEN), <-- HDR, SK {N(NO_PROPOSAL_CHOSEN),
Nr, KEr} Nr, KEr}
HDR, SK {SA, Ni, KEi} --> HDR, SK {SA, Ni, KEi} -->
<-- HDR, SK {SA, Ni, KEi} <-- HDR, SK {SA, Ni, KEi}
3.3. Optional Payload Optimization at Rekeying Child SAs Besides, if the responder only supports the Child SA rekeying
optimization and doesn't support the IKE SA rekeying optimization, it
can also follow the way described above, i.e., it MUST send
NO_PROPOSAL_CHOSEN notification payload in the CREATE_CHILD_SA
response message when receiving the SA_UNCHANGED notification at the
time of rekeying IKE SAs.
3.3. Payload Optimization at Rekeying Child SAs
The payload optimization at rekeying Child SAs MUST NOT be used The payload optimization at rekeying Child SAs MUST NOT be used
unless both peers have indicated their support of this extension by unless both peers have indicated their support of this extension by
using the negotiation method described in Section 3.1. If the using the negotiation method described in Section 3.1. If the
initiator or responder decides to use this payload optimization, then initiator decides to optimize the payloads at the time of rekeying
it includes the SA_TS_UNCHANGED notification in its CREATE_CHILD_SA Child SAs, then it includes the SA_TS_UNCHANGED notification in its
exchange message at the time of rekeying Child SAs. This CREATE_CHILD_SA exchange message. If the initiator decides not to do
SA_TS_UNCHANGED notification MUST be included in a CREATE_CHILD_SA the optimization, then it just sends the rekeying request message as
exchange message when there is no SA and TS payloads included. The the original way, the rekeying is conducted as [RFC7296] defined.
new Child SA is created with the SPI value in the SA_TS_UNCHANGED
notification. 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.
3.3.1. Rekeying Child SAs When No Change of Initiator and Responder's 3.3.1. Rekeying Child SAs When No Change of Initiator and Responder's
Cryptographic Suites and ACL Configuration Cryptographic Suites and ACL Configuration
At the time of rekeying Child SAs, the initiator MAY send the At the time of rekeying Child SAs, the initiator MAY send the
SA_TS_UNCHANGED notification payload instead of the SA and TS SA_TS_UNCHANGED notification payload instead of the SA and TS
payloads when there is no change in its cryptographic suites and ACL payloads when there is no change in its cryptographic suites and ACL
configuration since last negotiation. After receiving the configuration since last negotiation. After receiving the
initiator's request message with the SA_TS_UNCHANGED notification, initiator's request message with the SA_TS_UNCHANGED notification,
the responder MAY respond to the initiator with the SA_TS_UNCHANGED the responder MAY respond to the initiator with the SA_TS_UNCHANGED
notification payload instead of the SA and TS payloads if there is notification payload instead of the SA and TS payloads if there is
also no change in its cryptographic suites and ACL configuration also no change in its cryptographic suites and ACL configuration
since last negotiation. since last negotiation.
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 MAY send the
SA_TS_UNCHANGED notification payload instead of the SA and TS
payloads in the rekeying request message. In this SA_TS_UNCHANGED
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
SA_TS_UNCHANGED 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 MAY send
the rekeying respond message to the initiator with the
SA_TS_UNCHANGED notification payload instead of the SA and TS
payloads. In this SA_TS_UNCHANGED notification, it contains the
responder's new SPI used for creating the new Child SA.
According to the initiator's new SPI and the responder's new SPI, 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: The CREATE_CHILD_SA message exchange in this case is shown below:
Initiator Responder Initiator Responder
-------------------------------------------------------------------- --------------------------------------------------------------------
HDR, SK {N(REKEY_SA), N(SA_TS_UNCHANGED), HDR, SK {N(REKEY_SA), N(SA_TS_UNCHANGED),
Ni, [KEi,]} --> Ni, [KEi,]} -->
<-- HDR, SK {N(SA_TS_UNCHANGED), <-- HDR, SK {N(SA_TS_UNCHANGED),
Nr, [KEr,]} Nr, [KEr,]}
3.3.2. Rekeying Child SAs When Initiator's Cryptographic Suites or ACL This SA_TS_UNCHANGED notification MUST be included in a
Configuration Changed CREATE_CHILD_SA exchange message when there is no SA and TS payloads
included at the time of rekeying Child SAs. When the SA_TS_UNCHANGED
At the time of or before rekeying Child SAs, the initiator's notification payload is included, the SA and TS payloads MUST NOT be
cryptographic suites or ACL configuration may be changed while there included.
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}
3.3.3. Rekeying Child SAs When Responder's Cryptographic Suites or ACL 3.3.2. Rekeying Child SAs When Responder's Cryptographic Suites or ACL
Configuration Changed Configuration Changed
At the time of or before rekeying Child SAs, the responder's At the time of or before rekeying Child SAs, the responder's
cryptographic suites or ACL configuration may be changed while there cryptographic suites or ACL configuration may be changed while there
is no change of initiator's cryptographic suites and ACL is no change of initiator's cryptographic suites and ACL
configuration. configuration. In this situation, the initiator MAY send the
SA_TS_UNCHANGED notification payload instead of the SA and TS
In this situation, the initiator MAY send the SA_TS_UNCHANGED payloads in the CREATE_CHILD_SA request message at the time of
notification payload instead of the SA and TS payloads in the rekeying Child SAs.
CREATE_CHILD_SA request message at the time of rekeying Child SAs.
If the responder decides to continue using the previously negotiated If the responder decides to continue using the previously negotiated
cryptographic suite and Traffic Selectors to rekey the Child SA, it cryptographic suite and Traffic Selectors to rekey the Child SA, it
MAY send the SA_TS_UNCHANGED notification payload in the MAY send the SA_TS_UNCHANGED notification payload in the
CREATE_CHILD_SA response message, then the rekeying is conducted like CREATE_CHILD_SA response message, then the rekeying is conducted like
Section 3.3.1. Section 3.3.1.
If the responder decides to re-negotiate the cryptographic suite or If the responder decides to re-negotiate the cryptographic suite or
Traffic Selectors, it MUST send NO_PROPOSAL_CHOSEN notification Traffic Selectors, it MUST send NO_PROPOSAL_CHOSEN notification
payload in the CREATE_CHILD_SA response message. After receiving payload in the CREATE_CHILD_SA response message. After receiving
skipping to change at page 8, line 33 skipping to change at page 9, line 15
Initiator Responder Initiator Responder
-------------------------------------------------------------------- --------------------------------------------------------------------
HDR, SK {N(SA_TS_UNCHANGED), Ni, KEi} --> HDR, SK {N(SA_TS_UNCHANGED), Ni, KEi} -->
<-- HDR, SK {N(NO_PROPOSAL_CHOSEN), <-- HDR, SK {N(NO_PROPOSAL_CHOSEN),
Nr, KEr} Nr, KEr}
HDR, SK {N(REKEY_SA), SA, Ni, [KEi,] HDR, SK {N(REKEY_SA), SA, Ni, [KEi,]
TSi, TSr} --> TSi, TSr} -->
<-- HDR, SK {SA, Nr, [KEr,] <-- HDR, SK {SA, Nr, [KEr,]
TSi, TSr} TSi, TSr}
Besides, if the responder only supports the IKE SA rekeying
optimization and doesn't support the Child SA rekeying optimization,
it can also follow the way described above, i.e., it MUST send
NO_PROPOSAL_CHOSEN notification payload in the CREATE_CHILD_SA
response message when receiving the SA_TS_UNCHANGED notification at
the time of rekeying Child SAs.
4. Payload Formats 4. Payload Formats
4.1. MINIMAL_REKEY_SUPPORTED Notification 4.1. MINIMAL_REKEY_SUPPORTED Notification
The MINIMAL_REKEY_SUPPORTED notification is used by the initiator and The MINIMAL_REKEY_SUPPORTED notification is used by the initiator and
responder to inform their ability of optimizing optional payload at responder to inform their ability of optimizing optional payload at
the time of rekeying IKE SAs and Child SAs to the peers. It is the time of rekeying IKE SAs and Child SAs to the peers. It is
formatted as follows: formatted as follows:
1 2 3 1 2 3
 End of changes. 27 change blocks. 
141 lines changed or deleted 170 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/