idnits 2.17.1 draft-mglt-ipsecme-diet-esp-requirements-00.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 2, 2014) is 3583 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'GUGG14' ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPSECME D. Migault, Ed. 3 Internet-Draft Orange 4 Intended status: Standards Track T. Guggemos, Ed. 5 Expires: January 3, 2015 Orange / LMU Munich 6 July 2, 2014 8 Diet-IPsec: Requirements for new IPsec/ESP protocols according to IoT 9 use cases 10 draft-mglt-ipsecme-diet-esp-requirements-00.txt 12 Abstract 14 IPsec/ESP is used to secure end-to-end communications. This document 15 lists the requirements Diet-ESP should meet to design IPsec/ESP for 16 IoT. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 3, 2015. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 53 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Byte-Alignment . . . . . . . . . . . . . . . . . . . . . . . 3 56 5. Crypto-Suites . . . . . . . . . . . . . . . . . . . . . . . . 3 57 6. Compression . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 7. Flexibility . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 8. Code Complexity . . . . . . . . . . . . . . . . . . . . . . . 5 60 9. Usability . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 10. Compatibility with IP compression Protocols . . . . . . . . . 5 62 11. Compatibility with Standard ESP . . . . . . . . . . . . . . . 6 63 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 13. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 14. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 6 66 15. Normative References . . . . . . . . . . . . . . . . . . . . 6 67 Appendix A. Power Consumption Example . . . . . . . . . . . . . 7 68 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 8 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Requirements notation 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in [RFC2119]. 77 2. Introduction 79 IoT devices can carry all kind of small applications and some of them 80 require a secure communication. They can be life critical devices 81 (like a fire alarm), security critical devices (like home theft 82 alarms) and home automation devices. Smart grid is one application 83 where supplied electricity is based on information provided by each 84 home. Similarly, home temperature might be determined by servo- 85 controls based on information provided by temperature sensors. 87 Using IPsec [RFC4301] in the IoT world provides some advantages, such 88 as: 90 - IPsec secures application communications transparently as security 91 is handled at the IP layer. As such, applications do not need to 92 be modified to be secured. 94 - IPsec does not depend on the transport layer. As a result, the 95 security framework remains the same for all transport protocols, 96 like UDP or TCP. 98 - IPsec is well designed for sleeping nodes as there are no 99 sessions. 101 - IPsec defines security rules for the whole device, which outsource 102 the device security to a designated area. Therefore IPsec can be 103 seen like a tiny firewall securing all communication for an IoT 104 device. 106 A common disadvantage of IPsec is that it is mostly implemented in 107 the kernel, whereas application are in the user space. As there are 108 no real distinctions between these two spaces in IoT and that IoT 109 devices are mostly designed to a specific and unique task, this may 110 not be an issue anymore. 112 IoT constraints have not been considered in the early design of 113 IPsec. In fact IPsec has mainly been designed to secure 114 infrastructure. This document describes the requirements of Diet- 115 ESP, the declination of IPsec/ESP for IoT, enabling optimized IPsec/ 116 ESP for the IoT. 118 3. Terminology 120 - IoT: Internet of Things 122 4. Byte-Alignment 124 IP extension headers MUST have 32 bit Byte-Alignment in IPv4 (section 125 3.1 of [RFC0791] - Padding description) and a 64 bit Byte-Alignment 126 in IPv6 (section 4 of [RFC2460]). As ESP [RFC4303] is such an 127 extension header, padding is mandatory to meet the alignment 128 constraint. This alignment is mostly caused by compiler and OS 129 requirements dealing with a 32 or 64 Bit processor. In the world of 130 IoT, processors and compilers are highly specialized and alignment is 131 often not necessary 32 Bit, but 16 or 8 bit. 133 R1: Diet-ESP SHOULD support Byte-Alignment that are different from 134 32 bits or 64 bits to prevent unnecessary padding. 136 R2: Each peer SHOULD be able to advertise and negotiate the Byte- 137 Alignment, used for Diet-ESP. This could be done for example 138 during the IKEv2 exchange. 140 5. Crypto-Suites 142 IEEE 802.15.4 defines AES-CCM*, that is AES-CTR and CBC-MAC, for link 143 layer security with upper layer key-management. Therefore it is 144 usually supported by hardware acceleration. 146 R3: Diet-ESP MUST support AES-CCM and MUST be able to take advantage 147 of AES-CCM hardware acceleration. Diet-ESP MAY support other 148 modes. 150 6. Compression 152 Sending data is very expensive regarding to power consumption, as 153 illustrated in Appendix A. Compression can be performed at different 154 layers. An encrypted ESP packet is an ESP Clear Text Data encrypted 155 and eventually concatenated with the Initialization Vector IV to form 156 an Encrypted Data Payload. This encrypted Data Payload is then 157 placed between an ESP Header and an ESP Trailer. Eventually, this 158 packet is authenticated with an ICV appended to ESP Trailer. 159 Compression can be performed at the ESP layer that is to say for the 160 fields of the ESP Header, ESP Trailer and the ICV. In addition, ESP 161 Clear Text Data may also be compressed with non ESP mechanisms like 162 ROHC [RFC3095], [RFC5225] for example, resulting in a smaller payload 163 to be encrypted. If ESP is using encryption, these mechanisms MUST 164 be performed over the ESP Clear Text Data before the ESP/Diet-ESP 165 processing as missing of encrypted fields make decryption harder. 167 R4: Diet-ESP SHOULD be able to compress/remove all static ESP fields 168 (SPI, Next Header) as well as the other fields SN, PADDING, Pad 169 Length or ICV. 171 R5: Diet-ESP SHOULD also allow compression mechanisms before the 172 IPsec/ESP processing. 174 R6: Diet-ESP SHOULD NOT allow compressed fields, not aligned to 1 175 byte in order to prevent alignment complexity. In other words, 176 Diet-ESP do not consider finer granularity than the byte. 178 7. Flexibility 180 Diet-ESP can compress some of the ESP fields as Diet-ESP is optimized 181 for IoT. Which field may be compressed or not, depends on the 182 scenario and current and future scenarios cannot been foreseen. In 183 fact Diet-ESP and ESP differs in the following point: ESP has been 184 designed so that any ESP secured communication on any device is able 185 to communicate with another. This means that ESP has been designed 186 to work for large Security Gateway under thousands of connections, as 187 well as devices with a single ESP communication. Because, ESP has 188 been designed not to introduce any protocol limitations, counters and 189 identifiers may become over-sized in an IoT context. 191 R7: The developer SHOULD be able to specify the maximum level of 192 compression. 194 R8: Diet-ESP SHOULD be able to compress any field independent from 195 another. 197 R9: Diet-ESP SHOULD be able to define different compression method, 198 when appropriated. 200 R10: Each peer SHOULD be able to announce and negotiate the different 201 compressed fields as well as the used method. 203 8. Code Complexity 205 IoT devices have limited space for memory and storage. 207 R11: Diet-ESP SHOULD be able to be implemented with minimal 208 complexity. More especially, Diet-ESP SHOULD consider small 209 implementation that implement only a subset of all Diet-ESP 210 capabilities without requiring involving standard ESP, specific 211 compressors and de-compressors. 213 9. Usability 215 Application Developer usually do not want to take care about the 216 underlying protocols and security. Standard ESP addresses the goal 217 by providing a framework that secures communication in any 218 circumstances. Although application developers for IoT are expected 219 to pay more attention to the device security and system requirements, 220 we do not expect them to be security aware developers. As a result, 221 some default parameters that provides a standard secure framework for 222 most cases should be provided. This is of course performed at the 223 expense of some optimization, but it makes possible for application 224 developers to have "standard" security and standard Diet-ESP 225 compression by setting a single bit "DIET-ESP secure". More advanced 226 developers will be able to tune the security parameters for their 227 needs. 229 R12: Diet-ESP SHOULD provide default configurations, which can be 230 easily set up by a developer. 232 10. Compatibility with IP compression Protocols 234 There are different protocols providing IP layer compression for 235 constraint devices like IoT (6LoWPAN [RFC6282] ) or Mobile Devices 236 (ROHC). 238 R13: Diet-ESP SHOULD be able to interact with IP compression 239 protocols. More especially, this means that a Diet-ESP packet 240 SHOULD be able to be sent in a ROHC or a 6LowPAN packet. Diet- 241 ESP document should explicitly detail how this can be achieved. 243 R14: Diet-ESP SHOULD also detail how compression of layers above IP 244 with ROHC or 6LowPAN is compatible with Diet-ESP. 246 11. Compatibility with Standard ESP 248 IPsec/ESP is widely deployed by different vendors on different 249 machines. IoT devices MAY have to communicate with Standard ESP 250 implementations. 252 R15: Diet-ESP SHOULD be able to interact with Standard ESP 253 implementations on a single platform. 255 R16: Diet-ESP SHOULD be able to communicate with Standard ESP. 257 12. IANA Considerations 259 There are no IANA consideration for this document. 261 13. Security Considerations 263 14. Acknowledgment 265 The current draft represents the work of Tobias Guggemos while his 266 internship at Orange [GUGG14]. 268 Diet-ESP is a joint work between Orange and Ludwig-Maximilians- 269 Universitaet Munich. We thank Daniel Palomares and Carsten Bormann 270 for their useful remarks, comments and guidance. 272 15. Normative References 274 [GUGG14] Guggemos, TG., "Diet-ESP: Applying IP-Layer Security in 275 Constrained Environments (Masterthesis)", September 2014. 277 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 278 1981. 280 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 281 Requirement Levels", BCP 14, RFC 2119, March 1997. 283 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 284 (IPv6) Specification", RFC 2460, December 1998. 286 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 287 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 288 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 289 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 290 Compression (ROHC): Framework and four profiles: RTP, UDP, 291 ESP, and uncompressed", RFC 3095, July 2001. 293 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 294 Internet Protocol", RFC 4301, December 2005. 296 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 297 4303, December 2005. 299 [RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression 300 Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and 301 UDP-Lite", RFC 5225, April 2008. 303 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 304 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 305 September 2011. 307 Appendix A. Power Consumption Example 309 IoT devices are often installed once and left untouched for a couple 310 of years. Furthermore they often do not have a power supply 311 wherefore they have to be fueled by a battery. This battery may have 312 a limited capacity and maybe not replaceable. Therefore, power can 313 be a limited resource in the world of IoT. Table 1 and Table 2 shows 314 the costs for transmitting data and computation 316 Note these data are mentioned here with an illustrative purpose, for 317 our motivations. These data may vary from one device to another, and 318 may change over time. 320 +-------------------------+---------------------+ 321 | | power consumption | 322 +-------------------------+---------------------+ 323 | low-power radios < 10mW | (100nJ - 1uJ) / bit | 324 +-------------------------+---------------------+ 326 Table 1: Power consumption for data transmission. 328 +----------------------------------+---------------------+ 329 | | power consumption | 330 +----------------------------------+---------------------+ 331 | energy-efficient microprocessors | 0.5nJ / instruction | 332 | high-performance microprocessors | 200nJ / instruction | 333 +----------------------------------+---------------------+ 335 Table 2: Power consumption for computation. 337 From these tables, sending 1 bit costs as much as 10-100 instructions 338 in the CPU. Therefore there is a high interest to reduce the number 339 of bits sent on the wire, even if it generates costs for computation. 341 Appendix B. Document Change Log 343 [draft-mglt-ipsecme-diet-ipsec-requirements-00.txt]: First version 344 published. 346 Authors' Addresses 348 Daniel Migault (editor) 349 Orange 350 38 rue du General Leclerc 351 92794 Issy-les-Moulineaux Cedex 9 352 France 354 Phone: +33 1 45 29 60 52 355 Email: daniel.migault@orange.com 357 Tobias Guggemos (editor) 358 Orange / LMU Munich 359 Am Osteroesch 9 360 87637 Seeg, Bavaria 361 Germany 363 Email: tobias.guggemos@gmail.com