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

["Eric Vyncke (evyncke)" <[e-mail]>]

Let me reply to Hannes’ statement: “Integrating the functionality into SCHC alone is not enough.”

I consider SCHC as a technical mean and not an end. I.e., it is not about adding IPsec to SCHC but rather about using SCHC to compress IPsec (= ESP & IKE). The SCHC WG did a similar work with COAP.

Regards

-éric

From: Schc <[e-mail]> on behalf of Hannes Tschofenig <hannes.tschofenig=[e-mail]>
Date: Monday, 11 December 2023 at 18:03
To: Daniel Migault <[e-mail]>, Hannes Tschofenig <hannes.tschofenig=[e-mail]>
Cc: Carsten Bormann <[e-mail]>, Tero Kivinen <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [Schc] [IPsec] WG Adoption calls for draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-diet-esp-extension

Hi Daniel, Hi all,



don't get me wrong: I am trying to be helpful.


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.



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.



Hence, I would aim for a more ambitious goal: Make IPsec/IKEv2 work well on Linux-based IoT devices (*)



Ciao

Hannes



*: Forget the constrained IoT device use case - there are better solutions available that don't require IPsec/IKEv2


Am 11.12.2023 um 14:53 schrieb Daniel Migault:
Hi Hannes,

One draft is esp, the other is ikev2, I tend to think it would be better to have two separate documents.

Validation of specification SCHC will be supported by implementations and I am aware of two ongoing implementations based on openschc. I am also aware of 2 implementations that do not rely on SCHC. One implementation on contiki and one in python (not public).
https://bitbucket.org/sylvain_www/diet-esp-contiki/src/master/

We are working on an implementation. 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.

As far as I know ROHC is still used, but I do not know how ROHC is specifically used for IPsec traffic.

Yours,
Daniel

On Mon, Dec 11, 2023 at 7:12 AM Hannes Tschofenig <hannes.tschofenig=[e-mail]<mailto:[e-mail]>> wrote:
Shouldn't the two drafts be merged?


Who of the authors is going to implement the specs?


Ciao
Hannes


@Carsten: I have not been following the ROHC work after standardization
was completed. Was it actually used? Is it still used?


Am 30.11.2023 um 14:09 schrieb Carsten Bormann:
> As a co-author of draft-mglt-ipsecme-diet-esp, I do support this work (as well as the accompanying draft-mglt-ipsecme-ikev2-diet-esp-extension) and plan to continue working on it.
>
> We did the equivalent of these two drafts for ROHC in RFC 5856 to 5858.
> The current work is an obvious missing link for SCHC that needs to be filled in, just as we did for ROHC in 2010.
>
> Grüße, Carsten
>
>
>> On 2023-11-27, at 19:33, Tero Kivinen <[e-mail]<mailto:[e-mail]>> wrote:
>>
>> This is two week adoption call for draft-mglt-ipsecme-diet-esp. If you
>> support adopting this document as a working group document for IPsecME
>> to work on, and then at some point publish this as an RFC, send
>> comments to this list.
>>
>> This adoption call ends 2023-12-13.
>>
>> Note, that I do want to see people saying that they think this
>> document is worth of working on, and that they plan to review and
>> comment on it. If I only get one or two people (including authors :-)
>> to say they support this work, then there is no point of work on this
>> in WG.
>> --
>> [e-mail]<mailto:[e-mail]>
>>
> _______________________________________________
> IPsec mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/ipsec

_______________________________________________
IPsec mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ipsec


--
Daniel Migault
Ericsson



_______________________________________________

IPsec mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/ipsec