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

[Valery Smyslov <[e-mail]>]

Hi Orie,

thank you for your comments, please see inline.

> Orie Steele 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:
> ----------------------------------------------------------------------
> 
> # Orie Steele, ART AD, comments for draft-ietf-ipsecme-ikev2-auth-announce-09
> CC @OR13
> 
> https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-
> ipsecme-ikev2-auth-announce-09.txt&submitcheck=True
> 
> ## Comments
> 
> Thanks to Marc Blanchet for the ARTART review, and to Valery for addressing his
> feedback.
> 
> ```
> 175	   then the responder MAY choose not to send actual list of the
> 176	   supported authentication methods in the IKE_SA_INIT exchange and
> 177	   instead ask the initiator to start the IKE_INTERMEDIATE exchange for
> 178	   the list to be sent in.
> ```
> 
> Why not "SHOULD not send..."?

Because we don't want to give one of the option more weight than the other.
The responder is free to act either way, since the possible issues with IP fragmentation 
are sometimes subtle and additional considerations can be evaluated by the responder.
With "SHOULD" the responder would have to almost always ask for 
IKE_INTERMEDIATE (since SHOULD is very close to MUST).

> ```
> 189	   the SUPPORTED_AUTH_METHODS notification.  Otherwise, the initiator
> 190	   MAY start the IKE_INTERMEDIATE exchange just for this sole purpose by
> 191	   sending an empty IKE_INTERMEDIATE request.  The initiator MAY also
> 192	   indicate its identity (and possibly the perceived responder's
> 193	   identity too) by including the IDi payload (possibly along with the
> 194	   IDr payload) into the IKE_INTERMEDIATE request.  This information
> 195	   could help the responder to send back only those authentication
> 196	   methods, that are configured to be used for authentication of this
> 197	   particular initiator.  If these payloads are sent, they MUST be
> 198	   identical to the IDi/IDr payloads sent later in the IKE_AUTH request.
> ```
> 
> Why not SHOULD instead of MAY?

For the same reason - to leave an initiator a freedom of choice.
For example, the initiator can be not interested in receiving 
the responder's list of supported auth methods (e.g., the initiator
itself may be able to authenticate itself with the only one method, 
thus no point to know that the responder supports more, thus
no point to waste a round trip). The same for the second "MAY" - 
the initiator may be not willing to send its identity in the 
IKE_INTERMEDIATE exchange for the same reason 
(in case the IKE_INTERMEDIATE is started anyway for some
other purposes).

Using "SHOULD" here would have left the initiator with less freedom of choice.

> ```
> 226	   HDR, SAi1, KEi, Ni -->
> 227	                                      <-- HDR, SAr1, KEr, Nr, [CERTREQ,]
> 228	                                          [N(SUPPORTED_AUTH_METHODS)()]
> 
> 230	   HDR, SK {..., [IDi, [IDr,]]}  -->
> 231	                                      <-- HDR, SK {..., [CERTREQ,]
> 232	                                      [N(SUPPORTED_AUTH_METHODS)(...)] }
> ```
> 
> Is the "()" vs "(...)" significant, or meant to indicate the empty IKE_INTERMEDIATE
> ?
> What does "(...)" expand to?

"()" means an empty SUPPORTED_AUTH_METHODS notification,
while "(...)" means a non-empty one (containing some auth methods).

> ```
> 347	   Signature" (1), "DSS Digital Signature" (3), "ECDSA with SHA-256 on
> 348	   the P-256 curve" (9), "ECDSA with SHA-384 on the P-384 curve" (10)
> 349	   and "ECDSA with SHA-512 on the P-512 curve" (11).  Note however, that
> 350	   these authentication methods are currently superseded by the "Digital
> 351	   Signature" (14) authentication method, which has a different
> ```
> 
> I think you mean P-521 curve, also known as secp521r1.

You are right, this is a typo. Fixed in my local copy, thank you.

> ## Nits
> 
> ```
> 531	   This appendix shows some examples of announcing authentication
> 532	   methods.  This appendix is purely informative; if it disagrees with
> 533	   the body of this document, the other text is considered correct.
> ```
> 
> You will see errata filed either way...
> I recommend omitting the second sentence.

This is more or less standard text copied from other RFCs. 
See, for example, Appendix C in RFC 7296.

Regards,
Valery.