IKEv2 Optional
SA&TS Payloads in Child ExchangeHuawei TechnologiesDivyashree Techno Park, WhitefieldBangaloreKarnataka560066Indiasandeepkampati@huawei.comHuawei TechnologiesDivyashree Techno Park, WhitefieldBangaloreKarnataka560066IndiaMeduriS.Bharath@huawei.comHuawei Technologies101 Software Avenue, Yuhuatai DistrictNanjingJiangsuChinawilliam.panwei@huawei.comIPSECMEThis document describes a method for reducing the size of the
Internet Key Exchange version 2 (IKEv2) exchanges at time of rekeying
IKE SAs and Child SAs by removing or making optional of SA & TS
payloads. Reducing size of IKEv2 exchanges is desirable for low power
consumption battery powered devices. It also helps to avoid IP
fragmentation of IKEv2 messages.The Internet Key Exchange protocol version 2 (IKEv2) specified in
is used in the IP Security (IPsec) architecture
for the purposes of Security Association (SA) parameters negotiation and
authenticated key exchange. The protocol uses UDP as the transport for
its messages, which size varies from less than one hundred bytes to
several kBytes.In 4G networks security gateways/ePDG and in 5G networks cRAN/Cloud
will support more than 100,000 IKE/IPSEC tunnels. So on an average, for
every second there may be hundreds or thousands of IKE SAs and Child SAs
that are rekeying. This takes huge amount of bandwidth, packet
fragmentation and more processing resources. And it can be solved by
introducing the solution described in this document.This is useful in Internet of Things (IoT) devices which utilizing
lower power consumption technology. The appendix A of gives some estimate
data.Most devices don't prefer to change cryptographic suites frequently.
By taking this advantage the SA and TS payloads can be made optional at
the time of rekeying IKE SAs and Child SAs. In such situation, only a
new SPI value is needed to create the new IKE SA and Child SA. So a new
Notify payload which contains the needed SPI value can be sent instead
of the SA and TS payloads.In case of rekeying IKE SAs, the SA payloads can be optimized if
there is no change of cryptographic suites. In case of rekeying Child
SAs, the SA and TS payloads can be optimized if there is no change of
cryptographic suites and ACL configuration.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 when, and only
when, they appear in all capitals, as shown here.This section provides protocol details and contains the normative
parts.The initiator indicates its support for optimizing optional
payloads at rekeying IKE SAs and Child SAs by including a Notify
payload of type MINIMAL_REKEY_SUPPORTED in the IKE_AUTH request
message. If the responder also supports this extension, it includes
the MINIMAL_REKEY_SUPPORTED notification in the response message. If
the responder doesn't support this extension, it MUST ignore the
MINIMAL_REKEY_SUPPORTED notification sent by the initiator and MUST
NOT respond error to the initiator.The IKE_AUTH message exchange in this case is shown below:The payload optimization at rekeying IKE SAs MUST NOT be used
unless both peers have indicated their support of this extension by
using the negotiation method described in Section 3.1. If the
initiator or responder decides to use this payload optimization, then
it includes the SA_UNCHANGED notification in its CREATE_CHILD_SA
exchange message at the time of rekeying IKE SAs. This SA_UNCHANGED
notification MUST be included in a CREATE_CHILD_SA exchange message
when there is no SA payloads included. The new IKE SA is created with
the SPI value in the SA_UNCHANGED notification.At the time of rekeying IKE SAs, the initiator MAY send the
SA_UNCHANGED notification payload instead of the SA payloads when
there is no change in its cryptographic suites since last
negotiation. After receiving the initiator's request message with
the SA_UNCHANGED notification, the responder MAY respond to the
initiator with the SA_UNCHANGED notification payload instead of the
SA payloads if there is also no change in its cryptographic suites
since last negotiation.The CREATE_CHILD_SA message exchange in this case is shown
below:The initiator sends a SA_UNCHANGED notification payload, a Nonce
payload and a Diffie-Hellman value in the KEi payload. A new
initiator SPI is supplied in the SPI field of the SA_UNCHANGED
notification payload.The responder replies (using the same Message ID to respond) with
a SA_UNCHANGED notification payload, a Nonce payload and a
Diffie-Hellman value in the KEr payload. A new responder SPI is
supplied in the SPI field of the SA_UNCHANGED notification
payload.When the SA_UNCHANGED notification payload is included, the SA
payload MUST NOT be included.At the time of or before rekeying IKE SAs, the initiator's
cryptographic suites may be changed while there is no change of
responder's cryptographic suites. New cryptographic suites may be
added to the initiator, or some outdated cryptographic suites may be
deleted from the initiator.In this situation, the initiator MUST send the SA payloads in the
CREATE_CHILD_SA request message at the time of rekeying IKE SAs.If the responder selects a different cryptographic suite than
which was previously negotiated, then the rekeying MUST be conducted
in the original way defined in , 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:At the time of or before rekeying IKE SAs, the responder's
cryptographic suites may be changed while there is no change of
initiator's cryptographic suites. New cryptographic suites may be
added to the responder, or some outdated cryptographic suites may be
deleted from the responder.In this situation, the initiator sends the SA_UNCHANGED
notification payload instead of the SA payloads in the
CREATE_CHILD_SA request message at the time of rekeying IKE SAs.If the responder decides to continue using the previously
negotiated cryptographic suite to rekey the IKE SA, it MAY send the
SA_UNCHANGED notification payload in the CREATE_CHILD_SA response
message, then the rekeying is conducted like Section 3.2.1.If the responder decides to re-negotiate the cryptographic suite,
it MUST send NO_PROPOSAL_CHOSEN notification payload in the
CREATE_CHILD_SA response message. After receiving this error
notification, the initiator MUST retry the CREATE_CHILD_SA exchange
with the SA payloads. Then the rekeying is conducted in the original
way defined in . The CREATE_CHILD_SA message
exchange in this case is shown below:The payload optimization at rekeying Child SAs MUST NOT be used
unless both peers have indicated their support of this extension by
using the negotiation method described in Section 3.1. If the
initiator or responder decides to use this payload optimization, then
it includes the SA_TS_UNCHANGED notification in its CREATE_CHILD_SA
exchange message at the time of rekeying Child SAs. This
SA_TS_UNCHANGED notification MUST be included in a CREATE_CHILD_SA
exchange message when there is no SA and TS payloads included. The new
Child SA is created with the SPI value in the SA_TS_UNCHANGED
notification.At the time of rekeying Child SAs, the initiator MAY send the
SA_TS_UNCHANGED notification payload instead of the SA and TS
payloads when there is no change in its cryptographic suites and ACL
configuration since last negotiation. After receiving the
initiator's request message with the SA_TS_UNCHANGED notification,
the responder MAY respond to the initiator with the SA_TS_UNCHANGED
notification payload instead of the SA and TS payloads if there is
also no change in its cryptographic suites and ACL configuration
since last negotiation.The CREATE_CHILD_SA message exchange in this case is shown
below: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
, 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: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 . The CREATE_CHILD_SA message exchange in this
case is shown below: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:Protocol ID (1 octet) - MUST be 0.SPI Size (1 octet) - MUST be 0, meaning no SPI is present.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.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:Protocol ID (1 octet) - MUST be 1.SPI Size (1 octet) - MUST be 8.Notify Message Type (2 octets) - MUST be <Need to get value
from IANA>, the value assigned for the SA_UNCHANGED
notification.SPI (8 octets) - Security Parameter Index. The initiator sends
initiator SPI. The responder sends responder SPI.The SA_TS_UNCHANGED notification is used to replace the SA payloads
and TS payloads at the time of rekeying Child SAs when there is no
change of cryptographic suites and ACL configuration in initiator or
responder. It is formatted as follows:Protocol ID (1 octet) - MUST be either (2) to indicate AH or
(3) to indicate ESP.SPI Size (1 octet) - MUST be 4.Notify Message Type (2 octets) - MUST be <Need to get value
from IANA>, the value assigned for the SA_TS_UNCHANGED
notification.SPI (4 octets) - Security Parameter Index. The initiator sends
initiator SPI. The responder sends responder SPI.This document defines two new Notify Message Types in the "IKEv2
Notify Message Types - Status Types" registry. IANA is requested to
assign codepoints in this registry.TBD