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.
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.
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.
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.
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.
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.
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?
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
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.
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.
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.
11. Section 7.
s/Security Policy Index/Security Parameter Index
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.
13. Section 8.3.
I wonder why the registry is called "IKEv2 Header Compression", while
the profile is about ESP header compression.
14. Section 8.2.
range_afrg is undefined. Perhaps this is a typo, the body of the draft
mentions range_afrg_proposal.
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.
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 to ipsec-le...@ietf.org
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
