< draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-00.txt   draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01.txt >
IPSECME S. Kampati IPSECME S. Kampati
Internet-Draft Huawei Internet-Draft M. Bharath
Intended status: Standards Track Feb 18, 2019 Intended status: Standards Track W. Pan
Expires: Aug 22, 2019 Expires: November 22, 2019 Huawei
May 21, 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-00 draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01
Abstract Abstract
This document describes a method for reduce the size of the Internet This document describes a method for reducing the size of the
Key Exchange version 2 (IKEv2) exchanges at time of IKE rekey and Internet Key Exchange version 2 (IKEv2) exchanges at time of rekeying
Child SA Rekey by removing or making optional of SA & TS payloads. IKE SAs and Child SAs by removing or making optional of SA & TS
Reducing size of IKEv2 exchange is desirable for low power payloads. Reducing size of IKEv2 exchanges is desirable for low
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.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 Aug 22, 2019. This Internet-Draft will expire on November 22, 2019.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Negotiation of Support for Optimizing Optional Payload at
3.2 Rekeying IKE SAs with the CREATE_CHILD_SA . . . . . . . . . 4 Rekeying IKE SAs and Child SAs . . . . . . . . . . . . . 3
3.2.1 Exchange with out SA payload . . . . . . . . . . . . . 4 3.2. Optional Payload Optimization at Rekeying IKE SAs . . . . 4
3.2.2 Exchange with optional SA payload . . . . . . . . . . 5 3.2.1. Rekeying IKE SAs When No Change of Initiator and
3.2.3 Exchange when there is change in responder . . . . . . 6 Responder's Cryptographic Suites . . . . . . . . . . 4
3.3 Exchange without SA and TS payload . . . . . . . . . . . . . 7 3.2.2. Rekeying IKE SAs When Initiator's Cryptographic
4 Security Considerations . . . . . . . . . . . . . . . . . . . . 7 Suites Changed . . . . . . . . . . . . . . . . . . . 5
5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 3.2.3. Rekeying IKE SAs When Responder's Cryptographic
4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Suites Changed . . . . . . . . . . . . . . . . . . . 5
4.1. Normative References . . . . . . . . . . . . . . . . . . . 8 3.3. Optional Payload Optimization at Rekeying Child SAs . . . 6
4.2. Informative References . . . . . . . . . . . . . . . . . . 8 3.3.1. Rekeying Child SAs When No Change of Initiator and
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Responder's Cryptographic Suites and ACL
Configuration . . . . . . . . . . . . . . . . . . . . 6
3.3.2. Rekeying Child SAs When Initiator's Cryptographic
Suites or ACL Configuration Changed . . . . . . . . . 7
3.3.3. Rekeying Child SAs When Responder's Cryptographic
Suites or ACL Configuration Changed . . . . . . . . . 7
4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. MINIMAL_REKEY_SUPPORTED Notification . . . . . . . . . . 8
4.2. SA_UNCHANGED Notification . . . . . . . . . . . . . . . . 9
4.3. SA_TS_UNCHANGED Notification . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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 kBytes.
In 4G network security gateways/ePDG and in 5G networks cRAN/Cloud In 4G networks security gateways/ePDG and in 5G networks cRAN/Cloud
will support more than one 100000 IKE/IPSEC tunnels. So on an will support more than 100,000 IKE/IPSEC tunnels. So on an average,
average, for every second we encounter many rekeys. This takes huge for every second there may be hundreds or thousands of IKE SAs and
amount of bandwidth, packet fragmentation and more processing. This Child SAs that are rekeying. This takes huge amount of bandwidth,
can be solved by introducing this solution. 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 This is useful in Internet of Things (IoT) devices which utilizing
lower power consumption technology. The appendix A of [IPSEC-IOT- lower power consumption technology. The appendix A of
REQS] gives some estimate data. [I-D.mglt-6lo-diet-esp-requirements] gives some estimate data.
Most of devices they don't preferred to change suits frequently.
Taking this advantage we can make SA and TS as optional payloads at
time of IKE SA rekey and IPSEC SA rekey.
In ESP transport mode if when protocol ID and port numbers are any to
any than no need to send TS payloads.
In case of Rekeying IKE SAs with the CREATE_CHILD_SA Exchange Minimum Most devices don't prefer to change cryptographic suites frequently.
size of (single set of cryptographic suite)SA payload 52 bytes, we By taking this advantage the SA and TS payloads can be made optional
can replace these payloads with Notify payload N(NEW_SPI) to get SPI at the time of rekeying IKE SAs and Child SAs. In such situation,
which of Size is 16 bytes. So we are have reduced 36 bytes. 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 Child SAs with the CREATE_CHILD_SA Exchange In case of rekeying IKE SAs, the SA payloads can be optimized if
Minimum size of SA payload 40 bytes, each TS size 24 bytes (2*24 = 48 there is no change of cryptographic suites. In case of rekeying
bytes). total Size 88 bytes. we can replace these payloads with Child SAs, the SA and TS payloads can be optimized if there is no
Notify payload N(NEW_SPI) to get SPI which of Size is 12 bytes, So change of cryptographic suites and ACL configuration.
total reduced size is 76 bytes.
2. Conventions Used in This Document 2. Conventions Used in This Document
2.1. Requirements Language 2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"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.
3.1 Negotiation 3.1. Negotiation of Support for Optimizing Optional Payload at Rekeying
IKE SAs and Child SAs
The initiator indicates its support for IKE optional payloads at The initiator indicates its support for optimizing optional payloads
rekey and willingness to use it by including a Notification payload at rekeying IKE SAs and Child SAs by including a Notify payload of
of type IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTED in the IKE_SA_INIT type MINIMAL_REKEY_SUPPORTED in the IKE_AUTH request message. If the
request message. If the responder also supports this extension and responder also supports this extension, it includes the
is willing to use it, it includes this notification in the response MINIMAL_REKEY_SUPPORTED notification in the response message. If the
message. 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.
Initiator Responder The IKE_AUTH message exchange in this case is shown below:
-----------------------------------------------------------------
HDR(A,0), SAi1, KEi, Ni, -->
N(IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTED)
<-- HDR, SAr1, KEr, Nr, [CERTREQ,] Initiator Responder
N(IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTED) --------------------------------------------------------------------
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 Notify payload is formatted as follows: 3.2. Optional Payload Optimization at Rekeying IKE SAs
1 2 3 The payload optimization at rekeying IKE SAs MUST NOT be used unless
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 both peers have indicated their support of this extension by using
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ the negotiation method described in Section 3.1. If the initiator or
| Next Payload |C| RESERVED | Payload Length | responder decides to use this payload optimization, then it includes
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ the SA_UNCHANGED notification in its CREATE_CHILD_SA exchange message
|Protocol ID(=0)| SPI Size (=0) | Notify Message Type | 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.
o Protocol ID (1 octet) - MUST be zero. 3.2.1. Rekeying IKE SAs When No Change of Initiator and Responder's
Cryptographic Suites
o SPI Size (1 octet) - MUST be zero, meaning no Security Parameter At the time of rekeying IKE SAs, the initiator MAY send the
Index (SPI) is present. 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.
o Notify Message Type (2 octets) - MUST be <Need to get value from The CREATE_CHILD_SA message exchange in this case is shown below:
IANA>, the value assigned for the
IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTED notification.
3.2 Rekeying IKE SAs with the CREATE_CHILD_SA Initiator Responder
--------------------------------------------------------------------
HDR, SK {N(SA_UNCHANGED), Ni, KEi} -->
<-- HDR, SK {N(SA_UNCHANGED), Nr, KEr}
IKE REKEY optional SA payloads support MUST NOT be used unless both The initiator sends a SA_UNCHANGED notification payload, a Nonce
peers have indicated their support for it. The NEW_SPI notification payload and a Diffie-Hellman value in the KEi payload. A new
MUST be included in a CREATE_CHILD_SA exchange when there is no SA initiator SPI is supplied in the SPI field of the SA_UNCHANGED
payload, The New IKE SA is created with the SPI values in the NEW_SPI notification payload.
Notify payload.
3.2.1 Exchange with out SA 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.
At time of IKE rekey initiator sends NEW_SPI notification payload When the SA_UNCHANGED notification payload is included, the SA
instead SA payload when there is no change in initial negotiated payload MUST NOT be included.
cryptographic suite. Responder sends NEW_SPI notification payload
instead SA payload when there is no change in initial negotiated
cryptographic suite.
An IKEv2 message exchange with this modification is shown below: 3.2.2. Rekeying IKE SAs When Initiator's Cryptographic Suites Changed
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 Initiator Responder
---------------------------------------------------------------- --------------------------------------------------------------------
HDR, SK {N(NEW_SPI), Ni} --> HDR, SK {SA, Ni, KEi} -->
<-- HDR, SK {N(SA_UNCHANGED), Nr, KEr}
Initiator sends NEW_SPI notification payload, Nonce payload and a 3.2.3. Rekeying IKE SAs When Responder's Cryptographic Suites Changed
Diffie-Hellman value in the KEi payload.
A new initiator SPI is supplied in the SPI field of the NEW_SPI At the time of or before rekeying IKE SAs, the responder's
notification payload. 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.
The CREATE_CHILD_SA response for creating a new Child SA is: 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.
<-- HDR, SK {N(NEW_SPI), Nr} 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.
The responder replies (using the same Message ID to respond) with the If the responder decides to re-negotiate the cryptographic suite, it
NEW_SPI notification payload, Nonce payload and a Diffie-Hellman MUST send NO_PROPOSAL_CHOSEN notification payload in the
value in the KEr payload 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:
A new responder SPI is supplied in the SPI field of the SA payload. 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}
NEW_SPI notification payload is included, MUST NOT include NEW_SPI 3.3. Optional Payload Optimization at Rekeying Child SAs
notification payload.
The Notify payload is formatted as follows: 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.
0 1 2 3 3.3.1. Rekeying Child SAs When No Change of Initiator and Responder's
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 Cryptographic Suites and ACL Configuration
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protocol ID(=1)| SPI Size (=8) | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Security Parameter Index (SPI) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Protocol ID (1 octet) - MUST be 1. 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.
o SPI Size (1 octet) - this field MUST be 8. The CREATE_CHILD_SA message exchange in this case is shown below:
o Notify Message Type (2 octets) - MUST be <To be assigned by Initiator Responder
IANA>, the value assigned for the NEW_SPI notification. --------------------------------------------------------------------
HDR, SK {N(REKEY_SA), N(SA_TS_UNCHANGED),
Ni, [KEi,]} -->
<-- HDR, SK {N(SA_TS_UNCHANGED),
Nr, [KEr,]}
o SPI - IKE SPI (4 octets), initiator will send initiator IKE 3.3.2. Rekeying Child SAs When Initiator's Cryptographic Suites or ACL
SPI. Responder will send responder IKE SPI Configuration Changed
3.2.2 Exchange with optional SA payload At the time of or before rekeying Child SAs, the initiator's
Initiator side new cryptographic suites are added after initial SA cryptographic suites or ACL configuration may be changed while there
creation, So at time of CREATE_CHILD_SA initiator sends SA payload is no change of responder's cryptographic suites and ACL
when multiple cryptographic suite, but responder selected previous configuration.
suits at time of CREATE_CHILD_SA Exchange, so responder MAY send
NEW_SPI notification payload instead of SA payload. so initiator need
to use old IKE SA negotiated cryptographic suits to new IKE SA.
Initiator Responder 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 {SA, Ni, KEi} --> HDR, SK {N(REKEY_SA), SA, Ni, [KEi,]
TSi, TSr} -->
<-- HDR, SK {N(SA_TS_UNCHANGED),
Nr, KEr}
<-- HDR, SK {N(NEW_SPI), Nr} 3.3.3. Rekeying Child SAs When Responder's Cryptographic Suites or ACL
Configuration Changed
3.2.3 Exchange when there is change in responder 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.
At time of IKE rekey initiator sends NEW_SPI notification payload In this situation, the initiator MAY send the SA_TS_UNCHANGED
instead SA payload when there is no change in initial negotiated notification payload instead of the SA and TS payloads in the
cryptographic suite. Responder side there is change in cryptographic CREATE_CHILD_SA request message at the time of rekeying Child SAs.
suite so responder send NO_PROPOSAL_CHOSEN notification payload to
initiator.
Initiator need to send new rekey request with SA payload. 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.
Initiator Responder 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(NEW_SPI), Ni, KEi} --> 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}
<-- HDR, SK {N(NO_PROPOSAL_CHOSEN), Nr, KEr} 4. Payload Formats
HDR, SK {SA, Ni, KEi} --> 4.1. MINIMAL_REKEY_SUPPORTED Notification
<-- HDR, SK {SA, Ni, KEi} 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:
3.3 Exchange without SA and TS payload 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Child SA REKEY optional SA and TS paylaods, support MUST NOT be used o Protocol ID (1 octet) - MUST be 0.
unless both peers have indicated their support for it.
The NEW_SPI notification MUST be included in a CREATE_CHILD_SA o SPI Size (1 octet) - MUST be 0, meaning no SPI is present.
exchange when there is no SA payload, The New Child SA is created
with the SPI values in the NEW_SPI Notify payload.
An Rekeying Child SAs with the CREATE_CHILD_SA Exchange exchange with o Notify Message Type (2 octets) - MUST be <Need to get value from
this modification is shown below: IANA>, the value assigned for the MINIMAL_REKEY_SUPPORTED
notification.
Initiator Responder This notification contains no data.
------------------------------------------------------------------
HDR, SK {N(NEW_SPI), Ni, [KEi,]} --> 4.2. SA_UNCHANGED Notification
<-- HDR, SK {N(NEW_SPI), Nr, [KEr,]} 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:
The Notify payload 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.
o SPI Size (1 octet) - MUST be 8.
o Notify Message Type (2 octets) - MUST be <Need to get value from
IANA>, the value assigned for the SA_UNCHANGED notification.
o SPI (8 octets) - Security Parameter Index. The initiator sends
initiator SPI. The responder sends responder SPI.
4.3. SA_TS_UNCHANGED Notification
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
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 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 | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protocol ID | SPI Size (=4) | Notify Message Type | |Protocol ID | SPI Size (=4) | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Security Parameter Index (SPI) |
~ Security Parameter Index (SPI) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Protocol ID (1 octet) - this field MUST contain either (2) to o Protocol ID (1 octet) - MUST be either (2) to indicate AH or (3)
indicate AH or (3) to indicate ESP. to indicate ESP.
o SPI Size (1 octet) - MUST be 4. o SPI Size (1 octet) - MUST be 4.
o Notify Message Type (2 octets) - MUST be <Need to get value from o Notify Message Type (2 octets) - MUST be <Need to get value from
IANA>, the value assigned for the NEW_SPI notification. IANA>, the value assigned for the SA_TS_UNCHANGED notification.
o SPI (variable length) - AH/ESP SPI (4 octets), initiator will o SPI (4 octets) - Security Parameter Index. The initiator sends
send initiator SPI. Responder will send responder SPI initiator SPI. The responder sends responder SPI.
4 Security Considerations 5. IANA Considerations
TBD
5 IANA Considerations This document defines two new Notify Message Types in the "IKEv2
This document defines two new Notify Message Types in the "Notify Notify Message Types - Status Types" registry. IANA is requested to
Message Types - Status Types" registry. IANA is requested to assign assign codepoints in this registry.
codepoints in this registry.
NOTIFY messages: status types Value NOTIFY messages: status types Value
---------------------------------------------------------- ----------------------------------------------------------
NEW_SPI TBD MINIMAL_REKEY_SUPPORTED TBD
IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTED TBD SA_UNCHANGED TBD
SA_TS_UNCHANGED TBD
4. References 6. Security Considerations
4.1. Normative References TBD
[RFC2119] 7. References
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] 7.1. Normative References
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] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Requirement Levels", BCP 14, RFC 2119,
Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc8174>. <https://www.rfc-editor.org/info/rfc2119>.
4.2. Informative References [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>.
[IPSEC-IOT-REQS] [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
Migault, D., Guggemos, T., and C. Bormann, "Requirements for 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
Diet-ESP the IPsec/ESP protocol for IoT", draft-mglt-6lo-diet- May 2017, <https://www.rfc-editor.org/info/rfc8174>.
esp-requirements-02 (work in progress), July 2016.
7.2. Informative References
[I-D.mglt-6lo-diet-esp-requirements]
Migault, D., Guggemos, T., and C. Bormann, "Requirements
for Diet-ESP the IPsec/ESP protocol for IoT", draft-mglt-
6lo-diet-esp-requirements-02 (work in progress), July
2016.
Authors' Addresses Authors' Addresses
Sandeep Kampati Sandeep Kampati
Huawei Technologies Huawei Technologies
Divyashree Techno Park, Whitefield Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066 Bangalore, Karnataka 560066
India India
Email: sandeepkampati@huawei.com Email: sandeepkampati@huawei.com
Meduri S S Bharath
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
Email: MeduriS.Bharath@huawei.com
Wei Pan
Huawei Technologies
101 Software Avenue, Yuhuatai District
Nanjing, Jiangsu
China
Email: william.panwei@huawei.com
 End of changes. 73 change blocks. 
195 lines changed or deleted 344 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/