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

From: Martin Vigoureux via Datatracker <[email-masked]>
Date: Wed, 08 Jan 2020 13:48:19 -0800

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

   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
by the way, if it is a resend of the message described in the paragraph above,
then "if the original message did" seems superfluous.

   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

   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.

---

From: Valery Smyslov <[email-masked]>
Date: Thu, 9 Jan 2020 11:04:30 +0300

Hi Martin,

> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/

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 :-)

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

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

>       to the base64 character set, namely the 64 characters 0-9, A-Z,

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.

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

---

From: Martin Vigoureux <[email-masked]>
Date: Thu, 9 Jan 2020 13:01:05 +0100

Hello Valery,

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

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

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

>     the received data as the first payload, and all other payloads
my bad. I did a quick read of that section and obviously missed the last 
part of that sentence ...
> like hardware tokens etc.). So it's just a general recommendation.
ok, understood.
> 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.

> Valery.
regards,
martin