Hello Ana,
Please see my comments below. The updated text was pushed in version -04 over
the weekend.
Best,
Sandra.
________________________________________
From: Ana Minaburo <anaminab...@gmail.com>
Sent: Thursday, January 23, 2025 14:51
To: Daniel Migault <mglt.i...@gmail.com>
Cc: s...@ietf.org <s...@ietf.org>; ipsec@ietf.org <ipsec@ietf.org>
Subject: [Schc] Re: Fwd: [IPsec] WGLC for draft-ietf-ipsecme-diet-esp
Attention This email originates from outside the concordia.ca domain. // Ce
courriel provient de l'extérieur du domaine de concordia.ca
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.
[SC] I changed the part where we defined Context as follows (note, however,
that the definition of Context (not SCHC Context) still exists in the SCHC
architecture document, Terminology section).
OLD:
Compression with SCHC is based on the use of a Set of Rules (SoR) used in a
SCHC instance for C/D operations {{?I-D.ietf-schc-architecture}}. One or more
SoR constitute the SCHC Context. In the case of IPsec, the Context can be
agreed via IKEv2 {{!RFC7296}} and its specific extension
{{!I-D.ietf-ipsecme-ikev2-diet-esp-extension}}.
NEW
Compression with SCHC is based on one or more SCHC instances, each with its Set
of Rules (SoR) for C/D operations {{?I-D.ietf-schc-architecture}}. In the case
of IPsec, the SoR for a SCHC session can be agreed via IKEv2 {{!RFC7296}} and
its specific extension {{!I-D.ietf-ipsecme-ikev2-diet-esp-extension}}.
- You need to add the SCHC Strata
[SC] Done. I aligned the text in the introduction to mention that each stratum
has a SCHC header instance and may generate a SCHC Packet with a SCHC Header.
The intermediate layer (CTEC) does not have a SCHC Header since the encryption
happens in the same entity right in the layer below.
- You need to define the SCHC Header Instances
[SC] We will update Fig. 4 to reflect the SCHC Headers and SCHC Payload at each
stratum.
- You need to align your terminology section to draft-architecture
[SC] Done.
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?
[SC] I changed the text to align it with the description of SCHC Session
Manager and SCHC Instances in the latest SCHC architecture draft.
OLD:
Each SoR indicates the ESP header fields to be matched by the rules. The SCHC
instances define how the SCHC Context is initialized from the SA and generate
the corresponding SCHC rules (i.e., RuleID, SCHC MAX_PACKET_SIZE, new SCHC
Compression/Decompression Actions (CDA), and fragmentation). The appendix
provides illustrative examples of applications of EHCP implemented with the
OpenSCHC
[OpenSCHC<https://www.ietf.org/archive/id/draft-ietf-ipsecme-diet-esp-03.html#OpenSCHC>].
NEW:
The Rules of type C/D describe the behavior of each header field in the ESP
header. A SCHC Session manager provides the management of SCHC Instances with a
definition of how the SoR and the SoV are initialized from the SA (i.e.,
RuleID, SCHC MAX_PACKET_SIZE, new SCHC Compression/Decompression Actions (CDA),
and fragmentation). The appendix provides illustrative examples of applications
of Diet-ESP implemented with the OpenSCHC
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.
[SC] Fragmentation may still happen, it is just out of the scope of this
document. I guess we could change the title to "ESP Header Compression with
SCHC" and no longer use the "profile" term in the document. I'll hear other
opinions about this from the WG.
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
[SC] ESP requires byte alignment to encrypt.
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.
[SC] Yes. It was clarified in the text to avoid the confusion.
OLD:
Similarly to the SA, Rules are directional and the Direction Indicator (DI) is
set to Up for outbound SA and Down for inbound SA. Each Rule also contains a
Field Position parameter that is set to 1, unless specified otherwise.
NEW:
A rule describes all the header fields required for a certain transformation
(e.g., compression, decompression, fragmentation, reassembly, etc.). The fields
are identified by a Field ID (FID). Fields may include a Direction Indicator
(DI), which in Diet-ESP is set to Up for an outbound SA and Down for an inbound
SA. Each field also contains a Field Position parameter that is set to 1,
unless specified otherwise.
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)
[SC] Yes. There are specific IDs in the ESP header that will serve as
discriminators. We will provide this in the draft as you suggest.
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
[SC] The table was supposed to indicate the set of variables, their source
specification, and the SCHC Stratum where they will be used to help generate
the SoR. The labels of the table were modified to reflect that.
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
[SC] As Daniel mentioned, we are open to suggestions on how to apply compute in
replacement to the new MO/CDA
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
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
