> Hi Valery, > > Both look good to me. Thanks! > > One typo: s/mesages/messages/
Thank you! Regards, Valery. > Thanks! > Mirja > > > > > On 8. Jan 2020, at 15:04, Valery Smyslov <s...@elvis.ru> 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 <ipsec-boun...@ietf.org> On Behalf Of Mirja > >> Kühlewind > >>>> via > >>>>>>>> Datatracker > >>>>>>>> Sent: Tuesday, January 07, 2020 8:41 AM > >>>>>>>> To: The IESG <i...@ietf.org> > >>>>>>>> Cc: ipsec@ietf.org; ipsecme-cha...@ietf.org; > >>>> david.walterm...@nist.gov; > >>>>>>>> draft-ietf-ipsecme-qr-ik...@ietf.org > >>>>>>>> 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 > >>>>>>>> IPsec@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/ipsec > >>>>>>> > >>>>>>> > >>>>> > >>>>> > >>>>> > >>> > >>> > > > > > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
