Hi Eric,
I think we are saying the same thing. Making the SCHC integration will be nice but does not get you to solve anything for constrained IoT device implementations. Ciao Hannes From: Eric Vyncke (evyncke) <evyncke=40cisco....@dmarc.ietf.org> Sent: Dienstag, 12. Dezember 2023 12:34 To: Hannes Tschofenig <hannes.tschofe...@gmx.net>; Daniel Migault <mglt.i...@gmail.com> Cc: ipsec@ietf.org; s...@ietf.org Subject: Re: [Schc] [IPsec] WG Adoption calls for draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-diet-esp-extension Let me reply to Hannes’ statement: “Integrating the functionality into SCHC alone is not enough.” I consider SCHC as a technical mean and not an end. I.e., it is not about adding IPsec to SCHC but rather about using SCHC to compress IPsec (= ESP & IKE). The SCHC WG did a similar work with COAP. Regards -éric From: Schc <schc-boun...@ietf.org <mailto:schc-boun...@ietf.org> > on behalf of Hannes Tschofenig <hannes.tschofenig=40gmx....@dmarc.ietf.org <mailto:hannes.tschofenig=40gmx....@dmarc.ietf.org> > Date: Monday, 11 December 2023 at 18:03 To: Daniel Migault <mglt.i...@gmail.com <mailto:mglt.i...@gmail.com> >, Hannes Tschofenig <hannes.tschofenig=40gmx....@dmarc.ietf.org <mailto:hannes.tschofenig=40gmx....@dmarc.ietf.org> > Cc: Carsten Bormann <c...@tzi.org <mailto:c...@tzi.org> >, Tero Kivinen <kivi...@iki.fi <mailto:kivi...@iki.fi> >, ipsec@ietf.org <mailto:ipsec@ietf.org> <ipsec@ietf.org <mailto:ipsec@ietf.org> >, s...@ietf.org <mailto:s...@ietf.org> <s...@ietf.org <mailto:s...@ietf.org> > Subject: Re: [Schc] [IPsec] WG Adoption calls for draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-diet-esp-extension 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 <mailto: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 >> <mailto: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 <mailto:kivi...@iki.fi> >> > _______________________________________________ > IPsec mailing list > IPsec@ietf.org <mailto:IPsec@ietf.org> > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org <mailto:IPsec@ietf.org> https://www.ietf.org/mailman/listinfo/ipsec -- Daniel Migault Ericsson _______________________________________________ IPsec mailing list IPsec@ietf.org <mailto:IPsec@ietf.org> https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
