Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ?

Paul Wouters <paul@nohats.ca> Thu, 18 June 2020 16:52 UTC

Return-Path: <paul@nohats.ca>
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 28EBC3A0D50 for <ipsec@ietfa.amsl.com>; Thu, 18 Jun 2020 09:52:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 Tm9nHhSh8Blh for <ipsec@ietfa.amsl.com>; Thu, 18 Jun 2020 09:52:50 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 D1DDA3A0D37 for <ipsec@ietf.org>; Thu, 18 Jun 2020 09:52:49 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 49np0023SzzMvl; Thu, 18 Jun 2020 18:52:48 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1592499168; bh=CRv5A0Xsa2T34w4LWUxtG/xaoyNgE5t/o+/f0sFUqk4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=N/xNkdWXHqrKuanqQrgFj5svh3O0WmluzBzN724NPXBmwrCuXynNSofvUIOJQ5n5l Pghq9ymDVJWmczBj+jESfnxDQNd6rGxuYt0r+TGjerca9hvPfGoh0ZaWtSeIXCeLoi nVOKY+QEhwCA8mJyGVJciDTGDW8IwQkxQ9vAnFkk=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 9x-G9jhknLIs; Thu, 18 Jun 2020 18:52:47 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 18 Jun 2020 18:52:47 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 182DD6020D8B; Thu, 18 Jun 2020 12:52:46 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0DBD866A7A; Thu, 18 Jun 2020 12:52:46 -0400 (EDT)
Date: Thu, 18 Jun 2020 12:52:45 -0400
From: Paul Wouters <paul@nohats.ca>
To: "Dang, Quynh H. (Fed)" <quynh.dang@nist.gov>
cc: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>, "Panos Kampanakis (pkampana)" <pkampana@cisco.com>, Valery Smyslov <smyslov.ietf@gmail.com>, 'ipsecme mailing list' <ipsec@ietf.org>
In-Reply-To: <BY5PR09MB47555C6C46D68B3A496064AAF39B0@BY5PR09MB4755.namprd09.prod.outlook.com>
Message-ID: <alpine.LRH.2.22.394.2006181246100.20534@bofh.nohats.ca>
References: <BY5PR09MB47550EF86C79AD4B009DACE2F39A0@BY5PR09MB4755.namprd09.prod.outlook.com>, <059d01d644af$4f2c7ed0$ed857c70$@gmail.com> <BY5PR09MB4755E77A264964F3D73FB7FEF39A0@BY5PR09MB4755.namprd09.prod.outlook.com> <BN7PR11MB254714D71BB281B1B35FF662C99B0@BN7PR11MB2547.namprd11.prod.outlook.com>, <BN7PR11MB2641EC57D261F6DF13F3D702C19B0@BN7PR11MB2641.namprd11.prod.outlook.com> <BY5PR09MB4755DB61CF3B8CF894ADC388F39B0@BY5PR09MB4755.namprd09.prod.outlook.com>, <alpine.LRH.2.22.394.2006181221040.20534@bofh.nohats.ca> <BY5PR09MB47555C6C46D68B3A496064AAF39B0@BY5PR09MB4755.namprd09.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/QXR-t1GKx7CcQe8fVDwyota4L0w>
Subject: Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ?
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: Thu, 18 Jun 2020 16:52:51 -0000

On Thu, 18 Jun 2020, Dang, Quynh H. (Fed) wrote:

> I don't know 10,000 or 20,000 users trying to connect to a VPN server around the same time where each pair is 300 kilobytes or more would have a
> noticeable impact or not. It depends on many factors I think. One of the factors is how the server stores those data for its computations. 
> 
> Let's say each pair is a 0.5 megabyte, 20,000 users would be around 10G of memory/storage. So, the over all performance impact could be
> noticeable once in a while for some VPN network.  

If you need that much memory to keep state, I don't think it matters
exactly how you receive and send that using IKEv2? Perhaps some
post quantum algorithms are better in that you dont have to keep
so much state during the exchange? And that could be a reason to
favour those. But you are far more qualified to judge that, than I am.

The intermediate exchange allows you to have many additional round trips
if that helps you reduce CPU or memory use. So I think from an IKEv2
point of view, that is all the scaffolding we need to provide. When
the new algorithms appear, we can go and implement those in a new RFC,
using the intermediate exchange.

I think Valery also had some ideas on how in the future, we could avoid
doing a hybrid key exchange with a classic DH that just costs CPU and
no longer gets us any security.

Paul