| IPSECME | D. Migault, Ed. |
| Internet-Draft | Orange |
| Intended status: Standards Track | December 13, 2014 |
| Expires: June 16, 2015 |
Diet-ESP Context IKEv2 Extension
draft-mglt-6lo-diet-esp-context-ikev2-extension-00.txt
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.
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.
This draft defines an extension for IKEv2 so peers can agree the Diet-ESP Context, and thus negotiate a Diet-ESP association.
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 http://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 June 16, 2015.
Copyright (c) 2014 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 (http://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.
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 [RFC2119].
This section defines terms and acronyms used in this document.
Diet-ESP [I-D.mglt-ipsecme-diet-esp] [I-D.mglt-ipsecme-diet-esp-payload-compression] has been designed to reduce the ESP overhead on IP packet sent over the wire.
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.
IKEv2 [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.
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.
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.
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.
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.
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.
If the responder does not agree with the proposals it MUST respond with a UNACCEPTABLE_DIET_ESP_CONTEXT.
If the initiator does not understand the Diet-ESP Proposal Payload received by the responder, the SA MUST be deleted.
The Diet-ESP Context is a set of values defined [I-D.mglt-ipsecme-diet-esp] and [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 Table 1.
Table 1 presents the various fields and associated values of the Diet-ESP Context defined in this document.
| Fields Definition | Values |
|---|---|
| ALIGN | 0 for 8 bit alignment |
| 1 for 16 bit alignment | |
| 2 for 32 bit alignment | |
| 3 for 64 bit alignment | |
| SPI_SIZE | 0 for 0 byte of SPI |
| 1 for 1 byte of SPI | |
| 2 for 2 bytes of SPI | |
| 3 for 4 bytes of SPI | |
| SN_SIZE | 0 for 0 byte of SN |
| 1 for 1 byte of SN | |
| 2 for 2 bytes of SN | |
| 3 for 4 bytes of SN | |
| NH | 0 indicates Next Header is removed |
| 1 indicates Next Header is present | |
| PAD | 0 indicates Pad Length is removed |
| 1 indicates Pad Length is present | |
| Diet-ESP_ICV_SIZE | 0 for 0 byte of ICV |
| 1 for 1 byte of ICV | |
| 2 for 2 bytes of ICV | |
| 3 for 4 bytes of ICV | |
| COMPRESS_ESP_PAYLOAD | 0 indicates TS are not considered |
| 1 indicates TS are considered | |
| CHECKSUM_LSB | 0 for 0 byte of Checksum |
| 1 for 1 byte of Checksum | |
| 2 for 2 bytes of Checksum | |
| SEQUENCE_NUMBER_LSB | 0 for 0 byte of TCP Sequence Number |
| 1 for 1 byte of TCP Sequence Number | |
| 2 for 2 bytes of TCP Sequence Number | |
| 3 for 4 bytes of TCP Sequence Number |
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.
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.
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.
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.
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.
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.
Figure 1 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.
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) }
Figure 1
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.
Figure 2 illustrates the Notify Payload packet format as described in section 3. 10 of [RFC7296]. This format is used for the DIET_ESP_CONTEXT_PROPOSALS notification.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Notify Payload
The fields Next Payload, Critical Bit, RESERVED and Payload Length are defined in [RFC7296]. Specific fields defined in this document are:
The DIET_ESP_CONTEXT_PROPOSALS Notify Payload is used to:
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.
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 [RFC7296] and is represented in Figure 3
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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Diet-ESP Payload
The Diet-ESP Context Payload of format FULL_SUPPORT is an empty payload.
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 Table 2. The fields value are described in Table 1
| Bit | Fields Definition |
|---|---|
| 0 - 1 | ALIGN: (2 bits) |
| 2 - 3 | SPI_SIZE: (2 bits) |
| 4 - 5 | SN_SIZE: (2 bits) |
| 6 | NH: (1 bit) |
| 7 | PAD: (1 bit) |
| 8 - 9 | Diet-ESP_ICV_SIZE: (2 bits) |
| 10 | COMPRESS_ESP_PAYLOAD: (1 bit) |
| 11 - 12 | CHECKSUM_LSB: (2 bits) |
| 13 - 14 | SEQUENCE_NUMBER_LSB: (2 bits) |
| 15 | Unassigned |
The Diet-ESP Context Payload of format MINIMAL_CONTEXT defines for all fields a minimal value. The Format of the Payload is defined by Table 2. The fields value are described in Table 1
The Diet-ESP Context Payload of format MAXIMAL_CONTEXT defines for all fields a maximal value. The Format of the Payload is defined by Table 2. The fields value are described in Table 1
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 Table 3. The fields value are described in Table 1
| Bit | Fields Definition |
|---|---|
| 0 - 1 | ALIGN: (Minimal accepted value) |
| 2 - 3 | SPI_SIZE: (Minimal accepted value) |
| 4 - 5 | SN_SIZE: (Minimal accepted value) |
| 6 | NH: (Minimal accepted value) |
| 7 | PAD: (Minimal accepted value) |
| 8 - 9 | Diet-ESP_ICV_SIZE: (Minimal accepted value) |
| 10 | COMPRESS_ESP_PAYLOAD: (Minimal accepted value) |
| 11 - 12 | CHECKSUM_LSB: (Minimal accepted value) |
| 13 - 14 | SEQUENCE_NUMBER_LSB: (Minimal accepted value) |
| 15 - 16 | SPI_SIZE: (Maximal accepted value) |
| 17 - 18 | SN_SIZE: (Maximal accepted value) |
| 19 | NH: (Maximal accepted value) |
| 20 | PAD: (Maximal accepted value) |
| 21 - 22 | Diet-ESP_ICV_SIZE: (Maximal accepted value) |
| 23 | COMPRESS_ESP_PAYLOAD: (Maximal accepted value) |
| 24 - 25 | CHECKSUM_LSB: (Minimal accepted value) |
| 26 - 27 | SEQUENCE_NUMBER_LSB: (Minimal accepted value) |
| 28 - 31 | Unassigned |
This Notify Payload my return a Diet-ESP Proposal Payload accepted by the responder.
IANA is requested to allocate two values in the IKEv2 Notify Message Types - Status Types registry:
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
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC7296] | Kaufman, C., Hoffman, P., Nir, Y., Eronen, P. and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, October 2014. |
| [I-D.mglt-ipsecme-diet-esp] | Migault, D. and T. Guggemos, "Diet-ESP: a flexible and compressed format for IPsec/ESP", Internet-Draft draft-mglt-ipsecme-diet-esp-01, July 2014. |
| [I-D.mglt-ipsecme-diet-esp-payload-compression] | Migault, D. and T. Guggemos, "Diet-IPsec: ESP Payload Compression of IPv6 / UDP / TCP / UDP-Lite", Internet-Draft draft-mglt-ipsecme-diet-esp-payload-compression-00, July 2014. |