Dear Sandra and Daniel,
Sorry to have been not so responsive, but I missed this version of the
document.
This version is much clearer, but I need to understand more about IKE to
make the link between IKE and SCHC.
It is not clear to me if you use regular information or you carry them into
extensions of IKE.
Below are some comments on the first part of the draft. I think it requires
some coordination with the SCHC WG to define missing elements, such as IPv4
header compression or new MO/CDA.
If you want we can have a call to discuss it.
Laurent
---------
Abstract
This document specifies Diet-ESP, a compression mechanism for control
information in IPsec/ESP communications. The compression is
expressed through the Static Context Header Compression architecture.
LT => Maybe the introduction should be revised, I don't understand the
meaning.
In my view, it uses SCHC rules and SCHC compression.
...
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
| Security Parameter Index (SPI) | ^Auth.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cove-
| Sequence Number | |rage
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
| ESP Data Payload (variable) | | ^
~ Higher Layer Message (transport) or IP datagram (tunnel) ~ | |
| | |Encr.
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cove-
| | ESP Padding (0-255 bytes) | |rage
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Next Header | v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| Integrity Check Value-ICV (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Top-Level Format of an ESP Packet
LT=> The link between the figure 1 and the decription above and the
different
level (stratum) of compressis is hard to follow, especially because the
boudaries are not clear.
Table 2 gives a nice vision of a compression rule. This rule constains
first an IPv4/UDO headers, followed by ESP Padding and Byte Aligment.
(the pad length and next header are missing), follwowed by SPI/SN.
I understand your need to have a simple architecture, with a limited number
of rules, but I don't see how you can process it as a single rule, since
after that, you apply 3 compressions (cf. Figure 2 and the text below).
2.1. The Three Compressors Described in this Specification
The document outlines the three compressors utilized in Diet-ESP,
which are detailed as follows:
1. Inner IP Compression (IIPC): The original packet to be protected
by ESP, namely, the Inner IP packet (IIP), is split into a Header
subject to compression and a Payload (see Section 4 for more
details). The process in the IIPC pertains to the compression
and decompression of fields of the Header of the IIP. For
outbound packets, after IIPC, ESP incorporates the compressed
Header and the (unaltered) Payload of the IIP into the ESP Data
Payload of a Clear Text ESP packet (CTE) (refer to Figure 1). In
the case of inbound packets, decompression occurs after the
compressed Header is retrieved from the ESP Payload Data within
the CTE.
LT=> CTE does not appear in figure 1?
Migault, et al. Expires 9 October 2025 [Page 4]
Internet-Draft EHCP April 2025
2. Clear Text ESP Compression (CTEC): This process pertains to the
compression and decompression of the segment of the ESP packet
that is destined for encryption. This encompasses the ESP Data
Payload and the ESP Trailer, which includes the Padding, Pad
Length, and Next Header fields, as illustrated in Figure 1. For
the CTEC stage, only these three ESP Trailer fields are eligible
for compression. For outbound packets, ESP subsequently encrypts
the compressed CTE packet. For inbound packets, decompression
takes place following the decryption process of the ESP.
3. Encrypted ESP Compression (EEC): This process pertains to the
compression and decompression of the Encrypted ESP packet (EE),
which consists of the ESP Header, the encrypted payload, and the
Integrity Check Value (ICV). Since neither the encrypted payload
nor the ICV can be compressed, only the ESP Header, specifically
the SPI and SN fields, is subject to compression.
2.2. The Scope of SCHC in this Specification
SCHC [RFC8724] offers a mechanism for header compression as well as
an optional fragmentation feature. SCHC facilitates the compression
and decompression of headers by utilizing a common context that may
encompass multiple Rules. Each Rule is designed to correspond with
specific values or ranges of values within the header fields. When a
Rule is successfully matched, the corresponding header fields are
substituted with the Rule ID and the Compression Residue. The
Compression Residue for the packet header is the concatenation of the
non-empty residues for each field of the header. The Compression
Residue is directly followed by the packet payload and an optional
padding to ensure byte alignment.
This document utilizes SCHC as a practical means to illustrate the
capability to compress and decompress a structured payload. It is
important to note that any elements of SCHC that pertain to aspects
other than compression or decompression, such as fragmentation, fall
outside the purview of this document. The reference to SCHC herein
is solely for descriptive purposes related to compression and
decompression, and it is not anticipated that the general SCHC
framework will be integrated into the ESP implementation. The
structured payloads addressed in this specification pertain to
internal structures managed by ESP for the processing of an IP
packet. Consequently, the compression and decompression processes
outlined in this document represent supplementary steps for the ESP
stack in handling the ESP packet.
...
4. Diet-ESP Integration into the IPsec Stack
Figure 2 depicts the incorporation of Diet-ESP within the IPsec
framework.
...
When an Inner IP packet (IIP) is received, IPsec identifies the SA
linked to that packet. Upon the ESP determining the IIPC Rule from
LT=> Maybe indicate that it's an incoming packet that needs to be
compressed.
the AfRG contained within the SA, the IIPC separates the IIP into
Header and Payload, and compresses the Header. The compressed Header
is composed of RuleID, Compressed Residue, and an optional padding
field. The original Payload of the IIP is then appended after the
compressed Header (IIPC: C{Header}, Payload). Subsequently, ESP
LT=> The architecture draft proposed to use parentheses to indicate
compression, but your notation is also valuable.
constructs the Clear Text ESP packet (CTE). The CTEC Rule is derived
from the AfRG of the SA, allowing for the compression of the CTE
(CTEC: C {C{Header}, Payload, ET}, where ET represents the ESP
LT=> I don't feel confortable with "recursive compression", for me it is
more
two successive compression, you have first C{Header}Payload which is
encrypted,
followed by C{ET}. I would prefer, if I'm not wrong someting like:
E{C{Header}, payload},C{ET}
where E{} indicates encryption and C{} compression.
...
4.1. SCHC Parameters for Diet-ESP
...
The 1 byte
may be used in future implementations to support multiple flows over
the same SA.
LT=> SCHC does not impose a length for RuleID, since they are organised on
a binary tree. What is not clear to me, is the relation between a SA and a
rule.
I was thinking that the SA was used to derive a rule, so in that condition,
you
need a single rule (no rule ID is needed).
...
4.2. Attributes for Rule Generation
The list of attributes for the Rule Generation (AfRG) is shown in
Table 1. These attributes are used to express the various
compressions that operate at the IIPC, CTEC, and EEC.
As outlined in Section 4, this specification does not detail the
process by which the AfRG are established between peers. Instead,
such negotiations are addressed in
[I-D.ietf-ipsecme-ikev2-diet-esp-extension]. However, the AfRG can
be classified into two distinct categories. The first category
encompasses AfRG that are negotiated through a specific IKEv2
extension tailored for the negotiation of AfRG linked to a particular
profile, the Diet-ESP profile in this context. The AfRG referenced
in Table 1 in this category are: the DSCP Compression/Decompression
Action (CDA) dscp_cda, the ECN CDA ecn_cda, the Flow Label CDA
flow_label_cda, the ESP alignment alignment, the ESP SPI Least
Significant Bits (LSB) esp_spi_lsb, and the ESP Sequence Number LSB
esp_sn_lsb.
LT=> it take me time to understand, in fact you are providing the CDA
value that will be set in the rule for a specific field.
The second category pertains to AfRG that are negotiated through
IKEv2 exchanges or extensions that are not specifically designed for
compression purposes. This category includes AfRG associated with
TS, as identified in Table 1, which are the TS IP Version
ts_ip_version, the TS IP Source Start ts_ip_src_start, the TS IP
Source End ts_ip_src_end, the TS IP Destination Start
ts_ip_dst_start, the TS IP Destination End ts_ip_dst_end, the TS
Protocol ts_proto, the TS Port Source Start ts_port_src_start, the TS
Port Source End ts_port_src_end, the TS Port Destination Start
ts_port_dst_start, and the TS Port Destination End ts_port_dst_end.
These AfRG are derived from the Traffic Selectors established through
TSi/TSr payloads during the IKEv2 CREATE_CHILD_SA exchange, as
described in [RFC7296], Section 3.13. The AfRG IPsec Mode designated
as ipsec_mode in Table 1 is determined by the presence or absence of
the USE_TRANSPORT_MODE Notify Payload during the CREATE_CHILD_SA
exchange, as detailed in [RFC7296], Section 1.3.1. The AfRG Tunnel
IP designated as tunnel_ip in Table 1 is obtained from the IP address
of the IKE messages exchanged during the CREATE_CHILD_SA process, as
noted in [RFC7296], Section 1.1.3. The AfRGs designated as ESP
Encryption Algorithm esp_encr and ESP Security Parameter Index (SPI)
esp_spi in Table 1 are established through the SAi2/SAr2 payloads
during the CREATE_CHILD_SA exchange, while the AfRG designated as ESP
Sequence Number esp_sn in Table 1 is initialized upon the creation of
the Child SA and incremented for each subsequent ESP message. The
DSCP values identified as dscp_list in Table 1 are established
through the DSCP Notify Payload [I-D.mglt-ipsecme-dscp-np].
LT=> This part raises some questions that must be covered by the SCHC WG.
- There is no compression defined for IPv4 in the SCHC WG, sdo you want
the group to work on that? For instance, how is handled the IPv4
identification field ?
- I don't understand the use of "msb" in the TV of rule given in Table 2.
May be
a new MO should be created. for instance in_delta, which indicates that the
FV is between the TV and TV+delta. A CDA delta-sent send the value FV-TV (In
my view we should avoid negative numbers to avoid complex coding of delta).
...
flow_label_cda: indicates the Flow Label CDA, that is how the Flow
Label field of the inner IPv6 packet or the Identification field
of the inner IPv4 packet is compressed / decompressed - See
Section 4.2.1 for more information. In a nutshell,
"not_compressed" indicates that Flow Label (resp. Identification)
LT=> I don't understand the difference between not-compressed and
value-sent.
On Mon, Mar 17, 2025 at 2:15 AM Daniel Migault <mglt.i...@gmail.com> wrote:
> Hi,
>
> Please find the updated drafts that outline diet-esp [1] and its
> corresponding IKEv2 extension [2]. We extend our gratitude for the feedback
> received from both the IPsec and SCHC perspectives during the Working Group
> Last Call (WGLC).
>
> We believe that these versions adequately address all comments provided by
> the IPsecme Working Group and the SCHC Working Group. Additionally, we have
> implemented and validated the necessary changes.
>
> Diet-esp incorporates the agreement on Differentiated Services Code Point
> (DSCP) as part of the compression context. Consequently, the management of
> DSCP should not be left to the classifier operated locally by each peer.
> While we could have included the negotiation in [2], we contend that the
> DSCP negotiation merits its own extension in a separate document, as this
> represents the second use case we have encountered. We seek the working
> group's opinion.
>
> Yours,
>
> Daniel
>
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-diet-esp/
> [2]
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-diet-esp-extension/
> [3] https://datatracker.ietf.org/doc/draft-mglt-ipsecme-dscp-np/
> On 2025-02-14 17:51, Daniel Migault wrote:
>
> Hi,
>
> A newly updated version of the Diet-ESP description has been released [1].
> This iteration focuses on its compatibility with SCHC and includes more
> explicit examples in the appendix. We look forward to engaging in further
> discussions within the SCHC Working Group next week.
>
> We welcome any additional feedback you may have.
>
> Yours,
> Daniel
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-diet-esp/
>
>
> On 2025-01-27 03:40, Laurent Toutain wrote:
>
> Hi Daniel,
>
> May be it is clear from a IPsec perspective, but not from a SCHC
> perspective.
>
> I think that to be called SCHC, the compression description in your draft
> must be aligned with the vocabulary on RFC8724 and forthcoming
> architecture. The notion of rule looks ambiguous in your draft, looks more
> like an entry in the SCHC terminology, making hard to follow where you are
> going. Same thing for the tables, in RFC 8724 and 8824 you have an
> "unformal" way to describe how the header fields are compressed. This has
> to be defined. This helps also to create the augmentation the RFC9363 Data
> Model to add the FID and MO/CDA you are defining in your draft.
>
> We can work on it if you want.
>
> Laurent
>
> On Mon, Jan 27, 2025 at 3:03 AM Daniel Migault <mglt.i...@gmail.com>
> wrote:
>
>> Hi,
>>
>> This iteration has taken into account a considerable number of comments
>> that have been received to date. While some comments related to SCHC are
>> still pending resolution, those concerning IPsec appear to have been
>> addressed. Consequently, this version can serve as a solid foundation for
>> subsequent reviews.
>>
>> The current version is available here:
>> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-diet-esp/
>>
>> The diff can be seen here:
>>
>> https://author-tools.ietf.org/diff?doc_1=draft-ietf-ipsecme-diet-esp-04&doc_2=draft-ietf-ipsecme-diet-esp-03
>>
>> Yours,
>> Daniel
>>
>>
>> On 2025-01-23 14:51, Ana Minaburo wrote:
>>
>> 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
>>>
>> --
>> Schc mailing list -- s...@ietf.org
>> To unsubscribe send an email to schc-le...@ietf.org
>>
>
>
> --
> Laurent Toutain
> +------ VoIP (recommended) ---+--- Télécom Bretagne --- +
> | Tel: +33 2 22 06 8156 | Tel: + 33 2 99 12 7026 | Visit :
> | Fax: +33 2 22 06 8445 | Fax: +33 2 99 12 7030 |
> http://class.touta.in
> | laur...@touta.in | laurent.tout...@telecom-bretagne.eu
> +----------------------------------------+--------------------------------+
>
>
--
Laurent TOUTAIN
Enseignant Chercheur
02 99 12 70 26 <0299127026> - 06 80 07 59 00 <0680075900>
[image: IMT Atlantique] <https://www.imt-atlantique.fr/>
Une école de l'IMT <https://www.imt.fr/>
Technopôle Brest-Iroise CS 83818 29238 Brest Cedex 3
La Chantrerie 4 rue Alfred Kastler CS 20722 44307 Nantes Cedex 3
2, rue de la Châtaigneraie CS 17608 35576 Cesson Sévigné Cedex
www.imt-atlantique.fr
[image: LinkedIn IMT Atlantique]
<https://www.linkedin.com/school/24772587/>[image:
Instagram IMT Atlantique] <https://www.instagram.com/imt_atlantique/>[image:
Facebook IMT Atlantique] <https://www.facebook.com/IMTAtlantique>[image:
YouTube IMT Atlantique] <https://www.youtube.com/c/imtatlantique>
Toute l'actualité scientifique de l'IMT : I'MTech <https://imtech.imt.fr/>
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
