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

[Mirja Kuehlewind <[e-mail]>]

Hi Valery,

Both look good to me. Thanks!

One typo: s/mesages/messages/

Thanks!
Mirja



> On 8. Jan 2020, at 15:04, Valery Smyslov <[e-mail]> wrote:
> 
> Hi Mirja,
> 
> [...]
> 
>>> 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.
> 
> OK.
> 
>    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 MUST include a NO_PPK_AUTH notification in the above
>   message  to indicate this optionality to the responder.
> 
>>> [...]
>>> 
>>>>>>>> 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.
> 
> Is this better?
> 
> 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 response mesages
> retransmitting the request as if no responses were received at all,
> until either the received message contains the USE_PPK or exchange times out 
> (see section 2.4 of [RFC7296] for more details on retransmission timers in IKEv2). 
> If all the received responses contain no USE_PPK, then the exchange is aborted.
> 
> Regards,
> Valery.
> 
>> 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
>>>>>>> 
>>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>> 
>>> 
> 
> 
>