Subject: Re: [IPsec] [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

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 18 Feb 2014 19:10:02 +0200

Hi Daniel,

This might be a naive answer - I have not read the draft in detail.

But on the "is this a duck or not" question, it seems to me the answer 
is simple: if the protocol can work stand-alone (two endpoints talking 
to each other, with manual keying and no IKE), then it's a protocol. 
Otherwise it's a protocol extension.

And if it's a protocol, it needs an IP protocol number, which is a 
seriously expensive resource. We allocated one for WESP 
(http://tools.ietf.org/html/rfc5840#section-4), is there any chance we 
could reuse it somehow?

Thanks,
	Yaron

> Hi Hannes,
[...]

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 26 Feb 2014 10:47:09 +0400

Hi,

First, I agree with Yaron that Diet-ESP looks more like a new protocol,
than like ESP extension. And in this case it must have its own
protocol number.

Then, I have some concerns how Diet-ESP will live with NATs.
The draft is silent about it. If we consider Diet-ESP as ESP
extension, then standard UDP-encapsulation must apply.
But here is the problem - with UDP encapsulation the first
4 bytes of packet data are used to distinguish between
IKE and UDP-encapsulated ESP, as in ESP these bytes
are SPI wich is never zero. In Diet-ESP this is not true -
SPI may be shorter than 4 bytes or even be absent and
there is a chance that those bytes will be zero (e.g. an IV
may appear to be zero, and SPI and SN are absent).
So, with Diet-ESP we cannot reliably distinguish IKE
from UDP-encapsulated ESP and therefore some other
mechanism must be (re)invented.

And last, the draft declares that its main goal is to minimize
power consumption caused by transferring extra bytes.
But in this case it's probably more fruitful to define some
new crypto transform for IoT, than redesigning ESP. In this
case you may use implicit IV (or explicit, but small),
small ICV, use stream cipher etc. I think
that in this case you may gain even more economy
in power consumption than with current approach.

Regards,
Valery Smyslov.

----- Original Message ----- 
From: "Yaron Sheffer" <[email-masked]>
To: "Daniel Migault" <[email-masked]>; "Hannes Tschofenig" 
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "Sye Loong Keoh" 
<[email-masked]>
Sent: Tuesday, February 18, 2014 9:10 PM
Subject: Re: [IPsec] [Dtls-iot] IPsec/Diet-ESP for IoT and Minimal ESP

> But on the "is this a duck or not" question, it seems to me the answer is 
> simple: if the protocol can work stand-alone (two endpoints talking to 
> each other, with manual keying and no IKE), then it's a protocol. 
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Daniel Migault <[email-masked]>
Date: Thu, 27 Feb 2014 14:55:23 +0100

Hi Valery,

> than like ESP extension. And in this case it must have its own

I agree, for me the best way would have had and ESP extension and
eventually define a new algorithm DIET-AES-CTR for example. However,
because we are also making possible to remove Padding and Pad Len and
Next Header this looks comprised and we change the header it looks
that Diet-ESP is a new protocol.

> mechanism must be (re)invented.

True, we did not think of of NAT in IoT context. We have added a
section on that point. Actually, if UPD encapsulation is required,
then using a SPI (even one byte) solves this issue. We will publish
the draft as soon as possible wit the update. Thanks for the feed
back.

> in power consumption than with current approach.

Completely agree. We are currently working on ESP format, but we are
also considering AES-CTR without explicit IV.

However, the ratio computing vs communication in IoT is quite
impressive and there is a high interest in compressing frames before
transmitting them.
    - Computing ranges from 0.5nJ per instruction for extremely
energy-efficient microcontrollers (such as CoolRisc or MSP430) to 200
nJ per instruction for high-performance microprocessors (such as
ARM9).
    - Communication: from 100nJ to 1uJ per bit transmitted or
received, depending on modulation complexity and transmission power
(we only consider "low-power" radios, with transmit powers lower than
about 10mW).

Roughly speaking, this means that, for the energy cost of exchanging 1
bit, our system can alternatively compute 10-100 instructions.

Best Regards,
Daniel

>
>
> ----- Original Message ----- From: "Yaron Sheffer" <[email-masked]>
>> simple: if the protocol can work stand-alone (two endpoints talking to each
>> other, with manual keying and no IKE), then it's a protocol. Otherwise it's
>> a protocol extension.
>>
>> (http://tools.ietf.org/html/rfc5840#section-4), is there any chance we could
>> reuse it somehow?
>>
>> Thanks,
>> Yaron
>>

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

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 28 Feb 2014 10:34:29 +0400

Hi Daniel,

> bit, our system can alternatively compute 10-100 instructions.

Yes, it's impressive. Did you consider using ROHC (RObust Header 
Compression)?
It will allow you to significantly decrease size of TCP/UDP/IP headers.

Regards,
Valery Smyslov.

---

From: Tobias Guggemos <[email-masked]>
Date: Fri, 28 Feb 2014 16:00:24 +0100

Hello Valery

Yes we considered ROHC and also 6LoWPAN, because both include 
possibilities for compression ESP.
First, it's definitely an option and remains an option even if Diet-ESP 
is going to be used.
We are thinking about Diet-ESP because:
- If I'm right ROHC needs at least one uncompressed packet to be send, 
which may be expensive.
- As we want to use IPsec/ESP we have all necessary information in the 
SAD/SPD to restore the information of IP/UDP/(partly TCP). The idea is 
to use them instead of adding ROHC compressors between the different 
layers which 1) adds ROM space (which may be limited) and 2) storage for 
an information which is already there.
- In case of Diet-ESP it is really simple to restore the payload headers 
and it costs only two bits to send once in the session. This is why we 
decided to add this as an option.

BR
Tobias