One document matched: draft-mglt-6lo-diet-esp-context-ikev2-extension-00.xml
<?xml version="1.0" encoding="windows-1252"?>
<?rfc linefile="1:/tmp/CGI11956.1"?>
<?rfc linefile="1:/tmp/CGI11956.1"?>
<?rfc toc="yes"?>
<!-- generate a table of contents -->
<?rfc symrefs="yes"?>
<!-- use anchors instead of numbers for references -->
<?rfc sortrefs="yes" ?>
<!-- alphabetize the references -->
<?rfc compact="yes" ?>
<!-- conserve vertical whitespace -->
<?rfc subcompact="no" ?>
<?rfc tocdepth="6"?>
<!-- but keep a blank line between list items -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC7296 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7296.xml">
<!ENTITY I-D.mglt-ipsecme-diet-esp PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.mglt-ipsecme-diet-esp.xml">
<!ENTITY I-D.mglt-ipsecme-diet-esp-payload-compression PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.mglt-ipsecme-diet-esp-payload-compression.xml">
]>
<rfc category="std" docName="draft-mglt-6lo-diet-esp-context-ikev2-extension-00.txt" ipr="trust200902">
<front>
<title abbrev="Diet-ESP">Diet-ESP Context IKEv2 Extension</title>
<author fullname="Daniel Migault" initials="D." surname="Migault" role="editor">
<organization>Orange</organization>
<address>
<postal>
<street>38 rue du General Leclerc</street>
<city>92794 Issy-les-Moulineaux Cedex 9</city>
<country>France</country>
</postal>
<phone>+33 1 45 29 60 52</phone>
<facsimile/>
<email>mglt.ietf@gmail.com</email>
<uri/>
</address>
</author>
<date/>
<area>INTERNET</area>
<workgroup>IPSECME</workgroup>
<abstract>
<t>Diet-ESP has been designed for IoT to limit the IPsec ESP overhead in each IPsec packet. Diet-ESP is based on the standard IPsec ESP, and needs that peers agree on a Diet-ESP Context that defines how standard ESP packets can be compressed before being sent over the wire.</t>
<t>Standard IPsec ESP can be agreed between peers using IKEv2. However, current IKEv2 does not make possible to negotiate a Diet-ESP Context, and thus to negotiate a Diet-ESP communication.</t>
<t>This draft defines an extension for IKEv2 so peers can agree the Diet-ESP Context, and thus negotiate a Diet-ESP association.</t>
</abstract>
</front>
<middle>
<section title="Requirements notation">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119"/>.
</t>
</section>
<section title="Requirements notation">
<t>This section defines terms and acronyms used in this document.
<list hangIndent="6" style="hanging">
<t hangText="- Diet-ESP Context: ">Defines the necessary parameters that are needed in order to set a Diet-ESP session. A Diet-ESP Context is a set of parameters with no particular format.</t>
<t hangText="- Diet-ESP Proposal Payload: ">Defines the payload that carries the necessary information to derive the Diet-ESP Context. It can be seen as a container for Diet-ESP Context parameters. The Diet-ESP Proposal Payload is associated to a Diet-ESP Context, and Diet-ESP Context may evolve over time. As a result, the Diet-ESP Proposal needs to identify the Diet-ESP Context (using a Diet-ESP Context ID). When one peers wants to propose a set of various values, there may be some more optimal ways to presents these proposals. The Diet-ESP Proposal also identifies the Diet-ESP Context Payload with the Diet-ESP Context Payload Format. The Diet-ESP Context Payload Format defines the Diet-ESP Context Payload. </t>
<t hangText="- Diet-ESP Context Payload: ">Is associated to a Diet-ESP Context ID and Diet-ESP Context Payload Format. It defines how the remaining bits must be interpreted to derive the parameters associated to a Diet-ESP Context.</t>
</list>
</t>
</section>
<section title="Introduction">
<t>Diet-ESP <xref target="I-D.mglt-ipsecme-diet-esp"/> <xref target="I-D.mglt-ipsecme-diet-esp-payload-compression"/> has been designed to reduce the ESP overhead on IP packet sent over the wire.</t>
<t>The principle of Diet-ESP is to use ESP and compress each field. Compression depends on the context and the environment and is defined by the Diet-ESP Context.</t>
<t>IKEv2 <xref target="RFC7296"/> enables negotiation of ESP Security Associations, but does not enable the negotiation of the Diet-ESP Context. Thus preventing establishment of Diet-ESP SA. This document describes an extension of IKEv2 that make possible two peers to agree on a Diet-ESP Context and thus make possible the establishment of a Diet-ESP SA.</t>
</section>
<section title="Protocol Overview">
<t>When an initiator wants to negotiate an Security Association (SA) using Diet-ESP, it negotiates a regular SA with a SA Payload, and indicates its willingness to establish a Diet-ESP session. In order to set the Diet-ESP session, a Diet-ESP Context MUST be agreed between the two peers. As a result, the initiator and the responder MUST negotiate and agree on a Diet-ESP Context.</t>
<t>To indicate its preference for a Diet-ESP instead of standard ESP, the initiator adds a DIET_ESP_CONTEXT_PROPOSAL Notify Payload. This Notify Payload carries a Diet-ESP Proposal Payload which can be seen as a container proposing Diet-ESP Contexts Payload. The Diet-ESP Proposal Payload indicates the Diet-ESP Context ID, a Diet-ESP Context Payload Format. These parameters make possible to derive properly the Diet-ESP Context parameters from the Diet-ESP Context Payload.</t>
<t>A Diet-ESP Context Payload is defined for each Diet-ESP Context ID and Diet-ESP Context Payload Format. The Diet-ESP Context ID indicates the Diet-ESP Context it refers to. For example, a Diet-ESP Context ID set to 0 indicates the initiator and responder refers to the Diet-ESP Context defined in this document. The Diet-ESP Context Payload Format corresponds to a convenient ways to present the proposals.</t>
<t>When the responder receives a DIET_ESP_CONTEXT_PROPOSAL Notify Payload. If the responder also wants to establish a Diet-ESP session, it responds with a DIET_ESP_CONTEXT_PROPOSAL Notify Payload with the chosen Diet-ESP Context. The chosen Diet-ESP Context is sent back using a specific Diet-ESP Proposal Payload. From this point, both peers have agreed with a standard ESP SA and a Diet-ESP Context. IP packets related to this specific SA are sent on the wired using the compressed format defined by the Diet-ESP Context.</t>
<t>If the responder does not accept the values proposed by the initiator for the Diet-ESP Context, the DIET_ESP_CONTEXT_PROPOSAL Notify Payload is ignored and no response is sent back. </t>
<t>If the responder does not agree with the proposals it MUST respond with a UNACCEPTABLE_DIET_ESP_CONTEXT.</t>
<t>If the initiator does not understand the Diet-ESP Proposal Payload received by the responder, the SA MUST be deleted.</t>
</section>
<section title="Diet-ESP Context">
<t>The Diet-ESP Context is a set of values defined <xref target="I-D.mglt-ipsecme-diet-esp"/> and <xref target="I-D.mglt-ipsecme-diet-esp-payload-compression"/>. The Diet-ESP Context is a structure that defines fields and accepted values. A instance or a set of instance of Diet-ESP Context is exchanged on the wire using specific Diet-ESP Context Payload. The different types of Diet-ESP Context Payload are defined in <xref target="tab-diet-esp-context"/>.</t>
<t> <xref target="tab-diet-esp-context"/> presents the various fields and associated values of the Diet-ESP Context defined in this document.</t>
<texttable anchor="tab-diet-esp-context" title="Diet-ESP Context Definition">
<ttcol align="left">Fields Definition</ttcol><ttcol align="left">Values</ttcol>
<c> ALIGN </c><c> 0 for 8 bit alignment </c>
<c> </c><c> 1 for 16 bit alignment</c>
<c> </c><c> 2 for 32 bit alignment</c>
<c> </c><c> 3 for 64 bit alignment</c>
<c> SPI_SIZE </c><c> 0 for 0 byte of SPI</c>
<c> </c><c> 1 for 1 byte of SPI</c>
<c> </c><c> 2 for 2 bytes of SPI</c>
<c> </c><c> 3 for 4 bytes of SPI</c>
<c> SN_SIZE </c><c> 0 for 0 byte of SN</c>
<c> </c><c> 1 for 1 byte of SN </c>
<c> </c><c> 2 for 2 bytes of SN</c>
<c> </c><c> 3 for 4 bytes of SN</c>
<c> NH </c><c> 0 indicates Next Header is removed</c>
<c> </c><c> 1 indicates Next Header is present</c>
<c> PAD </c><c> 0 indicates Pad Length is removed</c>
<c> </c><c> 1 indicates Pad Length is present</c>
<c> Diet-ESP_ICV_SIZE </c><c> 0 for 0 byte of ICV</c>
<c> </c><c> 1 for 1 byte of ICV</c>
<c> </c><c> 2 for 2 bytes of ICV</c>
<c> </c><c> 3 for 4 bytes of ICV</c>
<c> COMPRESS_ESP_PAYLOAD</c><c> 0 indicates TS are not considered</c>
<c> </c><c> 1 indicates TS are considered</c>
<c> CHECKSUM_LSB </c><c> 0 for 0 byte of Checksum</c>
<c> </c><c> 1 for 1 byte of Checksum</c>
<c> </c><c> 2 for 2 bytes of Checksum</c>
<c> SEQUENCE_NUMBER_LSB </c><c> 0 for 0 byte of TCP Sequence Number</c>
<c> </c><c> 1 for 1 byte of TCP Sequence Number</c>
<c> </c><c> 2 for 2 bytes of TCP Sequence Number</c>
<c> </c><c> 3 for 4 bytes of TCP Sequence Number</c>
</texttable>
</section>
<section title="Protocol details">
<section title="Diet-ESP Context Negotiation">
<t>Negotiation of Diet-ESP Compression is separate from the negotiation of cryptographic parameters associated with a Child SA. A initiator requesting a Child SA MAY advertise its support for one or more Diet-ESP Context through one Notify payloads of type DIET_ESP_CONTEXT_PROPOSALS. This Notify message may be included only in a message containing an SA payload negotiating a Child SA and indicates a willingness by its sender to use Diet-ESP on this SA. The responder MAY indicate acceptance of a single Diet-ESP Context with a Notify payload of type DIET_ESP_CONTEXT_PROPOSALS. These payloads MUST NOT occur in messages that do not contain SA payloads.</t>
<t>Diet-ESP has been designed to compress ESP only. As a result, when a SA Payload embeds multiple proposals, the negotiated Diet-ESP Context concerns all proposals with an Protocol ID set to ESP, and MUST be ignored for any other Protocol IDs.</t>
<t>If the responder accepts at least one proposal, the responder responds with a DIET_ESP_CONTEXT_PROPOSALS Notify Payload. This notification carries a Diet-ESP Proposal Payload of Diet-ESP Context Payload Format SINGLE_CONTEXT. The format provides a single Diet-ESP Context with each parameter uniquely specified.</t>
<t>If the responder does not support the Diet-ESP extension, it ignores the DIET_ESP_CONTEXT_PROPOSALS Notify Payload. By default, in case, no Diet-ESP Context have been agreed, the SA negotiated is ESP. </t>
<t>If the responder understand all proposals but accepts none of the proposed Diet-ESP Context, it MUST indicate the initiator that these values are not acceptable with a UNACCEPTABLE_DIET_ESP_CONTEXT Notify Payload. By default, the SA is then agreed using standard ESP, so if the responder does not want this SA, it MUST Delete the SA.</t>
<t>If the initiator does not understand the responded Diet-ESP Context by the responder, the initiator MUST delete its SA, re-initiates the IKEv2 negotiation using standard ESP.</t>
<t><xref target="diet-esp-nego"/> illustrates the case where the initiator and the responder agree on a Diet-ESP Context. The negotiation occurs during the IKE_AUTH exchange. However, the negotiation can occurs for any Child SA negotiation.</t>
<figure anchor="diet-esp-nego">
<artwork><![CDATA[
Initiator Responder
-------------------------------------------------------------------
HDR, SK { IDi, CERT, AUTH,
CP(CFG_REQUEST),
SAi2, TSi, TSr,
N(DIET_ESP_PROPOSALS) }
<-- HDR, SK { IDr, CERT, AUTH,
CP(CFG_REPLY), SAr2, TSi, TSr,
N(DIET_ESP_PROPOSALS) }
]]></artwork>
</figure>
</section>
<section title="Error Handling">
<t>To indicate that a responder supports the Diet-ESP extension but does not agree with the proposed Diet-ESP Context, the responder sends a UNACCEPTABLE_DIET_ESP_CONTEXT Notify Payload.</t>
</section>
</section>
<section title="Payload Description">
<t><xref target="Figure6"/> illustrates the Notify Payload packet format as described in section 3. 10 of <xref target="RFC7296"/>. This format is used for the DIET_ESP_CONTEXT_PROPOSALS notification.</t>
<figure title="Notify Payload" anchor="Figure6">
<artwork>
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 | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>The fields Next Payload, Critical Bit, RESERVED and Payload Length are defined in <xref target="RFC7296"/>. Specific fields defined in this document are:
<list style="hanging" hangIndent="6">
<!-- Do we need to respecify the fields that are already specified in RFC5996?
<t hangText="- Next Payload (1 octet):">Indicates the type of payload that follows this payload.</t>
<t hangText="- Critical Bit (1 bit):"> Indicates how the responder handles the Notify Payload. As notify payload is mandatory to support in IKEv2, the Critical Bit is not set.
</t>
<t hangText="- RESERVED (7 bits):"> MUST be set to zero; MUST be ignored on receipt.</t>
<t hangText="- Payload Length (2 octets):"> Length in octets of the current payload, including the generic payload header.</t> -->
<t hangText="- Protocol ID (1 octet):"> set to zero.</t>
<t hangText="- SPI Size (1 octet):"> set to zero.</t>
<t hangText="- Notify Message Type (2 octets):"> Specifies the type of notification message. It is set to <TBA by IANA> for the DIET_ESP_CONTEXT_PROPOSALS and UNACCEPTABLE_DIET_ESP_CONTEXT notification.</t>
</list>
</t>
<section title="DIET_ESP_CONTEXT_PROPOSALS Notify Payload">
<t>The DIET_ESP_CONTEXT_PROPOSALS Notify Payload is used to:
<list style="hanging" hangIndent="6">
<t hangText="- By the initiator:"> To announce its support of Diet-ESP as a well as the accepted Diet-ESP Contexts.</t>
<t hangText="- By the responder:"> To announce its support of Diet-ESP as well as the agreed Diet-ESP Context</t>
</list>
</t>
<t>To announce the accepted values for each fields of the Diet-ESP Contexts, the initiator sends a DIET_ESP_CONTEXT_PROPOSALS Notify Payload with one or multiple Diet-ESP Proposal Payload.</t>
<section anchor="sec-diet-esp-proposal-payload" title="Diet-ESP Proposal Payload">
<t>The Diet-ESP Payload can be seen as a container for a Diet-ESP Context. The format for signaling Diet-ESP Attributes takes a similar format to the Transform Attributes described in Section 3.3.5 of <xref target="RFC7296"/> and is represented in <xref target="fig-diet-esp-payload"/></t>
<t>Note that the Diet-ESP Context is provided with all parameters, and the current specification does not make possible to provide each parameter individually. Providing the whole Diet-ESP Context reduces the number of byte of the Attribute Payload over providing each parameter individually.</t>
<figure anchor="fig-diet-esp-payload" title="Diet-ESP Payload">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| Diet-ESP Attribute | AF=0 Attribute Length |
|F| Context ID |Context Format | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diet-ESP Context Payload |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="hanging" hangIndent="6">
<t hangText="- AF=0 (1 bit) :">Specified the attribute format is of Type/Length/Value.</t>
<t hangText="- Diet-ESP Context ID (7 bits) :">The ID of the Diet-ESP Context.
<list style="hanging" hangIndent="6">
<t hangText="- 0:">The Diet-ESP Context defined in this document.</t>
<t hangText="- 1 - 127:">Unassigned</t>
</list></t>
<t hangText="- Diet-ESP Context Format (4 bits) :">indicates the Diet-ESP Context Payload Format. The following values are considered:
<list style="hanging" hangIndent="6">
<t hangText="- 0 FULL_SUPPORT:">The initiator indicates it has no restrictions on the fields values of the Diet-ESP Context and supports all defined values.</t>
<t hangText="- 1 SINGLE_CONTEXT:">Defines a single Diet-ESP Context. It can be used by the initiator if only a single value is accepted for each field of the Diet-ESP Context. It is used by the responder to indicate the agreed Diet-ESP Context.</t>
<t hangText="- 2 MINIMAL_CONTEXT:">The initiator indicates for each field of the Diet-ESP Context the minimal accepted values.</t>
<t hangText="- 3 MAXIMAL_CONTEXT:">The initiator indicates for each field of the Diet-ESP Context the maximal accepted values.</t>
<t hangText="- 4 RANGE_CONTEXT:">The initiator indicates for each field of the Diet-ESP Context a range of accepted values.</t>
<t hangText="- 5 - 255:">Unassigned</t>
</list></t>
</list>
</t>
<section title="FULL_SUPPORT Diet-ESP Context Payload Format">
<t>The Diet-ESP Context Payload of format FULL_SUPPORT is an empty payload.</t>
</section>
<section title="SINGLE_CONTEXT Diet-ESP Context Payload Format">
<t>The Diet-ESP Context Payload that corresponds to the SINGLE_CONTEXT Format assigns a specific value for each field. This format may be used by the initiator to indicate a very specific proposal, or by the responder to indicate its choice of values for the agreed Diet-ESP Context. The Format of the Payload is defined by <xref target="tab-diet-esp-context-single"/>. The fields value are described in <xref target="tab-diet-esp-context"/></t>
<texttable anchor="tab-diet-esp-context-single" title="MINIMAL_CONTEXT Diet-ESP Context Format">
<ttcol align="left">Bit</ttcol><ttcol align="left">Fields Definition</ttcol>
<c>0 - 1 </c><c> ALIGN: (2 bits) </c>
<c>2 - 3 </c><c> SPI_SIZE: (2 bits) </c>
<c>4 - 5 </c><c> SN_SIZE: (2 bits) </c>
<c>6 </c><c> NH: (1 bit) </c>
<c>7 </c><c> PAD: (1 bit) </c>
<c>8 - 9 </c><c> Diet-ESP_ICV_SIZE: (2 bits) </c>
<c>10 </c><c> COMPRESS_ESP_PAYLOAD: (1 bit) </c>
<c>11 - 12 </c><c> CHECKSUM_LSB: (2 bits) </c>
<c>13 - 14 </c><c> SEQUENCE_NUMBER_LSB: (2 bits) </c>
<c>15 </c><c> Unassigned </c>
</texttable>
</section>
<section title="MINIMAL_CONTEXT Diet-ESP Context Payload Format">
<t>The Diet-ESP Context Payload of format MINIMAL_CONTEXT defines for all fields a minimal value. The Format of the Payload is defined by <xref target="tab-diet-esp-context-single"/>. The fields value are described in <xref target="tab-diet-esp-context"/></t>
</section>
<section title="MAXIMAL_CONTEXT Diet-ESP Context Payload Format">
<t>The Diet-ESP Context Payload of format MAXIMAL_CONTEXT defines for all fields a maximal value. The Format of the Payload is defined by <xref target="tab-diet-esp-context-single"/>. The fields value are described in <xref target="tab-diet-esp-context"/></t>
</section>
<section title="RANGE_CONTEXT Diet-ESP Context Payload Format">
<t>The Diet-ESP Context Payload of format RANGE_CONTEXT defines for all fields a minimum and a maximum value. The only field that is where only the minimal value is provided is the ALIGN field. The Format of the Payload is defined by <xref target="tab-diet-esp-context-range"/>. The fields value are described in <xref target="tab-diet-esp-context"/></t>
<texttable anchor="tab-diet-esp-context-range" title="RANGE_CONTEXT Diet-ESP Context Format">
<ttcol align="left">Bit</ttcol><ttcol align="left">Fields Definition</ttcol>
<c>0 - 1 </c><c> ALIGN: (Minimal accepted value) </c>
<c>2 - 3 </c><c> SPI_SIZE: (Minimal accepted value) </c>
<c>4 - 5 </c><c> SN_SIZE: (Minimal accepted value) </c>
<c>6 </c><c> NH: (Minimal accepted value) </c>
<c>7 </c><c> PAD: (Minimal accepted value) </c>
<c>8 - 9 </c><c> Diet-ESP_ICV_SIZE: (Minimal accepted value) </c>
<c>10 </c><c> COMPRESS_ESP_PAYLOAD: (Minimal accepted value) </c>
<c>11 - 12 </c><c> CHECKSUM_LSB: (Minimal accepted value) </c>
<c>13 - 14 </c><c> SEQUENCE_NUMBER_LSB: (Minimal accepted value) </c>
<c>15 - 16 </c><c> SPI_SIZE: (Maximal accepted value) </c>
<c>17 - 18 </c><c> SN_SIZE: (Maximal accepted value) </c>
<c>19 </c><c> NH: (Maximal accepted value) </c>
<c>20 </c><c> PAD: (Maximal accepted value) </c>
<c>21 - 22 </c><c> Diet-ESP_ICV_SIZE: (Maximal accepted value) </c>
<c>23 </c><c> COMPRESS_ESP_PAYLOAD: (Maximal accepted value) </c>
<c>24 - 25 </c><c> CHECKSUM_LSB: (Minimal accepted value) </c>
<c>26 - 27 </c><c> SEQUENCE_NUMBER_LSB: (Minimal accepted value) </c>
<c>28 - 31 </c><c> Unassigned </c>
</texttable>
</section>
</section>
</section>
<section title="UNACCEPTABLE_DIET_ESP_CONTEXT Notify Payload">
<t>This Notify Payload my return a Diet-ESP Proposal Payload accepted by the responder.</t>
</section>
</section>
<section title="Acknowledgment">
<t></t>
</section>
<section title="IANA Considerations">
<t>IANA is requested to allocate two values in the IKEv2 Notify Message Types - Status Types registry:</t>
<figure>
<artwork>
IKEv2 Notify Message Types - Status Types
-----------------------------------------
DIET_ESP_CONTEXT_PROPOSALS - TBA
UNACCEPTABLE_DIET_ESP_CONTEXT - TBA
Diet-ESP Attribute Types (Diet-ESP ID = 0)
-----------------------------------------
FULL_SUPPORT - 256
SINGLE_CONTEXT - 257
MINIMAL_CONTEXT - 258
MAXIMAL_CONTEXT - 259
RANGE_CONTEXT - 260
</artwork>
</figure>
</section>
<section anchor="sec-security-considerations" title="Security Considerations">
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC7296;
</references>
<references title="Informational References">
&I-D.mglt-ipsecme-diet-esp;
&I-D.mglt-ipsecme-diet-esp-payload-compression;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:17:33 |