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