Re: [IPsec] Diet-ESP

[Hannes Tschofenig <[e-mail]>]

Hi Daniel,

I would like to understand your use case a bit better. Just securing
sensor communication is not enough.

What application layer protocols do you expect to run on these devices?
What radio technologies do you assume are going to be used?
How does the envisioned stack on these devices look like?

Ciao
Hannes

On 02/18/2015 04:44 AM, Daniel Migault wrote:
> 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] <mailto:[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] <tel:%2B33%206%2070%2072%2069%2058>
>     >
>     >
>     > _______________________________________________
>     > IPsec mailing list
>     > [e-mail] <mailto:[e-mail]>
>     > https://www.ietf.org/mailman/listinfo/ipsec
>     >
> 
> 
> 
> 
> -- 
> Daniel Migault
> Ericsson
> 
> 
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec
>