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