From nobody Mon Jun 1 13:20:39 2020 Return-Path: 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 302F43A1535; Mon, 1 Jun 2020 13:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ssZo5K0vjKCO; Mon, 1 Jun 2020 13:20:37 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id EA61C3A14C3; Mon, 1 Jun 2020 13:20:36 -0700 (PDT) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 57AFA60F1A; Mon, 1 Jun 2020 20:20:36 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Christian Hopps In-Reply-To: <13344.1583165241@localhost> Date: Mon, 1 Jun 2020 16:20:35 -0400 Cc: Christian Hopps , IPsecME WG , ipsecme-ads@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <13344.1583165241@localhost> To: ipsecme-chairs@ietf.org X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [IPsec] Early Allocation Request for IPTFS_PROTOCOL IP protocol number. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2020 20:20:38 -0000 Dear ipsecme Chairs, This request is inline with the guidelines as set forth in RFC7120 = (https://tools.ietf.org/html/rfc7120) I would like to request early allocation of the IP protocol number [A] = used for the ESP payload identifier for IPTFS (suggested value is 144 or = next available) as documented in = https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-01 [B] This will aid in the deployment of an experimental implementation of the = documented protocol as well as testing inter-operability with other = expected implementations. [C], [D] In addition to these RFC7120 reasons, the topic was raised on the WG = list and discussed in previous meetings. The discussions highlighted = that early allocation was a good choice as it allowed for the temporary = assignment and an extended period of time for adequate review (and = explanation if needed) of this allocation prior to publication requested = being reached. Thanks, Chris. [A-D] - refer to https://tools.ietf.org/html/rfc7120#page-4 section 2a - = 2d. From nobody Tue Jun 2 07:21:16 2020 Return-Path: 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 22DE53A0ABD; Tue, 2 Jun 2020 07:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_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=iki.fi 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 NrtwR39ZlGwq; Tue, 2 Jun 2020 07:21:11 -0700 (PDT) Received: from meesny.iki.fi (meesny.iki.fi [195.140.195.201]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 509E73A0AB9; Tue, 2 Jun 2020 07:21:10 -0700 (PDT) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: kivinen) by meesny.iki.fi (Postfix) with ESMTPSA id 7269A202FB; Tue, 2 Jun 2020 17:21:08 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1591107668; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JYvsIn59AGpk8BscVF22yHwK2FiCbF8/jBvqGET6xQI=; b=TjgDRsW0WxhMbJ0ktjShh0Mo1466w0jbzGzKKSXR/WQ7FiS/Sx58aJmo+c62srIHN5tDhG tuQYQLcCZOeGNhUwbGj9jOjNf8n1CVBtrgnsjyNJtkQuPfNhNuy3rDSfV4LcWc8Ngas/MV GQ5ydIgaGInombxGE7IM7cpah5LL0O0= Received: by fireball.acr.fi (Postfix, from userid 15204) id 2FD9225C12BA; Tue, 2 Jun 2020 17:21:08 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24278.24659.921904.72666@fireball.acr.fi> Date: Tue, 2 Jun 2020 17:21:07 +0300 From: Tero Kivinen To: Christian Hopps Cc: ipsecme-chairs@ietf.org, IPsecME WG , ipsecme-ads@ietf.org In-Reply-To: References: <13344.1583165241@localhost> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 16 min X-Total-Time: 17 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1591107668; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JYvsIn59AGpk8BscVF22yHwK2FiCbF8/jBvqGET6xQI=; b=o/o2wEvEJXic8m3oBRAxn3nCFVDc43ZSHyCHMtZtj4DHCqFSkjiLrmCOV9BQIr6tFEJjY1 YpaWm0RHProK2suK34lD+FniqR+AdPCdZA+SVRNlU3auy5KH7e/WsnWDkRvILpPHXbZymW F+Ba6/gPyQhYrnb9Y1i7Ve47u3Sq/Xo= ARC-Seal: i=1; s=meesny; d=iki.fi; t=1591107668; a=rsa-sha256; cv=none; b=iTeae5YYzZxgwigLltCJW4wCzpUqENutbkYBs/eBhpykbVMWAcUQX+IWeJpWuGVkg8neIZ LI2HslI7saYu4JYTsIuW3CWW4PVAW6xwcYcLl2T/K9jZM/vTM/5HoTsYBjV4T590I5qjiF iGWrdYeExgC2S1IoKpio4zssweg2ZuQ= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: [IPsec] Early Allocation Request for IPTFS_PROTOCOL IP protocol number. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 14:21:14 -0000 Christian Hopps writes: > Dear ipsecme Chairs, > > This request is inline with the guidelines as set forth in RFC7120 > (https://tools.ietf.org/html/rfc7120) > > I would like to request early allocation of the IP protocol number > [A] used for the ESP payload identifier for IPTFS (suggested value > is 144 or next available) as documented in > https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-01 [B] > > This will aid in the deployment of an experimental implementation of > the documented protocol as well as testing inter-operability with > other expected implementations. [C], [D] > > In addition to these RFC7120 reasons, the topic was raised on the WG > list and discussed in previous meetings. The discussions highlighted > that early allocation was a good choice as it allowed for the > temporary assignment and an extended period of time for adequate > review (and explanation if needed) of this allocation prior to > publication requested being reached. I am bit concerned about this. First of all, as far as I understand for IPsec we do not need real IP protocol number, as the number we are using is never going to appear anywhere in the actual IP packet header, it only appears in the ESP trailer Next Header field. Note, that the ESP Next Header field is not exactly same as IP Protocol Numbers, it is: The Next Header is a mandatory, 8-bit field that identifies the type of data contained in the Payload Data field, e.g., an IPv4 or IPv6 packet, or a next layer header and data. The value of this field is chosen from the set of IP Protocol Numbers defined on the web page of the IANA, e.g., a value of 4 indicates IPv4, a value of 41 indicates IPv6, and a value of 6 indicates TCP. i.e., it is separate set of numbers, which happen to mostly match what IP protocol numbers use, but we also interpret some values differently, for example value 59 (IP protocol no next header) is used to indicate dummy packet etc. We could easily use similar trick than what we use for dummy packets for this too. Also there is warpped ESP which would allow us to use that, which would again allow us to do things without allocating new IP protocol number. We had some discussion about this in the mailing list earlier, but I didn't think that there was really a final result from that discussion (or I might be remembering wrong, as I didn't have too much time to participate that discussion at that time). The reason I am concerned is that I was there when we wanted to get the Wrapped ESP IP protocol number, and there was quite a lot of discussion going on at that time, and it was not just we send request, and we get the number. Of course at that point I also supported proposal which did not require new IP protocol number, so for me the problems getting IP number was for my favor :-) Anyways before we commit resources and try to get the IP protocol number I want to make sure we actually need it, and we have good responses to why we cannot do it with the other ways I presented above. I would assume those questions are going to be asked from chairs or area directors during the process anyways, so we need to have good answers to them ready (and for me it would be quite hard to explain why we cannot use warpped ESP, or dummy packet trick as I think we can do those and we do not need IP protocol number). Note, that if the answer is going to be that we want to use this also when we are not using IPsec, then this is even bigger can of worms, as that would most likely mean that this work does not belong to the IPsecME working group, but should be part of completely different area... -- kivinen@iki.fi From nobody Tue Jun 2 08:57:27 2020 Return-Path: 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 754A43A0DFA; Tue, 2 Jun 2020 08:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 4LV-4uKTGPBC; Tue, 2 Jun 2020 08:57:22 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id D36603A0D34; Tue, 2 Jun 2020 08:56:49 -0700 (PDT) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 3285F60EC0; Tue, 2 Jun 2020 15:56:48 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Christian Hopps In-Reply-To: <24278.24659.921904.72666@fireball.acr.fi> Date: Tue, 2 Jun 2020 11:56:48 -0400 Cc: Christian Hopps , ipsecme-chairs@ietf.org, IPsecME WG , ipsecme-ads@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7322AB98-43B1-43E2-BCC6-7EC685869A8B@chopps.org> References: <13344.1583165241@localhost> <24278.24659.921904.72666@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [IPsec] Early Allocation Request for IPTFS_PROTOCOL IP protocol number. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 15:57:27 -0000 > On Jun 2, 2020, at 10:21 AM, Tero Kivinen wrote: >=20 > Christian Hopps writes: >> Dear ipsecme Chairs, >>=20 >> This request is inline with the guidelines as set forth in RFC7120 >> (https://tools.ietf.org/html/rfc7120)=20 >>=20 >> I would like to request early allocation of the IP protocol number >> [A] used for the ESP payload identifier for IPTFS (suggested value >> is 144 or next available) as documented in >> https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-01 [B]=20 >>=20 >> This will aid in the deployment of an experimental implementation of >> the documented protocol as well as testing inter-operability with >> other expected implementations. [C], [D]=20 >>=20 >> In addition to these RFC7120 reasons, the topic was raised on the WG >> list and discussed in previous meetings. The discussions highlighted >> that early allocation was a good choice as it allowed for the >> temporary assignment and an extended period of time for adequate >> review (and explanation if needed) of this allocation prior to >> publication requested being reached.=20 >=20 > I am bit concerned about this. First of all, as far as I understand > for IPsec we do not need real IP protocol number, as the number we are > using is never going to appear anywhere in the actual IP packet > header, it only appears in the ESP trailer Next Header field. We would if people want to re-use the framing outside of IPsec. This is = not a requirement for us, but it's something to consider none-the-less = (more below on that though). > Note, that the ESP Next Header field is not exactly same as IP > Protocol Numbers, it is: >=20 > The Next Header is a mandatory, 8-bit field that identifies the type > of data contained in the Payload Data field, e.g., an IPv4 or IPv6 > packet, or a next layer header and data. The value of this field is > chosen from the set of IP Protocol Numbers defined on the web page = of > the IANA, e.g., a value of 4 indicates IPv4, a value of 41 indicates > IPv6, and a value of 6 indicates TCP. >=20 > i.e., it is separate set of numbers, which happen to mostly match what > IP protocol numbers use, but we also interpret some values > differently, for example value 59 (IP protocol no next header) is used > to indicate dummy packet etc. Re-purposing is good backup option we have available to us if for some = odd reason we cannot ultimately retain our early allocation. I don't = think this should stop us from getting an early allocation even if we = were to end up choosing this option though. > We could easily use similar trick than what we use for dummy packets > for this too. Also there is warpped ESP which would allow us to use > that, which would again allow us to do things without allocating new > IP protocol number. I did talk about why wrapped was not an optimal solution in an earlier = thread, and received an agreement with my reasoning there. In short it = still has a next-header field requirement so we are back to where we = started, and we lose bandwidth to boot. I think the repurposing of a = protocol number as a backup solution is better than trying to use WESP. >=20 > We had some discussion about this in the mailing list earlier, but I > didn't think that there was really a final result from that discussion > (or I might be remembering wrong, as I didn't have too much time to > participate that discussion at that time). >=20 > The reason I am concerned is that I was there when we wanted to get > the Wrapped ESP IP protocol number, and there was quite a lot of > discussion going on at that time, and it was not just we send request, > and we get the number. Of course at that point I also supported > proposal which did not require new IP protocol number, so for me the > problems getting IP number was for my favor :-) >=20 > Anyways before we commit resources and try to get the IP protocol > number I want to make sure we actually need it, and we have good > responses to why we cannot do it with the other ways I presented > above. This should not be that big of a deal if we have justification, which we = do, but this is one reason for the early allocation. Doing an early allocation allows us to move forward, and in the end if = we cannot get the allocation or it becomes too onerous we could then = re-use an existing number as a backup. So this shouldn't be a big drain = on the WG either way. Getting the early allocation also will allow 2 years for people who want = to to experiment with non-IPsec uses (the E in IETF :) If something = comes of that then it will help provide further justification for making = the allocation permanent. Its worth noting that the basic header associated with the proposed IP = protocol number is a single sub-type octet which defines what follows. = It places no restrictions on what follows that sub-type octet, and so it = is *very* easy to re-use this protocol number in the future. It is much = more reusable than WESP, for example. I think this should also help = answer external objections if they are raised. > I would assume those questions are going to be asked from chairs or > area directors during the process anyways, so we need to have good > answers to them ready (and for me it would be quite hard to explain > why we cannot use warpped ESP, or dummy packet trick as I think we can > do those and we do not need IP protocol number). >=20 > Note, that if the answer is going to be that we want to use this also > when we are not using IPsec, then this is even bigger can of worms, as > that would most likely mean that this work does not belong to the > IPsecME working group, but should be part of completely different > area... As I mentioned above, people have already expressed interest in possibly = using the IPTFS framing outside of IPsec for some of its positive = non-IPsec properties. This doesn't mean we have to boil the ocean and = standardize the framing outside of IPsec, it just means we should be = considerate about the possible re-use while we do our work. Thanks, Chris. > --=20 > kivinen@iki.fi >=20 From nobody Tue Jun 2 13:40:54 2020 Return-Path: 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 4D3F83A0FCF for ; Tue, 2 Jun 2020 13:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 SBNkQreqYFji for ; Tue, 2 Jun 2020 13:40:49 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 531DA3A0418 for ; Tue, 2 Jun 2020 13:40:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 8EBC038A90; Tue, 2 Jun 2020 16:38:25 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id go0qhpWAKFrv; Tue, 2 Jun 2020 16:38:24 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 1EF0338A87; Tue, 2 Jun 2020 16:38:24 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 72B3D75; Tue, 2 Jun 2020 16:40:46 -0400 (EDT) From: Michael Richardson To: Tero Kivinen , Christian Hopps , IPsecME WG In-Reply-To: <24278.24659.921904.72666@fireball.acr.fi> References: <13344.1583165241@localhost> <24278.24659.921904.72666@fireball.acr.fi> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] Early Allocation Request for IPTFS_PROTOCOL IP protocol number. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 20:40:52 -0000 --=-=-= Content-Type: text/plain Tero Kivinen wrote: > I am bit concerned about this. First of all, as far as I understand > for IPsec we do not need real IP protocol number, as the number we are > using is never going to appear anywhere in the actual IP packet > header, it only appears in the ESP trailer Next Header field. Yes, we did have this conversation. We know that it can't be a number that IANA might re-use for a an actual protocol number. So it could somehow be a re-use of something that is obsolete, historic, or just contradicted with ever being used with IPsec. (If I had to pick a such a number, I'd use AH's number) > We had some discussion about this in the mailing list earlier, but I > didn't think that there was really a final result from that discussion > (or I might be remembering wrong, as I didn't have too much time to > participate that discussion at that time). My memory is that most people didn't think that protocols numbers were so scarce that the cost exceeded the possible confusion. Christian is asking for one number, not ten. > The reason I am concerned is that I was there when we wanted to get > the Wrapped ESP IP protocol number, and there was quite a lot of > discussion going on at that time, and it was not just we send request, > and we get the number. Of course at that point I also supported > proposal which did not require new IP protocol number, so for me the > problems getting IP number was for my favor :-) Does anyone use Wrapped ESP? Can we just mark that as historic now :-) > Note, that if the answer is going to be that we want to use this also > when we are not using IPsec, then this is even bigger can of worms, as > that would most likely mean that this work does not belong to the > IPsecME working group, but should be part of completely different > area... Let's assume that we might want to use this protocol with another secure tunnel protocol which was not ESP. But, not in the clear over the Internet. (Think: QUIC, Wireguard, OpenVPN) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl7WuU4ACgkQgItw+93Q 3WWfIAgAogJDn7qdfaGeR40/wPiBnSH+ioGA5tD+0pzt+W69mSJ8KX+1bPhbXecS M7j78NSGaq6CEldBVWm1zkdIlFcaeN73o3Q/Y9wxXWk93Vvl1uXhR3pCqEOPrBFV f6+UIxjmuJ4UGcajgy6aMlCv2/c5wBj1uRMTBVSChXLdfdxuHwQzVaa7w4N53Gtu p+oKcLh9tBj7eBQ2DDNIjvoOhIZA4/os9Rlixer3zV/D0WI54D83l5kTlkjrcVWk WfoTXdK8i8VKHoQz3w3QGWvWS6XvLkK9TDQhpz7s+BSYqQzp3oDMAUi14EkrJqTF wYxI5M4m5YdpwuENQgPLJgD6ZbF+vA== =it7K -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 5 12:40:51 2020 Return-Path: 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 1A3CE3A0786 for ; Fri, 5 Jun 2020 12:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=edDk0GEh; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=e4YdWXK9 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 t8OVK2KlSOtc for ; Fri, 5 Jun 2020 12:40:48 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C97B73A077A for ; Fri, 5 Jun 2020 12:40:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9368; q=dns/txt; s=iport; t=1591386047; x=1592595647; h=from:to:subject:date:message-id:mime-version; bh=jPcXvCaNAY7h0H3KPl4sLOLEYKzZTZwN1wVjca3q+iI=; b=edDk0GEh5/v2R9aC+YXdCcrVt3xkyA2yTCuElzjOH8xkK47yWfdFGfYs +F1YoSqXpLntRfoPibOJctARzP+ZhzyS+cNUKQ6LxwpkI56Cgawt9+7nU eO03z5LanwlZ2vcauEM6c6QZTATBKLDaShi+WwLghUTlioYYPyvBm8N9O I=; X-IPAS-Result: =?us-ascii?q?A0DmCABLn9pe/5RdJa1mgQmBSoEjL1IHb1gvLAqHYQOhK?= =?us-ascii?q?oRogUKBEANVCwEBAQwBAS0CBAEBhEQCgjQCJDcGDgIDAQEBAwIDAQEBAQUBA?= =?us-ascii?q?QECAQYEbYVbAQuGCwsQEwEBOBEBgQAmAQQbGoMFgX5NAy4BqCsCgTmIYXSBN?= =?us-ascii?q?IMBAQEFhWIYgg4JgTiCZIloGoFBP4FUhyQBEgEJGoNFgi2YNZtNCoJZBI5Ii?= =?us-ascii?q?lWeQZEAngoCBAIEBQIOAQEFgWkjZnBwFTuCaVAXAg2UMopWdDcCBggBAQMJf?= =?us-ascii?q?IwKLYEGAYEPAQE?= IronPort-PHdr: =?us-ascii?q?9a23=3Aru62xROVXcpgYz7/pAUl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvKw33l7EQYud7OhL2KLasKHlDGoH55vJ8HUPa4dFWB?= =?us-ascii?q?JNj8IK1xchD8iIBQyeTrbqYiU2Ed4EWApj+He2YklYBMi4YEfd8TW+6DcIEU?= =?us-ascii?q?D5Mgx4bu3+Bo/ViZGx0Oa/s53eaglFnnyze7R3eR63tg7W8MIRhNhv?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.73,477,1583193600"; d="scan'208,217";a="479915348" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Jun 2020 19:40:46 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 055JekWj009993 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 5 Jun 2020 19:40:46 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 5 Jun 2020 14:40:46 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 5 Jun 2020 15:40:45 -0400 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 5 Jun 2020 14:40:45 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hgh97EM9ncmJwZQlOy2hEcYjuD3xmNH9voXT8kDpfss3Gmr2TyxVlNzZEvO1k9v3mxRtDnQYKTM0iAimO8zB7enky0AGUQv6gddFtPj0Cz4DwZS/SceMI7EUrkI6ilzSw80M9ymP26WeAxbtm0FdqN0s+oJkXfule9/c3v/XQYkspRkKzy0XbHINBEHhBKEERPR7GoOIFffatlDjdKuR12tetYLgYLlDFwR8Vit/iNudbYmu31wT7M//iSlNgsEPHVlP6spLQ8FpWf1rRYBOdUvBVNQyXVf3KoBTJw5Jg4RJcoc29hsc0+Q+8mWVv+2no328Zzu+dIm27MNMab72MA== 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=aY5b7UuVQNKFlWQJz0gs4UyLFG5J57Lk0llm3eZnrXI=; b=lXdcv8Pd+T/UmTNuku1DixxoTjuCUncOfvORbfZMI+/AmXEAgckaP0J2LZw6s+xfOEjb5of/Bc36hirkmNQwvGt3dPcY1AJ8W9jyjMQI+rXFzDZpqBlOU7srHpL+NwUG/aDJ6QsELlrZAN8N0HnaQ1u1h+af9RMAk5TD4d+pV1/XcbyEjxaOMlucjFHpTw/D084p8t+E4rZNBhJlBkMqGRpmWDtiOpkm7oy4IFXK2yA6cJu/7BqWkQEeLkQY74dJ6tXh/rz6v8AF9aQdQ8mw337koF37RZnU3Hau1gYFf7WPLU5r4D9YtmiPdmSjo47CEMKaAIwXEDPRQnrOoR3Kwg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aY5b7UuVQNKFlWQJz0gs4UyLFG5J57Lk0llm3eZnrXI=; b=e4YdWXK9SLrHxHu05PNARQDqX9ZWOGTxOb7G+GDyu6rRrX5LdbM2WRDXkEUUpJK6lKcft2huWexg64P1G0ZPDM+wDjjFLa7BKnaVxo/+i/QOUo3a2pJFKynfbBLuzuQ1LLtENLftsFlcA6Ssrheig3sHv6DEfF7nYvjilA0vPbM= Received: from BN7PR11MB2641.namprd11.prod.outlook.com (2603:10b6:406:b1::25) by BN7PR11MB2577.namprd11.prod.outlook.com (2603:10b6:406:b1::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.20; Fri, 5 Jun 2020 19:40:45 +0000 Received: from BN7PR11MB2641.namprd11.prod.outlook.com ([fe80::35bd:ecae:1e28:58f5]) by BN7PR11MB2641.namprd11.prod.outlook.com ([fe80::35bd:ecae:1e28:58f5%5]) with mapi id 15.20.3066.019; Fri, 5 Jun 2020 19:40:44 +0000 From: "Scott Fluhrer (sfluhrer)" To: "ipsec@ietf.org" Thread-Topic: Last minute change to draft-ietf-ipsecme-qr-ikev2 Thread-Index: AdY7b0YZDPRKeamGTBelnS42EluRIw== Date: Fri, 5 Jun 2020 19:40:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.76] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8d5ecb8f-2fd7-4d0a-a2a1-08d8098856cc x-ms-traffictypediagnostic: BN7PR11MB2577: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0425A67DEF x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: de8XTmOCZUlOzd0gQMsyAg8evcC1d5MU1ushWk2tBhOFb58+oE60w0clmuQ97uzPCuTPrLQDJHkA7I9H6j30NEV9D24gna1+5BdshyFVbX9YjeG3D7yDCebJ2ruDxrH87wd3GOEGkN9cn3JbbYFoRBw2/qEEgzj+mpDQ4LZA4+C92rxw0sWUXkM5p4BhnjpOUUjpoUFT8/bPBK5Id3AVhWff+LiOS/DD90UHEVFHF/2CwGx6HGif3TmAcurwS5BGIVOEsp66S25NouRFALSBkgukmvCbuilBWKMX2yLh6/o6ilkGTT0C0AvbEAUjt0PZ+QYFNUQqTwWfqyi/CEXj/w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2641.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(376002)(346002)(136003)(366004)(396003)(186003)(55016002)(9686003)(8936002)(6506007)(26005)(478600001)(33656002)(83380400001)(2906002)(5660300002)(52536014)(66946007)(71200400001)(6916009)(66446008)(86362001)(76116006)(66556008)(66476007)(316002)(7696005)(8676002)(64756008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: l541QW8MzeFB/jSAdC39Qh9J7uJntMzjpAk0G/6OGC2OigRSmZbFu/hqruWQK56BzDV0L3hTFBXf0/74vI13mymSt4vccF8etTW4duuwC+3bS9wmi19CF2DZ7OEqzAHbvO8aIYvcuXdJVtOO90Lzz0icOZ7/3eEvQ5a0Im0aO1i9IpdAWXk+slCmFw7u/n/tDCVNdxEbf/EAGt8blbIQkjq9R2b0rdqhJbi/Vx7PrI0qllYvtwrgUbDQ8E9EiHAeeSY0Poh55ecK+WLGVx6kIIa78QFrvhKRmW8ziIxYyCNy9wv6Ax2arGe/o/qgoMnMqtqqWRIEyL8dSikhlxkvlajRl9yZ+iYHi0m/s42k5vQbTsZuMob5AwuWY+OeM+utNG/ihkYbt2bK9/8eAsFF8hFLfjH2W7U0fUqsSpEMYpObE6MpnVx1ZQ7DeGCxbhAoa2K5EhKMOewbcpb8eAa1tjVi94U8QIEVDwBi5JJf3Dg= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN7PR11MB2641BAFC172E209AFCF219FDC1860BN7PR11MB2641namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8d5ecb8f-2fd7-4d0a-a2a1-08d8098856cc X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2020 19:40:44.7520 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: FDIzsAfQOm0FwR7/Qm154CDH14eb+E9b5s3d2lMmlbgoUTgruJ+ngnYKZcHBoHGiLtj/QP8EhRcGszfxvEOpag== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2577 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: [IPsec] Last minute change to draft-ietf-ipsecme-qr-ikev2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 19:40:50 -0000 --_000_BN7PR11MB2641BAFC172E209AFCF219FDC1860BN7PR11MB2641namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The draft "Mixing Preshared Keys in IKEv2 for Post-quantum Security" was wi= nding through the AUTH48 process, when at the last minute, I received an em= ail from a researcher who thought they found a problem with low entropy PPK= s (the preshared keys that the draft uses). While it turned out that what = the found really wasn't a problem, such low entropy PPKs are a problem in g= eneral. To address this, I suggested to the RFC editors that we modify the first pa= ragraph of the security considerations from: Original text: Quantum computers are able to perform Grover's algorithm [GROVER]; that effectively halves the size of a symmetric key. Because of this, the user SHOULD ensure that the post-quantum preshared key used has at least 256 bits of entropy, in order to provide 128 bits of post-quantum security. That provides security equivalent to Level 5 as defined in the NIST PQ Project Call For Proposals [NISTPQCFP]. Modified text: Quantum computers are able to perform Grover's algorithm [GROVER]; that effectively halves the size of a symmetric key. Because of this, the user SHOULD ensure that the post-quantum preshared key used has at least 256 bits of entropy, in order to provide 128 bits of post-quantum security. That provides security equivalent to Level 5 as defined in the NIST PQ Project Call For Proposals [NISTPQCFP]. An attacker who impersonates the server is able to validate guesses to the PPK. Because of this, low entropy PPK values MUST NOT be used. Additional text high-lighted. Because of the lateness of this change, Ben Kaduk (the area director) asked= me to check with the list to make sure everyone is OK with this addition. Comments? --_000_BN7PR11MB2641BAFC172E209AFCF219FDC1860BN7PR11MB2641namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The draft “Mixing Preshared Keys in IKEv2 for = Post-quantum Security” was winding through the AUTH48 process, when a= t the last minute, I received an email from a researcher who thought they f= ound a problem with low entropy PPKs (the preshared keys that the draft uses).  While it turned out that what the found r= eally wasn’t a problem, such low entropy PPKs are a problem in genera= l.

 

To address this, I suggested to the RFC editors that= we modify the first paragraph of the security considerations from:

 

Original text:

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   Quantum computers are able to perform = Grover's algorithm [GROVER];

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   that effectively halves the size of a = symmetric key.  Because of

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   this, the user SHOULD ensure that the = post-quantum preshared key used

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   has at least 256 bits of entropy, in o= rder to provide 128 bits of

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   post-quantum security.  That prov= ides security equivalent to Level 5

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   as defined in the NIST PQ Project Call= For Proposals [NISTPQCFP].

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5"> 

Modified text:

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   Quantum computers are able to perform = Grover's algorithm [GROVER];

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   that effectively halves the size of a = symmetric key.  Because of

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   this, the user SHOULD ensure that the = post-quantum preshared key used

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   has at least 256 bits of entropy, in o= rder to provide 128 bits of

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   post-quantum security.  That prov= ides security equivalent to Level 5

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   as defined in the NIST PQ Project Call= For Proposals [NISTPQCFP].

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   An attacker who impersonates the server is able to validate guesses to

<= b>   the PPK.  Because of this, low= entropy PPK values MUST NOT be used.

 

Additional text high-lighted.

 

Because of the lateness of this change, Ben Kaduk (t= he area director) asked me to check with the list to make sure everyone is = OK with this addition.

 

Comments?

--_000_BN7PR11MB2641BAFC172E209AFCF219FDC1860BN7PR11MB2641namp_-- From nobody Fri Jun 5 13:44:54 2020 Return-Path: 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 876D43A0D4E for ; Fri, 5 Jun 2020 13:44:50 -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 s9ZnL3HdyD2J for ; Fri, 5 Jun 2020 13:44:48 -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 AEB5B3A0D49 for ; Fri, 5 Jun 2020 13:44:48 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 49dvlb2XQbzMQ7; Fri, 5 Jun 2020 22:44:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1591389883; bh=jw9qMuZMa1Bm9rYF5i9pyiQiJp/c4AMrsUa8JnbmV58=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=T+sBqRISUEDkYMA4TSHQZrn/JeCA84QZ3QmACoH9cTUir2qF3+iemFvAvr/Osg5dP dsJoylznf/fBx+5jP4BCOmbGNBFJ+Qxhu0NmVm4SFSqly+ILaYYcsqK4eoXWDQqfhr QaGL+JWWrt+PwrBTkTMNWgOFhUOMS6gCDtIT6iaE= 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 Lwr1cWJ1savZ; Fri, 5 Jun 2020 22:44:42 +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; Fri, 5 Jun 2020 22:44:42 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 09F236020E29; Fri, 5 Jun 2020 16:44:40 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id F3C4766A99; Fri, 5 Jun 2020 16:44:40 -0400 (EDT) Date: Fri, 5 Jun 2020 16:44:40 -0400 (EDT) From: Paul Wouters To: "Scott Fluhrer (sfluhrer)" cc: "ipsec@ietf.org" In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [IPsec] Last minute change to draft-ietf-ipsecme-qr-ikev2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 20:44:51 -0000 On Fri, 5 Jun 2020, Scott Fluhrer (sfluhrer) wrote: > The draft “Mixing Preshared Keys in IKEv2 for Post-quantum Security” was winding through the AUTH48 process, when at the last > minute, I received an email from a researcher who thought they found a problem with low entropy PPKs (the preshared keys that the > draft uses).  While it turned out that what the found really wasn’t a problem, such low entropy PPKs are a problem in general. We had this discussion in the WG. >    An attacker who impersonates the server is able to validate guesses to >    the PPK.  Because of this, low entropy PPK values MUST NOT be used. My problem with the text is that the setion is about how the users are using the software/protocol. So a MUST NOT reads kind of weird, because users don't read RFCs. Implementors are the ones who can follow a MUST NOT, but the text makes no requirement of implementors. I've been here before with PSKs. I had added some code in our implementation to do some simple strength check on entropy and reject weak PSKs. But there was a discussion on how far one should go and of course examples of easy stupid tricks to defeat simplistic entropy checks. In the end, it got removed again. I would be happy for the draft to recommend something like a minimum length of 32 bytes. I can implement that. We know some people will use 32 A's or 0's, but where would you draw the line. Alternatively, the text could suggest some kind of exponential backoff scheme based on wrong PPK values that would dramatically slow down the efforts of an attacker. Again, that would be something we can implement. I am fine with the first sentence being included. The second one could read something like "Because of this, low entropy PPK values MAY be rejected and implementations MAY warn about their use". This then leaves it up to implementors as to whether they will add some entropy checking code or not. Paul From nobody Sun Jun 7 02:00:14 2020 Return-Path: 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 D20953A0C63; Sun, 7 Jun 2020 02:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 gQ6dVq36UmmZ; Sun, 7 Jun 2020 02:00:09 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [62.96.220.36]) (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 619313A0C61; Sun, 7 Jun 2020 02:00:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id DDBA120561; Sun, 7 Jun 2020 11:00:01 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXVHm9KiaH6R; Sun, 7 Jun 2020 11:00:01 +0200 (CEST) Received: from mail-essen-01.secunet.de (mail-essen-01.secunet.de [10.53.40.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by a.mx.secunet.com (Postfix) with ESMTPS id 61FCA20523; Sun, 7 Jun 2020 11:00:01 +0200 (CEST) Received: from mbx-essen-01.secunet.de (10.53.40.197) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.487.0; Sun, 7 Jun 2020 11:00:00 +0200 Received: from gauss2.secunet.de (10.182.7.193) by mbx-essen-01.secunet.de (10.53.40.197) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Sun, 7 Jun 2020 11:00:00 +0200 Received: by gauss2.secunet.de (Postfix, from userid 1000) id 5F57B31801AE; Sun, 7 Jun 2020 11:00:00 +0200 (CEST) Date: Sun, 7 Jun 2020 11:00:00 +0200 From: Steffen Klassert To: Christian Hopps CC: Tero Kivinen , IPsecME WG , , Message-ID: <20200607090000.GJ13121@gauss3.secunet.de> References: <13344.1583165241@localhost> <24278.24659.921904.72666@fireball.acr.fi> <7322AB98-43B1-43E2-BCC6-7EC685869A8B@chopps.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <7322AB98-43B1-43E2-BCC6-7EC685869A8B@chopps.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-ClientProxiedBy: cas-essen-01.secunet.de (10.53.40.201) To mbx-essen-01.secunet.de (10.53.40.197) X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 Archived-At: Subject: Re: [IPsec] Early Allocation Request for IPTFS_PROTOCOL IP protocol number. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 09:00:12 -0000 On Tue, Jun 02, 2020 at 11:56:48AM -0400, Christian Hopps wrote: > > On Jun 2, 2020, at 10:21 AM, Tero Kivinen wrote: > > Christian Hopps writes: > > > I would assume those questions are going to be asked from chairs or > > area directors during the process anyways, so we need to have good > > answers to them ready (and for me it would be quite hard to explain > > why we cannot use warpped ESP, or dummy packet trick as I think we can > > do those and we do not need IP protocol number). > > > > Note, that if the answer is going to be that we want to use this also > > when we are not using IPsec, then this is even bigger can of worms, as > > that would most likely mean that this work does not belong to the > > IPsecME working group, but should be part of completely different > > area... > > As I mentioned above, people have already expressed interest in possibly using the IPTFS framing outside of IPsec for some of its positive non-IPsec properties. This doesn't mean we have to boil the ocean and standardize the framing outside of IPsec, it just means we should be considerate about the possible re-use while we do our work. I'm one of those who was interested in a different usecase for the IPTFS payload. My plan was to present about that at the Linux IPsec workshop this year. Unfortunately, this workshop was canceled because of COVID-19 outbreak, so I never got feedback about the idea. Below is the Abstract of this presentation that sketches the idea (just for the case somebody finds it usefull). - An alternative usecase for IPTFS_PROTOCOL payload type tunnels. This alterative usecase tries to solve the 'small packet' tunneling problem. Sending small packets over a tunnel usually creates quite a lot of overhead, as each packet needs to get it's own tunnel header etc. For IPsec, the situation is even worse as a cpu intensive crypto operation has to be applied for each of these small packets. With the IPTFS_PROTOCOL payload type, we could group small packets and send them into one big packet over the tunnel. This can avoid tunneling overhead because we need only one tunnel header for multiple packets. Also this method would be very data and instruction cache effective because multiple packets are processed together. The good thing is that the Linux forwarding path can already provide packets chains (GRO), so we would just need to take these packets chains and put them into big tunnel packets with IPTFS_PROTOCOL payload type. As a side effect, having IPTFS_PROTOCOL as a general purpose tunnel payload, it might be easier to argue for a new IP protocol number allocation. Steffen From nobody Sun Jun 7 03:24:28 2020 Return-Path: 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 4F7553A0CF5 for ; Sun, 7 Jun 2020 03:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 36IKLlyHZwkJ for ; Sun, 7 Jun 2020 03:24:23 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 F031B3A0CF2 for ; Sun, 7 Jun 2020 03:24:22 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id y11so15241683ljm.9 for ; Sun, 07 Jun 2020 03:24:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=2+9dZ5Xoivk3qAACm4gc9y5vk5q2EZll4DGWLajmiR4=; b=UtBx+hzMfG0MXKegxKodNRmEEsg9SR5PZHxJ7sSTKWjJAzRXC7ZAf10LwDSmvz06SO ft7WYP4oxfYMXzZS3LwtQ3LNHyufAmQIfXa9z+LRlSwEZk7lqJweh9y2VcTH+g38qKJX x0iyZz1iEDHeeB7QYDI2BIN6ZrgAwFPwprir5bayDeWG4jI5526JWVC1nJmGPvl1YgjD Ze0dpky++4CSMFTEMjm/eVp2/8iuvQAX1xbJWHB7Ao6LannJCTgD6oliGLO374lwVR5H MphQJJOpD/4cqr0uid9fQMKTHRTwoNF5LkFGxufgY6Zi3TRw/MKIcnpaLKf7NXu9xFCT ifrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=2+9dZ5Xoivk3qAACm4gc9y5vk5q2EZll4DGWLajmiR4=; b=KNv3Fm3mlQjvFRqRSNY2LMUM5ZxX6eLxNgmWpuoaXV/S3sj6+ojR5d/EbpGZzQ2n9m XjA1j28mrQVJxn/1uEt7aU5V9qGFmswgXXKZZ1mSlZPpE/Fj8PfUszydCPCK8Ys0JRPU zwFinkvJSJSJbX1QhKNSkmxDSAvkG3N88fpqjk/cplqOYNadAoxJDLhdDkTrUVO7V74L mLYOf2rk7pqSt67VoWzO/vyw+dcZYwdYMh4/5FnJqUEZ3dAaWPQrmWzKNBULa6mfhsb6 blaa5Jd94qmAgm9UB0Po8iI9GtglLaNj3Bsg58foFSlcPD75QAbw+tGBK4CaPHrPitYU 10NQ== X-Gm-Message-State: AOAM533NV7giFI9DnQblelHm/x+7JzU5WkWHB5nal06JPBG7WS2oex0R iIBubhZ3Tutcgx3MafeIMdPfwLvx X-Google-Smtp-Source: ABdhPJzljSgZTfryf65rVl3X09RIKY9uRSijIg/Z42J1RGKuNl4Y3gjMtUxyaJjisRfcCcw8UhfhSQ== X-Received: by 2002:a2e:9c4b:: with SMTP id t11mr8133199ljj.412.1591525460814; Sun, 07 Jun 2020 03:24:20 -0700 (PDT) Received: from chichi (95-27-147-103.broadband.corbina.ru. [95.27.147.103]) by smtp.gmail.com with ESMTPSA id m15sm3252556lfk.65.2020.06.07.03.24.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 Jun 2020 03:24:20 -0700 (PDT) From: "Valery Smyslov" To: "'Paul Wouters'" , "'Scott Fluhrer \(sfluhrer\)'" Cc: References: In-Reply-To: Date: Sun, 7 Jun 2020 13:24:19 +0300 Message-ID: <001701d63cb5$ce6e2380$6b4a6a80$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ3Vq54pN5tf5sr+ANZG5BOdYrkiwKdr4tSp3XOhVA= Content-Language: ru Archived-At: Subject: Re: [IPsec] Last minute change to draft-ietf-ipsecme-qr-ikev2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 10:24:25 -0000 Hi Paul, > On Fri, 5 Jun 2020, Scott Fluhrer (sfluhrer) wrote: >=20 > > The draft =E2=80=9CMixing Preshared Keys in IKEv2 for Post-quantum = Security=E2=80=9D was > winding through the AUTH48 process, when at the last > > minute, I received an email from a researcher who thought they found = a > problem with low entropy PPKs (the preshared keys that the > > draft uses). While it turned out that what the found really = wasn=E2=80=99t a > problem, such low entropy PPKs are a problem in general. >=20 > We had this discussion in the WG. >=20 > > An attacker who impersonates the server is able to validate = guesses to > > the PPK. Because of this, low entropy PPK values MUST NOT be = used. >=20 > My problem with the text is that the setion is about how the users are > using the software/protocol. So a MUST NOT reads kind of weird, = because > users don't read RFCs. Implementors are the ones who can follow a MUST > NOT, but the text makes no requirement of implementors. I read this text as a caveat for implementers to not use=20 keys which cannot provide enough entropy in any case (e.g. passwords). With this reading it's a text for implementers, not for users. Regards, Valery. > I've been here before with PSKs. I had added some code in our > implementation to do some simple strength check on entropy and > reject weak PSKs. But there was a discussion on how far one should > go and of course examples of easy stupid tricks to defeat simplistic > entropy checks. In the end, it got removed again. >=20 > I would be happy for the draft to recommend something like a minimum > length of 32 bytes. I can implement that. We know some people will > use 32 A's or 0's, but where would you draw the line. >=20 > Alternatively, the text could suggest some kind of exponential backoff > scheme based on wrong PPK values that would dramatically slow down the > efforts of an attacker. Again, that would be something we can = implement. >=20 > I am fine with the first sentence being included. The second one could > read something like "Because of this, low entropy PPK values MAY be > rejected and implementations MAY warn about their use". This then = leaves > it up to implementors as to whether they will add some entropy = checking > code or not. >=20 > Paul >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Sun Jun 7 07:49:04 2020 Return-Path: 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 3A75C3A08C7 for ; Sun, 7 Jun 2020 07:49:02 -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 tvYxKPuurNSC for ; Sun, 7 Jun 2020 07:49:00 -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 E99683A08BE for ; Sun, 7 Jun 2020 07:48:59 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 49fzm828c9zMWw; Sun, 7 Jun 2020 16:48:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1591541336; bh=bQaGKrBLUaaxoq0i0Xg6ObwU7CNcUD7Kw/MVNY3GGKU=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=dYhr+gNa0s/Ck6tdahSZcKafcvDmR0LQqBig1yoKnwnUWEt6mWG7wh+N1FC/13607 Rlo9ytkLFZwCPo/Oh/rmysOpg4d17HfI3f8nJRfxczFk08CVTkqh0tPxEqXv/p0sGM 09uDydxRqJ0YkH02xcrdXrhzaut0pFgL9SQDMhNQ= 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 6-7h0bVy4Ypa; Sun, 7 Jun 2020 16:48:55 +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; Sun, 7 Jun 2020 16:48:55 +0200 (CEST) Received: from [193.111.228.74] (unknown [193.111.228.74]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 1018F6020D44; Sun, 7 Jun 2020 10:48:54 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Paul Wouters Mime-Version: 1.0 (1.0) Date: Sun, 7 Jun 2020 10:48:37 -0400 Message-Id: References: <001701d63cb5$ce6e2380$6b4a6a80$@gmail.com> Cc: "Scott Fluhrer (sfluhrer)" , ipsec@ietf.org In-Reply-To: <001701d63cb5$ce6e2380$6b4a6a80$@gmail.com> To: Valery Smyslov X-Mailer: iPhone Mail (17F75) Archived-At: Subject: Re: [IPsec] Last minute change to draft-ietf-ipsecme-qr-ikev2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 14:49:02 -0000 > On Jun 7, 2020, at 06:24, Valery Smyslov wrote: >=20 > =EF=BB=BFHi Paul, >=20 > I read this text as a caveat for implementers to not use=20 > keys which cannot provide enough entropy in any case (e.g. passwords). > With this reading it's a text for implementers, not for users. If you read it that way, then I strongly recommend we put implementeren advi= se there. The last thing we want is implemented deciding differently on the m= inimum entropy enforced. Because if I say 32 bytes length and you say 16, in= terop with me breaks until I lower to 16, and a few years down the line we a= ll set the minimum length at 1 for interoperability. If it=E2=80=99s advise to the user, we can hand wave. If it is requirement f= or the implementer, we need very specific directions. Paul= From nobody Sun Jun 7 18:43:47 2020 Return-Path: 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 51E793A08E4 for ; Sun, 7 Jun 2020 18:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 7i1R3kBxDSxQ for ; Sun, 7 Jun 2020 18:43:44 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95D3D3A08E1 for ; Sun, 7 Jun 2020 18:43:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id BA3C6389F3; Sun, 7 Jun 2020 21:41:15 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cHo1YFkkNjum; Sun, 7 Jun 2020 21:41:15 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 258EC389E6; Sun, 7 Jun 2020 21:41:15 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0112C213; Sun, 7 Jun 2020 21:43:41 -0400 (EDT) From: Michael Richardson To: Steffen Klassert , IPsecME WG In-Reply-To: <20200607090000.GJ13121@gauss3.secunet.de> References: <13344.1583165241@localhost> <24278.24659.921904.72666@fireball.acr.fi> <7322AB98-43B1-43E2-BCC6-7EC685869A8B@chopps.org> <20200607090000.GJ13121@gauss3.secunet.de> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] Early Allocation Request for IPTFS_PROTOCOL IP protocol number. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 01:43:46 -0000 --=-=-= Content-Type: text/plain Steffen Klassert wrote: > This alterative usecase tries to solve the 'small packet' tunneling > problem. Sending small packets over a tunnel usually creates quite a > lot of overhead, as each packet needs to get it's own tunnel header > etc. For IPsec, the situation is even worse as a cpu intensive crypto > operation has to be applied for each of these small packets. With the > IPTFS_PROTOCOL payload type, we could group small packets and send them > into one big packet over the tunnel. This can avoid tunneling overhead > because we need only one tunnel header for multiple packets. Also this > method would be very data and instruction cache effective because > multiple packets are processed together. The good thing is that the > Linux forwarding path can already provide packets chains (GRO), so we > would just need to take these packets chains and put them into big > tunnel packets with IPTFS_PROTOCOL payload type. As a side effect, > having IPTFS_PROTOCOL as a general purpose tunnel payload, it might be > easier to argue for a new IP protocol number allocation. Does your use case include situations where this is not an IPsec tunnel? Tero's point was that when we are putting things into ESP, that we effectively get an IPsec-specific protocol number space, and so maybe we don't need a first-class protocol number. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl7dl80ACgkQgItw+93Q 3WWGagf+MHz6K2g5Qmhuu8B//ZVYGaDEjTrCNDp2NaJ03mHP0R5Maqdn8U0Vzmuv 7rPTnWenYUt57Utsrgo7DqOquoJ1W+zDfPfTuBCXZk/B4hIr5/PG56SMavQVHGur lS8mrdOvP5Gs2R/bSXwxeZxVCINkl2fbHKL8u/HhKGoy9CnCfgxbs0ArDdwCC1E0 MQ12r+N3BxZCbGQ/f8mHqSzPPBl4llrUitanF81XoFnKNsGZX7DSzOlSS35P3ITE 8VKjzMxI3t45c09PkbBHCx42erUjA7QbBInvYfjZGxw611plWILcp9KVyK94cDvB JO5RQGuLfuHmQlqc0fjPQ7rYwrx7KA== =oFdL -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 8 02:47:13 2020 Return-Path: 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 6C9BE3A0852 for ; Mon, 8 Jun 2020 02:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 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, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 tuYRWBl-5RJL for ; Mon, 8 Jun 2020 02:47:04 -0700 (PDT) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 E9C213A0839 for ; Mon, 8 Jun 2020 02:47:03 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id e125so9811828lfd.1 for ; Mon, 08 Jun 2020 02:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=09Vjynww55Qo+KVegkFogLCVcUAWv89rJAVVMyTHNpY=; b=eTLExUlBWLMDaq3jSR8ZL/zYUy+Ec83k9ugqxju43q70UT0hv/rTZJA84SuEJ1+Li/ 9VHMxuVvokJ46c6UYkogUY+XP5wrZ1r3F++1bwYCIqcv1AOC5KoM7RH6ZXnOO/tcP1Su 4sHUL+3LS1Z1cFhESd3J2+5ysQMbbtGH+YNaiQvDmgYy7F2PJNT63unMANB5TyLP+ePY tFJQOpYEbM3S6vzDOOMxcUmGX27ve0tZPada3i505mlIS36D+q8dnYty9b9xTQiAZy61 EOiElde6olKwejaSXubLL/3dvOSLdb+Jt9L/QHVZtQJyq/Ug0xFYmtB8fH6mTSTvc7qE HJWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=09Vjynww55Qo+KVegkFogLCVcUAWv89rJAVVMyTHNpY=; b=rU+DL4vPLUzfFqq/TqmPpqiPDJwVcnTOh4QjZgydKxycNekQsSIRko9UyvgxkxuIBY jk8vwvD+Szgu0YDqC1GPvOdsb0SjyNiWJ6mshFqbuY9hpIZSucTCwphyoTix0xFmu3Ht VqQeoTOU1WztSi4D4KO+aMebFSZJV30K/AM3CNwIM9p+FMn5HKh/ZXAVNALWYnrPonbQ Jy6Wqmm6ByyWJus6Zsk7sre/l1J/TIO2cFyPMoXHkDcpdh1QaxD2q4SJF6fP8abHwWrt sOrSDzXi6lrdU5345i1bwMBJEjiPzgHen49wKnRyvZ6ibcUeh8B84v7NG/KtjRrOqGms uSPg== X-Gm-Message-State: AOAM530CCnClDW4wlelbCvNEW7VgS6SfDnsc0Bb22zpwGGfI6/ZAvFvx pi21nSJ54+nuX19DMekFyV+BkGSf X-Google-Smtp-Source: ABdhPJxS6s/zKyFhpOQEUZJkv2oJFOZne1/naNX4oUpnrhNiDK711vIvV42IMQofk8d07Mc0rKWAgQ== X-Received: by 2002:ac2:4114:: with SMTP id b20mr12107454lfi.34.1591609621418; Mon, 08 Jun 2020 02:47:01 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id r28sm1320045lfn.31.2020.06.08.02.47.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jun 2020 02:47:00 -0700 (PDT) From: "Valery Smyslov" To: "'Paul Wouters'" Cc: "'Scott Fluhrer \(sfluhrer\)'" , References: <001701d63cb5$ce6e2380$6b4a6a80$@gmail.com> In-Reply-To: Date: Mon, 8 Jun 2020 12:47:00 +0300 Message-ID: <018001d63d79$c1e49ad0$45add070$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJmsZScpsfivbl21m8aqyLUT01XFQF0Og+lp6HqgKA= Content-Language: ru Archived-At: Subject: Re: [IPsec] Last minute change to draft-ietf-ipsecme-qr-ikev2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 09:47:12 -0000 > > =EF=BB=BFHi Paul, > > > > I read this text as a caveat for implementers to not use > > keys which cannot provide enough entropy in any case (e.g. = passwords). > > With this reading it's a text for implementers, not for users. >=20 > If you read it that way, then I strongly recommend we put = implementeren advise there. The last thing we want > is implemented deciding differently on the minimum entropy enforced. = Because if I say 32 bytes length and > you say 16, interop with me breaks until I lower to 16, and a few = years down the line we all set the minimum > length at 1 for interoperability. >=20 > If it=E2=80=99s advise to the user, we can hand wave. If it is = requirement for the implementer, we need very specific > directions. I'd rather to avoid using concrete numbers here - they depend on a = situation and tend to change over time. I think that our message to implementers is: don't use this extension = with secrets that are easily guessable (PINs, passwords, SMS-codes etc.), because malicious server = can guess them. It doesn't mean that we limit the minimal size of the key to some = pre-hardcoded value (although we have already advised a couple of sentences above that 256 = bit keys SHOULD be used).=20 It only means that implementers must not use this extension if their = implementations generate PPKs by,=20 say, deriving them from passwords. Anyway, can you come up with a text that that you'll be fine with and = that will address this concern? Regards, Valery. > Paul From nobody Mon Jun 8 04:05:11 2020 Return-Path: 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 343BB3A095E for ; Mon, 8 Jun 2020 04:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 NnqdFLI86Fap for ; Mon, 8 Jun 2020 04:05:07 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [62.96.220.36]) (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 6E36E3A0789 for ; Mon, 8 Jun 2020 04:05:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 5FD7A205A4; Mon, 8 Jun 2020 13:05:03 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QofaKbcI2aK; Mon, 8 Jun 2020 13:05:02 +0200 (CEST) Received: from mail-essen-01.secunet.de (mail-essen-01.secunet.de [10.53.40.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by a.mx.secunet.com (Postfix) with ESMTPS id E2802201E2; Mon, 8 Jun 2020 13:05:02 +0200 (CEST) Received: from mbx-essen-01.secunet.de (10.53.40.197) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.487.0; Mon, 8 Jun 2020 13:05:02 +0200 Received: from gauss2.secunet.de (10.182.7.193) by mbx-essen-01.secunet.de (10.53.40.197) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Mon, 8 Jun 2020 13:05:02 +0200 Received: by gauss2.secunet.de (Postfix, from userid 1000) id 36D7B3180167; Mon, 8 Jun 2020 13:05:02 +0200 (CEST) Date: Mon, 8 Jun 2020 13:05:02 +0200 From: Steffen Klassert To: Michael Richardson CC: IPsecME WG Message-ID: <20200608110502.GH19286@gauss3.secunet.de> References: <13344.1583165241@localhost> <24278.24659.921904.72666@fireball.acr.fi> <7322AB98-43B1-43E2-BCC6-7EC685869A8B@chopps.org> <20200607090000.GJ13121@gauss3.secunet.de> <14166.1591580621@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <14166.1591580621@localhost> User-Agent: Mutt/1.9.4 (2018-02-28) X-ClientProxiedBy: cas-essen-02.secunet.de (10.53.40.202) To mbx-essen-01.secunet.de (10.53.40.197) X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 Archived-At: Subject: Re: [IPsec] Early Allocation Request for IPTFS_PROTOCOL IP protocol number. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 11:05:09 -0000 On Sun, Jun 07, 2020 at 09:43:41PM -0400, Michael Richardson wrote: > > Steffen Klassert wrote: > > This alterative usecase tries to solve the 'small packet' tunneling > > problem. Sending small packets over a tunnel usually creates quite a > > lot of overhead, as each packet needs to get it's own tunnel header > > etc. For IPsec, the situation is even worse as a cpu intensive crypto > > operation has to be applied for each of these small packets. With the > > IPTFS_PROTOCOL payload type, we could group small packets and send them > > into one big packet over the tunnel. This can avoid tunneling overhead > > because we need only one tunnel header for multiple packets. Also this > > method would be very data and instruction cache effective because > > multiple packets are processed together. The good thing is that the > > Linux forwarding path can already provide packets chains (GRO), so we > > would just need to take these packets chains and put them into big > > tunnel packets with IPTFS_PROTOCOL payload type. As a side effect, > > having IPTFS_PROTOCOL as a general purpose tunnel payload, it might be > > easier to argue for a new IP protocol number allocation. > > Does your use case include situations where this is not an IPsec tunnel? My main usecase would be an IPsec tunnel, but the same can work for other tunnel types too. If we have an IP protocol number, it is just easy to use it outside of IPsec world, but I don't have a strong opinion on that. Steffen From nobody Mon Jun 8 08:07:27 2020 Return-Path: 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 42E9A3A0C53 for ; Mon, 8 Jun 2020 08:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=J0B9bACK; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=kmv5+slN 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 0-vddk2sNY6i for ; Mon, 8 Jun 2020 08:07:23 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 537BD3A0DD5 for ; Mon, 8 Jun 2020 08:06:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22924; q=dns/txt; s=iport; t=1591628792; x=1592838392; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=pwfEza2PCb+xZr5N0GXC6wOudfEWXsI8Mb2OfItrM5M=; b=J0B9bACK8x/hcUdDQJy0pBqaZOkRQ4NWUBWwRHYpv3wUuJMn1e8KL6hv 92S2AGhJm98FJzPoI0W2xEaGQxKjNi54nUwq1RuTo6YqDrVYDN5qgPSNl qgfJwulK0SDXMIR51QNgirHjFG1ClpMzMLSbYA7Xn9Hu6ii3W3yK8quRb 0=; IronPort-PHdr: =?us-ascii?q?9a23=3AuDrnExTBEuued0BFvWtbsIrSQdpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQBN+J6v9YhazRqa+zEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutZlDOrDu19zFBUh?= =?us-ascii?q?n6PBB+c+LyHIOahs+r1ue0rpvUZQgAhDe0bb5oahusqgCEvcgNiowkIaE0mR?= =?us-ascii?q?Y=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABCgCuU95e/5hdJa1mHgEBCxIMQIJ?= =?us-ascii?q?tL1IHb1gvLAqHYAONP5hSgUKBEANVCwEBAQwBAS0CBAEBhEQCgjQCJDgTAgM?= =?us-ascii?q?BAQsBAQUBAQECAQYEbYVbAQuFcgEBAQEDEgsQEwEBLAwPAgEIEQQBARkIDjI?= =?us-ascii?q?dCAEBBBMIDQQJgwWBfk0DLgGlAAKBOYhhdIE0gwEBAQWFKxiCDgmBOIJkhyG?= =?us-ascii?q?CTBqBQT+BVIJNPoQZARIBCRpNgniCLY5diV8linGQOAqCWY5PileeSpEDmgu?= =?us-ascii?q?EBQIEAgQFAg4BAQWBaiJmcHAVO4JpUBcCDZBAg3KKVnQ3AgYIAQEDCXyMUiQ?= =?us-ascii?q?JgQYBgQ8BAQ?= X-IronPort-AV: E=Sophos;i="5.73,487,1583193600"; d="scan'208,217";a="492467934" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Jun 2020 15:06:27 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 058F6RKp001064 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 8 Jun 2020 15:06:27 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 8 Jun 2020 10:06:26 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 8 Jun 2020 10:06:26 -0500 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 8 Jun 2020 10:06:26 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bMRNwmM7Eqf0PDV/dmivb8PrcxacDNJZmgsNbIsiCiJ2KdwED9nHynTdGVrkDRvUogLLKsfIwQKOk2BDhhhbilTQUyIy63evbe5uFvHc/29PrL38fGjOfhGOySoLfbHmlOwR1dwjXwujOj0Q4VkeKswMtXtQAIqvpoHSTvjb3+CsIl7F5Ssm3dB3aCmmOb5EldOLFC8s1coSXLCHJ7MAf984iifHbMTeneId3WNvTGU42ZAuNr28S5C1hhZeqzrPv1Xm2Hew0eVqu813xgIJ9FwZSegq4FMHv7m5HOHsOxTTSXmP3cxDmn7piRfyPa28gVlepIssCxzNavqfpqBDgA== 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=zAjP30+F08Pi8+VXkr70cprNtJS9LCRfKaUJ3iNtxjI=; b=VBKoYfPL5M/r1zH6LM1B57pYnQN8BzsbZmq/3pU9Byi/P7PJm8PctCE1ZV05AJUaLbtFRUS7Z7WU8pAQ0g7Bsq+enWLFkvQ0ndsBx9OZNfLppNeLgclUJNaRanYiBTDS8lLFSacwKcs0RoFHnHT6PVVrn7HB3hr3WwwksHvsCBom189eOpCf+zokPHno1C94Z/B3VTTADj1VWZQ+FLXuMtUylFAG/ogDhJC833N6pz6+PVbu2ou7gmUxCzZ0Dt4vAhH9usBVJlNcR71/lGMjXiQTdySS9QWDVsCUbRrZOuj6Z4M+LnPHC7eU27FH1bl6cpQOiNPM6RKbmZONhgiShw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zAjP30+F08Pi8+VXkr70cprNtJS9LCRfKaUJ3iNtxjI=; b=kmv5+slNMKil2y8VtkNOtq/6dEv6dQV+rZ2WQGbDzylTBYYaW8h/isYdb2AuGChIpyZ8AgKDqkKlR7JMhxXAm4DeD0cHd98gvYtzfoqOjhlI34zFCtdIPaFt1FK9uioI7ohFaZSaSLA/EleRFrmjXaImCuW2ZdUYRGnHbjWxO8k= Received: from BN7PR11MB2641.namprd11.prod.outlook.com (2603:10b6:406:b1::25) by BN7PR11MB2627.namprd11.prod.outlook.com (2603:10b6:406:ae::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Mon, 8 Jun 2020 15:06:25 +0000 Received: from BN7PR11MB2641.namprd11.prod.outlook.com ([fe80::35bd:ecae:1e28:58f5]) by BN7PR11MB2641.namprd11.prod.outlook.com ([fe80::35bd:ecae:1e28:58f5%5]) with mapi id 15.20.3066.023; Mon, 8 Jun 2020 15:06:25 +0000 From: "Scott Fluhrer (sfluhrer)" To: "ipsec@ietf.org" Thread-Topic: Last minute change to draft-ietf-ipsecme-qr-ikev2 Thread-Index: AdY7b0YZDPRKeamGTBelnS42EluRIwCIhypQ Date: Mon, 8 Jun 2020 15:06:24 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.76] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 74c0cf34-bb1b-4c1c-da1c-08d80bbd833e x-ms-traffictypediagnostic: BN7PR11MB2627: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 042857DBB5 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: EEpiZA4zktltm9Aq/UjUa8dIPLmIigmPTvJKEeulxwFaAaxWWRPZj5H8xcVZ0BPtHSCuCUvqCfVzH8qVYDr6lAjkUeh04xpTjabdcPs+k7ncewTYmupZKJ3/OzqaXYccvbP+fv2OraejtuAj7aH+/6CuOzpOfJmovw+RiqFg7EHUMSqoBTKockem9on1X6VDdiFQG2ePvpUZlxmBW9fU21DtwTQ/lnBYP/D0IE2vMMNHXb6EtdvxQE4hT/u4QW2tgIwQUJwAJxwIi/LiyvUja+RazuQS5QyxnLGXKaxyIqFtKCGL/whUQq3O1YUoxdmgmmzZSRjiY/BBWG5fwTV4wA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2641.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(346002)(366004)(376002)(396003)(136003)(33656002)(83380400001)(66556008)(55016002)(64756008)(7696005)(2906002)(53546011)(26005)(66476007)(66946007)(66446008)(9686003)(76116006)(6506007)(71200400001)(478600001)(186003)(86362001)(52536014)(5660300002)(8936002)(8676002)(6916009)(316002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 3cSx8Z96RqDeEgf7eulrM8SQPE73jUj5VLiHgNHYnNrC/TyB+yOQsyAs4XY0KoZXxSkCMpCcCnNDwfrmFov5RyH6ozXSR/I6I01qYqi9E3aC1ZF3eSKy/gNrwWjjbBfiGzqsVRNP02jFU+NfWZlQs+clNFK7TVe0qmBPpdGHhAly+YchPUh9bIbio89tuSaGSpBq27456SMn4E3CQd43KaUnxyc/7eE9wxBOaaiB90ocL17n+Q96hva6Q9Dzqk2laQDUlKmGc61whiPJSTqgH5Hs/x5P83ULquKpXUm7B6lOXlrH2ZK/f8PmyaiFLVnU7uNcVsDLC61adMq2vuQnmeWByQagquZscNwqhcgISHRd9B8A+fim98CYIGeP+SxlPuRFpwllANQaZgE2sbHw3jJBojdvNUpwXl4JSitllIivOaixUS7yln5OMqdztCRYcfEENltOq6UlMznYO9+KufuhkXsHwIoEDnRliP2DQ60= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN7PR11MB2641A192BD1268A76C880B63C1850BN7PR11MB2641namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 74c0cf34-bb1b-4c1c-da1c-08d80bbd833e X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2020 15:06:25.0374 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TYV+rbqDLPoxExE1HU/I6/F86FkoyYeZv2Ni1EMlWyiwZ0PczWyDwNQmYfKsQstt0YNBz9upVbSJ0hoOC42fIg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2627 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [IPsec] Last minute change to draft-ietf-ipsecme-qr-ikev2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 15:07:25 -0000 --_000_BN7PR11MB2641A192BD1268A76C880B63C1850BN7PR11MB2641namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tero had this comment (which didn't make it onto this mailing list): Btw, there is similar text in RFC7296 (base IKEv2) saying following: When using pre-shared keys, a critical consideration is how to assure the randomness of these secrets. The strongest practice is to ensure that any pre-shared key contain as much randomness as the strongest key being negotiated. Deriving a shared secret from a password, name, or other low-entropy source is not secure. These sources are subject to dictionary and social-engineering attacks, among others. so one option would also point to IKEv2 RFC and say that same restrictions = for not using low-entropy key that apply for pre-shared keys there applies = also PPK. That comment strikes me as having a good point; the pre-shared keys in IKE = are subject to exactly the same dictionary attack that a PPK would have, an= d so the same advice would apply to both. On the other hand, asking the re= ader to dig through a 142 page document for the relevant advice, or even sc= an through 3 pages of the security considerations would appear to be less f= riendly than we could be; in addition, advice for PPKs also need to conside= r Quantum Computers (which were not a consideration with IKE pre-shared key= s). How about this text (which integrates suggestions both from the security co= nsiderations of both RFC7296 and the PPK text, while trying to not sound li= ke Frankentext [1]. A critical consideration is how to assure the randomness of this post-quantum preshared key. Quantum computers are able to perform Grover's algorithm [GROVER]; that effectively halves the size of a symmetric key. In addition, an adversary, even with a conventional computer, can perform a dictionary search over plausible post-quantum preshared key values. The strongest practice is to ensure that any post-quantum preshared key contains at least 256 bits of entropy, this will provide 128 bits of post-quantum security, while providing security against conventional dictionary attacks. That provides security equivalent to Level 5 as defined in the NIST PQ Project Call For Proposals [NISTPQCFP]. Deriving a postquantum preshared key from a password, name, or other low-entropy source is not secure because of these known attacks. The highlighted sections is text that is new to the draft; this would repla= ce the first paragraph of the Security Considerations section. And, I would agree with Valery; I also would prefer to avoid putting number= s that sound concrete; especially on something that is hard to measure (and= "amount of entropy" is notoriously hard to measure - you can measure lengt= h, but that doesn't actually mean "guessability", which is what we're tryin= g to get at). [1]: For those readers who might not be familiar with English Literation or= pop culture, there is a classic English novel "Frankenstein", when a scien= tist (Dr Frankenstein) patches together parts from several corpses, and bri= ngs it to life (of course, it didn't go well); in later references to this = original novel, the stitching of the several parts is obvious. The allusio= n "Frankentext" suggests parts of several works being clumsily stitched tog= ether. It is typically good advice to avoid cultural references when talki= ng on an international mailing list; I just couldn't help myself this time.= .. From: Scott Fluhrer (sfluhrer) Sent: Friday, June 05, 2020 3:41 PM To: ipsec@ietf.org Subject: Last minute change to draft-ietf-ipsecme-qr-ikev2 The draft "Mixing Preshared Keys in IKEv2 for Post-quantum Security" was wi= nding through the AUTH48 process, when at the last minute, I received an em= ail from a researcher who thought they found a problem with low entropy PPK= s (the preshared keys that the draft uses). While it turned out that what = the found really wasn't a problem, such low entropy PPKs are a problem in g= eneral. To address this, I suggested to the RFC editors that we modify the first pa= ragraph of the security considerations from: Original text: Quantum computers are able to perform Grover's algorithm [GROVER]; that effectively halves the size of a symmetric key. Because of this, the user SHOULD ensure that the post-quantum preshared key used has at least 256 bits of entropy, in order to provide 128 bits of post-quantum security. That provides security equivalent to Level 5 as defined in the NIST PQ Project Call For Proposals [NISTPQCFP]. Modified text: Quantum computers are able to perform Grover's algorithm [GROVER]; that effectively halves the size of a symmetric key. Because of this, the user SHOULD ensure that the post-quantum preshared key used has at least 256 bits of entropy, in order to provide 128 bits of post-quantum security. That provides security equivalent to Level 5 as defined in the NIST PQ Project Call For Proposals [NISTPQCFP]. An attacker who impersonates the server is able to validate guesses to the PPK. Because of this, low entropy PPK values MUST NOT be used. Additional text high-lighted. Because of the lateness of this change, Ben Kaduk (the area director) asked= me to check with the list to make sure everyone is OK with this addition. Comments? --_000_BN7PR11MB2641A192BD1268A76C880B63C1850BN7PR11MB2641namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tero had this comment (which didn’t make it on= to this mailing list):

 

Btw, there is similar text in RFC7296 (base IKEv2= ) saying following:

 

   When using pre-shared keys, a critic= al consideration is how to assure

   the randomness of these secrets.&nbs= p; The strongest practice is to ensure

   that any pre-shared key contain as m= uch randomness as the strongest

   key being negotiated.  Deriving= a shared secret from a password,

   name, or other low-entropy source is= not secure.  These sources are

   subject to dictionary and social-eng= ineering attacks, among others.

 

so one option would also point to IKEv2 RFC and s= ay that same restrictions for not using low-entropy key that apply for pre-= shared keys there applies also PPK.

 

 

That comment strikes me as having a good point; t= he pre-shared keys in IKE are subject to exactly the same dictionary attack= that a PPK would have, and so the same advice would apply to both.  O= n the other hand, asking the reader to dig through a 142 page document for the relevant advice, or even scan thro= ugh 3 pages of the security considerations would appear to be less friendly= than we could be; in addition, advice for PPKs also need to consider Quant= um Computers (which were not a consideration with IKE pre-shared keys).

 

How about this text (which integrates suggestions= both from the security considerations of both RFC7296 and the PPK text, wh= ile trying to not sound like Frankentext [1].

 

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   A critical consideration is how to assure the randomness of this

<= b>   post-quantum preshared key.  Quantum computers are able to perform

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   Grover's algorithm [GROVER]; that effe= ctively halves the size of a

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   symmetric key.  In addition, an adversary, even with a conventional

<= b>   computer, can perform a dictionary = search over plausible post-quantum

<= b>   preshared key values.  The strongest practice is to ensure that

<= b>   any post-quantum preshared key cont= ains at least 256 bits of entropy,

<= b>   this will provide 128 bits of post-quantum securi= ty, while providing

<= b>   security against conventional dicti= onary attacks.  That provides

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   security equivalent to Level 5 as defi= ned in the NIST PQ Project Call

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   For Proposals [NISTPQCFP].  Derivin= g a postquantum preshared key from

<= b>   a password, name, or other low-entr= opy source is not secure because

<= b>   of these known attacks.<= /span>

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5"> 

The highlighted sections is text that is new to t= he draft; this would replace the first paragraph of the Security Considerat= ions section.

 

And, I would agree with Valery; I also would pref= er to avoid putting numbers that sound concrete; especially on something th= at is hard to measure (and “amount of entropy” is notoriously h= ard to measure – you can measure length, but that doesn’t actually mean “guessability”, which is what we&#= 8217;re trying to get at).

 

 

[1]: For those readers who might not be familiar = with English Literation or pop culture, there is a classic English novel &#= 8220;Frankenstein”, when a scientist (Dr Frankenstein) patches togeth= er parts from several corpses, and brings it to life (of course, it didn’t go well); in later references to this ori= ginal novel, the stitching of the several parts is obvious.  The allus= ion “Frankentext” suggests parts of several works being clumsil= y stitched together.  It is typically good advice to avoid cultural references when talking on an international mailing list; I just = couldn’t help myself this time…

 

From: Scott Fluhrer (sfluhrer)
Sent: Friday, June 05, 2020 3:41 PM
To: ipsec@ietf.org
Subject: Last minute change to draft-ietf-ipsecme-qr-ikev2

 

The draft “Mixing Preshared Keys in IKEv2 for = Post-quantum Security” was winding through the AUTH48 process, when a= t the last minute, I received an email from a researcher who thought they f= ound a problem with low entropy PPKs (the preshared keys that the draft uses).  While it turned out that what the found r= eally wasn’t a problem, such low entropy PPKs are a problem in genera= l.

 

To address this, I suggested to the RFC editors that= we modify the first paragraph of the security considerations from:

 

Original text:

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   Quantum computers are able to perform = Grover's algorithm [GROVER];

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   that effectively halves the size of a = symmetric key.  Because of

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   this, the user SHOULD ensure that the = post-quantum preshared key used

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   has at least 256 bits of entropy, in o= rder to provide 128 bits of

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   post-quantum security.  That prov= ides security equivalent to Level 5

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   as defined in the NIST PQ Project Call= For Proposals [NISTPQCFP].

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5"> 

Modified text:

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   Quantum computers are able to perform = Grover's algorithm [GROVER];

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   that effectively halves the size of a = symmetric key.  Because of

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   this, the user SHOULD ensure that the = post-quantum preshared key used

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   has at least 256 bits of entropy, in o= rder to provide 128 bits of

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   post-quantum security.  That prov= ides security equivalent to Level 5

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   as defined in the NIST PQ Project Call= For Proposals [NISTPQCFP].

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   An attacker who impersonates the server is able to validate guesses to

<= b>   the PPK.  Because of this, low= entropy PPK values MUST NOT be used.

 

Additional text high-lighted.

 

Because of the lateness of this change, Ben Kaduk (t= he area director) asked me to check with the list to make sure everyone is = OK with this addition.

 

Comments?

--_000_BN7PR11MB2641A192BD1268A76C880B63C1850BN7PR11MB2641namp_-- From nobody Mon Jun 8 09:00:15 2020 Return-Path: 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 391F93A0B5C for ; Mon, 8 Jun 2020 09:00:13 -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=unavailable 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 u4fgQS6c28u4 for ; Mon, 8 Jun 2020 09:00:09 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 4040C3A0D28 for ; Mon, 8 Jun 2020 08:59:55 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id a25so21164775ljp.3 for ; Mon, 08 Jun 2020 08:59:55 -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=Ml9m7Cs4mUH1qCt43AsTMRCCRK1gQfnRzZVC6e+tSOA=; b=X3H+F/L/Ep5ZSi732GhuaTZT71nUaMAcgZkERk5jeOV8XLLxLQNUx5gU6mjj9capUb 1wBS33lIZqxYsEDDPWRHGzc1GMGBb2eNaf8hXOfv7ud6bqV35YwC3XrdDhGs2dMdeVEL LU9IxujtvnA5DMW3uInJKbzn0Tx+nDFjEexQ6gxgaub2KrrRLeCOc1bfuhUlSfpJCQpn GzHRuCiSsq96xqY2877noslCQ4duDnS50czeBolANVrWzG5M0ePEyVi01UhUEFBeCCYM 3dg5d5xOBYqkGYXGdwJGu7CYY4U38hdTyD/QyPx2m9fmHE+29bZdRRJ5mo61R2k9+JyH Ar4Q== 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=Ml9m7Cs4mUH1qCt43AsTMRCCRK1gQfnRzZVC6e+tSOA=; b=BPnVfa3p93/ulCuWI2wgwYDK1XZB0iaOHtv43RWCjW0ZgIMBHUkfxVUa5LELy3aYpI KBWOfIJEGzHE7CS8XMhwx3laNW1KFGWKWwFegfL9/p/ZhKecX2f4jVNQsOn+pSTD+TB3 g4uQ3wgx1fnfBdXdYt4vRaM/U+tFsZjduLEleurtjQYMBqzxVLc9gxv+3raPgxMFY7rS 1jK4i1aiNOZ+aVddRotBhwY4SKrBDsXYDedTGLlM8dOawJrrlU3CVMacV2iVfpFSBW78 QzfTl3RQ7XZeHSctF9fTY3AK2h8VINlzz3tBd+Yw2Tn7rq15VVLr1OihS/otKPqbpntc 5Raw== X-Gm-Message-State: AOAM530Qu5wIoysQSD2koRCRtmHaSr7Iz85iuaUCKQ+imsQ0D4U9dUtY oDa/SCWtRnZIsnp4ni1AT/RYB+9t X-Google-Smtp-Source: ABdhPJwyyR4hD/NFXTSMm9Wfvw1AT6SR3w1P5/6yqEfGPmCmy3n84SOXUFS64ounslQPdvGrly7QMQ== X-Received: by 2002:a2e:b4e7:: with SMTP id s7mr10777591ljm.336.1591631991181; Mon, 08 Jun 2020 08:59:51 -0700 (PDT) Received: from chichi (95-27-147-103.broadband.corbina.ru. [95.27.147.103]) by smtp.gmail.com with ESMTPSA id u8sm4435314lff.38.2020.06.08.08.59.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jun 2020 08:59:50 -0700 (PDT) From: "Valery Smyslov" To: "'Scott Fluhrer \(sfluhrer\)'" , References: In-Reply-To: Date: Mon, 8 Jun 2020 18:59:47 +0300 Message-ID: <007c01d63dad$d623b830$826b2890$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007D_01D63DC6.FB7A8D20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ3Vq54pN5tf5sr+ANZG5BOdYrkiwKgCxFOp3etq8A= Content-Language: ru Archived-At: Subject: Re: [IPsec] Last minute change to draft-ietf-ipsecme-qr-ikev2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 16:00:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_007D_01D63DC6.FB7A8D20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Scott, I like this variant. Regards, Valery. From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Scott Fluhrer (sfluhrer) Sent: Monday, June 08, 2020 6:06 PM To: ipsec@ietf.org Subject: Re: [IPsec] Last minute change to draft-ietf-ipsecme-qr-ikev2 Tero had this comment (which didn't make it onto this mailing list): Btw, there is similar text in RFC7296 (base IKEv2) saying following: When using pre-shared keys, a critical consideration is how to assure the randomness of these secrets. The strongest practice is to ensure that any pre-shared key contain as much randomness as the strongest key being negotiated. Deriving a shared secret from a password, name, or other low-entropy source is not secure. These sources are subject to dictionary and social-engineering attacks, among others. so one option would also point to IKEv2 RFC and say that same restrictions for not using low-entropy key that apply for pre-shared keys there applies also PPK. That comment strikes me as having a good point; the pre-shared keys in IKE are subject to exactly the same dictionary attack that a PPK would have, and so the same advice would apply to both. On the other hand, asking the reader to dig through a 142 page document for the relevant advice, or even scan through 3 pages of the security considerations would appear to be less friendly than we could be; in addition, advice for PPKs also need to consider Quantum Computers (which were not a consideration with IKE pre-shared keys). How about this text (which integrates suggestions both from the security considerations of both RFC7296 and the PPK text, while trying to not sound like Frankentext [1]. A critical consideration is how to assure the randomness of this post-quantum preshared key. Quantum computers are able to perform Grover's algorithm [GROVER]; that effectively halves the size of a symmetric key. In addition, an adversary, even with a conventional computer, can perform a dictionary search over plausible post-quantum preshared key values. The strongest practice is to ensure that any post-quantum preshared key contains at least 256 bits of entropy, this will provide 128 bits of post-quantum security, while providing security against conventional dictionary attacks. That provides security equivalent to Level 5 as defined in the NIST PQ Project Call For Proposals [NISTPQCFP]. Deriving a postquantum preshared key from a password, name, or other low-entropy source is not secure because of these known attacks. The highlighted sections is text that is new to the draft; this would replace the first paragraph of the Security Considerations section. And, I would agree with Valery; I also would prefer to avoid putting numbers that sound concrete; especially on something that is hard to measure (and "amount of entropy" is notoriously hard to measure - you can measure length, but that doesn't actually mean "guessability", which is what we're trying to get at). [1]: For those readers who might not be familiar with English Literation or pop culture, there is a classic English novel "Frankenstein", when a scientist (Dr Frankenstein) patches together parts from several corpses, and brings it to life (of course, it didn't go well); in later references to this original novel, the stitching of the several parts is obvious. The allusion "Frankentext" suggests parts of several works being clumsily stitched together. It is typically good advice to avoid cultural references when talking on an international mailing list; I just couldn't help myself this time. From: Scott Fluhrer (sfluhrer) Sent: Friday, June 05, 2020 3:41 PM To: ipsec@ietf.org Subject: Last minute change to draft-ietf-ipsecme-qr-ikev2 The draft "Mixing Preshared Keys in IKEv2 for Post-quantum Security" was winding through the AUTH48 process, when at the last minute, I received an email from a researcher who thought they found a problem with low entropy PPKs (the preshared keys that the draft uses). While it turned out that what the found really wasn't a problem, such low entropy PPKs are a problem in general. To address this, I suggested to the RFC editors that we modify the first paragraph of the security considerations from: Original text: Quantum computers are able to perform Grover's algorithm [GROVER]; that effectively halves the size of a symmetric key. Because of this, the user SHOULD ensure that the post-quantum preshared key used has at least 256 bits of entropy, in order to provide 128 bits of post-quantum security. That provides security equivalent to Level 5 as defined in the NIST PQ Project Call For Proposals [NISTPQCFP]. Modified text: Quantum computers are able to perform Grover's algorithm [GROVER]; that effectively halves the size of a symmetric key. Because of this, the user SHOULD ensure that the post-quantum preshared key used has at least 256 bits of entropy, in order to provide 128 bits of post-quantum security. That provides security equivalent to Level 5 as defined in the NIST PQ Project Call For Proposals [NISTPQCFP]. An attacker who impersonates the server is able to validate guesses to the PPK. Because of this, low entropy PPK values MUST NOT be used. Additional text high-lighted. Because of the lateness of this change, Ben Kaduk (the area director) asked me to check with the list to make sure everyone is OK with this addition. Comments? ------=_NextPart_000_007D_01D63DC6.FB7A8D20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Scott,

 

I like this = variant.

 

Regards,

Valery.

 

From:= IPsec = [mailto:ipsec-bounces@ietf.org] On Behalf Of Scott Fluhrer = (sfluhrer)
Sent: Monday, June 08, 2020 6:06 PM
To: = ipsec@ietf.org
Subject: Re: [IPsec] Last minute change to = draft-ietf-ipsecme-qr-ikev2

 

Tero had this comment (which didn’t make it onto this = mailing list):

 

Btw, there is similar text in RFC7296 (base IKEv2) saying = following:

 

   When using pre-shared keys, a critical = consideration is how to assure

   the randomness of = these secrets.  The strongest practice is to = ensure

   that any pre-shared key contain as much = randomness as the strongest

   key being = negotiated.  Deriving a shared secret from a = password,

   name, or other low-entropy source is not = secure.  These sources are

   subject to = dictionary and social-engineering attacks, among = others.

 

so one option would also point to IKEv2 RFC and say that = same restrictions for not using low-entropy key that apply for = pre-shared keys there applies also PPK.

 

 

That comment strikes me as = having a good point; the pre-shared keys in IKE are subject to exactly = the same dictionary attack that a PPK would have, and so the same advice = would apply to both.  On the other hand, asking the reader to dig = through a 142 page document for the relevant advice, or even scan = through 3 pages of the security considerations would appear to be less = friendly than we could be; in addition, advice for PPKs also need to = consider Quantum Computers (which were not a consideration with IKE = pre-shared keys).

 

How about this text (which integrates suggestions both from = the security considerations of both RFC7296 and the PPK text, while = trying to not sound like Frankentext [1].

 

   A critical = consideration is how to assure the randomness of = this

   post-quantum preshared = key.  Quantum computers are able to = perform

   Grover's algorithm = [GROVER]; that effectively halves the size of a

   symmetric key.  = In addition, an adversary, even with a = conventional

   computer, can perform = a dictionary search over plausible = post-quantum

   preshared key = values.  The strongest practice is = to ensure that

   any post-quantum = preshared key contains at least 256 bits of = entropy,

   this will = provide 128 bits of post-quantum = security, while providing

   security against = conventional dictionary attacks.  That = provides

   security equivalent to = Level 5 as defined in the NIST PQ Project Call

   For Proposals = [NISTPQCFP].  Deriving a postquantum preshared key = from

   a password, name, or = other low-entropy source is not secure = because

   of these known = attacks.

 

The highlighted sections is text = that is new to the draft; this would replace the first paragraph of the = Security Considerations section.

 

And, I would agree with Valery; = I also would prefer to avoid putting numbers that sound concrete; = especially on something that is hard to measure (and “amount of = entropy” is notoriously hard to measure – you can measure = length, but that doesn’t actually mean “guessability”, = which is what we’re trying to get at).

 

 

[1]: For those readers who might = not be familiar with English Literation or pop culture, there is a = classic English novel “Frankenstein”, when a scientist (Dr = Frankenstein) patches together parts from several corpses, and brings it = to life (of course, it didn’t go well); in later references to = this original novel, the stitching of the several parts is = obvious.  The allusion “Frankentext” suggests parts of = several works being clumsily stitched together.  It is typically = good advice to avoid cultural references when talking on an = international mailing list; I just couldn’t help myself this = time…

 

From: Scott Fluhrer = (sfluhrer)
Sent: Friday, June 05, 2020 3:41 PM
To: = ipsec@ietf.org
Subject: Last minute change to = draft-ietf-ipsecme-qr-ikev2

 

The draft “Mixing Preshared = Keys in IKEv2 for Post-quantum Security” was winding through the = AUTH48 process, when at the last minute, I received an email from a = researcher who thought they found a problem with low entropy PPKs (the = preshared keys that the draft uses).  While it turned out that what = the found really wasn’t a problem, such low entropy PPKs are a = problem in general.

 

To address this, I suggested to the RFC editors that we = modify the first paragraph of the security considerations = from:

 

Original text:

   Quantum computers are = able to perform Grover's algorithm [GROVER];

   that effectively = halves the size of a symmetric key.  Because = of

   this, the user SHOULD = ensure that the post-quantum preshared key used

   has at least 256 bits = of entropy, in order to provide 128 bits of

   post-quantum = security.  That provides security equivalent to Level = 5

   as defined in the NIST = PQ Project Call For Proposals [NISTPQCFP].

 

Modified = text:

   Quantum computers are = able to perform Grover's algorithm [GROVER];

   that effectively = halves the size of a symmetric key.  Because = of

   this, the user SHOULD = ensure that the post-quantum preshared key used

   has at least 256 bits = of entropy, in order to provide 128 bits of

   post-quantum = security.  That provides security equivalent to Level = 5

   as defined in the NIST = PQ Project Call For Proposals [NISTPQCFP].

   An attacker who = impersonates the server is able to validate guesses = to

   the PPK.  Because = of this, low entropy PPK values MUST NOT be = used.

 

Additional text high-lighted.

 

Because of the lateness of this = change, Ben Kaduk (the area director) asked me to check with the list to = make sure everyone is OK with this addition.

 

Comments?

------=_NextPart_000_007D_01D63DC6.FB7A8D20-- From nobody Mon Jun 8 09:38:03 2020 Return-Path: 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 9AAF13A0CF1 for ; Mon, 8 Jun 2020 09:38:01 -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 qLhuNRC2mEsw for ; Mon, 8 Jun 2020 09:38:00 -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 1186C3A0CF8 for ; Mon, 8 Jun 2020 09:38:00 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 49gf7S3s6WzMc4; Mon, 8 Jun 2020 18:37:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1591634276; bh=Nd4O+XLcEcC1oXq3yGwbgNhz9nlefFTsBrtfMPa6ye4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=g4TET7CRB1wbyxr3FqGZ3KRRkxy0kJLOdKCSZSsLo0CaFGbMpTwx6cAdVKsKiFcFN pwmQRluY7A+hrbjrG/ARglCXa3BHPzeq9yznP2JIxZ7LlTCB7/mvzpFscHwKIX019a ytDuxvLehg0Z1IfdI4BTwVSWvG1l+B8/8GfM0o7c= 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 YTHndleGN97Q; Mon, 8 Jun 2020 18:37:55 +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; Mon, 8 Jun 2020 18:37:55 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 3ED2D6020D44; Mon, 8 Jun 2020 12:37:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 34C73669F1; Mon, 8 Jun 2020 12:37:54 -0400 (EDT) Date: Mon, 8 Jun 2020 12:37:54 -0400 (EDT) From: Paul Wouters To: "Scott Fluhrer (sfluhrer)" cc: "ipsec@ietf.org" In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [IPsec] Last minute change to draft-ietf-ipsecme-qr-ikev2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 16:38:02 -0000 On Mon, 8 Jun 2020, Scott Fluhrer (sfluhrer) wrote: > How about this text (which integrates suggestions both from the security considerations of both RFC7296 and the PPK text, while > trying to not sound like Frankentext [1]. That is okay with me. > And, I would agree with Valery; I also would prefer to avoid putting numbers that sound concrete; especially on something that is > hard to measure (and “amount of entropy” is notoriously hard to measure – you can measure length, but that doesn’t actually mean > “guessability”, which is what we’re trying to get at). I agree with not putting in numbers. I am worried about rejecting anything as an implementation though because whichever implementation has the strongest checks will be the least compatible. So in the end, the text you suggested to add will have to be completely ignored by implementers :/ Paul From nobody Mon Jun 8 10:24:46 2020 Return-Path: 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 3DD963A0E3E for ; Mon, 8 Jun 2020 10:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-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 (768-bit key) header.d=labn.net 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 X3vcu1DB30nu for ; Mon, 8 Jun 2020 10:24:36 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (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 5844B3A0DE4 for ; Mon, 8 Jun 2020 10:24:36 -0700 (PDT) Received: from CMGW (unknown [10.9.0.13]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 251171E067D for ; Mon, 8 Jun 2020 11:24:35 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id iLVijuU4wtoKZiLVijVUJ0; Mon, 08 Jun 2020 11:24:35 -0600 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.2 cv=J/Ha1EvS c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=nTHF0DUjJn0A:10 a=Vy_oeq2dmq0A:10 a=7ZN4cI0QAAAA:8 a=48vgC7mUAAAA:8 a=2sEVj68OLAwJVC2l1w4A:9 a=BeMJvph1DpctVb6w:21 a=8WRhziln2aXCndyh:21 a=QEXdDO2ut3YA:10 a=Dl0WHwQvj8hGZljrFLtM:22 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=gAaFSIcUDzju3QHnsPOfwCnqVgQCQtXiHrJokSK9MUQ=; b=a+ED7Wsic58yq+6LSAzyWZcEsK 67xGFHRlCkGTie3A1brTE12zYdgay7wVILBZh+lgUoDMUDndZexSKLyPTgFvsKbQ2ZE0SLBcEdjU3 7YvQUmEORGb51j8X0k7/v5kYL; Received: from [127.0.0.1] (port=39669 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1jiLVi-0015gt-Pk; Mon, 08 Jun 2020 11:24:34 -0600 To: Steffen Klassert , Michael Richardson Cc: IPsecME WG References: <13344.1583165241@localhost> <24278.24659.921904.72666@fireball.acr.fi> <7322AB98-43B1-43E2-BCC6-7EC685869A8B@chopps.org> <20200607090000.GJ13121@gauss3.secunet.de> <14166.1591580621@localhost> <20200608110502.GH19286@gauss3.secunet.de> From: Lou Berger Message-ID: <684b221b-bab0-073a-defe-b1296ecdb659@labn.net> Date: Mon, 8 Jun 2020 13:24:31 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200608110502.GH19286@gauss3.secunet.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 127.0.0.1 X-Source-L: Yes X-Exim-ID: 1jiLVi-0015gt-Pk X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([IPv6:::1]) [127.0.0.1]:39669 X-Source-Auth: lberger@labn.net X-Email-Count: 5 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [IPsec] Early Allocation Request for IPTFS_PROTOCOL IP protocol number. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 17:24:45 -0000 On 6/8/2020 7:05 AM, Steffen Klassert wrote: > On Sun, Jun 07, 2020 at 09:43:41PM -0400, Michael Richardson wrote: >> Steffen Klassert wrote: >> > This alterative usecase tries to solve the 'small packet' tunneling >> > problem. Sending small packets over a tunnel usually creates quite a >> > lot of overhead, as each packet needs to get it's own tunnel header >> > etc. For IPsec, the situation is even worse as a cpu intensive crypto >> > operation has to be applied for each of these small packets. With the >> > IPTFS_PROTOCOL payload type, we could group small packets and send them >> > into one big packet over the tunnel. This can avoid tunneling overhead >> > because we need only one tunnel header for multiple packets. Also this >> > method would be very data and instruction cache effective because >> > multiple packets are processed together. The good thing is that the >> > Linux forwarding path can already provide packets chains (GRO), so we >> > would just need to take these packets chains and put them into big >> > tunnel packets with IPTFS_PROTOCOL payload type. As a side effect, >> > having IPTFS_PROTOCOL as a general purpose tunnel payload, it might be >> > easier to argue for a new IP protocol number allocation. >> >> Does your use case include situations where this is not an IPsec tunnel? > My main usecase would be an IPsec tunnel, but the same can work > for other tunnel types too. If we have an IP protocol number, > it is just easy to use it outside of IPsec world, but I don't > have a strong opinion on that. FWIW  Ethernet TFS (802.1AEdk) is taking an approach that allows for this type of operation  as some there want to explicitly allow the E-TFS framing separated from  MACsec encryption... Lou > > Steffen > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Thu Jun 11 05:44:47 2020 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D1D393A079B; Thu, 11 Jun 2020 05:44:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, ynir.ietf@gmail.com, kaduk@mit.edu X-Test-IDTracker: no X-IETF-IDTracker: 7.3.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159187948476.4039.16061601344849148413@ietfa.amsl.com> Date: Thu, 11 Jun 2020 05:44:44 -0700 Archived-At: Subject: [IPsec] ipsecme - New Meeting Session Request for IETF 108 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 12:44:45 -0000 A new meeting session request has just been submitted by Yoav Nir, a Chair of the ipsecme working group. --------------------------------------------------------- Working Group Name: IP Security Maintenance and Extensions Area Name: Security Area Session Requester: Yoav Nir Number of Sessions: 1 Length of Session(s): 100 Minutes Number of Attendees: 30 Conflicts to Avoid: Chair Conflict: tls acme Technology Overlap: cfrg People who must be present: Yoav Nir Tero Kivinen Benjamin Kaduk Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Jun 11 13:05:32 2020 Return-Path: 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 E63003A0CBA for ; Thu, 11 Jun 2020 13:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=bqdpxmFf; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=AgUD8eLY 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 qrpDoCPjWlMW for ; Thu, 11 Jun 2020 13:05:27 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 321363A0CBC for ; Thu, 11 Jun 2020 13:05:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24053; q=dns/txt; s=iport; t=1591905927; x=1593115527; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=CaKoikjh+bWGk2of1JLAw0vYsnl3sUmAejUI8aMl3TA=; b=bqdpxmFfTjfAJXfN0P/49G5q3qyrSJXyowZ5bTUBn0vxmvLPP7EVNpNa 4/2FG/TcsT4gM/bZIHFi0SavqXeZztryQt9M4QqCFCpCXZ4O/2QrV4deS tALBpbFehQO2xWB+60zGRhIui6HmEH7V4F5kI/Aptn3m81n7NaleTgaHF c=; IronPort-PHdr: =?us-ascii?q?9a23=3AtsCdiBF5eyaDghAdnOW8q51GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401gObUYDS8fkCiufKvebnQ2NTqZqCsXVXdptKWl?= =?us-ascii?q?dFjMgNhAUvDYaDDlGzN//laSE2XaEgHF9o9n22Kw5ZTcD5YVCBrni79zVUGx?= =?us-ascii?q?jjO0xyPOumUoLXht68gua1/ZCbag5UhT27NLV1Khj+rQjYusQMx4V4LaNkwR?= =?us-ascii?q?rSqXwOcONTlm4=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJCAB7jeJe/5RdJa1mHQEBAQEJARI?= =?us-ascii?q?BBQUBQIFKgSMvUgdvWC8sCodgA405mFKBQoEQA1ULAQEBDAEBLQIEAQGERAK?= =?us-ascii?q?CIgIkOBMCAwEBCwEBBQEBAQIBBgRthVsMhXIBAQEBAxILEBMBASwMDwIBCBE?= =?us-ascii?q?EAQEZCAcHMhQJCAEBBAESCA0ECYMFgX5NAy4BqQsCgTmIYXSBNIMBAQEFhSA?= =?us-ascii?q?Ygg4JgTiCZIcbgkwagUE/gVSCTT6EGQESAQkaNBmCeIItjm6JaSWKepBFCoJ?= =?us-ascii?q?ZjlmKXJ5ckROaIoQGAgQCBAUCDgEBBYFqImZwcBU7gmlQFwINjh6DcYpWdDc?= =?us-ascii?q?CBggBAQMJfI0VJAmBBgGBDwEB?= X-IronPort-AV: E=Sophos;i="5.73,500,1583193600"; d="scan'208,217";a="505660195" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Jun 2020 20:05:26 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 05BK5PU5032465 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 11 Jun 2020 20:05:26 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 11 Jun 2020 15:05:26 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 11 Jun 2020 15:05:25 -0500 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 11 Jun 2020 15:05:25 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GQNZYLI5UFCWg6cSp6UW2+zd5Nu0zOgQtpjHyOb5+6A6FRkCTae9IeN+AqjkNnYD1PzDtuz79p/wqL7cSuFxpPTyWkuivYkCU+Lr3sm8kEsiGIgOwJuVl8bTcJVjFkVywRAi1FgFC+qej//GRp8QiXbNaNAmidQO2xknQCyesPnLFGcDIGhPuNS9Muik1mJA4PsIk+9js9dr3uyeORRo4IFcAFc+X6GupvYlZZkjueLViYAjPi9GuoDeLSELzBn9jcvuzmMN4Sr6eArzN8fMS1UoYIghYfHF6AUXrWz4Z/lytll83FyVshR8N4qQ82BEHdzbg9iMHYTbwm5vAd/Ntw== 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=mW7WWjpIKSSFClAbOf8Bq8F4V+pTSuD08yF+Sugc27c=; b=XColDv+gG4ggkaMSqk6HDyk3J3YqyisZ5LO2UYHoXota2jpNP/ablTsATsOk3VRgJp/2w5/mRCEkf/hj28P0DAZwGWT/mPNwmWIq4OaJYLuYLMc4W/NNUqYkUrOTUO8GtBmrn4LjDVbeya379IitZvBtDs3zhLF/BSvky0sa/Jl8ZpQ2uOarL9hZQBX+7VMUmgKqr1OSkEYqtLaWe58IiFuUJfWIUL2GU7XZs2s62umGBQvqdJUaG+tlz0yVixINRVGuonlsnVIFQN2ih2/9bpS0fOVSSpolvLZMv2UCetfPPNsb7k40JaT9GTRjsrvrUudDlPQU1pOFP5uANVUmpQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mW7WWjpIKSSFClAbOf8Bq8F4V+pTSuD08yF+Sugc27c=; b=AgUD8eLYqVnuy09J2O2J+ZWVpoGk6OYcC6tw5OCfYwYY1Y4EF5rdK/lgWaQmqiiu3FlxVuolZYzZP9syycakLdNok28eKdpN8H1RXXEpJpW1/Lx2SnYwqZYQP4Up4afnqAdv5BUAUmTo5Ijk0oWVUqNrTXLfT9hdGwSUs01dDw4= Received: from BN7PR11MB2641.namprd11.prod.outlook.com (2603:10b6:406:b1::25) by BN8PR11MB3714.namprd11.prod.outlook.com (2603:10b6:408:90::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.19; Thu, 11 Jun 2020 20:05:24 +0000 Received: from BN7PR11MB2641.namprd11.prod.outlook.com ([fe80::35bd:ecae:1e28:58f5]) by BN7PR11MB2641.namprd11.prod.outlook.com ([fe80::35bd:ecae:1e28:58f5%5]) with mapi id 15.20.3088.022; Thu, 11 Jun 2020 20:05:24 +0000 From: "Scott Fluhrer (sfluhrer)" To: "Scott Fluhrer (sfluhrer)" , "ipsec@ietf.org" Thread-Topic: Last minute change to draft-ietf-ipsecme-qr-ikev2 Thread-Index: AdY7b0YZDPRKeamGTBelnS42EluRIwCIhypQAKZrv1A= Date: Thu, 11 Jun 2020 20:05:24 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.76] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7f92e411-bad0-4807-cb56-08d80e42c6f8 x-ms-traffictypediagnostic: BN8PR11MB3714: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0431F981D8 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: vs2Zg0Wh04Uj+s4cI56L6I/ybbESgpOB6QnoJ6QJSHJUqkHU82k2ROIqH3gYxfEeGYWQHrKeiG6TDceSBrN6vxUqEcbu2oJv7FNv5l1oxf+G5530IWpiF/rzWxm9ozehx6YpPa2qG6j6bKwS7A1AsToBOTnfONd26p/eSvJGS4CKSzEMYIaTlweifOrms3UtYVUuHECnL6igRW1PRF8xTOyruF1pVjgxf51Qb32seMz9shGAaHTeSZXGCpSfBCVTK24rfvbLB/pqBKbHUjn4Vve1HGHeSGD/FyuhJ+Kp2pxu9zoeY587IUyeCmQDPuVn6Pcvua33LvCr57iDEyoJwA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2641.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(346002)(366004)(376002)(39860400002)(396003)(478600001)(8676002)(6506007)(7696005)(2906002)(110136005)(186003)(9686003)(71200400001)(53546011)(316002)(33656002)(26005)(83380400001)(55016002)(76116006)(66446008)(66556008)(64756008)(8936002)(86362001)(66946007)(66476007)(5660300002)(52536014); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: vsj+k5EnTSf3Un9pyS4o/5oHqpG9K74JL+qpM6+yzTI8ZgHyCmdUd3imNU7FDWuJQeXiYHOGXKNDf5TMqqJc4Pbc39XnuR/KEH/K5yCO19+29qzDWzGeIC8IL7RajBwb+6wA01mI9Cdxp5hmiILLjXm92GanICZ+oSONvz5/4Dld5MTToexuKblQZLTldCaokRYtW823QoiWbEdPlIUrNdO/J5EmQcMRms68q9yMGO8Njvq+EYNamgiwog7kEkKMbh/rzYHMO7DV1F6TCxzWf/vUT0/DqbW6H3GdhaY8TzeM+prgYxszFaunEYAFRr9D06lVgDMJx4nIXsGt4EZIen/2i/pvp6OY7NyZEiAOsI312f/O2QNuM0llqm2cZCV6QRuv0PgA7pDKZnKWAOBK1NDWFWkwiB9GBockTAikqdlZSdIXSNPKrqaYYbZpPMLWWRIfUZeKZUQPyrlEkClAbzpRVMKK8VuawsJMdaYo9TpPrE5bAG74v6jPzkpDFySc x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN7PR11MB2641A4A2967691DC5EE7A198C1800BN7PR11MB2641namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7f92e411-bad0-4807-cb56-08d80e42c6f8 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2020 20:05:24.1269 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: JBdChxZgkByntf55+tbjYiG9M/Q+1qk199vBqK0oJ2R0AF44++p8J3/kCD4vXA6bW7sQizcpyGAgatyMjmqgyA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR11MB3714 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: Re: [IPsec] Last minute change to draft-ietf-ipsecme-qr-ikev2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 20:05:30 -0000 --_000_BN7PR11MB2641A4A2967691DC5EE7A198C1800BN7PR11MB2641namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Does anyone else have comments about this text (either for or against)? Pa= ul, Tero, you had previously chimed in; do either of you something to say? From: IPsec On Behalf Of Scott Fluhrer (sfluhrer) Sent: Monday, June 08, 2020 11:06 AM To: ipsec@ietf.org Subject: Re: [IPsec] Last minute change to draft-ietf-ipsecme-qr-ikev2 Tero had this comment (which didn't make it onto this mailing list): Btw, there is similar text in RFC7296 (base IKEv2) saying following: When using pre-shared keys, a critical consideration is how to assure the randomness of these secrets. The strongest practice is to ensure that any pre-shared key contain as much randomness as the strongest key being negotiated. Deriving a shared secret from a password, name, or other low-entropy source is not secure. These sources are subject to dictionary and social-engineering attacks, among others. so one option would also point to IKEv2 RFC and say that same restrictions = for not using low-entropy key that apply for pre-shared keys there applies = also PPK. That comment strikes me as having a good point; the pre-shared keys in IKE = are subject to exactly the same dictionary attack that a PPK would have, an= d so the same advice would apply to both. On the other hand, asking the re= ader to dig through a 142 page document for the relevant advice, or even sc= an through 3 pages of the security considerations would appear to be less f= riendly than we could be; in addition, advice for PPKs also need to conside= r Quantum Computers (which were not a consideration with IKE pre-shared key= s). How about this text (which integrates suggestions both from the security co= nsiderations of both RFC7296 and the PPK text, while trying to not sound li= ke Frankentext [1]. A critical consideration is how to assure the randomness of this post-quantum preshared key. Quantum computers are able to perform Grover's algorithm [GROVER]; that effectively halves the size of a symmetric key. In addition, an adversary, even with a conventional computer, can perform a dictionary search over plausible post-quantum preshared key values. The strongest practice is to ensure that any post-quantum preshared key contains at least 256 bits of entropy, this will provide 128 bits of post-quantum security, while providing security against conventional dictionary attacks. That provides security equivalent to Level 5 as defined in the NIST PQ Project Call For Proposals [NISTPQCFP]. Deriving a postquantum preshared key from a password, name, or other low-entropy source is not secure because of these known attacks. The highlighted sections is text that is new to the draft; this would repla= ce the first paragraph of the Security Considerations section. And, I would agree with Valery; I also would prefer to avoid putting number= s that sound concrete; especially on something that is hard to measure (and= "amount of entropy" is notoriously hard to measure - you can measure lengt= h, but that doesn't actually mean "guessability", which is what we're tryin= g to get at). [1]: For those readers who might not be familiar with English Literation or= pop culture, there is a classic English novel "Frankenstein", when a scien= tist (Dr Frankenstein) patches together parts from several corpses, and bri= ngs it to life (of course, it didn't go well); in later references to this = original novel, the stitching of the several parts is obvious. The allusio= n "Frankentext" suggests parts of several works being clumsily stitched tog= ether. It is typically good advice to avoid cultural references when talki= ng on an international mailing list; I just couldn't help myself this time.= .. From: Scott Fluhrer (sfluhrer) Sent: Friday, June 05, 2020 3:41 PM To: ipsec@ietf.org Subject: Last minute change to draft-ietf-ipsecme-qr-ikev2 The draft "Mixing Preshared Keys in IKEv2 for Post-quantum Security" was wi= nding through the AUTH48 process, when at the last minute, I received an em= ail from a researcher who thought they found a problem with low entropy PPK= s (the preshared keys that the draft uses). While it turned out that what = the found really wasn't a problem, such low entropy PPKs are a problem in g= eneral. To address this, I suggested to the RFC editors that we modify the first pa= ragraph of the security considerations from: Original text: Quantum computers are able to perform Grover's algorithm [GROVER]; that effectively halves the size of a symmetric key. Because of this, the user SHOULD ensure that the post-quantum preshared key used has at least 256 bits of entropy, in order to provide 128 bits of post-quantum security. That provides security equivalent to Level 5 as defined in the NIST PQ Project Call For Proposals [NISTPQCFP]. Modified text: Quantum computers are able to perform Grover's algorithm [GROVER]; that effectively halves the size of a symmetric key. Because of this, the user SHOULD ensure that the post-quantum preshared key used has at least 256 bits of entropy, in order to provide 128 bits of post-quantum security. That provides security equivalent to Level 5 as defined in the NIST PQ Project Call For Proposals [NISTPQCFP]. An attacker who impersonates the server is able to validate guesses to the PPK. Because of this, low entropy PPK values MUST NOT be used. Additional text high-lighted. Because of the lateness of this change, Ben Kaduk (the area director) asked= me to check with the list to make sure everyone is OK with this addition. Comments? --_000_BN7PR11MB2641A4A2967691DC5EE7A198C1800BN7PR11MB2641namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Does anyone else have comments about this text (eith= er for or against)?  Paul, Tero, you had previously chimed in; do eith= er of you something to say?

 

From: IPsec <ipsec-bounces@ietf.org> On Behalf Of Scott Fluhrer (sfluhrer)
Sent: Monday, June 08, 2020 11:06 AM
To: ipsec@ietf.org
Subject: Re: [IPsec] Last minute change to draft-ietf-ipsecme-qr-ike= v2

 

Tero had this comment (which didn’t make it on= to this mailing list):

 

Btw, there is similar text in RFC7296 (base IKEv2= ) saying following:

 

   When using pre-shared keys, a critic= al consideration is how to assure

   the randomness of these secrets.&nbs= p; The strongest practice is to ensure

   that any pre-shared key contain as m= uch randomness as the strongest

   key being negotiated.  Deriving= a shared secret from a password,

   name, or other low-entropy source is= not secure.  These sources are

   subject to dictionary and social-eng= ineering attacks, among others.

 

so one option would also point to IKEv2 RFC and s= ay that same restrictions for not using low-entropy key that apply for pre-= shared keys there applies also PPK.

 

 

That comment strikes me as having a good point; t= he pre-shared keys in IKE are subject to exactly the same dictionary attack= that a PPK would have, and so the same advice would apply to both.  O= n the other hand, asking the reader to dig through a 142 page document for the relevant advice, or even scan thro= ugh 3 pages of the security considerations would appear to be less friendly= than we could be; in addition, advice for PPKs also need to consider Quant= um Computers (which were not a consideration with IKE pre-shared keys).

 

How about this text (which integrates suggestions= both from the security considerations of both RFC7296 and the PPK text, wh= ile trying to not sound like Frankentext [1].

 

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   A critical consideration is how to assure the randomness of this

<= b>   post-quantum preshared key.  Quantum computers are able to perform

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   Grover's algorithm [GROVER]; that effe= ctively halves the size of a

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   symmetric key.  In addition, an adversary, even with a conventional

<= b>   computer, can perform a dictionary = search over plausible post-quantum

<= b>   preshared key values.  The strongest practice is to ensure that

<= b>   any post-quantum preshared key cont= ains at least 256 bits of entropy,

<= b>   this will provide 128 bits of post-quantum securi= ty, while providing

<= b>   security against conventional dicti= onary attacks.  That provides

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   security equivalent to Level 5 as defi= ned in the NIST PQ Project Call

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   For Proposals [NISTPQCFP].  Deriving a postquantum preshared key fr= om

<= b>   a password, name, or other low-entr= opy source is not secure because

<= b>   of these known attacks.<= /span>

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5"> 

The highlighted sections is text that is new to t= he draft; this would replace the first paragraph of the Security Considerat= ions section.

 

And, I would agree with Valery; I also would pref= er to avoid putting numbers that sound concrete; especially on something th= at is hard to measure (and “amount of entropy” is notoriously h= ard to measure – you can measure length, but that doesn’t actually mean “guessability”, which is what we&#= 8217;re trying to get at).

 

 

[1]: For those readers who might not be familiar = with English Literation or pop culture, there is a classic English novel &#= 8220;Frankenstein”, when a scientist (Dr Frankenstein) patches togeth= er parts from several corpses, and brings it to life (of course, it didn’t go well); in later references to this ori= ginal novel, the stitching of the several parts is obvious.  The allus= ion “Frankentext” suggests parts of several works being clumsil= y stitched together.  It is typically good advice to avoid cultural references when talking on an international mailing list; I just = couldn’t help myself this time…

 

From: Scott Fluhrer (sfluhrer)
Sent: Friday, June 05, 2020 3:41 PM
To: ipsec@ietf.org
Subject: Last minute change to draft-ietf-ipsecme-qr-ikev2

 

The draft “Mixing Preshared Keys in IKEv2 for = Post-quantum Security” was winding through the AUTH48 process, when a= t the last minute, I received an email from a researcher who thought they f= ound a problem with low entropy PPKs (the preshared keys that the draft uses).  While it turned out that what the found r= eally wasn’t a problem, such low entropy PPKs are a problem in genera= l.

 

To address this, I suggested to the RFC editors that= we modify the first paragraph of the security considerations from:

 

Original text:

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   Quantum computers are able to perform = Grover's algorithm [GROVER];

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   that effectively halves the size of a = symmetric key.  Because of

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   this, the user SHOULD ensure that the = post-quantum preshared key used

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   has at least 256 bits of entropy, in o= rder to provide 128 bits of

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   post-quantum security.  That prov= ides security equivalent to Level 5

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   as defined in the NIST PQ Project Call= For Proposals [NISTPQCFP].

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5"> 

Modified text:

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   Quantum computers are able to perform = Grover's algorithm [GROVER];

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   that effectively halves the size of a = symmetric key.  Because of

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   this, the user SHOULD ensure that the = post-quantum preshared key used

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   has at least 256 bits of entropy, in o= rder to provide 128 bits of

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   post-quantum security.  That prov= ides security equivalent to Level 5

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   as defined in the NIST PQ Project Call= For Proposals [NISTPQCFP].

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   An attacker who impersonates the server is able to validate guesses to

<= b>   the PPK.  Because of this, low= entropy PPK values MUST NOT be used.

 

Additional text high-lighted.

 

Because of the lateness of this change, Ben Kaduk (t= he area director) asked me to check with the list to make sure everyone is = OK with this addition.

 

Comments?

--_000_BN7PR11MB2641A4A2967691DC5EE7A198C1800BN7PR11MB2641namp_-- From nobody Thu Jun 11 13:35:02 2020 Return-Path: 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 6757C3A082E for ; Thu, 11 Jun 2020 13:35:00 -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 qahFZWYX1_nx for ; Thu, 11 Jun 2020 13:34:59 -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 E31F83A0829 for ; Thu, 11 Jun 2020 13:34:58 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 49jbFY2YMWzMm0; Thu, 11 Jun 2020 22:34:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1591907697; bh=i5pFI/BUPknk0fyYDzM4TwAcO1upWCfHUl2mnmKLArE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=RfAtsD4RXQgHck667fYpglJWAtYHcbSG9oJBrsjQ32N9l+sd44lTOES2TMWGEf5pZ 0guae4fI3/j9iPjzFtD0Oni22bs4hSWqevenwHzSvQaL1o+Ac+2UvgmeopLX7g9V0w TgLYz34nBbAT6FJI/v9dp9ygtxO56inN+qaJABv4= 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 Gz614iXPRD5V; Thu, 11 Jun 2020 22:34:56 +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, 11 Jun 2020 22:34:56 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id D1DBF6020D59; Thu, 11 Jun 2020 16:34:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C783966B7C; Thu, 11 Jun 2020 16:34:54 -0400 (EDT) Date: Thu, 11 Jun 2020 16:34:54 -0400 (EDT) From: Paul Wouters To: "Scott Fluhrer (sfluhrer)" cc: "ipsec@ietf.org" In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [IPsec] Last minute change to draft-ietf-ipsecme-qr-ikev2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 20:35:01 -0000 On Thu, 11 Jun 2020, Scott Fluhrer (sfluhrer) wrote: > Does anyone else have comments about this text (either for or against)? Paul, Tero, you had previously chimed in; do either of you something to say? I'm fine with the change proposed. Paul From nobody Sun Jun 14 16:01:33 2020 Return-Path: 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 1B2403A07BA for ; Sun, 14 Jun 2020 16:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 QFt31NVCoBRH for ; Sun, 14 Jun 2020 16:01:30 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC3AA3A07B9 for ; Sun, 14 Jun 2020 16:01:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id CE8C1389FF for ; Sun, 14 Jun 2020 18:58:55 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hGP9SHfOYcSm for ; Sun, 14 Jun 2020 18:58:54 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id BE7E5389FD for ; Sun, 14 Jun 2020 18:58:54 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8792875F for ; Sun, 14 Jun 2020 19:01:27 -0400 (EDT) From: Michael Richardson To: ipsec@ietf.org In-Reply-To: <159216161966.11870.9061488083423868610@ietfa.amsl.com> References: <159216161966.11870.9061488083423868610@ietfa.amsl.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] WG Action: Formed Multiplexed Application Substrate over QUIC Encryption (masque) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2020 23:01:32 -0000 --=-=-= Content-Type: text/plain ---- A new IETF WG has been formed in the Transport Area. For additional information, please contact the Area Directors or the WG Chairs. Multiplexed Application Substrate over QUIC Encryption (masque) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: Christopher Wood Eric Kinnear Assigned Area Director: Martin Duke Transport Area Directors: Magnus Westerlund Martin Duke Mailing list: Address: masque@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/masque Archive: https://mailarchive.ietf.org/arch/browse/masque/ Group page: https://datatracker.ietf.org/group/masque/ Charter: https://datatracker.ietf.org/doc/charter-ietf-masque/ Many network topologies lead to situations where transport protocol proxying is beneficial. For example, proxying enables endpoints to communicate when end-to-end connectivity is not possible, or to apply additional encryption where desirable (such as a VPN). Proxying can also improve client privacy, e.g., by hiding a client's IP address from a target server. Proxying technologies such as SOCKS and HTTP(S) CONNECT exist, albeit with their own shortcomings. For example, SOCKS signalling is not encrypted and HTTP CONNECT is currently limited to TCP. In contrast, HTTP/3 is a viable candidate protocol for proxying arbitrary traffic, as in a single connection it provides secure connectivity, multiplexed streams, address migration, and a unified congestion controller. An HTTP/3 datagram construct built on top of QUIC datagram frames would provide for unreliable data transmission and enable transporting UDP and other unreliable flows via a proxy. Moreover, it would not introduce potentially redundant or unnecessary recovery mechanisms. Lastly, HTTP supports an established request/response semantic that can set up and configure flows for different services. The primary goal of this working group is to develop mechanism(s) that allow configuring and concurrently running multiple proxied stream- and datagram-based flows inside an HTTPS connection. These mechanism(s) are collectively called MASQUE. The group will specify HTTP and/or HTTP/3 extensions to enable this functionality. The group will focus on a limited set of client-initiated services: (1) UDP CONNECT and (2) IP proxying. Server-initiated services are out of scope. The working group will first deliver a protocol solution for UDP CONNECT and a requirements document for IP proxying. Once both are complete, the working group will focus on a protocol solution for IP proxying. The working group will consider fallback to versions of HTTPS that operate over TCP as a mitigation to UDP or HTTP/3 blocking. Moreover, the working group will consider implications of tunneling protocols with congestion control and loss recovery over MASQUE, and may issue recommendations accordingly. New congestion control and loss recovery algorithms are out of scope. Multicast support is out of scope. However, the group may specify extension points that would enable future work on multicast. Specifying proxy server discovery mechanisms is also out of scope. However, the group may consider features, such as proxy server identifiers, that aid future discovery mechanisms. Impacts on address migration, NAT rebinding, and future multipath mechanisms of QUIC are not anticipated. However, the working group should document these impacts, or those of any other QUIC developments, if they arise. The group will coordinate closely with other working groups responsible for maintaining relevant protocol extensions, such as HTTPBIS, QUIC, or TLS. It will also coordinate closely with ICCRG and TSVWG on congestion control and loss recovery considerations, and intarea for IP Proxying. Milestones: - Submit a standards track UDP CONNECT document - Submit an informational IP Proxying over MASQUE document _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl7mrEcACgkQgItw+93Q 3WU9iggAl/Sq2N9H8sIOd5AflNMSoBlnHKIOrfxsmBNaSjj0HO8PLG5xliTIMx6y j5XvaiqoiCFIIheM/2/i+8YJU6tzFAigL5otMzMdWD88brGcUdCdMShJLQbKal/u WTrsd7mUDzdFnpE4/C0SLCA8EvUtwEzJSHmgDwZevYLb87MoRB3wWOLOrX6dNVN7 +X1TcGDGdR3CUyfZUdGagWOekJeB7aDDnJxxpjAfhbNupnOGbGYPqYGmnvaKPZx/ WNKOSMByKv/Z23ui4/83k/KOmXPuuf+lihzGCsoPrqJmu56xmsxv91gRUoGggoc4 838CsidaxfVCMbcbJbN+zIy5kTn7Rg== =ieQE -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 15 00:53:00 2020 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DCA5C3A0AA1; Mon, 15 Jun 2020 00:52:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.3.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <159220757484.32119.17958275380428394021@ietfa.amsl.com> Date: Mon, 15 Jun 2020 00:52:54 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-intermediate-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2020 07:52:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Intermediate Exchange in the IKEv2 Protocol Author : Valery Smyslov Filename : draft-ietf-ipsecme-ikev2-intermediate-04.txt Pages : 11 Date : 2020-06-15 Abstract: 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 messages, but cannot be used in the initial IKEv2 exchange. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-intermediate/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-intermediate-04 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-intermediate-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-intermediate-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 15 00:57:49 2020 Return-Path: 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 D5E5F3A0AA9 for ; Mon, 15 Jun 2020 00:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 XEyNL6KooEtr for ; Mon, 15 Jun 2020 00:57:45 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 274ED3A0911 for ; Mon, 15 Jun 2020 00:57:45 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id i27so17955721ljb.12 for ; Mon, 15 Jun 2020 00:57:45 -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 :content-transfer-encoding:thread-index:content-language; bh=HIfM4xZkLv5BTDBAczA55OkJAcXcL5jMW0Gpxt9qGU4=; b=lXmAxrr0h4+t79yfrlQzX0FqPCL6bsx4WT2cCmcm7SUzu8a2r9jH+8kKbPf5PyN/J7 jJTXuwTFmTzlYDHp7EiGrVfu+wiP4PkHdCqtefeJtLTTJvNRnjM1j0MogZfthwZZYMjM g7g1EorBjjJMiJp9sBxwWokQLKWlnbrCgkwj+OnSoI5qUy6VDHnthretcLoCDTEd2XOo YWdZa29JolWsSm1tiUcyi5DoIbKUBQj3cQ88C2UQWpqAnAANNX82LOZ4DKpg5/KvR0RT sBHw+guHP64m6/j/yIyWbGqTmiTDqk2+1xiPB/UfoEl1Gf2HNQL3ezqx3VmptlqJgzgL JBgA== 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:content-transfer-encoding:thread-index :content-language; bh=HIfM4xZkLv5BTDBAczA55OkJAcXcL5jMW0Gpxt9qGU4=; b=BIMe+DL5Q5gVXJe+qJW+JdGhYl5ZjGoheorBTovJ69xj3OCUWEKJzUMgBJZBwgWy2y zXnZ/Hax6mep99pEc5anCFs7f+SstK8GII5FXFIVSokuFraTuyjmOw+Fvgs1DSIRrKqN V3Fk6+bTs58xpu667DyLFo2ONXMB3amPXTn0AvNLyZwh5Mk5gw0f4CWpIBScXGQWFvcA RGgwW8RMgRJgnyi4zeppX6vdgU/b2ykn1sKRYA+6qWQCJLlwGSMIGqQC+IWxb1c1aLPf cdtjtiqOxWQ2TYCAkzHrUYCeEd7km6C7G4QndXed8AVpwKglaVOn8FY5jgEJODMlJUVt RlTA== X-Gm-Message-State: AOAM5309rqdOFMg8g3PMZXAxvJgJd9mJ7/bINT3YK6LydpoH7XY565es Qq/IovnZyC+F7OeQpKtYttBBoYeS X-Google-Smtp-Source: ABdhPJwUe6Fgxj8/niP6LU7rWubB2lxtkC7sPnJfRw9SaVYIpgLIaeR2baw3AUMF7bh9dinICPvaKA== X-Received: by 2002:a2e:c49:: with SMTP id o9mr12438079ljd.428.1592207862735; Mon, 15 Jun 2020 00:57:42 -0700 (PDT) Received: from buildpc ([82.138.51.3]) by smtp.gmail.com with ESMTPSA id g24sm5193031lfh.90.2020.06.15.00.57.41 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jun 2020 00:57:42 -0700 (PDT) From: "Valery Smyslov" To: References: <159220757484.32119.17958275380428394021@ietfa.amsl.com> In-Reply-To: <159220757484.32119.17958275380428394021@ietfa.amsl.com> Date: Mon, 15 Jun 2020 10:57:42 +0300 Message-ID: <030b01d642ea$a64b46e0$f2e1d4a0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKb+ieMjCEtDyiE9dIBpSyK+Czaj6dN4ADw Content-Language: ru Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-intermediate-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2020 07:57:47 -0000 Hi, a new version of INTERMEDITAE exchange draft is posted to prevent its expiration. Few nits in the diagrams are fixed (too long lines, unnecessary brackets, misplaces ellipses etc.). No changes to the protocol itself. Regards, Valery. > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. > > Title : Intermediate Exchange in the IKEv2 Protocol > Author : Valery Smyslov > Filename : draft-ietf-ipsecme-ikev2-intermediate-04.txt > Pages : 11 > Date : 2020-06-15 > > Abstract: > 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 messages, but cannot be used in the initial IKEv2 exchange. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-intermediate/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-intermediate-04 > https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-intermediate-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-intermediate-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Jun 15 05:48:35 2020 Return-Path: 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 EC29B3A0D55 for ; Mon, 15 Jun 2020 05:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=YLj8VYnR; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=q6BfZVUv 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 pcF_hxNKxjAF for ; Mon, 15 Jun 2020 05:48:31 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8CE33A0D54 for ; Mon, 15 Jun 2020 05:48:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25484; q=dns/txt; s=iport; t=1592225310; x=1593434910; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=xcfAYW9oO3net/y1xKoXYwSAgwx9BYkq23dm0BLUdxY=; b=YLj8VYnRPbuD2VDYCHJcY6Year7AZ5z2mj0fq0opsKCoKXM21y4RftjD on15bxxHVLyi8n3GS45ZutZ8gRrJ+VeUwWk3v18XcBnTWDePAl50eMjYo P3dAZxbHGumApaVFDT37gmIWVLR6DWgdgcem/Vu6oRo1++KaAeMy+7v+B k=; IronPort-PHdr: =?us-ascii?q?9a23=3ATBkBoxLJih+Jd+V62tmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeGv6k/gFrAR46d6v9YhazRqa+zEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsuta1jbuHb07DMOFF?= =?us-ascii?q?P4LwUmbujwE5TZ2sKw0e368pbPYgJO0Ty6Z746LBi/oQjL8McMho43IacqwR?= =?us-ascii?q?yPqXxNKOk=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A8CABFbede/4UNJK1mHQEBAQEJARI?= =?us-ascii?q?BBQUBQIFKgSMvUQdvWC8sCodgA409mFKBQoEQA1ULAQEBDAEBLQIEAQGERAK?= =?us-ascii?q?CLwIkOBMCAwEBCwEBBQEBAQIBBgRthVsMhXIBAQEBAxILEBMBASwMDwIBCBE?= =?us-ascii?q?EAQEZCAcHMhQJCAEBBAESCA0ECYMFgX5NAy4BqRACgTmIYXSBNIMBAQEFhS4?= =?us-ascii?q?Ygg4JgTiCZIcbgksagUE/gVSCTT6CXASBKAESAQkaNBmCeIItjnCJaiaKe5B?= =?us-ascii?q?GCoJZjl2KXp5nkReaJoQHAgQCBAUCDgEBBYFqImZwcBU7gmlQFwINjh6DcYp?= =?us-ascii?q?WdAI1AgYIAQEDCXyNVCQJgQYBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.73,514,1583193600"; d="scan'208,217";a="513732215" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Jun 2020 12:48:28 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 05FCmSMD007675 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 15 Jun 2020 12:48:28 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 15 Jun 2020 07:48:27 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 15 Jun 2020 08:48:26 -0400 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 15 Jun 2020 07:48:26 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bPeZ8R7LMOOAt/K3FrvSqENDMokDxKox780BTjzHB4r+B0wI758/qAX1oZE11c2s8vE+C2CeC5lDXYj7OubvnEy9eoq12J94LcYkCkiTz1lVwWrDOzrqn3eAgfMbqNQqGr2zO6kYB3SxecrHfC/oJHoQiOZXgZJzk2+M0Pl+UciIP7BEbTbglbRj2h21M6J6sAW013gFrZ+uAbOe6Z5bDK+IcsaUqq8eKPYLmFN8S3LHq22GFKAspgZdO4ABnnk3S5T8hoUCZVMrgDiGBgLLR6NiyMwHl6thqSkOTyUkjx885ajA69836Hl6EonEL2U2rsx0QFVdBSmlTjB5kJodWw== 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=GZymC6iP0VigBn+vGPd8NpeBiHu14wf/tNVnS3HOlCc=; b=FCNQeyxBXaZHa3i2djJTQVYw9mRaw7gWHZxjM1hFTdI6HF5Z9tR+LvcKYcbXkz0rUw7tmgMZmNVhkP/Zet5xNzIGlkvIwHRmub4KwZBpYWIxU4fXDC9q8cvTZU0xQQ2HAnMHaPDat4ZGsYXa+/Of8/ga5GdUiTCksDqSvoTtKBNz3sSSSE5DzH4tAWSHY1ORvXLdXmWwGQHk1b0j/vnOxBasQyWkQB8h6cJ8A+wOeyKDl0fdjYyNqnp7sRqdkj8DvCxpN61i2y2pKx4zmYKAngyOxcgap21TWGZ6TZVLJKguQv44mUFqnPPYcuqTyigEoKWGl4KnUpCf3fuNqBNSTw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GZymC6iP0VigBn+vGPd8NpeBiHu14wf/tNVnS3HOlCc=; b=q6BfZVUvZQ2g8qJCH1WGZybqSOSmMOBxLjAmjbP4nqhkxYae/R8g6gYgZnX6ptk1pM4JMG5baAs1gmqGePkDrYhar75P3LIPfQ4dVGw+vQQZ2uhBT9laFF0N9lQVHYscECtH4wf+ET3Bci71Ep0N15VRb0gkTq6GO6lO6Jp0dzM= Received: from BN7PR11MB2641.namprd11.prod.outlook.com (2603:10b6:406:b1::25) by BN6PR11MB1652.namprd11.prod.outlook.com (2603:10b6:405:10::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.23; Mon, 15 Jun 2020 12:48:23 +0000 Received: from BN7PR11MB2641.namprd11.prod.outlook.com ([fe80::35bd:ecae:1e28:58f5]) by BN7PR11MB2641.namprd11.prod.outlook.com ([fe80::35bd:ecae:1e28:58f5%5]) with mapi id 15.20.3088.029; Mon, 15 Jun 2020 12:48:23 +0000 From: "Scott Fluhrer (sfluhrer)" To: "Scott Fluhrer (sfluhrer)" , "ipsec@ietf.org" Thread-Topic: Last minute change to draft-ietf-ipsecme-qr-ikev2 Thread-Index: AdY7b0YZDPRKeamGTBelnS42EluRIwCIhypQAKZrv1AAugLhIA== Date: Mon, 15 Jun 2020 12:48:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.76] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 494f0c0e-ec34-4ca5-588f-08d8112a639b x-ms-traffictypediagnostic: BN6PR11MB1652: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 04359FAD81 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 9HfDSSOtPDwT5j0DAo8z8UVaaEw4GolRnreWj01bNWGCnD7rUHvfcVJ0vBqidTeTTHk7wmOf4pWlxiMpjFDKlPt7hssbiD8GoqzF98xgVq2n1G0LYmSHRMSTzINkrDvdxsrw+yp48pgY9xLDrZj2J1TnXHXiX3OTEpu2qMwfMFmb9y91w/1bXHRHTgbdPSuZMYNtwVCtUTIGB0pYBK0xaUXBJk67HOYZYkKd9kFztvK33g93p5ARc+j5wnndlwY+x49eQHalGFUw5E2BTggYUgZXB83n5mYwX8/8W46hprW1zvyQShWLeUuQpMyaepV9NZDAtaK5FKSlBJIVXVtmVQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2641.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(39860400002)(136003)(366004)(376002)(346002)(316002)(186003)(33656002)(6506007)(110136005)(66946007)(52536014)(76116006)(66446008)(66556008)(66476007)(53546011)(64756008)(478600001)(8936002)(7696005)(8676002)(83380400001)(26005)(86362001)(2906002)(71200400001)(55016002)(5660300002)(9686003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: Wo/C1Trm0AQCXgHDGbhFae8AOS1qqwAVu/jH2ch5b69ymz+3HBM7XUTLhS0G3hTtW0aOoR5/OYBbmJ2n+S/Re3pUSzg2NkkvC6Qn0sbHUNGwpjMIHSBXr7SpzP3DwJk89Q2MVvJi4BP4jK3PExac036Z+vDiC5xgF6p/M5p6O1gW85o+Gd9gX1+0fS0YlmzLkaQsAXxtOcM5hMtJx6r661ZygMcD12qAoSGqQEdhaxULRI+gnIc89EDixadbPa82uGhl9gxZeMefBuImoB7Y39nS/tGFkue+P6j3qvIiqI13Wuk8TfyKQ93VKYHmepf8M7cZ02W3sqKEGJsiIx976YHwvf9ckt0sdFzgzEb1/akTWjrZieLyWFbkfMa3VXjNQ+7DXlUJuWaaNGr18rnORR3umQi1NwgmMUSPD684jS1tyqYnUx0T5FgqIxMgF1lukNCFHdUvKkQAE+y8YgcP1mmtMdsqFOGWwjDQfB3IeqE= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN7PR11MB264133951A5BD65CA102FF45C19C0BN7PR11MB2641namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 494f0c0e-ec34-4ca5-588f-08d8112a639b X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jun 2020 12:48:22.9369 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /ruEzF/5+7ZZNdfkyHpFd0kpAX+MFOdQQYozvGUNZ212dp7G1C24utUI+cfsiK7nFFnfbpHTWMhrKZK+M9mgNw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1652 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: Subject: Re: [IPsec] Last minute change to draft-ietf-ipsecme-qr-ikev2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2020 12:48:33 -0000 --_000_BN7PR11MB264133951A5BD65CA102FF45C19C0BN7PR11MB2641namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Last call; does anyone have any objections if I send these changes to the R= FC editors as a final modification? From: Scott Fluhrer (sfluhrer) Sent: Thursday, June 11, 2020 4:05 PM To: Scott Fluhrer (sfluhrer) ; ipsec@ietf.org Subject: RE: Last minute change to draft-ietf-ipsecme-qr-ikev2 Does anyone else have comments about this text (either for or against)? Pa= ul, Tero, you had previously chimed in; do either of you something to say? From: IPsec > On Beha= lf Of Scott Fluhrer (sfluhrer) Sent: Monday, June 08, 2020 11:06 AM To: ipsec@ietf.org Subject: Re: [IPsec] Last minute change to draft-ietf-ipsecme-qr-ikev2 Tero had this comment (which didn't make it onto this mailing list): Btw, there is similar text in RFC7296 (base IKEv2) saying following: When using pre-shared keys, a critical consideration is how to assure the randomness of these secrets. The strongest practice is to ensure that any pre-shared key contain as much randomness as the strongest key being negotiated. Deriving a shared secret from a password, name, or other low-entropy source is not secure. These sources are subject to dictionary and social-engineering attacks, among others. so one option would also point to IKEv2 RFC and say that same restrictions = for not using low-entropy key that apply for pre-shared keys there applies = also PPK. That comment strikes me as having a good point; the pre-shared keys in IKE = are subject to exactly the same dictionary attack that a PPK would have, an= d so the same advice would apply to both. On the other hand, asking the re= ader to dig through a 142 page document for the relevant advice, or even sc= an through 3 pages of the security considerations would appear to be less f= riendly than we could be; in addition, advice for PPKs also need to conside= r Quantum Computers (which were not a consideration with IKE pre-shared key= s). How about this text (which integrates suggestions both from the security co= nsiderations of both RFC7296 and the PPK text, while trying to not sound li= ke Frankentext [1]. A critical consideration is how to assure the randomness of this post-quantum preshared key. Quantum computers are able to perform Grover's algorithm [GROVER]; that effectively halves the size of a symmetric key. In addition, an adversary, even with a conventional computer, can perform a dictionary search over plausible post-quantum preshared key values. The strongest practice is to ensure that any post-quantum preshared key contains at least 256 bits of entropy, this will provide 128 bits of post-quantum security, while providing security against conventional dictionary attacks. That provides security equivalent to Level 5 as defined in the NIST PQ Project Call For Proposals [NISTPQCFP]. Deriving a postquantum preshared key from a password, name, or other low-entropy source is not secure because of these known attacks. The highlighted sections is text that is new to the draft; this would repla= ce the first paragraph of the Security Considerations section. And, I would agree with Valery; I also would prefer to avoid putting number= s that sound concrete; especially on something that is hard to measure (and= "amount of entropy" is notoriously hard to measure - you can measure lengt= h, but that doesn't actually mean "guessability", which is what we're tryin= g to get at). [1]: For those readers who might not be familiar with English Literation or= pop culture, there is a classic English novel "Frankenstein", when a scien= tist (Dr Frankenstein) patches together parts from several corpses, and bri= ngs it to life (of course, it didn't go well); in later references to this = original novel, the stitching of the several parts is obvious. The allusio= n "Frankentext" suggests parts of several works being clumsily stitched tog= ether. It is typically good advice to avoid cultural references when talki= ng on an international mailing list; I just couldn't help myself this time.= .. From: Scott Fluhrer (sfluhrer) Sent: Friday, June 05, 2020 3:41 PM To: ipsec@ietf.org Subject: Last minute change to draft-ietf-ipsecme-qr-ikev2 The draft "Mixing Preshared Keys in IKEv2 for Post-quantum Security" was wi= nding through the AUTH48 process, when at the last minute, I received an em= ail from a researcher who thought they found a problem with low entropy PPK= s (the preshared keys that the draft uses). While it turned out that what = the found really wasn't a problem, such low entropy PPKs are a problem in g= eneral. To address this, I suggested to the RFC editors that we modify the first pa= ragraph of the security considerations from: Original text: Quantum computers are able to perform Grover's algorithm [GROVER]; that effectively halves the size of a symmetric key. Because of this, the user SHOULD ensure that the post-quantum preshared key used has at least 256 bits of entropy, in order to provide 128 bits of post-quantum security. That provides security equivalent to Level 5 as defined in the NIST PQ Project Call For Proposals [NISTPQCFP]. Modified text: Quantum computers are able to perform Grover's algorithm [GROVER]; that effectively halves the size of a symmetric key. Because of this, the user SHOULD ensure that the post-quantum preshared key used has at least 256 bits of entropy, in order to provide 128 bits of post-quantum security. That provides security equivalent to Level 5 as defined in the NIST PQ Project Call For Proposals [NISTPQCFP]. An attacker who impersonates the server is able to validate guesses to the PPK. Because of this, low entropy PPK values MUST NOT be used. Additional text high-lighted. Because of the lateness of this change, Ben Kaduk (the area director) asked= me to check with the list to make sure everyone is OK with this addition. Comments? --_000_BN7PR11MB264133951A5BD65CA102FF45C19C0BN7PR11MB2641namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Last call; does anyone have any objections if I send= these changes to the RFC editors as a final modification?

 

From: Scott Fluhrer (sfluhrer) <sfluhrer= =3D40cisco.com@dmarc.ietf.org>
Sent: Thursday, June 11, 2020 4:05 PM
To: Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com>; ipsec@ietf.= org
Subject: RE: Last minute change to draft-ietf-ipsecme-qr-ikev2<= /o:p>

 

Does anyone else have comments about this text (eith= er for or against)?  Paul, Tero, you had previously chimed in; do eith= er of you something to say?

 

From: IPsec <ipsec-bounces@ietf.org> On Behalf Of Scott Fluhrer (sfluhrer)
Sent: Monday, June 08, 2020 11:06 AM
To: ipsec@ietf.org
Subject: Re: [IPsec] Last minute change to draft-ietf-ipsecme-qr-ike= v2

 

Tero had this comment (which didn’t make it on= to this mailing list):

 

Btw, there is similar text in RFC7296 (base IKEv2= ) saying following:

 

   When using pre-shared keys, a critic= al consideration is how to assure

   the randomness of these secrets.&nbs= p; The strongest practice is to ensure

   that any pre-shared key contain as m= uch randomness as the strongest

   key being negotiated.  Deriving= a shared secret from a password,

   name, or other low-entropy source is= not secure.  These sources are

   subject to dictionary and social-eng= ineering attacks, among others.

 

so one option would also point to IKEv2 RFC and s= ay that same restrictions for not using low-entropy key that apply for pre-= shared keys there applies also PPK.

 

 

That comment strikes me as having a good point; t= he pre-shared keys in IKE are subject to exactly the same dictionary attack= that a PPK would have, and so the same advice would apply to both.  O= n the other hand, asking the reader to dig through a 142 page document for the relevant advice, or even scan thro= ugh 3 pages of the security considerations would appear to be less friendly= than we could be; in addition, advice for PPKs also need to consider Quant= um Computers (which were not a consideration with IKE pre-shared keys).

 

How about this text (which integrates suggestions= both from the security considerations of both RFC7296 and the PPK text, wh= ile trying to not sound like Frankentext [1].

 

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   A critical consideration is how to assure the randomness of this

<= b>   post-quantum preshared key.  Quantum computers are able to perform

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   Grover's algorithm [GROVER]; that effe= ctively halves the size of a

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   symmetric key.  In addition, an adversary, even with a conventional

<= b>   computer, can perform a dictionary = search over plausible post-quantum

<= b>   preshared key values.  The strongest practice is to ensure that

<= b>   any post-quantum preshared key cont= ains at least 256 bits of entropy,

<= b>   this will provide 128 bits of post-quantum securi= ty, while providing

<= b>   security against conventional dicti= onary attacks.  That provides

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   security equivalent to Level 5 as defi= ned in the NIST PQ Project Call

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   For Proposals [NISTPQCFP].  Deriving a postquantum preshared key fr= om

<= b>   a password, name, or other low-entr= opy source is not secure because

<= b>   of these known attacks.<= /span>

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5"> 

The highlighted sections is text that is new to t= he draft; this would replace the first paragraph of the Security Considerat= ions section.

 

And, I would agree with Valery; I also would pref= er to avoid putting numbers that sound concrete; especially on something th= at is hard to measure (and “amount of entropy” is notoriously h= ard to measure – you can measure length, but that doesn’t actually mean “guessability”, which is what we&#= 8217;re trying to get at).

 

 

[1]: For those readers who might not be familiar = with English Literation or pop culture, there is a classic English novel &#= 8220;Frankenstein”, when a scientist (Dr Frankenstein) patches togeth= er parts from several corpses, and brings it to life (of course, it didn’t go well); in later references to this ori= ginal novel, the stitching of the several parts is obvious.  The allus= ion “Frankentext” suggests parts of several works being clumsil= y stitched together.  It is typically good advice to avoid cultural references when talking on an international mailing list; I just = couldn’t help myself this time…

 

From: Scott Fluhrer (sfluhrer)
Sent: Friday, June 05, 2020 3:41 PM
To: ipsec@ietf.org
Subject: Last minute change to draft-ietf-ipsecme-qr-ikev2

 

The draft “Mixing Preshared Keys in IKEv2 for = Post-quantum Security” was winding through the AUTH48 process, when a= t the last minute, I received an email from a researcher who thought they f= ound a problem with low entropy PPKs (the preshared keys that the draft uses).  While it turned out that what the found r= eally wasn’t a problem, such low entropy PPKs are a problem in genera= l.

 

To address this, I suggested to the RFC editors that= we modify the first paragraph of the security considerations from:

 

Original text:

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   Quantum computers are able to perform = Grover's algorithm [GROVER];

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   that effectively halves the size of a = symmetric key.  Because of

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   this, the user SHOULD ensure that the = post-quantum preshared key used

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   has at least 256 bits of entropy, in o= rder to provide 128 bits of

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   post-quantum security.  That prov= ides security equivalent to Level 5

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   as defined in the NIST PQ Project Call= For Proposals [NISTPQCFP].

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5"> 

Modified text:

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   Quantum computers are able to perform = Grover's algorithm [GROVER];

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   that effectively halves the size of a = symmetric key.  Because of

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   this, the user SHOULD ensure that the = post-quantum preshared key used

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   has at least 256 bits of entropy, in o= rder to provide 128 bits of

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   post-quantum security.  That prov= ides security equivalent to Level 5

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   as defined in the NIST PQ Project Call= For Proposals [NISTPQCFP].

<= span style=3D"font-size:10.5pt;font-family:"Courier New";color:bl= ack;background:#FFFDF5">   An attacker who impersonates the server is able to validate guesses to

<= b>   the PPK.  Because of this, low= entropy PPK values MUST NOT be used.

 

Additional text high-lighted.

 

Because of the lateness of this change, Ben Kaduk (t= he area director) asked me to check with the list to make sure everyone is = OK with this addition.

 

Comments?

--_000_BN7PR11MB264133951A5BD65CA102FF45C19C0BN7PR11MB2641namp_-- From nobody Wed Jun 17 06:49:02 2020 Return-Path: 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 6A1423A0809 for ; Wed, 17 Jun 2020 06:49:01 -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 OuI12NLq9iQs for ; Wed, 17 Jun 2020 06:48:59 -0700 (PDT) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02on2134.outbound.protection.outlook.com [40.107.89.134]) (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 7CCE53A077D for ; Wed, 17 Jun 2020 06:48:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UxZzDb06kXo6nIrfrfq5ye2swf0vmq0xJzehih576GIyUn3pOsu1TgD5rD1h8NwjPS6QhLmYqkolGfaP6CWt6nYupQGdGbIhfOePJ2IsyT6UOiF59zzks2BeY8Ae+zKoOUxhpao2jG0HkRlMyXolLJgPM8DM4b1yJMFCAemsZW5d2YNOekyICjwZlMp2yfFUEoRzf2I+KhDw7FhBXHL2PpLdZfc8t5G3dgTglfCL1Xgq04/EIO6oT1tu3HyuNiOdKsJ8IBLWfcaDRarTjXLE9DUWUNbOQ/3fdzlCAFfoEhId+ZVlBysb/LAtMuLM6iWzw0eyhD59lLybmuIec+7E2A== 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=r4haKjYmwg2BoTSWh1iDIzsck8/cJt9VAdNCdfVyLn4=; b=jDbuEIyPMeCNrEeRyYoZYjR/2N+uzRefXdopIzqp6KXkPTCZ0OuTsJv/pn8aKN30erK8FilbiW1shF4V0IyNxlXIurrrezS/BCOxdgDuDZBUDdqjlDl67CM8pESmpGfXFoNqvo0Lwa4voNWS801RWUQB9hY2NX0Tce3MBVkNLV2634s0fXyUFOfUa9qnxmOyMzn43DgnzipgbK2Byv6aJNOMwUUv1xX5m7VDOTkBMaWBfP9/1yS8Nob8bMQcIxcSMWInUYhcHU0G0nVttL6jftzhASpAAm77qG13XOYn2vYnQiD3LOddoMCGjm8k0jcAX0xy4zd3CHAKZRG3sb55Bg== 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=r4haKjYmwg2BoTSWh1iDIzsck8/cJt9VAdNCdfVyLn4=; b=K599ForQTbpgRMZpvQT+/KgTn1jmT+M0Xib/Fsai0KU5o8p66xqERBOzJIZ5zNhrJaYPHc4IufPydl+s7+1INDhBo/K7RDhTg43BDNi+72kVMIm8DkAmNcqkbDjuwn+CmUrCdZeFtjc8ZI3/fAY/+Ia7podOWN5sRpyuFOmmJ6Q= Received: from BY5PR09MB4755.namprd09.prod.outlook.com (2603:10b6:a03:24b::12) by BY5PR09MB4504.namprd09.prod.outlook.com (2603:10b6:a03:1c5::8) 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 13:48:55 +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 13:48:55 +0000 From: "Dang, Quynh H. (Fed)" To: ipsecme mailing list Thread-Topic: Maximum sizes of IKEv2 messages and UDP messages ? Thread-Index: AQHWRKwTbexJ5B/60kaRS2oRKSlgJg== Date: Wed, 17 Jun 2020 13:48:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; 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: 7987f4c2-07c6-4bd9-2913-08d812c52da8 x-ms-traffictypediagnostic: BY5PR09MB4504: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6108; x-forefront-prvs: 04371797A5 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 11lWSu0PFOp5GZs6Jws04abp+doawF0O9rXwHtPFwvqtoLbolfIUIv3CA3mOuNtcU+jzffYQExUdKfsYd0jQmtf5xlM4Z7LQ1HfCKWC5J/5ZDQlZr75bKz1oemnIKKhr2OlPQ3WVSWUMKXiWRl+rIs2nstg8p8PZgyZWJjM+VaaiPSI5Jqy0Oe+mVO4+xw115VxtbY6o2oPuIfS+BBMCEXsd4JaB9Zcx1pfX1b1ELHXSetE+Y006t5sPywEDZbkhsxE4Yv58DALMbczxhDnMg95LpDu9TVzl7Dz5tt1egh1tUTlQtHs8/4aJuwKKwuAMpH87bLMP1yTPNAVJ2zX/NA== 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:(376002)(136003)(366004)(396003)(39850400004)(346002)(7696005)(186003)(66446008)(8676002)(19627405001)(66946007)(4744005)(55016002)(66476007)(9686003)(15650500001)(6916009)(71200400001)(64756008)(66556008)(76116006)(91956017)(316002)(6506007)(5660300002)(26005)(52536014)(8936002)(33656002)(83380400001)(478600001)(86362001)(2906002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: KWm2FqIyD0B5weXVAeB1VW6WhOvQ0T2PUEBAHwuNnFf8J9boFM3OKciKk6+O6qY7FMALxCXMwUYcYePtxd+QvDI1BkjV+caPYCbKtcO8Ps+936jjJmKuwEsTD1kn5cFLqOuf9VwBWEWwRtCkza8ifEzGyusSsYfxQsuIHsFD/MwT1vOjh+paDDy8FCjEWkos9RCj3MQWAUoZau1k2PqmMqan7JbYXZeu49HDGyFNValyHPhmsCGHqakdScz8xKsS/y6k/H5sTqyqxDxfyW7/nsQRvylGWZpzLyv/4BfqI/FvjdzzZe6X4PBhHUPQcvJ5oTcv504BVZC3j0jUnudDSQsOrDyP7FfYr6Rbtvzl7aMbMni5iluhargrtgHmJ2Oy44klBrtrDXsRg3XOXSihtvmrzSo+YN3z3a0cSthVaFE8/g788YbaAfuMSGAU4yRTk5mv6Mjkl1ZrlRRhnFzWbVJdNUPs8/4Ehyuy6NhhdRU= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BY5PR09MB47550EF86C79AD4B009DACE2F39A0BY5PR09MB4755namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 7987f4c2-07c6-4bd9-2913-08d812c52da8 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2020 13:48:55.5553 (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: jITw2ApNSH9LQaLC7IoxKu9NdAPBZte8ZXIqsdiMaBLzuL1kUcMYZj4tPAaBxOhx X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR09MB4504 Archived-At: Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 13:49:02 -0000 --_000_BY5PR09MB47550EF86C79AD4B009DACE2F39A0BY5PR09MB4755namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi everyone, I am interested in knowing what are typical maximum sizes for IKEv2 message= s 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 lim= it. As you know some of the post quantum cryptographic candidates in our standa= rdization process have large or very large public key , signature and/or ci= phertext 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. --_000_BY5PR09MB47550EF86C79AD4B009DACE2F39A0BY5PR09MB4755namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi everyone,

I am interested in knowing what are typical maximum sizes for IKEv2 message= s 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 lim= it.

As you know some of the post quantum cryptographic candidates in our standa= rdization process have large or very large public key , signature and/or ci= phertext 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. 
--_000_BY5PR09MB47550EF86C79AD4B009DACE2F39A0BY5PR09MB4755namp_-- From nobody Wed Jun 17 06:58:06 2020 Return-Path: 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 D42DE3A081D for ; Wed, 17 Jun 2020 06:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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] 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 15yixPQZM7BK for ; Wed, 17 Jun 2020 06:58:02 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 1EF753A081B for ; Wed, 17 Jun 2020 06:57:59 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id c21so1361179lfb.3 for ; Wed, 17 Jun 2020 06:57:59 -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=h8lCJffNnuEgBLkm2TeIbOy2s3S9A13bfxgcYbrLXXY=; b=CjrutFh3QEsdQaCkKMRxZGeZ1SbSZK6ZkXUvD3zn60ImV5t9yvKpjv7a1rSNinoysh qVjT6o41kaabkuVJk1BaA0ie9xrqqF7kko+hFrf1wkEhvZwMguoasWrZcZIFxUlNUfIB fKZLFtbOHsbsxS1AjacWrAFlNZO7vbqHaPNL5uQfrtV0fL63xI6Vfnl1urv9wqkj17I5 vCm87NbG+NYn75sF7eNFEL86wv2ZaMSkJjqEMZxJjsUHxYAnmx3wy8kcHas6GCT8AEi4 998JA2g9kmP8huTbR/zO3OdQoO8qfD/Dov4AtE32zH7TmYp6DDftSiXChy18aF9u4FNr FxhA== 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=h8lCJffNnuEgBLkm2TeIbOy2s3S9A13bfxgcYbrLXXY=; b=ia78FQk7OMKwY2jsERzdBJnA2uqlD/WBe00cR8cgF2jebXt42Rtz4304AuVz1rBJvA VG7YoEeLRmBE2tECNx1ULyNMc2bwkGLjmjYsh0iMWOtnkqiHN8dnqI+Hj4h8xO5xB1IB iGvsMHPsNsQsJHYoyxaDjNJ01+isHe8a6CqrWC/yGA1H/wvaj7pgkZSU9N1hxHDaTHLo VZifL6sMk7u00dpKN4WWCMHBC7DlWkMrWN3wZLWqerMxpVGwT5RKTnZV25C7VwJRTsUK WwtZJri/gZ+fPozWGrmp2rzyx4CBcIM1g9keO5uERg75u441psE/d9REYS9HPkdF07yn Lmiw== X-Gm-Message-State: AOAM530Ikb4WrETos23D4Mbsf80eXhggr2Kts5mY7OpU8j4+yp8QOVVo BRjGhXtnlTRzBvTirG/MRWTyCF3i X-Google-Smtp-Source: ABdhPJwKIz5nUDQrLJzqhFudp2OrC/PIXYniXL4Rp0MSU8i8ot9gA1vKN5Y7W+/8ap6XJuJPdoStqw== X-Received: by 2002:a19:c194:: with SMTP id r142mr4627918lff.87.1592402276962; Wed, 17 Jun 2020 06:57:56 -0700 (PDT) Received: from buildpc ([82.138.51.3]) by smtp.gmail.com with ESMTPSA id s8sm5005540ljh.101.2020.06.17.06.57.55 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Jun 2020 06:57:56 -0700 (PDT) From: "Valery Smyslov" To: "'Dang, Quynh H. \(Fed\)'" , "'ipsecme mailing list'" References: In-Reply-To: Date: Wed, 17 Jun 2020 16:57:58 +0300 Message-ID: <059d01d644af$4f2c7ed0$ed857c70$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_059E_01D644C8.747B3D70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHCZ+QZYbN6OZwcSebby6LP6QErR6kEjYFA Content-Language: ru Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 13:58:04 -0000 This is a multipart message in MIME format. ------=_NextPart_000_059E_01D644C8.747B3D70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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. ------=_NextPart_000_059E_01D644C8.747B3D70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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. 

------=_NextPart_000_059E_01D644C8.747B3D70-- From nobody Wed Jun 17 06:58:31 2020 Return-Path: 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 3B9573A0848 for ; Wed, 17 Jun 2020 06:58:18 -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 b--CDEsvQUgw for ; Wed, 17 Jun 2020 06:58:16 -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 7B4873A0857 for ; Wed, 17 Jun 2020 06:58:16 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 49n6923DYDzMsW; Wed, 17 Jun 2020 15:58:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1592402294; bh=TGtbldtfBM/B3DexuNj6CpB/N4CTcrp4zCKrrea6Nn4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=g7ui0GZLuToAI8qM7NWVmxY0BKGCQIypna2RvywFvEOp9v9yN4vn9pmZVUz4oOQLO fFKqBL1p3l5Aj4AXipAxvmD+5ieK64nwKacRkxNX+JuF0bi1UvFxBctdTHpmNXNWG0 5r/Ak5HUcfhCRvB1pbXQKVpJ4Yz/3mHuas56T8WM= 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 f2fzV9QdNlKD; Wed, 17 Jun 2020 15:58:13 +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; Wed, 17 Jun 2020 15:58:13 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 0F0EE6029B9B; Wed, 17 Jun 2020 09:58:12 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0DDD8669F1; Wed, 17 Jun 2020 09:58:12 -0400 (EDT) Date: Wed, 17 Jun 2020 09:58:11 -0400 (EDT) From: Paul Wouters To: "Dang, Quynh H. (Fed)" cc: ipsecme mailing list In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 13:58:30 -0000 On Wed, 17 Jun 2020, Dang, Quynh H. (Fed) wrote: > 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. https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-intermediate Paul From nobody Wed Jun 17 09:36:58 2020 Return-Path: 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 ; 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 ; 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 ; 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)" To: Valery Smyslov , 'ipsecme mailing list' 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: References: , <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: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 16:36:56 -0000 --_000_BY5PR09MB4755E77A264964F3D73FB7FEF39A0BY5PR09MB4755namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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-i= etf-ipsecme-ikev2-intermediate-04 look good to me. It looks like if/when someone implements them and adds a large key and/or c= iphertext KEM, the maximum IKEv2 message size must be adjusted if the exist= ing 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 m= essage size (it is an implementation specific issue). Let's say after 10 or 15 years from now, the group trusts the security of s= ome PQ KEM and signature algorithms and would like to use them in normal IK= Ev2 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 signat= ure algorithm has a small signature and a small public key) which would wor= k well in a normal IKEv2's implementation ? I guess the impact is small generally because an IPsec tunnel normally stay= s up for a long time. Does my guess seem ok here ? Would there be some noticeable impact on a high-volume connections VPN serv= er ? Regards, Quynh. draft-ietf-ipsecme-ikev2-intermediate-04 - Intermediate Exchange in the IKE= v2 Protocol This documents defines a new exchange, called Intermediate Exchange, for th= e Internet Key Exchange protocol Version 2 (IKEv2). This exchange can be us= ed for transferring large amount of data in the process of IKEv2 Security A= ssociation (SA) establishment. Introducing Intermediate Exchange allows re-= using existing IKE Fragmentation mechanism, that helps to avoid IP fragment= ation of large IKE ... tools.ietf.org ________________________________ From: Valery Smyslov Sent: Wednesday, June 17, 2020 9:57 AM To: Dang, Quynh H. (Fed) ; 'ipsecme mailing list' 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 met= hods. Actually, it=92s 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 need= ed. Regards, Valery. From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Dang, Quynh H. (Fe= d) 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 message= s 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 lim= it. As you know some of the post quantum cryptographic candidates in our standa= rdization process have large or very large public key , signature and/or ci= phertext 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. --_000_BY5PR09MB4755E77A264964F3D73FB7FEF39A0BY5PR09MB4755namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Thank you Valery and thank you everyone who responded to me.


It looks like if/when someone implements them and adds a large key and/or c= iphertext KEM, the maximum IKEv2 message size must be adjusted if the exist= ing 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 s= ee any mentioning of the maximum IKEv2 message size (it is an implementatio= n specific issue). 

Let's say after 10 or 15 years from now, the group trusts the security of s= ome PQ KEM and signature algorithms and would like to use them in normal IK= Ev2 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 signat= ure algorithm has a small signature and a small public key) which would work well in a normal IKEv2's implemen= tation ? 

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

Would there be some noticeable impact on a high-volume connections VPN serv= er ?

Regards,
Quynh. 
This documents defines a new exchange, called Intermediate Exchange, for th= e Internet Key Exchange protocol Version 2 (IKEv2). This exchange can be us= ed for transferring large amount of data in the process of IKEv2 Security A= ssociation (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 <sm= yslov.ietf@gmail.com>
Sent: Wednesday, June 17, 2020 9:57 AM
To: Dang, Quynh H. (Fed) <quynh.dang@nist.gov>; 'ipsecme maili= ng list' <ipsec@ietf.org>
Subject: RE: [IPsec] Maximum sizes of IKEv2 messages and UDP message= s ?
 

Hi Qui= nh,

 =

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

It spe= cifically addresses your concern about large public keys of PQ KE methods.<= /span>

 =

Actual= ly, it=92s 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.

 =

Regard= s,

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 ?<= /span>

 

Hi everyone,

 

I am interested in knowing what are typic= al maximum sizes for IKEv2 messages and UDP messages in implementations.&nb= sp;

 

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

 

As you know some of the post quantum cryp= tographic candidates in our standardization process have large or very larg= e 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 appr= eciated.

 

Regards,

Quynh. 

--_000_BY5PR09MB4755E77A264964F3D73FB7FEF39A0BY5PR09MB4755namp_-- From nobody Wed Jun 17 10:04:23 2020 Return-Path: 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 C690D3A0AE1; Wed, 17 Jun 2020 10:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 53wakDD6rsLH; Wed, 17 Jun 2020 10:04:08 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6730F3A0ABE; Wed, 17 Jun 2020 10:04:08 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 2C44854843F; Wed, 17 Jun 2020 19:04:03 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 239D5440043; Wed, 17 Jun 2020 19:04:03 +0200 (CEST) Date: Wed, 17 Jun 2020 19:04:03 +0200 From: Toerless Eckert To: Yoav Nir Cc: Michael Richardson , "ipsec@ietf.org WG" , draft-ietf-anima-autonomic-control-plane@ietf.org Message-ID: <20200617170403.GA18378@faui48f.informatik.uni-erlangen.de> References: <20200224195013.GA3878@faui48f.informatik.uni-erlangen.de> <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> <23402.1582670650@localhost> <20200226000318.GJ39574@faui48f.informatik.uni-erlangen.de> <31896.1582680023@localhost> <8A7ABA50-0ACB-41A2-9AE5-4EE15DB86F3A@gmail.com> <27926.1582739768@localhost> <0E1FEB34-E329-4686-80CE-0DFE253409C2@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0E1FEB34-E329-4686-80CE-0DFE253409C2@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 17:04:22 -0000 Seems as if the reply to this sub-thread was overlooked, sorry. In the ACP, a node has multiple IPsec connection, each of which acts like a virtual link to another node and each of them will carry IPv6 packets with arbitrary IPv6 source and destination adresses. So the ideal, most compact option is: Tunnel Mode. ESP payload (Next Header) is IPv6 (41) TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) This is not IPinIP. IPinIP would be if the IPv6 packet inside the ESP encapsulation itself would have a next header field of 41 and and we would have another IPv6 packet there. I guess we could set the IP protocol selector to 41, but browsing through RFCs, i can not find a single example where this is done, instead all TSi examples use 0. Transport Mode: Payload = ESP Next Header is GRE (47) TSi = (47, 0-65535, Initiator-IPv6-LL-addr ... Initiator-ACP-LL-addr) TSr = (47, 0-65535, Responder-IPv6-LL-addr ... Responder-IPv6-LL-addr) These two choices are somewhat arbitrary, i am sure some vendor not following this draft will later come and complain that he prefers GRE in tunnel mode or IPinIP tunnel or transport mode, but those profiles can always easily be added through later RFCs if there is sufficient support by updating the ACP RFC and would work proprietarily between vendor devices anyhow even today. For now i think it is most interesting for ACP to have what is the most compact header (tunnel mode) and one alternative showing use of ttransport mode and hopefully useful to vendors with legacy gear that most often has GRE tunnel interfaces but not explicit IPsec interfaces. Here is the current tentative text, please yell if NOK: -- native: An ACP node that is supporting native IPsec MUST use IPsec in tunnel mode, negotiated via IKEv2, and with IPv6 payload (e.g., ESP Next Header of 41). It MUST use local and peer link-local IPv6 addresses for encapsulation. Manual keying MUST NOT be used, see . Traffic Selectors are: TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) IPsec tunnel mode is required because the ACP will route/forward packets received from any other ACP node across the ACP secure channels, and not only its own generated ACP packets. With IPsec transport mode (and no additional encapsulation header in the ESP payload), it would only be possible to send packets originated by the ACP node itself because the IPv6 address of the ESP must be the same as of the outer IPv6 header. -- GRE: The requirements for ESP/IPsec/IKEv2 with GRE are the same as for native IPsec (see ) except that IPsec transport mode and next protocol GRE (47) are to be negotiated. Tunnel mode is not required because of GRE. Traffic Selectors are: TSi = (47, 0-65535, Initiator-IPv6-LL-addr ... Initiator-ACP-LL-addr) TSr = (47, 0-65535, Responder-IPv6-LL-addr ... Responder-IPv6-LL-addr) If IKEv2 initiator and responder support IPsec over GRE, it has to be preferred over native IPsec. The ACP IPv6 traffic has to be carried across GRE according to . -- Cheers Toerless On Thu, Feb 27, 2020 at 12:41:55AM +0200, Yoav Nir wrote: > > > > On 26 Feb 2020, at 19:56, Michael Richardson wrote: > > > > > > Yoav Nir wrote: > >> The draft says ???IPsec tunnel mode is required ???, so it???s not > >> transport. What goes in the TS payloads? > > > > TSi=HostA-LL/128, TSr=HostB-LL/128, Protocol = GRE(47) or IPIP(41) > > If that???s the intention, I don???t see why this should be tunnel mode. Both GRE and IPIP are tunnels, and they do not require ESP tunnel mode to add yet another IP header. > > Yoav From nobody Wed Jun 17 10:59:27 2020 Return-Path: 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 944D03A0AB0; Wed, 17 Jun 2020 10:59:25 -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 vARnPPJZ49sG; Wed, 17 Jun 2020 10:59:22 -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 C540B3A0AB6; Wed, 17 Jun 2020 10:59:22 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 49nCWD5YMHzMtv; Wed, 17 Jun 2020 19:59:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1592416760; bh=Bb/4E4QrEwx4PrgtMeIwxEMzPqglsd++d1iCUjbPnN8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=c0jGgDKd+bAiNqN569xKeSXSCvU7adsVPAtHqu9PdD5rYweyTagTAygubYCkrFMD4 mmB2UNke2iCKy9msiHkUVzY9SjVPD8H+Uq81o9qpmGmmgAC7NouvlcMBbjWS9qk0TW p1z1n0/lr9BEIDsUNUcbkvRJMcU/Firi0Pba4ugM= 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 LNHJGbzY_iDV; Wed, 17 Jun 2020 19:59:19 +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; Wed, 17 Jun 2020 19:59:19 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 75A5B6029B9B; Wed, 17 Jun 2020 13:59:18 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6AFE7CA134; Wed, 17 Jun 2020 13:59:18 -0400 (EDT) Date: Wed, 17 Jun 2020 13:59:18 -0400 (EDT) From: Paul Wouters To: Toerless Eckert cc: Yoav Nir , "ipsec@ietf.org WG" , Michael Richardson , draft-ietf-anima-autonomic-control-plane@ietf.org In-Reply-To: <20200617170403.GA18378@faui48f.informatik.uni-erlangen.de> Message-ID: References: <20200224195013.GA3878@faui48f.informatik.uni-erlangen.de> <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> <23402.1582670650@localhost> <20200226000318.GJ39574@faui48f.informatik.uni-erlangen.de> <31896.1582680023@localhost> <8A7ABA50-0ACB-41A2-9AE5-4EE15DB86F3A@gmail.com> <27926.1582739768@localhost> <0E1FEB34-E329-4686-80CE-0DFE253409C2@gmail.com> <20200617170403.GA18378@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 17:59:26 -0000 On Wed, 17 Jun 2020, Toerless Eckert wrote: > These two choices are somewhat arbitrary, i am sure some vendor > not following this draft will later come and complain that he > prefers GRE in tunnel mode or IPinIP tunnel or transport mode, Note that you cannot _require_ transport mode, as the IKEv2 protocol only allows you to _suggest_ transport mode. The peer can reject that suggestion and insist the connection uses tunnel mode. Paul From nobody Wed Jun 17 11:31:36 2020 Return-Path: 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 7A82F3A0AE1; Wed, 17 Jun 2020 11:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no 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 rNngdPZBkeYg; Wed, 17 Jun 2020 11:31:32 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F8333A0C9D; Wed, 17 Jun 2020 11:31:31 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 39208548068; Wed, 17 Jun 2020 20:31:27 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 2FCD1440043; Wed, 17 Jun 2020 20:31:27 +0200 (CEST) Date: Wed, 17 Jun 2020 20:31:27 +0200 From: Toerless Eckert To: Paul Wouters Cc: Yoav Nir , "ipsec@ietf.org WG" , Michael Richardson , draft-ietf-anima-autonomic-control-plane@ietf.org Message-ID: <20200617183127.GX16371@faui48f.informatik.uni-erlangen.de> References: <20200224195013.GA3878@faui48f.informatik.uni-erlangen.de> <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> <23402.1582670650@localhost> <20200226000318.GJ39574@faui48f.informatik.uni-erlangen.de> <31896.1582680023@localhost> <8A7ABA50-0ACB-41A2-9AE5-4EE15DB86F3A@gmail.com> <27926.1582739768@localhost> <0E1FEB34-E329-4686-80CE-0DFE253409C2@gmail.com> <20200617170403.GA18378@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 18:31:35 -0000 On Wed, Jun 17, 2020 at 01:59:18PM -0400, Paul Wouters wrote: > On Wed, 17 Jun 2020, Toerless Eckert wrote: > > > These two choices are somewhat arbitrary, i am sure some vendor > > not following this draft will later come and complain that he > > prefers GRE in tunnel mode or IPinIP tunnel or transport mode, > > Note that you cannot _require_ transport mode, as the IKEv2 > protocol only allows you to _suggest_ transport mode. The peer > can reject that suggestion and insist the connection uses > tunnel mode. But we do define a profile of use of IPsec that both sides need to support to ineroperate. So what specifically does prohibit a specificartion of such a profile to require to support and prefer one mode over the other ? This is a peer-to-peer communication solution, so no interop with devices not confirming to this spec. Cheers Toerless From nobody Wed Jun 17 13:01:33 2020 Return-Path: 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 8EC923A0DCA; Wed, 17 Jun 2020 13:01:31 -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 uXIAffpwVTby; Wed, 17 Jun 2020 13:01:30 -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 258513A0D8C; Wed, 17 Jun 2020 13:01:29 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 49nGD81LKlzMv7; Wed, 17 Jun 2020 22:01:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1592424088; bh=S1444SWQgnFy0XrXBROXU1HanpW5SKno/mmuuCKW/bs=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=iU8HaxZ25SAxWyVX0sQw8A+SKftHS0t3+EIX38Osn8C7pLg5Z87VFJYmA4NK47knV /JgqwXBtH/M6i072UKvtGP/mNxuE+nzIDrdJUFYIssfWJb15EemVN7ko4AETEO4HP0 en7TNRcpiOVR2kO0ozXSqJapkKrlEpKyCAfUasNw= 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 5vqpDqz9G_9l; Wed, 17 Jun 2020 22:01:27 +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; Wed, 17 Jun 2020 22:01:26 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id B34336029B9B; Wed, 17 Jun 2020 16:01:25 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A8FD6669F1; Wed, 17 Jun 2020 16:01:25 -0400 (EDT) Date: Wed, 17 Jun 2020 16:01:25 -0400 (EDT) From: Paul Wouters To: Toerless Eckert cc: Yoav Nir , "ipsec@ietf.org WG" , Michael Richardson , draft-ietf-anima-autonomic-control-plane@ietf.org In-Reply-To: <20200617183127.GX16371@faui48f.informatik.uni-erlangen.de> Message-ID: References: <20200224195013.GA3878@faui48f.informatik.uni-erlangen.de> <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> <23402.1582670650@localhost> <20200226000318.GJ39574@faui48f.informatik.uni-erlangen.de> <31896.1582680023@localhost> <8A7ABA50-0ACB-41A2-9AE5-4EE15DB86F3A@gmail.com> <27926.1582739768@localhost> <0E1FEB34-E329-4686-80CE-0DFE253409C2@gmail.com> <20200617170403.GA18378@faui48f.informatik.uni-erlangen.de> <20200617183127.GX16371@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 20:01:32 -0000 On Wed, 17 Jun 2020, Toerless Eckert wrote: >> Note that you cannot _require_ transport mode, as the IKEv2 >> protocol only allows you to _suggest_ transport mode. The peer >> can reject that suggestion and insist the connection uses >> tunnel mode. > > But we do define a profile of use of IPsec that both sides need to support > to ineroperate. So what specifically does prohibit a specificartion of such > a profile to require to support and prefer one mode over the other ? > > This is a peer-to-peer communication solution, so no interop > with devices not confirming to this spec. The profile is about protocol choices you agree to set in the profile. These choices are expected to be negotiated, eg encryption via AES_GCM, or encryption via CHACHA20_POLY1305. Your profile can say to pick one of these or both, because the protocol allows that. But the protocol does not provide the profiles a way to say "MUST do transport mode". The protocol only provides a way to say "Prefers transport mode". Technically, your profile could say to "request transport mode, and refuse the connection if the other end is unwilling to use transport mode", but that I would argue that would constitute a protocol modification which is not what a profile should do. Paul From nobody Wed Jun 17 13:56:29 2020 Return-Path: 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 7CAA63A0AEE; Wed, 17 Jun 2020 13:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.164 X-Spam-Level: X-Spam-Status: No, score=-0.164 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 t4i5Ud1UlslG; Wed, 17 Jun 2020 13:56:25 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 246983A0AEB; Wed, 17 Jun 2020 13:56:24 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 1E2BE548440; Wed, 17 Jun 2020 22:56:20 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 0B50C440043; Wed, 17 Jun 2020 22:56:20 +0200 (CEST) Date: Wed, 17 Jun 2020 22:56:20 +0200 From: Toerless Eckert To: Paul Wouters Cc: Yoav Nir , "ipsec@ietf.org WG" , Michael Richardson , draft-ietf-anima-autonomic-control-plane@ietf.org Message-ID: <20200617205619.GC16371@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 20:56:28 -0000 Thank, Paul Given how you are focussing on this aspect, can i assume that you are happy with the everything else in the suggested text ? Wrt to tunnel vs. transport mode: If you can, please propose specific text that would improve the quality of the doc wrt. to your point. I can only observe: a) I have not found the word "profile" in neither rfc4301 nor rfc5996, so i have no basis from which to argue what could or could not be called permissible for a "profile" b) I have not seen MUST support transport and MUST support tunnel mode, so being "incapable" of either option will lead to closing the connection, and those implementatoins are i think compliant with the IPsec/IKEv2 RFCs. b) All router implementations i know that can do tunnel and transport mode allow you to configure which option specifically to use and they too will close a connection is there is a mismatch. One could call that configuration "unwilling". ACP draft does not even have a notion of "unwilling", just "incapable". Cheers Toerless Every router allows you to configure whether an On Wed, Jun 17, 2020 at 04:01:25PM -0400, Paul Wouters wrote: > On Wed, 17 Jun 2020, Toerless Eckert wrote: > > > > Note that you cannot _require_ transport mode, as the IKEv2 > > > protocol only allows you to _suggest_ transport mode. The peer > > > can reject that suggestion and insist the connection uses > > > tunnel mode. > > > > But we do define a profile of use of IPsec that both sides need to support > > to ineroperate. So what specifically does prohibit a specificartion of such > > a profile to require to support and prefer one mode over the other ? > > > > This is a peer-to-peer communication solution, so no interop > > with devices not confirming to this spec. > > The profile is about protocol choices you agree to set in the > profile. These choices are expected to be negotiated, eg encryption via > AES_GCM, or encryption via CHACHA20_POLY1305. Your profile can say to > pick one of these or both, because the protocol allows that. > > But the protocol does not provide the profiles a way to say "MUST > do transport mode". The protocol only provides a way to say "Prefers > transport mode". > > Technically, your profile could say to "request transport mode, and > refuse the connection if the other end is unwilling to use transport > mode", but that I would argue that would constitute a protocol > modification which is not what a profile should do. > > Paul -- --- tte@cs.fau.de From nobody Wed Jun 17 14:08:00 2020 Return-Path: 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 EC5733A0B68; Wed, 17 Jun 2020 14:07:58 -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 TDg9O1aGCDJs; Wed, 17 Jun 2020 14:07:54 -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 A46C73A0AE6; Wed, 17 Jun 2020 14:07:53 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 49nHhl5f5SzMvB; Wed, 17 Jun 2020 23:07:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1592428071; bh=VMB3EqoepxioANTK3FyrULw7ndGMT9cRGGbJS+fOZfk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=KHqXgRo+HIzQ/UJGWkgovyzWOHvrrU++O+CPc/W5s/D6eH9soZ/LziQ3P+9ADpvJ+ 9kqr1+NWuRVgMpgtMLsF3RA7hSjfCtAiOvohFatmuzXHJLU3t6G0y/U/uQDCznKU+y /Noi3WlfY8rBSUnNGOiShyQlhHYi/s95GdkcDjMM= 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 htXXOZ9f4P5O; Wed, 17 Jun 2020 23:07:50 +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; Wed, 17 Jun 2020 23:07:50 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id E84826029B9B; Wed, 17 Jun 2020 17:07:48 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id DE089CA134; Wed, 17 Jun 2020 17:07:48 -0400 (EDT) Date: Wed, 17 Jun 2020 17:07:48 -0400 (EDT) From: Paul Wouters To: Toerless Eckert cc: Yoav Nir , "ipsec@ietf.org WG" , Michael Richardson , draft-ietf-anima-autonomic-control-plane@ietf.org In-Reply-To: <20200617205619.GC16371@faui48f.informatik.uni-erlangen.de> Message-ID: References: <20200617205619.GC16371@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 21:07:59 -0000 On Wed, 17 Jun 2020, Toerless Eckert wrote: > Given how you are focussing on this aspect, > can i assume that you are happy with the everything > else in the suggested text ? I don't know yet. I have to re-read the last draft version. > Wrt to tunnel vs. transport mode: > > If you can, please propose specific text that would improve > the quality of the doc wrt. to your point. > > I can only observe: > > a) I have not found the word "profile" in neither rfc4301 > nor rfc5996, so i have no basis from which to argue what could > or could not be called permissible for a "profile" I don't think we have an official IETF definition of a profile, but it usually means a collection of protocol parameters that are normally negotiated. For an example IPsec profile, see: https://www.rfc-editor.org/rfc/rfc6380.html Another more recent one is the draft for the updated CNDSA profile: https://tools.ietf.org/html/draft-corcoran-cnsa-ipsec-profile-00 > b) I have not seen MUST support transport and MUST support > tunnel mode, so being "incapable" of either option will > lead to closing the connection, and those implementatoins > are i think compliant with the IPsec/IKEv2 RFCs. Tunnel Mode is Mandatory To Implement. Transpode Mode is not. > b) All router implementations i know that can do tunnel > and transport mode allow you to configure which option > specifically to use and they too will close a connection > is there is a mismatch. One could call that configuration > "unwilling". Yes. In IKEv1, one was allowed to require Tunnel OR Transport mode, but for IKEv2 it was a conscious decision to make transport mode something a responder could refuse, without breaking the IPsec connection. This was done specifically to move most scenarios (especially over the internet, especially when NAT is involved) to Tunnel Mode. Transport Mode can be used but really should only be used if there is no NAT. And those reasons are also why I now bring this up. I want to avoid a new RFC that requires Transport Mode. It is fine to recommend it, as long as the responder is still allowed to refuse this, and be ensured that tunnel mode will be used instead. A connection MUST NOT hard fail on not getting Transport Mode. > ACP draft does not even have a notion of "unwilling", > just "incapable". My comments were triggered based on the texts in this email thread. As I said, I still need to reread the latest draft version. Paul From nobody Wed Jun 17 15:19:26 2020 Return-Path: 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 A12E23A0816; Wed, 17 Jun 2020 15:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 EAXB0vyeBwxo; Wed, 17 Jun 2020 15:19:23 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6F853A07CA; Wed, 17 Jun 2020 15:19:22 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 7AB86548441; Thu, 18 Jun 2020 00:19:17 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 73D15440043; Thu, 18 Jun 2020 00:19:17 +0200 (CEST) Date: Thu, 18 Jun 2020 00:19:17 +0200 From: Toerless Eckert To: Paul Wouters Cc: Yoav Nir , "ipsec@ietf.org WG" , Michael Richardson , draft-ietf-anima-autonomic-control-plane@ietf.org Message-ID: <20200617221917.GE16371@faui48f.informatik.uni-erlangen.de> References: <20200617205619.GC16371@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 22:19:26 -0000 On Wed, Jun 17, 2020 at 05:07:48PM -0400, Paul Wouters wrote: > On Wed, 17 Jun 2020, Toerless Eckert wrote: > > > Given how you are focussing on this aspect, > > can i assume that you are happy with the everything > > else in the suggested text ? > > I don't know yet. I have to re-read the last draft version. Just about the text i sent today on this thread. Still finalizing the -25 version of the actual draft. > > Wrt to tunnel vs. transport mode: > > > > If you can, please propose specific text that would improve > > the quality of the doc wrt. to your point. > > > > I can only observe: > > > > a) I have not found the word "profile" in neither rfc4301 > > nor rfc5996, so i have no basis from which to argue what could > > or could not be called permissible for a "profile" > > I don't think we have an official IETF definition of a profile, but it > usually means a collection of protocol parameters that are normally > negotiated. For an example IPsec profile, see: > > https://www.rfc-editor.org/rfc/rfc6380.html > > Another more recent one is the draft for the updated CNDSA profile: > > https://tools.ietf.org/html/draft-corcoran-cnsa-ipsec-profile-00 > > > b) I have not seen MUST support transport and MUST support > > tunnel mode, so being "incapable" of either option will > > lead to closing the connection, and those implementatoins > > are i think compliant with the IPsec/IKEv2 RFCs. > > Tunnel Mode is Mandatory To Implement. Transpode Mode is not. > > > b) All router implementations i know that can do tunnel > > and transport mode allow you to configure which option > > specifically to use and they too will close a connection > > is there is a mismatch. One could call that configuration > > "unwilling". > > Yes. In IKEv1, one was allowed to require Tunnel OR Transport > mode, but for IKEv2 it was a conscious decision to make > transport mode something a responder could refuse, without > breaking the IPsec connection. This was done specifically to > move most scenarios (especially over the internet, especially > when NAT is involved) to Tunnel Mode. Transport Mode can be > used but really should only be used if there is no NAT. The ACP tunnels are across link-local scope IPv6 addresses inside a LAN. Hence no issue. And for manual configured tunnel there is the GRE tunnel option. > And those reasons are also why I now bring this up. I want to > avoid a new RFC that requires Transport Mode. It is fine to > recommend it, as long as the responder is still allowed to > refuse this, and be ensured that tunnel mode will be used instead. > A connection MUST NOT hard fail on not getting Transport Mode. Where does in say in RFC7296 that you MUST implement tunnel mode and SHOULD/MAY implement transport mode ? RFC7296: | The USE_TRANSPORT_MODE notification MAY be included in a request | message that also includes an SA payload requesting a Child SA. It | requests that the Child SA use transport mode rather than tunnel mode | for the SA created. If the request is accepted, the response MUST | also include a notification of type USE_TRANSPORT_MODE. If the | responder declines the request, the Child SA will be established in | tunnel mode. If this is unacceptable to the initiator, the initiator | MUST delete the SA. The last two sentences read to me as if it is fine to only support transport but not tunnel mode, at least for the initiator: closing the connection ("deleting SA") if the initiator is only willing to do tansport mode, but not tunnel mode. What do you read from that ? > > ACP draft does not even have a notion of "unwilling", > > just "incapable". > > My comments were triggered based on the texts in this email thread. > As I said, I still need to reread the latest draft version. Sure, it was just clarification, but logically its hard to argue protocol violation based on attempting to distinguish unwilling and incapable. Sounds like a good court soap opera: DA: "Sir.IKEv2, Where you incapable or unwilling" ? IKEv2: "Incapable, it's not my fault" ! DA: "But i see your source code which makes you capable". IKEv2: "But the operator disabled it" DA: "You should not listen to what the operator says, you are an autonomous system" ;-)) But seriously: Whats the technical reasoning ? Just be sure to have an MTI ? Clearly for the use-case of automatic ACP secure channel, the transport mode option is the one with least packet header / MTU loss overhead. In 6.7.5 are the actual requirments and it does say for the ACP baseline profile "MUST transport", "MAY GRE". Give or take disagremement about whats technically best (which we should resolve), lets assume we do agree the technical goal is correct, if there really is clear text in IKEv2 thats violated (see above ask), we could still add a one line section making this an update to IKEv2 RFC for the specific case of automatic ACP link-local tunnels. I just find that unnecessary based on a) not finding the IKEv2 RFC requirements text, b) knowing how it is common implementation practice to choose an option like ACP is asking for. Cheers Toerless > Paul From nobody Wed Jun 17 17:36:24 2020 Return-Path: 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 05E203A0828; Wed, 17 Jun 2020 17:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 p2G7EWj04RnJ; Wed, 17 Jun 2020 17:36:21 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68C073A0829; Wed, 17 Jun 2020 17:36:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 96EA138A00; Wed, 17 Jun 2020 20:33:43 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id oLECADBDMpYS; Wed, 17 Jun 2020 20:33:40 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 0D74F389EB; Wed, 17 Jun 2020 20:33:40 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 74BBA10F9; Wed, 17 Jun 2020 20:36:15 -0400 (EDT) From: Michael Richardson To: Paul Wouters , Toerless Eckert , Yoav Nir , "ipsec\@ietf.org WG" , draft-ietf-anima-autonomic-control-plane@ietf.org In-Reply-To: References: <20200224195013.GA3878@faui48f.informatik.uni-erlangen.de> <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> <23402.1582670650@localhost> <20200226000318.GJ39574@faui48f.informatik.uni-erlangen.de> <31896.1582680023@localhost> <8A7ABA50-0ACB-41A2-9AE5-4EE15DB86F3A@gmail.com> <27926.1582739768@localhost> <0E1FEB34-E329-4686-80CE-0DFE253409C2@gmail.com> <20200617170403.GA18378@faui48f.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 00:36:23 -0000 --=-=-= Content-Type: text/plain Paul Wouters wrote: >> These two choices are somewhat arbitrary, i am sure some vendor >> not following this draft will later come and complain that he >> prefers GRE in tunnel mode or IPinIP tunnel or transport mode, > Note that you cannot _require_ transport mode, as the IKEv2 > protocol only allows you to _suggest_ transport mode. The peer > can reject that suggestion and insist the connection uses > tunnel mode. I don't agree. The IPsec WG does not mandate transport mode in order to be compliant to RFC4301 and RFC7296. If I ask for transport mode, and the other end does not agree to do it, I can certainly drop the negotiation. The ANIMA WG *can* write a stronger requirement, because that does not contradict RFC7296. We can't make something optional that IPsec requires, (such as ESP without authentication, or other dumb thing). -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl7qtv8ACgkQgItw+93Q 3WV6EQf/aedAnu9BQtKJKNxRBhANKI7cuu2RwfcvLo3hYAqHK6Oq5fQM3TuZtLAY M02rH4ITcxditYR7BQHjkOCeBngHwiJ73J2BZxJ6/gcm/yvPW305D4JAgWa4N1Tk gGRlLhK8nAq+Yh9zmi2qdem+jhln4bTdOHWd7H8tDY3FN6R+gx2ho/5UQ4yBKSwx Hkx6fBghW+M2PP+ltGf8VybAtgtSfzL+0tKh2PNxHc5bfLhJCAhauREX6Ovo/UyI X62vL6Of+flq8n6VftJSHs2rcOS1zw4E5nY57cNplqL/ffaSMpJyOehIaZ/hW+gZ taHWzrC3+BRdeinMiikryHN9FPYphw== =gyPI -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 17 17:37:41 2020 Return-Path: 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 E50F33A082C; Wed, 17 Jun 2020 17:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 v_0lQbIHCStc; Wed, 17 Jun 2020 17:37:38 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B0EE3A0838; Wed, 17 Jun 2020 17:37:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id C556538A00; Wed, 17 Jun 2020 20:35:01 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1msS2EbFn_Pr; Wed, 17 Jun 2020 20:35:01 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 35B51389EB; Wed, 17 Jun 2020 20:35:01 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9E8AC10F9; Wed, 17 Jun 2020 20:37:36 -0400 (EDT) From: Michael Richardson To: Paul Wouters , Toerless Eckert , Yoav Nir , "ipsec\@ietf.org WG" , draft-ietf-anima-autonomic-control-plane@ietf.org In-Reply-To: References: <20200224195013.GA3878@faui48f.informatik.uni-erlangen.de> <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> <23402.1582670650@localhost> <20200226000318.GJ39574@faui48f.informatik.uni-erlangen.de> <31896.1582680023@localhost> <8A7ABA50-0ACB-41A2-9AE5-4EE15DB86F3A@gmail.com> <27926.1582739768@localhost> <0E1FEB34-E329-4686-80CE-0DFE253409C2@gmail.com> <20200617170403.GA18378@faui48f.informatik.uni-erlangen.de> <20200617183127.GX16371@faui48f.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 00:37:40 -0000 --=-=-= Content-Type: text/plain Paul Wouters wrote: > Technically, your profile could say to "request transport mode, and > refuse the connection if the other end is unwilling to use transport > mode", but that I would argue that would constitute a protocol > modification which is not what a profile should do. How is this different than: "request authentication with a RSA certificate known to this CA, and refuse the connection if the other end is unwilling to use an appropriate key" -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl7qt1AACgkQgItw+93Q 3WWY8Qf/RfJ8Zh33vLlo8kBHYtOcVXPvDvbuqjUhG1EwSgCVKXBo9N6fk4TCS4Xo Wuenx0Ha6he7bP1YwaMQP40WwbmWapQ/N0I6zcXSko0bGG6GHiG9xUnlwA5wqS9Q 7fhwGL+nk6VKSFIAmYl8fqEzK9r/TgGg856YAZ1sgsbIBjeSz4BklSQJcdVZcTGo uUcvpjE6ZS2OkMv1XMwsP1tsLFst0gmwElWWRJg0o1rwDGDxW00rPh7HC+towQ5B 3V1wZb2IajLvn8yp2Xb4AtEl855Wbrk9o4InoEEVjFRpjFrHosQI990PVbVG0xWk 2Hudxi7OchH2LEFmAUWx8uJnXZ0bOg== =tA84 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 17 17:55:22 2020 Return-Path: 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 CFA4C3A08E2; Wed, 17 Jun 2020 17:55:20 -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 ToEeUjsjS68D; Wed, 17 Jun 2020 17:55:19 -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 A33553A08DE; Wed, 17 Jun 2020 17:55:18 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 49nNl76jDlzMvQ; Thu, 18 Jun 2020 02:55:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1592441715; bh=rDdwoU8W3Y+saF9XqeTlCd1ULiXH9dL4vCQai47+fXc=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=DRmHqunxhEBjWct3N5NwWjvIPqW1XHB3n9RxCpYLjMvuR/Te3MmvzrnzeFDH0Ajkn 1qXaz/XC4nWWLWyXwgmM79oJRQrXRD3WGwhrTlyLuPsZYzVfxpGgKz6OLY/+nmExPf z0MBthKLgGlW1k0PvzxRuHLgUQRkDz4s7QMo2Qok= 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 Ett_nfExYdYZ; Thu, 18 Jun 2020 02:55:13 +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 02:55:13 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 5F14F6029B9B; Wed, 17 Jun 2020 20:55:12 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 54A4C669F1; Wed, 17 Jun 2020 20:55:12 -0400 (EDT) Date: Wed, 17 Jun 2020 20:55:12 -0400 (EDT) From: Paul Wouters To: Michael Richardson cc: Toerless Eckert , Yoav Nir , "ipsec@ietf.org WG" , draft-ietf-anima-autonomic-control-plane@ietf.org In-Reply-To: <872.1592440656@localhost> Message-ID: References: <20200224195013.GA3878@faui48f.informatik.uni-erlangen.de> <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> <23402.1582670650@localhost> <20200226000318.GJ39574@faui48f.informatik.uni-erlangen.de> <31896.1582680023@localhost> <8A7ABA50-0ACB-41A2-9AE5-4EE15DB86F3A@gmail.com> <27926.1582739768@localhost> <0E1FEB34-E329-4686-80CE-0DFE253409C2@gmail.com> <20200617170403.GA18378@faui48f.informatik.uni-erlangen.de> <20200617183127.GX16371@faui48f.informatik.uni-erlangen.de> <872.1592440656@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 00:55:21 -0000 On Wed, 17 Jun 2020, Michael Richardson wrote: > Paul Wouters wrote: > > Technically, your profile could say to "request transport mode, and > > refuse the connection if the other end is unwilling to use transport > > mode", but that I would argue that would constitute a protocol > > modification which is not what a profile should do. > > How is this different than: > "request authentication with a RSA certificate known to this CA, > and refuse the connection if the other end is unwilling to use an appropriate > key" The RFC states: The USE_TRANSPORT_MODE notification MAY be included in a request message that also includes an SA payload requesting a Child SA. It requests that the Child SA use transport mode rather than tunnel mode for the SA created. If the request is accepted, the response MUST also include a notification of type USE_TRANSPORT_MODE. If the responder declines the request, the Child SA will be established in tunnel mode. If this is unacceptable to the initiator, the initiator MUST delete the SA. But note that the responder has already installed the IPsec SA in tunnel mode. So if the initiator finds that unacceptable, it must send the delete. During all this time, connectivity between the nodes will be blocked. The intention here is that transport mode is optional and should not be mandated by other protocols. Otherwise, the IKEv1 style negoation of transport OR tunnel mode would have been kept. So I would recommend to follow the intention of RFC 7296 and not make up your own restrictions. Whether a certain CA is acceptable is a configuration matter. There is no text in the RFC that states which certificates you must trust. Paul From nobody Wed Jun 17 18:57:43 2020 Return-Path: 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 5EF143A0A93; Wed, 17 Jun 2020 18:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no 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 3zvKIf4fFwzB; Wed, 17 Jun 2020 18:57:39 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F12D33A0A92; Wed, 17 Jun 2020 18:57:38 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 18499548440; Thu, 18 Jun 2020 03:57:33 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 12040440043; Thu, 18 Jun 2020 03:57:33 +0200 (CEST) Date: Thu, 18 Jun 2020 03:57:33 +0200 From: Toerless Eckert To: Paul Wouters Cc: Michael Richardson , Yoav Nir , "ipsec@ietf.org WG" , draft-ietf-anima-autonomic-control-plane@ietf.org Message-ID: <20200618015733.GG16371@faui48f.informatik.uni-erlangen.de> References: <31896.1582680023@localhost> <8A7ABA50-0ACB-41A2-9AE5-4EE15DB86F3A@gmail.com> <27926.1582739768@localhost> <0E1FEB34-E329-4686-80CE-0DFE253409C2@gmail.com> <20200617170403.GA18378@faui48f.informatik.uni-erlangen.de> <20200617183127.GX16371@faui48f.informatik.uni-erlangen.de> <872.1592440656@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 01:57:41 -0000 On Wed, Jun 17, 2020 at 08:55:12PM -0400, Paul Wouters wrote: > The RFC states: > > The USE_TRANSPORT_MODE notification MAY be included in a request > message that also includes an SA payload requesting a Child SA. It > requests that the Child SA use transport mode rather than tunnel mode > for the SA created. If the request is accepted, the response MUST > also include a notification of type USE_TRANSPORT_MODE. If the > responder declines the request, the Child SA will be established in > tunnel mode. If this is unacceptable to the initiator, the initiator > MUST delete the SA. > > > But note that the responder has already installed the IPsec SA in tunnel > mode. So if the initiator finds that unacceptable, it must send the > delete. During all this time, connectivity between the nodes will be > blocked. The intention here is that transport mode is optional and > should not be mandated by other protocols. Otherwise, the IKEv1 > style negoation of transport OR tunnel mode would have been kept. How about my mails ask that i read this text such that the initiator will delete the SA (not only client SA) if transport mode is not supported be responder. Aka: the last two sentences to me describe exactly the case where the initiator can/want only support transport mode. Aka: i can not read your interpretation into this text. Please answer the other questions from my reply mail. > So I would recommend to follow the intention of RFC 7296 and not make > up your own restrictions. Again, i had a lot of arguments in my email that i need to see answers to so that we can make progress here. Cheers Toerless From nobody Thu Jun 18 05:19:11 2020 Return-Path: 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 ; 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 ; 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 ; Thu, 18 Jun 2020 05:19:07 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id e4so6966677ljn.4 for ; 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" To: "'Dang, Quynh H. \(Fed\)'" , "'ipsecme mailing list'" References: , <059d01d644af$4f2c7ed0$ed857c70$@gmail.com> In-Reply-To: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 12:19:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0673_01D64583.CF390060 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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. 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 Sent: Wednesday, June 17, 2020 9:57 AM To: Dang, Quynh H. (Fed) ; 'ipsecme mailing list' 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. ------=_NextPart_000_0673_01D64583.CF390060 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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-mult= iple-ke-00#section-1.1  and  https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-int= ermediate-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. 

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,<= o:p>

Quynh. 

------=_NextPart_000_0673_01D64583.CF390060-- From nobody Thu Jun 18 06:32:38 2020 Return-Path: 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 E71513A0F33 for ; Thu, 18 Jun 2020 06:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=OL1Bl3l5; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=a1pqhq1m 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 ntPCm815CyzA for ; Thu, 18 Jun 2020 06:32:27 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 054DB3A0F9E for ; Thu, 18 Jun 2020 06:32:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31620; q=dns/txt; s=iport; t=1592487127; x=1593696727; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=hANcs84bZwa92MAPVYt1V3LtxpNdz/GZDHMxhY2Bwrc=; b=OL1Bl3l5w/SADNj4W/GUUkIXsdtXzhaPm8l0hkoQ4E7yb6S2Z7rcUx9C aiEmDQYJOyiVE3U2WlL61X0UzGVBIEEFyR0YwEsTk/dJyI6uxO5yViyUR CNVFPqbVBciqyzJhMPEcMGQpDuCCQc4J5R6Gy5t58+AuSjyUwc4B9cgKo w=; X-Files: smime.p7s : 4024 IronPort-PHdr: =?us-ascii?q?9a23=3Avm5E7R1xUxMsB9OrsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWFuadhiVbTVsPa5u5Kze3MvPOoVW8B5MOHt3YPONxJWg?= =?us-ascii?q?QegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZXyYlTIqTuz4CIcXB?= =?us-ascii?q?LlOlk9KuH8AIWHicOx2qi78IHSZAMdgj27bPtyIRy6oB+XuNMRhN5pK706zV?= =?us-ascii?q?3CpX4bdg=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C7CADHa+te/5hdJa1mHgEBCxIMQIE?= =?us-ascii?q?/C4EjLyMuB28rLS8sCodgA41Ah1WCKo5TglIDVQQHAQEBCQMBASUIAgQBAYR?= =?us-ascii?q?EAoImAiQ3Bg4CAwEBCwEBBQEBAQIBBgRthVsMhXIBAQEBAgESGxMBASwMBAs?= =?us-ascii?q?CAQgRBAEBIQcHAh8RFAkIAgQBCQkIBhSDBYF+TQMOEQ8BDqwdAoE5iGF0gTS?= =?us-ascii?q?DAQEBBYEyAQMChAMNC4IHBwmBOIFTgRSJeBqBQT+BVIIfLj6CGkIBAQIBgTQ?= =?us-ascii?q?QGhUWCYMRgi2OdjKKb4luj3xMCoJahCeCU4FGi3mFCIJwgReIBJJjj1SBT4F?= =?us-ascii?q?jiC2CVpFTAgQCBAUCDgEBBYFpI4FWcBU7gmkJRxcCDY4eCQgSg06FFIVCdAI?= =?us-ascii?q?1AgYIAQEDCXyNPoE0AYEQAQE?= X-IronPort-AV: E=Sophos;i="5.73,526,1583193600"; d="p7s'?scan'208,217";a="787017458" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Jun 2020 13:32:06 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 05IDW6cQ009621 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 18 Jun 2020 13:32:06 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 18 Jun 2020 08:32:05 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 18 Jun 2020 09:32:05 -0400 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 18 Jun 2020 09:32:05 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PQ5uga7TvSbyThlbrPCPOmh8cBCbgGImwbWNJgOsDTKZvqaiYUIxgM/KV/IzrZ77gk1JlNGWtrHovzQacZCt2N+3LwJkQ6k45SaI+yjzg//YZmurBK2ZYDmAiJew/EKxI5htgUN9JUh6fdiMxQK6gQSeA5uwFKhcNyi3xjqhb68VoQ0BbxiFt8/fsPGR+pdVI0KT/RPPD+Vsnm4hJohmXEctimockmLq10yMMygHWsd7+KK0x4qsEWfv3X6dCUlv+M9qHL4KFVqQFpAT9joPBhmcBWs6bvtlGwnHoqSvp46FzFcB6G7SqfNItz7aAxPhYWKTY3oDGUZ8LRrP0wiRvQ== 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=muoJf2TisKo3wyiTNkwN4qvbGCbxaQQXcpK5Jr3Mb9g=; b=K2Yw0vcWRugixRtSTj29FP1xFOy3I0FB1j+DO3kxdrFzmIORLzFNbacdpXDtwwar8dnumEUCQ/Y8A//2L2qHWCYbT1vgp4jZk5F7Dxx/53TEiUeZ033gANlsvoTOxmAtTtOMr2B5u+aowjbMVgLJRhUhNNfTfZ2KnPIQwN99c3crO7yoWrr2v1sEPSmlZeBPGiUbx9gx49R/CvlBHBbdSG/Dd1vcT2jIoINAu1dwey7ZKRgwYxrfm2WBMM39JGNMM/LCDsEKYIhwiTpKOQDWgxaieVqqnqPLmRsUAk4TWb4SbqF3QCAzClqRZw7PzzI80/2l+hvKUp74uKRCvsD+Og== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=muoJf2TisKo3wyiTNkwN4qvbGCbxaQQXcpK5Jr3Mb9g=; b=a1pqhq1mmhDiqIhj0QFuXAGOMFITC7/6ioMMRsUwo2UUCSxtMZQ34VF8gCllhGt9rynMAnsLfYgSSKWj79/3uLJJxnpemXFDXPlHL3GjT+hnjZSUIP78WVCVJIHrXGt8fUft+ODITFTLJyIdffCvd12VpsME1Bzu5zZQ+xvYHEw= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (2603:10b6:406:af::18) by BN8PR11MB3828.namprd11.prod.outlook.com (2603:10b6:408:89::23) 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 13:32:04 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::7d1c:98b:2131:d35]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::7d1c:98b:2131:d35%3]) with mapi id 15.20.3109.021; Thu, 18 Jun 2020 13:32:04 +0000 From: "Panos Kampanakis (pkampana)" To: "Dang, Quynh H. (Fed)" , "Valery Smyslov" , "'ipsecme mailing list'" Thread-Topic: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ? Thread-Index: AQHWRKwTbexJ5B/60kaRS2oRKSlgJqjc1UQAgAAH7FWAAYCSgA== Date: Thu, 18 Jun 2020 13:32:03 +0000 Message-ID: References: , <059d01d644af$4f2c7ed0$ed857c70$@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [68.93.142.48] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3f36c701-2afa-425a-1263-08d8138bfd30 x-ms-traffictypediagnostic: BN8PR11MB3828: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0438F90F17 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: SGQxlZWPsOrt+qGPDghCshN/4/mvefDaYzvyGrcN4UFXFJnY8h8iN8j5G41XCutAh6hTW+PZn4oVCnM7kSXKS2AY2NTfV6wRnsOdWt4RdYnTlNrPHxZ7jEciZaixLXwWNn4+iBEB7Ati9FQeeOUi7UvUpVPw4Qu5kt1c03H7pmGpNZJY5jDbGyErmHUkTzDFIKCh5XZjh3U9C+MrRPJWFtv1ADfWlPTzl8OQMqwduRxnYiFF9ldHXSo1YL3KOU+GT/dtgF4gA/EmGJdq9L8hABFDeuHmX85pyJqxtsL8DakIBPDeWTefHOrvdRCB5Oliv6C+8aQDhGFmwQALHzyxFpDlAU8uyR1pe8FK/+7RuYnQTnaffB5MO3huh3/8PinTwP914zmMhWgo5IwDlns+Sw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2547.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(39860400002)(396003)(346002)(376002)(136003)(86362001)(15650500001)(55016002)(966005)(71200400001)(9686003)(7696005)(5660300002)(53546011)(478600001)(66574015)(9326002)(33656002)(8936002)(76116006)(186003)(316002)(66946007)(66616009)(66476007)(66446008)(64756008)(66556008)(2906002)(26005)(110136005)(52536014)(6506007)(166002)(83380400001)(8676002)(99936003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: s9Y0OcNkfvetYM+TzVfb61k8R1exbYDqsXrWaVUT07yC4t7/hpdpEJeJV20e2rsCI5GbD5DSoMV5WSZjsb6KASxGAmQLxiQoh4FW8uWbfwjv72N2ofpCizejpF1/WIEb3e14j0Md8nxWoRtN2bLE/wFRC6bkLr1KDXzU6KFfEsGWPHxzNswjVv1mirr1e5tXlGc2x+KwoaUaRL/vFmOR4iuK4FA7QTG1N5lWG32tYGI0qVEFVVyFObqSiw7G7LlZ32Ifiz75YBoGNy9n26hKepLNAEHVWVhnOuTSQSydQO0EUxmNcPaC7j0HBlkURqnHfpnImlUHjai7SwPFkTUxopTLzCiBnVXvvLpyGBJloT7P1BCGvG6TCsj4vahgJJksSTwAslkoJWfy7vAxpfvtmy5E5kJuvjxbYe6+XI/KJ0mjXnG+7BtKTxIh19T/G1w7nGTUsKYedYNtIHRewPkDnpUjWutzvYKyDIx78S0JbB4= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0016_01D64553.5250FDD0" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3f36c701-2afa-425a-1263-08d8138bfd30 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2020 13:32:03.9844 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: W1aquqkKM37h7ENreQrYfW2MhT475/3qMwCrdO8RSCqOy0Fz+nWEv31VPQFGlmb16EQA7EkZaZ3Tr8Ewfq4TCg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR11MB3828 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 13:32:37 -0000 ------=_NextPart_000_0016_01D64553.5250FDD0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0017_01D64553.5250FDD0" ------=_NextPart_001_0017_01D64553.5250FDD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Quynh, > 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 ? > 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 ? We tested this in the context of TLS in https://eprint.iacr.org/2020/071. For a tunnel that stays up for a long time (not just a few seconds like HTTPS) and sends Megabytes of data or more, then the larger key+signatures size are amortized over the tunnel data. What becomes more important then is the keygen, encap, decap, sign/verify time. In other words, servers that terminate a lot of connections at the same time will be impacted by slower operations in the handshake (the server throughput drops), but their tunnels that send a few more kilobytes of handshake data and magnitudes more over the tunnel are not significantly affected especially if we are talking about UDP and not TCP (with congestion control slowing down the handshake). From: IPsec On Behalf Of Dang, Quynh H. (Fed) Sent: Wednesday, June 17, 2020 12:37 PM To: Valery Smyslov ; 'ipsecme mailing list' Subject: Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ? 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 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 > Sent: Wednesday, June 17, 2020 9:57 AM To: Dang, Quynh H. (Fed) >; 'ipsecme mailing list' > 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. ------=_NextPart_001_0017_01D64553.5250FDD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Quynh, =

 

> 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 ?

> 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 ?

 

We tested this in the = context of TLS in https://eprint.iacr.org/2020/07= 1. For a tunnel that stays up for a long time (not just a few = seconds like HTTPS) and sends Megabytes of data or more, then the larger = key+signatures size are amortized over the tunnel data. What becomes = more important then is the keygen, encap, decap, sign/verify time. =

 

In other words, servers = that terminate a lot of connections at the same time will be impacted by = slower operations in the handshake (the server throughput drops), but = their tunnels that send a few more kilobytes of handshake data and = magnitudes more over the tunnel are not significantly affected = especially if we are talking about UDP and not TCP (with congestion = control slowing down the handshake).

 

 

 

From: IPsec = <ipsec-bounces@ietf.org> On Behalf Of Dang, Quynh H. = (Fed)
Sent: Wednesday, June 17, 2020 12:37 PM
To: = Valery Smyslov <smyslov.ietf@gmail.com>; 'ipsecme mailing list' = <ipsec@ietf.org>
Subject: Re: [IPsec] Maximum sizes of = IKEv2 messages and UDP messages ?

 

Thank you Valery and thank you = everyone who responded 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. 

=

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

<= /td>

 

 

=

 

=

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. 

------=_NextPart_001_0017_01D64553.5250FDD0-- ------=_NextPart_000_0016_01D64553.5250FDD0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDGkw ggNDMIICK6ADAgECAhBf+HsoK1TcjUKjFbVoya3/MA0GCSqGSIb3DQEBBQUAMDUxFjAUBgNVBAoT DUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNpc2NvIFJvb3QgQ0EgMjA0ODAeFw0wNDA1MTQyMDE3 MTJaFw0yOTA1MTQyMDI1NDJaMDUxFjAUBgNVBAoTDUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNp c2NvIFJvb3QgQ0EgMjA0ODCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBALCauaunrwp3 p+JxtrRmYpR4iEfGYlWEQDK/wKsupRxx1rxue6iqum7SFYhIRZ2i/IPQzLmM4CZocEp43yEXnvRh BckVyM8W2jVhiZRDqISoMZh4m7lObyxTEmzNHa0rJLsxxCv/g0Rvtj0kdwnqvyqoH2pW9iAPEVSX gXWnJc5ZaoJl77fq5+KNdYtu8t1Ppl5inM8QCmTQTm3OK8xb9WClJ0eNafR/zhtw3nAbINZuzaYB qDwS0qk/oGteu44gi3qR47Vo7qDnxAF0qFMLK0qaD2USDoJNjmP97+ubGttTphNgr8J918dsFyXU c/tHZFCBgJRM4b+uSxzfku0uBd8CAQOjUTBPMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/ MB0GA1UdDgQWBBQn88gVHm6aAgkWrSugiWBf2nsvqjAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG 9w0BAQUFAAOCAQEAnZ2EhKNBqXx3DLdTyk5EUGLvVHzTdRcc6ODGSEu2/kw6GYFWsFbuGZZiqlqj ZMH2TlQzxnf+xRy65V0lyvXwk5qDES7my/h0Rf7nBbir59/LS+E3hNq5i5dwHvDii9ew2A6dsWnW KpF7qUlPfuaOldiDJzzVaEkO1J32LuunvuswpKwfRPyVqzMG+31gCt60imOwnKnypLlTAYfQaKQn f6v/6frJQDiIZ7Q5xoRvV8lT27qO7sBDsvgJg27/Zs8+7xezWBglCTRe48vWFLbs8pJvdOQvgSrV kpHg4Jc8MmgFhUvR91fiUh2TGlSfBXDASnFgHkMLYB7+o86BGeELNTCCBG4wggNWoAMCAQICCmEQ gG0AAAAAAA4wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UE AxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTE0MDQwNDIwMjQxOFoXDTI5MDUxNDIwMjU0MlowLDEO MAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxveWVlIENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyt9+FkxTFfsjVs3GuWUKBJXl3kxFZ4wMxwbgqx9tXzcqe+fto62A fxHI84Lr7p9Q2cm/PaEvuzwRBzXvuKXZUU7ZsPdToJSALCySZa0Qb6GGa19ACpmlUEQakE3P5kz7 RgaNSOMH1+GtY9fV6CcAFb9uB7JDu2UGL332WV2bEsUsfb3rRLBS4cL8Hu2dWfcdk6erMaZCQjkn 04FixlQsJozbPRTQqI4V6iikG/69rDyeTdbVTK+My/9LnwVsD3GBMiRh7RmrvupxtGiMu8j05Is/ d1OifhWecwvjV3Reg9Lok8bMNJEMAped1weTdVS0X4MsAheosJBld9lS5O4idwIDAQABo4IBhzCC AYMwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFJ+VNrSOXdVLwwrBpymTQ1EG/YlRMBkGCSsG AQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB8G A1UdIwQYMBaAFCfzyBUebpoCCRatK6CJYF/aey+qMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly93 d3cuY2lzY28uY29tL3NlY3VyaXR5L3BraS9jcmwvY3JjYTIwNDguY3JsMFAGCCsGAQUFBwEBBEQw QjBABggrBgEFBQcwAoY0aHR0cDovL3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL2NlcnRzL2Ny Y2EyMDQ4LmNlcjBcBgNVHSAEVTBTMFEGCisGAQQBCRUBFQAwQzBBBggrBgEFBQcCARY1aHR0cDov L3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL3BvbGljaWVzL2luZGV4Lmh0bWwwDQYJKoZIhvcN AQEFBQADggEBAD5OviMaRgKNXmvbigI0C2Ob5QE8Jl2McLIk62Be7IqEZC4bWRWjZxrhFuP94E19 RJojKNLttveiH+dEze1t6oYhVCisbGG8+8hlUARAiiqL/J9uGJ71xT6loqkcAK5xphe7STJLSlgT k0w26fcvDeiA6zhdVHnKhVKkpOJWd9MNByFOnCQyDOK+pcNxLU6IN9TwL1ZoRkdFa11QiCX3Oimk 8YhBrVN+VzGGKtbgZ4fYU6uBo3V3vtshyDpHtGkn1e7f9/TWcY26etFzL33dzaZ4lChlw4l3XkLq 6AfCEDF5djpBdiCRjwpBUIIbCSmyESBvA+sL4j8i1vo/uEartrAwggSsMIIDlKADAgECAgoBhhEi QTzquitVMA0GCSqGSIb3DQEBCwUAMCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBF bXBsb3llZSBDQTAeFw0xOTEyMjAxOTQ5MDJaFw0yMTEyMTkxOTU5MDJaMIGfMSQwIgYDVQQDExtQ YW5vcyBLYW1wYW5ha2lzIChwa2FtcGFuYSkxFDASBgNVBAsTC0Npc2NvIFVzZXJzMRIwEAYDVQQL EwlFbXBsb3llZXMxEzARBgoJkiaJk/IsZAEZEwNjb20xFTATBgoJkiaJk/IsZAEZEwVjaXNjbzEh MB8GCSqGSIb3DQEJAQwScGthbXBhbmFAY2lzY28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAmIHTLIzoAnuMUiHMx8V+PF9JpAcB7zrNHOY1Vj1R1Vx7ty7m9yo9G991T2n7zHo4 UzF6tnB9NxzQOKCY54oqP5KjVGYOPPo+qZ+2rx1GABzdKUF4LwUUKOTf9uXAtvsvIRUc5J/csShT jcUIvtVmiAzWXWRfMYShjBYBVtx/h8fDqAqfFAzd6HG0TcdsN/BRb9k6QEW1afHjPKlRUaDRELyj nFGJZd2OsUJ7/aKMdFmQFd2CAJYzsuwLYjeqJsuGNzBc/k6mzQPf6FW17nz17G41KReU0UdZf2yZ jvimkwCQ/yW8SVTOcGBP+Zk+Lq5EYEGQMu1qtNK/97bXMc5kuwIDAQABo4IBWjCCAVYwDgYDVR0P AQH/BAQDAgTwMAwGA1UdEwEB/wQCMAAwegYIKwYBBQUHAQEEbjBsMDwGCCsGAQUFBzAChjBodHRw Oi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY2VjYS5jZXIwLAYIKwYBBQUHMAGG IGh0dHA6Ly9wa2ljdnMuY2lzY28uY29tL3BraS9vY3NwMB8GA1UdIwQYMBaAFJ+VNrSOXdVLwwrB pymTQ1EG/YlRMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jaXNjb2NlcnRzLmNpc2NvLmNvbS9m aWxlL2NlY2EuY3JsMB0GA1UdEQQWMBSBEnBrYW1wYW5hQGNpc2NvLmNvbTAdBgNVHQ4EFgQUjrl7 6Mrrdw3ZYFiTpZBdtrUm5P4wHwYDVR0lBBgwFgYKKwYBBAGCNwoDDAYIKwYBBQUHAwQwDQYJKoZI hvcNAQELBQADggEBAMhR6xCTygu68lppjWebXTXYznix5961hcmwiJRkPtUIGQ5JQwXyCwq/Juuq yc5ebeq9cQEO5iqyxik/UAQ35BlmKb7SNLi75RtFE/AIZrRsEjTUoO2EtCMQOEMcenWa2XE8fEID BkwzreKeaOchCbDd4L9PvKFht6nDDFtb6VZdWs4ort+J3iFeilVf3oI5MSVi+qroWaFLnLYTQGTn qEjWANfKw3RRBAMdoPCZ+N4eftAk1TWVS08nOsPoKWXtIqX6y0ZPs/EZjBSk57v1TPLpYhEqYGXI oGJlIvzIAfYNoUg8yP8toG5T7x+7hRz0MMUGWcCDsS9PMFxH6SnrUSMxggMNMIIDCQIBATA6MCwx DjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTAN BglghkgBZQMEAgEFAKCCAaQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMjAwNjE4MTMzMjAxWjAvBgkqhkiG9w0BCQQxIgQgeXgTPHKnCFX1uxElGCUhALyhDuwxhNUK 6IPzadpoWM0wSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lz Y28gRW1wbG95ZWUgQ0ECCgGGESJBPOq6K1UwSwYLKoZIhvcNAQkQAgsxPKA6MCwxDjAMBgNVBAoT BUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTCBoAYJKoZIhvcN AQkPMYGSMIGPMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUD BAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDALBglghkgBZQMEAgEwCwYJKoZIhvcN AQEKMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEggEA XtkY0R7w2XbPnVCgP+ikp7FpxWweu4ATGHYBXFSxuG3W6gQSsS8UPwlhDDU19JN7s0SySeD8KABG R5chEtwbGmS63SkLg0xj/4xj3+cPsxaFDxmFMoqLvub2MHNJFt2XtNV8M6CCAjyrCaaY/3aOpooF EPPoh4U3l3HQkPMNXSC2lOIkcaYwrvZfHykVlONzlkj87cY45K+X6RMaJz3kgkw32i3YQDYfNuad Vx6Miz/DrSM+2/QJy88s8tLu4z1X+a91IABac5elx9X4gl3wYnK6GCiyHV7rdQoMEfAFZS2u33hG 9TKAao5WX4YosR6PjuTPjCzboWTAP3nM5hAo2QAAAAAAAA== ------=_NextPart_000_0016_01D64553.5250FDD0-- From nobody Thu Jun 18 06:52:06 2020 Return-Path: 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 9A76E3A0FC4 for ; Thu, 18 Jun 2020 06:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=c73a1ktq; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=QlNmbKGJ 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 wbFKuIW0VKI7 for ; Thu, 18 Jun 2020 06:52:00 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 981903A0FC2 for ; Thu, 18 Jun 2020 06:52:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30470; q=dns/txt; s=iport; t=1592488320; x=1593697920; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=KYlq3d5yjP3R2N7w++jzDfp00i7y4FZRc9nkn9h6d9c=; b=c73a1ktqk+t5Sy4TZE06NJhgAQIgqELFALN9nDtslOqmGwoBjryjXDPE XL3RRBwsaeBWCNLvm5L60o1Iu0WS3DQRXg2jNyyB4y0NllkGXJdw3+yvM 120MFh7z4RAC6prz6BHlH6sc59YSe6rZNtXNHMeDjQKVF9DPK+YMzbeLA 0=; IronPort-PHdr: =?us-ascii?q?9a23=3A39n8oh2JYRkju1C3smDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWFuadhiVbTVsPa5u5Kze3MvPOoVW8B5MOHt3YPONxJWg?= =?us-ascii?q?QegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZXyYlTIqTuz4CIcXB?= =?us-ascii?q?LlOlk9KuH8AIWHicOx2qi78IHSZAMdgj27bPtyIRy6oB+XuNMRhN5pK706zV?= =?us-ascii?q?3CpX4bdg=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D0AQA+cOte/4ENJK1mHQEBAQEJARI?= =?us-ascii?q?BBQUBQIE5BQELAYEiLyMGKAdvWC8sCodgA41BiX+OU4JSA1ULAQEBDAEBJQg?= =?us-ascii?q?CBAEBhEQCgiYCJDcGDgIDAQELAQEFAQEBAgEGBG2FWwyFcgEBAQECARIbEwE?= =?us-ascii?q?BLAwECwIBCBEEAQEhAQYHIREUCQgCBAEJCQgagwWBfk0DDiABDqwkAoE5iGF?= =?us-ascii?q?0gTSDAQEBBYEyAQMChBINC4IOCYE4AYJmiXgagUE/gVSCGAcuPoIaQgEBAgG?= =?us-ascii?q?BNBAaKwmDEYItjnYZGYk4gwqIG498TAqCWohAi3mFCIJwgReIBJJjj1SBT4F?= =?us-ascii?q?jiC2CVpFTAgQCBAUCDgEBBYFpI4FWcBU7gmkJRxcCDY4eCQgSgQIBDoI9hRS?= =?us-ascii?q?FQnQCATQCBggBAQMJfI0+gTQBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.73,526,1583193600"; d="scan'208,217";a="784683968" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Jun 2020 13:51:58 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 05IDpw2j026186 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 18 Jun 2020 13:51:58 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 18 Jun 2020 08:51:58 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 18 Jun 2020 09:51:57 -0400 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 18 Jun 2020 09:51:57 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VT90ojwoo6fsdxG4onctbjUgAU4THCXIiUWxzTsp52I1HmGqCD3Kexq7zAbbiNiCFoNXLIXU3sQw1dpOicPqucoa1s+oxPVswg5e+ETBmZJNNSYpnafRoCBI+BwE1v4Pom9ECOA/wlWEZd1q8CChqARKJltQzYSjVa6J0pBo10nijvXQAZj8oN4YiSDjW6mXHzc2XTrUIhNlwqhZ/53HsTwt+1OMbf9lBTxH3XgvQAtcM+K4rBoEPPQG2WbfEG09OMPLCJ/kj8URm+EDqjMQ4CrOTeO4jzRmGzjyU6XkG8trjJUke/Paiy7QbxUAR3zQOShnMOVh9wJAbHaSJCApVA== 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=syt7azOgJO87EtaxwlcthHpAv3MIho3Gk8QQCb1DFlg=; b=H25fttut84pJYaQhlg8fPRYkk/PO6cujP9rkMlMuLxdA5kZhrO209wcDbUYLukf1n26jqBgbwfwd+PWgRzG+gbr4CqPV8G828UBPy/krXsVIFppQLpR3/FAIFJYbDAJ/19ma3uRdajdXDikWSa5OimVYGaTpF0aDajqzsY4q/5r6Sg8RI5fJOBZa7COlrbsqTtUwqYe2ncyPvz0Dc/zb5vyCAKeTjps28SWzPO+OHQdS4iGSNxEklS2AYaDSOL9KHnVwXXMXmejUfpj9xFDWZmz96o5J4dwQOVauCUAqDc8a/5jNJS/5P5mi1cVhuxOiuuxE5Y3VPsSpjCTyBK7Jzw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=syt7azOgJO87EtaxwlcthHpAv3MIho3Gk8QQCb1DFlg=; b=QlNmbKGJiq1oNsf2AXPxdx09lLN8oLHSr4y3tqkdKxx5l2YekZU47JtpFwPKxEDsdDfXwqnApP5Io/nCky8Bo81J09SBtiiWxX1ZRSsdg4Bn4lRVPhQOKC3T+qSA3ENZ7Uhvhz9+2KgF3xVVv1zqGRzkk62mwEEUeYwKiOygoNA= Received: from BN7PR11MB2641.namprd11.prod.outlook.com (2603:10b6:406:b1::25) by BN8PR11MB3716.namprd11.prod.outlook.com (2603:10b6:408:8a::30) 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 13:51:56 +0000 Received: from BN7PR11MB2641.namprd11.prod.outlook.com ([fe80::35bd:ecae:1e28:58f5]) by BN7PR11MB2641.namprd11.prod.outlook.com ([fe80::35bd:ecae:1e28:58f5%5]) with mapi id 15.20.3109.021; Thu, 18 Jun 2020 13:51:56 +0000 From: "Scott Fluhrer (sfluhrer)" To: "Panos Kampanakis (pkampana)" , "Dang, Quynh H. (Fed)" , Valery Smyslov , "'ipsecme mailing list'" Thread-Topic: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ? Thread-Index: AQHWRKwTbexJ5B/60kaRS2oRKSlgJqjc1UQAgAAH7FWAAYCSgIAABUVg Date: Thu, 18 Jun 2020 13:51:56 +0000 Message-ID: References: , <059d01d644af$4f2c7ed0$ed857c70$@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.76] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7eb5f41a-9b83-4493-c9d0-08d8138ec3c2 x-ms-traffictypediagnostic: BN8PR11MB3716: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0438F90F17 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: rft3YyYdtifkbTqvisTCBoNuGCfSu86795YWcEJIEPDt4/fU/0O/OaVPRezVUrEvfuN/mNDmTE+k3tF2YifdTRHPIgJv2JkJ6U23vLMTNAkHZ6rawC29GKxKMZ11B1prnyeX37ibwkIGlXgf2z94JobsMGTc9WiR7KJ79PLo2mKr7M+fST2vjLUPUJZivcXX7Hd3Vw7gvdmo1MIKMmGnWaLUfuIZ/9QMnK5QY9/etHwcMLxDN2EvbzW4WIFGrejat//qW/lvMuwxesl6BmhUXWQfYtC6j1BbJsIZpojvKrsVgch71fkxRtTBnlsO6JVsBVVAj+p86atx+hiqcnDU8+D+Wgn/pBaiyBB1LRluxXqpsEziA4Zo2sCKdTUdn1ORQ4qFsABM+o4LefrNrHvykg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2641.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(39860400002)(136003)(346002)(366004)(376002)(8676002)(966005)(71200400001)(166002)(26005)(66946007)(76116006)(66446008)(15650500001)(83380400001)(2906002)(53546011)(6506007)(7696005)(66476007)(66556008)(478600001)(64756008)(8936002)(86362001)(52536014)(5660300002)(316002)(66574015)(9686003)(110136005)(33656002)(186003)(55016002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 1/J6eEd0qbiCLh9kFohMFkwDRYQe+1wHUmb8q0vHeT34g+RVInypfZZvfH16jUUL7DM/nO2T+b9yH2ET4pS5wh8Fdnjybp4kL11EyDhJtrZtGMao1frbEi1ay+I7mMkdxdvdvsgIvuwVRxhH7wCAAf27tZsMjbs9z8qE/m+i3m3Mk9r8Gd3RXbSgRbm2s5SXWBXIucxsn4lJiXhJmMikMVpBVWhgsQTlDv5N/+5wLeT1ar8NZa9rRleeQyImbvFdOTcw2yBYIbUl0oe2SOKovS5W9qGk8nFwqNFHrw+QMJjikg443A9HHil7RXTLZyf+VDW8Nx9n2o4MKvkk70wMP6tXGt4ga+WdFHgS1ZtNHKI12CnYoHMFm76h7STa1YVuP9/ULkKUyXM+BcAhP+oBJSivQXmirN24YEXWRnyWhL6KF/6iP6FlteDvqvRDNeCnpO2H8UhqgyHJMjcqzKxbRdNXdhdste0GlAp7KWL+aJ0= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN7PR11MB2641EC57D261F6DF13F3D702C19B0BN7PR11MB2641namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7eb5f41a-9b83-4493-c9d0-08d8138ec3c2 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2020 13:51:56.1922 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: uJFzZa7FNdLu+LxyTTm7ixXGmUEA8g9Q0ZyJekvsZEvNufrOXF2ebVpP34c0OB6fJpDGs5WOnItXt1LYRc0kVA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR11MB3716 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 13:52:05 -0000 --_000_BN7PR11MB2641EC57D261F6DF13F3D702C19B0BN7PR11MB2641namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Speaking as a previous IPsec implementor, the biggest concern I had over IK= E performance was in the 'flash crowd' scenario; that is, you're an IPsec-b= ased 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. That scenario requires a rather lot of care to avoid "congestion", that is,= where you're so busy answering IKE messages that you don't get enough time= to complete any exchange before the IKE exchange times out. What you end = up doing is effectively triage; deliberately ignore some exchanges for the = moment so that you can complete others. Now, if you have large key shares, what that would add to the scenario is m= emory management; while processing the requests, you need to buffer the rec= eived key shares, and so part of your triage needs to worry about memory co= nsumption in addition to the computational costs. It's not clear what comp= lexity it would add; I would certainly be concerned if I were still an IPse= c implementor... From: IPsec On Behalf Of Panos Kampanakis (pkampan= a) Sent: Thursday, June 18, 2020 9:32 AM To: Dang, Quynh H. (Fed) ; Valery S= myslov ; 'ipsecme mailing list' Subject: Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ? Hi Quynh, > An obvious question is that what is the performance impact from this larg= e KEM using the approaches above when compared with a KEM (if its public ke= y and ciphertext are around 1,400-1,600 bytes in total) (assuming a pq sign= ature algorithm has a small signature and a small public key) which would w= ork well in a normal IKEv2's implementation ? > I guess the impact is small generally because an IPsec tunnel normally st= ays up for a long time. Does my guess seem ok here ? > Would there be some noticeable impact on a high-volume connections VPN se= rver ? > An obvious question is that what is the performance impact from this larg= e KEM using the approaches above when compared with a KEM (if its public ke= y and ciphertext are around 1,400-1,600 bytes in total) (assuming a pq sign= ature algorithm has a small signature and a small public key) which would w= ork well in a normal IKEv2's implementation ? > I guess the impact is small generally because an IPsec tunnel normally st= ays up for a long time. Does my guess seem ok here ? > Would there be some noticeable impact on a high-volume connections VPN se= rver ? We tested this in the context of TLS in https://eprint.iacr.org/2020/071. F= or a tunnel that stays up for a long time (not just a few seconds like HTTP= S) and sends Megabytes of data or more, then the larger key+signatures size= are amortized over the tunnel data. What becomes more important then is th= e keygen, encap, decap, sign/verify time. In other words, servers that terminate a lot of connections at the same tim= e will be impacted by slower operations in the handshake (the server throug= hput drops), but their tunnels that send a few more kilobytes of handshake = data and magnitudes more over the tunnel are not significantly affected esp= ecially if we are talking about UDP and not TCP (with congestion control sl= owing down the handshake). From: IPsec > On Beha= lf Of Dang, Quynh H. (Fed) Sent: Wednesday, June 17, 2020 12:37 PM To: Valery Smyslov >;= 'ipsecme mailing list' > Subject: Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ? 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-i= etf-ipsecme-ikev2-intermediate-04 look good to me. It looks like if/when someone implements them and adds a large key and/or c= iphertext KEM, the maximum IKEv2 message size must be adjusted if the exist= ing 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 m= essage size (it is an implementation specific issue). Let's say after 10 or 15 years from now, the group trusts the security of s= ome PQ KEM and signature algorithms and would like to use them in normal IK= Ev2 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 signat= ure algorithm has a small signature and a small public key) which would wor= k well in a normal IKEv2's implementation ? I guess the impact is small generally because an IPsec tunnel normally stay= s up for a long time. Does my guess seem ok here ? Would there be some noticeable impact on a high-volume connections VPN serv= er ? Regards, Quynh. draft-ietf-ipsecme-ikev2-intermediate-04 - Intermediate Exchange in the IKE= v2 Protocol This documents defines a new exchange, called Intermediate Exchange, for th= e Internet Key Exchange protocol Version 2 (IKEv2). This exchange can be us= ed for transferring large amount of data in the process of IKEv2 Security A= ssociation (SA) establishment. Introducing Intermediate Exchange allows re-= using existing IKE Fragmentation mechanism, that helps to avoid IP fragment= ation of large IKE ... tools.ietf.org ________________________________ From: Valery Smyslov = > Sent: Wednesday, June 17, 2020 9:57 AM To: Dang, Quynh H. (Fed) >;= 'ipsecme mailing list' > 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 met= hods. 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 need= ed. Regards, Valery.. From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Dang, Quynh H. (Fe= d) 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 message= s 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 lim= it. As you know some of the post quantum cryptographic candidates in our standa= rdization process have large or very large public key , signature and/or ci= phertext 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. --_000_BN7PR11MB2641EC57D261F6DF13F3D702C19B0BN7PR11MB2641namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

 

That scenario requires a rather lot of care to avoid= “congestion”, that is, where you’re so busy answering IK= E messages that you don’t get enough time to complete any exchange be= fore the IKE exchange times out.  What you end up doing is effectively triage; deliberately ignore some exchanges for the moment so t= hat you can complete others.

 

Now, if you have large key shares, what that would a= dd to the scenario is memory management; while processing the requests, you= need to buffer the received key shares, and so part of your triage needs t= o worry about memory consumption in addition to the computational costs.  It’s not clear what compl= exity it would add; I would certainly be concerned if I were still an IPsec= implementor…

 

From: IPsec <ipsec-bounces@ietf.org> On Behalf Of Panos Kampanakis (pkampana)
Sent: Thursday, June 18, 2020 9:32 AM
To: Dang, Quynh H. (Fed) <quynh.dang=3D40nist.gov@dmarc.ietf.org&= gt;; Valery Smyslov <smyslov.ietf@gmail.com>; 'ipsecme mailing list' = <ipsec@ietf.org>
Subject: Re: [IPsec] Maximum sizes of IKEv2 messages and UDP message= s ?

 

Hi Quynh, <= /span>

 

> An obvious questi= on is that what is the performance impact from this large KEM using the app= roaches above when compared with a KEM (if its public key and ciphertext ar= e around 1,400-1,600 bytes in total) (assuming a pq signature algorithm has a small signature and a small public key) whi= ch would work well in a normal IKEv2's implementation ?

> I guess the impac= t is small generally because an IPsec tunnel normally stays up for a long t= ime. Does my guess seem ok here ?

> Would there be so= me noticeable impact on a high-volume connections VPN server ?

> An obvious questi= on is that what is the performance impact from this large KEM using the app= roaches above when compared with a KEM (if its public key and ciphertext ar= e around 1,400-1,600 bytes in total) (assuming a pq signature algorithm has a small signature and a small public key) whi= ch would work well in a normal IKEv2's implementation ?

> I guess the impac= t is small generally because an IPsec tunnel normally stays up for a long t= ime. Does my guess seem ok here ?

> Would there be so= me noticeable impact on a high-volume connections VPN server ?

 

We tested this in the = context of TLS in https://eprint.iacr.org/2020/0= 71. For a tunnel that stays up for a long time (not just a few seconds = like HTTPS) and sends Megabytes of data or more, then the larger key+si= gnatures size are amortized over the tunnel data. What becomes more important then is the keygen, encap, decap, sign/v= erify time.

 

In other words, server= s that terminate a lot of connections at the same time will be impacted by = slower operations in the handshake (the server throughput drops), but their= tunnels that send a few more kilobytes of handshake data and magnitudes more over the tunnel are not significantl= y affected especially if we are talking about UDP and not TCP (with congest= ion control slowing down the handshake).

 

 

 

From: IPsec <ipsec-bounces@ietf.org> On Behalf Of Dang, Quynh H. (Fed)
Sent: Wednesday, June 17, 2020 12:37 PM
To: Valery Smyslov <smy= slov.ietf@gmail.com>; 'ipsecme mailing list' <ipsec@ietf.org>
Subject: Re: [IPsec] Maximum sizes of IKEv2 messages and UDP message= s ?

 

Thank y= ou Valery and thank you everyone who responded to me.

&n= bsp;

&n= bsp;

It look= s like if/when someone implements them and adds a large key and/or cipherte= xt KEM, the maximum IKEv2 message size must be adjusted if the existing imp= lementation does not already support the corresponding message size with the new KEM ( for an ephemeral key exc= hange, it contains a public key and a ciphertext) because I don't see any m= entioning of the maximum IKEv2 message size (it is an implementation specif= ic issue). 

&n= bsp;

Let's s= ay 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 wit= hout the 2 methods above.

&n= bsp;

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

&n= bsp;

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

&n= bsp;

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

&n= bsp;

Would t= here be some noticeable impact on a high-volume connections VPN server ?

&n= bsp;

Regards= ,

Quynh.&= nbsp;

This documents defines a new exchang= e, called Intermediate Exchange, for the Internet Key Exchange protocol Ver= sion 2 (IKEv2). This exchange can be used for transferring large amount of data in the process of IKEv2 Security Associa= tion (SA) establishment. Introducing Intermediate Exchange allows re-using = existing IKE Fragmentation mechanism, that helps to avoid IP fragmentation = of large IKE ...

tools.ietf.org

 

&n= bsp;

&n= bsp;

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 message= s ?

 

Hi Quinh,

 =

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

It specifically addresses your conce= rn about large public keys of PQ KE methods.<= /o:p>

 =

Actually, it’s generally OK to= have public keys/signatures up to 64Kbytes.<= /o:p>

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 ?<= /span>

 

Hi everyone,<= /o:p>

 <= /span>

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

 <= /span>

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

 <= /span>

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

 <= /span>

My guess is that some updates to the spec a= nd/or implementations would make them work. <= o:p>

 <= /span>

Your data points and discussions are apprec= iated.

 <= /span>

Regards,

Quynh. <= /o:p>

--_000_BN7PR11MB2641EC57D261F6DF13F3D702C19B0BN7PR11MB2641namp_-- From nobody Thu Jun 18 07:02:28 2020 Return-Path: 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 CD1543A1021 for ; Thu, 18 Jun 2020 07:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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=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 UOds9vdqBrh8 for ; Thu, 18 Jun 2020 07:02:24 -0700 (PDT) Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on2119.outbound.protection.outlook.com [40.107.91.119]) (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 4CE753A1020 for ; Thu, 18 Jun 2020 07:02:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LijXPw+fNeHRUR67aS6hNVizYACzuYBaT16j903OC2R0CKrNqZm77WSHWo6WMgLV7kc7FHWEqKT3RTXOayzJRySngYc1cDknM6prGxvc6jamzRnMkORhv7m7PSYXdWnBkkdte0w/yMd0Amcz+xxUy6vjyI2QlLlrlnAX0xz9awvbx98qKeodYM7QbrI8pH/u21B4pLwExZN96il/2KYROf36RCMFXWHnkPiJLYoXMt+PP69zHKJ4oGwttgb+kl2e1T7ibiUhApFA6iOwsk/D+/9JkWLa4FJvwffHeZPuZfARige4ahFW2x5OBZQLqThPEGvsw3XA0zyLC6ewKNHLQw== 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=qsz8liP0zah+uqizAq0je5qrx0AWEKDFTEocfo71BYg=; b=Q96XndUmJ9YBrbaqiEq8sp7pU8ioLKUiP2BqIyEdCGmJ1x3cwVC4G03+bi8o3pEpuv8taaZFEoNpwJ+s2R+VT+o14LU9anG9G4D+KAV1brvX8uQ3mxXI/Jr8toKVApSBmHJvq2wKqVSGspbqtS/seG1ZxbA3B2cQHU7PMCuWvGpsDPLNoAsaBJIbcXdwcVwZ78RvnHTKYkzV4KphPF9EbdeacunansK4odsOqsb8bJAMik6fkIawh3H20tH6k7k77CXQqAE2LTQwtm0fzBh/kL0tJ2L2wO/2CAUaI73Vv6ThJ7Sr48+8REmmeGVztmdYOOwGZ4gYSYGPctlU1a6Zkw== 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=qsz8liP0zah+uqizAq0je5qrx0AWEKDFTEocfo71BYg=; b=HgEPbjzNs2CaIF27BCDT57IqZJQN75B3ONCkHs/7F1XWqn+jxVSF9Vw4r3WnDvPwnsF8INDcvY2qnwJlH+/nM/vt/RkgoQqs6tg2lBhJQttTibT92SUSKz6CDgL5qwl/WG07bJ6y8O3GoweK8JJ6aQi/RM/G3QpC+FPbrIm91Hs= Received: from BY5PR09MB4755.namprd09.prod.outlook.com (2603:10b6:a03:24b::12) by BYAPR09MB2968.namprd09.prod.outlook.com (2603:10b6:a03:a2::10) 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 14:02:17 +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 14:02:17 +0000 From: "Dang, Quynh H. (Fed)" To: "Scott Fluhrer (sfluhrer)" , "Panos Kampanakis (pkampana)" , Valery Smyslov , 'ipsecme mailing list' Thread-Topic: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ? Thread-Index: AQHWRKwTbexJ5B/60kaRS2oRKSlgJqjc1UQAgAAH7FWAAYCSgIAABUVggAAD6eg= Date: Thu, 18 Jun 2020 14:02:17 +0000 Message-ID: References: , <059d01d644af$4f2c7ed0$ed857c70$@gmail.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; 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: 4bcf2ca9-49c2-41ad-c211-08d813903629 x-ms-traffictypediagnostic: BYAPR09MB2968: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0438F90F17 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: U4WR3sXWCr6RbtklHnGfPHR8pgFT6bEVSH45Amvj4QdoHEXEez5kpx8GIIXJR8RbgjTPsJWUviX5OjRRdNE1Cx9hlj1yx5D3WDwDYhbHAFwjkKXvk/18TY2terNKR53SdfdsdphyIcovPPHyYJHjvBA4Q1dCHPgxjNSdZ6rNsF8dWggLjSFV8i2ICTY5Rw9ne3ckSdjEebM1iFaqc2rmsj3ZryajEyPHulsRq6VnKr2oKFvqiQWU5X60ZkHYa8WTMOe9nE6OhSUMUN4hVNRGmXJv+7mdwpFi22bUUuUMeSTkZxDgpYDKH58IF7X//xi7wJ1YVQxfIH/RGLvAl1qzr0uG9cIsQp3gJUT933i3yZMXmz7PxhAt4ulcVw4cLHOFTcf2wlAzgD44KxfYLXhy1Q== 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)(376002)(346002)(136003)(396003)(86362001)(15650500001)(55016002)(966005)(71200400001)(9686003)(7696005)(19627405001)(5660300002)(19627235002)(53546011)(478600001)(66574015)(33656002)(8936002)(76116006)(316002)(186003)(91956017)(66946007)(66476007)(66446008)(64756008)(66556008)(2906002)(110136005)(6506007)(52536014)(83380400001)(166002)(8676002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: MwH770ea6nzXhrAgWWHZjKfv8mAjpXg+14i7Gv1yTRf1I+5eOvAK7j4XRDWdyOtIDu/4Gmiv8Hk6gcpMFkct4CgyKHLYicsCprdjc2kwNQh98FJIllSurMAKMvhFaDgD1PsqkxhlzCoh7UQBWcZuybd1z9dHHhFFYX0tTGaDc2HoGt9KvFsgRvNC0x+6qVqZAx99Oyytt+s0bS/iDdsbO/4L5fqXf7wc6Q5NNWdhCzpbZk3/BrpTmlzanjhZieJ2M0OaDZ6ssQuspqfnwogbY5B409um25AEsVSvoEFB0D69Ujb27TWQc6pW6vVg6gBgU4G8fHnBqEmz5LcVszwoP2hVi9bW7qWfYLI+10m/3THJCq9/1AlUKlnOqaH69epXyUhiutfWMGmtbWcmxRCadSytgZbJ+Y1mdsBFscTQtJVLQm7DY/wbzoWnF3gojk1U2TS3ji9E3ZOou5jwe0AP9U6sb3hgVsZlpDBvuzcv2DHsFIxEZYIKEEBNs93Ub8KY x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BY5PR09MB4755DB61CF3B8CF894ADC388F39B0BY5PR09MB4755namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 4bcf2ca9-49c2-41ad-c211-08d813903629 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2020 14:02:17.6864 (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: ATl6rZ5ATxaO3ijIQNo0qLXv6sjOa1kcZ9Wu21kPadACG9gNGrL46Dr0nmz/jqHQ X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR09MB2968 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 14:02:27 -0000 --_000_BY5PR09MB4755DB61CF3B8CF894ADC388F39B0BY5PR09MB4755namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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 cha= in. The impact varies from one situation to another I think. Regards, Quynh. ________________________________ From: Scott Fluhrer (sfluhrer) Sent: Thursday, June 18, 2020 9:51 AM To: Panos Kampanakis (pkampana) ; Dang, Quynh H. (Fed) = ; Valery Smyslov ; 'ipsecme ma= iling list' Subject: RE: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ? Speaking as a previous IPsec implementor, the biggest concern I had over IK= E performance was in the =91flash crowd=92 scenario; that is, you=92re an I= Psec-based security gateway, and then suddenly everyone wanted to negotiate= with you. This can happen if it=92s 8:00 AM (and everyone just arrived at= work), or if you=92re a back-up gateway, and then the primary gateway just= failed. That scenario requires a rather lot of care to avoid =93congestion=94, that= is, where you=92re so busy answering IKE messages that you don=92t get eno= ugh time to complete any exchange before the IKE exchange times out. What = you end up doing is effectively triage; deliberately ignore some exchanges = for the moment so that you can complete others. Now, if you have large key shares, what that would add to the scenario is m= emory management; while processing the requests, you need to buffer the rec= eived key shares, and so part of your triage needs to worry about memory co= nsumption in addition to the computational costs. It=92s not clear what co= mplexity it would add; I would certainly be concerned if I were still an IP= sec implementor=85 From: IPsec On Behalf Of Panos Kampanakis (pkampan= a) Sent: Thursday, June 18, 2020 9:32 AM To: Dang, Quynh H. (Fed) ; Valery S= myslov ; 'ipsecme mailing list' Subject: Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ? Hi Quynh, > An obvious question is that what is the performance impact from this larg= e KEM using the approaches above when compared with a KEM (if its public ke= y and ciphertext are around 1,400-1,600 bytes in total) (assuming a pq sign= ature algorithm has a small signature and a small public key) which would w= ork well in a normal IKEv2's implementation ? > I guess the impact is small generally because an IPsec tunnel normally st= ays up for a long time. Does my guess seem ok here ? > Would there be some noticeable impact on a high-volume connections VPN se= rver ? > An obvious question is that what is the performance impact from this larg= e KEM using the approaches above when compared with a KEM (if its public ke= y and ciphertext are around 1,400-1,600 bytes in total) (assuming a pq sign= ature algorithm has a small signature and a small public key) which would w= ork well in a normal IKEv2's implementation ? > I guess the impact is small generally because an IPsec tunnel normally st= ays up for a long time. Does my guess seem ok here ? > Would there be some noticeable impact on a high-volume connections VPN se= rver ? We tested this in the context of TLS in https://eprint.iacr.org/2020/071. For a tunnel that stays up for a long time (not just a few seconds l= ike HTTPS) and sends Megabytes of data or more, then the larger key+signatu= res size are amortized over the tunnel data. What becomes more important th= en is the keygen, encap, decap, sign/verify time. In other words, servers that terminate a lot of connections at the same tim= e will be impacted by slower operations in the handshake (the server throug= hput drops), but their tunnels that send a few more kilobytes of handshake = data and magnitudes more over the tunnel are not significantly affected esp= ecially if we are talking about UDP and not TCP (with congestion control sl= owing down the handshake). From: IPsec > On Beha= lf Of Dang, Quynh H. (Fed) Sent: Wednesday, June 17, 2020 12:37 PM To: Valery Smyslov >;= 'ipsecme mailing list' > Subject: Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ? 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 c= iphertext KEM, the maximum IKEv2 message size must be adjusted if the exist= ing 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 m= essage size (it is an implementation specific issue). Let's say after 10 or 15 years from now, the group trusts the security of s= ome PQ KEM and signature algorithms and would like to use them in normal IK= Ev2 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 signat= ure algorithm has a small signature and a small public key) which would wor= k well in a normal IKEv2's implementation ? I guess the impact is small generally because an IPsec tunnel normally stay= s up for a long time. Does my guess seem ok here ? Would there be some noticeable impact on a high-volume connections VPN serv= er ? Regards, Quynh. draft-ietf-ipsecme-ikev2-intermediate-04 - Intermediate Exchange in the IKE= v2 Protocol This documents defines a new exchange, called Intermediate Exchange, for th= e Internet Key Exchange protocol Version 2 (IKEv2). This exchange can be us= ed for transferring large amount of data in the process of IKEv2 Security A= ssociation (SA) establishment. Introducing Intermediate Exchange allows re-= using existing IKE Fragmentation mechanism, that helps to avoid IP fragment= ation of large IKE ... tools.ietf.org ________________________________ From: Valery Smyslov = > Sent: Wednesday, June 17, 2020 9:57 AM To: Dang, Quynh H. (Fed) >;= 'ipsecme mailing list' > 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 met= hods. Actually, it=92s 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 need= ed. Regards, Valery.. From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Dang, Quynh H. (Fe= d) 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 message= s 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 lim= it. As you know some of the post quantum cryptographic candidates in our standa= rdization process have large or very large public key , signature and/or ci= phertext 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. --_000_BY5PR09MB4755DB61CF3B8CF894ADC388F39B0BY5PR09MB4755namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
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 + ciphert= ext 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. 

Regards,
Quynh. 
From: Scott Fluhrer (sfluhr= er) <sfluhrer=3D40cisco.com@dmarc.ietf.org>
Sent: Thursday, June 18, 2020 9:51 AM
To: Panos Kampanakis (pkampana) <pkampana@cisco.com>; Dang, Qu= ynh H. (Fed) <quynh.dang@nist.gov>; Valery Smyslov <smyslov.ietf@g= mail.com>; 'ipsecme mailing list' <ipsec@ietf.org>
Subject: RE: [IPsec] Maximum sizes of IKEv2 messages and UDP message= s ?
 

Speaking as a previous IPsec implementor, the bigg= est concern I had over IKE performance was in the =91flash crowd=92 scenari= o; that is, you=92re an IPsec-based security gateway, and then suddenly eve= ryone wanted to negotiate with you.  This can happen if it=92s 8:00 AM (and everyone just arrived at work), or if yo= u=92re a back-up gateway, and then the primary gateway just failed.

 

That scenario requires a rather lot of care to avo= id =93congestion=94, that is, where you=92re so busy answering IKE messages= that you don=92t get enough time to complete any exchange before the IKE e= xchange times out.  What you end up doing is effectively triage; deliberately ignore some exchanges for the moment s= o that you can complete others.

 

Now, if you have large key shares, what that would= add to the scenario is memory management; while processing the requests, y= ou need to buffer the received key shares, and so part of your triage needs= to worry about memory consumption in addition to the computational costs.  It=92s not clear what comple= xity it would add; I would certainly be concerned if I were still an IPsec = implementor=85

 

From: IPsec <ipsec-bounces@ietf.org> = On Behalf Of Panos Kampanakis (pkampana)
Sent: Thursday, June 18, 2020 9:32 AM
To: Dang, Quynh H. (Fed) <quynh.dang=3D40nist.gov@dmarc.ietf.org&= gt;; Valery Smyslov <smyslov.ietf@gmail.com>; 'ipsecme mailing list' = <ipsec@ietf.org>
Subject: Re: [IPsec] Maximum sizes of IKEv2 messages and UDP message= s ?

 

Hi Quynh,

 

> An obvious ques= tion is that what is the performance impact from this large KEM using the a= pproaches 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 publi= c key) which would work well in a normal IKEv2's implementation ?

> I guess the imp= act 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 ?

> An obvious ques= tion is that what is the performance impact from this large KEM using the a= pproaches 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 publi= c key) which would work well in a normal IKEv2's implementation ?

> I guess the imp= act 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 ?

 

We tested this in th= e context of TLS in https://eprint.iacr.org/2020/071. For a tunnel that stays up for a long= time (not just a few seconds like HTTPS) and sends Megabytes of data or mo= re, then the larger key+signatures size are amortized over the tunnel d= ata. What becomes more important then is the keygen, encap, decap, sign/verify time.

 

In other words, serv= ers that terminate a lot of connections at the same time will be impacted b= y slower operations in the handshake (the server throughput drops), but the= ir tunnels that send a few more kilobytes of handshake data and magnitudes more over the tunnel are not significantl= y affected especially if we are talking about UDP and not TCP (with congest= ion control slowing down the handshake).

 

 

 

From: IPsec <ipsec-bounces@ietf.org> On Behalf Of Dang, Quynh H. (Fed)
Sent: Wednesday, June 17, 2020 12:37 PM
To: Valery Smyslov <smy= slov.ietf@gmail.com>; 'ipsecme mailing list' <ipsec@ietf.org>
Subject: Re: [IPsec] Maximum sizes of IKEv2 messages and UDP message= s ?

 

Than= k you Valery and thank you everyone who responded to me.

&nbs= p;

&nbs= p;

It l= ooks like if/when someone implements them and adds a large key and/or ciphe= rtext 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 exc= hange, it contains a public key and a ciphertext) because I don't see any m= entioning of the maximum IKEv2 message size (it is an implementation specif= ic issue). 

&nbs= p;

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.

&nbs= p;

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

&nbs= p;

An o= bvious 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 s= mall public key) which would work well in a normal IKEv2's implementation ?=  

&nbs= p;

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

&nbs= p;

Woul= d there be some noticeable impact on a high-volume connections VPN server ?=

&nbs= p;

Rega= rds,

Quyn= h. 

This documents defines a new exc= hange, 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 Ass= ociation (SA) establishment. Introducing Intermediate Exchange allows re-us= ing existing IKE Fragmentation mechanism, that helps to avoid IP fragmentat= ion of large IKE ...

tools.ietf.org

 

&nbs= p;

&nbs= p;

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 message= s ?

 

Hi Quinh,

 <= /span>

please look at the  draft-i= etf-ipsecme-ikev2-multiple-ke-00.

It specifically addresses your c= oncern about large public keys of PQ KE methods.

 <= /span>

Actually, it=92s 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.

 <= /span>

Regards,

Valery..

 <= /span>

 <= /span>

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 ?<= /span>

 

Hi everyone,

 

I am interested in knowing what are typi= cal maximum sizes for IKEv2 messages and UDP messages in implementations.&n= bsp;

 

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

 

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

 

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

 

Your data points and discussions are app= reciated.

 

Regards,=

Quynh. 

--_000_BY5PR09MB4755DB61CF3B8CF894ADC388F39B0BY5PR09MB4755namp_-- From nobody Thu Jun 18 08:42:12 2020 Return-Path: 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 D3E433A0A02 for ; Thu, 18 Jun 2020 08:42: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, 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 8bJK0VaVJX0H for ; Thu, 18 Jun 2020 08:42:09 -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 5A6193A0A0A for ; Thu, 18 Jun 2020 08:42:02 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 49nmQH6y5kzMvh; Thu, 18 Jun 2020 17:41:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1592494919; bh=lfGzxPTRmQjVSYBt++viLnEz6z3t7IaDUKJfNQ2xbMY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=mBuVfpuHF+nuD819qzqYP7Bzq919VKlInUEs1PrBKEOrAmtOrzKHtr7Bru5oy8vzJ 5WT4IQ9nzyX7tUg6jWNKsBATmnslxeJ1B5zPu3hW9BXnlsw1yUejziNs1OHjZsaNPl koPQowjSQ7f5KJmjPD1f+dOX2Cbn0Rj7mLuwRInw= 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 oU3U9fpFiUhn; Thu, 18 Jun 2020 17:41:57 +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 17:41:57 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 80C8B6020D8B; Thu, 18 Jun 2020 11:41:56 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 766A282301; Thu, 18 Jun 2020 11:41:56 -0400 (EDT) Date: Thu, 18 Jun 2020 11:41:56 -0400 (EDT) From: Paul Wouters To: "Panos Kampanakis (pkampana)" cc: "Dang, Quynh H. (Fed)" , Valery Smyslov , 'ipsecme mailing list' In-Reply-To: Message-ID: References: , <059d01d644af$4f2c7ed0$ed857c70$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 15:42:11 -0000 On Thu, 18 Jun 2020, Panos Kampanakis (pkampana) wrote: > > 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 ? > > We tested this in the context of TLS in https://eprint.iacr.org/2020/071. For a tunnel that stays up for a long time (not just a few seconds like > HTTPS) and sends Megabytes of data or more, then the larger key+signatures size are amortized over the tunnel data. What becomes more important > then is the keygen, encap, decap, sign/verify time. > > In other words, servers that terminate a lot of connections at the same time will be impacted by slower operations in the handshake (the server > throughput drops), but their tunnels that send a few more kilobytes of handshake data and magnitudes more over the tunnel are not significantly > affected especially if we are talking about UDP and not TCP (with congestion control slowing down the handshake). For libreswan, we recently went through performance enhancements, and we found a number of issues in our code that once meassured, were easilly fixed. There are still some linear lookups left in the Linux kernel for policies/states, but we found that with about 1000 users that keep connecting/disconnecting, it wasn't a big problem yet. Hopefully, more clients will use Session Resumption, which would at least cut out the (EC)DiffieHellman part of starting a session again, but on larger servers with that many clients, there tends to not be a guaranteed you can connect to the same server which can resume your session. Also, I'm not sure if we need to further postquantum prood the resumption mechanism (I don't think so, but I'm not a licensed cryptographer) Paul From nobody Thu Jun 18 09:23:51 2020 Return-Path: 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 ; 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 ; 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 ; 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 (EDT) From: Paul Wouters To: "Dang, Quynh H. (Fed)" cc: "Scott Fluhrer (sfluhrer)" , "Panos Kampanakis (pkampana)" , Valery Smyslov , 'ipsecme mailing list' In-Reply-To: Message-ID: References: , <059d01d644af$4f2c7ed0$ed857c70$@gmail.com> , MIME-Version: 1.0 Content-Type: text/plain; charset=Windows-1252; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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, youre an > IPsec-based security gateway, and then suddenly everyone wanted to negotiate with you. This can happen if its 8:00 AM (and everyone just > arrived at work), or if youre 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 From nobody Thu Jun 18 09:42:28 2020 Return-Path: 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 ; 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 ; 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 ; 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)" To: "paul@nohats.ca" CC: "Scott Fluhrer (sfluhrer)" , "Panos Kampanakis (pkampana)" , Valery Smyslov , 'ipsecme mailing list' 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: References: , <059d01d644af$4f2c7ed0$ed857c70$@gmail.com> , , In-Reply-To: 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: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 16:42:27 -0000 --_000_BY5PR09MB47555C6C46D68B3A496064AAF39B0BY5PR09MB4755namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Paul, I don't know 10,000 or 20,000 users trying to connect to a VPN server aroun= d the same time where each pair is 300 kilobytes or more would have a notic= eable 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 onc= e in a while for some VPN network. Quynh. ________________________________ From: Paul Wouters Sent: Thursday, June 18, 2020 12:23 PM To: Dang, Quynh H. (Fed) Cc: Scott Fluhrer (sfluhrer) ; Panos Kampanakis (pkampa= na) ; Valery Smyslov ; 'ipsecme= mailing list' 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 + ciphertex= t 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 =91flash crowd=92 scenario; that is, you=92re an > IPsec-based security gateway, and then suddenly everyone wanted to negoti= ate with you. This can happen if it=92s 8:00 AM (and everyone just > arrived at work), or if you=92re 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 --_000_BY5PR09MB47555C6C46D68B3A496064AAF39B0BY5PR09MB4755namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Paul,

I don't know 10,000 or 20,000 users trying to connect to a VPN server aroun= d the same time where each pair is 300 kilobytes or more would have a notic= eable 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 onc= e 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 Kampa= nakis (pkampana) <pkampana@cisco.com>; Valery Smyslov <smyslov.iet= f@gmail.com>; 'ipsecme mailing list' <ipsec@ietf.org>
Subject: Re: [IPsec] Maximum sizes of IKEv2 messages and UDP message= s ?
 
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 + ci= phertext and public key + sig).  The latter public key may be repl= aced 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 ov= er IKE performance was in the =91flash crowd=92 scenario; that is, you=92re= an
> IPsec-based security gateway, and then suddenly everyone wanted to neg= otiate with you.  This can happen if it=92s 8:00 AM (and everyone just=
> arrived at work), or if you=92re a back-up gateway, and then the prima= ry 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 "redir= ect if at
2000 clients".

Paul
--_000_BY5PR09MB47555C6C46D68B3A496064AAF39B0BY5PR09MB4755namp_-- From nobody Thu Jun 18 09:52:53 2020 Return-Path: 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 ; 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 ; 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 ; 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 (EDT) From: Paul Wouters To: "Dang, Quynh H. (Fed)" cc: "Scott Fluhrer (sfluhrer)" , "Panos Kampanakis (pkampana)" , Valery Smyslov , 'ipsecme mailing list' In-Reply-To: Message-ID: References: , <059d01d644af$4f2c7ed0$ed857c70$@gmail.com> , , MIME-Version: 1.0 Content-Type: text/plain; charset=Windows-1252; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From nobody Thu Jun 18 11:03:34 2020 Return-Path: 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 202893A0DBA; Thu, 18 Jun 2020 11:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi 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 rJudOLeJ8ph5; Thu, 18 Jun 2020 11:03:29 -0700 (PDT) Received: from meesny.iki.fi (meesny.iki.fi [195.140.195.201]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00E9B3A0DB8; Thu, 18 Jun 2020 11:03:28 -0700 (PDT) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: kivinen) by meesny.iki.fi (Postfix) with ESMTPSA id 5E5552017A; Thu, 18 Jun 2020 21:03:25 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1592503405; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=d9m9yDzt/JyOB79W5UhZ0EKNvEH0zSku1xTchReE1Qo=; b=pZaHbi9R4y8mxmwWKfZUzQ5ngHFHbzRXln+qmXrEbzWC9wbxUZZrnj6Gnt9VyOIgVT/kPi mGWQ6yKKoARhw//swEJqEiQyTwVQhnMDILTC87A/Ekr2I1hN3BrR8GITz/jmDBJYIIxjga Y4C3PVqgxX+kiDgsnF2wKy/DD/Lbavo= Received: by fireball.acr.fi (Postfix, from userid 15204) id 615FE25C145E; Thu, 18 Jun 2020 21:03:23 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24299.44139.322739.654469@fireball.acr.fi> Date: Thu, 18 Jun 2020 21:03:23 +0300 From: Tero Kivinen To: Toerless Eckert Cc: Paul Wouters , "ipsec\@ietf.org WG" , Michael Richardson , draft-ietf-anima-autonomic-control-plane@ietf.org, Yoav Nir In-Reply-To: <20200618015733.GG16371@faui48f.informatik.uni-erlangen.de> References: <31896.1582680023@localhost> <8A7ABA50-0ACB-41A2-9AE5-4EE15DB86F3A@gmail.com> <27926.1582739768@localhost> <0E1FEB34-E329-4686-80CE-0DFE253409C2@gmail.com> <20200617170403.GA18378@faui48f.informatik.uni-erlangen.de> <20200617183127.GX16371@faui48f.informatik.uni-erlangen.de> <872.1592440656@localhost> <20200618015733.GG16371@faui48f.informatik.uni-erlangen.de> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 46 min X-Total-Time: 55 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1592503405; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=d9m9yDzt/JyOB79W5UhZ0EKNvEH0zSku1xTchReE1Qo=; b=igteKdK/x9V6bKL3mxHcypUiRai2dpvYcxyUB8hRboIiYReYQsTM0h2G0f87XhzbD92tgi FXx723K6VrSZHywTm/M88OYr85wcVqtRr95MCQbWP/EX5N+QuDgb2SR5LPg329j+SkgQ7y POHkBx6LMtbOSLzMayaCqOfbD1T3oyU= ARC-Seal: i=1; s=meesny; d=iki.fi; t=1592503405; a=rsa-sha256; cv=none; b=wSB/eKbJjCc++v1+ihBbviNUSRvR1AwRihxVAWyFzmd2bU511EutHHk5IaL3VLKS3XYopy AHcqxC5GNYJOIIZXz30Rx4peC3epn9+iJLZhP3F+lduD6MKUHnXuHyrpZPAf8jc3Ty6m9y +wC9fb7PQxcdQiGwV9jBKU/jqxZbVBk= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 18:03:32 -0000 [talking as individual and one of RFC7296 authors, not as WG chair]. Toerless Eckert writes: > On Wed, Jun 17, 2020 at 08:55:12PM -0400, Paul Wouters wrote: > > The RFC states: > > > > The USE_TRANSPORT_MODE notification MAY be included in a request > > message that also includes an SA payload requesting a Child SA. It > > requests that the Child SA use transport mode rather than tunnel mode > > for the SA created. If the request is accepted, the response MUST > > also include a notification of type USE_TRANSPORT_MODE. If the > > responder declines the request, the Child SA will be established in > > tunnel mode. At this point the responder already created an Child SA in tunnel mode, and when the initiator receives that message from the responder it will also create the Child SA in tunnel mode. Responder might already be sending traffic at this point. This means both initiator and responder MUST implement tunnel mode, as otherwise they cannot perform those actions. Meaning as the fallback from the transport mode is tunnel mode, all implementations MUST implement it even if it not explictly said in the RFC. > > If this is unacceptable to the initiator, the initiator > > MUST delete the SA. This thing happens after the Child SA is created. I.e., now the initiator will check whether the Child SA created was following its policy, and it is completely valid for the initiators policy to say that must use transport mode, and then it will delete the SA as it was not following its policy. It still means that the initiator implementation MUST implement tunnel mode, but it does not have to USE it if it does not feel like doing that. The MUST/SHOULD etc only give requirements for the implementors, i.e., what features MUST or SHOULD be implemented and what MAY be implemented. In the RFCs we cannot use those keywords to instruct adminstrators/users what they should use. Quite often, especially in the security considerations section, we try to give requirements to the users, but we need to be very carefull not to do that. We can give information to users saying "do not use low entrypy passwords as PSK as they are known to be unsafe", but we cannot say MUST NOT use low entropy passwords, as there is no easy for for implementor to enforce that. For every single MUST or SHOULD and especially MUST NOT or SHOULD NOT you are writing to the RFC, you should think how can you answer to question from the customer who says, "show me the lines in your implementation which implements this MUST or SHOULD". For MUST and SHOULDs, that is usully still quite easy, but when someone asks "Show me the lines of code where you implement: This notification MUST NOT BE sent by an entity that may be replicated".... (and yes, I have had incoming customer support case, where they asked for every single MUST/SHOULD/MUST NOT/SHOULD NOT where it was implemented in the source of our toolkit). > > But note that the responder has already installed the IPsec SA in tunnel > > mode. So if the initiator finds that unacceptable, it must send the > > delete. During all this time, connectivity between the nodes will be > > blocked. The intention here is that transport mode is optional and > > should not be mandated by other protocols. Otherwise, the IKEv1 > > style negoation of transport OR tunnel mode would have been kept. Also the delete notifications might get lost, and it might takes tens of seconds, or even minutes before the initiator can finally tell the responder that the Child SA that didn't follow its policy is deleted. > How about my mails ask that i read this text such that the initiator will > delete the SA (not only client SA) if transport mode is not supported > be responder. Aka: the last two sentences to me describe exactly the > case where the initiator can/want only support transport mode. Initiator and responder can delete whatever SAs they like whenever they like. That does not matter to the actual case here. The issue there is that if the responder does not want to do transport mode, then SA will be created in tunnel mode, and the initiator must be able to cope with tunnel mode ESP packets it is receiving from the responder. I.e., it needs to be able to implement tunnel mode as much it understands those packets and does something to them (dropping them is fine, as if his policy says he wants to get transport mode packets and do not allow tunnel mode packets, then it is fine to have policy dropping all tunnel mode packets). > Aka: i can not read your interpretation into this text. Anyways, this discussion is not really useful. If the other end does not support transport mode (as it is allowed to do by IKEv2, as transport mode is optional), there is nothing you can do to make it support transport mode, and deleting the Child SA will just cause initiator to try again few seconds later when it gets next packet to that direction, with exactly same bad result. It would be much better to simply say that SHOULD use transport mode, as it is more efficient for GRE, but if other end does not support transport mode, using tunnel mode still gets the connectivity, even when we are wasting few bytes. In IPsec we had so much issues in IKEv1 where every single option and feature knob needed to be exactly right to get any connectivity, that in IKEv2 we tried to get rid of exact negotiation things, instead we propose something, and we do have fallback to go if other end does not accept our proposel. Transport -> tunnel is one of those. IPcomp -> no IPcomp is another, traffic selector narrowing is third, getting rid of negotiated lifetimes for SAs was yet another one etc. The basic idea is that when you finish IKEv2 exchange you have "usable" child SA you can use to send and receive traffic. Whether it was exactly what you wanted is another thing, and whether you can accept that, is initiator choise, and if he cannot accept it, he can delete the SA and be without connectivity compared to non-optimal connectivity. Also as I have understood that your nodes are security gateways (not hosts, as they do forward packets from other nodes) the RFC4301 already says that they: b) A security gateway MUST support tunnel mode and MAY support transport mode. If it supports transport mode, that should be used only when the security gateway is acting as a host, e.g., for network management, or to provide security between two intermediate systems along a path. Meaning tunnel mode is mandatory to implement in those devices anyways. The use of tunnel mode is completely different matter then. > Please answer the other questions from my reply mail. > > > So I would recommend to follow the intention of RFC 7296 and not make > > up your own restrictions. > > Again, i had a lot of arguments in my email that i need to see answers > to so that we can make progress here. I do disagree with Paul that I think profiles can require certain optional features to be implemented and used from the base standard, if it makes sense in there. That does not mean that you can remove features from the base standards, so even if you do say you use GRE with transport mode, the IPsec implementations used still need to implement tunnel mode too, as that is part of the base standard, but of course you do not need to allow that to be configured, so detecting use of that might be difficult. So I think it is ok to say that SHOULD (or even MUST) implement transport mode for GRE, but it is not ok to say that tunnel mode would be OPTIONAL, as that would make it so that it cannot connect to the conforming IKEv2 implementations not supporting transport mode. We had similar discussion in the RFC7815 minimal IKEv2. That document really only covered the Shared key authentication even when the base IKEv2 do require also PKIX certificates and RSA signatures. It does use one of the mandatory to implement features of the IKEv2, thus it can talk to all conforming IKEv2 implementations, thus interoperability is there, but cannot do both of the required authentication methods, which does not cause problems as full implementations need to support both anyways. -- kivinen@iki.fi From nobody Thu Jun 18 13:19:22 2020 Return-Path: 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 222043A0D09 for ; Thu, 18 Jun 2020 13:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-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 OG1vcEX5Df6v for ; Thu, 18 Jun 2020 13:19:18 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 1FD593A0F57 for ; Thu, 18 Jun 2020 13:19:18 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id t13so5018242wrs.2 for ; Thu, 18 Jun 2020 13:19:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8ahNj9HWZ9A5zbEw62uruB581SOywM+WDOOKex3IY7k=; b=AWIwkALPgeRB7lv9RCPb1IeYxv4LjdAPRiGo87I01cyTW77AOt6GRimM/RUREQ5UUk t2PQfvXdmUWGH9X5Q7vCL0aZV8WtyqN/U9Xfpdmcv3y/61NLbDk6S8TFGKB2EMZm/uI1 aPtYflsAbP9SHt0Z7YGuFwrSCHPYZIVQj8T+mk8aJ7UnfUc7t4ent9cIHJin3ZOwgoQR tfA6ppVEzr7neDiHTI+aLEKO9uVh6SPb5g882Q+kFY694qreO+oK5hicbNxCpFnlrwc/ BQL4jEvtsIk11XcTsW9umID1G34x4qcpU4LXNMEByzP5q2bRlVTivxl6Vc28CYrt3WXs dN0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8ahNj9HWZ9A5zbEw62uruB581SOywM+WDOOKex3IY7k=; b=O4jsp9Vsazge+atfuvfIB2yR9K5hmYUmXnvr1rXIqmy1H0cJ3wlUMGydMHbhAL6zCE GsK2Op+Vu0Lp53WVff/U8sDnuAmupgmUa98k0ZjLtfwoD5U5brZ6hnBxbZre9Xy+MDvf JQXdDbDJMdqkunPIkhIgO7YXFWuNaTiPBYBrihJ3avcQmse29HibS/iCkZuQNra3dFGX eoY0IZ8HGOfwkXTEfrBR3fCERY09gGqWqxppSi1w0ZsPVw6X50hyP0OeOqEs9gxwXOEp K5VXRQ7cL1tUDrjF8qvbk3a5wwWC2gxraG+c0HKP1Zfe2iNtv7oB3XXvKCkGqDOH+Yp0 vlow== X-Gm-Message-State: AOAM531DWKtgSnitoMuzqJ1FAK7cPB1SIYGOJ3/bDLrT4et1uWV7TeJx wnAub66hqxty7r5WLwAopMo= X-Google-Smtp-Source: ABdhPJzGqLpgSTN0auMMw/DJUHwSibyHiA11x9gQZf54q+SE0fj2t6t8BKdiQlVG0kxE/ycBhs/QWg== X-Received: by 2002:a5d:4bc5:: with SMTP id l5mr259710wrt.104.1592511556548; Thu, 18 Jun 2020 13:19:16 -0700 (PDT) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id k14sm4383162wrq.97.2020.06.18.13.19.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jun 2020 13:19:13 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Yoav Nir In-Reply-To: <24299.44139.322739.654469@fireball.acr.fi> Date: Thu, 18 Jun 2020 23:19:11 +0300 Cc: Toerless Eckert , Paul Wouters , "ipsec@ietf.org WG" , Michael Richardson Content-Transfer-Encoding: quoted-printable Message-Id: <94DE2624-828D-4555-B63B-F5569AFA6122@gmail.com> References: <31896.1582680023@localhost> <8A7ABA50-0ACB-41A2-9AE5-4EE15DB86F3A@gmail.com> <27926.1582739768@localhost> <0E1FEB34-E329-4686-80CE-0DFE253409C2@gmail.com> <20200617170403.GA18378@faui48f.informatik.uni-erlangen.de> <20200617183127.GX16371@faui48f.informatik.uni-erlangen.de> <872.1592440656@localhost> <20200618015733.GG16371@faui48f.informatik.uni-erlangen.de> <24299.44139.322739.654469@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 20:19:20 -0000 [talking as another individual and co-author of RFC7296, not as the = other chair] > On 18 Jun 2020, at 21:03, Tero Kivinen wrote: >=20 > [talking as individual and one of RFC7296 authors, not as WG chair]. >=20 > Toerless Eckert writes: >> On Wed, Jun 17, 2020 at 08:55:12PM -0400, Paul Wouters wrote: >>> The RFC states: >>>=20 >>> The USE_TRANSPORT_MODE notification MAY be included in a request >>> message that also includes an SA payload requesting a Child SA. = It >>> requests that the Child SA use transport mode rather than tunnel = mode >>> for the SA created. If the request is accepted, the response MUST >>> also include a notification of type USE_TRANSPORT_MODE. If the >>> responder declines the request, the Child SA will be established = in >>> tunnel mode. >=20 > At this point the responder already created an Child SA in tunnel > mode, and when the initiator receives that message from the responder > it will also create the Child SA in tunnel mode. Responder might > already be sending traffic at this point. >=20 > This means both initiator and responder MUST implement tunnel mode, as > otherwise they cannot perform those actions. Meaning as the fallback > from the transport mode is tunnel mode, all implementations MUST > implement it even if it not explictly said in the RFC. I half agree. RFC 7296 describes IKEv2, not IPsec. An IKEv2 = implementation must support the creation of a tunnel-mode Child SA. It = may configure an IPsec layer that does not support tunnel-mode. I think it=E2=80=99s compliant with the letter if not the spirit of RFC = 7296 to have a specialized IKEv2 implementation that can negotiate a = tunnel mode SA, but immediately deletes such an SA if it is created, and = I think such an implementation will also be compliant if it rejects any = CREATE_CHILD_SA request that does not include the USE_TRANSPORT_MODE = notification. Of course none of us would use such an implementation in our VPN = gateway, but it can be appropriate for special uses, such as = host-to-host within a datacenter. Having said that, supporting tunnel mode as a fallback and making = transport a SHOULD is still a good idea. Tunnel mode has a per-packet = extra cost of 20 or 40 bytes, but it=E2=80=99s generally better than no = communications at all. Yoav From nobody Thu Jun 18 14:07:21 2020 Return-Path: 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 0D5B63A0F8F; Thu, 18 Jun 2020 14:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 W03-iMiNkLYe; Thu, 18 Jun 2020 14:07:18 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB8343A0F91; Thu, 18 Jun 2020 14:07:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 1C698389CE; Thu, 18 Jun 2020 17:04:40 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id BEEgSAEM72l6; Thu, 18 Jun 2020 17:04:39 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id EFF5B389CD; Thu, 18 Jun 2020 17:04:38 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 25D9D24C; Thu, 18 Jun 2020 17:07:15 -0400 (EDT) From: Michael Richardson To: Tero Kivinen , Toerless Eckert , Paul Wouters , "ipsec\@ietf.org WG" , draft-ietf-anima-autonomic-control-plane@ietf.org, Yoav Nir In-Reply-To: <24299.44139.322739.654469@fireball.acr.fi> References: <31896.1582680023@localhost> <8A7ABA50-0ACB-41A2-9AE5-4EE15DB86F3A@gmail.com> <27926.1582739768@localhost> <0E1FEB34-E329-4686-80CE-0DFE253409C2@gmail.com> <20200617170403.GA18378@faui48f.informatik.uni-erlangen.de> <20200617183127.GX16371@faui48f.informatik.uni-erlangen.de> <872.1592440656@localhost> <20200618015733.GG16371@faui48f.informatik.uni-erlangen.de> <24299.44139.322739.654469@fireball.acr.fi> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 21:07:20 -0000 --=-=-= Content-Type: text/plain Tero Kivinen wrote: > The MUST/SHOULD etc only give requirements for the implementors, i.e., > what features MUST or SHOULD be implemented and what MAY be > implemented. In the RFCs we cannot use those keywords to instruct > adminstrators/users what they should use. Sigh. Again. The Autonomic Control Plane is established by automatic mechanisms, not by "administrators". That is, we have a protocol that acts as the "administrator" in this case. So, yes, we (ANIMA) can use BCP14 to say what the "configured" policy will be. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl7r14IACgkQgItw+93Q 3WVqogf+I0UZnjwh9NIw8YRj8cHOlj+UiXb433gPe71hwAg96xWHC42NeS2s3Dv+ kTfHfWx5Ie+5o36jsbjeYk05yk5ZnEh4I48R/4izhvEO7ABHI+YqFYy6NwFXYRVL zoepR/SWEDdiKJnj4EuFo4c+8TFH4Kp97ihz5YZ4YtzuS0SjrKzpR1v9JunJVW1v Ww7pNA1kOcKepNsvIWPJ6hciVsTwoNoF10P5AQsTabo/2H63NSZYSsXWyVRm1vSe 3K9Haml85sHvhq6cTw5jDZ9vnjii8It0NhwOYneDlaNW83ozFxvdE1Cm6R5JYmM3 MnxTrtD5y8iGUgEHErintMS/s8Hu5w== =7Onj -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 18 16:36:24 2020 Return-Path: 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 7474C3A09B4; Thu, 18 Jun 2020 16:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 MnE3LpkqIoJr; Thu, 18 Jun 2020 16:36:19 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 995083A09AE; Thu, 18 Jun 2020 16:36:19 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 328E8548440; Fri, 19 Jun 2020 01:36:14 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 2B6E1440043; Fri, 19 Jun 2020 01:36:14 +0200 (CEST) Date: Fri, 19 Jun 2020 01:36:14 +0200 From: Toerless Eckert To: Tero Kivinen Cc: Paul Wouters , "ipsec@ietf.org WG" , Michael Richardson , draft-ietf-anima-autonomic-control-plane@ietf.org, Yoav Nir Message-ID: <20200618233614.GN16371@faui48f.informatik.uni-erlangen.de> References: <27926.1582739768@localhost> <0E1FEB34-E329-4686-80CE-0DFE253409C2@gmail.com> <20200617170403.GA18378@faui48f.informatik.uni-erlangen.de> <20200617183127.GX16371@faui48f.informatik.uni-erlangen.de> <872.1592440656@localhost> <20200618015733.GG16371@faui48f.informatik.uni-erlangen.de> <24299.44139.322739.654469@fireball.acr.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24299.44139.322739.654469@fireball.acr.fi> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 23:36:23 -0000 THanks, Tero, inline On Thu, Jun 18, 2020 at 09:03:23PM +0300, Tero Kivinen wrote: > [talking as individual and one of RFC7296 authors, not as WG chair]. Is there some new IETF liability insurance that make us say this ? Ok: i am also only talking as an individual and ACP draft author and not was WG chair. ;-)) > Toerless Eckert writes: > > On Wed, Jun 17, 2020 at 08:55:12PM -0400, Paul Wouters wrote: > > > The RFC states: > > > > > > The USE_TRANSPORT_MODE notification MAY be included in a request > > > message that also includes an SA payload requesting a Child SA. It > > > requests that the Child SA use transport mode rather than tunnel mode > > > for the SA created. If the request is accepted, the response MUST > > > also include a notification of type USE_TRANSPORT_MODE. If the > > > responder declines the request, the Child SA will be established in > > > tunnel mode. > > At this point the responder already created an Child SA in tunnel > mode, and when the initiator receives that message from the responder > it will also create the Child SA in tunnel mode. Responder might > already be sending traffic at this point. > > This means both initiator and responder MUST implement tunnel mode, as > otherwise they cannot perform those actions. Meaning as the fallback > from the transport mode is tunnel mode, all implementations MUST > implement it even if it not explictly said in the RFC. [deleted question i wanted to ask here as you answer it below.] Sounds as if IKEv2 is effectively not built to allow optimizing the classical transport option case. For example using IPsec for transport connections of protocols, such as IGPs, BGP or the like. I did write the doc for how to use IPsec transport mode with RFC4601 PIM, alas, security was never widely used for such signaling, so RFC7761 completely removed it. But if somebody ever wanted to write a good profile for such use cases, they would run into this tunnel over transport issue. > > > If this is unacceptable to the initiator, the initiator > > > MUST delete the SA. > > This thing happens after the Child SA is created. I.e., now the > initiator will check whether the Child SA created was following its > policy, and it is completely valid for the initiators policy to say > that must use transport mode, and then it will delete the SA as it was > not following its policy. > > It still means that the initiator implementation MUST implement tunnel > mode, but it does not have to USE it if it does not feel like doing > that. > > The MUST/SHOULD etc only give requirements for the implementors, i.e., > what features MUST or SHOULD be implemented and what MAY be > implemented. In the RFCs we cannot use those keywords to instruct > adminstrators/users what they should use. I guess it is left up to the implementer to figure out that implementing support for tunnel mode in IKEv2 doesn't mean that it does have to actually implement support for it in the forwarding plane / ESP. > Quite often, especially in the security considerations section, we try > to give requirements to the users, but we need to be very carefull not > to do that. We can give information to users saying "do not use low > entrypy passwords as PSK as they are known to be unsafe", but we > cannot say MUST NOT use low entropy passwords, as there is no easy for > for implementor to enforce that. > > For every single MUST or SHOULD and especially MUST NOT or SHOULD NOT > you are writing to the RFC, you should think how can you answer to > question from the customer who says, "show me the lines in your > implementation which implements this MUST or SHOULD". For MUST and > SHOULDs, that is usully still quite easy, but when someone asks "Show > me the lines of code where you implement: This notification MUST NOT > BE sent by an entity that may be replicated".... Yeah, and it gets more tricky with the distinction of MUST in IKEv2 which may or may not be read to be inclusive to actual forwarding plane / ESP requirements. > (and yes, I have had incoming customer support case, where they asked > for every single MUST/SHOULD/MUST NOT/SHOULD NOT where it was > implemented in the source of our toolkit). I ould like to imagine it is satisfying to be such a large customer that you can not only answer but also make your vendor answer those questions, but in my experience those customers than also had to write long reports about the ansers ;-) I would love to see "protocol implementation compliance specification" or whatever you might call it, but i have given up asking for it in the IETF itself, and given ho i work for a vendor it is of course masochism ;-) > > > But note that the responder has already installed the IPsec SA in tunnel > > > mode. So if the initiator finds that unacceptable, it must send the > > > delete. During all this time, connectivity between the nodes will be > > > blocked. The intention here is that transport mode is optional and > > > should not be mandated by other protocols. Otherwise, the IKEv1 > > > style negoation of transport OR tunnel mode would have been kept. > > Also the delete notifications might get lost, and it might takes tens > of seconds, or even minutes before the initiator can finally tell the > responder that the Child SA that didn't follow its policy is deleted. Ok. > > How about my mails ask that i read this text such that the initiator will > > delete the SA (not only client SA) if transport mode is not supported > > be responder. Aka: the last two sentences to me describe exactly the > > case where the initiator can/want only support transport mode. > > Initiator and responder can delete whatever SAs they like whenever > they like. That does not matter to the actual case here. The issue > there is that if the responder does not want to do transport mode, > then SA will be created in tunnel mode, and the initiator must be able > to cope with tunnel mode ESP packets it is receiving from the > responder. I.e., it needs to be able to implement tunnel mode as much > it understands those packets and does something to them (dropping them > is fine, as if his policy says he wants to get transport mode packets > and do not allow tunnel mode packets, then it is fine to have policy > dropping all tunnel mode packets). > > > Aka: i can not read your interpretation into this text. > Anyways, this discussion is not really useful. Well, i find your, Yoav and Pauls explanation very helpful. May i dare to say: Also because of the lack of similar explanations in the RFCs. > If the other end does > not support transport mode (as it is allowed to do by IKEv2, as > transport mode is optional), there is nothing you can do to make it > support transport mode, and deleting the Child SA will just cause > initiator to try again few seconds later when it gets next packet to > that direction, with exactly same bad result. > > It would be much better to simply say that SHOULD use transport mode, > as it is more efficient for GRE, but if other end does not support > transport mode, using tunnel mode still gets the connectivity, even > when we are wasting few bytes. Well in the case of ACP we're fine with the way IKEv2 works, the MUST is on tunnel mode without GRE (just IP in IP), and the MAY is on GRE with transport and prefer that when available. I primarily wanted to make sure we have enough of a basis written to know what could be negotiated. Older router may likely prefer and fsaster implement GRE, hence its useful. But there is not a lot of need IMHO to have a lot of profile requirements because most connections will be between routers from the same vendor and they can extend the profile as they wish. > In IPsec we had so much issues in IKEv1 where every single option and > feature knob needed to be exactly right to get any connectivity, that > in IKEv2 we tried to get rid of exact negotiation things, instead we > propose something, and we do have fallback to go if other end does not > accept our proposel. Understood. Thats also why i am worried and maybe have written more than necessary requirements to ensure interop into ACP. And given how the main use of IPsec are VPN across IPv4 with all the NAT crap, it is quite useful to start with that as the first negotiation result. > Transport -> tunnel is one of those. IPcomp -> no IPcomp is another, > traffic selector narrowing is third, getting rid of negotiated > lifetimes for SAs was yet another one etc. Options Galore > The basic idea is that when you finish IKEv2 exchange you have > "usable" child SA you can use to send and receive traffic. > > Whether it was exactly what you wanted is another thing, and whether > you can accept that, is initiator choise, and if he cannot accept it, > he can delete the SA and be without connectivity compared to > non-optimal connectivity. > > Also as I have understood that your nodes are security gateways (not > hosts, as they do forward packets from other nodes) the RFC4301 > already says that they: > > b) A security gateway MUST support tunnel mode and MAY support > transport mode. If it supports transport mode, that should be > used only when the security gateway is acting as a host, e.g., for > network management, or to provide security between two > intermediate systems along a path. > > Meaning tunnel mode is mandatory to implement in those devices > anyways. The use of tunnel mode is completely different matter then. Yepp. The 4301 text describing limitations of transport mode does of course not cover the case where transport mode is used in conjunction with another tunneling protocol like GRE. > > Please answer the other questions from my reply mail. > > > > > So I would recommend to follow the intention of RFC 7296 and not make > > > up your own restrictions. > > > > Again, i had a lot of arguments in my email that i need to see answers > > to so that we can make progress here. > > I do disagree with Paul that I think profiles can require certain > optional features to be implemented and used from the base standard, > if it makes sense in there. That does not mean that you can remove > features from the base standards, so even if you do say you use GRE > with transport mode, the IPsec implementations used still need to > implement tunnel mode too, as that is part of the base standard, but > of course you do not need to allow that to be configured, so detecting > use of that might be difficult. > > So I think it is ok to say that SHOULD (or even MUST) implement > transport mode for GRE, but it is not ok to say that tunnel mode would > be OPTIONAL, as that would make it so that it cannot connect to the > conforming IKEv2 implementations not supporting transport mode. Yepp. Paul and i only got into this argument because i was surprised to learn about the IKEv2 details given my divergent experience from practice and the (sorry) not very explanatory IKEv2 rfc text. Luckily no conflict with the requirements in the ACP doc from what i can tell. > We had similar discussion in the RFC7815 minimal IKEv2. That document > really only covered the Shared key authentication even when the base > IKEv2 do require also PKIX certificates and RSA signatures. It does > use one of the mandatory to implement features of the IKEv2, thus it > can talk to all conforming IKEv2 implementations, thus > interoperability is there, but cannot do both of the required > authentication methods, which does not cause problems as full > implementations need to support both anyways. Thanks again for all the insight Toerless > -- > kivinen@iki.fi -- --- tte@cs.fau.de From nobody Thu Jun 18 18:16:17 2020 Return-Path: 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 CADAD3A0F80 for ; Thu, 18 Jun 2020 18:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 ksa7ZZskK7UR for ; Thu, 18 Jun 2020 18:16:13 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AA393A0F76 for ; Thu, 18 Jun 2020 18:16:13 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 465AB548045; Fri, 19 Jun 2020 03:16:07 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 3AAEE440043; Fri, 19 Jun 2020 03:16:07 +0200 (CEST) Date: Fri, 19 Jun 2020 03:16:07 +0200 From: 'Toerless Eckert' To: Paul Wouters Cc: Valery Smyslov , 'Yoav Nir' , ipsec@ietf.org, 'Michael Richardson' Message-ID: <20200619011607.GB18378@faui48f.informatik.uni-erlangen.de> References: <20200224195013.GA3878@faui48f.informatik.uni-erlangen.de> <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> <0b8001d5ecad$79ce7ad0$6d6b7070$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [IPsec] Interop with microsoft CA (was: IPsec profile feedback wanted (draft autonomic control) plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2020 01:16:16 -0000 Picking up some leftover open points. On Wed, Feb 26, 2020 at 03:10:55PM -0500, Paul Wouters wrote: > Actually we do. We had to add pkcs7 to ikev2 to be compatible with some > windows deployments when intermediate certificates were being sent. On > top of that, Microsoft did it wrong, as the format does not allow a > chain but they added more than one anyway. So if anything, we DO NOT > want to see more pkcs7 in IKEv2. ACP nodes would never need to talk directly to a Microsoft CA, but an ACP registrar might. Such as a registrar using BRSKI. Question: Would a registrar be able to convert the encoding of the certificate (chain) between pkcs7 towards a Microsoft CA and whatever RFC7296 prefers, i guess "X.509 Certificate - Signature" towards the enrolling/renewing client ? If that conversion is possible, we are done, because then its up to each vendors registrar implementation to do this, at best we might put a note into the non-normative part of ACP (operations of registrars) or nothing. But given how ACP is an OPS area document, i think the WG/area appreciates help operationalizing systems, and not only creating strict protocol specifications. Alas, in the pre-standard implementations of ACP i used, we always used pkcs7 towards client, which is why i haven't been able to try to figure out the answer to this question. Given how i hope its just container formats, i hope the answer is yes. Cheers Toerless From nobody Thu Jun 18 19:29:02 2020 Return-Path: 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 6D9033A1047 for ; Thu, 18 Jun 2020 19:29:01 -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 6o74AAKB5X2F for ; Thu, 18 Jun 2020 19:29:00 -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 D56363A1046 for ; Thu, 18 Jun 2020 19:28:59 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 49p2mn0yY3zWg; Fri, 19 Jun 2020 04:28:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1592533737; bh=y9KJcCQ4o8tzGhY08TiWFxmYvbfq7TqWvL71AFd3uUI=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=FiITP85rEVNp2j6MijQdJfWGVTcAP7+TV3F7rByznKDyXJhSpDyEWTjIuWM//4NOY 7YTfv6Z9x0vd8cbmPWecruDX+Vv4UWHANrL42+WQhrWoqWPhpzcWPy53YUGg39HI79 YF7RtAR3Ij672ol3QcS6ZfH4PRKT1Juq8RCuz1Ak= 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 nnMRPKHWfC_3; Fri, 19 Jun 2020 04:28:56 +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; Fri, 19 Jun 2020 04:28:56 +0200 (CEST) Received: from [193.111.228.74] (unknown [193.111.228.74]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id D925560298AC; Thu, 18 Jun 2020 22:28:54 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Paul Wouters Mime-Version: 1.0 (1.0) Date: Thu, 18 Jun 2020 22:28:37 -0400 Message-Id: References: <20200619011607.GB18378@faui48f.informatik.uni-erlangen.de> Cc: ipsec@ietf.org, Michael Richardson , Valery Smyslov , Yoav Nir In-Reply-To: <20200619011607.GB18378@faui48f.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: iPhone Mail (17F75) Archived-At: Subject: Re: [IPsec] Interop with microsoft CA (was: IPsec profile feedback wanted (draft autonomic control) plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2020 02:29:01 -0000 On Jun 18, 2020, at 21:16, Toerless Eckert wrote: >=20 > =EF=BB=BFPicking up some leftover open points. >=20 > Question: Would a registrar be able to convert the encoding of the certifi= cate > (chain) between pkcs7 towards a Microsoft CA and whatever RFC7296 prefers,= > i guess "X.509 Certificate - Signature" towards the enrolling/renewing cli= ent ? Yes.=20 Paul= From nobody Fri Jun 19 00:15:57 2020 Return-Path: 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 600653A07A3; Fri, 19 Jun 2020 00:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-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 JMi2LTHoco0A; Fri, 19 Jun 2020 00:15:55 -0700 (PDT) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 2610D3A07A1; Fri, 19 Jun 2020 00:15:55 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id p18so6778558eds.7; Fri, 19 Jun 2020 00:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=Co50Gjs/VbpkrNOBIU7bAoNpDyQ8BYS4cUghvfWSzbU=; b=oQk8VMPvK+fv2WxsL+lu/o5qwFL+Zy5imCanQj0Es6CJfHxBaDsTKmW3l0gToXKYeo uu/EIWhx4gLRvMYuhj0HlFBJLKx0FsbPE9QClpExwegcxSRVbjfwtBjLKpDcb5UsNta0 USs2JEJH0DFRJ0wcJGBIJRy0XpdjL1K/wAUznS1a4KzYCVX/E+/UM4rgT4pJgXghD8DE csgKKETdHzbyVYsj1jP+QQ9Ez04UkZ5OojM7fbZ638k4CnC31ZGyALicsxa2uFUcnI8A kDZEg9CJg9MvBBdKM5Vhu9aP8B8UjTDiX7uXe4UizGv1NA2JiM7X+H6tiW0O+CqnoVPD e6sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=Co50Gjs/VbpkrNOBIU7bAoNpDyQ8BYS4cUghvfWSzbU=; b=GgkL4bw35ZNK9vSD0R9W9Di4k4j5D3Bysg641FwcvvtaHeb2dphNa0d47JIlkmL64t aZWi4AVPy3rjIX/4lfWBMuQoI0iWbgogpSjGwh1vviIyIremXISWebkrUxVzn1PZlO9C JDfTxmcv0ZLg2GG+G2ICRcPySlKC4ETma23ysuXdtSJKCmyu3eimt7PQxpwq/B/S8Vtr t+7XyIwa7+gCpm9KEVTm6jrw73ViO6bUx3GWj0SvGGBxAJFtjjDjd12seO9YqCcYV1xC Hm7osJYyIx8Ov3CEWevv58H7XEUSH7wnMbQyOuBEp8qkAeD3z9oHGWbPcTeiGcnFAggz 5ZGg== X-Gm-Message-State: AOAM532H/5e94LCt9OMcAalT5aRx+sG4H/lMEuT6eH5uc4NyoT/2sBpI 1VnpmDvGkldoAB7N0c+kbYP5XBXvyRs= X-Google-Smtp-Source: ABdhPJzG4Z2ETQX0GaY4/S+zlHS5SEt5BswN6aaxwtQKfKxvazugMaYAuT4MzAu16+mRlGUl6z/b1Q== X-Received: by 2002:aa7:c71a:: with SMTP id i26mr1862578edq.149.1592550953240; Fri, 19 Jun 2020 00:15:53 -0700 (PDT) Received: from buildpc ([82.138.51.3]) by smtp.gmail.com with ESMTPSA id gx8sm4122816ejb.86.2020.06.19.00.15.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jun 2020 00:15:52 -0700 (PDT) From: "Valery Smyslov" To: "'Tero Kivinen'" , "'Toerless Eckert'" Cc: , "'Michael Richardson'" , "'Paul Wouters'" , "'Yoav Nir'" , References: <31896.1582680023@localhost> <8A7ABA50-0ACB-41A2-9AE5-4EE15DB86F3A@gmail.com> <27926.1582739768@localhost> <0E1FEB34-E329-4686-80CE-0DFE253409C2@gmail.com> <20200617170403.GA18378@faui48f.informatik.uni-erlangen.de> <20200617183127.GX16371@faui48f.informatik.uni-erlangen.de> <872.1592440656@localhost> <20200618015733.GG16371@faui48f.informatik.uni-erlangen.de> <24299.44139.322739.654469@fireball.acr.fi> In-Reply-To: <24299.44139.322739.654469@fireball.acr.fi> Date: Fri, 19 Jun 2020 10:15:55 +0300 Message-ID: <07ec01d64609$79c6f3e0$6d54dba0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJfvESiLKPDMjLOqfXClque4Ld36gIj04AsAgph5VwDPS3bWgKBohpyAZ1f9yEBHXfpnQGC3HJBAqY1bRsC35m2sgEkiPfdASjC046nHKnpMA== Content-Language: ru Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2020 07:15:56 -0000 Hi Tero, > [talking as individual and one of RFC7296 authors, not as WG chair]. > > Toerless Eckert writes: > > On Wed, Jun 17, 2020 at 08:55:12PM -0400, Paul Wouters wrote: > > > The RFC states: > > > > > > The USE_TRANSPORT_MODE notification MAY be included in a request > > > message that also includes an SA payload requesting a Child SA. It > > > requests that the Child SA use transport mode rather than tunnel mode > > > for the SA created. If the request is accepted, the response MUST > > > also include a notification of type USE_TRANSPORT_MODE. If the > > > responder declines the request, the Child SA will be established in > > > tunnel mode. > > At this point the responder already created an Child SA in tunnel > mode, and when the initiator receives that message from the responder > it will also create the Child SA in tunnel mode. Responder might > already be sending traffic at this point. The initiator is not obliged to actually create the Child SA if it violates its policy (i.e. to actually load it into kernel). It's true that it should immediately send a Delete Payload in this case as if the SA has been created and then deleted, but it doesn't mean that it should actually create the Child SA to send the Delete payload. Regards, Valery. From nobody Fri Jun 19 07:51:22 2020 Return-Path: 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 756BC3A0A9E; Fri, 19 Jun 2020 07:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 DkJQCUv8OX5o; Fri, 19 Jun 2020 07:51:18 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3F613A0A62; Fri, 19 Jun 2020 07:51:17 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 1F87C548045; Fri, 19 Jun 2020 16:51:12 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 17CF6440043; Fri, 19 Jun 2020 16:51:12 +0200 (CEST) Date: Fri, 19 Jun 2020 16:51:12 +0200 From: 'Toerless Eckert' To: Valery Smyslov Cc: 'Paul Wouters' , 'Yoav Nir' , ipsec@ietf.org, 'Michael Richardson' , draft-ietf-anima-autonomic-control-plane@ietf.org Message-ID: <20200619145112.GA47906@faui48f.informatik.uni-erlangen.de> References: <20200224195013.GA3878@faui48f.informatik.uni-erlangen.de> <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> <0b8001d5ecad$79ce7ad0$6d6b7070$@gmail.com> <0c9e01d5ed4c$2353f5a0$69fbe0e0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0c9e01d5ed4c$2353f5a0$69fbe0e0$@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [IPsec] Troubleshooting IPsec peer certs (was: Re: IPsec profile feedback wanted (draft autonomic control) plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2020 14:51:20 -0000 In ACP, we use IKEv2 between peers without assumed methods to retrieve certificates from "external" sources like http repositories. And CA most likely will have non-public Trust Anchor (TA) (enterptrise PKI). Imagine a large multi-tenant network infrastructure (office building, skyscraper) where each tenant runs their own network. It is easy to see how ACP nodes can be misplugged and unintentionally connect to a different tenants ACP node, or more likely, or where the building owner has not updated the L2 segmentation of the office areas according to tenancy. In this case the TA will not match, but the problem is how help troubleshoot the problem by being able to identify which other tenants (PKI) is on the other side of a non-working ACP connection. Michael Richardson was suggesting to include the cert of the TA into the IKEv2 certificate exchange. This was rejected by Valery/Paul and the suggestion was to use CERTREQ instead. In my reading of CERTREQ, it would not help in this situation, because the hash of an unknown TA does not progress the troubleshooting much as there is in general no offline way to resolve it. In addition, that hash would AFAIK already be available from the Signature of the cert (chain) received from the peer. CERTREQ seems to only help the peer to select the right Cert (chain) to send back in case it has multiple, but not to learn the peers TA details when there is no match. Pls correct me if i am wrong. So i am tentatively adding the following text: CERTREQ MUST be used to indicate the ACP TA hashes. This helps the peer in selecting the ACP certificate in case it has certificates also from other TA. It is RECOMMENDED for IKEv2 to be set up such that it will only use the ACP certificate/TA when acting as a responder on the transport endpoints indicated in DULL GRASP for the ACP. Let me know if there is something wrong with this. Nevertheless, this does not solve the original troubleshooting issue Michael wanted to resolve. From what i figure i can only write text that IKEv2 does not support this troubleshooting and that instead this should be solved by adding diagnostics information, such as the TA certificate to DULL GRASP (but that would be for future work). Let me know if you can think of a way to "legally" send the full certificate of the TA during IKEv2 exchanges. Thanks Toerless On Thu, Feb 27, 2020 at 11:58:53AM +0300, Valery Smyslov wrote: > > > 2. If certificate chains are used, all intermediate certificates up to, > > > and including the locally provisioned trust anchor certificate MUST > > > be signaled. See Section 6.10.7 for the sub-CA example in which > > > certificate chains are used. > > > > > > This is confusing. I read this text as the ???MUST??? is imposed only if > > > ???certificate chains are used???. Does it mean that implementations > > > may skip this ???MUST??? if EE certificate is directly signed by CA certificate > > > and there is no intermediate certificates? Or is it still a chain > > > and ???if??? is relevant to the case when there is no CA and there is a direct trust to EE certificates > > > (in which case PKI is not needed at all and you can use RAW public keys)? > > > > I agree it should not try to dictate how certificate based IKE > > certification works, but just reference to IKEv2 and its updates for > > that. > > That was my point :-) > > > > Another point: trust anchors certificates usually are not included in CERT payload in IKEv2. > > > I see draft???s a reasoning that this inclusion would allow better network debugging, > > > but I???m not sure I can buy this argument. Probably more detailed > > > explanation is needed. > > > > They could suggest that for easier debuggint a CERTREQ payload is > > included. That has the hash of the CA, which should be good enough. > > But again, IKEv2 already specifies this. Why is this document trying > > to change IKEv2 certificate processing? > > Agree. > > Regards, > Valery. > > > Paul From nobody Fri Jun 19 10:10:46 2020 Return-Path: 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 E60113A0C89; Fri, 19 Jun 2020 10:10:44 -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 o_hh3xWkp6AH; Fri, 19 Jun 2020 10:10:43 -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 052853A0B0C; Fri, 19 Jun 2020 10:10:42 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 49pQL90l6xzMwX; Fri, 19 Jun 2020 19:10:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1592586641; bh=6iI+8+cTbMzD9aTv0AMjwUK51b5wGJi9tkqrY9rzhQE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=ZFM3iriciIs8cCNg5yMAPN6TmewohlgckjuO/XXjCSLeEo+1XnGQePUaQ3X8G27Tk cSeob0OcrcyWbyN02BXjMwYjZ2UyzrDg/NxAyosATzNrKB24dcT9rGBLo5J+4rWTiG cO5zRk1C1dSMikL+qfxrz4Q1eozJ5dVkkw/bKKjQ= 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 umno8YVOaNKs; Fri, 19 Jun 2020 19:10:39 +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; Fri, 19 Jun 2020 19:10:39 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id E7D106020EF2; Fri, 19 Jun 2020 13:10:37 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id DDBD066B7C; Fri, 19 Jun 2020 13:10:37 -0400 (EDT) Date: Fri, 19 Jun 2020 13:10:37 -0400 (EDT) From: Paul Wouters To: 'Toerless Eckert' cc: Valery Smyslov , ipsec@ietf.org, 'Michael Richardson' , 'Yoav Nir' , draft-ietf-anima-autonomic-control-plane@ietf.org In-Reply-To: <20200619145112.GA47906@faui48f.informatik.uni-erlangen.de> Message-ID: References: <20200224195013.GA3878@faui48f.informatik.uni-erlangen.de> <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> <0b8001d5ecad$79ce7ad0$6d6b7070$@gmail.com> <0c9e01d5ed4c$2353f5a0$69fbe0e0$@gmail.com> <20200619145112.GA47906@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [IPsec] Troubleshooting IPsec peer certs (was: Re: IPsec profile feedback wanted (draft autonomic control) plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2020 17:10:45 -0000 On Fri, 19 Jun 2020, 'Toerless Eckert' wrote: > Michael Richardson was suggesting to include the cert of the TA into the > IKEv2 certificate exchange. This was rejected by Valery/Paul and the suggestion > was to use CERTREQ instead. Normally, you do not include the TA itself, only intermediate root's and the EE-cert. The CERTREQ contains the hashes of _all_ trust anchors supported by that party, not just the one it is thinking of using right now with the exchange in progress. > In my reading of CERTREQ, it would not help in this situation, because the > hash of an unknown TA does not progress the troubleshooting much as there is > in general no offline way to resolve it. In addition, that hash would > AFAIK already be available from the Signature of the cert (chain) > received from the peer. Basically, in IKE_SA_INIT, before the IKE_AUTH and CERT payloads exchange, you exchange CERTREQ. You basically give a somewhat anonymised list of trust anchors you support. The initiator can loop through its known TA's and if it matches one, pick the proper certificate if there is one for that TA. The reason sending hashes and not the root CA's is that it becomes very easy to determine which CA's a particulat client supports. I know that is elpful to troubleshooting, but it was deemed a security/privacy issue. > CERTREQ seems to only help the peer to select > the right Cert (chain) to send back in case it has multiple, but not to > learn the peers TA details when there is no match. Pls correct me if i am wrong. That is correct. > So i am tentatively adding the following text: > > CERTREQ MUST be used to indicate the ACP TA hashes. This helps the peer in selecting the ACP certificate in case it has certificates also from other TA. It is RECOMMENDED for IKEv2 to be set up such that it will only use the ACP certificate/TA when acting as a responder on the transport endpoints indicated in DULL GRASP for the ACP. I'm not sure how much of your protocol involves talking to different parties that might have to install each others root CAs. Usually, either everyone shares the same (private) root CA because the root CA is an enterprise wide trust anchor, or if the connection is between two enterprises that are independent, administrators use PSK because neither one wants to trust a root CA maintained by the other. So the problem you describe hardly happens. But I'm not familiar with your uses cases. > Let me know if there is something wrong with this. I would not say MUST. If both parties know they have the same root CA installed, the IKEv2 protocol does not require you send that Root CA hashed in a CERTREQ. SHOULD would be better here? > Nevertheless, this does not solve the original troubleshooting issue > Michael wanted to resolve. From what i figure i can only write > text that IKEv2 does not support this troubleshooting and that > instead this should be solved by adding diagnostics information, > such as the TA certificate to DULL GRASP (but that would be for > future work). > > Let me know if you can think of a way to "legally" send the full > certificate of the TA during IKEv2 exchanges. Nothing prevents you from including the root CA (TA) in the CERT payload. It is perfectly valid. There is a privacy/security risk of revealing the root your trust. But that's your risk to evaluate. If you want to convey you are trusting many roots, then CERTREQ is the better place. You dont want to send 150+ root CAs over IKE. Presumbly, since you have 1 configured EE-cert to use for this connection, it will chain back to one intermediate/root CA ? That's the one you can just send as part of the CERT payload. Paul From nobody Fri Jun 19 11:40:51 2020 Return-Path: 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 8314C3A0CE4; Fri, 19 Jun 2020 11:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 v2WmkHxKsX5U; Fri, 19 Jun 2020 11:40:36 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E45F93A0D89; Fri, 19 Jun 2020 11:40:35 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 538F1548068; Fri, 19 Jun 2020 20:40:30 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 4D13D440043; Fri, 19 Jun 2020 20:40:30 +0200 (CEST) Date: Fri, 19 Jun 2020 20:40:30 +0200 From: 'Toerless Eckert' To: Paul Wouters Cc: Valery Smyslov , ipsec@ietf.org, 'Michael Richardson' , 'Yoav Nir' , draft-ietf-anima-autonomic-control-plane@ietf.org Message-ID: <20200619184030.GR16371@faui48f.informatik.uni-erlangen.de> References: <20200224195013.GA3878@faui48f.informatik.uni-erlangen.de> <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> <0b8001d5ecad$79ce7ad0$6d6b7070$@gmail.com> <0c9e01d5ed4c$2353f5a0$69fbe0e0$@gmail.com> <20200619145112.GA47906@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [IPsec] Troubleshooting IPsec peer certs (was: Re: IPsec profile feedback wanted (draft autonomic control) plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2020 18:40:50 -0000 On Fri, Jun 19, 2020 at 01:10:37PM -0400, Paul Wouters wrote: > > So i am tentatively adding the following text: > > > > CERTREQ MUST be used to indicate the ACP TA hashes. This helps the peer in selecting the ACP certificate in case it has certificates also from other TA. It is RECOMMENDED for IKEv2 to be set up such that it will only use the ACP certificate/TA when acting as a responder on the transport endpoints indicated in DULL GRASP for the ACP. > > I'm not sure how much of your protocol involves talking to different > parties that might have to install each others root CAs. Usually, > either everyone shares the same (private) root CA because the root CA > is an enterprise wide trust anchor, or if the connection is between > two enterprises that are independent, administrators use PSK because > neither one wants to trust a root CA maintained by the other. For use across ACP, all nodes MUST have the same set of TA to mutually authenticate each other, so CERTREQ would not make sense. I am just trying to figure out the prior suggestions on this thread by Michael et. al. that we should use CERTREQ, but have a hard time figuring out why. What i thought to understand is this: Responder has a lot of different set of TA, but only one of them for use with ACP. These sets MAY have common TA. How should the responder select which cert to send back to initiator. CERTREQ from the initiator would help if the set of ACP TA is disjoint from the TA used for other IKEv2 uses on the responder. But that may not be the case. Aka: I think i will not bother with CERTREQ unless someone gives me a fully worked out suggestion how to use it beneficially. But i think i will keep the text saying that IKEv2 for ACP needs to run on a transport endpoint where ONLY use of ACP certificate and TA is assumed. > So the problem you describe hardly happens. But I'm not familiar with > your uses cases. > > > Let me know if there is something wrong with this. > > I would not say MUST. If both parties know they have the same root CA > installed, the IKEv2 protocol does not require you send that Root CA > hashed in a CERTREQ. SHOULD would be better here? See above. I am inclinded to completely remove the sugestion to use CERTREQ. > > Nevertheless, this does not solve the original troubleshooting issue > > Michael wanted to resolve. From what i figure i can only write > > text that IKEv2 does not support this troubleshooting and that > > instead this should be solved by adding diagnostics information, > > such as the TA certificate to DULL GRASP (but that would be for > > future work). > > > > Let me know if you can think of a way to "legally" send the full > > certificate of the TA during IKEv2 exchanges. > > Nothing prevents you from including the root CA (TA) in the CERT > payload. It is perfectly valid. There is a privacy/security risk > of revealing the root your trust. But that's your risk to evaluate. Ok. Then i will keep that text and check where to put the discussion about the confidentiality of root CA problem. > If you want to convey you are trusting many roots, then CERTREQ is > the better place. You dont want to send 150+ root CAs over IKE. Sure. > Presumbly, since you have 1 configured EE-cert to use for this > connection, it will chain back to one intermediate/root CA ? That's > the one you can just send as part of the CERT payload. Normally yes. But when you have M&A (Mergers and Aquisitions) you would need to support multiple TA, but you would only send the TA cert from which your own cert is derived. Thats sufficient for troubleshooting. Thanks! Toerless > Paul -- --- tte@cs.fau.de From nobody Sun Jun 21 10:26:06 2020 Return-Path: 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 BD2823A0784; Sun, 21 Jun 2020 10:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 TP3p2Jfl51ie; Sun, 21 Jun 2020 10:26:03 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF8F73A077D; Sun, 21 Jun 2020 10:26:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id CA219389B6; Sun, 21 Jun 2020 13:23:22 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pdDg1yMdKOcx; Sun, 21 Jun 2020 13:23:21 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DA7CE389B4; Sun, 21 Jun 2020 13:23:20 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8B7FD57D; Sun, 21 Jun 2020 13:25:59 -0400 (EDT) From: Michael Richardson To: Paul Wouters , 'Toerless Eckert' , Valery Smyslov , ipsec@ietf.org, 'Yoav Nir' , draft-ietf-anima-autonomic-control-plane@ietf.org In-Reply-To: References: <20200224195013.GA3878@faui48f.informatik.uni-erlangen.de> <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> <0b8001d5ecad$79ce7ad0$6d6b7070$@gmail.com> <0c9e01d5ed4c$2353f5a0$69fbe0e0$@gmail.com> <20200619145112.GA47906@faui48f.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] Troubleshooting IPsec peer certs (was: Re: IPsec profile feedback wanted (draft autonomic control) plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2020 17:26:05 -0000 --=-=-= Content-Type: text/plain Paul Wouters wrote: > Basically, in IKE_SA_INIT, before the IKE_AUTH and CERT payloads > exchange, you exchange CERTREQ. You basically give a somewhat > anonymised list of trust anchors you support. The initiator can loop > through its known TA's and if it matches one, pick the proper > certificate if there is one for that TA. Unless we can convince various people otherwise, the TA will all be private enterprise/ISP CAs. > The reason sending hashes and not the root CA's is that it becomes very > easy to determine which CA's a particulat client supports. I know that > is elpful to troubleshooting, but it was deemed a security/privacy > issue. We are not dealing with "clients", because this is not a remote access scenario. Nor are these system visible in any way to the Internet. "Physical" connectivity is required. (In quotes, because microwaves, satellite systems and other layer-2 transmission media) This is an overlay network of ISP routers that use IPsec over IPv6 **Link-Layer** addresses. The privacy considerations are significantly different, while the need to do troubleshooting significantly higher. Sending the *complete* trust chain solves the problem, and should never cause a problem to any properly implemented daemon/certificate chain validator. > I'm not sure how much of your protocol involves talking to different > parties that might have to install each others root CAs. Usually, > either everyone shares the same (private) root CA because the root CA > is an enterprise wide trust anchor, or if the connection is between two > enterprises that are independent, administrators use PSK because > neither one wants to trust a root CA maintained by the other. At private ISP peering points, at IXPs (until discovered and disabled), and when cables and/or systems are mis-attached, the ACP may attempt to connect across security boundaries. This is intended in almost all cases to fail. Knowing what peers were rejected helps significantly in determining if some cables were misconnected. Since a goal of the ACP work is to reduce the expense (dollars and CO2 emissions) of deploying new network equipment, one can expect that over time the quality of the "remote hands" will find a new lower bound. (While we conceive of inter-ISP secure channels that might require cross-installation of trust anchors, those are just talk at this point) > So the problem you describe hardly happens. But I'm not familiar with > your uses cases. ... > Nothing prevents you from including the root CA (TA) in the CERT > payload. It is perfectly valid. There is a privacy/security risk of > revealing the root your trust. But that's your risk to evaluate. Good, we are in agreement here. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl7vmCcACgkQgItw+93Q 3WW2aAgAle6OrZshYGciKS9HQRWqR9c/DXb6IG+zzrch7bz+OyLoxNPGXvhBDrk6 nRJYatun6vMWBVS1hLz4HO1HmLZ/kMu7iObVFYWWoN+08R+MoKqLvWl9ekRCh5i9 9dqGCVPjoJguBrBV6BmK4E4Bhohbc1rlG2588u05NIbIaG32qNEAqJzc8UrAbAfg j1MT5P204pcdwQmKie0juPK/XqEVESDLSDnXiQATYMREqKG13DU81Ae1/gBt5Isn u6muabJe14xEMWsWa2zN3bMSN91b4BBBE9Au7epV+AaKPidtAKqG7hidUViWazke J43vDe4kDruxkB5kcuKuJKSDKjZLnw== =RW9v -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jun 21 19:22:07 2020 Return-Path: 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 E619E3A08BE; Sun, 21 Jun 2020 19:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 oXumMgYkV-zz; Sun, 21 Jun 2020 19:22:03 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1B123A08BD; Sun, 21 Jun 2020 19:22:01 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 206EA54843F; Mon, 22 Jun 2020 04:21:56 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 1ACD5440043; Mon, 22 Jun 2020 04:21:56 +0200 (CEST) Date: Mon, 22 Jun 2020 04:21:56 +0200 From: 'Toerless Eckert' To: Valery Smyslov Cc: ipsec@ietf.org, 'Michael Richardson' , 'Paul Wouters' , 'Yoav Nir' , draft-ietf-anima-autonomic-control-plane@ietf.org Message-ID: <20200622022156.GB47906@faui48f.informatik.uni-erlangen.de> References: <20200224195013.GA3878@faui48f.informatik.uni-erlangen.de> <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> <0b8001d5ecad$79ce7ad0$6d6b7070$@gmail.com> <0c9e01d5ed4c$2353f5a0$69fbe0e0$@gmail.com> <20200227183225.GP39574@faui48f.informatik.uni-erlangen.de> <0e5f01d5ee0b$f77182c0$e6548840$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0e5f01d5ee0b$f77182c0$e6548840$@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2020 02:22:05 -0000 Thanks, Valery let me pick up the one point i have no clear text solution for yet. On Fri, Feb 28, 2020 at 10:52:02AM +0300, Valery Smyslov wrote: > Hi Toerless, [...] > Well, the example you provided doesn't work. In IKEv2 first > the responder sends a list of TA (hashes) he has in a CERTREQ payload. > When the initiator receives it, he checks the list trying to find > a corresponding TA that signed his certificate (or a chain) and if he finds one, then he sends > back a bunch of his certificates starting from EE and up to (but not including) this TA. > If the initiator fails to find a proper TA, then the SA fails and no more exchanges take place. > If he finds one, then there is absolutely no point to send it back > to the responder, as the responder has indicated already that he has it. > The same happens in the opposite direction. > So I still cannot buy this argument. Ok, so lets assume initiator and responder being routers may have multiple certificates for diffent purposed. The initiator knows it needs to use the ACP certificate because the IKEv2 was triggered for the purpose of ACP. The responder can also know that it must use the ACP certificate from the transport address that it listens to: This are link-local scope IPv6 addresses with a UDP port number that is signalled in a discovery protocol. That way a responder can bind an IKEv2 instance that has only the ACP certificate available. When we assume that initiator and responder can perfectly well constrain themselves to their ACP certificates, it sounds almost as if we would want to mandate to NOT USE CERTREQ, because that would cause termination of the IKEv2 exchange before exchange of certificates takes places. And from what i read in rfc7296, CERTREQ is optional, so we can mandate NOT to use it. If i take our explanation, in the absence of CERTREQ, the initiator would send the cert chain, including TA (additional requiremement from ACP profile), and we would have the necessary informtion on the responder side - even if the mutual authentication then fails. I do not fully understand the sequence of events, e.g.: if this approach only works for one side (for the responder learning the TA of the initiator), or if it would only work for the other side. Pls. let me know, i can accordingly adjust the text. > More general thought: each side performs validation of peer's cert by his own, > using his own trust assumptions. If peer sends you his TA that he will be using while validating your > identity, then it sounds strange to me, because it's his trust anchor, not yours. > You even cannot check whether it's expired, because peer's clock may skew from yours... The signaling of TA is meant to help (human) diagnostics of authentication failure, not to make authentication successful. The candidate text for rev -25 has 4 examples. Lots of options for misconfigurations in large enterprises, no other way to get to the TA of a device trying to connect to you, etc. pp. Cheers Toerless > Regards, > Valery. > > > > > > 3. IKEv2 authentication MUST use authentication method 14 ("Digital > > > > > Signature") for ACP certificates; this authentication method can be > > > > > used with both RSA and ECDSA certificates, as indicated by a PKIX- > > > > > style OID. > > > > > > > > > > I think it???s better to rephrase this more accurately: ???indicated by an ASN.1 object > > > > > AlgorithmIdentifier??? > > > > > > > > Wouldn't it be more correct to say "indicated by a SubjectPublicKeyInfo > > > > (SPKI) ASN.1 object" ? > > > > > > No, as far as I understand the text, it tells that the particular > > > signing algorithm is indicated in the AUTH payload by inclusion its OID. > > > That's partially true, it is indicated by inclusion AlgorithmIdentifier ASN.1 object > > > (and not SubjectPublicKeyInfo or pure OID). > > > > > > It's probably better to just delete the text in the last sentence "as indicated by a PKIX-style OID". > > > > ;-) Going once, going twice ? ... If not, i'll follow this advice > > > > Thanks! > > Toerless > > > > > Regards, > > > Valery. > > > > > > > Paul > > > > > > _______________________________________________ > > > IPsec mailing list > > > IPsec@ietf.org > > > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec -- --- tte@cs.fau.de From nobody Sun Jun 21 20:38:28 2020 Return-Path: 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 8E3773A08FE; Sun, 21 Jun 2020 20:38:26 -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 UcqlZhaaOY-H; Sun, 21 Jun 2020 20:38:22 -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 311AB3A08C3; Sun, 21 Jun 2020 20:38:21 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 49qw9Q1Jtyz3WN; Mon, 22 Jun 2020 05:38:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1592797098; bh=ovA4TsLh5ACxn4pp1AwL+ZLAOpQ0lDQjFkRza96nKWA=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=UphN6q1e9Qw+UjQSUk0XKMPhSQjaOj1lCUfh6scS1nsu7mibcQ3Y2oHUA8xJx0kzN 48RL4lVoJYem9CsotS36BtaGnsnAHn+gCa14zcMVvrcjqmr0Of7OIGirIQfPpPCf4V 9fMuAO7gSj5vu/VRQLw/F9+7yVkm35faIOJM1slU= 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 jr_EgpYF69V0; Mon, 22 Jun 2020 05:38:17 +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; Mon, 22 Jun 2020 05:38:16 +0200 (CEST) Received: from [193.111.228.74] (unknown [193.111.228.74]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id BD4B06029BA2; Sun, 21 Jun 2020 23:38:15 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Paul Wouters Mime-Version: 1.0 (1.0) Date: Sun, 21 Jun 2020 23:37:58 -0400 Message-Id: References: <20200622022156.GB47906@faui48f.informatik.uni-erlangen.de> Cc: Valery Smyslov , ipsec@ietf.org, Michael Richardson , Yoav Nir , draft-ietf-anima-autonomic-control-plane@ietf.org In-Reply-To: <20200622022156.GB47906@faui48f.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: iPhone Mail (17F75) Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2020 03:38:27 -0000 On Jun 21, 2020, at 22:22, Toerless Eckert wrote: >=20 > =EF=BB=BFThanks, Valery >=20 > let me pick up the one point i have no clear text solution for yet. >=20 >> On Fri, Feb 28, 2020 at 10:52:02AM +0300, Valery Smyslov wrote: >> Hi Toerless, > [...] >> Well, the example you provided doesn't work. In IKEv2 first >> the responder sends a list of TA (hashes) he has in a CERTREQ payload. >> When the initiator receives it, he checks the list trying to find >> a corresponding TA that signed his certificate (or a chain) and if he fin= ds one, then he sends=20 >> back a bunch of his certificates starting from EE and up to (but not incl= uding) this TA.=20 >> If the initiator fails to find a proper TA, then the SA fails and no more= exchanges take place.=20 >> If he finds one, then there is absolutely no point to send it back >> to the responder, as the responder has indicated already that he has it. >> The same happens in the opposite direction. >=20 >> So I still cannot buy this argument. >=20 > Ok, so lets assume initiator and responder being routers may have multiple= > certificates for diffent purposed. The initiator knows it needs to use > the ACP certificate because the IKEv2 was triggered for the purpose of ACP= Yes. > The responder can also know that it must use the ACP certificate from the > transport address that it listens to: Yes=20 > When we assume that initiator and responder can perfectly well constrain > themselves to their ACP certificates, it sounds almost as if we would > want to mandate to NOT USE CERTREQ, because that would cause > termination of the IKEv2 exchange before exchange of certificates > takes places. What is causing termination ? > And from what i read in rfc7296, CERTREQ is optional, > so we can mandate NOT to use it. This is going to be the same discussion we had with transport mode. You shou= ld not try to modify the IKE protocol.=20 The protocol allows you to send it and allows you to ignore the contents of i= t. That should be fine for your use case.=20 > If i take our explanation, in the absence of CERTREQ, the initiator > would send the cert chain, including TA (additional requiremement from > ACP profile), and we would have the necessary informtion on the > responder side - even if the mutual authentication then fails. If you know who it is you are supposed to talking to based on an IP, why do y= ou even need a CA chain? Seems two self signed certs configured on both ends= work too. In that case, the IKE implementation would also not bother with C= ERTREQ (and maybe even CERT, but I=E2=80=99m pretty sure our implementation w= ould still send it) Paul= From nobody Sun Jun 21 20:43:15 2020 Return-Path: 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 ECC573A090E; Sun, 21 Jun 2020 20:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 z2ssBF5CxUo0; Sun, 21 Jun 2020 20:43:12 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 661183A0824; Sun, 21 Jun 2020 20:43:11 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 05M3gr6I017330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 21 Jun 2020 23:42:55 -0400 Date: Sun, 21 Jun 2020 20:42:53 -0700 From: Benjamin Kaduk To: Paul Wouters Cc: Toerless Eckert , ipsec@ietf.org, Michael Richardson , Valery Smyslov , draft-ietf-anima-autonomic-control-plane@ietf.org, Yoav Nir Message-ID: <20200622034253.GL11992@kduck.mit.edu> References: <20200622022156.GB47906@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2020 03:43:14 -0000 On Sun, Jun 21, 2020 at 11:37:58PM -0400, Paul Wouters wrote: > On Jun 21, 2020, at 22:22, Toerless Eckert wrote: > > > > Thanks, Valery > > > > let me pick up the one point i have no clear text solution for yet. > > > >> On Fri, Feb 28, 2020 at 10:52:02AM +0300, Valery Smyslov wrote: > >> Hi Toerless, > > [...] > >> Well, the example you provided doesn't work. In IKEv2 first > >> the responder sends a list of TA (hashes) he has in a CERTREQ payload. > >> When the initiator receives it, he checks the list trying to find > >> a corresponding TA that signed his certificate (or a chain) and if he finds one, then he sends > >> back a bunch of his certificates starting from EE and up to (but not including) this TA. > >> If the initiator fails to find a proper TA, then the SA fails and no more exchanges take place. > >> If he finds one, then there is absolutely no point to send it back > >> to the responder, as the responder has indicated already that he has it. > >> The same happens in the opposite direction. > > > >> So I still cannot buy this argument. > > > > Ok, so lets assume initiator and responder being routers may have multiple > > certificates for diffent purposed. The initiator knows it needs to use > > the ACP certificate because the IKEv2 was triggered for the purpose of ACP > > Yes. > > > > The responder can also know that it must use the ACP certificate from the > > transport address that it listens to: > > Yes > > > When we assume that initiator and responder can perfectly well constrain > > themselves to their ACP certificates, it sounds almost as if we would > > want to mandate to NOT USE CERTREQ, because that would cause > > termination of the IKEv2 exchange before exchange of certificates > > takes places. > > What is causing termination ? > > > > > And from what i read in rfc7296, CERTREQ is optional, > > so we can mandate NOT to use it. > > This is going to be the same discussion we had with transport mode. You should not try to modify the IKE protocol. > > The protocol allows you to send it and allows you to ignore the contents of it. That should be fine for your use case. > > > > If i take our explanation, in the absence of CERTREQ, the initiator > > would send the cert chain, including TA (additional requiremement from > > ACP profile), and we would have the necessary informtion on the > > responder side - even if the mutual authentication then fails. > > If you know who it is you are supposed to talking to based on an IP, why do you even need a CA chain? Seems two self signed certs configured on both ends work too. In that case, the IKE implementation would also not bother with CERTREQ (and maybe even CERT, but I’m pretty sure our implementation would still send it) It's not quite "you know who you are talking to based on IP", but more of "under this precondition, you know that the peer should be part of the same ACP domain, and thus using the same TA as you". But you don't know exactly which peer in the domain, and thus which EE cert, you're going to get. The case that (IIUC) triggered this subthread is when things are wired badly and you end up actually talking to someone in a different ACP domain, i.e., with a different TA. We want to be able to report what that "unexpected" TA is, so that the mis-wiring can be diagnosed more readily. -Ben From nobody Sun Jun 21 23:29:27 2020 Return-Path: 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 67C103A0967; Sun, 21 Jun 2020 23:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 Jcdh6ntalCnx; Sun, 21 Jun 2020 23:29:24 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEB173A0964; Sun, 21 Jun 2020 23:29:23 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id A126854843F; Mon, 22 Jun 2020 08:29:18 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 97A6F440043; Mon, 22 Jun 2020 08:29:18 +0200 (CEST) Date: Mon, 22 Jun 2020 08:29:18 +0200 From: Toerless Eckert To: Paul Wouters Cc: Valery Smyslov , ipsec@ietf.org, Michael Richardson , Yoav Nir , draft-ietf-anima-autonomic-control-plane@ietf.org Message-ID: <20200622062918.GH57796@faui48f.informatik.uni-erlangen.de> References: <20200622022156.GB47906@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2020 06:29:26 -0000 Inline On Sun, Jun 21, 2020 at 11:37:58PM -0400, Paul Wouters wrote: > On Jun 21, 2020, at 22:22, Toerless Eckert wrote: > > > > ???Thanks, Valery > > > > let me pick up the one point i have no clear text solution for yet. > > > >> On Fri, Feb 28, 2020 at 10:52:02AM +0300, Valery Smyslov wrote: > >> Hi Toerless, > > [...] > >> Well, the example you provided doesn't work. In IKEv2 first > >> the responder sends a list of TA (hashes) he has in a CERTREQ payload. > >> When the initiator receives it, he checks the list trying to find > >> a corresponding TA that signed his certificate (or a chain) and if he finds one, then he sends > >> back a bunch of his certificates starting from EE and up to (but not including) this TA. > >> If the initiator fails to find a proper TA, then the SA fails and no more exchanges take place. > >> If he finds one, then there is absolutely no point to send it back > >> to the responder, as the responder has indicated already that he has it. > >> The same happens in the opposite direction. > > > >> So I still cannot buy this argument. > > > > Ok, so lets assume initiator and responder being routers may have multiple > > certificates for diffent purposed. The initiator knows it needs to use > > the ACP certificate because the IKEv2 was triggered for the purpose of ACP > > Yes. > > > > The responder can also know that it must use the ACP certificate from the > > transport address that it listens to: > > Yes > > > When we assume that initiator and responder can perfectly well constrain > > themselves to their ACP certificates, it sounds almost as if we would > > want to mandate to NOT USE CERTREQ, because that would cause > > termination of the IKEv2 exchange before exchange of certificates > > takes places. > > What is causing termination ? Thats what i concluded from Valery's description to happen if the CERTREQ sent does not contain any TA hash that the recipient can match. If the functionality of CERTREQ is instead such that its just advisory and the replying side would/could/should still sent back a cert with a TA not in the CERTREQ , that would be good to understand. > > And from what i read in rfc7296, CERTREQ is optional, > > so we can mandate NOT to use it. > > The protocol allows you to send it and allows you to ignore the contents of it. That should be fine for your use case. so if the diagnostics we want would only be possible by ignoring the CERTREQ, that seems to be an option then which should need to be made clear in the ACP spec. Cheers Toerless > > If i take our explanation, in the absence of CERTREQ, the initiator > > would send the cert chain, including TA (additional requiremement from > > ACP profile), and we would have the necessary informtion on the > > responder side - even if the mutual authentication then fails. > > If you know who it is you are supposed to talking to based on an IP, why do you even need a CA chain? Seems two self signed certs configured on both ends work too. In that case, the IKE implementation would also not bother with CERTREQ (and maybe even CERT, but I???m pretty sure our implementation would still send it) > > Paul From nobody Mon Jun 22 07:42:09 2020 Return-Path: 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 BDC7E3A0D91; Mon, 22 Jun 2020 07:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 cHJABHbjstpm; Mon, 22 Jun 2020 07:42:07 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 38D363A0CB3; Mon, 22 Jun 2020 07:42:04 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id e4so19608946ljn.4; Mon, 22 Jun 2020 07:42:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=To2FEkNDxd45ZlOX0ZEnNLbqkpa9diu2/2P3rdkAb2U=; b=SEGLZg4xoG75M5t+Lga0PmSHDi5W/npor+ykn/X0NzfQuW2uJ6bUk+O7v9eqGyeG0k TWmeFnIgwdBiyeXrH0kczuFEAzkiE41bW2LP50EtORPUTh/SdDFmDnYp0QfwhAB7fm+6 E33uZ4k/XavOtrxXV0pfLExVQdr20/L6OImmzpmJjsRYioKLdqEccSd82jh8sFy6eapE EY8y4JlYeRD4nrt2HP32rarb/8t/XEp8us1VcYlCEiE/+7FvHgK958T74pWEF+XwSlFc ju/o3yQeKqXLkBgBC4QiFdmvk6Api6FSv/g4zWM4RcbLRd0/V9BgknkZin1/HDKNI3w9 NfEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=To2FEkNDxd45ZlOX0ZEnNLbqkpa9diu2/2P3rdkAb2U=; b=QfXs/ECrSi2W44s4n45/Mxnku4H0EXclEj9CUr/KTd9F3TYp/68WKEJMERVmr8ZAmQ OIZVDBNlmWdIsDsSTRT+pAetfOAlcF+0LAcojlQuC+ZJfAQMmHfYNOb2n7wBaWNj3Lp4 NRRCM7AdMbcod8f3CIc4Uer5Is5e7QLixjSUWMi0bOfTWSjmSyANN2aknnU9fWI8fOkr cXiDizqiUC7bHvEX04M8h6pqdO3G8NKNZG8UfNHPcAL4Bc23R+JUK4rks+QXcEzNo1Hg wc2lcoRylZCYobhfMYvXjX49AZ7bEaltKQ96lcl3EyyHEmBsbiNpkapt6rKpFEp2QcvW KTOw== X-Gm-Message-State: AOAM5330+d4Q6ptFqQEYTIszo4xzXNGnAZMEjM1Jpv5Qys7K0OsGrMCq YwNZy+fzZn6JTRfOmUgnaZJqcO9O X-Google-Smtp-Source: ABdhPJzJC5ekmhTdblWDeoUilePpkgXP7Nax+FgYd5U4gdbslaj+xolXrrdzogFUaHS3EBDQFGadMg== X-Received: by 2002:a2e:9859:: with SMTP id e25mr8803698ljj.243.1592836921897; Mon, 22 Jun 2020 07:42:01 -0700 (PDT) Received: from buildpc ([82.138.51.3]) by smtp.gmail.com with ESMTPSA id j25sm2126243lfh.95.2020.06.22.07.42.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jun 2020 07:42:00 -0700 (PDT) From: "Valery Smyslov" To: "'Toerless Eckert'" Cc: , "'Michael Richardson'" , "'Paul Wouters'" , "'Yoav Nir'" , References: <20200224195013.GA3878@faui48f.informatik.uni-erlangen.de> <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> <0b8001d5ecad$79ce7ad0$6d6b7070$@gmail.com> <0c9e01d5ed4c$2353f5a0$69fbe0e0$@gmail.com> <20200227183225.GP39574@faui48f.informatik.uni-erlangen.de> <0e5f01d5ee0b$f77182c0$e6548840$@gmail.com> <20200622022156.GB47906@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20200622022156.GB47906@faui48f.informatik.uni-erlangen.de> Date: Mon, 22 Jun 2020 17:42:00 +0300 Message-ID: <09ec01d648a3$4a01cf30$de056d90$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMQRTEh8jiXoowGsPdFJKCFNOl05wMD9EZlAcKt9BsCbOJ5MAG4ZZ1EAjNLfe8C0sfR4QHCJxjJpfLlg2A= Content-Language: ru Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2020 14:42:09 -0000 Hi Toerless, > Thanks, Valery > > let me pick up the one point i have no clear text solution for yet. > > On Fri, Feb 28, 2020 at 10:52:02AM +0300, Valery Smyslov wrote: > > Hi Toerless, > [...] > > Well, the example you provided doesn't work. In IKEv2 first > > the responder sends a list of TA (hashes) he has in a CERTREQ payload. > > When the initiator receives it, he checks the list trying to find > > a corresponding TA that signed his certificate (or a chain) and if he finds one, then he sends > > back a bunch of his certificates starting from EE and up to (but not including) this TA. > > If the initiator fails to find a proper TA, then the SA fails and no more exchanges take place. > > If he finds one, then there is absolutely no point to send it back > > to the responder, as the responder has indicated already that he has it. > > The same happens in the opposite direction. > > > So I still cannot buy this argument. > > Ok, so lets assume initiator and responder being routers may have multiple > certificates for diffent purposed. The initiator knows it needs to use > the ACP certificate because the IKEv2 was triggered for the purpose of ACP. > > The responder can also know that it must use the ACP certificate from the > transport address that it listens to: This are link-local scope IPv6 > addresses with a UDP port number that is signalled in a discovery protocol. > That way a responder can bind an IKEv2 instance that has only the ACP > certificate available. > > When we assume that initiator and responder can perfectly well constrain > themselves to their ACP certificates, it sounds almost as if we would > want to mandate to NOT USE CERTREQ, because that would cause > termination of the IKEv2 exchange before exchange of certificates > takes places. And from what i read in rfc7296, CERTREQ is optional, > so we can mandate NOT to use it. And I think that prohibiting sending CERTREQ is really bad idea for the profile. The better idea is to require ignoring CERTREQ content on receipt if you think it's not useful in your use case, but not banning sending it. > If i take our explanation, in the absence of CERTREQ, the initiator > would send the cert chain, including TA (additional requiremement from > ACP profile), and we would have the necessary informtion on the > responder side - even if the mutual authentication then fails. If I understand you correctly, you just want to include TA in CERT payload only for diagnostic purposes, right? Why Issuer DN from the last certificate in the chain before the TA is not sufficient? > I do not fully understand the sequence of events, e.g.: if this approach > only works for one side (for the responder learning the TA of the > initiator), or if it would only work for the other side. Only responder will learn the TA of the initiator. In case of misconfiguration the responder will receive the IKE_AUTH request that it will not be able to verify (because it doesn't have the right TA). In this case the responder must send back AUTHENTICATION_FAILED notify, and this is the only information the initiator will obtain. The reason why authentication failed and the TA the responder would use will remain unknown for the initiator in this case. Regards, Valery. > Pls. let me know, i can accordingly adjust the text. > > > More general thought: each side performs validation of peer's cert by his own, > > using his own trust assumptions. If peer sends you his TA that he will be using while validating your > > identity, then it sounds strange to me, because it's his trust anchor, not yours. > > You even cannot check whether it's expired, because peer's clock may skew from yours... > > The signaling of TA is meant to help (human) diagnostics of authentication failure, > not to make authentication successful. The candidate text for rev -25 has 4 examples. > Lots of options for misconfigurations in large enterprises, no other way to > get to the TA of a device trying to connect to you, etc. pp. > > Cheers > Toerless > > > Regards, > > Valery. > > > > > > > > 3. IKEv2 authentication MUST use authentication method 14 ("Digital > > > > > > Signature") for ACP certificates; this authentication method can be > > > > > > used with both RSA and ECDSA certificates, as indicated by a PKIX- > > > > > > style OID. > > > > > > > > > > > > I think it???s better to rephrase this more accurately: ???indicated by an ASN.1 object > > > > > > AlgorithmIdentifier??? > > > > > > > > > > Wouldn't it be more correct to say "indicated by a SubjectPublicKeyInfo > > > > > (SPKI) ASN.1 object" ? > > > > > > > > No, as far as I understand the text, it tells that the particular > > > > signing algorithm is indicated in the AUTH payload by inclusion its OID. > > > > That's partially true, it is indicated by inclusion AlgorithmIdentifier ASN.1 object > > > > (and not SubjectPublicKeyInfo or pure OID). > > > > > > > > It's probably better to just delete the text in the last sentence "as indicated by a PKIX-style OID". > > > > > > ;-) Going once, going twice ? ... If not, i'll follow this advice > > > > > > Thanks! > > > Toerless > > > > > > > Regards, > > > > Valery. > > > > > > > > > Paul > > > > > > > > _______________________________________________ > > > > IPsec mailing list > > > > IPsec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > -- > --- > tte@cs.fau.de From nobody Mon Jun 22 07:51:22 2020 Return-Path: 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 4850D3A0D90; Mon, 22 Jun 2020 07:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-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 xQm-uRLXCOFx; Mon, 22 Jun 2020 07:51:20 -0700 (PDT) Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) (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 F262F3A0D8C; Mon, 22 Jun 2020 07:51:19 -0700 (PDT) Received: by mail-lj1-x241.google.com with SMTP id i27so19608788ljb.12; Mon, 22 Jun 2020 07:51:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=HECtSSvf7NbYwyJzNU7mjMLtxQgUzsN1f+T77IfFBpo=; b=JsAsbnDG9A07wyMefvUoU3e7ZqPaQ7GWsUNvbgKwS+TyeC80plfV1Tpi+sQGZutCET kd6ACyk7qGNRIJJvAYBRGVFNBbJjd+p6GEJMkUtXlaGSfd9QMUpyOM4ZX2Io8Bok/vA4 dQWpCIIwi4QalZ0ktz/4ruqKfH8v+1pw6+PuLLbc2jDiv7ZXLxmajnltqLBcvAFFdIBL VWOYd0kEZiOwnDmAWgtzHrs2cP3psRYhFvVikA3+pEiJMm6NtDYk6MbBAKJMM4IKF1iL Y4uT8zGs4NujOJEG0XTSRjtq/n0wehBsthhkhhdHKR3Xv5t4A7EBfgBDYW7e1/T+SL8a UtKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=HECtSSvf7NbYwyJzNU7mjMLtxQgUzsN1f+T77IfFBpo=; b=XeQlxVhJFveAt6FIlqY0466XY6fslj37RCJWtfPXhnnutxBq2JmFQ3tDAjqCPzA4Ju JlOze8rJaFS7y8QOhGqW9d5JfNzegg79xZqicuHp+Ig6YA1suyQfvYJJzoJqd9lfyp2q 4FD3QpUMAxoXSFKA5fL8AKApAqKzs4VIOE/X5SgpJJlEROac0+9kUtLOfctV0rmBFAL8 rbT5F11R0xhb4tCsOtsMXyzfS+3vOrQ2sNVer4e6V2OdeOYZ+5St1Vu5TAA1WoS/VS/o nuYxkrsSD5D7tTLPpPBDB2l/AXsjoqGC/F74pKgxFsN1M7oH0OKH1mfQ3sAY3K5lCNU9 Uiuw== X-Gm-Message-State: AOAM5311tSiFnQtxotT1bfgXK8MU4ZaqRNDc1vHrhbVrodfUiR1/ui4r EBs45A7jI7lk66HfWVVFNcgD5PVy X-Google-Smtp-Source: ABdhPJznWU7ihBAVUt0me+z3fMsOa2z1ypEmLPJNWXp8EHhTtEUhfVr5EMVzvP2iKZlLbVX2aqoZLw== X-Received: by 2002:a2e:b8d5:: with SMTP id s21mr8440352ljp.34.1592837477722; Mon, 22 Jun 2020 07:51:17 -0700 (PDT) Received: from buildpc ([82.138.51.3]) by smtp.gmail.com with ESMTPSA id 193sm2748001ljj.48.2020.06.22.07.51.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jun 2020 07:51:16 -0700 (PDT) From: "Valery Smyslov" To: "'Benjamin Kaduk'" , "'Paul Wouters'" Cc: "'Toerless Eckert'" , , "'Michael Richardson'" , , "'Yoav Nir'" References: <20200622022156.GB47906@faui48f.informatik.uni-erlangen.de> <20200622034253.GL11992@kduck.mit.edu> In-Reply-To: <20200622034253.GL11992@kduck.mit.edu> Date: Mon, 22 Jun 2020 17:51:16 +0300 Message-ID: <09f301d648a4$95971030$c0c53090$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHCJxjJt5qD58MFqRQr7ltFsuMbHAHozMu8AYZuOrGo8X7FAA== Content-Language: ru Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2020 14:51:21 -0000 Hi Ben, > It's not quite "you know who you are talking to based on IP", but more of > "under this precondition, you know that the peer should be part of the same > ACP domain, and thus using the same TA as you". But you don't know exactly > which peer in the domain, and thus which EE cert, you're going to get. > > The case that (IIUC) triggered this subthread is when things are wired > badly and you end up actually talking to someone in a different ACP domain, > i.e., with a different TA. We want to be able to report what that > "unexpected" TA is, so that the mis-wiring can be diagnosed more readily. I still have an impression that this can be achieved without adding TA to the CERT payload. For example, the last cert in the path before the TA will have an Issuer DN of TA, so you'll have some information anyway... Regards, Valery. > -Ben From nobody Mon Jun 22 11:47:47 2020 Return-Path: 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 4BB083A07AB; Mon, 22 Jun 2020 11:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 O8Y2SzOuwYUV; Mon, 22 Jun 2020 11:47:43 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B5AC3A07AA; Mon, 22 Jun 2020 11:47:43 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id F115054843F; Mon, 22 Jun 2020 20:47:37 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id EABF8440043; Mon, 22 Jun 2020 20:47:37 +0200 (CEST) Date: Mon, 22 Jun 2020 20:47:37 +0200 From: 'Toerless Eckert' To: Valery Smyslov Cc: 'Benjamin Kaduk' , 'Paul Wouters' , ipsec@ietf.org, 'Michael Richardson' , draft-ietf-anima-autonomic-control-plane@ietf.org, 'Yoav Nir' Message-ID: <20200622184737.GJ57796@faui48f.informatik.uni-erlangen.de> References: <20200622022156.GB47906@faui48f.informatik.uni-erlangen.de> <20200622034253.GL11992@kduck.mit.edu> <09f301d648a4$95971030$c0c53090$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <09f301d648a4$95971030$c0c53090$@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2020 18:47:45 -0000 On Mon, Jun 22, 2020 at 05:51:16PM +0300, Valery Smyslov wrote: > Hi Ben, > > > It's not quite "you know who you are talking to based on IP", but more of > > "under this precondition, you know that the peer should be part of the same > > ACP domain, and thus using the same TA as you". But you don't know exactly > > which peer in the domain, and thus which EE cert, you're going to get. > > > > The case that (IIUC) triggered this subthread is when things are wired > > badly and you end up actually talking to someone in a different ACP domain, > > i.e., with a different TA. We want to be able to report what that > > "unexpected" TA is, so that the mis-wiring can be diagnosed more readily. > > I still have an impression that this can be achieved without adding TA to the CERT payload. > For example, the last cert in the path before the TA will have an Issuer DN > of TA, so you'll have some information anyway... Ok, so the ask to include TA cert into the signaling was raised by Mcr fairly late in the process, so from that side, i could argue it's too late and this discussion here is holding back the ACP draft too much. Then again, i spend probably a lot of time in labs and with customers troubleshooting in networks ACP and other IPsec security-association/certificate issues because of the security associations, so the need for actually STANDARDIZING diagnostic capabilities is really dear to my heart, and given how i didn't dare to bring it up, but Michael did, he has to call timeout. And given how this is an OPS area document we should think it is important. To your point: I think it is prudent to design a complex system solution with the best diagnostic we can think of upfront, instead of trying to add step by step diagnostic only after we have witnessed and tracked sufficient enough evidence it is needed. I call this the "how many dead children do we need before we approve the traffic crossing" problem. I think examples of where DN would not be sufficient (and its in the -25 text) would be expired certs from the correct CA, or certs from a misconfigured registrar with CA - where the operator unintentionally re-created a CA with the same DN, instead of going to the correct CA. But that last paragraph made me fall into the trap of me arguing the names of kids i am predicting to die, and i think thats not how we should design systems wrt. diagnostics. Cheers Toerless > Regards, > Valery. > > > -Ben -- --- tte@cs.fau.de From nobody Mon Jun 22 11:56:38 2020 Return-Path: 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 A7C3A3A07C5; Mon, 22 Jun 2020 11:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 fNnF08TyKeF2; Mon, 22 Jun 2020 11:56:34 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C74913A07C3; Mon, 22 Jun 2020 11:56:33 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id D7BA454843F; Mon, 22 Jun 2020 20:56:27 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id C0781440043; Mon, 22 Jun 2020 20:56:27 +0200 (CEST) Date: Mon, 22 Jun 2020 20:56:27 +0200 From: 'Toerless Eckert' To: Valery Smyslov Cc: ipsec@ietf.org, 'Michael Richardson' , 'Paul Wouters' , 'Yoav Nir' , draft-ietf-anima-autonomic-control-plane@ietf.org Message-ID: <20200622185627.GK57796@faui48f.informatik.uni-erlangen.de> References: <20200224195013.GA3878@faui48f.informatik.uni-erlangen.de> <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> <0b8001d5ecad$79ce7ad0$6d6b7070$@gmail.com> <0c9e01d5ed4c$2353f5a0$69fbe0e0$@gmail.com> <20200227183225.GP39574@faui48f.informatik.uni-erlangen.de> <0e5f01d5ee0b$f77182c0$e6548840$@gmail.com> <20200622022156.GB47906@faui48f.informatik.uni-erlangen.de> <09ec01d648a3$4a01cf30$de056d90$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <09ec01d648a3$4a01cf30$de056d90$@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2020 18:56:37 -0000 On Mon, Jun 22, 2020 at 05:42:00PM +0300, Valery Smyslov wrote: > And I think that prohibiting sending CERTREQ is really bad idea for the profile. > The better idea is to require ignoring CERTREQ content on receipt if you think > it's not useful in your use case, but not banning sending it. Yepp, figured that from Pauls response. > > If i take our explanation, in the absence of CERTREQ, the initiator > > would send the cert chain, including TA (additional requiremement from > > ACP profile), and we would have the necessary informtion on the > > responder side - even if the mutual authentication then fails. > > If I understand you correctly, you just want to include TA > in CERT payload only for diagnostic purposes, right? Yepp. > Why Issuer DN from the last certificate in the chain before the TA is not sufficient? See other mail. > > I do not fully understand the sequence of events, e.g.: if this approach > > only works for one side (for the responder learning the TA of the > > initiator), or if it would only work for the other side. > > Only responder will learn the TA of the initiator. > In case of misconfiguration the responder will receive > the IKE_AUTH request that it will not be able to verify > (because it doesn't have the right TA). In this case > the responder must send back AUTHENTICATION_FAILED > notify, and this is the only information the initiator will obtain. > The reason why authentication failed and the TA the responder > would use will remain unknown for the initiator in this case. Ok, thanks. I think ACP can deal with this. Need to heck the text we have and see whas missing... Cheers Toerless > Regards, > Valery. > > > Pls. let me know, i can accordingly adjust the text. > > > > > More general thought: each side performs validation of peer's cert by his own, > > > using his own trust assumptions. If peer sends you his TA that he will be using while validating your > > > identity, then it sounds strange to me, because it's his trust anchor, not yours. > > > You even cannot check whether it's expired, because peer's clock may skew from yours... > > > > The signaling of TA is meant to help (human) diagnostics of authentication failure, > > not to make authentication successful. The candidate text for rev -25 has 4 examples. > > Lots of options for misconfigurations in large enterprises, no other way to > > get to the TA of a device trying to connect to you, etc. pp. > > > > Cheers > > Toerless > > > > > Regards, > > > Valery. > > > > > > > > > > 3. IKEv2 authentication MUST use authentication method 14 ("Digital > > > > > > > Signature") for ACP certificates; this authentication method can be > > > > > > > used with both RSA and ECDSA certificates, as indicated by a PKIX- > > > > > > > style OID. > > > > > > > > > > > > > > I think it???s better to rephrase this more accurately: ???indicated by an ASN.1 object > > > > > > > AlgorithmIdentifier??? > > > > > > > > > > > > Wouldn't it be more correct to say "indicated by a SubjectPublicKeyInfo > > > > > > (SPKI) ASN.1 object" ? > > > > > > > > > > No, as far as I understand the text, it tells that the particular > > > > > signing algorithm is indicated in the AUTH payload by inclusion its OID. > > > > > That's partially true, it is indicated by inclusion AlgorithmIdentifier ASN.1 object > > > > > (and not SubjectPublicKeyInfo or pure OID). > > > > > > > > > > It's probably better to just delete the text in the last sentence "as indicated by a PKIX-style OID". > > > > > > > > ;-) Going once, going twice ? ... If not, i'll follow this advice > > > > > > > > Thanks! > > > > Toerless > > > > > > > > > Regards, > > > > > Valery. > > > > > > > > > > > Paul > > > > > > > > > > _______________________________________________ > > > > > IPsec mailing list > > > > > IPsec@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > _______________________________________________ > > > IPsec mailing list > > > IPsec@ietf.org > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > -- > > --- > > tte@cs.fau.de -- --- tte@cs.fau.de From nobody Tue Jun 23 00:10:58 2020 Return-Path: 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 813DB3A09BA; Tue, 23 Jun 2020 00:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 k-qwQp5ZhbVK; Tue, 23 Jun 2020 00:10:55 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 C05773A09B4; Tue, 23 Jun 2020 00:10:54 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id q19so22223514lji.2; Tue, 23 Jun 2020 00:10:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=JcteHuKkcBb5LeNTGALQs5W6guvtTiAv88AGg8aj5xg=; b=vRfjqmVoenDvYo07G7H+eA8wHv/zo8Ke+umhUfDzbxagTfP7++ZwGOEJqwqBtSZ/ub LgGDSUA3QZOGiSjAFn0UBCvwLxFS35a0Q+dPlDkHaPLZ6Zr/orOjMEebqqkF1Zb2q5Vl F83qR0YhYCGPtTYLGMzOAGuEHkqGie1N5aPwaIo1W1x2H41kagxjdE2/V+qH2VFTXrYj NiQvk8UwU+aS53wv5blT/CDLKo9YxN8RvxPrjaXBPR0TPQHpY4hZhnrB+BPdbaO8hhrc IqMgZapBC+5Ecb0SDK1DA33/5dr81vDgNR+M9fRB+L+VpBvvfas/ftXLcE9HsZB0tAc3 Txtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=JcteHuKkcBb5LeNTGALQs5W6guvtTiAv88AGg8aj5xg=; b=LwivAkVX2IZlUhUbSd1mzM3BeQXInrkqpRgGegk/6XfmvUj6KAtgGw6r6KDPI8hCk/ qa8lRBSb8HuR8SImnJb/5PO/UZPmWcy7EmcF3DW/Vg3NcYGYD5bd5NRb3SbMW+zuM1KJ /4jhOqTWK19CZ4eq20cXbIcasz1/UsMJ3nzXpZ+24/Ck5APD9PTyL0hjR9aqwvGSaltc VpAdlnPOqE27sJrTETQ1yzptq/kg8umjuRTWkCwXTG7DITUOioM5AhJGii/jMQzt5Hv6 vstASsjVW0HXfqJY5MsOW8wqTDrLxtoAxsrG72OQRfz04cHtu+bARFSB6F30nkwnbIOD VqIA== X-Gm-Message-State: AOAM532FsxxzS15P6EEw6FSW0GVagRBOZMbjgwwOlVaiNMZSr5U7UYP+ AKwNM8Hlr4BtchL0UVvmZwXSeHCT X-Google-Smtp-Source: ABdhPJz2Bo86fhvfUdUWhYPICSP6dnmPHg0yCtyWVdsMK7Ew3ruEv7z/7FJgdZwjvyfKhFR0hRTtFw== X-Received: by 2002:a2e:3a18:: with SMTP id h24mr10460563lja.268.1592896252390; Tue, 23 Jun 2020 00:10:52 -0700 (PDT) Received: from buildpc ([82.138.51.3]) by smtp.gmail.com with ESMTPSA id w20sm3103706lji.7.2020.06.23.00.10.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jun 2020 00:10:51 -0700 (PDT) From: "Valery Smyslov" To: "'Toerless Eckert'" Cc: "'Benjamin Kaduk'" , "'Paul Wouters'" , , "'Michael Richardson'" , , "'Yoav Nir'" References: <20200622022156.GB47906@faui48f.informatik.uni-erlangen.de> <20200622034253.GL11992@kduck.mit.edu> <09f301d648a4$95971030$c0c53090$@gmail.com> <20200622184737.GJ57796@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20200622184737.GJ57796@faui48f.informatik.uni-erlangen.de> Date: Tue, 23 Jun 2020 10:10:51 +0300 Message-ID: <0ac101d6492d$6e51d120$4af57360$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHCJxjJt5qD58MFqRQr7ltFsuMbHAHozMu8AYZuOrEDZBQVuAFwyAVQqMvgLoA= Content-Language: ru Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2020 07:10:57 -0000 Hi Toerless, > > I still have an impression that this can be achieved without adding TA to the CERT payload. > > For example, the last cert in the path before the TA will have an Issuer DN > > of TA, so you'll have some information anyway... > > Ok, so the ask to include TA cert into the signaling was raised by Mcr fairly > late in the process, so from that side, i could argue it's too late and this > discussion here is holding back the ACP draft too much. > > Then again, i spend probably a lot of time in labs and with customers > troubleshooting in networks ACP and other IPsec security-association/certificate > issues because of the security associations, so the need for actually > STANDARDIZING diagnostic capabilities is really dear to my heart, > and given how i didn't dare to bring it up, but Michael did, he has to call > timeout. And given how this is an OPS area document we should think it > is important. Well, this is the essence of my concerns: it seems to me that the issues you describe are not explicitly anima related issues, instead they are generic IPsec misconfiguration issues. If you believe they are so important, then they must be addressed in the ipsecme WG, and not by profiling IPsec explicitly for anima. (Unless I'm missing something about specificity of these issues for anima). > To your point: I think it is prudent to design a complex system solution > with the best diagnostic we can think of upfront, instead of trying to > add step by step diagnostic only after we have witnessed and tracked > sufficient enough evidence it is needed. I call this the "how many > dead children do we need before we approve the traffic crossing" > problem. I agree with this in general, but in security protocol there is always a tradeoff between better diagnostics and leaking additional information to a potential attacker. Often the latter outweigh. > I think examples of where DN would not be sufficient (and its in the -25 > text) would be expired certs from the correct CA, or certs from > a misconfigured registrar with CA - where the operator unintentionally > re-created a CA with the same DN, instead of going to the correct CA. Expired certs can be detected locally, I don't believe this is a problem (I assume your clock skew is not too large). In case your TA was replaced by the newer cert with the same DN as result of rollover, you'll have the Authority Key Identifier from the last cert in the path, so you'll be able to determine which particular TA with the same DN your peer intended to use... > But that last paragraph made me fall into the trap of me arguing the > names of kids i am predicting to die, and i think thats not how we should > design systems wrt. diagnostics. :-) Regards, Valery. > Cheers > Toerless > > > Regards, > > Valery. > > > > > -Ben > > -- > --- > tte@cs.fau.de From nobody Thu Jun 25 03:24:24 2020 Return-Path: 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 815043A08FD; Thu, 25 Jun 2020 03:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 TqMgXABXJSKH; Thu, 25 Jun 2020 03:24:21 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id D8BC43A0420; Thu, 25 Jun 2020 03:24:20 -0700 (PDT) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 2E55960F34; Thu, 25 Jun 2020 10:24:19 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Christian Hopps In-Reply-To: <24278.24659.921904.72666@fireball.acr.fi> Date: Thu, 25 Jun 2020 06:24:18 -0400 Cc: Christian Hopps , IPsecME WG , ipsecme-chairs@ietf.org, ipsecme-ads@ietf.org, Benjamin Kaduk , Yoav Nir Content-Transfer-Encoding: quoted-printable Message-Id: <1A6F92EC-5BF9-45BB-8D51-1C70BDCD01BB@chopps.org> References: <13344.1583165241@localhost> <24278.24659.921904.72666@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [IPsec] Early Allocation Request for IPTFS_PROTOCOL IP protocol number. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 10:24:23 -0000 Hi Tero, I believe the discussion has died down again and we have answers to the = questions you are concerned will be raised by the other reviewers of the = request (Yoav and Benjamin for the early allocation), to wit: 1) WRAP still requires a next-header/protocol number. Additionally it = would reduce bandwidth, is not widely implemented, and ultimately is not = a great fit as it's trying to solve a different problem (allowing more = packet inspection). 2) We could technically overload/re-use an existing IP protocol number = that we assume will never be used as an ESP payload, but this is a = sub-optimal solution as it disallows the re-use of IPTFS framing outside = of ESP. Ultimately this can serve as a backup solution that aligns with = (and thus supports) this (temporary) early allocation request. So can we move forward with the early allocation request? Thanks, Chris. > On Jun 2, 2020, at 10:21 AM, Tero Kivinen wrote: >=20 > Christian Hopps writes: >> Dear ipsecme Chairs, >>=20 >> This request is inline with the guidelines as set forth in RFC7120 >> (https://tools.ietf.org/html/rfc7120)=20 >>=20 >> I would like to request early allocation of the IP protocol number >> [A] used for the ESP payload identifier for IPTFS (suggested value >> is 144 or next available) as documented in >> https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-01 [B]=20 >>=20 >> This will aid in the deployment of an experimental implementation of >> the documented protocol as well as testing inter-operability with >> other expected implementations. [C], [D]=20 >>=20 >> In addition to these RFC7120 reasons, the topic was raised on the WG >> list and discussed in previous meetings. The discussions highlighted >> that early allocation was a good choice as it allowed for the >> temporary assignment and an extended period of time for adequate >> review (and explanation if needed) of this allocation prior to >> publication requested being reached.=20 >=20 > I am bit concerned about this. First of all, as far as I understand > for IPsec we do not need real IP protocol number, as the number we are > using is never going to appear anywhere in the actual IP packet > header, it only appears in the ESP trailer Next Header field. >=20 > Note, that the ESP Next Header field is not exactly same as IP > Protocol Numbers, it is: >=20 > The Next Header is a mandatory, 8-bit field that identifies the type > of data contained in the Payload Data field, e.g., an IPv4 or IPv6 > packet, or a next layer header and data. The value of this field is > chosen from the set of IP Protocol Numbers defined on the web page = of > the IANA, e.g., a value of 4 indicates IPv4, a value of 41 indicates > IPv6, and a value of 6 indicates TCP. >=20 > i.e., it is separate set of numbers, which happen to mostly match what > IP protocol numbers use, but we also interpret some values > differently, for example value 59 (IP protocol no next header) is used > to indicate dummy packet etc. >=20 > We could easily use similar trick than what we use for dummy packets > for this too. Also there is warpped ESP which would allow us to use > that, which would again allow us to do things without allocating new > IP protocol number. >=20 > We had some discussion about this in the mailing list earlier, but I > didn't think that there was really a final result from that discussion > (or I might be remembering wrong, as I didn't have too much time to > participate that discussion at that time). >=20 > The reason I am concerned is that I was there when we wanted to get > the Wrapped ESP IP protocol number, and there was quite a lot of > discussion going on at that time, and it was not just we send request, > and we get the number. Of course at that point I also supported > proposal which did not require new IP protocol number, so for me the > problems getting IP number was for my favor :-) >=20 > Anyways before we commit resources and try to get the IP protocol > number I want to make sure we actually need it, and we have good > responses to why we cannot do it with the other ways I presented > above. >=20 > I would assume those questions are going to be asked from chairs or > area directors during the process anyways, so we need to have good > answers to them ready (and for me it would be quite hard to explain > why we cannot use warpped ESP, or dummy packet trick as I think we can > do those and we do not need IP protocol number). >=20 > Note, that if the answer is going to be that we want to use this also > when we are not using IPsec, then this is even bigger can of worms, as > that would most likely mean that this work does not belong to the > IPsecME working group, but should be part of completely different > area... > --=20 > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 From nobody Thu Jun 25 09:16:09 2020 Return-Path: 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 0B3813A0CC3; Thu, 25 Jun 2020 09:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 pDoTdIPLoalR; Thu, 25 Jun 2020 09:15:53 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 650B73A0CC8; Thu, 25 Jun 2020 09:15:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 62E9E389C9; Thu, 25 Jun 2020 12:13:05 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id jfchY6PLzFTk; Thu, 25 Jun 2020 12:13:04 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3C2F3389AC; Thu, 25 Jun 2020 12:13:04 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 88B835DE; Thu, 25 Jun 2020 12:15:46 -0400 (EDT) From: Michael Richardson To: Christian Hopps , IPsecME WG , Benjamin Kaduk , ipsecme-ads@ietf.org In-Reply-To: <1A6F92EC-5BF9-45BB-8D51-1C70BDCD01BB@chopps.org> References: <13344.1583165241@localhost> <24278.24659.921904.72666@fireball.acr.fi> <1A6F92EC-5BF9-45BB-8D51-1C70BDCD01BB@chopps.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] Early Allocation Request for IPTFS_PROTOCOL IP protocol number. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 16:16:08 -0000 --=-=-= Content-Type: text/plain Christian Hopps wrote: > 1) WRAP still requires a next-header/protocol number. Additionally it > would reduce bandwidth, is not widely implemented, and ultimately is > not a great fit as it's trying to solve a different problem (allowing > more packet inspection). > 2) We could technically overload/re-use an existing IP protocol number > that we assume will never be used as an ESP payload, but this is a > sub-optimal solution as it disallows the re-use of IPTFS framing > outside of ESP. Ultimately this can serve as a backup solution that > aligns with (and thus supports) this (temporary) early allocation > request. > So can we move forward with the early allocation request? I would agree. The WG should go ahead with the early allocation request. It still needs AD approval, and then goes to the IESG. I think that the WG has agreed: 1) we need a number. 2) we'd like the number via early allocation 3) we have rough consensus that there are a set of protocol numbers that we *could* reuse, and I think that we could make a list of protocol numbers we know we can *not* reuse. (4,6,17 would start the list we can not use) so let's put the allocation request in, and let's let the IESG decide how much they want to optimize the protocol space. I think that we have consensus that our need for uniqueness is not as strong as other users. BUT simplificity of accounting and coding would make it simplest if the number was not something already in use. But, we are not out of protocol numbers, and I think that if it comes to recycling numbers, that maybe there are many low-hanging fruit as candidates. [13-16,18-26 comes easily to mind] Also, if the IESG wanted to mark WRAP as returned, that's a different discussion as well. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl70zbIACgkQgItw+93Q 3WUAeAf+I5P+mHedoOCi5tg75vjjwnvS67VTI//Gc9E2C55EoLcb8DDR3lh/SC+p 0TuwSwVf+Es2NV1e1U+VEQ+Yv/ic1n6mN/pne5irwyhg11ejhfeQhRP2zZTHKhBn DhDXEXkqxOBf1dh4UTreRkLi2ve4TqAt1chr0EueZyXMWYgkXN6jmCIaPV2Si//2 qobVDJ9fCbps6YgVCog6Ix42ANIPDrhjDoilyhIi6ikK9TfNKn+q1aAUrO48S6jA J/EzowTkKRUCdwSKTVnI/UcZ6G0t5f+3twzQVjfNXu5uYjUTfIBAD8YopdroiItv A0QuxPKehw0s/4HjH2bn4FQZCGldJg== =5OWU -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 25 09:41:52 2020 Return-Path: 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 5C7903A0C59; Thu, 25 Jun 2020 09:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 9t4imBX4uVs8; Thu, 25 Jun 2020 09:41:48 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DA463A0C51; Thu, 25 Jun 2020 09:41:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 94620389C9; Thu, 25 Jun 2020 12:39:04 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id yIyh3CIk3ojI; Thu, 25 Jun 2020 12:39:03 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6F977389C0; Thu, 25 Jun 2020 12:39:03 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id BC635A9; Thu, 25 Jun 2020 12:41:45 -0400 (EDT) From: Michael Richardson to: Christian Hopps , IPsecME WG , Benjamin Kaduk , ipsecme-ads@ietf.org In-Reply-To: <3711.1593101746@localhost> References: <13344.1583165241@localhost> <24278.24659.921904.72666@fireball.acr.fi> <1A6F92EC-5BF9-45BB-8D51-1C70BDCD01BB@chopps.org> <3711.1593101746@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] Early Allocation Request for IPTFS_PROTOCOL IP protocol number. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 16:41:51 -0000 --=-=-= Content-Type: text/plain Michael Richardson wrote: > But, we are not out of protocol numbers, and I think that if it comes to recycling > numbers, that maybe there are many low-hanging fruit as candidates. > [13-16,18-26 comes easily to mind] If I had to pick something, though, I'd pick 57, SKIP :-) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl7008kACgkQgItw+93Q 3WXQRAgAuX40t4T5+GirdWA2nAoz3xRkgV+1NYrBXDldJSKmXz4pArMBy2taV1b6 3fPQXgyKvAk+u629mvy/C6UV9KI+vvkUOGMpvuv05DR9Q+EuZSmeuFlXBjnH+VbH e8Z4ndH25CoTI8jeM3OPCwIfQAJZielnI4hElBpC++A9qoXPM6e09AGpn8Yuw7Lg KOpb3Tsi6V+bOUCs0sSXmwUgEvIEks0+DY/4Y/8MOwo+gS1ZfNixzik2vBPw8jLv uAZLzacdT/3ZCyvNCzl8a1YQ8PnLbJTzas+/wOKqoQ++VBThVInib59pk9n0ENlP URVj/Wt7hAydefgbR3i5oWBk2nSfFw== =XPlZ -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 25 10:43:56 2020 Return-Path: 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 2A03E3A0DF7 for ; Thu, 25 Jun 2020 10:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 Qq8T1Fa1C_Op for ; Thu, 25 Jun 2020 10:43:53 -0700 (PDT) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) (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 ABB873A0DF8 for ; Thu, 25 Jun 2020 10:43:53 -0700 (PDT) Received: from cmgw11.unifiedlayer.com (unknown [10.9.0.11]) by gproxy7.mail.unifiedlayer.com (Postfix) with ESMTP id 14367215E0D for ; Thu, 25 Jun 2020 11:43:49 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id oVuej2aT6ugPhoVuejjVyq; Thu, 25 Jun 2020 11:43:49 -0600 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.3 cv=JYqSU3CV c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=xqWC_Br6kY4A:10:nop_ipv6 a=nTHF0DUjJn0A:10:nop_rcvd_month_year a=Vy_oeq2dmq0A:10:endurance_base64_authed_username_1 a=r77TgQKjGQsHNAKrUKIA:9 a=l70xHGcnAAAA:8 a=48vgC7mUAAAA:8 a=AkHnC7Zg-u-nX14V7rkA:9 a=QEXdDO2ut3YA:10:nop_charset_2 a=Az6sxu5EcSdj4OOl0cgA:9 a=w9RSe_aWVprFqq9T:21 a=_W_S_7VecoQA:10:nop_html a=JtN_ecm89k2WOvw5-HMO:22 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=fvikbOhCXeNptojWzKBPXQYdFtxLinc4wFoHH3bHa3k=; b=fCzI4z7Xljdp0c5O5/X1GLWT7Y ACPS/BSBskUa7nVZ+gKYBCyLDTbQCheqIjmow7Yic7lm1ajE9IGLUuf212IPYg9MTe1nf8MrKU0wn Gn62AmFhk9rdcloInYrNHP8qE; Received: from [127.0.0.1] (port=14707 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1joVue-001Lgw-FB; Thu, 25 Jun 2020 11:43:48 -0600 To: Michael Richardson , Christian Hopps , IPsecME WG , Benjamin Kaduk , ipsecme-ads@ietf.org References: <13344.1583165241@localhost> <24278.24659.921904.72666@fireball.acr.fi> <1A6F92EC-5BF9-45BB-8D51-1C70BDCD01BB@chopps.org> <3711.1593101746@localhost> <10082.1593103305@localhost> From: Lou Berger Message-ID: <209b09a5-a052-3228-9b1c-c0ef9b057ccd@labn.net> Date: Thu, 25 Jun 2020 13:43:43 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <10082.1593103305@localhost> Content-Type: multipart/alternative; boundary="------------3FE9A9CB664183D9D313A482" Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 127.0.0.1 X-Source-L: Yes X-Exim-ID: 1joVue-001Lgw-FB X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([IPv6:::1]) [127.0.0.1]:14707 X-Source-Auth: lberger@labn.net X-Email-Count: 27 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [IPsec] Early Allocation Request for IPTFS_PROTOCOL IP protocol number. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 17:43:55 -0000 This is a multi-part message in MIME format. --------------3FE9A9CB664183D9D313A482 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I really think it makes most sense to push put in the early allocation request.  This is a valid long term use case.  There's no real shortage of IP numbers and IANA is continuing to assign them.  Also there's also a slew of them that can be reclaimed if/when they do become scarce.  I can even vouch for giving up one (v5) if/when needed  - it's already marked historic;-) Lou On 6/25/2020 12:41 PM, Michael Richardson wrote: > Michael Richardson wrote: > > But, we are not out of protocol numbers, and I think that if it comes to recycling > > numbers, that maybe there are many low-hanging fruit as candidates. > > [13-16,18-26 comes easily to mind] > > If I had to pick something, though, I'd pick 57, SKIP :-) > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --------------3FE9A9CB664183D9D313A482 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I really think it makes most sense to push put in the early allocation request.  This is a valid long term use case.  There's no real shortage of IP numbers and IANA is continuing to assign them.  Also there's also a slew of them that can be reclaimed if/when they do become scarce.  I can even vouch for giving up one (v5) if/when needed  - it's already marked historic;-)

Lou

On 6/25/2020 12:41 PM, Michael Richardson wrote:
Michael Richardson <mcr+ietf@sandelman.ca> wrote:
    > But, we are not out of protocol numbers, and I think that if it comes to recycling
    > numbers, that maybe there are many low-hanging fruit as candidates.
    > [13-16,18-26 comes easily to mind]

If I had to pick something, though, I'd pick 57, SKIP :-)

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-





_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--------------3FE9A9CB664183D9D313A482-- From nobody Fri Jun 26 06:41:03 2020 Return-Path: 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 7C8BD3A0BF7; Fri, 26 Jun 2020 06:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi 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 bogYcEjUapmZ; Fri, 26 Jun 2020 06:40:58 -0700 (PDT) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [IPv6:2a0b:5c81:1c1::37]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2717F3A0A5F; Fri, 26 Jun 2020 06:40:56 -0700 (PDT) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id E537E1B00084; Fri, 26 Jun 2020 16:40:53 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1593178854; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=hx+RiFL/QWftaQCxoXMPK+Ul5YNANvTZjcM56RTNYm8=; b=fnUEX3GiGcXayUx+f/e4r8/C6MHr8+mfpEJkB1JD2fv/HB69uQKKY1Z9OupxrkRaU3gL4S azhlqn7Lzw/9Qf2cn5zEhq7uETHrgiSwS5v2E03STyG0HUTejE2j66T9eo6SmrYCOFNYhO aS+EQ+SVDH9mBwCeuZ5XCFTA9AQm3CxZk6oqzD1k6MvCEdjvfoP6g/AaJxJtf0z9BtGpGO BwuOjq8gq/KpUUVzm9kDV8mSMdh6UjtMpHDbuZG+9r9XV4D4ymYZ4rEHHndvIL5mAt1avK lynirDNDmdt6DD0xhe36PpR53qTlFpTY9N+iZb1zeyZUNTofCxxZK0n6WUgung== Received: by fireball.acr.fi (Postfix, from userid 15204) id 8B48025C0FD9; Fri, 26 Jun 2020 16:40:53 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24309.64229.308771.733097@fireball.acr.fi> Date: Fri, 26 Jun 2020 16:40:53 +0300 From: Tero Kivinen To: Michael Richardson Cc: Paul Wouters , 'Toerless Eckert' , Valery Smyslov , ipsec@ietf.org, 'Yoav Nir' , draft-ietf-anima-autonomic-control-plane@ietf.org In-Reply-To: <24142.1592760359@localhost> References: <20200224195013.GA3878@faui48f.informatik.uni-erlangen.de> <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> <0b8001d5ecad$79ce7ad0$6d6b7070$@gmail.com> <0c9e01d5ed4c$2353f5a0$69fbe0e0$@gmail.com> <20200619145112.GA47906@faui48f.informatik.uni-erlangen.de> <24142.1592760359@localhost> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 30 min X-Total-Time: 42 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1593178853; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=hx+RiFL/QWftaQCxoXMPK+Ul5YNANvTZjcM56RTNYm8=; b=CfIerhzZVtO3E/dgeuVUAkLxxNjOzIueWTjIHuqfqED4rVq/Hud+/n5/x9ZUOxeqE4r1Qi 97XcC3KmFUb2cdslOE+FCTDVtyAjqZynUadHblScPGOERw/I1XUuGCnKyN+8+bxUC0Xz9L abPySXzZPshCRKK3/IDuo3HKM1kla7gyKMNFzljiiU5soYeTV1EH5rCWopTgzjcz64zCdC 03JgRJ218S/7hLKTArNrN9sssKm9uiRX8Tz/BHjEIXSjGHmpPRX/YNE5Y+XTPRj0IkFkoj H+Z4/4c+rbTGm7/gQrMVea8WDwjZbGbWbsVAjmxeWZNaSLDKbsAdxpvdp6k2VQ== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1593178854; a=rsa-sha256; cv=none; b=u/16wH+N6dLVT97PdJgSIbWc3z+Jr9OLq1eMPcLJ/DGiZZSvyYEY/6fM9juhHVxUNRrdKA ltdlK+iNAdFVriTCzlkr1UEIWFU3/wpOJtCOn6Tlv9hUtvHCM3qtm3JmRyD3wG18bfaJN7 wCOCMHe+Mj2LLbVtIY3lnTrnqcxqiDrS6wby8FtGf76Gswaoa/yNoYuEGTjwfPDMIcMOo9 Ekea3RiAQ6CCK0jJwPkcxTIX5WsYR3qOAVL5p14r49HHo9HfvrQQxuNXFwoWmwTlvZe9u0 sZqmry8MDXfZL6IMohNhYyoZAvp49PKEmcvhHBLrzmHU0K966viDgNIFHrpAIQ== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: Re: [IPsec] Troubleshooting IPsec peer certs (was: Re: IPsec profile feedback wanted (draft autonomic control) plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 13:41:02 -0000 Michael Richardson writes: > Unless we can convince various people otherwise, the TA will all be > private enterprise/ISP CAs. And for some reason those same private enterprise/ISP people are exactly those who say that we can't leak our CA certificates out, and thats why we can't have publicly available repository of our certificates or CAs, which of course lead to problem if you mandate sending that private information whoever ever wants to ask it... > > The reason sending hashes and not the root CA's is that it becomes very > > easy to determine which CA's a particulat client supports. I know that > > is elpful to troubleshooting, but it was deemed a security/privacy > > issue. > > We are not dealing with "clients", because this is not a remote access > scenario. Nor are these system visible in any way to the Internet. > "Physical" connectivity is required. (In quotes, because microwaves, > satellite systems and other layer-2 transmission media) > > This is an overlay network of ISP routers that use IPsec over IPv6 > **Link-Layer** addresses. The privacy considerations are significantly > different, while the need to do troubleshooting significantly higher. Ok, that clarifies some things. > Sending the *complete* trust chain solves the problem, and should > never cause a problem to any properly implemented daemon/certificate > chain validator. That might not solve anything even when you send the final TA. It does not really help when you get TA which has Subject name of "CN=Root", and Issuer name of "CN=Root". There is still no information where to go to find out who is the owner of the TA. If those are private TAs created by private enterprises/ISPs there is no guarantee that the TA itself has anything useful in it that allows you to identify who created it. This is especially true if the certificate hiearchy is created automatically by the vendor software without any actual user interaction. Yes, the TA might have something useful but it might not. On the other hand the Identity the other end sent might also have something useful or might not. If we look at different information available during IKEv2 negotiation to the endpoint of the exchange. During IKE_SA_INIT we might have Vendor IDs indicating the vendor of the implementation. This usually is hash of something, and it is always priprietary format, meaning you can recognize familiar vendors (i.e., you can map vendor you have seen before to vendor ID it sent before), but you cannot map random vendor ID to vendor. Anyways this might give you some debugging information. Then we have CERTREQ from the responder, i.e., we know which trust anchors it trusts, and we get hash of those keys it trust. The main idea there is to allow initiator to select one of the certificates he has in such way that he proposes certificate signed by one of those trust anchors. As both ends are supposed to be configured with trust anchors which they trust in, and from which they have certificates from, they can map this hash to actual trust anchor without any problems. Creating a mapping from trust anchor hash to trust anchor is trivial if you ever see the actual trust anchor certificate anywhere. If you ever have more than one TA ever in normal operations you want to mandate sending CERTREQs always. In the IKE_AUTH you have CERTREQ from the initiator, containing all of the trust anchors from the initiator, even when it used certificate from the only one of them. This allows responder to use different trust anchor when responding, i.e., initiator might use TA1, and responder might use TA2, but both trust in both TA1, and TA2, but they just happen to have certificates from different TAs. In addition to that there is CERT from to initiator, if initiator does not already know that the responder has its certificate. In some setups the TA hierarchy is properly made and each peer can find certificates from somewhere else, and there is no need to send them inside IKEv2 at all. In most common case you always send end entity certificate inside the IKE_AUTH so other end can verify it against its TA and match it against the identity. Note, that the certificate itself include Subject Name telling who this certificate was created for, and Issure Name telling who signed it. If the certificate hierarchy and names in the hierarchy are properly set there is no need to send TA. If the Subject name is "CN=device1, OU=HR Department, O=Example Inc, C=US", and the Issuer name is "CN=Root TA 2020, O=Example Inc, C=US", that already gives you all information you need to find out who is the owner of the cert. If the names are stupid like Subject name of "CN=device1231", and Issuer Name of "CN=Root" that does not help to get TA, as the TA again just have both Issuer Name and Subject Name of "CN=Root" which does not help you. Then there is still the IDi and IDr identities, those tell the identity of the peer. Depending on what identities are in use they might be very useful for debugging (like "device1@hr.example.com" and "vpn@example.com") or they might be completely useless like "10.5.0.1" and "10.1.0.1". Anyways sending TA only helps at all if the one who created the TA actually put some useful information in there, and if he did that, then the same information is already in the EE, thus seeing the TA does not really help. I would just put suggestion saying that whoever is creating those certificate hierarhies, they should use proper naming and include the name of the company etc in the Subject name of the certificates... -- kivinen@iki.fi From nobody Fri Jun 26 06:56:41 2020 Return-Path: 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 5C1323A0029; Fri, 26 Jun 2020 06:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi 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 0z-aAr1DvQYg; Fri, 26 Jun 2020 06:56:38 -0700 (PDT) Received: from meesny.iki.fi (meesny.iki.fi [IPv6:2001:67c:2b0:1c1::201]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AE173A0028; Fri, 26 Jun 2020 06:56:35 -0700 (PDT) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: kivinen) by meesny.iki.fi (Postfix) with ESMTPSA id 881B120549; Fri, 26 Jun 2020 16:56:32 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1593179792; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=OUUMTCiGDezVmi0yuxoSoodMvH0hIm4vGcy3esvcXho=; b=Tgd3OlDG2NLczreHKTY5AjEFetsCYqYURjZLWBCEdaYHC4of9pgp6c4GQle1qPgo3hVu8f gFtTa+DVqMckr3J9ztwCgpISRfzFlVS8qHc4WZam0HSmktyTXVn481LWs6dRq8VZivHn7M yhRuqqEq2HlPAPxcm5BSR1TGr48XTnM= Received: by fireball.acr.fi (Postfix, from userid 15204) id 32EF125C0FDA; Fri, 26 Jun 2020 16:56:32 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24309.65167.965465.953788@fireball.acr.fi> Date: Fri, 26 Jun 2020 16:56:31 +0300 From: Tero Kivinen To: "Valery Smyslov" Cc: "'Toerless Eckert'" , 'Michael Richardson' , draft-ietf-anima-autonomic-control-plane@ietf.org, 'Yoav Nir' , ipsec@ietf.org, 'Benjamin Kaduk' , 'Paul Wouters' In-Reply-To: <0ac101d6492d$6e51d120$4af57360$@gmail.com> References: <20200622022156.GB47906@faui48f.informatik.uni-erlangen.de> <20200622034253.GL11992@kduck.mit.edu> <09f301d648a4$95971030$c0c53090$@gmail.com> <20200622184737.GJ57796@faui48f.informatik.uni-erlangen.de> <0ac101d6492d$6e51d120$4af57360$@gmail.com> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 6 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1593179792; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=OUUMTCiGDezVmi0yuxoSoodMvH0hIm4vGcy3esvcXho=; b=R7FD2MApXXsphdzi5RTLAwfvp8HVbDIs/4FOGwag4A8IbNjNo4ik2gYr/Oc9X/yRw6BpKZ gJgufivWLMO1EzzrjfPoBiIW/OHdCcwVs63AeYrTk+23jNuTKS4sv/1BGRUUzCOry6VE6x PLZK7trwUutERPijAxotsdfTaqOA2qY= ARC-Seal: i=1; s=meesny; d=iki.fi; t=1593179792; a=rsa-sha256; cv=none; b=W2uSqArWL4IhpAML8899KpMG6ie54yssxprwloI3DjcD1WS2hmPZdT9sCbJETEzcTAzx6B XoiGuuw5oh9gFWkP+lUKPbV5IE2L1UXwNS0PCs2XnlEuQbwZuCcrAEEJKoMimC7Tk0TYjz l87z+iHxxV9ERJ/NaHhDFnp77w21Gf4= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 13:56:41 -0000 Valery Smyslov writes: > > I think examples of where DN would not be sufficient (and its in the -25 > > text) would be expired certs from the correct CA, or certs from > > a misconfigured registrar with CA - where the operator unintentionally > > re-created a CA with the same DN, instead of going to the correct CA. > > Expired certs can be detected locally, I don't believe this is a problem > (I assume your clock skew is not too large). In case your TA was replaced > by the newer cert with the same DN as result of rollover, you'll > have the Authority Key Identifier from the last cert in the path, > so you'll be able to determine which particular TA with the same DN > your peer intended to use... All certificate validation issues are something that can really only be debugged locally. In one of the implementations I was aware of there were about half a dozen different error codes returned during the validation problem each listing all errors it hit during the validation, and there is no way of knowing which of them is the actual final cause of the validation failure. I mean you could get LDAP_UNREACHABLE, EXPIRED_CERT, SELF_SIGNED_CERT during the same validation check. This might have been caused because you hit expired intermediate certificate, and there happend to be temporary failure to refetch that intermediate certificate from the LDAP server, and because of thise LDAP failure you used another cross signed certificate ending to the self signed trust anchor which you do not trust. So you get all those tree errors, and the real issue was the LDAP_UNREACHABLE. On the other hand it might have also been that the problem was the intermidiate certificate was expired, and there was no new certificate issued for it because of operation problems, and the LDAP_UNREACHABLE came because we cannot connect to the ldap server specified in that cross signed trust anchor, i.e. the correct problem was EXPIRED_CERT etc... Trying to find out what was the real reason why certificate validation failed is very complicated issue, and usually trying to do it by just having certificate chains is not enough. The only somewhat easy way is to look at the logs of the device and hope they are detailed enough to tell you these kind of things... -- kivinen@iki.fi From nobody Fri Jun 26 09:11:30 2020 Return-Path: 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 02ED13A0967; Fri, 26 Jun 2020 09:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no 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 KEu3v89btkrc; Fri, 26 Jun 2020 09:11:26 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 636613A0B9F; Fri, 26 Jun 2020 09:10:59 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id ADF96548440; Fri, 26 Jun 2020 18:10:53 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id A5039440043; Fri, 26 Jun 2020 18:10:53 +0200 (CEST) Date: Fri, 26 Jun 2020 18:10:53 +0200 From: 'Toerless Eckert' To: Tero Kivinen Cc: Michael Richardson , Paul Wouters , Valery Smyslov , ipsec@ietf.org, 'Yoav Nir' , draft-ietf-anima-autonomic-control-plane@ietf.org Message-ID: <20200626161053.GQ41244@faui48f.informatik.uni-erlangen.de> References: <20200224195013.GA3878@faui48f.informatik.uni-erlangen.de> <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> <0b8001d5ecad$79ce7ad0$6d6b7070$@gmail.com> <0c9e01d5ed4c$2353f5a0$69fbe0e0$@gmail.com> <20200619145112.GA47906@faui48f.informatik.uni-erlangen.de> <24142.1592760359@localhost> <24309.64229.308771.733097@fireball.acr.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24309.64229.308771.733097@fireball.acr.fi> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [IPsec] Troubleshooting IPsec peer certs (was: Re: IPsec profile feedback wanted (draft autonomic control) plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 16:11:29 -0000 On Fri, Jun 26, 2020 at 04:40:53PM +0300, Tero Kivinen wrote: > Michael Richardson writes: > > Unless we can convince various people otherwise, the TA will all be > > private enterprise/ISP CAs. > > And for some reason those same private enterprise/ISP people are > exactly those who say that we can't leak our CA certificates out, and > thats why we can't have publicly available repository of our > certificates or CAs, which of course lead to problem if you mandate > sending that private information whoever ever wants to ask it... I hope -25 captures this accordingly. Signalling of TA certificates may not be appropriate when the deployment is relying on a security model where the TA certificate content is considered confidential and only its hash is appropriate for signalling. ACP nodes SHOULD have a mechanism to select whether the TA certificate is signalled or not. Assuming that both options are possible with a specific secure channel protocol. Btw: i have not heard an explanation why a CA cert would have to be secret other than the classic "security by secrecy" dogma. Do you have an actual example why a CA cert would need to be kept secret ? I can only think of something like oh, the Coca Cola Root Certificate having the Coca Cola recipe in one of its fields as a human proof of authenticity of the certificate. But i can't imagine a ral case where this has been done. Although it sounds like a fun idea to be able to claim in court that a cert was creted by a holder of a particular non-cypto secret. Alas, that claim would then mean you would hve to reveal that non-crypto secret to court. In any case: If there is an actual crypto root CA in a company, you can always create a non-secret TA as a subCA without any of the secret information in the rootCA. IMHO! > > Sending the *complete* trust chain solves the problem, and should > > never cause a problem to any properly implemented daemon/certificate > > chain validator. > > That might not solve anything even when you send the final TA. > > It does not really help when you get TA which has Subject name of > "CN=Root", and Issuer name of "CN=Root". Of course not, but it is a lot easier to put diagnostic information into the root-CA that you may actually have manually crafted instead of the automatically enrolled EE or even potentially also automatically created intermediate CA certs. Like rfc822Name addresses of actual human contacts. > There is still no information where to go to find out who is the owner > of the TA. If those are private TAs created by private > enterprises/ISPs there is no guarantee that the TA itself has anything > useful in it that allows you to identify who created it. This is > especially true if the certificate hiearchy is created automatically > by the vendor software without any actual user interaction. Yes, there are no mandates whatsoever for any form of transparency to support diagnostics. The goal of the technology choices made is to support diagnostics if so desired by the operator deploying the solution. Mandating any level of transparency is beyond the reach of this spec. > Yes, the TA might have something useful but it might not. > > On the other hand the Identity the other end sent might also have > something useful or might not. > > If we look at different information available during IKEv2 negotiation > to the endpoint of the exchange. > > During IKE_SA_INIT we might have Vendor IDs indicating the vendor of > the implementation. This usually is hash of something, and it is > always priprietary format, meaning you can recognize familiar vendors > (i.e., you can map vendor you have seen before to vendor ID it sent > before), but you cannot map random vendor ID to vendor. Anyways this > might give you some debugging information. Yepp. As i said in before, as much as i like to do as much for diagnostics in ACP as possible, i will not be the one asking for anything new to be put into ACP, because the whole IETF/IESG review goes on for years already, so it needs to finish so we can work on all those additional good ideas via followup documents. > > Then we have CERTREQ from the responder, i.e., we know which trust > anchors it trusts, and we get hash of those keys it trust. > > The main idea there is to allow initiator to select one of the > certificates he has in such way that he proposes certificate signed > by one of those trust anchors. As both ends are supposed to be > configured with trust anchors which they trust in, and from which they > have certificates from, they can map this hash to actual trust anchor > without any problems. Sure. But i still fail to see an example where this would be really helpfull. I get the idea, but the root problem is that a particular IPsec session is opened by the initiator for a particular functional purpose. Different VPNs, different ACP, etc. pp. As soon as the certificates for different purposes where derived from overlapping TA, CERTREQ does not help to identify the purpose. And IPsec implementations are prone to not support binding to different UDP ports for different purposes, so there are always workarounds needed to support multiple purposes on the same device simultaneously. > Creating a mapping from trust anchor hash to trust anchor is trivial > if you ever see the actual trust anchor certificate anywhere. Sure. You just need to have seen the actul trust anchor cert once. > If you ever have more than one TA ever in normal operations you want > to mandate sending CERTREQs always. See above. To actually ensure that the other sides cert chain is signalled even when connection fails (for diagnosstics), the certreq must be ignored, which is fine, but given how it was also not helpfull (IMHO) to determine the purpose and hence valid TA in the first place, i consider it to be a well meaning but not useful option. But always happy to hear solutions that would only work when it is used. > In the IKE_AUTH you have CERTREQ from the initiator, containing all of > the trust anchors from the initiator, even when it used certificate > from the only one of them. This allows responder to use different trust > anchor when responding, i.e., initiator might use TA1, and responder > might use TA2, but both trust in both TA1, and TA2, but they just > happen to have certificates from different TAs. yepp. i think i understand how it works. > In addition to that there is CERT from to initiator, if initiator does > not already know that the responder has its certificate. In some > setups the TA hierarchy is properly made and each peer can find > certificates from somewhere else, and there is no need to send them > inside IKEv2 at all. Sure. actually the more common case. Albeit also one that i think should be avoided as much as possible because it just creates additional compllexity / third party dependencies. TO me its just an optimization when there are lots of possible TA (whole set of web CA for example), or a lot of connections for which setup is to be optimized. > In most common case you always send end entity certificate inside the > IKE_AUTH so other end can verify it against its TA and match it > against the identity. > > Note, that the certificate itself include Subject Name telling who > this certificate was created for, and Issure Name telling who signed > it. > > If the certificate hierarchy and names in the hierarchy are properly > set there is no need to send TA. If the Subject name is "CN=device1, > OU=HR Department, O=Example Inc, C=US", and the Issuer name is > "CN=Root TA 2020, O=Example Inc, C=US", that already gives you all > information you need to find out who is the owner of the cert. If the > names are stupid like Subject name of "CN=device1231", and Issuer Name > of "CN=Root" that does not help to get TA, as the TA again just have > both Issuer Name and Subject Name of "CN=Root" which does not help > you. yepp. > Then there is still the IDi and IDr identities, those tell the > identity of the peer. Depending on what identities are in use they > might be very useful for debugging (like "device1@hr.example.com" and > "vpn@example.com") or they might be completely useless like "10.5.0.1" > and "10.1.0.1". Hah. Ok, so this is an interesting point. I didn't try to understand this part so far and was just taking in the advice to use the ID_IPV6_ADDR from the certs ACP domain informatin field The more complete ID would have actually been the complete ACP domain information field, which would be possible too because IKEv2 also supports ID_RFC822_ADDR, which is the forward we have for the domain information field. Alas, there are IMHO unjustified dogmatic concerns about using rfc822addr at all, so it wouldn't really help to suggest using this also as the ID in IKEv2 for our case - however logical and iseful IMHO that would be. Are there actual configs in typical IKEv2 implementations that would allow to tie policies to flexibly matched peer identifies. And by that i men not IPv4/IPv6 peer identities but any of the other identitites, all of which are more descriptive than IPv4/IPv6. ?? > Anyways sending TA only helps at all if the one who created the TA > actually put some useful information in there, and if he did that, > then the same information is already in the EE, thus seeing the TA > does not really help. Agreed. But see above, this was at least from my side the intent anyhow (allow CA certs to have diagnostic info). > I would just put suggestion saying that whoever is creating those > certificate hierarhies, they should use proper naming and include the > name of the company etc in the Subject name of the certificates... Yes. Good point to explicitly indicate that signaling TA is only more useful than not when it has additional useful diagnostics, sch as e.g.: contact person email or the like. Cheers Toerless > -- > kivinen@iki.fi From nobody Tue Jun 30 12:26:40 2020 Return-Path: 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 66A363A03EA; Tue, 30 Jun 2020 12:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi 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 sD-kOGZ_vB2o; Tue, 30 Jun 2020 12:26:36 -0700 (PDT) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [185.185.170.37]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA8C73A03ED; Tue, 30 Jun 2020 12:26:29 -0700 (PDT) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 7D7711B00118; Tue, 30 Jun 2020 22:26:26 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1593545186; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Y4wASZ27L0WU7Jf01o6aPzhOK4J8Nc5P0PHzWpKx7TQ=; b=k9lfryaU3jsS22KvTFM4MNOCIe96/7TBb8hhKpdDmChzYpak/WapLXnTFFSSOjJeNb6ouk H8QKVxt/udwAXwrrBFLCwCcQlYsHuqfZ5b+Q5GytWZDlomn/jNiXBIpOwYjTedclnhohHo +lPOgDZ6uZnGieqY75eGa0RegGSAyJj8bxZSmyZu4WtSKBXplrXmm9ibTGAfYLAXaI7aXe GGXEEUeET48JEeIzB2P29gsPZdDnWsGNQluZ3eou7YGL0rfJv44t1gcJGmQcR9M4GmzXon k3gi6/uL4s3zGMcc2y15K3WYLi06f8+hiS4OIiaBSgrFVbwZ8IMqNez6XcJDRg== Received: by fireball.acr.fi (Postfix, from userid 15204) id 337C025C1150; Tue, 30 Jun 2020 22:26:26 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24315.37346.143409.46224@fireball.acr.fi> Date: Tue, 30 Jun 2020 22:26:26 +0300 From: Tero Kivinen To: "'Toerless Eckert'" Cc: Michael Richardson , Paul Wouters , Valery Smyslov , ipsec@ietf.org, "'Yoav Nir'" , draft-ietf-anima-autonomic-control-plane@ietf.org In-Reply-To: <20200626161053.GQ41244@faui48f.informatik.uni-erlangen.de> References: <20200224195013.GA3878@faui48f.informatik.uni-erlangen.de> <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> <0b8001d5ecad$79ce7ad0$6d6b7070$@gmail.com> <0c9e01d5ed4c$2353f5a0$69fbe0e0$@gmail.com> <20200619145112.GA47906@faui48f.informatik.uni-erlangen.de> <24142.1592760359@localhost> <24309.64229.308771.733097@fireball.acr.fi> <20200626161053.GQ41244@faui48f.informatik.uni-erlangen.de> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 52 min X-Total-Time: 53 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1593545186; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Y4wASZ27L0WU7Jf01o6aPzhOK4J8Nc5P0PHzWpKx7TQ=; b=JLQKEv2vmO0dvgLEEnIJgdU4i296N3EGXVAgAMp2EcL//GYl8cTvm+yrpkhNYAZ2csiMax 2Mg3d9Fb5u7vC9v8o6m8nD1/X9jkdySRlSsrgZahU+K8X5G6wsaLnaBb3C3+PiixOIsQP7 xc/z58UJfTPrU51ePfx5uKwjtAGafTwjbLbQEOme+HdAqS5MC6xSadKcD7ERuEybkNayAk msy4hWWLDzkK1Ugem94NoR9TSBz/Zf35QedC/ZUgU8n2oVRJO/D00fz4FtQK2tKQ659NlQ Y6LUE0Gidarr/cXzj9qmmXSy86/aPArpjm+mvbDKwzwrvjW4ZB9WONfM3scBnA== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1593545186; a=rsa-sha256; cv=none; b=lgqICKmwFIbZohwREsyry/vvcg4W01IyxZRKe6yl9BSWTxQVOjBrkt4UOClidaNoNLr/Ng rSF/v/lXpSj/hSXA8XTS/jl/QFI0VQL+/yUXwfDLVh50Vq3XvDX6Dbcl1a8VJMQjiFfXwr uKOrfr/WiAcWeOXwztux/VaqMR1JG9Xf3Hab28BHvUHIq2utGR+KoulueQf17WoVFDzunL HkGTabtB8qFMaEGFRhvoOasvrWwUZk6VE0idI2qPFKbMbb3dtNnW3C3a4+tUd1kZbnUlps Jvl61DwxUW7FvLKmrYcGWu6CByyefyFrYjYZpikQWbU/gNUQL54b8j68l+/EVg== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: Re: [IPsec] Troubleshooting IPsec peer certs (was: Re: IPsec profile feedback wanted (draft autonomic control) plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 19:26:40 -0000 'Toerless Eckert' writes: > > And for some reason those same private enterprise/ISP people are > > exactly those who say that we can't leak our CA certificates out, and > > thats why we can't have publicly available repository of our > > certificates or CAs, which of course lead to problem if you mandate > > sending that private information whoever ever wants to ask it... > > I hope -25 captures this accordingly. > > Signalling of TA certificates may not be appropriate when the > deployment is relying on a security model where the TA certificate > content is considered confidential and only its hash is appropriate > for signalling. ACP nodes SHOULD have a mechanism to select whether > the TA certificate is signalled or not. Assuming that both options > are possible with a specific secure channel protocol. I still consider sending TA certificate ever completely useless thing, that just wastes bytes. > Btw: i have not heard an explanation why a CA cert would have to > be secret other than the classic "security by secrecy" dogma. Yes. > Do you have an actual example why a CA cert would need to be kept secret ? No. I do not think there us any real reason to keep CA secret. The reason IKEv2 uses hashes is not really about the security it is about using handle for CA which is small enough that we can send them in the first packet without causing fragmentation. Happily this same method also satisifies those same people who think there might be valid reasons to keep CA cert secret. > > That might not solve anything even when you send the final TA. > > > > It does not really help when you get TA which has Subject name of > > "CN=Root", and Issuer name of "CN=Root". > > Of course not, but it is a lot easier to put diagnostic information > into the root-CA that you may actually have manually crafted > instead of the automatically enrolled EE or even potentially also > automatically created intermediate CA certs. Like rfc822Name > addresses of actual human contacts. I do not really belive that. In some systems either everything is generated automatically (including the TA), or there is some configuration parts when automatically creating hierarchy and then you can put things both to EE and CA. Also CA Subject Name is visible in the EE, so you do not need to put anything specific to EE, you just need to use useful Subject Name for CA. > > Then we have CERTREQ from the responder, i.e., we know which trust > > anchors it trusts, and we get hash of those keys it trust. > > > > The main idea there is to allow initiator to select one of the > > certificates he has in such way that he proposes certificate signed > > by one of those trust anchors. As both ends are supposed to be > > configured with trust anchors which they trust in, and from which they > > have certificates from, they can map this hash to actual trust anchor > > without any problems. > > Sure. But i still fail to see an example where this would be really helpfull. If you ever need to talk to devices that are not part of same authorization domain you need that feature (unless you want to provide lots of manual configuration to IKE). I.e., if you connect to SGW1, you need to use public/private key pair and certificate from CA1 to authenticate. And if you connect to SGW2 you need to use different public/private key pair and different certificate which is from CA2. You could manually list all possible SGW ip-addresses or names and configure that they must use specific CA, but that gets diffucult when the number of SGWs raise, can cause problems when certificates are renewed, as then you need to update your configuration again. So what IKEv2 does is that it will connect to the SGW, and SGW will tell that it requires you to use certificate signed by list of CAs and that list include for example CA1. Then initiator can select his own certificate from CA1, and the associated private key and use that when sending the IKE_AUTH to the other end. If he picks wrong CA, meaning wrong private key the responder will fail the authentication and connection is not established. Note, that the initiator does not really care which of his own private keys and associated certificate it uses, as all of them identify himself, he just need to pick something that is suitable for the remote peer. What the initiator needs to manually configure is that what kind of certificates are required by remote peer, i.e., which CA must have signed the certificate responder used. This is required for security so SGW1 cannot do IP or DNS hijack and claim to be SGW2 even when using CA1. Good thing for this is that we just configure that SGW1 needs to authenticate himself with cert from CA1, and SGW2 needs to use cert from CA2. Note, that initiator might not have any certificate from CA1 or CA2, it might actually use completely different CAs, i.e., the list of certificate authorities can be asymmetric. > I get the idea, but the root problem is that a particular IPsec > session is opened by the initiator for a particular functional > purpose. Different VPNs, different ACP, etc. pp. As soon > as the certificates for different purposes where derived > from overlapping TA, CERTREQ does not help to identify the > purpose. It is not supposed to identify the purpose, it is supposed to identify the CA which the other end is willing to trust, i.e., if you received CERTREQ you know that other end should accept certificate signed by those CAs, as the other end trusts those CAs, and trusts the identity mapping that certificate provides. > And IPsec implementations are prone to not > support binding to different UDP ports for different purposes, > so there are always workarounds needed to support multiple > purposes on the same device simultaneously. In IKEv2 there is IDi, and IDr for specifying purposes mostly. When initiator connects to the host, it can send both IDi (who he is), and IDr (who he wants to talk to). Then responder can see that if he understands IDr (it might be FQDN like example.com or company2.com), and if so, it will return same IDr for its own identity. Initiator tells his own identity in the IDi. Responder can also return something completely different for IDr, if it does no recognize the IDr, or even if it recognizes, i.e. it might actually return IDr of mail.example.com when initiator send IDr of example.com. This is similar to what TLS and SNI does, or Host-header in the http. Again this is only hint, and responder can use that information, or it might ignore it if it feels like so. > > Creating a mapping from trust anchor hash to trust anchor is trivial > > if you ever see the actual trust anchor certificate anywhere. > > Sure. You just need to have seen the actul trust anchor cert once. > > > If you ever have more than one TA ever in normal operations you want > > to mandate sending CERTREQs always. > > See above. To actually ensure that the other sides cert chain > is signalled even when connection fails (for diagnosstics), > the certreq must be ignored, which is fine, but given how it > was also not helpfull (IMHO) to determine the purpose and hence > valid TA in the first place, i consider it to be a well > meaning but not useful option. If you think CERTREQ is not helpful you have not understood how it works. Sending full chain including TA is not helpful at all in normal case, and is only marginally helpful for failure cases. The question is that do you want to waste resources 99.99% of time so that in the 0.01% cases there might be slight change that it might be helpful for when someone starts actually doing debugging. I think it is better to save bytes 100% of time... If you assume that you have misconfigurations so often that you want to send few kilobytes extra stuff for every negotiation, I think there is something seriously wrong with the architecture of the system in general. > > Then there is still the IDi and IDr identities, those tell the > > identity of the peer. Depending on what identities are in use they > > might be very useful for debugging (like "device1@hr.example.com" and > > "vpn@example.com") or they might be completely useless like "10.5.0.1" > > and "10.1.0.1". > > Hah. Ok, so this is an interesting point. I didn't try to > understand this part so far and was just taking in the advice > to use the ID_IPV6_ADDR from the certs ACP domain informatin field > The more complete ID would have actually been the complete > ACP domain information field, which would be possible too because > IKEv2 also supports ID_RFC822_ADDR, which is the forward we have > for the domain information field. Alas, there are IMHO unjustified > dogmatic concerns about using rfc822addr at all, so it wouldn't > really help to suggest using this also as the ID in IKEv2 for > our case - however logical and iseful IMHO that would be. The identity should be something that identifies the other end. I.e., IP address is fine if you are just connecting between ip-addresses. Random KEY_ID is fine, if you simply map that to something in your architecture (it could for example be MAC-address). > Are there actual configs in typical IKEv2 implementations > that would allow to tie policies to flexibly matched peer > identifies. And by that i men not IPv4/IPv6 peer identities > but any of the other identitites, all of which are more > descriptive than IPv4/IPv6. ?? I do not think there is typical thing to do. Some implementation do allow very complex mapping between identity and policy, even perhaps calling some external API call to do the mapping. Some implemntations simply make sure that the ID and some field in certificate match. All this depends where IPsec is used. In VPN setups the identities usually match either IP-addresses (site to site vpn between fixed ip-addresses), FQDN (site to site, or host to host), email address (roaming user to sgw) etc. > > Anyways sending TA only helps at all if the one who created the TA > > actually put some useful information in there, and if he did that, > > then the same information is already in the EE, thus seeing the TA > > does not really help. > > Agreed. But see above, this was at least from my side the > intent anyhow (allow CA certs to have diagnostic info). I do not like when we optimize for failure cases and waste resources just to provide information that might be useful when debugging. Especially when the content you are sending is binary blob which is quite meaningless unless you first decode it and show it to user somehow. What kind of user is going to see these debug printouts printing out the CA? -- kivinen@iki.fi From nobody Tue Jun 30 13:28:41 2020 Return-Path: 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 A42033A0834; Tue, 30 Jun 2020 13:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no 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 b7XFqansYYRN; Tue, 30 Jun 2020 13:28:29 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB5D23A0810; Tue, 30 Jun 2020 13:28:23 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 9E95E548011; Tue, 30 Jun 2020 22:28:12 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 97038440043; Tue, 30 Jun 2020 22:28:12 +0200 (CEST) Date: Tue, 30 Jun 2020 22:28:12 +0200 From: 'Toerless Eckert' To: Tero Kivinen Cc: Michael Richardson , Paul Wouters , Valery Smyslov , ipsec@ietf.org, 'Yoav Nir' , draft-ietf-anima-autonomic-control-plane@ietf.org Message-ID: <20200630202812.GF13952@faui48f.informatik.uni-erlangen.de> References: <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> <0b8001d5ecad$79ce7ad0$6d6b7070$@gmail.com> <0c9e01d5ed4c$2353f5a0$69fbe0e0$@gmail.com> <20200619145112.GA47906@faui48f.informatik.uni-erlangen.de> <24142.1592760359@localhost> <24309.64229.308771.733097@fireball.acr.fi> <20200626161053.GQ41244@faui48f.informatik.uni-erlangen.de> <24315.37346.143409.46224@fireball.acr.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24315.37346.143409.46224@fireball.acr.fi> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [IPsec] Troubleshooting IPsec peer certs (was: Re: IPsec profile feedback wanted (draft autonomic control) plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 20:28:40 -0000 Thanks a lot, Tero for all your time responding, inline On Tue, Jun 30, 2020 at 10:26:26PM +0300, Tero Kivinen wrote: > I still consider sending TA certificate ever completely useless > thing, that just wastes bytes. Luckily it was not me alone who wanted that feature but it was triggered by Michael, i just was happy to jump to it. As long as we're fine with the security evaluation i am happy if something we explore turns out to be useless wrt. diagnostics help. As i said i am really mostly paranoid about good diagnostics. > > Btw: i have not heard an explanation why a CA cert would have to > > be secret other than the classic "security by secrecy" dogma. > > Yes. > > > Do you have an actual example why a CA cert would need to be kept secret ? > > No. I do not think there us any real reason to keep CA secret. Great. > The reason IKEv2 uses hashes is not really about the security it is > about using handle for CA which is small enough that we can send them > in the first packet without causing fragmentation. Happily this same > method also satisifies those same people who think there might be > valid reasons to keep CA cert secret. Sure. > > > That might not solve anything even when you send the final TA. > > > > > > It does not really help when you get TA which has Subject name of > > > "CN=Root", and Issuer name of "CN=Root". > > > > Of course not, but it is a lot easier to put diagnostic information > > into the root-CA that you may actually have manually crafted > > instead of the automatically enrolled EE or even potentially also > > automatically created intermediate CA certs. Like rfc822Name > > addresses of actual human contacts. > > I do not really belive that. In some systems either everything is > generated automatically (including the TA), or there is some > configuration parts when automatically creating hierarchy and then you > can put things both to EE and CA. Also CA Subject Name is visible in > the EE, so you do not need to put anything specific to EE, you just > need to use useful Subject Name for CA. You because i am paranoid does not mean they are not after me ;-) I am not able right now to invest the time to compare all the fileds in a CA cert with what is available in the certs it signs. > > > Then we have CERTREQ from the responder, i.e., we know which trust > > > anchors it trusts, and we get hash of those keys it trust. > > > > > > The main idea there is to allow initiator to select one of the > > > certificates he has in such way that he proposes certificate signed > > > by one of those trust anchors. As both ends are supposed to be > > > configured with trust anchors which they trust in, and from which they > > > have certificates from, they can map this hash to actual trust anchor > > > without any problems. > > > > Sure. But i still fail to see an example where this would be really helpfull. > > If you ever need to talk to devices that are not part of same > authorization domain you need that feature (unless you want to > provide lots of manual configuration to IKE). > > I.e., if you connect to SGW1, you need to use public/private key pair > and certificate from CA1 to authenticate. And if you connect to SGW2 > you need to use different public/private key pair and different > certificate which is from CA2. > > You could manually list all possible SGW ip-addresses or names and > configure that they must use specific CA, but that gets diffucult when > the number of SGWs raise, can cause problems when certificates are > renewed, as then you need to update your configuration again. > > So what IKEv2 does is that it will connect to the SGW, and SGW will > tell that it requires you to use certificate signed by list of CAs and > that list include for example CA1. Then initiator can select > his own certificate from CA1, and the associated private key and use > that when sending the IKE_AUTH to the other end. If he picks wrong CA, > meaning wrong private key the responder will fail the authentication > and connection is not established. > > Note, that the initiator does not really care which of his own private > keys and associated certificate it uses, as all of them identify > himself, he just need to pick something that is suitable for the > remote peer. > > What the initiator needs to manually configure is that what kind of > certificates are required by remote peer, i.e., which CA must have > signed the certificate responder used. This is required for security > so SGW1 cannot do IP or DNS hijack and claim to be SGW2 even when > using CA1. Good thing for this is that we just configure that SGW1 > needs to authenticate himself with cert from CA1, and SGW2 needs to > use cert from CA2. > > Note, that initiator might not have any certificate from CA1 or CA2, > it might actually use completely different CAs, i.e., the list of > certificate authorities can be asymmetric. Good explanation. So, whats the most simple example for this ? I have a single VPN but multiple geographic headends and there is an obfuscated logic what certs each headends accepts, so i do have multiple and certreq helps me to choose ? I am sure everything is possible, i am just looking for the most simple example where that is actually used. I think for a specific VPN all my VPN clients always only had one cert. > > I get the idea, but the root problem is that a particular IPsec > > session is opened by the initiator for a particular functional > > purpose. Different VPNs, different ACP, etc. pp. As soon > > as the certificates for different purposes where derived > > from overlapping TA, CERTREQ does not help to identify the > > purpose. > > It is not supposed to identify the purpose, it is supposed to identify > the CA which the other end is willing to trust, i.e., if you received > CERTREQ you know that other end should accept certificate signed by > those CAs, as the other end trusts those CAs, and trusts the identity > mapping that certificate provides. Sure... example (see above) would help to get a better feel of this. > > And IPsec implementations are prone to not > > support binding to different UDP ports for different purposes, > > so there are always workarounds needed to support multiple > > purposes on the same device simultaneously. > > In IKEv2 there is IDi, and IDr for specifying purposes mostly. When > initiator connects to the host, it can send both IDi (who he is), and > IDr (who he wants to talk to). Then responder can see that if he > understands IDr (it might be FQDN like example.com or > company2.com), and if so, it will return same IDr for its own > identity. Initiator tells his own identity in the IDi. > > Responder can also return something completely different for IDr, if > it does no recognize the IDr, or even if it recognizes, i.e. it might > actually return IDr of mail.example.com when initiator send IDr of > example.com. > > This is similar to what TLS and SNI does, or Host-header in the http. > > Again this is only hint, and responder can use that information, or it > might ignore it if it feels like so. Ok, so i hope i am correct to state that in general we could have ignored specifying IDi/IDr in our profile as its not necessary. I forgot who proposed we put our nodes IPv6 address into this field, but the IPv6 address itself doesn't seem to be very useful to identify whether the nodes are in the same network. The full name of a node was so far an rfc822Name, now i need to fix it to become what i think is going to be a GeneralName, and hence it might best be to signal IDi/IDr as ID_DER_ASN1_GN > > > Creating a mapping from trust anchor hash to trust anchor is trivial > > > if you ever see the actual trust anchor certificate anywhere. > > > > Sure. You just need to have seen the actul trust anchor cert once. > > > > > If you ever have more than one TA ever in normal operations you want > > > to mandate sending CERTREQs always. > > > > See above. To actually ensure that the other sides cert chain > > is signalled even when connection fails (for diagnosstics), > > the certreq must be ignored, which is fine, but given how it > > was also not helpfull (IMHO) to determine the purpose and hence > > valid TA in the first place, i consider it to be a well > > meaning but not useful option. > > If you think CERTREQ is not helpful you have not understood how it > works. > > Sending full chain including TA is not helpful at all in normal case, > and is only marginally helpful for failure cases. The question is that > do you want to waste resources 99.99% of time so that in the 0.01% > cases there might be slight change that it might be helpful for when > someone starts actually doing debugging. The use-case are long-lived IPsec connections between routers that would stay up until a node reboots, a link fails or somebody misplugs a cable. We had network operators that plugged in a UPS to a router when they moved routers to a new building after 10 years, just because they wanted to keep their router-uptime record. For all i care, IKEv2 could be performed by two dancing turtles singing the packets. There is no advertisement revenue in this use-case in faster IKEv2 handshake. Not even an annoyed toerless waiting for his notebook VPN to come up ;-). Sure at some point in time after this is sucessfull in enterprise SP backbone networks, we will have to revisit optimizing for low-end IoT, but this particular issue is by far not the only one for that space. We disagree on your surely scientifically analyzed benefit of 0.001%. Even a 0.1 % of cases benefit could be a huge benefit. In big, badly manaed pops, some link diagnostics is taking weeks for folks to bring in better diagnostics gear. Can i promise our idea for better IKEv2 diagnostic will help ? No, we can't but we only need to establish IMHO that it does not hurt, and i think it does not. > I think it is better to save bytes 100% of time... You assume that you have other diagnostics channels, and if you do, i do agree. In our case we're at the lowest level/first stuff that establishes connectivity. > If you assume that you have misconfigurations so often that you want > to send few kilobytes extra stuff for every negotiation, I think there > is something seriously wrong with the architecture of the system in > general. Again, these are not QUIC pages where every msec faster display of advertisement URLs makes a lot of money. Or annoyed users like myself waiting for a VPN tunnel to cume up on my laptop. > > > Then there is still the IDi and IDr identities, those tell the > > > identity of the peer. Depending on what identities are in use they > > > might be very useful for debugging (like "device1@hr.example.com" and > > > "vpn@example.com") or they might be completely useless like "10.5.0.1" > > > and "10.1.0.1". > > > > Hah. Ok, so this is an interesting point. I didn't try to > > understand this part so far and was just taking in the advice > > to use the ID_IPV6_ADDR from the certs ACP domain informatin field > > The more complete ID would have actually been the complete > > ACP domain information field, which would be possible too because > > IKEv2 also supports ID_RFC822_ADDR, which is the forward we have > > for the domain information field. Alas, there are IMHO unjustified > > dogmatic concerns about using rfc822addr at all, so it wouldn't > > really help to suggest using this also as the ID in IKEv2 for > > our case - however logical and iseful IMHO that would be. > > The identity should be something that identifies the other end. I.e., > IP address is fine if you are just connecting between ip-addresses. > Random KEY_ID is fine, if you simply map that to something in your > architecture (it could for example be MAC-address). With our current thinking, the GeneralName would be probably something ilke: type AcpRealm: node:@ > > Are there actual configs in typical IKEv2 implementations > > that would allow to tie policies to flexibly matched peer > > identifies. And by that i men not IPv4/IPv6 peer identities > > but any of the other identitites, all of which are more > > descriptive than IPv4/IPv6. ?? > > I do not think there is typical thing to do. Some implementation do > allow very complex mapping between identity and policy, even perhaps > calling some external API call to do the mapping. Some implemntations > simply make sure that the ID and some field in certificate match. > > All this depends where IPsec is used. In VPN setups the identities > usually match either IP-addresses (site to site vpn between fixed > ip-addresses), FQDN (site to site, or host to host), email address > (roaming user to sgw) etc. Thanks > > > Anyways sending TA only helps at all if the one who created the TA > > > actually put some useful information in there, and if he did that, > > > then the same information is already in the EE, thus seeing the TA > > > does not really help. > > > > Agreed. But see above, this was at least from my side the > > intent anyhow (allow CA certs to have diagnostic info). > > I do not like when we optimize for failure cases and waste > resources just to provide information that might be useful when > debugging. Please take longevity and core focus of the use-case into account. > Especially when the content you are sending is binary blob > which is quite meaningless unless you first decode it and show it to > user somehow. What kind of user is going to see these debug printouts > printing out the CA? I imagine a GUI at the NOC of a network operator: Unauthenticated ACP neigbhor on NodeXXX/InterfaceYYY: node:@ Click to see cert chain diagnostics And would show similar decode of the cert chain including TA as you would get from e.g.: clicking on the trust icon on a browser. Thats about the minimum. I wish we would have not been called back using rfc822Name for our solution, because then we could have even easily authenticated such a peer from a different domain by relying on ACME certificates. Oh well. Cheers Toerless > -- > kivinen@iki.fi From nobody Tue Jun 30 14:49:21 2020 Return-Path: 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 4E4D83A0893; Tue, 30 Jun 2020 14:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 TRmAVNnzAuYg; Tue, 30 Jun 2020 14:49:16 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9847C3A088A; Tue, 30 Jun 2020 14:49:16 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 72E6EF40757; Tue, 30 Jun 2020 14:48:57 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, ipsec@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20200630214857.72E6EF40757@rfc-editor.org> Date: Tue, 30 Jun 2020 14:48:57 -0700 (PDT) Archived-At: Subject: [IPsec] =?utf-8?q?RFC_8784_on_Mixing_Preshared_Keys_in_the_Inter?= =?utf-8?q?net_Key_Exchange_Protocol_Version_2_=28IKEv2=29_for_Post-quantu?= =?utf-8?q?m_Security?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 21:49:20 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8784 Title: Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security Author: S. Fluhrer, P. Kampanakis, D. McGrew, V. Smyslov Status: Standards Track Stream: IETF Date: June 2020 Mailbox: sfluhrer@cisco.com, pkampana@cisco.com, mcgrew@cisco.com, svan@elvis.ru Pages: 16 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipsecme-qr-ikev2-11.txt URL: https://www.rfc-editor.org/info/rfc8784 DOI: 10.17487/RFC8784 The possibility of quantum computers poses a serious challenge to cryptographic algorithms deployed widely today. The Internet Key Exchange Protocol Version 2 (IKEv2) is one example of a cryptosystem that could be broken; someone storing VPN communications today could decrypt them at a later time when a quantum computer is available. It is anticipated that IKEv2 will be extended to support quantum-secure key exchange algorithms; however, that is not likely to happen in the near term. To address this problem before then, this document describes an extension of IKEv2 to allow it to be resistant to a quantum computer by using preshared keys. This document is a product of the IP Security Maintenance and Extensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC