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

[Valery Smyslov <[e-mail]>]

Hi Éric,

 

please see inline.

 

Thank you, Valery, for the prompt reply.

 

See below for EVY>

 

Regards

 

-éric

 

From: Valery Smyslov <[e-mail] <mailto:[e-mail]> >
Date: Thursday, 11 April 2024 at 15:23
To: Eric Vyncke (evyncke) <[e-mail] <mailto:[e-mail]> >,
'The IESG' <[e-mail] <mailto:[e-mail]> >
Cc: [e-mail]
<mailto:[e-mail]>
<[e-mail]
<mailto:[e-mail]> >,
[e-mail] <mailto:[e-mail]>
<[e-mail] <mailto:[e-mail]> >, [e-mail]
<mailto:[e-mail]>  <[e-mail] <mailto:[e-mail]> >,
[e-mail] <mailto:[e-mail]>  <[e-mail]
<mailto:[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

          Great!



> ## 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.

         In fact it does, but it sends this after the responder, in the
following exchange. So, the responder sends its list first.
         This is to have the announcements and the list of trust anchors (in
the CERTREQ payload) co-located in the same message.


> ## 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 ?

I think that since we explicitly reference the description of the Notify
Payload in RFC 7296, 
readers will be able to know how the generic payload header fields should be
filled in, right?

I’m just trying to follow other IKEv2 extensions RFCs, where usually these
details are omitted
(if one wants to implement an IKEv2 extension, then we presume that he/she
is familiar with IKEv2 enough to know how to construct a payload).

What about the Protocol ID (and SPI Size), the text currently defines what
should be there.
The current text is:

   The Notify payload format is defined in Section 3.10 of [RFC7296].
   When a Notify payload of type SUPPORTED_AUTH_METHODS is sent, the
   Protocol ID field is set to 0, the SPI Size is set to 0, meaning
   there is no SPI field, and the Notify Message Type is set to <TBA by
   IANA>.



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#ike
v2-parameters-12

 

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

         It is already there (in the para describing the notification
payload data, Section 3.2)!

Authentication methods are represented as values from the
"IKEv2 Authentication Method" registry defined in [IKEV2-IANA].

and later in the Normative references:

[IKEV2-IANA]

    IANA, "Internet Key Exchange Version 2 (IKEv2)
    Parameters", <https://www.iana.org/assignments/ikev2-
    parameters/ikev2-parameters.xhtml#ikev2-parameters-12>.


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)

         Indeed J

Regards,
Valery.