Diet-ESP: a flexible and compressed format for IPsec/ESP
draft-mglt-ipsecme-diet-esp-01

The information below is for an old version of the document
Document Type Expired Internet-Draft (individual)
Last updated 2015-01-03 (latest revision 2014-07-02)
Stream (None)
Intended RFC status (None)
Formats
Expired & archived
plain text pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at
https://www.ietf.org/archive/id/draft-mglt-ipsecme-diet-esp-01.txt

Abstract

IPsec/ESP secure every single IP packets exchanged between two nodes. This makes security transparent to the applications, as opposed to TLS or DTLS for example. IPsec/ESP has not widely been used to secure application because IPsec is implemented in the kernel space, and IPsec/ESP security rules are defined on the device -- similarly to firewall. In addition, IPsec/ESP introduces network overhead on an IP packet basis, as opposed as TLS/DTLS that introduces network overhead on an UDP or TCP segment basis. This mostly impacts devices that do not perform IP fragmentation. Such drawbacks are not anymore valid for IoT, and the IPsec/ESP may even better fits IoT usage and security requirements. IoT device are usually hardware dedicated for a given task or a given application which makes Kernel / user land split less significant. IoT devices send data that is most likely expected to fit in a single IP packet. Eventually, configuring IPsec/ESP security rules provides the ability to enforce the security of the device, as security is not handled on a per-application basis. Then the database structure of the IPsec/ ESP security policies perfectly match sleeping nodes. This document defines Diet-ESP that adapts IPsec/ESP for IoT. The goal of Diet-ESP is to reduce the size of the IPsec/ESP packet sent on the wire. As a result Diet-ESP is expected to compress traditional IPsec/ESP packet without impacting the security provided by IPsec/ESP.

Authors

Daniel Migault (daniel.migault@orange.com)
Tobias Guggemos (tobias.guggemos@gmail.com)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)