IETF Logo Mail Archive

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

"Dang, Quynh H. (Fed)" <quynh.dang@nist.gov> Thu, 18 June 2020 16:42 UTC

Return-Path: <quynh.dang@nist.gov>
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 4FCC23A0AD5 for <ipsec@ietfa.amsl.com>; Thu, 18 Jun 2020 09:42:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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=nist.gov
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 jDrmiHro6CQX for <ipsec@ietfa.amsl.com>; Thu, 18 Jun 2020 09:42:25 -0700 (PDT)
Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on2105.outbound.protection.outlook.com [40.107.91.105]) (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 73FF03A0943 for <ipsec@ietf.org>; Thu, 18 Jun 2020 09:42:25 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=H4+WKASsCgOdwHjbrjFyGLH7h3S2n6XNDT1euRu4tm9GZJsOgao0PS53X0UbfaecZ/mAu03TmOLUyhEzaLd0+1kH0yv77uNkSZGdAcGRqRlN2fTHVDupHO/QcWpQcrXYnlWR0arAzgg4zvqFrL4D08a1WrJG3/uyokbekK2lSUOyKECr7i3IHjsmwM2uEXb+wkaXhxiacWJqzMXAZDNqFMC2OS/3qq63MjHHwEJWCktwH4wUbh0gGRQIaQr9FuTAlO0Sae5Qq3genzX7eawbzJ06Z3JtIxoL3wq0G1NAThuXpvE6mPA2hw0FDiuz8qh+22YLQpx/mB6hnoKlYY0v8A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VcfvYiNGn1RBhNojtML9aExm0crtQgfkPIkHhzMZNrQ=; b=Z1mO9L5dCH20aa/WySgOdtiBwhdaTIw1IXhahbAGyHE7XzUvcLZhZLCnYJVt4FZ0v5y/JSKTrEGAhUU03OSg86D36UH9Zg8pfbU4dwPpYlxhy2O62xK3t9zsGwdL0LrMEMK279jCSarWOPejLKlHK3eMzCNBtQxf02vg8lip84GaiadNc0lAzN2s0ffOqmeld/A57145vgng7PokLaqOvkhwd2g4fj9+5tQ6w2q2UeGx5TZTDeCwbqfIlqG0ivyLrWJHmeeHMj+xMW2LLt8EcmooztKorO+nLkgLMSk+yZPqSZrt1Qcz+Hj6AHB5eCJt+7ofTlBz9poaej55FJbPmg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VcfvYiNGn1RBhNojtML9aExm0crtQgfkPIkHhzMZNrQ=; b=OSG8mXZpVuSvHbln4Mh58YLWp0rAPN9japVP8uSrey8ZsMZZQ4WLikwOaO0NaqDUGTEdZdSLtQ2oFZoJJB9+rSz3LIyf2C4j24RDB9VN9RhY5AbX7C96EcQ1Bng4AaOfDtg2B5SEZJEwyaMnGBZXNMhwiGoRYE4XYlqcuGMd0zU=
Received: from BY5PR09MB4755.namprd09.prod.outlook.com (2603:10b6:a03:24b::12) by BY5PR09MB4517.namprd09.prod.outlook.com (2603:10b6:a03:1d7::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Thu, 18 Jun 2020 16:42:23 +0000
Received: from BY5PR09MB4755.namprd09.prod.outlook.com ([fe80::ad7a:30eb:a279:a9a3]) by BY5PR09MB4755.namprd09.prod.outlook.com ([fe80::ad7a:30eb:a279:a9a3%6]) with mapi id 15.20.3109.021; Thu, 18 Jun 2020 16:42:23 +0000
From: "Dang, Quynh H. (Fed)" <quynh.dang@nist.gov>
To: "paul@nohats.ca" <paul@nohats.ca>
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>
Thread-Topic: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ?
Thread-Index: AQHWRKwTbexJ5B/60kaRS2oRKSlgJqjc1UQAgAAH7FWAAYCSgIAABUVggAAD6eiAAClbgIAAALFr
Date: Thu, 18 Jun 2020 16:42:23 +0000
Message-ID: <BY5PR09MB47555C6C46D68B3A496064AAF39B0@BY5PR09MB4755.namprd09.prod.outlook.com>
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>
In-Reply-To: <alpine.LRH.2.22.394.2006181221040.20534@bofh.nohats.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: nohats.ca; dkim=none (message not signed) header.d=none;nohats.ca; dmarc=none action=none header.from=nist.gov;
x-originating-ip: [2610:20:6005:218::92]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: b2a89744-9a70-4b78-2b09-08d813a693ab
x-ms-traffictypediagnostic: BY5PR09MB4517:
x-ld-processed: 2ab5d82f-d8fa-4797-a93e-054655c61dec,ExtAddr
x-microsoft-antispam-prvs: <BY5PR09MB4517DB55E0E278BA6881E7F5F39B0@BY5PR09MB4517.namprd09.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0438F90F17
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: RtfGEuasqWRhRSv0oCaccp61O/S6tFwcxFWLt4wUajeYRaBXziLLSQhfLzFs3xgxPFK/N31zzhgmHwzSgIr54oB/+aMxWeAx9q1dLDfb62N++r0lzwHi4HwZIUwKGyGa2rpr08i6c2BjPLunO5vM29IMz/zSZZC2yGz9c/2W+mVihtAfs+UJtMH2L3UUOjmqE8A1gke+Z4NZ0NtNPqCSrmXYhMRAuqrMyGCxdEGGYGRX2TZUZbidmw1EMFcfMsV+2+lmhiF7AJnxzKlJ0D7fdUk5WMl7dGBcQ+s/lMnSqteaZHgpe5aVRLRHlLXope7rMEPNB7hKOX8JSP1df74tWg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR09MB4755.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(366004)(396003)(136003)(376002)(346002)(39860400002)(7696005)(71200400001)(19627405001)(86362001)(316002)(6916009)(8936002)(8676002)(66476007)(66556008)(64756008)(66446008)(33656002)(54906003)(66946007)(76116006)(186003)(91956017)(83380400001)(55016002)(9686003)(52536014)(5660300002)(53546011)(6506007)(4326008)(478600001)(15650500001)(2906002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: 8DFtR4NIBCt71rTxlxBsEP2d/UG9DSBh1RiN3iwmep5FBJ/VkJyWi+K+SmKN3lofeKisPzWKhKyCE+8cAsnJqyA/yBSWMIminT+kkzVBi1eo/4/P2KY24ysKXfBFFP03vWR1xdnBVOKIX9nuWSbJeiL2JkSigBdk+QP32mQpjdufjbEU17gjGTDEh5GyNrKaec4oxFcy3SBU9uSno0T8jLJaUmJB8nHDnFl3uVNnxx7SJph+M+Lpo3Y0UMM0ES5GCaDVK/wKiH8CZ1f/v8AWx+Vo/yTjv7Lq+leOrnXC/v8F1aVuVBYEWBNkhqUEP/ltvB+H4KWPPi7OFQnOnQJKYimguZ0zqAQdqS73A+Q775xFw48148Zm17tbwQusazjt8f1mAvnwBMwHxVETQM4pRJdHcKPaygybZRDyfCf+8qHewJ7pXULy+Ad/TwLH7046OpUg5JqbmnSXlRt+W5ASeWvLqq60DFGFZqMPNjKHjPwY6fn+GzCYlTBzP1HDSmqM
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BY5PR09MB47555C6C46D68B3A496064AAF39B0BY5PR09MB4755namp_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-Network-Message-Id: b2a89744-9a70-4b78-2b09-08d813a693ab
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2020 16:42:23.3960 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: D0lRuBCgxZPsUcWn2RMK31Bgj3jlfbv3shN63dRjq/x5q+B+b9AkkIBI7BjXptvH
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR09MB4517
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/XRn4IHlFGjfhYiBDBo27MCw2MN8>
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:42:27 -0000

Hi Paul,

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.

Quynh.
________________________________
From: Paul Wouters <paul@nohats.ca>
Sent: Thursday, June 18, 2020 12:23 PM
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>
Subject: Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ?

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