Here’s an issue with this draft; it doesn’t meet the requirements that it claims. In particular, it claims that it is based on standard IPsec, and that its security is equivalent to IPsec (R1-R3). However, it allows (and, as far as I am concerned, encourages) the use of tiny ICVs; these tiny ICVs introduce security vulnerabilities that do not occur within sane configurations of IPsec (where sane includes using an integrity transform). In particular, using tiny ICVs with GCM is a known security issue.
Now, it would be possible to have an encryption protocol that would not have issues with small ICVs (say, by using a wide block cipher); however this would be rather different than standard IPsec (in part because IPsec was never designed with these minimal bandwidth constraints); either we need to stay with an IPsec-based protocol (which implies a largish ICV), or go with something else (which would have less overhead, but doesn’t look that much like IPsec internally). Oh, and a minor note on the IV generation: it’s actually secure to use the same key you use to encrypt to encrypt the counter for the IV; you don’t need a separate key. From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Daniel Migault Sent: Monday, February 16, 2015 10:08 PM To: 6...@ietf.org Cc: ipsec@ietf.org Subject: [IPsec] Diet-ESP 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 +33 6 70 72 69 58
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
