Re: [IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-ikev2-intermediate-09: (with COMMENT)

Valery Smyslov <svan@elvis.ru> Wed, 02 March 2022 07:09 UTC

Return-Path: <svan@elvis.ru>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1907E3A12C0; Tue, 1 Mar 2022 23:09:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJ1jngUGiU5h; Tue, 1 Mar 2022 23:09:49 -0800 (PST)
Received: from dpmail.elvis.ru (dpmail.elvis.ru [93.188.44.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 581A03A12BD; Tue, 1 Mar 2022 23:09:45 -0800 (PST)
Received: from kmail.elvis.ru ([93.188.44.208]) by dpmail.elvis.ru with esmtp (Exim 4.89) (envelope-from <svan@elvis.ru>) id 1nPJ7D-00037b-3W; Wed, 02 Mar 2022 10:09:41 +0300
Received: from mail16.office.elvis.ru ([10.111.1.29] helo=mail.office.elvis.ru) by kmail.elvis.ru with esmtp (Exim 4.92) (envelope-from <svan@elvis.ru>) id 1nPJ7C-0004Mh-V1; Wed, 02 Mar 2022 10:09:39 +0300
Received: from MAIL16.office.elvis.ru (10.111.1.29) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Wed, 2 Mar 2022 10:09:38 +0300
Received: from buildpc (10.111.10.33) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server id 15.1.1779.2 via Frontend Transport; Wed, 2 Mar 2022 10:09:38 +0300
From: Valery Smyslov <svan@elvis.ru>
To: 'Éric Vyncke' <evyncke@cisco.com>, 'The IESG' <iesg@ietf.org>
CC: draft-ietf-ipsecme-ikev2-intermediate@ietf.org, ipsecme-chairs@ietf.org, ipsec@ietf.org, ynir.ietf@gmail.com
References: <164620305328.18018.5385286809724354469@ietfa.amsl.com>
In-Reply-To: <164620305328.18018.5385286809724354469@ietfa.amsl.com>
Date: Wed, 02 Mar 2022 10:09:41 +0300
Message-ID: <047201d82e04$7ccce7e0$7666b7a0$@elvis.ru>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFvw1VtCbDbI7T67gda/tEp9sY4Tq18eiiw
Content-Language: ru
X-CrossPremisesHeadersFilteredBySendConnector: MAIL16.office.elvis.ru
X-OrganizationHeadersPreserved: MAIL16.office.elvis.ru
X-KLMS-AntiSpam-Interceptor-Info: not scanned
X-KLMS-Rule-ID: 1
X-KLMS-Message-Action: clean
X-KLMS-AntiSpam-Status: not scanned, disabled by settings
X-KLMS-AntiPhishing: Clean, bases: 2022/02/20 23:15:00
X-KLMS-AntiVirus: Kaspersky Security for Linux Mail Server, version 8.0.3.30, bases: 2022/02/20 20:13:00 #18795747
X-KLMS-AntiVirus-Status: Clean, skipped
X-Spam-Scanner: Rspamd work in dpmail.elvis.ru, WHITELIST
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/P5BA8svC8KES3RsJeJ8L-t56h3E>
Subject: Re: [IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-ikev2-intermediate-09: (with COMMENT)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Wed, 02 Mar 2022 07:09:52 -0000

Hi Éric,

thank you for your comments.

> Éric Vyncke has entered the following ballot position for
> draft-ietf-ipsecme-ikev2-intermediate-09: 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/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-intermediate/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you for the work put into this document.
> 
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated even if only for my own education).
> 
> Special thanks to Yoav Nir for the shepherd's write-up including the section
> about the WG consensus.
> 
> I hope that this helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> ## Abstract
> 
> The abstract would benefit by adding a few use cases / applicability statement
> (per the shepherd's write-up and introduction, i.e., a hint for PQ crypto).

I updated the abstract as follows:

   This document defines a new exchange, called Intermediate Exchange,
   for the Internet Key Exchange protocol Version 2 (IKEv2).  This
   exchange can be used for transferring large amounts of data in the
   process of IKEv2 Security Association (SA) establishment.  An example
   of the need to do this is using Quantum Computer resistant key
   exchange methods for IKE SA establishment.  Introducing the
   Intermediate Exchange allows re-using the existing IKE fragmentation
   mechanism, that helps to avoid IP fragmentation of large IKE
   messages, but cannot be used in the initial IKEv2 exchange.

Is it OK?

> ## Section 1
> 
> s/If size of a message is large enough, IP fragmentation takes place/If size of
> a message is larger than the MTU, IP fragmentation takes place/

I have no problem with this clarification, but I suggest s/MTU/PMTU
in the new text, since IP fragmentation for IPv4 can also take place
on the intermediate routers. So, if you don't mind, I'll change the text to:

"If the size of a message is larger than the PMTU, ..."

> RFC 7383 is dated 2014, is it still applicable in 2022 ?

Yes. The problems with correct handling of IP fragments in SOHO devices
still persist, as far as I know, so RFC 7383 is still applicable. 
Most (if not all) IPsec vendors support it.

Thank you!

Regards,
Valery.