Hi Hannes, Seems I did not click "sent" yesterday. Please see my response inline.
Yours, Daniel On Mon, Dec 11, 2023 at 12:02 PM Hannes Tschofenig < hannes.tschofe...@gmx.net> wrote: > Hi Daniel, Hi all, > > > don't get me wrong: I am trying to be helpful. > > > This is how I am reading your comments. > Integrating the functionality into SCHC alone is not enough. You need to > integrate it into an implementation of IKEv2/IPsec that is suitable to the > mentioned constrained IoT use cases. I have not seen IPsec/IKEv2 being used > in constrained environments so far nor have I seen a "lightweight" > implementation for microcontrollers. > In our case, we want to "compress" / "decompress" IPsec traffic for our base stations. These could be seen as IoT in the sense that they are under heavy constraints... but I admit these are not sensors with a battery. The advantage of using SCHC is that there is a SCHC protocol code points so we can have different layers of compressions and use the same framework for all layers (including applications). ESP is only one layer. The implementation of course needs compression/decompression to be integrated into IPsec. In our case mostly to adapt data structures accordingly and perform the actual compression / decompression. Suppose one field is removed. Some implementations build that field and remove it, others may simply not add that field. Doing one or the other depends on which hardware / software you are using. > I have, however, heard about uses of WireGuard on Linux-based IoT devices > (these are non-constrained devices, obviously) with the argument that it is > simple to use and efficient. > > > I believe it is worthwhile to think about the motivation of using > WireGuard instead of IPsec/IKEv2 instead of spending a lot of time on yet > another tiny optimization. > > > For ESP, I have in mind wireguard performs 10 % / 15 % better in terms of throughput for Chacha and AES-GCM, but I do not know enough to tell if this is due to a specific setting or whether there is an implementation/systems reasons for it. I hardly see the packet format being an issue but of course I might be wrong. Of course if one can improve ESP we should do it and that is part of the evolution of ESP. > Hence, I would aim for a more ambitious goal: Make IPsec/IKEv2 work well > on Linux-based IoT devices (*) > It would be interesting to understand what you think should be improved with the current IPsec/IKEv2. We have defined minimal versions of IKEv2/ESP that go into the simplification of the code. I think we could do more to ease the configuration, and probably the yang model that the WG are a good start - at least we are thinking of leveraging from these. > > Ciao > > Hannes > > > *: Forget the constrained IoT device use case - there are better solutions > available that don't require IPsec/IKEv2 > > > Am 11.12.2023 um 14:53 schrieb Daniel Migault: > > Hi Hannes, > > One draft is esp, the other is ikev2, I tend to think it would be better > to have two separate documents. > > Validation of specification SCHC will be supported by implementations and > I am aware of two ongoing implementations based on openschc. I am also > aware of 2 implementations that do not rely on SCHC. One implementation on > contiki and one in python (not public). > https://bitbucket.org/sylvain_www/diet-esp-contiki/src/master/ > > We are working on an implementation. What is not completely clear to me > now is how we will be able to have/make public implementations for linux > implementation and potentially *Swan projects. It is a bit too early for > now, but I am hoping to have a path in the next coming months. > > As far as I know ROHC is still used, but I do not know how ROHC is > specifically used for IPsec traffic. > > Yours, > Daniel > > On Mon, Dec 11, 2023 at 7:12 AM Hannes Tschofenig <hannes.tschofenig= > 40gmx....@dmarc.ietf.org> wrote: > >> Shouldn't the two drafts be merged? >> >> >> Who of the authors is going to implement the specs? >> >> >> Ciao >> Hannes >> >> >> @Carsten: I have not been following the ROHC work after standardization >> was completed. Was it actually used? Is it still used? >> >> >> Am 30.11.2023 um 14:09 schrieb Carsten Bormann: >> > As a co-author of draft-mglt-ipsecme-diet-esp, I do support this work >> (as well as the accompanying draft-mglt-ipsecme-ikev2-diet-esp-extension) >> and plan to continue working on it. >> > >> > We did the equivalent of these two drafts for ROHC in RFC 5856 to 5858. >> > The current work is an obvious missing link for SCHC that needs to be >> filled in, just as we did for ROHC in 2010. >> > >> > Grüße, Carsten >> > >> > >> >> On 2023-11-27, at 19:33, Tero Kivinen <kivi...@iki.fi> wrote: >> >> >> >> This is two week adoption call for draft-mglt-ipsecme-diet-esp. If you >> >> support adopting this document as a working group document for IPsecME >> >> to work on, and then at some point publish this as an RFC, send >> >> comments to this list. >> >> >> >> This adoption call ends 2023-12-13. >> >> >> >> Note, that I do want to see people saying that they think this >> >> document is worth of working on, and that they plan to review and >> >> comment on it. If I only get one or two people (including authors :-) >> >> to say they support this work, then there is no point of work on this >> >> in WG. >> >> -- >> >> kivi...@iki.fi >> >> >> > _______________________________________________ >> > IPsec mailing list >> > IPsec@ietf.org >> > https://www.ietf.org/mailman/listinfo/ipsec >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > > > -- > Daniel Migault > Ericsson > > _______________________________________________ > IPsec mailing listIPsec@ietf.orghttps://www.ietf.org/mailman/listinfo/ipsec > > -- Daniel Migault Ericsson
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
