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

[Daniel Migault <[e-mail]>]

I applied your comments on my local copy. Please see some additional
comments inline.
Yours,
Daniel

On Thu, May 12, 2022 at 12:30 PM Robert Moskowitz <[e-mail]>
wrote:

>
>
> 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.
>
> I checked previous versions and did not find a UDP Transport mode example.
The current version is limited to UDP in tunnel mode. I do not expect much
changes, but that is something we can add. I also believe that BEET mode -
though no a standard might be good but that one I am pretty sure I never
drafted it.

>
> 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.
>
yes, I am wondering if adding some SCHC IDs would be sufficient or if
something more would be needed.

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

-- 
Daniel Migault
Ericsson