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

Hi Valery,

On Wed, Feb 26, 2014 at 7:47 AM, Valery Smyslov <svanru@gmail.com> wrote:
> 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.
>

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.

> 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.
>

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.

> 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.
>

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.

> Regards,
> Valery Smyslov.
>
>
Best Regards,
Daniel

>
>
> ----- Original Message ----- From: "Yaron Sheffer" <yaronf.ietf@gmail.com>
> To: "Daniel Migault" <mglt.ietf@gmail.com>; "Hannes Tschofenig"
> <hannes.tschofenig@gmx.net>
> Cc: <ipsec@ietf.org>; <lwip@ietf.org>; "Sye Loong Keoh"
> <SyeLoong.Keoh@glasgow.ac.uk>
> Sent: Tuesday, February 18, 2014 9:10 PM
> Subject: Re: [IPsec] [Dtls-iot] IPsec/Diet-ESP for IoT and Minimal ESP
>
>
>> 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
>>
>> On 02/18/2014 03:06 PM, Daniel Migault wrote:
>>>
>>> Hi Hannes,
>>>
>> [...]
>>
>>>
>>> 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
>>>
>>
>> _______________________________________________
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
>
>

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