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