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

[Daniel Migault <[e-mail]>]

Hi Valery,

Thanks for the additional guidance. We will update the drafts and share 
them shortly.

Yours,
Daniel

On 2025-01-17 03:16, Valery Smyslov wrote:
>
> Hi Daniel,
>
> thank you for the explanation, please see inline.
>
> Hi Valery,
>
> Thanks for your review. We will promptly address your comment and 
> update the draft. Please let me respond to your questions/reviews below.
>
> Yours,
>
> Daniel
>
> On 2025-01-16 08:11, Valery Smyslov wrote:
>
>     Hi,
>
>     I reviewed draft-ietf-ipsecme-ikev2-diet-esp-extension.
>
>     Summary: I don't think that the document is ready.
>
>     With the current text I have trouble reading it as implementer.
>
>     Issues:
>
>     1. Section 2.
>
>         Certain AfRG have already been
>
>         established during the SA negotiation process through IKEv2.  This
>
>         extension facilitates the agreement on the remaining AfRG through
>
>         IKEv2.
>
>     >From my reading of this text, the negotiation of some AfRGs is defined
>
>     elsewhere. I don't think this is correct.
>
> <mglt>
>
> I beleive this assertion holds true, as certain parameters of the AfRG 
> have already been negotiated through IKEv2, such as TS or IPsec mode, 
> for instance. While these parameters are not explicitly categorized as 
> AfRG, they serve as inputs for defining the compression. Since we 
> refer to these inputs as AfRG for the purpose of defining compression, 
> we consider these parameters as being negotiated via IKEv2.
>
> The AfRGs are referenced in draft-ietf-ipsecme-diet-esp, specifically 
> in Table 1. Only six parameters require a specific negotiation, which 
> is achieved by this extension.
>
> We will focus on refining and clarifying the language used.
>
>  </mglt>
>
> I believe that all this should be explained in the draft. Moreover, I 
> think that there should be an explanation
>
>          of how _/each/_ of the remaining parameters is getting its 
> value. For example:
>
>        “The TV for ts_port_src_start is taken from the “Start Port” 
> field of the Traffic Selector of TSi payload
>
>        in the request message.”
>
>        This should be spelled out for each implicitly negotiated 
> parameter, currently implementers
>
>        have to guess this. I’d also like to see the FID, MO and CDA 
> values for each parameter.
>
>        Perhaps a table similar to Table 1 in diet-esp draft, but with 
> more columns, would help.
>
<mglt2>
I understand. It is essential that this information is explicitly 
outlined either in the definition of the profile or within its 
corresponding IKE extension. My initial consideration was to 
differentiate the drafts between draft-ietf-ipsecme-diet-esp, which 
specifies the compression and assumes that all necessary parameters 
(AfRGs) are available, and draft-ietf-ipsecme-ikev2-diet-esp-extension, 
which elaborates on how all parameters are agreed upon through IKE. As 
we revised draft-ietf-ipsecme-diet-esp, we provided detailed information 
regarding the IKE payloads and subfields necessary for deriving the 
AfRG. Consequently, I believe this document could effectively narrow its 
focus to the additional AfRGs that still require negotiation.

Regarding the FL MO CDA value, as I noted in my previous response to the 
diet-esp compression document, it may prove somewhat challenging to 
provide anything beyond a textual description. However, we will strive 
to document this in a clear manner.
</mglt2>

>     2. Section 3.
>
>     I think that it is better to replace the term "Proposal Payload"
>     with just "Proposal"
>
>     or "Proposal Substructure" to avoid confusion with IKEv2 payloads.
>
> <mglt>
>
> Thanks for the feed back. To prevent any misunderstanding regarding 
> the Proposal Substructure as outlined in RFC7296 Section 3.3.1, we 
> opted for the term "Proposal Payload." However, we acknowledge your 
> concerns and are receptive to alternative designations. Personally, 
> and at the time I am reading your comment, I have a preference for 
> "Proposal," and "HCP Proposal" seems also serve as a viable option.
>
> We will give this careful consideration.
>
> </mglt>
>
>     3. Section 3.
>
>         Nevertheless, it is anticipated that the responder will provide an
>
>         explanation for rejecting all HCP Proposals.  If the reason pertains
>
>         to an AfRG with an unacceptable value, the responder SHOULD reply
>
>         with an HCP_UNSUPPORTED Notify Payload.  This Notify Payload SHOULD
>
>         include one or more acceptable Proposal Payloads to guide the
>
>         initiator.
>
>     This is not how the parameters negotiation is used to be done in IKEv2.
>
>     Currently, the initiator sends list of all acceptable for it parameters
>
>     and the responder selects the subset that is acceptable for it.
>
>     With the approach in the draft the responder would send back the value
>
>     that is not presented by the initiator. Either this value is unacceptable
>
>     for initiator (and thus no reason to send it back except for logging)
>
>     or the initiator didn't send *all* acceptable for it values.
>
>     This is a major change to the way parameters are generally
>
>     negotiated in IKEv2 and thus it should be justified with a very good reason.
>
>     I currently fail to see such, but perhaps I'm missing something.
>
> <mglt>
>
> Thank you for your comment; we will likely need to provide further 
> clarification on this matter. The HCP_UNSUPPORT explicitly states that 
> none of the proposals can be accepted, and there is no requirement for 
> additional information to be supplied. I concur that the message may 
> not be essential, which is why we categorized it as a SHOULD.
>
> The rationale behind this message is our anticipation that certain 
> implementations will exclusively support Diet-ESP with a specific set 
> of parameters, and not even support the uncompressed  ESP at all. 
> Consequently, we want such implementations to have the capability to 
> indicate a negotiation failure due to their support for Diet-ESP with 
> very particular parameters. If this indication is provided, it is 
> expected to be generic in nature. We only expect the initiator to log 
> this information. We appreciate your concern and will clarify that we 
> are not altering the IKEv2 negotiation process or the reasons for 
> introducing this Notification Payload.
>
> </mglt>
>
> Why do you add new notification for this? We have NO_PROPOSAL_CHOSEN, 
> which has the following meaning:
>
>    NO_PROPOSAL_CHOSEN 14
>
>        None of the proposed crypto suites was acceptable.  This can be
>
>        sent in any case where the offered proposals (including but not
>
>        limited to SA payload values, USE_TRANSPORT_MODE notify,
>
>        IPCOMP_SUPPORTED notify) are not acceptable for the responder.
>
> *       This can also be used as "generic" Child SA error when Child SA*
>
> *       cannot be created for some other reason.  See also Section 2.7.*
>
>          Why this is not acceptable for your case? Except that it does 
> not provide logging.
>
>          But I’m not sure it justifies adding a new notification for 
> the very specific case.
>
<mglt>We would have like to provide a peer to advertise a configuration 
that works - especially for devices that have a single configuration 
implemented. Other than that, we could use NO_PROPOSAL_CHOSEN. </mglt>

>     4. Section 3.
>
>     HCP_UNSUPPORTED is a very bad name. My first perception was that
>
>     it means that HCP is not supported at all by the responder, in which case
>
>     the responder would not have known anything about this notify too. After re-reading
>
>     I realized, that it means that no provided parameters are acceptable,
>
>     thus the better name would be HCP_NO_PROPOSAL_CHOSEN.
>
> <mglt>I concur that your proposal is a better wording, particularly 
> since a single node transmitting that message indicates its support 
> for HCP. Thank you for presenting the proposal.
>
> </mglt>
>
>     In addition, it is defined as a status type notify, but it should be
>
>     an error type notify (not a fatal one), since it indicates an error
>
>     in creating Child SA.
>
>     And I see no need for it at all, if HCP negotiation is performed
>
>     as it is done in IKEv2 for all other parameters.
>
> <mglt>I concur that it is preferable to categorize this as an error. I 
> believe I clarified the rationale behind the creation of that message 
> in 3.</mglt>
>
>     5. Section 3.
>
>         In cases where the AfRG was not explicitly stated, the
>
>         responder will provide the AfRG unless it defaults to a standard
>
>         value.
>
>     I wonder what default values are and where they are defined.
>
>     Table 1 in draft-ietf-ipsecme-diet-esp lists only possible values
>
>     for each parameter and doesn't mark any of them as default.
>
> <mglt>The division we have established is that 
> draft-ietf-ipsecme-diet-esp outlines the methodology for compression 
> as derived from AfRG. It is presumed that all AfRG have been clearly 
> defined. The present draft is tasked with detailing the process by 
> which the AfRG are reached, and a default value has been introduced to 
> facilitate negotiations. This rationale underpins our decision to 
> elaborate on this matter within this document, specifically in Section 
> 7. </mglt>
>
>     6. Section 3.
>
>     There is no discussion whether HCP parameters should
>
>     match other values negotiated by IKEv2. For example,
>
>     is it allowed that values in ts_* parameters don't
>
>     match TSi/TSr content? What peers need should do in this case?
>
>     Am I missing something?
>
> <mglt>I believe this is a valid observation. While I anticipate 
> HCP_UNSUPPORTED, it has not been explicitly stated. We will ensure 
> this is clarified. Thank you for your feedback.
>
> It is important to note that in draft-ietf-ipsecme-diet-esp, we have 
> made certain assumptions regarding the TS. However, I concur that this 
> aspect also requires explicit handling by IKEv2.
>
> """
>
>    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.
>
> """
>
> </mglt>
>
>     7. Section 4.
>
>     In description of Proposal Payload:
>
>         EHCP Name (2 octets):  The identifier of the EHCP Name. (see Table 2)
>
>     Typo: s/2 octets/1 octet
>
> <mglt> We will correct this. Thanks.</mglt>
>
>     8. Section 5.
>
>     As far as I understand, the attribute range_afrg_proposal is used to
>
>     provide the range of supported compression parameters.
>
>     It is not clear how the identifiers of these parameters are
>
>     represented - e.g. how many octets an identifier occupies.
>
>     I presume it occupies two bytes, as IKEv2 attribute type, but this is not spelled out.
>
>     Perhaps I'm badly missing, the text is not clear for me.
>
> <mglt>
>
> The range_afrg_proposal consists of two attributes, namely AfRG_min 
> and AfRG_max. Both AfRG_min and AfRG_max are classified as attributes, 
> and consequently, the overall length encompasses the lengths of both 
> AfRG_min and AfRG_max.
>
> The potential misunderstanding may arise from our reference to 
> AfRG_min and AfRG_max as values. While these represent the values for 
> the range, they are indeed attributes. It would be beneficial to 
> enhance our description by explicitly stating that AfRG_min and 
> AfRG_max are attributes. Additionally, we should outline the procedure 
> for managing the range, specifically ensuring that both attributes are 
> of the same type. We will make the necessary clarifications in this 
> section. Thank you for bringing this matter to our attention.
>
> </mglt>
>
> I think this all should be clarified. I’d also like to see few examples.
>
<mglt> We will provide examples and clarify the text.</mglt>
>
>     9. Section 7.
>
>     I wonder why the attributes for the listed AfRGs are encoded in TLV format,
>
>     and not in TV format? They all contain one-octet value, so they all
>
>     would fit in TV format. In my humble opinion, the goal of this specification
>
>     is to make IPsec packets smaller, and at the same time less-than-optimal
>
>     encoding is used for these attributes.
>
> <mglt>
>
> It is accurate that the attributes established for the Diet-ESP EHCP 
> possess a fixed length. Furthermore, in our specific instance, these 
> attributes share the same length. Nevertheless, this should not be 
> anticipated for every profile, (determined by the HCP Name attribute). 
> We needed to strike a balance between flexibility and bandwidth 
> optimization, and thus far, we have opted to prioritize flexibility. 
> Additionally, it is worth noting that this format is commonly used to 
> describe attributes in IKEv2. It may be beneficial to include a note 
> regarding the rationale behind this decision.
>
> </mglt>
>
> I suspect you missed my point. Let me be more specific.
>
>          Let’s take for example the alignment attribute. Table 3 
> states that it
>
>          has associated data, which meant that it is encoded on the 
> wire as TLV attribute format.
>
>          The data, that this attribute contains, is always 1 octet in 
> length (since it is a codepoint defined
>
>          in Table 8.5.4, with a 255 as a maximum value). This doesn’t 
> depend on any future profile, this is fixed in your profile.
>
>          Thus, your current encoding on the wire takes 5 octets. But 
> since the attribute data is always 1 octet in length, you might use TV 
> encoding
>
>          for this attribute (set Has Associated Data to NO), which 
> would result in 4-octet encoding on the wire.
>
>          I agree that this is not a big saving, but it seems to me 
> that the IOT-targeted document should
>
>          use any possibility to save, no?
>
<mglt>That is a very good point. We had in mind TV but described TLV for 
our parameters. ;-) We will fic that for sure! Thanks!.</mglt>
>
>     10. Section 7.
>
>     Text regarding alignment:
>
>        *  Default Value: the default value is set to "32 bit", which
>
>           corresponds to the standard IPv6 bit alignment
>
>     This contradicts to what RFC 4303 specifies (Section 2.3):
>
>         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.
>
>     Perhaps different alignments are meant, but with no clarification in the draft this is unclear for me.
>
> <mglt> This is a valid observation. We will provide clarification on 
> this matter. While we may adopt IPv6 alignment as the default, we will 
> ensure that the text is made clear. Thanks for providing the note.</mglt>
>
>     11. Section 7.
>
>     s/Security Policy Index/Security Parameter Index
>
> <mglt>ok.Thanks.</mglt>
>
>     12. Section 7.
>
>     This section provide registration information only for 6 AfRG out of 23 listed in Table 1
>
>     of draft-ietf-ipsecme-diet-esp, that are needed to implement EHC. I wonder
>
>     where can I get information about the others.
>
> <mglt>Table 1 lists all 23 AfRGs. The reference column specifies the 
> sources where these parameters are defined. For 18 of these, the AfRG 
> is a parameter outlined in either RFC7296, RFC4301, or a draft 
> concerning DSCP values. All these AfRGs are established through the 
> creation of a CHILD SA via IKEv2. When explicitly negotiated by IKEv2 
> with a specific payload, we referred to RFC7296 or RFC4301 was 
> utilized. Six of the parameters are defined in 
> draft-ietf-ipsecme-diet-esp, which details the negotiation process for 
> these six parameters.</mglt>
>
> Please see my comment above. There must be more details of how all 
> other parameters are getting their values.
>
>          It is not sufficient to reference RFC 7296 or RFC 4301 – they 
> both are silent about AfRGs and implementers
>
>          have to guess from what fields AfRGs should take their values 
> from.
>
>          I also think that there must be Operational Considerations 
> section, which should help implementers
>
>          to correctly select some values. For example, when selecting 
> esp_sn_lsb, implementations
>
>          should consider the maximum number of packets that is 
> expected to be send over a Child SA
>
>          being negotiated before its rekeyng (thus, this is an Child 
> SA-wide parameter), while
>
>          for selecting esp_spi_lsb, implementation should consider the 
> total number of Child SAs,
>
>          that are expected to be active at any given time, (thus this 
> is a system-wide parameter).
>
>          I suspect that all these nuances currently have to be guessed 
> by implementers with no help
>
>          from the authors L
>
<mglt>I agree, we will add that section probably in both drafts.</mglt>
>
>     Regards, Valery.
>
>     13. Section 8.3.
>
>     I wonder why the registry is called "IKEv2 Header Compression", while
>
>     the profile is about ESP header compression.
>
> <mglt>I am not oppose to changing the terminology; however, I am 
> willing to clarify the rationale behind our chosen designation. We are 
> quite receptive to adopting an alternative designation if necessary.
>
> Section 8.3 outlines a registry that pertains to the profile for which 
> parameters (AfRGs) are negotiated. This registry is exclusively 
> utilized by IKEv2, which is why IKEv2 is included in the registry's 
> name. It is important to note that this does not imply that the 
> compression concerns IKEv2, and we could opt to remove IKEv2 from the 
> title, thereby referring to the registry as the "Header Compression 
> Profile."<mglt>
>
>     14. Section 8.2.
>
>          range_afrg is undefined. Perhaps this is a typo, the body of the draft mentions range_afrg_proposal.
>
> <mglt>Thanks. This is a typo yes.</mglt>
>
>     15. Section 8.4.
>
>     The same question as in issue 12 - what about other AfRG needed for ECH?
>
>     Only 6 out of 23 have codepoints.
>
> <mglt>I tried to answer in question 1 and 12.</mglt>
>
>     Regards,
>
>     Valery.
>
>         This will start two week WGLC for the
>
>         draft-ietf-ipsecme-ikev2-diet-esp-extension [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-ikev2-diet-esp-extension/
>
>         --
>
>         [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]
>