Thanks for sending this out! Definitely very interesting stuff. I like the new
focus on how to compress UDP/TCP within Diet-ESP.
Some of the introduction text could use some clarification/wordsmithing:
IPsec/ESP has not been designed to reduce the networking overhead of
the communications. In fact saving bandwidth comes with additional
operation that may affect or impact large infrastructure where
bandwidth usage is not an issue. On the other hand, IoT emerged with
completely different constraints. IoT communications are different
in many ways and a few important differences may be that sending any
extra byte impact significantly the life time of these devices. In
addition, these devices are also expected to be sleeping nodes where
communications are hardly based on sessions as we used to.
Perhaps could be:
IPsec/ESP was not designed to reduce the networking overhead of
the communications. In fact, reducing bandwidth often adds computational
overhead that may negatively impact large infrastructures in which
bandwidth usage is not a constraint. On the other hand, IoT devices have
completely different constraints. In IoT communications, sending any
extra bytes can significantly impact the battery life of devices. These
are also often expected to be sleeping nodes, for which IPsec sessions
have a very different meaning.
I think the work on the appendices to provide more full examples of how the
packets are compressed is very effective. Thanks for adding that. I did find it
a bit confusing that the packet diagrams don’t give a clear picture of the
effect of encryption on inner packet data. In the RFC 4303 diagrams, the
‘inner’ portions are all summarized as ‘Payload Data’, which is the content
that is encrypted. In your diagrams, we see the decrypted content written out.
Perhaps there is some labelling on the figures you can add to make that a bit
> On Oct 12, 2016, at 11:50 AM, Daniel Migault <daniel.miga...@ericsson.com>
> Please find an update version of the diet-esp document we discussed in
> Berlin. The scope of the compression has been extended, and the compression
> simplified. We also provided example in the appendix section.
> Comments are welcome as usual!
> -----Ursprüngliche Nachricht-----
> Von: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> Gesendet: Mittwoch, 12. Oktober 2016 19:45
> An: Carsten Bormann <c...@tzi.org>; Daniel Migault
> <daniel.miga...@ericsson.com>; Tobias Guggemos <gugge...@mnm-team.org>
> Betreff: New Version Notification for draft-mglt-ipsecme-diet-esp-02.txt
> A new version of I-D, draft-mglt-ipsecme-diet-esp-02.txt
> has been successfully submitted by Daniel Migault and posted to the IETF
> Name: draft-mglt-ipsecme-diet-esp
> Revision: 02
> Title: ESP Header Compression and Diet-ESP
> Document date: 2016-10-04
> Group: Individual Submission
> Pages: 43
> Status: https://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/
> Htmlized: https://tools.ietf.org/html/draft-mglt-ipsecme-diet-esp-02
> ESP Header Compression (EHC) defines a flexible framework to compress
> communications protected with IPsec/ESP. Compression and
> decompression is defined by EHC Rules orchestrated by EHC Strategies.
> The document specifies the Diet-ESP EHC Strategy and associated EHC
> Rules. Diet-ESP compresses up to 32 bytes per packet for traditional
> IPv6 VPN and up to 66 bytes for IPv6 VPN set over a single TCP or UDP
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> The IETF Secretariat
> IPsec mailing list
IPsec mailing list