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