idnits 2.17.1 draft-raza-6lo-ipsec-04.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6282], [RFC4301]), 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 -- The document date (March 18, 2016) is 2960 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: 'IEEE802.15.4' is mentioned on line 78, but not defined == Missing Reference: 'RFC5795' is mentioned on line 101, but not defined == Missing Reference: 'RFC6550' is mentioned on line 156, but not defined == Missing Reference: 'RFC2119' is mentioned on line 170, but not defined == Missing Reference: 'RFC4835' is mentioned on line 249, but not defined ** Obsolete undefined reference: RFC 4835 (Obsoleted by RFC 7321) == Unused Reference: 'KEYWORDS' is defined on line 398, but no explicit reference was found in the text == Unused Reference: 'RFC3095' is defined on line 440, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6434 (Obsoleted by RFC 8504) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6Lo Working Group S. Raza 3 Internet-Draft S. Duquennoy 4 Intended Status: Standard Track SICS, Stockholm 5 G. Selander 6 Ericsson, Stockholm 7 Expires: September 19, 2016 March 18, 2016 9 Compression of IPsec AH and ESP Headers for 6LoWPAN Networks 10 draft-raza-6lo-ipsec-04 12 Abstract 14 This document describes the header compression mechanisms for IPsec 15 [RFC4301] based on the encoding scheme standardized in [RFC6282]. The 16 IPsec Authentication Header (AH) and Encapsulated Security Payload 17 (ESP) headers are compressed using Next Header Compression (NHC) 18 defined in [RFC6282]. This document does not invalidate any encoding 19 schemes proposed in 6LoWPAN [RFC6282] but rather complements it with 20 compressed IPsec AH and ESP headers using the free bits in the IPv6 21 Extension Header encoding. Also, this document does not require any 22 changes in a conventional IPsec host on the Internet; the header 23 compression is applied only at the 6LoWPAN layer and is effective 24 within 6LoWPAN networks. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 19, 2016. 43 Copyright and License Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1 AH in 6LoWPAN Networks . . . . . . . . . . . . . . . . . . 3 62 1.2 IPsec and RPL . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Linking IPsec Headers Compression with 6LoWPAN . . . . . . . . 5 65 3. LOWPAN_NHC for Authentication Header . . . . . . . . . . . . . 5 66 4. LOWPAN_NHC for Encapsulated Security Payload (ESP) . . . . . . 7 67 5. Implementation Considerations . . . . . . . . . . . . . . . . . 8 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 72 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 75 1 Introduction 77 [RFC6282] defines how IPv6 datagrams can be routed over IEEE 802.15.4 78 [IEEE802.15.4]-based networks. [RFC6282] defines header compression 79 schemes that can significantly reduce the size of IP, IP extension, 80 and UDP headers. This enables the routing of heavy-weight IP traffic 81 to resource-constrained [IEEE802.15.4]-based wireless networks. The 82 security in [IEEE802.15.4]-based IP networks or what is more commonly 83 known as 6LoWPAN networks is particularly important when we connect 84 vulnerable wireless networks with the insecure Internet. The 85 standardized and SHOULD be supported security solution for IPv6 is IP 86 security (IPsec) [RFC4301][RFC6434]. This means that every IPv6 host 87 on the Internet SHOULD be able to process IP packets secured with 88 IPsec. IPsec, in transport mode, can provide end-to-end (E2E) secure 89 communication between two hosts in the Internet. Thus, it is 90 beneficial to extend 6LoWPAN so that IPsec communication between an 91 IPv6 device (e.g. a sensor node) in 6LoWPAN networks and a IPv6 host 92 on the Internet becomes possible. This document does not cover the 93 tunnel mode of IPsec. 95 There are previous proposals to compress IPsec headers. Those 96 compression schemes are applicable to any Internet host and are not 97 specific to resource-constrained 6LoWPAN networks. Migault et al. 98 [draft-mglt-6lo-diet-esp-01][draft-mglt-6lo-aes-implicit-iv-01] 99 propose compressing IPsec but require corresponding modifications in 100 the conventional Internet host. Similarly, the RObust Header 101 Compression (ROHC) [RFC5795][RFC5856] is an efficient and flexible 102 header compression concept but targets any Internet host and is not 103 specific to 6LoWPAN network. These previous schemes plus Generic 104 Header Compression [RFC7400] are complementary to our approach. Our 105 header compression mechanisms are confined to 6LoWPAN networks and do 106 not require any change in the IPsec AH and ESP standards or in a 107 conventional IPsec host on the Internet. 109 It is desirable to complement 6LoWPAN header compression with IPsec 110 to keep packet sizes reasonable in resource constrained 111 [IEEE802.15.4]-based network. There are no header compression 112 specified for IPsec's AH[RFC4302] and ESP[RFC4303] extension headers 113 for 6LoWPAN networks. This draft therefore proposes AH and ESP 114 extension header encoding schemes. 116 1.1 AH in 6LoWPAN Networks 118 AH is underused in the Internet due a number of reason. First, AH is 119 incompatible with Network Address Translation (NAT) that changes the 120 source IP address, which invalidates the integrity check and results 121 in packet rejection by the IPSec peer. Second, ESP can provide both 122 Integrity protection and encryption. However, ESP can only 123 authenticate the ESP header and application data but not the IP 124 header part. This is not an issue when the IPsec tunnel mode is use 125 because the inner IP header, ESP header and the application data is 126 both integrity and confidentiality protected. 128 In the IPv6-connected IoT there are no NATs and the transport mode 129 that provides end-to-end security is favorable. Therefore, the use of 130 ESP along with AH makes more sense in the IoT. As the IP address is a 131 part of IPsec AH integrity check, IPsec can protect against the IP 132 spoofing attack that is one of the most likely attacks against 133 constrained nodes running IPv6. Though IPv6 stateless address auto- 134 configuration is proposed, it is not a requirement for IPv6 hosts. 135 IPv6 addresses are assigned to resource-constrained nodes in 6LoWPAN 136 networks at the deployment time and they most likely stay the same 137 during the lifetime of a nodes unless manually changed through 138 software/firmware updates. Address auto-configurations for 6LoWPAN 139 networks that ensure end-to-end connectivity is in fact out of 140 question unless an efficient and suitable mechanism is developed 141 targeting 6loWPAN networks. Though mostly there is only one 142 application running in a 6LoWPAN node, IPv6 offers potentially 143 unlimited address space which allows using multiple IPv6 addresses 144 for a single 6LoWPAN node, hence allowing unique IPsec security 145 association per application. Also, if IPsec is using IKE [RFC7427] 146 unique security association per application can be dynamically 147 established. 149 Also, for a number of use cases in 6LoWPAN networks, such as sensing 150 and transmitting temperature data, only integrity protection is 151 required. For these use cases, AH-only is a favorable solution. 153 1.2 IPsec and RPL 155 Unlike IPv4, IPv6 ICMPv6 messages are protected by IPsec. As the RPL 156 Control Message [RFC6550] is an ICMPv6 message, it is therefore 157 possible to protect it with IPsec. However, all RPL Control 158 Messages, except DAO / DAO-ACK messages in non-storing mode, are 159 exchanged between two neighboring devices and have the scope of a 160 link. Though IPsec security associations can be created between two 161 neighboring devices, IEEE 802.15.4 security at the link layer is more 162 suitable for per-hop protection, and IPsec in transport mode can be 163 used to protect DAO/DAO-ACK messages in non-storing mode. 165 1.3 Terminology 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in RFC 2119 [RFC2119]. 171 2. Linking IPsec Headers Compression with 6LoWPAN 173 [RFC6282] defines the general format of NHC that can be used to 174 encode IP extension headers. [RFC6282] already defines an NHC 175 encoding for IPv6 Extension Headers (NHC_EH) that can be used to link 176 uncompressed AH and ESP headers to the 6LoWPAN header compression. In 177 order to compress the IP extension headers a GHC byte for Extension 178 Header (GHC_EH) [RFC7400] is proposed which has the same layout as 179 NHC_EH with different ID bits. NHC_EH and GHC_EH consist of an octet 180 where three bits (bits 4, 5 and 6) are used to encode the IPv6 181 Extension Header ID (EID). Out of eight possible values for the EID, 182 six are assigned and the remaining two slots (101 and 110) are 183 currently unassigned. As AH and ESP are IP extension headers it makes 184 sense to use one of these unassigned slots for the IPsec headers. We 185 propose to use the reserved slot 101 for the IPsec headers, AH or 186 ESP. The corresponding ID field in the AH or ESP will distinguish 187 these headers from each other. It is also necessary to set the NH bit 188 in NHC_EH or GHC_EH to 1 to specify that the next header (a header 189 after AH or ESP, e.g. UDP) is NHC-encoded. 191 3. LOWPAN_NHC for Authentication Header 193 6LoWPAN can be used to compress a significant number of bits in AH. 194 The next header is decided based on the value of NH bit in the IPv6 195 Extension Header Encoding in [RFC6282]. This draft proposes to always 196 elide the length field. The payload length field (the length of AH 197 header in 32-bit words units minus "2" [RFC4302]) in the AH header is 198 always elided, as it can be inferred from the lower layers: either 199 from the IEEE 802.15.4 header or the 6LoWPAN header. The size of ICV 200 can be obtained from the SPI value because the length of the 201 authenticating data depend on the the algorithm used and are fixed 202 for any input size. The RESERVED field in the AH header is also 203 always elided. The SPI and SN are compressed using the proposed NHC 204 encoding for the AH header shown in Figure 1 and are explained 205 below. 207 0 1 2 3 4 5 6 7 208 +---+---+---+---+---+---+---+---+ 209 | 1 | 1 | 0 | 1 | SPI | SN | 210 +---+---+---+---+---+---+---+---+ 212 Figure 1: Proposed LOWPAN NHC encoding for AH 214 o The first four bits in the NHC AH represent the NHC ID we define 215 for AH or ESP. These are set to 1101. 217 o If SPI = 00: the default SPI for the IEEE 802.15.4 network is used 218 and the SPI field is omitted. We set the default SPI value to 1. 219 This does not mean that all nodes use the same security 220 association (SA), but that every node has a single preferred SA, 221 identified by SPI 1. If SPI = 01: the least significant 8 bits of 222 the SPI are carried inline; the remaining 24 bits are elided. If 223 SPI = 10: the least significant 16 bits of the SPI are carried 224 inline; the remaining 16 bits are elided. If SPI = 11: All 32 225 bits of the SPI are carried inline. 227 o If SN = 00: the least significant 8 bits of sequence number are 228 carried inline. The remaining bits are elided. If SN = 01: the 229 least significant 16 bits of the SN are carried inline; the 230 remaining 16 bits are elided. If SN = 10: the least significant 231 24 bits of the SPI are carried inline; the remaining 8 bits are 232 elided. If SN = 11: All 32 bits of the SPI are carried inline. 234 The sequence number field in the AH header [RFC4302] contains a 235 value 1 for the first packet sent using a given Security 236 Association (SA), and it is incremented sequentially for the 237 subsequent packets. Note that by using 8-bit sequence number we do 238 not limit the size of sequence number to 255, but propose to use 8 239 bits for the sequence number prior to the transmission of the 240 256th packet on an SA. From the 2^8 to 2^(16-1) we propose to use 241 16-bit sequence number. Follow the same procedure for the 24-bit 242 sequence number as well. However, the sender and the receiver 243 sequence number counters must be reset prior to sending 2^32nd 244 packet as proposed in [RFC4302]. 246 Note that even when used in 6LoWPAN, AH calculates the ICV on the 247 uncompressed IP header, thus allowing authenticated communication 248 with Internet hosts. The minimum length of a standard AH, supporting 249 the mandatory HMAC-SHA1-96[RFC4835], consists of 12 bytes of header 250 fields plus 12 bytes of ICV. Figure 2 shows a sample NHC compressed 251 IP/UDP packet secured with AH. Using NHC encoding for the AH we can 252 reduce the AH header overhead from 24 bytes to 14 bytes: 1 byte of 253 next header, 1 byte of length, 2 bytes of Reserved field, 4 bytes of 254 SPI, and 2 bytes of sequence number. However, two additional bytes 255 are used to define NHC_EH and NHC_AH. Therefore, in the best case, 256 with AES-XCBC-MAC-96 [RFC3566] or HMAC-SHA1-96 ciphers (when 12 bytes 257 are used for ICV), applying NHC encoding for AH saves 8 bytes in each 258 data packet secured with IPsec AH. 260 | octet 1 | octet 2 | octet 1 | octet 1 | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | LOWPAN_IPHC | Hop Limit | Source Address| 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Source Address| Destination Address | LOWPAN_NHC_EH | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | LOWPAN_NHC_AH | Seq. No | | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 268 | | 269 + + 270 | Integrity Check Value-ICV (Variable) | 271 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | | LOWPAN_NHC_UDP|S Port | D Port| 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | | 275 + + 276 | UDP Payload (Variable) | 277 + + 278 | | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 Figure 2: A sample NHC compressed IP/UDP packet secured with AH. 283 4. LOWPAN_NHC for Encapsulated Security Payload (ESP) 285 The encryption in the IPsec ESP includes Payload Data, Padding, Pad 286 Length and Next Header fields in the ESP. Therefore, we cannot 287 compress these fields at the 6LoWPAN layer, and these fields are 288 always carried inline. Also, when using ESP the UDP header and 289 payload is also encrypted, hence cannot be compressed using NHC 290 encodings for UDP defined in the [RFC6282]. However, we can compress 291 the SPI and and sequence number (SN) fields in the ESP header. Figure 292 3 shows a proposed NHC encodings for the ESP that are explained 293 below. 295 0 1 2 3 4 5 6 7 296 +---+---+---+---+---+---+---+---+ 297 | 1 | 1 | 1 | 0 | SPI | SN | 298 +---+---+---+---+---+---+---+---+ 300 Figure 3: Proposed LOWPAN NHC encoding for ESP 302 o The first four bits in the NHC ESP represent the NHC ID we define 303 for ESP. These are set to 1001. 305 o The SPI and SN bits are encoded exactly the same way as in 306 Section 3 for the AH header. 308 In case of ESP we cannot skip the next header unless the end hosts 309 are able to execute 6LoWPAN compression/decompression and 310 encryption/decryption jointly. The nodes in the 6LoWPAN network make 311 their decision about the next header based on the NH value not the 312 actual header that is carried inline. In the case of ESP we MUST set 313 the NH value in the NHC_EH or GHC_EH to zero to indicate that the 314 full 8 bits of next header field are carried inline. 316 | octet 1 | octet 2 | octet 1 | octet 1 | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | LOWPAN_IPHC | Hop Limit | Source Address| 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Source Address| Destination Address | LOWPAN_NHC_EH | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | LOWPAN_NHC_ESP| Seq No | IV | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | IV [Variable Size] | Source Port | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Destination Port | Length | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Checksum | | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 330 | UDP Payload (Variable) | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Pad | Pad Length | Next Header | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | | 335 + + 336 | Integrity Check Value (Variable) | 337 + + 338 | | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 Figure 4: A sample NHC compressed IP/UDP packet secured with ESP. 343 With perfect block alignment, the minimum ESP overhead without 344 authentication is 10 bytes [RFC4303]. After optimal compression this 345 header overhead is reduced to 6 bytes, considering that two bytes are 346 used for NHC_EH and NHC_ESP. ESP also includes an IV which is equal 347 to the size of an encryption block; 16 bytes in the case of AES. If 348 authentication is enabled in the ESP, additional 12 bytes of ICV are 349 also required. Figure 4 shows an UDP/IP packet secured with 350 compressed ESP. 352 5. Implementation Considerations 354 We provide an open source implementation of the proposed compression 355 scheme in the Contiki operating system. The implementation is 356 released under BSD license and can be obtained through the 357 contikiprojects repository at the following URI: 358 svn://svn.code.sf.net/p/contikiprojects/code/sics.se/ipsec 360 6. Security Considerations 362 The compression scheme proposed in this document does not compromise 363 any security properties provided by IPsec AH and ESP. In particular, 364 the SN field is compressed in an on-demand fashion, as described in 365 Section 3. In order to overcome replay attacks, it is recommended 366 that the communication end-points should re-establish a security 367 association before the sequence number overflows. However, in 368 constrained environments, different implementations can decide the 369 overflow size; 2^8, 2^16, 2^24, or 2^32. This leads to a trade-off 370 between the overhead incurred by establishing a new security 371 association and by sending more bits of sequence number. The 372 Initialization Vector (IV) and Integrity Check Value (ICV) are also 373 not compressed to take full advantage of IPsec AH and ESP security. 375 7. IANA Considerations 377 [RFC6282] creates a new IANA registry for the LOWPAN_NHC header type 378 where the two slots, 1110101N and 1110110N, in LOWPAN_NHC for the 379 IPv6 Extension Header are unassigned. This document requests the 380 assignment of one of these two unassigned values, 1110101N, to IPsec 381 AH and ESP. This document also requests the assignment of following 382 contents: 384 1101XXYY: The 6LOWPAN_NHC encoding for the IPsec Authentication 385 Header. 387 1001XXYY: The 6LOWPAN_NHC encoding for the IPsec Encapsulated 388 Security Payload Header. 390 Capital letters in bit positions represent class-specific bit 391 assignments. The letters XX and YY represent SPI and SN 392 respectively, as defined in Section 3. 394 9. References 396 9.1. Normative References 398 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 399 Requirement Levels", BCP 14, RFC 2119, DOI 400 10.17487/RFC2119, March 1997, . 403 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 404 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 405 December 2005, . 407 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 408 10.17487/RFC4302, December 2005, . 411 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 412 RFC 4303, DOI 10.17487/RFC4303, December 2005, 413 . 415 [RFC6282] Hui, J., Ed., and P. Thubert, "Compression Format for IPv6 416 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 417 DOI 10.17487/RFC6282, September 2011, . 420 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 421 Requirements", RFC 6434, DOI 10.17487/RFC6434, December 422 2011, . 424 [RFC7400] C. Bormann , "6LoWPAN-GHC: Generic Header Compression for 425 IPv6 over Low-Power Wireless Personal Area Networks 426 (6LoWPANs)", RFC 7400, November 2014 428 9.2. Informative References 430 [draft-mglt-6lo-diet-esp-01] Migault, D., Guggemos, T., "Diet-ESP: a 431 flexible and compressed format for IPsec/ESP", August 432 2015, 435 [draft-mglt-6lo-aes-implicit-iv-01] Migault, D., Guggemos, T, 436 "Implicit IV for AES-CBC, AES-CTR, AES-CCM and AES-GCM", 437 August 2015, 440 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 441 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 442 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 443 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 444 Compression (ROHC): Framework and four profiles: RTP, UDP, 445 ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095, 446 July 2001, . 448 [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm 449 and Its Use With IPsec", RFC 3566, DOI 10.17487/RFC3566, 450 September 2003, . 452 [RFC5856] Ertekin, E., Jasani, R., Christou, C., and C. Bormann, 453 "Integration of Robust Header Compression over IPsec 454 Security Associations", RFC 5856, DOI 10.17487/RFC5856, 455 May 2010, . 457 [RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in 458 the Internet Key Exchange Version 2 (IKEv2)", RFC 7427, 459 DOI 10.17487/RFC7427, January 2015, . 462 [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for 463 IPv6 over Low-Power Wireless Personal Area Networks 464 (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 465 2014, . 467 Authors' Addresses 469 Shahid Raza 470 SICS Swedish ICT AB (SICS) 471 Isafjordsgatan 22, 16440 Kista 472 SWEDEN 474 Phone: +46-(0)768831797 475 EMail: shahid@sics.se 477 Simon Duquennoy 478 SICS Swedish ICT AB (SICS) 479 Isafjordsgatan 22, 16440 Kista 480 SWEDEN 482 Phone: +46-(0)702021482 483 EMail: simonduq@sics.se 485 Goeran Selander 486 Ericsson 487 Farogatan 6, 16480 Kista 488 SWEDEN 490 Email: goran.selander@ericsson.com