Re: [IPsec] Comments on draft-mglt-ipsecme-diet-esp-07

[Daniel Migault <[e-mail]>]

Hi Bob,

I apologize for the delayed response. I am happy to go back to this
document.

Yours,
Daniel

On Fri, May 6, 2022 at 5:02 PM Robert Moskowitz <[e-mail]>
wrote:

> First read-through.
>
> Is there an implementation of this draft?
>
> yes we do have an implementation on contiki, as well as in python.

The implementation is available here:
https://bitbucket.org/sylvain_www/diet-esp-contiki

You can also find a description of the implementation as well as some
experimental measurements we performed there:
https://www.researchgate.net/publication/316348221_Diet-ESP_IP_layer_security_for_IoT

Obviously it being last published in '19 some drafts are now RFCs and
> thus need updating.
>
> Sure ;-)

> Page 5 at top:
>
> Non ESP fields may be compressed by ESP under
>     certain circumstances, but EHC is not intended to provide a generic
>     way outside of ESP to compress these protocols.
>
> How does EHC work with SCHC CoAP compression, rfc 8824?  I would think
> this is a must work with...
>
> I agree that is something we should consider and probably clarify.
Diet-ESP is  not intended to provide some compression beyond what is being
used for TS. I do not see CoAP as part of these TS, and as such, I would
expect the compression associated to CoAP to be handled "after Diet-ESP".
Not having read how SCHC compresses CoAP, I Assume that SCHC CoAP
compresses also the UDP/IP part which ends in the compressed CoAP packet
not being an IP packet. On the sender side, when IPsec is applied to such
packet, there is a need that this compressed CoAP packet matches the SPD TS
- unless these are set to ANY. So my first question would be how SCHC
CoAP works with IPsec ?

Assuming the compressed packet is protected by IPsec, only the ESP fields
will be subject to compression. On the other hand, if IPsec requires some
fields, there is probably a need to request Diet-ESP to compress what
SCHC(CoAP) has not compressed to make IPsec work.



>     As depicted in Figure 1, the EHC Strategy - Diet-ESP in our case -
>     and the EHC Context are agreed upon between the two peers, e.g.
>     during key exchange.  The EHC Rules are to be implemented on the
>     peers and do not require further agreement.
>
> Can the EHC Strategy, Context, and Rules be static between two hosts?
> This is of interest to me with Network Remote ID where these will always
> be the same (I think so far) between the UA and Service Provider.
>
> In fact if aligned with SCHC, static is the norm which can be overridden
> during a key exchange.  This approach would allow the key exchange to be
> unmodified to support diet-esp.
>
> Rules are static and require only to agree on a very small number of
parameters via IKEv2. WHat I do not think we considered is the exchange of
additional SCHC rules.


>     With EHC, the agreement of the level or occurrence of compression is
>     left the negotiation protocol (e.g.  IKEv2), contradicting the
>     signalization of the level of compression for a certain packet send
>     over the wire.
>
> This is a sentence fragment and I don't get what is being said here.
> Taking out the comma delimited:
>
>     With EHC, contradicting the
>     signalization of the level of compression for a certain packet send
>     over the wire.
>
> ?
>
> Good I will need to review the doc.

> This
>     leads to multiple SAs, and thus, multiple SPIs for different levels
>     of compression agreed with the EHC Context.
>
> This can lead to multiple...
>
> Sure, Thanks.

> I think
>
>     If the sender detects the de-compression can not be guaranteed with a
>     given EHC Context and EHC Strategy, it MUST NOT apply compression.
>
> If the sender detects that the de-
>
> ?
>
> Made it through sec 6, stopping for now a 6.1 where I will continue Monday?
>
> I see that with ESP Next Header compression and ony UDP in the SA, that
> SCHC for UDP is not needed so don't need an IP Protocol number for SCHC
> here.  But what about SCHC for CoAP over UDP?
>
> I think there is a need to define which layers will compress the inner
UDP, and this is likely to depend on the TS values.

> Anyway, stopping for now.  More, I suspect, later.
>
> Oh, and NIST is having their 4th LWC workshop M-W, so I am busy with
> that too!
>
> Bob
>
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec
>


-- 
Daniel Migault
Ericsson