Hi Paul, Please find my comments inline.
Yours, Daniel On Mon, Dec 11, 2023 at 9:59 AM Paul Wouters <p...@nohats.ca> wrote: > > > > > On Dec 11, 2023, at 08:53, Daniel Migault <mglt.i...@gmail.com> wrote: > > > > > > 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. > > For libreswan to consider this, there would have to be ESP support (or > plans) by maintainers of IPsec in Linux and/or BSD. > One thing is that we have implementations, another is that these implementations are public and the other thing is that it is supported by libreswan / Linux. As I mentioned earlier, I am hoping the publication of a Linux implementation can be clarified in the next coming months. It sounds though realistic to me that a Linux implementation be published. I see support from the SCHC crowd, but haven’t seen the same from the IPsec > crowd. I’m also myself still a bit unsure who would actually deploy this > outside proof of concept scenarios. > I am personally active on these drafts because we have a deployment perspective. The PoC phase is over for many years now and I can see a number of vendors we are willing to interconnect with. We would also want to look at using an scsh library (GPL compatible) as we > wouldn’t want to re-implement what seems like a very complicated high cpu > load parser. > > It is unclear to me who "We" is. However, assuming scsh stands for schc, and as I tried to mention a few minutes ago, we rely on SCHC for the specification. Implementations do not have to (see our old implementations for example). So, whoever is behind "We" does not have to necessarily re-implement or rely on a GPL SCHC library. Regarding compression / decompression I do see SCHC as pretty efficient especially because of the use of static context, so I am wondering 1) why "We" seesthis as "a very complicated high cpu load parser" and 2) what compression/decompression alternative "We" would find more efficient. > Paul > > > -- Daniel Migault Ericsson
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec