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
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
