Re: [IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

["Eric Vyncke (evyncke)" <[e-mail]>]

Thank you, Valery, for the prompt reply.

See below for EVY>

Regards

-éric

From: Valery Smyslov <[e-mail]>
Date: Thursday, 11 April 2024 at 15:23
To: Eric Vyncke (evyncke) <[e-mail]>, 'The IESG' <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: RE: Éric Vyncke's No Objection on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)
Hi Éric,

thank you for your comments, please see inline.

> Éric Vyncke has entered the following ballot position for
> draft-ietf-ipsecme-ikev2-auth-announce-09: No Objection
>
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
>
>
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-
> positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-auth-announce/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> # Éric Vyncke, INT AD, comments fordraft-ietf-ipsecme-ikev2-auth-announce-09
>
> Thank you for the work put into this document.
>
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated even if only for my own education), and some nits.
>
> Special thanks to Tero Kivinen for the shepherd's detailed write-up including
> the WG consensus and the justification of the intended status.
>
> I hope that this review helps to improve the document,
>
> Regards,
>
> -éric
>
> # COMMENTS (non-blocking)
>
> ## Abstract
>
> As the I-D is about authentication methods, I wonder whether `with multiple
> different credentials` is the right wording, should it rather be "different
> authentication methods" ? (of course with some text repetition).

I believe "different credentials" may include "different authentication methods"?
There are may also be some subtleties. For example, consider the situation
when user has 2 certificates: RSA and ECDSA. In this case he/she has
different credentials, but from IKEv2 point of view, both use the same
authentication method, "Digital Signature", with different signature algorithms.

I make the following change:
s/multiple different credentials/multiple credentials of different type

Is this better?
EVY> I think so



> ## Section 3.1
>
> `Regardless of whether the notification is received,` may be I am mis-reading
> this, but why would the responder send the notification if the initiator does
> not care anyway ?

The responder doesn't know if the initiator cares or not.
There is no negotiation of this feature, each party just makes its mind
whether to send and whether to process this notification (if it is ever supported).

EVY> sure it will work like described in the I-D, but I find it really weird that the initiator does not send its own list.

> ## Section 3.2
>
> While the readers may guess some details, but let's be clear in a proposed
> standard I-D:
>
> 1) `Notification Data field` does not appear in figure 4
> 2) role of C flag and its value
> 3) value of Protocol ID
> 4) saying that reserved field must be set to 0 by sender and ignored on the
> receiver

There is a reference to Section 3.10 of RFC 7296, which contains
details of how a generic payload header should be filled in.
The Protocol ID and SPI Size values are defined in this document (zero).

EVY> I am off-line now so cannot check in the I-D whether the reference is there. But, may I suggest to state somewhere that the fields C/protocol id/reserved are specified in RFC 7296 ?


What about 1), well, the "Notification Data" is the generic name
of this field in the Notify Payload. Its content depends on the type of the notify message.
I quickly scanned other RFCs which defined new notifications and they all
renamed the "Notification Data" to some name specific to the
type of notification. So, to avoid confusion, I changed the text as follows:

s/The Notification Data field/ Notification data

Hope this eliminates the possible confusion.

EVY> this would help indeed


> ## Section 3.2.1
>
> Let's be crisp and specify that the length is in octets.

Done.

> Is there a registry for authentication method ? or should this specification be
> updated for every new authentication method ?

https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-12

EVY> may I suggest to add a reference to this registry (again off-line and cannot check)


I hope no, but I cannot predict how IKEv2 would be tweaked in the future :-)

> # NITS (non-blocking / cosmetic)
>
> ## Section 1
>
> The last sentence of the 2nd paragraph is rather long and I think that "that"
> should be used in `the peer which supports wider range of`.

Thank you, I've been always mixing when to use "which" or "that" :-)

I changed s/which/that

EVY> ;-) I had to learn it myself (not easy for non English speaker)


> ## Section 3.2.1
>
> Missing closing parenthesis in the last paragraph.

Fixed.

Regards,
Valery.