Subject: Re: [IPsec] [Dtls-iot] IPsec/Diet-ESP for IoT and Minimal ESP

From: Daniel Migault <[email-masked]>
Date: Tue, 18 Feb 2014 14:22:24 +0100

Hi Hannes,

So yes I agree, minimal ESP better fits lwig whereas diet-esp better
fits ipsecme.

Orange already operates networks of smart communicating objects,
either directly or through its joint-venture m2o City. Orange is
committed to contributing to the advent of the Internet of Things.
Dominique is maybe the best entry point to know more on our activities
with IoT. We are currently looking at using IPsec and compare it with
TLS as a research topic.

Currently Tobi implemented Diet-ESP on Python and for contiki. As soon
as we have published tests we will provide the code as opensource.

BR,
Daniel

On Fri, Jan 31, 2014 at 9:12 PM, Hannes Tschofenig
<[email-masked]> wrote:
> Hi Daniel,
>
> the charter of the DICE working group considers IPsec/IKEv2 outside the
> scope. The charter also requires the work to be a profile rather than a
> new design. A profile is just a subset of the functionality of the
> existing protocol that would still interoperate with the full version.
>
> On the content: Do you plan to use the work within your company / in
> products? I have not ran into someone who was planning to use IPsec in
> the IoT context but I am happy to learn about new deployments.
>
> Ciao
> Hannes
>
>
> On 01/31/2014 02:48 PM, Daniel Migault wrote:
>> Hi,
>>
>> Please find the two drafts we have just posted. They are about
>> IPsec/ESP minimal implementation and Diet-ESP designed for IoT.
>>
>> Comment are welcome!
>>
>> Best Regards,
>> Daniel
>>
>>
>> Name:        draft-mglt-dice-diet-esp
>> Revision:    00
>> Title:        Diet-ESP: a flexible and compressed format for IPsec/ESP
>> Document date:    2014-01-31
>> Group:        Individual Submission
>> Pages:        21
>> URL:http://www.ietf.org/internet-drafts/draft-mglt-dice-diet-esp-00.txt
>> Status:https://datatracker.ietf.org/doc/draft-mglt-dice-diet-esp/
>> Htmlized:http://tools.ietf.org/html/draft-mglt-dice-diet-esp-00
>>
>>
>> Abstract:
>>    IPsec/ESP has been designed to secure IP packets exchanged between
>>    two nodes.  IPsec implements security at the IP layer which makes
>>    security transparent to the applications, as opposed to TLS or DTLS
>>    that requires application to implement TLS/DTLS.  As a result, IPsec
>>    enable to define the security rules in a similar way one establishes
>>    firewall rules.
>>
>>    One of the IPsec's drawbacks is that implementing security on a per
>>    packet basis adds overhead to each IP packet.  Considering IoT
>>    devices, the data transmitted over an IP packet is expected to be
>>    rather small, and the cost of sending extra bytes is so high that
>>    IPsec/ESP can hardly be used for IoT as it is currently defined in
>>    RFC 4303.
>>
>>    This document defines Diet-ESP, a protocol that compress and reduce
>>    the ESP overhead of IPsec/ESP so that it can fit security and energy
>>    efficient IoT requirements.  Diet-ESP use already existing mechanism
>>    like IKEv2 to negotiate the compression format.  Furthermore a lot of
>>    information, already existing for an IPsec Security Association, are
>>    reused to offer light negotiation in addition to maximum compression.
>>
>>
>> Name:        draft-mglt-lwig-minimal-esp
>> Revision:    00
>> Title:        Minimal ESP
>> Document date:    2014-01-31
>> Group:        Individual Submission
>> Pages:        6
>> URL:http://www.ietf.org/internet-drafts/draft-mglt-lwig-minimal-esp-00.txt
>> Status:https://datatracker.ietf.org/doc/draft-mglt-lwig-minimal-esp/
>> Htmlized:http://tools.ietf.org/html/draft-mglt-lwig-minimal-esp-00
>>
>>
>> Abstract:
>>    This document describes a minimal version of the IP Encapsulation
>>    Security Payload (ESP) described in RFC 4303 which is part of the
>>    IPsec suite.
>>
>>    ESP is used to provide confidentiality, data origin authentication,
>>    connectionless integrity, an anti-replay service (a form of partial
>>    sequence integrity), and limited traffic flow confidentiality.
>>
>>    This document does not update or modify RFC 4303, but provides a
>>    compact description of the minimal version of the protocol.  If this
>>    document and RFC 4303 conflicts then RFC 4303 is the authoritative
>>    description.
>>
>>
>

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58