[prev in list] [next in list] [prev in thread] [next in thread]
List: ipsec
Subject: Re: [IPsec] Martin Vigoureux's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)
From: Martin Vigoureux <martin.vigoureux () nokia ! com>
Date: 2020-01-09 12:01:05
Message-ID: 09c7f062-b7f0-84d4-97cf-bd268d655255 () nokia ! com
[Download RAW message or body]
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
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic