idnits 2.17.1 draft-mglt-6lo-diet-esp-context-ikev2-extension-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 17, 2015) is 3355 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-02) exists of draft-mglt-6lo-diet-esp-00 == Outdated reference: A later version (-01) exists of draft-mglt-6lo-diet-esp-payload-compression-00 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lo D. Migault, Ed. 3 Internet-Draft Ericsson 4 Intended status: Standards Track February 17, 2015 5 Expires: August 21, 2015 7 Diet-ESP Context IKEv2 Extension 8 draft-mglt-6lo-diet-esp-context-ikev2-extension-02.txt 10 Abstract 12 Diet-ESP has been designed for IoT to limit the IPsec ESP overhead in 13 each IPsec packet. Diet-ESP is based on the standard IPsec ESP, and 14 needs that peers agree on a Diet-ESP Context that defines how 15 standard ESP packets can be compressed before being sent over the 16 wire. 18 Standard IPsec ESP can be agreed between peers using IKEv2. However, 19 current IKEv2 does not make possible to negotiate a Diet-ESP Context, 20 and thus to negotiate a Diet-ESP communication. 22 This draft defines an extension for IKEv2 so peers can agree the 23 Diet-ESP Context, and thus negotiate a Diet-ESP association. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 21, 2015. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 60 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 61 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 63 5. Diet-ESP Context . . . . . . . . . . . . . . . . . . . . . . 4 64 6. Protocol details . . . . . . . . . . . . . . . . . . . . . . 5 65 6.1. Diet-ESP Context Negotiation . . . . . . . . . . . . . . 6 66 6.2. Error Handling . . . . . . . . . . . . . . . . . . . . . 7 67 7. Payload Description . . . . . . . . . . . . . . . . . . . . . 7 68 7.1. DIET_ESP_CONTEXT_PROPOSALS Notify Payload . . . . . . . . 8 69 7.1.1. Diet-ESP Proposal Payload . . . . . . . . . . . . . . 8 70 7.1.1.1. FULL_SUPPORT Diet-ESP Context Payload Format . . 9 71 7.1.1.2. SINGLE_CONTEXT Diet-ESP Context Payload Format . 9 72 7.1.1.3. MINIMAL_CONTEXT Diet-ESP Context Payload Format . 10 73 7.1.1.4. MAXIMAL_CONTEXT Diet-ESP Context Payload Format . 10 74 7.1.1.5. RANGE_CONTEXT Diet-ESP Context Payload Format . . 10 75 7.2. UNACCEPTABLE_DIET_ESP_CONTEXT Notify Payload . . . . . . 11 76 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 11 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 78 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 81 11.2. Informational References . . . . . . . . . . . . . . . . 12 82 Appendix A. Document Change Log . . . . . . . . . . . . . . . . 13 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 85 1. Requirements notation 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC2119]. 91 2. Requirements notation 93 This section defines terms and acronyms used in this document. 95 - Diet-ESP Context: Defines the necessary parameters that are 96 needed in order to set a Diet-ESP session. A Diet-ESP Context 97 is a set of parameters with no particular format. 99 - Diet-ESP Proposal Payload: Defines the payload that carries the 100 necessary information to derive the Diet-ESP Context. It can 101 be seen as a container for Diet-ESP Context parameters. The 102 Diet-ESP Proposal Payload is associated to a Diet-ESP Context, 103 and Diet-ESP Context may evolve over time. As a result, the 104 Diet-ESP Proposal needs to identify the Diet-ESP Context (using 105 a Diet-ESP Context ID). When one peers wants to propose a set 106 of various values, there may be some more optimal ways to 107 presents these proposals. The Diet-ESP Proposal also 108 identifies the Diet-ESP Context Payload with the Diet-ESP 109 Context Payload Format. The Diet-ESP Context Payload Format 110 defines the Diet-ESP Context Payload. 112 - Diet-ESP Context Payload: Is associated to a Diet-ESP Context ID 113 and Diet-ESP Context Payload Format. It defines how the 114 remaining bits must be interpreted to derive the parameters 115 associated to a Diet-ESP Context. 117 3. Introduction 119 Diet-ESP [I-D.mglt-6lo-diet-esp] 120 [I-D.mglt-6lo-diet-esp-payload-compression] has been designed to 121 reduce the ESP overhead on IP packet sent over the wire. 123 The principle of Diet-ESP is to use ESP and compress each field. 124 Compression depends on the context and the environment and is defined 125 by the Diet-ESP Context. 127 IKEv2 [RFC7296] enables negotiation of ESP Security Associations, but 128 does not enable the negotiation of the Diet-ESP Context. Thus 129 preventing establishment of Diet-ESP SA. This document describes an 130 extension of IKEv2 that make possible two peers to agree on a Diet- 131 ESP Context and thus make possible the establishment of a Diet-ESP 132 SA. 134 4. Protocol Overview 136 When an initiator wants to negotiate an Security Association (SA) 137 using Diet-ESP, it negotiates a regular SA with a SA Payload, and 138 indicates its willingness to establish a Diet-ESP session. In order 139 to set the Diet-ESP session, a Diet-ESP Context MUST be agreed 140 between the two peers. As a result, the initiator and the responder 141 MUST negotiate and agree on a Diet-ESP Context. 143 To indicate its preference for a Diet-ESP instead of standard ESP, 144 the initiator adds a DIET_ESP_CONTEXT_PROPOSAL Notify Payload. This 145 Notify Payload carries a Diet-ESP Proposal Payload which can be seen 146 as a container proposing Diet-ESP Contexts Payload. The Diet-ESP 147 Proposal Payload indicates the Diet-ESP Context ID, a Diet-ESP 148 Context Payload Format. These parameters make possible to derive 149 properly the Diet-ESP Context parameters from the Diet-ESP Context 150 Payload. 152 A Diet-ESP Context Payload is defined for each Diet-ESP Context ID 153 and Diet-ESP Context Payload Format. The Diet-ESP Context ID 154 indicates the Diet-ESP Context it refers to. For example, a Diet-ESP 155 Context ID set to 0 indicates the initiator and responder refers to 156 the Diet-ESP Context defined in this document. The Diet-ESP Context 157 Payload Format corresponds to a convenient ways to present the 158 proposals. 160 When the responder receives a DIET_ESP_CONTEXT_PROPOSAL Notify 161 Payload. If the responder also wants to establish a Diet-ESP 162 session, it responds with a DIET_ESP_CONTEXT_PROPOSAL Notify Payload 163 with the chosen Diet-ESP Context. The chosen Diet-ESP Context is 164 sent back using a specific Diet-ESP Proposal Payload. From this 165 point, both peers have agreed with a standard ESP SA and a Diet-ESP 166 Context. IP packets related to this specific SA are sent on the 167 wired using the compressed format defined by the Diet-ESP Context. 169 If the responder does not accept the values proposed by the initiator 170 for the Diet-ESP Context, the DIET_ESP_CONTEXT_PROPOSAL Notify 171 Payload is ignored and no response is sent back. 173 If the responder does not agree with the proposals it MUST respond 174 with a UNACCEPTABLE_DIET_ESP_CONTEXT. 176 If the initiator does not understand the Diet-ESP Proposal Payload 177 received by the responder, the SA MUST be deleted. 179 5. Diet-ESP Context 181 The Diet-ESP Context is a set of values defined 182 [I-D.mglt-6lo-diet-esp] and 183 [I-D.mglt-6lo-diet-esp-payload-compression]. The Diet-ESP Context is 184 a structure that defines fields and accepted values. A instance or a 185 set of instance of Diet-ESP Context is exchanged on the wire using 186 specific Diet-ESP Context Payload. The different types of Diet-ESP 187 Context Payload are defined in Table 1. 189 Table 1 presents the various fields and associated values of the 190 Diet-ESP Context defined in this document. 192 +-------------------------------+-----------------------------------+ 193 | Fields Definition | Values | 194 +-------------------------------+-----------------------------------+ 195 | ALIGN | 0 for 8 bit alignment | 196 | | 1 for 16 bit alignment | 197 | | 2 for 32 bit alignment | 198 | | 3 for 64 bit alignment | 199 | SPI_SIZE | 0 for 0 byte of SPI | 200 | | 1 for 1 byte of SPI | 201 | | 2 for 2 bytes of SPI | 202 | | 3 for 4 bytes of SPI | 203 | SN_SIZE | 0 for 0 byte of SN | 204 | | 1 for 1 byte of SN | 205 | | 2 for 2 bytes of SN | 206 | | 3 for 4 bytes of SN | 207 | NH | 0 indicates Next Header is | 208 | | removed | 209 | | 1 indicates Next Header is | 210 | | present | 211 | PAD | 0 indicates Pad Length is removed | 212 | | 1 indicates Pad Length is present | 213 | Diet-ESP_ICV_SIZE | 0 for 0 byte of ICV | 214 | | 1 for 1 byte of ICV | 215 | | 2 for 2 bytes of ICV | 216 | | 3 for 4 bytes of ICV | 217 | COMPRESS_ESP_PAYLOAD | 0 indicates TS are not considered | 218 | | 1 indicates TS are considered | 219 | TRANSPORT_CHECKSUM_LSB | 0 for 0 byte of Checksum | 220 | | 1 for 1 byte of Checksum | 221 | | 2 for 2 bytes of Checksum | 222 | TRANSPORT_SEQUENCE_NUMBER_LSB | 0 for 0 byte of TCP Sequence | 223 | | Number | 224 | | 1 for 1 byte of TCP Sequence | 225 | | Number | 226 | | 2 for 2 bytes of TCP Sequence | 227 | | Number | 228 | | 3 for 4 bytes of TCP Sequence | 229 | | Number | 230 +-------------------------------+-----------------------------------+ 232 Table 1: Diet-ESP Context Definition 234 6. Protocol details 235 6.1. Diet-ESP Context Negotiation 237 Negotiation of Diet-ESP Compression is separate from the negotiation 238 of cryptographic parameters associated with a Child SA. A initiator 239 requesting a Child SA MAY advertise its support for one or more Diet- 240 ESP Context through one Notify payloads of type 241 DIET_ESP_CONTEXT_PROPOSALS. This Notify message may be included only 242 in a message containing an SA payload negotiating a Child SA and 243 indicates a willingness by its sender to use Diet-ESP on this SA. 244 The responder MAY indicate acceptance of a single Diet-ESP Context 245 with a Notify payload of type DIET_ESP_CONTEXT_PROPOSALS. These 246 payloads MUST NOT occur in messages that do not contain SA payloads. 248 Diet-ESP has been designed to compress ESP only. As a result, when a 249 SA Payload embeds multiple proposals, the negotiated Diet-ESP Context 250 concerns all proposals with an Protocol ID set to ESP, and MUST be 251 ignored for any other Protocol IDs. 253 If the responder accepts at least one proposal, the responder 254 responds with a DIET_ESP_CONTEXT_PROPOSALS Notify Payload. This 255 notification carries a Diet-ESP Proposal Payload of Diet-ESP Context 256 Payload Format SINGLE_CONTEXT. The format provides a single Diet-ESP 257 Context with each parameter uniquely specified. 259 If the responder does not support the Diet-ESP extension, it ignores 260 the DIET_ESP_CONTEXT_PROPOSALS Notify Payload. By default, in case, 261 no Diet-ESP Context have been agreed, the SA negotiated is ESP. 263 If the responder understand all proposals but accepts none of the 264 proposed Diet-ESP Context, it MUST indicate the initiator that these 265 values are not acceptable with a UNACCEPTABLE_DIET_ESP_CONTEXT Notify 266 Payload. By default, the SA is then agreed using standard ESP, so if 267 the responder does not want this SA, it MUST Delete the SA. 269 If the initiator does not understand the responded Diet-ESP Context 270 by the responder, the initiator MUST delete its SA, re-initiates the 271 IKEv2 negotiation using standard ESP. 273 Figure 1 illustrates the case where the initiator and the responder 274 agree on a Diet-ESP Context. The negotiation occurs during the 275 IKE_AUTH exchange. However, the negotiation can occurs for any Child 276 SA negotiation. 278 Initiator Responder 279 ------------------------------------------------------------------- 280 HDR, SK { IDi, CERT, AUTH, 281 CP(CFG_REQUEST), 282 SAi2, TSi, TSr, 283 N(DIET_ESP_PROPOSALS) } 284 <-- HDR, SK { IDr, CERT, AUTH, 285 CP(CFG_REPLY), SAr2, TSi, TSr, 286 N(DIET_ESP_PROPOSALS) } 288 Figure 1 290 6.2. Error Handling 292 To indicate that a responder supports the Diet-ESP extension but does 293 not agree with the proposed Diet-ESP Context, the responder sends a 294 UNACCEPTABLE_DIET_ESP_CONTEXT Notify Payload. 296 7. Payload Description 298 Figure 2 illustrates the Notify Payload packet format as described in 299 section 3. 10 of [RFC7296]. This format is used for the 300 DIET_ESP_CONTEXT_PROPOSALS notification. 302 1 2 3 303 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 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Next Payload |C| RESERVED | Payload Length | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Protocol ID | SPI Size | Notify Message Type | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 Figure 2: Notify Payload 312 The fields Next Payload, Critical Bit, RESERVED and Payload Length 313 are defined in [RFC7296]. Specific fields defined in this document 314 are: 316 - Protocol ID (1 octet): set to zero. 318 - SPI Size (1 octet): set to zero. 320 - Notify Message Type (2 octets): Specifies the type of notification 321 message. It is set to for the 322 DIET_ESP_CONTEXT_PROPOSALS and UNACCEPTABLE_DIET_ESP_CONTEXT 323 notification. 325 7.1. DIET_ESP_CONTEXT_PROPOSALS Notify Payload 327 The DIET_ESP_CONTEXT_PROPOSALS Notify Payload is used to: 329 - By the initiator: To announce its support of Diet-ESP as a well as 330 the accepted Diet-ESP Contexts. 332 - By the responder: To announce its support of Diet-ESP as well as 333 the agreed Diet-ESP Context 335 To announce the accepted values for each fields of the Diet-ESP 336 Contexts, the initiator sends a DIET_ESP_CONTEXT_PROPOSALS Notify 337 Payload with one or multiple Diet-ESP Proposal Payload. 339 7.1.1. Diet-ESP Proposal Payload 341 The Diet-ESP Payload can be seen as a container for a Diet-ESP 342 Context. The format for signaling Diet-ESP Attributes takes a 343 similar format to the Transform Attributes described in Section 3.3.5 344 of [RFC7296] and is represented in Figure 3 346 Note that the Diet-ESP Context is provided with all parameters, and 347 the current specification does not make possible to provide each 348 parameter individually. Providing the whole Diet-ESP Context reduces 349 the number of byte of the Attribute Payload over providing each 350 parameter individually. 352 1 2 3 353 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 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 |A| Diet-ESP Attribute | AF=0 Attribute Length | 356 |F| Context ID |Context Format | | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Diet-ESP Context Payload | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 Figure 3: Diet-ESP Payload 363 - AF=0 (1 bit) : Specified the attribute format is of Type/Length/ 364 Value. 366 - Diet-ESP Context ID (7 bits) : The ID of the Diet-ESP Context. 368 - 0: The Diet-ESP Context defined in this document. 370 - 1 - 127: Unassigned 372 - Diet-ESP Context Format (4 bits) : indicates the Diet-ESP Context 373 Payload Format. The following values are considered: 375 - 0 FULL_SUPPORT: The initiator indicates it has no 376 restrictions on the fields values of the Diet-ESP Context 377 and supports all defined values. 379 - 1 SINGLE_CONTEXT: Defines a single Diet-ESP Context. It can 380 be used by the initiator if only a single value is 381 accepted for each field of the Diet-ESP Context. It is 382 used by the responder to indicate the agreed Diet-ESP 383 Context. 385 - 2 MINIMAL_CONTEXT: The initiator indicates for each field of 386 the Diet-ESP Context the minimal accepted values. 388 - 3 MAXIMAL_CONTEXT: The initiator indicates for each field of 389 the Diet-ESP Context the maximal accepted values. 391 - 4 RANGE_CONTEXT: The initiator indicates for each field of 392 the Diet-ESP Context a range of accepted values. 394 - 5 - 255: Unassigned 396 7.1.1.1. FULL_SUPPORT Diet-ESP Context Payload Format 398 The Diet-ESP Context Payload of format FULL_SUPPORT is an empty 399 payload. 401 7.1.1.2. SINGLE_CONTEXT Diet-ESP Context Payload Format 403 The Diet-ESP Context Payload that corresponds to the SINGLE_CONTEXT 404 Format assigns a specific value for each field. This format may be 405 used by the initiator to indicate a very specific proposal, or by the 406 responder to indicate its choice of values for the agreed Diet-ESP 407 Context. The Format of the Payload is defined by Table 2. The 408 fields value are described in Table 1 409 +----------+-------------------------------------------+ 410 | Bit | Fields Definition | 411 +----------+-------------------------------------------+ 412 | 0 - 1 | ALIGN: (2 bits) | 413 | 2 - 3 | SPI_SIZE: (2 bits) | 414 | 4 - 5 | SN_SIZE: (2 bits) | 415 | 6 | NH: (1 bit) | 416 | 7 | PAD: (1 bit) | 417 | 8 - 9 | Diet-ESP_ICV_SIZE: (2 bits) | 418 | 10 | COMPRESS_ESP_PAYLOAD: (1 bit) | 419 | 11 - 12 | TRANSPORT_CHECKSUM_LSB: (2 bits) | 420 | 13 - 14 | TRANSPORT_SEQUENCE_NUMBER_LSB: (2 bits) | 421 | 15 | Unassigned | 422 +----------+-------------------------------------------+ 424 Table 2: MINIMAL_CONTEXT Diet-ESP Context Format 426 7.1.1.3. MINIMAL_CONTEXT Diet-ESP Context Payload Format 428 The Diet-ESP Context Payload of format MINIMAL_CONTEXT defines for 429 all fields a minimal value. The Format of the Payload is defined by 430 Table 2. The fields value are described in Table 1 432 7.1.1.4. MAXIMAL_CONTEXT Diet-ESP Context Payload Format 434 The Diet-ESP Context Payload of format MAXIMAL_CONTEXT defines for 435 all fields a maximal value. The Format of the Payload is defined by 436 Table 2. The fields value are described in Table 1 438 7.1.1.5. RANGE_CONTEXT Diet-ESP Context Payload Format 440 The Diet-ESP Context Payload of format RANGE_CONTEXT defines for all 441 fields a minimum and a maximum value. The only field that is where 442 only the minimal value is provided is the ALIGN field. The Format of 443 the Payload is defined by Table 3. The fields value are described in 444 Table 1 445 +----------+--------------------------------------------------------+ 446 | Bit | Fields Definition | 447 +----------+--------------------------------------------------------+ 448 | 0 - 1 | ALIGN: (Minimal accepted value) | 449 | 2 - 3 | SPI_SIZE: (Minimal accepted value) | 450 | 4 - 5 | SN_SIZE: (Minimal accepted value) | 451 | 6 | NH: (Minimal accepted value) | 452 | 7 | PAD: (Minimal accepted value) | 453 | 8 - 9 | Diet-ESP_ICV_SIZE: (Minimal accepted value) | 454 | 10 | COMPRESS_ESP_PAYLOAD: (Minimal accepted value) | 455 | 11 - 12 | TRANSPORT_CHECKSUM_LSB: (Minimal accepted value) | 456 | 13 - 14 | TRANSPORT_SEQUENCE_NUMBER_LSB: (Minimal accepted | 457 | | value) | 458 | 15 - 16 | SPI_SIZE: (Maximal accepted value) | 459 | 17 - 18 | SN_SIZE: (Maximal accepted value) | 460 | 19 | NH: (Maximal accepted value) | 461 | 20 | PAD: (Maximal accepted value) | 462 | 21 - 22 | Diet-ESP_ICV_SIZE: (Maximal accepted value) | 463 | 23 | COMPRESS_ESP_PAYLOAD: (Maximal accepted value) | 464 | 24 - 25 | TRANSPORT_CHECKSUM_LSB: (Minimal accepted value) | 465 | 26 - 27 | TRANSPORT_SEQUENCE_NUMBER_LSB: (Minimal accepted | 466 | | value) | 467 | 28 - 31 | Unassigned | 468 +----------+--------------------------------------------------------+ 470 Table 3: RANGE_CONTEXT Diet-ESP Context Format 472 7.2. UNACCEPTABLE_DIET_ESP_CONTEXT Notify Payload 474 This Notify Payload my return a Diet-ESP Proposal Payload accepted by 475 the responder. 477 8. Acknowledgment 479 The current work on Diet-ESP results from exchange and cooperation 480 between Orange, Ludwig-Maximilians-Universitaet Munich, Universite 481 Pierre et Marie Curie. We thank Daniel Palomares and Carsten Bormann 482 for their useful remarks, comments and guidances on the design. We 483 thank Sylvain Killian for implementing an open source Diet-ESP on 484 Contiki and testing it on the FIT IoT-LAB [fit-iot-lab] funded by the 485 French Ministry of Higher Education and Research. We thank the IoT- 486 Lab Team and the INRIA for maintaining the FIT IoT-LAB platform and 487 for providing feed backs in an efficient way. 489 9. IANA Considerations 491 IANA is requested to allocate two values in the IKEv2 Notify Message 492 Types - Status Types registry: 494 IKEv2 Notify Message Types - Status Types 495 ----------------------------------------- 496 DIET_ESP_CONTEXT_PROPOSALS - TBA 497 UNACCEPTABLE_DIET_ESP_CONTEXT - TBA 499 Diet-ESP Attribute Types (Diet-ESP ID = 0) 500 ----------------------------------------- 501 FULL_SUPPORT - 256 502 SINGLE_CONTEXT - 257 503 MINIMAL_CONTEXT - 258 504 MAXIMAL_CONTEXT - 259 505 RANGE_CONTEXT - 260 507 10. Security Considerations 509 11. References 511 11.1. Normative References 513 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 514 Requirement Levels", BCP 14, RFC 2119, March 1997. 516 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 517 Kivinen, "Internet Key Exchange Protocol Version 2 518 (IKEv2)", STD 79, RFC 7296, October 2014. 520 11.2. Informational References 522 [I-D.mglt-6lo-diet-esp] 523 Migault, D. and T. Guggemos, "Diet-ESP: a flexible and 524 compressed format for IPsec/ESP", draft-mglt-6lo-diet- 525 esp-00 (work in progress), January 2015. 527 [I-D.mglt-6lo-diet-esp-payload-compression] 528 Migault, D. and T. Guggemos, "Diet-IPsec: ESP Payload 529 Compression of IPv6 / UDP / TCP / UDP-Lite", draft-mglt- 530 6lo-diet-esp-payload-compression-00 (work in progress), 531 January 2015. 533 [fit-iot-lab] 534 "Future Internet of Things (FIT) IoT-LAB", 535 . 537 Appendix A. Document Change Log 539 01 - 541 - Changing affiliation 543 01 - 545 - Adding Change log section 547 - Adding Acknowledgment section 549 - Updating references 6lo 551 - Updating notation coherent with draft-mglt-6lo-diet-esp-payload- 552 compression 554 - 556 00-First version published 558 Author's Address 560 Daniel Migault (editor) 561 Ericsson 562 8400 boulevard Decarie 563 Montreal, QC H4P 2N2 564 Canada 566 Email: mglt.ietf@gmail.com