Internet DRAFT - draft-mglt-ipsecme-diet-esp-requirements
draft-mglt-ipsecme-diet-esp-requirements
IPSECME D. Migault, Ed.
Internet-Draft Orange
Intended status: Standards Track T. Guggemos, Ed.
Expires: January 3, 2015 Orange / LMU Munich
July 2, 2014
Diet-IPsec: Requirements for new IPsec/ESP protocols according to IoT
use cases
draft-mglt-ipsecme-diet-esp-requirements-00.txt
Abstract
IPsec/ESP is used to secure end-to-end communications. This document
lists the requirements Diet-ESP should meet to design IPsec/ESP for
IoT.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 3, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Migault & Guggemos Expires January 3, 2015 [Page 1]
Internet-Draft Diet-ESP July 2014
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Byte-Alignment . . . . . . . . . . . . . . . . . . . . . . . 3
5. Crypto-Suites . . . . . . . . . . . . . . . . . . . . . . . . 3
6. Compression . . . . . . . . . . . . . . . . . . . . . . . . . 4
7. Flexibility . . . . . . . . . . . . . . . . . . . . . . . . . 4
8. Code Complexity . . . . . . . . . . . . . . . . . . . . . . . 5
9. Usability . . . . . . . . . . . . . . . . . . . . . . . . . . 5
10. Compatibility with IP compression Protocols . . . . . . . . . 5
11. Compatibility with Standard ESP . . . . . . . . . . . . . . . 6
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
13. Security Considerations . . . . . . . . . . . . . . . . . . . 6
14. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 6
15. Normative References . . . . . . . . . . . . . . . . . . . . 6
Appendix A. Power Consumption Example . . . . . . . . . . . . . 7
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Introduction
IoT devices can carry all kind of small applications and some of them
require a secure communication. They can be life critical devices
(like a fire alarm), security critical devices (like home theft
alarms) and home automation devices. Smart grid is one application
where supplied electricity is based on information provided by each
home. Similarly, home temperature might be determined by servo-
controls based on information provided by temperature sensors.
Using IPsec [RFC4301] in the IoT world provides some advantages, such
as:
- IPsec secures application communications transparently as security
is handled at the IP layer. As such, applications do not need to
be modified to be secured.
- IPsec does not depend on the transport layer. As a result, the
security framework remains the same for all transport protocols,
like UDP or TCP.
Migault & Guggemos Expires January 3, 2015 [Page 2]
Internet-Draft Diet-ESP July 2014
- IPsec is well designed for sleeping nodes as there are no
sessions.
- IPsec defines security rules for the whole device, which outsource
the device security to a designated area. Therefore IPsec can be
seen like a tiny firewall securing all communication for an IoT
device.
A common disadvantage of IPsec is that it is mostly implemented in
the kernel, whereas application are in the user space. As there are
no real distinctions between these two spaces in IoT and that IoT
devices are mostly designed to a specific and unique task, this may
not be an issue anymore.
IoT constraints have not been considered in the early design of
IPsec. In fact IPsec has mainly been designed to secure
infrastructure. This document describes the requirements of Diet-
ESP, the declination of IPsec/ESP for IoT, enabling optimized IPsec/
ESP for the IoT.
3. Terminology
- IoT: Internet of Things
4. Byte-Alignment
IP extension headers MUST have 32 bit Byte-Alignment in IPv4 (section
3.1 of [RFC0791] - Padding description) and a 64 bit Byte-Alignment
in IPv6 (section 4 of [RFC2460]). As ESP [RFC4303] is such an
extension header, padding is mandatory to meet the alignment
constraint. This alignment is mostly caused by compiler and OS
requirements dealing with a 32 or 64 Bit processor. In the world of
IoT, processors and compilers are highly specialized and alignment is
often not necessary 32 Bit, but 16 or 8 bit.
R1: Diet-ESP SHOULD support Byte-Alignment that are different from
32 bits or 64 bits to prevent unnecessary padding.
R2: Each peer SHOULD be able to advertise and negotiate the Byte-
Alignment, used for Diet-ESP. This could be done for example
during the IKEv2 exchange.
5. Crypto-Suites
IEEE 802.15.4 defines AES-CCM*, that is AES-CTR and CBC-MAC, for link
layer security with upper layer key-management. Therefore it is
usually supported by hardware acceleration.
Migault & Guggemos Expires January 3, 2015 [Page 3]
Internet-Draft Diet-ESP July 2014
R3: Diet-ESP MUST support AES-CCM and MUST be able to take advantage
of AES-CCM hardware acceleration. Diet-ESP MAY support other
modes.
6. Compression
Sending data is very expensive regarding to power consumption, as
illustrated in Appendix A. Compression can be performed at different
layers. An encrypted ESP packet is an ESP Clear Text Data encrypted
and eventually concatenated with the Initialization Vector IV to form
an Encrypted Data Payload. This encrypted Data Payload is then
placed between an ESP Header and an ESP Trailer. Eventually, this
packet is authenticated with an ICV appended to ESP Trailer.
Compression can be performed at the ESP layer that is to say for the
fields of the ESP Header, ESP Trailer and the ICV. In addition, ESP
Clear Text Data may also be compressed with non ESP mechanisms like
ROHC [RFC3095], [RFC5225] for example, resulting in a smaller payload
to be encrypted. If ESP is using encryption, these mechanisms MUST
be performed over the ESP Clear Text Data before the ESP/Diet-ESP
processing as missing of encrypted fields make decryption harder.
R4: Diet-ESP SHOULD be able to compress/remove all static ESP fields
(SPI, Next Header) as well as the other fields SN, PADDING, Pad
Length or ICV.
R5: Diet-ESP SHOULD also allow compression mechanisms before the
IPsec/ESP processing.
R6: Diet-ESP SHOULD NOT allow compressed fields, not aligned to 1
byte in order to prevent alignment complexity. In other words,
Diet-ESP do not consider finer granularity than the byte.
7. Flexibility
Diet-ESP can compress some of the ESP fields as Diet-ESP is optimized
for IoT. Which field may be compressed or not, depends on the
scenario and current and future scenarios cannot been foreseen. In
fact Diet-ESP and ESP differs in the following point: ESP has been
designed so that any ESP secured communication on any device is able
to communicate with another. This means that ESP has been designed
to work for large Security Gateway under thousands of connections, as
well as devices with a single ESP communication. Because, ESP has
been designed not to introduce any protocol limitations, counters and
identifiers may become over-sized in an IoT context.
R7: The developer SHOULD be able to specify the maximum level of
compression.
Migault & Guggemos Expires January 3, 2015 [Page 4]
Internet-Draft Diet-ESP July 2014
R8: Diet-ESP SHOULD be able to compress any field independent from
another.
R9: Diet-ESP SHOULD be able to define different compression method,
when appropriated.
R10: Each peer SHOULD be able to announce and negotiate the different
compressed fields as well as the used method.
8. Code Complexity
IoT devices have limited space for memory and storage.
R11: Diet-ESP SHOULD be able to be implemented with minimal
complexity. More especially, Diet-ESP SHOULD consider small
implementation that implement only a subset of all Diet-ESP
capabilities without requiring involving standard ESP, specific
compressors and de-compressors.
9. Usability
Application Developer usually do not want to take care about the
underlying protocols and security. Standard ESP addresses the goal
by providing a framework that secures communication in any
circumstances. Although application developers for IoT are expected
to pay more attention to the device security and system requirements,
we do not expect them to be security aware developers. As a result,
some default parameters that provides a standard secure framework for
most cases should be provided. This is of course performed at the
expense of some optimization, but it makes possible for application
developers to have "standard" security and standard Diet-ESP
compression by setting a single bit "DIET-ESP secure". More advanced
developers will be able to tune the security parameters for their
needs.
R12: Diet-ESP SHOULD provide default configurations, which can be
easily set up by a developer.
10. Compatibility with IP compression Protocols
There are different protocols providing IP layer compression for
constraint devices like IoT (6LoWPAN [RFC6282] ) or Mobile Devices
(ROHC).
R13: Diet-ESP SHOULD be able to interact with IP compression
protocols. More especially, this means that a Diet-ESP packet
SHOULD be able to be sent in a ROHC or a 6LowPAN packet. Diet-
ESP document should explicitly detail how this can be achieved.
Migault & Guggemos Expires January 3, 2015 [Page 5]
Internet-Draft Diet-ESP July 2014
R14: Diet-ESP SHOULD also detail how compression of layers above IP
with ROHC or 6LowPAN is compatible with Diet-ESP.
11. Compatibility with Standard ESP
IPsec/ESP is widely deployed by different vendors on different
machines. IoT devices MAY have to communicate with Standard ESP
implementations.
R15: Diet-ESP SHOULD be able to interact with Standard ESP
implementations on a single platform.
R16: Diet-ESP SHOULD be able to communicate with Standard ESP.
12. IANA Considerations
There are no IANA consideration for this document.
13. Security Considerations
14. Acknowledgment
The current draft represents the work of Tobias Guggemos while his
internship at Orange [GUGG14].
Diet-ESP is a joint work between Orange and Ludwig-Maximilians-
Universitaet Munich. We thank Daniel Palomares and Carsten Bormann
for their useful remarks, comments and guidance.
15. Normative References
[GUGG14] Guggemos, TG., "Diet-ESP: Applying IP-Layer Security in
Constrained Environments (Masterthesis)", September 2014.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
Migault & Guggemos Expires January 3, 2015 [Page 6]
Internet-Draft Diet-ESP July 2014
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le,
K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
Compression (ROHC): Framework and four profiles: RTP, UDP,
ESP, and uncompressed", RFC 3095, July 2001.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression
Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and
UDP-Lite", RFC 5225, April 2008.
[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
September 2011.
Appendix A. Power Consumption Example
IoT devices are often installed once and left untouched for a couple
of years. Furthermore they often do not have a power supply
wherefore they have to be fueled by a battery. This battery may have
a limited capacity and maybe not replaceable. Therefore, power can
be a limited resource in the world of IoT. Table 1 and Table 2 shows
the costs for transmitting data and computation
Note these data are mentioned here with an illustrative purpose, for
our motivations. These data may vary from one device to another, and
may change over time.
+-------------------------+---------------------+
| | power consumption |
+-------------------------+---------------------+
| low-power radios < 10mW | (100nJ - 1uJ) / bit |
+-------------------------+---------------------+
Table 1: Power consumption for data transmission.
Migault & Guggemos Expires January 3, 2015 [Page 7]
Internet-Draft Diet-ESP July 2014
+----------------------------------+---------------------+
| | power consumption |
+----------------------------------+---------------------+
| energy-efficient microprocessors | 0.5nJ / instruction |
| high-performance microprocessors | 200nJ / instruction |
+----------------------------------+---------------------+
Table 2: Power consumption for computation.
From these tables, sending 1 bit costs as much as 10-100 instructions
in the CPU. Therefore there is a high interest to reduce the number
of bits sent on the wire, even if it generates costs for computation.
Appendix B. Document Change Log
[draft-mglt-ipsecme-diet-ipsec-requirements-00.txt]: First version
published.
Authors' Addresses
Daniel Migault (editor)
Orange
38 rue du General Leclerc
92794 Issy-les-Moulineaux Cedex 9
France
Phone: +33 1 45 29 60 52
Email: daniel.migault@orange.com
Tobias Guggemos (editor)
Orange / LMU Munich
Am Osteroesch 9
87637 Seeg, Bavaria
Germany
Email: tobias.guggemos@gmail.com
Migault & Guggemos Expires January 3, 2015 [Page 8]