Hi Martin, > Martin Vigoureux has entered the following ballot position for > draft-ietf-ipsecme-qr-ikev2-10: 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/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Hi, > > It seems to me there are places where 2119/8174 keywords would make sense. > Few examples, with suggestions: > If the initiator is configured to use a post-quantum preshared key > with the responder (whether or not the use of the PPK is mandatory), > then it will include a notification USE_PPK in the IKE_SA_INIT > request message as follows: > >>MUST include
Isn't it just a protocol description and not a requirement? Anyway, I have no problem with using RFC2119 language here, but a few years ago I was told by one of ADs that I improperly used RFC2119 language when I wrote a very similar sentence: "if initiator is configured with foo it MAY include a bar notification in its request"; I was told then that plain English must be used in this case :-) > If the initiator needs to resend this initial message with a cookie > (because the responder response included a COOKIE notification), then > the resend would include the USE_PPK notification if the original > message did. > >>MUST (or SHOULD?) include I don't think it is needed here. Section 2.6 of RFC7296 has already a requirement, that ...the initiator MUST then retry the IKE_SA_INIT request, and include the COOKIE notification containing the received data as the first payload, and all other payloads unchanged. So we don't impose new requirement, we just remind readers that USE_PPK will also be included in the resend message. > by the way, if it is a resend of the message described in the paragraph above, > then "if the original message did" seems superfluous. It is a resend, but the resending message is a bit different from the original, since it includes the cookie received from the responder. See section 2.6 of RFC7296 for details. > Otherwise the responder replies with the IKE_SA_INIT message including a > USE_PPK notification in the response: > >>MUST reply > > initiator and the responder. The responder can use the PPK_ID to > look up the corresponding PPK value. Not all implementations are > able to configure arbitrary octet strings; to improve the > potential interoperability, it is recommended that, in the > PPK_ID_FIXED case, both the PPK and the PPK_ID strings be limited > to the base64 character set, namely the 64 characters 0-9, A-Z, > a-z, + and /. > >>RECOMMENDED The "recommended" here is intentionally made non-normative, otherwise the requirement is too strong (there are a number of use cases, where the requirement for PPK to be base64 limited makes a little sense, like hardware tokens etc.). So it's just a general recommendation. > values 3-127 are reserved for IANA; > Maybe it's just because I'm not used to that wording, but why "reserved for > IANA" ? The table seems to qualify them as unassigned. Is there a difference? I've been thinking that "reserved for IANA" means that these values are currently unassigned, but IANA will use them for future assignments... Thank you, Valery. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
