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 <[email protected]> on behalf of Hannes Tschofenig 
<[email protected]>
Date: Monday, 11 December 2023 at 18:03
To: Daniel Migault <[email protected]>, Hannes Tschofenig 
<[email protected]>
Cc: Carsten Bormann <[email protected]>, Tero Kivinen <[email protected]>, 
[email protected] <[email protected]>, [email protected] <[email protected]>
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 
<[email protected]<mailto:[email protected]>> 
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 
>> <[email protected]<mailto:[email protected]>> 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.
>> --
>> [email protected]<mailto:[email protected]>
>>
> _______________________________________________
> IPsec mailing list
> [email protected]<mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/ipsec

_______________________________________________
IPsec mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/ipsec


--
Daniel Migault
Ericsson



_______________________________________________

IPsec mailing list

[email protected]<mailto:[email protected]>

https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to