Hi Daniel,
thanks for the additional background. I would suggest avoid talking about IoT in the documents and take the use case description from our email conversation instead. This will provide a more convincing story for the functionality you are suggesting. Ciao Hannes Am 24.12.2023 um 22:18 schrieb Daniel Migault:
Hi Hannes, I actually do not mind at all whether the Base Stations are considered as an IoT or not. I said "could be" in the sense that is a very specific hardware dedicated to very specific tasks looking closely at the resources engaged in its transactions to meet the latency requirements. Obviously anyone looking at compressing the number of bytes is paying attention to the resources. I agree though they might also be quite far from use cases with low battery, few packets.... I think the confusion comes from the fact that the annexes of the current document are only focused on IoT. These are examples we started with quite some time ago, but these are not anymore the use case for which I have cycles to drive this effort. That said, I still think the protocol can be used for other use cases than the base station use case - including any IoT and non IoT related use case. I am actually quite happy that we are not addressing a single use case. Yours, Daniel On Sun, Dec 24, 2023 at 8:47 AM Hannes Tschofenig <[email protected]> wrote: Hi Daniel, I think we are on the same page on a number of items already. There is only this "base station is an IoT use case" issue left. Could you explain under what circumstances you consider a base station being an IoT device (or even a constrained IoT use case)? Ciao Hannes Am 17.12.2023 um 16:45 schrieb Daniel Migault:Hi Hannes, Please find my responses inline. Yours, Daniel On Tue, Dec 12, 2023 at 9:45 AM <[email protected]> wrote: 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]> 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. <mglt> I am fine with the base station not being IoT - I said "could". The interfaces we want to use diet-esp are fronthaul or sidehaul related in our case are the Lower Layer Control (LLS), the low latency coordination interface between RAN Compute basebands (E5 or Elastic RAN in LTE). It is correct that these interfaces include the user plan. On the other hand, I am pretty sure my co-workers did not mean to say so and it is correct that DTLS may be used on on the midhaul and inter Centralized Units interfaces such as CU-UP/CU-CP (E1), DU/CU-UP (F1-C), DU/CU-UP(F1-C), CU-CP/CU-CP (Xn-C), CU-CP/AMF (N2). </mglt> 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. <mglt> I agree. This context is currently not being mentioned as we were mostly focused on the profile itself, but we will add some context. </mglt> 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. <mglt> I agree, but that seems to me a separate document. </mglt> 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. <mglt> It might be interesting and probably the topic of another thread. I think wireguard positioned itself toward IPsec/IKEv2 which could be a good starting point. I guess that is what makes it hard is that there are multiple implementations/deployment of IPsec. </mglt> Ciao Hannes -- Daniel Migault Ericsson-- Daniel Migault Ericsson
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
