Hi Hannes, Sure, we will consider that feedback when updating the draft. Thanks!
Yours, Daniel On Tue, Dec 26, 2023 at 3:42 AM Hannes Tschofenig <hannes.tschofe...@gmx.net> wrote: > 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 < > hannes.tschofe...@gmx.net> 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 <hannes.tschofe...@gmx.net> wrote: >> >>> Hi Daniel, >>> >>> >>> >>> thanks for your response. See my response below. >>> >>> >>> >>> *From:* Daniel Migault <mglt.i...@gmail.com> >>> *Sent:* Dienstag, 12. Dezember 2023 15:20 >>> *To:* Hannes Tschofenig <hannes.tschofe...@gmx.net> >>> *Cc:* Hannes Tschofenig <hannes.tschofenig=40gmx....@dmarc.ietf.org>; >>> Carsten Bormann <c...@tzi.org>; Tero Kivinen <kivi...@iki.fi>; >>> ipsec@ietf.org; s...@ietf.org >>> *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 < >>> hannes.tschofe...@gmx.net> 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 > > -- Daniel Migault Ericsson
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
