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

[Mirja Kuehlewind <[e-mail]>]

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.

> 
>> 2) It is a little hard to include a time that would match all situations. It really
>> depends on the server DoS protection policy and when it kicks on. The
>> initiator cannot really know how fast is considered too fast for the
>> responder so it has to make a conservative decision. Adding a " (e.g.,
>> seconds) " would probably suffice here.
> 
> Since this situation is most probably caused by misconfiguration (or some attack),
> I think that the period of inactivity for the initiator should be longer, at least several minutes.
> Anyway, I agree that it's hard to give universal advice here.
> I'd leave the text as is, since the reference to "misconfiguration"
> in this para gives in my opinion enough hint of how long to wait.

Since you both disagree by an order of magnitude, it seems to me that some more advise would actually be helpful. It’s fully understood that there is no one value that fits all but providing further advise what this value depends on and what could be a good range in most cases could be helpful. I would actually think that given the misconfiguration is on the other end and the person implementing this value has no idea about what the misconfiguration would be, it’s anyway guessing, so why not guess now and give some advise.

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

> 
>> 4) I am not sure adding one more notification for downgrade detection
>> adds much here. Remember IKEv2 has subsequent messages to do
>> IKE_AUTH etc and we wanted to not introduce more significant deviations
>> on IKEv2.
>> 
>> If the PPK is optional for both peers then downgrade is possible but it is the
>> cost of being flexible to allow some peers to use PPK and some to not. If any
>> of the peers has PPK as mandatory then downgrade will be caught and
>> rejected as explained in the Sec Considerations section, so I think we are OK
>> there.
> 
> I agree with Panos: the downgrade is possible only if using PPK is optional
> for both, in which case both parties agree that downgrade is OK.

Having some downgrade detection would enable to log an attack if optional PPK was used. This could give further insights for the network admin or provide some motivation to move quickly to mandatory PPK. Alternative you could of course even have another config option where PPK is optional but you still close the connection with an error if downgrade is detected later on. Was just an idea…


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