Hi Daniel,
thanks for your response. See my response below. From: Daniel Migault <[email protected]> Sent: Dienstag, 12. Dezember 2023 15:20 To: Hannes Tschofenig <[email protected]> Cc: Hannes Tschofenig <[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 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 <[email protected] <mailto:[email protected]> > 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. [Hannes] Base Stations are not constrained IoT devices (see RFC 7228 terminology). I assume that the base stations originate or terminate the traffic and the traffic being protected is some signaling protocol. If so, your co-workers, Magnus & John, who working on SCTP in the TSVWG, tell us that IPsec/IKEv2 is being phased out and replaced by TLS/DTLS. There is a design team working on this topic in the TSVWG. Hopefully your drafts are not taken over by the attempts to move telco infrastructure implementations into the cloud. 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. [Hannes] Your use case makes sense to me (if IPsec is still going to be used in this environment in the future). You should maybe add text about this use case to your document. This would provide a lot of extra context for the reader. The feedback on the list in response to the call for adoption was confusing to me. Someone was saying “I could use it for ANIMA” and others said “I could use it for LPWAN”. I don’t believe those use cases are realistic. 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. [Hannes] Paul responded to this aspect already. I have not done an analysis but it would be good to talk about this topic in some document so that two sides of the story can be described. 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. [Hannes] I would like a document I could point to whenever I run into the next “Wireguard is so much better than IPsec” discussion. If, as part of this write-up, we find out that there are gaps, I would like those to be fixed. Reading Paul’s email, I think he is saying that there are not gaps. Everything is just fine. Ciao Hannes
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
