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. 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. 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. 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. 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
