Hi,
Thank you, Laurent, for your feedback. We initially believed we could reply
quickly, but due to scheduling conflicts, we now anticipate providing a
response and addressing them by next week at the latest.
Yours,
Daniel
On Tue, Apr 29, 2025 at 9:01 AM Laurent Toutain <laur...@touta.in> wrote:
> 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/>
>
--
Daniel Migault
Ericsson
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
