idnits 2.17.1 draft-moskowitz-ssls-hip-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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([RFC7401]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 171 has weird spacing: '...T Index inde...' -- The document date (June 27, 2017) is 2488 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) == Missing Reference: 'TBD-IANA' is mentioned on line 334, but not defined == Missing Reference: 'RFC 2394' is mentioned on line 315, but not defined == Missing Reference: 'RFC 2395' is mentioned on line 316, but not defined == Missing Reference: 'RFC 3051' is mentioned on line 317, but not defined == Unused Reference: 'I-D.ietf-hip-dex' is defined on line 495, but no explicit reference was found in the text == Unused Reference: 'RFC2394' is defined on line 509, but no explicit reference was found in the text == Unused Reference: 'RFC2395' is defined on line 513, but no explicit reference was found in the text == Unused Reference: 'RFC3051' is defined on line 517, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-hares-i2nsf-ssls-00 == Outdated reference: A later version (-24) exists of draft-ietf-hip-dex-05 == Outdated reference: A later version (-06) exists of draft-moskowitz-hierarchical-hip-03 Summary: 2 errors (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SSE BOF R. Moskowitz 3 Internet-Draft L. Xia 4 Intended status: Standards Track Huawei 5 Expires: December 29, 2017 I. Faynberg 6 Stargazers Consulting, LLC 7 S. Hares 8 Hickory Hill Consulting 9 P. Giacomin 10 FreeLance 11 June 27, 2017 13 Secure Session Layer Services KMP via HIP 14 draft-moskowitz-ssls-hip-02 16 Abstract 18 This memo specifies the details for establishing and maintaining a 19 Secure Session Layer Services (SSLS) association between two 20 applications using the Host Identity Protocol (HIP [RFC7401]). This 21 is primarily achieved by adding SSLS specific HIP parameters for the 22 HIP base exchange. The SSLS association state and security 23 boundaries are also defined. 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 December 29, 2017. 42 Copyright Notice 44 Copyright (c) 2017 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 62 2.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Discovering an SSLS application peer . . . . . . . . . . . . 3 65 4. HIP parameters to negotiate and manage SSLS . . . . . . . . . 3 66 4.1. SSE_INFO . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4.2. SSE_TRANSFORM . . . . . . . . . . . . . . . . . . . . . . 5 68 4.3. SSE_FORMAT . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.4. GPCOMP_INFO . . . . . . . . . . . . . . . . . . . . . . . 7 70 4.5. SSLS_INFO . . . . . . . . . . . . . . . . . . . . . . . . 7 71 4.6. NOTIFICATION Parameter . . . . . . . . . . . . . . . . . 8 72 5. Security Boundaries and APIs . . . . . . . . . . . . . . . . 8 73 5.1. Application to HIP API . . . . . . . . . . . . . . . . . 9 74 6. HIP mobility and SSLS . . . . . . . . . . . . . . . . . . . . 10 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 77 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 80 10.2. Informative References . . . . . . . . . . . . . . . . . 11 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 83 1. Introduction 85 The Secure Session Layer Services (SSLS) [I-D.hares-i2nsf-ssls] 86 provides a well defined session layer that can be implemented in any 87 application to provide any or all of the following: 89 o data compression 91 o chunking of data 93 o secure envelope 95 o fragmentation and reassembly 96 Applications implementing SSLS may need to negotiate the use of this 97 service and its components. They must be able to negotiate the 98 security association to support the use of the Session Security 99 Envelope (SSE [I-D.moskowitz-sse]). HIP is an ideal protocol to 100 support this association management. The SSE management requirement 101 closely parallels HIP support of ESP [RFC7402] to the extent that 102 Section 4 need only define the new parameter and point to [RFC7402] 103 for the processing details. 105 2. Terms and Definitions 107 2.1. Requirements Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [RFC2119]. 113 2.2. Notations 115 This section will contain notations 117 2.3. Definitions 119 GPcomp: General Purpose Compression. 121 SSE: Session Specific Envelope. 123 3. Discovering an SSLS application peer 125 A HIP enabled SSLS application needs to discover its peer 126 application. This could be manually configured, discovered via DNS, 127 or some other services discovery mechanism. 129 In the DNS example, the application recognizes the returned address 130 as a HIT and the HI RR record. It next needs to discover the IP 131 address for this HIT. If the HIT is Hierarchical 132 [I-D.moskowitz-hierarchical-hip], it can use the HHIT DNS reverse 133 lookup mechanism. In either case, the IP address may be that of the 134 peer application's RVS [RFC8004]. 136 Any other service discovery mechanism still has to provide the HIT, 137 HI, and IP address as a minimal set of information. 139 4. HIP parameters to negotiate and manage SSLS 141 Five HIP parameters are defined for setting up SSLS associations in 142 HIP communication and for restarting existing ones. Also, the 143 NOTIFICATION parameter, described in [RFC7401], has four new error 144 parameters. 146 Parameter Type Length Data 148 SSE_INFO [TBD-IANA] 12 Remote's old SPI, new SPI 149 SSE_TRANSFORM [TBD-IANA] variable SSE Encryption and 150 Authentication Transform(s) 151 SSE_FORMAT [TBD-IANA] variable SSE Format 152 GPCOMP_INFO [TBD-IANA] 12 Compression Algorithm 153 SSLS_INFO [TBD-IANA] 8 SSLS chunking and fragmenting 155 4.1. SSE_INFO 157 0 1 2 3 158 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 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Type | Length | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Reserved | KEYMAT Index | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | OLD SPI | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | NEW SPI | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 Type [TBD-IANA] 170 Length 12 171 KEYMAT Index index, in bytes, where to continue to draw SSE keys 172 from KEYMAT. If the packet includes a new 173 Diffie-Hellman key and the SSE_INFO is sent in an 174 UPDATE packet, the field MUST be zero. If the 175 SSE_INFO is included in base exchange messages, the 176 KEYMAT Index must have the index value of the point 177 from where the SSE SA keys are drawn. Note that 178 the length of this field limits the amount of 179 keying material that can be drawn from KEYMAT. If 180 that amount is exceeded, the packet MUST contain 181 a new Diffie-Hellman key. 182 OLD SPI old SPI for data sent to address(es) associated 183 with this SA. If this is an initial SA setup, the 184 OLD SPI value is zero. 185 NEW SPI new SPI for data sent to address(es) associated 186 with this SA. 188 The processing of SSE_INFO is similar to ESP_INFO, section 5.1.1 of 189 RFC7402 [RFC7402], without the KEYMAT generation. 191 4.2. SSE_TRANSFORM 193 The SSE_TRANSFORM parameter is used during SSE SA establishment. The 194 first party sends a selection of transform families in the 195 SSE_TRANSFORM parameter, and the peer must select one of the proposed 196 values and include it in the response SSE_TRANSFORM parameter. 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Type | Length | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Reserved | Suite ID #1 | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Suite ID #2 | Suite ID #3 | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Suite ID #n | Padding | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 Type [TBD-IANA] 211 Length length in octets, excluding Type, Length, and 212 padding. 213 Reserved zero when sent, ignored when received. 214 Suite ID defines the SSE Suite to be used. 216 The following Suite IDs can be used: 218 Suite ID Value 220 RESERVED 0 [this draft] 221 RESERVED 1 - 9 [this draft] 222 AES-CCM-8 10 [RFC4309] 223 AES-CCM-16 11 [RFC4309] 224 AES-GCM with an 8-octet ICV 12 [RFC4106] 225 AES-GCM with a 16-octet ICV 13 [RFC4106] 226 AES-CMAC-96 14 [RFC4493], [RFC4494] 227 AES-GMAC 15 [RFC4543] 229 SSE only supports the newer CCM and GCM modes of operation. The 230 Suite ID assignments are as above to align with [RFC7402]. 232 The sender of an SSE transform parameter MUST make sure that there 233 are no more than six (6) Suite IDs in one SSE transform parameter. 234 Conversely, a recipient MUST be prepared to handle received transform 235 parameters that contain more than six Suite IDs. The limited number 236 of Suite IDs sets the maximum size of the SSE_TRANSFORM parameter. 237 As the default configuration, the SSE_TRANSFORM parameter MUST 238 contain at least one of the mandatory Suite IDs. There MAY be a 239 configuration option that allows the administrator to override this 240 default. 242 Mandatory implementations: AES-CCM-16. AES-CMAC-96 SHOULD also be 243 supported. 245 4.3. SSE_FORMAT 247 The SSE_FORMAT parameter is used during SSE SA establishment. The 248 first party sends a selection of formats in the SSE_FORMAT parameter, 249 and the peer must select one of the proposed values and include it in 250 the response SSE_FORMAT parameter. 252 0 1 2 3 253 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 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Type | Length | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Reserved | Format ID #1 | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Format ID #2 | Format ID #3 | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Format ID #n | Padding | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 Type [TBD-IANA] 265 Length length in octets, excluding Type, Length, and 266 padding. 267 Reserved zero when sent, ignored when received. 268 Format ID defines the SSE Format to be used. 270 The following Format IDs can be used: 272 Format ID Value 274 RESERVED 0 [this draft] 275 Compact 1 [I-D.moskowitz-sse] 276 Large 2 [I-D.moskowitz-sse] 277 Extreme 3 [I-D.moskowitz-sse] 279 The sender of an SSE format parameter MUST make sure that there are 280 no more than six (6) Format IDs in one SSE format parameter. 281 Conversely, a recipient MUST be prepared to handle received format 282 parameters that contain more than six Format IDs. The limited number 283 of Format IDs sets the maximum size of the SSE_FORMAT parameter. As 284 the default configuration, the SSE_FORMAT parameter MUST contain at 285 least one of the mandatory Format IDs. There MAY be a configuration 286 option that allows the administrator to override this default. 288 Mandatory implementations: Compact 290 4.4. GPCOMP_INFO 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Type | Length | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | CPI | Comp ID #1 | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Comp ID #2 | Comp ID #3 | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Comp ID #n | Padding | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Type [TBD-IANA] 305 Length length in octets, excluding Type, Length, and 306 padding. 307 Suite ID defines the SSE Suite to be used. 309 The following Comp IDs can be used: 311 Comp ID Value 313 RESERVED 0 [this draft] 314 GPCOMP_OUI 1 (UNSPECIFIED) 315 GPCOMP_DEFLATE 2 [RFC 2394] 316 GPCOMP_LZS 3 [RFC 2395] 317 GPCOMP_LZJH 4 [RFC 3051] 319 The Comp ID has the same interpretation as IPcomp, section 2.22 of 320 RFC7402 [RFC7296]. 322 The processing of GPCOMP_INFO is similar to ESP_TRANSFORM, section 323 5.1.2 of RFC7402 [RFC7402]. 325 4.5. SSLS_INFO 326 0 1 2 3 327 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 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Type | Length | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Chunk size | Fragment size | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 Type [TBD-IANA] 335 Length 8 336 Chunk size Maximum data chunk supported. 0 if no chunking. 337 Fragment size Maximum data fragment supported. 0 if no fragmenting. 339 4.6. NOTIFICATION Parameter 341 The HIP base specification defines a set of NOTIFICATION error types. 342 The following error types are required for describing errors in ESP 343 Transform crypto suites during negotiation. 345 NOTIFICATION PARAMETER - ERROR TYPES Value 346 ------------------------------------ ----- 348 NO_SSE_PROPOSAL_CHOSEN 20 350 None of the proposed SSE Transform crypto suites was 351 acceptable. 353 INVALID_SSE_TRANSFORM_CHOSEN 21 355 The SSE Transform crypto suite does not correspond to 356 one offered by the Responder. 358 NO_SSE_FORMAT_CHOSEN 22 360 None of the proposed SSE Format suites was acceptable. 362 INVALID_SSE_FORMAT_CHOSEN 23 364 The SSE Format suite does not correspond to one offered 365 by the Responder. 367 5. Security Boundaries and APIs 369 When an application has direct control over the security of the 370 communication, even when this is done via external modules, extreme 371 care is needed in managing the environment. This is why HIP 372 communicates some values directly to the SSE and GPcomp modules. 374 This way the application cannot override their action. This does 375 require the application to be able to accept calls from HIP itself 376 whenever an event changes the SPIs for an association. 378 5.1. Application to HIP API 380 It is assumed the application has learned the peer HIT and IP address 381 before invoking HIP. Thus the calling parameters are: 383 Source HIT, HI, and IP address 384 Destination HIT, HI, and IP address 385 SSE acceptable Transform and Format lists 386 GPcomp acceptable Algorithms list [Null if no compression] 387 Max chunk size [0 = no chunking] 388 Max fragment size [0 = no fragmenting] 390 HIP returns to the calling application: 392 Source HIT, HI, and IP address 393 Actual destination HIT, HI, and IP address 394 SSE SPIs 395 SSE agreed format 396 GPcomp status [Yes/No] 397 Agreed max chunk size [0 = no chunking] 398 Agreed max fragment size [0 = no fragment] 400 HIP sends to the SSE module: 402 SSE SPIs 403 SSE agreed transform 404 SSE session keys [Note: SSE controls HIP rekeying based on 405 transform and Sequence Number. In which 406 case HIP will notify the application of 407 a change to the SPIs] 409 HIP sends to the GPcomp module: 411 SSE SPIs 412 GPcomp agreed algorithm 414 6. HIP mobility and SSLS 416 The HIP module SHOULD detect an IP address change for an interface 417 and initiate a HIP Mobility operation [RFC8046]. It will then inform 418 the SSLS application of the address change and any SPI changes to the 419 application and other components. 421 An example of this is a CPE gateway managed with RESTCONF on a PPPoE 422 link that has restarted and had a new IP address assigned. The 423 RESTCONF server would be able to apply any configuration changes to 424 the gateway without needing to wait for the gateway to call back 425 first. 427 7. IANA Considerations 429 This document defines five Parameter Types and four NOTIFY Message 430 Types for the Host Identity Protocol [RFC7401]. 432 SSE_INFO: This document defines the new SSE_INFO parameter (see 433 Section 4.1). The parameter value will be assigned by IANA. Its 434 value should come from the 66-127 range. 436 SSE_TRANSFORM: This document defines the new SSE_TRANSFORM parameter 437 (see Section 4.2). The parameter value will be assigned by IANA. 438 Its value should come from the 4096-4480 range. 440 SSE_FORMAT: This document defines the new SSE_FORMAT parameter (see 441 Section 4.3). The parameter value will be assigned by IANA. Its 442 value should come from the 4096-4480 range. 444 GPCOMP_INFO: This document defines the new GPCOMP_INFO parameter 445 (see Section 4.4). The parameter value will be assigned by IANA. 446 Its value should come from the 66-127 range. It should be greater 447 than SSE_INFO. 449 SSLS_INFO: This document defines the new SSLS_INFO parameter (see 450 Section 4.5). The parameter value will be assigned by IANA. Its 451 value should come from the 66-127 range. 453 The new NOTIFY error types and their values are defined in 454 Section 4.6, and they have been added to the Notify Message Type 455 namespace created by [RFC7401]. 457 8. Security Considerations 459 Security boundaries must be rigorously observed. Care is taken in 460 terms of what information is known to which module. Still the 461 application possesses both the clear and crypto text and can thus be 462 an attack point against the session keys. 464 9. Acknowledgments 466 TBD 468 10. References 470 10.1. Normative References 472 [I-D.hares-i2nsf-ssls] 473 Hares, S. and R. Moskowitz, "Secure Session Layer 474 Services", draft-hares-i2nsf-ssls-00 (work in progress), 475 March 2016. 477 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 478 Requirement Levels", BCP 14, RFC 2119, 479 DOI 10.17487/RFC2119, March 1997, 480 . 482 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 483 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 484 RFC 7401, DOI 10.17487/RFC7401, April 2015, 485 . 487 [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the 488 Encapsulating Security Payload (ESP) Transport Format with 489 the Host Identity Protocol (HIP)", RFC 7402, 490 DOI 10.17487/RFC7402, April 2015, 491 . 493 10.2. Informative References 495 [I-D.ietf-hip-dex] 496 Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)", 497 draft-ietf-hip-dex-05 (work in progress), February 2017. 499 [I-D.moskowitz-hierarchical-hip] 500 Moskowitz, R. and X. Xu, "Hierarchical HITs for HIPv2", 501 draft-moskowitz-hierarchical-hip-03 (work in progress), 502 June 2017. 504 [I-D.moskowitz-sse] 505 Moskowitz, R., Faynberg, I., Lu, H., Hares, S., and P. 506 Giacomin, "Session Security Envelope", draft-moskowitz- 507 sse-05 (work in progress), June 2017. 509 [RFC2394] Pereira, R., "IP Payload Compression Using DEFLATE", 510 RFC 2394, DOI 10.17487/RFC2394, December 1998, 511 . 513 [RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using 514 LZS", RFC 2395, DOI 10.17487/RFC2395, December 1998, 515 . 517 [RFC3051] Heath, J. and J. Border, "IP Payload Compression Using 518 ITU-T V.44 Packet Method", RFC 3051, DOI 10.17487/RFC3051, 519 January 2001, . 521 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 522 (GCM) in IPsec Encapsulating Security Payload (ESP)", 523 RFC 4106, DOI 10.17487/RFC4106, June 2005, 524 . 526 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 527 Mode with IPsec Encapsulating Security Payload (ESP)", 528 RFC 4309, DOI 10.17487/RFC4309, December 2005, 529 . 531 [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The 532 AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June 533 2006, . 535 [RFC4494] Song, JH., Poovendran, R., and J. Lee, "The AES-CMAC-96 536 Algorithm and Its Use with IPsec", RFC 4494, 537 DOI 10.17487/RFC4494, June 2006, 538 . 540 [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message 541 Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, 542 DOI 10.17487/RFC4543, May 2006, 543 . 545 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 546 Kivinen, "Internet Key Exchange Protocol Version 2 547 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 548 2014, . 550 [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 551 Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, 552 October 2016, . 554 [RFC8046] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility 555 with the Host Identity Protocol", RFC 8046, 556 DOI 10.17487/RFC8046, February 2017, 557 . 559 Authors' Addresses 561 Robert Moskowitz 562 Huawei 563 Oak Park, MI 48237 565 Email: rgm@labs.htt-consult.com 567 Liang Xia 568 Huawei 569 No. 101, Software Avenue, Yuhuatai District 570 Nanjing 571 China 573 Email: Frank.xialiang@huawei.com 575 Igor Faynberg 576 Stargazers Consulting, LLC 577 East Brunswick, NJ 08816 578 USA 580 Email: igorfaynberg@gmail.com 582 Susan Hares 583 Hickory Hill Consulting 584 7453 Hickory Hill 585 Saline, MI 48176 586 USA 588 Email: shares@ndzh.com 590 Pierpaolo Giacomin 591 FreeLance 593 Email: yrz@anche.no