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

Valery Smyslov <smyslov.ietf@gmail.com> Thu, 18 June 2020 12:19 UTC

Return-Path: <smyslov.ietf@gmail.com>
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 213F83A0CCF for <ipsec@ietfa.amsl.com>; Thu, 18 Jun 2020 05:19:10 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 hOPg98Fe-Bdp for <ipsec@ietfa.amsl.com>; Thu, 18 Jun 2020 05:19:07 -0700 (PDT)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57AAD3A0CCC for <ipsec@ietf.org>; Thu, 18 Jun 2020 05:19:07 -0700 (PDT)
Received: by mail-lj1-x229.google.com with SMTP id e4so6966677ljn.4 for <ipsec@ietf.org>; Thu, 18 Jun 2020 05:19:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :thread-index:content-language; bh=AO/eC/uoZZw1ebAZbbqBi+lNAg5mepb4Rz0GQ/RO8ac=; b=hOt+AKmueZJ7wHlSMTIGSf1/7bVCb6CjCkhyJAEVNT0eBct7v4MUcxn5AUghr1ucMw 4mW1qKVPvO1DRB7bdgdwSZDiMu1H6f1qCpi6CEeUYnit1fOh9DMz9TSd6wdZr8sI9AvX ZIIpUloNCeB9rjPBUz+TFwoIA4UkOBZNHqyBOJRENK8V0t/8rFbSpRXA20ChCOBA68AI PE9c+8Bp9Y5d2IexHpHQWUOZsiaVDL6Jp0ZXuAzp7ZAsZByHZ1djfNhTA94YLIrzcfKv gqa9pfu3UFE/2CEckIYhqsrq5aGXgku+m3JqcoIDNHxAWc6VtnYfcE2gJ8ZBQd4njRTT DuZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=AO/eC/uoZZw1ebAZbbqBi+lNAg5mepb4Rz0GQ/RO8ac=; b=RhZVB1Z5p2WKebrDFEX9Jx3jiR28OUOA/BiWwMng6h3QuujzTxHWORL1DEOKmiaKYM iLXnBuvzvLSNHI6OSknc1JqSQz2u0FhlmojbYmFN+N7jzBN8nSGc5y594MTN0NAcA90y I6RP/+MMppkAX5RaQNTncFreJ04lyCGQBpEGIi2xx+lJ8sofOjEyWtqOkrq6TQIjvYV0 zusgnxSdFnyTE0yXN+BJ7rAAEXtLHUb2GeXA/QGrDRLhRFInEdSb1FqIn800Nfj4ia0r WpusywUQCkwrSYWGR+AoqLe7hJ1X7uFomIykTwuTH/lVXo3HPDmraI3I6ZcbHsvE1zL8 ltaQ==
X-Gm-Message-State: AOAM530bd29/x6oXGjszLZ1k5L4sOndLfo+AeOYrNj7tAjyso0BP6wYi ix+dhNqzsYG5O8aCQYmsFKhYMZ6E
X-Google-Smtp-Source: ABdhPJz0cL59KueRkodHTfd4uVbK3Kue1/41amV25iffPml7R6ki3WzyW/NsZjhKClh1AYVSCk2Qdw==
X-Received: by 2002:a2e:8002:: with SMTP id j2mr2255215ljg.158.1592482744824; Thu, 18 Jun 2020 05:19:04 -0700 (PDT)
Received: from buildpc ([82.138.51.3]) by smtp.gmail.com with ESMTPSA id e13sm605141ljo.6.2020.06.18.05.19.02 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jun 2020 05:19:03 -0700 (PDT)
From: Valery Smyslov <smyslov.ietf@gmail.com>
To: "'Dang, Quynh H. (Fed)'" <quynh.dang@nist.gov>, 'ipsecme mailing list' <ipsec@ietf.org>
References: <BY5PR09MB47550EF86C79AD4B009DACE2F39A0@BY5PR09MB4755.namprd09.prod.outlook.com>, <059d01d644af$4f2c7ed0$ed857c70$@gmail.com> <BY5PR09MB4755E77A264964F3D73FB7FEF39A0@BY5PR09MB4755.namprd09.prod.outlook.com>
In-Reply-To: <BY5PR09MB4755E77A264964F3D73FB7FEF39A0@BY5PR09MB4755.namprd09.prod.outlook.com>
Date: Thu, 18 Jun 2020 15:19:06 +0300
Message-ID: <067201d6456a$a9e97e70$fdbc7b50$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0673_01D64583.CF390060"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHCZ+QZYbN6OZwcSebby6LP6QErRwHGUNodAk21UNio5VLOIA==
Content-Language: ru
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/UVztEW__bIV1k1QszPPhX8f13IM>
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 12:19:10 -0000

Hi Quynh,

 

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.

 

          Note, that this is essentially the same approach - draft-multiple-ke is based on draft-ikev2-intermediate

          and only clarifies its usage for the particular case of KE methods with large public keys (and combining several KE too).

 

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). 

 

          There are already few implementations and they even had an interop last November.

          And you are right that the maximum IKEv2 message size is implementation dependent

          (in any case it is limited to 64 Kbytes).

 

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. 

 

          These drafts were specifically written to address 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 ?

 

          I think it depends on many factors. You are right that generally IPsec tunnels are relatively long lived.

          We also have an SA resumption mechanism (RFC 5723) that allows to quickly restore SA.

          But of course for the SA establishment we'll do have a penalty of performing more exchanges,

          and more data to transfer...

 

          Regards,

          Valery.

 

Regards,

Quynh. 


 <https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-intermediate-04> draft-ietf-ipsecme-ikev2-intermediate-04 - Intermediate
Exchange in the IKEv2 Protocol

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.