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/
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list --ipsec@ietf.org
To unsubscribe send an email toipsec-le...@ietf.org
_______________________________________________
IPsec mailing list --ipsec@ietf.org
To unsubscribe send an email toipsec-le...@ietf.org
