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 <rgm-...@htt-consult.com> 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 > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- Daniel Migault Ericsson
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
