Hi Valery,
Thank you very much for your review.
We agree with all these issues you pointed out, and we'll address them in the
next version.
Regards & Thanks！
Wei PAN (潘伟)
> -----Original Message-----
> From: IPsec <[email protected]> On Behalf Of Valery Smyslov
> Sent: Friday, May 3, 2024 8:51 PM
> To: [email protected]
> Subject: [IPsec] Review of draft-ietf-ipsecme-ikev2-sa-ts-payloads-opt
>
> Hi,
>
> I reviewed draft-ietf-ipsecme-ikev2-sa-ts-payloads-opt.
> The document is in a good shape, however it has some issues that need
> to be fixed.
>
> 1. Section 3.
>
> To indicate support for the optimized rekey negotiation, the
> initiator includes the OPTIMIZED_REKEY_SUPPORTED notify payload
> in
> the IKE_AUTH exchange request. If multiple IKE_AUTH exchanges
> are
> sent, the OPTIMIZED_REKEY_SUPPORTED notify payload should be in
> the
> last IKE_AUTH exchange, which is the exchange that also contains the
> TS payloads.
>
> This is not correct, If multiple IKE_AUTH exchanges take place, then TS
> payloads are in the very _first_ IKE_AUTH request and in the very _last_
> IKE_AUTH response. See Section 2.16 of RFC 7296, Section 4 of RFC 6467
> and Section 2 of RFC 4739.
>
> 2. Section 6.2
>
> The Critical bit MUST be 1. A value of 0 MUST be ignored.
>
> This is wrong. The Critical bit refers to the Payload Type and not to the
> payload content.
> In this case the type of payload is Notify Payload, that was defined in
RFC
> 7296.
> And all payloads types defined in RFC 7296 must not have the Critical bit
> set.
>
> 3. Section 6.1.
>
> The Critical bit MUST be 0. A non-zero value MUST be ignored.
>
> While this is correct, the requirement is already present in RFC 7296
> (Section 3.2), and I see no need to repeat it here. This is a generic
rule of
> payload processing in IKEv2 and the optimized rekey extension doesn't
> change it, so no need to repeat.
>
> 4. Section 6.2
>
> The format of the OPTIMIZED_REKEY notification makes use of Protocol
> ID, SPI Size and SPI fields of the Notify Payload to specify SPI of the
new
> (not yet created) SA. This use contradicts RFC 7296.
> Section 3.10 of RFC 7296 says:
>
> o Protocol ID (1 octet) - If this notification concerns an existing
> SA whose SPI is given in the SPI field, this field indicates the
> type of that SA.
>
> Note, that these fields are concerned with _existing_ SA, which is not the
> case for the OPTIMIZED_REKEY notification.
> I propose to leave SPI fields empty, set both Protocol ID and SPI Size to
> zero and move the SPI for the new SA to the Notification Data.
> Note, that there is no ambiguity as to what protocol (AH or ESP) this
> new SPI should be used with, since the REKEY_SA notification contains
> this information.
>
> Regards,
> Valery.
>
>
>
> _______________________________________________
> IPsec mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
