Re: [IPsec] WG Adoption calls for draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-diet-esp-extension

[Daniel Migault <[e-mail]>]

Hi Paul,

Please find my comments inline.

Yours,
Daniel
On Mon, Dec 11, 2023 at 9:59 AM Paul Wouters <[e-mail]> wrote:

>
> >
> > On Dec 11, 2023, at 08:53, Daniel Migault <[e-mail]> 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