IPSECME                                                       S. Kampati
Internet-Draft                                                    Huawei                                                M. Bharath
Intended status: Standards Track                            Feb 18, 2019                                  W. Pan
Expires: Aug November 22, 2019                                        Huawei
                                                            May 21, 2019

            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

   This document describes a method for reduce reducing the size of the
   Internet Key Exchange version 2 (IKEv2) exchanges at time of rekeying
   IKE rekey SAs and Child SA Rekey SAs by removing or making optional of SA & TS
   payloads.  Reducing size of IKEv2 exchange 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 Aug November 22, 2019.

Copyright Notice

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   3
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   3.  Protocol Details  . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1
     3.1.  Negotiation of Support for Optimizing Optional Payload at
           Rekeying IKE SAs and Child SAs  . . . . . . . . . . . . .   3
     3.2.  Optional Payload Optimization at Rekeying IKE SAs . . . .   4
       3.2.1.  Rekeying IKE SAs When No Change of Initiator and
               Responder's Cryptographic Suites  . . . . . . .  3
     3.2 . . .   4
       3.2.2.  Rekeying IKE SAs with the CREATE_CHILD_SA When Initiator's Cryptographic
               Suites Changed  . . . . . . . . .  4
       3.2.1  Exchange with out SA  payload . . . . . . . . . .   5
       3.2.3.  Rekeying IKE SAs When Responder's Cryptographic
               Suites Changed  . . . . .  4
       3.2.2  Exchange with optional SA  payload . . . . . . . . . .  5
       3.2.3  Exchange when there is change in responder . . . .   5
     3.3.  Optional Payload Optimization at Rekeying Child SAs . . .   6
     3.3 Exchange without SA
       3.3.1.  Rekeying Child SAs When No Change of Initiator and TS payload
               Responder's Cryptographic Suites and ACL
               Configuration . . . . . . . . . . . . .  7
   4 Security Considerations . . . . . . .   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
   5
   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 .  8
   4.  References . . . . . . . . . . . . . . . . . .  10
   7.  References  . . . . . . . .  8
     4.1. . . . . . . . . . . . . . . . . .  10
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . .  8
     4.2.  10
     7.2.  Informative References  . . . . . . . . . . . . . . . . . .  8  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . .  9  11

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

   In 4G network networks security gateways/ePDG and in 5G networks cRAN/Cloud
   will support more than one 100000 100,000 IKE/IPSEC tunnels.  So on an average,
   for every second we encounter many rekeys. 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. This processing resources.  And it can be
   solved by introducing the solution described in this solution. document.

   This is useful in Internet of Things (IoT) devices which utilizing
   lower power consumption technology.  The appendix A of [IPSEC-IOT-
   REQS]
   [I-D.mglt-6lo-diet-esp-requirements] gives some estimate data.

   Most of devices they don't preferred prefer to change suits cryptographic suites frequently.
   Taking
   By taking this advantage we can make the SA and TS as optional 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 rekey and IPSEC Child SA.
   So a new Notify payload which contains the needed SPI value can be
   sent instead of the 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 rekeying IKE SAs with SAs, the CREATE_CHILD_SA Exchange Minimum
   size of (single set of cryptographic suite)SA payload 52 bytes, we
   can replace these SA payloads with Notify payload N(NEW_SPI) to get SPI
   which of Size can be optimized if
   there is 16 bytes. So we are have reduced 36 bytes. no change of cryptographic suites.  In case of Rekeying rekeying
   Child SAs with SAs, the CREATE_CHILD_SA Exchange
   Minimum size of SA payload 40 bytes, each and TS size 24 bytes (2*24 = 48
   bytes). total Size 88 bytes. we can replace these payloads with
   Notify payload N(NEW_SPI) to get SPI which of Size is 12 bytes,  So
   total reduced size can be optimized if there is 76 bytes. 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.

3.1

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

   The initiator indicates its support for IKE optimizing optional payloads
   at
   rekey rekeying IKE SAs and willingness to use it Child SAs by including a Notification Notify payload of
   type IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTED MINIMAL_REKEY_SUPPORTED in the IKE_SA_INIT IKE_AUTH request message.  If the
   responder also supports this extension and
   is willing to use it, extension, it includes this 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(A,0), SAi1, KEi, Ni,
   --------------------------------------------------------------------
   HDR, SK {IDi, [CERT,] [CERTREQ,]
       [IDr,] AUTH, SAi2, TSi, TSr,
       N(MINIMAL_REKEY_SUPPORTED)} -->
   N(IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTED)
                                 <-- HDR, SAr1, KEr, Nr, [CERTREQ,]
                           N(IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTED)

   The Notify payload 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   | SK {IDr, [CERT,] AUTH,
                                         SAr2, TSi, TSr,
                                         N(MINIMAL_REKEY_SUPPORTED)}

3.2.  Optional Payload Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Protocol ID(=0)| SPI Size (=0) |      Notify Message Type      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Protocol ID (1 octet) - MUST be zero.

   o  SPI Size (1 octet) - MUST be zero, meaning no Security Parameter
      Index (SPI) is present.

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

3.2 Optimization at Rekeying IKE SAs with the CREATE_CHILD_SA

   The payload optimization at rekeying IKE REKEY optional SA payloads support SAs MUST NOT be used unless
   both peers have indicated their support for it. The NEW_SPI 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
   payload,
   payloads included.  The New new IKE SA is created with the SPI values value in
   the NEW_SPI
   Notify payload.

3.2.1  Exchange with out SA  payload SA_UNCHANGED notification.

3.2.1.  Rekeying IKE SAs When No Change of Initiator and Responder's
        Cryptographic Suites

   At the time of rekeying IKE rekey SAs, the initiator sends NEW_SPI MAY send the
   SA_UNCHANGED notification payload instead of the SA payload payloads when
   there is no change in initial negotiated its cryptographic suite. Responder sends NEW_SPI 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 payload when payloads if there is also no change in initial negotiated its cryptographic suite.

   An IKEv2 suites
   since last negotiation.

   The CREATE_CHILD_SA message exchange with in this modification case is shown below:

   Initiator                         Responder
   ----------------------------------------------------------------
   --------------------------------------------------------------------
   HDR, SK {N(NEW_SPI), Ni} {N(SA_UNCHANGED), Ni, KEi} -->

   Initiator
                                 <-- HDR, SK {N(SA_UNCHANGED), Nr, KEr}

   The initiator sends NEW_SPI 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 NEW_SPI SA_UNCHANGED
   notification payload.

   The CREATE_CHILD_SA response for creating a new Child SA is:

                                 <--  HDR, SK {N(NEW_SPI), Nr}

   The responder replies (using the same Message ID to respond) with the
   NEW_SPI a
   SA_UNCHANGED notification payload, a Nonce payload and a Diffie-Hellman Diffie-
   Hellman value in the KEr payload payload.  A new responder SPI is supplied in
   the SPI field of the SA SA_UNCHANGED notification payload.

   NEW_SPI

   When the SA_UNCHANGED notification payload is included, MUST NOT include NEW_SPI
   notification payload.

   The Notify the SA
   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(=1)| SPI Size (=8) |      Notify Message Type      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                Security Parameter Index (SPI)                 ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      o  Protocol ID (1 octet) - MUST NOT be 1.

      o  SPI Size (1 octet) -  this field MUST included.

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

      o  Notify Message Type (2 octets) - MUST changed while there is no change of
   responder's cryptographic suites.  New cryptographic suites may be <To
   added to the initiator, or some outdated cryptographic suites may be assigned by
      IANA>,
   deleted from the value assigned for initiator.

   In this situation, the NEW_SPI notification.

      o  SPI  - IKE SPI (4 octets), initiator will send initiator IKE
      SPI. Responder will MUST send responder IKE SPI

3.2.2  Exchange with optional SA  payload
   Initiator side new cryptographic suites are added after initial the SA
   creation, So payloads in the
   CREATE_CHILD_SA request message at the time of  CREATE_CHILD_SA initiator sends SA payload
   when multiple rekeying IKE SAs.

   If the responder selects a different cryptographic suite, but 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 previous
   suits at time of cryptographic suite in the CREATE_CHILD_SA Exchange, so
   response message.

   If the responder selects the previously negotiated cryptographic
   suite to rekey the IKE SA, it MAY send
   NEW_SPI the SA_UNCHANGED notification
   payload instead of the SA payload. so payload in the CREATE_CHILD_SA response
   message, and the initiator need
   to MUST use old IKE SA negotiated the cryptographic suits 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(NEW_SPI), Nr}

3.2.3  Exchange when there is change in responder {N(SA_UNCHANGED), Nr, KEr}

3.2.3.  Rekeying IKE SAs When Responder's Cryptographic Suites Changed

   At the time of or before rekeying IKE rekey 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 NEW_SPI the SA_UNCHANGED notification
   payload instead of the SA payload when there is no change payloads in initial 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. Responder side there is change in cryptographic suite so responder to rekey the IKE SA, it MAY send NO_PROPOSAL_CHOSEN 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
   initiator.

   Initiator need to re-negotiate the cryptographic suite, it
   MUST send new rekey request 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 payload. 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), {N(SA_UNCHANGED), Ni, KEi} -->
                                 <-- HDR, SK {N(NO_PROPOSAL_CHOSEN),
                                         Nr, KEr}
   HDR, SK {SA, Ni, KEi} -->
                                 <-- HDR, SK {SA, Ni, KEi}

3.3 Exchange without SA and TS

3.3.  Optional Payload Optimization at Rekeying Child SAs

   The payload optimization at rekeying Child SA REKEY optional SA and TS paylaods, support SAs MUST NOT be used
   unless both peers have indicated their support for it.

   The NEW_SPI 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 payload, and TS payloads included.  The New
   new Child SA is created with the SPI values value in the NEW_SPI Notify payload.

   An SA_TS_UNCHANGED
   notification.

3.3.1.  Rekeying Child SAs When No Change of Initiator and Responder's
        Cryptographic Suites and ACL Configuration

   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 Exchange message exchange with in this modification case is shown below:

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

3.3.2.  Rekeying Child SAs When Initiator's Cryptographic Suites or ACL
        Configuration Changed

   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 Notify 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
        Configuration Changed

   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}

4.  Payload Formats

4.1.  MINIMAL_REKEY_SUPPORTED Notification

   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      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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.  SA_UNCHANGED Notification

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

   o  Protocol ID (1 octet) -  this field MUST contain 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 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)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Protocol ID (1 octet) - MUST be either (2) to indicate AH or (3)
      to indicate ESP.

   o  SPI Size (1 octet) - MUST be 4.

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

   o  SPI (variable length) - AH/ESP SPI (4 octets), octets) - Security Parameter Index.  The initiator will
      send sends
      initiator SPI. Responder will send  The responder SPI

4 Security Considerations
   TBD

5 sends responder SPI.

5.  IANA Considerations

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

   NOTIFY messages: status types            Value
   ----------------------------------------------------------
   NEW_SPI
   MINIMAL_REKEY_SUPPORTED                  TBD
   IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTED
   SA_UNCHANGED                             TBD

4.
   SA_TS_UNCHANGED                          TBD

6.  Security Considerations

   TBD

7.  References

4.1.

7.1.  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, 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>. <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>.

4.2.

7.2.  Informative References

   [IPSEC-IOT-REQS]

   [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 draft-mglt-
              6lo-diet-esp-requirements-02 (work in progress), July
              2016.

Authors' Addresses

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

   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