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

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

Hi Hannes,

Thank you for pointing out the issue. Actually we wanted to have feed
back from both communities.
    - lwig for IoT to make sure we address all or relevant scenarios
of IoT, and understand those we do not address.
    - ipsecme for the design of diet-esp.

My understanding is that diet-esp should then be more an ipsecme draft
and minimal esp should be in lwig. We will make this change in the
next version of the draft diet-esp this week!

Now comes also another question: Is diet-ESP a new protocol, a new
extension, a ESP compression algorithm.... I would be happy to get
opinion on that.

1) Diet-ESP: Extension vs Protocol

    - a) Diet-ESP is an IPsec extension
The way we considered to peers agreeing on the diet-esp context is
using minimal IKE sending an DIET-ESP_SUPPORTED Notify Payloads with
proposition of DIET-ESP Context. The responder just ignores the
propositions or chose one. All remaining stuff would be negotiated via
the traditional CREATE_CHILD_SA were peers would agree on ESP, keys,
algos....
>From that point of view it looks the diet-ESP is more a
wire-compression algorithm. If not supported by one of the peer we
fall back with standard ESP.

    -b) Diet-ESP is a new Protocol
Another way would be to consider that all parameters of the Diet-ESP
Context would be negotiated in the CREATE_CHILD_SA exchange with new
Transform structures.
>From that point of view diet-esp would look more like a new protocol
and the possible choice may be IKE/ESP/AH/DIET-ESP....

 There might be other alternatives I would be happy to hear about. For
now I like better the extension way.

2) What Diet-ESP changes from regular ESP

Diet-ESP changes IPsec and ESP headers, trailers with smaller fields.

Diet-ESP changes the way the packet is compressed and encrypted.

On the other hand, for a sensor with a single diet-ESP configuration,
most of the IPsec stack remains unchanged. This is not so true for
peers that are able to handle all Diet-ESP configuraions. In that case
the standard way of looking up in the SAD may be changed. We will
provide a better description of this in the next version of the draft.

BR,
Daniel

On Sun, Feb 16, 2014 at 8:23 PM, Hannes Tschofenig
<[email-masked]> wrote:
> Hi Daniel,
>
> thanks for the pointer to the ipsecme agenda.
>
> I agree with you that ipsecme would be the right place to get this work
> done since the proposal makes changes to IPsec ESP and they have the
> needed experience.
>
> LWIG, as part of the charter, is not allowed to make changes to existing
> protocols, as this snippet from the charter illustrates:
> "
> The group shall also not develop any new protocols or protocol behavior
> modifications beyond what is already allowed by existing RFCs, because
> it is important to ensure that different types of devices can work together.
> "
>
>
> Ciao
> Hannes
>
> On 02/13/2014 02:45 PM, Daniel Migault wrote:
>> Hi,
>>
>> We have not updated the draft to change their names, but I agree they
>> definitely better fit in the LWIG. We would like to present them both
>> in LWIG in London.
>>
>> Note Tero has been provided a 20 minute slot for an overview on "IPsec
>> in constrained environments". So people interested in IoT and security
>> should check the agenda at ipsecme too.
>>
>> [1] http://www.ietf.org/proceedings/89/agenda/agenda-89-ipsecme
>>
>> On Tue, Feb 4, 2014 at 2:53 AM, Sye Loong Keoh
>> <[email-masked]> wrote:
>>> Hi Daniel,
>>>
>>> As pointed out by Hannes, DICE WG is not chartered to look at IPSec for IoT.
>>> However, I think your draft might be useful for LWIG WG though.
>>>
>>> Cheers
>>> Sye Loong
>>>
>>> -----Original Message-----
>>> From: dtls-iot [mailto:[email-masked]] On Behalf Of Daniel Migault
>>> Sent: Friday, 31 January, 2014 10:48 PM
>>> To: [email-masked]; [email-masked]
>>> Subject: [Dtls-iot] IPsec/Diet-ESP for IoT and Minimal ESP
>>>
>>> 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
>>> _______________________________________________
>>> dtls-iot mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/dtls-iot
>>
>>
>>
>

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