Hi,
This version has addresses all comments received so far. There is one
aspect that remains to be resolved. draft-ietf-ipsecme-diet-esp defines
a way to compress the DSCP field. Initially DSCP fields associated to
the SA were negociated by the draft-mglt-ipsecme-dscp-np. We considered
including the negociation as part of the HCP_PROPOSAL defined in this
draft. However, HCP_PROPOSAL is mostly focused on negociating
compression parameters for parameters negociated elsewhere. As a result,
we do not beleive that including the negociation of DSCP values as part
o fthe HCP_PROPOSAL is a good design. Instead, we beleive these should
remain negociated as described in draft-mglt-ipsecme-dscp-np. We
appreciate any feed back.
Some small nits remain to be addressed - just saw them after publication
- so we expect a new version next week. and this for both drafts.
The current version is available here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-diet-esp-extension/
The diff can be seen here:
https://author-tools.ietf.org/diff?doc_1=draft-ietf-ipsecme-ikev2-diet-esp-extension-03&doc_2=draft-ietf-ipsecme-ikev2-diet-esp-extension-02
Yours,
Daniel
On 2025-01-26 22:04, Daniel Migault wrote:
Hi Michael,
Thanks for the comments. Please see comments and responses inline.
Yours,
Daniel
On 2025-01-25 14:27, Michael Richardson wrote:
I have read draft-ietf-ipsecme-ikev2-diet-esp-extension and
draft-ietf-ipsecme-diet-esp. It's been a long time since I last read them.
I found them reasonably well written, and seem to be detailed enough to
implement.. but... I'd like to see have a few more examples in the diet-esp
document, and I wonder about srcv6: 2001:db8:, with destination ff02::.
It there any reason to wonder if this is a magic choice for compression?
The selection of the specific values was not based on any particular
reasons. With LSB compression, the larger the network prefix in the
TS, the greater the potential for compression. It is relatively
straightforward to generate the examples, as we have the necessary
code available. Please feel free to let us know if you would like to
see a specific example, and we would be happy to provide it. We will
provide additional examples.
Are there interactions between the outer IP header compression mechanisms
listed and RFC7400, or RFC4944? Neither of which is cited.
There are no interactions in the sense that we do not rely on them. We
only compress the IP header when operating in tunnel mode, and the
compressed IP header is the inner IP header. The outer IP header is
not compressed. RFC 4944 and 7400 can be used to compress the outer
header, depending on L2.
I think that Valery's comments are probably on, and HCP_UNSUPPORTED surprised
me.
The current version of the draft has replaced HCP_UNSUPPORTED with
NO_PROPOSAL_CHOSEN, as we did not want this to be a blocking issue. We
still believe that being able to provide a way for a random device to
offer a hint could be useful. Conversely, we can also consider having
such information available out-of-band prior to establishing the
communication. We are open to the preference of the WG on this matter.
I see the implementation note; has this run on real devices with real radios
yet?
This version of the draft has only been tested according to the SCHC
(Static Context Header Compression) protocol, which means that the
SCHC expression of the compression corresponds to our understanding.
An early implementation of the draft has been developed on Contiki, as
shown in the following link:
https://bitbucket.org/sylvain_www/diet-esp-contiki. It has been tested
on real devices, but the context was IoT. Beyond the Proof of Concept
(PoC), for diet-esp to be integrated into commercial telecom products,
it needs to become a standard. This is why we are leading that effort ;-)
The 5-author guideline is exceeded by a bit, what is the plan here?
We will see with Tero what is the actual maximum number. Though every
steps of that documents were important, it is likely the authors
involved in the SCHC version will be prioritized. Other will be added
in the co-author section.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
][email protected] http://www.sandelman.ca/ | ruby on rails [
_______________________________________________
IPsec mailing list [email protected]
To unsubscribe send an email [email protected]
_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]
