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