IETF Logo Mail Archive

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

Paul Wouters <paul@nohats.ca> Thu, 18 June 2020 16:23 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 91BF43A0D94 for <ipsec@ietfa.amsl.com>; Thu, 18 Jun 2020 09:23:43 -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=unavailable 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 FmQvrpTCE-lM for <ipsec@ietfa.amsl.com>; Thu, 18 Jun 2020 09:23:41 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::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 0E2053A0D49 for <ipsec@ietf.org>; Thu, 18 Jun 2020 09:23:40 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 49nnLM4RHczMvl; Thu, 18 Jun 2020 18:23:39 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1592497419; bh=Ctt2DrsIohh+ffEKQTFkU7Dpx28VG1NIJkyIZ47CPK8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=NWoe1mbL7GOkpQjXOC/F5NCZMFqk4OljVp/f2XJIDRpqAI1DFKRY5x8dBIxNiIIoM sGgvNWaoq3vuwuscKYIDRuFNR6eRzfepx8YRv8qPYTgUbJK+SFiFfwh2ooxY8+gnUR /LGxY/q1ED9whcoG5k3CzxDv/gEv2qNeg4ukYeaM=
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 tBqY9-7jeVrW; Thu, 18 Jun 2020 18:23:38 +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:23:38 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 78A1E6020D8B; Thu, 18 Jun 2020 12:23:37 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7724966A7A; Thu, 18 Jun 2020 12:23:37 -0400 (EDT)
Date: Thu, 18 Jun 2020 12:23:37 -0400
From: Paul Wouters <paul@nohats.ca>
To: "Dang, Quynh H. (Fed)" <quynh.dang=40nist.gov@dmarc.ietf.org>
cc: "Scott Fluhrer (sfluhrer)" <sfluhrer=40cisco.com@dmarc.ietf.org>, "Panos Kampanakis (pkampana)" <pkampana@cisco.com>, Valery Smyslov <smyslov.ietf@gmail.com>, 'ipsecme mailing list' <ipsec@ietf.org>
In-Reply-To: <BY5PR09MB4755DB61CF3B8CF894ADC388F39B0@BY5PR09MB4755.namprd09.prod.outlook.com>
Message-ID: <alpine.LRH.2.22.394.2006181221040.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>
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/GxbI9bxAuOVv_8r7HGkUsd5zjAM>
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:23:50 -0000

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

> Hi Panos and Scott,
> 
> That was exactly what I was thinking. We have been working remotely.
> 
> One could have more than 300 kbytes for a pair of (public key + ciphertext and public key + sig).  The latter public key may be replaced by a
> cert chain.
> 
> The impact varies from one situation to another I think. 

> Speaking as a previous IPsec implementor, the biggest concern I had over IKE performance was in the ‘flash crowd’ scenario; that is, you’re an
> IPsec-based security gateway, and then suddenly everyone wanted to negotiate with you.  This can happen if it’s 8:00 AM (and everyone just
> arrived at work), or if you’re a back-up gateway, and then the primary gateway just failed.

We have RFC 5685 REDIRECT for that. If your server becomes too busy, it
can redirect new or existing clients to another gateway, provided that
other gateway will authenticate itself identically to this gateway.

I don't think the key sizes really matter here. Even if computation is
2x or 3x more CPU intensively, from an "overloaded server" point of view
that just means like "redirect if at 3000 clients" vs "redirect if at
2000 clients".

Paul

v2.23.0 | Report a Bug | By Email