[IPsec] Re: WGLC for draft-ietf-ipsecme-diet-esp

[Daniel Migault <[e-mail]>]

Hi,

As a follow-up regarding the recent modifications implemented thus far, 
please find attached the current version of the draft [1] along with the 
diff view compared to the one in WGLC [2].

The questions that require clarification are as follows:

1. Should we take ESP alignment into account, or is it permissible to 
disregard it? I believe we should consider it.

2. How is the DSCP list negotiated? Should we base our description on 
draft-mglt-ipsecme-dscp-np, or should we incorporate the negotiation 
details into the draft-ietf-ipsecme-ikev2-diet-esp-extension draft?

Yours,
Daniel


[1] 
https://raw.githubusercontent.com/mglt/draft-mglt-ipsecme-diet-esp/refs/heads/master/draft-ietf-ipsecme-diet-esp.txt

[2] 
https://author-tools.ietf.org/diff?doc_1=draft-ietf-ipsecme-diet-esp&url_2=https://raw.githubusercontent.com/mglt/draft-mglt-ipsecme-diet-esp/refs/heads/master/draft-ietf-ipsecme-diet-esp.txt

On 2025-01-20 19:14, Daniel Migault wrote:
>
> Hi Valery,
>
> I apologize for the delay I missed this email. Thanks you very much 
> for the deep review. We have updated the draft accordingly. We do have 
> one remaining question regarding the 64 bit (or 32 bit) alignment for 
> the IPv6 ESP extension header (and IPv4 equivalent). I have the 
> impression it does not really apply to ESP, in which case we could 
> omit that AfRG completely.   Please find below some response comments.
>
>
> Yours,
> Daniel
>
> On 2025-01-16 08:11, Valery Smyslov wrote:
>> Hi,
>>
>> I reviewed draft-ietf-ipsecme-ikev2-diet-esp.
>>
>> Summary: I don't think that the document is ready.
>> There are many issues (or various severity) that need to be fixed.
>>
>> Issues.
>>
>> 1. Section 4.3.
>>
>>     The compression of the Inner IP Packet is based on the attributes
>>     that are derived from the negotiated Traffic Selectors TSi/TSr, as
>>     described in [RFC7296], Section 3.13.  The Traffic Selectors may
>>     result in a quite complex expression, and this specification
>>     restricts that complexity.  In particular, Diet-ESP restricts the
>>     Traffic Selector to a single type of IP address (i.e., IPv4 or IPv6),
>>     a single protocol (such as UDP, TCP, or not relevant), a single port
>>     range, and multiple DSCP numbers. Such simplification corresponds to
>>     the expression of an individual Traffic Selector Payload [RFC7296],
>>     Section 3.13.1.
>>
>> This text is problematic. Section 3.13.1 describes Traffic Selector (substructure)
>> and not a Traffic Selector payload (which is defined in Section 3.13).
>> In addition, traffic selectors, as defined in RFC 7296, cannot express DSCP,
>> thus I don't know how to interpret the above requirement.
>>
>> I believe the text tries to say that there MUST be only
>> one Traffic Selector (Section 3.13.1) in both TSi and TSr payloads
>> (described in Section 3.13). The TS Type MUST be
>> either TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE.
>>
>> (I don't know what to do with DSCP. The protocol and the TS type
>> are always single-valued in a Traffic Selector substructure).
>>
>> Perhaps my interpretation is not correct, but the current text needs to be revised anyway.
>
> <mglt>
>
> You are correct that "Traffic Selector Payload" should be substituted 
> with "Traffic Selector Substructure" or possibly "Traffic Selectors," 
> which aligns more closely with the terminology used in RFC 7296. 
> Additionally, it is accurate that "and multiple DSCP numbers" should 
> be omitted. The inclusion of DSCP likely stems from initial 
> considerations during the drafting of what ultimately became 
> draft-mglt-ipsecme-dscp-np. We concur that these elements do not 
> belong to the Traffic Selector.
>
> We originally aimed for the description of the compression to be 
> separate from the negotiation process of AfRGs. However, in light of 
> your additional suggestions, we are now incorporating more detailed 
> information regarding the negotiation of each AfRG through IKE. Our 
> objective is to potentially limit the description of the HCP IKE 
> extension to only those AfRGs that are actually negotiated by the HCP 
> IKE extension. We have thoroughly reviewed the text and propose the 
> following updates to our local copy.
>
> """
> The Traffic Selectors may result in a quite complex expression, and 
> this specification restricts that complexity.
> This specification restricts the resulting TSi/TSr to a single type of 
> IP address (IPv4 or IPv6), a single protocol (e.g., UDP, TCP, or ANY), 
> a single port range for source and destination. This specification 
> presumes that the Traffic Selectors can be articulated as a result of 
> CREATE_CHILD_SA with only one Traffic Selector {{!RFC7296, Section 
> 3.13.1}} in both TSi and TSr payloads (as described in {{!RFC7296, 
> Section 3.13}}). The TS Type MUST be either TS_IPV4_ADDR_RANGE or 
> TS_IPV6_ADDR_RANGE.
> """<mglt>
>
>> 2. Section 4.3, Table 1.
>>
>> For ts_ip_version parameter possible values listed as "IPv4-only IPv6-only".
>> Should they be "IPv4-only" "IPv6-only" instead?
> <mglt>You are correct, we replaced "IPv4-only IPv6-only" by 
> "IPv4-only" "IPv6-only" for ts_ip_version"</mglt>
>> Also s/IP4/IPv4     (two cases)
> <mglt>You are correct, we replaced the two occurences of "IP4" by 
> "IPv4". </mglt>
>> Why "64 bit" parameter denotes its own empty row? Should it be along with
>> possible alignment values? The same question for  ANY, ... and
>> "generated", "zero"  empty rows. Perhaps they should be merged with the above cells.
> .
> <mglt>It seems a issue that happen during the markdown conversion. We 
> will look into that. </mglt>
>> 3. Section 4.3
>>
>>     This specification limits the expression of the Traffic Selector to
>>     be of the form (IP source range, IP destination range, Port source
>>     range, Port destination range, Protocol ID list, DSCP list).  This
>>     limits the original flexibility of the expression of TS, but provides
>>     sufficient flexibility.
>>
>> This is not consistent with the text above, since the text above
>> requires that there be only one protocol and not the list.
>> And again, DSCP values cannot be expressed in IKEv2 Traffic Selectors.
> <mglt>You are correct. There is no more Protocol ID list or DSCP in 
> the TS and the text has been updated.</mglt>
>
>> 4. Section 4.3.
>>
>> It is not very clear for me what iipc_profile is for. In other words,
>> if the value is "diet-esp", then what it means? Does it mean
>> that only those parameters, defined in Table 1 for IIPC must be used?
>> Should the application verify this? Should all these parameters be supported
>> or it is allowed to support only some of them? I'd like to see more
>> discussion of this in the draft. Perhaps external reference to
>> some SCHC document is needed.
>
> <mglt>
>
> The iipc_profile specifies the method of compressing the inner packet, 
> which can either be "uncompressed" or "diet-esp". This document 
> outlines the Diet-ESP compression protocol, which provides two options 
> for compressing the inner IP packet: "diet-esp" and "uncompress." 
> These iipc_profiles can be regarded as configuration parameters. An 
> implementation that adheres to this protocol is anticipated to support 
> both "diet-esp" and "uncompress." The details of the compression 
> process are elaborated in section 5.1, which explains how the values 
> are managed by Diet-ESP. To  enhance clarity we referred to 
> iipc_profiles- that can be seen as sub profiles - with "iipc_diet-esp" 
> and "iipc_uncompress".
>
> </mglt>
>
>> 5. Section 4.3.
>>
>> Please, expand the text for possible values for dscp_cda and ecn_cda
>> instead of sending readers to flow_label_cda by "(See flow_label_cda)".
>> The list of values is different, so it is better to repeat their meaning
>> for each parameter.
> <mglt>We expanded the text to explain the values. We also expanded the 
> text of the variable themselves.</mglt>
>> 6. Section 4.3.
>>
>> The explanations for dscp_cda and ecn_cda both start with the text
>> "indicates how the DSCP values of the inner IP packet are generated.".
>> Unless I'm badly missing something, this should be s/generated/compressed / decompressed
> <mglt>You are correct, your wording seems more appropriated. We 
> changed it as suggested.</mglt>
>> 7. Section 4.3
>>
>> ts_ip_dst_start, ts_ip_dst_end, ts_port_dst_start, ts_port_dst_end  are not explained in the text.
> <mglt>Correct. We added them. These have probably been lost as we used 
> to have ts_ip_src/dst_start. </mglt>
>> 8. Section 4.3
>>
>> Please, expand LSB and MSB on first use (I presume Least /Most Significant Bits).
> <mglt>We expanded them.</mglt>
>> 9. Section 4.3.
>>
>> In the text related to ts_proto - why RFC 5996 is referenced? It is obsoleted by RFC 7296.
> <mglt> The reason for keeping 5996 is that ANY is not defined in 7296. 
> This is something we noticed and had updated to The representation of 
> "ANY" is given in {{!RFC4301, Section 4.4.4.2}}. on our local copy. 
> </mglt>
>
>> 10. Section 4.3.
>>
>> The text related to dscp_list parameter informally references the expired draft draft-mglt-ipsecme-dscp-np.
>> In my reading of this text, it is impossible to implement this draft without reading
>> draft-mglt-ipsecme-dscp-np (at least this is my impression). Thus, reference
>> to draft-mglt-ipsecme-dscp-np should be normative, whichm in my understanding, makes impossible
>> publication of this document unless draft-mglt-ipsecme-dscp-np becomes RFC.
>> Alternatively, please rewrite the text so, that draft-mglt-ipsecme-dscp-np is not needed
>> for implementing this document.
>
> <mglt>
>
> You are correct that the relationship to draft-mglt-ipsecme-dscp-np 
> necessitates further discussion, as it has not yet been adopted in the 
> charter. The draft-mglt-ipsecme-dscp-np outlines the process by which 
> peers reach an agreement on DSCP code points through an IKEv2 Notify 
> Payload.
>
> We need to see if there is a way to move draft-mglt-ipsecme-dscp-np to 
> a standard track otherwise, we will have to include the negotiation in 
> draft-ietf-ipsecme-diet-esp-ikev2-extension. Our preference would be 
> to leverage on draft-mglt-ipsecme-dscp-np, as we believe that such 
> DSCP negotiation could be beneficial for various other applications. 
> However we remain open to suggestions. </mglt>
>> 11. Section 4.3.
>>
>> The text related to alignment parameter is very problematic. I cannot figure out what it is all about.
>> For example, "indicates the byte alignement supported by the OS for the ESP extension." What is "supported by OS"?
>> What is "ESP extension"? What should be aligned?
>> Why 32-bit alignment is for IPv6? As far as I remember, the IPv6 header should be 64-bit aligned,
>> 32-bit alignment is used for IPv4. Am I missing something?
>> Since AES-CCM is mentioned, I presume that alignment in fact means not a requirement
>> for the start of payload alignment, but instead the requirement for the total size of the payload
>> to be encrypted to be multiple of the encryption transform block size. If this is the case,
>> then this should be spelled out more accurately. In addition, the block size can be different
>> from 128 bits (for example, for GOST "Magma" it is 64 bits, there may also be defined
>> encryption transforms with 256-bit block size in future), so this should be expressed more accurately,
>> referencing the requirements imposed by encryption transform.
>> By the way, possible values for alignment do not include "128 bits", so the text
>> related to AES-CCM "a 128 bit alignment is overwritten by the block size" cannot be parsed by me.
>>
>> BTW, a typo: s/alignement/alignment
>>
> <mglt>
> We appreciate you bringing this issue to our attention. It appears 
> there has been a discrepancy in the numbers for the IP4 and IPv6 
> extension header alignment. This alignment parameter is not related to 
> the block size of the encryption algorithm, but solely to the 
> alignment of the ESP extension header. As you mentioned, there is 
> another alignment associated with the block cipher block length, which 
> we have linked to the ESP encryption algorithm (esp_encr). 
> Importantly, the ESP Padding and Pad Length must be generated to meet 
> both (1) the requirement that the Clear Text ESP matches the block 
> cipher size (block len(Payload Data) + len(Padding) + 1 = 0 
> %block_size) and (2) the requirement that the entire ESP extension 
> meets the alignment specifications (compressed ESP Header + len(IV) + 
> x block_size = 0 % alignment). I am addressing these discussions 
> separately, and here I am focusing solely on the alignment, as I 
> believe this is potentially something we can remove. The discussion 
> regarding the block_size is covered in the esp_encr section related to 
> comment 13.
>
> In light of RFC8200 and RFC4303, I am curious whether the 64-bit 
> alignment for IPv6 is applicable to the Encapsulating Security Payload 
> (ESP). Given that generic extension headers and options express their 
> lengths in 8-octet units, they must be aligned to 64 bits. This 
> alignment allows us to potentially bypass the current option or 
> proceed to the next option without the need to parse the extension 
> header or option.
>
> RFC8200 section 4 states:
>
> """
>
> Each extension header is an integer multiple of 8 octets long, in
>     order to retain 8-octet alignment for subsequent headers.  Multi-
>     octet fields within each extension header are aligned on their
>     natural boundaries, i.e., fields of width n octets are placed at an
>     integer multiple of n octets from the start of the header, for n = 1,
>     2, 4, or 8.
>
> """
>
> Conversely, ESP is a mandatory component of IPv6 and is always 
> positioned as the last extension header. Consequently, IPv6 must be 
> capable of parsing ESP, and there are no subsequent headers to 
> consider. Furthermore, the length of the ESP extension is determined 
> by the IPv6 Payload Length field, which is a 16-bit integer 
> representing bytes, rather than an 8-byte word. Based on RFC8200, I am 
> uncertain whether this restriction is applicable.
>
> Upon further examination of RFC4303, the payload data section indicates:
>
> """
> Note that the beginning of the next layer protocol header MUST be
>     aligned relative to the beginning of the ESP header as follows.  For
>     IPv4, this alignment is a multiple of 4 bytes.  For IPv6, the
>     alignment is a multiple of 8 bytes.
> """
>
> The definition of the next layer protocol header is somewhat 
> ambiguous. If it refers to the layer that follows the ESP payload, 
> then there is none, as ESP is the final extension header, and thus the 
> alignment condition does not apply. Alternatively, if the next layer 
> protocol pertains to the Payload Data indicated by esp.next_header, 
> then the condition seems to imply that the Security Parameter Index 
> (SPI) and Sequence Number (SN) and IV must be 8 bytes aligned. This 
> situation appears rather peculiar. Therefore, unless I am overlooking 
> something, it seems to me that we could entirely eliminate the constraint.
>
> It is essential to assess the current status of IPv4. However, 
> concerning IPv6, I believe we can disregard any previous 
> considerations related to alignment.
>
> </mglt>
>> 12. Section 4.3.
>>
>> Text related to tunnel_ip states that it "can be an IPv4 or IPv6 address". However,
>> in the Table 1 only IPv6 address is allowed.
> < mglt> You are correct, we added IPv4 as well in the Table 1.</mglt>
>
>> 13. Section 4.3.
>>
>> Text related to esp_encr - I fail to understand why knowing the encryption algorithm is needed
>> for compression. Perhaps this should be clarified.
>>
>> BTW, a typo: s/compresse/compress
>
> <mglt>We clarified this in the section defining the AfRG as follws:
>
> esp_encr:
> : designates the ESP Encryption Algorithm - also designated as 
> Transform 1 in {{!RFC7296, Section 3.3.2}}. The algorithm is needed to 
> determine whether the ESP Payload Data needs to be aligned to some 
> predefined block size and if the ESP Pad Length and Padding fields can 
> be compressed.  For the purpose of compression it is RECOMMENDED to 
> use algorithms that already compressed their IV {{!RFC8750}}.
>
> </mglt>
>
>> 14. Section 4.3.
>>
>> s/Security Policy Index/Security Parameter Index
> <mglt>Thanks. we updated the text.</mglt>
>> 15. Section 4.3.
>>
>> Text for esp_sn_lsb: "and is defined by this specification". Is this clarification needed for this parameter?
>> I believe many parameters listed above are also defined by this specification, but it is only mentioned for esp_sn_lsb.
>>
>> In addition - why possible values for this parameter are 0-64?
>> SN in the ESP header is always 32 bits in length, for 64-bit ESN the upper 32 bits are never transmitted.
> <mglt>you are correct, we removed "and is defined by this 
> specification" and possible values are limited to 32 as we only 
> compress bits on the wire. The virtual ones do not take too much 
> bandwidth.;-)</mglt>
>> 16. Section 5.1.1
>>
>> If you add some table similar to Table 1, with FL, MO, CDA values for each parameter,
>> it will make reading easier. Alternatively, place description of compressing each field to its own paragraph.
>> The current text is difficult to read.
> <mglt>The challenge we face is that the FL and MO CDA outline the 
> compression methods for fields within the inner IP packet. These 
> compression guidelines are contingent upon the different combinations 
> of the AfRG parameters detailed in Table 1. The SCHC parameters are 
> more pertinent when derived from IP fields and specific AfRGs, 
> resulting in a considerable number of potential combinations. Annex 
> A.1 appears to offer an example of a rule set that can be formulated 
> for a particular scenario. We will consider this, although I 
> anticipate that achieving a more lucid representation than a textual 
> description may prove difficult.</mglt>
>> 17. Section 5.1.3.
>>
>> In the text "If the IP Header is an IPv6 Header" perhaps "tunnel" is missing before "IP"?
> <mglt>You are correct. Thanks!.<mglt>
>> 18. Section 5.1.3.
>>
>> Please expand "IHL" (Internet Header Length).
> <mglt> We expanded it.</mglt>
>> 19. Section 5.3.
>>
>>     SCHC Compression efficiently compresses the Next Header field,
>>     reducing overhead and aligning the packet to byte boundaries using
>>     SCHC Padding.  After this, the SCHC Pad Length field is added.
>>
>> It is not clear for me what is the sequence of applying various actions.
>> >From my understanding the SCHC Padding is applied before CTEC compression,
>> but reading this text it seems that it is applied after it too. Is it applied twice?
> <mglt> No. It is implemented subsequent to the compression of the 
> inner packet. The rationale behind this is to ensure that the Data 
> Payload is represented in bytes to be encrypted. We significantly 
> rewrote the section 5.2 that explains the SCHC padding and it role 
> over the ESP Payload Data as well as Section 5.3 which details the 
> clear text ESP .<mglt>
>> 20. Section 5.3.
>>
>>     The ESP Padding and Pad Length fields are reduced by the SCHC
>>     compression rule.
>>
>> I fail to understand how this can be done. The padding is included
>> into the ICV computation, I don't know how you are going to elide these bytes.
> <mglt> We remove them before the encryption when encryption makes it 
> possible to remove them - that is we do not need any alignment.</mglt>
>> 21. Section 5.3.
>>
>> Isn't IPv6 require 64-bit alignment and not 32?
>
> <mglt>yes we need to clarify this over the two drafts. This is related 
> to the discussion of comment 11. I currently believe it does not 
> impact our design. </mglt>
>
>
>> 22. Section 5.4.
>>
>> I fail to understand why there is a need to send SN uncompressed
>> in case of implicit IV. In any case, you *must* be able to decompress
>> SN to an original value *before* decrypting the packet. If there is a chance
>> SN is decompressed incorrectly, then the packet will be dropped anyway
>> (due to ICV verification failure). As a consequence - the esp_encr
>> parameter is not needed.
> <mglt>This is correct. We need to clarify this in the text. We 
> actually do not consider the case SN are omitted. </mglt
>> 23. Section 5.4.
>>
>>     The IPv6 Next Header field or the IPv4 Protocol field that contains
>>     the "ESP" value is changed to "SCHC".
>>
>> What is the value for "SCHC"? I failed to find it in IANA registry
>> https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
>
> <mglt>The current document describing the SCHC protocol number is the 
> one below. As the document is also requesting port number which seems 
> a bit more controversial.
>
> https://datatracker.ietf.org/doc/draft-ietf-schc-protocol-numbers/
>
> I am currently thinking making it only optional as it is only could be 
> useful if we want to differentiate the traffic of the Compressed ESP 
> from the one non-Compressed ESP.
>
> </mglt>
>
>> 24. Section 7.
>>
>> Where the mentioned IANA registries are situated?
>> I failed to find any "IIPC Profile" registry on IANA website.
>>
>>   
>
> <mglt>In Section 7. We request the creation of that registry. </mglt>
>> Regards,
>> Valery.
>>   
>>
>>
>>> 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/
>>> --
>>> [e-mail]
>>>
>>> _______________________________________________
>>> IPsec mailing list [e-mail]
>>> To unsubscribe send an email [e-mail]
>> _______________________________________________
>> IPsec mailing list [e-mail]
>> To unsubscribe send an email [e-mail]