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

Mirja Kühlewind via Datatracker <noreply@ietf.org> Tue, 07 January 2020 13:41 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: ipsec@ietf.org
Delivered-To: ipsec@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 786611200E9; Tue, 7 Jan 2020 05:41:13 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Mirja Kühlewind via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-ipsecme-qr-ikev2@ietf.org, David Waltermire <david.waltermire@nist.gov>, ipsecme-chairs@ietf.org, david.waltermire@nist.gov, ipsec@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.115.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Mirja Kühlewind <ietf@kuehlewind.net>
Message-ID: <157840447348.21027.3875533519589774243.idtracker@ietfa.amsl.com>
Date: Tue, 07 Jan 2020 05:41:13 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/5dqe7unlHogb4fBPZ9sPG907Bh4>
Subject: [IPsec] Mirja Kühlewind's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jan 2020 13:41:14 -0000

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