Re: [IPsec] Mirja Kühlewind's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)

[Mirja Kuehlewind <[e-mail]>]

Hi Valery,

Inline again.

> On 8. Jan 2020, at 14:27, Valery Smyslov <[e-mail]> wrote:
> 
> Hi Mirja,
> 
>> Hi Valery,
>> 
>> Please see inline.
>> 
>>> On 8. Jan 2020, at 12:55, Valery Smyslov <[e-mail]> wrote:
>>> 
>>> Hi Mirja,
>>> 
>>>> Hi Panos, hi Valery,
>>>> 
>>>> Please see below.
>>>> 
>>>>> On 8. Jan 2020, at 10:27, Valery Smyslov <[e-mail]> wrote:
>>>>> 
>>>>> Hi Panos, Mirja,
>>>>> 
>>>>>> Hi Mirja,
>>>>>> 
>>>>>> To try to answer your questions
>>>>>> 
>>>>>> 1) You are right. This is mentioned in a paragraph below that reads
>>>>>> 
>>>>>> [...] or continue without using the
>>>>>> PPK (if the PPK was not configured as mandatory and the initiator
>>>>>> included the NO_PPK_AUTH notification in the request).
>>>>>> 
>>>>>> But for clarity we will slightly rephrase the sentence you pointed out to
>>>>>> 
>>>>>> only if using PPKs for communication with this responder
>>>>>> is optional for the initiator (based on the mandatory_or_not flag),
>>>>>> then the initiator MAY include a notification NO_PPK_AUTH in the
>>>>>> above message.
>>>>> 
>>>>> After re-reading this para, I think that uppercase "MAY" is not needed
>>>> here,
>>>>> because if the initiator doesn't include NO_PPK_AUTH, then it leaves
>>>>> no chances for the responder to complete IKE SA without using PPK,
>>>>> so in this case using PPK becomes in fact mandatory. I think the proper
>>>> text should be:
>>>>> 
>>>>>  For this purpose, if using PPKs for communication with this responder
>>>>>  is optional for the initiator (based on the mandatory_or_not flag),
>>>>>  then the initiator includes a notification NO_PPK_AUTH in the
>>>>>  above message.
>>>> 
>>>> I think what you propose is actually to replace the MAY by a MUST. In
>> any
>>>> case using normative language is helpful here because that is an action
>> that
>>>> needs to be implemented somehow, so the implementor would need to
>>>> know what the protocol is supposed to do.
>>> 
>>> I have no problem with using normative MUST here, since it doesn't
>>> change the meaning of the text. That said, I still prefer to avoid using
>>> it here (by following section 6 of RFC2119), because in my
>>> understanding it is just a description of protocol behaviour and not a
>> special requirement.
>> 
>> This depends: if you look at this from the receiver side, it a description of
>> the protocol behaviour. But for the sender it’s an action that must be
>> specified. I think the below text is mention to describe the requirement on
>> the sender, so normative language is appropriate. Maybe the wording “the
>> initiation indicates” is confusing here and it should actually say “the initiator
>> includes a NO_PPK_AUTH notification to indicate this optionality to the
>> responder“…?
> 
> It is definitely better, thank you!
> 
>    For this purpose, if using PPKs for communication with this responder
>    is optional for the initiator (based on the mandatory_or_not flag),
>    then the initiator includes a NO_PPK_AUTH notification in the above message 
>    to indicate this optionality to the responder.
> 
> Is it OK now?


I still think use of normative language would be appropriate here.

> 
> [...]
> 
>>>>>> 3) Waiting for one or two RTTs is probably a good rule. The side-effect
>>>> could
>>>>>> be that the initiator stays waiting for responses for too long which
>> delays
>>>>>> the handshake. I am not sure we can mandate in absolute time
>> because
>>>> it
>>>>>> depends on the relative distance between client and server. We can
>>>>>> probably include " (e.g., one round-trip) " in the text.
>>>>> 
>>>>> I think one or two RTT is too short, moreover since it's an initial request,
>>>>> no RTT is yet measured (IKEv2 uses UDP as primary transport).
>>>>> We try here to be in line with core IKEv2 spec, which deliberately
>>>>> doesn't give any concrete figures of how long to wait for an response
>>>>> (section 2.4 of RFC7296). So, I'd leave the text as is.
>>>> 
>>>> Kind of same here. Given you two disagree here already, I think it would
>> be
>>>> good to give further advise.
>>> 
>>> I'm reluctant to provide concrete figures, because RFC7296 deliberately
>>> doesn't do it and this is just an extension to the IKEv2. I'd rather reference
>>> the core spec here. How about the following text:
>>> 
>>> To thwart
>>>  this kind of attack it is RECOMMENDED, that if using PPKs is
>>>  mandatory for the initiator and the received response doesn't contain
>>>  the USE_PPK notification, then the initiator doesn't abort the
>>>  exchange immediately, but instead waits for more responses
>>>  retransmitting the request until either the received message
>>>  contains the USE_PPK or connection times out (see section 2.4 of
>> [RFC7296]
>>>  for more details). If all the received responses contain no USE_PPK, then
>> the exchange is aborted.
>> 
>> I looked at section 2.4 of RFC7296 and the situation is actually different
>> there because the initiator will accept/open multiple connections and then
>> close them again if detected to not be proper. 
> 
> I meant another part of 2.4:
> 
>   The number of retries and length of timeouts are not covered in this
>   specification because they do not affect interoperability. 
> 
>> So there is state anyway. Here you don’t have an open connection and therefore you need an
>> timeout. 
> 
> Sure we need a timeout. But this is exactly the same timeout which
> IKEv2 initiator uses when trying to establish initial connection with the peer.
> 
>> I would recommend to at least say something like:
>> "Ideally the timeout would be in the order of the RTT plus additional
>> processing delays at the responder. As these times are not known the
>> timeout should be choosen sufficiently larger, however, state may be
>> removed anytime when needed (e.g. in an attack situation).”
>> 
>> (Please use your own wording…)
> 
> The whole idea of thwarting this attack is not to trust 
> the responses not containing USE_PPK notification (suspecting that they may be forged).
> So the initiator continues to retransmit and wait for other responses.
> For how long? For the same period of time that it would retransmit and wait for any response
> as if no responses were received at all. So, we introduce no new timeouts here 
> comparing with the core spec.

Okay. I wasn’t aware that these are existing time-outs. I think the document could be more clear about this then.

Mirja



> 
> Regards,
> Valery.
> 
> [...]
> 
>> Mirja
>> 
>> 
>>> 
>>> Regards,
>>> Valery.
>>> 
>>>> Mirja
>>>> 
>>>> 
>>>> 
>>>>> 
>>>>> Regards,
>>>>> Valery.
>>>>> 
>>>>>> Rgs,
>>>>>> Panos
>>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: IPsec <[e-mail]> On Behalf Of Mirja Kühlewind
>> via
>>>>>> Datatracker
>>>>>> Sent: Tuesday, January 07, 2020 8:41 AM
>>>>>> To: The IESG <[e-mail]>
>>>>>> Cc: [e-mail]; [e-mail];
>> [e-mail];
>>>>>> [e-mail]
>>>>>> Subject: [IPsec] Mirja Kühlewind's No Objection on draft-ietf-ipsecme-
>> qr-
>>>>>> ikev2-10: (with COMMENT)
>>>>>> 
>>>>>> Mirja Kühlewind 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:
>>>>>> ----------------------------------------------------------------------
>>>>>> 
>>>>>> 1) One small question on section 3:
>>>>>> "if using PPKs for communication with this responder
>>>>>> is optional for the initiator, then the initiator MAY include a
>>>>>> notification NO_PPK_AUTH in the above message."
>>>>>> This does mean that NO_PPK_AUTH notification should not be sent
>> when
>>>>>> the mandatory_or_not flag indicates that PPK is mandatory, right? Or
>> is
>>>> that
>>>>>> a separate configuration? Would be good to clarify in the doc!
>>>>>> 
>>>>>> 2) Section 6 says:
>>>>>> "In this situation, it is RECOMMENDED
>>>>>> that the initiator caches the negative result of the negotiation for
>>>>>> some time and doesn't make attempts to create it again for some
>> time,"
>>>>>> Would it be possible to give any hints about what "some time" means
>> or
>>>> at
>>>>>> least the order of magnitude? Maybe it could be recommended to
>> wait a
>>>>>> couple of seconds? Or how long is it usually expected to take until the
>>>> half-
>>>>>> open connection will be expired?
>>>>>> 
>>>>>> 3) Also here:
>>>>>> "then the initiator doesn't abort the
>>>>>> exchange immediately, but instead waits some time for more
>> responses
>>>>>> (possibly retransmitting the request)."
>>>>>> How long should one wait? Probably 1-2 RTTs if the RTT is known or
>>>> maybe
>>>>>> there is some good max value like 500ms or 1s or more...?  Is there
>> any
>>>> risk
>>>>>> in waiting too long?
>>>>>> 
>>>>>> 3) And one high-level comment (without knowing to much details
>> about
>>>>>> IKEv2):
>>>>>> Would it be possible do a downgrade detection, meaning when non-
>> PKK
>>>>>> encryption is established the initiator would tell the responser again
>> that
>>>> it
>>>>>> was initially requesting PKK, just to double-check...?
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> IPsec mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/ipsec
>>>>> 
>>>>> 
>>> 
>>> 
>>> 
> 
>