Hi Paul,
reading your response it sounds to me that a myth busting (or a hitchhiker's guide to IKEv2/IPsec) document would be useful. I am curious whether others have also run into similar discussions about Wireguard. Additionally, it seems worthwhile to think about doing something similar to RFC 7925 (and draft-ietf-uta-tls13-iot-profile-08 <https://datatracker.ietf.org/doc/draft-ietf-uta-tls13-iot-profile/> ) but for IKEv2 / IPsec, maybe based on draft-kivinen-ipsecme-ikev2-minimal / draft-mglt-lwig-minimal-esp. Ciao Hannes From: Paul Wouters <[email protected]> Sent: Montag, 11. Dezember 2023 20:30 To: Hannes Tschofenig <[email protected]> Cc: Daniel Migault <[email protected]>; Carsten Bormann <[email protected]>; Tero Kivinen <[email protected]>; [email protected]; [email protected] Subject: Re: [IPsec] WG Adoption calls for draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-diet-esp-extension On Dec 11, 2023, at 12:03, Hannes Tschofenig <[email protected] <mailto:[email protected]> > wrote: 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. It’s actually far less efficient because it only supports chacha20poly1305, so when doing benchmarks resulting in similar (within 5%) bandwidth, it ends up using 90% CPU versus like 5% with AES_GCM that’s hardware accelerated. The ESP tunnel mode packet format and the wireguard packet format are basically the same thing. The one thing people claim that can be argued is that configuration of wireguard is easier, but for IoT, I would expect either solution to be so abstracted from the user to not be a relevant consideration. 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. There is minimal IKEv2 and minimal ESP. Hence, I would aim for a more ambitious goal: Make IPsec/IKEv2 work well on Linux-based IoT devices (*) What’s the limiting factor here? usually Linux based iot has “plenty” of RAM, CPU and flash. Paul *: Forget the constrained IoT device use case - there are better solutions available that don't require IPsec/IKEv2 Coap? EDHOC ? Paul 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 <[email protected] <mailto:[email protected]> > 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 <[email protected] >> <mailto:[email protected]> > 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. >> -- >> [email protected] <mailto:[email protected]> >> > _______________________________________________ > IPsec mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/ipsec -- Daniel Migault Ericsson _______________________________________________ IPsec mailing list [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
