idnits 2.17.1 draft-mglt-6lo-diet-esp-requirements-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 (July 8, 2016) is 2842 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) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lo D. Migault 3 Internet-Draft Ericsson 4 Intended status: Standards Track T. Guggemos 5 Expires: January 9, 2017 LMU Munich 6 C. Bormann 7 Universitaet Bremen TZI 8 July 8, 2016 10 Requirements for Diet-ESP the IPsec/ESP protocol for IoT 11 draft-mglt-6lo-diet-esp-requirements-02.txt 13 Abstract 15 IPsec/ESP is used to secure end-to-end communications. This document 16 lists the requirements Diet-ESP should meet to design IPsec/ESP for 17 IoT. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 9, 2017. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 3 57 5. Byte-Alignment . . . . . . . . . . . . . . . . . . . . . . . 4 58 6. Crypto-Suites . . . . . . . . . . . . . . . . . . . . . . . . 4 59 7. Compression . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 8. Flexibility . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 9. Code Complexity . . . . . . . . . . . . . . . . . . . . . . . 5 62 10. Usability . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 11. Compatibility with IP compression Protocols . . . . . . . . . 6 64 12. Compatibility with Standard ESP . . . . . . . . . . . . . . . 6 65 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 66 14. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 15. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 7 68 16. Normative References . . . . . . . . . . . . . . . . . . . . 7 69 Appendix A. Power Consumption Example . . . . . . . . . . . . . 8 70 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Requirements notation 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in [RFC2119]. 79 2. Introduction 81 IoT devices can carry all kind of small applications and some of them 82 require a secure communication. They can be life critical devices 83 (like a fire alarm), security critical devices (like home theft 84 alarms) and home automation devices. Smart grid is one application 85 where supplied electricity is based on information provided by each 86 home. Similarly, home temperature might be determined by servo- 87 controls based on information provided by temperature sensors. 89 Using IPsec [RFC4301] in the IoT world provides some advantages, such 90 as: 92 - IPsec secures application communications transparently as security 93 is handled at the IP layer. As such, applications do not need to 94 be modified to be secured. 96 - IPsec does not depend on the transport layer. As a result, the 97 security framework remains the same for all transport protocols, 98 like UDP or TCP. 100 - IPsec is well designed for sleeping nodes as there are no 101 sessions. 103 - IPsec defines security rules for the whole device, which outsource 104 the device security to a designated area. Therefore IPsec can be 105 seen like a tiny firewall securing all communication for an IoT 106 device. 108 IPsec is mostly implemented in the kernel, whereas application are in 109 the user space. This is often considered as a disadvantage for 110 IPsec. However, as there are no real distinctions between these two 111 spaces in IoT and that IoT devices are mostly designed to a specific 112 and unique task, this may not be an issue anymore. 114 IoT constraints have not been considered in the early design of 115 IPsec. In fact IPsec has mainly been designed to secure 116 infrastructure. This document describes the requirements of Diet- 117 ESP, the declination of IPsec/ESP for IoT, enabling optimized IPsec/ 118 ESP for the IoT. 120 3. Terminology 122 - IoT: Internet of Things 124 4. Protocol Design 126 Diet-ESP is based on IPsec/ESP and is adapted for IoT. Adaptation to 127 IoT scenarios must not be at the expense of security, and the 128 security evaluation of Diet-ESP should benefit as far as possible 129 from the long experience of already existing protocols. As a result 130 the protocol design requirements for Diet-ESP are as follows: 132 R1: Diet-ESP MUST benefit from the IPsec/ESP security. 134 R2: Diet-ESP MUST NOT introduce vulnerabilities over IPsec/ESP. 135 This means that at some points IPsec/ESP is implemented. A 136 foreseen way to reach that goal is to associate IPsec/ESP with 137 compressors/decompressors. 139 R3: Diet-ESP SHOULD rely on existing protocol or frameworks. 141 5. Byte-Alignment 143 IP extension headers MUST have 32 bit Byte-Alignment in IPv4 (section 144 3.1 of [RFC0791] - Padding description) and a 64 bit Byte-Alignment 145 in IPv6 (section 4 of [RFC2460]). As ESP [RFC4303] is such an 146 extension header, padding is mandatory to meet the alignment 147 constraint. This alignment is mostly caused by compiler and OS 148 requirements dealing with a 32 or 64 Bit processor. In the world of 149 IoT, processors and compilers are highly specialized and alignment is 150 often not necessary 32 Bit, but 16 or 8 bit. As a result, the byte- 151 alignment requirement is as follows: 153 R4: Diet-ESP MUST support Byte-Alignment that are different from 32 154 bits or 64 bits to prevent unnecessary padding. 156 R5: Each peer MUST be able to advertise and negotiate the Byte- 157 Alignment, used for Diet-ESP. This could be done for example 158 during the IKEv2 exchange. 160 6. Crypto-Suites 162 IEEE 802.15.4 defines AES-CCM*, that is AES-CTR and CBC-MAC, for link 163 layer security with upper layer key-management. Therefore it is 164 usually supported by hardware acceleration. This leads to the 165 following crypto-suite requirement: 167 R6: Diet-ESP MUST support AES-CCM and MUST be able to take advantage 168 of AES-CCM hardware acceleration. Diet-ESP MAY support other 169 modes. 171 7. Compression 173 Sending data is very expensive regarding to power consumption, as 174 illustrated in Appendix A. Compression can be performed at different 175 layers. An encrypted ESP packet is an ESP Clear Text Data encrypted 176 and eventually concatenated with the Initialization Vector IV to form 177 an Encrypted Data Payload. This encrypted Data Payload is then 178 placed between an ESP Header and an ESP Trailer. Eventually, this 179 packet is authenticated with an ICV appended to ESP Trailer. 180 Compression can be performed at the ESP layer that is to say for the 181 fields of the ESP Header, ESP Trailer and the ICV. In addition, ESP 182 Clear Text Data may also be compressed with non ESP mechanisms like 183 ROHC [RFC3095], [RFC5225] for example, resulting in a smaller payload 184 to be encrypted. If ESP is using encryption, these mechanisms MUST 185 be performed over the ESP Clear Text Data before the ESP/Diet-ESP 186 processing as missing of encrypted fields make decryption harder. As 187 a result, compression requirements are as follows: 189 R7: Diet-ESP MUST be able to compress/remove all static ESP fields 190 (SPI, Next Header) as well as the other fields SN, Padding, Pad 191 Length or ICV. 193 R8: Diet-ESP SHOULD also allow compression mechanisms before the 194 IPsec/ESP processing. 196 R9: Diet-ESP SHOULD NOT allow compressed fields, not aligned to 1 197 byte in order to prevent alignment complexity. In other words, 198 Diet-ESP do not consider finer granularity than the byte. 200 8. Flexibility 202 Diet-ESP can compress some of the ESP fields as Diet-ESP is optimized 203 for IoT. Which field may be compressed or not, depends on the 204 scenario and current and future scenarios cannot been foreseen. As a 205 result, the flexibility requirements are as follows: 207 R10: Diet-ESP MUST be able to compress any field independently from 208 another. 210 R11: Diet-ESP SHOULD provide different ways to compress a single 211 field, so the most appropriated way can be agreed between the 212 peers. 214 R12: Each peer MUST be able to announce and negotiate the different 215 compressed fields as well as the used method. 217 In fact Diet-ESP and ESP differs in the following point: ESP has been 218 designed so that any ESP secured communication so any device is able 219 to communicate with another. This means that ESP has been designed 220 to work for large Security Gateway under thousands of connections, as 221 well as devices with a single ESP communication. Because, ESP has 222 been designed not to introduce any protocol limitations, counters and 223 identifiers may become over-sized in an IoT context. 225 9. Code Complexity 227 IoT devices have limited space for memory and storage, which leads to 228 the following requirement. 230 R13: Diet-ESP MUST be able to be implemented with minimal complexity. 231 More especially, Diet-ESP MUST consider small implementation 232 that implement only a subset of all Diet-ESP capabilities 233 without requiring involving standard ESP, specific compressors 234 and de-compressors. 236 10. Usability 238 Application Developer usually do not want to take care about the 239 underlying protocols and security. In addition, the security 240 configuration should remain feasible by a standard software 241 developer. The usability requirements regarding Diet-ESP are as 242 follows: 244 R14: Diet-ESP MUST remain independent from the application. 246 R15: Diet-ESP MUST detail for each field how compression impacts the 247 security of the device. Although the creation of profiles is 248 out of scope of Diet-ESP, it is expected that profiles may be 249 defined latter by the usage. 251 11. Compatibility with IP compression Protocols 253 There are different protocols providing IP layer compression for 254 constraint devices like IoT (6LoWPAN [RFC6282] ) or Mobile Devices 255 (ROHC). The requirements regarding interactions of Diet-ESP and 256 additional compression protocols are as follows: 258 R16: Diet-ESP MUST be able to interact with IP compression protocols. 259 More especially, this means that a Diet-ESP packet MUST be able 260 to be sent in a ROHC or a 6LowPAN packet. Diet-ESP document 261 should explicitly detail how this can be achieved. 263 R17: Diet-ESP MUST also detail how compression of layers above IP 264 with ROHC or 6LowPAN is compatible with Diet-ESP. 266 12. Compatibility with Standard ESP 268 IPsec/ESP is widely deployed by different vendors on different 269 machines. IoT devices MAY have to communicate with Standard ESP 270 implementations. The ESP compatibility requirements is as follows: 272 R18: Diet-ESP MUST be able to communicate with Standard ESP. 274 13. IANA Considerations 276 There are no IANA consideration for this document. 278 14. Security Considerations 280 Security Considerations have been expressed as one of the 281 requirement. 283 15. Acknowledgment 285 The current work on Diet-ESP results from exchange and cooperation 286 between Orange, Ludwig-Maximilians-Universitaet Munich, Universite 287 Pierre et Marie Curie. We thank Daniel Palomares and Carsten Bormann 288 for their useful remarks, comments and guidances on the design. We 289 thank Sylvain Killian for implementing an open source Diet-ESP on 290 Contiki and testing it on the FIT IoT-LAB [fit-iot-lab] funded by the 291 French Ministry of Higher Education and Research. We thank the IoT- 292 Lab Team and the INRIA for maintaining the FIT IoT-LAB platform and 293 for providing feed backs in an efficient way. 295 16. Normative References 297 [fit-iot-lab] 298 "Future Internet of Things (FIT) IoT-LAB", 299 . 301 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 302 DOI 10.17487/RFC0791, September 1981, 303 . 305 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 306 Requirement Levels", BCP 14, RFC 2119, 307 DOI 10.17487/RFC2119, March 1997, 308 . 310 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 311 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 312 December 1998, . 314 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 315 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 316 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 317 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 318 Compression (ROHC): Framework and four profiles: RTP, UDP, 319 ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095, 320 July 2001, . 322 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 323 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 324 December 2005, . 326 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 327 RFC 4303, DOI 10.17487/RFC4303, December 2005, 328 . 330 [RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression 331 Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and 332 UDP-Lite", RFC 5225, DOI 10.17487/RFC5225, April 2008, 333 . 335 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 336 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 337 DOI 10.17487/RFC6282, September 2011, 338 . 340 Appendix A. Power Consumption Example 342 IoT devices are often installed once and left untouched for a couple 343 of years. Furthermore they often do not have a power supply 344 wherefore they have to be fueled by a battery. This battery may have 345 a limited capacity and maybe not replaceable. Therefore, power can 346 be a limited resource in the world of IoT. Table 1 and Table 2 shows 347 the costs for transmitting data and computation 349 Note these data are mentioned here with an illustrative purpose, for 350 our motivations. These data may vary from one device to another, and 351 may change over time. 353 +-------------------------+---------------------+ 354 | | power consumption | 355 +-------------------------+---------------------+ 356 | low-power radios < 10mW | (100nJ - 1uJ) / bit | 357 +-------------------------+---------------------+ 359 Table 1: Power consumption for data transmission. 361 +----------------------------------+---------------------+ 362 | | power consumption | 363 +----------------------------------+---------------------+ 364 | energy-efficient microprocessors | 0.5nJ / instruction | 365 | high-performance microprocessors | 200nJ / instruction | 366 +----------------------------------+---------------------+ 368 Table 2: Power consumption for computation. 370 From these tables, sending 1 bit costs as much as 10-100 instructions 371 in the CPU. Therefore there is a high interest to reduce the number 372 of bits sent on the wire, even if it generates costs for computation. 374 Appendix B. Document Change Log 376 [draft-mglt-6lo-diet-esp-requirements-01.txt]: Changing affiliation. 378 [draft-mglt-6lo-diet-esp-requirements-00.txt]: Published: Minor re- 379 wordings 381 [draft-mglt-ipsecme-diet-ipsec-requirements-00.txt]: First version 382 published. 384 Authors' Addresses 386 Daniel Migault 387 Ericsson 388 8400 boulevard Decarie 389 Montreal, QC H4P 2N2 390 Canada 392 Email: daniel.migault@ericsson.com 394 Tobias Guggemos 395 LMU Munich 396 Am Osteroesch 9 397 87637 Seeg, Bavaria 398 Germany 400 Email: tobias.guggemos@gmail.com 402 Carsten Bormann 403 Universitaet Bremen TZI 404 Postfach 330440 405 Bremen D-28359 406 Germany 408 Phone: +49-421-218-63921 409 Email: cabo@tzi.org