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

[Robert Moskowitz <[e-mail]>]

On 5/12/22 11:58, Daniel Migault wrote:
> Hi Bob,
>
> I apologize for the delayed response. I am happy to go back to this 
> document.

Good and thank you.

I also see a tunnel application, but that will be for later.

First UDP Transport and UDP BEET mode.

>
> 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 ?

Most of the SCHC CoAP rfc deals with the CoAP headers, and any UDP 
consideration is out-of-scope.  Even with UDP/DTLS, 8824 is silent. I think.

So this draft can easily ignore CoAP.  It took me a bit of reading to 
get to this point..

>
> 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 far as diet-esp is concerned any 8824 CoAP compression is just data 
payload.  The SCHC RuleID is the first field either in the UDP data or 
the DTLS data.


>
>         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.

I just asked this again in my latest missive.  I think you need the IKE 
payloads.

And I will somewhere have to do the matching HIP payloads.  ;)

>         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.

After more reading, I think for Transport/BEET, it will always be 
diet-esp.  For Tunnel, it may well be 8724.  The diet-esp rules will 
establish this.  Also the RuleID for the 8724 tunnel could be implicit 
in the packet, only being in the SA.  Compared to 9011.


Next I will write up the UDP example.  Unless you have one and just did 
not include it in the appendix?

Bob