Hi Daniel, Hi all,
don't get me wrong: I am trying to be helpful. 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. 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. Hence, I would aim for a more ambitious goal: Make IPsec/IKEv2 work well on Linux-based IoT devices (*) 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 list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
