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

"Dang, Quynh H. (Fed)" <quynh.dang@nist.gov> Wed, 17 June 2020 16:36 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 776FA3A0AA0 for <ipsec@ietfa.amsl.com>; Wed, 17 Jun 2020 09:36:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.091
X-Spam-Level:
X-Spam-Status: No, score=-2.091 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, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 uCNQyqtntf_Q for <ipsec@ietfa.amsl.com>; Wed, 17 Jun 2020 09:36:42 -0700 (PDT)
Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on2129.outbound.protection.outlook.com [40.107.91.129]) (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 88C6A3A0ABA for <ipsec@ietf.org>; Wed, 17 Jun 2020 09:36:42 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZYFzXp6OpAsLAC0In1Lo36+bUpS0j86SBl4M7k1S3fGuEv6b8J4ppDUqftNvAb6VbaOjJEeY4Ff02ogMte7HEisePzck7alDhvVI7bTIQLq3Gv4WiHuOPEyCdj4DaZhJtEyels0heuPHNPNS3vQ0ahgcZ+eHFZIo8DtYljc9Ml64zAd5JfKKzLMHwM1VeNcBqsEoTuQIX8QrubDy3tvlos7plgkW4iDkeQqLquMvTa0ORRivf1SljY8uxNTHTUpbj77nfETt1r8cVYe7kbt3FL9p5XUpB9eG3zezBkdym1Pzz4ltd5WlvBWL3hfDg4U591aX7y4+tj3fH0ZX/0xxow==
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=v2rHWIVz3+4iC0/YdVFSfZKQ6zqXykI5ghIxqjPiJOQ=; b=eBbbron22Rq2TzS7l5MGEdYf8HwOcjOcCTlKMjBhYggY6GOQ2Ej193zR5Vn5+DY2cv9mIc3W74p0IqYgTY+7c8rRgjV41DRp7VK9iazlJdpQ92lO1ZMox60KnP9qtGAMsZ4UASF0h/aIPf590pHTFuT84ZAF6zPUIlPCHKh0vx2O2zO14NkhmLMNaauMJBEOecIFVAKHC7K5CjuXi0rsqjxfEbQNyQ2MGoZhZ7efkcoi7uQ7It43ANUzvzQFFSa5CL1FSMHjBsayufbRBlHWUiwNPWKyST+X963kl06f+uZSjBDEr0W24Mcogu9+XupsALt1WUDuOBIRHyfeHTpSxg==
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=v2rHWIVz3+4iC0/YdVFSfZKQ6zqXykI5ghIxqjPiJOQ=; b=OzFvmT6VQCdWr47jGMg0SRShDhixAsMOsZGs8F5BSpO7ifR3mLkOKEfs6VjCXttDF1yH8KQ0cFG7o+oL2QsPz21KJwHD5hsb+UYm+LdpItmEMPo0mnLRzFg2gkhuOOIgJNiXDLf57KRR+7Rd2nP87d6tSh9J/CIuU6BGZGNEL6g=
Received: from BY5PR09MB4755.namprd09.prod.outlook.com (2603:10b6:a03:24b::12) by BY5PR09MB4691.namprd09.prod.outlook.com (2603:10b6:a03:242::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Wed, 17 Jun 2020 16:36:38 +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; Wed, 17 Jun 2020 16:36:38 +0000
From: "Dang, Quynh H. (Fed)" <quynh.dang@nist.gov>
To: 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/60kaRS2oRKSlgJqjc1UQAgAAH7FU=
Date: Wed, 17 Jun 2020 16:36:38 +0000
Message-ID: <BY5PR09MB4755E77A264964F3D73FB7FEF39A0@BY5PR09MB4755.namprd09.prod.outlook.com>
References: <BY5PR09MB47550EF86C79AD4B009DACE2F39A0@BY5PR09MB4755.namprd09.prod.outlook.com>, <059d01d644af$4f2c7ed0$ed857c70$@gmail.com>
In-Reply-To: <059d01d644af$4f2c7ed0$ed857c70$@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nist.gov;
x-originating-ip: [129.6.152.168]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 00ff12c7-643b-4914-afd3-08d812dc9bb7
x-ms-traffictypediagnostic: BY5PR09MB4691:
x-microsoft-antispam-prvs: <BY5PR09MB4691FEDEAE646ACD92CD970EF39A0@BY5PR09MB4691.namprd09.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 04371797A5
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: dhtod901nrq0Q66q+imQhJNhlwcPdl6s98Iwrrsd+1hUsIRxEOIU31b7pT304XXDC62g8Kzi6OPEFr7bsy4HxD4w1cwm9fNoeEI7jm5f+BELvqGQUaVMvjFB9Pnxo0sRp/UTqJ6clP20EHqmPmxuhNbmlS72DNh+kddPQ4TQjzornv2n1v7WBg/r/w89l9bnH1rk828C4QVYpz5bbe42R4MSzT3AD7kXSsXboH8b2IOQdGwGQF8pVYqBKfWp68ZcbrEWO702jN1R5HpjkWoOUSjCTauFhv7aJMu0yorR8Kd58zlbxOsUcasazGU/aN08+LsiX9Vw0PirVvn48t7Bp64zGUiNQcWVcKG/dLJm7Cw5dwczCe9afpwiMsSR6p6HG14ekD4TmnDKp/1UK2DaNw==
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:(39860400002)(366004)(346002)(396003)(376002)(136003)(478600001)(9686003)(91956017)(76116006)(7696005)(66946007)(5660300002)(110136005)(6506007)(66556008)(64756008)(86362001)(316002)(15650500001)(19627405001)(53546011)(66476007)(52536014)(66574015)(66446008)(83380400001)(186003)(55016002)(26005)(8676002)(19627235002)(71200400001)(33656002)(2906002)(966005)(8936002)(166002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: 7NY4tbPTyJQtXT2Y7mHkwJyLHQoO1wnqO5OlaEDJIbM+Sm7H09qg/JHDg/xBBimXnHj5JukuZ2RtetkVGNEhtQDUUkgwZuGPzo6Lg+mxG3t61tHV8QPcIHikt9PCsFIvwyndwLrF7Isb5QnmInsiQVm0NIE1p2m88Pq1x6jaQZtKvW212fJDOik2KjmTqtYWiJZCoVe4lZ+YN9BoPha3xSYXGX08oOLwQBsL3cL9cxiOO/gPQg415QtJXXxgE/KFVbKvdJeHvZwkZ2wY8SaMQWtDDvlPrb6xhdzBg2JMo+J7vOGc8k3wBkKzer9ciWVFd/ypao4WGAWFPhF6ZCh2pjF30ut39AG/MjcZBX9yqT8B1Wo95mOTBoZNHIoHUQjXXwfBW2WtH2rRkeg37+yL+ksmzynRBz+pOi9Tp0f+iGRoYu+OiQLt4lwEYl66vXTHbcoNO95YnHbZv2+pyCz3EtjfJ2vJxUsGlofKpumWqnE=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BY5PR09MB4755E77A264964F3D73FB7FEF39A0BY5PR09MB4755namp_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-Network-Message-Id: 00ff12c7-643b-4914-afd3-08d812dc9bb7
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2020 16:36:38.6491 (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: wWNbhGGVaOzfRPx0o6OhjVpdWWWpYUuvRm7TrUO/Fzjv4wLNYqhK5bseoK8xcM+W
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR09MB4691
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/JwOX3-624C3BGRDdJaY8AgKJBBw>
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: Wed, 17 Jun 2020 16:36:56 -0000

Thank you Valery and thank you everyone who responded to me.

The approaches in the drafts https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-multiple-ke-00#section-1.1  and  https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-intermediate-04 look good to me.

It looks like if/when someone implements them and adds a large key and/or ciphertext KEM, the maximum IKEv2 message size must be adjusted if the existing implementation does not already support the corresponding message size with the new KEM ( for an ephemeral key exchange, it contains a public key and a ciphertext) because I don't see any mentioning of the maximum IKEv2 message size (it is an implementation specific issue).

Let's say after 10 or 15 years from now, the group trusts the security of some PQ KEM and signature algorithms and would like to use them in normal IKEv2 without the 2 methods above.

In that situation, if the KEM has large public key and/or ciphtertext would have the IP fragmentation and packet drop issues. So, this KEM should use the approaches in the drafts above to deal with these issues.

An obvious question is that what is the performance impact from this large KEM using the approaches above when compared with a KEM (if its public key and ciphertext are around 1,400-1,600 bytes in total) (assuming a pq signature algorithm has a small signature and a small public key) which would work well in a normal IKEv2's implementation ?

I guess the impact is small generally because an IPsec tunnel normally stays up for a long time. Does my guess seem ok here ?

Would there be some noticeable impact on a high-volume connections VPN server ?

Regards,
Quynh.
draft-ietf-ipsecme-ikev2-intermediate-04 - Intermediate Exchange in the IKEv2 Protocol<https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-intermediate-04>
This documents defines a new exchange, called Intermediate Exchange, for the Internet Key Exchange protocol Version 2 (IKEv2). This exchange can be used for transferring large amount of data in the process of IKEv2 Security Association (SA) establishment. Introducing Intermediate Exchange allows re-using existing IKE Fragmentation mechanism, that helps to avoid IP fragmentation of large IKE ...
tools.ietf.org



________________________________
From: Valery Smyslov <smyslov.ietf@gmail.com>
Sent: Wednesday, June 17, 2020 9:57 AM
To: Dang, Quynh H. (Fed) <quynh.dang@nist.gov>; 'ipsecme mailing list' <ipsec@ietf.org>
Subject: RE: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ?


Hi Quinh,



please look at the  draft-ietf-ipsecme-ikev2-multiple-ke-00.

It specifically addresses your concern about large public keys of PQ KE methods.



Actually, it’s generally OK to have public keys/signatures up to 64Kbytes.

If you need to deal with larger keys, then some update of the specs is needed.



Regards,

Valery.





From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Dang, Quynh H. (Fed)
Sent: Wednesday, June 17, 2020 4:49 PM
To: ipsecme mailing list
Subject: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ?



Hi everyone,



I am interested in knowing what are typical maximum sizes for IKEv2 messages and UDP messages in implementations.



The reason is that the IKEv2's spec has a must and a should being 1280 and 3000 bytes respectively for IKEv2 messages, but does not have a maximum limit.



As you know some of the post quantum cryptographic candidates in our standardization process have large or very large public key , signature and/or ciphertext sizes.



My guess is that some updates to the spec and/or implementations would make them work.



Your data points and discussions are appreciated.



Regards,

Quynh.