Re: [IPsec] Martin Vigoureux's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)

[Martin Vigoureux <[e-mail]>]

Hello Valery,

thank you for your feedback. Please see in-inline.

Le 2020-01-09 à 9:04, Valery Smyslov a écrit :
> 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?
it is, but for a implementation to behave like that I tend to think that 
having a requirement in the first place would make sense.

> 
> 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 :-)
ADs can have different points of view :-)
Yet, I'm not seeking to change to the doc, so if you feel this is fine 
like that (and I agree that at least it's not wrong) then don't change 
anything.

> 
>>     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.
my bad. I did a quick read of that section and obviously missed the last 
part of that sentence ...
> 
> 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.
ok, understood.
> 
>>     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...
As said, this is the first time I see this written this way, so I raised 
the question. If it is well understood that this means "unassigned" then 
fine. What is ultimately important is what is written in the table/registry.

> 
> Thank you,
> Valery.
> 
> 
> 
regards,
martin