Hmm, it used to be that if you are subscribed to one IETF list, you can
post to any of them. That does not seem to work for the ipsec list :/
---------- Forwarded message ---------
From: Paul Wouters <paul.wout...@aiven.io>
Date: Sun, Jul 11, 2021 at 11:34 PM
Subject: Re: [IPsec] I-D Action:
draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.txt
To: Panwei (William) <william.pan...@huawei.com>
Cc: ipsec@ietf.org <ipsec@ietf.org>
On Mon, 5 Jul 2021, Panwei (William) wrote:
Hi Wei Pan,
> According to the discussion on the mailing list, I update the draft to
version 05. In this version, I deleted the unnecessary considerations for
the configuration changes. For now, the solution is very simple and just
includes the negotiation at creating IKE SAs and optimization at rekeying
IKE and Child SAs.
>
> Comments and feedbacks are more than welcome.
It is lookger much better and simpler, but I still had a few issues and
wanted to make the document a bit shorter and clearer. I made some
changes for your consideration. I've attached an updated xml and txt file
in case you would like to use my changes. The changes are:
- Reduced the text that was used to explain a lot of IKEv2 basics.
Instead, a reference to IKEv2 should be enough. This greatly simplifies
the text.
- Remove the parts about "changed configuration".
If the crypto parameters have changed, you SHOULD NOT use REKEY. RFC 7296
says this:
In Section 2.8, "Note that, when rekeying, the new Child SA MAY have
different Traffic Selectors and algorithms than the old one" was
changed to "Note that, when rekeying, the new Child SA SHOULD NOT
have different Traffic Selectors and algorithms than the old one".
So if the configuration has changed, you should not do any kind of REKEY,
whether it is OPTIMIZED or not. You should do a re-authentication (in
other words, a new IKE from scratch)
- IKE REKEY MUST contain KE, because RFC 7296 says:
The main reason for rekeying the IKE SA is to ensure that the
compromise of old keying material does not provide information about
the current keys, or vice versa. Therefore, implementations MUST
perform a new Diffie-Hellman exchange when rekeying the IKE SA. In
other words, an initiator MUST NOT propose the value "NONE" for the
Diffie-Hellman transform, and a responder MUST NOT accept such a
proposal. This means that a successful exchange rekeying the IKE SA
always includes the KEi/KEr payloads.
- Removed: It also helps to avoid IP fragmentation of IKEv2 messages
I don't think this is actually true, since on rekey there are no required
CERT payloads, which is the vast majority of the payload size in IKE_AUTH
that causes fragmentation.
- Changed MINIMUM_REKEY{_SUPPORTED} to OPTIMIZED_REKEY{_SUPPORTED}
This matches better with the OPTIMIZED_REKEY notify. Also, I find that
"minimum" is a little confusing. It could mean "minimum lifetime" or
"minimum of the previous one". I find "optimized" covers this better
than "minium".
- Shortened titles
For improved readability of Table of Contents
- Some grammar and style
Open questions to the working group:
1) Should the SUPPORTED notify mean that peers MAY use this method or MUST
use this method? There could be a use for making it MUST, as a peer
could then eventually stop supporting the "old method". Initiators
would know by the lack of the notify that they might not be able to
rekey in the old way, and must add/delete or re-auth the SA.
2) Alternatively, the SUPPORTED notify could have a payload that signifies
whether the old method is supported or not.
3) Should we look at supporting rekeying multiple Child SAs at once? Or
should we tell people they should have used additional Traffic
Selectors and combined the Child SAs into one ?
4) When a Child SA was negotiated with PFS, what should an optimized rekey
do when there is no KE payload? Send INVALID_KE_PAYLOAD ?
Paul
>
> Regards & Thanks!
> Wei Pan
>
>> -----Original Message-----
>> From: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] On Behalf
>> Of internet-dra...@ietf.org
>> Sent: Monday, July 5, 2021 12:24 PM
>> To: i-d-annou...@ietf.org
>> Subject: I-D Action:
draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.txt
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>
>> Title : IKEv2 Optional SA&TS Payloads in Child
>> Exchange
>> Authors : Sandeep Kampati
>> Wei Pan
>> Meduri S S Bharath
>> Meiling Chen
>> Filename :
>> draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.txt
>> Pages : 9
>> Date : 2021-07-04
>>
>> Abstract:
>> This document describes a method for reducing the size of the
>> Internet Key Exchange version 2 (IKEv2) exchanges at time of rekeying
>> IKE SAs and Child SAs by removing or making optional of SA & TS
>> payloads. Reducing size of IKEv2 exchanges is desirable for low
>> power consumption battery powered devices. It also helps to avoid IP
>> fragmentation of IKEv2 messages.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-kampati-ipsecme-ikev2-sa-ts-payloa
>> ds-opt/
>>
>> There is also an htmlized version available at:
>> https://datatracker.ietf.org/doc/html/draft-kampati-ipsecme-ikev2-sa-ts-p
>> ayloads-opt-05
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-kampati-ipsecme-ikev2-sa-ts-paylo
>> ads-opt-05
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> i-d-annou...@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html or
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
IPSECME Working Group S. Kampati
Internet-Draft W. Pan
Intended status: Standards Track Huawei
Expires: 12 January 2022 M. Bharath
Mavenir
M. Chen
CMCC
11 July 2021
IKEv2 Optional SA&TS Payloads in Child Exchange
draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05
Abstract
This document describes a method for reducing the size of the
Internet Key Exchange version 2 (IKEv2) CREATE_CHILD_SA exchanges
used for rekeying of the IKE or Child SA by replacing the SA and TS
payloads with a Notify Message payload. Reducing size and complexity
of IKEv2 exchanges is especially useful for low power consumption
battery powered devices.
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 12 January 2022.
Copyright Notice
Copyright (c) 2021 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
Kampati, et al. Expires 12 January 2022 [Page 1]
Internet-Draft IKEv2 Optional Child SA&TS Payloads July 2021
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. Negotiation of Support for OPTIMIZED REKEY . . . . . . . . . 3
4. Optimized Rekey of the IKE SA . . . . . . . . . . . . . . . . 4
5. Optimized Rekey of Child SAs . . . . . . . . . . . . . . . . 5
6. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. OPTIMIZED_REKEY_SUPPORTED Notify . . . . . . . . . . . . 5
6.2. OPTIMIZED_REKEY Notify . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Operational Considerations . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
11. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
The Internet Key Exchange protocol version 2 (IKEv2) [RFC7296] is
used to negotiate Security Association (SA) parameters for the IKE SA
and the Child SAs. Cryptographic key material for these SAs have a
limited lifetime before it needs to be refreshes, a process referred
to as "rekeying". IKEv2 uses the CREATE_CHILD_SA exchange to rekey
either the IKE SA or the Child SAs.
When rekeying, a full set of previously negotiated parameters are
exchanged. However, most of these parameters will be the same, and
some of these parameters MUST be the same.
For example, the Traffic Selector (TS) negotiated for the new Child
SA MUST cover the Traffic Selectors negotiated for the old Child SA.
And in practically all cases, a new Child SA would not need to cover
more Traffic Selectors. In the rare case where this would be needed,
a new Child SA could be negotiatied instead of the current Child SA
being rekeyed. Similarly, IKEv2 states that the cryptographic
parameters negotiated for rekeying SHOULD NOT be different. This
means that the security properties of the IKE or Child SA in practise
do not change during a typical rekey.
Kampati, et al. Expires 12 January 2022 [Page 2]
Internet-Draft IKEv2 Optional Child SA&TS Payloads July 2021
This document specifies a method to omit these parameters and replace
them with a single Notify Message declaring that all these parameters
are identical to the originally negotiated parameters.
For security gateways/ePDG in 4G networks or cRAN/Cloud gateways in
5G networks, gateways typically support more than 100,000 IKE/IPSEC
tunnels. At any point in time, there will be hundreds or thousands
of IKE SAs and Child SAs that are being rekeyed. This takes a large
amount of bandwidth and CPU power and any protocol simplification or
bandwidth reducing would result in an significant resource saving.
For Internet of Things (IoT) devices which utilize low power
consumption technology, reducing the size of rekey exchange reduces
its power consumption, as sending bytes over the air is usually the
most power consuming operation of such a device. Reducing the CPU
operations required to verify the rekey exchanges parameters will
also save power and extend the lifetime for these devices.
When using identical parameters during the IKE or Child SA rekey, the
SA and TS payloads can be omited. For an IKE SA rekey, instead of
the (large) SA payload, only a Key Exchange (KE) payload and a new
Notify Type payload with the new SPI is required. For a Child SA
payload, instead of the SA or TS payloads, only an optional Nonce
payload (when using PFS) and a new Notify Type payload with the new
SPI is needed. This makes the rekey exchange packets much smaller
and the peers do not need to verify that the SA or TS parameters are
compatible with the old SA.
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. Negotiation of Support for OPTIMIZED REKEY
To indicate support for the optimized rekey negotiation, the
initiator includes the OPTIMIZED_REKEY_SUPPORTED Notify payload in
the IKE_AUTH exchange request. A responder that supports the
optimized rekey exchange inclues the OPTIMIZED_REKEY_SUPPORTED Notify
payload in its response. Note that the notify indiciates support for
optimized rekey for both IKE and Child SAs.
Kampati, et al. Expires 12 January 2022 [Page 3]
Internet-Draft IKEv2 Optional Child SA&TS Payloads July 2021
When a peer wishes to rekey an IKE SA or Child SA, it MAY use the
optimized rekey method during the CREATE_CHILD_SA exchange. A
responder MUST accept that the initiator uses a regular or optimized
reey.
The initiator indicates its support for optimizing payloads at
rekeying IKE SAs and Child SAs by including a Notify payload of type
MINIMAL_REKEY_SUPPORTED in the IKE_AUTH request message. By
observing the MINIMAL_REKEY_SUPPORTED notification in the received
message, the responder can deduce the initiator's support of this
extension. If the responder also supports this extension, it
includes the MINIMAL_REKEY_SUPPORTED notification in the
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:
Initiator Responder
--------------------------------------------------------------------
HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2, TSi, TSr,
N(OPTIMIZED_REKEY_SUPPORTED)} -->
<-- HDR, SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr,
N(OPTIMIZED_REKEY_SUPPORTED)}
If the responder does not support this extension, as per regular
IKEv2 processing, it MUST ignore the unknown Notify payload. The
initiator will notice the lack of the OPTIMIZED_REKEY_SUPPORTED
Notify in the reply and thus know it cannot use the optimized rekey
method.
The IKE_AUTH message exchange in this case is shown below:
4. Optimized Rekey of the IKE SA
The initiator of an optimized rekey request sends a CREATE_CHILD_SA
payload with the OPTIMIZED_REKEY notify payload containing the new
Security Parameter Index (SPI) for the new IKE SA. It omits the SA
payload.
The responder of an optimized rekey request performs the same
process. It includes the OPTIMIZED_REKEY notify with its new IKE SPI
and omits the SA payload.
Both parties send Nonce and KE payloads just as they would do for a
regular IKE SA rekey.
Kampati, et al. Expires 12 January 2022 [Page 4]
Internet-Draft IKEv2 Optional Child SA&TS Payloads July 2021
The CREATE_CHILD_SA message exchange in this case is shown below:
Initiator Responder
--------------------------------------------------------------------
HDR, SK {N(OPTIMIZED_REKEY),
Ni, KEi} -->
<-- HDR, SK {N(OPTIMIZED_REKEY),
Nr, KEr}
5. Optimized Rekey of Child SAs
The initiator of an optimized rekey request sends a CREATE_CHILD_SA
payload with the OPTIMIZED_REKEY notify payload containing the new
Security Parameter Index (SPI) for the new Child SA. It omits the SA
payload. If the current Child SA was negotiated with Perfect Forward
Secrecy (PFS), a KEi payload MUST be included as well. If no PFS was
negotiated for the current Child SA, a KEi payload MUST NOT be
included.
The responder of an optimized rekey request performs the same
process. It includes the OPTIMIZED_REKEY notify with its new IKE SPI
and omits the SA and TS payloads. Depending on the PFS negotiation
of the current Child SA, the responder includes a KEr payload.
Both parties send Nonce payloads just as they would do for a regular
Child SA rekey.
Using the received old SPI from the REKEY_SA payload and the new SPI
received from the OPTIMIZED_REKEY payload, both parties can perform
the Child SA rekey operation.
The CREATE_CHILD_SA message exchange in this case is shown below:
Initiator Responder
--------------------------------------------------------------------
HDR, SK {N(REKEY_SA), N(OPTIMIZED_REKEY),
Ni, [KEi,]} -->
<-- HDR, SK {N(OPTIMIZED_REKEY),
Nr, [KEr,]}
6. Payload Formats
6.1. OPTIMIZED_REKEY_SUPPORTED Notify
The OPTIMIZED_REKEY_SUPPORTED Notify Message type notification is
used by the initiator and responder to indicate their support for the
optimized rekey negotation.
Kampati, et al. Expires 12 January 2022 [Page 5]
Internet-Draft IKEv2 Optional Child SA&TS Payloads July 2021
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* 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 the value [TBD1].
This Notify Message type contains no data.
6.2. OPTIMIZED_REKEY Notify
The OPTIMIZED_REKEY Notify Message type is used to perform an
optimized IKE SA or Child SA rekey.
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) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Protocol ID (1 octet) - MUST be 1.
* SPI Size (1 octet) - MUST be 8 when rekeying an IKE SAs. MUST be
4 when rekeying a Child SA.
* Notify Message Type (2 octets) - MUST be set to the value [TBD2].
* SPI (4 octets or 8 octets) - Security Parameter Index. The peer's
new SPI.
7. IANA Considerations
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.
Kampati, et al. Expires 12 January 2022 [Page 6]
Internet-Draft IKEv2 Optional Child SA&TS Payloads July 2021
NOTIFY messages: status types Value
----------------------------------------------------------
OPTIMIZED_REKEY_SUPPORTED TBD1
OPTIMIZED_REKEY TBD2
8. Operational Considerations
Some implementations allow sending rekey messages with a different
set of Traffic Selectors or cryptographic parameters in response to a
configuration update. IKEv2 states this SHOULD NOT be done. Whether
or not optimized rekeying is used, a configuration change that
changes the Traffic Selectors or cryptographic parameters MUST NOT
use the optimized rekey method. It SHOULD also not use a regular
rekey method but instead start an entire new IKE and Child SA
negotiation with the new parameters.
9. Security Considerations
The optimized rekey removes sending unneccessary new parameters that
originally would have to be validated against the original
parameters. In that sense, this optimalization enhances the security
of the rekey process.
10. Acknowledgments
Special thanks go to Paul Wouters, Valery Smyslov, and Antony Antony.
11. 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, "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] 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>.
Authors' Addresses
Sandeep Kampati
Huawei Technologies
Divyashree Techno Park, Whitefield
Kampati, et al. Expires 12 January 2022 [Page 7]
Internet-Draft IKEv2 Optional Child SA&TS Payloads July 2021
Bangalore 560066
Karnataka
India
Email: sandeepkamp...@huawei.com
Wei Pan
Huawei Technologies
101 Software Avenue, Yuhuatai District
Nanjing
Jiangsu,
China
Email: william.pan...@huawei.com
Meduri S S Bharath
Mavenir Systems Pvt Ltd
Manyata Tech Park
Bangalore
Karnataka
India
Email: bharath.med...@mavenir.com
Meiling Chen
China Mobile
32 Xuanwumen West Street, West District
Beijing
Beijing, 100053
China
Email: chenmeil...@chinamobile.com
Kampati, et al. Expires 12 January 2022 [Page 8]
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.24 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc ipr="trust200902" consensus="true" docName="draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05" category="std">
<front>
<title abbrev="IKEv2 Optional Child SA&TS Payloads">IKEv2 Optional SA&TS Payloads in Child Exchange</title>
<author initials="S." surname="Kampati" fullname="Sandeep Kampati">
<organization abbrev="Huawei">Huawei Technologies</organization>
<address>
<postal>
<street>Divyashree Techno Park, Whitefield</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560066</code>
<country>India</country>
</postal>
<email>sandeepkamp...@huawei.com</email>
</address>
</author>
<author initials="W." surname="Pan" fullname="Wei Pan">
<organization abbrev="Huawei">Huawei Technologies</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhuatai District</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code></code>
<country>China</country>
</postal>
<email>william.pan...@huawei.com</email>
</address>
</author>
<author initials="M." surname="Bharath" fullname="Meduri S S Bharath">
<organization abbrev="Mavenir">Mavenir Systems Pvt Ltd</organization>
<address>
<postal>
<street>Manyata Tech Park</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code></code>
<country>India</country>
</postal>
<email>bharath.med...@mavenir.com</email>
</address>
</author>
<author initials="M." surname="Chen" fullname="Meiling Chen">
<organization abbrev="CMCC">China Mobile</organization>
<address>
<postal>
<street>32 Xuanwumen West Street, West District</street>
<city>Beijing</city>
<region>Beijing</region>
<code>100053</code>
<country>China</country>
</postal>
<email>chenmeil...@chinamobile.com</email>
</address>
</author>
<date year="2021"/>
<area>Security</area>
<workgroup>IPSECME Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document describes a method for reducing the size of the
Internet Key Exchange version 2 (IKEv2) CREATE_CHILD_SA exchanges
used for rekeying of the IKE or Child SA by replacing the SA and TS
payloads with a Notify Message payload. Reducing size and complexity
of IKEv2 exchanges is especially useful for low power consumption
battery powered devices.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>The Internet Key Exchange protocol version 2 (IKEv2) <xref target="RFC7296"></xref>
is used to negotiate Security Association (SA) parameters for the IKE
SA and the Child SAs. Cryptographic key material for these SAs have a
limited lifetime before it needs to be refreshes, a process referred to
as "rekeying". IKEv2 uses the CREATE_CHILD_SA exchange to rekey either
the IKE SA or the Child SAs.</t>
<t>When rekeying, a full set of previously negotiated parameters
are exchanged. However, most of these parameters will be the same,
and some of these parameters MUST be the same.</t>
<t>For example, the Traffic Selector (TS) negotiated for the new Child
SA MUST cover the Traffic Selectors negotiated for the old Child SA. And
in practically all cases, a new Child SA would not need to cover more
Traffic Selectors. In the rare case where this would be needed, a new
Child SA could be negotiatied instead of the current Child SA being
rekeyed. Similarly, IKEv2 states that the cryptographic parameters
negotiated for rekeying SHOULD NOT be different. This means that the
security properties of the IKE or Child SA in practise do not change
during a typical rekey.</t>
<t>This document specifies a method to omit these parameters and replace
them with a single Notify Message declaring that all these parameters
are identical to the originally negotiated parameters.</t>
<t>For security gateways/ePDG in 4G networks or cRAN/Cloud gateways
in 5G networks, gateways typically support more than 100,000 IKE/IPSEC
tunnels. At any point in time, there will be hundreds or thousands of
IKE SAs and Child SAs that are being rekeyed. This takes a large amount of
bandwidth and CPU power and any protocol simplification or bandwidth
reducing would result in an significant resource saving.</t>
<t>For Internet of Things (IoT) devices which utilize low power
consumption technology, reducing the size of rekey exchange reduces its
power consumption, as sending bytes over the air is usually the most
power consuming operation of such a device. Reducing the CPU operations
required to verify the rekey exchanges parameters will also save power
and extend the lifetime for these devices.</t>
<t>When using identical parameters during the IKE or Child SA rekey,
the SA and TS payloads can be omited. For an IKE SA rekey, instead of
the (large) SA payload, only a Key Exchange (KE) payload and a new
Notify Type payload with the new SPI is required. For a Child SA
payload, instead of the SA or TS payloads, only an optional Nonce payload
(when using PFS) and a new Notify Type payload with the new SPI is needed.
This makes the rekey exchange packets much smaller and the peers do not
need to verify that the SA or TS parameters are compatible with the
old SA.</t>
</section>
<section anchor="conventions-used-in-this-document" title="Conventions Used in This Document">
<section anchor="requirements-language" title="Requirements Language">
<t>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 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all
capitals, as shown here.</t>
</section>
</section>
<section anchor="negotiation" title="Negotiation of Support for OPTIMIZED REKEY">
<t>To indicate support for the optimized rekey negotiation, the initiator
includes the OPTIMIZED_REKEY_SUPPORTED Notify payload in the IKE_AUTH
exchange request. A responder that supports the optimized rekey exchange
inclues the OPTIMIZED_REKEY_SUPPORTED Notify payload in its response. Note
that the notify indiciates support for optimized rekey for both IKE and
Child SAs.</t>
<t>When a peer wishes to rekey an IKE SA or Child SA, it MAY use the
optimized rekey method during the CREATE_CHILD_SA exchange. A responder
MUST accept that the initiator uses a regular or optimized reey.</t>
<t>The initiator indicates its support for optimizing payloads
at rekeying IKE SAs and Child SAs by including a Notify payload of
type MINIMAL_REKEY_SUPPORTED in the IKE_AUTH request message. By
observing the MINIMAL_REKEY_SUPPORTED notification in the received
message, the responder can deduce the initiatorâs support of this
extension. If the responder also supports this extension, it
includes the MINIMAL_REKEY_SUPPORTED notification in the
corresponding response message. After receiving the response
message, the initiator can also know the support of this extension of
the responder side.</t>
<t>The IKE_AUTH message exchange in this case is shown below:</t>
<figure><artwork><![CDATA[
Initiator Responder
--------------------------------------------------------------------
HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2, TSi, TSr,
N(OPTIMIZED_REKEY_SUPPORTED)} -->
<-- HDR, SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr,
N(OPTIMIZED_REKEY_SUPPORTED)}
]]></artwork></figure>
<t>If the responder does not support this extension, as per regular
IKEv2 processing, it MUST ignore the unknown Notify payload. The
initiator will notice the lack of the OPTIMIZED_REKEY_SUPPORTED Notify
in the reply and thus know it cannot use the optimized rekey method.</t>
<t>The IKE_AUTH message exchange in this case is shown below:</t>
</section>
<section anchor="payload-optimization-ike" title="Optimized Rekey of the IKE SA">
<t>The initiator of an optimized rekey request sends a CREATE_CHILD_SA
payload with the OPTIMIZED_REKEY notify payload containing the new
Security Parameter Index (SPI) for the new IKE SA. It omits the SA
payload.</t>
<t>The responder of an optimized rekey request performs the same process. It
includes the OPTIMIZED_REKEY notify with its new IKE SPI and omits the SA
payload.</t>
<t>Both parties send Nonce and KE payloads just as they would do for a regular
IKE SA rekey.</t>
<t>The CREATE_CHILD_SA message exchange in this case is shown below:</t>
<figure><artwork><![CDATA[
Initiator Responder
--------------------------------------------------------------------
HDR, SK {N(OPTIMIZED_REKEY),
Ni, KEi} -->
<-- HDR, SK {N(OPTIMIZED_REKEY),
Nr, KEr}
]]></artwork></figure>
</section>
<section anchor="payload-optimization-child" title="Optimized Rekey of Child SAs">
<t>The initiator of an optimized rekey request sends a CREATE_CHILD_SA
payload with the OPTIMIZED_REKEY notify payload containing the new
Security Parameter Index (SPI) for the new Child SA. It omits the SA
payload. If the current Child SA was negotiated with Perfect Forward
Secrecy (PFS), a KEi payload MUST be included as well. If no PFS
was negotiated for the current Child SA, a KEi payload MUST NOT be
included.</t>
<t>The responder of an optimized rekey request performs the same
process. It includes the OPTIMIZED_REKEY notify with its new IKE SPI
and omits the SA and TS payloads. Depending on the PFS negotiation of
the current Child SA, the responder includes a KEr payload.</t>
<t>Both parties send Nonce payloads just as they would do for a regular
Child SA rekey.</t>
<t>Using the received old SPI from the REKEY_SA payload and the new SPI
received from the OPTIMIZED_REKEY payload, both parties can perform the
Child SA rekey operation.</t>
<t>The CREATE_CHILD_SA message exchange in this case is shown below:</t>
<figure><artwork><![CDATA[
Initiator Responder
--------------------------------------------------------------------
HDR, SK {N(REKEY_SA), N(OPTIMIZED_REKEY),
Ni, [KEi,]} -->
<-- HDR, SK {N(OPTIMIZED_REKEY),
Nr, [KEr,]}
]]></artwork></figure>
</section>
<section anchor="payload-formats" title="Payload Formats">
<section anchor="supported-notify" title="OPTIMIZED_REKEY_SUPPORTED Notify">
<t>The OPTIMIZED_REKEY_SUPPORTED Notify Message type notification is used by the initiator and
responder to indicate their support for the optimized rekey negotation.</t>
<figure><artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<t><list style="symbols">
<t>Protocol ID (1 octet) - MUST be 0.</t>
<t>SPI Size (1 octet) - MUST be 0, meaning no SPI is present.</t>
<t>Notify Message Type (2 octets) - MUST be the value [TBD1].</t>
</list></t>
<t>This Notify Message type contains no data.</t>
</section>
<section anchor="optimized-rekey" title="OPTIMIZED_REKEY Notify">
<t>The OPTIMIZED_REKEY Notify Message type is used to perform an optimized
IKE SA or Child SA rekey.</t>
<figure><artwork><![CDATA[
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) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<t><list style="symbols">
<t>Protocol ID (1 octet) - MUST be 1.</t>
<t>SPI Size (1 octet) - MUST be 8 when rekeying an IKE SAs. MUST be 4 when rekeying a Child SA.</t>
<t>Notify Message Type (2 octets) - MUST be set to the value [TBD2].</t>
<t>SPI (4 octets or 8 octets) - Security Parameter Index. The peer's new SPI.</t>
</list></t>
</section>
</section>
<section anchor="iana-considerations" title="IANA Considerations">
<t>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.</t>
<figure><artwork><![CDATA[
NOTIFY messages: status types Value
----------------------------------------------------------
OPTIMIZED_REKEY_SUPPORTED TBD1
OPTIMIZED_REKEY TBD2
]]></artwork></figure>
</section>
<section anchor="operational-considerations" title="Operational Considerations">
<t>Some implementations allow sending rekey messages with a different
set of Traffic Selectors or cryptographic parameters in response to a
configuration update. IKEv2 states this SHOULD NOT be done. Whether or
not optimized rekeying is used, a configuration change that changes the
Traffic Selectors or cryptographic parameters MUST NOT use the optimized
rekey method. It SHOULD also not use a regular rekey method but instead
start an entire new IKE and Child SA negotiation with the new parameters.</t>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>The optimized rekey removes sending unneccessary new parameters that
originally would have to be validated against the original parameters. In
that sense, this optimalization enhances the security of the rekey
process.</t>
</section>
<section anchor="acknowledgments" title="Acknowledgments">
<t>Special thanks go to Paul Wouters, Valery Smyslov, and Antony Antony.</t>
</section>
</middle>
<back>
<references title='Normative References'>
<reference anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>
<reference anchor="RFC8174" target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author>
<date year='2017' month='May' />
<abstract><t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>
<reference anchor="RFC7296" target='https://www.rfc-editor.org/info/rfc7296'>
<front>
<title>Internet Key Exchange Protocol Version 2 (IKEv2)</title>
<author initials='C.' surname='Kaufman' fullname='C. Kaufman'><organization /></author>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'><organization /></author>
<author initials='Y.' surname='Nir' fullname='Y. Nir'><organization /></author>
<author initials='P.' surname='Eronen' fullname='P. Eronen'><organization /></author>
<author initials='T.' surname='Kivinen' fullname='T. Kivinen'><organization /></author>
<date year='2014' month='October' />
<abstract><t>This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document obsoletes RFC 5996, and includes all of the errata for it. It advances IKEv2 to be an Internet Standard.</t></abstract>
</front>
<seriesInfo name='STD' value='79'/>
<seriesInfo name='RFC' value='7296'/>
<seriesInfo name='DOI' value='10.17487/RFC7296'/>
</reference>
</references>
</back>
<!-- ##markdown-source:
H4sIAC2I4mAAA+1b7W4bSXb9T4DvUPEAO9KG5Ega2+MRNouhJXnMtSUrorzO
ZHZgFNlFsqJmN7ermhyu7UVeI6+XJ8m5t6q6m82mJHsMIwmWBiyyWR/389xT
H+x2u+2W1TZWx2Lw4mx5JF4trE4TGYth/3fXQ3Ep13EqIyN0Ik5mOo7E2a/j
mUymqt2So1GmllsdXbPN7u1WlI4TOcc0USYntnsj5wtpdVcvjBrPVVffqOVR
18iuNd2F79RNF7Z78KjdGkurpmm2PhbGRu1Wu6UX2bGwWW7s0cHB9wdHkCVT
8lgM1TjPtF23W6s0u5lmab6AeJfDs5PzM/EGj3QyFT/S43brRq3RKML3iVVZ
omz3lCSj4Y2VSfRWxmmieBroutDH7ZYQNh0fi7Uy9N6kmc3UxJQP1vPKZ8iU
21maoV8X1sPjYU+8cGpTa2eNIWZSalH9Is2mx+J5LldKi2s1niVpnE61myKY
3H1NT9Rc6hiGceN4s/4w4+9743TOgkFOZY/FqV6upZnhgx8Y/sluOuLNTFs1
0SqOqPU4jSDY148eHxw8fvw1P4FJj8VTeB02yRQ9ytQU3j6G3FkirbyRrmee
WHLTIIm0LPR+08M8SanzGyjmH3ySrisdx1rOewuZ4Isduh4eHIphOrErRIbo
L1WSq474KUdjKzUsgXZ6bEt9HzwoNb2QyX8gUqp6/klDe5NvaIlAT0otz3vi
6Uxm0s5KTc9VhHgUQ/yrfMdKn0vIpDMxXBur5kZcLq14aaOq4r5JRfORG6Q3
53F/mLsGddXPZbKGlmxQ9nCzlp/sT2h6MlNJVU0dU2aFp6wgW0ecpyMdq6pW
J+cnJxWVxugzd/1/GFOXOfeo6/Ttkfi3HP7O5ypBABkrhvxNx31o8OfhwcHB
o2+r+ipd92rl0UnNq+1WkmZz5NJSceZfPTs5Ojz8Prx/cvjdw/D+u6PvHx8z
LCWTSh/3r9vtQnVIJ8eMLdczbQTAkBSxIlJmnOmRMkKKuQJcRAJDQL4oH5NF
7UwJo/+mRDqh9+1WACvxQq0LKBZLlRkoJI7EHoPxvlD+KwxshdVzHiFTAD3W
F62A0PgyiQq8NmK0RpN5uqSZIcVcMl6mAdgxwrAvfieuh8BDj9E9cRVkDXK6
clAKQPoqozM5ihVrF6crDJCuVAZfJSaf8wRiJC10Wwv+RkXotNRjhRkGVsjY
pGKm4oUBBAu5THUEXG+3JpmckiElj1BMPlfGSMzdCx6Y6yiiMGy3viK8z1LI
TF2cR5RoNusiSwH4adxgX7NQYw3IjJAS7dbPPgp+IWVzw0/Zd4PLoiah6yXe
7wuZjQlvxzbPnD3YsYs8W6QG5iIrhy59Y9KxdsrtDfv7YoH8R5xAHJGgJFr/
Hdzoyg1MoalaRgKeLnzQE6RjoU1O07w+vRTSsJCIzcQsUM1gT4ijrSkM2BGr
mQaKsG+XMgM0i0mWzkWMBugsYfREiVmeROSy0doSdsNFRsFmiJkbHaf8lF3R
H49RcjmwU1EYrePCXI0zOAByexMiGmHsb9hqHJ5mluZUokbKNUiTeM0GlCLW
c01aAz2QxpwtFPMU3piJNIe9y3YwVtEwAtz1UAKV81isJyrkC7RDwKtfFzoj
x2TkXTlKc2RU2m655074hSKXjNGBc4yfoSvmBkiBToxibWaYP1Er/xwYC69z
31iOQ4KLNCa9FFvrGWY0IRSm8OpKrs036vL0Rwqvhz9iNEs8x6Xx+Kp/8c1J
nOYcfI9+BID5r1nENZdNYfIFeVrMgfvOf8DJDqAy2PrsRNg8SVSMxBtCS44u
ZBy8OYWyZG5y7ZokS8m8MyQroGItRkUcsK0AZjmxEoroXYADAeAV9A/IRJEK
I5NxDEZDDhaOgt/ReaUjO+sgD8Y3CJbN9KexWS/4G8BhKM7guDTPGEZgTja4
UQFa2DCG2wOb5s6BUMOk8dIFoPZY4bEY1DCNc54sILdP9Qqo9wqYp3Ah4EK0
TvKYGhY4A3ejCSgFYCG93g8SuXRrtzBHrP9Gs8aMk9toaQNbWjdrtlFCYpVM
7czj4zfB/oXVi3Qnqp2ASy4VdysMXp25J/rWJSyQiNOsA8hg05GyMFHojhK+
gCIY3ztEcYlh6PD1g52vk3GcRypiw52nxhbWiNLkv//zvyz6qwn0R9p4ZB5n
64VNp5lcwF4IaiQ1AZP6aw4HxGuM9HRNUeQMQH6IlhJxMlUhNSlYsEAJdSy4
fi4jVVQ8wIRTtV5ARWM4o1LBeDnDpc05JjuUQEApn/mXA4BonCuKjEQp6Mw6
Ye1inWDUyo29MTT0GaZ+kAug/mRdGNDhM/wDWpsYPwiPXM7mdINniHKglVXo
6AFn2xTsBmgylqZR6U7oV7cdmW2OQoGUmHA8Zk7RwmsYrMlxbLf6bO1WYdfO
HT6rzisq0yKab52Xx+ufvCTrTfQ0z9hlPccSTtJkSdUUgS9e+4rOSX3q05yb
fQX689ccZYCeGPES0+VyqgKtoFJAi0wjHpy/Hl4/6Li/4uIVv786+9fXg6uz
U3o/fN5/+bJ441q0W/j06vVL34DelV1PXp2fn12cut54KmqPzvs/4Q+p+ODV
5fXg1UX/5YMtrOL8QwiOKAsBTUg0LqNmE9+enoBrHT4U7979k+fBHz74D0SE
8WGF+ulm43h3H7nsyMVCyYxGkXFMALPQFkDRoUlQ0VeJII95q18GjnKqEM+x
KaAU1YZhD0iy1JCtZDORa+lq4EYaBC5ObDWzLq6fqglViNwUyEA55SPIpawn
bsQ69HwRq7LArGYEb66CGgK9mWQ+epOkK1fLAhdwuF9pCoahqSJaX0Z8GSba
m1oCjMiXo0o0b8Gz4AQGhIIhQCmaxxfePMlQjqcJdAgsm8eibGCBUFiJBymK
aaf3BFbLafHHfG5GbkowmRNiojPAMIBiQakEFQPbdDBViD/hsQByFQNCHrtS
nk6BgThyxBwUlueAw0NPoMeVhCdAJRjAErMRaIuHFcTtT6zyDLpCiJ0SOtH0
GbYgoAh25a/qpi0whRZxziUsCUOTsyLncQemHweoLvk37BBMMqFa7Ofi0hfA
CtFxe/kgS1PJjJGCSH0WorlhMQ4Z00/s+EowOcdTz4EQKNACTE1lnp9iIYrK
7gi0N8ZY6WVDwPU8xl1sqjosVeVdP6/pZUXTq9s1ffdVxXofAlqW/tJJxMsY
w4uRimlFg2W5St9hWqZyxDLYavUaSuTSrhdKnA8uBuf9l2+vzl6c/fR2+Pry
8tXV9dlpsZp7cfa2//r6uWCigQQJdhJP13D6yKhsGSjXrqESmpqUI2PqTQe0
W37Ajn9cdVxEhE5tBjbIkdlORvWrVYlhqjaY1EbaxCUGgqI58TiKf2Zj5mO1
ALSnmZ/IM2+8RVEvjORy1SkbzBRa1VTfTF0W2oPsFviU8js/bqhLedArFvnB
fSHpw/q4KItMQnSoSyMF8s0bOX/HizhREGrX6ypMzLsOv/nVbj0/veqI4Qvx
bnCqO+Lnk7Or684v7i/IQ+cX2oES4ufBaYbHpBta9/VRBzRJ039Zx7W42Nvh
yf0Potv9o2u0+/WHbldURMlKUXjOu7qH17CfbYt29+sW4YNr4Jx6pEepMm71
EAJmO9oFszE9TdxqGFF4r4APZXgzUglxaLx2i9iYF0SoLEt55bLR2NEBosY7
JqTtxyag2MyppmQpcELaejbcZRKudkUidALmucrcXIKMZw5hLyk3uYzFStJ2
Q4XvVPkBccuJTnavnP+Rqf/LMrWSZmADvs6H0u/3XrZrfnBmUWVr7bdKdlga
ibDBlye0V+CpkNtim9HmQqAHvPuks1sqApKUqb7LhCpl87vtG8ucd++qtOSD
27LcsQOATHNyd3ixU0vEiPZo5why07wQTpjYNC5KIS6nLzr4nYCVpI0Z3iSI
aGctlsZbT0UligGU2B7CxQ2t+c4H/16DrmLjvmEbYFE56t3gyHW2w7sDLOBt
U7ldoeqCbJO2YN0FYAnbm5dhY5vOmtSvYm94Odh3UUC0j7UPnKHcJHEeaqAV
m1Pt0oQxygHUbZow9MF5FRvVCRqRE3a1XwOWkbCStDEA/G9ef/gBeXWUcCSB
gdlK/BTrShdDTIXKQNINgUSrS4qkuoybUVKxiStUwSauVBEPLFTwVrrV3aI5
sKh2lDtL4pMCp90qlAiRw5tb94uO6pFDYxTyWLIwS8NMnbpFtlrXtv594m6s
7ovidnJ11r8+e3vyfPDy9C1a/R+scRd7NQfuh+qFgvHiTH98qdo54t2vi4zm
rBapzcUkhTydr94neju8OAQAl0BJvpbiVE8mWnWfqziew9V+F9cBJRQu87jv
gK2cnqJLu1VarMuTQXrMVy4CAtfEqxHAMD4rVxJADwiTNI796ijN9FTTae2l
yiZ06PUszVbSZcCQjtjGa7F3+Wy4324VeW3AgCUfR5KyKmE4YeCLpxjPzub+
SA4kj4tPdX9gc4shU6SlEXthh82fE5z7IB+cukMxbr/voEXeAb9134jbXNNu
1XyT1XxTEXbbNY4n3OWbRvHKY59bWzMKj8pDD94YrWMCreE9GBSlypOMgkps
Vmx/glKcY97PpDRU6Fvf1q+sZUa1M5r7kMBiqXBvGlguLupEsN1yTFD8FiKI
QUxZIz4jESwE/xQm2FTAbz2eQHUvCWJxkgeKKO7NEO8bGzsOisrLH3cyxV31
fhPc7sEUxTZRpAp4H6ZYOUP7slyxdlpVo2PtFnNG8emUkdPKcUbx0ZSRFhT3
DbmdRDLsL9zKJMU2kfxsAfjFCOVmENUpJV3aQH+zAepl3agitQxW83Pu6lNq
shE/H0NCC3D4f09Dh/39jriVk/4Mjtb55YvTUkybYdoqM/0kftBu1b11L35Q
Q6Bibz8Su+41VE7WihtR9yKmjUyifl5fqeulLOHk14/zjE9tjacZu7ZjLzb2
NFxA3++sorxctrV7W4EFymx3m9MzCznSMZUfGKv5cM9l9f0uigTc8AejAyvo
2MbdHfXH747Rm0qiNQbZYcOzo4Zn36L/AVofiW/FQ/FIPBbfiSfi+4951m79
c/c3/mu33osLcLLC2eL9yXsAxNnw7OrP8BQ+FxKHJi/d1SX/ev95pCiuGQxO
9/7lYP89o/+QKi19DFL4U8KwdLmmE8LPKEXAhN+Lijhi71CkY6vsvugWWHDQ
o1aljE1NOkACSQf4nPtuYbNAPLtt9d83KrN35AYy1ZH+8ocL5e4lTZX1C12+
IjDoX/T/8keX3O6xNLRy9DXzvseF5TppIzGL+gzx+UpmuF9TA8umzL8VUEPG
87LT3bWsb3jemb1b4LrjYlHYemOStVGoC2TphEupO4UhIKqi5p1YvUu8duuj
Lj7dIjRt+RJIibsw6uAfCPXZEYpHrSLUky+FUKWu/nXHdn399b5hiI98fWmo
Pbwbap+4fHMbYve4H4ouD+/RpaReXwyub8PNwg57D/2stLHwpCLBrmBwvzao
779ubIi6JpVrGtxkY2PO00LSgu5i0trFwVR5J7DyK5qJW/eu0uoV2arxir2K
B/wDjnarsQ2UstLmxn18wL8TMjZb95wc2oRdAbZ4u+Usyr84WqSaVu1h0VT0
LMERxHfw7Kdi55Z+zMhzWZ668vozeeu3LJZ2X2PYel0/Pd1eje98ceviKLiM
gG0HvXHxHtbQjZt/u64BhP0Gnxju1noDi5aVi5x+m7nxejFfDgm/RvLUe6Py
uaFo24UWL3yDWxb3qtweH4XV5uDF3nhN3FWafG3p1mvMSwysnf3UvfrBBP/Q
q0gB/nELxURm/XzhFCkrl/L046cwspOpGJsc0h/TplKsIv5VBDtiSPcsZUx7
QsmNEdOUxriUeSzepDn9kKhD8UY/6BjO1yZOl46g9BObJmv/p/gZ1UiOb+j9
/wBYIJ0GNzwAAA==
-->
</rfc>
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
