From nobody Sun May 3 05:37:41 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6B63A09DF for ; Sun, 3 May 2020 05:37:38 -0700 (PDT) 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, 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 u8eA9zKTGVwD for ; Sun, 3 May 2020 05:37:36 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 16C573A09CB for ; Sun, 3 May 2020 05:37:36 -0700 (PDT) Received: from tops.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 75C2F610DF; Sun, 3 May 2020 12:37:35 +0000 (UTC) User-agent: mu4e 1.4.3; emacs 26.3 From: Christian Hopps To: ipsec@ietf.org Cc: chopps@chopps.org Date: Sun, 03 May 2020 08:37:34 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: [IPsec] IPTFS and transport mode. 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, 03 May 2020 12:37:38 -0000 --=-=-= Content-Type: text/plain; format=flowed Hi ipsecme, An open issue we have for IPTFS is the use of transport mode. During the last face-to-face IETF meeting transport mode was mentioned, and my response had been that transport mode was less secure than non-TFS tunnel mode as the IP header was leaking user information so it hadn't been a consideration for us; however, it was later pointed out (by Paul W. I believe), that transport mode is (unfortunately?) commonly used with GRE tunnels in lieu of IPsec tunnel mode so we probably still needed to handle this case. Key to TFS is sending data even when there is none from the user and also changing the rate at which we send the user data. This means that we need to be able to generate empty packets, and we need to be able to consolidate user data packets. This is the primary hurdle in handling transport mode, it means that we must cache information from the user connection in order to generate empty packets, and we must also be able to aggregate user data packet headers. For the common case of GRE/tunnel (which is the main justification for use of transport mode IMO), the GRE header information should be stable, and relatively easy to cache/consolidate for regeneration/aggregation. Handling only this case is relatively easy, We should be able to use the last received header information to generate new headers for empty packets, likewise aggregating headers should also work as each IP header should be the same. This simpler solution requires specification of what IP header fields are expected to be the same packet to packet. It means that certain things in the user IP header should not be present as well, like IP fragmentation/reassembly data, or per packet varying IP options/extension headers. IP fragmentation: - For the GRE/tunnel case we could mandate that the GRE tunnel packets need to arrive at IPsec un-fragmented. - For a more generic transport case IP fragmentation in the unencrypted header is a leak of user information so we would need to hide it (starts seeming like a tunnel again) IP options/IPv6 extension headers: - These would need to remain stable, or leaving them off or repeating them would need to be OK. - For the the GRE/tunnel case this hopefully would be straight-forward - Unsure on how to specify this for more generic case. We believe that there's enough complexity in the handling and specification of TFS for transport mode that we should address this mode in a separate draft. This will allow us to get the less complex TFS tunnel mode specified while we continue to work on the various aspects of how best to handle TFS transport mode. We would be happy to work with other interested folks to write this TFS transport mode draft. Thanks, Chris. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAl6uuw4ACgkQLh2DDte4 MCWGHw//SfbWzNKDAXRctIP4D/O0wcMGFBrFcSAclV3HAaKeHQEzX7/eF4jNNKSf 7wgZSup8H+6+ergr7iw1Egd842lr3/tlhtAfH6BXhvMkCXMgRm6Uv8FEvmXPOzWI G6m9A8Vsh8L70reaFlIAgzrhE2UxxxBUxNtIyfCYTye8wnLWMCsIC8RbKl6QubxT Q6y2yb/RKJ5rZ/rAQow83Ls8TECm92L4YJW0xV6BYIEekFJoyWuhjzg2cJspMYfT q+HIE8RQZostbTwCnRNQQQHxQyznpUEMVEoNPJ0nO7fZ57OLJPpDhZQRXVVyI4n7 Rf6h7PbqfOOpLaOzT2Te3gTLXEPCBhV+Ej8LrQQZias+vAjSqR9WIR3yRxTm++zL kNeVc+ny3vam+MyjQ0jzG/Txp+egbe2wqe5DjRBpoUsBuIBxXMT/xXbWGghMDau3 tVueabHi/WlZGh/+UvMAuDrlFHOlnVCW8iDRSLheoojotlymGUF3hll8am2SEN94 7DKWvyP6RRnC/3mYP2+7I9AvCfAH/dNXFtUVkDwVFRlYoqTQqWRu5h8XI9DM7A+f zkxtUhB0GnF5uAWD/K3NhUpHlXivJYWyzUgDtVe+nsG6I00HqnfmxCB2N0S8Z/Y3 ZIkB5nTqOL/BNntAKkxKhz5AJcLSy1e+jZ1OydIjn533TrDAI6Q= =TVaX -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun May 3 10:08:20 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38EDA3A1068 for ; Sun, 3 May 2020 10:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wn1vvjgLDKOi for ; Sun, 3 May 2020 10:08:18 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 022F43A105A for ; Sun, 3 May 2020 10:08:17 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B50DF3897B; Sun, 3 May 2020 13:06:19 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 71460201; Sun, 3 May 2020 13:08:16 -0400 (EDT) From: Michael Richardson To: Christian Hopps cc: ipsec@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] IPTFS and transport mode. 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, 03 May 2020 17:08:20 -0000 --=-=-= Content-Type: text/plain Christian Hopps wrote: > non-TFS tunnel mode as the IP header was leaking user information so it > hadn't been a consideration for us; however, it was later pointed out > (by Paul W. I believe), that transport mode is (unfortunately?) > commonly used with GRE tunnels in lieu of IPsec tunnel mode so we > probably still needed to handle this case. If there will be changes to the GRE/IPsec mode, then maybe BEET mode could be considered rather than transport mode. BEET mode looks like transport mode on the wire, but is treated virtually like tunnel mode. This is essentially what you describe: > For the common case of GRE/tunnel (which is the main justification for > use of transport mode IMO), the GRE header information should be > stable, and relatively easy to cache/consolidate for > regeneration/aggregation. Handling only this case is relatively easy, > We should be able to use the last received header information to > generate new headers for empty packets, likewise aggregating headers > should also work as each IP header should be the same. You have described essentially BEET mode :-) It is described in RFC7402. > We believe that there's enough complexity in the handling and > specification of TFS for transport mode that we should address this > mode in a separate draft. This will allow us to get the less complex > TFS tunnel mode specified while we continue to work on the various > aspects of how best to handle TFS transport mode. I am not convinced that you really want to handle the generic transport mode case. I think that you want to handle the GRE case specifically. I'm unclear if your above description is a hack to make GRE/tunnel fit into your current situation, or if you are describing a new situation that would handle in a new draft. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl6u+oAACgkQgItw+93Q 3WV74wf+JzrSa9iCrCqDqCk43h6cN9XIvwQu6iV9EKOij0+vIBxiwXG63GUD09sv ZZKz3LxKFoFqqrtn1tZzSg9OqVmcZoft/ZP1l+b4QG4VLHIpmLLJjWdmkOUH7AXy MNnjJ3pmPVbSOZ1ExZYNgZ0QVNQErMB7uzQOAbuk83LjPiHBR2P6BViNKaV6Xjmc JnuOll153kbMtYOIQgX1GItDtHdeVjYDsv7+AbQEDmaPDmeog3fmmhMTKYY/RGxx +f8/XJefqx4q6pcO48vmRQtn4MxwEwlXAqjCBpE3mt/G84Y2Jctt4twOTIllmXKz ol1unLXxgn7YDw/6kifCWTemxZuNXg== =YdD3 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun May 3 14:39:27 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 304573A0A7D for ; Sun, 3 May 2020 14:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3snrwQIOTdB for ; Sun, 3 May 2020 14:39:23 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 10D1E3A0A73 for ; Sun, 3 May 2020 14:39:22 -0700 (PDT) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 62533610CF; Sun, 3 May 2020 21:39:22 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Christian Hopps In-Reply-To: <7081.1588525696@localhost> Date: Sun, 3 May 2020 17:39:21 -0400 Cc: Christian Hopps , ipsec@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <91FC4B2D-4190-45A5-B681-705365658999@chopps.org> References: <7081.1588525696@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [IPsec] IPTFS and transport mode. 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, 03 May 2020 21:39:25 -0000 > On May 3, 2020, at 1:08 PM, Michael Richardson = wrote: >=20 >=20 > Christian Hopps wrote: >> non-TFS tunnel mode as the IP header was leaking user information so = it >> hadn't been a consideration for us; however, it was later pointed out >> (by Paul W. I believe), that transport mode is (unfortunately?) >> commonly used with GRE tunnels in lieu of IPsec tunnel mode so we >> probably still needed to handle this case. >=20 > If there will be changes to the GRE/IPsec mode, then maybe BEET mode = could be > considered rather than transport mode. BEET mode looks like transport = mode > on the wire, but is treated virtually like tunnel mode. This is = essentially > what you describe: >=20 >> For the common case of GRE/tunnel (which is the main justification = for >> use of transport mode IMO), the GRE header information should be >> stable, and relatively easy to cache/consolidate for >> regeneration/aggregation. Handling only this case is relatively easy, >> We should be able to use the last received header information to >> generate new headers for empty packets, likewise aggregating headers >> should also work as each IP header should be the same. >=20 > You have described essentially BEET mode :-) > It is described in RFC7402. >=20 >> We believe that there's enough complexity in the handling and >> specification of TFS for transport mode that we should address this >> mode in a separate draft. This will allow us to get the less complex >> TFS tunnel mode specified while we continue to work on the various >> aspects of how best to handle TFS transport mode. >=20 > I am not convinced that you really want to handle the generic = transport mode > case. I think that you want to handle the GRE case specifically. > I'm unclear if your above description is a hack to make GRE/tunnel fit = into > your current situation, or if you are describing a new situation that = would > handle in a new draft. The primary thing I'm suggesting here is that we define TFS transport = mode in a separate draft. Whether we support generic transport or only a subset of transport = configurations (e.g., tunnels) or both, the reasons we make whatever = choices we make, and the mechanisms for how to implement TFS with = whatever is chosen, is what this new draft would cover. I see this = building on top of the TFS tunnel mode draft. The rest of what I put above was really just ideas for what would go in = that new draft. My thinking that if we wanted to support a subset of = transport mode configurations (e.g., for use with GRE, SRv6, IP-IP, etc) = we could specify that by defining a set of restrictions on the user IP = headers. I'm not sure if that's what you mean is a hack or not, but I = figured if we define it by the restrictions rather than specifically = only for GRE it's more broadly useful for little extra cost. In any case = the discussion of this and definition is what I think would go well in = the context of it's own draft. Thanks, Chris. > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Sun May 3 15:49:27 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9DBB3A08FA; Sun, 3 May 2020 15:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4E1IMmlLEk4G; Sun, 3 May 2020 15:49:24 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80D003A0877; Sun, 3 May 2020 15:49:24 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 043MnFkx006276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 3 May 2020 18:49:17 -0400 Date: Sun, 3 May 2020 15:49:14 -0700 From: Benjamin Kaduk To: Yoav Nir Cc: Valery Smyslov , ipsec@ietf.org, ipsecme-chairs@ietf.org, Tommy Pauly Message-ID: <20200503224914.GG27494@kduck.mit.edu> References: <0b5201d61d43$0f16dfe0$2d449fa0$@gmail.com> <53F12987-8F6B-46B7-831C-A4185E2B3805@apple.com> <007d01d61e3c$c43a8990$4caf9cb0$@gmail.com> <69538081-E679-4BE4-A818-6AD424ECBCF0@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <69538081-E679-4BE4-A818-6AD424ECBCF0@gmail.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [IPsec] Clarifications and Implementation Guidelines for using TCP Encapsulation in IKEv2 draft 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, 03 May 2020 22:49:26 -0000 On Wed, Apr 29, 2020 at 10:54:26PM +0300, Yoav Nir wrote: > [With chair hat on] > > Yes, the charter says that we are to make a guidance document. If the working group feels that it’s better to put the specification and guidance in a single document, we can work on that and clear it with the ADs. > > Charters can be modified. FWIW I don't see a particular need to recharter to do an 8229bis. -Ben From nobody Sun May 3 16:55:15 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98473A0972 for ; Sun, 3 May 2020 16:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3qiC8gdsqCy for ; Sun, 3 May 2020 16:55:13 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4852D3A0970 for ; Sun, 3 May 2020 16:55:13 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 49FjXZ68ZZzFX9; Mon, 4 May 2020 01:55:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1588550110; bh=JbUx3DbZzsTfWZH0bqHL9w1ziYqluejFIwy6YQKZJtk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=FJz0KrMOq34/X3KfmATe/vuOd//oafb6YEOTouO7aRVtmY24yhKsN279+2TOumiKC j4ScpaExJNE8L4XJu+jCX6Z1BwHwgUhFXTT3PWY+OVtOBDvmgQG/WOfgAcQroUtuqo 9pbEEqaJvlGw5PpmeCfLUI3M0znWJ+TX06d/SkDQ= 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 9aehil8YkddV; Mon, 4 May 2020 01:55:09 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 4 May 2020 01:55:09 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 94DE3601EBCB; Sun, 3 May 2020 19:55:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 9129B23F8D7; Sun, 3 May 2020 19:55:08 -0400 (EDT) Date: Sun, 3 May 2020 19:55:08 -0400 (EDT) From: Paul Wouters To: Christian Hopps cc: ipsec@ietf.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [IPsec] IPTFS and transport mode. 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, 03 May 2020 23:55:15 -0000 On Sun, 3 May 2020, Christian Hopps wrote: > An open issue we have for IPTFS is the use of transport mode. > > During the last face-to-face IETF meeting transport mode was mentioned, and > my response had been that transport mode was less secure than non-TFS tunnel > mode as the IP header was leaking user information so it hadn't been a > consideration for us; however, it was later pointed out (by Paul W. I > believe), that transport mode is (unfortunately?) commonly used with GRE > tunnels in lieu of IPsec tunnel mode so we probably still needed to handle > this case. That is one use case of an IPsec connection across the internet using transport mode. There are other uses of transport mode, such as nodes within a LAN/WAN, but I don't think these really gain much from TFS. You can't really have all your data center nodes generate fake traffic between them. If if these cross data centers, there is another gateway to gateway IPsec connection in place as the outer layer, using tunnel mode (or transport mode with GRE) > We believe that there's enough complexity in the handling and specification > of TFS for transport mode that we should address this mode in a separate > draft. This will allow us to get the less complex TFS tunnel mode specified > while we continue to work on the various aspects of how best to handle TFS > transport mode. That's fine with me, provided that we think that we the current TFS for tunnel mode would not need modification later to support transport mode, and that we are mostly looking to specify restrictions on specific packets and options in the transmode mode draft. > We would be happy to work with other interested folks to write this TFS > transport mode draft. I think that is valid. Also, anyone who would _really_ want TFS can also turn their transmode mode IPsec into tunnel mode IPsec. Paul From nobody Sun May 3 23:07:15 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 560943A0CC1; Sun, 3 May 2020 23:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNABALB2V8OX; Sun, 3 May 2020 23:07:12 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 DB2053A0CC6; Sun, 3 May 2020 23:07:11 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id a4so2229080lfh.12; Sun, 03 May 2020 23:07:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=DuCOoseqObS1NydzROhjVIIe5TJBKws9kvWB/eQQ7/8=; b=uradxrLryUpuIM1Q/H8Q/x4XJKbbBZTDJSxgZvSi7nQCVIM6XKT20CXfTm9NpDBwiE yEw3w2B5Sz9zeiiIuR3hBhFLHqP4pu+F4aD7JdoKGep4ab+wwE7AdfhPawxggNJcdFjR /8nYrrkQa1ZM06o/tCQVWCV1A+5H0kCEP6Qf15+sfmmKeU6siYlgEowOxGSDglJ2qdFS N7Vdr4qklDcGj5eCnF2AfFPNeCkyfH6lTyr8mQMYlhu8EW/YYvzq/E+6ghhmMvERM53L s6NyYcgLy/HQ+KaZuqalh8q0Q1/6XhrEtvMVlCuN9hJ05aP+I82cOnLh0Xz886u/iSdf haYg== 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:content-language :thread-index; bh=DuCOoseqObS1NydzROhjVIIe5TJBKws9kvWB/eQQ7/8=; b=fUtx/7oAyHbZYDbc1WcIqKWLqZOUURA4rXIjVbfqYT05rHNBjWhq6P0NNhB3acRc3C 2EEp/OsdvWwzs76mVPzxj7MTWu9f7ctJRic8mBc3q8RpzPNxsRQ6um5j0btpsnsNAGfi Eq4augnBe4p9Fm8Cyq2qAo77wWN2783il0gT04ECTrsQ9Egi2O87hfkB60XFbUY1XBQJ cKzNlkjMroNlHHqyeCbo2sT7EKXqAiHBJlIL4snlX9W/fHjfrm2rm/i4r2AbpvBFx4ZO 3B2Cl6nvTCsYfHvEowWB8a5gcXMRYmod5Y93oVanMdbJk9hZNVdqrzlIvIwulGWXQkTf 9PAw== X-Gm-Message-State: AGi0PuYOcXrU10gyS8yVI62YAEbh7dWeoLn3vnMFtDRvkenmyUxOHMaW bItJKNetCQKtXPftFti5Vta5zFKl X-Google-Smtp-Source: APiQypLOVYuVCmM0+wnKOqpbtvSl1a4ZEznu64/PjcelGHbE2ok/avKrMDjmjuF9MNes9BoyYsTc4A== X-Received: by 2002:a05:6512:10cd:: with SMTP id k13mr10574852lfg.173.1588572429735; Sun, 03 May 2020 23:07:09 -0700 (PDT) Received: from chichi (95-27-147-103.broadband.corbina.ru. [95.27.147.103]) by smtp.gmail.com with ESMTPSA id t19sm8664242lfl.53.2020.05.03.23.07.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 03 May 2020 23:07:09 -0700 (PDT) From: "Valery Smyslov" To: "'Benjamin Kaduk'" , "'Yoav Nir'" Cc: , , "'Tommy Pauly'" References: <0b5201d61d43$0f16dfe0$2d449fa0$@gmail.com> <53F12987-8F6B-46B7-831C-A4185E2B3805@apple.com> <007d01d61e3c$c43a8990$4caf9cb0$@gmail.com> <69538081-E679-4BE4-A818-6AD424ECBCF0@gmail.com> <20200503224914.GG27494@kduck.mit.edu> In-Reply-To: <20200503224914.GG27494@kduck.mit.edu> Date: Mon, 4 May 2020 09:07:08 +0300 Message-ID: <004a01d621da$3ebab960$bc302c20$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: ru Thread-Index: AQJ4LbZ9m5c/82foCko2jbr+bIGR0wF6ZQFdAY3dosQB4F+1GwJreDRJpxi2PWA= Archived-At: Subject: Re: [IPsec] Clarifications and Implementation Guidelines for using TCP Encapsulation in IKEv2 draft 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, 04 May 2020 06:07:13 -0000 Hi Ben, > On Wed, Apr 29, 2020 at 10:54:26PM +0300, Yoav Nir wrote: > > [With chair hat on] > > > > Yes, the charter says that we are to make a guidance document. If = the > working group feels that it=E2=80=99s better to put the specification = and guidance in a > single document, we can work on that and clear it with the ADs. > > > > Charters can be modified. >=20 > FWIW I don't see a particular need to recharter to do an 8229bis. Can you please clarify for those of us who (like me) are not native = speakers: do you think that the current charter allows to do an 8229bis without = need to recharter or do you think there is no need to do an 8229bis and thus no need to = recharter? Thank you, Valery. > -Ben From nobody Mon May 4 08:17:28 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 127E83A0A23 for ; Mon, 4 May 2020 08:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqFCch_sw8o7 for ; Mon, 4 May 2020 08:17:23 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 496DA3A0A22 for ; Mon, 4 May 2020 08:17:20 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0FA663897B; Mon, 4 May 2020 11:15:21 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8C6228B6; Mon, 4 May 2020 11:17:18 -0400 (EDT) From: Michael Richardson To: Christian Hopps cc: ipsec@ietf.org In-Reply-To: <91FC4B2D-4190-45A5-B681-705365658999@chopps.org> References: <7081.1588525696@localhost> <91FC4B2D-4190-45A5-B681-705365658999@chopps.org> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] IPTFS and transport mode. 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, 04 May 2020 15:17:26 -0000 --=-=-= Content-Type: text/plain Christian Hopps wrote: > Whether we support generic transport or only a subset of transport > configurations (e.g., tunnels) or both, the reasons we make whatever > choices we make, and the mechanisms for how to implement TFS with > whatever is chosen, is what this new draft would cover. I see this > building on top of the TFS tunnel mode draft. > The rest of what I put above was really just ideas for what would go in > that new draft. My thinking that if we wanted to support a subset of > transport mode configurations (e.g., for use with GRE, SRv6, IP-IP, > etc) we could specify that by defining a set of restrictions on the > user IP headers. I'm not sure if that's what you mean is a hack or not, > but I figured if we define it by the restrictions rather than > specifically only for GRE it's more broadly useful for little extra > cost. In any case the discussion of this and definition is what I think > would go well in the context of it's own draft. I understand you, and I agree with your idea. I agree with putting it into a different draft, but we might need to clearly articulate where the extension point is in this draft. I will have to re-read the document, since it's been awhile since I read it. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl6wMf4ACgkQgItw+93Q 3WU5LggAninIIQ1pGezKyUig/FKI6UpfaKei+/QUqr8L4vo3UlEwqLw8O+tceNy8 tiOr/JCmRYEIBUSZ0dptGTmQYEByoBHhfAwjKQoEAC6pXxChdkFO7fl2ot7xt/Fv fmQeGAw1qxMrTvqDoQBjRvUQw20zLhST489cTNWvgAPYj1eBQLpT17AhEe9oYxZ4 LuHQO7QTWc3PXx2ONhaK5uB+lCCOFmLQVEufYRD0BrHJvffIvIJW740Mb7eSGbCw k4XngmMPgCvaGd+qrE5h0oRK7qbwCQXqedY898MRfH+IQ4NQ0nqmsLvmT1KnpCu0 x60gKjqiPkGXTzYpFZWBb+LYENy+HQ== =aHsK -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed May 6 06:42:24 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB893A07F8 for ; Wed, 6 May 2020 06:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8_b6Rdios-U for ; Wed, 6 May 2020 06:42:13 -0700 (PDT) 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 B724E3A0ABB for ; Wed, 6 May 2020 06:42:11 -0700 (PDT) Received: from kmail2.elvis.ru ([93.188.44.210]) by akmail.elvis.ru with esmtp (Exim 4.89) (envelope-from ) id 1jWKJM-0000Pr-P9 for ipsec@ietf.org; Wed, 06 May 2020 16:42:08 +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 1jWKJM-0006eQ-B6 for ipsec@ietf.org; Wed, 06 May 2020 16:42:08 +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, 6 May 2020 16:42:08 +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, 6 May 2020 16:42:08 +0300 From: Valery Smyslov To: IPsecME WG References: <158877219792.32315.17792974305291155977@ietfa.amsl.com> In-Reply-To: <158877219792.32315.17792974305291155977@ietfa.amsl.com> Date: Wed, 6 May 2020 16:42:11 +0300 Message-ID: <030201d623ac$24b3ab70$6e1b0250$@elvis.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ6pIE+fZ0cGV5siaEuPO7ai8p3mKdSDlhQ 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: 2020/02/16 23:24:00 X-KLMS-AntiVirus: Kaspersky Security for Linux Mail Server, version 8.0.3.30, bases: 2020/02/16 18:54:00 #14771046 X-KLMS-AntiVirus-Status: Clean, skipped X-Spam-Scanner: Rspamd work in akmail.elvis.ru, WHITELIST Archived-At: Subject: [IPsec] FW: New Version Notification for draft-smyslov-ipsecme-rfc8229bis-00.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: Wed, 06 May 2020 13:42:22 -0000 Hi, following the suggestions from Tom and Paul I've prepared a 8229bis draft. It incorporates all the clarifications from ipsecme-tcp-guidelines draft. Comments are very welcome. Regards, Valery. -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Wednesday, May 06, 2020 4:37 PM To: Valery Smyslov Subject: New Version Notification for draft-smyslov-ipsecme-rfc8229bis-00.txt A new version of I-D, draft-smyslov-ipsecme-rfc8229bis-00.txt has been successfully submitted by Valery Smyslov and posted to the IETF repository. Name: draft-smyslov-ipsecme-rfc8229bis Revision: 00 Title: TCP Encapsulation of IKE and IPsec Packets Document date: 2020-05-06 Group: Individual Submission Pages: 30 URL: https://www.ietf.org/internet-drafts/draft-smyslov-ipsecme-rfc8229bis-00.txt Status: https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-rfc8229bis/ Htmlized: https://tools.ietf.org/html/draft-smyslov-ipsecme-rfc8229bis-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-smyslov-ipsecme-rfc8229bis Abstract: This document describes a method to transport Internet Key Exchange Protocol (IKE) and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as "TCP encapsulation", involves sending both IKE packets for Security Association establishment and Encapsulating Security Payload (ESP) packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP. TCP encapsulation for IKE and IPsec was defined in [RFC8229]. This document updates specification for TCP encapsulation by including additional calarifications obtained during implementation and deployment of this method. This documents makes RFC8229 obsolete. 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. The IETF Secretariat From nobody Thu May 7 00:52:27 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4D63A0A00 for ; Thu, 7 May 2020 00:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSKec0QzRSjr for ; Thu, 7 May 2020 00:52:16 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C54443A09FC for ; Thu, 7 May 2020 00:52:15 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id y4so5244566ljn.7 for ; Thu, 07 May 2020 00:52:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=rpMkRL0ESMvaKm7kQo+ZnbbgaXvV1RaOn3DSQTxlcac=; b=qI94A7Rmz1WRdJxpIHDHLXy3rYFAY56aGThu30jsFGV6sIMm6/UI8TBXrOChoVovx8 VQra1y7BfmwV7utKoVD4E5Ynby3vUqtEt1+U1y7oFWTJsW2tLYk+GIpPBQc4D54ybNz8 l+u+yvZ9q/DOvjkw8p0ytPqynqtpmYYS8LAwaO6ihHjUXqyNT7n97aZKv4aCBp/agLwl aEOtUwrPEYzmqHwRC1WGGCJ6cC/IWPCXK03YT5YjeZp5OagL50Nk+o73PzWzaTx5Yaxh COKcQ2XWXBRqK08Hb1icmxUZekjBD1gxuu/0/FzHgaUpplmh9lj1Glatf3zJVuy+5UbC M+kw== 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=rpMkRL0ESMvaKm7kQo+ZnbbgaXvV1RaOn3DSQTxlcac=; b=jQTRVa7Aahw43mE1wOCp/fEYPoXCXVFBZZWBpnKGctIIlz6Y4xCkYYeul2cTTar+oZ 5VhZz66eEdSHFyvk3e2eWm7SQfMBIsuqg2i11HUZLRFGj+YPr9jaqVtiJ8pi8VP0bUEs GT93KlpoGV+feB2e+yWc2+shhgBbD2F5aCbW9o0UMoWvSimWuDwW8t06e5Yo84LEC8h6 Bw3dnWhLiZbwNmikuzE7EP7WG4kzdFI+B+CI4VqBjeJNCDu207OcMc3g2PmydYZKjRxu V+x/JPyUERc1OpUqT9EyXGSZjLl9TuA9qE6osrT/L12MpQ10GnxoYupXsWL2k5vpA859 Y43A== X-Gm-Message-State: AGi0PuYliUR2h3Su1ECk9gukU+Qz2zLddmNuHsdamJeG0YaSENclgtko E6qYk9FXQloaszXusLicmap8mQak X-Google-Smtp-Source: APiQypKeEhZknk1gdDJUXGff1YYwtxzZ+fws/TPrmNPmCNZwKb+OdJ4RE79Aza3WV7NDsqV1MWxorg== X-Received: by 2002:a2e:8145:: with SMTP id t5mr7624683ljg.291.1588837933793; Thu, 07 May 2020 00:52:13 -0700 (PDT) Received: from svannotebook (95-27-147-103.broadband.corbina.ru. [95.27.147.103]) by smtp.gmail.com with ESMTPSA id t16sm2819574ljo.6.2020.05.07.00.52.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 May 2020 00:52:13 -0700 (PDT) From: "Valery Smyslov" To: "'Christian Hopps'" , "'Michael Richardson'" Cc: References: <7081.1588525696@localhost> <91FC4B2D-4190-45A5-B681-705365658999@chopps.org> In-Reply-To: <91FC4B2D-4190-45A5-B681-705365658999@chopps.org> Date: Thu, 7 May 2020 10:52:10 +0300 Message-ID: <034d01d62444$6ad86170$40892450$@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: AQHywP8qoLzIJEnE+QtlITIQ3cvGSAJcErS1Ad0IA6eoQTsxgA== Content-Language: ru Archived-At: Subject: Re: [IPsec] IPTFS and transport mode. 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, 07 May 2020 07:52:18 -0000 Hi, > > Christian Hopps wrote: > The primary thing I'm suggesting here is that we define TFS transport mode in > a separate draft. I agree that transport mode should be described in a separate draft provided that a tunnel mode draft will allow easy adding of transport mode. > Whether we support generic transport or only a subset of transport > configurations (e.g., tunnels) or both, the reasons we make whatever choices > we make, and the mechanisms for how to implement TFS with whatever is > chosen, is what this new draft would cover. I see this building on top of the TFS > tunnel mode draft. I think a generic transport mode should be supported. Any specific configuration (like GRE+transport) regardless of how widely it is used today, may become extinct tomorrow. Regards, Valery. > The rest of what I put above was really just ideas for what would go in that > new draft. My thinking that if we wanted to support a subset of transport > mode configurations (e.g., for use with GRE, SRv6, IP-IP, etc) we could specify > that by defining a set of restrictions on the user IP headers. I'm not sure if > that's what you mean is a hack or not, but I figured if we define it by the > restrictions rather than specifically only for GRE it's more broadly useful for > little extra cost. In any case the discussion of this and definition is what I think > would go well in the context of it's own draft. > > Thanks, > Chris. From nobody Thu May 7 16:12:07 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A65563A0D8D for ; Thu, 7 May 2020 16:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JpxW3vJ4qy5 for ; Thu, 7 May 2020 16:11:47 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F3D83A0E2B for ; Thu, 7 May 2020 16:11:31 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 49J8NK1RZHzF78 for ; Fri, 8 May 2020 01:11:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1588893089; bh=Y/HEi5Oimw/zr07P5KZaf6gmDvVUXMVJv7tljuCqL4c=; h=Date:From:To:Subject; b=BWqNSHHhFs92yQJiJ5LQHWccQHlJbL2GWadcFq/HyE3Uas/6fI9JtUVtwYuLX5vRZ PW7n8vIE+j49mkR+MGDGgK4UIL32Lueg7yRxkWQH6MYHi78UkmSfpZlGsWsiEcs4HR ZyrcipWxLukYxprMU++1hbQuaYlkmNRf+Qa/0Kmk= 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 Iq3eAGhb9Sgt for ; Fri, 8 May 2020 01:11:27 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Fri, 8 May 2020 01:11:26 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 0322C6029B99; Thu, 7 May 2020 19:11:25 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id F3B7966B7C for ; Thu, 7 May 2020 19:11:25 -0400 (EDT) Date: Thu, 7 May 2020 19:11:25 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [IPsec] Matching of IKE ID on certificate subject and RDN ordering 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, 07 May 2020 23:12:04 -0000 Recently I had an interesting issue come up. I needed to generate a certificate with a specific OU= content that our openssl/python code couldn't do, and I switched to nss's cert-util to generate a cert of sets for a test. Then I noticed something strange. Let's say you have the following DN specified for certificate generation: C=CZ, ST=Moravia, L=Brno, O=Test Example, OU="Global, Support, Services", CN=server For openssl, when checking the subject of the cert, it matches in this order. but when I generated the same certificate with nss cert-util and re-read it back in openssl, it showed me: CN=server, OU="Global, Support, Services", O=Test Example, L=Brno, ST=Moravia, C=CZ Note that C= and CN= are swapped. These are differences in the binary data, not the presentation. When reading https://tools.ietf.org/html/rfc5280#section-7.1 we see: Two distinguished names DN1 and DN2 match if they have the same number of RDNs, for each RDN in DN1 there is a matching RDN in DN2, and the matching RDNs appear in the same order in both DNs. So technically, when we expect one, receiving the other order would be wrong. So should we really do matching based on the same order of RDNs. What do other implementations do? Now, I guess I can weasel myself out of here, by claiming that we are not comparing two certificates. We just get one via CERT payload and validate it, and _then_ compare its DN against our IKE ID (which is a DN, sorta kinda). So perhaps I can say the IKE ID can take RDN's in any order. As we are dealing with (private) CA's, we can probably be ensured it would not create two certs that only differ in RDN ordering. Interested in hearing what others think, Paul From nobody Fri May 8 01:05:47 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C476B3A0886 for ; Fri, 8 May 2020 01:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hsr.ch 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 GjwPU-IR__k7 for ; Fri, 8 May 2020 01:05:42 -0700 (PDT) Received: from mx2.hsr.ch (mx2.hsr.ch [152.96.36.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B50093A04BB for ; Fri, 8 May 2020 01:05:42 -0700 (PDT) X-Virus-Scanned: by SpamTitan at hsr.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hsr.ch; s=hsr1119; t=1588925140; bh=AhSUcP0+CtnQ0i3IlFaic9HUb3TGDqBHfJU5DN70e8Q=; h=Subject:To:References:From:Date:In-Reply-To; b=TThBZ7mwH+XsPUzmttBFVMIDl9I+Ykai5oWcBExHeZx0WTjSFK8y8jI7V40wZRXg2 /v1mBvCng4+YsnTbDd3f1IQ7dGbxFlgjZohLEnDxkzoclEaDhOhNI3EnPLNzIdkmne BOiLz8EcwxvvxYlu7KViX5U70+RT2pOLWcXw39cBm8xfG45Zn6O45I8mZZvzppLJOU gaFj+W3whCt6xFMGSPFvXujIvIPEBjt+h6ldJDw/4ZrZRXLqpTFPpURXH3SYHgn1HL +5LkcjP+/kZXSaIAm3mOK/UlD+t74wv9ek1JZqnkInNn20T1bclXFxRqu3cIaCv37w 8RjHxosmXm+tA== Authentication-Results: mx2.hsr.ch; none Received: from [192.168.2.100] (152.96.21.56) by sid00233.hsr.ch (152.96.21.236) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 8 May 2020 10:05:34 +0200 To: Paul Wouters , "ipsec@ietf.org WG" References: From: Tobias Brunner Message-ID: <70c23d31-3cc8-f1f5-f361-a6b8bdab90b8@hsr.ch> Date: Fri, 8 May 2020 10:05:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [152.96.21.56] X-ClientProxiedBy: sid00234.hsr.ch (152.96.21.234) To sid00233.hsr.ch (152.96.21.236) Archived-At: Subject: Re: [IPsec] Matching of IKE ID on certificate subject and RDN ordering 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, 08 May 2020 08:05:45 -0000 Hi Paul, > For openssl, when checking the subject of the cert, it matches in this > order. but when I generated the same certificate with nss cert-util > and re-read it back in openssl, it showed me: > > CN=server, OU="Global, Support, Services", O=Test Example, L=Brno, ST=Moravia, C=CZ > > Note that C= and CN= are swapped. These are differences in the binary data, not the presentation. That's because, according to the documentation and examples, NSS certutil follows RFC 1485 when it comes to string representations of DNs, which states: The name is presented/input in a little-endian order (most significant component last). The latest RFC that replaced it, RFC 4514, states it this way, which is a bit clearer: Otherwise, the output consists of the string encodings of each RelativeDistinguishedName in the RDNSequence ..., starting with the last element of the sequence and moving backwards toward the first. Why the last RDN first? Could be to see the CN immediately, which usually identifies the actual entity. What you see in OpenSSL is the physical representation in the ASN.1 encoding of the certificate, i.e. the RDNs in their actual order in the RDNSequence. We follow the same principle in strongSwan when logging and parsing DNs. > So technically, when we expect one, receiving the other order would be > wrong. So should we really do matching based on the same order of RDNs. > What do other implementations do? In strongSwan we have an option (charon.rdn_matching) that allows changing how DNs in certificates are matched against configured IKE identities. It defaults to 'strict', which results in what RFC 5280 describes, i.e. all RDNs have to match in the same order (wildcards to ignore the values of RDNs are always allowed). With 'reordered', all RDNs have to be there, but their order doesn't matter. Finally, with 'relaxed', the certificate's DN may additionally contain RNDs that are not configured, which are then treated like wildcards. For example, with 'relaxed' you could configure CN=server which would be the same as configuring C=*, ST=*, L=*, O=*, OU=*, CN=server which matched both certificates with 'relaxed' and 'reordered' but only one with 'strict'. Using 'reordered' and 'relaxed' causes some overhead (memory and runtime) so 'strict' continues to be the default. Regards, Tobias From nobody Fri May 8 17:02:46 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8723A011F; Fri, 8 May 2020 17:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDzDzaMfQiif; Fri, 8 May 2020 17:00:24 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA0313A0406; Fri, 8 May 2020 17:00:23 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 04900CDT022893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 8 May 2020 20:00:14 -0400 Date: Fri, 8 May 2020 17:00:12 -0700 From: Benjamin Kaduk To: Valery Smyslov Cc: "'Yoav Nir'" , ipsec@ietf.org, ipsecme-chairs@ietf.org, "'Tommy Pauly'" Message-ID: <20200509000012.GX27494@kduck.mit.edu> References: <0b5201d61d43$0f16dfe0$2d449fa0$@gmail.com> <53F12987-8F6B-46B7-831C-A4185E2B3805@apple.com> <007d01d61e3c$c43a8990$4caf9cb0$@gmail.com> <69538081-E679-4BE4-A818-6AD424ECBCF0@gmail.com> <20200503224914.GG27494@kduck.mit.edu> <004a01d621da$3ebab960$bc302c20$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <004a01d621da$3ebab960$bc302c20$@gmail.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [IPsec] Clarifications and Implementation Guidelines for using TCP Encapsulation in IKEv2 draft 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, 09 May 2020 00:00:48 -0000 On Mon, May 04, 2020 at 09:07:08AM +0300, Valery Smyslov wrote: > Hi Ben, > > > On Wed, Apr 29, 2020 at 10:54:26PM +0300, Yoav Nir wrote: > > > [With chair hat on] > > > > > > Yes, the charter says that we are to make a guidance document. If the > > working group feels that it’s better to put the specification and guidance in a > > single document, we can work on that and clear it with the ADs. > > > > > > Charters can be modified. > > > > FWIW I don't see a particular need to recharter to do an 8229bis. > > Can you please clarify for those of us who (like me) are not native speakers: > do you think that the current charter allows to do an 8229bis without need to recharter > or do you think there is no need to do an 8229bis and thus no need to recharter? Sorry! I think that the current charter allows us to do an 8229bis without additional rechartering. -Ben From nobody Sun May 10 04:20:21 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8F63A08EA; Sun, 10 May 2020 04:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8snn3kD8ubyB; Sun, 10 May 2020 04:20:13 -0700 (PDT) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [212.16.98.55]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA4C73A08EC; Sun, 10 May 2020 04:20:11 -0700 (PDT) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 753A21B0042E; Sun, 10 May 2020 14:20:08 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1589109608; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=iaiIt2AN20MeRntY/iP9NZRGEmDEDkQRreKiK/vEkOk=; b=IdJ0SHZqDwrPEunw8/oizKG4IrZPT/Gc9biehu5tnQ94zgUHTZIdqeZEgsiWtB8cxh1Pf+ EiDAY4Dvy2badfxV8jiFcGU3yoQJErDzpr9oeysZzH9m54/TejYT7v2VfaLdmZFNyBumYQ GOQ6wVz97frrLDx3HPlVj7uL34xhXFhklH0Xz1c9KAvBihOe/T/SeCls+poLe8yjCNllW0 OmdNzU6Do1JQWNvKQFm8fCc285H6APw+EdhB77N44dnjIclBoBp/XynfsOJrkw+K5oX4N6 nKTmoyd0e6RVwbGfUsk6A4hchA9Ruly1mUFF1VLrgtlBSbMyEH4EFHY/f5NFzA== Received: by fireball.acr.fi (Postfix, from userid 15204) id 7655B25C15C5; Sun, 10 May 2020 14:20:07 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24247.58215.388734.625949@fireball.acr.fi> Date: Sun, 10 May 2020 14:20:07 +0300 From: Tero Kivinen To: Benjamin Kaduk Cc: Valery Smyslov , ipsec@ietf.org, ipsecme-chairs@ietf.org, 'Tommy Pauly' , 'Yoav Nir' In-Reply-To: <20200509000012.GX27494@kduck.mit.edu> References: <0b5201d61d43$0f16dfe0$2d449fa0$@gmail.com> <53F12987-8F6B-46B7-831C-A4185E2B3805@apple.com> <007d01d61e3c$c43a8990$4caf9cb0$@gmail.com> <69538081-E679-4BE4-A818-6AD424ECBCF0@gmail.com> <20200503224914.GG27494@kduck.mit.edu> <004a01d621da$3ebab960$bc302c20$@gmail.com> <20200509000012.GX27494@kduck.mit.edu> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 13 min X-Total-Time: 20 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1589109608; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=iaiIt2AN20MeRntY/iP9NZRGEmDEDkQRreKiK/vEkOk=; b=IDXlROzLTGH+rOBd+wS6+9OHaupjQzKIUeTaPbWMr8RZm1aaz/e7atC5/HBmxsOrcROQHu 40FdpiOdIiHcEE+Ur/7uifhZ2fbtH72TR2JE39BpM40mBQEjFPzneLrPeaG8dXWpNujmAZ qkVEJgIPoLXoPYuixyoxxupCylnaHn5XVJHbniFzxNWwQwraDFyk390dcZFcPbdB2S8Qdz PhvhPBatETbEbbF8kKPk5bFU93L/EkyrcyNOqao9Ignk0UHO1MtTz3bPUFDD4IvXcP39Cy 6uJ1e8MrhVfschjbAFKMaBQaaxVk1F/JlX7gYh6lMgp7u3zcMVQoWgH4pFC+IA== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1589109608; a=rsa-sha256; cv=none; b=ZZQ8Ii/H+ByrEdAH/e6UMU9KAEqhZpCXqTjRJgYqmosI+PuPEtn+Ymeu3IwIymhZdOjCkv dHL4O9eW4psRNQjk7AUff06QdSR4D8lcP5MmAo+/lqHXVjD6ijdfqMJEWik/Mthk+CmOiy NGceeZlsvfDxkQ1ShPVvOK8VAJw0X/vK4Jt+wol9qR3qaeqDCKkWdwHVPR+yqwvIxin3Wc /NCRdtNdGWK5WAa10Y12nVt1Ww8AsFloL5ib3wEqDJeJ9DzvXWr+xl03JfBdZxjY1ghntD Vq+P00ad235Ph5hoAUXObOUvdyokVnFy/9JE1M0WY5+iKDts+JKBxqwhSIMC3A== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: Re: [IPsec] Clarifications and Implementation Guidelines for using TCP Encapsulation in IKEv2 draft 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, 10 May 2020 11:20:19 -0000 Benjamin Kaduk writes: > Sorry! I think that the current charter allows us to do an 8229bis > without additional rechartering. Good. I myself think it is better to do bis documents than just clarification guidelines as splitting things to multiple documents do make things harder to implement. Also I think that currently everything in the draft is really a clarification to the original document, i.e. something that the original document should have already said more clearly, and in some cases there are new rules to be added to the processing of the packets. There are no real implementation guidelines in the current draft, i.e., something that would say something like "when doing xxx, it is often good idea to do yyy also", or "to implement zzz, algorithm like aaa is good, but others can also be used". I.e., cases where there are multiple ways of doing same thing, and any of them can be used, but some of them has been found to be better than others. Because of this I think it would be quite natural to start making the bis document instead of clarification document if authors are willing to work on such draft too... -- kivinen@iki.fi From nobody Sun May 10 05:03:00 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4882B3A091A for ; Sun, 10 May 2020 05:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gf6l-Jx9wKoq for ; Sun, 10 May 2020 05:02:51 -0700 (PDT) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [IPv6:2a00:1c30:1c1::55]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B961A3A0917 for ; Sun, 10 May 2020 05:02:49 -0700 (PDT) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id F3F501B000A0; Sun, 10 May 2020 15:02:45 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1589112166; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XcQym6hylxIBcy8hpfdqTClrRa8aCFazmQnwqmGDlZY=; b=humcZYkB74WZ3z+8hs94JgfntebDWttvRXJvrk8Avts7naZOdCF2Z0DFKIaTOR+Rk34zAg BPeRngvM66HuXlTRCLlNvaqKVQ2rVlgZnaVtBNQKEZ3caa0AgCIZM1QU1IWDdKAbSTu7id 0Y2NsyQH4tz5vfcBZkopHeknoiKw4nUaNbq1/Td+w6AJFgArvKING/XjPeYThSRPZodgPq NczLy4oCQ8ambZ1IMwDrSaSKeWvLJ8gYOmATLrCWcT/wBRDRN/f2hXKfCaeS0Lat+PBX8s r9i88vWcrg8N+vFZpsb5iyFl6Qsy3TF5U5rWqw0zMIAvPLnyB+x5q9acApc7BA== Received: by fireball.acr.fi (Postfix, from userid 15204) id D7A4525C15D7; Sun, 10 May 2020 15:02:44 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24247.60772.749384.75052@fireball.acr.fi> Date: Sun, 10 May 2020 15:02:44 +0300 From: Tero Kivinen To: Paul Wouters Cc: "ipsec\@ietf.org WG" In-Reply-To: References: X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 27 min X-Total-Time: 33 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1589112166; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XcQym6hylxIBcy8hpfdqTClrRa8aCFazmQnwqmGDlZY=; b=FTOnmyUhCx2MG9YFAwV8dpXNDXk51KKxIXLqGYaFX05zVOZnRioujnJX8xuFJpdf347puS kpN+G0udGqLeF1F0YOvO10dY+sez3RNPWaXVqGWg0wW+WzZHAke6iJx74PtPsKBs6QVSPD mbHn9CK/0uuAMc7KZ4TZ9fIF/SXG7GW47h6PHbNYQ22gq7wn0ZWhYj+ugLkrx9RzGB3ddf ry1vPLk37YehZ1LWARvabI79i74QZ5l77Yc5y7SINNOPsYj994gyEVWrAd5Uh8TSMueEId 7VYxcGDXe2x7whqj+rzYja0NoqQXCe8R4stHCNpBZKwju9UD8vrn09ANs6X6SQ== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1589112166; a=rsa-sha256; cv=none; b=Ho3hDS4XGeK1CY06H8thh9kaESAn/Dd2SOAc+3gc545ROKfEhYf7vIrsFbbW2X4lp0I23u ULmabZdn4ltrQCFkXHrKHFeWvdq7/dfqbFteKk6zIneGpDkmDvCufJhv9n+2zOSIBgM+uZ dScfH6riOMPd9b5SqtoT4oCba8TqnQdcrcDSsPvDJuVeoyQTuX5xy9WrYm9EmB8PAZkuUD Bzr/0datFrMgYrlrLE4stboVbuQz2r+NL/Ktv9YFQZp4ZMu2L5w3462yFpopPs8GAg2d4e dkQW4lB2iZBjJVus+XzkbMHvTBxsnVoDQE3/Efz0MukSG465+yz1pp8BuqbWCw== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: [IPsec] Matching of IKE ID on certificate subject and RDN ordering 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, 10 May 2020 12:02:56 -0000 Paul Wouters writes: > > Recently I had an interesting issue come up. I needed to generate a > certificate with a specific OU= content that our openssl/python > code couldn't do, and I switched to nss's cert-util to generate > a cert of sets for a test. > > Then I noticed something strange. Let's say you have the following > DN specified for certificate generation: > > C=CZ, ST=Moravia, L=Brno, O=Test Example, OU="Global, Support, Services", CN=server > > For openssl, when checking the subject of the cert, it matches in this > order. but when I generated the same certificate with nss cert-util > and re-read it back in openssl, it showed me: > > CN=server, OU="Global, Support, Services", O=Test Example, L=Brno, ST=Moravia, C=CZ > > Note that C= and CN= are swapped. These are differences in the binary data, not the presentation. Most likely another assumes bitwise DN order, and other used LDAP DN order. Another is most significant part first, another is least significant part first. I.e., I assume you made certificate incorrectly when you switched to new tool, as you assumed it takes DN in same order than openssl tools took it. Most of the tools just take the DN you give to them and do not look at the order of C, ST, L, etc parts, but just encode the sequence in the order you gave them in. But some tools assume you give the DN in LDAP order which is reversed order from what you have in the actual binary DER, so they reverse the list before doing this encoding. >From RFC4514: ---------------------------------------------------------------------- 2.1. Converting the RDNSequence If the RDNSequence is an empty sequence, the result is the empty or zero-length string. Otherwise, the output consists of the string encodings of each RelativeDistinguishedName in the RDNSequence (according to Section 2.2), starting with the last element of the sequence and moving backwards toward the first. ---------------------------------------------------------------------- If you look at the https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/tools/NSS_Tools_certutil page you notice that examples do have DN in reverse order, i.e. CN first etc, while openssl takes them in other order. So it clearly assumes you give the DN in ldap order, not in the most significant part first order. BTW, If I remember right the reason for LDAP to use the least significant part first order was that it allowed searching the database using partial searches like "CN=kivinen" without the need to fill in the OU, O, C etc parts and search could then simply assume default values for those omitted parts. Or something like that. > When reading https://tools.ietf.org/html/rfc5280#section-7.1 we see: > > Two distinguished names DN1 and DN2 match if they > have the same number of RDNs, for each RDN in DN1 there is a matching > RDN in DN2, and the matching RDNs appear in the same order in both > DNs. > > > So technically, when we expect one, receiving the other order would be > wrong. So should we really do matching based on the same order of RDNs. > What do other implementations do? You MUST match them in order. If the order is wrong then the DNs do not match. Note, that there can be multiple OU fields in the same certificate and the order of those must be preserved, and also those are reversed depending on the string format used, so you cannot just take the attributes and sort them in some order, you must know which order is supposed to be used and use that. I.e., if you have C=FI, O=example Corp, OU=Development, OU=Support, CN=server and C=FI, O=example Corp, OU=Support, OU=Development, CN=server then they are two different sub devisions inside the same organization, and you must be able to limit developments version control server so that only support people of the development division can access it and the global support devision do not have any access to it.... Same goes with other things for example for DC attributes. And when you reverse those for least significant part first order, you do reverse the order of OU fields too. > Now, I guess I can weasel myself out of here, by claiming that we are > not comparing two certificates. We just get one via CERT payload and > validate it, and _then_ compare its DN against our IKE ID (which is a > DN, sorta kinda). So perhaps I can say the IKE ID can take RDN's in > any order. As we are dealing with (private) CA's, we can probably be > ensured it would not create two certs that only differ in RDN ordering. It is better to properly make the certificates so that the most significant part of the DN is first in sequence (i.e., C first inside ASN.1 sequence) and make sure you give then DN in the order that will result in that to the tool you are using. If you ever use any string representation for the DN you must clarify in your documentation which format you use, i.e., whether you use most significant part first, or least siginifanct part first. And when you encode and print them you always consistently do the encoding and printing in same order. And do matching using binary representation in the order they are in the DER sequence. -- kivinen@iki.fi From nobody Fri May 15 11:18:11 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CB13A0B12 for ; Fri, 15 May 2020 11:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 iyHwXxNK8pJD for ; Fri, 15 May 2020 11:18:08 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 B661D3A0B09 for ; Fri, 15 May 2020 11:18:07 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id 188so2592104lfa.10 for ; Fri, 15 May 2020 11:18:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=7mTgUi8evJ/mN65tNKT/RxCZhpsNUwB2qWE5f/VkSEw=; b=A+jR9xRtuGQaYXcP8YrX9ipb+vNi3X4FYEG4IwjrbhF5syAh5cBh6q+FPOtkuqZmlQ 5pKkYFzRyEvoeGncjxFo7CChQO73NxgyTqycwJ3qmuo1GGCG3HDYZDQmSPM57EvTVCLd uHkhE5T4RD+/yPmOE5sMkHh0U5l5E5GOT+IXvoA5dxxXMyCKdFgnvGdWCpGtF2nxC67e zMsdibLVcCJrsgxJoGf7QF6XWu+1pucdWdj3uF/Apr9Xl/oKt6eyMRwXCtHRhZAjEDK4 Uyxde6Q75OsOy2YEsvwwW2rinSidQOn36+cox5UUgDLijcBif2V3TnbO1z1u1iet9jnI AA8w== 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=7mTgUi8evJ/mN65tNKT/RxCZhpsNUwB2qWE5f/VkSEw=; b=BODpzFzBqbyxTTF5M8ML84enKW8MSBSQCKTenZ5IMzgKre03WiHOuoN8H50gtoFV6t q/nddSNEq1pjIaHSymYCS4q3yY6osE/PpoMLGnRgQJvdcRZ+dHLHKGOEakxwFHKuNLDM W+nUm7gOJ0UfwK4OIrrwzIYaZCyznxHauoXdzr0D8NEsFLEBNj3WS7KeCtENlyHsTaxH COEas45N/IPrCFAHyEnfDEeiUATzl0xYQOQImKHPmn6OP3tnUk5AgWEuNC4fsJzLjc+a 4Tez4ziuy5fSPQyyBMo0OaP58S499oY/LEiHuWH/z/Hp18SSQggQzwtaiy02ccbDn+yb p3nQ== X-Gm-Message-State: AOAM531HwXOPJLBvKUq/Yswuj4gG6MLZtQfjLop3Dcg/wEVtF98Vx838 7GI9XHyZccN7V1LYB/FhSg91RSme X-Google-Smtp-Source: ABdhPJzk6RwiLRw1bYJ5nBlFmJziJVNXskoHz6ce1zZxJ7BQ6JvvRwBXZQXUbONn9sxCHagy4aVybw== X-Received: by 2002:a19:7418:: with SMTP id v24mr3231230lfe.15.1589566685430; Fri, 15 May 2020 11:18:05 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id r3sm1735412lfm.52.2020.05.15.11.18.03 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 May 2020 11:18:04 -0700 (PDT) From: "Valery Smyslov" To: "IPsecME WG" References: <158956634114.27989.1031660528241074625@ietfa.amsl.com> In-Reply-To: <158956634114.27989.1031660528241074625@ietfa.amsl.com> Date: Fri, 15 May 2020 21:18:08 +0300 Message-ID: <0bae01d62ae5$30284070$9078c150$@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: AQF48YVsAB9mEO8kY5RJjBrJ76MiTKlj5f0A Content-Language: ru Archived-At: Subject: [IPsec] FW: New Version Notification for draft-smyslov-ipsecme-rfc8229bis-01.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, 15 May 2020 18:18:10 -0000 Hi, a new version of rfc8229bis draft is published. Tommy Pauly agreed to co-author the draft and has already significantly improved the quality of the draft's text. Regards, Valery. -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Friday, May 15, 2020 9:12 PM To: Tommy Pauly; Valery Smyslov Subject: New Version Notification for draft-smyslov-ipsecme-rfc8229bis-01.txt A new version of I-D, draft-smyslov-ipsecme-rfc8229bis-01.txt has been successfully submitted by Valery Smyslov and posted to the IETF repository. Name: draft-smyslov-ipsecme-rfc8229bis Revision: 01 Title: TCP Encapsulation of IKE and IPsec Packets Document date: 2020-05-15 Group: Individual Submission Pages: 30 URL: https://www.ietf.org/internet-drafts/draft-smyslov-ipsecme-rfc8229bis-01.txt Status: https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-rfc8229bis/ Htmlized: https://tools.ietf.org/html/draft-smyslov-ipsecme-rfc8229bis-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-smyslov-ipsecme-rfc8229bis Diff: https://www.ietf.org/rfcdiff?url2=draft-smyslov-ipsecme-rfc8229bis-01 Abstract: This document describes a method to transport Internet Key Exchange Protocol (IKE) and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as "TCP encapsulation", involves sending both IKE packets for Security Association establishment and Encapsulating Security Payload (ESP) packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP. TCP encapsulation for IKE and IPsec was defined in [RFC8229]. This document updates specification for TCP encapsulation by including additional calarifications obtained during implementation and deployment of this method. This documents makes RFC8229 obsolete. 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. The IETF Secretariat From nobody Mon May 18 10:12:55 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 230363A0911 for ; Mon, 18 May 2020 10:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.189 X-Spam-Level: X-Spam-Status: No, score=-0.189 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 brJ9GE6Qq_ek for ; Mon, 18 May 2020 10:12:51 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2098.outbound.protection.outlook.com [40.107.243.98]) (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 CE65A3A090B for ; Mon, 18 May 2020 10:12:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=C4+0RsWTSN+KJwNuVIClJx8ZzKGlkIOEafvKdcVJhPmt5dMbx2oLOJP1s8jZBQKQJj4wRCeL/dLV+3FnMuetfJ7CzOnWf4e1VoIiQP1PwlHf4O+Epo2xB/LgRagjug4GzwVXItK+yRbdkTzSGVLifmNop/5u5gl6fadGav6oiXsYgCHRrD6AvPm/iWVNZuTiWxvVTxeE+hItAZ+yQn1c4fQbXLDOEGDz5rvFRyOhA2kRkzQo0Ayc0UYzsk/iLdU2SBtDrvKDjdh/mKFSWPST77ZIj0Ll+OKyEi3JPGFFRSeKfUtyrp+FsuW2lhCxB4QPD94mZwhztFPpYHl1u6+AEg== 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=OrP5v0VgVn2KvILpJWXf8DTkZIM0Sisddw8LfpNocKY=; b=Juy+uJvpYcCshk47To2asv6HPw2FQgUfZXtEq5FH8BkGc+kon+E+uDKLrGTKuydVAfAk69YnrMvD/plfFZu9MSoFFWyS/BioTvt8/i3JB3ORNBm6SLd7+DB7FM3IxpVY+u1xJs5/y6gLWbDmlQCUWtHRPKBKVWf3PSGgP+POyLVvO/gJiXGvTqbSnpCDYISabdWmIfdGzNW05i3mJE2PzHUrclpHvw9djiNqvZzTmJnJ8ifklFPl2p+n79UNrp29tYniSpxnPrABUJyWEhLi/PvWSGisN/xOYZuWbTbr+D3DKe0oUoPx+d8vVLK0HQsFSXmeY70S2+q2AZRc+6Fp3g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OrP5v0VgVn2KvILpJWXf8DTkZIM0Sisddw8LfpNocKY=; b=B8EsEygi8TEZCRIRpxpRR+8qSOtLL3Nc/dbG8eaj70SlZS7Ue+fQfMteN+qJYHIF80gg3pqlFgPp+4GaEROkbdW2nWWLDTHju5cZAmwq5SddFWvVvcMRFR/YlP+yRbDS+4SMyGmRpQiajBAa8r/xc4R5EMt6rKNA0OPDvnuH9lM= Received: from SN6PR13MB2334.namprd13.prod.outlook.com (2603:10b6:805:55::16) by SN6PR13MB2559.namprd13.prod.outlook.com (2603:10b6:805:5c::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.11; Mon, 18 May 2020 17:12:47 +0000 Received: from SN6PR13MB2334.namprd13.prod.outlook.com ([fe80::7813:cef6:bbde:1970]) by SN6PR13MB2334.namprd13.prod.outlook.com ([fe80::7813:cef6:bbde:1970%5]) with mapi id 15.20.3021.019; Mon, 18 May 2020 17:12:47 +0000 From: Linda Dunbar To: "ipsec@ietf.org WG" Thread-Topic: Is there any drafts or RFCs on solutions to RFC 7018 Auto-Discovery VPN Problem Statement and Requirements? Thread-Index: AdYtNxBY7rsPEhAvSSaEorpChh0soA== Date: Mon, 18 May 2020 17:12:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [72.180.73.64] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b358bdf4-c7ab-4a92-72ba-08d7fb4eb030 x-ms-traffictypediagnostic: SN6PR13MB2559: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 04073E895A x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mjLuwTQ7+PF95ZYBuNiEdKlbufzhzqOiZV91d6yUV5Dov4U0ItqifMAEB0xEIQTVNkqTJll/DJyhdzVYUssGvD7t7cS9NRmxakZ3HWoz+NGfhQLsOclc/6zbwwPqYhHBbQwdSxJJzDHbHGHdW5cqADM7nSobbWFSXFWT8yoLLUJKz8Bk3NVCMTIIwEaFP+FvwNUm+AlRBD3ff8zihZy3IHkCGUnhdEodgkuNXc+7rga3MRSgWoZIZXbOn3JvQeyrlyg8EGZw+IF0SMOGzRrOofJE5pyTGaMIamjlaeNTTtAbmLhg9PM6EJBqjJ6CkD2VbskAFsQacCGxxM/PonBBKw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR13MB2334.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(39840400004)(376002)(396003)(366004)(136003)(8936002)(186003)(5660300002)(8676002)(52536014)(2906002)(86362001)(76116006)(66946007)(55016002)(9686003)(44832011)(66476007)(66556008)(64756008)(66446008)(6916009)(6506007)(478600001)(316002)(4744005)(71200400001)(7696005)(26005)(33656002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: Kp42MBlAylhDwXE4ItXDUISLfxrd19vHLZG8YSfszIylKBLOFujVjf1oTJLbvvKl/tZmqayyPknZURiT5yQG7q0XPSHp7WpLZ1Y2K2gcW4uWSBtazcmVZiYA+XcjqT70hZvyVkS4Zv5i19r6B7TCr66C1QgdeTJ02Cu+iCv24+PCpsGisFLtLdZWg0JW9jWuPqHawZfE8Z+Kz7j8DFCzYIrisbzj2DLrtzEnA78W7X/JOP3fVmYaOPbg0VJL4S8/QTZo7WE/ohP0tZTJkH3lB9hZh7aLdCRlRKr2lReuJ2h8A3vgqSvxVNxFO8wfQ03cqSd6+v6Ax4JO7qWYIgc+h4VFYk4tzIhorr+lgdvnOI/10i4MdQ4pKYnm05sKj2Dd1jmTRcpNUbAsNmofMIDlKE+OWJSv79XX/YpKdLblmKMvxYbEMGXxeth6awyZ3xqJfVt15vMgYo4Eqs7P54ynk1wlO/rXhYSduupDc0J68fc= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SN6PR13MB233450103D13365702E14D7A85B80SN6PR13MB2334namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-Network-Message-Id: b358bdf4-c7ab-4a92-72ba-08d7fb4eb030 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2020 17:12:47.7091 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: NlPVVaIUbks1g+DyFi6PeM23kSXzBE/g01qfg2yd6dMZu45DrUwAiNDFlT1F/t0OxyhSS+XnoBb71LC8tTibbg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR13MB2559 Archived-At: Subject: [IPsec] Is there any drafts or RFCs on solutions to RFC 7018 Auto-Discovery VPN Problem Statement and Requirements? 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, 18 May 2020 17:12:53 -0000 --_000_SN6PR13MB233450103D13365702E14D7A85B80SN6PR13MB2334namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We are experiencing the problems described in RFC 7018 (Auto-Discovery VPN = Problem Statement and Requirements), i.e. the problem of enabling a large = number of peers (primarily Gateway) to communicate directly using IPsec to = protect the traffic between them. Is there any drafts describing the solutions to the problems identified by = RFC7018? Thank you very much, Linda Dunbar --_000_SN6PR13MB233450103D13365702E14D7A85B80SN6PR13MB2334namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We are experiencing the problems described in RFC 70= 18 (Auto-Discovery VPN Problem Statement and Requirements), i.e. the  = problem of enabling a large number of peers (primarily Gateway) to communic= ate directly using IPsec to protect the traffic between them.

 

Is there any drafts describing the solutions to the = problems identified by RFC7018?

 

Thank you very much,

 

Linda Dunbar

--_000_SN6PR13MB233450103D13365702E14D7A85B80SN6PR13MB2334namp_-- From nobody Mon May 18 10:16:03 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2AF3A0912 for ; Mon, 18 May 2020 10:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=CYcda6FL; dkim=pass (1024-bit key) header.d=juniper.net header.b=ZkJks0tX 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 ART1WGlrtS89 for ; Mon, 18 May 2020 10:15:58 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 A35193A0911 for ; Mon, 18 May 2020 10:15:58 -0700 (PDT) Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 04IHDOrs026525; Mon, 18 May 2020 10:15:53 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=IZLdk5WeiU2GkAnF3XOK6iMYSeIvcN63GE/BenY3aLg=; b=CYcda6FLDx2A5yndsg/EU5EfXWi2H7/K+odhE+jxkJV32P36BoxFPeF5ZH6JBPZwTDYZ eo1tGInH4NqAWQv6tDRmiN+X3nfr9Q78iofCT3ey6vFGruk+jQxCGILpXCgGpFLiYOMK T+7UFSS5YiqsGU7kPhpNAuye/pxf2eQ13uiqhl9Ftz1qXauppe/ahA9WhA4SOYLFsgoo PTgoaSqcELwHCXM36wrzTLtN5dg2iyzMiaLTyOf4WAXOqmiYLMeYxb5KI8o5dUE95lBs VOos+2eVIAl/Pjv65yUvfZ+Ki5IvS7s/rV+Lr3eSry/V0LPEEtGZ6dNeqVNzxW5oEkDQ pw== Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2171.outbound.protection.outlook.com [104.47.55.171]) by mx0b-00273201.pphosted.com with ESMTP id 312yxfj7ss-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 May 2020 10:15:52 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BvMVcxMX/IKgwBVp91r3aVibMcpMyCVVv86MEw35sw8R5vzvse8j9Am6CoUC4GXYNq+pz+bQbgCVXFqEqMxiInQQpPzwUFn8mifS4irBZZGwPS3QvdxJXks+OoH2COsjgvBKF3wU0CYN4NNL2k7pIiBrzGr3OBWFgjBtOKcljPkur0XS71wW4ISvovBhxCSpj1Ruhid56u4fs/rPEPi8ahfZ2aOZpYaPe2aiYwadNgqS2LDzUHk198KBHejxt64eYHJa+OCneHB7lMezxLTdL2e5LMAtuofQmz5jfV8VHgwDBFs4NWCiPBVN+eoJmZ9ze6nX4xvlJhf6DDCuBJKw9g== 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=IZLdk5WeiU2GkAnF3XOK6iMYSeIvcN63GE/BenY3aLg=; b=anE5blPYyFTCgvAzOKHOH828GBtqiknOiZouds+P/3uGIFCbh6b8HObZMdoLF0mzozXdqFGA234q8Cu8I3rdTrux7rDF0yz213cCy2ButEixH3NNzi/wJLvacsRtzVmIXkOdPFkvxnw+fD3SkKi8z/cAJRT+1bsOwJ/zpMuYAjrNbuOc8dG+QkCuvkXvEDhRx90IAEyW9GU/cFnKr+SzH++J6xAS0i7thsuZu82WEf7ZbEMQL+LBwGMWOCuoe9s/McMkyTkDZ1CHq1ptzw82+Ay27IEu+8i+yGt3XG4jMGmiZ6kJL7ii6Tk2+Odm4Y5Mna0e9OBm4zxOXQ7oZOS5gQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IZLdk5WeiU2GkAnF3XOK6iMYSeIvcN63GE/BenY3aLg=; b=ZkJks0tXuIQFLROSeAlNqff053GLvAMuc/G+EaXjya6pjK7miT/BR9hRyrLDtqvziL9Rt/b8GlLbwcSNXzCvfz5vThYsDMlClgX2ihdFMeCn7reQybnciH4qkWYSojHf3SpGQg5qT1Ex+TkvttQ/vIkWDXXIiGUzHoBJ1Zn4fvk= Received: from DM6PR05MB5465.namprd05.prod.outlook.com (2603:10b6:5:5c::29) by DM6PR05MB4875.namprd05.prod.outlook.com (2603:10b6:5:13::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.11; Mon, 18 May 2020 17:15:49 +0000 Received: from DM6PR05MB5465.namprd05.prod.outlook.com ([fe80::7d2e:8687:3116:3574]) by DM6PR05MB5465.namprd05.prod.outlook.com ([fe80::7d2e:8687:3116:3574%6]) with mapi id 15.20.3021.013; Mon, 18 May 2020 17:15:49 +0000 From: Praveen Sathyanarayan To: Linda Dunbar , "ipsec@ietf.org WG" Thread-Topic: Is there any drafts or RFCs on solutions to RFC 7018 Auto-Discovery VPN Problem Statement and Requirements? Thread-Index: AdYtNxBY7rsPEhAvSSaEorpChh0soAAAL8iY Date: Mon, 18 May 2020 17:15:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-05-18T17:15:49.140Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=0; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.242.10] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: caffdc44-1cd3-47bc-314f-08d7fb4f1c96 x-ms-traffictypediagnostic: DM6PR05MB4875: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 04073E895A x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 9GwXDBuIlfel2yaFsozbzADRIJ9AtwD0IdIpWYTGZryIqXBimN1s5OpY3Bd8vCG3NzIyyVu0QzUzv/c+njEykid2TVArxihty5NkuX5B6FT1xx3gOKTsAQHGW4INgQ40AN5E4vfJcfRtRaHyltGnmwxkDPh1iymXjeDWdMMrEkDWcps39Z0+z37WUsONHanjX+pl8jCfRcnmjOGaW9uUaqsrYSliT8o9J+oaxGjnC3hFBJauYmSLp9BIKZWga1+e585GgjHg2cbN5qt/3+Zw4i8e2UrT2X0WocGfkPznscioq5nu8YUy3lxS85cUjgv4eVVor8gcl6CM8EBlCj4AhZ/HVUV1k2INRuwxZgQiekXdFun12HL/4DYwOW+v8Z3u8MlWMrsq6xaEpz6vWENdVQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR05MB5465.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(396003)(376002)(366004)(346002)(136003)(19627405001)(53546011)(6506007)(52536014)(33656002)(86362001)(71200400001)(5660300002)(2906002)(110136005)(4744005)(316002)(966005)(19627235002)(66446008)(66476007)(91956017)(76116006)(66946007)(66556008)(64756008)(55016002)(166002)(478600001)(7696005)(186003)(8936002)(8676002)(26005)(9686003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 7wRufu13BO5/hrsgUEmTbwuhYmp8QtYJHYujrHH+9j9N1Q22zCQoKO8mNjbtHm8BkKPuFNc6EbfcRGeWrsAALA0r1dv5FOuYkQCwXW6sw85EtRS0Q0Jeh8BoN5Z3xLW1+DE6BFKcbH19QqT1+XzrtsMRsnZZVP43ChRkq/F0tsUn3SQJg6hXQoU94BKZnE5rzjCfE7XatqL8qSAKBYSGI/Z+Q7mLMyKvtMPZijpyAbEXZzL0nvET1Pzj2pxguM2IWztJNXJrpReFBtyvK7bWwbjjWPqqq90krRhLgP9tCYgmuFmTKbrpokRHIYWJZ3259gAnvTovRnLh+Lkn7lr7XCQHL+LP5PsIs+wgFAxwVuGlHeW9pLFP8b3OOacjTRgzgTEoDpy+LAGB/SqFVuezE1QROfTSqHbOTfqgWn+iG6Q8EG28535mF95h/lRJk5vSc2+zdv+rnl0K0Qcj5KpgnywHkEeZ6kmm7GkVmDHJMIo= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR05MB54655481A4501309A522A567A5B80DM6PR05MB5465namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: caffdc44-1cd3-47bc-314f-08d7fb4f1c96 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2020 17:15:49.5488 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: w0qa63DlN1zVH52wTMC7WVoy8W3vpXD+g0DIfBSHiVxI+iF8yU4TQWhigMuiBlBmhRy93dK1sVUKRJNivZ+LQg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4875 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.676 definitions=2020-05-18_06:2020-05-15, 2020-05-18 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 lowpriorityscore=0 priorityscore=1501 adultscore=0 mlxlogscore=999 cotscore=-2147483648 impostorscore=0 bulkscore=0 clxscore=1011 phishscore=0 mlxscore=0 spamscore=0 suspectscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2005180144 Archived-At: Subject: Re: [IPsec] Is there any drafts or RFCs on solutions to RFC 7018 Auto-Discovery VPN Problem Statement and Requirements? 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, 18 May 2020 17:16:01 -0000 --_000_DM6PR05MB54655481A4501309A522A567A5B80DM6PR05MB5465namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Linda, We published the following draft for AutoDiscovery VPN. It is already imple= mented by Juniper and other major vendors. https://tools.ietf.org/html/draft-sathyanarayan-ipsecme-advpn-03 Thanks, Praveen ________________________________ From: IPsec on behalf of Linda Dunbar Sent: Monday, May 18, 2020 10:12 AM To: ipsec@ietf.org WG Subject: [IPsec] Is there any drafts or RFCs on solutions to RFC 7018 Auto-= Discovery VPN Problem Statement and Requirements? [External Email. Be cautious of content] We are experiencing the problems described in RFC 7018 (Auto-Discovery VPN = Problem Statement and Requirements), i.e. the problem of enabling a large = number of peers (primarily Gateway) to communicate directly using IPsec to = protect the traffic between them. Is there any drafts describing the solutions to the problems identified by = RFC7018? Thank you very much, Linda Dunbar Juniper Business Use Only --_000_DM6PR05MB54655481A4501309A522A567A5B80DM6PR05MB5465namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Linda,

We published the following draft for AutoDiscovery VPN. It is already imple= mented by Juniper and other major vendors.


Thanks,
Praveen
From: IPsec <ipsec-bounc= es@ietf.org> on behalf of Linda Dunbar <linda.dunbar@futurewei.com>= ;
Sent: Monday, May 18, 2020 10:12 AM
To: ipsec@ietf.org WG <ipsec@ietf.org>
Subject: [IPsec] Is there any drafts or RFCs on solutions to RFC 701= 8 Auto-Discovery VPN Problem Statement and Requirements?
 

[External Email. Be cautious of content]=

We are experiencing the problems described in RFC = 7018 (Auto-Discovery VPN Problem Statement and Requirements), i.e. the &nbs= p;problem of enabling a large number of peers (primarily Gateway) to commun= icate directly using IPsec to protect the traffic between them.

 

Is there any drafts describing the solutions to th= e problems identified by RFC7018?

 

Thank you very much,

 

Linda Dunbar


Juniper Business Use Only

--_000_DM6PR05MB54655481A4501309A522A567A5B80DM6PR05MB5465namp_-- From nobody Mon May 18 10:31:51 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B903A0A00 for ; Mon, 18 May 2020 10:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTLebpkQ2KgC for ; Mon, 18 May 2020 10:31:48 -0700 (PDT) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 1C5D13A09FF for ; Mon, 18 May 2020 10:31:48 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id t7so4517682plr.0 for ; Mon, 18 May 2020 10:31:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:savedfromemail:date:subject:in-reply-to:importance:from :to:mime-version; bh=65HjsV8nRih6gplX6b+oDXgp4/NSu1i9aYgLfv1l6LA=; b=dj3H68dXC8QCX2JaUHQvGY7svkcuDyYELTfdSUN9B/3dYpip5XbPEfltES/QejG4Ay VP2B757/55PPCi/CxThZMdppTDwAopHSDm8vVeW7CKzlcKQ++Xz+GzwlimoponEGND1H aRJelHBgR98FUmPieoNiG24z8MePCtGTlxsrJvBxfqiHfeyfLOgv3fi9OKypuJouMByb Q7ZxbL90KhXK7dl67YIdT+gDXpUlVQm7+Lzc0VQOLjKH893CQap3+UfGwB/WSZ7kfbuL t5iiDu6nzDfNawXhE+BJmdaKfgWaIPkYahWhKrslGic1bPHPUSOFcrIq4a0ox7lOh8av JJKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:savedfromemail:date:subject :in-reply-to:importance:from:to:mime-version; bh=65HjsV8nRih6gplX6b+oDXgp4/NSu1i9aYgLfv1l6LA=; b=dzrU3iwOiivK5+BdypquJYCYnyHtwqyEotpXcKNvZJFd5Th1c0Ogfu4PlgTGcWqySX 8eCB2IM6N4FTUXerA6sSls23c45zO23hJsaNPPmZlfCwzZts+zbn7tccOKbScO56vrNW wNVemWjt/vHWBkzt7l1yNBIcG9CmDJl3OkkgzUKrULgfVZQiyocqKkvWCraM34yrgcie uGWldtPgggDcBVP7NUoa7W1zYBp2toaRiT+amB1nzRSZ+C63CYrG+/1L0msFPn5Nuvkq GcsT1xyC29ipb7RU5afh7xJqrPIVI1fF4axv+bHS0EchNwaIIu6mYpjbAVJ5Cd3x8D2o bPQQ== X-Gm-Message-State: AOAM533lFd8Nlmx+lTgwEbQqEVSfK1TNcYmxfF1ZBwOzkkw+svAlMPfM RMiLY7PkWIg8YG3JWCxYnhc= X-Google-Smtp-Source: ABdhPJzY6iDKuHqCO7a79RfDR5ImaPw96dq+ajufbsa4mFXidaIzWIiakb9/FMsE4UaVSd64FqGcNA== X-Received: by 2002:a17:902:502:: with SMTP id 2mr12230695plf.134.1589823107562; Mon, 18 May 2020 10:31:47 -0700 (PDT) Received: from ?IPv6:2601:647:5180:4720:557d:60fd:bd14:cf32? ([2601:647:5180:4720:557d:60fd:bd14:cf32]) by smtp.gmail.com with ESMTPSA id l9sm9518791pfd.5.2020.05.18.10.31.46 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 May 2020 10:31:46 -0700 (PDT) Message-ID: <5ec2c682.1c69fb81.4aa28.d34b@mx.google.com> SavedFromEmail: vishwas.ietf@gmail.com Date: Mon, 18 May 2020 10:31:45 -0700 In-Reply-To: Importance: normal From: "vishwas.ietf" To: Linda Dunbar , "ipsec@ietf.org WG" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_45472275879500" Archived-At: Subject: Re: [IPsec] Is there any drafts or RFCs on solutions to RFC 7018 Auto-Discovery VPN Problem Statement and Requirements? 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, 18 May 2020 17:31:50 -0000 ----_com.samsung.android.email_45472275879500 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 TGluZGEsVGhlcmUgd2VyZSA0IGRyYWZ0cyB3cml0dGVuIGJhc2VkIG9uIHRoZSBleGlzdGluZyBz dGF0ZSBvZiBhcnQgYXQgdGhhdCB0aW1lLldlIGNyZWF0ZWQgb25lIGFzIEhQIGFuZCBIM0MgYWJv dXQgNiB5ZWFycyBiYWNrLiBDaXNjbyBoYWQgb25lIHRvbyBhbmQgc28gZGlkIG90aGVycy5odHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWFvLWlwc2VjbWUtYWQtdnBuLXByb3RvY29s LTAyLVZpc2h3YXMKLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLUZyb206IExpbmRh IER1bmJhciA8bGluZGEuZHVuYmFyQGZ1dHVyZXdlaS5jb20+IERhdGU6IDUvMTgvMjAgIDEwOjEz IEFNICAoR01ULTA4OjAwKSBUbzogImlwc2VjQGlldGYub3JnIFdHIiA8aXBzZWNAaWV0Zi5vcmc+ IFN1YmplY3Q6IFtJUHNlY10gSXMgdGhlcmUgYW55IGRyYWZ0cyBvciBSRkNzIG9uIHNvbHV0aW9u cyB0byBSRkMgNzAxOCBBdXRvLURpc2NvdmVyeSBWUE4gUHJvYmxlbSBTdGF0ZW1lbnQgYW5kIFJl cXVpcmVtZW50cz8gCgpXZSBhcmUgZXhwZXJpZW5jaW5nIHRoZSBwcm9ibGVtcyBkZXNjcmliZWQg aW4gUkZDIDcwMTggKEF1dG8tRGlzY292ZXJ5IFZQTiBQcm9ibGVtIFN0YXRlbWVudCBhbmQgUmVx dWlyZW1lbnRzKSwgaS5lLiB0aGUgwqBwcm9ibGVtIG9mIGVuYWJsaW5nIGEgbGFyZ2UgbnVtYmVy IG9mIHBlZXJzIChwcmltYXJpbHkgR2F0ZXdheSkgdG8gY29tbXVuaWNhdGUgZGlyZWN0bHkgdXNp bmcgSVBzZWMgdG8gcHJvdGVjdCB0aGUKIHRyYWZmaWMgYmV0d2VlbiB0aGVtLiAKwqAKSXMgdGhl cmUgYW55IGRyYWZ0cyBkZXNjcmliaW5nIHRoZSBzb2x1dGlvbnMgdG8gdGhlIHByb2JsZW1zIGlk ZW50aWZpZWQgYnkgUkZDNzAxOD8KCsKgClRoYW5rIHlvdSB2ZXJ5IG11Y2gsIArCoApMaW5kYSBE dW5iYXIKCg== ----_com.samsung.android.email_45472275879500 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXYgZGlyPSJh dXRvIj5MaW5kYSw8L2Rpdj48ZGl2IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRv Ij5UaGVyZSB3ZXJlIDQgZHJhZnRzIHdyaXR0ZW4gYmFzZWQgb24gdGhlIGV4aXN0aW5nIHN0YXRl IG9mIGFydCBhdCB0aGF0IHRpbWUuPC9kaXY+PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2 IGRpcj0iYXV0byI+V2UgY3JlYXRlZCBvbmUgYXMgSFAgYW5kIEgzQyBhYm91dCA2IHllYXJzIGJh Y2suIENpc2NvIGhhZCBvbmUgdG9vIGFuZCBzbyBkaWQgb3RoZXJzLjwvZGl2PjxkaXYgZGlyPSJh dXRvIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWFvLWlwc2VjbWUtYWQtdnBu LXByb3RvY29sLTAyPC9kaXY+PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2IGRpcj0iYXV0 byI+LVZpc2h3YXM8L2Rpdj48ZGl2IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2 PjxkaXYgc3R5bGU9ImZvbnQtc2l6ZToxMDAlO2NvbG9yOiMwMDAwMDAiIGRpcj0iYXV0byI+PCEt LSBvcmlnaW5hbE1lc3NhZ2UgLS0+PGRpdj4tLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0t LS0tPC9kaXY+PGRpdj5Gcm9tOiBMaW5kYSBEdW5iYXIgJmx0O2xpbmRhLmR1bmJhckBmdXR1cmV3 ZWkuY29tJmd0OyA8L2Rpdj48ZGl2PkRhdGU6IDUvMTgvMjAgIDEwOjEzIEFNICAoR01ULTA4OjAw KSA8L2Rpdj48ZGl2PlRvOiAiaXBzZWNAaWV0Zi5vcmcgV0ciICZsdDtpcHNlY0BpZXRmLm9yZyZn dDsgPC9kaXY+PGRpdj5TdWJqZWN0OiBbSVBzZWNdIElzIHRoZXJlIGFueSBkcmFmdHMgb3IgUkZD cyBvbiBzb2x1dGlvbnMgdG8gUkZDIDcwMTggQXV0by1EaXNjb3ZlcnkgVlBOIFByb2JsZW0gU3Rh dGVtZW50IGFuZCBSZXF1aXJlbWVudHM/IDwvZGl2PjxkaXY+PGJyPjwvZGl2PjwvZGl2Pgo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBhcmUgZXhwZXJp ZW5jaW5nIHRoZSBwcm9ibGVtcyBkZXNjcmliZWQgaW4gUkZDIDcwMTggKEF1dG8tRGlzY292ZXJ5 IFZQTiBQcm9ibGVtIFN0YXRlbWVudCBhbmQgUmVxdWlyZW1lbnRzKSwgaS5lLiB0aGUgJm5ic3A7 cHJvYmxlbSBvZiBlbmFibGluZyBhIGxhcmdlIG51bWJlciBvZiBwZWVycyAocHJpbWFyaWx5IEdh dGV3YXkpIHRvIGNvbW11bmljYXRlIGRpcmVjdGx5IHVzaW5nIElQc2VjIHRvIHByb3RlY3QgdGhl CiB0cmFmZmljIGJldHdlZW4gdGhlbS4gPG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JcyB0aGVyZSBh bnkgZHJhZnRzIGRlc2NyaWJpbmcgdGhlIHNvbHV0aW9ucyB0byB0aGUgcHJvYmxlbXMgaWRlbnRp ZmllZCBieSBSRkM3MDE4Pwo8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rIHlvdSB2ZXJ5IG11 Y2gsIDxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TGluZGEgRHVuYmFyPG86cD48L286cD48L3A+Cjwv ZGl2Pgo8L2JvZHk+PC9odG1sPg== ----_com.samsung.android.email_45472275879500-- From nobody Mon May 18 10:53:38 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F3B3A0B13 for ; Mon, 18 May 2020 10:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.189 X-Spam-Level: X-Spam-Status: No, score=-0.189 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 xkEvTn33voRT for ; Mon, 18 May 2020 10:53:33 -0700 (PDT) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2115.outbound.protection.outlook.com [40.107.244.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 A4E083A0B12 for ; Mon, 18 May 2020 10:53:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BaN/W31ChK3i7LLeoDLQlDOUpctohk7ZdEJUq/cFKzSMoU5b/Lwfo3VT2rj/3siIZ0nKRkz4wHPMwHN9fSGJBPZ0nvKaoGtLWqfKyyWr03RYJYV4HS8O0WQ5f2mBNwHigcfyjdqNs1ovoIwKChsixzNZEAq3AD/kLmjJbHE9SG4PdsnRpH4M03DA0wF1NQdVOMd/MywyZJ4FxIIJXuh1u6/Z5d6RbcNS4jkDXUOg6LM5K5ROwD3sQg9DBG79TgW+qS/70pxQ1tRN/ccdogcdxEjcdl5I+DYb781kbN22VTh+agu1MriwmLeZkOgzLY/2h7Pv6J13+73Cb3JeU9yeBQ== 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=cmglo+P1dQDHh0nb8w6dWMk84/pVZNePUo8N8jaFCws=; b=kiSMQTnNwvmTy4yPCvfN5JuTzhXwOXG/m/8Ub2XnZNrH1j8/bnPne6eGENzgb/q7I9QVBadx3ocb9BTcjP/+NpoCabVfu9F/PPjEqP3kkBhwbBmfredlenakTQavnL7G0GDg00mrd1OTvXtE4OdiJoJBpubVLJYW+5cowvPIzp0eb9Aw/rlJBJvi9J5tKP7nC4r8zJNBY9THQ7O1MMKD0Et6Lz4WQLU/GcCcWtGl8rVCG5nI1suB0NUngR/EkWOpfUMuZYVURjDUP5oTRpvyFsNHlgii9mLxme1fLDpRKnH0xKo/57vou/oYgrnn5JIdRuCXBc2ZN2iX4SPF+6TZRw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cmglo+P1dQDHh0nb8w6dWMk84/pVZNePUo8N8jaFCws=; b=YEbF5XRU9aT/wOa6ukx53LnoUpLy3g/WawhyxcWGLEWhKZouZkQBNG2lRLZvS3J9oS8g0wPOq/2G7XXTAqUEetYuYM4o3qPFjHehtvqBJMijs+fboc82CFJbQ81+d+GCmiGbxLsoe27Bgk+K6SySbxYT+W0K1um/rUlFOMyj1qg= Received: from SN6PR13MB2334.namprd13.prod.outlook.com (2603:10b6:805:55::16) by SN6PR13MB2494.namprd13.prod.outlook.com (2603:10b6:805:56::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.13; Mon, 18 May 2020 17:53:31 +0000 Received: from SN6PR13MB2334.namprd13.prod.outlook.com ([fe80::7813:cef6:bbde:1970]) by SN6PR13MB2334.namprd13.prod.outlook.com ([fe80::7813:cef6:bbde:1970%5]) with mapi id 15.20.3021.019; Mon, 18 May 2020 17:53:31 +0000 From: Linda Dunbar To: vishwas.ietf , "ipsec@ietf.org WG" Thread-Topic: [IPsec] Is there any drafts or RFCs on solutions to RFC 7018 Auto-Discovery VPN Problem Statement and Requirements? Thread-Index: AdYtNxBY7rsPEhAvSSaEorpChh0soAAAyMyAAAC2RVA= Date: Mon, 18 May 2020 17:53:31 +0000 Message-ID: References: <5ec2c682.1c69fb81.4aa28.d34b@mx.google.com> In-Reply-To: <5ec2c682.1c69fb81.4aa28.d34b@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [72.180.73.64] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 135a71fc-e7bd-4e10-526a-08d7fb5460aa x-ms-traffictypediagnostic: SN6PR13MB2494: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 04073E895A x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: TR1UxiZ2MksbMeaAnc9Xk4GQuy22M4eAWSUu/W/2I0u8aGxzoTBrycCMEQJqeJb5dSkWg4Qtl+CwwwFm0EzjDQFh619hl7GObmX6pLBrKZCgdKsOekd1lFckrCZYc8kHvV+T4XrW1nC5lfgyT+oTYvSEUB2Gh8X4tpkRx2ldjVsFdLFVY9pyVWSKXOVVpQLS4Ma2wwj7OjRdiBXCOBxxi7CYFFRMAR7pMY+gtRcjICYDuEOBdOk/XnuHSHIf6Vv0+LtXHA2VAkViJpmtcqZibhHJAIMPynPE4HrL39JgDrXV5mGATGEdEGflfJlDZ4/Wm8CD1av56OfXj5AaCNbfmAr7j/OWjzhywUpSp3a934FjMvtXz0MbZYFYX6MssWBUKqdlyKlIiVCD6kaLu67o0A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR13MB2334.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(39840400004)(346002)(376002)(366004)(396003)(55016002)(8676002)(71200400001)(8936002)(316002)(478600001)(166002)(966005)(86362001)(110136005)(64756008)(6506007)(66476007)(44832011)(7696005)(76116006)(66946007)(5660300002)(9686003)(66446008)(52536014)(186003)(66556008)(2906002)(26005)(33656002)(53546011); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: rgc4OyRzHy3jhxp9N/EAH0SZ7+auCQV0ZbCTAr9gEW5waquWG5Xb/BTF2F0mSyL7XqSL7NDsFDclbUFB2kGdAzhDNm2dHyQHHOEqNWzKY+6Ht8T8nWqJGY1d3ZfqSsUF081C7VV8OCfFBo5qbgu4xTTVlhPV3EOssSqKOhUfjMBpUhy4pUrlYBR+CHJ5SgSMSxE+bLrCdvThkYNNOsIF5SfkOav35niLBnZaUc1mjb1wQTGUvIy9ZFqV7PjxM97iSCwzaFgGQceH/iP+ezT+L50sfd6vpSPvEx6l4BDl5NWza44y8TE1owR3NBt/sxLPN4BhRi4MWaBWxIsm5GMAquYT/LYqjSGYH+W1d5mDifFvbhJZte+jCoQBZSwwJfwRNFNq9BHgCrHX/oZs3d4RuKJsq7NXw99rbu9HQUbburwXNN2yENaQ709Gfaz2cZEWGJfx27uSETP7VPOqVkjh4O+uKwfh1QNODYAV8zFzjvA= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SN6PR13MB2334433FD0CFC6F80CFDDF6585B80SN6PR13MB2334namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-Network-Message-Id: 135a71fc-e7bd-4e10-526a-08d7fb5460aa X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2020 17:53:31.2294 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jd5070dVIHQgg9IP+tnhaI8fZRV7RXjCK4abyMoRiyPhfq59Vrp4CfXSSX8S7wQzQUZk/PMUoOreVLvzqrpi5Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR13MB2494 Archived-At: Subject: Re: [IPsec] Is there any drafts or RFCs on solutions to RFC 7018 Auto-Discovery VPN Problem Statement and Requirements? 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, 18 May 2020 17:53:36 -0000 --_000_SN6PR13MB2334433FD0CFC6F80CFDDF6585B80SN6PR13MB2334namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VmlzaHdhcywNCg0KVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgdGhlIGxpbmsuICAgVGhlIGRyYWZ0 IHdhcyBkYXRlZCBhdWcgMjAxMy4NCldoeSBpdCBkaWRu4oCZdCBtb3ZlIGZvcndhcmQ/DQoNCkxp bmRhDQoNCkZyb206IHZpc2h3YXMuaWV0ZiA8dmlzaHdhcy5pZXRmQGdtYWlsLmNvbT4NClNlbnQ6 IE1vbmRheSwgTWF5IDE4LCAyMDIwIDEyOjMyIFBNDQpUbzogTGluZGEgRHVuYmFyIDxsaW5kYS5k dW5iYXJAZnV0dXJld2VpLmNvbT47IGlwc2VjQGlldGYub3JnIFdHIDxpcHNlY0BpZXRmLm9yZz4N ClN1YmplY3Q6IFJFOiBbSVBzZWNdIElzIHRoZXJlIGFueSBkcmFmdHMgb3IgUkZDcyBvbiBzb2x1 dGlvbnMgdG8gUkZDIDcwMTggQXV0by1EaXNjb3ZlcnkgVlBOIFByb2JsZW0gU3RhdGVtZW50IGFu ZCBSZXF1aXJlbWVudHM/DQoNCkxpbmRhLA0KDQpUaGVyZSB3ZXJlIDQgZHJhZnRzIHdyaXR0ZW4g YmFzZWQgb24gdGhlIGV4aXN0aW5nIHN0YXRlIG9mIGFydCBhdCB0aGF0IHRpbWUuDQoNCldlIGNy ZWF0ZWQgb25lIGFzIEhQIGFuZCBIM0MgYWJvdXQgNiB5ZWFycyBiYWNrLiBDaXNjbyBoYWQgb25l IHRvbyBhbmQgc28gZGlkIG90aGVycy4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1tYW8taXBzZWNtZS1hZC12cG4tcHJvdG9jb2wtMDINCg0KLVZpc2h3YXMNCg0KDQotLS0tLS0t LSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tDQpGcm9tOiBMaW5kYSBEdW5iYXIgPGxpbmRhLmR1 bmJhckBmdXR1cmV3ZWkuY29tPG1haWx0bzpsaW5kYS5kdW5iYXJAZnV0dXJld2VpLmNvbT4+DQpE YXRlOiA1LzE4LzIwIDEwOjEzIEFNIChHTVQtMDg6MDApDQpUbzogImlwc2VjQGlldGYub3JnIFdH PG1haWx0bzppcHNlY0BpZXRmLm9yZyUyMFdHPiIgPGlwc2VjQGlldGYub3JnPG1haWx0bzppcHNl Y0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBbSVBzZWNdIElzIHRoZXJlIGFueSBkcmFmdHMgb3IgUkZD cyBvbiBzb2x1dGlvbnMgdG8gUkZDIDcwMTggQXV0by1EaXNjb3ZlcnkgVlBOIFByb2JsZW0gU3Rh dGVtZW50IGFuZCBSZXF1aXJlbWVudHM/DQoNCldlIGFyZSBleHBlcmllbmNpbmcgdGhlIHByb2Js ZW1zIGRlc2NyaWJlZCBpbiBSRkMgNzAxOCAoQXV0by1EaXNjb3ZlcnkgVlBOIFByb2JsZW0gU3Rh dGVtZW50IGFuZCBSZXF1aXJlbWVudHMpLCBpLmUuIHRoZSAgcHJvYmxlbSBvZiBlbmFibGluZyBh IGxhcmdlIG51bWJlciBvZiBwZWVycyAocHJpbWFyaWx5IEdhdGV3YXkpIHRvIGNvbW11bmljYXRl IGRpcmVjdGx5IHVzaW5nIElQc2VjIHRvIHByb3RlY3QgdGhlIHRyYWZmaWMgYmV0d2VlbiB0aGVt Lg0KDQpJcyB0aGVyZSBhbnkgZHJhZnRzIGRlc2NyaWJpbmcgdGhlIHNvbHV0aW9ucyB0byB0aGUg cHJvYmxlbXMgaWRlbnRpZmllZCBieSBSRkM3MDE4Pw0KDQpUaGFuayB5b3UgdmVyeSBtdWNoLA0K DQpMaW5kYSBEdW5iYXINCg== --_000_SN6PR13MB2334433FD0CFC6F80CFDDF6585B80SN6PR13MB2334namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0K CXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu Ow0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r PSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VmlzaHdhcywgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo YW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHRoZSBsaW5rLiAmbmJzcDsmbmJzcDtUaGUgZHJhZnQgd2Fz IGRhdGVkIGF1ZyAyMDEzLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5X aHkgaXQgZGlkbuKAmXQgbW92ZSBmb3J3YXJkPyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TGlu ZGE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Ux RTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPkZyb206PC9iPiB2aXNod2FzLmlldGYgJmx0O3Zpc2h3YXMuaWV0ZkBnbWFpbC5jb20m Z3Q7IDxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE1heSAxOCwgMjAyMCAxMjozMiBQTTxicj4N CjxiPlRvOjwvYj4gTGluZGEgRHVuYmFyICZsdDtsaW5kYS5kdW5iYXJAZnV0dXJld2VpLmNvbSZn dDs7IGlwc2VjQGlldGYub3JnIFdHICZsdDtpcHNlY0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUkU6IFtJUHNlY10gSXMgdGhlcmUgYW55IGRyYWZ0cyBvciBSRkNzIG9uIHNvbHV0 aW9ucyB0byBSRkMgNzAxOCBBdXRvLURpc2NvdmVyeSBWUE4gUHJvYmxlbSBTdGF0ZW1lbnQgYW5k IFJlcXVpcmVtZW50cz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5MaW5kYSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhlcmUgd2VyZSA0IGRyYWZ0cyB3cml0dGVuIGJhc2VkIG9uIHRoZSBleGlzdGlu ZyBzdGF0ZSBvZiBhcnQgYXQgdGhhdCB0aW1lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBjcmVhdGVkIG9uZSBhcyBIUCBhbmQgSDNDIGFi b3V0IDYgeWVhcnMgYmFjay4gQ2lzY28gaGFkIG9uZSB0b28gYW5kIHNvIGRpZCBvdGhlcnMuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWFvLWlwc2VjbWUtYWQtdnBuLXBy b3RvY29sLTAyIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWFvLWlwc2VjbWUt YWQtdnBuLXByb3RvY29sLTAyPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4tVmlzaHdhczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPkZyb206IExpbmRhIER1bmJhciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxpbmRhLmR1 bmJhckBmdXR1cmV3ZWkuY29tIj5saW5kYS5kdW5iYXJAZnV0dXJld2VpLmNvbTwvYT4mZ3Q7DQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkRhdGU6IDUvMTgvMjAgMTA6MTMgQU0gKEdNVC0w ODowMCkNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VG86ICZxdW90OzxhIGhyZWY9Im1h aWx0bzppcHNlY0BpZXRmLm9yZyUyMFdHIj5pcHNlY0BpZXRmLm9yZyBXRzwvYT4mcXVvdDsgJmx0 OzxhIGhyZWY9Im1haWx0bzppcHNlY0BpZXRmLm9yZyI+aXBzZWNAaWV0Zi5vcmc8L2E+Jmd0Ow0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5TdWJqZWN0OiBbSVBzZWNdIElzIHRoZXJlIGFu eSBkcmFmdHMgb3IgUkZDcyBvbiBzb2x1dGlvbnMgdG8gUkZDIDcwMTggQXV0by1EaXNjb3Zlcnkg VlBOIFByb2JsZW0gU3RhdGVtZW50IGFuZCBSZXF1aXJlbWVudHM/DQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XZSBhcmUgZXhwZXJpZW5jaW5nIHRoZSBw cm9ibGVtcyBkZXNjcmliZWQgaW4gUkZDIDcwMTggKEF1dG8tRGlzY292ZXJ5IFZQTiBQcm9ibGVt IFN0YXRlbWVudCBhbmQgUmVxdWlyZW1lbnRzKSwgaS5lLiB0aGUgJm5ic3A7cHJvYmxlbSBvZiBl bmFibGluZyBhIGxhcmdlIG51bWJlciBvZiBwZWVycyAocHJpbWFyaWx5DQogR2F0ZXdheSkgdG8g Y29tbXVuaWNhdGUgZGlyZWN0bHkgdXNpbmcgSVBzZWMgdG8gcHJvdGVjdCB0aGUgdHJhZmZpYyBi ZXR3ZWVuIHRoZW0uDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklzIHRoZXJlIGFueSBk cmFmdHMgZGVzY3JpYmluZyB0aGUgc29sdXRpb25zIHRvIHRoZSBwcm9ibGVtcyBpZGVudGlmaWVk IGJ5IFJGQzcwMTg/DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYW5rIHlvdSB2ZXJ5 IG11Y2gsDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkxpbmRhIER1bmJhcjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_SN6PR13MB2334433FD0CFC6F80CFDDF6585B80SN6PR13MB2334namp_-- From nobody Mon May 18 11:52:26 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 779753A0D8E for ; Mon, 18 May 2020 11:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, 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 Tgr68jzZpQbW for ; Mon, 18 May 2020 11:52:20 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CD253A0D89 for ; Mon, 18 May 2020 11:52:19 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 49Qp6911T3zDkG; Mon, 18 May 2020 20:52:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1589827937; bh=b1fME2jAkRZri40Zjab3FZVD925I1m36VzSJXoL4UG8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=lHso8D1gQejmUpyn974Yh0xFm3o4n/+e1ngS1/zA7obPRPtWzU6s8O+U0aOHO/kiB yxFmo7BSRVdySzCzxslBwHIaF0YMx1/0s9nu9Wjuy2X5h5TUtmaSl+t0jE0TOVlUS1 EBsbkbhrsdygt2MQyAvI+MzCLRxXqo/Rl8xbPyNM= 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 CGrfV3iKUnK5; Mon, 18 May 2020 20:52:15 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 18 May 2020 20:52:15 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id AA4026020D59; Mon, 18 May 2020 14:52:14 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A6E2D65E5F; Mon, 18 May 2020 14:52:14 -0400 (EDT) Date: Mon, 18 May 2020 14:52:14 -0400 (EDT) From: Paul Wouters To: Linda Dunbar cc: "ipsec@ietf.org WG" In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [IPsec] Is there any drafts or RFCs on solutions to RFC 7018 Auto-Discovery VPN Problem Statement and Requirements? 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, 18 May 2020 18:52:25 -0000 On Mon, 18 May 2020, Linda Dunbar wrote: > We are experiencing the problems described in RFC 7018 (Auto-Discovery VPN Problem Statement and Requirements), i.e. the  problem of enabling a large number of peers > (primarily Gateway) to communicate directly using IPsec to protect the traffic between them. unfortunately, standarization failed because vendors wanted their own solution standarized, and the WG didn't want multiple standards, so it decided to do none. For libreswan, we do "Opportunistic IPsec", which is basically "just try host-to-host IPsec, fail to either clear or block depending on policy". We also have a "you can do auth-null for passive attack protection" in one or both directions" and a migration path from there to fully authenticated IPsec. Authentication based on a shared CA or DNSSEC. These are packet trigger based solutions. It works well for most meshes, and requires no proprietary or new standards. The only two non-standard parts are that when using certificates, we allow requiring an addictional call to match the IKE ID with certificate SAN in the DNS (to prevent a compromised node from pretending to be another node in the mesh) and we have one non-standarized payload to signify we can do auth-null as well as authenticated IPsec, which we hopefully can retire once this document gets adopted / implemented: https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-auth-announce/ > Is there any drafts describing the solutions to the problems identified by RFC7018? There might be the old drafts of the autovpn candidates, but as that is all incompatible and/or proprietary, and mostly from before my time, I have not looked at those solutions much. One issue I have with Cisco solutions, is that they now prefer to wrap everything in GRE, which isn't the best from a security point of view. NHRP (using opennhrp) seems somewhat popular too? Paul From nobody Tue May 19 10:36:44 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5AF3A0D9E for ; Tue, 19 May 2020 10:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCcZ272fN9VH for ; Tue, 19 May 2020 10:36:40 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A48353A0D9C for ; Tue, 19 May 2020 10:36:40 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 49RNNP0202zF4P for ; Tue, 19 May 2020 19:36:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1589909797; bh=Bzs/Tr2OURPb8a5gRHYt3qa+bhrYbeldmB+/bb0aw5E=; h=Date:From:To:Subject; b=XXTB6At/PylPqZuuszb2U3dNpfDeAFN4Igjy8bKo7bP7aYDJOkQxJC32HUFjI7cMg sf4fowJwi57hZvf66M5JCfO3aEy6oupdCOri1pT4aphfEENsFodo2AmyUfQq5z9Sm7 HFT9leL0VKyZrS+LMor/zW6yisBNhiZaPHGqRT80= 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 CeX_NEGdcgVX for ; Tue, 19 May 2020 19:36:35 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Tue, 19 May 2020 19:36:35 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id BDC11601EBCA; Tue, 19 May 2020 13:36:34 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id BA26665E5F for ; Tue, 19 May 2020 13:36:34 -0400 (EDT) Date: Tue, 19 May 2020 13:36:34 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [IPsec] draft-ietf-ipsecme-qr-ikev2 has been in RFC Editor queue for 123 days? 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, 19 May 2020 17:36:43 -0000 What is going on with draft-ietf-ipsecme-qr-ikev2 ? It seems stuck in the RFC Editor queue ? Can the WG chairs or AD see about getting this unstuck and out the door? Paul From nobody Tue May 19 10:49:08 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7FB3A1029 for ; Tue, 19 May 2020 10:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhUZqu75A2Dq for ; Tue, 19 May 2020 10:49:04 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87F403A102B for ; Tue, 19 May 2020 10:49:04 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 04JHmx0l006898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 19 May 2020 13:49:02 -0400 Date: Tue, 19 May 2020 10:48:59 -0700 From: Benjamin Kaduk To: Paul Wouters Cc: "ipsec@ietf.org WG" Message-ID: <20200519174859.GO58497@kduck.mit.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [IPsec] draft-ietf-ipsecme-qr-ikev2 has been in RFC Editor queue for 123 days? 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, 19 May 2020 17:49:07 -0000 On Tue, May 19, 2020 at 01:36:34PM -0400, Paul Wouters wrote: > > What is going on with draft-ietf-ipsecme-qr-ikev2 ? > > It seems stuck in the RFC Editor queue ? > > Can the WG chairs or AD see about getting this unstuck and out the door? There's a giant backlog in the "RFC-EDITOR" state (see https://www.rfc-editor.org/current_queue.php); my understanding is that this accumulated in the gap period between Heather and John, and there's not really a way to make the overall queue move faster. It is possible for the IESG to request expedited processing of a specific document, if needed -- is there a timely need for an RFC number for this document that we should do so? Thanks, Ben From nobody Tue May 19 11:47:35 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 013FB3A0D41 for ; Tue, 19 May 2020 11:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XF013m822ieR for ; Tue, 19 May 2020 11:47:31 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41CA53A0D3F for ; Tue, 19 May 2020 11:47:30 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 49RPy907nvzF6j; Tue, 19 May 2020 20:47:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1589914049; bh=esyaHzZmFPPLkKSUB53eukoKiEXki8hA1Y7DUm5KDiU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=pb3ow3Kx7axaixyxDz882fyR28k8KuHcF30NT3UFgEH3XSNtE3rJPOsWoVk7HEVc/ gcSboN+MjOGV4unvKviFUJ8LDTc/xc14G/wRrl9F+N6FRQgG9DHcFWh96XUAY9jBD/ VStaB9K+foE6HSQpxPORaRtS2DSdVd0rjJORtPX4= 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 gpCUzCWQ6QIS; Tue, 19 May 2020 20:47:26 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 19 May 2020 20:47:26 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 05EC3601EBCA; Tue, 19 May 2020 14:47:26 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 021BF65E64; Tue, 19 May 2020 14:47:26 -0400 (EDT) Date: Tue, 19 May 2020 14:47:25 -0400 (EDT) From: Paul Wouters To: Benjamin Kaduk cc: "ipsec@ietf.org WG" In-Reply-To: <20200519174859.GO58497@kduck.mit.edu> Message-ID: References: <20200519174859.GO58497@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] draft-ietf-ipsecme-qr-ikev2 has been in RFC Editor queue for 123 days? 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, 19 May 2020 18:47:33 -0000 On Tue, 19 May 2020, Benjamin Kaduk wrote: >> Can the WG chairs or AD see about getting this unstuck and out the door? > > There's a giant backlog in the "RFC-EDITOR" state (see > https://www.rfc-editor.org/current_queue.php); my understanding is that > this accumulated in the gap period between Heather and John, and there's > not really a way to make the overall queue move faster. Oh, I see. > It is possible for > the IESG to request expedited processing of a specific document, if needed > -- is there a timely need for an RFC number for this document that we > should do so? Ahh, no there is no reason for an expedited processing. Paul From nobody Tue May 19 12:01:26 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFEA63A0FBF for ; Tue, 19 May 2020 12:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lO8ZODp7Qlyh for ; Tue, 19 May 2020 12:01:15 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 D274F3A1050 for ; Tue, 19 May 2020 12:01:06 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id g4so931707ljl.2 for ; Tue, 19 May 2020 12:01:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=ZHENPm6kx8zcClYilumLIljUzGJvevnPyuu3CBQE2xE=; b=IN+RnxlfgkPQ0vztU4+4DQg1fAyvIqFcNaVu1r54bgNirJCrMT4K4+bIHuGgGhjHYg ePQ/EKWvhIsWufkNEIjEaZvw2Bf/4SxztMPjpjysESZMPoPqwiP4jqEQKg6HUhFALHhC 7cbsE7rCkFWycUaIjfu2+z8V5ZOXOvUorIrXsyEVHv1FbQCZk0ZSrtSx3XH8xpsLOwjO hrlvdyswjAZU5OTYbdgIG8afP2gKuCaQAOZPHltfgplj5HpxqhgNY2UUY+Iefb/0aoO+ dbJbaUko8NmKRYR176HPs9LFZ4VRYFmogsRNT1DA2Ufk20Iu9abKXcR4cMyTL8R9C+Xt Xg0g== 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=ZHENPm6kx8zcClYilumLIljUzGJvevnPyuu3CBQE2xE=; b=pZJoS4+9cv8ElNG4v6wya7nTHFCUpR+Jk/PVSrRrjhwKw478HrKtwblgIwviYbYzqz bRJiWjfDSmr7fIesuVe9sHW76d9affWx9ELuzgMG6D0WC2twIoutOFqyqPuVZ+KRiTEz ECNSg6M6+jt3Dedy8s7rchsWfwja876ATWSibZK5WeJNHgEkHKKYVcw91xUTJ0a3mgTK X2pPitMr7Ma6c7HOVx9eq6W9VIAlDyMPbFHexksAWBx5EGnL9toPy6w5Y22OeuVHUUO+ l7T1sq0F7zeHnxvDZjkp9bPNpnyqyDw9bf84k1+mYHBxxGeoDme1TV9KSKuYcrLM9DiF UZ+w== X-Gm-Message-State: AOAM5319PWM6SYypn3w1F5DYsJ8FL7mP5q+gRmXshNtUydylDxnsUP80 93eHj2sy/sZvlmL6DrXGGEYTVznd X-Google-Smtp-Source: ABdhPJyCXy4WmwBOy4/9f6Expv+1pZlKiaVrKObaYT4AoukfxL2CDhKS9lPdAkuGJ2lAWdESUPMODw== X-Received: by 2002:a2e:2a82:: with SMTP id q124mr523402ljq.155.1589914864520; Tue, 19 May 2020 12:01:04 -0700 (PDT) Received: from chichi (95-27-147-103.broadband.corbina.ru. [95.27.147.103]) by smtp.gmail.com with ESMTPSA id r13sm218816ljh.66.2020.05.19.12.01.02 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 May 2020 12:01:03 -0700 (PDT) From: "Valery Smyslov" To: "'Paul Wouters'" , "'Benjamin Kaduk'" Cc: References: <20200519174859.GO58497@kduck.mit.edu> In-Reply-To: Date: Tue, 19 May 2020 22:00:58 +0300 Message-ID: <00f801d62e0f$d5c39480$814abd80$@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: AQJuXPI+9tAsvPeTRNDnxhmXCAeimwH4SZnPAUc1J9WnZWctEA== Content-Language: ru Archived-At: Subject: Re: [IPsec] draft-ietf-ipsecme-qr-ikev2 has been in RFC Editor queue for 123 days? 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, 19 May 2020 19:01:24 -0000 Hi, > On Tue, 19 May 2020, Benjamin Kaduk wrote: > > >> Can the WG chairs or AD see about getting this unstuck and out the > door? > > > > There's a giant backlog in the "RFC-EDITOR" state (see > > https://www.rfc-editor.org/current_queue.php); my understanding is > that > > this accumulated in the gap period between Heather and John, and > there's > > not really a way to make the overall queue move faster. > > Oh, I see. Ben, thank you for the explanation. The draft has already endured unfortunate delay in the WG, this one is just another unfortunate one. That is that. > > It is possible for > > the IESG to request expedited processing of a specific document, if > needed > > -- is there a timely need for an RFC number for this document that we > > should do so? > > Ahh, no there is no reason for an expedited processing. I agree with Paul (with co-author hat on). The code-points are already allocated and several vendors have implemented the draft. The only thing left is an RFC number to refer to, but we can wait for it. Regards, Valery. > Paul > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue May 19 20:07:54 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB9353A094C for ; Tue, 19 May 2020 20:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBGO6g-GOpqx for ; Tue, 19 May 2020 20:07:50 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EAF53A094A for ; Tue, 19 May 2020 20:07:49 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 04K37haA007505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 19 May 2020 23:07:45 -0400 Date: Tue, 19 May 2020 20:07:43 -0700 From: Benjamin Kaduk To: Valery Smyslov Cc: "'Paul Wouters'" , ipsec@ietf.org Message-ID: <20200520030743.GT58497@kduck.mit.edu> References: <20200519174859.GO58497@kduck.mit.edu> <00f801d62e0f$d5c39480$814abd80$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00f801d62e0f$d5c39480$814abd80$@gmail.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [IPsec] draft-ietf-ipsecme-qr-ikev2 has been in RFC Editor queue for 123 days? 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, 20 May 2020 03:07:52 -0000 On Tue, May 19, 2020 at 10:00:58PM +0300, Valery Smyslov wrote: > Hi, > > > On Tue, 19 May 2020, Benjamin Kaduk wrote: > > > > >> Can the WG chairs or AD see about getting this unstuck and out the > > door? > > > > > > There's a giant backlog in the "RFC-EDITOR" state (see > > > https://www.rfc-editor.org/current_queue.php); my understanding is > > that > > > this accumulated in the gap period between Heather and John, and > > there's > > > not really a way to make the overall queue move faster. > > > > Oh, I see. > > Ben, thank you for the explanation. The draft has already > endured unfortunate delay in the WG, this one is just another unfortunate > one. > That is that. > > > > It is possible for > > > the IESG to request expedited processing of a specific document, if > > needed > > > -- is there a timely need for an RFC number for this document that we > > > should do so? > > > > Ahh, no there is no reason for an expedited processing. > > I agree with Paul (with co-author hat on). > The code-points are already allocated and several vendors have implemented > the draft. > The only thing left is an RFC number to refer to, but we can wait for it. Amusingly enough, it just entered AUTH48 this evening (and thus, provisionally has an RFC number assigned). -Ben From nobody Wed May 20 10:34:19 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D303A0CE0 for ; Wed, 20 May 2020 10:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 hkA5igEi1uLr for ; Wed, 20 May 2020 10:34:08 -0700 (PDT) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2133.outbound.protection.outlook.com [40.107.220.133]) (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 A6FC13A0CC7 for ; Wed, 20 May 2020 10:34:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KMESOSes6P1Jdr8dmXrjfE7D6yLRvYQjwCBG/9eOAftmwP970V//+bsg+9WMV0lUusp4hvBpriaG6s0d8Jx1D9TDvPzpE1XOtHiKG5c0hY1iULJnnxGLwc/Ehpa2hu6pVh+RPMwAQ2RMIip32FgoyMyR9Qe62nrS573kBqVXe90pNyTdMcm7uAHkCVSUrV33XO/nfmeAmwLB/fhDm/3Jtc2ebGcm/r3bg9o10RFuBzwpCoPcvl0nK7dgTQ5GI4kYVf6I7Ci6ICliD3CLxdtRit9PDuzsX4cs+A2L8xHj2+p2qKDUj1G7vwEeFEkDsRUZ9I58v8pHDNfROwtghq54KA== 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=xf59XHpT8wGLobxoIjWkk77PX5EqibvsRvJhU+8ydFo=; b=il9edsbrATLDCn0DUzRrCIjMbJ9siO8QFjQWgAxVv+VLthhL6mPR8opAT8CBwtWveOCpmnO49IdcTwe70C07I2h73ztI2It6TGXRBrnp6HBcQlumNVNGEY9h8j3RapxCyKXzwxpB5FtuPqbR0mQLDGcCa6ItPr54IBYmbV9snopSlgcRseGJRQ1gO2Jgzwe3gahB1dkLCXKmUCGqvwSdR1qlbrXChwS81f1RXa+4E+vTqlg3By6G6alwsoRXzVBTavePsK+lm7v3HylYN32YWXQDU2q6BU/DZ2jRmfLeDotAoecFrcBWA80bASrD0YAx3ucgkc1gPW2fhyJIluYUQg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xf59XHpT8wGLobxoIjWkk77PX5EqibvsRvJhU+8ydFo=; b=HD3B6/t0KzukF7tMn4NBSGYyVtY46FmowiuPZ9yudeDD8PSgrc5FXUYpzas86Sa9woEsACSYhxYkp36/G6HX7LybZ6Ay3RARtYCXmoxfY64p3llosdagpR3GjFxqQ30Q5NqbVF/xicqyTcCJ2nhnqywsITu8q9onURChQOI60Aw= Received: from SN6PR13MB2334.namprd13.prod.outlook.com (2603:10b6:805:55::16) by SN6PR13MB2365.namprd13.prod.outlook.com (2603:10b6:805:5a::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.12; Wed, 20 May 2020 17:34:01 +0000 Received: from SN6PR13MB2334.namprd13.prod.outlook.com ([fe80::7813:cef6:bbde:1970]) by SN6PR13MB2334.namprd13.prod.outlook.com ([fe80::7813:cef6:bbde:1970%5]) with mapi id 15.20.3021.019; Wed, 20 May 2020 17:34:01 +0000 From: Linda Dunbar To: Paul Wouters CC: "ipsec@ietf.org WG" Thread-Topic: [IPsec] Is there any drafts or RFCs on solutions to RFC 7018 Auto-Discovery VPN Problem Statement and Requirements? Thread-Index: AdYtNxBY7rsPEhAvSSaEorpChh0soAADmGAAAGHB/1A= Date: Wed, 20 May 2020 17:34:00 +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: nohats.ca; dkim=none (message not signed) header.d=none;nohats.ca; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [72.180.73.64] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c56c9662-440c-4fc8-7a42-08d7fce3fbed x-ms-traffictypediagnostic: SN6PR13MB2365: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 04097B7F7F x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: IQDYrCOR5OCCOEf3yQx3Pe2CbhET5gs+GUoWp9iZJ5lgCI61PwGxjZfxx8Y8T0F+EXG0ukDvQtSPu9aGeGAR9TnGLj06HCYjF5DIiKXwaK1DQ3EhAexmyY5+zqsOcj6IFyOilL/CoBcId+Avi/dG4Oi2l6Qf6fCjv+eqouX50q3zVSaInES+fer1gV7m7cmemtzHLzN5XCuZbNz53M9u4JqcmqMU2JGq2+ngMDIBHP8+2CJt1md7D9BpniEZyjAAQWpnzxAeSMVHlPaqbswK81W6B4dhcgHgcFuFNTYGKDDunpfEyqAH+1mJsx48kXRF740d0J4bhnzA3sGcvPcMJEolity/fTZ5BTmCiUg6obnLbFDNEZNzqi8TGucGlCMrP12IY23oY6tsG+MBnnBA7g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR13MB2334.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(396003)(39840400004)(366004)(136003)(52536014)(5660300002)(26005)(8936002)(71200400001)(45080400002)(316002)(186003)(66556008)(966005)(478600001)(66476007)(66446008)(86362001)(64756008)(66946007)(76116006)(33656002)(53546011)(6506007)(55016002)(8676002)(44832011)(2906002)(6916009)(9686003)(7696005)(4326008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 4GrY+Kqe3aimxVB/+o2MuI5tGn2OX1CFznDVALu4+soVlYRqOMW+PwHJILl53Q6ULMzsNYuRRNjdBhE4qTdYoj/aQE1PUYOR7+b+g8MdMgqL8u1D9E94ZYCc87cRisrRQXvvUFKVOEAUTCdrA9QrVlC7YJ+BHHdtxiHp/rjkbWgNw/2gHbbMuheT8RvTEb3qeJfDa2s19Ic4xwcUeeo3+FFkJnFe52plLrgXXbN9ZR+0+HSKRULSptw92pFtHYbU20mmr6NKh1naVwS5igCOKa5P5icSKJ+lNDHa+g2N228Az/mZqrawJaYn0K71CXoPm7lutX53QrBzt4IiPw1NDIQoFghuWtz7p7//QtRziVzKhFhtmO/oS0ncHQIE7cLSdk4pRbAtiqwXgFxna8rFFWBZ19NFKNMTVPPGCH6Fbf4ZT6u3BUQoKlGJzzr/QzpGYPGGlHSAbt6rAPRV/aL/EpryzoTh8x50Wpt3d0uNaqc= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-Network-Message-Id: c56c9662-440c-4fc8-7a42-08d7fce3fbed X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2020 17:34:00.6787 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 1u7LdX7yqTbKasMnTThuZg22tqooWixDhxPfDu2PNTwZkvomLurlnVfMOs+xK8ayvkzYbi9k+1A3y5vx2NN7ww== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR13MB2365 Archived-At: Subject: Re: [IPsec] Is there any drafts or RFCs on solutions to RFC 7018 Auto-Discovery VPN Problem Statement and Requirements? 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, 20 May 2020 17:34:17 -0000 Paul,=20 Thank you very much for the detailed explanation.=20 What is " you can do auth-null for passive attack protection"? does it mea= n "NO Authentication"?=20 If two peers have shared CA, does it mean there is no need for Authenticati= on?=20 Thanks, Linda -----Original Message----- From: Paul Wouters =20 Sent: Monday, May 18, 2020 1:52 PM To: Linda Dunbar Cc: ipsec@ietf.org WG Subject: Re: [IPsec] Is there any drafts or RFCs on solutions to RFC 7018 A= uto-Discovery VPN Problem Statement and Requirements? On Mon, 18 May 2020, Linda Dunbar wrote: > We are experiencing the problems described in RFC 7018 (Auto-Discovery=20 > VPN Problem Statement and Requirements), i.e. the =A0problem of enabling = a large number of peers (primarily Gateway) to communicate directly using I= Psec to protect the traffic between them. unfortunately, standarization failed because vendors wanted their own solut= ion standarized, and the WG didn't want multiple standards, so it decided t= o do none. For libreswan, we do "Opportunistic IPsec", which is basically "just try ho= st-to-host IPsec, fail to either clear or block depending on policy". We also have a "you can do auth-null for passive attack protection" in one or both directions" and a migration path from there to fully authent= icated IPsec. Authentication based on a shared CA or DNSSEC. These are packet trigger based solutions. It works well for most meshes, and requires no proprietary or new standards= . The only two non-standard parts are that when using certificates, we allo= w requiring an addictional call to match the IKE ID with certificate SAN in= the DNS (to prevent a compromised node from pretending to be another node = in the mesh) and we have one non-standarized payload to signify we can do a= uth-null as well as authenticated IPsec, which we hopefully can retire once= this document gets adopted / implemented: https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fdraft-smyslov-ipsecme-ikev2-auth-announce%2F&data= =3D02%7C01%7Clinda.dunbar%40futurewei.com%7C1a29cf55dab94e9d7e3b08d7fb5c975= 4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637254247407162655&sdata= =3D8%2B%2FxIlUKattjsk957tdKCXR137ntP8WZ5YcnNsBzBD4%3D&reserved=3D0 > Is there any drafts describing the solutions to the problems identified b= y RFC7018? There might be the old drafts of the autovpn candidates, but as that is all= incompatible and/or proprietary, and mostly from before my time, I have no= t looked at those solutions much. One issue I have with Cisco solutions, is that they now prefer to wrap ever= ything in GRE, which isn't the best from a security point of view. NHRP (using opennhrp) seems somewhat popular too? Paul From nobody Sun May 24 09:24:05 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F6B3A0B81 for ; Sun, 24 May 2020 09:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgotbQqTNWwb for ; Sun, 24 May 2020 09:24:02 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B85C3A0B7C for ; Sun, 24 May 2020 09:24:02 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id z13so8591702ljn.7 for ; Sun, 24 May 2020 09:24:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=Id+gH9YJiq3O4cFa+Fmww8JBxExcz3V1PGOTSQ9E47o=; b=CCEOStpmqKbMtPmZp7FyIztUSLe7LuRDmlil8Q2UTWQvubiTUUE7NNxDWJA84GAp4y te/ezIfFvCPzLPWoJt2TdrgNDgNLUHMLRzTzlpXnil4sUzKwEIEmJfLiF9wI2kz5rDdo loz6C5QwTtBWNcvd1A8laqGC/uI9mdu1oopfUliy6sOGiGS1hQ0WBOwODZj+RUbCiSG0 Lu6QWq7cf8b1nW/r4MS9qh9nzMMjhL9BHIRATg7s9rqWBTFgO9ClKFqi9rmb4jIC/1X3 ahPeWoLUADKhN/12Xoonz1fiLTelWcSiKRU7TPkhtr4hxuuuHNEJHVbbQ+5q6yeS9iI8 Z7FA== 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=Id+gH9YJiq3O4cFa+Fmww8JBxExcz3V1PGOTSQ9E47o=; b=g9hRY0UI5vMhsxXVRii82rOFpe1lUjS8RO1bgf8vcv7KNsu+IW6SzwmLcZrRPPW/9b vv1oi+x3FhblBrcXMkxOUWyu1HLk6aEhSxmHxvUFC/peBcaFdj9fKZiRtvj5AMHPdoku CWsKZp57OtXJB1S9goJiSV2Q5/HR4KXl/9YEhnNpSXSJOq90/PLZjwO9VwhqFZ+Sd3H8 HxVI0l+8YwKlGnuLlghTbmwP0GaCHl4G8n2Jj3MTuFRoDuj7CdWVsn/w3+zD0QP81Smw pBH64FvV08GkO3fYxli/weOIeoGiqFzD8PXtkb9QeDhAhmNtkekE2uZAD3cZQfzPj1wA yJvg== X-Gm-Message-State: AOAM530f5luE60hfH1hDQJbExdOwpUq0XtDfB4JeYGLTjylhA7mN3b4n jg02m8D2XDqAHteNO//8z/YdvgAN X-Google-Smtp-Source: ABdhPJyQcA+dI1CmWDCRkQbKALpTs/4ww0oadUXvTzp+0cuHo3MhiWuKjlbPjv5F+5PsFu2LMullag== X-Received: by 2002:a2e:6a11:: with SMTP id f17mr1727777ljc.328.1590337439960; Sun, 24 May 2020 09:23:59 -0700 (PDT) Received: from chichi (95-27-147-103.broadband.corbina.ru. [95.27.147.103]) by smtp.gmail.com with ESMTPSA id f9sm4293180ljf.99.2020.05.24.09.23.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 May 2020 09:23:58 -0700 (PDT) From: "Valery Smyslov" To: "'Linda Dunbar'" , "'Paul Wouters'" Cc: References: In-Reply-To: Date: Sun, 24 May 2020 19:23:58 +0300 Message-ID: <002d01d631e7$bae0cf30$30a26d90$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFcG9V+LNVx37zPeZAOazGVwjuEIAGD/LLMAlqpkfmpjKEyAA== Content-Language: ru Archived-At: Subject: Re: [IPsec] Is there any drafts or RFCs on solutions to RFC 7018 Auto-Discovery VPN Problem Statement and Requirements? 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, 24 May 2020 16:24:04 -0000 Hi Linda, > Paul, >=20 > Thank you very much for the detailed explanation. >=20 > What is " you can do auth-null for passive attack protection"? does = it mean > "NO Authentication"? Yes, NULL authentication method in IKEv2 provides no authentication. It is intended to be used in cases where no trust relationship exists between peers or where authentication is=20 performed by other means. It only protects against passive attacks. > If two peers have shared CA, does it mean there is no need for > Authentication? If peers have shared CA they can mutually authenticate themselves and there is no need for NULL authentication in this case. Hope this helps, Valery. > Thanks, Linda >=20 >=20 >=20 > -----Original Message----- > From: Paul Wouters > Sent: Monday, May 18, 2020 1:52 PM > To: Linda Dunbar > Cc: ipsec@ietf.org WG > Subject: Re: [IPsec] Is there any drafts or RFCs on solutions to RFC = 7018 > Auto-Discovery VPN Problem Statement and Requirements? >=20 > On Mon, 18 May 2020, Linda Dunbar wrote: >=20 > > We are experiencing the problems described in RFC 7018 = (Auto-Discovery > > VPN Problem Statement and Requirements), i.e. the =9Aproblem of = enabling > a large number of peers (primarily Gateway) to communicate directly = using > IPsec to protect the traffic between them. >=20 > unfortunately, standarization failed because vendors wanted their own > solution standarized, and the WG didn't want multiple standards, so it > decided to do none. >=20 > For libreswan, we do "Opportunistic IPsec", which is basically "just = try host- > to-host IPsec, fail to either clear or block depending on policy". > We also have a "you can do auth-null for passive attack protection" > in one or both directions" and a migration path from there to fully > authenticated IPsec. Authentication based on a shared CA or DNSSEC. >=20 > These are packet trigger based solutions. >=20 > It works well for most meshes, and requires no proprietary or new > standards.. The only two non-standard parts are that when using > certificates, we allow requiring an addictional call to match the IKE = ID with > certificate SAN in the DNS (to prevent a compromised node from = pretending > to be another node in the mesh) and we have one non-standarized = payload > to signify we can do auth-null as well as authenticated IPsec, which = we > hopefully can retire once this document gets adopted / implemented: >=20 > = https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdat > atracker.ietf.org%2Fdoc%2Fdraft-smyslov-ipsecme-ikev2-auth- > announce%2F&data=3D02%7C01%7Clinda.dunbar%40futurewei.com%7C > 1a29cf55dab94e9d7e3b08d7fb5c9754%7C0fee8ff2a3b240189c753a1d5591f > edc%7C1%7C0%7C637254247407162655&sdata=3D8%2B%2FxIlUKattjsk9 > 57tdKCXR137ntP8WZ5YcnNsBzBD4%3D&reserved=3D0 >=20 > > Is there any drafts describing the solutions to the problems = identified by > RFC7018? >=20 > There might be the old drafts of the autovpn candidates, but as that = is all > incompatible and/or proprietary, and mostly from before my time, I = have > not looked at those solutions much. >=20 > One issue I have with Cisco solutions, is that they now prefer to wrap > everything in GRE, which isn't the best from a security point of view. >=20 > NHRP (using opennhrp) seems somewhat popular too? >=20 > Paul >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon May 25 07:09:03 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E279F3A0C1B for ; Mon, 25 May 2020 07:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 frvl_Q0P7Cf9 for ; Mon, 25 May 2020 07:08:44 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 BF46B3A0C62 for ; Mon, 25 May 2020 07:08:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 3FEEF62156 for ; Mon, 25 May 2020 10:08:42 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9ynMtvycO3J9 for ; Mon, 25 May 2020 10:08:37 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 8476E6213A for ; Mon, 25 May 2020 10:08:37 -0400 (EDT) To: ipsec@ietf.org From: Robert Moskowitz Message-ID: <3980213d-88a2-0787-a9b2-3e41cd5d90ca@htt-consult.com> Date: Mon, 25 May 2020 10:08:17 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [IPsec] Can selected IPv6 Headers be part of Authenticated Data with ESP-GCM? 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, 25 May 2020 14:08:47 -0000 I have an interesting use case for a new IPv6 header that MAY be secure within the ESP payload, or MAY be exposed for inroute processing, but MUST be protected (authenticated data). My cursory review is not showing this is currently supported. Is it, our would I need to define a variant of the AES-GCM mode? Thanks From nobody Mon May 25 09:47:49 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B39C3A0DBB for ; Mon, 25 May 2020 09:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.44 X-Spam-Level: X-Spam-Status: No, score=-0.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, 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 HC5_EPH9hCo6 for ; Mon, 25 May 2020 09:47:42 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [209.87.249.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 757543A0DB9 for ; Mon, 25 May 2020 09:47:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 86C2B38A48; Mon, 25 May 2020 12:45:23 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WOsdN-yo2mHE; Mon, 25 May 2020 12:45:22 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 3121B38A3B; Mon, 25 May 2020 12:45:22 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 57EF04BE; Mon, 25 May 2020 12:47:37 -0400 (EDT) From: Michael Richardson To: Robert Moskowitz cc: ipsec@ietf.org In-Reply-To: <3980213d-88a2-0787-a9b2-3e41cd5d90ca@htt-consult.com> References: <3980213d-88a2-0787-a9b2-3e41cd5d90ca@htt-consult.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] Can selected IPv6 Headers be part of Authenticated Data with ESP-GCM? 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, 25 May 2020 16:47:46 -0000 --=-=-= Content-Type: text/plain Robert Moskowitz wrote: > I have an interesting use case for a new IPv6 header that MAY be secure > within the ESP payload, or MAY be exposed for inroute processing, but MUST be > protected (authenticated data). That's not the ESP model. ESP only protects something inside/after it. AH did what you wanted. Sorta. I suggest you put two copies of the header, or you make one copy an implicit property of the SA (a la BEET mode) if need the packets to "emerge" with that header and you don't want to spend bytes. It's obviously mutable in-transit. I don't think it matters what cipher you use, although I can imagine trying to bork this issue via some super-specific custom thing. > My cursory review is not showing this is currently supported. > Is it, our would I need to define a variant of the AES-GCM mode? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl7L9qkACgkQgItw+93Q 3WXDoQf/f90wNMuLp2sEZ/WAS+90i8blfuaYCgxNg9POQSW3NLHkDeENy/MuYoME cAJzi3LfFtL1cLtu0Z1ZOBDMQPGAsg4TF1IOTNvnX8VQYYsvDc2LbapX8q32rAj4 fiHCOVhE7DH1vey04dYEAgD1r8D8dS2XCO9rIw/MgW25egSLQhF25M1dA2xjtfLn +gsj3jBnJ8wUYD/8ajJ5afRzTL1u2hQ9hlTlPUbRoFT5SuMqa88egaGi3sPmFxgG fBKd44Mr4SMBhjS8urkM9stsNRBtwsixy9yO+5NTxiWohnT4VFbCrj7WQOe+pnjw Jej3t3zEEnBk8CA400La6CpJJwBLjQ== =vS0H -----END PGP SIGNATURE----- --=-=-=--