Re: [6lo] [IPsec] Diet-ESP

[Daniel Migault <[e-mail]>]

Hi Hannes,

We designing Diet-ESP was to enable motes to secure their communications
and provide end-to-end security. This function is important for us and I
guess we are not the only one interested in this functionality.

We believe it is worth exposing how IPsec can be use to fit the IoT
constraints, regardless of what other protocols are providing.

There are probably other alternatives (like DTLS), however :
    - a) DTLS/IPsec address different use cases
    - b) no real comparison have been made possible between these security
protocols designed for IoT, and we believe IPsec is pretty efficient.

Current spec may not be perfect. However, the impact on security can
largely be under control. First of all Diet-ESP results in the combination
of ROHC ROHCoverIPsec which are already standard with deep security
reviews. Then most of the compressed fields are not security related.
Padding, Pad Len, Next Header have nothing to deal with security.

Security related fields are SN, ICV, SPI. SN and SPI are compressed means
that they have to be decompressed before applying IPsec/ESP. Because of the
compression/decompression these fields are not altered and from an
IPsec/ESP perspective compression is transparent. On the other hand,
appropriate values MUST be chosen so compression/decompression can occur.

In the case of the ICV, this value cannot be decompressed, and thus we have
to make things right. Two alternatives are proposed and I would be happy to
update the draft with the best one.

If you have specific security impacts in mind, please let us know.

BR,
Daniel


On Tue, Feb 17, 2015 at 5:36 PM, Hannes Tschofenig <
[e-mail]> wrote:

> Daniel,
>
> I understand that you spend a lot of time in writing these
> specifications but, as mentioned in the past I just do not see the need
> for this type of standardization activity. Nobody I have spoken with
> asks for this functionality.
>
> If there is indeed a need for IPsec ESP use in IoT then I am not sure
> that the proposed optimizations are so useful given the impact for
> security.
>
> Ciao
> Hannes
>
> On 02/17/2015 04:08 AM, Daniel Migault wrote:
> > Please find the new version of Diet-ESP a compress IPsec/ESP for IoT. We
> > have implemented and tested Diet-ESP. Compared to the standard
> > IPsec/ESP, Diet-ESP can reduce the networking overhead added to
> > unprotected data from 100% to a few percent. I will be happy to present
> > these draft next IETF.
> >
> > Feel free to make comments!
> >
> > The drafts includes:
> >     1) draft-mglt-6lo-diet-esp-requirements
> > <http://datatracker.ietf.org/doc/draft-mglt-6lo-diet-esp-requirements/>:
> > lists the requirements for Diet-ESP
> >     2) draft-mglt-6lo-aes-implicit-iv
> > <http://datatracker.ietf.org/doc/draft-mglt-6lo-aes-implicit-iv/>:
> > indicates how to avoid carrying the IV in each ESP packet. It is instead
> > generated by each peers. The protocols described in the draft can be
> > used with the regular IPsec/ESP.
> >     3) draft-mglt-6lo-diet-esp
> > <http://datatracker.ietf.org/doc/draft-mglt-6lo-diet-esp/> describes the
> > core Diet-ESP protocol, that is how to compress/decompress each fields
> > of the standard IPsec/ESP. Compression is discribed through a Diet-ESP
> > Context.
> >     4) draft-mglt-6lo-diet-esp-payload-compression
> > <
> http://datatracker.ietf.org/doc/draft-mglt-6lo-diet-esp-payload-compression/
> >:
> > describes how the clear text can be compressed before encryption. In
> > fact unless IPsec/ESP is used with NULL encryption, the data in the ESP
> > packet is encrypted. Encryption makes compression hard to perform.
> > Instead compressing before encrypting can be very efficient. This makes
> > possible to remove UDP/TPC/IP tunnel headers.
> >     5) draft-mglt-6lo-diet-esp-context-ikev2-extension
> > <
> http://datatracker.ietf.org/doc/draft-mglt-6lo-diet-esp-context-ikev2-extension/
> >:
> > describes how to negociate Diet-ESP with IKEv2. In fact this mostly
> > result in an agreement for the DIet-ESP Context. This exchange may then
> > be extended to Diet-HIP Exchange.
> >
> > BR,
> > Daniel
> > --
> > Daniel Migault
> > Orange Labs -- Security
> > [phone]
> >
> >
> > _______________________________________________
> > IPsec mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ipsec
> >
>
>


-- 
Daniel Migault
Ericsson