From nobody Sun Dec 1 00:52:34 2019 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 083E712001A for ; Sun, 1 Dec 2019 00:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 imuNYU7iytq8 for ; Sun, 1 Dec 2019 00:52:32 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD861200F4 for ; Sun, 1 Dec 2019 00:52:32 -0800 (PST) Received: from stubbs.int.chopps.org (66-227-211-29.dhcp.trcy.mi.charter.com [66.227.211.29]) (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 354126090E; Sun, 1 Dec 2019 08:52:31 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Christian Hopps In-Reply-To: Date: Sun, 1 Dec 2019 03:52:30 -0500 Cc: Christian Hopps , Valery Smyslov , IPsecME WG Content-Transfer-Encoding: quoted-printable Message-Id: <3F136824-B2BB-429A-BC24-226FC2F9D199@chopps.org> References: <039e01d5a5f2$ac51d350$04f579f0$@gmail.com> <042301d5a6b6$bc8e9fe0$35abdfa0$@gmail.com> <044701d5a6d0$032d5a90$09880fb0$@gmail.com> <5CAB559D-595E-4503-AC72-31E88B6F53AA@chopps.org> To: Paul Wouters X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [IPsec] ESP next payload number [Re: Some thoughts regarging draft-hopps-ipsecme-iptfs-01] 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, 01 Dec 2019 08:52:34 -0000 I think it's important for this discussion to recognize that we have 2 = orthogonal issues. 1) How does IP-TFS work on the wire with IPsec/ESP - this is where we = need to make sure we don't unnecessarily restrict uni-directional use. 2) What are the changes to IKEv2 to support IP-TFS - this is where we = need to decided if we need the ability to negotiate uni-direction cases, = we don't believe we need to do this. I think this is inline with what = people are expecting here (i.e., a pair of SAs with IP-TFS enabled or = not). More inline.. > On Dec 1, 2019, at 2:41 AM, Paul Wouters wrote: >=20 > On Fri, 29 Nov 2019, Christian Hopps wrote: >=20 >>> ESP SAs are always created in pairs. And whether IP-TFS is enabled = or not is common for both SAs. >>> Even if you use only one SA for IP-TFS traffic, the other will have = IP-TFS enabled too. >>> How are you going with your spec to create a pair of SAs where = IP-TFS is enabled in one direction and >>> disabled in the other? Am I missing something? Even if you are able = to create such a pair of SAs, is it justified? >>=20 >> Understood that SAs are created in pairs. The intent here (and = throughout the draft) is not to unnecessarily restrict possible uses. = Having IP-TFS enabled on only one of a pair of SAs can make sense when = you're only trying to protect traffic sent in one direction from traffic = analysis (again e.g., telemetry). The use of IP-TFS does involve the = allocation of a fixed amount of bandwidth so the justification for not = enabling it in one direction is to save that bandwidth. >=20 > It seems unwise to protect traffic one way but not the other way. Are > endusers really able to make the right decision based on their = generated > traffic? If you are that hungry for resources, perhaps this isn't an > option for you to use? There is no traffic to protect in the reverse direction. Consider = telemetry where one is simply sending un-acked UDP data using to = monitors. >=20 > Also, if an inbound or outbound SA is not using IP-TFS, couldn't the > memory be deallocated, or the memory allocation could be postponed > until the first IP-TFS type packet arrives? >=20 > The architecture is really symmetrical for in/out bound SA's, so I > would prefer we do not change that. We are not looking to change the architecture, only to use the existing = one (see orthogonal issues). The telemetry example is one case of = uni-directional traffic; however, multicast is another area where you = can get non-"TCP flow-like" unidirectional configurations. >=20 >> The spec is (trying to be) very careful in not restricting the = unidirectional TFS use case b/c there's no reason to do so, and so there = should not be anything in the document that restricts having only one of = the SA pairs used by IPsec/ESP running with IP-TFS. >=20 > The question is, does it need to be negotiated or not or can a well > implemented implementation postpone all memory requirements if this > feature is unused in one direction? The standard case of using IKEv2 (i.e., what most users will use) = assumes bi-directional use which seems appropriate. The draft also = allows for not starting the IP-TFS constant send immediately. Finally, = the draft does not restrict other less-traditional use cases which fall = outside the scope of IKEv2 use. For IKEv2 we believe bi-directional only is fine and that's what the = draft has defined. >=20 >> Setting up such an SA pair is orthogonal to being able to run with = that configuration. While the vast majority of IPsec utilizes IKEv2 for = SA creation/management, this is not a requirement of IPsec/ESP. The = unidirectional case can be covered with local configuration (along with = IKEv2), or by using another method entirely for the SA management. >=20 > Non-IKE can negotiate whatever it want and hack in custom IPsec SA's > that we would find completely illegal. That's out of scope of this WG, > but we should also not bring it into scope as "others might want = that". >=20 >> The intent in the end is to specify what we need to for IP-TFS = operation, but not too over-specify and unnecessarily restrict possible = future (or outside) uses. IOW, less is more. >=20 > But I am still not convinced endusers can make these decisions of > bidirectional vs unidirectional and whther or not their traffic > becomes more susceptible to traffic analyses attacks. Which users are we talking about here? We agree, for the vast majority = of end-users the standard use case will be bi-directional, and the IKEv2 = changes reflect this (see 2). We're not making it *easy* to run uni-directional we're simply not = outright prohibiting this use case for users who may have more complex = requirements and/or know what they are doing.=20 We've got the restriction in IKEv2, but what is the value in further = restricting things at the IPsec/ESP level (1)? There is real value lost = in making this restriction, so I think we need to justify it if we = choose to do so. Thanks, Chris. >> FWIW, I did explore adding machinery to IKEv2 to allow setting = up/negotiating unidirectional use cases, but it adds a lot of = complexity, and so we decided that while unidirectional TFS protection = is useful it will still be a relatively uncommon configuration and was = best left for local configuration for now. If in the future we see a = large call for on-demand/negotiated (vs local config) uni-directional = TFS we can always come back and add it to IKEv2. What's important in the = context of the IKEv2 changes for now is that we don't do anything to = block doing this in the future. >=20 > I have not yet been convinced of this. > Paul >=20 From nobody Sun Dec 1 00:55:32 2019 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 159541200FB for ; Sun, 1 Dec 2019 00:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 wdHHVSnY4jqV for ; Sun, 1 Dec 2019 00:55:30 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id E634312001A for ; Sun, 1 Dec 2019 00:55:29 -0800 (PST) Received: from stubbs.int.chopps.org (66-227-211-29.dhcp.trcy.mi.charter.com [66.227.211.29]) (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 557F36094B; Sun, 1 Dec 2019 08:55:29 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Christian Hopps In-Reply-To: Date: Sun, 1 Dec 2019 03:55:27 -0500 Cc: Christian Hopps , Valery Smyslov , IPsecME WG Content-Transfer-Encoding: quoted-printable Message-Id: <190A9F3C-F8F1-480E-A931-F3BF00C1B33F@chopps.org> References: <039e01d5a5f2$ac51d350$04f579f0$@gmail.com> <041b01d5a6ad$e9621550$bc263ff0$@gmail.com> <3B82404F-3121-444F-97A0-6E18258DAC04@chopps.org> <043801d5a6bd$80cd8500$82688f00$@gmail.com> To: Paul Wouters X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [IPsec] IKEv2 IPTFS transform [Re: Some thoughts regarging draft-hopps-ipsecme-iptfs-01] 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, 01 Dec 2019 08:55:31 -0000 > On Nov 30, 2019, at 1:35 AM, Paul Wouters wrote: >=20 >=20 > On Nov 29, 2019, at 21:01, Valery Smyslov = wrote: >=20 >> A lot of things in IKEv2 is negotiated by using notifications. With = regard to child SA they are -=20 >> using transport mode, using IPcomp, using WESP, using ROHC.=20 >> IP-TFC looks to me like a natural continuation of this line. >=20 > I agree. This is easier to implement than using traffic selectors and = seems more appropriate as it is an =E2=80=9Coptional=E2=80=9D thing to = enable - similar to transport mode and compression. >=20 Just sending a note so others don't need to +1 this, that I'll be = looking into these changes for the next rev, :) Thanks, Chris. > Paul >=20 From nobody Sun Dec 1 18:29:08 2019 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 59B00120122 for ; Sun, 1 Dec 2019 18:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, 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 sk-lru0M4oKd for ; Sun, 1 Dec 2019 18:29:05 -0800 (PST) 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 2417712011F for ; Sun, 1 Dec 2019 18:29:04 -0800 (PST) Received: from 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 xB22Sxtd024442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 1 Dec 2019 21:29:01 -0500 Date: Sun, 1 Dec 2019 18:28:59 -0800 From: Benjamin Kaduk To: Christian Hopps Cc: Paul Wouters , IPsecME WG , Valery Smyslov Message-ID: <20191202022859.GE32847@mit.edu> References: <039e01d5a5f2$ac51d350$04f579f0$@gmail.com> <042301d5a6b6$bc8e9fe0$35abdfa0$@gmail.com> <044701d5a6d0$032d5a90$09880fb0$@gmail.com> <5CAB559D-595E-4503-AC72-31E88B6F53AA@chopps.org> <3F136824-B2BB-429A-BC24-226FC2F9D199@chopps.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F136824-B2BB-429A-BC24-226FC2F9D199@chopps.org> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [IPsec] ESP next payload number [Re: Some thoughts regarging draft-hopps-ipsecme-iptfs-01] 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, 02 Dec 2019 02:29:06 -0000 On Sun, Dec 01, 2019 at 03:52:30AM -0500, Christian Hopps wrote: > I think it's important for this discussion to recognize that we have 2 orthogonal issues. > > 1) How does IP-TFS work on the wire with IPsec/ESP - this is where we need to make sure we don't unnecessarily restrict uni-directional use. > > 2) What are the changes to IKEv2 to support IP-TFS - this is where we need to decided if we need the ability to negotiate uni-direction cases, we don't believe we need to do this. I think this is inline with what people are expecting here (i.e., a pair of SAs with IP-TFS enabled or not). > > More inline.. > > > On Dec 1, 2019, at 2:41 AM, Paul Wouters wrote: > > > > On Fri, 29 Nov 2019, Christian Hopps wrote: > > > > It seems unwise to protect traffic one way but not the other way. Are > > endusers really able to make the right decision based on their generated > > traffic? If you are that hungry for resources, perhaps this isn't an > > option for you to use? > > There is no traffic to protect in the reverse direction. Consider telemetry where one is simply sending un-acked UDP data using to monitors. I feel like I must be missing something; if there's no traffic in the reverse direction why does it matter if we assign semantics to the reverse SA or not? -Ben From nobody Mon Dec 2 00:02:01 2019 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 BEEFE12021C for ; Mon, 2 Dec 2019 00:01:59 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 9EV-h3VER8HE for ; Mon, 2 Dec 2019 00:01:58 -0800 (PST) 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 EA73C120154 for ; Mon, 2 Dec 2019 00:01:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id CFB92204B4; Mon, 2 Dec 2019 09:01:55 +0100 (CET) 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 DQCw9gQHBcKK; Mon, 2 Dec 2019 09:01:55 +0100 (CET) Received: from mail-essen-01.secunet.de (mail-essen-01.secunet.de [10.53.40.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a.mx.secunet.com (Postfix) with ESMTPS id 651232019C; Mon, 2 Dec 2019 09:01:55 +0100 (CET) Received: from gauss2.secunet.de (10.182.7.193) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server id 14.3.439.0; Mon, 2 Dec 2019 09:01:55 +0100 Received: by gauss2.secunet.de (Postfix, from userid 1000) id 100C8318025B; Mon, 2 Dec 2019 09:01:55 +0100 (CET) Date: Mon, 2 Dec 2019 09:01:55 +0100 From: Steffen Klassert To: Valery Smyslov CC: IPsecME WG Message-ID: <20191202080154.GM13225@gauss3.secunet.de> References: <039e01d5a5f2$ac51d350$04f579f0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <039e01d5a5f2$ac51d350$04f579f0$@gmail.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 Archived-At: Subject: Re: [IPsec] Some thoughts regarging draft-hopps-ipsecme-iptfs-01 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, 02 Dec 2019 08:02:00 -0000 On Thu, Nov 28, 2019 at 04:49:36PM +0300, Valery Smyslov wrote: > Hi, > > after reading through draft-hopps-ipsecme-iptfs-01 I have some thoughts. > > 1. I think it's a wrong decision to support tunnel mode ESP only. IP-TFS for transport mode ESP > is equally important because one of the widely used scenario is to combine general purpose > tunneling (like GRE) with transport mode ESP. In this case traffic flowing over such SA > will in fact be tunnel traffic from several hosts, but the SA is created in transport mode. > For this reason I think that IP-TFS must support transport mode SA either. I'd like to agree here. It does not add much more complexity and there are valid usecases for transport mode (and even for BEET mode). > 4. I'd like to see more text in the draft regarding reassembling of incoming packets. Yes, I think some words on how to reassemble the fragments are really needed. > It seems to me that it can be done pretty easy by linking the reassembly logic > with replay protection window. While it looks like doing the reassembling based on ESP sequence numbers might be an easy approach, it could be also dangerous. Consider a system that encapsulates two flows on different cpus with the same SA. This system can TX packets in the following order: TX cpu0 inner flow0 SA0: Offset: 0 Offset: 100 [ ESP1 (1500) ] [ ESP3 (1500) ] [--800--][--800- -][-----1400---] -------------------------------------------------------------------------------------- TX cpu1 inner flow1 SA0: Offset: 0 Offset: 100 [ ESP2 (1500) ] [ ESP4 (1500) ] [--800--][--800- -][----1400----] On the receive side, it is not that clear how to reassemble the fragments from ESP3 and ESP4 into the fragments from ESP1 and ESP2. Maybe some packet ID in the IP-TFS header could help to identify related fragments. Steffen From nobody Mon Dec 2 00:28:21 2019 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 B73DE120154 for ; Mon, 2 Dec 2019 00:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 JdEVSq0CoWPw for ; Mon, 2 Dec 2019 00:28:19 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 A8F6412006D for ; Mon, 2 Dec 2019 00:28:18 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id k8so28419738ljh.5 for ; Mon, 02 Dec 2019 00:28:18 -0800 (PST) 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=zWbwW3I2SyEiUVv3D6g6wHI8MxdyDr3mBL4cOF+m4OI=; b=DwBoJeZFJt/F8O3bym+jAZu5ZZ8yEjjMjMZooP/9h7Ad8eNHRdbrPE0rrCojYjRnh+ 9woZsXw/5C3GmomQMdJEudTcZHKU/+L5JoND8H38mlBJzoaproaIu2Ft4bKk+tWYfV/J eRi4TOif8R01RZX+SdsbjKMeHwCKHMVtvP7tfLStl2F1DHrrCst1NNwY4jCIk35M4glz 2dlOG08XRfQlc9AFY/xI6dGGK4wzr0JBt4fqk1HogyQLKu/EOq67XfAnLCauh07xFAme kOu3/PWPHC29VPdI5lZmTHbOEIYoSk3i74hXb+HsXY7TP0adjf9hLtHO3ujsXjPFujXp nHfQ== 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=zWbwW3I2SyEiUVv3D6g6wHI8MxdyDr3mBL4cOF+m4OI=; b=tIPjrhqps95tiwv5e8/NOmb6FVIlNgYaKaCNeBLbck5Jh8wZSXmSddrDqm6erF4+RP v1+u0D/C1eUJ/jRaqlPCdi0ED2alVXPJIPIc8fjMCHrMMJp/Fomw2LXNU17wd475Nnpq nQOddgxKUcCXxusAtn1p9nCHcOoU0God51OL1p0EgqS0bI9YmGiYjd2hAMZKSn/unjBO e43rkbLVZ0mcdei4wHcrO0qLuTsCLxb5qyDZlKoEpAcBPkx8abidFweOyxMDebnrFJGP OfnMIOjkJwzyCkbklYvj2fmokFOEAF+q84+JC2ftFuFEzAwHcWOJa/XOlij0m4mhusmb FlVw== X-Gm-Message-State: APjAAAX8CSJ6sn4DJQTt/9TljMBXf9J9HEKN1quphQmomk3AOzcSj9rb iY4JTTm7Blj4fqj6W4prBAmB3KdG X-Google-Smtp-Source: APXvYqxS8tCJr8amgYFgFnLyIU6E8oaKevpe7PBoGv+12Ej8aGqba1WAdEJsgrcVYZRvvv29gQgiKw== X-Received: by 2002:a2e:9942:: with SMTP id r2mr11234598ljj.182.1575275296441; Mon, 02 Dec 2019 00:28:16 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id k25sm5735529lji.42.2019.12.02.00.28.15 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 02 Dec 2019 00:28:15 -0800 (PST) From: "Valery Smyslov" To: "'Steffen Klassert'" Cc: "'IPsecME WG'" References: <039e01d5a5f2$ac51d350$04f579f0$@gmail.com> <20191202080154.GM13225@gauss3.secunet.de> In-Reply-To: <20191202080154.GM13225@gauss3.secunet.de> Date: Mon, 2 Dec 2019 11:28:16 +0300 Message-ID: <050701d5a8ea$72651b20$572f5160$@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: AQHtQTffgHTNPTWByX2TyLtNjmyTVQK65kI2p2F2nPA= Content-Language: ru Archived-At: Subject: Re: [IPsec] Some thoughts regarging draft-hopps-ipsecme-iptfs-01 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, 02 Dec 2019 08:28:20 -0000 Hi Steffen, > > It seems to me that it can be done pretty easy by linking the reassembly logic > > with replay protection window. > > While it looks like doing the reassembling based on ESP sequence numbers > might be an easy approach, it could be also dangerous. > > Consider a system that encapsulates two flows on different cpus > with the same SA. This system can TX packets in the following > order: > > TX cpu0 inner flow0 SA0: > > Offset: 0 Offset: 100 > [ ESP1 (1500) ] [ ESP3 (1500) ] > [--800--][--800- -][-----1400---] > > -------------------------------------------------------------------------------------- > TX cpu1 inner flow1 SA0: > Offset: 0 Offset: 100 > [ ESP2 (1500) ] [ ESP4 (1500) ] > [--800--][--800- -][----1400----] > > > On the receive side, it is not that clear how to reassemble the fragments > from ESP3 and ESP4 into the fragments from ESP1 and ESP2. Maybe some > packet ID in the IP-TFS header could help to identify related fragments. I'm probably missing something here, but I think that sending side assigns every outgoing IP packet to some SA. Then the packet is added to the ESP message (that may already contain previous packets). If the packet cannot fit into the left space, it is split and the rest of the packet is sent in the next ESP message of the same SA. In this case there must not be situations when one part of the IP packet is sent over one SA and the rest of the packet is sent over different SA. Am I missing something? Regards, Valery. > Steffen From nobody Mon Dec 2 00:49:37 2019 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 E8BCB1200A1 for ; Mon, 2 Dec 2019 00:49:35 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 t_EpVqKIn_uu for ; Mon, 2 Dec 2019 00:49:34 -0800 (PST) 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 15ABA120013 for ; Mon, 2 Dec 2019 00:49:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 263BD20571; Mon, 2 Dec 2019 09:49:31 +0100 (CET) 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 mCWUPERRgHOz; Mon, 2 Dec 2019 09:49:30 +0100 (CET) Received: from mail-essen-01.secunet.de (mail-essen-01.secunet.de [10.53.40.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a.mx.secunet.com (Postfix) with ESMTPS id AE1CD20561; Mon, 2 Dec 2019 09:49:30 +0100 (CET) Received: from gauss2.secunet.de (10.182.7.193) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server id 14.3.439.0; Mon, 2 Dec 2019 09:49:30 +0100 Received: by gauss2.secunet.de (Postfix, from userid 1000) id 43DF03180271; Mon, 2 Dec 2019 09:49:30 +0100 (CET) Date: Mon, 2 Dec 2019 09:49:30 +0100 From: Steffen Klassert To: Valery Smyslov CC: 'IPsecME WG' Message-ID: <20191202084930.GN13225@gauss3.secunet.de> References: <039e01d5a5f2$ac51d350$04f579f0$@gmail.com> <20191202080154.GM13225@gauss3.secunet.de> <050701d5a8ea$72651b20$572f5160$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <050701d5a8ea$72651b20$572f5160$@gmail.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 Archived-At: Subject: Re: [IPsec] Some thoughts regarging draft-hopps-ipsecme-iptfs-01 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, 02 Dec 2019 08:49:36 -0000 Hi Valery, On Mon, Dec 02, 2019 at 11:28:16AM +0300, Valery Smyslov wrote: > Hi Steffen, > > > > It seems to me that it can be done pretty easy by linking the reassembly logic > > > with replay protection window. > > > > While it looks like doing the reassembling based on ESP sequence numbers > > might be an easy approach, it could be also dangerous. > > > > Consider a system that encapsulates two flows on different cpus > > with the same SA. This system can TX packets in the following > > order: > > > > TX cpu0 inner flow0 SA0: > > > > Offset: 0 Offset: 100 > > [ ESP1 (1500) ] [ ESP3 (1500) ] > > [--800--][--800- -][-----1400---] > > > > -------------------------------------------------------------------------------------- > > TX cpu1 inner flow1 SA0: > > Offset: 0 Offset: 100 > > [ ESP2 (1500) ] [ ESP4 (1500) ] > > [--800--][--800- -][----1400----] > > > > > > On the receive side, it is not that clear how to reassemble the fragments > > from ESP3 and ESP4 into the fragments from ESP1 and ESP2. Maybe some > > packet ID in the IP-TFS header could help to identify related fragments. > > I'm probably missing something here, but I think that sending side assigns > every outgoing IP packet to some SA. Then the packet is added to the ESP message > (that may already contain previous packets). If the packet cannot fit into the > left space, it is split and the rest of the packet is sent in the next > ESP message of the same SA. All packets are sent over the same SA, but on different cpus. This means that the 'rest' might not be in the next ESP message. The other cpu could have TXed some ESP packets before, it is a race. In this example, flow0 is encapsulated on cpu0, flow1 is encapsulated on cpu1, both on the same SA. ESP1 contains flow0, but ESP2 contains flow1. The 'rest' from flow0 is encapsulated in ESP3, the 'rest' from flow1 is encapsulated in ESP4. So I think it is not clear how to do a correct reassembling here. Steffen From nobody Mon Dec 2 01:02:47 2019 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 8FE1A120041 for ; Mon, 2 Dec 2019 01:02:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 33Rupua1NbZA for ; Mon, 2 Dec 2019 01:02:44 -0800 (PST) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 4D901120013 for ; Mon, 2 Dec 2019 01:02:44 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id d20so9307146ljc.12 for ; Mon, 02 Dec 2019 01:02:44 -0800 (PST) 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=6PntpCLilRE0ecl4LXJ+ZLnlGR7PzXNE3ewFj4EtLQ0=; b=Bsxs5wojJtB4IVEoRaZ1yUtQ4RetA2D8+PnDR/YiHbGzM9s+Wk317g0GjzyEAd1wQu BtLphS0LgHVx7tzHaL9tCJ01nkBesP2iHOTaXVO5xuvEB02Gmn9ldH7gfBrbdG71rzEz iBokw6Fg3xloTYlxvsJ8eAz0Iis+8puzsRiSVrQEHqMhB5wRMpd3xcAUGghWtw8qhrVw V58pTKJTYgGHizelbUD0JAv6zx1timpzuJ7vk7KoklbyFWTqJe1xaGyigX2LYFe6A4LU uRE1Wgy/npMXrMYq+sYcFtL8g56v/h50qS3Xfr3uowFq19Wp/cH8guxmMkEQVO63yNbt u/4A== 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=6PntpCLilRE0ecl4LXJ+ZLnlGR7PzXNE3ewFj4EtLQ0=; b=C5Hmw4FSkSGTj4dNGEcQCeNd/NhwI3EzywIRtU2tyPSsntEOn+FxWXnbZp7LUd8utq TLz6tVrV1IDbeKYYP4mVvWlgSkLFzEyzMyq3UMx5PSW3T7ygbmOe53baVJe2U8+LSz4Q xjQIAqyOqYIz8A8qTyBAUoJpj/MmBNT2E+lmRzraIW9TlkzDwDugJ/AQmiOzYRScWbZX +fOVqKBDghO5REyKIrdp5cHpK0nJvSbYt6bMRbHL9HG+/uIr7RTFe5I7iGUr6TK2K1FA 4ABguiA7ZWRLcAPuyP1KDlAhtmp+hdFxX9MTG+TCLiqt98s3C6YlrHaXnoMlj7X8V7y6 YrAg== X-Gm-Message-State: APjAAAVTEYyajvkk2RaVrCqAWrUA2W2+7ot/2w40RZt1t3wCWdPBSRM8 TsbzfVfjJtziSc6egzV0aZy8B28k X-Google-Smtp-Source: APXvYqxBQYhIoQZ82m3OKGMXwjjJI43djezEfCZJSbPwSWY6whUn+tnoqvaPstNiJeFPyO8q0Vkqww== X-Received: by 2002:a2e:2c0a:: with SMTP id s10mr10507877ljs.193.1575277362256; Mon, 02 Dec 2019 01:02:42 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id i23sm14229156lfj.71.2019.12.02.01.02.41 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 02 Dec 2019 01:02:41 -0800 (PST) From: "Valery Smyslov" To: "'Steffen Klassert'" Cc: "'IPsecME WG'" References: <039e01d5a5f2$ac51d350$04f579f0$@gmail.com> <20191202080154.GM13225@gauss3.secunet.de> <050701d5a8ea$72651b20$572f5160$@gmail.com> <20191202084930.GN13225@gauss3.secunet.de> In-Reply-To: <20191202084930.GN13225@gauss3.secunet.de> Date: Mon, 2 Dec 2019 12:02:42 +0300 Message-ID: <050901d5a8ef$41cbc0e0$c56342a0$@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: AQHtQTffgHTNPTWByX2TyLtNjmyTVQK65kI2AlcpSPgCBmcKL6c+lWdQ Content-Language: ru Archived-At: Subject: Re: [IPsec] Some thoughts regarging draft-hopps-ipsecme-iptfs-01 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, 02 Dec 2019 09:02:45 -0000 > All packets are sent over the same SA, but on different cpus. This means > that the 'rest' might not be in the next ESP message. The other cpu > could have TXed some ESP packets before, it is a race. > > In this example, flow0 is encapsulated on cpu0, flow1 is encapsulated on cpu1, > both on the same SA. > > ESP1 contains flow0, but ESP2 contains flow1. The 'rest' from flow0 is > encapsulated in ESP3, the 'rest' from flow1 is encapsulated in ESP4. > So I think it is not clear how to do a correct reassembling here. Ah, I see now. It seems to be a real problem and I think that in this case fragmentation must be disabled. And this must be discussed in the draft. Regards, Valery. > Steffen From nobody Mon Dec 2 02:37:49 2019 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 3CC1F1200FA for ; Mon, 2 Dec 2019 02:37:48 -0800 (PST) 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_DNSWL_NONE=-0.0001, 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 4qw4yOBinBFq for ; Mon, 2 Dec 2019 02:37:47 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 167C61200E7 for ; Mon, 2 Dec 2019 02:37:47 -0800 (PST) Received: from stubbs.int.chopps.org (66-227-211-29.dhcp.trcy.mi.charter.com [66.227.211.29]) (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 45EDF60582; Mon, 2 Dec 2019 10:37:46 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Christian Hopps In-Reply-To: <20191202022859.GE32847@mit.edu> Date: Mon, 2 Dec 2019 05:37:45 -0500 Cc: Christian Hopps , Paul Wouters , IPsecME WG , Valery Smyslov Content-Transfer-Encoding: quoted-printable Message-Id: References: <039e01d5a5f2$ac51d350$04f579f0$@gmail.com> <042301d5a6b6$bc8e9fe0$35abdfa0$@gmail.com> <044701d5a6d0$032d5a90$09880fb0$@gmail.com> <5CAB559D-595E-4503-AC72-31E88B6F53AA@chopps.org> <3F136824-B2BB-429A-BC24-226FC2F9D199@chopps.org> <20191202022859.GE32847@mit.edu> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [IPsec] ESP next payload number [Re: Some thoughts regarging draft-hopps-ipsecme-iptfs-01] 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, 02 Dec 2019 10:37:48 -0000 > On Dec 1, 2019, at 9:28 PM, Benjamin Kaduk wrote: >=20 > On Sun, Dec 01, 2019 at 03:52:30AM -0500, Christian Hopps wrote: >> I think it's important for this discussion to recognize that we have = 2 orthogonal issues. >>=20 >> 1) How does IP-TFS work on the wire with IPsec/ESP - this is where we = need to make sure we don't unnecessarily restrict uni-directional use. >>=20 >> 2) What are the changes to IKEv2 to support IP-TFS - this is where we = need to decided if we need the ability to negotiate uni-direction cases, = we don't believe we need to do this. I think this is inline with what = people are expecting here (i.e., a pair of SAs with IP-TFS enabled or = not). >>=20 >> More inline.. >>=20 >>> On Dec 1, 2019, at 2:41 AM, Paul Wouters wrote: >>>=20 >>> On Fri, 29 Nov 2019, Christian Hopps wrote: >>>=20 >>> It seems unwise to protect traffic one way but not the other way. = Are >>> endusers really able to make the right decision based on their = generated >>> traffic? If you are that hungry for resources, perhaps this isn't an >>> option for you to use? >>=20 >> There is no traffic to protect in the reverse direction. Consider = telemetry where one is simply sending un-acked UDP data using to = monitors. >=20 > I feel like I must be missing something; if there's no traffic in the > reverse direction why does it matter if we assign semantics to the = reverse > SA or not? B/c an IP-TFS enabled SA is sending a constant stream of packets either = filled with the actual traffic or pad if no data is available. Thanks, Chris. >=20 > -Ben From nobody Mon Dec 2 03:22:30 2019 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 B902D12002E for ; Mon, 2 Dec 2019 03:22:29 -0800 (PST) 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_DNSWL_NONE=-0.0001, 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 klZ6PHNLfw6m for ; Mon, 2 Dec 2019 03:22:28 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC49120020 for ; Mon, 2 Dec 2019 03:22:28 -0800 (PST) Received: from stubbs.int.chopps.org (66-227-211-29.dhcp.trcy.mi.charter.com [66.227.211.29]) (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 91E2360582; Mon, 2 Dec 2019 11:22:27 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Christian Hopps In-Reply-To: <20191202080154.GM13225@gauss3.secunet.de> Date: Mon, 2 Dec 2019 06:22:26 -0500 Cc: Christian Hopps , Valery Smyslov , IPsecME WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <039e01d5a5f2$ac51d350$04f579f0$@gmail.com> <20191202080154.GM13225@gauss3.secunet.de> To: Steffen Klassert X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [IPsec] Some thoughts regarging draft-hopps-ipsecme-iptfs-01 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, 02 Dec 2019 11:22:30 -0000 > On Dec 2, 2019, at 3:01 AM, Steffen Klassert = wrote: >=20 > On Thu, Nov 28, 2019 at 04:49:36PM +0300, Valery Smyslov wrote: >> Hi, >>=20 >> after reading through draft-hopps-ipsecme-iptfs-01 I have some = thoughts. >>=20 >> 1. I think it's a wrong decision to support tunnel mode ESP only. = IP-TFS for transport mode ESP >> is equally important because one of the widely used scenario is to = combine general purpose >> tunneling (like GRE) with transport mode ESP. In this case traffic = flowing over such SA >> will in fact be tunnel traffic from several hosts, but the SA is = created in transport mode. >> For this reason I think that IP-TFS must support transport mode SA = either. >=20 > I'd like to agree here. It does not add much more complexity and there = are valid usecases > for transport mode (and even for BEET mode). >=20 >> 4. I'd like to see more text in the draft regarding reassembling of = incoming packets. >=20 > Yes, I think some words on how to reassemble the fragments are really > needed. >=20 >> It seems to me that it can be done pretty easy by linking the = reassembly logic >> with replay protection window. >=20 > While it looks like doing the reassembling based on ESP sequence = numbers > might be an easy approach, it could be also dangerous. >=20 > Consider a system that encapsulates two flows on different cpus > with the same SA. This system can TX packets in the following > order: >=20 > TX cpu0 inner flow0 SA0: >=20 > Offset: 0 Offset: 100 =20 > [ ESP1 (1500) ] [ ESP3 (1500) ] =20 > [--800--][--800- -][-----1400---]=20 >=20 > = --------------------------------------------------------------------------= ------------ > TX cpu1 inner flow1 SA0: > Offset: 0 = Offset: 100 =20 > [ ESP2 (1500) ] [ = ESP4 (1500) ] > [--800--][--800- = -][----1400----] =20 >=20 >=20 > On the receive side, it is not that clear how to reassemble the = fragments > from ESP3 and ESP4 into the fragments from ESP1 and ESP2. Maybe some > packet ID in the IP-TFS header could help to identify related = fragments. Indeed the code mustn't fragment this way. :) We could add a bit of text that one should avoid this mistake. One way to implement this is using a queue of packets to order the = transmission. The flows (using any number cpus) add their packets to the = queue. The IP-TFS ESP encapsulation code (again using any number of = CPUs) remove packet fragments, in order, from the queue when = constructing the IP-TFS ESP packets. The SA ESP sequence number stored = with the queue. Another way to do this (the way we are coding it) is to queue pre-built = IP-TFS payloads directly onto a queue. In this case you have an = "in-progress" payload that you add the next packet to while the queue is = locked. If you fill this in-progress payload you simply move it to the = send queue and start a new in-progress payload, repeat if need be until = the whole packet is present in the queue, then you unlock the queue. The = send routine (again running on any number of CPUs) dequeues, encrypts = and sends the payloads. For the second method the payload construction is very quick as we are = not doing buffer copies, but simply using buffer chaining/indirection, = so the queue lock is not problematic. Thanks, Chris. > Steffen >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 From nobody Mon Dec 2 06:11:54 2019 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 EF6C4120086 for ; Mon, 2 Dec 2019 06:11:51 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 VLGaWPWYxAHD for ; Mon, 2 Dec 2019 06:11:49 -0800 (PST) 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 842AA12006D for ; Mon, 2 Dec 2019 06:11:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 06093204FD; Mon, 2 Dec 2019 15:11:46 +0100 (CET) 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 GcVlB_a6K4zG; Mon, 2 Dec 2019 15:11:45 +0100 (CET) Received: from mail-essen-01.secunet.de (mail-essen-01.secunet.de [10.53.40.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a.mx.secunet.com (Postfix) with ESMTPS id 8EB1B201AE; Mon, 2 Dec 2019 15:11:45 +0100 (CET) Received: from gauss2.secunet.de (10.182.7.193) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server id 14.3.439.0; Mon, 2 Dec 2019 15:11:45 +0100 Received: by gauss2.secunet.de (Postfix, from userid 1000) id 251B3318262A; Mon, 2 Dec 2019 15:11:45 +0100 (CET) Date: Mon, 2 Dec 2019 15:11:45 +0100 From: Steffen Klassert To: Christian Hopps CC: IPsecME WG , Valery Smyslov Message-ID: <20191202141145.GJ14361@gauss3.secunet.de> References: <039e01d5a5f2$ac51d350$04f579f0$@gmail.com> <20191202080154.GM13225@gauss3.secunet.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 Archived-At: Subject: Re: [IPsec] Some thoughts regarging draft-hopps-ipsecme-iptfs-01 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, 02 Dec 2019 14:11:52 -0000 On Mon, Dec 02, 2019 at 06:22:26AM -0500, Christian Hopps wrote: > > On Dec 2, 2019, at 3:01 AM, Steffen Klassert wrote: > > On Thu, Nov 28, 2019 at 04:49:36PM +0300, Valery Smyslov wrote: > > > >> 4. I'd like to see more text in the draft regarding reassembling of incoming packets. > > > > Yes, I think some words on how to reassemble the fragments are really > > needed. > > > >> It seems to me that it can be done pretty easy by linking the reassembly logic > >> with replay protection window. > > > > While it looks like doing the reassembling based on ESP sequence numbers > > might be an easy approach, it could be also dangerous. > > > > Consider a system that encapsulates two flows on different cpus > > with the same SA. This system can TX packets in the following > > order: > > > > TX cpu0 inner flow0 SA0: > > > > Offset: 0 Offset: 100 > > [ ESP1 (1500) ] [ ESP3 (1500) ] > > [--800--][--800- -][-----1400---] > > > > -------------------------------------------------------------------------------------- > > TX cpu1 inner flow1 SA0: > > Offset: 0 Offset: 100 > > [ ESP2 (1500) ] [ ESP4 (1500) ] > > [--800--][--800- -][----1400----] > > > > > > On the receive side, it is not that clear how to reassemble the fragments > > from ESP3 and ESP4 into the fragments from ESP1 and ESP2. Maybe some > > packet ID in the IP-TFS header could help to identify related fragments. > > Indeed the code mustn't fragment this way. :) > > We could add a bit of text that one should avoid this mistake. I'm not so sure whether the receiver should rely on that the sender did the fragmentation right. I think a packet ID, like IP fragments have, would just solve the problem. The implementation would not even need to care about this multicore race then. Steffen From nobody Mon Dec 2 07:58:03 2019 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 524AE12080D for ; Mon, 2 Dec 2019 07:58:02 -0800 (PST) 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_DNSWL_NONE=-0.0001, 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 gCswZYJd-_kl for ; Mon, 2 Dec 2019 07:58:01 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id D9EE8120800 for ; Mon, 2 Dec 2019 07:58:00 -0800 (PST) Received: from stubbs.int.chopps.org (66-227-211-29.dhcp.trcy.mi.charter.com [66.227.211.29]) (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 5AEE460582; Mon, 2 Dec 2019 15:58:00 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Christian Hopps In-Reply-To: <20191202141145.GJ14361@gauss3.secunet.de> Date: Mon, 2 Dec 2019 10:57:59 -0500 Cc: Christian Hopps , IPsecME WG , Valery Smyslov Content-Transfer-Encoding: quoted-printable Message-Id: References: <039e01d5a5f2$ac51d350$04f579f0$@gmail.com> <20191202080154.GM13225@gauss3.secunet.de> <20191202141145.GJ14361@gauss3.secunet.de> To: Steffen Klassert X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [IPsec] Some thoughts regarging draft-hopps-ipsecme-iptfs-01 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, 02 Dec 2019 15:58:02 -0000 > On Dec 2, 2019, at 9:11 AM, Steffen Klassert = wrote: >=20 > On Mon, Dec 02, 2019 at 06:22:26AM -0500, Christian Hopps wrote: >>> On Dec 2, 2019, at 3:01 AM, Steffen Klassert = wrote: >>> On Thu, Nov 28, 2019 at 04:49:36PM +0300, Valery Smyslov wrote: >>>=20 >>>> 4. I'd like to see more text in the draft regarding reassembling of = incoming packets. >>>=20 >>> Yes, I think some words on how to reassemble the fragments are = really >>> needed. >>>=20 >>>> It seems to me that it can be done pretty easy by linking the = reassembly logic >>>> with replay protection window. >>>=20 >>> While it looks like doing the reassembling based on ESP sequence = numbers >>> might be an easy approach, it could be also dangerous. >>>=20 >>> Consider a system that encapsulates two flows on different cpus >>> with the same SA. This system can TX packets in the following >>> order: >>>=20 >>> TX cpu0 inner flow0 SA0: >>>=20 >>> Offset: 0 Offset: 100 =20 >>> [ ESP1 (1500) ] [ ESP3 (1500) ] =20 >>> [--800--][--800- -][-----1400---]=20 >>>=20 >>> = --------------------------------------------------------------------------= ------------ >>> TX cpu1 inner flow1 SA0: >>> Offset: 0 = Offset: 100 =20 >>> [ ESP2 (1500) ] [ = ESP4 (1500) ] >>> [--800--][--800- = -][----1400----] =20 >>>=20 >>>=20 >>> On the receive side, it is not that clear how to reassemble the = fragments >>> from ESP3 and ESP4 into the fragments from ESP1 and ESP2. Maybe some >>> packet ID in the IP-TFS header could help to identify related = fragments. >>=20 >> Indeed the code mustn't fragment this way. :) >>=20 >> We could add a bit of text that one should avoid this mistake. >=20 > I'm not so sure whether the receiver should rely on that > the sender did the fragmentation right. I think a packet > ID, like IP fragments have, would just solve the problem. > The implementation would not even need to care about this > multicore race then. The receiver can do any number of wrong things with what it sends, but = I'd normally call those bugs. :) Technically though, attaching a packet ID to the fragments to allowing = sending them in any order saves only a little on code complexity (i.e., = not using an ordering queue) on the sender side; however, it seems to = add a disproportionate amount of complexity to the receiver/reassembly = (which could e.g., be aggregating VPN server). Adding a packet ID also = means that you can't just chain the inner traffic buffers together to = form the IP-TFS payload as you must now insert an extra header between = each of the inner packets, this is going to affect performance and = memory use on whitebox/software based deployments as well as reduce = available bandwidth on the tunnel. I think we should try and keep fragmentation and reassembly as simple as = possible so that it is easy to implement and get right. Having coded = this using just the ESP sequence numbers to correct-order the received = packets, I can say it's an easy-to-moderate complex function that = performs well, it took a few iterations on the code to get it right and = well tested. Adding another level to this receive complexity should only = be done if we absolutely have to. I don't think we are there yet, given = that the use of a simple ordering queue on the sender side is all we are = talking about. Again it's easy to add some text to the document to highlight what needs = to be paid attention to if one is using multiple cores to send on a = single IPsec SA. Thanks, Chris. > Steffen >=20 From nobody Tue Dec 3 00:10:16 2019 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 B563A120143 for ; Tue, 3 Dec 2019 00:10:15 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 zlFB78MqqFWn for ; Tue, 3 Dec 2019 00:10:14 -0800 (PST) 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 AC653120131 for ; Tue, 3 Dec 2019 00:10:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id BA2BC20523; Tue, 3 Dec 2019 09:10:09 +0100 (CET) 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 iHCGCxLmpm0I; Tue, 3 Dec 2019 09:10:09 +0100 (CET) Received: from mail-essen-01.secunet.de (mail-essen-01.secunet.de [10.53.40.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a.mx.secunet.com (Postfix) with ESMTPS id 30B4320411; Tue, 3 Dec 2019 09:10:09 +0100 (CET) Received: from gauss2.secunet.de (10.182.7.193) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server id 14.3.439.0; Tue, 3 Dec 2019 09:10:08 +0100 Received: by gauss2.secunet.de (Postfix, from userid 1000) id B4459318017A; Tue, 3 Dec 2019 09:10:08 +0100 (CET) Date: Tue, 3 Dec 2019 09:10:08 +0100 From: Steffen Klassert To: Christian Hopps CC: IPsecME WG , Valery Smyslov Message-ID: <20191203081008.GO13225@gauss3.secunet.de> References: <039e01d5a5f2$ac51d350$04f579f0$@gmail.com> <20191202080154.GM13225@gauss3.secunet.de> <20191202141145.GJ14361@gauss3.secunet.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 Archived-At: Subject: Re: [IPsec] Some thoughts regarging draft-hopps-ipsecme-iptfs-01 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, 03 Dec 2019 08:10:16 -0000 On Mon, Dec 02, 2019 at 10:57:59AM -0500, Christian Hopps wrote: > > On Dec 2, 2019, at 9:11 AM, Steffen Klassert wrote: > > On Mon, Dec 02, 2019 at 06:22:26AM -0500, Christian Hopps wrote: > >>> On Dec 2, 2019, at 3:01 AM, Steffen Klassert wrote: > >>> On Thu, Nov 28, 2019 at 04:49:36PM +0300, Valery Smyslov wrote: > >>> > >>>> 4. I'd like to see more text in the draft regarding reassembling of incoming packets. > >>> > >>> Yes, I think some words on how to reassemble the fragments are really > >>> needed. > >>> > >>>> It seems to me that it can be done pretty easy by linking the reassembly logic > >>>> with replay protection window. > >>> > >>> While it looks like doing the reassembling based on ESP sequence numbers > >>> might be an easy approach, it could be also dangerous. > >>> > >>> Consider a system that encapsulates two flows on different cpus > >>> with the same SA. This system can TX packets in the following > >>> order: > >>> > >>> TX cpu0 inner flow0 SA0: > >>> > >>> Offset: 0 Offset: 100 > >>> [ ESP1 (1500) ] [ ESP3 (1500) ] > >>> [--800--][--800- -][-----1400---] > >>> > >>> -------------------------------------------------------------------------------------- > >>> TX cpu1 inner flow1 SA0: > >>> Offset: 0 Offset: 100 > >>> [ ESP2 (1500) ] [ ESP4 (1500) ] > >>> [--800--][--800- -][----1400----] > >>> > >>> > >>> On the receive side, it is not that clear how to reassemble the fragments > >>> from ESP3 and ESP4 into the fragments from ESP1 and ESP2. Maybe some > >>> packet ID in the IP-TFS header could help to identify related fragments. > >> > >> Indeed the code mustn't fragment this way. :) > >> > >> We could add a bit of text that one should avoid this mistake. > > > > I'm not so sure whether the receiver should rely on that > > the sender did the fragmentation right. I think a packet > > ID, like IP fragments have, would just solve the problem. > > The implementation would not even need to care about this > > multicore race then. > > The receiver can do any number of wrong things with what it sends, but I'd normally call those bugs. :) Yes, that's true. But if the protocol allows to do things wrong, it is a bug in the protocol :) Maybe you can just make it clear at the sender side by saying something like 'Fragments must be sent ordered and ESP encapsulated with consecutive sequence numbers.' > > Technically though, attaching a packet ID to the fragments to allowing sending them in any order saves only a little on code complexity (i.e., not using an ordering queue) on the sender side; I hoped to avoid such an ordering/serialization queue as I fear this will become a bottleneck. With the current design, I don't see how to do this without a queue. I know, it is an implementation detail, but implementation matters too :) > however, it seems to add a disproportionate amount of complexity to the receiver/reassembly (which could e.g., be aggregating VPN server). Yes, if you know that the next fragment comes with the next ESP packet, things are much easier. So we have the complexity either at the sender or the receiver side, not so sure what performs better. > Adding a packet ID also means that you can't just chain the inner traffic buffers together to form the IP-TFS payload as you must now insert an extra header between each of the inner packets, this is going to affect performance and memory use on whitebox/software based deployments as well as reduce available bandwidth on the tunnel. Good point. You can always chain extra headers and inner packets with a scatter-gather list, but it will have some performance impact. > I think we should try and keep fragmentation and reassembly as simple as possible so that it is easy to implement and get right. I absolutely agree here. > Having coded this using just the ESP sequence numbers to correct-order the received packets, I can say it's an easy-to-moderate complex function that performs well, it took a few iterations on the code to get it right and well tested. Adding another level to this receive complexity should only be done if we absolutely have to. I don't think we are there yet, given that the use of a simple ordering queue on the sender side is all we are talking about. > > Again it's easy to add some text to the document to highlight what needs to be paid attention to if one is using multiple cores to send on a single IPsec SA. As said above, just make it clear how the sender must order the fragments if you don't want a packet ID. Steffen From nobody Tue Dec 3 03:03:01 2019 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 F156A1202A0 for ; Tue, 3 Dec 2019 03:02:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 91w2HVJmAQM4 for ; Tue, 3 Dec 2019 03:02:58 -0800 (PST) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 15261120041 for ; Tue, 3 Dec 2019 03:02:58 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id y19so2552706lfl.9 for ; Tue, 03 Dec 2019 03:02:57 -0800 (PST) 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=cipqNqaO2zC5zNBm9CwmgLM/XXAoRMFOOQXUHsHas4I=; b=FpxX25eBqD2rbuY42ygqGx2mTIUBm2LsiSzAgf9IgFnfc4wf23vDQg29szXNQqeq5C WM5Gu/XVDZiKBaCEu28YbAnWHGG9IBC0dGS220q1zf+30Lu/eNsA3nmQfrHTGRRu1sKg gIAevB+DUOomGmz8yyZqwOrDh2Ug570xLiHVDoXQEegYTQavprvtB/jHTjQBrxzIfBUa +Sq+QpYBdv3NFYDBW1itt/kBgLaYVrZjjVZ1/4ayLixJqyRPjVaQjXT6YiX6Y+pNSH99 K1MAIvYFEbNo8WZZI6WBydM9n20bOD0i+1SGwduhWQ7sIr1hju5wNgvLmOBVBQX6lW9c 3S4g== 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=cipqNqaO2zC5zNBm9CwmgLM/XXAoRMFOOQXUHsHas4I=; b=nWf9+j2jfD92YvA03tThBbtunESLOjChuJEAeYjOvjRI6nfH0PRcDs6BKJpGp4TvCG p57KLkr8crV80p4AqiF/+fYuqRrCu6yvQGBNrg/ftpyRIYc97u51YPlHsffudR0LzBzM 3RWZffJXolJGMU7tOj/xaqMVURhkVXAbGJ8W3ZTEsveRW9wULJU7nbg5hr0xoOnBOzmb +WZn6eOybx2FAaLLY3LYx7vlNqm3tLXyr/oEGkoFS4NsljEX9/zWMwOk76Uq3aBmOLb1 22ZrBrEaGiYyMre5gtlNsFfYNDEq3AfI4hQemU2beDxcilEvDNlMhgc/8w4dB8oFui6I pnWw== X-Gm-Message-State: APjAAAWnQwwSe2T2gr+10ZTzSPjQzjmAlQNhLKhiaxZZPENiXgBqtgRF 3EU3Eqf7QaBnWqhrVlglNyE= X-Google-Smtp-Source: APXvYqy/OgT+V95415MThXvHHeFee3nLxvrMswapbWz4rnugOUjd5+/KAWXO1iJmgdcmcwHYpyfC8w== X-Received: by 2002:a19:4f54:: with SMTP id a20mr2404010lfk.39.1575370976368; Tue, 03 Dec 2019 03:02:56 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id q10sm1133863ljj.60.2019.12.03.03.02.55 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 03 Dec 2019 03:02:55 -0800 (PST) From: "Valery Smyslov" To: "'Steffen Klassert'" , "'Christian Hopps'" Cc: "'IPsecME WG'" References: <039e01d5a5f2$ac51d350$04f579f0$@gmail.com> <20191202080154.GM13225@gauss3.secunet.de> <20191202141145.GJ14361@gauss3.secunet.de> <20191203081008.GO13225@gauss3.secunet.de> In-Reply-To: <20191203081008.GO13225@gauss3.secunet.de> Date: Tue, 3 Dec 2019 14:02:57 +0300 Message-ID: <05fa01d5a9c9$38a9cb30$a9fd6190$@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: AQHtQTffgHTNPTWByX2TyLtNjmyTVQK65kI2Af/tjrgCAga0egEq2Sl0AtENFjenI0hQsA== Content-Language: ru Archived-At: Subject: Re: [IPsec] Some thoughts regarging draft-hopps-ipsecme-iptfs-01 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, 03 Dec 2019 11:03:00 -0000 > > The receiver can do any number of wrong things with what it sends, but I'd normally call those bugs. :) > > Yes, that's true. But if the protocol allows to do things wrong, it is > a bug in the protocol :) > > Maybe you can just make it clear at the sender side by saying something > like 'Fragments must be sent ordered and ESP encapsulated with consecutive > sequence numbers.' I concur (modulo s/must/MUST). And in addition: "If this requirement cannot be met, the sender MUST NOT fragment packets." > > Adding a packet ID also means that you can't just chain the inner traffic buffers together to form the IP-TFS > payload as you must now insert an extra header between each of the inner packets, this is going to affect > performance and memory use on whitebox/software based deployments as well as reduce available > bandwidth on the tunnel. > > Good point. You can always chain extra headers and inner packets with > a scatter-gather list, but it will have some performance impact. If support for transport mode is added then an extra header seems anavoidable... > > I think we should try and keep fragmentation and reassembly as simple as possible so that it is easy to > implement and get right. > > I absolutely agree here. Strongly agree. Regards, Valery. > Steffen From nobody Tue Dec 3 04:34:13 2019 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 7951A1200E7 for ; Tue, 3 Dec 2019 04:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 On_NyAD9125w for ; Tue, 3 Dec 2019 04:34:10 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4CE1200B1 for ; Tue, 3 Dec 2019 04:34:10 -0800 (PST) Received: from stubbs.int.chopps.org (66-227-211-29.dhcp.trcy.mi.charter.com [66.227.211.29]) (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 7842F60582; Tue, 3 Dec 2019 12:34:09 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Christian Hopps In-Reply-To: <20191203081008.GO13225@gauss3.secunet.de> Date: Tue, 3 Dec 2019 07:34:08 -0500 Cc: Christian Hopps , IPsecME WG , Valery Smyslov Content-Transfer-Encoding: quoted-printable Message-Id: <2C17C9A0-0C7A-463F-BBB0-4A1824793C8B@chopps.org> References: <039e01d5a5f2$ac51d350$04f579f0$@gmail.com> <20191202080154.GM13225@gauss3.secunet.de> <20191202141145.GJ14361@gauss3.secunet.de> <20191203081008.GO13225@gauss3.secunet.de> To: Steffen Klassert X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [IPsec] Some thoughts regarging draft-hopps-ipsecme-iptfs-01 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, 03 Dec 2019 12:34:11 -0000 > On Dec 3, 2019, at 3:10 AM, Steffen Klassert = wrote: > On Mon, Dec 02, 2019 at 10:57:59AM -0500, Christian Hopps wrote: >>=20 >> Technically though, attaching a packet ID to the fragments to = allowing sending them in any order saves only a little on code = complexity (i.e., not using an ordering queue) on the sender side; >=20 > I hoped to avoid such an ordering/serialization queue as I fear > this will become a bottleneck. With the current design, I don't > see how to do this without a queue. I know, it is an implementation > detail, but implementation matters too :) Absolutely. >> however, it seems to add a disproportionate amount of complexity to = the receiver/reassembly (which could e.g., be aggregating VPN server). >=20 > Yes, if you know that the next fragment comes with the next ESP > packet, things are much easier. So we have the complexity either > at the sender or the receiver side, not so sure what performs better. FWIW, we will have some implementation/operational experience here to = look at, as a WG, prior to making any final choices. I'm currently = working to code this for running over a 100G link in a whitebox setup, = and I will report back to the WG when we have some numbers. :) Thanks, Chris.= From nobody Tue Dec 3 04:37:02 2019 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 A279F1200E7 for ; Tue, 3 Dec 2019 04:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 gIHtScbektzS for ; Tue, 3 Dec 2019 04:36:59 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7C09B120020 for ; Tue, 3 Dec 2019 04:36:59 -0800 (PST) Received: from stubbs.int.chopps.org (66-227-211-29.dhcp.trcy.mi.charter.com [66.227.211.29]) (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 C8A5260582; Tue, 3 Dec 2019 12:36:58 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Christian Hopps In-Reply-To: <05fa01d5a9c9$38a9cb30$a9fd6190$@gmail.com> Date: Tue, 3 Dec 2019 07:36:57 -0500 Cc: Christian Hopps , Steffen Klassert , IPsecME WG Content-Transfer-Encoding: quoted-printable Message-Id: <33168DA4-8B68-4F09-9997-0A9AD110810B@chopps.org> References: <039e01d5a5f2$ac51d350$04f579f0$@gmail.com> <20191202080154.GM13225@gauss3.secunet.de> <20191202141145.GJ14361@gauss3.secunet.de> <20191203081008.GO13225@gauss3.secunet.de> <05fa01d5a9c9$38a9cb30$a9fd6190$@gmail.com> To: Valery Smyslov X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [IPsec] Some thoughts regarging draft-hopps-ipsecme-iptfs-01 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, 03 Dec 2019 12:37:01 -0000 > On Dec 3, 2019, at 6:02 AM, Valery Smyslov = wrote: >=20 >>> Adding a packet ID also means that you can't just chain the inner = traffic buffers together to form the IP-TFS >> payload as you must now insert an extra header between each of the = inner packets, this is going to affect >> performance and memory use on whitebox/software based deployments as = well as reduce available >> bandwidth on the tunnel. >>=20 >> Good point. You can always chain extra headers and inner packets with >> a scatter-gather list, but it will have some performance impact. >=20 > If support for transport mode is added then an extra header seems = anavoidable... I suspect you are correct. For the transport case it should be enough to = just replicate the ESP sequence number method (i.e., add it to the = IP-TFS header once) too though. Thanks, Chris. From nobody Tue Dec 3 05:08:17 2019 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 1857312002E; Tue, 3 Dec 2019 05:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 nrqyFOA_e0il; Tue, 3 Dec 2019 05:08:14 -0800 (PST) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 DBED1120019; Tue, 3 Dec 2019 05:08:13 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id j6so3762608lja.2; Tue, 03 Dec 2019 05:08:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=QVkhHup+jtaPqOrVxW6x+Ebbq+ApRGt8wrQ0yC53Bas=; b=LpioZkYoOnTGchXpDgpeIG1g0qkezYHGZ2zmwFRefZyVQLJkiqaHtfCjqgymhlCSLO jwa7tGxDs8zTRvHQ7rHvmYwQo6HxX2KL1Qs5mXNe+6hHrU1bouBBX3I/zyOtZUc5ewa3 3a7+EHiDodLMacbProld6Xpj6kvT7Bo1rO2v582Jh4aF/qhCOzXIBCaqgVGxUgHrZNgK 7h5CUxM3lMjbxzd/e3nuazJqVme5kc3wQ4j4C2tPjnvPK0UBHjeGgql+dIRKkcVAAeXO 7yXonqpSPJ3kNTmG14aM1HENfrTULQkEoOWzWcu/nhGDm09/PjQtvYulibBlT3EL9BQ9 XEPg== 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:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=QVkhHup+jtaPqOrVxW6x+Ebbq+ApRGt8wrQ0yC53Bas=; b=B1rRFio5AgBPyq/C9y6FRFGByfqiGuUDG8csTO0sSVrSBic6f977iQXTvtDzyMRzFH R5Fd3ZPrLNXgBPM0hRmLOrMhMCS5DtaAXAZu2H/mpFxD2rqComMVvuczHQYG7YH1coGz PXevHm3H7vl3roTa4bgaZfvsxV8s0Hw6es6eJYp/nl/tTVOfw4ctBnM1wqd6gH8RGZOK c84INt1nRXGnguYthhT5rkhmnVqHdkdG+di0qikceKeHpE7kHHOWdAw3nVJnwjAyIYT2 EX2JUOTH3elNTVV78PDY7WriP1vczXH2QB2X0VYlwAAHmxYibWuotOOOfkX0BqYuciT8 xexQ== X-Gm-Message-State: APjAAAXFZSjICCMh+3wr2ksMwK3xXDayxd6T1UYWOZc3+OqReGIve6WV VYweHEqZuyf0J5np6kNgbj/dHLiK X-Google-Smtp-Source: APXvYqw9d8+0xKGzRVrDlgQdRh4SjtrOzg9zTer8ZHx8QjxqE7m1U9+kOEimzkFqL6eL0SSV+abXOg== X-Received: by 2002:a2e:809a:: with SMTP id i26mr2504753ljg.108.1575378491800; Tue, 03 Dec 2019 05:08:11 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id n83sm1290106lfd.70.2019.12.03.05.08.10 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 03 Dec 2019 05:08:11 -0800 (PST) From: "Valery Smyslov" To: "'Daniel Migault'" , "'Tobias Guggemos'" Cc: , "IPsecME WG" Date: Tue, 3 Dec 2019 16:08:12 +0300 Message-ID: <060501d5a9da$b8552490$28ff6db0$@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: AdWppfOpIKBZp+0/S/GeseFeC790Mw== Content-Language: ru Archived-At: Subject: [IPsec] Review of draft-ietf-lwig-minimal-esp-00 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, 03 Dec 2019 13:08:16 -0000 Hi, I reviewed draft-ietf-lwig-minimal-esp-00. In general I think that the document provides useful guidelines on how ESP can be implemented on constrained devices. General comment: the draft uses RFC2119 requirement language in several places, and it is not always clear whether it is just a repetition of the RFC4301 requirements or a new requirement imposed by this document. In general, I think it's better not to include the existing RFC4301/4303 requirements in the draft or make it absolutely clear that these are not new requirements if you need to mention them (adding a reference to a corresponding section in the RFCs). Another general comment: sections 3-7 discuss how the corresponding ESP packet fields can be tweaked to deal with low resource devices. I think that for the sake of clarity the suggested measures must be summarized in each of these sections. Currently these sections contain quite a lot of discussion and no clear conclusions what is OK to do and in what situations. I think document will be more clear if such conclusions are put at the end of each section (currently some advises are spread over them). Specific comments: Section 3. When fix SPI are used, it is RECOMMENDED the constraint node has as many SPI values as ESP session per host IP address, and that SA lookup includes the IP addresses. This is probably wrong if we take into considerations that SA may be rekeyed. Some words should be added either prohibiting rekeying ESP SAs in this case or discussing that in case of rekey one will consume additional SPI values for in fact the same SA. When used indoor, the privacy information is stored in the encrypted data and as such does not leak privacy. I cannot parse this :-) Such packet will not be rejected due to an SPI mismatch, but instead after the signature check which requires more resource and thus make DoS more efficient, especially for devices powered by batteries. I think this a very good argument against fixed (predictable) SPIs. In fact, after reading through this section it seems to me that the conclusion must be - predictable (fixed) SPIs SHOULD NOT be used. Values 0-255 SHOULD NOT be used. I believe these values MUST NOT be used with IPsec ESP, no? Why "SHOULD NOT"? The values from this range are reserved for other protocols utilizing ESP (e.g. SPI (1) was used in SKIP). Section 4. I see no discussion regarding using ESN. I think there is generally no point to use ESN for constrained devices, but it can be useful if clock is used to generate (E)SN, as suggested in the draft. In this case 64-bit numbers can make sure that no two packets will be sent with the same ESN (provided the clock has high resolution). Section 5. The purpose of padding is to respect the 32 bit alignment of ESP. It is not an accurate statement, the padding is also used when encryption transform requires the input to be a multiple of some number of bytes. Many modern transforms (based on GCM, CCM, CTR modes) don't have such a requirement, but some (e.g. based on CBC mode) do have. Section 6. For interoperability, it is RECOMMENDED a minimal ESP implementation discards dummy packets. I'm puzzled by this sentence. What else can the receiver do with dummy packets other than discard? RFC4303 leaves him only this option :-) Nits: Throughout the text: s/fix SPI/fixed SPI s/constraint node/constrained node s/algorythm/algorithm Section 2: s/IPsec suite protocol/IPsec protocol suite Section 3: However, for some constraint nodes, generating a random SPI may consume to much resource, in which case SPI can be generated using predictable functions or even a fix value. s/to/too When a constraint node uses fix value for SPIs, it imposes some limitations on the number of inbound SA. This limitation can be alleviate by how the SA look up is performed. When fix SPI are used, it is RECOMMENDED the constraint node has as many SPI values as ESP session per host IP address, and that SA lookup includes the IP addresses. s/alleviate/alleviated s/RECOMMENDED the/RECOMMENDED that the More specifically, traffic pattern MAY leak sufficient information in itself. In other words, privacy leakage is a complex and the use of random SPI is unlikely to be sufficient. s/MAY/may In addition, predictable SPI enable an attacker to forge packets with a valid SPI. s/enable/enables Section 5: As a result, TFC cannot not be enabled with minimal, and communication protection that were relying on TFC will be more sensitive to traffic shaping. s/cannot not/cannot s/minimal/minimal ESP s/were relying/rely Section 7: Currently recommended [RFC8221] only recommend crypto-suites with an ICV which makes the ICV a mandatory field. s/recommend/recommends Section 8: The recommended suites to use are expect to evolve over time and implementer SHOULD follow the recommendations provided by [RFC8221] and updates. s/expect/expected s/implementer/implementers Note that it is not because a encryption algorithm transform is widely deployed that is secured. s/a/an Regards, Valery Smyslov. From nobody Tue Dec 3 05:22:07 2019 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 2701F12002E; Tue, 3 Dec 2019 05:22:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 pncR0c_2FgbR; Tue, 3 Dec 2019 05:21:59 -0800 (PST) Received: from mail-vs1-f52.google.com (mail-vs1-f52.google.com [209.85.217.52]) (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 3EA0D120019; Tue, 3 Dec 2019 05:21:59 -0800 (PST) Received: by mail-vs1-f52.google.com with SMTP id p21so2308514vsq.6; Tue, 03 Dec 2019 05:21:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jrkIUF4c5NCWFUwvueHAmgb46y1wjXsoS0sbNsjmYF4=; b=g3IQe1zgIoFK6ef1A1o1dAQoVOIfynnw4o35WJE9lINB6p1CFU7gcv1wVGxnMaCY33 x0Jwdz25hHrXexr7gTyABoLcFQwDO3vSJaXpC6nHGcl2CQZ3RnNfS0mtaWnnlzF6JEB1 yEse7goxOpSynnmAAB9xSBZ3gMTtFp6E6WZHcXa7r0YfhTH0WWxyzqg2beR5JuS3HI3G UyvmUmN/4LybdThRnpuMu3VfdZAqTUZcx2cBefA9AMd2FQbXR78MXXF3kqoIrqVPrwCj PAMkBJsUu5E2ZFliCIh/k/tyg7Vkh0TsyQJvGYRhwmyeUnHCIiVB/kn21UwqDy9oI7wU VKaQ== X-Gm-Message-State: APjAAAUHSfUvRU0K8ATBbLg+BBsBaPusc3QHEw3ZuLWIU2SJARnnWjqV UffGnz0ZAP7cA4gQ/tMgtK5n/iRGV22es0Ftyb8= X-Google-Smtp-Source: APXvYqyeLR4Y8ISKX4MjXyRhTb2ETzKm+PGD2Jf01PGplrElN10I0Qga8/hBWL0SxeqaxoomvxpN4mfkM/Ks35u9R5U= X-Received: by 2002:a67:ead6:: with SMTP id s22mr2682754vso.69.1575379318298; Tue, 03 Dec 2019 05:21:58 -0800 (PST) MIME-Version: 1.0 References: <060501d5a9da$b8552490$28ff6db0$@gmail.com> In-Reply-To: <060501d5a9da$b8552490$28ff6db0$@gmail.com> From: Daniel Migault Date: Tue, 3 Dec 2019 08:21:47 -0500 Message-ID: To: Valery Smyslov Cc: Tobias Guggemos , lwip@ietf.org, IPsecME WG Content-Type: multipart/alternative; boundary="000000000000a75fc50598cc9408" Archived-At: Subject: Re: [IPsec] Review of draft-ietf-lwig-minimal-esp-00 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, 03 Dec 2019 13:22:01 -0000 --000000000000a75fc50598cc9408 Content-Type: text/plain; charset="UTF-8" Thank you Valery for the detailed review. That is really much appreciated. We will update the document accordingly by the next few weeks also considering the feed backs from Scott. Yours, Daniel On Tue, Dec 3, 2019 at 8:08 AM Valery Smyslov wrote: > Hi, > > I reviewed draft-ietf-lwig-minimal-esp-00. In general I think that the > document > provides useful guidelines on how ESP can be implemented on constrained > devices. > > General comment: the draft uses RFC2119 requirement language in several > places, > and it is not always clear whether it is just a repetition of the RFC4301 > requirements > or a new requirement imposed by this document. In general, I think it's > better not to include > the existing RFC4301/4303 requirements in the draft or make it absolutely > clear that these are not > new requirements if you need to mention them (adding a reference to a > corresponding section > in the RFCs). > > Another general comment: sections 3-7 discuss how the corresponding ESP > packet fields > can be tweaked to deal with low resource devices. I think that for the > sake of clarity > the suggested measures must be summarized in each of these sections. > Currently > these sections contain quite a lot of discussion and no clear conclusions > what > is OK to do and in what situations. I think document will be more clear if > such > conclusions are put at the end of each section (currently some advises are > spread > over them). > > > Specific comments: > > Section 3. > > When fix SPI are used, > it is RECOMMENDED the constraint node has as many SPI values as ESP > session per host IP address, and that SA lookup includes the IP > addresses. > > This is probably wrong if we take into considerations that SA may be > rekeyed. > Some words should be added either prohibiting rekeying ESP SAs in this case > or discussing that in case of rekey one will consume additional SPI values > for in fact the same SA. > > When used indoor, the privacy information is stored in the encrypted > data and as such does not leak privacy. > > I cannot parse this :-) > > Such packet will not be rejected due to an SPI mismatch, but instead > after the signature check which requires more resource and thus make > DoS more efficient, especially for devices powered by batteries. > > I think this a very good argument against fixed (predictable) SPIs. > In fact, after reading through this section it seems to me that the > conclusion must be - predictable (fixed) SPIs SHOULD NOT be used. > > Values 0-255 SHOULD NOT be used. > > I believe these values MUST NOT be used with IPsec ESP, no? > Why "SHOULD NOT"? The values from this range are reserved > for other protocols utilizing ESP (e.g. SPI (1) was used in SKIP). > > Section 4. > > I see no discussion regarding using ESN. I think there is generally no > point > to use ESN for constrained devices, but it can be useful if clock is used > to generate (E)SN, as suggested in the draft. In this case 64-bit numbers > can make sure that no two packets will be sent with the same ESN > (provided the clock has high resolution). > > Section 5. > > The purpose of padding is to respect the 32 bit alignment of ESP. > > It is not an accurate statement, the padding is also used when encryption > transform requires the input to be a multiple of some number of bytes. > Many modern transforms (based on GCM, CCM, CTR modes) don't have such > a requirement, but some (e.g. based on CBC mode) do have. > > Section 6. > > For interoperability, it is RECOMMENDED a minimal ESP > implementation discards dummy packets. > > I'm puzzled by this sentence. What else can the receiver do with dummy > packets other than discard? RFC4303 leaves him only this option :-) > > > Nits: > Throughout the text: > s/fix SPI/fixed SPI > s/constraint node/constrained node > s/algorythm/algorithm > > Section 2: > > s/IPsec suite protocol/IPsec protocol suite > > Section 3: > > However, for some constraint nodes, generating a random SPI may > consume to much resource, in which case SPI can be generated using > predictable functions or even a fix value. > > s/to/too > > When a constraint node uses fix value for SPIs, it imposes some > limitations on the number of inbound SA. This limitation can be > alleviate by how the SA look up is performed. When fix SPI are used, > it is RECOMMENDED the constraint node has as many SPI values as ESP > session per host IP address, and that SA lookup includes the IP > addresses. > > s/alleviate/alleviated > s/RECOMMENDED the/RECOMMENDED that the > > More specifically, traffic pattern MAY leak sufficient information in > itself. In other words, privacy leakage is a complex and the use of > random SPI is unlikely to be sufficient. > > s/MAY/may > > In addition, > predictable SPI enable an attacker to forge packets with a valid SPI. > > s/enable/enables > > Section 5: > > As a result, TFC cannot not be enabled with minimal, and > communication protection that were relying on TFC will be more > sensitive to traffic shaping. > > s/cannot not/cannot > s/minimal/minimal ESP > s/were relying/rely > > Section 7: > > Currently recommended > [RFC8221] only recommend crypto-suites with an ICV which makes the > ICV a mandatory field. > > s/recommend/recommends > > Section 8: > > The recommended suites to use are expect to evolve over time > and implementer SHOULD follow the recommendations provided by > [RFC8221] and updates. > > s/expect/expected > s/implementer/implementers > > Note that it > is not because a encryption algorithm transform is widely > deployed that is secured. > > s/a/an > > Regards, > Valery Smyslov. > > > --000000000000a75fc50598cc9408 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Valery for the detailed review. That is really m= uch appreciated. We will update the document accordingly by the next few we= eks also considering the feed backs from Scott.=C2=A0=C2=A0

<= div>Yours,=C2=A0
Daniel

On Tue, Dec 3, 2019 at 8:08 AM Valery Smysl= ov <smyslov.ietf@gmail.com= > wrote:
Hi,<= br>
I reviewed draft-ietf-lwig-minimal-esp-00. In general I think that the docu= ment
provides useful guidelines on how ESP can be implemented on constrained
devices.

General comment: the draft uses RFC2119 requirement language in several pla= ces,
and it is not always clear whether it is just a repetition of the RFC4301 r= equirements
or a new requirement imposed by this document. In general, I think it's= better not to include
the existing RFC4301/4303 requirements in the draft or make it absolutely c= lear that these are not
new requirements if you need to mention them (adding a reference to a corre= sponding section
in the RFCs).

Another general comment: sections 3-7 discuss how the corresponding ESP pac= ket fields
can be tweaked to deal with low resource devices. I think that for the sake= of clarity
the suggested measures must be summarized in each of these sections. Curren= tly
these sections contain quite a lot of discussion and no clear conclusions w= hat
is OK to do and in what situations. I think document will be more clear if = such
conclusions are put at the end of each section (currently some advises are = spread
over them).


Specific comments:

Section 3.

=C2=A0 =C2=A0When fix SPI are used,
=C2=A0 =C2=A0it is RECOMMENDED the constraint node has as many SPI values a= s ESP
=C2=A0 =C2=A0session per host IP address, and that SA lookup includes the I= P
=C2=A0 =C2=A0addresses.

This is probably wrong if we take into considerations that SA may be rekeye= d.
Some words should be added either prohibiting rekeying ESP SAs in this case=
or discussing that in case of rekey one will consume additional SPI values<= br> for in fact the same SA.

=C2=A0 =C2=A0When used indoor, the privacy information is stored in the enc= rypted
=C2=A0 =C2=A0data and as such does not leak privacy.

I cannot parse this :-)

=C2=A0 =C2=A0Such packet will not be rejected due to an SPI mismatch, but i= nstead
=C2=A0 =C2=A0after the signature check which requires more resource and thu= s make
=C2=A0 =C2=A0DoS more efficient, especially for devices powered by batterie= s.

I think this a very good argument against fixed (predictable) SPIs.
In fact, after reading through this section it seems to me that the
conclusion must be - predictable (fixed) SPIs SHOULD NOT be used.

=C2=A0 =C2=A0Values 0-255 SHOULD NOT be used.

I believe these values MUST NOT be used with IPsec ESP, no?
Why "SHOULD NOT"? The values from this range are reserved
for other protocols utilizing ESP (e.g. SPI (1) was used in SKIP).

Section 4.

I see no discussion regarding using ESN. I think there is generally no poin= t
to use ESN for constrained devices, but it can be useful if clock is used to generate (E)SN, as suggested in the draft. In this case 64-bit numbers can make sure that no two packets will be sent with the same ESN
(provided the clock has high resolution).

Section 5.

=C2=A0 =C2=A0The purpose of padding is to respect the 32 bit alignment of E= SP.

It is not an accurate statement, the padding is also used when encryption transform requires the input to be a multiple of some number of bytes.
Many modern transforms (based on GCM, CCM, CTR modes) don't have such a requirement, but some (e.g. based on CBC mode) do have.

Section 6.

=C2=A0 =C2=A0For interoperability, it is RECOMMENDED a minimal ESP
=C2=A0 =C2=A0implementation discards dummy packets.=C2=A0

I'm puzzled by this sentence. What else can the receiver do with dummy<= br> packets other than discard? RFC4303 leaves him only this option :-)


Nits:
Throughout the text:
s/fix SPI/fixed SPI
s/constraint node/constrained node
s/algorythm/algorithm

Section 2:

s/IPsec suite protocol/IPsec protocol suite

Section 3:

=C2=A0 =C2=A0However, for some constraint nodes, generating a random SPI ma= y
=C2=A0 =C2=A0consume to much resource, in which case SPI can be generated u= sing
=C2=A0 =C2=A0predictable functions or even a fix value.=C2=A0

s/to/too

=C2=A0 =C2=A0When a constraint node uses fix value for SPIs, it imposes som= e
=C2=A0 =C2=A0limitations on the number of inbound SA.=C2=A0 This limitation= can be
=C2=A0 =C2=A0alleviate by how the SA look up is performed.=C2=A0 When fix S= PI are used,
=C2=A0 =C2=A0it is RECOMMENDED the constraint node has as many SPI values a= s ESP
=C2=A0 =C2=A0session per host IP address, and that SA lookup includes the I= P
=C2=A0 =C2=A0addresses.

s/alleviate/alleviated
s/RECOMMENDED the/RECOMMENDED that the

=C2=A0 =C2=A0More specifically, traffic pattern MAY leak sufficient informa= tion in
=C2=A0 =C2=A0itself.=C2=A0 In other words, privacy leakage is a complex and= the use of
=C2=A0 =C2=A0random SPI is unlikely to be sufficient.

s/MAY/may

=C2=A0 =C2=A0In addition,
=C2=A0 =C2=A0predictable SPI enable an attacker to forge packets with a val= id SPI.

s/enable/enables

Section 5:

=C2=A0 =C2=A0As a result, TFC cannot not be enabled with minimal, and
=C2=A0 =C2=A0communication protection that were relying on TFC will be more=
=C2=A0 =C2=A0sensitive to traffic shaping.=C2=A0

s/cannot not/cannot
s/minimal/minimal ESP
s/were relying/rely

Section 7:

=C2=A0 =C2=A0Currently recommended
=C2=A0 =C2=A0[RFC8221] only recommend crypto-suites with an ICV which makes= the
=C2=A0 =C2=A0ICV a mandatory field.

s/recommend/recommends

Section 8:

=C2=A0 =C2=A0The recommended suites to use are expect to evolve over time =C2=A0 =C2=A0and implementer SHOULD follow the recommendations provided by<= br> =C2=A0 =C2=A0[RFC8221] and updates.

s/expect/expected
s/implementer/implementers

=C2=A0 =C2=A0 =C2=A0 =C2=A0Note that it
=C2=A0 =C2=A0 =C2=A0 =C2=A0is not because a encryption algorithm transform = is widely
=C2=A0 =C2=A0 =C2=A0 =C2=A0deployed that is secured.=C2=A0

s/a/an

Regards,
Valery Smyslov.


--000000000000a75fc50598cc9408-- From nobody Tue Dec 3 10:34:33 2019 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 7E1431201E5 for ; Tue, 3 Dec 2019 10:34:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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 mZl00B8KWzbI for ; Tue, 3 Dec 2019 10:34:30 -0800 (PST) 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 4258412010D for ; Tue, 3 Dec 2019 10:34:30 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 47S9cf4Pn1zF4Y; Tue, 3 Dec 2019 19:34:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1575398066; bh=ApZgO3njPq/wD0Es8Y2lzXJeeSrfbhIJlKj+2agU8Hk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=uREaehFoyClZIkSMGKe9HHsn85+RNC0i6JMHsP5pZ13Gl8Ggrmm/8WczsCsThAqFP 4EPghOBxXJV1R7K5o/BjOzCfGJ5AaZCYuCz4JHP3j62fw1eJML292Hl4s89cI5BHUM aFSJC8cjYB/ExVUpo8zBpgXgLDYohPYu0WXysu4E= 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 gxbZ6InDDjc1; Tue, 3 Dec 2019 19:34:24 +0100 (CET) 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; Tue, 3 Dec 2019 19:34:24 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 91AA960015B8; Tue, 3 Dec 2019 13:34:23 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8DCA3308EB; Tue, 3 Dec 2019 13:34:23 -0500 (EST) Date: Tue, 3 Dec 2019 13:34:23 -0500 (EST) From: Paul Wouters To: Valery Smyslov cc: IPsecME WG In-Reply-To: <036d01d5a5c5$d301f980$7905ec80$@gmail.com> Message-ID: References: <036d01d5a5c5$d301f980$7905ec80$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [IPsec] Alternative Approach for Postquantum Preshared Keys in 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: Tue, 03 Dec 2019 18:34:33 -0000 On Thu, 28 Nov 2019, Valery Smyslov wrote: > some time ago I've posted a new draft "An Alternative Approach for Postquantum Preshared Keys in IKEv2". > AS you all know we have "Postquantum Preshared Keys for IKEv2" (draft-ietf-ipsecme-qr-ikev2) draft > that is already in Publication Requested state. This draft defines a mechanism to achieve PQ security > by means of additional Preshared Key (PPK) that is mixed up in IKE SA keys calculation. > This approach is believed to be a temporary solution until new PK KE primitives are standardized. Yes, PPK is for use with non-PQ algorithms as a stop-gap meassure until we have PQ algorithms/exchanges. But that means ideally that if or when IKE_INTERMEDIATE is used, we are using PQ-safe algorithms and PPK's are not used anymore. We might also end up with something PA-safe that does not require IKE_INTERMEDIATE. > The problem is that in the "Group Key Management using IKEv2" (draft-yeung-g-ikev2), > that is just adopted as a WG document, the responder (Group Controller / Key Server) > transfers session keys to the initiator (Group Member) immediately once IKE SA between > them is created. Obviously, keys are sensitive information and they are not protected > by PPK in this case. The workaround suggested in draft-yeung-g-ikev2-16 is to perform > quite long series of exchanges (consuming more resources) to postpone session > keys transfer until the initial SA is rekeyed. Understood. > The draft "An Alternative Approach for Postquantum Preshared Keys in IKEv2" proposes > an alternative approach for using PPK by utilizing the IKE_INTERMEDIATE exchange, > in which PPK IDs are exchanged. This allows an initial IKE SA to be secure > against QC, that would substantially simplify G-IKEv2 implementation if PQ security > using PPK is needed. Wouldn't this introduce the same bad error handling in IKE_INTERMEDIATE we had in IKEv1 of getting unreadable messages? > This alternative approach can also be used in regular IKEv2. Compared > with draft-ietf-ipsecme-qr-ikev2 it has few advantages and a single > drawback - it requires an additional exchange for IKE SA to set up. That is likely less problematic than the PPK management involved? And presumable this goes away when we have PQ-safe algorithms, so it is only a temporary extra round trip? (still hoping that the new PQ-safe stuff does not require the IKE_INTERMEDIATE exchange :) > However, if IKE_INTERMEDIATE is used for some other (not yet defined) > purposes too, the PPK IDs can be piggybacked and thus having no such penalty > as an extra exchange. But ideally, neither PPK or IKE_INTERMEDIATE would be needed for PQ-safe exchanges :P > Comments, reviews, opinions are very welcome. > Is it worth to adopt this draft as a WG document? There is also another solution to your original problem: require PQ-safe algorithms for Group SA's that need to be PQ-safe and don't use PPKs at all. Since PPK's are a "stop gap" method meant for existing things, and group SA's are still being designed, developed and implemented, by the time the group sa work is done, we might already have PQ-safe exchanges so PPK is no longer needed. I'd be tempted to wait a bit for now before we do too much work that ends up not being needed. I suspect most implementors would wait as well anyway. specific comments on the draft: I don't like returning AUTHENTICATION_FAILED outside of IKE_AUTH as proposed in your document. Since the only thing that could possibly cause that is PPK failure, you might as well return a new error that clearly states that (eg the original IKEv2 assumption to hide presenting too much info by returning AUTHENTICATION_FAILED in many cases does not apply here) If using PPK is optional for the responder, then she returns the empty PPK_IDENTITY notification, thus informing the initiator that the IKE SA can be created only without using PPK. This is a strange concept of "optional" :) Another issue I see is with connection selection and PPK selection. At the IKE_INTERMEDIATE exchange, we don't know yet which connection this will map to, as we haven't seen the AUTH payload nor the IDr payload. So I think you would at the minimum need to also send the IDr payload if you are sending a PPK payload. Or you need to overload or derive this information from the supplied PPK_ID. I feel this might cause operational problems. For computing the IKE SA keys, I would prefer to leave this method as unchanged as possible. Adding PPK mixing into the prf+ differently from the standard one will make the code more complex. Isn't it enough to make the PPK part of SKEYSEED? Why do we need to use this from the additional prf+ calls as well? Paul Paul From nobody Wed Dec 4 00:34:42 2019 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 1BC39120116 for ; Wed, 4 Dec 2019 00:34:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 cQ68w6oZfFwC for ; Wed, 4 Dec 2019 00:34:38 -0800 (PST) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 003DE120111 for ; Wed, 4 Dec 2019 00:34:37 -0800 (PST) Received: by mail-lj1-x22d.google.com with SMTP id u17so7084320lja.4 for ; Wed, 04 Dec 2019 00:34:37 -0800 (PST) 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=Qtbdz2gMxxMeh4CGmxih4hB1lsNJ7CYcUNoSRQyki7I=; b=TGVV0biLPprc9L3hQ8Hgsvm7uk86dxcHt9uT6CgwQDExjnT5ufV9qZAD56hDn1FU7B i3417ukAqN+EQk+UUSXbbc79a6zJQSbRSP/yvwEfivV0H+RRrNHEUxtBe0YCFX6xlQsp zO55li0pcYN/I7aRw4aj7FI1Iuho0QxqcwgxQdZ3zOezDdN4IDn+C9ZUhqV1Vx/WUrjC X0S3Rt6cpwuDEkb7zl52KymaLSamMPXHA2DVxwRuvVefPOyfSFrmXco2gJsTOQi/UR3C Mi+rcKJEuGDS/I8E1VQ//IbcCvQwK6PrfL5d5e5rIVnWmHKIIQMiylZARflOApxvtbhg /p1g== 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=Qtbdz2gMxxMeh4CGmxih4hB1lsNJ7CYcUNoSRQyki7I=; b=tUJo0sA1Tvf41iaKMyI1CKi7FUOZ0sc+9JUPk+hX+w8yg98s5f+LaBYf7l1KDe1gMs 4J3HtfJcHn2CSrZAyiDMwpwQIkur3daHXztsZ5NyTx9ZPyrPxX1blH1rqW//CAGLXXUo 6mjFPGFs81z6zjrpNVMrOWBOlYLrUWJsw/aKMxeizzYzDvWHVFORJIlYRD2dL5+PGWI0 dZeD5XQakAYAL7oUmSiyT3f9dIaZ4Wh0o9nOteYaMOQh+DHJLAujxmgEN/oMFtZqAWX/ RQWk7z5AezfzBG2Vu6vODT+7Led5cZj7Am8a1NpBKlOziSwVs/s8y+Y+m03ifs2RF10V yLYQ== X-Gm-Message-State: APjAAAXeD/17JtR0sFZNpTMX32t20gBbcbYAPKfQtixTKtbgRUBqG51h vzEWqq+Lfj7bDkYXP21TDc9LIojV X-Google-Smtp-Source: APXvYqxckMQImrp9F3EYwMjCp0HIJtLum+suO6COzztNucT42CEECX+6HbjqfPO6V1oPQi7OBP2AMw== X-Received: by 2002:a2e:2418:: with SMTP id k24mr1214295ljk.49.1575448475213; Wed, 04 Dec 2019 00:34:35 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id u3sm2817737lfb.68.2019.12.04.00.34.33 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 04 Dec 2019 00:34:34 -0800 (PST) From: "Valery Smyslov" To: "'Paul Wouters'" Cc: "'IPsecME WG'" References: <036d01d5a5c5$d301f980$7905ec80$@gmail.com> In-Reply-To: Date: Wed, 4 Dec 2019 11:34:36 +0300 Message-ID: <070a01d5aa7d$a9bf7b30$fd3e7190$@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: AQHcnqnRLcHC5nhIUfd7JIBnKEpl9QIGf8whp4te+GA= Content-Language: ru Archived-At: Subject: Re: [IPsec] Alternative Approach for Postquantum Preshared Keys in 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: Wed, 04 Dec 2019 08:34:40 -0000 Hi Paul, thank you for the thorough review. > > some time ago I've posted a new draft "An Alternative Approach for Postquantum Preshared Keys in IKEv2". > > > AS you all know we have "Postquantum Preshared Keys for IKEv2" (draft-ietf-ipsecme-qr-ikev2) draft > > that is already in Publication Requested state. This draft defines a mechanism to achieve PQ security > > by means of additional Preshared Key (PPK) that is mixed up in IKE SA keys calculation. > > This approach is believed to be a temporary solution until new PK KE primitives are standardized. > > Yes, PPK is for use with non-PQ algorithms as a stop-gap meassure until > we have PQ algorithms/exchanges. But that means ideally that if or when > IKE_INTERMEDIATE is used, we are using PQ-safe algorithms and PPK's are > not used anymore. We might also end up with something PA-safe that does > not require IKE_INTERMEDIATE. The IKE_INTERMEDIATE was designed so that it is not tied to PQ document and can be used for other purposes too. Here is the instance of such an application :-) > > The problem is that in the "Group Key Management using IKEv2" (draft-yeung-g-ikev2), > > that is just adopted as a WG document, the responder (Group Controller / Key Server) > > transfers session keys to the initiator (Group Member) immediately once IKE SA between > > them is created. Obviously, keys are sensitive information and they are not protected > > by PPK in this case. The workaround suggested in draft-yeung-g-ikev2-16 is to perform > > quite long series of exchanges (consuming more resources) to postpone session > > keys transfer until the initial SA is rekeyed. > > Understood. > > > The draft "An Alternative Approach for Postquantum Preshared Keys in IKEv2" proposes > > an alternative approach for using PPK by utilizing the IKE_INTERMEDIATE exchange, > > in which PPK IDs are exchanged. This allows an initial IKE SA to be secure > > against QC, that would substantially simplify G-IKEv2 implementation if PQ security > > using PPK is needed. > > Wouldn't this introduce the same bad error handling in IKE_INTERMEDIATE > we had in IKEv1 of getting unreadable messages? The IKE_INTERMEDIATE messages are always encrypted with the keys that don't depend on PPK, so the responder can always decrypt them. The selected PPK is only used to derive the keys for the IKE_AUTH (and thus for IKE SA). So, there is no problem with the IKE_INTERMEDIATE, but if the selected PPK mismatches on the peers, the responder won't be able to decrypt the IKE_AUTH message. I think this issue can be addressed if some notification is included in the responder's IKE_INTERMEDIATE message along with the selected PPK_ID, containing the data that proves the responder knows the PPK it has selected. Something like: prf(PPK,Ni | Nr | SPIi | SPIr) This will allow the initiator to detect PPK mismatch before PPK is used and cancel the exchange. > > This alternative approach can also be used in regular IKEv2. Compared > > with draft-ietf-ipsecme-qr-ikev2 it has few advantages and a single > > drawback - it requires an additional exchange for IKE SA to set up. > > That is likely less problematic than the PPK management involved? And > presumable this goes away when we have PQ-safe algorithms, so it is only > a temporary extra round trip? (still hoping that the new PQ-safe stuff > does not require the IKE_INTERMEDIATE exchange :) Yes, the PPK solution was intended to be a temporary one. However, in Russia we have a saying: "there is no more permanent than temporary" :-) > > However, if IKE_INTERMEDIATE is used for some other (not yet defined) > > purposes too, the PPK IDs can be piggybacked and thus having no such penalty > > as an extra exchange. > > But ideally, neither PPK or IKE_INTERMEDIATE would be needed for PQ-safe exchanges :P In an ideal world - yes. But we all have quite a lot of experience demonstrating us that the real world is far from ideal :-) > > Comments, reviews, opinions are very welcome. > > Is it worth to adopt this draft as a WG document? > > There is also another solution to your original problem: require PQ-safe > algorithms for Group SA's that need to be PQ-safe and don't use PPKs > at all. Since PPK's are a "stop gap" method meant for existing things, > and group SA's are still being designed, developed and implemented, > by the time the group sa work is done, we might already have PQ-safe > exchanges so PPK is no longer needed. My primary motivation was to allow G-IKEv2 to have the same level of security as IKEv2 has. We don't know when PQ-safe primitives are approved (some NIST competitions lasted for years) and we don't yet know the properties of the approved PQ KE primitives. With QSKE draft we try to be prepared, but I really hate to think that the approved KE method will have 100+ Kb public key (like McEliece). Yes, we can handle this case too, but the cost is high. In this circumstances having pretty simple and reliable solution with PPK may still be attractive for some applications, even after PQ methods are approved. > I'd be tempted to wait a bit for now before we do too much work that > ends up not being needed. I suspect most implementors would wait as > well anyway. I don't think the amount of work here is really high. The draft reuses the IKE_INTERMEDIATE and the way the PPK is mixed into key derivation defined in draft-ietf-ipsecme-qr-ikev2. There are not much new stuff. > specific comments on the draft: > > I don't like returning AUTHENTICATION_FAILED outside of IKE_AUTH as > proposed in your document. Since the only thing that could possibly > cause that is PPK failure, you might as well return a new error > that clearly states that (eg the original IKEv2 assumption to hide > presenting too much info by returning AUTHENTICATION_FAILED in many > cases does not apply here) I was thinking about this, and decided not to introduce new notifications. Do you have any specific concerns about AUTHENTICATION_FAILED outside IKE_AUTH? It looks like the natural choice here... The other possibility is to reuse the AUTHORIZATION_FAILED notification, that is in G-IKEv2, or to add a new one. > If using PPK is optional for the responder, then she returns the > empty PPK_IDENTITY notification, thus informing the initiator that > the IKE SA can be created only without using PPK. > > This is a strange concept of "optional" :) Well, the text is confusing, I agree. The context is that the responder doesn't have any of PPKs suggested by the initiator, but using PPK is optional for the responder. that's why it informs the initiator: "I don't have any of suggested PPK, but we may continue without PPK, if you like". I'll add clarification to this text. > Another issue I see is with connection selection and PPK selection. > At the IKE_INTERMEDIATE exchange, we don't know yet which connection > this will map to, as we haven't seen the AUTH payload nor the IDr > payload. So I think you would at the minimum need to also send the > IDr payload if you are sending a PPK payload. Or you need to overload > or derive this information from the supplied PPK_ID. I feel this might > cause operational problems. Well, I'm not sure this is a real issue. If PPKs are fixed, then I see no problem: the responder just selects one of the proposed PPKs and during IKE_AUTH he verifies that the selected PPK is configured for the IDi. If the responder selects a wrong PPK, then it means that there is a misconfiguration and the connection won't be established anyway. Of course, the initiator must only propose the PPK identities that are suitable for the connection being created. Otherwise the following situation may happen. Consider there are two group of users each configured with own PPK (group PPKs). If initiator is a member of both groups and he doesn't know which group the responder belongs to, he may include two PPK identities for the responder to select. If the responder is also a member of both groups, he will select an arbitrary PPK (he owns both). But if due to misconfiguration (or some transient changes in configuration) it happens, that the responder thinks the initiator belongs only to one of this groups (this becomes clear in IKE_AUTH) and he made a wrong guess, the SA won't be set up (but it couldn't be if the responder knew the IDi of initiator when he was selecting PPK). I think it's rather weird situation and is also the result of misconfiguration, however I admit that including IDi would help in this case. The problem may also arise when PPK identity is generated and depends on peer identity (e.g. some OTP cases when each new connection uses new PPK_ID generated using the initiator's identity). Currently these use cases are mostly theoretical ones. Can you come up with more use cases when it is needed? > For computing the IKE SA keys, I would prefer to leave this method as > unchanged as possible. Adding PPK mixing into the prf+ differently > from the standard one will make the code more complex. Isn't it enough > to make the PPK part of SKEYSEED? Why do we need to use this from the > additional prf+ calls as well? I just re-used the way PPK is stirred into the IKE SA keys from draft-ietf-ipsecme-qr-ikev2. Sure, for this draft it's possible to redefine this way and to mix PPK into SKEYSEED, but I'm not sure it's easier to implement (I suppose this draft will be implemented by those vendors who have already implemented draft-ietf-ipsecme-qr-ikev2, so the already implemented mixing functions will be just re-used for all SK_* keys). Thanks, Valery. > Paul From nobody Fri Dec 6 01:46:16 2019 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 8B298120288 for ; Fri, 6 Dec 2019 01:46:15 -0800 (PST) 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_DNSWL_NONE=-0.0001, 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 nUjTigTujSvx for ; Fri, 6 Dec 2019 01:46:14 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 301B9120227 for ; Fri, 6 Dec 2019 01:46:14 -0800 (PST) Received: from stubbs.int.chopps.org (66-227-211-29.dhcp.trcy.mi.charter.com [66.227.211.29]) (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 93ACE600E7; Fri, 6 Dec 2019 09:46:13 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Christian Hopps In-Reply-To: <20191126005425.GR32847@mit.edu> Date: Fri, 6 Dec 2019 04:46:12 -0500 Cc: Christian Hopps , ipsec@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <4CBAA2F6-9489-4E4D-96CE-926D7C976CB4@chopps.org> References: <20191126005425.GR32847@mit.edu> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [IPsec] IPSECME chair transition 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, 06 Dec 2019 09:46:15 -0000 Thanks David! Welcome Yoav! Thanks, Chris. > On Nov 25, 2019, at 7:54 PM, Benjamin Kaduk wrote: > > Hi all, > > Please join me in thanking David Waltermire for his many years of service > as IPSECME co-chair; Dave is stepping down to leave more time for his other > projects. Thank you, Dave! > Taking over from Dave will be Yoav Nir -- welcome Yoav! > > Thanks to you both, > > Ben > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Fri Dec 6 19:05:20 2019 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 3A80F1200C4 for ; Fri, 6 Dec 2019 19:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 0rWy4RTKC8r1 for ; Fri, 6 Dec 2019 19:05:18 -0800 (PST) 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 CE73E1200A3 for ; Fri, 6 Dec 2019 19:05:17 -0800 (PST) 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 xB735AaE023318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 6 Dec 2019 22:05:12 -0500 Date: Fri, 6 Dec 2019 19:05:10 -0800 From: Benjamin Kaduk To: Valery Smyslov Cc: "'Paul Wouters'" , "'IPsecME WG'" Message-ID: <20191207030510.GX13890@kduck.mit.edu> References: <036d01d5a5c5$d301f980$7905ec80$@gmail.com> <070a01d5aa7d$a9bf7b30$fd3e7190$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <070a01d5aa7d$a9bf7b30$fd3e7190$@gmail.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [IPsec] Alternative Approach for Postquantum Preshared Keys in 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: Sat, 07 Dec 2019 03:05:19 -0000 On Wed, Dec 04, 2019 at 11:34:36AM +0300, Valery Smyslov wrote: > > thank you for the thorough review. Seconded! > > Another issue I see is with connection selection and PPK selection. > > At the IKE_INTERMEDIATE exchange, we don't know yet which connection > > this will map to, as we haven't seen the AUTH payload nor the IDr > > payload. So I think you would at the minimum need to also send the > > IDr payload if you are sending a PPK payload. Or you need to overload > > or derive this information from the supplied PPK_ID. I feel this might > > cause operational problems. > > Well, I'm not sure this is a real issue. If PPKs are fixed, then I see no problem: > the responder just selects one of the proposed PPKs and during IKE_AUTH > he verifies that the selected PPK is configured for the IDi. If the responder > selects a wrong PPK, then it means that there is a misconfiguration and > the connection won't be established anyway. > > Of course, the initiator must only propose the PPK identities that are suitable > for the connection being created. Otherwise the following situation may happen. > Consider there are two group of users each configured with own PPK (group PPKs). > If initiator is a member of both groups and he doesn't know which > group the responder belongs to, he may include two PPK identities for the responder > to select. If the responder is also a member of both groups, he will select > an arbitrary PPK (he owns both). But if due to misconfiguration (or some transient > changes in configuration) it happens, that the responder thinks the initiator > belongs only to one of this groups (this becomes clear in IKE_AUTH) and > he made a wrong guess, the SA won't be set up (but it couldn't be if the > responder knew the IDi of initiator when he was selecting PPK). > I think it's rather weird situation and is also the result of misconfiguration, > however I admit that including IDi would help in this case. > > The problem may also arise when PPK identity is generated and depends on peer identity > (e.g. some OTP cases when each new connection uses new PPK_ID generated > using the initiator's identity). Currently these use cases are mostly > theoretical ones. It seems likely that some formal analysis would help shed light on the issues here, if we could find someone interested and able to do the work. I'll see if I can ask around... -Ben From nobody Mon Dec 9 20:58:14 2019 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 92F0512021C for ; Mon, 9 Dec 2019 20:58:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 wpxyO_IucF_5 for ; Mon, 9 Dec 2019 20:58:11 -0800 (PST) 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 D69AD1201DC for ; Mon, 9 Dec 2019 20:58:10 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 47X79V1n4Tz3Ly; Tue, 10 Dec 2019 05:58:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1575953886; bh=Bsir6afxKjUI8sTWPtbqc3PyI5narXZrlcYCP+GJOug=; h=Date:From:To:cc:Subject; b=gL05K5bgt62kCHFqZe2waYnf3yXeXsZIT1PxFWNMM70e9jihfg7BHHyYt9sXbswLa zs/BTSdpKU4t+G872aMZuIpOMYbBCWSjzuVCMnITS2x01PntLQRNhZxeuqVKhN3fla vCZZgXyG6ZeDZFCXP15ueTomhxa1JDcEH4Tba6m8= 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 XHnjW5g6fYBI; Tue, 10 Dec 2019 05:58:04 +0100 (CET) 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; Tue, 10 Dec 2019 05:58:04 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 9309060011A0; Mon, 9 Dec 2019 23:58:03 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8F16323D192; Mon, 9 Dec 2019 23:58:03 -0500 (EST) Date: Mon, 9 Dec 2019 23:58:03 -0500 (EST) From: Paul Wouters To: "ipsec@ietf.org WG" cc: Sahana Prasad Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [IPsec] Labeled IPsec options 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, 10 Dec 2019 04:58:14 -0000 Hi, As agreed at IETF 106, we would write up the options for negotiating Labeled IPsec that we have discussed, with their PROs and CONs, so that the working group can make a final decision. Option 1) TS_IPV4_ADDR_RANGE_SECLABEL and TS_IPV6_ADDR_RANGE_SECLABEL https://tools.ietf.org/html/draft-ietf-ipsecme-labeled-ipsec-00 This option introduced a new Traffic Selector type that is similar to the core IKEv2 RFC S_IPV4_ADDR_RANGE and TS_IPV6_ADDR_RANGE, but also contain a Security Label field PROs: - Early failure during IKE_AUTH when mismatched. No IPsec SA establishes - Does not otherwise change the Traffic Selector processing CONs: - A bit ugly to have sort of duplicate Traffic Selector types - All new TS types in the future would need to get a seclabel and non-seclabel version. Option 2) TS_SECLABEL https://tools.ietf.org/html/draft-ietf-ipsecme-labeled-ipsec-02 PROs: - No copies of TS TYPE's with/without seclabel CONs: - Error handling is less nice. Responder might setup an IPsec SA narrowed to without security label (unsupported TStypes can be ignored according to RFC 7296), and the initiator has to refuse it by sending a Delete SA message (as security labels are typically mandatory) - Changes Traffic Selector processing, as now one is told that if you pick TS_SECLABEL you must also pick a TS_IPV{46}_ADDR_RANGE. Thus updates RFC 7296 with "sub typing" of TS TYPEs. Option 3) Use NOTIFY payloads (not specified in a draft) PROs: - No changes to Traffic Selector code or specification. Easiest to implement. CONs: - Error handling is less nice. Responder might setup an IPsec SA without supporting the NOTIFY, and initiator has to Delete SA it. Option 4) A new payload type like NOTIFY but now we can set Critical Flag (not specified in a draft) PROs: - No changes to Traffic Selector code or specification. Easiest to implement. - Can use payload with Critical Flag, so exchange fails if not configured or supported for security label type payload - Error handling already done as part of standard IKEv2 CONs: - Takes up a new payload number. - Old Implementations might ignore Critical Flag and new payload type and setup IPsec SA without Security Label? New implementations not receiving the new payload type must also send Delete SA to prevent non-label IPsec SA on responder to linger. Please let us know on the list which solution you prefer and why, so we can make a final decision and move on :) Paul & Sahana From nobody Tue Dec 10 18:10:46 2019 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 E65B3120086; Tue, 10 Dec 2019 18:10:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 NzWMuNZcqsSc; Tue, 10 Dec 2019 18:10:43 -0800 (PST) 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 315A1120059; Tue, 10 Dec 2019 18:10:43 -0800 (PST) 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 xBB2AdU9031310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Dec 2019 21:10:41 -0500 Date: Tue, 10 Dec 2019 18:10:39 -0800 From: Benjamin Kaduk To: draft-ietf-ipsecme-qr-ikev2@ietf.org Cc: ipsec@ietf.org Message-ID: <20191211021039.GZ13890@kduck.mit.edu> References: <157602964597.9873.4051369223279728575.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <157602964597.9873.4051369223279728575.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [IPsec] Datatracker State Update Notice: 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, 11 Dec 2019 02:10:45 -0000 It looks like the "reference" column for the registry dind't make it into the -09, but I'm happy to include that change along with the last-call feedback. -Ben On Tue, Dec 10, 2019 at 06:00:45PM -0800, IETF Secretariat wrote: > IESG state changed: > > New State: Last Call Requested > > (The previous state was AD Evaluation::AD Followup) > > > Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ > From nobody Wed Dec 11 06:44:51 2019 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 4346D12008A; Wed, 11 Dec 2019 06:44:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: David Waltermire , ipsecme-chairs@ietf.org, draft-ietf-ipsecme-qr-ikev2@ietf.org, ipsec@ietf.org, david.waltermire@nist.gov, kaduk@mit.edu Content-Transfer-Encoding: 7bit Reply-To: last-call@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <157607548927.11531.316316195814237240.idtracker@ietfa.amsl.com> Date: Wed, 11 Dec 2019 06:44:49 -0800 Archived-At: Subject: [IPsec] Last Call: (Postquantum Preshared Keys for IKEv2) to Proposed Standard 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: Wed, 11 Dec 2019 14:44:49 -0000 The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'Postquantum Preshared Keys for IKEv2' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2019-12-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The possibility of Quantum Computers poses a serious challenge to cryptographic algorithms deployed widely today. 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. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Dec 11 07:55:05 2019 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 4FEC0120BAB; Wed, 11 Dec 2019 07:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=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 xcYXsbdbLQr4; Wed, 11 Dec 2019 07:55:02 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 DD4F3120BDF; Wed, 11 Dec 2019 07:55:01 -0800 (PST) Received: from [10.32.60.122] (76-209-242-70.lightspeed.mtryca.sbcglobal.net [76.209.242.70]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id xBBFsweh035434 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 11 Dec 2019 08:54:59 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 76-209-242-70.lightspeed.mtryca.sbcglobal.net [76.209.242.70] claimed to be [10.32.60.122] From: "Paul Hoffman" To: ipsec@ietf.org Cc: draft-ietf-ipsecme-qr-ikev2@ietf.org Date: Wed, 11 Dec 2019 07:54:59 -0800 X-Mailer: MailMate (1.13.1r5671) Message-ID: In-Reply-To: <157607548927.11531.316316195814237240.idtracker@ietfa.amsl.com> References: <157607548927.11531.316316195814237240.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [IPsec] Last Call: (Postquantum Preshared Keys for IKEv2) to Proposed Standard 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, 11 Dec 2019 15:55:03 -0000 I'm glad to see this document finally make it towards standardization. Just a minor editorial note: capitalizing "Quantum Computers" is incorrect and should be fixed before it goes to the RFC Editor. --Paul Hoffman From nobody Wed Dec 11 08:23:29 2019 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 4CE71120A91; Wed, 11 Dec 2019 08:23:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RCVD_IN_DNSWL_LOW=-0.7, 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=akamai.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 8mGuP54tmKpu; Wed, 11 Dec 2019 08:23:26 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 0B6D6120A45; Wed, 11 Dec 2019 08:23:25 -0800 (PST) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xBBGMPOE018052; Wed, 11 Dec 2019 16:23:25 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=d6aj/2uPodAVFVDAyVcvdpHJ43dTvBYHmEKczIK3AoE=; b=Xt49w+oZRp2DHh35LW1NkOAXOtyAFAZSpuhnT3HHtLyt1gAoQbNh31pkLPIpFgX1PUot OmuNI3GmzRNtNsW+OVNeZYHeP0AydC0TKo+nTn3EfQ/sHrDMlpQHDnQ34zogZca2o+9B tJo6qDuy0lH2Tj3l7Fw8zScFJ+24jeQfY2Tkmblei1v8hXIZkTiiXpZCyGsaF/GWSyMa j6uxvlh8c4omKCYcPvJzQKOy3M8GNrM1uJTXj/osbRAL6WKPVmok6wGxX5qTFXdrfYe4 mVugu2DKTpnzAsPAdplvdoWWYEZz4bMLpNk1hlZ2t41Dp2RmkudMeLU4WBLszuX4ZqKc eg== Received: from prod-mail-ppoint6 (prod-mail-ppoint6.akamai.com [184.51.33.61] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2wts5qt737-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 11 Dec 2019 16:23:25 +0000 Received: from pps.filterd (prod-mail-ppoint6.akamai.com [127.0.0.1]) by prod-mail-ppoint6.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xBBGHi1w012318; Wed, 11 Dec 2019 11:23:23 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint6.akamai.com with ESMTP id 2wr89yd912-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 11 Dec 2019 11:23:23 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 11 Dec 2019 11:23:22 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Wed, 11 Dec 2019 11:23:22 -0500 From: "Salz, Rich" To: "last-call@ietf.org" CC: "ipsec@ietf.org" , "ipsecme-chairs@ietf.org" , "david.waltermire@nist.gov" , "draft-ietf-ipsecme-qr-ikev2@ietf.org" Thread-Topic: Last Call: (Postquantum Preshared Keys for IKEv2) to Proposed Standard Thread-Index: AQHVsDGdEPO2BClUZEya4low1c3Hh6e1HjkA Date: Wed, 11 Dec 2019 16:23:22 +0000 Message-ID: References: <157607548927.11531.316316195814237240.idtracker@ietfa.amsl.com> In-Reply-To: <157607548927.11531.316316195814237240.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.20.0.191208 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.81.220] Content-Type: text/plain; charset="utf-8" Content-ID: <97D8310876328B4D89EF6997087C9AFB@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-12-11_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=794 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1912110137 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-11_04:2019-12-11,2019-12-11 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 impostorscore=0 mlxlogscore=761 malwarescore=0 spamscore=0 mlxscore=0 adultscore=0 suspectscore=0 lowpriorityscore=0 bulkscore=0 phishscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912110137 Archived-At: Subject: Re: [IPsec] Last Call: (Postquantum Preshared Keys for IKEv2) to Proposed Standard 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, 11 Dec 2019 16:23:27 -0000 V2UgYXJlIHNlZWluZyBhIGZsdXJyeSBvZiB0aGVzZSBraW5kIG9mIOKAnHBvc3QgcXVhbnR1bSBw cm90ZWN0aW9u4oCdIHRoaW5ncy4gIFRoaXMgaXMgcHJlbWF0dXJlLiBUaGUgY28tY2hhaXIgb2Yg dGhlIENGUkcsIEtlbm55IFBhdGVyc29uLCBzYWlkIHNvIGF3aGlsZSBiYWNrLg0KDQpBdCBiZXN0 LCB0aGlzIHNob3VsZCBiZSBFWFBFUklNRU5UQUwuDQoNCkkgd291bGQgbGlrZSB0byBzZWUgYW4g SUVTRyBwb2xpY3kgdGhhdCBtYWtlcyBhbGwgZHJhZnRzIG9uIHRoaXMgdG9waWMgYmUgRVhQRVJJ TUVOVEFMLg0KIA0KDQo= From nobody Wed Dec 11 08:36:14 2019 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 3E3F5120C08; Wed, 11 Dec 2019 08:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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=bY3Kpjd+; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=mIuyFoV0 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 VK3MH0E2-7Cg; Wed, 11 Dec 2019 08:36:04 -0800 (PST) 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 42CE7120BF0; Wed, 11 Dec 2019 08:36:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1660; q=dns/txt; s=iport; t=1576082164; x=1577291764; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/ht3NECBw9/Npa0i4s5lnLMiY3fzoJLbb/DZ3wFhYh4=; b=bY3Kpjd+nxnpn5AV6ebHdtsuNtLv4VpqHjnUMDcXaNCk/iEHPHoSYJA7 KDXduqe7NtEs99ysIivHWzQ40C5wMJktwnwdMuQeNh2rwsYKVd48TpaaO H23xkFYet/Oit4gOZbTxXAlzq8O9HB0dVad4JidGiVA9RVfVaBtdsA8yR k=; IronPort-PHdr: =?us-ascii?q?9a23=3Ar1YVdB3MbLurtXIasmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQEkP/Mf7wYjYSF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ChBQCkGfFd/4cNJK1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgX6BS1AFgUQgBAsqCoN5g0YDiwqCX5gGglIDVAkBAQEMAQEtAgE?= =?us-ascii?q?BhEACF4FuJDgTAgMNAQEEAQEBAgEFBG2FNwyFXgEBAQEDEhERDAEBNwELBAI?= =?us-ascii?q?BCBEEAQEDAh8HAgICMBUICAIEAQ0FCBqFRwMuAQKibgKBOIhhdYEygn4BAQW?= =?us-ascii?q?FGhiCFwmBDiiMGBqBQT+BEUeCTD6ESxWCeTKCLI90OZ5CCoIvlhGaQI5Kmjg?= =?us-ascii?q?CBAIEBQIOAQEFgWkigVhwFYMnUBEUjGYMFxWDO4pTdIEojGwBgQ8BAQ?= X-IronPort-AV: E=Sophos;i="5.69,301,1571702400"; d="scan'208";a="680540774" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Dec 2019 16:36:03 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id xBBGa23r026148 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 11 Dec 2019 16:36:03 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 11 Dec 2019 10:36:02 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 11 Dec 2019 10:36:00 -0600 Received: from NAM10-DM6-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.1473.3 via Frontend Transport; Wed, 11 Dec 2019 11:36:00 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EtSNBSCSoXfgUH8JSw6K+T8nlN9NzpZjYr6+Wv8eRh8FFt8ECBwv3AYXqpSTsP70JmVJipuFx81LK0ZkJk++nGqsDlifQ0wEAyQphIIKOOE7MEFs8AcnvtO2x1s84w7RQMa7xeIxz3m/S9X8ufJ9swJK1dD8Qra50k+HVZ4VryaLHFrjT+0XUyIx7TRaUT67CmGH3XFpCDchAZKGvv1rKOhOskMuNRghh+GpeEsSy8qnSXB8lIG2Sln3dP8xg1YrHG+j80Fi0IlDSonAkY8fPUU6uy7BcHWvgaIPgLQjqJ9g3zJA6laoHyIYtPGFlJmZXEVMRMZfhxmWz4Yqm6q5eg== 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=/ht3NECBw9/Npa0i4s5lnLMiY3fzoJLbb/DZ3wFhYh4=; b=X7TG8yurZF7kyiAxkj7fZ6rm2goRQc6xyKZPqYQ2ziHUep5YulgX7A49L48egrtUzW3xFwqQr6k6Jm0SY1ks5igl39YrJDFpT1ZVZ+Hr5JZ3WXSJO03qWxLfmq8e/9u129Hvo3AvPbmdoIdQe7c8VBFSNTy19NyLIwbN8UXqYx9lQb63tegDWeAykQAccWWp68UnABgdJ5gIakZuheBQuPyqxfMNHyQO3bNfUlwQpck71X/DkF6ZGqvQlQNVUWoRIW59k4zlDI6RCzTOMkB74xKlgPvDoZlikB6tERijCQ7XWQZGvGXN/e0ieNMhf4BiG0jNr6uWu9asGGiTaDB8OQ== 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=/ht3NECBw9/Npa0i4s5lnLMiY3fzoJLbb/DZ3wFhYh4=; b=mIuyFoV0b7qgse0EHjN+8jJzDRe8x7SmGnRXwFm/CZQKM2e2pQN4TXxpGeTyD8XNEt4uLAYZpqIiulUdgEOvruLoIbniT5/u7KFtuIaM30Eh7zCONw1NBqxfgP9hmElhpISTzhph2Xd50hRP0HCaLxPt8OvaLNspd16LzjFwfIE= Received: from BN8PR11MB3666.namprd11.prod.outlook.com (20.178.221.19) by BN8PR11MB3537.namprd11.prod.outlook.com (20.178.219.210) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.16; Wed, 11 Dec 2019 16:35:59 +0000 Received: from BN8PR11MB3666.namprd11.prod.outlook.com ([fe80::e197:a6bd:76f6:ac39]) by BN8PR11MB3666.namprd11.prod.outlook.com ([fe80::e197:a6bd:76f6:ac39%7]) with mapi id 15.20.2538.016; Wed, 11 Dec 2019 16:35:59 +0000 From: "Scott Fluhrer (sfluhrer)" To: "Salz, Rich" , "last-call@ietf.org" CC: "ipsec@ietf.org" , "ipsecme-chairs@ietf.org" , "david.waltermire@nist.gov" , "draft-ietf-ipsecme-qr-ikev2@ietf.org" , "kenny.paterson@rhul.ac.uk" Thread-Topic: Last Call: (Postquantum Preshared Keys for IKEv2) to Proposed Standard Thread-Index: AQHVsD/PJNGOoNGV2kyFiFRfMF0PW6e1ICmQ Date: Wed, 11 Dec 2019 16:35:59 +0000 Message-ID: References: <157607548927.11531.316316195814237240.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=sfluhrer@cisco.com; x-originating-ip: [173.38.117.71] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 42a255fc-7463-4862-2c77-08d77e583421 x-ms-traffictypediagnostic: BN8PR11MB3537: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-forefront-prvs: 024847EE92 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(346002)(39860400002)(366004)(396003)(189003)(199004)(13464003)(7696005)(66446008)(6506007)(76116006)(53546011)(66946007)(66476007)(110136005)(316002)(64756008)(66556008)(54906003)(9686003)(33656002)(52536014)(55016002)(2906002)(5660300002)(478600001)(4326008)(81166006)(86362001)(81156014)(8676002)(26005)(71200400001)(186003)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR11MB3537; H:BN8PR11MB3666.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2a1FUUXwL3SGEacsj4mD4kFG0cGbFCTWqG6oakLhZyx9JyPSCm2EXPfjDPmnM6zFaUbY1EgWfWKufo9s3AZ4r3qDa8o/mPRz+Kl0GJx+oeO+urY4W/3f1LdkRgstHIsYQ3ym5ZvXKEXMeFBzgnTms7FGidsUgbGYJIAclIkzUPsy0fnwzdHQvDVAoco3dV1lKqK5FLDoTikrFk2VHVmXFPgXn2zdeNe8bVi09D0uY22FrhFo94mfZCFZFc7a8AyEN1oU71+IX0qOSX4j7QywnIpFF5sqDQGLSnY1/nvvlfSnC6XoPwnCQesIhn2H30e0YvKHgA/Tv5NvRJvHlS8YbGPjtfYkyiuFjCJ9DcfZ8h7eFrxRxq4mbbk7C+TIBHPRcK7xSUsLpIDPR2890gJDX7VEi5YmOpq2DMYEQofoYVNbaVmiJkM5M6L5KJKURVReN9Jg1DmCRUE1GeBlGpfyR0cRImzLT9XFlEOlUaktX5AKYVGdd0I/KIuTHtRDEmZ/ x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 42a255fc-7463-4862-2c77-08d77e583421 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2019 16:35:59.0577 (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: T8QndxcCqiFwopV0GGUb3peJTfVEaS0zKOuMdShlaEGSnFWrpZ1llHmNEFmpx6JLyVYpmDXiJBpupASHaqUwnw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR11MB3537 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [IPsec] Last Call: (Postquantum Preshared Keys for IKEv2) to Proposed Standard 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, 11 Dec 2019 16:36:06 -0000 RGlkIEtlbm55IG1ha2UgdGhpcyBzdGF0ZW1lbnQgaW4gdGhlIGNvbnRleHQgb2YgcG9zdHF1YW50 dW0gY3J5cHRvZ3JhcGh5ICh0aGF0IGlzLCBwdWJsaWMga2V5IGFsZ29yaXRobXMgdGhhdCBhcmUg YmVsaWV2ZWQgdG8gYmUgc2VjdXJlIGV2ZW4gaWYgdGhlIGFkdmVyc2FyeSBoYXMgYSBxdWFudHVt IGNvbXB1dGVyKT8NCg0KVGhhdCB3b3VsZCBjZXJ0YWlubHkgYmUgYSByZWFzb25hYmxlIHN0YXRl bWVudCAoYXMgbW9zdCBwb3N0cXVhbnR1bSBhbGdvcml0aG1zIGFyZSBmYWlybHkgbmV3LCBhbmQg YXJlIHN0aWxsIGJlaW5nIGNyeXB0b2dyYXBoaWNhbGx5IHZldHRlZCkuDQoNCk9uIHRoZSBvdGhl ciBoYW5kLCB0aGlzIHNwZWNpZmljIGRyYWZ0IGRvZXNuJ3QgaW52b2x2ZSBhbnkgcG9zdHF1YW50 dW0gYWxnb3JpdGhtczsgaXQgcmVsaWVzIG9ubHkgb24gY3VycmVudGx5IGFjY2VwdGVkIGFsZ29y aXRobXMsIGFuZCBzbyBLZW5ueSdzIGNhdXRpb24gd291bGQgbm90IGFwcGx5Lg0KDQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFNhbHosIFJpY2ggPHJzYWx6QGFrYW1haS5j b20+DQo+IFNlbnQ6IFdlZG5lc2RheSwgRGVjZW1iZXIgMTEsIDIwMTkgMTE6MjMgQU0NCj4gVG86 IGxhc3QtY2FsbEBpZXRmLm9yZw0KPiBDYzogaXBzZWNAaWV0Zi5vcmc7IGlwc2VjbWUtY2hhaXJz QGlldGYub3JnOyBkYXZpZC53YWx0ZXJtaXJlQG5pc3QuZ292Ow0KPiBkcmFmdC1pZXRmLWlwc2Vj bWUtcXItaWtldjJAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IExhc3QgQ2FsbDogPGRyYWZ0LWll dGYtaXBzZWNtZS1xci1pa2V2Mi0wOS50eHQ+IChQb3N0cXVhbnR1bQ0KPiBQcmVzaGFyZWQgS2V5 cyBmb3IgSUtFdjIpIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+IA0KPiBXZSBhcmUgc2VlaW5nIGEg Zmx1cnJ5IG9mIHRoZXNlIGtpbmQgb2Yg4oCccG9zdCBxdWFudHVtIHByb3RlY3Rpb27igJ0gdGhp bmdzLg0KPiBUaGlzIGlzIHByZW1hdHVyZS4gVGhlIGNvLWNoYWlyIG9mIHRoZSBDRlJHLCBLZW5u eSBQYXRlcnNvbiwgc2FpZCBzbyBhd2hpbGUNCj4gYmFjay4NCj4gDQo+IEF0IGJlc3QsIHRoaXMg c2hvdWxkIGJlIEVYUEVSSU1FTlRBTC4NCj4gDQo+IEkgd291bGQgbGlrZSB0byBzZWUgYW4gSUVT RyBwb2xpY3kgdGhhdCBtYWtlcyBhbGwgZHJhZnRzIG9uIHRoaXMgdG9waWMgYmUNCj4gRVhQRVJJ TUVOVEFMLg0KPiANCg0K From nobody Wed Dec 11 08:40:46 2019 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 35BE21208F3; Wed, 11 Dec 2019 08:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, 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=akamai.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 TjOfSAUn9LQ0; Wed, 11 Dec 2019 08:40:42 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 4A2A81208D9; Wed, 11 Dec 2019 08:40:42 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id xBBGcQPV003424; Wed, 11 Dec 2019 16:40:39 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=s3pRte9wnEQbg3imhUq45OUFEu50KvveDvYkWjv3UHE=; b=nNQZkFHVa+fOwSvpcTArDOA8C1U+X9ChA+rihK6/p4l9kay8ihoFxqUJIiEsO3mDe/EB 0jaEWJWL+PAZqDR7qBgrHbkftmNQY55hhLUe2bQpl4W2k/RcXpPSg6vc9ncUJvul3fXk ZOkMF83PqOVN0Xeg4mkmG8Kaqk6xh1Sx+BCQedeEnlGqhFTUNpThlvhMHFPQqUWORzh/ A83hCoeP/9gWhN0kCju/QFokP21m8UlpC81byGiL+1V7d9bXLN4ARVXxDS+TBv5YzxOY DI3IvT7nf1NNdu8wpNWfRQucFnRpAj7QcxIbDE7dtZqEDwv6PgtXPVt/HLFSjO0f1Cie Xw== Received: from prod-mail-ppoint3 (prod-mail-ppoint3.akamai.com [96.6.114.86] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2wr5ce2fah-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 11 Dec 2019 16:40:39 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xBBGWHla006152; Wed, 11 Dec 2019 11:40:38 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint3.akamai.com with ESMTP id 2wr8a39wdy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 11 Dec 2019 11:40:38 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 11 Dec 2019 11:40:37 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Wed, 11 Dec 2019 11:40:37 -0500 From: "Salz, Rich" To: "Scott Fluhrer (sfluhrer)" , "last-call@ietf.org" CC: "ipsec@ietf.org" , "ipsecme-chairs@ietf.org" , "david.waltermire@nist.gov" , "draft-ietf-ipsecme-qr-ikev2@ietf.org" , "kenny.paterson@rhul.ac.uk" Thread-Topic: Last Call: (Postquantum Preshared Keys for IKEv2) to Proposed Standard Thread-Index: AQHVsDGdEPO2BClUZEya4low1c3Hh6e1HjkAgABXWID//613gA== Date: Wed, 11 Dec 2019 16:40:36 +0000 Message-ID: References: <157607548927.11531.316316195814237240.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.20.0.191208 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.81.220] Content-Type: text/plain; charset="utf-8" Content-ID: <74A4207337085B4084CBF046F017948E@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-12-11_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=681 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1912110139 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-11_04:2019-12-11,2019-12-11 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 clxscore=1011 malwarescore=0 mlxlogscore=654 phishscore=0 bulkscore=0 suspectscore=0 adultscore=0 spamscore=0 lowpriorityscore=0 priorityscore=1501 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912110140 Archived-At: Subject: Re: [IPsec] Last Call: (Postquantum Preshared Keys for IKEv2) to Proposed Standard 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, 11 Dec 2019 16:40:44 -0000 U2xpZGVzOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvOTkvbWF0ZXJpYWxz L3NsaWRlcy05OS1zYWFnLXBvc3QtcXVhbnR1bS1jcnlwdG9ncmFwaHkNCg0KVmlkZW86IGh0dHBz Oi8vd3d3LnlvdXR1YmUuY29tL3dhdGNoP3Y9YWJtZDFuNVdVdmMmdD0xNDUxcyANCg0KDQrvu79P biAxMi8xMS8xOSwgMTE6MzYgQU0sICJTY290dCBGbHVocmVyIChzZmx1aHJlcikiIDxzZmx1aHJl ckBjaXNjby5jb20+IHdyb3RlOg0KDQogICAgRGlkIEtlbm55IG1ha2UgdGhpcyBzdGF0ZW1lbnQg aW4gdGhlIGNvbnRleHQgb2YgcG9zdHF1YW50dW0gY3J5cHRvZ3JhcGh5ICh0aGF0IGlzLCBwdWJs aWMga2V5IGFsZ29yaXRobXMgdGhhdCBhcmUgYmVsaWV2ZWQgdG8gYmUgc2VjdXJlIGV2ZW4gaWYg dGhlIGFkdmVyc2FyeSBoYXMgYSBxdWFudHVtIGNvbXB1dGVyKT8NCiAgICANCiAgICBUaGF0IHdv dWxkIGNlcnRhaW5seSBiZSBhIHJlYXNvbmFibGUgc3RhdGVtZW50IChhcyBtb3N0IHBvc3RxdWFu dHVtIGFsZ29yaXRobXMgYXJlIGZhaXJseSBuZXcsIGFuZCBhcmUgc3RpbGwgYmVpbmcgY3J5cHRv Z3JhcGhpY2FsbHkgdmV0dGVkKS4NCiAgICANCiAgICBPbiB0aGUgb3RoZXIgaGFuZCwgdGhpcyBz cGVjaWZpYyBkcmFmdCBkb2Vzbid0IGludm9sdmUgYW55IHBvc3RxdWFudHVtIGFsZ29yaXRobXM7 IGl0IHJlbGllcyBvbmx5IG9uIGN1cnJlbnRseSBhY2NlcHRlZCBhbGdvcml0aG1zLCBhbmQgc28g S2VubnkncyBjYXV0aW9uIHdvdWxkIG5vdCBhcHBseS4NCiAgICANCiAgICA+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQogICAgPiBGcm9tOiBTYWx6LCBSaWNoIDxyc2FsekBha2FtYWkuY29t Pg0KICAgID4gU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciAxMSwgMjAxOSAxMToyMyBBTQ0KICAg ID4gVG86IGxhc3QtY2FsbEBpZXRmLm9yZw0KICAgID4gQ2M6IGlwc2VjQGlldGYub3JnOyBpcHNl Y21lLWNoYWlyc0BpZXRmLm9yZzsgZGF2aWQud2FsdGVybWlyZUBuaXN0LmdvdjsNCiAgICA+IGRy YWZ0LWlldGYtaXBzZWNtZS1xci1pa2V2MkBpZXRmLm9yZw0KICAgID4gU3ViamVjdDogUmU6IExh c3QgQ2FsbDogPGRyYWZ0LWlldGYtaXBzZWNtZS1xci1pa2V2Mi0wOS50eHQ+IChQb3N0cXVhbnR1 bQ0KICAgID4gUHJlc2hhcmVkIEtleXMgZm9yIElLRXYyKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0K ICAgID4gDQogICAgPiBXZSBhcmUgc2VlaW5nIGEgZmx1cnJ5IG9mIHRoZXNlIGtpbmQgb2Yg4oCc cG9zdCBxdWFudHVtIHByb3RlY3Rpb27igJ0gdGhpbmdzLg0KICAgID4gVGhpcyBpcyBwcmVtYXR1 cmUuIFRoZSBjby1jaGFpciBvZiB0aGUgQ0ZSRywgS2VubnkgUGF0ZXJzb24sIHNhaWQgc28gYXdo aWxlDQogICAgPiBiYWNrLg0KICAgID4gDQogICAgPiBBdCBiZXN0LCB0aGlzIHNob3VsZCBiZSBF WFBFUklNRU5UQUwuDQogICAgPiANCiAgICA+IEkgd291bGQgbGlrZSB0byBzZWUgYW4gSUVTRyBw b2xpY3kgdGhhdCBtYWtlcyBhbGwgZHJhZnRzIG9uIHRoaXMgdG9waWMgYmUNCiAgICA+IEVYUEVS SU1FTlRBTC4NCiAgICA+IA0KICAgIA0KICAgIA0KDQo= From nobody Wed Dec 11 10:00:06 2019 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 2499A120088; Wed, 11 Dec 2019 09:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RCVD_IN_DNSWL_HI=-5, 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=jHrw3ZnG; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=L8p/iF78 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 WEPUr84pSFYR; Wed, 11 Dec 2019 09:59:56 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1216A1200B9; Wed, 11 Dec 2019 09:59:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6838; q=dns/txt; s=iport; t=1576087196; x=1577296796; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=iD5ciUoFs687kut/4w8HAxBa/tNLjNVRTjSoQ4psy4s=; b=jHrw3ZnGgLsX8D3ue65kWePCrC3IUvRckBNmAAes/6FpdsQCnp79Oo5v jZKxXQbo8B+xGcRnY3gm521w7q0aTAUEERKRPUtA6tpQVf1gqYwW4LVSj 0vHjNlhpSSxcnXZPe6UojJyFzjYeqy8iG+YNJRU+LDeURgew9tJVtEZ+x U=; X-Files: smime.p7s : 3012 IronPort-PHdr: =?us-ascii?q?9a23=3ATNNC0xfZdcZF87vKhg5acRdNlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwKYD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/aic1BsldfFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdAQD2LfFd/5tdJa1lGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYF+gUtQBWwrLSAECyoKg3mDRgOLCk6CEZgGglI?= =?us-ascii?q?DVAIHAQEBCQMBASUIAgEBhEACggUkOBMCAw0BAQQBAQECAQUEbYU3DIVeAQE?= =?us-ascii?q?BAQIBEhEdAQE3AQQHBAIBCBEEAQEBIwcCAgIwHQgCBA4FDhSDAAGCRgMOEQ8?= =?us-ascii?q?BDqMSAoE4iGF1gTKCfgEBBYE5A4NZGIIQBwMGgTaBU4kCgUMaggCBEScggkw?= =?us-ascii?q?+gmQCAgEZgV6CeTKCLI90nnsKgi+DVYI2gRmOUhuaQJcTkW8CBAIEBQIOAQE?= =?us-ascii?q?FgWkigVhwFWUBgkFQERSMZgwXFYM7hRSFP3SBKIxsAYEPAQE?= X-IronPort-AV: E=Sophos;i="5.69,302,1571702400"; d="p7s'?scan'208";a="391096378" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Dec 2019 17:59:55 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id xBBHxsX3016385 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 11 Dec 2019 17:59:55 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 11 Dec 2019 11:59:54 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 11 Dec 2019 11:59:53 -0600 Received: from NAM02-BL2-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.1473.3 via Frontend Transport; Wed, 11 Dec 2019 12:59:53 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Xr5w5zO0uhfEwUCPANm4RscB/u0m0sMqMfW7eVtRHtQb77kz2RPT7T2j7ufrTwgyDKgCUvumXEu6+DCCePw6Yxvnx8ndD5uQKcXNNxf9+x6CqtopoCsmhUPOORjLSNaItbsy7Qa0RVADOEiwQXgDoqjCgT9VZM28+C0LxY4TSpJuE8NeJ1Emt8R0Y9HVanG6x/FjfF5vkjC3q+9Byp86qJMwfh1TW/5rpl96hc4a5btnAgtENgzbNbfU2HPSk+MzD/dNaxNzkuS6HmupslGNJX7Ix9wh8+LkBQq3j26YqNlK/lJOkx2nIhANK3+y+aR5OqrjNnpWr53sKwR0mOZVgg== 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=4BGzHgI8e48pINngwvu69yPHgQ4ehME8yO3Z/Kt3Sz4=; b=bw2cGfuGb3GKoSCbLHt0VkIvA561MwEQ5tgois4acpCKnmnntVB/58Jj85vr3kHtV+qzE5SmHNjqFgUbR0U8OXwNZG0xPVqpW0ZnZruIIOz7MhaXPAuVehWQJv6OUlxLVHQ7Zeuqisi/t0jNMunkk/sRZEi8vYZrXZvTH/kS/VvCffm+CwRjIP1mssD4pNz8WBXuBqsuOIpbCCE/vbiCJQipYOrS41tJrjtES2Qcmr03lrrNgGO7iXz59ddZd5dIjHsDesXVwHo5W2eIzWQWS5NIiqOD0WtOK5jzAIMHa0CmK8Jo1G1C2MDnvgACtet8S1UcXvFE7Xve/hLADzhs1Q== 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=4BGzHgI8e48pINngwvu69yPHgQ4ehME8yO3Z/Kt3Sz4=; b=L8p/iF78L1T17RGYYxaMde9GR7Mg7ViA/4punF/sIo2l5f7tG+DFTmQleM6QYlbTJqXt/xkGngkBl3J+uYvi7ftuTSDkrwXJIqlp1bRTd8kfgItjklNP9X/XS3j2gWmWf7tSd6WMwnpwW0eP70XYPuZeoiegliCnu0OuF+d4QrM= Received: from MWHPR11MB0079.namprd11.prod.outlook.com (10.164.204.138) by MWHPR11MB1710.namprd11.prod.outlook.com (10.169.235.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.13; Wed, 11 Dec 2019 17:59:52 +0000 Received: from MWHPR11MB0079.namprd11.prod.outlook.com ([fe80::d849:db34:3479:6d3e]) by MWHPR11MB0079.namprd11.prod.outlook.com ([fe80::d849:db34:3479:6d3e%7]) with mapi id 15.20.2516.018; Wed, 11 Dec 2019 17:59:51 +0000 From: "David McGrew (mcgrew)" To: "Salz, Rich" CC: "Scott Fluhrer (sfluhrer)" , "last-call@ietf.org" , "ipsec@ietf.org" , "ipsecme-chairs@ietf.org" , "david.waltermire@nist.gov" , "draft-ietf-ipsecme-qr-ikev2@ietf.org" , Kenny Paterson Thread-Topic: Last Call: (Postquantum Preshared Keys for IKEv2) to Proposed Standard Thread-Index: AQHVsDGfAoxccpvdWECBsX/5DhLMP6e1HjkAgABXWID//613gIAAFhyA Date: Wed, 11 Dec 2019 17:59:51 +0000 Message-ID: <1601E041-8E1A-49CE-BB0D-3DA9A3EA8CA9@cisco.com> References: <157607548927.11531.316316195814237240.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mcgrew@cisco.com; x-originating-ip: [173.38.117.69] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 06602070-131d-4f5e-b8a1-08d77e63ebcd x-ms-traffictypediagnostic: MWHPR11MB1710: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 024847EE92 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(376002)(39860400002)(366004)(346002)(13464003)(189003)(199004)(316002)(26005)(66476007)(6506007)(53546011)(5660300002)(66556008)(6916009)(64756008)(36756003)(66946007)(186003)(91956017)(66616009)(66446008)(4326008)(86362001)(76116006)(2616005)(8676002)(71200400001)(478600001)(8936002)(81166006)(6512007)(81156014)(33656002)(6486002)(2906002)(966005)(54906003); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR11MB1710; H:MWHPR11MB0079.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: lGQhMlj2MQ/4suMQVL7faxkeQP+bQVR9O7F3etj4ZxC/90P9yavGJlnuVQxF9LP/weY4BgiSmI3q/fVz8vGHGcORwMUZNArBrNmBenarrQC04yshJaqRY3rXC/0vid/HPECO9/6h7toI9k5BLJaBnHfi0YUGtXpoGlR+TRvtKvRr2w1i9Xfa1dQmYGUX9y2eMOdhid9Byuahm7Rh9t5RZv+aWzp8jdGdkKU0YvaWZsOvb1RAKfM4FsI39kWXFhXTZ02wyWdVlB7n8fvFTPVrtZ1Cmkv6HDp+7stXmen2f/PSFyMx/c4uWjxNrZDOfm2TzWhSR/0WXRnPoBrX2osW34Xg4aAKYBYvkKJWqFBR03h+ru3Su0y44jOp6jEfjqFWUbAvi/oVlN6bbYNsaXbqJVX4E3qestKyHFGWh6t+0cXUXLf6Qe1aXLld7jqFX/5k4wM0q4XVOc81hLb7sojm9k/ZYLe7keYV5lOQACAXJk8RpxZaA6VkuKB7d6kl0AKNSkBMzjUgOBeWWzIWp402e6UublF6KLdbIesm1M5ky2Y= Content-Type: multipart/signed; boundary="Apple-Mail=_5C448BD0-908E-4594-801D-30F46539B825"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 06602070-131d-4f5e-b8a1-08d77e63ebcd X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2019 17:59:51.6825 (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: Mo/qrEuCgEIyYG1CcuHZFL+zcsm+ph4pV69UtIgRZX9ovYkeGpgP7RLETw0eLoe/o+6ny4xy+S4iS0uJlJ46jw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1710 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [IPsec] Last Call: (Postquantum Preshared Keys for IKEv2) to Proposed Standard 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, 11 Dec 2019 17:59:59 -0000 --Apple-Mail=_5C448BD0-908E-4594-801D-30F46539B825 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Rich, I strongly disagree with your statement that =E2=80=9Cthis is = premature=E2=80=9D, and the slides that you cite do not support that = claim. I totally agree with the points in Kenny=E2=80=99s slides, = especially as they pertain to QKD and SDO-shopping, but they say nothing = about improvements to security protocols that use quantum-resistant = *symmetric* cryptography. The Postquantum Preshared Keys for IKEv2 = specification is a sound and mature specification that uses existing = crypto algorithms with parameters that are widely believed to be post = quantum secure.=20 David > On Dec 11, 2019, at 11:40 AM, Salz, Rich wrote: >=20 > Slides: = https://datatracker.ietf.org/meeting/99/materials/slides-99-saag-post-quan= tum-cryptography >=20 > Video: https://www.youtube.com/watch?v=3Dabmd1n5WUvc&t=3D1451s=20 >=20 >=20 > =EF=BB=BFOn 12/11/19, 11:36 AM, "Scott Fluhrer (sfluhrer)" = wrote: >=20 > Did Kenny make this statement in the context of postquantum = cryptography (that is, public key algorithms that are believed to be = secure even if the adversary has a quantum computer)? >=20 > That would certainly be a reasonable statement (as most postquantum = algorithms are fairly new, and are still being cryptographically = vetted). >=20 > On the other hand, this specific draft doesn't involve any = postquantum algorithms; it relies only on currently accepted algorithms, = and so Kenny's caution would not apply. >=20 >> -----Original Message----- >> From: Salz, Rich >> Sent: Wednesday, December 11, 2019 11:23 AM >> To: last-call@ietf.org >> Cc: ipsec@ietf.org; ipsecme-chairs@ietf.org; = david.waltermire@nist.gov; >> draft-ietf-ipsecme-qr-ikev2@ietf.org >> Subject: Re: Last Call: = (Postquantum >> Preshared Keys for IKEv2) to Proposed Standard >>=20 >> We are seeing a flurry of these kind of =E2=80=9Cpost quantum = protection=E2=80=9D things. >> This is premature. The co-chair of the CFRG, Kenny Paterson, said so = awhile >> back. >>=20 >> At best, this should be EXPERIMENTAL. >>=20 >> I would like to see an IESG policy that makes all drafts on this = topic be >> EXPERIMENTAL. >>=20 >=20 >=20 >=20 --Apple-Mail=_5C448BD0-908E-4594-801D-30F46539B825 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCRgw ggRuMIIDVqADAgECAgphEIBtAAAAAAAOMA0GCSqGSIb3DQEBBQUAMDUxFjAUBgNVBAoTDUNpc2Nv IFN5c3RlbXMxGzAZBgNVBAMTEkNpc2NvIFJvb3QgQ0EgMjA0ODAeFw0xNDA0MDQyMDI0MThaFw0y OTA1MTQyMDI1NDJaMCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBD QTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMrffhZMUxX7I1bNxrllCgSV5d5MRWeM DMcG4KsfbV83Knvn7aOtgH8RyPOC6+6fUNnJvz2hL7s8EQc177il2VFO2bD3U6CUgCwskmWtEG+h hmtfQAqZpVBEGpBNz+ZM+0YGjUjjB9fhrWPX1egnABW/bgeyQ7tlBi999lldmxLFLH2960SwUuHC /B7tnVn3HZOnqzGmQkI5J9OBYsZULCaM2z0U0KiOFeoopBv+vaw8nk3W1UyvjMv/S58FbA9xgTIk Ye0Zq77qcbRojLvI9OSLP3dTon4VnnML41d0XoPS6JPGzDSRDAKXndcHk3VUtF+DLAIXqLCQZXfZ UuTuIncCAwEAAaOCAYcwggGDMBAGCSsGAQQBgjcVAQQDAgEAMB0GA1UdDgQWBBSflTa0jl3VS8MK wacpk0NRBv2JUTAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTALBgNVHQ8EBAMCAYYwEgYDVR0T AQH/BAgwBgEB/wIBADAfBgNVHSMEGDAWgBQn88gVHm6aAgkWrSugiWBf2nsvqjBDBgNVHR8EPDA6 MDigNqA0hjJodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY3JsL2NyY2EyMDQ4LmNy bDBQBggrBgEFBQcBAQREMEIwQAYIKwYBBQUHMAKGNGh0dHA6Ly93d3cuY2lzY28uY29tL3NlY3Vy aXR5L3BraS9jZXJ0cy9jcmNhMjA0OC5jZXIwXAYDVR0gBFUwUzBRBgorBgEEAQkVARUAMEMwQQYI KwYBBQUHAgEWNWh0dHA6Ly93d3cuY2lzY28uY29tL3NlY3VyaXR5L3BraS9wb2xpY2llcy9pbmRl eC5odG1sMA0GCSqGSIb3DQEBBQUAA4IBAQA+Tr4jGkYCjV5r24oCNAtjm+UBPCZdjHCyJOtgXuyK hGQuG1kVo2ca4Rbj/eBNfUSaIyjS7bb3oh/nRM3tbeqGIVQorGxhvPvIZVAEQIoqi/yfbhie9cU+ paKpHACucaYXu0kyS0pYE5NMNun3Lw3ogOs4XVR5yoVSpKTiVnfTDQchTpwkMgzivqXDcS1OiDfU 8C9WaEZHRWtdUIgl9zoppPGIQa1TflcxhirW4GeH2FOrgaN1d77bIcg6R7RpJ9Xu3/f01nGNunrR cy993c2meJQoZcOJd15C6ugHwhAxeXY6QXYgkY8KQVCCGwkpshEgbwPrC+I/Itb6P7hGq7awMIIE ojCCA4qgAwIBAgIKAYYU3Q/9eGQDMzANBgkqhkiG9w0BAQsFADAsMQ4wDAYDVQQKEwVDaXNjbzEa MBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwHhcNMTkwNDIyMTIzODM0WhcNMjEwNDIxMTI0ODM0 WjCBlzEeMBwGA1UEAxMVRGF2aWQgTWNHcmV3IChtY2dyZXcpMRQwEgYDVQQLEwtDaXNjbyBVc2Vy czESMBAGA1UECxMJRW1wbG95ZWVzMRMwEQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQB GRMFY2lzY28xHzAdBgkqhkiG9w0BCQEMEG1jZ3Jld0BjaXNjby5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCoSLZirLsy97KtylIrycv21gMzgpcc3zahqrPFUEX7nDXMNc7j5sKP dufKb60g6mPtrgJWqlu2mu4S04JRgrQ/rH+roMwtuKlWUEHzyJbuH0x+kfp7pFGOr1ywMsPvMa68 8RoVdP/r0+hJyJJkajSbnbYX2B3ADRUX0/+en7zAtAm78IZIiHrj0dR+PeeobyIFg8MHh3qITTpl ok/9HD6KakvZ4oKiPIOF25ifxdx/dUjj9VNEHu9q/q3yu4v5tGeW3meBGTBBdAwW4RdE+a0uzZgP J4xXo7YKj6SGX0wrKhKM3tw9aONlNUmlM7bFH+lelB52IlTlnKoSSS3AGWzlAgMBAAGjggFYMIIB VDAOBgNVHQ8BAf8EBAMCBPAwDAYDVR0TAQH/BAIwADB6BggrBgEFBQcBAQRuMGwwPAYIKwYBBQUH MAKGMGh0dHA6Ly93d3cuY2lzY28uY29tL3NlY3VyaXR5L3BraS9jZXJ0cy9jZWNhLmNlcjAsBggr BgEFBQcwAYYgaHR0cDovL3BraWN2cy5jaXNjby5jb20vcGtpL29jc3AwHwYDVR0jBBgwFoAUn5U2 tI5d1UvDCsGnKZNDUQb9iVEwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2Npc2NvY2VydHMuY2lz Y28uY29tL2ZpbGUvY2VjYS5jcmwwGwYDVR0RBBQwEoEQbWNncmV3QGNpc2NvLmNvbTAdBgNVHQ4E FgQUJdhyCus9Dtak+dWE6OMQL3tyEFcwHwYDVR0lBBgwFgYKKwYBBAGCNwoDDAYIKwYBBQUHAwQw DQYJKoZIhvcNAQELBQADggEBABX3vrR/z95R931ACHm3fjMQEg5I5FV6lULEFqcXFa6XzVA576Q3 FxT9c9gk4Pv+opDDWaSbUjiZp+DItlfNqiNWvA6+gy1M3MY/x6BKbVSGdqoAELCM9ED65F/e56aQ M0915+3AIDjWX+Gi6lTbp1+Kb8g2yUgMcG9bpzN9XDLZ1Vvz/N++1OnCzbLzd49UEtQVDes9t+WJ v7tGM3O8XS/Kzj1BDKrPzmEDple4aiaTCoarcgSufCROLewjBREt2Mngg6+w8i+k9X2MQlQzJbzs +DMZZvZk4lqMcE4lu5TbKChsLQixICwHgKFrSobzu0xJLLfyJBCGszyRRaeujtcxggJqMIICZgIB ATA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYU3Q/9 eGQDMzANBglghkgBZQMEAgEFAKCCAQEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTkxMjExMTc1OTQzWjAvBgkqhkiG9w0BCQQxIgQgA2nFwHX7O8Bo06ifJY8sjCfi Z2QGzJVYZ2H9qCpGEAgwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgGA1UE AxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGFN0P/XhkAzMwSwYLKoZIhvcNAQkQAgsxPKA6MCwxDjAM BgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYU3Q/9eGQDMzANBgkq hkiG9w0BAQEFAASCAQAfzh/pXaU8C+2U0bQD3JzQo05zAHas905yGe/apj3cWlEWD7/dOYRpUDoO FQRShnOO9ximsV6PlmU/062POJOdjsW8cW048fb3l+VCu07K8BrTRzqSesWdCjrBU/TWGlbCmeKz QIoFVt2watEb5u+8/TRad9FZT7tWB/+PMIif7TWigda+vJIfjSTIjGiSw6XBWhNllbDe9axaLFyR 741aObr5E0uhI7jZ8O06lPcCPrF/8FqB9aSaPnR+ZbM9QNFuPxN4s1kFkCHb+InX6QNqevAKNGBl MflzlJQlkWPWJFBHAZlUtZ2ySLQPhhWDPAwhCfOC43Nooupiwp1aivagAAAAAAAA --Apple-Mail=_5C448BD0-908E-4594-801D-30F46539B825-- From nobody Wed Dec 11 10:03:53 2019 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 B33A2120088; Wed, 11 Dec 2019 10:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=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 0NNKSydY7gHl; Wed, 11 Dec 2019 10:03:52 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 1E97712002E; Wed, 11 Dec 2019 10:03:52 -0800 (PST) Received: from [10.32.60.122] (76-209-242-70.lightspeed.mtryca.sbcglobal.net [76.209.242.70]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id xBBI3lXe044749 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 11 Dec 2019 11:03:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 76-209-242-70.lightspeed.mtryca.sbcglobal.net [76.209.242.70] claimed to be [10.32.60.122] From: "Paul Hoffman" To: "Salz, Rich" Cc: last-call@ietf.org, ipsec@ietf.org, "Kenny Paterson" Date: Wed, 11 Dec 2019 10:03:47 -0800 X-Mailer: MailMate (1.13.1r5671) Message-ID: In-Reply-To: References: <157607548927.11531.316316195814237240.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [IPsec] [Last-Call] Last Call: (Postquantum Preshared Keys for IKEv2) to Proposed Standard 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, 11 Dec 2019 18:03:53 -0000 On 11 Dec 2019, at 8:23, Salz, Rich wrote: > We are seeing a flurry of these kind of “post quantum protection” > things. This is the only one I have seen that is a method, not a new key exchange algorithm. It is understandable that you could have missed this from the title which misstates the topic. A much better title would be "Mixing Preshared Keys in IKEv2 for Postquantum Resistance". > This is premature. Disagree. The method described in the document has been well-discussed in the IPsecME for years, getting good cryptographic review. > The co-chair of the CFRG, Kenny Paterson, said so awhile back. I don't think that's what he said in the slides you posted, but I've Cc'd him so he can reply. The slides are about picking new post-quantum algorithms; what is described in the draft is a method for mixing in preshared secrets with current algorithms. --Paul Hoffman From nobody Wed Dec 11 10:21:34 2019 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 77923120089; Wed, 11 Dec 2019 10:21:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RCVD_IN_DNSWL_LOW=-0.7, 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=akamai.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 vY3iH47gGzuk; Wed, 11 Dec 2019 10:21:29 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 B351B12002E; Wed, 11 Dec 2019 10:21:29 -0800 (PST) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id xBBIG5OC030127; Wed, 11 Dec 2019 18:21:28 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=nvSjgbVDZOZd9/0VADoa3A7n7nw1rm/flXg371woYbU=; b=bx8pVhH52jwK8BJua5nwQpV+b5B+notl1B/JxPLZ9bydhthPnM/2CXcfrBSfvngaudFm Rl/Z2cFPtregOH3MFX8i7KGjOsuYy9iv97iUzwTQp1vkOzH5psUQkNL0bFknyFnDDv4V tl2t5Mw/14NVI/TlXXwnttfTzdTeB5vvh6E7JrAJJQ7NHLjcaJ4cjhzW1QhBpOXmEKYj FB6OBJhnUVGi0TWS8zJlV4kj+kn8p/z4k72YV/7Q7wWr4lWlrhQRHWqd8wYta07YUthW +6N4EocpR99eR2ZwW6ZDxsmty2+Qfyb4pOWX1nmMpLORy0sDupvpKCAZI6xcTubK958U Nw== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2wr21kbedt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 11 Dec 2019 18:21:28 +0000 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xBBIHAkT015646; Wed, 11 Dec 2019 10:21:27 -0800 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint5.akamai.com with ESMTP id 2wraxbn9pg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 11 Dec 2019 10:21:27 -0800 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 11 Dec 2019 13:21:26 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Wed, 11 Dec 2019 13:21:26 -0500 From: "Salz, Rich" To: Paul Hoffman CC: "last-call@ietf.org" , "ipsec@ietf.org" , Kenny Paterson Thread-Topic: [Last-Call] Last Call: (Postquantum Preshared Keys for IKEv2) to Proposed Standard Thread-Index: AQHVsDGdEPO2BClUZEya4low1c3Hh6e1HjkAgABv4ID//7EbgA== Date: Wed, 11 Dec 2019 18:21:26 +0000 Message-ID: <1BB9D55C-7880-4ABF-AD82-F0C1F8FC04A5@akamai.com> References: <157607548927.11531.316316195814237240.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.20.0.191208 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.81.220] Content-Type: text/plain; charset="utf-8" Content-ID: <09A2BEB606AD0344ADF96DE4085A16DF@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-12-11_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=967 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1912110152 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-11_05:2019-12-11,2019-12-11 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 spamscore=0 suspectscore=0 priorityscore=1501 malwarescore=0 phishscore=0 clxscore=1011 lowpriorityscore=0 bulkscore=0 mlxscore=0 mlxlogscore=934 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912110152 Archived-At: Subject: Re: [IPsec] [Last-Call] Last Call: (Postquantum Preshared Keys for IKEv2) to Proposed Standard 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, 11 Dec 2019 18:21:32 -0000 PiBBIG11Y2ggYmV0dGVyIHRpdGxlIHdvdWxkIGJlIA0KICAgICJNaXhpbmcgUHJlc2hhcmVkIEtl eXMgaW4gSUtFdjIgZm9yIFBvc3RxdWFudHVtIFJlc2lzdGFuY2UiLg0KICANClRoYXQncyBiZXR0 ZXIuDQoNCkkgbWlzdW5kZXJzdG9vZCB0aGUgZG9jdW1lbnQgYXMgYm90aCB5b3UgYW5kIERhdmlk IE1jZ3JldyBraW5kbHkgZXhwbGFpbmVkLiAgSSB3aXRoZHJhdyBteSBjb25jZXJucyBhbmQgaG9w ZSB0aGUgdGl0bGUgaXMgY2hhbmdlZC4NCg0K From nobody Wed Dec 11 10:26:08 2019 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 7665B120089; Wed, 11 Dec 2019 10:26:07 -0800 (PST) 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_DNSWL_NONE=-0.0001, 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 GQcHU902ZDUA; Wed, 11 Dec 2019 10:26:05 -0800 (PST) Received: from akmail.elvis.ru (akmail.elvis.ru [82.138.51.97]) (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 2D6EB12002E; Wed, 11 Dec 2019 10:26:05 -0800 (PST) Received: from kmail2.elvis.ru ([93.188.44.210]) by akmail.elvis.ru with esmtp (Exim 4.89) (envelope-from ) id 1if6gS-0005wv-9z; Wed, 11 Dec 2019 21:26:00 +0300 Received: from mail16.office.elvis.ru ([10.111.1.29] helo=mail.office.elvis.ru) by kmail2.elvis.ru with esmtp (Exim 4.89) (envelope-from ) id 1if6gR-0005vn-Q5; Wed, 11 Dec 2019 21:26:00 +0300 Received: from MAIL16.office.elvis.ru (10.111.1.29) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Wed, 11 Dec 2019 21:25:59 +0300 Received: from chichi (10.100.100.20) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server id 15.1.1779.2 via Frontend Transport; Wed, 11 Dec 2019 21:25:55 +0300 From: Valery Smyslov To: "'Salz, Rich'" , "'Scott Fluhrer (sfluhrer)'" , CC: , , , , References: <157607548927.11531.316316195814237240.idtracker@ietfa.amsl.com> In-Reply-To: Date: Wed, 11 Dec 2019 21:25:01 +0300 Message-ID: <005a01d5b050$4d078b70$e716a250$@elvis.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGM9Z3ExXRmfdXrGr3pQvUqcx7OgQFaQgbjAUPLUxMCDF9MuKghYKKg Content-Language: ru X-CrossPremisesHeadersFilteredBySendConnector: MAIL16.office.elvis.ru X-OrganizationHeadersPreserved: MAIL16.office.elvis.ru X-Spam-Scanner: Rspamd work in kmail2.elvis.ru, WHITELIST X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Status: not scanned, disabled by settings X-KLMS-AntiPhishing: Clean, bases: 2019/12/11 18:05:00 X-KLMS-AntiVirus: Kaspersky Security for Linux Mail Server, version 8.0.3.30, bases: 2019/12/11 16:38:00 #14775872 X-KLMS-AntiVirus-Status: Clean, skipped X-Spam-Scanner: Rspamd work in akmail.elvis.ru, WHITELIST Archived-At: Subject: Re: [IPsec] Last Call: (Postquantum Preshared Keys for IKEv2) to Proposed Standard 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, 11 Dec 2019 18:26:07 -0000 Hi Rich, I think that Kenny's slides only support the idea, that the draft should = be Standards Track. In particular, the slide "The Coming Crypt-Apocalypse?" has a bullet: * And traffic captured now could be broken later, so it=E2=80=99s a = problem *today* if you have data that needs to be kept secure for decades. That's the problem the draft solves. Regards, Valery. > Slides: = https://datatracker.ietf.org/meeting/99/materials/slides-99-saag- > post-quantum-cryptography >=20 > Video: https://www.youtube.com/watch?v=3Dabmd1n5WUvc&t=3D1451s >=20 >=20 > =EF=BB=BFOn 12/11/19, 11:36 AM, "Scott Fluhrer (sfluhrer)" = > wrote: >=20 > Did Kenny make this statement in the context of postquantum > cryptography (that is, public key algorithms that are believed to be = secure > even if the adversary has a quantum computer)? >=20 > That would certainly be a reasonable statement (as most = postquantum > algorithms are fairly new, and are still being cryptographically = vetted). >=20 > On the other hand, this specific draft doesn't involve any = postquantum > algorithms; it relies only on currently accepted algorithms, and so = Kenny's > caution would not apply. >=20 > > -----Original Message----- > > From: Salz, Rich > > Sent: Wednesday, December 11, 2019 11:23 AM > > To: last-call@ietf.org > > Cc: ipsec@ietf.org; ipsecme-chairs@ietf.org; > david.waltermire@nist.gov; > > draft-ietf-ipsecme-qr-ikev2@ietf.org > > Subject: Re: Last Call: = (Postquantum > > Preshared Keys for IKEv2) to Proposed Standard > > > > We are seeing a flurry of these kind of =E2=80=9Cpost quantum = protection=E2=80=9D > things. > > This is premature. The co-chair of the CFRG, Kenny Paterson, = said so > awhile > > back. > > > > At best, this should be EXPERIMENTAL. > > > > I would like to see an IESG policy that makes all drafts on this = topic be > > EXPERIMENTAL. > > >=20 >=20 From nobody Wed Dec 11 10:44:47 2019 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 7841A120821 for ; Wed, 11 Dec 2019 10:44:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=nokia.onmicrosoft.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 G6WTpl9cjyKT for ; Wed, 11 Dec 2019 10:44:44 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130111.outbound.protection.outlook.com [40.107.13.111]) (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 044F5120820 for ; Wed, 11 Dec 2019 10:44:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l5s2CI2xvlr2dduz12y+G34bWIZR0qo4SebOKSXsUGN6GYloxdeXeGl5nP+NkVJ/IA0JqEB1KU+Okd+fnVub9u83AZwjaxAndYCi03h12vBqW35jm662hZBK1VWOYCcx0nDeDE5QIDs4GGUH1ZH9u9Xq3uAQ6L/l5Stlun0xlPJiw2pbcIqZZckr4cFsJoUvb1YRGTHhD4U1dQ72yLQLo0H2P1jm1RRWkXoWFeWRMYh0Rx5kZDs7Uw7v0R6y3GFUAkgYthm0z52yyGtffyMdVbjuMbEndi6+dDoxas811AkDjjff/zbntqtgGMuETNVk1NC2Ny+XGToV0+k8NUgKlQ== 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=mEI4IGnJoT4A7NxKopKF0t5KNggX6mpv/GPt28Vukl0=; b=U1GoqpxoGOlp0ZgAcbKCIOZK/I1yKIvgN67E5g6VezfS3RXyoedVISi9SdWugyWrImZokDJEi+TGjpPxpkCOD5swVk7ZOeKvpqKFYvnbJyZaHQ2mMpM3p9hG9t5ffkMUaX7ouy58ke6oTHJkRTN7OzOh1frPSLKUs7//9Y9Vgkopumv67wnUsOzkg72x178ipeggr3+pXGKhGHw6o7tXP2NCcnVzQELhNVUfisJ16kLlQXOcb7UwqlYj59cyN55IgCdUJ3Fwux3AoYt2hvgfIOtbSOZ6wBVYNAwHkDI89npzfkfFuDvW/YrDSd0VfcUTW2dg12pt1Q1+/25nYIfWYQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mEI4IGnJoT4A7NxKopKF0t5KNggX6mpv/GPt28Vukl0=; b=GQqupYI7tSB0eciaNGvoxm1K8FIsxmvrN5U/37xDAdjBTsCe/n6p6zUlKV8jJ0Y4l48vaiUW1wzN6sszUnY2aaqBwW2qRuHRa9O8+/DncxQfXwhfXgbvlztk/RpdPVVr25mZTJz77iBEFuhf6NprFwJEZw2rtCH4Iy1zL//u8IU= Received: from AM5PR0701MB2353.eurprd07.prod.outlook.com (10.169.150.18) by AM5PR0701MB2929.eurprd07.prod.outlook.com (10.168.156.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.4; Wed, 11 Dec 2019 18:44:41 +0000 Received: from AM5PR0701MB2353.eurprd07.prod.outlook.com ([fe80::c00:ee6e:9763:f843]) by AM5PR0701MB2353.eurprd07.prod.outlook.com ([fe80::c00:ee6e:9763:f843%7]) with mapi id 15.20.2538.016; Wed, 11 Dec 2019 18:44:41 +0000 From: "Hu, Jun (Nokia - US/Mountain View)" To: Paul Wouters , "ipsec@ietf.org WG" CC: Sahana Prasad Thread-Topic: [IPsec] Labeled IPsec options Thread-Index: AQHVrxZ09uToqmx5zEOPjFh9TCkZuae1Rf+A Date: Wed, 11 Dec 2019 18:44:41 +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: spf=none (sender IP is ) smtp.mailfrom=jun.hu@nokia.com; x-originating-ip: [2601:646:8500:5ce4:51f0:dbe7:fd3:efdd] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: fb243381-6466-44c5-0a93-08d77e6a2ef9 x-ms-traffictypediagnostic: AM5PR0701MB2929: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 024847EE92 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(346002)(396003)(39860400002)(376002)(366004)(199004)(13464003)(189003)(6506007)(7696005)(9686003)(5660300002)(53546011)(55016002)(478600001)(4326008)(966005)(8936002)(8676002)(66446008)(316002)(81166006)(81156014)(52536014)(86362001)(110136005)(33656002)(2906002)(66946007)(76116006)(66556008)(64756008)(66476007)(71200400001)(186003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2929; H:AM5PR0701MB2353.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: vsPL5a9LUKfmJM3+PvY67vrLU5Oz+YWQ0pAILynz0ScsvqSooJdk4p8or91Clk06IJ6VcE/Uwqfm0NpphNERxjKq1ZU8vLf4wp6x1FYeHByW5kkI1xVZQBoqgaQTvkKQ00NOhvxhMjOKjeWjZF0KHn9+sGFNvHfN8VI5/w1Djlz4UIGf4+xB2f4blJKuHOldVPPn1gwY++jSlPIDzIi6phS3xSyHhNXWClsDSPnRdMFbo/ON2rvaIzUHOAHrej86qyUWDbVxRMZYxHoZQy50nRw7snbfEz/UNiFKd1yIXTGP+wvITyrs2gMvGU8Z4QWtnT5vhH+h1MKngLB/Z/K+oCpf22Z9kOOPxmxSAALe2pHRRXdXmkWIk8a02Nn1j4SNnaau5tTJp31HJ1AN3zF4B5dlw8dGnBHwheKJsriPY+K0M4Xn0yxqBgbyxz7SYWPn2yod+8z6ysrOtPW7zO88bMJWTwPnvccU7k5nmypIqzs3cMYl5aL2WpM4c5JDnrL74rdk+USvKIlyo8WathiVwTcT4XT6lGvcaZNF+cK6OIQ= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: fb243381-6466-44c5-0a93-08d77e6a2ef9 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2019 18:44:41.5331 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: iVR0t2LVn2odf3z4Jv4QIQAS4UYi3h/oNKa5ce3f3kWveKkuoEvx/hNkOfQLwkMKi4BBiFT3x2N2+QKhEee/tw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2929 Archived-At: Subject: Re: [IPsec] Labeled IPsec options 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, 11 Dec 2019 18:44:46 -0000 +1 for option4, +0.5 for option3=20 One factor to consider is the granularity of label, for me it is per CHILD_= SA; option1 is per TS (e.g TS with label and TS without label could be mixe= d in the same payload), option2 is per TS payload (e.g. you could have TSi = with label, TSr without label) Option3 is a bit "abusing" the semantic of notification payload, since a "l= abel notification" is not communicating a status, error or capability.=20 -----Original Message----- From: IPsec On Behalf Of Paul Wouters Sent: Monday, December 9, 2019 8:58 PM To: ipsec@ietf.org WG Cc: Sahana Prasad Subject: [IPsec] Labeled IPsec options Hi, As agreed at IETF 106, we would write up the options for negotiating Labele= d IPsec that we have discussed, with their PROs and CONs, so that the worki= ng group can make a final decision. Option 1) TS_IPV4_ADDR_RANGE_SECLABEL and TS_IPV6_ADDR_RANGE_SECLABEL https://tools.ietf.org/html/draft-ietf-ipsecme-labeled-ipsec-00 This option introduced a new Traffic Selector type that is similar to the c= ore IKEv2 RFC S_IPV4_ADDR_RANGE and TS_IPV6_ADDR_RANGE, but also contain a = Security Label field PROs: - Early failure during IKE_AUTH when mismatched. No IPsec SA establishes - Does not otherwise change the Traffic Selector processing CONs: - A bit ugly to have sort of duplicate Traffic Selector types - All new TS types in the future would need to get a seclabel and non-secla= bel version. Option 2) TS_SECLABEL https://tools.ietf.org/html/draft-ietf-ipsecme-labeled-ipsec-02 PROs: - No copies of TS TYPE's with/without seclabel CONs: - Error handling is less nice. Responder might setup an IPsec SA narrowed to without security label (unsupported TStypes can be ignored according to RFC 7296), and the initiator has to refuse it by sending a Delete SA message (as security labels are typically mandatory) - Changes Traffic Selector processing, as now one is told that if you pick TS_SECLABEL you must also pick a TS_IPV{46}_ADDR_RANGE. Thus updates RFC 7296 with "sub typing" of TS TYPEs. Option 3) Use NOTIFY payloads (not specified in a draft) PROs: - No changes to Traffic Selector code or specification. Easiest to implement. CONs: - Error handling is less nice. Responder might setup an IPsec SA without supporting the NOTIFY, and initiator has to Delete SA it. Option 4) A new payload type like NOTIFY but now we can set Critical Flag (= not specified in a draft) PROs: - No changes to Traffic Selector code or specification. Easiest to implement. - Can use payload with Critical Flag, so exchange fails if not configured or supported for security label type payload - Error handling already done as part of standard IKEv2 CONs: - Takes up a new payload number. - Old Implementations might ignore Critical Flag and new payload type and setup IPsec SA without Security Label? New implementations not receiving the new payload type must also send Delete SA to prevent non-label IPsec SA on responder to linger. Please let us know on the list which solution you prefer and why, so we can= make a final decision and move on :) Paul & Sahana _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Dec 11 11:11:52 2019 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 3A788120052; Wed, 11 Dec 2019 11:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 nI8uUC9hoITA; Wed, 11 Dec 2019 11:11:44 -0800 (PST) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 1BE1D120127; Wed, 11 Dec 2019 11:11:44 -0800 (PST) Received: by mail-wm1-x32d.google.com with SMTP id b11so8429656wmj.4; Wed, 11 Dec 2019 11:11:44 -0800 (PST) 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=dUI7nYzSOxGHYWAAwvPSP5MAiCy36Fsq6mzBr8l0wyM=; b=ZKTn06peTybZzhqEQcOthd9KR71H83QtaR9KJ2+2cHt7EsJQx0z2EomqbYY4+LAtc2 fpL55fVx8XG4vpfwSF2Twe2D5ztaZ7fkGnB6mUI6liplj29YX2hjar1KvAn7BARALwNp GM2R0P7bRn2eyC04B4TYEf6Ep0NsOdcB5p2GHYn8/kb5ZrJ6/lgZqGFAOLvLokmRGcWs ilNSfXgUXzC9t2VH52/HBJ7YOVvMT2MdsS3PCI5INY4XAYNPzdqsvNEfCwEUQfpVDmQI xZz0MS6aEYA09b4c1NfxK4pmgp5Bp3JwwLnMwwiQwgA4HUuAzWvKvoXMJP8bw7iAQMQo 7Nfg== 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=dUI7nYzSOxGHYWAAwvPSP5MAiCy36Fsq6mzBr8l0wyM=; b=B+PiHfa4IlKaE/kBtKqi/xtZCbAS4BK3rcNJZz0tLAAoYJTuH8yyJZy+4rVBMFcPlS +xl7XwZVnmv3gzkCAU5ZbwQAHyXiwsNHbb8ihQm1N1OLN90iwfAqr4eHcxRrPLdTsHlM Fmzxf523Gzc2+7/qT9cg6X/qSmUzkWXrCN6+Pj7yXTd9J/X0OcdgnhZhnLviqYYVjupx pviSmUHDNBhq93uTHSsgL3DqIgVie2N9KZ6Ud3K87ZtOL1nDFs4paK1Bz8p0ySzuGkMQ 6LMF3a/RAKczYeV30gsHatfthyzj0QDXK9EFBc/2jFEtT5e5NOtoVQw1TepMSUrt/1KW C6jA== X-Gm-Message-State: APjAAAXR/G7pkVb47g6zuCQXOic4gv9Fj/28759dUBqdGLfaOPzT+uGk UjnyuT+kJ7gjS98RKqSDsDo= X-Google-Smtp-Source: APXvYqzC8K3IiZlMUkawZHZYF2hb0lsQvIDuxEjpoRTLZK4W52aOr9//05UA4PmxM4EulTL6Mua5fA== X-Received: by 2002:a1c:7c11:: with SMTP id x17mr1517959wmc.168.1576091502606; Wed, 11 Dec 2019 11:11:42 -0800 (PST) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id i8sm3355035wro.47.2019.12.11.11.11.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Dec 2019 11:11:41 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Yoav Nir In-Reply-To: Date: Wed, 11 Dec 2019 21:11:35 +0200 Cc: Rich Salz , ipsec@ietf.org, last-call@ietf.org, Kenny Paterson Content-Transfer-Encoding: quoted-printable Message-Id: <9B63006D-03FC-4EB5-82C2-54BF1D9FF879@gmail.com> References: <157607548927.11531.316316195814237240.idtracker@ietfa.amsl.com> To: Paul Hoffman X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [IPsec] [Last-Call] Last Call: (Postquantum Preshared Keys for IKEv2) to Proposed Standard 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, 11 Dec 2019 19:11:46 -0000 Hi, Paul > On 11 Dec 2019, at 20:03, Paul Hoffman wrote: >=20 > On 11 Dec 2019, at 8:23, Salz, Rich wrote: >=20 >> We are seeing a flurry of these kind of =E2=80=9Cpost quantum = protection=E2=80=9D things. >=20 > This is the only one I have seen that is a method, not a new key = exchange algorithm. It is understandable that you could have missed this = from the title which misstates the topic. A much better title would be = "Mixing Preshared Keys in IKEv2 for Postquantum Resistance". Should we consider this a last call comment? Yoav From nobody Wed Dec 11 14:04:39 2019 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 33233120124; Wed, 11 Dec 2019 14:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, MAY_BE_FORGED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 wOZO69U7Zzzm; Wed, 11 Dec 2019 14:04:32 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 41DE2120099; Wed, 11 Dec 2019 14:04:32 -0800 (PST) Received: from [10.32.60.122] (76-209-242-70.lightspeed.mtryca.sbcglobal.net [76.209.242.70] (may be forged)) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id xBBM4OBY065241 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 11 Dec 2019 15:04:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 76-209-242-70.lightspeed.mtryca.sbcglobal.net [76.209.242.70] (may be forged) claimed to be [10.32.60.122] From: "Paul Hoffman" To: "Yoav Nir" Cc: "Rich Salz" , ipsec@ietf.org, last-call@ietf.org, "Kenny Paterson" Date: Wed, 11 Dec 2019 14:04:24 -0800 X-Mailer: MailMate (1.13.1r5671) Message-ID: In-Reply-To: <9B63006D-03FC-4EB5-82C2-54BF1D9FF879@gmail.com> References: <157607548927.11531.316316195814237240.idtracker@ietfa.amsl.com> <9B63006D-03FC-4EB5-82C2-54BF1D9FF879@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [IPsec] Last Call: (Postquantum Preshared Keys for IKEv2) to Proposed Standard 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, 11 Dec 2019 22:04:33 -0000 On 11 Dec 2019, at 11:11, Yoav Nir wrote: > Hi, Paul > >> On 11 Dec 2019, at 20:03, Paul Hoffman wrote: >> >> On 11 Dec 2019, at 8:23, Salz, Rich wrote: >> >>> We are seeing a flurry of these kind of “post quantum >>> protection” things. >> >> This is the only one I have seen that is a method, not a new key >> exchange algorithm. It is understandable that you could have missed >> this from the title which misstates the topic. A much better title >> would be "Mixing Preshared Keys in IKEv2 for Postquantum Resistance". > > Should we consider this a last call comment? Yes, please do. --Paul Hoffman From nobody Wed Dec 11 22:11:27 2019 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 458921200FF for ; Wed, 11 Dec 2019 22:11:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 JZezQJi3KGkg for ; Wed, 11 Dec 2019 22:11:23 -0800 (PST) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 5E0FD1200FD for ; Wed, 11 Dec 2019 22:11:23 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id h23so877009ljc.8 for ; Wed, 11 Dec 2019 22:11:23 -0800 (PST) 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=RH3zwttCCo7LOZDyq2NvjNmQfQok0oorBYSuFnyhbHc=; b=ic1icA/mcovsiy+pXru/0BgCalMEzh5Kk5AMx6hMtk7dU2fQAxui/gRY9brcCBvR87 toENP+1EiZ3piuB3GvAkw5a6znTH7LfzGLLAydQ+BAN46Gc26aB359dFcBi3nOLsZB10 fdS50Jy31fy2hiseka0EMp6Dmi7EvyOmAtWfePhtuu2mKsAkLGCUJU4C0+YY68CHJQGG LMcjfCLZGNhaTLvEBkTmZtYPJ+ub+ldZy8JzVQ7H6cGJX1Ka/3ctP1/4rn3xnK71C5Uo m/HhOOKjsu7Fywkp8DWc/PUPSdWtUjDs05hNftNyvqzypXcKGNmNiNXuYPcrIpYixzqW U4sg== 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=RH3zwttCCo7LOZDyq2NvjNmQfQok0oorBYSuFnyhbHc=; b=UiEHDbiTVXEy1h0Cf3PqorDIs5GCEe7UqigTn2q2X9voN4M03TCA2ouwe8OyjoL3+U Rl9BaUgOrMXkqomF7JVhoIn7XPEA+XIrwNES6U5V9nF45aF1W145EdyapEnylTR8ykUz a+m2Idr/shV03EsgT8HYnI7uXbljSj5ST5qCVeAlN34SesHQ+3T8vZZsmfkfqESgG0sM WIOMzP0Fs0JLTCkNkGd71tEV9/kJq0RIgoLL4SjN3XWlNCtNnf6L0Hm24Rcq9dXh6A73 GGiOrkvWQyBbBRAKM//NaBB5+JL+nXzmGHL7ExLwqnTPv4FtrDY1NcGIgfXEu18W80Vf sBZA== X-Gm-Message-State: APjAAAWvLlabjgXxtI1oOEw3Nhc4/vAEykynJQpisa+8M+xG3zK8eem6 DRd3n4rgXu3gRj1liEjSNcepHJ8M X-Google-Smtp-Source: APXvYqzmAnnKJQuU/vPeFzWPpnCNvAjO+JLe+/547Fr8Oc1VNKVv6vzIfqBNuqc3cQu/epIV+eR7WQ== X-Received: by 2002:a2e:9b8f:: with SMTP id z15mr4769699lji.20.1576131081066; Wed, 11 Dec 2019 22:11:21 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id e20sm2290772ljl.59.2019.12.11.22.11.20 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 11 Dec 2019 22:11:20 -0800 (PST) From: "Valery Smyslov" To: "'Paul Wouters'" , Cc: "'Sahana Prasad'" References: In-Reply-To: Date: Thu, 12 Dec 2019 09:11:22 +0300 Message-ID: <01f501d5b0b2$facb4370$f061ca50$@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: AQLx+ZsZ28gCWkLjxf5xPWFraxjS5KV9a7nw Content-Language: ru Archived-At: Subject: Re: [IPsec] Labeled IPsec options 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, 12 Dec 2019 06:11:25 -0000 Hi Paul, I don't think option 4 is a good idea. If old responder encounters an unknown payload with Critical bit set in IKE_AUTH, it will return back UNSUPPORTED_CRITICAL_PAYLOAD and IKE SA won't be set up. See section 2.21.2 of RFC7296. This would require initiator to retry from IKE_SA_INIT, doubling the work. Or it can create childless IKE SA and then try CREATE_CHILD_SA - not an optimal solution too. I also don't like option 2 since it requires changing the way TSs are handled in IKEv2. Option 1 looks like the clearest from pure theoretical point of view, however I agree that it could lead to TS types explosion in future. Option 3 looks like a compromise from practical point of view. You can solve the problem of imperfect error handling by adding a new SECLABES_SUPPORTED notification, that must be exchanged in IKE_SA_INIT. If both peers support seclabels, then the responder must not ignore seclabel notifications in IKE_AUTH and CREATE_CHILD_SA. The drawback is that we need one more notification and it must be exchanged in IKE_SA_INIT, increasing its message size. Not a big deal. Regards, Valery. > Hi, > > As agreed at IETF 106, we would write up the options for negotiating > Labeled IPsec that we have discussed, with their PROs and CONs, so > that the working group can make a final decision. > > > > Option 1) TS_IPV4_ADDR_RANGE_SECLABEL and TS_IPV6_ADDR_RANGE_SECLABEL > https://tools.ietf.org/html/draft-ietf-ipsecme-labeled-ipsec-00 > > This option introduced a new Traffic Selector type that is similar > to the core IKEv2 RFC S_IPV4_ADDR_RANGE and TS_IPV6_ADDR_RANGE, but > also contain a Security Label field > > PROs: > - Early failure during IKE_AUTH when mismatched. No IPsec SA establishes > - Does not otherwise change the Traffic Selector processing > CONs: > - A bit ugly to have sort of duplicate Traffic Selector types > - All new TS types in the future would need to get a seclabel and non-seclabel version. > > > > > Option 2) TS_SECLABEL > https://tools.ietf.org/html/draft-ietf-ipsecme-labeled-ipsec-02 > > PROs: > - No copies of TS TYPE's with/without seclabel > CONs: > - Error handling is less nice. Responder might setup an IPsec SA > narrowed to without security label (unsupported TStypes can be > ignored according to RFC 7296), and the initiator has to refuse > it by sending a Delete SA message (as security labels are typically > mandatory) > - Changes Traffic Selector processing, as now one is told that > if you pick TS_SECLABEL you must also pick a TS_IPV{46}_ADDR_RANGE. > Thus updates RFC 7296 with "sub typing" of TS TYPEs. > > > > > Option 3) Use NOTIFY payloads > (not specified in a draft) > > PROs: > - No changes to Traffic Selector code or specification. Easiest to > implement. > CONs: > - Error handling is less nice. Responder might setup an IPsec SA > without supporting the NOTIFY, and initiator has to Delete SA it. > > > > Option 4) A new payload type like NOTIFY but now we can set Critical Flag > (not specified in a draft) > PROs: > - No changes to Traffic Selector code or specification. Easiest to > implement. > - Can use payload with Critical Flag, so exchange fails if not > configured or supported for security label type payload > - Error handling already done as part of standard IKEv2 > CONs: > - Takes up a new payload number. > - Old Implementations might ignore Critical Flag and new payload type > and setup IPsec SA without Security Label? New implementations not > receiving the new payload type must also send Delete SA to prevent > non-label IPsec SA on responder to linger. > > > Please let us know on the list which solution you prefer and why, so we > can make a final decision and move on :) > > Paul & Sahana > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Dec 12 12:38:50 2019 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 C1CFD1200D6; Thu, 12 Dec 2019 12:38:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.419 X-Spam-Level: X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 XbdmT6m86o4Y; Thu, 12 Dec 2019 12:38:46 -0800 (PST) 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) by ietfa.amsl.com (Postfix) with ESMTPS id A755E120024; Thu, 12 Dec 2019 12:38:45 -0800 (PST) Received: by fireball.acr.fi (Postfix, from userid 15204) id 39E8325C12A4; Thu, 12 Dec 2019 22:38:41 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24050.42321.185052.541103@fireball.acr.fi> Date: Thu, 12 Dec 2019 22:38:41 +0200 From: Tero Kivinen To: Benjamin Kaduk Cc: draft-ietf-ipsecme-qr-ikev2@ietf.org, ipsec@ietf.org In-Reply-To: <20191211021039.GZ13890@kduck.mit.edu> References: <157602964597.9873.4051369223279728575.idtracker@ietfa.amsl.com> <20191211021039.GZ13890@kduck.mit.edu> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 9 min Archived-At: Subject: Re: [IPsec] Datatracker State Update Notice: 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, 12 Dec 2019 20:38:49 -0000 Benjamin Kaduk writes: > It looks like the "reference" column for the registry dind't make it into > the -09, but I'm happy to include that change along with the last-call > feedback. If you are talking about the reference column of the IANA registries, then they are not needed in the draft (or rfc). IANA will normally add them automatically to the registries when doing the assignment. -- kivinen@iki.fi From nobody Thu Dec 12 12:42:24 2019 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 0BAA3120088; Thu, 12 Dec 2019 12:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 S6R-CQd822FD; Thu, 12 Dec 2019 12:42:20 -0800 (PST) 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 9389A120024; Thu, 12 Dec 2019 12:42:20 -0800 (PST) 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 xBCKgFgf029221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 12 Dec 2019 15:42:18 -0500 Date: Thu, 12 Dec 2019 12:42:15 -0800 From: Benjamin Kaduk To: Tero Kivinen Cc: draft-ietf-ipsecme-qr-ikev2@ietf.org, ipsec@ietf.org Message-ID: <20191212204215.GZ13890@kduck.mit.edu> References: <157602964597.9873.4051369223279728575.idtracker@ietfa.amsl.com> <20191211021039.GZ13890@kduck.mit.edu> <24050.42321.185052.541103@fireball.acr.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24050.42321.185052.541103@fireball.acr.fi> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [IPsec] Datatracker State Update Notice: 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, 12 Dec 2019 20:42:22 -0000 On Thu, Dec 12, 2019 at 10:38:41PM +0200, Tero Kivinen wrote: > Benjamin Kaduk writes: > > It looks like the "reference" column for the registry dind't make it into > > the -09, but I'm happy to include that change along with the last-call > > feedback. > > If you are talking about the reference column of the IANA registries, > then they are not needed in the draft (or rfc). IANA will normally add > them automatically to the registries when doing the assignment. I was more interested in being clear that the new registry we're creating should have a "Reference" column, than making sure new allocations from existing registries get the proper reference listed. But there's plenty of time left in which to make that happen :) -Ben From nobody Thu Dec 12 13:02:13 2019 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 2F2E9120123 for ; Thu, 12 Dec 2019 13:02:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.419 X-Spam-Level: X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 yqGe0wY8JWPj for ; Thu, 12 Dec 2019 13:02:10 -0800 (PST) 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) by ietfa.amsl.com (Postfix) with ESMTPS id A1B601200F9 for ; Thu, 12 Dec 2019 13:02:09 -0800 (PST) Received: by fireball.acr.fi (Postfix, from userid 15204) id 284EB25C12B0; Thu, 12 Dec 2019 23:02:08 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24050.43728.115813.170898@fireball.acr.fi> Date: Thu, 12 Dec 2019 23:02:08 +0200 From: Tero Kivinen To: "Valery Smyslov" Cc: "'Paul Wouters'" , , 'Sahana Prasad' In-Reply-To: <01f501d5b0b2$facb4370$f061ca50$@gmail.com> References: <01f501d5b0b2$facb4370$f061ca50$@gmail.com> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 12 min X-Total-Time: 11 min Archived-At: Subject: Re: [IPsec] Labeled IPsec options 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, 12 Dec 2019 21:02:11 -0000 Valery Smyslov writes: > I don't think option 4 is a good idea. If old responder > encounters an unknown payload with Critical bit set in IKE_AUTH, it will > return back UNSUPPORTED_CRITICAL_PAYLOAD and IKE SA won't be set up. > See section 2.21.2 of RFC7296. This would require initiator to retry from > IKE_SA_INIT, doubling the work. Or it can create childless IKE SA > and then try CREATE_CHILD_SA - not an optimal solution too. Agree fully on that. > I also don't like option 2 since it requires changing the way TSs > are handled in IKEv2. Also agree. > Option 1 looks like the clearest from pure theoretical point of view, > however I agree that it could lead to TS types explosion in future. Yes, I think option 1 would be most proper way of doing the negotiation. I am not sure if we are going to get that many new traffic selectors in the future, so I do not think the TS types explosion is going to be that big issue. Also in most setups I would expect security labels to be either always mandatory or always omitted (and that information quite often comes directly from configuration). I do not really see that common cases where initiator would try to use security labels and responder not supporting them. I.e., if you do always require security labels, there is no TS explosion as you only propose TS with security labels. If you do not support them, you use normal TS. You would propose both only if you do not care whether other end supports security labels, but are willing to use them if it supports, but what is the meaning of security labels then? Why even propose them if you do not care what they are? > Option 3 looks like a compromise from practical point of view. Agree on that too. Either option 1 or 3 would be acceptable for me, with slight preference on option 1 because it would be proper way of doing things. > You can solve the problem of imperfect error handling by adding > a new SECLABES_SUPPORTED notification, that must be exchanged > in IKE_SA_INIT. If both peers support seclabels, then > the responder must not ignore seclabel notifications in IKE_AUTH > and CREATE_CHILD_SA. The drawback is that we need > one more notification and it must be exchanged in IKE_SA_INIT, > increasing its message size. Not a big deal. I am not sure we need that. I mean if initiator do require security labels and sends security labels notification, but responder does not reply to them, what can it do next? There isn't going to be any communications between the peers in that case, so it should simply tear down the SA anyways. If it gets same information during IKE_SA_INIT (missing SECLABELS_SUPPORTED), it cannot trust that thing yet as other end is not authenticated, so it will need to run IKE_AUTH to the end anyways to make sure that there was no attack removing that SECLABELS_SUPPORTED notification. So it will detect that error at the end of IKE_AUTH always. In that case there is no point of adding notification to the IKE_SA_INIT. -- kivinen@iki.fi From nobody Thu Dec 12 13:13:16 2019 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 EEFFB12013B for ; Thu, 12 Dec 2019 13:13:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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 zVWlgKgSY2tY for ; Thu, 12 Dec 2019 13:13:10 -0800 (PST) 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 60E01120123 for ; Thu, 12 Dec 2019 13:13:10 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 47YmjZ0KRBzDZG; Thu, 12 Dec 2019 22:13:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1576185186; bh=8t0qjsHSGe/idux6UHSAtqu4ObYtxDKD82L8ZTjMy9I=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=HZvFd3qNbSaiYKPezs1ksPxeEgbO/97GuKPqtCJrAX7TPPy3TTJ8ZiaYuEekfP0ls Ahd5Nl+c0xAEs7/C9mSu+ffyQh0TxUTPHLHuijIPJSPWK9aJf4sLoH31KUAhQmUIUs dL6bVj7U13a/GoIIR765Q+dAOJMQ8cbMCpYKxhm8= 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 A9zeKGO8ANJU; Thu, 12 Dec 2019 22:13:04 +0100 (CET) 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, 12 Dec 2019 22:13:04 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id A6AC56007ADD; Thu, 12 Dec 2019 16:13:03 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A2BD3308EC; Thu, 12 Dec 2019 16:13:03 -0500 (EST) Date: Thu, 12 Dec 2019 16:13:03 -0500 (EST) From: Paul Wouters To: Valery Smyslov cc: ipsec@ietf.org, 'Sahana Prasad' In-Reply-To: <01f501d5b0b2$facb4370$f061ca50$@gmail.com> Message-ID: References: <01f501d5b0b2$facb4370$f061ca50$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Labeled IPsec options 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, 12 Dec 2019 21:13:13 -0000 On Thu, 12 Dec 2019, Valery Smyslov wrote: > I don't think option 4 is a good idea. If old responder > encounters an unknown payload with Critical bit set in IKE_AUTH, it will > return back UNSUPPORTED_CRITICAL_PAYLOAD and IKE SA won't be set up. > See section 2.21.2 of RFC7296. This would require initiator to retry from > IKE_SA_INIT, doubling the work. Or it can create childless IKE SA > and then try CREATE_CHILD_SA - not an optimal solution too. I don't think that matters. Security labels are never optional but always mandatory. And it seems very unlikely to have a mix of child sa's with and without label. So they will all have a label, and then failing the IKE SA is fine, since no single child sa will be able to be setup anyway. It's better than the responder setting up an SA that needs to be torn down by the initiator sending a delete. > Option 1 looks like the clearest from pure theoretical point of view, > however I agree that it could lead to TS types explosion in future. > > Option 3 looks like a compromise from practical point of view. > You can solve the problem of imperfect error handling by adding > a new SECLABES_SUPPORTED notification, that must be exchanged > in IKE_SA_INIT. If both peers support seclabels, then But you really mean SECLABEL_REQUIRED? The "supported" keyword here is misleading. The problem of doing this in IKE_SA_INIT is that it could result in a spoofed answers omiting the payload? > the responder must not ignore seclabel notifications in IKE_AUTH > and CREATE_CHILD_SA. The drawback is that we need > one more notification and it must be exchanged in IKE_SA_INIT, > increasing its message size. Not a big deal. So I'm not sure I trust this design. Paul From nobody Thu Dec 12 13:15:41 2019 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 5AB15120044 for ; Thu, 12 Dec 2019 13:15:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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 xYm-0TaxowHd for ; Thu, 12 Dec 2019 13:15:36 -0800 (PST) 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 B8AEE120024 for ; Thu, 12 Dec 2019 13:15:36 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 47YmmR2n3pzDZK; Thu, 12 Dec 2019 22:15:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1576185335; bh=47au5qALF4NnudvkmotmwonirO2hVlcieYfPrhtHuPw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=CmZoofiMvdKNQtXD09fDHQg97cgNloA0ELxBioLRK49lL+oKyLNSsMhrLOwwirrbv fUjJwlXMzJVB1gsq5LbJ4jHTVvfnOEQP56Gnnu/GlZ9vJfYjRv9J71O3SH6ssjatRD BFHzoUgOok81DcSmWl47PA1nVwAjhzDImNTyDsEg= 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 a9b4_rJ8zOxJ; Thu, 12 Dec 2019 22:15:34 +0100 (CET) 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, 12 Dec 2019 22:15:34 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 192D16007ADD; Thu, 12 Dec 2019 16:15:33 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 152F7308EC; Thu, 12 Dec 2019 16:15:33 -0500 (EST) Date: Thu, 12 Dec 2019 16:15:33 -0500 (EST) From: Paul Wouters To: Tero Kivinen cc: Valery Smyslov , ipsec@ietf.org, 'Sahana Prasad' In-Reply-To: <24050.43728.115813.170898@fireball.acr.fi> Message-ID: References: <01f501d5b0b2$facb4370$f061ca50$@gmail.com> <24050.43728.115813.170898@fireball.acr.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Labeled IPsec options 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, 12 Dec 2019 21:15:38 -0000 On Thu, 12 Dec 2019, Tero Kivinen wrote: >> Option 1 looks like the clearest from pure theoretical point of view, >> however I agree that it could lead to TS types explosion in future. > > Yes, I think option 1 would be most proper way of doing the > negotiation. I am not sure if we are going to get that many new > traffic selectors in the future, so I do not think the TS types > explosion is going to be that big issue. That is fair. > If it gets same information during IKE_SA_INIT (missing > SECLABELS_SUPPORTED), it cannot trust that thing yet as other end is > not authenticated, so it will need to run IKE_AUTH to the end anyways > to make sure that there was no attack removing that > SECLABELS_SUPPORTED notification. So it will detect that error at the > end of IKE_AUTH always. > > In that case there is no point of adding notification to the > IKE_SA_INIT. Indeed. PUL From nobody Thu Dec 12 13:24:48 2019 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 2B4A2120142 for ; Thu, 12 Dec 2019 13:24:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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 Ow9wreAOJuJE for ; Thu, 12 Dec 2019 13:24:44 -0800 (PST) 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 6DA2B120121 for ; Thu, 12 Dec 2019 13:24:44 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 47Ymyz0xnzzDZs; Thu, 12 Dec 2019 22:24:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1576185883; bh=EnH3eMmmJ42cQxxiIygfA38hYyewjezWzncK97cuhmk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=b6sxkXXAik72hSHZcxa5IxxIwZ0KIeTX6xExoTATuK/5WM3HUFZoW6f+wCkT41l1S YthZrtgQQJ7gLGiLE2TIfj0w99rvHkFivM6NE9eS9RUOASqJJKqIa4vU4GGlA30YeA fh+E1W1z9P5nwU8zRqgQGc64petY4PSqWPmTSIIQ= 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 2MX5t_-pECVr; Thu, 12 Dec 2019 22:24:42 +0100 (CET) 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, 12 Dec 2019 22:24:42 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 4D5206007C4F; Thu, 12 Dec 2019 16:24:41 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 49B2C308EC; Thu, 12 Dec 2019 16:24:41 -0500 (EST) Date: Thu, 12 Dec 2019 16:24:41 -0500 (EST) From: Paul Wouters To: "Hu, Jun (Nokia - US/Mountain View)" cc: "ipsec@ietf.org WG" , Sahana Prasad In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Labeled IPsec options 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, 12 Dec 2019 21:24:46 -0000 On Wed, 11 Dec 2019, Hu, Jun (Nokia - US/Mountain View) wrote: > Subject: Re: [IPsec] Labeled IPsec options > > +1 for option4, +0.5 for option3 > One factor to consider is the granularity of label, for me it is per CHILD_SA; option1 is per TS (e.g TS with label and TS without label could be mixed in the same payload), option2 is per TS payload (e.g. you could have TSi with label, TSr without label) If you select multiple TS's these all become part of one Child SA. So I think the granularity of the label does not change between the solutions? > Option3 is a bit "abusing" the semantic of notification payload, since a "label notification" is not communicating a status, error or capability. A bit yes :) Paul From nobody Thu Dec 12 13:53:47 2019 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 EB81D12012C; Thu, 12 Dec 2019 13:53:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.419 X-Spam-Level: X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 F6bdorTU8acY; Thu, 12 Dec 2019 13:53:37 -0800 (PST) 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) by ietfa.amsl.com (Postfix) with ESMTPS id 82005120024; Thu, 12 Dec 2019 13:53:37 -0800 (PST) Received: by fireball.acr.fi (Postfix, from userid 15204) id 8030325C12DB; Thu, 12 Dec 2019 23:53:33 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24050.46813.494623.78865@fireball.acr.fi> Date: Thu, 12 Dec 2019 23:53:33 +0200 From: Tero Kivinen To: Benjamin Kaduk Cc: ipsec@ietf.org, draft-ietf-ipsecme-qr-ikev2@ietf.org In-Reply-To: <20191212204215.GZ13890@kduck.mit.edu> References: <157602964597.9873.4051369223279728575.idtracker@ietfa.amsl.com> <20191211021039.GZ13890@kduck.mit.edu> <24050.42321.185052.541103@fireball.acr.fi> <20191212204215.GZ13890@kduck.mit.edu> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 2 min X-Total-Time: 1 min Archived-At: Subject: Re: [IPsec] Datatracker State Update Notice: 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, 12 Dec 2019 21:53:41 -0000 Benjamin Kaduk writes: > On Thu, Dec 12, 2019 at 10:38:41PM +0200, Tero Kivinen wrote: > > Benjamin Kaduk writes: > > > It looks like the "reference" column for the registry dind't make it into > > > the -09, but I'm happy to include that change along with the last-call > > > feedback. > > > > If you are talking about the reference column of the IANA registries, > > then they are not needed in the draft (or rfc). IANA will normally add > > them automatically to the registries when doing the assignment. > > I was more interested in being clear that the new registry we're creating > should have a "Reference" column, than making sure new allocations from > existing registries get the proper reference listed. IANA will add that. Most of our previous RFCs do not explictly mention reference column when creating registry. In some cases we have that when we add to existing registry, especially if we are modifying the reference column values. > But there's plenty of time left in which to make that happen :) -- kivinen@iki.fi From nobody Thu Dec 12 15:18:22 2019 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 EC7B512012C for ; Thu, 12 Dec 2019 15:18:20 -0800 (PST) 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_DNSWL_NONE=-0.0001, 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 RVfqou8mCA2T for ; Thu, 12 Dec 2019 15:18:18 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C36112012A for ; Thu, 12 Dec 2019 15:18:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 776EB300B0C for ; Thu, 12 Dec 2019 18:18:16 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Q5QaNLMFdDf0 for ; Thu, 12 Dec 2019 18:18:14 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id 1ABF1300474; Thu, 12 Dec 2019 18:18:13 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <24050.43728.115813.170898@fireball.acr.fi> Date: Thu, 12 Dec 2019 18:18:14 -0500 Cc: IETF IPsec , Sahana Prasad Content-Transfer-Encoding: quoted-printable Message-Id: <32430816-736B-42E3-8988-85D4D3F6392E@vigilsec.com> References: <01f501d5b0b2$facb4370$f061ca50$@gmail.com> <24050.43728.115813.170898@fireball.acr.fi> To: Tero Kivinen , Valery Smyslov , Paul Wouters X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [IPsec] Labeled IPsec options 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, 12 Dec 2019 23:18:21 -0000 > On Dec 12, 2019, at 4:02 PM, Tero Kivinen wrote: >=20 > Valery Smyslov writes: >> I don't think option 4 is a good idea. If old responder=20 >> encounters an unknown payload with Critical bit set in IKE_AUTH, it = will >> return back UNSUPPORTED_CRITICAL_PAYLOAD and IKE SA won't be set up. >> See section 2.21.2 of RFC7296. This would require initiator to retry = from >> IKE_SA_INIT, doubling the work. Or it can create childless IKE SA >> and then try CREATE_CHILD_SA - not an optimal solution too. >=20 > Agree fully on that.=20 >=20 >> I also don't like option 2 since it requires changing the way TSs >> are handled in IKEv2. >=20 > Also agree. >=20 >> Option 1 looks like the clearest from pure theoretical point of view, >> however I agree that it could lead to TS types explosion in future. >=20 > Yes, I think option 1 would be most proper way of doing the > negotiation. I am not sure if we are going to get that many new > traffic selectors in the future, so I do not think the TS types > explosion is going to be that big issue. >=20 > Also in most setups I would expect security labels to be either always > mandatory or always omitted (and that information quite often comes > directly from configuration). I do not really see that common cases > where initiator would try to use security labels and responder not > supporting them. >=20 > I.e., if you do always require security labels, there is no TS > explosion as you only propose TS with security labels. If you do not > support them, you use normal TS. >=20 > You would propose both only if you do not care whether other end > supports security labels, but are willing to use them if it supports, > but what is the meaning of security labels then? Why even propose them > if you do not care what they are? If the initiator wants to use labels but the responder does not support = labels, will the initiator move forward anyway? Doing so would seem = surprising to me. The point of the label is to indicate what handling = is needed to adequately protect the data. Moving forward without the = responder agreeing to that handling seems unlikely to me. Are there = situations where moving forward is "the right thing"? If not, then Option 1 makes the most sense to me. Russ From nobody Thu Dec 12 17:09:43 2019 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 A57A01200FB for ; Thu, 12 Dec 2019 17:09:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=nokia.onmicrosoft.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 fqklNQ6Xt3jq for ; Thu, 12 Dec 2019 17:09:40 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130123.outbound.protection.outlook.com [40.107.13.123]) (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 95404120090 for ; Thu, 12 Dec 2019 17:09:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=axPt2EVOj5v3peL+P1YzsciK7FEmah7j2w7AwOR+epyH00DMxB/T3tOdZGuyqNSUtDJ4j6kVdTO4tKUV3uJIkN5gXvn5SaZrIiQdyONjHgBtLMpVH7YwnybjcYb0z6fqfEOVlJfCEM8/sGJRFj5lHqjUuJEPjpdi4mekZr4VD7htnaL0148f9DaOQa4iTrnTQ1k75JBf2afQ81iXkiOBHs4hsO4Aq2HM69yR8iFuO1+ht4Wiv1pdgdTxqtUtWBHLQzh8ujGHzE3ABAs2+7dsIGdzwmko0loCBI/z3OxjyygFL+efLFKwLUCwAmmeVVBoJtW+TcpPPKOZueErLC3eag== 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=PXaQ8siOBUB3LH9a6deslufo5c34qBTBFXVZfydDmHk=; b=h1lTG3gvpj044X6xUtUek7iQ6zL8TTOf/Qxm0Ww31qnRUUIpnxXSKjKWMjIyHnyJWXaCKBBw058PPMENgLcuIdVcGKCcxbFUzT0TTFx/matb15yA6ZD3UARsEX+SM///TR32y9IpRANOOzIa0EJLlLuPsQ6fo5ow3QqGl6LLJYsHSDL2ckQXZcO5B+n2LE8CN5CK/Fo65JRZsEmSHZc0vfwqiPT/nJgQC2mKLfs02P4VxB/Ys2TFeuY+s7y/FAXmgSavqsA/6LdyAkiKuafOHO4NXc4HPjsA85y+p6cDrDjztNjetoCvVMzplZgZYIv0RpYqIMW8UFkmbqmrd7Gg9w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PXaQ8siOBUB3LH9a6deslufo5c34qBTBFXVZfydDmHk=; b=vY3FdE1Yfmg0MNUbe0A5yN80mI9CO4krl8R/4FOi44it4zYry3j7/45xCmChGz+l6QLdvO6dL1h4OVA+qnd4wZtbEPuuWSLWv9f/Px3vLpNK4gbJ9a27XeQcsdJ/dqW+vWImMwitT7Ksx0itkBAzb0j4vK91om2VXPO9gxL74qM= Received: from AM5PR0701MB2353.eurprd07.prod.outlook.com (10.169.150.18) by AM5PR0701MB2292.eurprd07.prod.outlook.com (10.169.152.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.9; Fri, 13 Dec 2019 01:09:36 +0000 Received: from AM5PR0701MB2353.eurprd07.prod.outlook.com ([fe80::c00:ee6e:9763:f843]) by AM5PR0701MB2353.eurprd07.prod.outlook.com ([fe80::c00:ee6e:9763:f843%7]) with mapi id 15.20.2538.017; Fri, 13 Dec 2019 01:09:35 +0000 From: "Hu, Jun (Nokia - US/Mountain View)" To: Paul Wouters CC: "ipsec@ietf.org WG" , Sahana Prasad Thread-Topic: [IPsec] Labeled IPsec options Thread-Index: AQHVrxZ09uToqmx5zEOPjFh9TCkZuae1Rf+AgAHA9YCAAD0q8A== Date: Fri, 13 Dec 2019 01:09:35 +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: spf=none (sender IP is ) smtp.mailfrom=jun.hu@nokia.com; x-originating-ip: [98.234.123.80] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 91273852-952d-4b03-c7cc-08d77f691ea8 x-ms-traffictypediagnostic: AM5PR0701MB2292: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0250B840C1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(376002)(346002)(136003)(39860400002)(199004)(189003)(13464003)(6916009)(54906003)(6506007)(316002)(53546011)(9686003)(186003)(55016002)(7696005)(478600001)(26005)(81166006)(8676002)(8936002)(4326008)(81156014)(71200400001)(86362001)(33656002)(2906002)(52536014)(5660300002)(66476007)(66946007)(64756008)(76116006)(66446008)(66556008); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2292; H:AM5PR0701MB2353.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: UrLelRUTFhkt6t8Zuky4oJ0nJnBeD/h5WCrio1yNHpMpmp193a6QGI012yh5x4Uoi+RegHxKcHe9qHLqTX8cNa5F0mTQlHe2fxR1U+39lbC+33aGdh1U3Wlm+mMD5n03bj/UFeueU6vquiHbjMYxptgqb4jpfuCpC04OBoK8Gw4Q6VgPZwFyYWP8SGjf0XnSKFablCDC7xUKBwiqaTYc8o5l004eoj8TZGxoqM0JBO6u0WJpZ3/wo1waDR1fZ38BCoEDBbxyufCeG/gnHhnhYeEpI9/m/kTTj3a87WODMSW3yWk+Cu2HPNWrzy7l1ZuzcCC/mRshJgwODMvf2Hgz0mA9jgJ13AKet4hn1qfooPovz/vg0CLwxe09qDUSTtNYEDcKINxim9gtbIgCNs76ZtVDWd2hm8LF28pQfTwGonBpX3wiOhkZ0tpi9FK1E2XosTKI1wJ89LDe2uwRLlyw243tRcw0UHGC5bU5FoIVyp4wBa3iBMh5hvN9PA6sWbSd x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 91273852-952d-4b03-c7cc-08d77f691ea8 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Dec 2019 01:09:35.7976 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: NLiXm5ctDGyWiSlCvw8eTeL+UQIvKnzXiDa23Qu2bTj91HJvD7HCXahL0v2OAQE/ItQRZmVzHJi2KMHu1xdiDQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2292 Archived-At: Subject: Re: [IPsec] Labeled IPsec options 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, 13 Dec 2019 01:09:42 -0000 In line as [Hu Jun] -----Original Message----- From: Paul Wouters =20 Sent: Thursday, December 12, 2019 1:25 PM To: Hu, Jun (Nokia - US/Mountain View) Cc: ipsec@ietf.org WG ; Sahana Prasad Subject: Re: [IPsec] Labeled IPsec options On Wed, 11 Dec 2019, Hu, Jun (Nokia - US/Mountain View) wrote: > Subject: Re: [IPsec] Labeled IPsec options >=20 > +1 for option4, +0.5 for option3 > One factor to consider is the granularity of label, for me it is per=20 > CHILD_SA; option1 is per TS (e.g TS with label and TS without label=20 > could be mixed in the same payload), option2 is per TS payload (e.g.=20 > you could have TSi with label, TSr without label) If you select multiple TS's these all become part of one Child SA. So I thi= nk the granularity of the label does not change between the solutions? [Hu Jun] if we agree that label is per CHILD_SA, then with option 1 or 2, t= here is possibility for invalid TS combination, following are some examples= of invalid TS: - with option-1: There are two TS in TSi, first TS contains label-1, 2nd TS= contains label-2 - with option-2: TSi contains label-1, while TSr contains a different label= -2=20 With option-3/4 there is no such concern=20 =20 > Option3 is a bit "abusing" the semantic of notification payload, since a = "label notification" is not communicating a status, error or capability. A bit yes :) Paul From nobody Fri Dec 13 06:25:22 2019 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 50AE7120131 for ; Fri, 13 Dec 2019 06:25:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 dfnK8NUcyLni for ; Fri, 13 Dec 2019 06:25:18 -0800 (PST) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 1EA5812011D for ; Fri, 13 Dec 2019 06:25:18 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id 21so2880117ljr.0 for ; Fri, 13 Dec 2019 06:25:18 -0800 (PST) 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=Iddu3kimKnVt0P6uwRRgvE4IRmfM2+WUUBPfSfMxzeA=; b=B/J0SWWxNtsCcWGyszTGK7ZrZKwmZdk7W91HW3UtTGJK1uWmKgBKkltkM6D5X9DFHz 62A0NJJ3tlFLVWSFbWHLxsAcaa9LsLECGPA79T02hRGzw1+dMhvnpI4Qk/tc1l623tKs Rhi87YBCzVvUwGiJc6kVBAuYFL1g9O2laN1UifDnCj9+ZnhHQN6BLRU7FwVEUdtP76Wg WAihF3STVIDriWPOzk08xIHTuy3MLDkGj15iTa73ZLly54eAyb5S/jk0YJ/HIYi7aCSq MnAmW7bC945FC6K28LY9WFgECjr3FrK1OxGsdhkCvj6n3k2GCx1h0YlllCRLWhJdBJ36 IYfQ== 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=Iddu3kimKnVt0P6uwRRgvE4IRmfM2+WUUBPfSfMxzeA=; b=V6h8oWRUCtoRceCISav5OWPFmhJCc4GwyNtsQMJgmrI1vWncSqVpDVECOXgHRW8TxS PXnGVDq3WffGLstU38/nghZyXcN50dklBoF5AUKRKmLVPp2mg/53BLGZML/5D9yxVX+p 4TCG264EtWHxF9PWtPS65n0Q03AHjJ8mPBqTsfFu0EYq7T1q0prfRGoiq7BzB23D4xjy 7nXLB/OX08qlREf4EeuGQUhPYyzZC9Quw546BOGRtpAJBNOXE2f6iqN2vL9oBRnH/e84 I4Bz9fpXUufZ/uhhiHmrd4vwJ2Pj+T5qkysb0r/DNaGbcE/ViFSZ4OAXml/FAKTnqfOH JEOg== X-Gm-Message-State: APjAAAXiBkicSyUdsG02o8I0WFa5Ru3EBJsy5FQygfho7KpXA9JjNVe8 oqao3mUYjHNDGSEDV3U43ucCMtSQ X-Google-Smtp-Source: APXvYqzz5QtGDt8Zsr+Jz+1/Apa7K9UiV0crsvjZwVZHxvvRlKkDQcwJb9CZQCXE20N+i2qd2ogTng== X-Received: by 2002:a2e:b045:: with SMTP id d5mr9874146ljl.184.1576247116170; Fri, 13 Dec 2019 06:25:16 -0800 (PST) Received: from svannotebook ([185.48.36.95]) by smtp.gmail.com with ESMTPSA id g14sm4928711ljj.37.2019.12.13.06.25.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Dec 2019 06:25:15 -0800 (PST) From: "Valery Smyslov" To: "'Paul Wouters'" Cc: , "'Sahana Prasad'" References: <01f501d5b0b2$facb4370$f061ca50$@gmail.com> In-Reply-To: Date: Fri, 13 Dec 2019 17:25:14 +0300 Message-ID: <046001d5b1c1$232c7be0$698573a0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLx+ZsZ28gCWkLjxf5xPWFraxjS5AGiqmCDAKLVkHulbV650A== Content-Language: ru Archived-At: Subject: Re: [IPsec] Labeled IPsec options 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, 13 Dec 2019 14:25:20 -0000 Hi Paul, > > I don't think option 4 is a good idea. If old responder encounters an > > unknown payload with Critical bit set in IKE_AUTH, it will return back > > UNSUPPORTED_CRITICAL_PAYLOAD and IKE SA won't be set up. > > See section 2.21.2 of RFC7296. This would require initiator to retry > > from IKE_SA_INIT, doubling the work. Or it can create childless IKE SA > > and then try CREATE_CHILD_SA - not an optimal solution too. > > I don't think that matters. Security labels are never optional but always > mandatory. And it seems very unlikely to have a mix of child sa's with and > without label. So they will all have a label, and then failing the IKE SA is fine, Do you want to say, that it's impossible to have two SGWs with multiple networks behind them so, that traffic from some networks will have security labels and traffic from the others won't have? If such a configuration is possible, then it's perfectly OK to have a mix of labelled and non-labelled IPsec SAs created by one IKE SA. Regards, Valery. > since no single child sa will be able to be setup anyway. It's better than the > responder setting up an SA that needs to be torn down by the initiator sending > a delete. > > > Option 1 looks like the clearest from pure theoretical point of view, > > however I agree that it could lead to TS types explosion in future. > > > > Option 3 looks like a compromise from practical point of view. > > You can solve the problem of imperfect error handling by adding a new > > SECLABES_SUPPORTED notification, that must be exchanged in > > IKE_SA_INIT. If both peers support seclabels, then > > But you really mean SECLABEL_REQUIRED? The "supported" > keyword here is misleading. The problem of doing this in IKE_SA_INIT is that it > could result in a spoofed answers omiting the payload? > > > the responder must not ignore seclabel notifications in IKE_AUTH and > > CREATE_CHILD_SA. The drawback is that we need one more notification > > and it must be exchanged in IKE_SA_INIT, increasing its message size. > > Not a big deal. > > So I'm not sure I trust this design. > > Paul From nobody Fri Dec 13 06:32:10 2019 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 1B8F512011D for ; Fri, 13 Dec 2019 06:32:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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 P78AZ-wsie5V for ; Fri, 13 Dec 2019 06:32:06 -0800 (PST) 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 A213C12009E for ; Fri, 13 Dec 2019 06:32:06 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 47ZCmP2VhQzDRm; Fri, 13 Dec 2019 15:32:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1576247525; bh=5VKfGiXLR4hdrYAEc53Np0ViMkzjcVUYsiy+3qMjh64=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=cpmnCdW7rvN48S3LzI+BBhnqjPlnqIqtDF1rOBDJYFDbi+m13gOzeQa+ZU1+6XW0e uihsq/Sg48AeZaCo5KULKi7A4kYJXtX3J0C1qUWDXFsRUdnIag6PsoriLoAe3E4Owy hy7e9uANSGFc/67vo1F+c6HJ9HfCgBH6Tyq8ZTRo= 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 p59ps_6y477p; Fri, 13 Dec 2019 15:32:04 +0100 (CET) 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, 13 Dec 2019 15:32:04 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 816066007ADD; Fri, 13 Dec 2019 09:32:03 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7DD5066AA8; Fri, 13 Dec 2019 09:32:03 -0500 (EST) Date: Fri, 13 Dec 2019 09:32:03 -0500 (EST) From: Paul Wouters To: Valery Smyslov cc: ipsec@ietf.org, 'Sahana Prasad' In-Reply-To: <046001d5b1c1$232c7be0$698573a0$@gmail.com> Message-ID: References: <01f501d5b0b2$facb4370$f061ca50$@gmail.com> <046001d5b1c1$232c7be0$698573a0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Labeled IPsec options 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, 13 Dec 2019 14:32:08 -0000 On Fri, 13 Dec 2019, Valery Smyslov wrote: >> I don't think that matters. Security labels are never optional but always >> mandatory. And it seems very unlikely to have a mix of child sa's with and >> without label. So they will all have a label, and then failing the IKE SA >> is fine, > > Do you want to say, that it's impossible to have two SGWs with multiple > networks behind them so, that traffic from some networks will have security > labels and traffic from the others won't have? I'm not saying it is impossible. I am saying it is not likely to be a real life configuration. If you classify network traffic with labels, your goal is to not have unlabeled traffic come in at all. You might have a label SEC_WHATEVER, but it still seems far more likely you would mark the traffic as having come from SGWx with some kind of LABELx to track the origin throughout your network. > If such a configuration is possible, then it's perfectly OK to have a mix > of labelled and non-labelled IPsec SAs created by one IKE SA. I'd argue the reverse. It would likely be better not to allow such an awful configuration :) Paul From nobody Fri Dec 13 06:51:46 2019 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 3A43C120219 for ; Fri, 13 Dec 2019 06:51:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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 yakDJj5io3rx for ; Fri, 13 Dec 2019 06:51:43 -0800 (PST) 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 0E350120855 for ; Fri, 13 Dec 2019 06:51:23 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 47ZDBd5kffzDXJ; Fri, 13 Dec 2019 15:51:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1576248681; bh=TVm6bQUaUoI7Yp0qi8sAezZ9t8awqeHjdvr9SMfv9fg=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=kbEX+T+PrWCF2O/Qwi5OCNpPQeBuMHfa891EigzIGaDNVPdrUYa/A5elnaEjiVH3F 3p6JEfMrYxz5nF50DcqW/WyHSafB0XRa/vhNF6fqjAAbG3FRTqvTnoVLQxkes2VpSw ndsrqQL5+SEM8KX/5LbFPD8bhT4AV7gYIQEnbcUI= 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 TN7MR7MRfp7c; Fri, 13 Dec 2019 15:51:20 +0100 (CET) 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, 13 Dec 2019 15:51:20 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id CB2F26007ADD; Fri, 13 Dec 2019 09:51:19 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C792066AA8; Fri, 13 Dec 2019 09:51:19 -0500 (EST) Date: Fri, 13 Dec 2019 09:51:19 -0500 (EST) From: Paul Wouters To: "Hu, Jun (Nokia - US/Mountain View)" cc: "ipsec@ietf.org WG" , Sahana Prasad In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Labeled IPsec options 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, 13 Dec 2019 14:51:44 -0000 On Fri, 13 Dec 2019, Hu, Jun (Nokia - US/Mountain View) wrote: >> If you select multiple TS's these all become part of one Child SA. So I think the granularity of the label does not change between the solutions? > > [Hu Jun] if we agree that label is per CHILD_SA, then with option 1 or 2, there is possibility for invalid TS combination, following are some examples of invalid TS: > - with option-1: There are two TS in TSi, first TS contains label-1, 2nd TS contains label-2 This issue is similar to network ranges though. Say you want to have: 10.0.1.0/24 <-> 192.168.0.0/16 10.0.2.0/24 <-> 172.16.100.0/24 Then you can also not have a TSi containing 10.0.1.0/24, 10.0.2.0/24 and a TSr containing 192.168.0.0/16, 172.16.100.0/24 With 10.0.1.0/24+SEC_LABEL1 and 10.0.1.0/24+SEC_LABEL2 youl have a similar issue, that is you would need to use a seperate CREATE_CHILD_SA to prevent the mixup of TS elements. > - with option-2: TSi contains label-1, while TSr contains a different label-2 Yes, see above. > With option-3/4 there is no such concern Since the notify or new payload type would be the same for all other TS parts, you do have the same problem. You also need a different CREATE_CHILD_SA negotiation to specify the different label. So I don't think what you describe is a new issue only affecting some of the solution options. All solutions need a similar workaround to prevent the mixup. Paul From nobody Fri Dec 13 06:52:47 2019 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 CAC6112011D for ; Fri, 13 Dec 2019 06:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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 0CLVm9UBj-yw for ; Fri, 13 Dec 2019 06:52:45 -0800 (PST) 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 F241412009E for ; Fri, 13 Dec 2019 06:52:44 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 47ZDDC55lhzDXJ; Fri, 13 Dec 2019 15:52:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1576248763; bh=B32f+sA5EHQE3mUxxAjFV4X4HlEFt8lDxGV+Ln/kj9I=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Mv4ck0SzAV9QPRv+Ru8wXd+FSI9sCr3rnvvBouCJ8k0q4Gekt9cY7KD2Cv9+hZ/BH S7mAKLETjZnW7HoOJIoCSoeR6sgDXQmPCv4A+9AdPzPNX7+yAxxEZ3u0+vMsdnR0pv 0fiZAzNjSVqbzMCWptCb51un0W73OSWtGsa1KdPo= 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 UEloh2YJyKwq; Fri, 13 Dec 2019 15:52:42 +0100 (CET) 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, 13 Dec 2019 15:52:42 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 0353A6007ADD; Fri, 13 Dec 2019 09:52:42 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0218166AA8; Fri, 13 Dec 2019 09:52:42 -0500 (EST) Date: Fri, 13 Dec 2019 09:52:41 -0500 (EST) From: Paul Wouters To: Russ Housley cc: Tero Kivinen , Valery Smyslov , IETF IPsec , Sahana Prasad In-Reply-To: <32430816-736B-42E3-8988-85D4D3F6392E@vigilsec.com> Message-ID: References: <01f501d5b0b2$facb4370$f061ca50$@gmail.com> <24050.43728.115813.170898@fireball.acr.fi> <32430816-736B-42E3-8988-85D4D3F6392E@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Labeled IPsec options 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, 13 Dec 2019 14:52:46 -0000 On Thu, 12 Dec 2019, Russ Housley wrote: > If the initiator wants to use labels but the responder does not support labels, will the initiator move forward anyway? Doing so would seem surprising to me. The point of the label is to indicate what handling is needed to adequately protect the data. Moving forward without the responder agreeing to that handling seems unlikely to me. Are there situations where moving forward is "the right thing"? I don't think anyone has come up with a real use case where the security labels are optional. > If not, then Option 1 makes the most sense to me. noted. Paul From nobody Fri Dec 13 06:52:56 2019 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 28BA31208E2 for ; Fri, 13 Dec 2019 06:52:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 g5LNJC-73CLf for ; Fri, 13 Dec 2019 06:52:53 -0800 (PST) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 2300A12011D for ; Fri, 13 Dec 2019 06:52:53 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id m6so2878317ljc.1 for ; Fri, 13 Dec 2019 06:52:53 -0800 (PST) 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=FWKiHBxKIO6BIX3VM+tE/jGt7NdGVijEP9HZtsWiZzI=; b=rkYl413U5vk2etB47+zGUe1pNCOntKtTCCL6vHisUwhwGEEagbt2Gf0I2Yh+yq0UTf J9w2n83jbc5xvya+e+LZYHtlFw2yyBY1Di4Fncnv1Tbob2/LnRfkUNjZUJk/60nC9xdB wfSLFWcjdkwpWN9f25FutpAYteOx4d68IN6DNY+K/yJSVRK5BkzhFZNWHGr/QwwQlFlr 6kyc0zGMCvR26uImuVvnGSi2gPrDsnfn6Iaa2sMtbVs8E0khwM1uqdSJ8Bm9dxIk2hqF r3Y9iFynGZsYALi6iMb0vCmAaCc6B+TEsotLfG2z0SvrOusewhzCfD+bnotdUig5yYM9 Zn/A== 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=FWKiHBxKIO6BIX3VM+tE/jGt7NdGVijEP9HZtsWiZzI=; b=I8k7ypWOrrJFsIYuWfEXzYcjlM+Q1XjM9YFRgAQkLkZsipSoxfhIJJZyu1ywKquyTs J0Cb8rnIMHNQ94LawLo4gClt/nkM/tVr/BbhngSey2aICs3l0e4rQXqV760GWqyfCOPq eKbPRJhGexziqN7XKk0PqW90bEUo5mDUw23y8mhAEWyzNvdhzrVL2sgqMks+xtjghCaU Ff+LEWttvtGu6MBfSFbOAmUFqtmJpCSpV8yvi+J6VeJOdcULNGzFtxAtWUwHZ0zjfj4P 2AsEpnT7NWU92m2dVHd3kiBBQ04b4GCeJPid/I9tZ6upuRKAvdjPPSbLi5P8GNDGmgRU I/ZA== X-Gm-Message-State: APjAAAWo3HKnGLQ0D1JCHFG8ErlRXBVBScQnAegYESwxlSgiMLzW+isJ v8VjWKu0/LfeSMxNJY0gEshEuGlr X-Google-Smtp-Source: APXvYqwqQjxR9GVcEzPJNYQmKcSkd0fD7Qg80gFcwnlE5rKL0pmczR9Zcxb8vfYgSBsVPRT/tR3/tg== X-Received: by 2002:a2e:8698:: with SMTP id l24mr10135298lji.94.1576248771042; Fri, 13 Dec 2019 06:52:51 -0800 (PST) Received: from svannotebook ([185.48.36.95]) by smtp.gmail.com with ESMTPSA id y25sm4673742lfy.59.2019.12.13.06.52.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Dec 2019 06:52:50 -0800 (PST) From: "Valery Smyslov" To: "'Paul Wouters'" Cc: , "'Sahana Prasad'" References: <01f501d5b0b2$facb4370$f061ca50$@gmail.com> <046001d5b1c1$232c7be0$698573a0$@gmail.com> In-Reply-To: Date: Fri, 13 Dec 2019 17:52:49 +0300 Message-ID: <046301d5b1c4$fdad5840$f90808c0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLx+ZsZ28gCWkLjxf5xPWFraxjS5AGiqmCDAKLVkHsB/ZSllADlO9DtpVZRu8A= Content-Language: ru Archived-At: Subject: Re: [IPsec] Labeled IPsec options 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, 13 Dec 2019 14:52:55 -0000 > >> I don't think that matters. Security labels are never optional but > >> always mandatory. And it seems very unlikely to have a mix of child > >> sa's with and without label. So they will all have a label, and then > >> failing the IKE SA is fine, > > > > Do you want to say, that it's impossible to have two SGWs with > > multiple networks behind them so, that traffic from some networks will > > have security labels and traffic from the others won't have? > > I'm not saying it is impossible. I am saying it is not likely to be a real life > configuration. If you classify network traffic with labels, your goal is to not > have unlabeled traffic come in at all. You might have a label SEC_WHATEVER, > but it still seems far more likely you would mark the traffic as having come > from SGWx with some kind of LABELx to track the origin throughout your > network. > > > If such a configuration is possible, then it's perfectly OK to have a > > mix of labelled and non-labelled IPsec SAs created by one IKE SA. > > I'd argue the reverse. It would likely be better not to allow such an awful > configuration :) So, am I right that you want all IPsec SAs created from a single IKE SA to either have labels or not? If so, then it looks like an IKE SA property, and thus an ability to use labels should really be negotiated when IKE SA is created (well, I don't care whether it is SECLABELS_SUPPORTED or SECLABELS_REQUIRED notification :-)). And since peers know that seclabels are supported, we won't have any problems with legacy implementations (for example, the responder cannot ignore label in notification in option 3). Regards, Valery. > > Paul From nobody Fri Dec 13 06:59:08 2019 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 376C5120154 for ; Fri, 13 Dec 2019 06:59:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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 zpEPBdUq5-sy for ; Fri, 13 Dec 2019 06:59:06 -0800 (PST) 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 21B2512011D for ; Fri, 13 Dec 2019 06:59:06 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 47ZDMX60TQzDZ5; Fri, 13 Dec 2019 15:59:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1576249144; bh=MQxjjLqfVYuKFwrXc9W+Skid5zsVPE4Y/we4VLitPFM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=mWqEwNpm9tsOJnBZOBIGv5Ye+So48vspzKsfc/55pGj//sBzYgkfGJdLkrO1UQvQ3 8w1z64LcvPxU2R6Z/W16OA54uCPNOxYKuF9Uq40R7czGXIg4iMqNQtdHahLIotUYPk BeGsnlmpfsDXY9VpRFRN4FFJ1AfDFFeQEbNd+voE= 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 m9RJ6N-XDfnN; Fri, 13 Dec 2019 15:59:03 +0100 (CET) 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, 13 Dec 2019 15:59:03 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id D88CA6007ADD; Fri, 13 Dec 2019 09:59:02 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D502666AA8; Fri, 13 Dec 2019 09:59:02 -0500 (EST) Date: Fri, 13 Dec 2019 09:59:02 -0500 (EST) From: Paul Wouters To: Valery Smyslov cc: ipsec@ietf.org, 'Sahana Prasad' In-Reply-To: <046301d5b1c4$fdad5840$f90808c0$@gmail.com> Message-ID: References: <01f501d5b0b2$facb4370$f061ca50$@gmail.com> <046001d5b1c1$232c7be0$698573a0$@gmail.com> <046301d5b1c4$fdad5840$f90808c0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Labeled IPsec options 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, 13 Dec 2019 14:59:07 -0000 On Fri, 13 Dec 2019, Valery Smyslov wrote: >>>> I don't think that matters. Security labels are never optional but >>>> always mandatory. And it seems very unlikely to have a mix of child >>>> sa's with and without label. So they will all have a label, and then >>>> failing the IKE SA is fine, >>> >>> Do you want to say, that it's impossible to have two SGWs with >>> multiple networks behind them so, that traffic from some networks will >>> have security labels and traffic from the others won't have? >> >> I'm not saying it is impossible. I am saying it is not likely to be a real > life >> configuration. If you classify network traffic with labels, your goal is > to not >> have unlabeled traffic come in at all. You might have a label > SEC_WHATEVER, >> but it still seems far more likely you would mark the traffic as having > come >> from SGWx with some kind of LABELx to track the origin throughout your >> network. >> >>> If such a configuration is possible, then it's perfectly OK to have a >>> mix of labelled and non-labelled IPsec SAs created by one IKE SA. >> >> I'd argue the reverse. It would likely be better not to allow such an > awful >> configuration :) > > So, am I right that you want all IPsec SAs created from a single IKE SA to > either > have labels or not? I described what I think are real life scenarios between two gateways. I was not specifying whether did appeared in a single IKE SA or a single IKE_AUTH/CREATE_CHILD_SA. See my previous email how we also have IPV4 ranges that we find are not combinable and thus we need to use a seperate CREATE_CHILD_SA to install the subset of allowed v4 combinations. The same would apply to labels. > If so, then it looks like an IKE SA property, and thus > an ability > to use labels should really be negotiated when IKE SA is created I don't think there is a need to ban the option to do it in seperate exchanges. I don't think we need to force admins to create two IKE SA's between the same endpoints to get labeled and unlabeled IPsec SA's. > (well, I don't care whether it is SECLABELS_SUPPORTED or SECLABELS_REQUIRED > notification :-)). And since peers know that seclabels are supported, we > won't > have any problems with legacy implementations (for example, the responder > cannot ignore label in notification in option 3). Sure, but one suggests the code can do it, the other suggests the configuration insists on it. It avoids the implementor question of "if we understand seclabels, but this connection does not use/require them, should I answer a SECLABELS_SUPPORTED notify with a reply?". Paul From nobody Fri Dec 13 07:04:27 2019 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 4A474120013 for ; Fri, 13 Dec 2019 07:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 k8c0DIEJeD0P for ; Fri, 13 Dec 2019 07:04:24 -0800 (PST) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 8F7C312009E for ; Fri, 13 Dec 2019 07:04:24 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id c19so2955138lji.11 for ; Fri, 13 Dec 2019 07:04:24 -0800 (PST) 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=eJq8Q256aEMe5YMtfS9yYO2nkGKB5zdPwy9slNCPsD0=; b=rkj6bShL4Tsks2yuFR1C3H4TlgCLAHQXrsyuXe2pTVNHn/dwclmnaxANhd9D1rAFS3 oA8u3hrp23C1RN+9fhE55c3oidVKsqpl6NRKHWou6NcbPvxzX2EnNGP6NtzAVsxUtV0s ANNCtf1yTm2FkcDgnwoLBgza4z6AJKZFdJDgtYYyVNhc2ai+XYeh0EzoUVZUTbb0BezH 7FYb6eK9anZnmuL1ai4QVfMaudwL4Uya+Pb3HIUWnde6VBKKue8In6/bYMwuup3DEF2C Pjsxe836gAMRdc1U5+4cyAsOSXbYSrrsSzMtk+TPEhtGm6KTSIOEAzSTY2wSG8tO+8LD FLTg== 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=eJq8Q256aEMe5YMtfS9yYO2nkGKB5zdPwy9slNCPsD0=; b=IHeHHsnZUrigzRTWpSIwQXr8jx3w3WLA4cZ/qvMNMHqXFmuTGjSInqixI4xUwNzmCe WkEUdSy9bfpp7v05lrFl1/w1uvKS9rm1MzP41fEpuJ0nP61uOwqT2NhMS0SOuhsc9KNr ++4RM7a3qtwocmGwVHIJmeZdJDmgQW7BrceLXeH2avlumpMvqeezy7thW2tya74Y1gAd qEzELkumjkyzaWFSPxfuDTul17ZNx4qFMmeJ5ZI/pCeTAgsnncngDLzA4yqDOKEUAQOn UlYmvrpTmLr2Q3n19oAwPvViY2ycNQQsthWRdWHsBEKA4SDCEIhPbAsLrS+fuU24w9IY 8cng== X-Gm-Message-State: APjAAAVX9ItriG731JMphnIvWvxkcfdj3a99D1re60CoK46lnlflNXJP q3mCVCJuiUZNGDNzdYe1XPOa47aV X-Google-Smtp-Source: APXvYqy4cIG5+6m3IMB/nfJqNYDuWkMkJMONZk/hMTXGEOncrP42Picv8RmxGirX19ACbUyVYv4X7g== X-Received: by 2002:a2e:7405:: with SMTP id p5mr9964634ljc.34.1576249461102; Fri, 13 Dec 2019 07:04:21 -0800 (PST) Received: from svannotebook ([185.48.36.95]) by smtp.gmail.com with ESMTPSA id 145sm4939423ljj.69.2019.12.13.07.04.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Dec 2019 07:04:20 -0800 (PST) From: "Valery Smyslov" To: "'Tero Kivinen'" Cc: , "'Sahana Prasad'" , "'Paul Wouters'" References: <01f501d5b0b2$facb4370$f061ca50$@gmail.com> <24050.43728.115813.170898@fireball.acr.fi> In-Reply-To: <24050.43728.115813.170898@fireball.acr.fi> Date: Fri, 13 Dec 2019 18:04:16 +0300 Message-ID: <046401d5b1c6$98ed09d0$cac71d70$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLx+ZsZ28gCWkLjxf5xPWFraxjS5AGiqmCDANTXOjyla9tAYA== Content-Language: ru Archived-At: Subject: Re: [IPsec] Labeled IPsec options 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, 13 Dec 2019 15:04:26 -0000 Hi Tero, > > You can solve the problem of imperfect error handling by adding a new > > SECLABES_SUPPORTED notification, that must be exchanged in > > IKE_SA_INIT. If both peers support seclabels, then the responder must > > not ignore seclabel notifications in IKE_AUTH and CREATE_CHILD_SA. The > > drawback is that we need one more notification and it must be > > exchanged in IKE_SA_INIT, increasing its message size. Not a big deal. > > I am not sure we need that. I mean if initiator do require security labels and > sends security labels notification, but responder does not reply to them, what > can it do next? There isn't going to be any communications between the peers > in that case, so it should simply tear down the SA anyways. The SA won't be created in this case, since the initiator stopped creating it by not initiating IKE_AUTH. > If it gets same information during IKE_SA_INIT (missing > SECLABELS_SUPPORTED), it cannot trust that thing yet as other end is not > authenticated, so it will need to run IKE_AUTH to the end anyways to make > sure that there was no attack removing that SECLABELS_SUPPORTED > notification. So it will detect that error at the end of IKE_AUTH always. Well, the situation is no worse than with NO_PROPOSAL_CHOSEN or with USE_PPK. In brief - if an attacker is so powerful, that it can remove packets from the network and replace them with forged ones, then it can break communication anyway (just drop all packets). On the other hand, if an attacker can only inject packets, then the responder's packet will eventually reach the initiator. In our case the strategy for initiator is: retransmit and wait. If even after several retransmission it doesn't receive message with SECLABELS_SUPPORTED, then there is no reason to continue with IKE_AUTH (if using labels is mandatory for initiator). If it receives a message with SECLABELS_SUPPORTED, then go with it. Regards, Valery. > In that case there is no point of adding notification to the IKE_SA_INIT. > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Dec 13 12:18:00 2019 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 E1D0112008B; Fri, 13 Dec 2019 12:17:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christer Holmberg via Datatracker To: Cc: ipsec@ietf.org, last-call@ietf.org, draft-ietf-ipsecme-qr-ikev2.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Christer Holmberg Message-ID: <157626827886.12929.4367951047776204825@ietfa.amsl.com> Date: Fri, 13 Dec 2019 12:17:58 -0800 Archived-At: Subject: [IPsec] Genart last call review of draft-ietf-ipsecme-qr-ikev2-09 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: Fri, 13 Dec 2019 20:17:59 -0000 Reviewer: Christer Holmberg Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-ipsecme-qr-ikev2-09 Reviewer: Christer Holmberg Review Date: 2019-12-13 IETF LC End Date: 2019-12-25 IESG Telechat date: Not scheduled for a telechat Summary: The document is well-written, and almost ready for publication. However, I have a couple of minor comments that I would like the authors to address. Major issues: None Minor issues: Q1: The Security Considerations lists IKEv2/IPSec algorithms that are not considered quantum-resistant. However, that is not mentioned anywhere else. I think it would be good to mention that in the Abstract and/or Introduction. Q2: Section 3 says: "If the responder does not support this specification or does not have any PPK configured, then it ignores the received notification and continues with the IKEv2 protocol as normal." I assume the ignoring of a non-supported notification and continuing with normal IKEv2 is part of the IKEv2 specification. If so, I suggest to say add something like: ", as described in RFCXXXX." Nits/editorial comments: Q3: The Security Considerations talk about the Grover's algorithm. Please add a reference. From nobody Fri Dec 13 12:28:50 2019 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 634B412008B; Fri, 13 Dec 2019 12:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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 nka9dvBsDP4y; Fri, 13 Dec 2019 12:28:47 -0800 (PST) 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 F40D7120888; Fri, 13 Dec 2019 12:28:25 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 47ZMgV6410zF6f; Fri, 13 Dec 2019 21:28:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1576268902; bh=Gberw/jHi1EjdfaDCqBN6cSyqwBvtXWVygUhZvMLfzM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=D8KI0EjwdaqWl9YAHISCmA06TQOJCrYAFOXfhcsbHzbfzNC0TFX5gYpyBEm+SlfUr bLuw+QnYhjxW4FwavBDyQ/Z7bwX0OSeIBdZ+ckHKRX8yG7uCunavt5u4HNi6DBycjR hfsd2yP0ahpELA46GSPq+GUbIDYeFF68/L604Upo= 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 lryujhk-9fbE; Fri, 13 Dec 2019 21:28:21 +0100 (CET) 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, 13 Dec 2019 21:28:21 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id C51106007ADD; Fri, 13 Dec 2019 15:28:20 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C457066AA8; Fri, 13 Dec 2019 15:28:20 -0500 (EST) Date: Fri, 13 Dec 2019 15:28:20 -0500 (EST) From: Paul Wouters To: "Salz, Rich" cc: Paul Hoffman , "ipsec@ietf.org" , "last-call@ietf.org" , Kenny Paterson In-Reply-To: <1BB9D55C-7880-4ABF-AD82-F0C1F8FC04A5@akamai.com> Message-ID: References: <157607548927.11531.316316195814237240.idtracker@ietfa.amsl.com> <1BB9D55C-7880-4ABF-AD82-F0C1F8FC04A5@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] [Last-Call] Last Call: (Postquantum Preshared Keys for IKEv2) to Proposed Standard 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, 13 Dec 2019 20:28:48 -0000 On Wed, 11 Dec 2019, Salz, Rich wrote: >> A much better title would be > "Mixing Preshared Keys in IKEv2 for Postquantum Resistance". > > That's better. > > I misunderstood the document as both you and David Mcgrew kindly explained. I withdraw my concerns and hope the title is changed. I am fine with the title change (and publication). We have long ago implemented this and performed a number of interop tests. Paul From nobody Sun Dec 15 23:48:29 2019 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 D8BC0120025; Sun, 15 Dec 2019 23:48:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Barry Leiba via Datatracker To: "The IESG" Cc: ipsecme-chairs@tools.ietf.org, ipsecme-chairs@ietf.org, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <157648250284.11650.7617421500571091763.idtracker@ietfa.amsl.com> Date: Sun, 15 Dec 2019 23:48:22 -0800 Archived-At: Subject: [IPsec] Barry Leiba's No Objection on charter-ietf-ipsecme-12-00: (with COMMENT) 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, 16 Dec 2019 07:48:23 -0000 Barry Leiba has entered the following ballot position for charter-ietf-ipsecme-12-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Some wordsmithing on the two new paragraphs, mostly correcting grammar errors and awkward wording: NEW RFC8229, published in 2017, specifies how to encapsulate IKEv2 and ESP traffic in TCP. Implementation experience has revealed that not all situations are covered in RFC8229, and that may lead to interoperability problems or to suboptimal performance. The WG will provide a document to give implementors more guidance about how to use reliable stream transport in IKEv2 and clarify some issues that have been discovered. A possible starting point is draft-smyslov-ipsecme-tcp-guidelines. The demand for Traffic Flow Confidentiality has been increasing in the user community, but the current method defined in RFC4303 (adding null padding to each ESP payload) is very inefficient in its use of network resources. The working group will develop an alternative TFC solution that uses network resources more efficiently. END From nobody Mon Dec 16 02:19:56 2019 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 54B9912018D; Mon, 16 Dec 2019 02:19:51 -0800 (PST) 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: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <157649159129.21546.1759543447284728344@ietfa.amsl.com> Date: Mon, 16 Dec 2019 02:19:51 -0800 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-iptfs-00.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, 16 Dec 2019 10:19:51 -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 : IP Traffic Flow Security Author : Christian Hopps Filename : draft-ietf-ipsecme-iptfs-00.txt Pages : 25 Date : 2019-12-16 Abstract: This document describes a mechanism to enhance IPsec traffic flow security by adding traffic flow confidentiality to encrypted IP encapsulated traffic. Traffic flow confidentiality is provided by obscuring the size and frequency of IP traffic using a fixed-sized, constant-send-rate IPsec tunnel. The solution allows for congestion control as well. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-00 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-iptfs-00 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 Dec 16 03:10:47 2019 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 EAFF71200FA; Mon, 16 Dec 2019 03:10:45 -0800 (PST) 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: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <157649464589.21642.12936346733885439093@ietfa.amsl.com> Date: Mon, 16 Dec 2019 03:10:45 -0800 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-intermediate-03.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, 16 Dec 2019 11:10:46 -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-03.txt Pages : 11 Date : 2019-12-16 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-03 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-intermediate-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-intermediate-03 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 Dec 16 03:15:16 2019 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 1734812023E for ; Mon, 16 Dec 2019 03:15:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 S-a1yMU3so-3 for ; Mon, 16 Dec 2019 03:15:14 -0800 (PST) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 A6F45120233 for ; Mon, 16 Dec 2019 03:15:13 -0800 (PST) Received: by mail-wr1-x434.google.com with SMTP id z7so6696580wrl.13 for ; Mon, 16 Dec 2019 03:15:13 -0800 (PST) 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=4JdRCnKIKMgeFlW4u0YIxmafy8OTiaHkShnRuuEdvUw=; b=kfrNUt0vsS3cBap3otrjNyVvhMFsHLfTdhy/oGLc/PsHi+hK5Z0CnXJuCmPwDaNMVh a1e0NkW7WUXkZDdyZWG79atcTMaAzbVcQbj1Uwk69huEbUS8HziLTYPpmt5DGft1T2fs v6e1Gu43J8i/bmniQ5TPbFVY6kaO0JXu8Oav+hrFlMiX/vQc8z0W0nW2bfAOJ8gdLO4g pebgIpHlaEf5gSix5KFOief/l1i9mIWCxNtRMa1NXDV+uL8fJ3ID6PIu+lJkTy24pc76 UT2GgRmOPtMtOixQYDP7JjGXlU3N9EUEfTV3ueV8UbCgdnuTpgxLEoR86FUv5AjTMTZC btMA== 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=4JdRCnKIKMgeFlW4u0YIxmafy8OTiaHkShnRuuEdvUw=; b=DCfVqlwM/z1z/3Va0alIivxI/vPZ4eJwEiT4snrsX3FkLTzCzVjVAZb1ZzqYS645fO Cfo7jFfrRYd+Q//fmJMsLDiXR9yRQ5EZAT9Fp0rKA408Ga6JsKDfAHaeD+Cy/juGh+1n ecNs8oYCnzaoY5wg0cH6rKqholv4BAsOKCEKeOyCv28W0Fz4olkajxSLCwkYvB6kJZ78 OMBtzdbKcyNgjISoHzzvhQnzv6Cn/AUrqLNsnV9qFaAnIJyulbmx0l8J/5kwDAcBFA6J miK6lp7P6BewGniGgPH7bTmmONbJJDOxVbaPt8dZAAyjYugORAyBzMabIYCC52HcaBpp /2yw== X-Gm-Message-State: APjAAAWhvrqeVEPx5gu9uh6Be8jX41CGYG2wEOAkHeAkx5CK1S+URxrT UQg1KqvfM7+xeLIO/NhaOqbujbbz X-Google-Smtp-Source: APXvYqyiUg1M6A/7+lwFKlS1rmJJYnT/fzId9bAcWODQ6sLdY/LNqI9Q9orfh1jObdSe7s6LfT9BHw== X-Received: by 2002:adf:e984:: with SMTP id h4mr28796411wrm.275.1576494912013; Mon, 16 Dec 2019 03:15:12 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id x11sm20764333wmg.46.2019.12.16.03.15.11 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 16 Dec 2019 03:15:11 -0800 (PST) From: "Valery Smyslov" To: References: <157649464589.21642.12936346733885439093@ietfa.amsl.com> In-Reply-To: <157649464589.21642.12936346733885439093@ietfa.amsl.com> Date: Mon, 16 Dec 2019 14:15:09 +0300 Message-ID: <002201d5b402$14bf18e0$3e3d4aa0$@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: AQGKs4eVB9W3BDmhTUM1Pj30u1hdQahSm/yg Content-Language: ru Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-intermediate-03.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, 16 Dec 2019 11:15:15 -0000 Hi, a new version of the drafts has been published. This update includes official IANA code-points, that just have been assigned. 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-03.txt > Pages : 11 > Date : 2019-12-16 > > 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-03 > https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-intermediate-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-intermediate-03 > > > 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 Dec 16 04:38:39 2019 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 A9515120815; Mon, 16 Dec 2019 04:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 pH3maiUksy5E; Mon, 16 Dec 2019 04:38:36 -0800 (PST) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 E5EC012083E; Mon, 16 Dec 2019 04:38:35 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id s22so6616142ljs.7; Mon, 16 Dec 2019 04:38:35 -0800 (PST) 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=HfGe73aUIp0YnDgfxVsQY/vKzlA8aYDPxs4Q1pzv7DI=; b=UCOZB+TbLbweA2taB9aiLw2VSGcyupUCK1FI286aV8qGXCCauUTAcxM73XZJ1A0nY0 gXxkdA1udH5c2ZYbEkuVoZ0NQ3b0K7h5wL8nJFmRMjJO/Z+qsZPvycBKLGeHnWXV6lpc WJVAAkTJdIJLZQ9X9/HX6XnyCq0TgT7HZMQykSCllEmvLWV2MFDdUZPFzl3HeD6ZzFmO GAF2li805kDOY/uLbY58u1x3gT6MYqflzFSXyZg7KPtLK81Fh20xG5F4kAjOskWsthau dWEKbtFA5sDZuKr93cQzyAqSsqm8Ne8Va05hyq2PDTVsAeW6JJdKhYvh+4xg3JcdHOl0 Km2g== 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=HfGe73aUIp0YnDgfxVsQY/vKzlA8aYDPxs4Q1pzv7DI=; b=QFgjDYJDBShxQQ4sGgEh0dNQO6S9C6FD7SWoEbcHzDcd4/jVhEz3+cyqNK1t1NyiSW 4WaHEKtxSj1PZnWsBfSkQBlKCqyUUR1hl5S3dLE0h29hX92KTIOFC1W1xepvMmoE0Nlf vVo64j5LAs1mcyMiVyI1TEsg44DnS+N9bHBR4TadwGux2x5EEJVRFr1gY5OOzyWQk3B6 ycK+6a3diOuogSAL/j5uckncb/Ga9BCdj4iDcPrEuofn+STKDw8ASxroAn8eV3yaaHWi SkrTPATrEKl36RTg8RmjNhVJc1yF5OPg76kJfn5afvykhnU4hCWqIUjldmbtwQWcElL3 j+aA== X-Gm-Message-State: APjAAAUbMEsKVqJoeHKOGcO7IUDclErLSDCux15dqzPYlOnVPOJ5Z1gk CwPRrRQZZa1lrIYoPpVvf/A= X-Google-Smtp-Source: APXvYqwCel/OqXEIkZOtrEKAexYQ9tuXkvg0I55CrpzEFCCOm3uA0O6Shbx5KqBkIMPT1zAPrwmt6g== X-Received: by 2002:a2e:8015:: with SMTP id j21mr19909735ljg.172.1576499913671; Mon, 16 Dec 2019 04:38:33 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id r2sm8788269lfn.13.2019.12.16.04.38.32 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 16 Dec 2019 04:38:33 -0800 (PST) From: "Valery Smyslov" To: "'Christer Holmberg'" , Cc: , , References: <157626827886.12929.4367951047776204825@ietfa.amsl.com> In-Reply-To: <157626827886.12929.4367951047776204825@ietfa.amsl.com> Date: Mon, 16 Dec 2019 15:38:30 +0300 Message-ID: <003701d5b40d$b9eeff00$2dccfd00$@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: AQMlZcJ9+EeVN47S1gA7hAtaORoS/aUdSHDQ Content-Language: ru Archived-At: Subject: Re: [IPsec] Genart last call review of draft-ietf-ipsecme-qr-ikev2-09 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, 16 Dec 2019 12:38:38 -0000 Hi Christer, thank you for your review. Please, see inline. > Reviewer: Christer Holmberg > Review result: Almost Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-ipsecme-qr-ikev2-09 > Reviewer: Christer Holmberg > Review Date: 2019-12-13 > IETF LC End Date: 2019-12-25 > IESG Telechat date: Not scheduled for a telechat > > Summary: The document is well-written, and almost ready for publication. > However, I have a couple of minor comments that I would like the authors to > address. > > Major issues: None > > Minor issues: > > Q1: > > The Security Considerations lists IKEv2/IPSec algorithms that are not > considered quantum-resistant. However, that is not mentioned anywhere else. I > think it would be good to mention that in the Abstract and/or Introduction. Introduction already contains the following text: If the preshared key has sufficient entropy and the PRF, encryption and authentication transforms are quantum-secure, then the resulting system is believed to be quantum resistant, that is, invulnerable to an attacker with a quantum computer. We think that it is out of scope of this document to classify existing algorithms on the ground of whether they are quantum secure or not, the Security Considerations section lists only most obvious cases. > Q2: > > Section 3 says: > > "If the responder does not support this specification or does not have > any PPK configured, then it ignores the received notification and > continues with the IKEv2 protocol as normal." > > I assume the ignoring of a non-supported notification and continuing with > normal IKEv2 is part of the IKEv2 specification. If so, I suggest to say add > something like: > > ", as described in RFCXXXX." OK. > Nits/editorial comments: > > Q3: > > The Security Considerations talk about the Grover's algorithm. Please add a > reference. Added. Thank you, Valery Smyslov. > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Dec 16 04:59:11 2019 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 D9C4A120848; Mon, 16 Dec 2019 04:59:08 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 1cp3A4ymi63O; Mon, 16 Dec 2019 04:59:06 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40055.outbound.protection.outlook.com [40.107.4.55]) (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 8A448120843; Mon, 16 Dec 2019 04:59:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=L2LVc1yhZ3Qd/6NHQN2diRyjDsea6pN/9nL+qzhIRBLMhEAnmjzPZ343hFZEC7f3BIGdDpT5iy+8xgbxzp/WNONhA8E3cY22gLWxOV4JJm0ZAYAtmRS2og3RYKQm8xBaUVA7hexZCZ7afIj5+/Nk/r5OBY+PLnBXvxnNSFIqG0d0ySgN9Ck73RNBqaXbdvgqEMiaEXPo80suS0KFfX7p0yUxXptd5YinJRhTx9V5fFQ79kZDSQbw7VrqXa0RjvlY1HMREYqExXuViOdH/cLUyBTi+R9V/7Cz9eS3vBMgspaNEMgkl3Lk1MphSkoobasjObt1JAnmzjDv/91EoiTakQ== 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=F/9kpAkBU2g2PdvKaZ0LBxIiz5R0L9UyuRFBCEXfoNw=; b=FiAuDrRQoFW5kVxWtBXMtqr3a/uZi/KK9yVo8zqG+6K9+Nr8OUFzDaUzwz9PtEAbmD2lhsi3ISMKL2lSLlTXUow37OA/UtPY7bQ+6KVvtHn/qPlhZkqFx/CH+LzwXtkdTcnFd6DE0fl2ZvWwTiLiTrOo1Q5AqyhxlWyr/+OCBRX7TfXdeTR9V7h5vQSdYypS85zY2gwImhHSdIMuQ7S2AeSO+x7GUQ5T9IJuhvkFRiRJH2VslDo0LLrwRuNSW9WWEoy1PEQUzF6uFYgYxqBEicD8hCoU2SY6Mrogd1ccRQfUehe12VUNVqMQbD9IeyI2b0ayoLl3fEtRg4qPgEkaAw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=F/9kpAkBU2g2PdvKaZ0LBxIiz5R0L9UyuRFBCEXfoNw=; b=ptwQF5PrcHMT9vQlA7Xm00MgJ0dE4SaTi/4AM2ZEtAQrnZG30RArlbGnqGC2AL3pMvYpacHM+db0BFduLyJHHnIvbuW15wSqMD1LgcLnaJVq970WbSSjfzZK0eebIo09yHXpCJXgWz77UK+X8VIGXP6yarNpIwpdQKyuaERZLmU= Received: from DB6PR0701MB2421.eurprd07.prod.outlook.com (10.168.73.16) by DB6PR0701MB2421.eurprd07.prod.outlook.com (10.168.73.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.10; Mon, 16 Dec 2019 12:59:04 +0000 Received: from DB6PR0701MB2421.eurprd07.prod.outlook.com ([fe80::39bd:a590:dcd9:201e]) by DB6PR0701MB2421.eurprd07.prod.outlook.com ([fe80::39bd:a590:dcd9:201e%10]) with mapi id 15.20.2559.012; Mon, 16 Dec 2019 12:59:04 +0000 From: Christer Holmberg To: Valery Smyslov , "gen-art@ietf.org" CC: "ipsec@ietf.org" , "last-call@ietf.org" , "draft-ietf-ipsecme-qr-ikev2.all@ietf.org" Thread-Topic: [IPsec] Genart last call review of draft-ietf-ipsecme-qr-ikev2-09 Thread-Index: AQHVtA2+lB/py2UdqE+D6BUDVm/mVae82pkA Date: Mon, 16 Dec 2019 12:59:04 +0000 Message-ID: <982B1149-64ED-4BA6-B2AC-3D1860CA924C@ericsson.com> References: <157626827886.12929.4367951047776204825@ietfa.amsl.com> <003701d5b40d$b9eeff00$2dccfd00$@gmail.com> In-Reply-To: <003701d5b40d$b9eeff00$2dccfd00$@gmail.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [2001:14b8:1829:11:d94d:35dd:76:bc06] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 983343a3-40ca-4434-34a5-08d78227ba95 x-ms-traffictypediagnostic: DB6PR0701MB2421: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 02530BD3AA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(39860400002)(396003)(376002)(366004)(346002)(199004)(189003)(6506007)(66446008)(64756008)(66556008)(66476007)(66946007)(91956017)(76116006)(2616005)(44832011)(36756003)(8676002)(71200400001)(186003)(316002)(4326008)(6512007)(8936002)(2906002)(478600001)(81166006)(54906003)(86362001)(81156014)(33656002)(5660300002)(110136005)(6486002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR0701MB2421; H:DB6PR0701MB2421.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: vLImapFTEJ8WMYmVVb6ObJuCBe067aTBccJPOXretGCm3Gr6L72n6szzNyG4PxVeZweO65y/5i6yjfh5YlRdzFMg3OkNSXEuDiDiB0ZVP27bQT7ciQW1dTzrybCQyFc7kyj+4vi1wL7eFHGDZF5AH7yrvxgPpJ8S/+Em7Kr8uwcLfFMbtA7V6pJr8vR/MyyA7m0aG8e1VPL34NbpLX+Eud5DwfahlEfmFdg3fQGA76grlGifIje7JQoaKT5qhsWcd8yt2yIhZy9tXMARqT7vTL9jXo4V95mTHunO4JSfnj8U2lF5sd/hw1Q9A+6ciG2tj62PI6wouVpAsF8rFiM+mdaOGYUV+3CALCM4cggVT7P0vF7XP4NEc4Jx/9j4lEPaqZcrnz8Sg6IEap4gtHjMfYhv6ySZI3LKNfET8T3vLc3Nq6d8ERPMyHfux2zh87j5 x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <7724E4AC789D6847B7FF1C2B6AD84E75@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 983343a3-40ca-4434-34a5-08d78227ba95 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2019 12:59:04.1440 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ZoDvmfcIutp3WOMlJ3noBHU6AHVsNQ9dtC4FQXOkdyTYlnEbTxlPOkiT3wHy3n2Ci8NtoxfuOmqTJY89/y+h2bpCgOzFBckUE7BFN1LwtBU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2421 Archived-At: Subject: Re: [IPsec] Genart last call review of draft-ietf-ipsecme-qr-ikev2-09 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, 16 Dec 2019 12:59:09 -0000 SGkgVmFsZXJ5LA0KDQogICAgPj4gUTE6DQogICAgPj4gDQogICAgPj4gVGhlIFNlY3VyaXR5IENv bnNpZGVyYXRpb25zIGxpc3RzIElLRXYyL0lQU2VjIGFsZ29yaXRobXMgdGhhdCBhcmUgbm90DQog ICAgPj4gY29uc2lkZXJlZCBxdWFudHVtLXJlc2lzdGFudC4gSG93ZXZlciwgdGhhdCBpcyBub3Qg bWVudGlvbmVkIGFueXdoZXJlIGVsc2UuIEkNCiAgICA+PiB0aGluayBpdCB3b3VsZCBiZSBnb29k IHRvIG1lbnRpb24gdGhhdCBpbiB0aGUgQWJzdHJhY3QgYW5kL29yIEludHJvZHVjdGlvbi4NCiAg ICA+DQogICAgPiBJbnRyb2R1Y3Rpb24gYWxyZWFkeSBjb250YWlucyB0aGUgZm9sbG93aW5nIHRl eHQ6DQogICAgPg0KICAgID4gICBJZiB0aGUgcHJlc2hhcmVkIGtleSBoYXMNCiAgICA+ICAgc3Vm ZmljaWVudCBlbnRyb3B5IGFuZCB0aGUgUFJGLCBlbmNyeXB0aW9uIGFuZCBhdXRoZW50aWNhdGlv bg0KICAgID4gICB0cmFuc2Zvcm1zIGFyZSBxdWFudHVtLXNlY3VyZSwgdGhlbiB0aGUgcmVzdWx0 aW5nIHN5c3RlbSBpcyBiZWxpZXZlZA0KICAgID4gICB0byBiZSBxdWFudHVtIHJlc2lzdGFudCwg dGhhdCBpcywgaW52dWxuZXJhYmxlIHRvIGFuIGF0dGFja2VyIHdpdGggYQ0KICAgID4gICBxdWFu dHVtIGNvbXB1dGVyLg0KICAgID4NCiAgICA+IFdlIHRoaW5rIHRoYXQgaXQgaXMgb3V0IG9mIHNj b3BlIG9mIHRoaXMgZG9jdW1lbnQgdG8gY2xhc3NpZnkgZXhpc3RpbmcNCiAgICA+IGFsZ29yaXRo bXMgb24gdGhlIGdyb3VuZCBvZiB3aGV0aGVyIHRoZXkgYXJlIHF1YW50dW0gc2VjdXJlIG9yIG5v dCwNCiAgICA+IHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIGxpc3RzIG9ubHkg bW9zdCBvYnZpb3VzIGNhc2VzLg0KDQpJIHdhcyB0aGlua2luZyBvZiBqdXN0IGFkZGluZyAodG8g dGhlIHRleHQgeW91IHJlZmVyZW5jZWQgYWJvdmUpIHNvbWV0aGluZyBsaWtlOg0KDQoiVGhlIFNl Y3VyaXR5IENvbnNpZGVyYXRpb25zIGdpdmVzIHNvbWUgZXhhbXBsZXMgb2YgYWxnb3JpdGhtcyB0 aGF0IGFyZSBub3QgY29uc2lkZXJlZCBxdWFudHVtLXJlc2lzdGFudC4iDQoNCkJ1dCwgaWYgeW91 IGRvbid0IHRoaW5rIGl0IGlzIG5lZWRlZCwgSSBhbSBmaW5lIHdpdGggdGhhdC4gSXQgd2FzIG9u bHkgYSBtaW5vciBpc3N1ZSwgc28gOikNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KICAgIA0K ICAgIA0KDQo= From nobody Mon Dec 16 11:05:33 2019 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 B4E141208E9 for ; Mon, 16 Dec 2019 11:05:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 O0zYVUHcfJgZ for ; Mon, 16 Dec 2019 11:05:29 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70094.outbound.protection.outlook.com [40.107.7.94]) (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 6726E1208E4 for ; Mon, 16 Dec 2019 11:05:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OktZzkacUYIST5nvPDJSOLaO49DO5JObrGM/55wbUW9kzsV0VyuBZ2yvZyrBG/QJ/SNWVN2K6JkAfUREG/K2g5p6z+CuinPcDOrxllBQ725nRtICchInk3EduzbZ6+HqWDP5W6/qV6odHlji7pFtZZFqzeWMK65O4bgHbziHwm3KuNYLoIZGg8kUjFgB3F1ECVE8J6jBaNGINRxyEn6XFDXQmnpQ9HA0aW0nplQtWJyUM5AWESdJcQQ/eDUvGseEN171dbwWVmyDHXw5LLnuH88QLI3faiVoQt6WNsjJ186jwOk1S/MVLlC9sG3rx4aY+qEp87CwOagbn2QLz0vxiQ== 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=hUqXzsY/b5U7IelPRCTA8PfSRnyKKkBqShCYkA+4Hx8=; b=k95fw2nnS1gRuMeh0YyWZ03U+BeCi6daByoRa5uP//32batax06P6mmncHZ0Q2i9jTfIcO2kg1vOar3NRzJ7BBfC2qZXMHfMbhkYNEHU8Paw+PT+tnT2GhwYBqZEowPvZkWY33xa+OXoCY12TVYEIqcT55knQ0JMFF+o0OXoSuwnKqio3ypSshimwPLYDrDJpzmIiUo9wHldLV03+ggUWS8sEhWNkJJNdQ2BdCG3qB64qZnklyhDLSbQdlmGcIjAwxqe5H9DlmTENA/3TJvIe8RhQ4R0uHd8Hcj/+4dqJ0k08IZDJMlevN6JISU6V+LWLhlpcOSTmlJiAL5rPh2iyA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hUqXzsY/b5U7IelPRCTA8PfSRnyKKkBqShCYkA+4Hx8=; b=Oaom19BdNjH5PvqsUZ4iuf646TbQBqOo3vRnqpNEYwxyXHx/1SLmzSfukSJNuMzDYhPSAMAKluTrYarNjv5KiOGMEV0oRpxb9XoKDm4UTVlPjNZndCnTk2bRQ+EKvV1dM0ji7tSdK86I7d+s8+4nVyn+gzpFZa9F9VLw3KmJG+0= Received: from AM5PR0701MB2353.eurprd07.prod.outlook.com (10.169.150.18) by AM5PR0701MB2481.eurprd07.prod.outlook.com (10.169.153.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.12; Mon, 16 Dec 2019 19:05:26 +0000 Received: from AM5PR0701MB2353.eurprd07.prod.outlook.com ([fe80::c00:ee6e:9763:f843]) by AM5PR0701MB2353.eurprd07.prod.outlook.com ([fe80::c00:ee6e:9763:f843%7]) with mapi id 15.20.2559.012; Mon, 16 Dec 2019 19:05:26 +0000 From: "Hu, Jun (Nokia - US/Mountain View)" To: Paul Wouters CC: "ipsec@ietf.org WG" , Sahana Prasad Thread-Topic: [IPsec] Labeled IPsec options Thread-Index: AQHVrxZ09uToqmx5zEOPjFh9TCkZuae1Rf+AgAHA9YCAAD0q8IAA50OAgAT6SPA= Date: Mon, 16 Dec 2019 19:05:26 +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: spf=none (sender IP is ) smtp.mailfrom=jun.hu@nokia.com; x-originating-ip: [2601:646:8500:5ce4:d131:b115:9adb:2e1] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 1bc7f654-8708-480a-fa8a-08d7825ae937 x-ms-traffictypediagnostic: AM5PR0701MB2481: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02530BD3AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(136003)(376002)(346002)(396003)(366004)(31014005)(13464003)(199004)(189003)(66946007)(186003)(54906003)(7696005)(52536014)(86362001)(4326008)(81166006)(55016002)(53546011)(5660300002)(81156014)(9686003)(6506007)(71200400001)(8936002)(76116006)(2906002)(478600001)(8676002)(66476007)(316002)(33656002)(66556008)(6916009)(64756008)(66446008); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2481; H:AM5PR0701MB2353.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: PhnNxSWKOaj9/i4Pl/xSUGWU9rdc2iKPJMw4OBzUHjVCE4GoQDtzNi38KfV6ARPFSuUKmOlNxy0YPTXqQ6OB6v3Qlf0osm2lUbbySP2VNbhRFH6witVnCYWFrmiRwoBbJND7/rH6vxBWWTzf/BYp4B3aMtB5k9+JfHeS5E1ZKuA+XJofUuLum74dOp1vr9gvSZCWXFyNqBwUWYvgGmzpnG8X5ctLPPGgrfhjtb0fyNjHNSkvde07f53o+YvuHgjSwfgFprJC19itvw5a2gxTD190Z/0Glo24rFz3ln0mxr9EhMI8zdW6ahGLa8kXDC8BD3MDcaD68VS4kI38u77Egjw9mUZVSKvlWudijJmKIm9iglnYFRNRHxwTOQqhL6UaAqsaC4RL306A75akf4FwrRPbvxStDJ+q/wfoLCeKRMez112BC5g28xj9DNliZyU7hPYz9ExeMOh0fRPHUCP2r/7o6Hd7bwfPWzKS5U+klq2g6txkPxHYpVL5VBHaf3tcyA0F1RvwsPI9Nx0+SXh6eg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1bc7f654-8708-480a-fa8a-08d7825ae937 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2019 19:05:26.6542 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 6tdTJjv30Iz9S5isXIZnz0gCfBduGAquN7l9Ndt2RpDgdHXZ52XeynMKQYxElWn6d/towVsctFcfIJBfFfvIag== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2481 Archived-At: Subject: Re: [IPsec] Labeled IPsec options 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, 16 Dec 2019 19:05:32 -0000 -----Original Message----- From: Paul Wouters =20 Sent: Friday, December 13, 2019 6:51 AM To: Hu, Jun (Nokia - US/Mountain View) Cc: ipsec@ietf.org WG ; Sahana Prasad Subject: RE: [IPsec] Labeled IPsec options On Fri, 13 Dec 2019, Hu, Jun (Nokia - US/Mountain View) wrote: >> If you select multiple TS's these all become part of one Child SA. So I = think the granularity of the label does not change between the solutions? > > [Hu Jun] if we agree that label is per CHILD_SA, then with option 1 or 2,= there is possibility for invalid TS combination, following are some exampl= es of invalid TS: > - with option-1: There are two TS in TSi, first TS contains label-1,=20 > 2nd TS contains label-2 This issue is similar to network ranges though. Say you want to have: 10.0.1.0/24 <-> 192.168.0.0/16 10.0.2.0/24 <-> 172.16.100.0/24 Then you can also not have a TSi containing 10.0.1.0/24, 10.0.2.0/24 and a = TSr containing 192.168.0.0/16, 172.16.100.0/24 With 10.0.1.0/24+SEC_LABEL1 and 10.0.1.0/24+SEC_LABEL2 youl have a similar = issue, that is you would need to use a seperate CREATE_CHILD_SA to prevent = the mixup of TS elements. [Hu Jun] since this label is new, ideally we should avoid to have such simi= lar issue; and if this the label is per CHILD_SA, then of course it will re= quire multiple CHILD_SA to have multiple labels, I don't think that's an is= sue. So again, I think WG need to get a consensus on the granularity of lab= el before an option could be decided , is it per tunnel, per CHILD_SA or pe= r TS? for me it is per CHILD_SA > - with option-2: TSi contains label-1, while TSr contains a different=20 > label-2 Yes, see above. > With option-3/4 there is no such concern Since the notify or new payload type would be the same for all other TS par= ts, you do have the same problem. [Hu Jun] sorry, but I fail to see why option-3/4 have same problem if the l= abel is per CHILD_SA and semantic of new notification/payload is for the wh= ole CHILD_SA=20 You also need a different CREATE_CHILD_SA negotiation to specify the diffe= rent label. So I don't think what you describe is a new issue only affectin= g some of the solution options. All solutions need a similar workaround to = prevent the mixup. Paul From nobody Mon Dec 16 13:38:05 2019 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 402A112092F for ; Mon, 16 Dec 2019 13:38:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] 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 Ixd7yC9bV1Da for ; Mon, 16 Dec 2019 13:38:02 -0800 (PST) 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) by ietfa.amsl.com (Postfix) with ESMTPS id 94CEA120026 for ; Mon, 16 Dec 2019 13:38:00 -0800 (PST) Received: by fireball.acr.fi (Postfix, from userid 15204) id B6E3625C16A7; Mon, 16 Dec 2019 23:37:57 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24055.63797.695416.153493@fireball.acr.fi> Date: Mon, 16 Dec 2019 23:37:57 +0200 From: Tero Kivinen To: "Valery Smyslov" Cc: , "'Sahana Prasad'" , "'Paul Wouters'" In-Reply-To: <046401d5b1c6$98ed09d0$cac71d70$@gmail.com> References: <01f501d5b0b2$facb4370$f061ca50$@gmail.com> <24050.43728.115813.170898@fireball.acr.fi> <046401d5b1c6$98ed09d0$cac71d70$@gmail.com> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 9 min X-Total-Time: 9 min Archived-At: Subject: Re: [IPsec] Labeled IPsec options 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, 16 Dec 2019 21:38:04 -0000 Valery Smyslov writes: > In our case the strategy for initiator is: retransmit and wait. > If even after several retransmission it doesn't receive message > with SECLABELS_SUPPORTED, then there is no reason to continue > with IKE_AUTH (if using labels is mandatory for initiator). > If it receives a message with SECLABELS_SUPPORTED, then go with it. Which means configuration errors result in timeout instead of getting clear error message that there is configuration error. I.e., when initiator changes configuration and add SECLABELS_SUPPORTED, and then tries to connect SGW, instead of getting error message saying SECLABLES were not supported by other end it will result in unauthenticated error messages and then finally timeout. I always prefer to get proper authenticated error message from the other end for configuration errors. I.e., if we instead propose traffic selectors with SECLABELS and we should get TS_ACCEPTABLE error message from the responder and that clearly indicates that there is configuration error. >From the RFC7296 section 2.9: ---------------------------------------------------------------------- ... If the type of Traffic Selector proposed is unknown, the responder ignores that Traffic Selector, so that the unknown type is not returned in the narrowed set. ... The responder performs the narrowing as follows: o If the responder's policy does not allow it to accept any part of the proposed Traffic Selectors, it responds with a TS_UNACCEPTABLE Notify message. ... ---------------------------------------------------------------------- I.e., if the other end does not support TS type containing labels, it will ignore them and not include them in the narrowed set. If the narrowed set becomes empty because of that it will return TS_UNACCEPTABLE error message to the initiator and that gives clear feedback that there is configuration error. This is much more preferred than waiting for some time and then after timeout decide that there might have been configuration error... -- kivinen@iki.fi From nobody Tue Dec 17 11:31:17 2019 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 EE6CE120870 for ; Tue, 17 Dec 2019 11:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=sn3rd.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 riknk9EnGz2U for ; Tue, 17 Dec 2019 11:31:12 -0800 (PST) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 E12AC120125 for ; Tue, 17 Dec 2019 11:31:11 -0800 (PST) Received: by mail-qk1-x735.google.com with SMTP id 21so6519486qky.4 for ; Tue, 17 Dec 2019 11:31:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=eNqhFgCJEzsOi7tfl+WWg9stBuzJNUDNvv2LMzY1yhk=; b=SymqO1J/RR3tl7d8rgOmnD3NJlXkEiq1zBH783/FIXxJG3tbRJO6lBUYo4gZyS0fCc 0PwJBxWJuzkIuSsp+Oal2Yde6csvb9RC+JFXL5cCudhvNtMstnLNURlVXHfS9EAtZ6/0 LrWBU5LbU6hNnTSish4DvMjjA706KHzMm+zEs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=eNqhFgCJEzsOi7tfl+WWg9stBuzJNUDNvv2LMzY1yhk=; b=Ej2IeQ+/0w4b/ivipApSqLS+pH8lIXEmlQVgDQDuuC3DMNH2Qh65dcZRcNSHmCEFhm wY/7QSAjWvMWFnu1npKECXKuUsTYH7d2vSrD9M5LpBHi44JLhCKy8koPN7KB720fXyhV RjPmvykhRoPMGhJ/3CXMHhWIcELlEibMtzASirxsdzLmQRr3PPtacwROwwGymCeJY8KJ wobkXqS93mcL0ntzGIlYIIjRZVNJW7tHVnvjmsoC1BxDo3XNEoSVmIJ9zebldCwVd+vt fdg+0kVoj0tqGMI/ZDL6caXJK9t8GypvseBaUDfe8LJbyKISI9GMe6jJQfnUC6EOH869 zslA== X-Gm-Message-State: APjAAAVaL2gy5+cC2wvqwSJjEPgPhASNYNk54XliYF3vGoAFDDWFELf8 r7+zqCiHaDNRLeUyWmejzmF8w/aVV34= X-Google-Smtp-Source: APXvYqw69dHSyIs4RPkpSwdDUrwagzh3eb9chRyfa+aPMaxqSpmbUfgTLRG+ia6P+zsc6Y4784UCqg== X-Received: by 2002:a37:582:: with SMTP id 124mr6844178qkf.257.1576611070269; Tue, 17 Dec 2019 11:31:10 -0800 (PST) Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id 201sm7415002qkf.10.2019.12.17.11.31.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Dec 2019 11:31:09 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Tue, 17 Dec 2019 14:31:08 -0500 To: IPsec List X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [IPsec] graveyard: deprecate->historic 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, 17 Dec 2019 19:31:15 -0000 warning: process mumbo jumbo follows Technically, I think that s3 of draft-pwouters-ikev1-ipsec-graveyard is = trying to do is move IKEv1 to historic. IKEv1 is already obsoleted by = RFC 4036, but that=E2=80=99s not quite the same thing as moving what was = a standards track document to =E2=80=9Chistoric=E2=80=9D. The various = way to move an RFC to historic is described in this IESG statement {0]. = Since there=E2=80=99s already a draft going, it seems like #3 is the = path. The question is whether there should be two drafts: one that moves RFC = 2409 to historic and the other deprecates the algorithms. I wouldn=E2=80=99= t be hard over on splitting, but it=E2=80=99s probably better to use the = =E2=80=9Chistoric=E2=80=9D terminology in s3. I suggest the following = changes: 0: Tweak abstract OLD: This document deprecates Internet Key Exchange version 1 (IKEv1) and additionally deprecates a number of algorithms that are obsolete. NEW: This document moves Internet Key Exchange version 1 (IKEv1) to Historic status. It also deprecates a number of algorithms that are obsolete and closes all IKEv1 registries. 1: Tweak intro OLD: This document specifies the deprecation of IKEv1, and requests IANA to close all IKEv1 registries. NEW: This document moves IKEv1 to to Historic status, and requests IANA to close all IKEv1 registries. 2: Change section title s/Deprecating IKEv1/RFC 2409 to Historic spt [0] = https://ietf.org/about/groups/iesg/statements/designating-rfcs-historic-20= 14-07-20/ [1]=20= From nobody Thu Dec 19 00:23:04 2019 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 6E0981200A3; Thu, 19 Dec 2019 00:23:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: ipsecme-chairs@tools.ietf.org, ipsecme-chairs@ietf.org, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <157674378344.27479.12446329982899756695.idtracker@ietfa.amsl.com> Date: Thu, 19 Dec 2019 00:23:03 -0800 Archived-At: Subject: [IPsec] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_charter-i?= =?utf-8?q?etf-ipsecme-12-00=3A_=28with_COMMENT=29?= 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, 19 Dec 2019 08:23:03 -0000 Éric Vyncke has entered the following ballot position for charter-ietf-ipsecme-12-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- While I have no objection to the charter, I would suggest to coordinate to compressed ESP/IKEv2 of this charter with the compression work done in LPWAN (mainly or only for the non-encrypted parts). From nobody Fri Dec 20 14:45:49 2019 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 A8CF31200C1; Fri, 20 Dec 2019 14:45:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.114.0 Auto-Submitted: auto-generated Precedence: bulk Cc: ipsec@ietf.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <157688194268.4174.10133506940103129622.idtracker@ietfa.amsl.com> Date: Fri, 20 Dec 2019 14:45:42 -0800 Archived-At: Subject: [IPsec] WG Review: IP Security Maintenance and Extensions (ipsecme) 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: Fri, 20 Dec 2019 22:45:43 -0000 The IP Security Maintenance and Extensions (ipsecme) WG in the Security Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2020-01-06. IP Security Maintenance and Extensions (ipsecme) ----------------------------------------------------------------------- Current status: Active WG Chairs: Yoav Nir Tero Kivinen Assigned Area Director: Benjamin Kaduk Security Area Directors: Benjamin Kaduk Roman Danyliw Mailing list: Address: ipsec@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/ipsec Archive: https://mailarchive.ietf.org/arch/browse/ipsec/ Group page: https://datatracker.ietf.org/group/ipsecme/ Charter: https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs, IKEv1 is now obsoleted), IKEv2 (RFC 7296), and the IPsec security architecture (RFC 4301). IPsec is widely deployed in VPN gateways, VPN remote access clients, and as a substrate for host-to-host, host-to-network, and network-to-network security. The IPsec Maintenance and Extensions Working Group continues the work of the earlier IPsec Working Group which was concluded in 2005. Its purpose is to maintain the IPsec standard and to facilitate discussion of clarifications, improvements, and extensions to IPsec, mostly to ESP and IKEv2. The working group also serves as a focus point for other IETF Working Groups who use IPsec in their own protocols. The current work items include: IKEv1 using shared secret authentication was partially resistant to quantum computers. IKEv2 removed this feature to make the protocol more usable. The working group will add a mode to IKEv2 or otherwise modify the shared-secret mode of IKEv2 to have similar or better quantum resistant properties to those of IKEv1. Currently, widely used counter mode based ciphers send both the ESP sequence number and IV in the form of a counter, as they are very commonly the same. There has been interest to work on a document that will compress the packet and derive IV from the sequence number instead of sending it in separate field. The working group will specify how this compression can be negotiated in the IKEv2, and specify how the encryption algorithm and ESP format is used in this case. The Group Domain of Interpretation (GDOI - RFC 6407) is an IKEv1-based protocol for negotiating group keys for both multicast and unicast uses. The Working Group will develop an IKEv2-based alternative that will include cryptographic updates. A possible starting point is draft-yeung-g-ikev2. Postquantum Cryptography brings new key exchange methods. Most of these methods that are known to date have much larger public keys than conventional Diffie-Hellman public keys. Directly using these methods in IKEv2 might lead to a number of problems due to the increased size of initial IKEv2 messages. The working group will analyze the possible problems and develop a solution, that will make adding Postquantum key exchange methods more easy. The solution will allow post quantum key exchange to be performed in parallel with (or instead of) the existing Diffie-Hellman key exchange. A growing number of use cases for constrained networks - but not limited to those networks - have shown interest in reducing ESP (resp. IKEv2) overhead by compressing ESP (resp IKEv2) fields. The WG will define extensions of ESP and IKEv2 to enable ESP header compression. Possible starting points are draft-mglt-ipsecme-diet-esp, draft-mglt-ipsecme-ikev2-diet-esp-extension, draft-smyslov-ipsecme-ikev2-compression and draft-smyslov-ipsecme-ikev2-compact. RFC7427 allows peers to indicate hash algorithms they support, thus eliminating ambiguity in selecting a hash function for digital signature authentication. However, advances in cryptography lead to a situation when some signature algorithms have several signature formats. A prominent example is RSASSA-PKCS#1 v 1.5 and RSASSA-PSS; however it is envisioned that the same situation may repeat in future with other signature algorithms. Currently IKE peers have no explicit way to indicate to each other which signature format(s) they support. That leads to interoperability problems. The WG will investigate the situation and come up with a solution that allows peers to deal with the problem in an interoperable way. RFC7296 defines a generic notification code that is related to a failure to handle an internal address failure. That code does not explicitly allow an initiator to determine why a given address family is not assigned, nor whether it should try using another address family. The Working Group will specify a set of more specific notification codes that will provide sufficient information to the IKEv2 initiator about the encountered failure. A possible starting pointing is draft-boucadair-ipsecme-ipv6-ipv4-codes. Some systems support security labels (aka security context) as one of the selectors of the SPD. This label needs to be part of the IKE negotiation for the IPsec SA. Non-standard implementations exist for IKEv1 (formerly abusing IPSEC Security Association Attribute 10, now using private space IPSEC Security Association Attribute 32001). The work is to standarize this for IKEv2, in a way that will be backwards compatible with old implementations, meaning it must not require any changes to implementations not supporting this. RFC8229, published in 2017, specifies how to encapsulate IKEv2 and ESP traffic in TCP. Implementation experience has revealed that not all situations are covered in RFC8229, and that may lead to interoperability problems or to suboptimal performance. The WG will provide a document to give implementors more guidance about how to use reliable stream transport in IKEv2 and clarify some issues that have been discovered. A possible starting point is draft-smyslov-ipsecme-tcp-guidelines. The demand for Traffic Flow Confidentiality has been increasing in the user community, but the current method defined in RFC4303 (adding null padding to each ESP payload) is very inefficient in its use of network resources. The working group will develop an alternative TFC solution that uses network resources more efficiently. Milestones: Dec 2019 - The internal address failure indication in IKEv2 to IESG May 2020 - G-DOI for IKEv2 to IESG May 2020 - Postquantum cryptography document for IKEv2 to IESG Aug 2020 - The security labels support for IKEv2 to IESG Aug 2020 - TCP-encapsulation guidelines document to IESG Nov 2020 - Traffic Flow Confidentiality document to IESG Jun 2021 - The ESP on contrained network to IESG Jun 2021 - Signature algorithm negotiation for IKEv2 to IESG From nobody Mon Dec 23 10:46:59 2019 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 A3A96120CC5 for ; Mon, 23 Dec 2019 10:46:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 NIYNuBrA8A-6 for ; Mon, 23 Dec 2019 10:46:56 -0800 (PST) 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 D16D91200C4 for ; Mon, 23 Dec 2019 10:46:55 -0800 (PST) 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 xBNIkp6R017144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Dec 2019 13:46:54 -0500 Date: Mon, 23 Dec 2019 10:46:51 -0800 From: Benjamin Kaduk To: Sean Turner Cc: IPsec List Message-ID: <20191223184651.GC35479@kduck.mit.edu> References: 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] graveyard: deprecate->historic 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, 23 Dec 2019 18:46:58 -0000 Since we're in pedantic process mode... On Tue, Dec 17, 2019 at 02:31:08PM -0500, Sean Turner wrote: > warning: process mumbo jumbo follows > > Technically, I think that s3 of draft-pwouters-ikev1-ipsec-graveyard is trying to do is move IKEv1 to historic. IKEv1 is already obsoleted by RFC 4036, but that’s not quite the same thing as moving what was a standards track document to “historic”. The various way to move an RFC to historic is described in this IESG statement {0]. Since there’s already a draft going, it seems like #3 is the path. > > The question is whether there should be two drafts: one that moves RFC 2409 to historic and the other deprecates the algorithms. I wouldn’t be hard over on splitting, but it’s probably better to use the “historic” terminology in s3. I suggest the following changes: > > 0: Tweak abstract > > OLD: > > This document deprecates Internet Key Exchange version 1 (IKEv1) and > additionally deprecates a number of algorithms that are obsolete. > > NEW: > > This document moves Internet Key Exchange version 1 (IKEv1) to > Historic status. It also deprecates a number of algorithms that "this document" (i.e., the RFC-to-be) does not actually effecuate the move to Historic status; the separate "status-change" document does so. Looking at a recent example in RFC 8429, we see this phrased akin to "Accordingly, IKEv1 has been moved to Historic status" with no claim of doing so because of the current document. > are obsolete and closes all IKEv1 registries. > > 1: Tweak intro > > OLD: > > This document specifies the deprecation of > IKEv1, and requests IANA to close all IKEv1 registries. > > NEW: > > This document moves IKEv1 to to Historic status, and (similar here) > requests IANA to close all IKEv1 registries. > > 2: Change section title > > s/Deprecating IKEv1/RFC 2409 to Historic This is probably okay to keep (I see Paul took the changes already), but the first sentence is still "IKEv1 is deprecated", which is sending mixed signals. Perhaps something like "IKEv1 is no longer relevant for Internet systems" would work, though I suspect we could even get away without such an intro sentence and just dive in straight with "Systems running IKEv1 should be upgraded and reconfigured to run IKEv2." -Ben > spt > > [0] https://ietf.org/about/groups/iesg/statements/designating-rfcs-historic-2014-07-20/ > [1] > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Dec 24 20:01:51 2019 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 5FBB21200E9; Tue, 24 Dec 2019 20:01:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Watson Ladd via Datatracker To: Cc: ipsec@ietf.org, last-call@ietf.org, draft-ietf-ipsecme-qr-ikev2.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Watson Ladd Message-ID: <157724651034.19353.11323639071881214460@ietfa.amsl.com> Date: Tue, 24 Dec 2019 20:01:50 -0800 Archived-At: Subject: [IPsec] Secdir last call review of draft-ietf-ipsecme-qr-ikev2-09 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: Wed, 25 Dec 2019 04:01:50 -0000 Reviewer: Watson Ladd Review result: Not Ready Twas the night before Christmas when all through the house someone was desperately trying to get a review done on time. I didn't see anything wrong per se in the draft itself, but I found the capitalization of quantum computer an odd choice. IKEv2 is a complicated protocol, and I am not 100% sure that this draft does what we want it to: It would be great if someone could check very carefully in some symbolic model, ala what has been done in TLS. The guidance on sizes seems to rule out NIST level 1, but not any higher levels: might be worth calling out this explicitly. From nobody Tue Dec 24 20:34:15 2019 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 6EDD7120125; Tue, 24 Dec 2019 20:34:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 VU2ylmbU-CAf; Tue, 24 Dec 2019 20:34:11 -0800 (PST) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 0F227120071; Tue, 24 Dec 2019 20:34:11 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id y6so14118493lji.0; Tue, 24 Dec 2019 20:34:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NOg1hF3tnOUIuEohl2L03ZSDXE5LJF7ZP5SWDQ21eCY=; b=mpN7+x+ShVdYxyQquk2ww7WO5KoXiSI6hKwUN455vlZIRlwpo4NWdVac3k40UDfSug /8e9H+BkHu3X5Lf0CpK0NkirFwfoLZo9iJyYLgBASJ7zR+icHoBEY8gMh220hbr0yZsh SzI8c7Cj6w2uL1GT9Fz7JZKCJccDRv2o9kuITLzdT7zEfqkQrGfVXaeu6D2ZJ9MW1Amz PlcaFp4k3RlhO5xCLqSwvLVDP/+b2yjKazvl1K93AVS5mAkIQkTCtgfehwo52tsvCvEc WJBJQ2L4SvCJtZFESkMiFY3IwlKE4egq4Di4xsqkd1M0wRlLeOWwSPsHTa3T60uLMOhB 24fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NOg1hF3tnOUIuEohl2L03ZSDXE5LJF7ZP5SWDQ21eCY=; b=DT9nr80rSu2ajYGfESgiv/v4xk7vNnfu6lntd8596vMcV6ofvCuv5MROkjPVZcZY0x 6DYbKNtS1s9hhDga4l7GzB3FFGB6ep2AQLzLmj/BNR91FQeimdmnjMB/mC8GCmwcD5zf WpFGooL+YdR8pQ5KJVmPDSR+V4bzdmbGB91OsJbjK2P9qvOmBLT4rczLjQLT7Vh0o9va n8mMy3uMEqEpV4iBaWOiJ95JMeeshX7t1yYjBmAXDIhK7P+eO57khTD3fUCZuts7fx1K Al0Y0POkxcVCQIWevVVKyl27iaZFkEnpdQoafB5+jMYhj7bQrkcgGzRQU2ndhR/PrNUY eNZA== X-Gm-Message-State: APjAAAXnLGaUHtZ2EiyFTTdkmKUWvg9qkcL479eOI0qIIwHMRh0GmTri GXQEwWlPPz40r3JTWCpehVHr06fbIhD5wHn5VHw= X-Google-Smtp-Source: APXvYqz8rSq5gJ27w+iMRxhGfyMWJRIStD6OWFpFyCJsmNqPeHbaZnTjD6RvVKl7+nD8S83FNzY7IQ2bPKKMPKu0vGM= X-Received: by 2002:a2e:8551:: with SMTP id u17mr16949442ljj.165.1577248449086; Tue, 24 Dec 2019 20:34:09 -0800 (PST) MIME-Version: 1.0 References: <157724651034.19353.11323639071881214460@ietfa.amsl.com> In-Reply-To: <157724651034.19353.11323639071881214460@ietfa.amsl.com> From: Watson Ladd Date: Tue, 24 Dec 2019 20:33:57 -0800 Message-ID: To: Watson Ladd Cc: secdir , "ipsec@ietf.org WG" , last-call@ietf.org, draft-ietf-ipsecme-qr-ikev2.all@ietf.org Content-Type: multipart/alternative; boundary="00000000000087cc6f059a7fc5b3" Archived-At: Subject: Re: [IPsec] [secdir] Secdir last call review of draft-ietf-ipsecme-qr-ikev2-09 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, 25 Dec 2019 04:34:14 -0000 --00000000000087cc6f059a7fc5b3 Content-Type: text/plain; charset="UTF-8" Damn misclick. I meant With Nits. On Tue, Dec 24, 2019 at 8:02 PM Watson Ladd via Datatracker < noreply@ietf.org> wrote: > Reviewer: Watson Ladd > Review result: Not Ready > > Twas the night before Christmas > when all through the house > someone was desperately trying to get a review done on time. > > I didn't see anything wrong per se in the draft itself, but I found the > capitalization of quantum computer an odd choice. IKEv2 is a complicated > protocol, and I am not 100% sure that this draft does what we want it to: > It > would be great if someone could check very carefully in some symbolic > model, > ala what has been done in TLS. The guidance on sizes seems to rule out NIST > level 1, but not any higher levels: might be worth calling out this > explicitly. > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > -- "Man is born free, but everywhere he is in chains". --Rousseau. --00000000000087cc6f059a7fc5b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Damn misclick. I meant With Nits.

On Tue, Dec 24, 2019= at 8:02 PM Watson Ladd via Datatracker <noreply@ietf.org> wrote:
Reviewer: Watson Ladd
Review result: Not Ready

Twas the night before Christmas
when all through the house
someone was desperately trying to get a review done on time.

I didn't see anything wrong per se in the draft itself, but I found the=
capitalization of quantum computer an odd choice. IKEv2 is a complicated protocol, and I am not 100% sure that this draft does what we want it to: I= t
would be great if someone could check very carefully in some symbolic model= ,
ala what has been done in TLS. The guidance on sizes seems to rule out NIST=
level 1, but not any higher levels: might be worth calling out this explici= tly.

_______________________________________________
secdir mailing list
secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/= SecDirReview


--
"Man is born free, but everywhere he is in chains"= ;.
--Rousseau.
--00000000000087cc6f059a7fc5b3-- From nobody Tue Dec 24 22:52:32 2019 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 6C56012011F; Tue, 24 Dec 2019 22:52:30 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 Y31XMX6KaiWO; Tue, 24 Dec 2019 22:52:27 -0800 (PST) Received: from akmail.elvis.ru (akmail.elvis.ru [82.138.51.97]) (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 85DDC120045; Tue, 24 Dec 2019 22:52:27 -0800 (PST) Received: from kmail2.elvis.ru ([93.188.44.210]) by akmail.elvis.ru with esmtp (Exim 4.89) (envelope-from ) id 1ik0Wu-0001cR-53; Wed, 25 Dec 2019 09:52:24 +0300 Received: from mail16.office.elvis.ru ([10.111.1.29] helo=mail.office.elvis.ru) by kmail2.elvis.ru with esmtp (Exim 4.89) (envelope-from ) id 1ik0Wt-0002m8-FI; Wed, 25 Dec 2019 09:52:24 +0300 Received: from MAIL16.office.elvis.ru (10.111.1.29) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Wed, 25 Dec 2019 09:52:23 +0300 Received: from buildpc (10.111.10.33) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server id 15.1.1779.2 via Frontend Transport; Wed, 25 Dec 2019 09:52:23 +0300 From: Valery Smyslov To: 'Watson Ladd' CC: 'secdir' , , , References: <157724651034.19353.11323639071881214460@ietfa.amsl.com> In-Reply-To: Date: Wed, 25 Dec 2019 09:52:26 +0300 Message-ID: <02c101d5baef$de2cdd90$9a8698b0$@elvis.ru> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02C2_01D5BB09.037B2700" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHAI3dxdU4nCxDkFGYNjlyUdbESogLEWRy+p99zWWA= Content-Language: ru X-CrossPremisesHeadersFilteredBySendConnector: MAIL16.office.elvis.ru X-OrganizationHeadersPreserved: MAIL16.office.elvis.ru X-Spam-Scanner: Rspamd work in kmail2.elvis.ru, WHITELIST X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Status: not scanned, disabled by settings X-KLMS-AntiPhishing: Clean, bases: 2019/12/25 05:40:00 X-KLMS-AntiVirus: Kaspersky Security for Linux Mail Server, version 8.0.3.30, bases: 2019/12/25 05:12:00 #14885698 X-KLMS-AntiVirus-Status: Clean, skipped X-Spam-Scanner: Rspamd work in akmail.elvis.ru, WHITELIST Archived-At: Subject: Re: [IPsec] [secdir] Secdir last call review of draft-ietf-ipsecme-qr-ikev2-09 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, 25 Dec 2019 06:52:31 -0000 ------=_NextPart_000_02C2_01D5BB09.037B2700 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Watson, =20 thank you for spending your time on this review in Christmas Eve. =20 The capitalization issue has been already noticed and fixed. =20 I=E2=80=99m not sure the draft should mention NIST levels, because=20 they are relevant mostly for US customers. I think that=20 generic recommendations on key sizes are more appropriate for this document. =20 Regards, Valery. =20 Damn misclick. I meant With Nits. =20 On Tue, Dec 24, 2019 at 8:02 PM Watson Ladd via Datatracker = wrote: Reviewer: Watson Ladd Review result: Not Ready Twas the night before Christmas when all through the house someone was desperately trying to get a review done on time. I didn't see anything wrong per se in the draft itself, but I found the capitalization of quantum computer an odd choice. IKEv2 is a complicated protocol, and I am not 100% sure that this draft does what we want it = to: It would be great if someone could check very carefully in some symbolic = model, ala what has been done in TLS. The guidance on sizes seems to rule out = NIST level 1, but not any higher levels: might be worth calling out this = explicitly. _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --=20 "Man is born free, but everywhere he is in chains". --Rousseau. ------=_NextPart_000_02C2_01D5BB09.037B2700 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Watson,

 

thank you for spending your time on this review in Christmas = Eve.

 

The capitalization issue has been already noticed and = fixed.

 

I=E2=80=99m not sure the draft should mention NIST levels, because =

they are relevant mostly for US customers. I think that =

generic recommendations on key sizes are more = appropriate

for this document.

 

Regards,

Valery.

 

Damn misclick. I meant With = Nits.

 

On = Tue, Dec 24, 2019 at 8:02 PM Watson Ladd via Datatracker <noreply@ietf.org> = wrote:

Reviewer: = Watson Ladd
Review result: Not Ready

Twas the night before = Christmas
when all through the house
someone was desperately = trying to get a review done on time.

I didn't see anything wrong = per se in the draft itself, but I found the
capitalization of quantum = computer an odd choice. IKEv2 is a complicated
protocol, and I am not = 100% sure that this draft does what we want it to: It
would be great = if someone could check very carefully in some symbolic model,
ala = what has been done in TLS. The guidance on sizes seems to rule out = NIST
level 1, but not any higher levels: might be worth calling out = this = explicitly.

_______________________________________________
sec= dir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wik= i: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview



--

------=_NextPart_000_02C2_01D5BB09.037B2700-- From nobody Wed Dec 25 03:57:46 2019 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 1CC3112082E; Wed, 25 Dec 2019 03:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 fEFU3pPeOt1L; Wed, 25 Dec 2019 03:57:41 -0800 (PST) Received: from outgoing-exchange-5.mit.edu (outgoing-exchange-5.mit.edu [18.9.28.59]) (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 BC58A12004A; Wed, 25 Dec 2019 03:57:40 -0800 (PST) Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id xBPBxhLp019915; Wed, 25 Dec 2019 06:59:44 -0500 Received: from oc11expo31.exchange.mit.edu (18.9.4.104) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 25 Dec 2019 06:56:01 -0500 Received: from oc11expo31.exchange.mit.edu (18.9.4.104) by oc11expo31.exchange.mit.edu (18.9.4.104) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 25 Dec 2019 06:57:32 -0500 Received: from oc11expo31.exchange.mit.edu ([18.9.4.104]) by oc11expo31.exchange.mit.edu ([18.9.4.104]) with mapi id 15.00.1365.000; Wed, 25 Dec 2019 06:57:32 -0500 From: Uri Blumenthal To: Valery Smyslov CC: Watson Ladd , "ipsec@ietf.org" , "last-call@ietf.org" , "draft-ietf-ipsecme-qr-ikev2.all@ietf.org" , secdir Thread-Topic: [secdir] Secdir last call review of draft-ietf-ipsecme-qr-ikev2-09 Thread-Index: AQHVutgQJ9+wavcRBECx2knvNxQEcqfKlyyAgAAmsQCAAFU9gA== Date: Wed, 25 Dec 2019 11:57:32 +0000 Message-ID: <70FA58C0-97E1-4F76-B88B-A28101A46069@mit.edu> References: <02c101d5baef$de2cdd90$9a8698b0$@elvis.ru> In-Reply-To: <02c101d5baef$de2cdd90$9a8698b0$@elvis.ru> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/signed; boundary="Apple-Mail-D2EEC21A-E3BF-4669-B023-977D9FB8468C"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] [secdir] Secdir last call review of draft-ietf-ipsecme-qr-ikev2-09 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, 25 Dec 2019 11:57:43 -0000 --Apple-Mail-D2EEC21A-E3BF-4669-B023-977D9FB8468C Content-Type: multipart/alternative; boundary=Apple-Mail-877A88EF-9CA1-4975-BC02-1B11CA7980C3 Content-Transfer-Encoding: 7bit --Apple-Mail-877A88EF-9CA1-4975-BC02-1B11CA7980C3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 TklTVCBzdGFuZGFyZHMgYXJlIG1hbmRhdG9yeSBmb3IgYSBzdWJzZXQgb2YgVVMgY2l0aXplbnMu IEJ1dCBlbm91Z2ggb2YgYnVzaW5lc3NlcyBvdXRzaWRlIHRoZSBVUyBwYXkgYXR0ZW50aW9uIHRv IHdoYXQgTklTVCBzYXlzIHRvIG1ha2UgYWRkaW5nIHRoZSByZWZlcmVuY2UgcmVsZXZhbnQgYW5k IHVzZWZ1bC4NCg0KPiBPbiBEZWMgMjUsIDIwMTksIGF0IDAxOjUyLCBWYWxlcnkgU215c2xvdiA8 c3ZhbkBlbHZpcy5ydT4gd3JvdGU6DQo+IA0KPiDvu78NCj4gSGkgV2F0c29uLA0KPiAgDQo+IHRo YW5rIHlvdSBmb3Igc3BlbmRpbmcgeW91ciB0aW1lIG9uIHRoaXMgcmV2aWV3IGluIENocmlzdG1h cyBFdmUuDQo+ICANCj4gVGhlIGNhcGl0YWxpemF0aW9uIGlzc3VlIGhhcyBiZWVuIGFscmVhZHkg bm90aWNlZCBhbmQgZml4ZWQuDQo+ICANCj4gSeKAmW0gbm90IHN1cmUgdGhlIGRyYWZ0IHNob3Vs ZCBtZW50aW9uIE5JU1QgbGV2ZWxzLCBiZWNhdXNlDQo+IHRoZXkgYXJlIHJlbGV2YW50IG1vc3Rs eSBmb3IgVVMgY3VzdG9tZXJzLiBJIHRoaW5rIHRoYXQNCj4gZ2VuZXJpYyByZWNvbW1lbmRhdGlv bnMgb24ga2V5IHNpemVzIGFyZSBtb3JlIGFwcHJvcHJpYXRlDQo+IGZvciB0aGlzIGRvY3VtZW50 Lg0KPiAgDQo+IFJlZ2FyZHMsDQo+IFZhbGVyeS4NCj4gIA0KPiBEYW1uIG1pc2NsaWNrLiBJIG1l YW50IFdpdGggTml0cy4NCj4gIA0KPiBPbiBUdWUsIERlYyAyNCwgMjAxOSBhdCA4OjAyIFBNIFdh dHNvbiBMYWRkIHZpYSBEYXRhdHJhY2tlciA8bm9yZXBseUBpZXRmLm9yZz4gd3JvdGU6DQo+IFJl dmlld2VyOiBXYXRzb24gTGFkZA0KPiBSZXZpZXcgcmVzdWx0OiBOb3QgUmVhZHkNCj4gDQo+IFR3 YXMgdGhlIG5pZ2h0IGJlZm9yZSBDaHJpc3RtYXMNCj4gd2hlbiBhbGwgdGhyb3VnaCB0aGUgaG91 c2UNCj4gc29tZW9uZSB3YXMgZGVzcGVyYXRlbHkgdHJ5aW5nIHRvIGdldCBhIHJldmlldyBkb25l IG9uIHRpbWUuDQo+IA0KPiBJIGRpZG4ndCBzZWUgYW55dGhpbmcgd3JvbmcgcGVyIHNlIGluIHRo ZSBkcmFmdCBpdHNlbGYsIGJ1dCBJIGZvdW5kIHRoZQ0KPiBjYXBpdGFsaXphdGlvbiBvZiBxdWFu dHVtIGNvbXB1dGVyIGFuIG9kZCBjaG9pY2UuIElLRXYyIGlzIGEgY29tcGxpY2F0ZWQNCj4gcHJv dG9jb2wsIGFuZCBJIGFtIG5vdCAxMDAlIHN1cmUgdGhhdCB0aGlzIGRyYWZ0IGRvZXMgd2hhdCB3 ZSB3YW50IGl0IHRvOiBJdA0KPiB3b3VsZCBiZSBncmVhdCBpZiBzb21lb25lIGNvdWxkIGNoZWNr IHZlcnkgY2FyZWZ1bGx5IGluIHNvbWUgc3ltYm9saWMgbW9kZWwsDQo+IGFsYSB3aGF0IGhhcyBi ZWVuIGRvbmUgaW4gVExTLiBUaGUgZ3VpZGFuY2Ugb24gc2l6ZXMgc2VlbXMgdG8gcnVsZSBvdXQg TklTVA0KPiBsZXZlbCAxLCBidXQgbm90IGFueSBoaWdoZXIgbGV2ZWxzOiBtaWdodCBiZSB3b3J0 aCBjYWxsaW5nIG91dCB0aGlzIGV4cGxpY2l0bHkuDQo+IA0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzZWNkaXIgbWFpbGluZyBsaXN0DQo+IHNl Y2RpckBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nl Y2Rpcg0KPiB3aWtpOiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvYXJlYS9zZWMvdHJhYy93aWtpL1Nl Y0RpclJldmlldw0KPiANCj4gDQo+IC0tDQo+ICJNYW4gaXMgYm9ybiBmcmVlLCBidXQgZXZlcnl3 aGVyZSBoZSBpcyBpbiBjaGFpbnMiLg0KPiAtLVJvdXNzZWF1Lg0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzZWNkaXIgbWFpbGluZyBsaXN0DQo+ IHNlY2RpckBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NlY2Rpcg0KPiB3aWtpOiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvYXJlYS9zZWMvdHJhYy93aWtp L1NlY0RpclJldmlldw0K --Apple-Mail-877A88EF-9CA1-4975-BC02-1B11CA7980C3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPk5JU1Qgc3RhbmRh cmRzIGFyZSBtYW5kYXRvcnkgZm9yIGEgc3Vic2V0IG9mIFVTIGNpdGl6ZW5zLiBCdXQgZW5vdWdo IG9mIGJ1c2luZXNzZXMgb3V0c2lkZSB0aGUgVVMgcGF5IGF0dGVudGlvbiB0byB3aGF0IE5JU1Qg c2F5cyB0byBtYWtlIGFkZGluZyB0aGUgcmVmZXJlbmNlIHJlbGV2YW50IGFuZCB1c2VmdWwuPGRp dj48ZGl2IGRpcj0ibHRyIj48YnI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+T24gRGVjIDI1LCAy MDE5LCBhdCAwMTo1MiwgVmFsZXJ5IFNteXNsb3YgJmx0O3N2YW5AZWx2aXMucnUmZ3Q7IHdyb3Rl Ojxicj48YnI+PC9ibG9ja3F1b3RlPjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXYg ZGlyPSJsdHIiPu+7vw0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0 ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0i TWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPjxzdHlsZT48IS0tDQovKiBGb250 IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFu b3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAu TXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzQ0NTQ2QTt9 DQouLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V Uzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjIuMGNtIDQyLjVwdCAyLjBjbSAzLjBjbTt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT48ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQ0NTQ2 QSI+SGkgV2F0c29uLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0NDU0NkEiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0NDU0NkEiPnRoYW5rIHlvdSBm b3Igc3BlbmRpbmcgeW91ciB0aW1lIG9uIHRoaXMgcmV2aWV3IGluIENocmlzdG1hcyBFdmUuPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQ0NTQ2QSI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQ0NTQ2QSI+VGhlIGNhcGl0YWxpemF0aW9uIGlzc3VlIGhh cyBiZWVuIGFscmVhZHkgbm90aWNlZCBhbmQgZml4ZWQuPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE0 LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzQ0NTQ2QSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzQ0NTQ2QSI+SeKAmW0gbm90IHN1cmUgdGhlIGRyYWZ0IHNob3VsZCBtZW50aW9uIE5JU1QgbGV2 ZWxzLCBiZWNhdXNlIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0NDU0NkEiPnRo ZXkgYXJlIHJlbGV2YW50IG1vc3RseSBmb3IgVVMgY3VzdG9tZXJzLiBJIHRoaW5rIHRoYXQgPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQ0NTQ2QSI+Z2VuZXJpYyByZWNvbW1lbmRh dGlvbnMgb24ga2V5IHNpemVzIGFyZSBtb3JlIGFwcHJvcHJpYXRlPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzQ0NTQ2QSI+Zm9yIHRoaXMgZG9jdW1lbnQuPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzQ0NTQ2QSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE0 LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzQ0NTQ2QSI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojNDQ1NDZBIj5WYWxlcnkuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQ0NTQ2 QSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+PGRp dj48cCBjbGFzcz0iTXNvTm9ybWFsIj5EYW1uIG1pc2NsaWNrLiBJIG1lYW50IFdpdGggTml0cy48 bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBEZWMgMjQsIDIwMTkg YXQgODowMiBQTSBXYXRzb24gTGFkZCB2aWEgRGF0YXRyYWNrZXIgJmx0OzxhIGhyZWY9Im1haWx0 bzpub3JlcGx5QGlldGYub3JnIj5ub3JlcGx5QGlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj48cCBjbGFzcz0iTXNvTm9ybWFsIj5SZXZpZXdlcjog V2F0c29uIExhZGQ8YnI+UmV2aWV3IHJlc3VsdDogTm90IFJlYWR5PGJyPjxicj5Ud2FzIHRoZSBu aWdodCBiZWZvcmUgQ2hyaXN0bWFzPGJyPndoZW4gYWxsIHRocm91Z2ggdGhlIGhvdXNlPGJyPnNv bWVvbmUgd2FzIGRlc3BlcmF0ZWx5IHRyeWluZyB0byBnZXQgYSByZXZpZXcgZG9uZSBvbiB0aW1l Ljxicj48YnI+SSBkaWRuJ3Qgc2VlIGFueXRoaW5nIHdyb25nIHBlciBzZSBpbiB0aGUgZHJhZnQg aXRzZWxmLCBidXQgSSBmb3VuZCB0aGU8YnI+Y2FwaXRhbGl6YXRpb24gb2YgcXVhbnR1bSBjb21w dXRlciBhbiBvZGQgY2hvaWNlLiBJS0V2MiBpcyBhIGNvbXBsaWNhdGVkPGJyPnByb3RvY29sLCBh bmQgSSBhbSBub3QgMTAwJSBzdXJlIHRoYXQgdGhpcyBkcmFmdCBkb2VzIHdoYXQgd2Ugd2FudCBp dCB0bzogSXQ8YnI+d291bGQgYmUgZ3JlYXQgaWYgc29tZW9uZSBjb3VsZCBjaGVjayB2ZXJ5IGNh cmVmdWxseSBpbiBzb21lIHN5bWJvbGljIG1vZGVsLDxicj5hbGEgd2hhdCBoYXMgYmVlbiBkb25l IGluIFRMUy4gVGhlIGd1aWRhbmNlIG9uIHNpemVzIHNlZW1zIHRvIHJ1bGUgb3V0IE5JU1Q8YnI+ bGV2ZWwgMSwgYnV0IG5vdCBhbnkgaGlnaGVyIGxldmVsczogbWlnaHQgYmUgd29ydGggY2FsbGlu ZyBvdXQgdGhpcyBleHBsaWNpdGx5Ljxicj48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+c2VjZGlyIG1haWxpbmcgbGlzdDxicj48YSBocmVmPSJt YWlsdG86c2VjZGlyQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2VjZGlyQGlldGYub3JnPC9h Pjxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NlY2Rp ciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2VjZGlyPC9hPjxicj53aWtpOiA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvYXJlYS9z ZWMvdHJhYy93aWtpL1NlY0RpclJldmlldyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5p ZXRmLm9yZy9hcmVhL3NlYy90cmFjL3dpa2kvU2VjRGlyUmV2aWV3PC9hPjxvOnA+PC9vOnA+PC9w PjwvYmxvY2txdW90ZT48L2Rpdj48cCBjbGFzcz0iTXNvTm9ybWFsIj48YnIgY2xlYXI9ImFsbCI+ PGJyPi0tIDxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+Ik1hbiBpcyBi b3JuIGZyZWUsIGJ1dCBldmVyeXdoZXJlIGhlIGlzIGluIGNoYWlucyIuPGJyPi0tUm91c3NlYXUu PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PHNwYW4+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyPjxzcGFuPnNlY2RpciBtYWls aW5nIGxpc3Q8L3NwYW4+PGJyPjxzcGFuPnNlY2RpckBpZXRmLm9yZzwvc3Bhbj48YnI+PHNwYW4+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZWNkaXI8L3NwYW4+PGJyPjxz cGFuPndpa2k6IGh0dHA6Ly90b29scy5pZXRmLm9yZy9hcmVhL3NlYy90cmFjL3dpa2kvU2VjRGly UmV2aWV3PC9zcGFuPjxicj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --Apple-Mail-877A88EF-9CA1-4975-BC02-1B11CA7980C3-- --Apple-Mail-D2EEC21A-E3BF-4669-B023-977D9FB8468C Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCGsw ggQkMIICjKADAgECAgRbkXGgMA0GCSqGSIb3DQEBDAUAMBoxGDAWBgNVBAMMD0ZvcmVzdCBDQSBS U0EgNDAeFw0xODA5MDYxODI3NDRaFw0yMTA5MDYxODI3NDRaMA4xDDAKBgNVBAMMA1VyaTCCAaIw DQYJKoZIhvcNAQEBBQADggGPADCCAYoCggGBANJi8+lfrSCcWThbn0vQzXsW7AYTyTZSo/pv/274 xD/t1rpn/X/vegP2lSfr+SRJ4oJ+51MFJvRl/sAveroDN8gGrFyYaCg5ZsOMqksCmLha4Ttgk04L I/aqrPGuzF1OVgjhi6WrnFr80KS6sy3MWzYIYV6G1FycKEup5snMr1B1WWzFKOwSslnJwvCuHu2W Tc5OzJKPtxMcDIS9y6VOZTzsJUFe0bRiw0LICDBcB3fgKCvYMcDfke0pw13I4O7wEG40s9E6rTIj Q0H1LVk69pSo1ikzpikl5W8pXUQQrSmjHqhFn/Q+PwSzHSOralN0p1UMziUv57lgvvZbTaH1ooqq MZBuTed0xLye3w+h9+/iqDY4B7lFqbegzseBh7/Q6KdtfpkwwI7xSpZEME/V77KAMw+ipb+Itbij Bi3r/t81fDW8eitIAbVtalpFROlYIaZnIIohOZRyVjn2unZ+lj3jDKsDq53g+oleo+Ruszlt8nju 6uKhzE7bdX1xJuvCtwIDAQABo34wfDAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFIDAWBgNV HREEDzANgQt1cmlAbWl0LmVkdTAdBgNVHQ4EFgQU2p+nwSyQFM6byFBhc7oIZephJbcwJQYDVR0l BB4wHAYIKwYBBQUHAwQGCisGAQQBgjcKAwQGBFUdJQAwDQYJKoZIhvcNAQEMBQADggGBAH/zzG9P gU+ogFbc75JpUK0amUUtmtSsGDe4599GolCDiuPHrnbCGcaNc9aQjRaP3Q3aU7BB3aOjwssjQSN0 tsfZD8p+XPny/odhDSwS/25jCg0dVasd8q+Jd1S1g34RGUqPQ+5ofTrBSEkHBdLdJOnxBGo9GRzA yiDg34r6zK6BXNYv2GdqRk+GGGvL/w3CDR+ih36ZDBxw/EO19oH/aV4+mVlcRI6aoj4KMb+h4zMY S8jLDArIZSce4EWzJqxKVcX6Q7CE/0Br/7R8Ixs+vt5YKPUVpEbFM6koH624GDQYKM2kzXBnwYgS /jvl02KUx6uNmIgo+ufK2l7sc83vRLxBTJKhT0/USVkwu9uzg2zHJeGBZ4pmDhkIVkGcamW7KPYZ dgOz8zAOy8Ntk7GebPn85XuPcQS9UntdO61X1EyEXg4Ixl/qapidfJQfdCqEeZZXpaV3WKWE8u1l fNB00mC0/xhG3bikQxl3O20nyPjXvl6VZFzglsPRy1Xh5L//rzCCBD8wggKnoAMCAQICBFuRckIw DQYJKoZIhvcNAQEMBQAwGjEYMBYGA1UEAwwPRm9yZXN0IENBIFJTQSA0MB4XDTE4MDkwNjE4MzAy NloXDTIxMDkwNjE4MzAyNlowDjEMMAoGA1UEAwwDVXJpMIIBojANBgkqhkiG9w0BAQEFAAOCAY8A MIIBigKCAYEAtZvms8stf9xj5w7pjYzgmHe7TH0eX/q3buMBqdLufhFuqCizZPhXJmSbue8WHm8H HO7SHQPUqIqbPOMIQfAL8nwWhuTfsN5nrtFW77eiNsEexRNkbhw/U6RzamCGl6xQmUxOD0nabEmd Xdces+rjtzlvjpNHI7xrR32ee4JuGTjwAWlAHPtBC8TqiOR/ysR2K2umk5BkjCEWV9kDfGklfKmu IhuCzzpTvN3AnLMX9kP9IY6E9B8OsLOhkOFBbAMzyqkXibtPWluqOnYW3V3MVc9H1ir6sGLF5onW lHLEorI51WuHlfVO8WJRYwhrzQIIAWAYheZaH2wdb87Kw6o4JbHDLTDJHHrBDwfqa5OtFTeQNWCD JPdHa4xfFpjnMTzP18POa5C6QN5XBpTFsfccWyEdt+ykGB2FMzhB3GgMVRfWPgo8TgxVwU9MHt8s vmxj8KMUd7afSJBOjMIRPZ6gi8Vja9SR9+Hj/YWgpKZMHhI7irJVpWF++7hhfxxDbgDBAgMBAAGj gZgwgZUwDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBsAwFgYDVR0RBA8wDYELdXJpQG1pdC5l ZHUwHQYDVR0OBBYEFK3WLENy4CH330dGZEWchN+L1r28MD4GA1UdJQQ3MDUGCCsGAQUFBwMCBggr BgEFBQcDAwYKKwYBBAGCNwoDDAYJKoZIhvcvAQEFBggrBgEFBQcDBDANBgkqhkiG9w0BAQwFAAOC AYEACYbThcFo+JTQNP5UacMtYogWU/yOx5GBLSNNa5cpvoRrOJc9CUDfzfnrd7IhDLXvnFUYNt3i oyU13LKRoPsp/YYuZ2CBI1om9g27SSqqEcOom0eojIKkPNw+sJzYVl7Dz2I7f9DHN6nEC9BeT8Do rjuq67UOlZZw0YvlvCmtMI4xJ7CUM8NrphoeRN18OnbwmkHWIYnYwdxipTJ8oLWi5EbKaUEYyLlC JWd6o9vH8cFNzsViPUl9POxBtX++o5KxtW7/JQwrQt3uFubF6rHQag6HDeXcXSyI0DmL8MrfVtHi Ma2bN+7z8N9Wnuvx8v0qlqfwd+uhmP7OvD32PuzjQxuGyPd43DZazlMhY9IRpSSCPhdbxzS3YwKr jnTZlKGwPiYCmiQ0XSEW3K64Exe4t+jrkBReocr9ccslB4d4XhxQPdAvUdI43xGMbnFea7pyTDyP b0z1vMrYt6dAguU0QTgRZsPFoIldK70ILvncq9amhxuQ4Uw+u2WUXiYba2R1MYICoTCCAp0CAQEw IjAaMRgwFgYDVQQDDA9Gb3Jlc3QgQ0EgUlNBIDQCBFuRckIwDQYJYIZIAWUDBAIBBQCggdEwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkxMjI1MTE1NzMxWjAvBgkq hkiG9w0BCQQxIgQgiBdm9AIUa2EAE17v20HFGHuqMfsNenJEn1uHHayt5fgwMQYJKwYBBAGCNxAE MSQwIjAaMRgwFgYDVQQDDA9Gb3Jlc3QgQ0EgUlNBIDQCBFuRcaAwMwYLKoZIhvcNAQkQAgsxJKAi MBoxGDAWBgNVBAMMD0ZvcmVzdCBDQSBSU0EgNAIEW5FxoDANBgkqhkiG9w0BAQEFAASCAYCQxBmJ vAav3FY+Z8soa2MpkgL3NGuQUqGIkxacx8LEbzFBnjF3uCDrOYKVhazzRTA13JJIIZnvyMa/T7AT 1eXSJhMiu+QormQ70xOdCEAwisahI4B18oEnDTrj73EsSvoCakZQjGddEa5lswNA3xd+uO8d67WF FL58A0PYD3dzlstA7l5TcHMlXGVGQTNr2mVzxq7L3BujW9/ID/JZTbM8VWQ68G7JItsgFoH1oRTv p4SYHBGikg/GmbnHQEWvs2QEXSnT3quQUmqcamJlnvJIQUEccqCENHdZ+8Bq1M586yqknWdWwAOa 6fT/I+T3Mu7nzalu0I5AXqej1sx62dm6UTbuYp6sz3eYZSKFumEy7aZ6hGVzWw+wDCnUoKbyDvQI gF2YpmBdICTpFpTKW/3Lx5xNj16muYDwROysvXIoOYzh2vDG38KZtlDOz1mzsrFgYQQQtMKUv8zu F90/p3yQs+wkm79xvrsRarIiz3hD1mV4PzfdQzzDl9nB/UO0jogAAAAAAAA= --Apple-Mail-D2EEC21A-E3BF-4669-B023-977D9FB8468C-- From nobody Wed Dec 25 06:35:01 2019 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 2555012002E for ; Wed, 25 Dec 2019 06:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 QRCef7gNTAG1 for ; Wed, 25 Dec 2019 06:34:57 -0800 (PST) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 1C4B2120025 for ; Wed, 25 Dec 2019 06:34:57 -0800 (PST) Received: by mail-wm1-x331.google.com with SMTP id q9so2722920wmj.5 for ; Wed, 25 Dec 2019 06:34:57 -0800 (PST) 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=BtSgdXxIPnvZBYmYew7A1ZFntI/Q5fuP67yArEMY1Rg=; b=h+05jEx3pKjyWgJQ3e7kMCsSQE/I4ijqeCOTqFq8h1knCk82ACzKFxerfGe72E1f/H 2O71YI2u1X0M6zQtrs1h/97dKV+0PVl6zhfcUppvdl8cujDUMsn4Jai6GBjR5OexgKzg h4P6JMWNKb+M+ilmmYx9DUBf+9QMOXRPV1Oen5hqeDT5x48zI9qekTerSD//db2AshIO 0Syt1TRSXRM1Xb3QZJ5861tGeYMnb/Z4ZAaS4KiVr+5wn7g2Gc3pjfJU5busNpR6fPE8 c7yVUXfCq6WcnG1VBnWTdPH321lRK/b1h+x+JQnv3NP839fx7itjkA2c8UWyyw1YpqJn jfOw== 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=BtSgdXxIPnvZBYmYew7A1ZFntI/Q5fuP67yArEMY1Rg=; b=Pu7SnkNn+MQhS9XpImRtUMmWO7eLA7nM0OvHtLa0C8wmYzGyE6TXv3ZjWvAUKp58gr aqYkGJuKY/+UKtwzOPoyHmpLhwu0bnp0hx7Y2dXLBftluoOtcD94/9a0nN036PC5MMo9 /LRNWvrc5QYa8M0bN434HSKRN0+iBJV6wZB2metZ6dr1lx6OdPCVtPSsdUT7zzIih5C4 U55P80n1550MZQlbUn/D1SDIaPboSXouUnyEGvIx/z4GyD0Rr+a9ixAq1mLIkIWjHlpd 75xbeySb8WF7I2Xa9suYp1aF41cJ19y74sNTUiSGF1lWA4sSurwFyXwd216r6ubjlnDE 9G3w== X-Gm-Message-State: APjAAAWqJuPhFSngCyBGG77TK2fE2l2d7AQEMzPSZPRxBnFMFbzX4PAT MZ3YSf79Z7iz85DalY6KOFevujEp X-Google-Smtp-Source: APXvYqxnQa+hwGLI3zTZQC0ZDz2j804+YpjWVpZlMBam46lgaathv3Cq1l/TeO7S4OZUKhSr/IafTQ== X-Received: by 2002:a7b:c4cc:: with SMTP id g12mr9949571wmk.68.1577284495389; Wed, 25 Dec 2019 06:34:55 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id o4sm27514989wrw.97.2019.12.25.06.34.54 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 25 Dec 2019 06:34:54 -0800 (PST) From: "Valery Smyslov" To: "'Tero Kivinen'" Cc: , "'Sahana Prasad'" , "'Paul Wouters'" References: <01f501d5b0b2$facb4370$f061ca50$@gmail.com> <24050.43728.115813.170898@fireball.acr.fi> <046401d5b1c6$98ed09d0$cac71d70$@gmail.com> <24055.63797.695416.153493@fireball.acr.fi> In-Reply-To: <24055.63797.695416.153493@fireball.acr.fi> Date: Wed, 25 Dec 2019 17:34:56 +0300 Message-ID: <032201d5bb30$7b70ec00$7252c400$@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: AQLx+ZsZ28gCWkLjxf5xPWFraxjS5AGiqmCDANTXOjwB/YUU0gIxTZDgpV01HJA= Content-Language: ru Archived-At: Subject: Re: [IPsec] Labeled IPsec options 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, 25 Dec 2019 14:34:59 -0000 Hi Tero, first, I'm not against using new TS accommodating seclabels. It is the most pure way to go from theoretical PoV. The only concern with this approach is that the number of TS types will be growing up. Another approach - use some new status notification containing seclabel that the initiator would include in any request to create Child SA. This is easy to implement, but there is a possibility, that unsupporting responder will just ignore this notification and create SA w/o proposed seclabel. In this case the initiator would need to immediately delete this SA. My proposal only deals with this situation. If initiator and responder exchange SECLABELS_SUPPORTED notifications at the time of creating IKE SA (in IKE_SA_INIT), then the initiator will know, whether the responder supports seclabels or not. And if the responder supports seclabels, it will not be able to ignore notification (of other type) indicating the desired security label at the time Child SA is created (in IKE_AUTH or in CREATE_CHILD_SA). So you misunderstood, there is no any timeouts, there is clear indication for the initiator of whether the responder supports this feature (and thus it's OK to use it) or not (in which case depending on the initiator's policy the communication may or may not be possible). Again, I'm fine with either using new Traffic Selectors or Notify for this purpose. Both have pros and contras. Regards, Valery. > Valery Smyslov writes: > > In our case the strategy for initiator is: retransmit and wait. > > If even after several retransmission it doesn't receive message > > with SECLABELS_SUPPORTED, then there is no reason to continue > > with IKE_AUTH (if using labels is mandatory for initiator). > > If it receives a message with SECLABELS_SUPPORTED, then go with it. > > Which means configuration errors result in timeout instead of getting > clear error message that there is configuration error. > > I.e., when initiator changes configuration and add > SECLABELS_SUPPORTED, and then tries to connect SGW, instead of getting > error message saying SECLABLES were not supported by other end it will > result in unauthenticated error messages and then finally timeout. > > I always prefer to get proper authenticated error message from the > other end for configuration errors. I.e., if we instead propose > traffic selectors with SECLABELS and we should get TS_ACCEPTABLE error > message from the responder and that clearly indicates that there is > configuration error. > > >From the RFC7296 section 2.9: > > ---------------------------------------------------------------------- > .... > If the type of Traffic Selector proposed is unknown, the responder > ignores that Traffic Selector, so that the unknown type is not > returned in the narrowed set. > .... > The responder performs the narrowing as follows: > > o If the responder's policy does not allow it to accept any part of > the proposed Traffic Selectors, it responds with a TS_UNACCEPTABLE > Notify message. > .... > ---------------------------------------------------------------------- > > I.e., if the other end does not support TS type containing labels, it > will ignore them and not include them in the narrowed set. If the > narrowed set becomes empty because of that it will return > TS_UNACCEPTABLE error message to the initiator and that gives clear > feedback that there is configuration error. > > This is much more preferred than waiting for some time and then after > timeout decide that there might have been configuration error... > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Dec 25 09:19:01 2019 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 5D53D1200A4; Wed, 25 Dec 2019 09:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 lrj_8Q_ULnfF; Wed, 25 Dec 2019 09:18:58 -0800 (PST) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 321B112008A; Wed, 25 Dec 2019 09:18:58 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id u1so23120355ljk.7; Wed, 25 Dec 2019 09:18:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BgPttg34novKpTJ1ZNpQfjOKpwM5DsFq3mUyHPE4N5M=; b=KzneKkeSh0i01MRTQzYJwwjQVLojTHioqmOAGytBc+RHb1gfQY8CkJhfp6QQ5toxCU I0RJReoo6rekO+0eIeOa44ZxbKW26gtzy8V6djIU2FZSd4tJ0SdxxHsh8jV5e9D3lkvA bDRKC1c/6tbe0vnliPI8l0fRhsrJjbTFobNJDPDdKvkngKWIfVdqxqfHRKe4qkFs1daf Ilh67JBnR8+eM9vobIYYV6VjxbvCD1TCbMDzoqhut1y97JHwNh6SbjZgf+AHT0Z5njDe 8tJ7s9G+hvpzYdMTCgp9mnkyRJq+wYOnllJFGXzWegMGGMro/ABLax4XGF0w1Eol4oTD juow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BgPttg34novKpTJ1ZNpQfjOKpwM5DsFq3mUyHPE4N5M=; b=WXTyQ52cKpGz7apgEMxthUpW+PzZWVzCAOp58qhtLgrFyElDfxvfE8Xg4TZ07/vGr/ M3RKvRVla20fa+RSCNfHZckuRPiE9jrAkcgxYeoo8FGvqhvr65cGI2LqvyAqoEJ7fN/z yW7HKOuVPZgYUurxdzJdrunDX9bX0jXZ310zehNBp9H4LXEvEdHzTdJEV0zr9zPbntEd 4YnH9AC2IVnXBAGpQzyie/UKnG0HK0cC29q50Z+NxJA9yxRreEZAnJsVM/KeK00TKJ33 CZFIXfwqk7ts9WvkD+FffUcgZ3UjoWySYT+hsACqyWcTyKsFSyw8lxqmb4gz6hSZHely joTQ== X-Gm-Message-State: APjAAAVALoDJW3RAByyFxySR+bKvgBezVEcGfBo9g0CHKhlmN0Up6SIl ZuDRYEbl33uKvaXmIIJeLdf6iAHzPNz6hlWNfC0= X-Google-Smtp-Source: APXvYqxIRqAT0V6S61uavwcul4OBWcUhimZqMgU2lRYoefdDnh7VLq/kHAuIUaU4QCdLehux+R31LgwORyXhGvjB9xI= X-Received: by 2002:a2e:80cc:: with SMTP id r12mr23811861ljg.154.1577294336203; Wed, 25 Dec 2019 09:18:56 -0800 (PST) MIME-Version: 1.0 References: <02c101d5baef$de2cdd90$9a8698b0$@elvis.ru> <70FA58C0-97E1-4F76-B88B-A28101A46069@mit.edu> In-Reply-To: <70FA58C0-97E1-4F76-B88B-A28101A46069@mit.edu> From: Watson Ladd Date: Wed, 25 Dec 2019 09:18:44 -0800 Message-ID: To: Uri Blumenthal Cc: Valery Smyslov , "ipsec@ietf.org" , "last-call@ietf.org" , "draft-ietf-ipsecme-qr-ikev2.all@ietf.org" , secdir Content-Type: multipart/alternative; boundary="0000000000009da28a059a8a74a0" Archived-At: Subject: Re: [IPsec] [secdir] Secdir last call review of draft-ietf-ipsecme-qr-ikev2-09 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, 25 Dec 2019 17:19:00 -0000 --0000000000009da28a059a8a74a0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 25, 2019 at 3:57 AM Uri Blumenthal wrote: > NIST standards are mandatory for a subset of US citizens. But enough of > businesses outside the US pay attention to what NIST says to make adding > the reference relevant and useful. > It's not about standards, it's about the competition and the relevant security level definitions. Not that I feel strongly about it, just a suggestion. > On Dec 25, 2019, at 01:52, Valery Smyslov wrote: > > =EF=BB=BF > > Hi Watson, > > > > thank you for spending your time on this review in Christmas Eve. > > > > The capitalization issue has been already noticed and fixed. > > > > I=E2=80=99m not sure the draft should mention NIST levels, because > > they are relevant mostly for US customers. I think that > > generic recommendations on key sizes are more appropriate > > for this document. > > > > Regards, > > Valery. > > > > Damn misclick. I meant With Nits. > > > > On Tue, Dec 24, 2019 at 8:02 PM Watson Ladd via Datatracker < > noreply@ietf.org> wrote: > > Reviewer: Watson Ladd > Review result: Not Ready > > Twas the night before Christmas > when all through the house > someone was desperately trying to get a review done on time. > > I didn't see anything wrong per se in the draft itself, but I found the > capitalization of quantum computer an odd choice. IKEv2 is a complicated > protocol, and I am not 100% sure that this draft does what we want it to: > It > would be great if someone could check very carefully in some symbolic > model, > ala what has been done in TLS. The guidance on sizes seems to rule out NI= ST > level 1, but not any higher levels: might be worth calling out this > explicitly. > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > > > -- > > "Man is born free, but everywhere he is in chains". > --Rousseau. > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > --=20 "Man is born free, but everywhere he is in chains". --Rousseau. --0000000000009da28a059a8a74a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Dec 25, 2019 at 3:57 AM Uri B= lumenthal <uri@mit.edu> wrote:
=
N= IST standards are mandatory for a subset of US citizens. But enough of busi= nesses outside the US pay attention to what NIST says to make adding the re= ference relevant and useful.

It's= not about standards, it's about the competition and the relevant secur= ity level definitions. Not that I feel strongly about it, just a suggestion= .


On Dec 2= 5, 2019, at 01:52, Valery Smyslov <svan@elvis.ru> wrote:

=EF=BB=BF

= Hi Watson,

=C2=A0

thank you for spend= ing your time on this review in Christmas Eve.

= =C2=A0

The capitalization issue has been already noticed and fi= xed.

=C2=A0

I=E2=80=99m not sure the = draft should mention NIST levels, because

they are rele= vant mostly for US customers. I think that

generic reco= mmendations on key sizes are more appropriate

for this d= ocument.

=C2=A0

Regards,

Valery.

=C2=A0

Damn misclick. I meant With Nits.

=C2=A0

<= div>

On Tue, Dec 24, 2019 at 8:02 PM Watson Ladd via = Datatracker <norep= ly@ietf.org> wrote:

Revie= wer: Watson Ladd
Review result: Not Ready

Twas the night before C= hristmas
when all through the house
someone was desperately trying to= get a review done on time.

I didn't see anything wrong per se i= n the draft itself, but I found the
capitalization of quantum computer a= n odd choice. IKEv2 is a complicated
protocol, and I am not 100% sure th= at this draft does what we want it to: It
would be great if someone coul= d check very carefully in some symbolic model,
ala what has been done in= TLS. The guidance on sizes seems to rule out NIST
level 1, but not any = higher levels: might be worth calling out this explicitly.

_________= ______________________________________
secdir mailing list
secdir@ietf.org
https:/= /www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ie= tf.org/area/sec/trac/wiki/SecDirReview



--

=

"Man is born free, but everywhere he is in chai= ns".
--Rousseau.

_________= ______________________________________
secdir mailing list<= /span>
secdir= @ietf.org
https://www.ietf.org/mailman/listinfo/secdir<= /a>
wiki: http://tools.ietf.org/area/sec/trac/wiki= /SecDirReview


--
= "Man is born free, but everywhere he is in chains".
--Rousseau= .
--0000000000009da28a059a8a74a0-- From nobody Wed Dec 25 09:29:18 2019 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 3AE1D1200DF; Wed, 25 Dec 2019 09:29:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=smyslov.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 44Ni8lmLNJLz; Wed, 25 Dec 2019 09:29:13 -0800 (PST) Received: from direct.host-care.com (direct.host-care.com [198.136.54.115]) (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 110461200DB; Wed, 25 Dec 2019 09:29:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smyslov.net ; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To: References:Cc:To:From:Sender:Reply-To: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=rneZ+KmZPXE4LNeYoWlRDPfmgdao61WBWS1cvip/e7g=; b=sXPMNhDcsH8kXXduLuJ5ZuF/y6 N3u4q52nwAdad7OKHfQ9HaFkhn6IDpvltKtB9jLIInHBriMHCuenH6Sp0DO5j3wJ13GBP2NShfYi3 zJGPLYVEjHmQBjxYSuoTpXLNvgwaJnY3cCysrdNp0uhdyp3ZskNBGl4pW1owStzdDAIfyY0dUuRn7 4hLmphp81XiQxH409bhhg0iDc5lbiXBpnKh/3PrOV85zl8laxAeVUFjIGzUUia/X8GO/+JZaBlUZ9 0fJ++wYIxWnsAHTH2BCMnQnjOzZOhwxQYfgIX1mKhjbKpXwpzvquwfxKmKkvWhUkA1vea/WkGdXZO LnkVBc7A==; Received: from 95-27-147-103.broadband.corbina.ru ([95.27.147.103]:49183 helo=chichi) by direct.host-care.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.92) (envelope-from ) id 1ikAT7-0003Pr-PW; Wed, 25 Dec 2019 12:29:10 -0500 From: "Valery Smyslov" To: "'Watson Ladd'" , "'Uri Blumenthal'" Cc: , , "'secdir'" , , "'Valery Smyslov'" References: <02c101d5baef$de2cdd90$9a8698b0$@elvis.ru> <70FA58C0-97E1-4F76-B88B-A28101A46069@mit.edu> In-Reply-To: Date: Wed, 25 Dec 2019 20:29:04 +0300 Message-ID: <003901d5bb48$cfc21460$6f463d20$@smyslov.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003A_01D5BB61.F511BD60" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQD4j+CcA1FUw/w7bryPcykwDxxYVgHNoREJAqKWLLmpYe92IA== Content-Language: ru X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - direct.host-care.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - smyslov.net X-Get-Message-Sender-Via: direct.host-care.com: authenticated_id: valery@smyslov.net X-Authenticated-Sender: direct.host-care.com: valery@smyslov.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [IPsec] [secdir] Secdir last call review of draft-ietf-ipsecme-qr-ikev2-09 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, 25 Dec 2019 17:29:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_003A_01D5BB61.F511BD60 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 25, 2019 at 3:57 AM Uri Blumenthal < = uri@mit.edu> wrote: NIST standards are mandatory for a subset of US citizens. But enough of = businesses outside the US pay attention to what NIST says to make adding = the reference relevant and useful. =20 It's not about standards, it's about the competition and the relevant = security level definitions. Not that I feel strongly about it, just a = suggestion.. =20 Then I'm a bit confused. What competition do you mean?=20 =20 Regards, Valery. =20 =20 On Dec 25, 2019, at 01:52, Valery Smyslov wrote: =EF=BB=BF=20 Hi Watson, =20 thank you for spending your time on this review in Christmas Eve. =20 The capitalization issue has been already noticed and fixed. =20 I=E2=80=99m not sure the draft should mention NIST levels, because=20 they are relevant mostly for US customers. I think that=20 generic recommendations on key sizes are more appropriate for this document. =20 Regards, Valery. =20 Damn misclick. I meant With Nits. =20 On Tue, Dec 24, 2019 at 8:02 PM Watson Ladd via Datatracker = wrote: Reviewer: Watson Ladd Review result: Not Ready Twas the night before Christmas when all through the house someone was desperately trying to get a review done on time. I didn't see anything wrong per se in the draft itself, but I found the capitalization of quantum computer an odd choice. IKEv2 is a complicated protocol, and I am not 100% sure that this draft does what we want it = to: It would be great if someone could check very carefully in some symbolic = model, ala what has been done in TLS. The guidance on sizes seems to rule out = NIST level 1, but not any higher levels: might be worth calling out this = explicitly. _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --=20 "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --=20 "Man is born free, but everywhere he is in chains". --Rousseau.. ------=_NextPart_000_003A_01D5BB61.F511BD60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, = Dec 25, 2019 at 3:57 AM Uri Blumenthal <uri@mit.edu> = wrote:

NIST = standards are mandatory for a subset of US citizens. But enough of = businesses outside the US pay attention to what NIST says to make adding = the reference relevant and = useful.

 

It's not about standards, it's about the competition = and the relevant security level definitions. Not that I feel strongly = about it, just a suggestion..

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Then I'm a bit = confused. What competition do you mean?

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Regards,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Valery.

 

 



On Dec 25, 2019, at = 01:52, Valery Smyslov <svan@elvis.ru> = wrote:

=EF=BB=BF

Hi Watson,

 

thank you for spending your time on this review in Christmas = Eve.

 

The capitalization issue has been already noticed and = fixed.

 

I=E2=80=99m not sure the draft should mention NIST levels, because =

they are relevant mostly for US customers. I think that =

generic recommendations on key sizes are more = appropriate

for this document.

 

Regards,

Valery.

 

Damn = misclick. I meant With Nits.

 <= /o:p>

On Tue, Dec = 24, 2019 at 8:02 PM Watson Ladd via Datatracker <noreply@ietf.org> = wrote:

Reviewer: = Watson Ladd
Review result: Not Ready

Twas the night before = Christmas
when all through the house
someone was desperately = trying to get a review done on time.

I didn't see anything wrong = per se in the draft itself, but I found the
capitalization of quantum = computer an odd choice. IKEv2 is a complicated
protocol, and I am not = 100% sure that this draft does what we want it to: It
would be great = if someone could check very carefully in some symbolic model,
ala = what has been done in TLS. The guidance on sizes seems to rule out = NIST
level 1, but not any higher levels: might be worth calling out = this = explicitly.

_______________________________________________
sec= dir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wik= i: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview



--

_______________________________________________
secd= ir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wik= i: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview



--

------=_NextPart_000_003A_01D5BB61.F511BD60-- From nobody Wed Dec 25 10:24:53 2019 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 977021200E0; Wed, 25 Dec 2019 10:24:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 mIB5s54-D65C; Wed, 25 Dec 2019 10:24:48 -0800 (PST) Received: from outgoing-exchange-7.mit.edu (outgoing-exchange-7.mit.edu [18.9.28.58]) (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 6DDF11200E7; Wed, 25 Dec 2019 10:24:48 -0800 (PST) Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-7.mit.edu (8.14.7/8.12.4) with ESMTP id xBPIOS7s021422; Wed, 25 Dec 2019 13:24:38 -0500 Received: from oc11expo31.exchange.mit.edu (18.9.4.104) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 25 Dec 2019 13:23:07 -0500 Received: from oc11expo31.exchange.mit.edu (18.9.4.104) by oc11expo31.exchange.mit.edu (18.9.4.104) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 25 Dec 2019 13:24:38 -0500 Received: from oc11expo31.exchange.mit.edu ([18.9.4.104]) by oc11expo31.exchange.mit.edu ([18.9.4.104]) with mapi id 15.00.1365.000; Wed, 25 Dec 2019 13:24:38 -0500 From: Uri Blumenthal To: Valery Smyslov CC: Watson Ladd , "ipsec@ietf.org" , "last-call@ietf.org" , secdir , "draft-ietf-ipsecme-qr-ikev2.all@ietf.org" , Valery Smyslov Thread-Topic: [secdir] Secdir last call review of draft-ietf-ipsecme-qr-ikev2-09 Thread-Index: AQHVutgQJ9+wavcRBECx2knvNxQEcqfKlyyAgAAmsQCAAFU9gIAAWb8AgAAC4wCAAA+GgA== Date: Wed, 25 Dec 2019 18:24:38 +0000 Message-ID: <8A4F97F4-723E-41C8-B4F6-C6D65F0BC848@mit.edu> References: <003901d5bb48$cfc21460$6f463d20$@smyslov.net> In-Reply-To: <003901d5bb48$cfc21460$6f463d20$@smyslov.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/signed; boundary="Apple-Mail-8082967C-EE3A-4682-8429-A70DBA3D925D"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] [secdir] Secdir last call review of draft-ietf-ipsecme-qr-ikev2-09 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, 25 Dec 2019 18:24:51 -0000 --Apple-Mail-8082967C-EE3A-4682-8429-A70DBA3D925D Content-Type: multipart/alternative; boundary=Apple-Mail-431E8F48-78D4-4243-AAAF-1F35F0B11EAB Content-Transfer-Encoding: 7bit --Apple-Mail-431E8F48-78D4-4243-AAAF-1F35F0B11EAB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 TklTVCBwcm9kdWNlcyBzdGFuZGFyZHMgYW5kIHJlY29tbWVuZGF0aW9ucy4gVVMgZ292ZXJubWVu dCBvcmdhbml6YXRpb25zIGFuZCBjb21wYW5pZXMgZG9pbmcgYnVzaW5lc3Mgd2l0aCB0aGVtIGFy ZSB1c3VhbGx5IHJlcXVpcmVkIHRvIGNvbXBseS4gT3JnYW5pemF0aW9ucyBhbmQgYnVzaW5lc3Nl cyAoYm90aCBVUyBhbmQgbm9uLVVTKSB0aGF0IGFyZSBub3QgYm91bmQgYnkgVVMgcmVndWxhdGlv bnMsIG9mdGVuIHBheSBhdHRlbnRpb24gdG8gd2hhdCBOSVNUIHJlY29tbWVuZHMuIA0KDQpUbyBy ZXBlYXQgbXlzZWxmLCBpdCBtYWdlcyBzZW5zZSB0byBhZGQgcmVmZXJlbmNlIHRvIHRoZSBOSVNU IGxldmVscywgZXZlbiBpZiBXYXRzb24gZG9lc24ndCBpbnNpc3QuIDstKQ0KDQo+IE9uIERlYyAy NSwgMjAxOSwgYXQgMTI6MjksIFZhbGVyeSBTbXlzbG92IDx2YWxlcnlAc215c2xvdi5uZXQ+IHdy b3RlOg0KPiANCj4g77u/DQo+IE9uIFdlZCwgRGVjIDI1LCAyMDE5IGF0IDM6NTcgQU0gVXJpIEJs dW1lbnRoYWwgPHVyaUBtaXQuZWR1PiB3cm90ZToNCj4gTklTVCBzdGFuZGFyZHMgYXJlIG1hbmRh dG9yeSBmb3IgYSBzdWJzZXQgb2YgVVMgY2l0aXplbnMuIEJ1dCBlbm91Z2ggb2YgYnVzaW5lc3Nl cyBvdXRzaWRlIHRoZSBVUyBwYXkgYXR0ZW50aW9uIHRvIHdoYXQgTklTVCBzYXlzIHRvIG1ha2Ug YWRkaW5nIHRoZSByZWZlcmVuY2UgcmVsZXZhbnQgYW5kIHVzZWZ1bC4NCj4gIA0KPiBJdCdzIG5v dCBhYm91dCBzdGFuZGFyZHMsIGl0J3MgYWJvdXQgdGhlIGNvbXBldGl0aW9uIGFuZCB0aGUgcmVs ZXZhbnQgc2VjdXJpdHkgbGV2ZWwgZGVmaW5pdGlvbnMuIE5vdCB0aGF0IEkgZmVlbCBzdHJvbmds eSBhYm91dCBpdCwganVzdCBhIHN1Z2dlc3Rpb24uLg0KPiAgDQo+ICAgICAgICAgICBUaGVuIEkn bSBhIGJpdCBjb25mdXNlZC4gV2hhdCBjb21wZXRpdGlvbiBkbyB5b3UgbWVhbj8NCj4gIA0KPiAg ICAgICAgICAgUmVnYXJkcywNCj4gICAgICAgICAgIFZhbGVyeS4NCj4gIA0KPiAgDQo+IA0KPiAN Cj4gT24gRGVjIDI1LCAyMDE5LCBhdCAwMTo1MiwgVmFsZXJ5IFNteXNsb3YgPHN2YW5AZWx2aXMu cnU+IHdyb3RlOg0KPiANCj4g77u/DQo+IEhpIFdhdHNvbiwNCj4gIA0KPiB0aGFuayB5b3UgZm9y IHNwZW5kaW5nIHlvdXIgdGltZSBvbiB0aGlzIHJldmlldyBpbiBDaHJpc3RtYXMgRXZlLg0KPiAg DQo+IFRoZSBjYXBpdGFsaXphdGlvbiBpc3N1ZSBoYXMgYmVlbiBhbHJlYWR5IG5vdGljZWQgYW5k IGZpeGVkLg0KPiAgDQo+IEnigJltIG5vdCBzdXJlIHRoZSBkcmFmdCBzaG91bGQgbWVudGlvbiBO SVNUIGxldmVscywgYmVjYXVzZQ0KPiB0aGV5IGFyZSByZWxldmFudCBtb3N0bHkgZm9yIFVTIGN1 c3RvbWVycy4gSSB0aGluayB0aGF0DQo+IGdlbmVyaWMgcmVjb21tZW5kYXRpb25zIG9uIGtleSBz aXplcyBhcmUgbW9yZSBhcHByb3ByaWF0ZQ0KPiBmb3IgdGhpcyBkb2N1bWVudC4NCj4gIA0KPiBS ZWdhcmRzLA0KPiBWYWxlcnkuDQo+ICANCj4gRGFtbiBtaXNjbGljay4gSSBtZWFudCBXaXRoIE5p dHMuDQo+ICANCj4gT24gVHVlLCBEZWMgMjQsIDIwMTkgYXQgODowMiBQTSBXYXRzb24gTGFkZCB2 aWEgRGF0YXRyYWNrZXIgPG5vcmVwbHlAaWV0Zi5vcmc+IHdyb3RlOg0KPiBSZXZpZXdlcjogV2F0 c29uIExhZGQNCj4gUmV2aWV3IHJlc3VsdDogTm90IFJlYWR5DQo+IA0KPiBUd2FzIHRoZSBuaWdo dCBiZWZvcmUgQ2hyaXN0bWFzDQo+IHdoZW4gYWxsIHRocm91Z2ggdGhlIGhvdXNlDQo+IHNvbWVv bmUgd2FzIGRlc3BlcmF0ZWx5IHRyeWluZyB0byBnZXQgYSByZXZpZXcgZG9uZSBvbiB0aW1lLg0K PiANCj4gSSBkaWRuJ3Qgc2VlIGFueXRoaW5nIHdyb25nIHBlciBzZSBpbiB0aGUgZHJhZnQgaXRz ZWxmLCBidXQgSSBmb3VuZCB0aGUNCj4gY2FwaXRhbGl6YXRpb24gb2YgcXVhbnR1bSBjb21wdXRl ciBhbiBvZGQgY2hvaWNlLiBJS0V2MiBpcyBhIGNvbXBsaWNhdGVkDQo+IHByb3RvY29sLCBhbmQg SSBhbSBub3QgMTAwJSBzdXJlIHRoYXQgdGhpcyBkcmFmdCBkb2VzIHdoYXQgd2Ugd2FudCBpdCB0 bzogSXQNCj4gd291bGQgYmUgZ3JlYXQgaWYgc29tZW9uZSBjb3VsZCBjaGVjayB2ZXJ5IGNhcmVm dWxseSBpbiBzb21lIHN5bWJvbGljIG1vZGVsLA0KPiBhbGEgd2hhdCBoYXMgYmVlbiBkb25lIGlu IFRMUy4gVGhlIGd1aWRhbmNlIG9uIHNpemVzIHNlZW1zIHRvIHJ1bGUgb3V0IE5JU1QNCj4gbGV2 ZWwgMSwgYnV0IG5vdCBhbnkgaGlnaGVyIGxldmVsczogbWlnaHQgYmUgd29ydGggY2FsbGluZyBv dXQgdGhpcyBleHBsaWNpdGx5Lg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gc2VjZGlyIG1haWxpbmcgbGlzdA0KPiBzZWNkaXJAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZWNkaXINCj4gd2lr aTogaHR0cDovL3Rvb2xzLmlldGYub3JnL2FyZWEvc2VjL3RyYWMvd2lraS9TZWNEaXJSZXZpZXcN Cj4gDQo+IA0KPiAtLQ0KPiAiTWFuIGlzIGJvcm4gZnJlZSwgYnV0IGV2ZXJ5d2hlcmUgaGUgaXMg aW4gY2hhaW5zIi4NCj4gLS1Sb3Vzc2VhdS4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gc2VjZGlyIG1haWxpbmcgbGlzdA0KPiBzZWNkaXJAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZWNkaXINCj4g d2lraTogaHR0cDovL3Rvb2xzLmlldGYub3JnL2FyZWEvc2VjL3RyYWMvd2lraS9TZWNEaXJSZXZp ZXcNCj4gDQo+IA0KPiAtLQ0KPiAiTWFuIGlzIGJvcm4gZnJlZSwgYnV0IGV2ZXJ5d2hlcmUgaGUg aXMgaW4gY2hhaW5zIi4NCj4gLS1Sb3Vzc2VhdS4uDQo= --Apple-Mail-431E8F48-78D4-4243-AAAF-1F35F0B11EAB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPk5JU1QgcHJvZHVj ZXMgc3RhbmRhcmRzIGFuZCByZWNvbW1lbmRhdGlvbnMuIFVTIGdvdmVybm1lbnQgb3JnYW5pemF0 aW9ucyBhbmQgY29tcGFuaWVzIGRvaW5nIGJ1c2luZXNzIHdpdGggdGhlbSBhcmUgdXN1YWxseSBy ZXF1aXJlZCB0byBjb21wbHkuIE9yZ2FuaXphdGlvbnMgYW5kIGJ1c2luZXNzZXMgKGJvdGggVVMg YW5kIG5vbi1VUykgdGhhdCBhcmUgbm90IGJvdW5kIGJ5IFVTIHJlZ3VsYXRpb25zLCBvZnRlbiBw YXkgYXR0ZW50aW9uIHRvIHdoYXQgTklTVCByZWNvbW1lbmRzLiZuYnNwOzxkaXY+PGJyPjxkaXYg ZGlyPSJsdHIiPlRvIHJlcGVhdCBteXNlbGYsIGl0IG1hZ2VzIHNlbnNlIHRvIGFkZCByZWZlcmVu Y2UgdG8gdGhlIE5JU1QgbGV2ZWxzLCBldmVuIGlmIFdhdHNvbiBkb2Vzbid0IGluc2lzdC4gOy0p PC9kaXY+PGRpdiBkaXI9Imx0ciI+PGJyPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPk9uIERlYyAy NSwgMjAxOSwgYXQgMTI6MjksIFZhbGVyeSBTbXlzbG92ICZsdDt2YWxlcnlAc215c2xvdi5uZXQm Z3Q7IHdyb3RlOjxicj48YnI+PC9ibG9ja3F1b3RlPjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiPjxkaXYgZGlyPSJsdHIiPu+7vw0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBj b250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjxtZXRhIG5hbWU9IkdlbmVyYXRvciIg Y29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPjxzdHlsZT48IS0t DQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBN aW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkFyaWFsIFVuaWNvZGUgTVMiOw0KCXBhbm9zZS0x OjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJy aTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OiJcQE1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQEFyaWFsIFVuaWNvZGUgTVMiOw0KCXBhbm9zZS0x OjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05v cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjIuMGNtIDQyLjVwdCAyLjBjbSAzLjBjbTt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+PGRpdj48ZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIFdlZCwgRGVjIDI1LCAyMDE5IGF0IDM6NTcgQU0g VXJpIEJsdW1lbnRoYWwgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86dXJpQG1pdC5lZHUiPjxz cGFuIGxhbmc9IkVOLVVTIj51cmlAbWl0LmVkdTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMi PiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+PGRpdj48 cCBjbGFzcz0iTXNvTm9ybWFsIj5OSVNUIHN0YW5kYXJkcyBhcmUgbWFuZGF0b3J5IGZvciBhIHN1 YnNldCBvZiBVUyBjaXRpemVucy4gQnV0IGVub3VnaCBvZiBidXNpbmVzc2VzIG91dHNpZGUgdGhl IFVTIHBheSBhdHRlbnRpb24gdG8gd2hhdCBOSVNUIHNheXMgdG8gbWFrZSBhZGRpbmcgdGhlIHJl ZmVyZW5jZSByZWxldmFudCBhbmQgdXNlZnVsLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvYmxvY2tx dW90ZT48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQncyBub3QgYWJvdXQgc3RhbmRhcmRzLCBpdCdz IGFib3V0IHRoZSBjb21wZXRpdGlvbiBhbmQgdGhlIHJlbGV2YW50IHNlY3VyaXR5IGxldmVsIGRl ZmluaXRpb25zLiBOb3QgdGhhdCBJIGZlZWwgc3Ryb25nbHkgYWJvdXQgaXQsIGp1c3QgYSBzdWdn ZXN0aW9uLi48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEzLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEzLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFRoZW4gSSdtIGEgYml0IGNvbmZ1c2VkLiBXaGF0IGNvbXBldGl0aW9uIGRvIHlvdSBtZWFuPyA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTMuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTMuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTMuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgVmFsZXJ5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMy4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj48ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPjxicj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5PbiBEZWMgMjUsIDIw MTksIGF0IDAxOjUyLCBWYWxlcnkgU215c2xvdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN2YW5AZWx2 aXMucnUiIHRhcmdldD0iX2JsYW5rIj5zdmFuQGVsdmlzLnJ1PC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIj7vu78gPG86cD48L286cD48 L3A+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQ0NTQ2QSI+SGkgV2F0c29uLDwvc3Bhbj48bzpwPjwvbzpw PjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzQ0NTQ2QSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTQuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojNDQ1NDZBIj50aGFuayB5b3UgZm9yIHNwZW5kaW5nIHlvdXIgdGltZSBvbiB0 aGlzIHJldmlldyBpbiBDaHJpc3RtYXMgRXZlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE0LjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzQ0NTQ2QSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj NDQ1NDZBIj5UaGUgY2FwaXRhbGl6YXRpb24gaXNzdWUgaGFzIGJlZW4gYWxyZWFkeSBub3RpY2Vk IGFuZCBmaXhlZC48L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0NDU0NkEiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQ0NTQ2QSI+SeKAmW0gbm90 IHN1cmUgdGhlIGRyYWZ0IHNob3VsZCBtZW50aW9uIE5JU1QgbGV2ZWxzLCBiZWNhdXNlIDwvc3Bh bj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQ0NTQ2QSI+dGhleSBhcmUgcmVsZXZhbnQg bW9zdGx5IGZvciBVUyBjdXN0b21lcnMuIEkgdGhpbmsgdGhhdCA8L3NwYW4+PG86cD48L286cD48 L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiM0NDU0NkEiPmdlbmVyaWMgcmVjb21tZW5kYXRpb25zIG9uIGtleSBz aXplcyBhcmUgbW9yZSBhcHByb3ByaWF0ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzQ0NTQ2QSI+Zm9yIHRoaXMgZG9jdW1lbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTQu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojNDQ1NDZBIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiM0NDU0NkEiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNDQ1 NDZBIj5WYWxlcnkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNDQ1NDZBIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgd2luZG93dGV4dCAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0O2Jv cmRlci1jb2xvcjpjdXJyZW50Y29sb3IgY3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciBibHVlIj48 ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RGFtbiBtaXNjbGljay4gSSBtZWFudCBXaXRoIE5p dHMuPG86cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBUdWUsIERlYyAy NCwgMjAxOSBhdCA4OjAyIFBNIFdhdHNvbiBMYWRkIHZpYSBEYXRhdHJhY2tlciAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ub3JlcGx5QGlldGYu b3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzow Y20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdDtib3JkZXItY29sb3I6Y3VycmVudGNvbG9y IGN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgcmdiKDIwNCwyMDQsMjA0KSI+PHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5SZXZpZXdlcjogV2F0c29uIExhZGQ8YnI+UmV2aWV3IHJlc3VsdDogTm90IFJl YWR5PGJyPjxicj5Ud2FzIHRoZSBuaWdodCBiZWZvcmUgQ2hyaXN0bWFzPGJyPndoZW4gYWxsIHRo cm91Z2ggdGhlIGhvdXNlPGJyPnNvbWVvbmUgd2FzIGRlc3BlcmF0ZWx5IHRyeWluZyB0byBnZXQg YSByZXZpZXcgZG9uZSBvbiB0aW1lLjxicj48YnI+SSBkaWRuJ3Qgc2VlIGFueXRoaW5nIHdyb25n IHBlciBzZSBpbiB0aGUgZHJhZnQgaXRzZWxmLCBidXQgSSBmb3VuZCB0aGU8YnI+Y2FwaXRhbGl6 YXRpb24gb2YgcXVhbnR1bSBjb21wdXRlciBhbiBvZGQgY2hvaWNlLiBJS0V2MiBpcyBhIGNvbXBs aWNhdGVkPGJyPnByb3RvY29sLCBhbmQgSSBhbSBub3QgMTAwJSBzdXJlIHRoYXQgdGhpcyBkcmFm dCBkb2VzIHdoYXQgd2Ugd2FudCBpdCB0bzogSXQ8YnI+d291bGQgYmUgZ3JlYXQgaWYgc29tZW9u ZSBjb3VsZCBjaGVjayB2ZXJ5IGNhcmVmdWxseSBpbiBzb21lIHN5bWJvbGljIG1vZGVsLDxicj5h bGEgd2hhdCBoYXMgYmVlbiBkb25lIGluIFRMUy4gVGhlIGd1aWRhbmNlIG9uIHNpemVzIHNlZW1z IHRvIHJ1bGUgb3V0IE5JU1Q8YnI+bGV2ZWwgMSwgYnV0IG5vdCBhbnkgaGlnaGVyIGxldmVsczog bWlnaHQgYmUgd29ydGggY2FsbGluZyBvdXQgdGhpcyBleHBsaWNpdGx5Ljxicj48YnI+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+c2VjZGlyIG1haWxp bmcgbGlzdDxicj48YSBocmVmPSJtYWlsdG86c2VjZGlyQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+c2VjZGlyQGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NlY2RpciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2VjZGlyPC9hPjxicj53aWtpOiA8YSBocmVmPSJodHRwOi8v dG9vbHMuaWV0Zi5vcmcvYXJlYS9zZWMvdHJhYy93aWtpL1NlY0RpclJldmlldyIgdGFyZ2V0PSJf YmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9hcmVhL3NlYy90cmFjL3dpa2kvU2VjRGlyUmV2 aWV3PC9hPjxvOnA+PC9vOnA+PC9wPjwvYmxvY2txdW90ZT48L2Rpdj48cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxiciBjbGVhcj0iYWxsIj48YnI+LS0gPG86cD48L286cD48L3A+PGRpdj48cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiJNYW4gaXMgYm9ybiBmcmVlLCBidXQgZXZlcnl3aGVyZSBoZSBpcyBp biBjaGFpbnMiLjxicj4tLVJvdXNzZWF1LjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvZGl2 PjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPnNlY2RpciBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOnNl Y2RpckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNlY2RpckBpZXRmLm9yZzwvYT48YnI+PGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZWNkaXIiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NlY2Rpcjwv YT48YnI+d2lraTogPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2FyZWEvc2VjL3RyYWMv d2lraS9TZWNEaXJSZXZpZXciIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcv YXJlYS9zZWMvdHJhYy93aWtpL1NlY0RpclJldmlldzwvYT48bzpwPjwvbzpwPjwvcD48L2Rpdj48 L2Jsb2NrcXVvdGU+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2PjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiciBjbGVhcj0iYWxsIj48YnI+LS0gPG86cD48L286cD48L3A+PGRpdj48cCBjbGFz cz0iTXNvTm9ybWFsIj4iTWFuIGlzIGJvcm4gZnJlZSwgYnV0IGV2ZXJ5d2hlcmUgaGUgaXMgaW4g Y2hhaW5zIi48YnI+LS1Sb3Vzc2VhdS4uPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+ PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2PjwvYm9keT48L2h0bWw+ --Apple-Mail-431E8F48-78D4-4243-AAAF-1F35F0B11EAB-- --Apple-Mail-8082967C-EE3A-4682-8429-A70DBA3D925D Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCGsw ggQkMIICjKADAgECAgRbkXGgMA0GCSqGSIb3DQEBDAUAMBoxGDAWBgNVBAMMD0ZvcmVzdCBDQSBS U0EgNDAeFw0xODA5MDYxODI3NDRaFw0yMTA5MDYxODI3NDRaMA4xDDAKBgNVBAMMA1VyaTCCAaIw DQYJKoZIhvcNAQEBBQADggGPADCCAYoCggGBANJi8+lfrSCcWThbn0vQzXsW7AYTyTZSo/pv/274 xD/t1rpn/X/vegP2lSfr+SRJ4oJ+51MFJvRl/sAveroDN8gGrFyYaCg5ZsOMqksCmLha4Ttgk04L I/aqrPGuzF1OVgjhi6WrnFr80KS6sy3MWzYIYV6G1FycKEup5snMr1B1WWzFKOwSslnJwvCuHu2W Tc5OzJKPtxMcDIS9y6VOZTzsJUFe0bRiw0LICDBcB3fgKCvYMcDfke0pw13I4O7wEG40s9E6rTIj Q0H1LVk69pSo1ikzpikl5W8pXUQQrSmjHqhFn/Q+PwSzHSOralN0p1UMziUv57lgvvZbTaH1ooqq MZBuTed0xLye3w+h9+/iqDY4B7lFqbegzseBh7/Q6KdtfpkwwI7xSpZEME/V77KAMw+ipb+Itbij Bi3r/t81fDW8eitIAbVtalpFROlYIaZnIIohOZRyVjn2unZ+lj3jDKsDq53g+oleo+Ruszlt8nju 6uKhzE7bdX1xJuvCtwIDAQABo34wfDAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFIDAWBgNV HREEDzANgQt1cmlAbWl0LmVkdTAdBgNVHQ4EFgQU2p+nwSyQFM6byFBhc7oIZephJbcwJQYDVR0l BB4wHAYIKwYBBQUHAwQGCisGAQQBgjcKAwQGBFUdJQAwDQYJKoZIhvcNAQEMBQADggGBAH/zzG9P gU+ogFbc75JpUK0amUUtmtSsGDe4599GolCDiuPHrnbCGcaNc9aQjRaP3Q3aU7BB3aOjwssjQSN0 tsfZD8p+XPny/odhDSwS/25jCg0dVasd8q+Jd1S1g34RGUqPQ+5ofTrBSEkHBdLdJOnxBGo9GRzA yiDg34r6zK6BXNYv2GdqRk+GGGvL/w3CDR+ih36ZDBxw/EO19oH/aV4+mVlcRI6aoj4KMb+h4zMY S8jLDArIZSce4EWzJqxKVcX6Q7CE/0Br/7R8Ixs+vt5YKPUVpEbFM6koH624GDQYKM2kzXBnwYgS /jvl02KUx6uNmIgo+ufK2l7sc83vRLxBTJKhT0/USVkwu9uzg2zHJeGBZ4pmDhkIVkGcamW7KPYZ dgOz8zAOy8Ntk7GebPn85XuPcQS9UntdO61X1EyEXg4Ixl/qapidfJQfdCqEeZZXpaV3WKWE8u1l fNB00mC0/xhG3bikQxl3O20nyPjXvl6VZFzglsPRy1Xh5L//rzCCBD8wggKnoAMCAQICBFuRckIw DQYJKoZIhvcNAQEMBQAwGjEYMBYGA1UEAwwPRm9yZXN0IENBIFJTQSA0MB4XDTE4MDkwNjE4MzAy NloXDTIxMDkwNjE4MzAyNlowDjEMMAoGA1UEAwwDVXJpMIIBojANBgkqhkiG9w0BAQEFAAOCAY8A MIIBigKCAYEAtZvms8stf9xj5w7pjYzgmHe7TH0eX/q3buMBqdLufhFuqCizZPhXJmSbue8WHm8H HO7SHQPUqIqbPOMIQfAL8nwWhuTfsN5nrtFW77eiNsEexRNkbhw/U6RzamCGl6xQmUxOD0nabEmd Xdces+rjtzlvjpNHI7xrR32ee4JuGTjwAWlAHPtBC8TqiOR/ysR2K2umk5BkjCEWV9kDfGklfKmu IhuCzzpTvN3AnLMX9kP9IY6E9B8OsLOhkOFBbAMzyqkXibtPWluqOnYW3V3MVc9H1ir6sGLF5onW lHLEorI51WuHlfVO8WJRYwhrzQIIAWAYheZaH2wdb87Kw6o4JbHDLTDJHHrBDwfqa5OtFTeQNWCD JPdHa4xfFpjnMTzP18POa5C6QN5XBpTFsfccWyEdt+ykGB2FMzhB3GgMVRfWPgo8TgxVwU9MHt8s vmxj8KMUd7afSJBOjMIRPZ6gi8Vja9SR9+Hj/YWgpKZMHhI7irJVpWF++7hhfxxDbgDBAgMBAAGj gZgwgZUwDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBsAwFgYDVR0RBA8wDYELdXJpQG1pdC5l ZHUwHQYDVR0OBBYEFK3WLENy4CH330dGZEWchN+L1r28MD4GA1UdJQQ3MDUGCCsGAQUFBwMCBggr BgEFBQcDAwYKKwYBBAGCNwoDDAYJKoZIhvcvAQEFBggrBgEFBQcDBDANBgkqhkiG9w0BAQwFAAOC AYEACYbThcFo+JTQNP5UacMtYogWU/yOx5GBLSNNa5cpvoRrOJc9CUDfzfnrd7IhDLXvnFUYNt3i oyU13LKRoPsp/YYuZ2CBI1om9g27SSqqEcOom0eojIKkPNw+sJzYVl7Dz2I7f9DHN6nEC9BeT8Do rjuq67UOlZZw0YvlvCmtMI4xJ7CUM8NrphoeRN18OnbwmkHWIYnYwdxipTJ8oLWi5EbKaUEYyLlC JWd6o9vH8cFNzsViPUl9POxBtX++o5KxtW7/JQwrQt3uFubF6rHQag6HDeXcXSyI0DmL8MrfVtHi Ma2bN+7z8N9Wnuvx8v0qlqfwd+uhmP7OvD32PuzjQxuGyPd43DZazlMhY9IRpSSCPhdbxzS3YwKr jnTZlKGwPiYCmiQ0XSEW3K64Exe4t+jrkBReocr9ccslB4d4XhxQPdAvUdI43xGMbnFea7pyTDyP b0z1vMrYt6dAguU0QTgRZsPFoIldK70ILvncq9amhxuQ4Uw+u2WUXiYba2R1MYICoTCCAp0CAQEw IjAaMRgwFgYDVQQDDA9Gb3Jlc3QgQ0EgUlNBIDQCBFuRckIwDQYJYIZIAWUDBAIBBQCggdEwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkxMjI1MTgyNDM3WjAvBgkq hkiG9w0BCQQxIgQg8R4guve9bByBQIhrZIQZ3cwEwVZs9lzBN8nL6mpUWIswMQYJKwYBBAGCNxAE MSQwIjAaMRgwFgYDVQQDDA9Gb3Jlc3QgQ0EgUlNBIDQCBFuRcaAwMwYLKoZIhvcNAQkQAgsxJKAi MBoxGDAWBgNVBAMMD0ZvcmVzdCBDQSBSU0EgNAIEW5FxoDANBgkqhkiG9w0BAQEFAASCAYAuUkGB 1dQ+ox7OXUzXJXdonLpP8Z2aPRIbx3rr/uuj8khZ13cYTs91v+ZiKebxqWOBILSA2NdCvXRcpXpk pbVotNgNguDexkkxUvZO6MatKqHCQyvwncBp8+Uf0wTG/JrZhSJnjPaGzy+dYJcjFlWTiB9XdOPc nak4m8zqug7ZJ/cPLGQg7nsfgrkk1Z18ZOSqmEWveOmDDZp4WAQ1FBswBdwQilQoJcw4Kzb3+8Va qoei3q4tmeKDFsQ5FscnQ88qtrNMv/Yv4LEnFnxI9eoSNLysR/JFDzsdzkpmbYmibX+G5Wc2N+AL nAGiCtvRuai10IdhPhds1hi9+A1FwhCgis9Jya1DryXdWVn5Yx2Ioz0FYKp510tfkFObIs3X247Y avcvBfvYfbajemwXT8/mbtKgVQgSqvod3rZOIIji2Xpk0bgGxv4YC/aOWXxcs9Wpz5mzpGyVt0uB l8VjhBWDli0g7Jyp9AWvV2wbl59nfqwvuDEWmNptcLH7KpH5eCwAAAAAAAA= --Apple-Mail-8082967C-EE3A-4682-8429-A70DBA3D925D-- From nobody Wed Dec 25 10:27:50 2019 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 7A15D1200DB; Wed, 25 Dec 2019 10:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 r32pKvhNhLW1; Wed, 25 Dec 2019 10:27:42 -0800 (PST) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 1D8A412002E; Wed, 25 Dec 2019 10:27:42 -0800 (PST) Received: by mail-lf1-x12f.google.com with SMTP id n25so17204838lfl.0; Wed, 25 Dec 2019 10:27:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lkQ7Vm1PUpSLKKHrqsAdIkrON01hExJHJXQzZS/zYrI=; b=EOjxngl7r/opo66b0GMqSGLf1aa+IR3oKnCg6CgxYRV0hBfL8AODF9GGaGgsuePw5F WlEnK08+BD1+MjWssCrBVPhYQDXuLDGa+mRqgHEep7bwS06B2YdqCtj3lzpCFkMOw4pb X5rynxLfitGjM+2rQjF1p0mIdkIBVvRoz+x381HO1LsQSv69O9VxGNc/CKYcoH2/9O/A qoxT6DAmen+Hh1mjaSslmq0aouAJclsTmE/DFtNdaosGqfhmjdLciPRFnO92p1lJYkuv HImy7pLFT46ZzI/fqfiCQTE0zMOlUHJ5TQQUaepeoiqvtS7wuJJ2fhq9YZJlpd5CvQw/ 5ALQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lkQ7Vm1PUpSLKKHrqsAdIkrON01hExJHJXQzZS/zYrI=; b=SP0/fAQZv5j8x5oGXQ9UO+uzyzcur/ijrtWHbNBUSL2VUSzPGuwsBz5aSdXKpqNn3U ixdjRG82d8J+LHEVXHJTSZMSjY8t7fCyzHHbNltp6fHikB7cwUAXo0hZiiNpVvwKUdfe OZeU1LaoK+D07HnY5RV+9Oz9BBJ49hT6iGcY9SJePwACpf11wQtODWQqtqmsQHsF5jLT bA/okOEq6Y2ERmUrPX2li3eAxybtKIe6kYdRdpROn2OlkC6C9q7MeOsh2vzNFLCPfBlu q74N78OLJduwrIRXbzuJAjMtuIRt1D+32CtXlhr6rk4zrd2YF48fF72pM/u1ta4D0EBX 9HsQ== X-Gm-Message-State: APjAAAVZpVCzTUTmH4/3NwseCVcnsU30H+v3IX+r5qprn+xbQNkUeU9X B8xwJfhgh5A+bqmACffMibZJeRq37HaGtXCxeaw= X-Google-Smtp-Source: APXvYqzHDdxGCRbgrFwCHDfjlOgRMd8+ZW5pqk9eN4tCp54/A56EgO4H1YENjkC9if0teJzNrvg4n+/f96JONebXWuI= X-Received: by 2002:a19:6509:: with SMTP id z9mr23369445lfb.97.1577298460360; Wed, 25 Dec 2019 10:27:40 -0800 (PST) MIME-Version: 1.0 References: <003901d5bb48$cfc21460$6f463d20$@smyslov.net> <8A4F97F4-723E-41C8-B4F6-C6D65F0BC848@mit.edu> In-Reply-To: <8A4F97F4-723E-41C8-B4F6-C6D65F0BC848@mit.edu> From: Watson Ladd Date: Wed, 25 Dec 2019 10:27:29 -0800 Message-ID: To: Uri Blumenthal Cc: Valery Smyslov , "ipsec@ietf.org" , "last-call@ietf.org" , secdir , "draft-ietf-ipsecme-qr-ikev2.all@ietf.org" , Valery Smyslov Content-Type: multipart/alternative; boundary="0000000000006f441f059a8b6add" Archived-At: Subject: Re: [IPsec] [secdir] Secdir last call review of draft-ietf-ipsecme-qr-ikev2-09 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, 25 Dec 2019 18:27:45 -0000 --0000000000006f441f059a8b6add Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm talking about the ongoing NIST quantum cryptography competition, which targets at the lowest level security equivalent to AES-128. On Wed, Dec 25, 2019 at 10:24 AM Uri Blumenthal wrote: > NIST produces standards and recommendations. US government organizations > and companies doing business with them are usually required to comply. > Organizations and businesses (both US and non-US) that are not bound by U= S > regulations, often pay attention to what NIST recommends. > > To repeat myself, it mages sense to add reference to the NIST levels, eve= n > if Watson doesn't insist. ;-) > > On Dec 25, 2019, at 12:29, Valery Smyslov wrote: > > =EF=BB=BF > > On Wed, Dec 25, 2019 at 3:57 AM Uri Blumenthal wrote: > > NIST standards are mandatory for a subset of US citizens. But enough of > businesses outside the US pay attention to what NIST says to make adding > the reference relevant and useful. > > > > It's not about standards, it's about the competition and the relevant > security level definitions. Not that I feel strongly about it, just a > suggestion.. > > > > Then I'm a bit confused. What competition do you mean? > > > > Regards, > > Valery. > > > > > > > > On Dec 25, 2019, at 01:52, Valery Smyslov wrote: > > =EF=BB=BF > > Hi Watson, > > > > thank you for spending your time on this review in Christmas Eve. > > > > The capitalization issue has been already noticed and fixed. > > > > I=E2=80=99m not sure the draft should mention NIST levels, because > > they are relevant mostly for US customers. I think that > > generic recommendations on key sizes are more appropriate > > for this document. > > > > Regards, > > Valery. > > > > Damn misclick. I meant With Nits. > > > > On Tue, Dec 24, 2019 at 8:02 PM Watson Ladd via Datatracker < > noreply@ietf.org> wrote: > > Reviewer: Watson Ladd > Review result: Not Ready > > Twas the night before Christmas > when all through the house > someone was desperately trying to get a review done on time. > > I didn't see anything wrong per se in the draft itself, but I found the > capitalization of quantum computer an odd choice. IKEv2 is a complicated > protocol, and I am not 100% sure that this draft does what we want it to: > It > would be great if someone could check very carefully in some symbolic > model, > ala what has been done in TLS. The guidance on sizes seems to rule out NI= ST > level 1, but not any higher levels: might be worth calling out this > explicitly. > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > > > -- > > "Man is born free, but everywhere he is in chains". > --Rousseau. > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > > > -- > > "Man is born free, but everywhere he is in chains". > --Rousseau.. > > --=20 "Man is born free, but everywhere he is in chains". --Rousseau. --0000000000006f441f059a8b6add Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm talking about the ongoing NIST qu= antum cryptography competition, which targets at the lowest level security = equivalent to AES-128.

On Wed, Dec 25, 2019 at 10:24 AM Uri Blumenthal &= lt;uri@mit.edu> wrote:
NIST produce= s standards and recommendations. US government organizations and companies = doing business with them are usually required to comply. Organizations and = businesses (both US and non-US) that are not bound by US regulations, often= pay attention to what NIST recommends.=C2=A0

To r= epeat myself, it mages sense to add reference to the NIST levels, even if W= atson doesn't insist. ;-)

On Dec 25, 2019, at 12:29, Valery Smyslov <valery@smyslov.net> wrote:

=
=EF=BB=BF

On Wed, Dec 25, 2019 at 3:57 AM Uri Blumenthal <uri@mit.edu= > wrote:

<= blockquote style=3D"border-color:currentcolor currentcolor currentcolor rgb= (204,204,204);border-style:none none none solid;border-width:medium medium = medium 1pt;padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm">

NIST standards are mandatory for a subset of US cit= izens. But enough of businesses outside the US pay attention to what NIST s= ays to make adding the reference relevant and useful.

=C2=A0

It's not about standards, it's about the = competition and the relevant security level definitions. Not that I feel st= rongly about it, just a suggestion..

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Then I'm a bit confused. What competition do you mean?

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Regards,

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Valery.

=C2=A0<= /u>

=C2=A0



On Dec 25, 2019, at 01:52, Valery Smyslov <svan@elvis.ru> wrote:<= u>

=EF=BB=BF

Hi Watson,

=C2=A0

thank you for spending your time on= this review in Christmas Eve.

=C2=A0

The capitalization issue has been already noticed and fixed.=

=C2=A0

I=E2=80=99m not sure the draft should menti= on NIST levels, because

they are relevant mostly for US= customers. I think that

generic recommendations on key= sizes are more appropriate

= for this document.=

=C2=A0

Regards,

Valery.

=C2=A0

Damn misclick. I meant With Nits.

=C2=A0

On Tue, Dec 24, 2019 at 8:02 PM Watson Ladd via Datatracker <noreply@ietf.org>= wrote:

Reviewer: Watson Ladd
Review re= sult: Not Ready

Twas the night before Christmas
when all through = the house
someone was desperately trying to get a review done on time.
I didn't see anything wrong per se in the draft itself, but I fou= nd the
capitalization of quantum computer an odd choice. IKEv2 is a comp= licated
protocol, and I am not 100% sure that this draft does what we wa= nt it to: It
would be great if someone could check very carefully in som= e symbolic model,
ala what has been done in TLS. The guidance on sizes s= eems to rule out NIST
level 1, but not any higher levels: might be worth= calling out this explicitly.

______________________________________= _________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/= secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDi= rReview



--

"Ma= n is born free, but everywhere he is in chains".
--Rousseau.=

_______________________= ________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/ma= ilman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/= trac/wiki/SecDirReview

=



-- <= u>

"Man is born free, but everywher= e he is in chains".
--Rousseau..


=
--
"Man is born fre= e, but everywhere he is in chains".
--Rousseau.
--0000000000006f441f059a8b6add-- From nobody Wed Dec 25 10:44:27 2019 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 5A4EF1200A1; Wed, 25 Dec 2019 10:44:20 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 AZGoerrZBrVP; Wed, 25 Dec 2019 10:44:17 -0800 (PST) Received: from akmail.elvis.ru (akmail.elvis.ru [82.138.51.97]) (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 2D42812002E; Wed, 25 Dec 2019 10:44:17 -0800 (PST) Received: from kmail2.elvis.ru ([93.188.44.210]) by akmail.elvis.ru with esmtp (Exim 4.89) (envelope-from ) id 1ikBdm-0007y3-9P; Wed, 25 Dec 2019 21:44:14 +0300 Received: from mail16.office.elvis.ru ([10.111.1.29] helo=mail.office.elvis.ru) by kmail2.elvis.ru with esmtp (Exim 4.89) (envelope-from ) id 1ikBdl-0001H0-BP; Wed, 25 Dec 2019 21:44:14 +0300 Received: from MAIL16.office.elvis.ru (10.111.1.29) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Wed, 25 Dec 2019 21:44:10 +0300 Received: from chichi (10.100.100.5) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server id 15.1.1779.2 via Frontend Transport; Wed, 25 Dec 2019 21:44:07 +0300 From: Valery Smyslov To: 'Watson Ladd' , 'Uri Blumenthal' CC: 'Valery Smyslov' , , , 'secdir' , References: <003901d5bb48$cfc21460$6f463d20$@smyslov.net> <8A4F97F4-723E-41C8-B4F6-C6D65F0BC848@mit.edu> In-Reply-To: Date: Wed, 25 Dec 2019 21:44:05 +0300 Message-ID: <007b01d5bb53$48c557f0$da5007d0$@elvis.ru> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007C_01D5BB6C.6E143DA0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHdvvqKSyXWSys4i9wLZip4/JKSjgI7xNqsAbHYPj2nm7dRkA== Content-Language: ru X-CrossPremisesHeadersFilteredBySendConnector: MAIL16.office.elvis.ru X-OrganizationHeadersPreserved: MAIL16.office.elvis.ru X-Spam-Scanner: Rspamd work in kmail2.elvis.ru, WHITELIST X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Status: not scanned, disabled by settings X-KLMS-AntiPhishing: Clean, bases: 2019/12/25 18:17:00 X-KLMS-AntiVirus: Kaspersky Security for Linux Mail Server, version 8.0.3.30, bases: 2019/12/25 14:37:00 #14886745 X-KLMS-AntiVirus-Status: Clean, skipped X-Spam-Scanner: Rspamd work in akmail.elvis.ru, WHITELIST Archived-At: Subject: Re: [IPsec] [secdir] Secdir last call review of draft-ietf-ipsecme-qr-ikev2-09 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, 25 Dec 2019 18:44:20 -0000 ------=_NextPart_000_007C_01D5BB6C.6E143DA0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Do you mean the post-quantum cryptography competition = (https://csrc.nist.gov/Projects/post-quantum-cryptography)?=20 =20 That's why I felt confused. The draft isn't concerned with any = post-quantum cryptography stuff, it uses only well-studied methods of classical cryptography. I don't = think this particular=20 competition is relevant here. =20 However, taking into consideration Grover's algorithm, it seems that 128 = bit level is the maximum available for the current off-the-shelf crypto algorithms (I'm not aware = of any widely used cipher with key=20 length more than 256 bit). =20 Regards, Valery. =20 =20 I'm talking about the ongoing NIST quantum cryptography competition, = which targets at the lowest level security equivalent to AES-128. =20 On Wed, Dec 25, 2019 at 10:24 AM Uri Blumenthal wrote: NIST produces standards and recommendations. US government organizations = and companies doing business with them are usually required to comply. = Organizations and businesses (both US and non-US) that are not bound by = US regulations, often pay attention to what NIST recommends.=20 =20 To repeat myself, it mages sense to add reference to the NIST levels, = even if Watson doesn't insist. ;-) On Dec 25, 2019, at 12:29, Valery Smyslov wrote: =EF=BB=BF=20 On Wed, Dec 25, 2019 at 3:57 AM Uri Blumenthal < = uri@mit.edu> wrote: NIST standards are mandatory for a subset of US citizens. But enough of = businesses outside the US pay attention to what NIST says to make adding = the reference relevant and useful. =20 It's not about standards, it's about the competition and the relevant = security level definitions. Not that I feel strongly about it, just a = suggestion.. =20 Then I'm a bit confused. What competition do you mean?=20 =20 Regards, Valery. =20 =20 =20 On Dec 25, 2019, at 01:52, Valery Smyslov wrote: =EF=BB=BF=20 Hi Watson, =20 thank you for spending your time on this review in Christmas Eve. =20 The capitalization issue has been already noticed and fixed. =20 I=E2=80=99m not sure the draft should mention NIST levels, because=20 they are relevant mostly for US customers. I think that=20 generic recommendations on key sizes are more appropriate for this document. =20 Regards, Valery. =20 Damn misclick. I meant With Nits. =20 On Tue, Dec 24, 2019 at 8:02 PM Watson Ladd via Datatracker = wrote: Reviewer: Watson Ladd Review result: Not Ready Twas the night before Christmas when all through the house someone was desperately trying to get a review done on time. I didn't see anything wrong per se in the draft itself, but I found the capitalization of quantum computer an odd choice. IKEv2 is a complicated protocol, and I am not 100% sure that this draft does what we want it = to: It would be great if someone could check very carefully in some symbolic = model, ala what has been done in TLS. The guidance on sizes seems to rule out = NIST level 1, but not any higher levels: might be worth calling out this = explicitly. _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --=20 "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --=20 "Man is born free, but everywhere he is in chains". --Rousseau.. --=20 "Man is born free, but everywhere he is in chains". --Rousseau. ------=_NextPart_000_007C_01D5BB6C.6E143DA0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Do you mean the post-quantum cryptography competition = (https://csrc.nist.gov/Projects/post-quantum-cryptography)?

 

That's why I felt confused. The draft isn't concerned with any = post-quantum cryptography stuff,

it uses only well-studied methods of classical cryptography. I don't = think this particular

competition is relevant here.

 

However, taking into consideration Grover's algorithm, it seems that = 128 bit level is the maximum

available for the current off-the-shelf crypto algorithms (I'm not = aware of any widely used cipher with key

length more than 256 bit).

 

Regards,

Valery.

 

 

I'm talking = about the ongoing NIST quantum cryptography competition, which targets = at the lowest level security equivalent to = AES-128.

 

On Wed, Dec 25, 2019 at 10:24 AM Uri Blumenthal <uri@mit.edu> = wrote:

NIST = produces standards and recommendations. US government organizations and = companies doing business with them are usually required to comply. = Organizations and businesses (both US and non-US) that are not bound by = US regulations, often pay attention to what NIST = recommends. 

 

To = repeat myself, it mages sense to add reference to the NIST levels, even = if Watson doesn't insist. ;-)



On Dec 25, 2019, at 12:29, Valery Smyslov = <valery@smyslov.net> = wrote:

=EF=BB=BF

On Wed, Dec 25, 2019 at 3:57 AM Uri Blumenthal = <uri@mit.edu> = wrote:

NIST = standards are mandatory for a subset of US citizens. But enough of = businesses outside the US pay attention to what NIST says to make adding = the reference relevant and = useful.

 <= /o:p>

It's not = about standards, it's about the competition and the relevant security = level definitions. Not that I feel strongly about it, just a = suggestion..

 

          Then I'm a bit = confused. What competition do you mean?

 

          = Regards,

          = Valery.

 

 

 <= /p>

On Dec 25, 2019, = at 01:52, Valery Smyslov <svan@elvis.ru> = wrote:

=EF=BB=BF =

Hi Watson,

 

thank you for spending your time on this review in Christmas = Eve.

 

The capitalization issue has been already noticed and = fixed.

 

I=E2=80=99m not sure the draft should mention NIST levels, because =

they are relevant mostly for US customers. I think that =

generic recommendations on key sizes are more = appropriate

for this document.

 

Regards,

Valery.

 

Damn = misclick. I meant With Nits.

 <= /o:p>

On Tue, Dec = 24, 2019 at 8:02 PM Watson Ladd via Datatracker <noreply@ietf.org> = wrote:

Reviewer: = Watson Ladd
Review result: Not Ready

Twas the night before = Christmas
when all through the house
someone was desperately = trying to get a review done on time.

I didn't see anything wrong = per se in the draft itself, but I found the
capitalization of quantum = computer an odd choice. IKEv2 is a complicated
protocol, and I am not = 100% sure that this draft does what we want it to: It
would be great = if someone could check very carefully in some symbolic model,
ala = what has been done in TLS. The guidance on sizes seems to rule out = NIST
level 1, but not any higher levels: might be worth calling out = this = explicitly.

_______________________________________________
sec= dir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wik= i: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview



--

____________= ___________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wik= i: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview



--



--

------=_NextPart_000_007C_01D5BB6C.6E143DA0-- From nobody Wed Dec 25 10:45:39 2019 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 61F5512002E; Wed, 25 Dec 2019 10:45:31 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 FvJuo-nDUb9m; Wed, 25 Dec 2019 10:45:29 -0800 (PST) Received: from akmail.elvis.ru (akmail.elvis.ru [82.138.51.97]) (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 F315D1200DB; Wed, 25 Dec 2019 10:45:28 -0800 (PST) Received: from kmail2.elvis.ru ([93.188.44.210]) by akmail.elvis.ru with esmtp (Exim 4.89) (envelope-from ) id 1ikBew-0007yp-LF; Wed, 25 Dec 2019 21:45:27 +0300 Received: from mail16.office.elvis.ru ([10.111.1.29] helo=mail.office.elvis.ru) by kmail2.elvis.ru with esmtp (Exim 4.89) (envelope-from ) id 1ikBev-0001I8-TO; Wed, 25 Dec 2019 21:45:26 +0300 Received: from MAIL16.office.elvis.ru (10.111.1.29) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Wed, 25 Dec 2019 21:45:24 +0300 Received: from chichi (10.100.100.5) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server id 15.1.1779.2 via Frontend Transport; Wed, 25 Dec 2019 21:45:22 +0300 From: Valery Smyslov To: 'Uri Blumenthal' , 'Valery Smyslov' CC: 'Watson Ladd' , , , 'secdir' , References: <003901d5bb48$cfc21460$6f463d20$@smyslov.net> <8A4F97F4-723E-41C8-B4F6-C6D65F0BC848@mit.edu> In-Reply-To: <8A4F97F4-723E-41C8-B4F6-C6D65F0BC848@mit.edu> Date: Wed, 25 Dec 2019 21:45:19 +0300 Message-ID: <008601d5bb53$75269480$5f73bd80$@elvis.ru> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0087_01D5BB6C.9A750500" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHdvvqKSyXWSys4i9wLZip4/JKSjgI7xNqsp6lKkCA= Content-Language: ru X-CrossPremisesHeadersFilteredBySendConnector: MAIL16.office.elvis.ru X-OrganizationHeadersPreserved: MAIL16.office.elvis.ru X-Spam-Scanner: Rspamd work in kmail2.elvis.ru, WHITELIST X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Status: not scanned, disabled by settings X-KLMS-AntiPhishing: Clean, bases: 2019/12/25 18:17:00 X-KLMS-AntiVirus: Kaspersky Security for Linux Mail Server, version 8.0.3.30, bases: 2019/12/25 14:37:00 #14886745 X-KLMS-AntiVirus-Status: Clean, skipped X-Spam-Scanner: Rspamd work in akmail.elvis.ru, WHITELIST Archived-At: Subject: Re: [IPsec] [secdir] Secdir last call review of draft-ietf-ipsecme-qr-ikev2-09 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, 25 Dec 2019 18:45:32 -0000 ------=_NextPart_000_0087_01D5BB6C.9A750500 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Uri, I don't mind referencing NIST levels, but I'd like to first hear = from my co-authors, who are definitely more experienced in cryptography and in NIST levels = than I am :-) =20 =20 NIST produces standards and recommendations. US government organizations = and companies doing business with them are usually required to comply. = Organizations and businesses (both US and non-US) that are not bound by = US regulations, often pay attention to what NIST recommends.=20 =20 To repeat myself, it mages sense to add reference to the NIST levels, = even if Watson doesn't insist. ;-) On Dec 25, 2019, at 12:29, Valery Smyslov wrote: =EF=BB=BF=20 On Wed, Dec 25, 2019 at 3:57 AM Uri Blumenthal < = uri@mit.edu> wrote: NIST standards are mandatory for a subset of US citizens. But enough of = businesses outside the US pay attention to what NIST says to make adding = the reference relevant and useful. =20 It's not about standards, it's about the competition and the relevant = security level definitions. Not that I feel strongly about it, just a = suggestion.. =20 Then I'm a bit confused. What competition do you mean?=20 =20 Regards, Valery. =20 =20 On Dec 25, 2019, at 01:52, Valery Smyslov wrote: =EF=BB=BF=20 Hi Watson, =20 thank you for spending your time on this review in Christmas Eve. =20 The capitalization issue has been already noticed and fixed. =20 I=E2=80=99m not sure the draft should mention NIST levels, because=20 they are relevant mostly for US customers. I think that=20 generic recommendations on key sizes are more appropriate for this document. =20 Regards, Valery. =20 Damn misclick. I meant With Nits. =20 On Tue, Dec 24, 2019 at 8:02 PM Watson Ladd via Datatracker = wrote: Reviewer: Watson Ladd Review result: Not Ready Twas the night before Christmas when all through the house someone was desperately trying to get a review done on time. I didn't see anything wrong per se in the draft itself, but I found the capitalization of quantum computer an odd choice. IKEv2 is a complicated protocol, and I am not 100% sure that this draft does what we want it = to: It would be great if someone could check very carefully in some symbolic = model, ala what has been done in TLS. The guidance on sizes seems to rule out = NIST level 1, but not any higher levels: might be worth calling out this = explicitly. _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --=20 "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --=20 "Man is born free, but everywhere he is in chains". --Rousseau.. ------=_NextPart_000_0087_01D5BB6C.9A750500 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Uri, I don't mind referencing NIST levels, but I'd like to first hear = from my co-authors,

who are definitely more experienced in cryptography and in NIST = levels than I am :-)

 

 

NIST produces standards = and recommendations. US government organizations and companies = doing business with them are usually required to comply. Organizations = and businesses (both US and non-US) that are not bound by US = regulations, often pay attention to what NIST = recommends. 

 

To = repeat myself, it mages sense to add reference to the NIST levels, even = if Watson doesn't insist. ;-)



On Dec 25, 2019, at 12:29, Valery Smyslov = <valery@smyslov.net> wrote:

=EF=BB=BF

On Wed, = Dec 25, 2019 at 3:57 AM Uri Blumenthal <uri@mit.edu> = wrote:

NIST standards are mandatory for a = subset of US citizens. But enough of businesses outside the US pay = attention to what NIST says to make adding the reference relevant and = useful.

 

It's not about standards, it's about the competition = and the relevant security level definitions. Not that I feel strongly = about it, just a suggestion..

 

          Then I'm a bit = confused. What competition do you mean?

 

          = Regards,

          = Valery.

 

 

=EF=BB=BF

Hi Watson,

 

thank you for spending your time on this review in Christmas = Eve.

 

The capitalization issue has been already noticed and = fixed.

 

I=E2=80=99m not sure the draft should mention NIST levels, because =

they are relevant mostly for US customers. I think that =

generic recommendations on key sizes are more = appropriate

for this document.

 

Regards,

Valery.

 

Damn = misclick. I meant With Nits.

 <= /o:p>

On Tue, Dec = 24, 2019 at 8:02 PM Watson Ladd via Datatracker <noreply@ietf.org> = wrote:

Reviewer: = Watson Ladd
Review result: Not Ready

Twas the night before = Christmas
when all through the house
someone was desperately = trying to get a review done on time.

I didn't see anything wrong = per se in the draft itself, but I found the
capitalization of quantum = computer an odd choice. IKEv2 is a complicated
protocol, and I am not = 100% sure that this draft does what we want it to: It
would be great = if someone could check very carefully in some symbolic model,
ala = what has been done in TLS. The guidance on sizes seems to rule out = NIST
level 1, but not any higher levels: might be worth calling out = this = explicitly.

_______________________________________________
sec= dir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wik= i: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview



--

_______________________________________________
secd= ir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wik= i: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview



--

------=_NextPart_000_0087_01D5BB6C.9A750500-- From nobody Thu Dec 26 09:58:12 2019 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 8ECC5120875; Thu, 26 Dec 2019 09:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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 wvZmMefd9vAC; Thu, 26 Dec 2019 09:58:03 -0800 (PST) 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 AE890120874; Thu, 26 Dec 2019 09:58:03 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 47kHjx5bJLzDJZ; Thu, 26 Dec 2019 18:57:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1577383077; bh=OxVekRl0JUVL+q4ZngfPRFsvm9HIBcbt7IkuCIKpels=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=taUljMVQbIH/7AD1aNNlfD1v9v+9NzaF6x05ABQKT85c1bXy747f3RYMCDOdgV8h9 PEp5xZQH3DXNE16JpuHiCh1fhInIWGLJgwINuS38YTV659slPzYCSpWBShNWWRKU1l MLHkJrM8INgj9OV+jt0aK+VTC1GdFzN6JK9bmmqA= 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 8ve1096K8jqt; Thu, 26 Dec 2019 18:57:56 +0100 (CET) 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, 26 Dec 2019 18:57:56 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 97B576007AD8; Thu, 26 Dec 2019 12:57:55 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 93B0D65E47; Thu, 26 Dec 2019 12:57:55 -0500 (EST) Date: Thu, 26 Dec 2019 12:57:55 -0500 (EST) From: Paul Wouters To: Valery Smyslov cc: "ipsec@ietf.org WG" , 'secdir' , draft-ietf-ipsecme-qr-ikev2.all@ietf.org, last-call@ietf.org In-Reply-To: <008601d5bb53$75269480$5f73bd80$@elvis.ru> Message-ID: References: <003901d5bb48$cfc21460$6f463d20$@smyslov.net> <8A4F97F4-723E-41C8-B4F6-C6D65F0BC848@mit.edu> <008601d5bb53$75269480$5f73bd80$@elvis.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] [Last-Call] [secdir] Secdir last call review of draft-ietf-ipsecme-qr-ikev2-09 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, 26 Dec 2019 17:58:06 -0000 On Wed, 25 Dec 2019, Valery Smyslov wrote: > Uri, I don't mind referencing NIST levels, but I'd like to first hear from my co-authors, > > who are definitely more experienced in cryptography and in NIST levels than I am :-) I don't think mentioning the NIST competition is useful. Per definition, that is incomplete preliminary data. Paul From nobody Thu Dec 26 10:02:11 2019 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 7177E1200BA for ; Thu, 26 Dec 2019 10:02:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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 bPopmrc2RZ0d for ; Thu, 26 Dec 2019 10:02:08 -0800 (PST) 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 AF4B8120091 for ; Thu, 26 Dec 2019 10:02:02 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 47kHpc5Ky3zDZQ; Thu, 26 Dec 2019 19:02:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1577383320; bh=cANJCKESXnDMIj6l6DMpzaVJ/zhXmsG/Unae4jXq/GY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=GWCtHNYl8JKhvdKMgIXW2kToxjkz4wXfI+EoviVyqscGs76KTJRr+XFuT+7Sn2Ci/ wFoAp21pz5E7uul4FOUewKwcD9RwoexGHEvzG2sMdSxJm8yywNxaFcuq4bG4mYxqWR vjU7YIZSOC6NlEmvtrpwirPXDvYuu5K56XkNITKo= 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 FXiF3cDpG0Vx; Thu, 26 Dec 2019 19:01:59 +0100 (CET) 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, 26 Dec 2019 19:01:59 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id D964A6007AD8; Thu, 26 Dec 2019 13:01:58 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D5CC865E47; Thu, 26 Dec 2019 13:01:58 -0500 (EST) Date: Thu, 26 Dec 2019 13:01:58 -0500 (EST) From: Paul Wouters To: Valery Smyslov cc: 'Tero Kivinen' , ipsec@ietf.org, 'Sahana Prasad' In-Reply-To: <032201d5bb30$7b70ec00$7252c400$@gmail.com> Message-ID: References: <01f501d5b0b2$facb4370$f061ca50$@gmail.com> <24050.43728.115813.170898@fireball.acr.fi> <046401d5b1c6$98ed09d0$cac71d70$@gmail.com> <24055.63797.695416.153493@fireball.acr.fi> <032201d5bb30$7b70ec00$7252c400$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Labeled IPsec options 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, 26 Dec 2019 18:02:10 -0000 On Wed, 25 Dec 2019, Valery Smyslov wrote: > Another approach - use some new status notification containing > seclabel that the initiator would include in any request to create > Child SA. This is easy to implement, but there is a possibility, > that unsupporting responder will just ignore this notification > and create SA w/o proposed seclabel. In this case the initiator > would need to immediately delete this SA. That is a big problem but not the only one. > My proposal only deals with this situation. If initiator and responder > exchange SECLABELS_SUPPORTED notifications at the time of > creating IKE SA (in IKE_SA_INIT), then the initiator will know, During IKE_SA_INIT you do not fully know which configuration you are talking to, as no ID's have been exchanged. If a server has some connections with and some without security labels, it cannot guarantee success despite the notification. And that is assuming the notification does not indicate "support" but indicates "supported and required" > Again, I'm fine with either using new Traffic Selectors or Notify > for this purpose. Both have pros and contras. I think the majority seems to be in favour of Traffic Selectors. While a combinatory explosion is a worry, we do not expect that many new types of traffic selectors, so it is unlikely to become a big problem I think. Paul From nobody Thu Dec 26 20:13:31 2019 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 502B712004E; Thu, 26 Dec 2019 20:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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=fmICZQ7a; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=rz8iZvX4 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 lgT5BsYRB7kO; Thu, 26 Dec 2019 20:13:28 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41D7812001E; Thu, 26 Dec 2019 20:13:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7297; q=dns/txt; s=iport; t=1577420008; x=1578629608; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6FX2rp36r9enI/zdOktm4/aGXrKhGM9lZnYiobw8OQo=; b=fmICZQ7aWA1ftwZDRntCWbZgvw9kOugYI6J+T21ZEaHgZVqeLBdHenSt Ff9nYK8hQyINromh4zljMWtxip2WA0cOG53VeEXX838rhi2dYIgSb4mlf Qv2U3ex87fk9dq70aDUuHpQm29mINAbbzrGoo/Kl7SAZba02z4o+9mTIJ 4=; X-Files: smime.p7s : 4024 IronPort-PHdr: =?us-ascii?q?9a23=3AvnUnOhHt9Ou/EocxSBDg0Z1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eebpZikiFcJLfFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuAACqgwVe/4MNJK1kHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWoFAQELAYFTUAVsKy0gBAsqh04DiniCX5gJgS6BJANUAgcBAQE?= =?us-ascii?q?JAwEBGAsKAgEBhEACgh8kNgcOAgMNAQEEAQEBAgEFBG2FNwyFXgEBAQECAQE?= =?us-ascii?q?BEAsjAQEsCwEEBwQCAQgRBAEBHhECJQsdCAIEAQ0FCAYUgwGBeU0DDhEPAQI?= =?us-ascii?q?Mn1wCgTiIYYIngn4BAQWEfxiCBQcDBoE2AYFSikYagUE/gRFHgh4uPoJkAQG?= =?us-ascii?q?BZRWDK4IslxmXfgqCNINhgjeGVolGmleOUppWAgQCBAUCDgEBBYFZAjCBWHA?= =?us-ascii?q?VO4JsUBgNjRI4gzuFFIU/dIEokiYBAQ?= X-IronPort-AV: E=Sophos;i="5.69,361,1571702400"; d="p7s'?scan'208";a="391285807" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Dec 2019 04:13:25 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id xBR4DPb8012752 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 27 Dec 2019 04:13:25 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 26 Dec 2019 22:13:24 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 26 Dec 2019 22:13:23 -0600 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.1473.3 via Frontend Transport; Thu, 26 Dec 2019 23:13:23 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iPLfbFYCFMY80Dfh7KTX/xbDpnOhQ+sAVPRQEYjjbUNv7SijSVmAeOFtEFSB4mZoSnTZDXtdwdVyNlcjkHclb10yq2bNOm5aHxcsJCthC5yVK9TcGblPACJqNH6azht3DLJ2t7O6Fdp5Wr9MWS6LFRCKKB50EUtsjilr94jGfq9ctKrUJVYf2lYGMPuFBLfsao5jT5KcyOyvdH4lQU5jU3tzTc0VFGx/KlERnmZcpQhRXIKiU0OhpFzhiwrXbMZScF20xbmnqjVcXk8B6CwQi4GbGVDu5oTlL335F3SAqwWiVIm1RICJN3bQLMgBKvoXJoW+pob+HVHIpex+8HsnSw== 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=lWR6Lfx8rnN3P01Q11KHEuu4VxOm+krUPqUioIlaFKc=; b=iKIoClP3bmiJijYsZGzokhC+m0EXbgfdoh9ief0kTK5u0MTY9G71q/QAVeA6r4JTvUotouCcCXpdyUN0VVF+VtNZ5y8oDQZcAgrLPrj7IAXwo65FacYToXmtFUxWneZLR4guLlaxFelkxliyGWOBlVclVIPg2p9hel+uFtryWVjVwfsyd07sGgjn3FqxDM0WEwYerDHd2H5yyXnQBFc0SGIk9+LGEBVmVnU3gTsx5VlRqw4Dr4i+bqLnDJBlO78bM/KBcSNBhxeaAKbda5DE8N9pfvOImh0Ht9BopK4kJwkSoWl34Nec62VsgPKOZcI99JrWkZ63m4rypxHi0CUz1Q== 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=lWR6Lfx8rnN3P01Q11KHEuu4VxOm+krUPqUioIlaFKc=; b=rz8iZvX4j2YJ3mUFNDr6qgNlPJdKS15TqdKlhbwffPgW/WsrBEJM+qVfh5uyfLuaQt7D3/zOW4N27JlgcNh3lsqtPc59Zp3i/TVVtZzy9ZHM3ujj6vYxMYcooaS16nCjDuv5PGAqOZKH3PAkkdtgulxJV/0rXBC+LyPHG101Y3g= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2563.namprd11.prod.outlook.com (52.135.244.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2581.11; Fri, 27 Dec 2019 04:13:23 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f%7]) with mapi id 15.20.2581.007; Fri, 27 Dec 2019 04:13:23 +0000 From: "Panos Kampanakis (pkampana)" To: Paul Wouters , Valery Smyslov CC: "ipsec@ietf.org WG" , "last-call@ietf.org" , "draft-ietf-ipsecme-qr-ikev2.all@ietf.org" , "'secdir'" Thread-Topic: [IPsec] [Last-Call] [secdir] Secdir last call review of draft-ietf-ipsecme-qr-ikev2-09 Thread-Index: AQHVvBYgaemvAijUV0anuRMjqrab/afNX7Lw Date: Fri, 27 Dec 2019 04:13:22 +0000 Message-ID: References: <003901d5bb48$cfc21460$6f463d20$@smyslov.net> <8A4F97F4-723E-41C8-B4F6-C6D65F0BC848@mit.edu> <008601d5bb53$75269480$5f73bd80$@elvis.ru> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1003::61] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 54f4d2da-3812-489a-09c7-08d78a831d32 x-ms-traffictypediagnostic: BN7PR11MB2563: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0264FEA5C3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(136003)(346002)(366004)(376002)(13464003)(189003)(199004)(86362001)(52536014)(4326008)(66616009)(66946007)(66476007)(66556008)(66446008)(64756008)(186003)(76116006)(2906002)(5660300002)(71200400001)(33656002)(316002)(81156014)(9686003)(81166006)(55016002)(54906003)(8676002)(8936002)(7696005)(478600001)(110136005)(53546011)(6506007)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2563; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: oRtAfOzVSJjzMxKXMNvvaBekBzUupkLCwkXNNJ3UYJ3OaZ08pWYTbvKOfTmP6xRUnePBDy6JIEWjZWw/SXkNXqxnuuhS6q6/BGyJd1JCs5jiRsQb4MrfWJPhGQ9YGfxooS5fvAClJLV5m3v0UTAIYYv828BXvCRPjWzWBWwB6xOvGMEHo11zwK6bg1K5hKPdhpPcRnGqn5Sz06Cxn3aX6HURhko0Jgh8forXufvT19MNMLQnmGL27bsd02/juz3GK6AZh5LXBNxQp9EA0xEb3oXVKVH2EH81QmdAINBPisETBkJGMyAwodyKbX7L0W5rkfOOo/whTE+A8RUjuTeY+S+tyOMTikmrcenou+xYGJiDuZXf0U+FdKODlH8i7E3cTEcM1eiiyj/SeQ9T0K87xj01qw4IvVOloSuJbJArO3rxczbkuKV9+4P//ec3Y+yBtZp7gra7sj+3haHx9gMbjt3l0okgY92AMlZFjVcUQGoSpYwz69xdjvO4CblEj9BjhI4hewAEO9p76Zotdv2puyNzSeIcUJfwVo3Ni+TxSyk= 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_0026_01D5BC42.103C7A40" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 54f4d2da-3812-489a-09c7-08d78a831d32 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Dec 2019 04:13:22.7873 (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: qfTBsDZer67e0xoS0Rp1eu04xcpM1m239WscX4H99KAwbdA4nUT+PmFG+C+sTwq3ItXYBjXnGkiydjAwifcdCg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2563 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.20, xch-aln-010.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [IPsec] [Last-Call] [secdir] Secdir last call review of draft-ietf-ipsecme-qr-ikev2-09 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, 27 Dec 2019 04:13:30 -0000 ------=_NextPart_000_0026_01D5BC42.103C7A40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To make sure we mention the NIST PQ Level categorization (that will not change as the NIST PQ Project progresses), I was thinking we could add something in the Sec Considerations section like [...] 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 defined in the NIST PQ Project Call For Proposals [NISTPQCFP]. -----Original Message----- From: IPsec On Behalf Of Paul Wouters Sent: Thursday, December 26, 2019 12:58 PM To: Valery Smyslov Cc: ipsec@ietf.org WG ; last-call@ietf.org; draft-ietf-ipsecme-qr-ikev2.all@ietf.org; 'secdir' Subject: Re: [IPsec] [Last-Call] [secdir] Secdir last call review of draft-ietf-ipsecme-qr-ikev2-09 On Wed, 25 Dec 2019, Valery Smyslov wrote: > Uri, I don't mind referencing NIST levels, but I'd like to first hear > from my co-authors, > > who are definitely more experienced in cryptography and in NIST levels > than I am :-) I don't think mentioning the NIST competition is useful. Per definition, that is incomplete preliminary data. Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0026_01D5BC42.103C7A40 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 DxcNMTkxMjI3MDQxMzIwWjAvBgkqhkiG9w0BCQQxIgQgJ9TmeFBRkrJayuKajW8iJaw0h5gA1Vf/ mmrVOEZNMn0wSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lz Y28gRW1wbG95ZWUgQ0ECCgGGESJBPOq6K1UwSwYLKoZIhvcNAQkQAgsxPKA6MCwxDjAMBgNVBAoT BUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTCBoAYJKoZIhvcN AQkPMYGSMIGPMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUD BAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDALBglghkgBZQMEAgEwCwYJKoZIhvcN AQEKMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEggEA SQM4uTpJn2c6HtBKopq47Zxs6pfvfHRELdoRjYcb75FcfA6Pq2QZbbJGatOAWrDE8BXBJjhCdLxZ 8MGdazYATcvDPpTZKjs1xIsTqGGLipYCj6f0hErHarNsJ8bmYIMI/SgtAhDckWMm9TPSoyClBREp AYr+b1eA7IL3NL/Ug7FNGPnEycYv6Cky8igI9QnQySbIFqlvOTmg3RnDr7wVrhfoYqxVdcynR25z CBREa3ICuEhXWHpSx5+Pp9K13+S27kDBUrkLuIaErDB20F4aahSthYO7QBa2Uf4RoJu1WP6m9EJc 6UD1TM/U0guGe66PPARrUrQoEeN/6TWg8cL7zQAAAAAAAA== ------=_NextPart_000_0026_01D5BC42.103C7A40-- From nobody Thu Dec 26 22:32:45 2019 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 DF6FC12002F; Thu, 26 Dec 2019 22:32:36 -0800 (PST) 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: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <157742835677.25224.11796589797546528418@ietfa.amsl.com> Date: Thu, 26 Dec 2019 22:32:36 -0800 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-qr-ikev2-10.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: Fri, 27 Dec 2019 06:32:37 -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 : Mixing Preshared Keys in IKEv2 for Post-quantum Resistance Authors : Scott Fluhrer David McGrew Panos Kampanakis Valery Smyslov Filename : draft-ietf-ipsecme-qr-ikev2-10.txt Pages : 19 Date : 2019-12-26 Abstract: The possibility of quantum computers poses a serious challenge to cryptographic algorithms deployed widely today. 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-qr-ikev2-10 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-qr-ikev2-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-qr-ikev2-10 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 Thu Dec 26 22:35:09 2019 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 DC7AD12004F for ; Thu, 26 Dec 2019 22:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 tZCoJmKVuncT for ; Thu, 26 Dec 2019 22:35:06 -0800 (PST) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 34BA412002F for ; Thu, 26 Dec 2019 22:35:06 -0800 (PST) Received: by mail-wm1-x330.google.com with SMTP id b19so7333316wmj.4 for ; Thu, 26 Dec 2019 22:35:06 -0800 (PST) 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=L4/sGT/B7KHbGxlZJWTY9+9ZM5tbgoCneRLv2gzUqV4=; b=Kiw4dwFNgZgjdZcT5j70jIdFAPZ+UyTPqL5Janp8GXx52ZIjnkYdjHbqbvJDe/+ehP O466cheMx20RhVXKC3QzxXRzDGzICKIwJ5FdzgsXPBOC78UjYhyz0MGvtNLFJStdy1pb GtSho7vGx9A4TKJ++NH66l2Cy5EaYm7KuFz50LooZcf9mpNVSNEqO9l4jiz75HgX4SU0 SggUbYa9SFgN8iDjeu5oNHeoN97iLLD6tLD4aWnR0h9Fj2lh6xYk94Vm5K0Q0p5jd1qc LQP0vVGPeiuXIuOKgxlot7BH7JkHNu45+7r1kg8XQsbt+ZVs4ZwfS0P9y9iSMaxHQA1q 8eJQ== 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=L4/sGT/B7KHbGxlZJWTY9+9ZM5tbgoCneRLv2gzUqV4=; b=j6ebiQdMZEeEdkHE7f9THCcqXQ/4KO+FV15wQ4AD8xEzpyh8hg4KEXrNHtTze7uKAw +Xy6/owXaFgA9kayzvXk96TiLxqZmq04qCTFRoGmCURKSvOpzYPBUnbc7zIz1DCTuwWJ v47ljIler4i7YkwXVa+L7uJooKP5JAWCmmH7RRXIchSHMg4DNhwz0XOGOpuIVVosbOlg S7vDi4J8Cac9Xg3uQBLmkYMF20coAylko6VrWSSo5xUSDkh4c4UjIBORm/+wVybMIwUA 9lvOALVeuKlnKCi7m/Fy2eJputvWqi8Hk2IzkpuOidEewUiJoBAFT114ZwVc+RZceVWK nLEg== X-Gm-Message-State: APjAAAUKbGe+vBezr7Hj7FwtMt7rAWiy7LUSmvfmRCY2mkxnimuCfoV1 bYdNIuvZJjydbYAdXZthsbZq/sCo X-Google-Smtp-Source: APXvYqxDhIJnCKwdl3YDxqezizu4WLOyLRuwWVio29RMTjsmsRby2SIWbksi3FQpFSRlCmHSOvuXlA== X-Received: by 2002:a7b:cd0a:: with SMTP id f10mr18227157wmj.56.1577428504392; Thu, 26 Dec 2019 22:35:04 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id f16sm33258333wrm.65.2019.12.26.22.35.03 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 26 Dec 2019 22:35:03 -0800 (PST) From: "Valery Smyslov" To: References: <157742835677.25224.11796589797546528418@ietfa.amsl.com> In-Reply-To: <157742835677.25224.11796589797546528418@ietfa.amsl.com> Date: Fri, 27 Dec 2019 09:35:07 +0300 Message-ID: <044e01d5bc7f$c882ee30$5988ca90$@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: AQJAF6UEbhud0MSapNeA3jioGmTrhKb4z/Hw Content-Language: ru Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-qr-ikev2-10.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: Fri, 27 Dec 2019 06:35:08 -0000 Hi, the -10 version of the draft addresses comments received during IETF LC and IANA review. 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 : Mixing Preshared Keys in IKEv2 for Post-quantum Resistance > Authors : Scott Fluhrer > David McGrew > Panos Kampanakis > Valery Smyslov > Filename : draft-ietf-ipsecme-qr-ikev2-10.txt > Pages : 19 > Date : 2019-12-26 > > Abstract: > The possibility of quantum computers poses a serious challenge to > cryptographic algorithms deployed widely today. 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. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ipsecme-qr-ikev2-10 > https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-qr-ikev2-10 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-qr-ikev2-10 > > > 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 Thu Dec 26 23:06:28 2019 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 BC41B12004F for ; Thu, 26 Dec 2019 23:06:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 6NG9FZyRF2Ye for ; Thu, 26 Dec 2019 23:06:25 -0800 (PST) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 26B9C120025 for ; Thu, 26 Dec 2019 23:06:25 -0800 (PST) Received: by mail-wr1-x435.google.com with SMTP id c14so25300977wrn.7 for ; Thu, 26 Dec 2019 23:06:25 -0800 (PST) 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=rIcmVRe1Q8hrGP3iYK8eDw6wQMan9A5hUK+U7VKqRjw=; b=fjpPwnE9b5ih+nuRYOj9CWhh/PBhBd2vsGV2aLeMg0+H9IcxjsO069FP8WxohDunR8 GXIK4v1CT5ewllrJQQ8YT01RHgDkJYYKn+brjEmCSOnQdmECW5C5kHvsEwLrFBNdgkS3 J0GoUcMGJLbw1K/byd4s0c6Skn/E29w539DROrSwLfpNcwWLb3pW/1Ucgkr5YqaXYvpY Hmp0qtEa3H5BW3atWqMN4QCSrKbJxqPKsGAGif1lNwtH9JJW/pUxSLVTzDfd2qcQ0x7r 217ki9VSueXlJ1cbhKCeY4UN4ahTEdH9CzjUzmnGBtBrcYh64+idPE0FhPQayAZn7Dmb Pkiw== 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=rIcmVRe1Q8hrGP3iYK8eDw6wQMan9A5hUK+U7VKqRjw=; b=oLaNyBIE14LhNyh/clELDXVU4Q2McCAwe9k1rXLHi04RlXvfmd7BdXSENEDzXtQPz5 K/Ely58axy1AFAzoY6IUaCwoGjvyqP3VIHLVldyxOD8xvQwut64p3XZbkh5jZWZf3jXX ZqfTDTTmV20bC9PLg+k4XwSIrfSx0EwXVkVH0FNUhAABwxNy3ngget8DDfl3LZE/HUPS IMbtjhaa4lf/iiUvP/5Z8mMm88QJPxNduR++NyEodfm/aJlcO29V4T5a5qaqllBYLGpn 3DeQh0BfTG0cwvJGQ7b8V4M0BJqWZ0sDXzUtuN+5WW4sHOKSDn3rk8lYGWsOb83drCC/ veZw== X-Gm-Message-State: APjAAAVCaqkeerBbQuXeRTyrG7nfw4oucpFct24/Vw2CrBLW1zBwy9l7 KzapkjuAaX7RAINWD2RSHgisEEYW X-Google-Smtp-Source: APXvYqyM/6SMoahVKROUzfG4yMxPbOWDhr+e0fU65clLVZRFuURH7BObxSjuiueodfKC+UUGlDkYXg== X-Received: by 2002:a5d:484f:: with SMTP id n15mr24274565wrs.365.1577430383163; Thu, 26 Dec 2019 23:06:23 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id f127sm10221881wma.4.2019.12.26.23.06.21 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 26 Dec 2019 23:06:22 -0800 (PST) From: "Valery Smyslov" To: "'Paul Wouters'" Cc: "'Tero Kivinen'" , , "'Sahana Prasad'" References: <01f501d5b0b2$facb4370$f061ca50$@gmail.com> <24050.43728.115813.170898@fireball.acr.fi> <046401d5b1c6$98ed09d0$cac71d70$@gmail.com> <24055.63797.695416.153493@fireball.acr.fi> <032201d5bb30$7b70ec00$7252c400$@gmail.com> In-Reply-To: Date: Fri, 27 Dec 2019 10:06:26 +0300 Message-ID: <044f01d5bc84$284b8300$78e28900$@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: AQLx+ZsZ28gCWkLjxf5xPWFraxjS5AGiqmCDANTXOjwB/YUU0gIxTZDgAjZptVYCZJBXO6U6/Rmg Content-Language: ru Archived-At: Subject: Re: [IPsec] Labeled IPsec options 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, 27 Dec 2019 07:06:27 -0000 Hi Paul, > > Another approach - use some new status notification containing > > seclabel that the initiator would include in any request to create > > Child SA. This is easy to implement, but there is a possibility, > > that unsupporting responder will just ignore this notification > > and create SA w/o proposed seclabel. In this case the initiator > > would need to immediately delete this SA. > > That is a big problem but not the only one. > > > My proposal only deals with this situation. If initiator and responder > > exchange SECLABELS_SUPPORTED notifications at the time of > > creating IKE SA (in IKE_SA_INIT), then the initiator will know, > > During IKE_SA_INIT you do not fully know which configuration you are > talking to, as no ID's have been exchanged. If a server has some > connections with and some without security labels, it cannot guarantee > success despite the notification. And that is assuming the notification > does not indicate "support" but indicates "supported and required" The successful exchange of SECLABELS_SUPPORTED notification only ensures that the responder won't ignore SECLABEL notification in requests to create IPsec SAs. In this case, if for any reason the server cannot create IPsec Sa with proposed security label (that is provided in SECLABEL notification), the server would return TS_UNACCEPTABLE (or NO_PROPOSAL_CHOSEN). So, SECLABELS_SUPPORTED doesn't say that every IPsec SA created with this IKE SA will have security labels, it only guarantees that notifications containing security labels won't be silently ignored. > > Again, I'm fine with either using new Traffic Selectors or Notify > > for this purpose. Both have pros and contras. > > I think the majority seems to be in favour of Traffic Selectors. While > a combinatory explosion is a worry, we do not expect that many new types > of traffic selectors, so it is unlikely to become a big problem I think. OK, I think it's a right way to go. In fact I suggested it back in May 2018 :-) Regards, Valery. > Paul From nobody Fri Dec 27 14:07:57 2019 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 9814D12013B for ; Fri, 27 Dec 2019 14:07:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.201 X-Spam-Level: X-Spam-Status: No, score=0.201 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.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 u0XXnV-HAanY for ; Fri, 27 Dec 2019 14:07:54 -0800 (PST) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 922841200DB for ; Fri, 27 Dec 2019 14:07:54 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.116.115.142]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id xBRM7aR4009231 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Dec 2019 14:07:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1577484469; x=1577570869; i=@elandsys.com; bh=VOT73fryMu2+kFcsd3cz324C8529zcXokeIzP8ec/JQ=; h=Date:To:From:Subject:In-Reply-To:References; b=Bmw7SRWaCDGVf1X/9IbZQiCrHldJc3yrlMLGMV4toPOBju8qZMC4Cx1jLoeXtukfR zlEFLaIk3Ew53pVRlQE5bx30vWdaMf39EVFLWe/nG4ihvncO+X87ReJeS0LxjrsDAq WAaxYldddftEOVu03Z3bjPUT8Na51O2QDCF2cd5k= Message-Id: <6.2.5.6.2.20191227134423.11d65a80@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 27 Dec 2019 13:54:32 -0800 To: "R. Atkinson" , ipsec@ietf.org From: S Moonesamy In-Reply-To: References: <02c101d5baef$de2cdd90$9a8698b0$@elvis.ru> <70FA58C0-97E1-4F76-B88B-A28101A46069@mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [IPsec] [Last-Call] [secdir] Secdir last call review of draft-ietf-ipsecme-qr-ikev2-09 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, 27 Dec 2019 22:07:55 -0000 Hi Ran, At 11:16 AM 26-12-2019, R. Atkinson wrote: >In my experience, many countries other than the US also reference >and use/follow many NIST specifications and many NIST recommendations/guidance. Which countries, other than the U.S., reference many NIST specifications? Regards, S. Moonesamy From nobody Mon Dec 30 12:25:58 2019 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 D186D120B5E for ; Mon, 30 Dec 2019 12:25:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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 5CPUTbjw6KUt for ; Mon, 30 Dec 2019 12:25:55 -0800 (PST) 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 082E112006B for ; Mon, 30 Dec 2019 12:25:54 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 47mppk6L7NzF1j; Mon, 30 Dec 2019 21:25:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1577737550; bh=KFkjUHoTXmolhG568pUJSyo4QAmathuTiJUNnBOn4w0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=uWNCAKz6Vu1Ul/OYEnMnOrzDIv+frfhRbi1HA1xIGw8+Lthmry7o46qEI4nHWj5B+ 4l86JHOv7/nJcjz14B3lKfl90s7dVIEWZhwks8sk3YPLCO8UMHiBTaL03CC8eyzAk2 586UsnfIT/+/ivZekqhFfjElm+JAP9o5Ong9xvdk= 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 m-TJvHPeywyt; Mon, 30 Dec 2019 21:25:49 +0100 (CET) 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, 30 Dec 2019 21:25:49 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 365526001421; Mon, 30 Dec 2019 15:25:48 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 32D7A65E47; Mon, 30 Dec 2019 15:25:48 -0500 (EST) Date: Mon, 30 Dec 2019 15:25:48 -0500 (EST) From: Paul Wouters To: Valery Smyslov cc: ipsec@ietf.org, 'Sahana Prasad' , 'Tero Kivinen' In-Reply-To: <044f01d5bc84$284b8300$78e28900$@gmail.com> Message-ID: References: <01f501d5b0b2$facb4370$f061ca50$@gmail.com> <24050.43728.115813.170898@fireball.acr.fi> <046401d5b1c6$98ed09d0$cac71d70$@gmail.com> <24055.63797.695416.153493@fireball.acr.fi> <032201d5bb30$7b70ec00$7252c400$@gmail.com> <044f01d5bc84$284b8300$78e28900$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Labeled IPsec options 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, 30 Dec 2019 20:25:57 -0000 On Fri, 27 Dec 2019, Valery Smyslov wrote: > The successful exchange of SECLABELS_SUPPORTED notification only > ensures that the responder won't ignore SECLABEL notification > in requests to create IPsec SAs. Over the hollidays, I tried to show weaknesses in this approach, but failed. I think Valery is right. Although, I'm not sure yet what an initiator requiring labels would do if the responder replied without the notify. Should it delete/retry the exchange, or start an IKE_AUTH with some kind of (new?) notify error ? Or should it go ahead regardless as to not leak to the network that this IPsec SA uses labels, and wait for the remote end to return an inevitable TS_UNACCEPTABLE? On the responder, I'll assume that it will continue in general with the IKE_SA_INIT reply even if it is missing the notify and it has some connections configured to use labels. Since it does not know for sure in all situation if its IKE_SA_INIT reply generated is for the proper connection (if it has multiple connections configured). So here too, after the responder receives Traffic Selectors of the non-label kind, it will return TS_UNACCEPTABLE. > OK, I think it's a right way to go. In fact I suggested it back in May 2018 :-) I paid in time for my reluctance to be convinced by you and Tero at that time :) Paul From nobody Mon Dec 30 18:41:20 2019 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 C3A1512008F for ; Mon, 30 Dec 2019 18:41:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 WO6d4RTVJApr for ; Mon, 30 Dec 2019 18:41:16 -0800 (PST) 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 A5E0712002E for ; Mon, 30 Dec 2019 18:41:16 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 47mz7t2LpQzF3H; Tue, 31 Dec 2019 03:41:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1577760074; bh=9XOze+nYwklEpurFsj/Hc+h2gQsxA/MeMYySrXUt834=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=XAJorYBBSADYUuzBau7y/Zn1SbR3HvWRWYZc0/fxgS+z9I3VXT1Mp8AQ4KHK5o5VA bxgu+W1NPmEtLrixnC9eayCv6w8mqZCWsNnv7h2A65CBIdgrAzVl4hA497L8ofczs5 UJZgPQd7OTOGH038Rg6Dfq41Nuh/8TFmJIaP1PB8= 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 zYjjo-yJfwQc; Tue, 31 Dec 2019 03:41:12 +0100 (CET) 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; Tue, 31 Dec 2019 03:41:12 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id A3DE06001421; Mon, 30 Dec 2019 21:41:11 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A012A66AA8; Mon, 30 Dec 2019 21:41:11 -0500 (EST) Date: Mon, 30 Dec 2019 21:41:11 -0500 (EST) From: Paul Wouters To: Benjamin Kaduk cc: Sean Turner , IPsec List In-Reply-To: <20191223184651.GC35479@kduck.mit.edu> Message-ID: References: <20191223184651.GC35479@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] graveyard: deprecate->historic 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, 31 Dec 2019 02:41:19 -0000 On Mon, 23 Dec 2019, Benjamin Kaduk wrote: > "this document" (i.e., the RFC-to-be) does not actually effecuate the move > to Historic status; the separate "status-change" document does so. Looking > at a recent example in RFC 8429, we see this phrased akin to "Accordingly, > IKEv1 has been moved to Historic status" with no claim of doing so because > of the current document. Changed, see https://tools.ietf.org/rfcdiff?url2=draft-pwouters-ikev1-ipsec-graveyard-04.txt Paul >> requests IANA to close all IKEv1 registries. >> >> 2: Change section title >> >> s/Deprecating IKEv1/RFC 2409 to Historic > > This is probably okay to keep (I see Paul took the changes already), but > the first sentence is still "IKEv1 is deprecated", which is sending mixed > signals. Is it a mixed signal? I've left the sentence in for now, but I'm fine if we decide to remove it. I can always do that after adoption when I need to re-submit the draft under the new name anyway. Paul