Dear Daniel,
Thank you for sharing this work. I appreciate the thought you've
put into it, and it provides us with a good starting point for
further development.
I have found some points for discussion
1. the Strata
In your document, you need 3 strata to compress the complete
stack. And anywhere in the document, you define the SCHC Header
Instance of each stratum.
I understand that for EEC and CTEC strata use a compressed SCHC
Header where there is only one Rule and the length is zero,
for instance for the IIP strata you must define a SCHC Header to
identify the next protocol in the stack.
2. Terminology
- You need to read the new architecture version and update your
terminology.
- SCHC Context has been removed, and there is only SCHC SoR for
each instance.
In the SoR there is only Rules, there is no context.
- You need to add the SCHC Strata
- You need to define the SCHC Header Instances
- You need to align your terminology section to draft-architecture
3. SCHC SoR initialization
You talk about a SA (Security Association) that will generate
the corresponding SCHC rules.
For me is not clear what you mean. Will the SA use the yang data
model together with the SA for this generation?
4. SCHC Profile
Until now, a SCHC Profile has been defined for Layer Two
fragmentation parameters.
I'm not sure you are using the correct term for SCHC profile
because you are not doing fragmentation.
It will be good to discuss and see what you mean by Profile.
5. Padding
I'm not a security specialist, but I see you are doing double
padding, one in SCHC compression and the other in the ESP.
Is it a security reason to do this way? If not SCHC does not
require alignment, so perhaps you can eliminate one padding
6. SoR and Rules
There is a confusion between Rule and FID. A Rule is a
description of the header fields, all the header fields!
the Rule does not have a direction by itself but each FID in the
Rule has it.
7. Identification of SoR
The architecture draft does not give any way to do this
identification, if you need it, you have to provide the way to
do it. (Section 4.2)
8. Table 1
This table is very confusing, you are defining parameters, and
at the same time, you are inventing TVs. But in your 'possible
values' you mixed between CDAs and values.
So this Table gives a different approach that is not used in SCHC
9. New MO / CDA and functions
There are 3 new MO/CDA, I'm not sure you need all of them. They
have not been defined in the RFCs 8724, or 8824, nor the
architecture, so you need to present the need for these new
MO/CDA to see their feasibility
We can discuss but the "lower" CDA must be a "compute*"
The "generate" may also be a "compute*"
The MSB(start,end) and LSB (strat,end) functions, as I
understand you are using them for the range. It is another way
to do it, that needs consensus
Ana
On Thu, Jan 9, 2025 at 6:01 PM Daniel Migault
<mglt.i...@gmail.com> wrote:
Hi,
Please find the WGLC for our compressed ESP based on SCHC.
Feel free to share your reviews/comments.
Yours,
Daniel
---------- Forwarded message ---------
From: *Tero Kivinen* <kivi...@iki.fi>
Date: Wed, Jan 8, 2025 at 6:15 PM
Subject: [IPsec] WGLC for draft-ietf-ipsecme-diet-esp
To: <ipsec@ietf.org>
This will start two week WGLC for the
draft-ietf-ipsecme-diet-esp [1].
This last call will end at 2025-01-23. If you have any
comments about
the draft send them to the WG list.
[1]
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-diet-esp/
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
--
Daniel Migault
Ericsson
--
Schc mailing list -- s...@ietf.org
To unsubscribe send an email to schc-le...@ietf.org
