From nobody Tue Apr 7 08:06:01 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 39B473A0598 for ; Tue, 7 Apr 2020 08:05:52 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 4-i6RLgU0rHx for ; Tue, 7 Apr 2020 08:05:50 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 516233A0B96 for ; Tue, 7 Apr 2020 08:05:48 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 48xW1k6btDzCrQ9; Tue, 7 Apr 2020 17:05:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1586271946; bh=OTgpA0g1dpNsND1JgwW6LlltYjv5BLUh7thK+MmfseQ=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=uI/piChUK3Ch9IDzV+3tmXSytBqSDNkJxPjB8/A/Ji0Wt4399htIKK/pmf2fuD/uQ pxQVBHgIqRreh1SpxeKYubSKJIOSaq4EZ//e1hb3fnhj+H8JJpKX6vtQKzOqjVfXu9 kx/YWr3AjCHveAAszIseyfithd89EYhVcdbcGHBjeoQA6GE505CnzmWmanGbweuFv5 MTPgRCF94uO6ESURYDDuqAdK+8Q/vGKrprX7xHoHHEjC+AgcfrhCnemwarBd6BzRPb Z7OqEUsz7xDGu07DC8xixwijL3yU6JiPMb0tp1m6vG4vKfPKQAOPmRNU8z6n1+k1Lz HFRyWTHm/S/3Q== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.23]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 48xW1k6NTQz1xpM; Tue, 7 Apr 2020 17:05:46 +0200 (CEST) From: To: "ipsec@ietf.org" CC: "draft-btw-add-ipsecme-ike@ietf.org" Thread-Topic: New Version Notification for draft-btw-add-ipsecme-ike-00.txt Thread-Index: AQHWDOyIbTZJxLeGj0KK8afUB9qxFKhtwHBg Date: Tue, 7 Apr 2020 15:05:45 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330314905F2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <158627130455.4940.10283560672234804392@ietfa.amsl.com> In-Reply-To: <158627130455.4940.10283560672234804392@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [IPsec] TR: New Version Notification for draft-btw-add-ipsecme-ike-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: Tue, 07 Apr 2020 15:05:53 -0000 SGkgYWxsLCANCg0KRllJLiBDb21tZW50cyBhcmUgbW9yZSB0aGFuIHdlbGNvbWUuIA0KDQpDaGVl cnMsDQpNZWQNCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZcKgOiBpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KRW52b3nD qcKgOiBtYXJkaSA3IGF2cmlsIDIwMjAgMTY6NTUNCsOAwqA6IERhbiBXaW5nOyBUaXJ1bWFsZXN3 YXIgUmVkZHkuSzsgVmFsZXJ5IFNteXNsb3Y7IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE47IFRp cnVtYWxlc3dhciBSZWRkeQ0KT2JqZXTCoDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1idHctYWRkLWlwc2VjbWUtaWtlLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC1idHctYWRkLWlwc2VjbWUtaWtlLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5 IHN1Ym1pdHRlZCBieSBNb2hhbWVkIEJvdWNhZGFpciBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiBy ZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtYnR3LWFkZC1pcHNlY21lLWlrZQ0KUmV2aXNpb246 CTAwDQpUaXRsZToJCUludGVybmV0IEtleSBFeGNoYW5nZSBQcm90b2NvbCBWZXJzaW9uIDIgKElL RXYyKSBDb25maWd1cmF0aW9uIGZvciBFbmNyeXB0ZWQgRE5TDQpEb2N1bWVudCBkYXRlOgkyMDIw LTA0LTA3DQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxMg0KVVJMOiAg ICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1idHct YWRkLWlwc2VjbWUtaWtlLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJ0dy1hZGQtaXBzZWNtZS1pa2UvDQpIdG1saXplZDogICAg ICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJ0dy1hZGQtaXBzZWNtZS1pa2Ut MDANCkh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1s L2RyYWZ0LWJ0dy1hZGQtaXBzZWNtZS1pa2UNCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1l bnQgc3BlY2lmaWVzIGEgbmV3IEludGVybmV0IEtleSBFeGNoYW5nZSBQcm90b2NvbCBWZXJzaW9u DQogICAyIChJS0V2MikgQ29uZmlndXJhdGlvbiBQYXlsb2FkIEF0dHJpYnV0ZSBUeXBlIGZvciBl bmNyeXB0ZWQgRE5TIHN1Y2gNCiAgIGFzIEROUy1vdmVyLUhUVFBTIChEb0gpIGFuZCBETlMtb3Zl ci1UTFMgKERvVCkuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90 ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBz dWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxh YmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCg== From nobody Wed Apr 8 15:10:40 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC9C93A187C for ; Wed, 8 Apr 2020 15:10:38 -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 KGvv1jIX3Xko for ; Wed, 8 Apr 2020 15:10:37 -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 56F003A187A for ; Wed, 8 Apr 2020 15:10:36 -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 038MAX9c022435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 8 Apr 2020 18:10:35 -0400 Date: Wed, 8 Apr 2020 15:10:32 -0700 From: Benjamin Kaduk To: ipsec@ietf.org Message-ID: <20200408221032.GU88064@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: [IPsec] terminology check: "modern IPsec protocol suite" 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, 08 Apr 2020 22:10:39 -0000 Hi all, draft-ietf-taps-transport-security is currently in IESG evaluation, and in its description of IKEv2 with ESP it asserts that "IKEv2 [RFC7296] and ESP [RFC4303] together form the modern IPsec protocol suite that encrypts and authenticates IP packets, either for creating tunnels (tunnel-mode) or for direct transport connections (transport-mode)." (https://tools.ietf.org/html/draft-ietf-taps-transport-security-11#section-3.4.1). I don't think I see a problem with that description, but wanted to run it by the WG for a quick sanity check before the document gets approved, in case there's something I'm forgetting. Thanks, Ben From nobody Wed Apr 8 16:46:22 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7323A1A0B for ; Wed, 8 Apr 2020 16:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxryzdtMPu_J for ; Wed, 8 Apr 2020 16:46:19 -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 D37093A1A09 for ; Wed, 8 Apr 2020 16:46:18 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 48yLWr4Xb5zHN0; Thu, 9 Apr 2020 01:46:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1586389576; bh=/PT1MNybmkDJOJaivOa2FWvpkHg+aHcWsdxnC2i8cBg=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=q9mTd9PzBAoBMsFrQpJZ14VrB2ulDc1EpJ7tdqfCjfZOyOGwi9yWJW0OrnM5Li4+g oCmkIYmx37EstHlb3Kj1WyLTo1I8hBp3+fakoLrUQVhSKfmhDn71h1TGlM91DJ3VOx xCpMa7wIXqsyi5dFPYPNk0t9h9jLt2b8P3yX2Sec= 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 FakVTKyU_Fnm; Thu, 9 Apr 2020 01:46: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; Thu, 9 Apr 2020 01:46:15 +0200 (CEST) Received: from [193.111.228.74] (unknown [193.111.228.74]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id CE399601EBC4; Wed, 8 Apr 2020 19:09:22 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Paul Wouters Mime-Version: 1.0 (1.0) Date: Wed, 8 Apr 2020 19:09:22 -0400 Message-Id: References: <20200408221032.GU88064@kduck.mit.edu> Cc: ipsec@ietf.org In-Reply-To: <20200408221032.GU88064@kduck.mit.edu> To: Benjamin Kaduk X-Mailer: iPhone Mail (17D50) Archived-At: Subject: Re: [IPsec] terminology check: "modern IPsec protocol suite" 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, 08 Apr 2020 23:46:21 -0000 On Apr 8, 2020, at 18:10, Benjamin Kaduk wrote: >=20 > =EF=BB=BFHi all, >=20 > draft-ietf-taps-transport-security is currently in IESG evaluation, and in= > its description of IKEv2 with ESP it asserts that "IKEv2 [RFC7296] and ESP= > [RFC4303] together form the modern IPsec protocol suite that encrypts and > authenticates IP packets, either for creating tunnels (tunnel-mode) or for= > direct transport connections (transport-mode)." > (https://tools.ietf.org/html/draft-ietf-taps-transport-security-11#section= -3.4.1). > I don't think I see a problem with that description, but wanted to run it > by the WG for a quick sanity check before the document gets approved, in > case there's something I'm forgetting. Looks correct and appropriate to me. Paul From nobody Wed Apr 8 17:12:04 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 229373A1A58 for ; Wed, 8 Apr 2020 17:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, 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 TAwAmyu-MRpC for ; Wed, 8 Apr 2020 17:12:00 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4817E3A1A57 for ; Wed, 8 Apr 2020 17:11:59 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CC9203897F; Wed, 8 Apr 2020 20:10:17 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0351516D; Wed, 8 Apr 2020 20:11:54 -0400 (EDT) From: Michael Richardson To: Paul Wouters cc: Benjamin Kaduk , ipsec@ietf.org In-Reply-To: References: <20200408221032.GU88064@kduck.mit.edu> 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] terminology check: "modern IPsec protocol suite" 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, 09 Apr 2020 00:12:03 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Paul Wouters wrote: >> =EF=BB=BFHi all, >> >> draft-ietf-taps-transport-security is currently in IESG evaluation, = and in >> its description of IKEv2 with ESP it asserts that "IKEv2 [RFC7296] a= nd ESP >> [RFC4303] together form the modern IPsec protocol suite that encrypt= s and >> authenticates IP packets, either for creating tunnels (tunnel-mode) = or for >> direct transport connections (transport-mode)." >> (https://tools.ietf.org/html/draft-ietf-taps-transport-security-11#s= ection-3.4.1). >> I don't think I see a problem with that description, but wanted to r= un it >> by the WG for a quick sanity check before the document gets approved= , in >> case there's something I'm forgetting. > Looks correct and appropriate to me. I also agree. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl6OaEkACgkQgItw+93Q 3WUdtgf9FA/fbmdsGus1qBirJn5dnyAaFt457+GD8ylzjBVsk2NAXYCtpO/kyoPP GbWwJ24et8qsdbkVFI1rePoDkdSw+kjIqcVIanjT5ZZ5p7iLvuulGOweTsnPGXdj meNnnSKyW/m0Afek3lzpAmAXJLs6mawAUyf+Bk9bc+nOlq3PhRbZYuR+TYuyFqKO QUxyjAsWO7opq+SApVdlWYKGoCY7ZT9r+FBmlVoYdSMcZDfMx1kIatumRThZhIch RKyvCQqSCbo/AxNwL63/LhVrJYHHlCXoCtls0XEtMhw9NzIr3l7CoK9HEqxJ0PLe mgliJgCRIfF9vosK+kHjDDzs8yy/nQ== =AtFh -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Apr 8 23:02: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 6522D3A0BD5 for ; Wed, 8 Apr 2020 23:02:22 -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 AwylmwfQxX0A for ; Wed, 8 Apr 2020 23:02:21 -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 E1A9E3A0BD4 for ; Wed, 8 Apr 2020 23:02:20 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id i20so10173091ljn.6 for ; Wed, 08 Apr 2020 23:02:20 -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=jYhL0bzN8loeLVYnxb8xRtS/CNTWJOAAHQfTXpAuABQ=; b=XbNcXwMkkY0O+SaZeXjDIR+jMXNZboM3GSMXob7HNHI85LiGQfpKoPdbl9LySqXAU0 Uy8UkOfyzAux5c4T6TyN4OCGGey0so9BX1Rjuat47byrnR3v5ymleCpLDFdORnt2Pzt7 nZzPpm2dmbDitcbU4EX32t16PjZ0Ka9jkQqmrrG/FvEtLm3y+7n//pEpwsNBkjIVXF+0 0gc69Fl9bQzvzQ2UlmdNecLRSQf4BtKlcr7/FIdIswNhBmrIKPGVX2jXW3vCaQwJzJiU fpFreqPDvCRYS0xmUT2KvMGdVVSC+UVGk5OdmXDUAp8NlkUVv71VqPFNAlQBvXSCe+mf N0Lg== 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=jYhL0bzN8loeLVYnxb8xRtS/CNTWJOAAHQfTXpAuABQ=; b=j/FrQRNti7jSptNVtwJ2aCOa6zXfTw0eVwfsPE3E4OaebC1+rddWvrm33Tmxu6feGx t0LKpHu503ngSW+hZXs6qTPA5NbjGJncsjqU4NuYadSPQ6+Vx3zmPWhKfZDFXGfSTTVB mFGFhdpikX/NRECulr0qRe3r9+PCV5cCEqKGOKlYqhKdm2l79B+/uxydpXRjtnCVF5tm Sp5eK9oKLnbzuxHA3pPjzdxrlTCP2lXfuRMmP6u9RQX1nNSZrUiwKOc+9jmGmMrdFBHb A62hNJI4ts1SThCuu09Ji4fQl+Ryc6+1phuWL+vH4vrx/mkpq9Xn281K0OoN1hGCfdQ2 yalg== X-Gm-Message-State: AGi0PubN0QTWsudzShvjdj/Z0ufbmuNis2K1BKiEfz/oneil8eUT2CzU gDbME/9NQ3PWzQOVJYElyDQarHMK X-Google-Smtp-Source: APiQypLg2UImoPfoj1gLgaDuDf6hcEn0RLEFiUh8EOrgMCFUlsJ1GlP5H1+ZVQ6jO7bNPKyrwjiWeQ== X-Received: by 2002:a2e:3a19:: with SMTP id h25mr7383390lja.133.1586412138645; Wed, 08 Apr 2020 23:02:18 -0700 (PDT) Received: from chichi (95-27-147-103.broadband.corbina.ru. [95.27.147.103]) by smtp.gmail.com with ESMTPSA id e17sm14459997ljo.75.2020.04.08.23.02.17 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 08 Apr 2020 23:02:17 -0700 (PDT) From: "Valery Smyslov" To: "'Paul Wouters'" , "'Benjamin Kaduk'" Cc: References: <20200408221032.GU88064@kduck.mit.edu> In-Reply-To: Date: Thu, 9 Apr 2020 09:02:12 +0300 Message-ID: <005901d60e34$69df52e0$3d9df8a0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJkC021nAz3+62Dydu/GtgXeI1K5gLrhKngpzz0ZYA= Content-Language: ru Archived-At: Subject: Re: [IPsec] terminology check: "modern IPsec protocol suite" 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, 09 Apr 2020 06:02:22 -0000 Hi, > > draft-ietf-taps-transport-security is currently in IESG evaluation, = and in > > its description of IKEv2 with ESP it asserts that "IKEv2 [RFC7296] = and ESP > > [RFC4303] together form the modern IPsec protocol suite that = encrypts > and > > authenticates IP packets, either for creating tunnels (tunnel-mode) = or for > > direct transport connections (transport-mode)." > > = (https://tools.ietf.org/html/draft-ietf-taps-transport-security-11#sectio= n- > 3.4.1). > > I don't think I see a problem with that description, but wanted to = run it > > by the WG for a quick sanity check before the document gets = approved, in > > case there's something I'm forgetting. >=20 > Looks correct and appropriate to me. I concur.=20 However, I'd suggest changing the title of the section from "IKEv2 with = ESP" to "IPsec". Regards, Valery. > Paul >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Apr 9 15:42: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 4DD3D3A111E for ; Thu, 9 Apr 2020 15:42:19 -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 tHkMURsuJRlc for ; Thu, 9 Apr 2020 15:42:18 -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 DF8823A111D for ; Thu, 9 Apr 2020 15:42:17 -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 039MgCKZ027140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 9 Apr 2020 18:42:14 -0400 Date: Thu, 9 Apr 2020 15:42:11 -0700 From: Benjamin Kaduk To: Valery Smyslov Cc: "'Paul Wouters'" , ipsec@ietf.org Message-ID: <20200409224211.GL88064@kduck.mit.edu> References: <20200408221032.GU88064@kduck.mit.edu> <005901d60e34$69df52e0$3d9df8a0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005901d60e34$69df52e0$3d9df8a0$@gmail.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [IPsec] terminology check: "modern IPsec protocol suite" 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, 09 Apr 2020 22:42:19 -0000 On Thu, Apr 09, 2020 at 09:02:12AM +0300, Valery Smyslov wrote: > Hi, > > > > draft-ietf-taps-transport-security is currently in IESG evaluation, and in > > > its description of IKEv2 with ESP it asserts that "IKEv2 [RFC7296] and ESP > > > [RFC4303] together form the modern IPsec protocol suite that encrypts > > and > > > authenticates IP packets, either for creating tunnels (tunnel-mode) or for > > > direct transport connections (transport-mode)." > > > (https://tools.ietf.org/html/draft-ietf-taps-transport-security-11#section- > > 3.4.1). > > > I don't think I see a problem with that description, but wanted to run it > > > by the WG for a quick sanity check before the document gets approved, in > > > case there's something I'm forgetting. > > > > Looks correct and appropriate to me. > > I concur. > > However, I'd suggest changing the title of the section from "IKEv2 with ESP" to "IPsec". Thanks everyone for the quick review! I will pass the title suggestion on to the authors. -Ben From nobody Thu Apr 9 15:46:50 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 93B573A112B for ; Thu, 9 Apr 2020 15:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Hj3MdMRrxdF for ; Thu, 9 Apr 2020 15:46:46 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B523F3A112A for ; Thu, 9 Apr 2020 15:46:46 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id C0108548017; Fri, 10 Apr 2020 00:46:40 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id B711F440040; Fri, 10 Apr 2020 00:46:40 +0200 (CEST) Date: Fri, 10 Apr 2020 00:46:40 +0200 From: Toerless Eckert To: Valery Smyslov Cc: 'Paul Wouters' , 'Benjamin Kaduk' , ipsec@ietf.org Message-ID: <20200409224640.GE44502@faui48f.informatik.uni-erlangen.de> References: <20200408221032.GU88064@kduck.mit.edu> <005901d60e34$69df52e0$3d9df8a0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005901d60e34$69df52e0$3d9df8a0$@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [IPsec] terminology check: "modern IPsec protocol suite" 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, 09 Apr 2020 22:46:49 -0000 Does IPsec not also include AH as an option still ? On Thu, Apr 09, 2020 at 09:02:12AM +0300, Valery Smyslov wrote: > Hi, > > > > draft-ietf-taps-transport-security is currently in IESG evaluation, and in > > > its description of IKEv2 with ESP it asserts that "IKEv2 [RFC7296] and ESP > > > [RFC4303] together form the modern IPsec protocol suite that encrypts > > and > > > authenticates IP packets, either for creating tunnels (tunnel-mode) or for > > > direct transport connections (transport-mode)." > > > (https://tools.ietf.org/html/draft-ietf-taps-transport-security-11#section- > > 3.4.1). > > > I don't think I see a problem with that description, but wanted to run it > > > by the WG for a quick sanity check before the document gets approved, in > > > case there's something I'm forgetting. > > > > Looks correct and appropriate to me. > > I concur. > > However, I'd suggest changing the title of the section from "IKEv2 with ESP" to "IPsec". > > Regards, > Valery. > > > Paul > > > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Apr 9 17:01: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 038363A1510 for ; Thu, 9 Apr 2020 17:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHhuQDh68n1d for ; Thu, 9 Apr 2020 17:01:24 -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 836E63A1513 for ; Thu, 9 Apr 2020 17:01:24 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 48yypp5LgszFhl; Fri, 10 Apr 2020 02:01:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1586476882; bh=5URIZDJG0YUTN75Ks1BnbtOmxWHqiTneIGyGeoEulww=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=Tfh6eeNXOi4psYXfahJARjJXWOvhN6PPVf/nFEllIz30UbgDoVBejFjOv77mmu87D XF8hYMgEB4budcaE38Oxg36HMXSDegLXwfMg99BK9VqXQane1XedJjBJepcbfyXrEz V/fbLCOfb9+dtNX50vKHnY6796Ig7houJQfbZFaQ= 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 L5MTZbRL4Sd1; Fri, 10 Apr 2020 02:01:21 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 10 Apr 2020 02:01:21 +0200 (CEST) Received: from [193.111.228.74] (unknown [193.111.228.74]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id E1F606020CF9; Thu, 9 Apr 2020 19:07:00 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Paul Wouters Mime-Version: 1.0 (1.0) Date: Thu, 9 Apr 2020 19:07:00 -0400 Message-Id: References: <20200409224640.GE44502@faui48f.informatik.uni-erlangen.de> Cc: Valery Smyslov , Benjamin Kaduk , ipsec@ietf.org In-Reply-To: <20200409224640.GE44502@faui48f.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: iPhone Mail (17D50) Archived-At: Subject: Re: [IPsec] terminology check: "modern IPsec protocol suite" 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, 10 Apr 2020 00:01:26 -0000 L > On Apr 9, 2020, at 18:56, Toerless Eckert wrote: >=20 > =EF=BB=BFDoes IPsec not also include AH as an option still ? We don=E2=80=99t mention the Protocol That Shall Not Be Named, and recommend= ESP-NULL instead. Paul= From nobody Thu Apr 9 17:02:50 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 7F31D3A151E for ; Thu, 9 Apr 2020 17:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQ67XAZMco53 for ; Thu, 9 Apr 2020 17:02:48 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 266C03A1510 for ; Thu, 9 Apr 2020 17:02:48 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id A9001548017; Fri, 10 Apr 2020 02:02:43 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 9FFE2440040; Fri, 10 Apr 2020 02:02:43 +0200 (CEST) Date: Fri, 10 Apr 2020 02:02:43 +0200 From: Toerless Eckert To: Paul Wouters Cc: Valery Smyslov , Benjamin Kaduk , ipsec@ietf.org Message-ID: <20200410000243.GI44502@faui48f.informatik.uni-erlangen.de> References: <20200409224640.GE44502@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [IPsec] terminology check: "modern IPsec protocol suite" 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, 10 Apr 2020 00:02:50 -0000 Haha. So you have to choose whether you want a title that a Muggle understand or not ;-) Cheers Toerless On Thu, Apr 09, 2020 at 07:07:00PM -0400, Paul Wouters wrote: > L > > On Apr 9, 2020, at 18:56, Toerless Eckert wrote: > > > > ???Does IPsec not also include AH as an option still ? > > We don???t mention the Protocol That Shall Not Be Named, and recommend ESP-NULL instead. > > Paul -- --- tte@cs.fau.de From nobody Thu Apr 9 22:46:45 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 E8E083A17A5 for ; Thu, 9 Apr 2020 22:46:43 -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 WtRWFDP1e-Sy for ; Thu, 9 Apr 2020 22:46:42 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 2B03C3A17A1 for ; Thu, 9 Apr 2020 22:46:41 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id t17so859224ljc.12 for ; Thu, 09 Apr 2020 22:46:41 -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=Ktugo163bOON9f1us8rx/txCM/0ewNpF0NYGP4KvTbw=; b=mS9hgtHBhYVRkSLG/yickC/7UULNKcVVBbax1n/T55jPq1SjP67He/DMQ0/kcr7573 igZeETA/F+MEQnvkWOMP0XlGIe9NaA2bFkHc4VYXAEk/BpO4Vg6tMxVxwWiI4IlawyI5 O2N1M2dFDFdKOgoAEt5Gxw0MIP+ikiz2EVTWkZc2guIXBQzXR+nDcqwSLI7mGyrPOF7u 9UpewzrMCcLgchge8m8AnxEOU4AMgtoXEdqe+IYriDAxSqrhCUtZnZYn4rlPvg9+QgWw fJ5TBVV2I3uWiLqRztwbTvHw0LYov4sppCKGry7cay7/z5nb2zBo15f5po5uxMmvVa0E /vDw== 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=Ktugo163bOON9f1us8rx/txCM/0ewNpF0NYGP4KvTbw=; b=TL3n1/OO9lw4PTT0kEzuI3tEdo0ED039i45FwXb6q/4eNPVePYbhFt2mK9M2/Cz+Ar TJJxoDb6NxX0EXImZIn3ANK2D37cRvBp8lLdeHAZgVfpWD+CdWsgi4mM6CF+Wv+0gy5s Dh7H0Zc2JO3hW0R2CT8yBVfWUoCObdPU1tgqhN4E0CJ4gHMio0Q7OUsBdYH/3g05+4Lm w2Cdhj3l4MWCER0ODVTvYrPdeL5zi5VGcNAxPrtFcNH57HJyqWblpNu1crUCyvm5r41Y eigSnD42aKHCk085z83Vms1dKVkJ5gyix/EluBbemcDllPnT3qBs/zLkifBeDuLj17B+ XB4w== X-Gm-Message-State: AGi0PuZ0n6FOw4FKf9QlThTYuTdOd+J/+9cZZ+vblY6ZHwhlMi2aB88J +zlgapgCkKftA8G5f9nbVODtT8h2 X-Google-Smtp-Source: APiQypLfF/Dsdt/iw3S9/13izdgGMLTCgXyZ4YFFjtJvBZCpLyTVmGMCvOAkjgoImHCqbHE/5PFUVw== X-Received: by 2002:a05:651c:30b:: with SMTP id a11mr1942470ljp.164.1586497599822; Thu, 09 Apr 2020 22:46:39 -0700 (PDT) Received: from chichi (95-27-147-103.broadband.corbina.ru. [95.27.147.103]) by smtp.gmail.com with ESMTPSA id t81sm629891lff.52.2020.04.09.22.46.38 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Thu, 09 Apr 2020 22:46:38 -0700 (PDT) From: "Valery Smyslov" To: "'Toerless Eckert'" Cc: "'Paul Wouters'" , "'Benjamin Kaduk'" , References: <20200408221032.GU88064@kduck.mit.edu> <005901d60e34$69df52e0$3d9df8a0$@gmail.com> <20200409224640.GE44502@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20200409224640.GE44502@faui48f.informatik.uni-erlangen.de> Date: Fri, 10 Apr 2020 08:46:32 +0300 Message-ID: <004101d60efb$6435dcc0$2ca19640$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: ru Thread-Index: AQJkC021nAz3+62Dydu/GtgXeI1K5gLrhKngAiJ93ncBpprwjqcgOSDA Archived-At: Subject: Re: [IPsec] terminology check: "modern IPsec protocol suite" 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, 10 Apr 2020 05:46:44 -0000 Hi Toerless, > Does IPsec not also include AH as an option still ? AH is still formally a part of IPsec, but it is next to extinct in real life. I see no ambiguity in renaming the section, since the text clearly says that IKEv2+ESP is a "modern IPsec protocol suite", which is right. Regards, Valery. > On Thu, Apr 09, 2020 at 09:02:12AM +0300, Valery Smyslov wrote: > > Hi, > > > > > > draft-ietf-taps-transport-security is currently in IESG evaluation, and in > > > > its description of IKEv2 with ESP it asserts that "IKEv2 [RFC7296] and > ESP > > > > [RFC4303] together form the modern IPsec protocol suite that encrypts > > > and > > > > authenticates IP packets, either for creating tunnels (tunnel-mode) or > for > > > > direct transport connections (transport-mode)." > > > > (https://tools.ietf.org/html/draft-ietf-taps-transport-security- > 11#section- > > > 3.4.1). > > > > I don't think I see a problem with that description, but wanted to run it > > > > by the WG for a quick sanity check before the document gets approved, > in > > > > case there's something I'm forgetting. > > > > > > Looks correct and appropriate to me. > > > > I concur. > > > > However, I'd suggest changing the title of the section from "IKEv2 with > ESP" to "IPsec". > > > > Regards, > > Valery. > > > > > Paul > > > > > > > > > _______________________________________________ > > > IPsec mailing list > > > IPsec@ietf.org > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Apr 14 19:13: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 6FCA33A151B for ; Tue, 14 Apr 2020 19:13: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 QXddDs5DeUsu for ; Tue, 14 Apr 2020 19:13:25 -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 36A173A151A for ; Tue, 14 Apr 2020 19:13:24 -0700 (PDT) Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 03F2DLbm003434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 14 Apr 2020 22:13:23 -0400 Date: Tue, 14 Apr 2020 19:13:21 -0700 From: Benjamin Kaduk To: ipsec@ietf.org Message-ID: <20200415021321.GI88064@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: [IPsec] revisiting 3DES and -graveyard 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, 15 Apr 2020 02:13:26 -0000 Hi all, I see in https://datatracker.ietf.org/meeting/104/materials/minutes-104-ipsecme-00 that we didn't want to get rid of 3DES at that time. Do we have a sense for how quickly that will change, the scope of existing deployments, etc.? In particular, would a general-purpose OS's implementation cause problems for its consumers if the next release dropped support? (Noting that consumers could stay on an old OS release to match the old algorithms, at least for a while.) Thanks, Ben From nobody Tue Apr 14 20:22:02 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2585A3A161E for ; Tue, 14 Apr 2020 20:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CICWRFTBbU4P for ; Tue, 14 Apr 2020 20:21:58 -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 248143A161B for ; Tue, 14 Apr 2020 20:21:58 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 49271w1C4gz1kK; Wed, 15 Apr 2020 05:21:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1586920916; bh=g+E9JcuTtiSMQRTDhOR5xYAHmO2iPnV31Jq5l6BASn4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Byqb9SMsb8K9kUivgELZKOXo2vSWrwYIyRbQR5wR8ZQH82aPsI7ULFzbephIg3LQT ade5/LDTPdr5VkS5kXqQxGGrlmgnuhKY41XZeWAavTxjFj5EL/9EPg5EFpR/audBXM NnQ15uiCbhNZ7Ld5SGCtNkWVPog0cBJW73pQm+Tc= 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 OOyyrDPQyxDL; Wed, 15 Apr 2020 05:21:54 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 15 Apr 2020 05:21:54 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 9D8366020D42; Tue, 14 Apr 2020 23:13:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 99E4E66B7C; Tue, 14 Apr 2020 23:13:05 -0400 (EDT) Date: Tue, 14 Apr 2020 23:13:05 -0400 (EDT) From: Paul Wouters To: Benjamin Kaduk cc: ipsec@ietf.org In-Reply-To: <20200415021321.GI88064@mit.edu> Message-ID: References: <20200415021321.GI88064@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] revisiting 3DES and -graveyard 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, 15 Apr 2020 03:22:00 -0000 On Tue, 14 Apr 2020, Benjamin Kaduk wrote: > I see in > https://datatracker.ietf.org/meeting/104/materials/minutes-104-ipsecme-00 > that we didn't want to get rid of 3DES at that time. Do we have a sense > for how quickly that will change, the scope of existing deployments, etc.? 3DES is already defined as SHOULD NOT. The next step in evolation would be a MUST NOT. So I think we are on the right path. The SHOULD NOT recommendation is from 2.5 years ago. Unfortunately, VPN deployments are slow to change, and I fear that a lot of IKEv1 gear is still out there running on 1990's configuration with 3DES, MD5/SHA1 and DH2/5. But I think those deployments will die out over time as hardware is replaced, and configurations are (very very slowly) upgraded. Anything with IKEv2 already does not really use 3DES anywhere. > In particular, would a general-purpose OS's implementation cause problems > for its consumers if the next release dropped support? (Noting that > consumers could stay on an old OS release to match the old algorithms, at > least for a while.) General-purpose OS's are a bit more modern than hardware VPN boxes. These all already do IKEv2 and even for IKEv1 would default to AES/AES-GCM. They would not need 3DES unless it is talking to a 1990's device. Note that in Fedora and RHEL, we already have a systemwide crypto policy that also applies to IKE/IPsec, and its DEFAULT policy is: (see /usr/share/crypto-policies/DEFAULT/libreswan.txt) ikev2=insist pfs=yes ike=aes_gcm256-sha2_512+sha2_256-dh19+dh20+dh21+dh14+dh15+dh16+dh18,chacha20_poly1305-sha2_512+sha2_256-dh19+dh20+dh21+dh14+dh15+dh16+dh18,aes256-sha2_512+sha2_256-dh19+dh20+dh21+dh14+dh15+dh16+dh18,aes_gcm128-sha2_512+sha2_256-dh19+dh20+dh21+dh14+dh15+dh16+dh18,aes128-sha2_256-dh19+dh20+dh21+dh14+dh15+dh16+dh18 esp=aes_gcm256,chacha20_poly1305,aes256-sha2_512+sha1+sha2_256,aes_gcm128,aes128-sha1+sha2_256 So no 3DES. I don't know how often people are overriding this on a per-configuration basis, but we (redhat) have definitely not had any complains of people who wanted to use 3des. I just noticed even our LEGACY systemwide crypto policy does not allow 3DES. I'm checking with our crypto people to see if that is by design or a bug. I think it is by design because even our LEGACY policy insists on ikev2 :) So in short, general purpose OSes have no problem, but might need to talk to 1990s old gear. I do think the next document update should change 3DES to MUST NOT. But I would like the graveyard draft to go out first pointing a bit further to the death of IKEv1. Perhaps a document update for October would be good? That would have given 3DES three years to go from SHOULD NOT to MUST NOT. Paul From nobody Wed Apr 15 05:49:13 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF913A0E1A for ; Wed, 15 Apr 2020 05:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50qB9TAxMYQU for ; Wed, 15 Apr 2020 05:49:09 -0700 (PDT) Received: from meesny.iki.fi (meesny.iki.fi [195.140.195.201]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 021153A0E16 for ; Wed, 15 Apr 2020 05:49:07 -0700 (PDT) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: kivinen) by meesny.iki.fi (Postfix) with ESMTPSA id 615182017B; Wed, 15 Apr 2020 15:49:03 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1586954943; 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=8amj9rcEzafOg0fL+ScvC8B0YFGlV1fMarPZ3flOjk4=; b=wqdcxtFLpHTOrKF+SrhO3VAMGIza2iToqGdySNo/t0zJZ95Cmdp6QQOM6g/QCLI8aE7qNc ubO8oVK/n3rtOzW4O2I2jovRdhfN8mta/bZ1qNW0NW5bCO3b7U5/u9w94cfrw/hoMmymdC DjeYQ81wG8RMWViD8rZuJqu8/nANCOE= Received: by fireball.acr.fi (Postfix, from userid 15204) id 6EE2B25C0E24; Wed, 15 Apr 2020 15:49:01 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24215.701.417106.744293@fireball.acr.fi> Date: Wed, 15 Apr 2020 15:49:01 +0300 From: Tero Kivinen To: Benjamin Kaduk Cc: ipsec@ietf.org In-Reply-To: <20200415021321.GI88064@mit.edu> References: <20200415021321.GI88064@mit.edu> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 7 min X-Total-Time: 6 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1586954943; 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=8amj9rcEzafOg0fL+ScvC8B0YFGlV1fMarPZ3flOjk4=; b=UpZzGTAAUqu4ZHZhbTBX3E0/ylo/5IceOCIjUnwhGcH05q1/25NC2mtlwSpCQKg/4nbA6k 5ov6t3TddvHKZN7+/l+62rVWkmRZ++veuJGZ7UULWwmItOeoFqRDMpKXW1yNjHCBkXV8a2 a9IXOWacGlaLV7Nmi4qAZFRxkS8zjqs= ARC-Seal: i=1; s=meesny; d=iki.fi; t=1586954943; a=rsa-sha256; cv=none; b=Y+AA5AnYoSvhKR77phW2sMba6Xn3Qgd2EXMIS39UjiopuWr7AlU9S04p4F00Yj7GMXfjg5 e/Kan2EViaA7HF3AVmTuu/rCsOqDzwfznWiZK/mSIGQC5QWIm1+oSdAMSrX25MzhxBx3Bb YFwUCc+GnKAMvGg+tv3+i24zWv2yhyo= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: [IPsec] revisiting 3DES and -graveyard 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, 15 Apr 2020 12:49:12 -0000 Benjamin Kaduk writes: > I see in > https://datatracker.ietf.org/meeting/104/materials/minutes-104-ipsecme-00 > that we didn't want to get rid of 3DES at that time. Do we have a sense > for how quickly that will change, the scope of existing deployments, etc.? One of the problems is that we as an IETF give instructions to implementors, not to users. If we change 3DES MUST NOT, then all implementations out there who do implement 3DES, but where it is disabled in configuration by default are no longer conformant to the new RFC, as they do still implement 3DES. Anybody who puts 3DES in any of the new implementations or new releases of the current implementations are going against the SHOULD NOT in the current RFC. Meaning they most likely have some old legacy stuff they need to support which only supports 3DES and thats why they want to keep 3DES in their current releases as they want to be able to talk to those. I would wait bit more than 2.5 years before saying MUST NOT. > In particular, would a general-purpose OS's implementation cause problems > for its consumers if the next release dropped support? (Noting that > consumers could stay on an old OS release to match the old algorithms, at > least for a while.) Especially with consumers and general-purpose OS there is no option for using old OS release anymore. Most of those will automatically update to latest version, and there usually isn't any easy way to downgrade back to previous version when issues are found. -- kivinen@iki.fi From nobody Wed Apr 15 08:03: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 1AD8F3A09F3 for ; Wed, 15 Apr 2020 08:03:53 -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 gTb7WKu9h5zM for ; Wed, 15 Apr 2020 08:03:50 -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 A3CF23A09F4 for ; Wed, 15 Apr 2020 08:03:50 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 649C33897B; Wed, 15 Apr 2020 11:02:07 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1081D602; Wed, 15 Apr 2020 11:03:49 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk , ipsec@ietf.org In-Reply-To: <20200415021321.GI88064@mit.edu> References: <20200415021321.GI88064@mit.edu> 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] revisiting 3DES and -graveyard 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, 15 Apr 2020 15:03:54 -0000 --=-=-= Content-Type: text/plain Benjamin Kaduk wrote: > I see in > https://datatracker.ietf.org/meeting/104/materials/minutes-104-ipsecme-00 > that we didn't want to get rid of 3DES at that time. Do we have a sense > for how quickly that will change, the scope of existing deployments, > etc.? > In particular, would a general-purpose OS's implementation cause problems > for its consumers if the next release dropped support? (Noting that > consumers could stay on an old OS release to match the old algorithms, at > least for a while.) 1) They all have AES128, and have had it for at least a decade. 2) general-purpose OS implementations are (sadly) *not* being used by the majority of "VPN" users, whether that's site-to-site or remote-access. Except on iOS and Android, where OS-provided IKEv2/IPsec is winning, and I'll bet they could drop 3DES tomorrow. The last time I have seen 3DES configured was for site-to-site VPNs between different (medical!) enterprises because neither side could be sure what the other side had, and equipment was old. They didn't dare change the configuration, or replace the hardware. (Cargo culting...) This was maybe 6 years ago. I believe that we could remove it. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl6XIlQACgkQgItw+93Q 3WWqQAgAuhIKvq+vMJ3HXpw0FnKCXxWBP6wy6uCFUfAEhs/5X0UDGu4IPPIVGfcU mJgaxurFKei0w695rPsLQ5KjGkJLQhNOsbN8L6fDVd5o3u3hG0oKJCbIwp6rVgu5 Ru5IwgZDFiYrT8bzzWAmQLr617nYExveAaTXI6sJNbn6DCMkex+2AThNXQ4HelG4 Efb+YM57/Nf49whEhgZHRC8/ZYBZAtV00EPSUiipjzdgULZQRiv4RTFZqinp1rZ+ YPD3q8b4H26BbVZ1anAclNZJcVkWZfHPc5cbC6y/BQPS6tB5oj7jaLtlY3lxfCTs L2no89IE+6zoo/flxAAEhJooiR6DWw== =bFh4 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Apr 17 16:08:17 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 280C33A0958 for ; Fri, 17 Apr 2020 16:08:16 -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 qT1r1RSPOk7R for ; Fri, 17 Apr 2020 16:08:14 -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 89DB23A0953 for ; Fri, 17 Apr 2020 16:08:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 2D1376224B; Fri, 17 Apr 2020 19:08:13 -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 MEP-b4cGnYuU; Fri, 17 Apr 2020 19:08:05 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (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 5857B621F2; Fri, 17 Apr 2020 19:08:03 -0400 (EDT) To: Tero Kivinen , Benjamin Kaduk Cc: ipsec@ietf.org References: <20200415021321.GI88064@mit.edu> <24215.701.417106.744293@fireball.acr.fi> From: Robert Moskowitz Message-ID: Date: Fri, 17 Apr 2020 19:07:47 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <24215.701.417106.744293@fireball.acr.fi> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [IPsec] revisiting 3DES and -graveyard 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, 17 Apr 2020 23:08:16 -0000 Just as an aside thought about 3DES: perhaps you saw my questions to the CFRG list where I have exactly 64 bits to encrypt and no place for an IV or such. One of the serious suggestions WAS 3DES with 3 keys. For a number of reasons I am not offering that in the initial ID, rather AES-CFB16... But for only 64 bits to encrypt, 3DES is a consideration. Nah. (also it may change to exactly 96 bits to encrypt.  They left out the UA Altitude and the FAA is not happy with that). Have a good weekend all! On 4/15/20 8:49 AM, Tero Kivinen wrote: > Benjamin Kaduk writes: >> I see in >> https://datatracker.ietf.org/meeting/104/materials/minutes-104-ipsecme-00 >> that we didn't want to get rid of 3DES at that time. Do we have a sense >> for how quickly that will change, the scope of existing deployments, etc.? > One of the problems is that we as an IETF give instructions to > implementors, not to users. If we change 3DES MUST NOT, then all > implementations out there who do implement 3DES, but where it is > disabled in configuration by default are no longer conformant to the > new RFC, as they do still implement 3DES. > > Anybody who puts 3DES in any of the new implementations or new > releases of the current implementations are going against the SHOULD > NOT in the current RFC. > > Meaning they most likely have some old legacy stuff they need to > support which only supports 3DES and thats why they want to keep 3DES > in their current releases as they want to be able to talk to those. > > I would wait bit more than 2.5 years before saying MUST NOT. > >> In particular, would a general-purpose OS's implementation cause problems >> for its consumers if the next release dropped support? (Noting that >> consumers could stay on an old OS release to match the old algorithms, at >> least for a while.) > Especially with consumers and general-purpose OS there is no option > for using old OS release anymore. Most of those will automatically > update to latest version, and there usually isn't any easy way to > downgrade back to previous version when issues are found. From nobody Mon Apr 20 17:01:18 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 989E23A136A for ; Mon, 20 Apr 2020 17:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 glhlLMLLijEK for ; Mon, 20 Apr 2020 17:00:44 -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 8B4253A136C for ; Mon, 20 Apr 2020 17:00:43 -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 03L00bIA015850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 20 Apr 2020 20:00:41 -0400 Date: Mon, 20 Apr 2020 17:00:37 -0700 From: Benjamin Kaduk To: Michael Richardson Cc: ipsec@ietf.org Message-ID: <20200421000037.GC27494@kduck.mit.edu> References: <20200415021321.GI88064@mit.edu> <12805.1586963029@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <12805.1586963029@localhost> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [IPsec] revisiting 3DES and -graveyard 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, 21 Apr 2020 00:00:48 -0000 Thanks all for the responses; this helps me get a better picture of the state of things and our future direction! On Wed, Apr 15, 2020 at 11:03:49AM -0400, Michael Richardson wrote: > > Benjamin Kaduk wrote: > > I see in > > https://datatracker.ietf.org/meeting/104/materials/minutes-104-ipsecme-00 > > that we didn't want to get rid of 3DES at that time. Do we have a sense > > for how quickly that will change, the scope of existing deployments, > > etc.? > > > In particular, would a general-purpose OS's implementation cause problems > > for its consumers if the next release dropped support? (Noting that > > consumers could stay on an old OS release to match the old algorithms, at > > least for a while.) > > 1) They all have AES128, and have had it for at least a decade. > > 2) general-purpose OS implementations are (sadly) *not* being used by the majority > of "VPN" users, whether that's site-to-site or remote-access. > Except on iOS and Android, where OS-provided IKEv2/IPsec is winning, > and I'll bet they could drop 3DES tomorrow. > > The last time I have seen 3DES configured was for site-to-site VPNs between > different (medical!) enterprises because neither side could be sure what the > other side had, and equipment was old. They didn't dare change the configuration, or > replace the hardware. (Cargo culting...) This was maybe 6 years ago. Funnily enough, we see a similar thing in the Kerberos world, with 3DES cross-realm keys set up decades ago that everyone is afraid to touch :) (It turns out that most of the time you don't actually need to get both administrators in the same room to update things, and it can be done asynchronously and asymmetrically, by one administrator at a time.) -Ben From nobody Mon Apr 20 18:48:13 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2021A3A150F for ; Mon, 20 Apr 2020 18:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 tojS1B6lLb5D for ; Mon, 20 Apr 2020 18:48:05 -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 96B6F3A150D for ; Mon, 20 Apr 2020 18:48:05 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 068D038980; Mon, 20 Apr 2020 21:46:16 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3AB363F; Mon, 20 Apr 2020 21:48:02 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk cc: ipsec@ietf.org In-Reply-To: <20200421000037.GC27494@kduck.mit.edu> References: <20200415021321.GI88064@mit.edu> <12805.1586963029@localhost> <20200421000037.GC27494@kduck.mit.edu> 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] revisiting 3DES and -graveyard 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, 21 Apr 2020 01:48:11 -0000 --=-=-= Content-Type: text/plain Benjamin Kaduk wrote: >> The last time I have seen 3DES configured was for site-to-site VPNs between >> different (medical!) enterprises because neither side could be sure what the >> other side had, and equipment was old. They didn't dare change the configuration, or >> replace the hardware. (Cargo culting...) This was maybe 6 years ago. > Funnily enough, we see a similar thing in the Kerberos world, with 3DES > cross-realm keys set up decades ago that everyone is afraid to touch :) > (It turns out that most of the time you don't actually need to get both > administrators in the same room to update things, and it can be done > asynchronously and asymmetrically, by one administrator at a time.) That requires clue that the current operators (no longer/don't) have. If it breaks, they don't how to fix or debug it either. In short: as Tero has pointed out it's already SHOULD NOT, and making it MUST NOT makes existing deployed products out of spec. I guess we don't have to rush. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl6eUNEACgkQgItw+93Q 3WUloQf6A/qvPt2Z4Q1Tv9qDhTKEWGxGSgUYXHGS+JPpungeX7K3tD9Qfopc4OQ7 pK132E9a/rEpeU3ia/PrSFYNB4UUQMVTLrWwqA6+aSSS89jmA+nF5kGsMOVLPaOU z1OwcThEBPxFvF8ehso+JpY2k1w1379+NwTnMoHiPeBTOtEiofeu+XF2MKl09yWN kjVzIbRQAvTTkw+SKqKZJKq4Y/Uw+hoXgaZ8vQyRk9iIpOg1TyHR7cY690rNEf8t xzRaTvy0hlehves4p0VTuj5CfUciPg7YUyteGi61nMXY7yL5fElQQq9+jiWXJKM5 sc7xLBKql7cPNVaf9xZ+bp30WNuUFg== =SJTI -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Apr 21 08:58: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 CB1C33A0D31 for ; Tue, 21 Apr 2020 08:58:31 -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, DKIMWL_WL_HIGH=-0.001, 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=blackberry.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 C_ystQv-awa3 for ; Tue, 21 Apr 2020 08:58:27 -0700 (PDT) Received: from smtp-pc11.blackberry.com (smtp-pc11.blackberry.com [74.82.81.43]) (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 811F83A0D95 for ; Tue, 21 Apr 2020 08:58:22 -0700 (PDT) Received: from pps.filterd (mhs401cnc.rim.net [127.0.0.1]) by mhs401cnc.rim.net (8.16.0.27/8.16.0.27) with SMTP id 03LFv12i040243; Tue, 21 Apr 2020 11:58:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blackberry.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=corp19; bh=lPMFYieaKwJixKdcN8MmdTivLJP/T3MQ3rd77sU2q2I=; b=cGw3eUs7VDNNLj1JbuVWVAkSiddg51elz9i10ckf9S9GCR8kSosoWhMqJ3ZrAG9n9Xzr IOcxTJdRAHHHdBUdg1vgzAUVWWIrZLb1dyXJod3uJzshGruiqRGdrOssoicF5dW/LE07 rr5gOG3Bqh0OftgaDv6z7ye6tmF2MPIiTlfNPASo8hha/vLIGqCHBotHXehkeBl8w89/ 0Na8ZKIeHPDbzeokezPUyeFJMR6Rb7IANJ1CKhy5VRygpvdSxL4uTgiLWjp9ohrDzK3T w/8y5VV7NsfUbZKQ/QPFzFALN9ln1fliuJd8wr5CQlC+w/xrzxmwRSgn/z4sKTNb1M3t mA== Received: from xch211cnc.rim.net (xch211cnc.rim.net [10.3.27.116]) by mhs401cnc.rim.net with ESMTP id 30hc49jrbp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 21 Apr 2020 11:58:13 -0400 Received: from XCH210YKF.rim.net (10.2.27.110) by XCH211CNC.rim.net (10.3.27.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 21 Apr 2020 11:58:13 -0400 Received: from XCH210YKF.rim.net ([fe80::81ca:ad34:fc3:5ce8]) by XCH210YKF.rim.net ([fe80::81ca:ad34:fc3:5ce8%5]) with mapi id 15.01.1913.007; Tue, 21 Apr 2020 11:58:13 -0400 From: Dan Brown To: Robert Moskowitz , Tero Kivinen , Benjamin Kaduk CC: "ipsec@ietf.org" Thread-Topic: [IPsec] revisiting 3DES and -graveyard Thread-Index: AQHWEst8EfG72jk5fUKJywPnzV1tI6h6ZfCAgAPRi4CABYULYA== Date: Tue, 21 Apr 2020 15:58:13 +0000 Message-ID: References: <20200415021321.GI88064@mit.edu> <24215.701.417106.744293@fireball.acr.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [100.64.97.2] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0015_01D617D4.1AFB9810" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-21_06:2020-04-20, 2020-04-21 signatures=0 Archived-At: Subject: Re: [IPsec] revisiting 3DES and -graveyard 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, 21 Apr 2020 15:58:33 -0000 ------=_NextPart_000_0015_01D617D4.1AFB9810 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Minor points about 3DES below (likely redundant). > -----Original Message----- > From: IPsec On Behalf Of Robert Moskowitz > > Just as an aside thought about 3DES: > > perhaps you saw my questions to the CFRG list where I have exactly 64 bits > to > encrypt and no place for an IV or such. > > One of the serious suggestions WAS 3DES with 3 keys. > [DB] Yes, but "serious" is not the right word. Also, just to be super-clear, this was not a CFRG suggestion! > > But for only 64 bits to encrypt, 3DES is a consideration. > > Nah. [DB] Last week, I looked up what NIST documents say about 3DES. https://csrc.nist.gov/publications/detail/sp/800-131a/rev-2/final If I read them correctly, this document implies something like: - NO: new deployment of 3DES - OK: old deployment of 3DES encryption, until 2023, then NO more 3DES encryption. - OK: old deployment of 3DES decryption (e.g. to decrypt archived stuff). Not sure how much IPSec wants to follow NIST. Presumably they do for 3DES, since 3DES is NIST's? The text below sounds to me like IPSec is already trying to do something along the NIST guidelines. (So, info above I wrote above is already well-known to IPSec.) > > One of the problems is that we as an IETF give instructions to > > implementors, not to users. If we change 3DES MUST NOT, then all > > implementations out there who do implement 3DES, but where it is > > disabled in configuration by default are no longer conformant to the > > new RFC, as they do still implement 3DES. > > > > Anybody who puts 3DES in any of the new implementations or new > > releases of the current implementations are going against the SHOULD > > NOT in the current RFC. > > > > Meaning they most likely have some old legacy stuff they need to > > support which only supports 3DES and thats why they want to keep 3DES > > in their current releases as they want to be able to talk to those. > > > > I would wait bit more than 2.5 years before saying MUST NOT. > > > >> In particular, would a general-purpose OS's implementation cause > >> problems for its consumers if the next release dropped support? > >> (Noting that consumers could stay on an old OS release to match the > >> old algorithms, at least for a while.) > > Especially with consumers and general-purpose OS there is no option > > for using old OS release anymore. Most of those will automatically > > update to latest version, and there usually isn't any easy way to > > downgrade back to previous version when issues are found. ---------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ------=_NextPart_000_0015_01D617D4.1AFB9810 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCFp4w ggXJMIIDsaADAgECAgUA9lfgwDANBgkqhkiG9w0BAQ0FADB8MQswCQYDVQQGEwJDQTEbMBkGA1UE CgwSQmxhY2tCZXJyeSBMaW1pdGVkMSIwIAYDVQQLDBlCbGFja0JlcnJ5IEVudGVycHJpc2UgUEtJ MSwwKgYDVQQDDCNCbGFja0JlcnJ5IEVudGVycHJpc2UgUlNBIFJvb3QgQ0EgMTAeFw0xMzEyMTMx NzQ1NDdaFw0zODEyMTMxNzQ1NDdaMHwxCzAJBgNVBAYTAkNBMRswGQYDVQQKDBJCbGFja0JlcnJ5 IExpbWl0ZWQxIjAgBgNVBAsMGUJsYWNrQmVycnkgRW50ZXJwcmlzZSBQS0kxLDAqBgNVBAMMI0Js YWNrQmVycnkgRW50ZXJwcmlzZSBSU0EgUm9vdCBDQSAxMIICIDANBgkqhkiG9w0BAQEFAAOCAg0A MIICCAKCAgEAxkXAf/EHxa1okuoiPnKhHeaDfSRXq35g7JH34MqiM2cxMsL+WMe/8792DLEAe5Lm FLURmrkBiqwgzkrpejF1WBUaqrM0nGSkxTfO9ywXFHKZnK2wyxE+uNdIN5KzuzijEFJpnHxapdJg k8VmsgSnn+wTyRF8J/2DsaKV7UPYNkoGGZtCggI6Dh92G9AUKzZBSjfaZRfwStEv26wVgM8CiqSa O2FuwYriu+To03yDNiC0XOaGbPLyPAdyJbY71Bud3RQE1wciQV0nLwXnyCBmDK127NkjdewY4nAF TVuKaTVCqAdGKRo5idywpSHknZy01AvOJNuvL/BkN9Nv9nflelSml5TJNhfSa2hDRmHvr0+Jns+A qORC2WlvCybRGHkmTjpYLLMnIVprNBWPCCE6B/RaoLvcTvDeUwBVoqYzLSfLT6jAoXVcJM+XT948 TzAgCKcJg4oupgiMtYyL/oktajJbnpiLtRZ3jRX2hEgRW8tJZckvlxtrBGxQLYWNVe48OdBhbNnO bByGN2o0/GAttfkM8WrdjnCNv5YZ1d1eZPqCJicQ7ML4xRzUPwD1u7YvgdVRFidB3CsxM9nnlnam MYWQIV5nUuyK/1NUTiAEhGBYOsLeemgvPz41TsjERujbzHcj8MM3zMdwhWr86Dp1292C/bwyNgMm OfVgsHnZRnECAQOjVDBSMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQW BBT4aYn4Y57vaF6BMGJwUqMO3bKWCDAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG9w0BAQ0FAAOC AgEArBVGo/mS9/+yWzGI03ae5osTFt3v2acQVj1OrqSABZQXTdOXjJL31Q4QJABZlwllzKeIlFne 3c9yn39i3QMhoSjqkn4NjbPjKiiyzOLoI0PGq5UTQtpGm7X/EaXkcYDFhrIHnGfC9dmB5WeuwMwX fmKwUtiLPhgtgjGBqkxSOiFFbBUBiLGs/muE4IYbKJGPKqilOBLpeK1Kyp8zXIrJLLQ0zzkK6TkQ x6RULQ+px3geS5UWkrsFXCHK/x9vBxH313O7RV7vvwt2Opc0HFw9LzF50jie/wqx9HD3tm0GgvqD Aabtlao1V1mfLpk8k+nrWd589ZZSHmQMVFvzETnrS0BS4wZssImORAbv6tVCHZSf6gu1XApnxMaM Hy8qmL9lfkoTaxF7cxzzwrj5P49Xj+n4NZT95GyYNAoU3AhAFrQV+H6BXFTOHNX/ALubYWg5x+xu JFi+7HTcaCjZzjSGLWG3kilqn6JkT229jgYClzN8EylemXv3yz1vVjXbTRZNDK9G/p1Jj2SxlBC/ mTBvedATbkIMVm5Wzl8cE3rIp+A9lZ+bS9CfVx5OthHQxXn0fuVCakWp4a+KTsTtFlqbtVMesdcU Q1uMk8Tap11X43bkAyX25l76ejxuVCZYZaOxZFt689bVqRFh4DjyfagCRu65eQgOu013aZiAc28i WCEwgghfMIIGR6ADAgECAhN8AAAtTl4y8yLDoDw8AAAAAC1OMA0GCSqGSIb3DQEBDQUAMFoxEzAR BgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xLjAsBgNVBAMTJUJsYWNrQmVy cnkgQ29ycG9yYXRlIFJTQSBJc3N1aW5nIENBIDMwHhcNMjAwNDAzMTg1MjE1WhcNMjEwNDAzMTg1 MjE1WjCBqTETMBEGCgmSJomT8ixkARkWA25ldDETMBEGCgmSJomT8ixkARkWA3JpbTENMAsGA1UE CxMEQU1FUjELMAkGA1UECxMCQ0ExFDASBgNVBAsTC01pc3Npc3NhdWdhMQ4wDAYDVQQLEwVVc2Vy czESMBAGA1UEAxMJRGFuIEJyb3duMScwJQYJKoZIhvcNAQkBFhhkYW5pYnJvd25AYmxhY2tiZXJy eS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDS9EruyZQmNb+gtO9Ki7JH5kFJ ng5Y2bztcEqCB0THjGcu0fRrAym0W+OPW1PfmH1Q0tmYGhKDkxOHyxe9/cnLgLEsVFKtoTN7EpJO Z1EBE4G/Jn/UeRtv2iFp/e7tOpI9LBbkbVOfHAwCVkx4ZA3mzv1P1FsKSomINNFs2E/Gg5n+Ml8G rO067W94t7IUL/MLyU/R8ooldqpjw4JJGcgEHlqFCMee1cufQqgv1o62LzCYAruHyBx5Xkkv0XvB eYMiCVS+lKlWC4E/V8mRiQxcs/k/ntG/1Gr4Te5Uhc+gomFWQ4p34FnrLVNtYpn0kgVyUX8/bfWw x2Eul3SJVoeZAgMBAAGjggPMMIIDyDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiHv5dLhrmB JIbBgTKD2/IlgtzYAYEA+ox9gcuuUQIBZAIBEzATBgNVHSUEDDAKBggrBgEFBQcDBDALBgNVHQ8E BAMCBsAwDAYDVR0TAQH/BAIwADBPBgNVHSABAf8ERTBDMEEGCisGAQQBm0oTFAMwMzAxBggrBgEF BQcCARYlaHR0cDovL2NwLnJpbS5uZXQvQ1BTL0NQU3RhdGVtZW50Lmh0bTAbBgkrBgEEAYI3FQoE DjAMMAoGCCsGAQUFBwMEMB0GA1UdDgQWBBTvAdV+R+3Qcn5rED5jj5u3fWNsUjAfBgNVHSMEGDAW gBRs0YtrknGE8G2HSz6tNwEU9cWjKzCCAUAGA1UdHwSCATcwggEzMIIBL6CCASugggEnhoHbbGRh cDovLy9DTj1CbGFja0JlcnJ5JTIwQ29ycG9yYXRlJTIwUlNBJTIwSXNzdWluZyUyMENBJTIwMyxD Tj1NQ0FVMDAxQ05DLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNl cyxDTj1Db25maWd1cmF0aW9uLERDPXdpbmRvd3MsREM9bG9jYWw/Y2VydGlmaWNhdGVSZXZvY2F0 aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50hkdodHRwOi8vY3Js My5yaW0ubmV0L0JsYWNrQmVycnklMjBDb3Jwb3JhdGUlMjBSU0ElMjBJc3N1aW5nJTIwQ0ElMjAz LmNybDCCARQGCCsGAQUFBwEBBIIBBjCCAQIwgdAGCCsGAQUFBzAChoHDbGRhcDovLy9DTj1CbGFj a0JlcnJ5JTIwQ29ycG9yYXRlJTIwUlNBJTIwSXNzdWluZyUyMENBJTIwMyxDTj1BSUEsQ049UHVi bGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5k b3dzLERDPWxvY2FsP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9u QXV0aG9yaXR5MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC11c2VyLmR5bi5yaW0ubmV0L29jc3Aw TQYDVR0RBEYwRKAoBgorBgEEAYI3FAIDoBoMGGRhbmlicm93bkBibGFja2JlcnJ5LmNvbYEYZGFu aWJyb3duQGJsYWNrYmVycnkuY29tMA0GCSqGSIb3DQEBDQUAA4ICAQC3YoZ/NDdWJ7HwVsqFtXSd qqk5N36J2tCSbaWMImQOAQWM3FjZ74HlqK6A5+n1L97o3H0NucFh+J1koyecQLdvoYRqBUtcnPtH g2Yl4zVG+8sgi+FLFhLdRE1TFRjQgoUCR930Um97w9MKjkYEEs+4WQqNVno90BE3h0vDB+3BEJ6b xrFenxhIEWxWCyUs17PGlF+Z6M2Cjn+sUeZ9fhTet6htOGM9Qwdv3Jqn+11WPzZ0mx7Y66yvCTDU sGj5gFyel5VZf8HILSzS+xLeQLrbIcSP2GjkziMSEclWGCduRdNQ6lvwPyHhNZOlRZ1OQo5BmAzH QRTbDgbV+1KEF59q/K/4tF4p8mxSX4vfXF6nYrW+ZZiBde6p7gzirIQ3w9AEqKsV44gXa0nKXmPq CbUGFDqnZfnpoh8Qzmvq6AkeNzxChzvUqetdDz0VSXUl1Un6HH1nddqh4cfBYOsrHnDRH/7cdHt9 m2EztqwBgJHIa6LviPGrIUiVZZk6XPHl0EgQsnDWqYQrL/PeBRzV2YUNKh7MDH+ZSN9OzTwxMShH dwI0SXRxBRrR5gLMbcr749K4LOSqgkXWCgItReNEGE45kJJuLKShsEjszfLfLItKAJdV+U5v+EtO W/fe2CvLLZKTdYWsHpl0NFfUyEs11VR3ygRHFwlffNtiP9QSLy9yDTCCCGowggZSoAMCAQICBEMV YiMwDQYJKoZIhvcNAQENBQAwfDELMAkGA1UEBhMCQ0ExGzAZBgNVBAoMEkJsYWNrQmVycnkgTGlt aXRlZDEiMCAGA1UECwwZQmxhY2tCZXJyeSBFbnRlcnByaXNlIFBLSTEsMCoGA1UEAwwjQmxhY2tC ZXJyeSBFbnRlcnByaXNlIFJTQSBSb290IENBIDEwHhcNMTkwMjA1MjEyMzUxWhcNMjQwMjA1MjEy MzUxWjBaMRMwEQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmltMS4wLAYDVQQD EyVCbGFja0JlcnJ5IENvcnBvcmF0ZSBSU0EgSXNzdWluZyBDQSAzMIICIjANBgkqhkiG9w0BAQEF AAOCAg8AMIICCgKCAgEA3ISRAnwqdZJeJfgSe6vpen977nOzY8JIsBRxrvm8Uai16mVl1Yy9spNS z9zTnCK4iwJsot0fOJMBiaMT4deYlKhTtPygAqso6llqyM0dKvd6Ez8K/ceV8fdR6zypzU9x8h7v fFkvaYJSPRkyyvdU8YGJ9iBLhBVGB3EI81y6IyqLhYhzZN9FbNAutU5y69QuvGS5n1RrtM03jgWu qqNceDW4JtsKl2bN9AC8YU5EUO2u3r4dRd2C1UWAgw9F22LFkages0iKJ772W/m7BDVjmetQWdT/ hi+wlfiBZjLJN1i8MM0uuIH0Fnv4tiiJTUtwpkdjH9iw3JIg/057tFOIypS3vVHQA5GJ75tS3LQj LYOym8KxOp/sLLKSLTnG1zxq8zyEvXd9vCpmjQd8P7cT3aKV0yZSoruoa75KmJZLqd9UR+12TKh1 z/h0uhedOivw8xpoYc+usf28k7BkWJ1lQc9uPhcibFC9duIu4+M14ftKFvRVyQsoLMfmyCi9Jmdo JC1BAq9TGkTCqGUyn/1mEeFLP9XtdlOhJX+ItTP6VLbgBOx1nTqQFvuVCYC7QUBOxbaDHTCJbKac Qz1YdhUgxDbqwJEODvIQ8zejYtGfBM9Hwil8AuYD/05MgcqPNi7CfasHiDHEk/iMAAHVrbsZG798 KBoL1Ih8nYi/da4mV7kCAwEAAaOCAxQwggMQMBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/ BAQDAgEGMB0GA1UdDgQWBBRs0YtrknGE8G2HSz6tNwEU9cWjKzAfBgNVHSMEGDAWgBT4aYn4Y57v aF6BMGJwUqMO3bKWCDBgBggrBgEFBQcBAQRUMFIwUAYIKwYBBQUHMAKGRGh0dHA6Ly9jcnQucmlt Lm5ldC9CbGFja0JlcnJ5JTIwRW50ZXJwcmlzZSUyMFJTQSUyMFJvb3QlMjBDQSUyMDEuY3J0MIIB NwYDVR0fBIIBLjCCASowggEmoIIBIqCCAR6GRGh0dHA6Ly9jcmwucmltLm5ldC9CbGFja0JlcnJ5 JTIwRW50ZXJwcmlzZSUyMFJTQSUyMFJvb3QlMjBDQSUyMDEuY3JshoHVbGRhcDovLy9DTj1CbGFj a0JlcnJ5JTIwRW50ZXJwcmlzZSUyMFJTQSUyMFJvb3QlMjBDQSUyMDEsQ049Um9vdENBLENOPUNE UCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9u LERDPXdpbmRvd3MsREM9bG9jYWw/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVj dENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIHfBgNVHSAEgdcwgdQwMwYKKwYBBAGbShMUATAl MCMGCCsGAQUFBwIBFhdodHRwczovL2NwLnJpbS5uZXQvY3BzLzAzBgorBgEEAZtKExQCMCUwIwYI KwYBBQUHAgEWF2h0dHBzOi8vY3AucmltLm5ldC9jcHMvMDMGCisGAQQBm0oTFAMwJTAjBggrBgEF BQcCARYXaHR0cHM6Ly9jcC5yaW0ubmV0L2Nwcy8wMwYKKwYBBAGbShMUBDAlMCMGCCsGAQUFBwIB FhdodHRwczovL2NwLnJpbS5uZXQvY3BzLzAQBgkrBgEEAYI3FQEEAwIBADAZBgkrBgEEAYI3FAIE DB4KAFMAdQBiAEMAQTANBgkqhkiG9w0BAQ0FAAOCAgEAG+Ro3/lYZMVkEiFocDjNPdMFpcohlYQN W023fMW3OuJoJ0ngkLCdcQoNGzZ3S60nzibXFkuFEF3HNAwqFcFTDapeGk9nPehF9o4MfLhJhn/L 3QZiCpgCGbTdPZazxjOwWjA1r/lwVT1wjrhZ4Hmj+GiUpVytrKeEs2zMzx2hQ1M0iXUSGz4KPzgZ 3ez9qq1xcqqskAhD+YNLovCH18KmXLfX8fkcELx8AxDCazjwgmrjWWs9LK/2Y6os16v9cOYIXIsj dhdq7HbdRtSX8GTghxEmInheWNzTd2z9lhRaE82aYkoCI8ivfQysjKDlcD+5LZiGoF7vT/8W53E4 w5OoykXNcuvHh2ByiWrqtnMNf//Awu9gg+fdDl4yV8MNbGrBDPjsxTpaKBtWmQHJVQ4lMwnA/MDZ 1mDbT5ZmnCb9hCxlVZkCeV5GzKGU7Tu47D8WfKfkGErNwMQuWbJ0a3pVBDrl34IF6B3V+pqnB8uY lLAQIXvXYtoVW+aHe5FnwmqomfgjTIiU/2fg9uBYwAaZSQN6YFDeKEcmGTP9r72Apa3cc/ui+mUR GBVFLJpGhADjSdOhzQVjmObsDU+DleTqIMkVkBF/izXYWLbSFfDjylR/MXdlau2acP9RZBitMyR3 kLAQNRmIYPzDeE6EKrUxpDBRDnAX53UY0cr64/qYIYkxggJJMIICRQIBATBxMFoxEzARBgoJkiaJ k/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xLjAsBgNVBAMTJUJsYWNrQmVycnkgQ29y cG9yYXRlIFJTQSBJc3N1aW5nIENBIDMCE3wAAC1OXjLzIsOgPDwAAAAALU4wDQYJYIZIAWUDBAIB BQCggaowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwNDIxMTU1 ODAwWjAvBgkqhkiG9w0BCQQxIgQgG+N8dWV0g0uq46D20t1YmSrKwO/Jzhh4ABl6nKpEIl0wPwYJ KoZIhvcNAQkPMTIwMDALBglghkgBZQMEAgEwCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjAHBgUr DgMCGjANBgkqhkiG9w0BAQEFAASCAQDIFV4+0Li+ZCPhD44onZ3AZQfn2vDRGoqSeKn2lyEANVxh wWDVzxuEN8wC+V3xtLyS0fhsHMUFmFnE/iF8+6u5yujOVNszorPWd8yrSBfD0DO0PvmIZlRglhqw QHnYnXvRbWkq3FnASA6bUIGv2a2DKuwPQzi/kf8Ne5Cwxi/zeogjoJIF1MSI37Jw7ZEiOGG2bSq6 URRaUr1+WrsQzK7TxOSv5zbIXJ+yKaKPEmGiwcMz/YAhdeK+PVqRt9GdEJK0cOgjBYzaR9KUUjBv zVRVoSNo5/2twkqXWUw/TdPQpZNYEIU1oPlHVg4fVtl3+UpSUect6kVU/WYZ2qemR/26AAAAAAAA ------=_NextPart_000_0015_01D617D4.1AFB9810-- From nobody Tue Apr 21 10:43: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 75A223A0885 for ; Tue, 21 Apr 2020 10:43:03 -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 QjQFWVjAHRQv for ; Tue, 21 Apr 2020 10:43:01 -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 9F2533A0884 for ; Tue, 21 Apr 2020 10:43:00 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4969rc0Q8WzF7f; Tue, 21 Apr 2020 19:42:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1587490976; bh=9q+DtdPunks3haMuyi1HYM/nFRnlZECl4rXpa1PKmyI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=arm012iTW9jUJ0eqlyXIm8nLOuI9xwiCWegCZU/Pia0VXLQqoTKwe4789inlbKIm/ FqlXqgqKYveIX+dcryzHkWwcrxwnYq1u7a/u/VPRv5Uq9E5/oWWz48em30OiVfnm+x yV1Y5PO1W4x4o8f2WdO8wCW7BMsK+54wi81hxEWo= 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 vVn9Jz4RSdqA; Tue, 21 Apr 2020 19:42:54 +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, 21 Apr 2020 19:42:54 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id A7333600125C; Tue, 21 Apr 2020 13:42:53 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A36A566B25; Tue, 21 Apr 2020 13:42:53 -0400 (EDT) Date: Tue, 21 Apr 2020 13:42:53 -0400 (EDT) From: Paul Wouters To: Dan Brown cc: Robert Moskowitz , Tero Kivinen , Benjamin Kaduk , "ipsec@ietf.org" In-Reply-To: Message-ID: References: <20200415021321.GI88064@mit.edu> <24215.701.417106.744293@fireball.acr.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] revisiting 3DES and -graveyard 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, 21 Apr 2020 17:43:04 -0000 On Tue, 21 Apr 2020, Dan Brown wrote: > [DB] Last week, I looked up what NIST documents say about 3DES. > https://csrc.nist.gov/publications/detail/sp/800-131a/rev-2/final > If I read them correctly, this document implies something like: > - NO: new deployment of 3DES > - OK: old deployment of 3DES encryption, until 2023, then NO more 3DES > encryption. > - OK: old deployment of 3DES decryption (e.g. to decrypt archived stuff). > Not sure how much IPSec wants to follow NIST. Presumably they do for 3DES, > since 3DES is NIST's? > The text below sounds to me like IPSec is already trying to do something along > the NIST guidelines. (So, info above I wrote above is already well-known to > IPSec.) There is also the SP800-77 rev 1 draft "Guide for IPsec" https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-77r1-draft.pdf Which puts 3DES (TDEA) into the "Legacy" category. It also states: When migrating from IKEv1 to IKEv2, an upgrade of the algorithms used is strongly recommended. 3DES, MD5, SHA-1 and DH Group 2 and 5 should not be used. The Triple DES (3DES) encryption algorithm is no longer recommended. It is much slower than AES-GCM and AES-CBC, and it requires more frequent rekeying to avoid birthday attacks due to its smaller block size of 64 bits. Paul From nobody Tue Apr 28 02:54:57 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85DE3A1212; Tue, 28 Apr 2020 02:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRIhPfvI7_ZH; Tue, 28 Apr 2020 02:54:55 -0700 (PDT) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC58B3A1210; Tue, 28 Apr 2020 02:54:54 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id y3so748638lfy.1; Tue, 28 Apr 2020 02:54:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=lUzjd0UEkPm1lRGFeGR2y4+pw8+UhRG6y1qm/4EvDSo=; b=kNONYapGyL46WNy2ORGFaAziI5yhPdW+AYjx+k1lGpKR28oaKVggwHQPBnCyhXUppU jzwUCUi0wzbhqC1v73xdXTgJ8u2B7cZU9pkcYeAU/0jDTHO33rT2Y5ejgZ6BW8vlMUz2 PaLuiYHV3VZ8XbBzQF10kILx5BSmn7xVobvihycC7ez8jQKOz1o4hZdKWIWioswC/c8z 9KhX6atRIYPy31yiN44L+yYOGjZA1bIngp6EOUfmQkIqQb92ohk5la0E6AvZycs4Fjzc NI12kweMlqsUornH2cf4uHWvwPnCgxfmKnahJ4DNsC6u2xTq9NyV3oM7hl17rEu+hTJW 0tCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=lUzjd0UEkPm1lRGFeGR2y4+pw8+UhRG6y1qm/4EvDSo=; b=NQLHN/rIyO2VhtRK0y8nQrQ+isWNasNov5iQoOBjUTRnLCN5765TvJ2GWkUvXi/s7m EZGpU/T5mJ6vhiBzh1iIfE8uxEcwTS4IVQY/fsVl6gkohtD/7ptcRCDRTyW1lRezSHET D08QifQimaWZB8mnZAd1iFT/O4OnV9wZwBXAEtIUFBN1FIfc3w8meOM1T0TwGU3rZ3CD CuAHT/hn1uizMoNBIAgZHgTmso2LJCuJxtN4hvUdJ3KCgQZuhaM+tkZl0W04DOA5vNCA JLfCT1TfKaDdEdQAS4DwA0aBsNVm7SBJASiWKecHdEsYq9a13O1uq7ODdYmLYIEppW/X suKQ== X-Gm-Message-State: AGi0PuY73VAKx9OKcBI3GCyAR+jwW1uZ6QAp+A4OSJ6xzh5jqLSr2Xro //53lFD0XLwGssNICdbscFgpsBD2 X-Google-Smtp-Source: APiQypJ0To83PCic0PZB4jvs8BBKV5bQeVy7acX7RwrGy7+pnKX3OFZA0M+sM4zWC82YScn/zEAFqQ== X-Received: by 2002:ac2:57cc:: with SMTP id k12mr18068017lfo.69.1588067692435; Tue, 28 Apr 2020 02:54:52 -0700 (PDT) Received: from svannotebook (95-27-147-103.broadband.corbina.ru. [95.27.147.103]) by smtp.gmail.com with ESMTPSA id s27sm12078857ljo.80.2020.04.28.02.54.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Apr 2020 02:54:51 -0700 (PDT) From: "Valery Smyslov" To: Cc: Date: Tue, 28 Apr 2020 12:54:49 +0300 Message-ID: <0b5201d61d43$0f16dfe0$2d449fa0$@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: AdYdQKpf169Cj9ucQkeiClQsqb56ag== Content-Language: ru Archived-At: Subject: [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: Tue, 28 Apr 2020 09:54:57 -0000 Hi, a one and half year ago at IETF 103 in Bangkok I presented draft-smyslov-ipsecme-tcp-guidelines "Clarifications and Implementation Guidelines for using TCP Encapsulation in IKEv2" (https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-tcp-guidelines/). >From my recollection of the meeting and from minutes it was a general feeling in the room that this document was useful for implementers, since it clarified some subtle issues that were not covered in RFC 8229. However, at that time no adoption call was issued since this work would require to update the IPSECME charter. It took over a year to adopt the updated charter and now the WG is chartered for this work with this draft as a possible starting point. The text in the charter: RFC8229, published in 2017, specifies how to encapsulate IKEv2 and ESP traffic in TCP. Implementation experience has revealed that not all situations are covered in RFC8229, and that may lead to interoperability problems or to suboptimal performance. The WG will provide a document to give implementors more guidance about how to use reliable stream transport in IKEv2 and clarify some issues that have been discovered. However, since it was so long since the WG last discussed the draft, the chairs asked me to send a message to the list to determine whether there is still an interest in the WG to proceed with this work with this draft as a starting point. Regards, Valery. From nobody Wed Apr 29 06:52: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 219E33A10F2; Wed, 29 Apr 2020 06:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=apple.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 wkyk91XM2A7F; Wed, 29 Apr 2020 06:52:44 -0700 (PDT) Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.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 79D413A10B0; Wed, 29 Apr 2020 06:52:44 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.42/8.16.0.42) with SMTP id 03TDYb1p054545; Wed, 29 Apr 2020 06:52:43 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=cB42dAaiqp/coIV1vZtWCLBYGkMZBy7+YDsk8N7OCh8=; b=SQ/tQiYJkcImO+hArxuMEhmN2zNPSx+iAcCOFgzVsRcp+wNsJssActoVdYduC6v4thgw 9tYe0fxQ45bWR4eIKcL15OLWCe1nF6eWHZ79CVdV9vI6BIsCNSRAoShxF3zE/4RPuWMw wzwopXe366BTL3cDqAtUkSHmZS2urpYwMSU6moxSECB4haspnKdQW7+geB/5vzbktN+g QKMq+S9LvbNMlQTT9LuI/55EV3TjXSx8zRRrjBAH48QzLFDpDroyQeGzdP/c4MuRqQn8 0B3ZuwMgtgphOZzEXXovqPLCd9LpFPYtm7IJ5rLwmVmZEjONYbfih0kD26ie0f+i8BTR Qw== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 30mhvtt41m-9 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 29 Apr 2020 06:52:43 -0700 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0Q9J00XAGYJS84A0@rn-mailsvcp-mta-lapp03.rno.apple.com>; Wed, 29 Apr 2020 06:52:40 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0Q9J00100Y3PJL00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Wed, 29 Apr 2020 06:52:40 -0700 (PDT) X-Va-A: X-Va-T-CD: 87ff8731591aecd9d6170308e7326a5f X-Va-E-CD: a35f54d2a9693656dea9dadbb15eb9f7 X-Va-R-CD: 264144e85cfb2c155bd4e356d0b79219 X-Va-CD: 0 X-Va-ID: 471b039f-1f30-426a-b97a-a62dfac9e300 X-V-A: X-V-T-CD: 87ff8731591aecd9d6170308e7326a5f X-V-E-CD: a35f54d2a9693656dea9dadbb15eb9f7 X-V-R-CD: 264144e85cfb2c155bd4e356d0b79219 X-V-CD: 0 X-V-ID: 2a1f65c7-d727-480b-9c54-4c92ab5dba2d X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-29_05:2020-04-29, 2020-04-29 signatures=0 Received: from [17.235.27.84] (unknown [17.235.27.84]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0Q9J00DD0YJRRI00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Wed, 29 Apr 2020 06:52:40 -0700 (PDT) Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\)) From: Tommy Pauly In-reply-to: <0b5201d61d43$0f16dfe0$2d449fa0$@gmail.com> Date: Wed, 29 Apr 2020 06:52:39 -0700 Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org Content-transfer-encoding: quoted-printable Message-id: <53F12987-8F6B-46B7-831C-A4185E2B3805@apple.com> References: <0b5201d61d43$0f16dfe0$2d449fa0$@gmail.com> To: Valery Smyslov X-Mailer: Apple Mail (2.3608.80.7.2.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-29_05:2020-04-29, 2020-04-29 signatures=0 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: Wed, 29 Apr 2020 13:52:50 -0000 Hi Valery, Thanks for bringing this up again. Would you be interested in making = this an RFC8229bis instead? I think it would be most useful for an = implementer to fold some of these clarifications into the main text = itself. How do you feel about that? Best, Tommy > On Apr 28, 2020, at 2:54 AM, Valery Smyslov = wrote: >=20 > Hi, >=20 > a one and half year ago at IETF 103 in Bangkok I presented > draft-smyslov-ipsecme-tcp-guidelines > "Clarifications and Implementation Guidelines for using TCP = Encapsulation in > IKEv2" > = (https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-tcp-guidelines/). >> =46rom my recollection of the meeting and from minutes it was a = general > feeling in the room that=20 > this document was useful for implementers, since it clarified some = subtle > issues > that were not covered in RFC 8229. However, at that time no adoption = call > was issued since this work would require to update the IPSECME = charter. > It took over a year to adopt the updated charter and now the WG > is chartered for this work with this draft as a possible starting = point. > The text in the charter: >=20 > RFC8229, published in 2017, specifies how to encapsulate=20 > IKEv2 and ESP traffic in TCP. Implementation experience has=20 > revealed that not all situations are covered in RFC8229, and = that > may=20 > lead to interoperability problems or to suboptimal performance. = The > WG=20 > will provide a document to give implementors more guidance about = how > to use=20 > reliable stream transport in IKEv2 and clarify some issues that = have > been=20 > discovered. >=20 > However, since it was so long since the WG last discussed the draft, = the > chairs asked me to=20 > send a message to the list to determine whether there is still an = interest=20 > in the WG to proceed with this work with this draft as a starting = point.=20 >=20 > Regards, > Valery. >=20 >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Apr 29 07:47:13 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD313A1226 for ; Wed, 29 Apr 2020 07:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0j9l1bh1uwyx for ; Wed, 29 Apr 2020 07:47:09 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 380B53A1225 for ; Wed, 29 Apr 2020 07:47:09 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 49C1Z25qyjzDdK; Wed, 29 Apr 2020 16:47:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1588171626; bh=XgB/llWPmuv7DpxLXfTJ1RRz8T6xmw8004C4WQexlUE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Az2IxNDf+b8BOfBYTYrQoDGZZoQTlNaIWhl3N/tCP5unKxrWOeMWdoe9KJnwcQ1dm rLoPrTerQd1WmJVGfTKKOjrg+P4RKxOScW+oEXSSlzSXM16mMggArUp+yHa2aNPp05 O9bJDaAI972Or2TijP5oTSsv7pqhwcR3XO0hW/D8= 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 zed92hFRHstt; Wed, 29 Apr 2020 16:47:05 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 29 Apr 2020 16:47:05 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 0FE8A6020D59; Wed, 29 Apr 2020 10:47:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0ED5823D186; Wed, 29 Apr 2020 10:47:05 -0400 (EDT) Date: Wed, 29 Apr 2020 10:47:05 -0400 (EDT) From: Paul Wouters To: Tommy Pauly cc: Valery Smyslov , "ipsec@ietf.org WG" In-Reply-To: <53F12987-8F6B-46B7-831C-A4185E2B3805@apple.com> Message-ID: References: <0b5201d61d43$0f16dfe0$2d449fa0$@gmail.com> <53F12987-8F6B-46B7-831C-A4185E2B3805@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed 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: Wed, 29 Apr 2020 14:47:12 -0000 On Wed, 29 Apr 2020, Tommy Pauly wrote: > Thanks for bringing this up again. Would you be interested in making this an RFC8229bis instead? I think it would be most useful for an implementer to fold some of these clarifications into the main text itself. How do you feel about that? That might be better. We have also been working on the Linux and libreswan code for this, and have also gotten into a few corner cases that might be good to explain the implementors. Paul From nobody Wed Apr 29 08:42:42 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 34F8C3A1310; Wed, 29 Apr 2020 08:42:40 -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 YVzhBfkkcdwb; Wed, 29 Apr 2020 08:42:38 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A66173A1331; Wed, 29 Apr 2020 08:42:24 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id w20so3156490ljj.0; Wed, 29 Apr 2020 08:42:24 -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=LfBPPtO6BBMNOuWt40m5FxtQgpnjkHNwIno2RDpDmWw=; b=tyBDq1xgmLqF7OrnqHX84eYdUpwahgBaoXtWmDsKHtwlK0WJg2NnYb5ehhE0oMaX2S PZZLROteTz7R5sd2TR+ppT9L38Zq/9aiBV4oQ1xXnSkigpw2Gkk22XCb+l7zmbY7Ldag tbq5uInUw3fRGdm758UO1HgafnmmLoQvlTnZgaVFO9ODqy1/AfG3VFFhY+xEu1EQDc8r QiBBQvadeiwb36+MCJsamSweUK0acwYNoq3r4UQm1lgVsHibfERENtiC7XDTo9hyRHWU W2OEOsX4mr1/7JeaqOs8ASgfjVjiv1JzZdfaJTUUFb6bJ07YFarfIgWQJa4aSr9as++0 fHBA== 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=LfBPPtO6BBMNOuWt40m5FxtQgpnjkHNwIno2RDpDmWw=; b=AydYR6oVIVXpnOpVSgK1mSxN9FnOPoZP5ByERfv0bvLrKdDUrDEd1FVNe7rEnDm44P KbnP+Z7vpRlsaYvegrmGQWPtD/YYgH3qjofzoFn4I96HdP2ACZ1Gf21u8XKIHCdtOb5r Fdg61AZKOcZ1z5+BwN8y+m+cfV3YVVVcVrZgu4oUMpbSQr8oFE6TGD/RxUKsbQRe1Z/B I/jh4oXAPCUkeqlyXzjN5XtrgRHwHXERA/IqfUaJv0B/nf35YHr2p69dMn4lwh6AYn3d oK99Rux9Akfi8OfjnIJjQYV5J8KmZAT9srfqegTcWirE4uFYOZUJhSKTKoy9qB+9GEkV AVqw== X-Gm-Message-State: AGi0PuY9mdBWNMb1X/lrv6mCUwZtKYs8WDoh8ozcNXx7DuYDDlBIQHoi BERz+xo3Ck5SEc547Sgc7nh6HJs3 X-Google-Smtp-Source: APiQypJsMg85Dkk0bRaUS/zkaOzrcXUdMH5RPHBgMnAyrcs2h3SIYbSdvqzzYtLPX9CxSXOnsa0cIA== X-Received: by 2002:a2e:9e45:: with SMTP id g5mr22135343ljk.180.1588174942047; Wed, 29 Apr 2020 08:42:22 -0700 (PDT) Received: from svannotebook (95-27-147-103.broadband.corbina.ru. [95.27.147.103]) by smtp.gmail.com with ESMTPSA id u16sm2693671ljk.9.2020.04.29.08.42.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Apr 2020 08:42:20 -0700 (PDT) From: "Valery Smyslov" To: "'Tommy Pauly'" Cc: , References: <0b5201d61d43$0f16dfe0$2d449fa0$@gmail.com> <53F12987-8F6B-46B7-831C-A4185E2B3805@apple.com> In-Reply-To: <53F12987-8F6B-46B7-831C-A4185E2B3805@apple.com> Date: Wed, 29 Apr 2020 18:42:18 +0300 Message-ID: <007d01d61e3c$c43a8990$4caf9cb0$@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: AQJ4LbZ9m5c/82foCko2jbr+bIGR0wF6ZQFdp0BHrbA= Content-Language: ru 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: Wed, 29 Apr 2020 15:42:41 -0000 Hi Tommy, > Hi Valery, > > Thanks for bringing this up again. Would you be interested in making this an > RFC8229bis instead? I think it would be most useful for an implementer to fold > some of these clarifications into the main text itself. How do you feel about > that? I'd be happy to do it. I also think that a -bis document is more useful. The reason that this draft is not a rfc8229bis is that one and half year ago it was a general feeling that more experience need to be collected before -bis document should be issued. Now it is almost 3 years since rfc8229 is published, I agree that it's probably time to start preparing -bis. One concern is the current WG charter - it seems to me that it only allows clarification document and not a -bis. It is a question to our chairs and AD - are we allowed to proceed with rfc8229bis document with the current charter text or should we update it and ask for re-chartering? Regards, Valery. > Best, > Tommy > > > On Apr 28, 2020, at 2:54 AM, Valery Smyslov > wrote: > > > > Hi, > > > > a one and half year ago at IETF 103 in Bangkok I presented > > draft-smyslov-ipsecme-tcp-guidelines > > "Clarifications and Implementation Guidelines for using TCP > > Encapsulation in IKEv2" > > (https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-tcp-guidelines/). > >> From my recollection of the meeting and from minutes it was a general > > feeling in the room that > > this document was useful for implementers, since it clarified some > > subtle issues that were not covered in RFC 8229. However, at that time > > no adoption call was issued since this work would require to update > > the IPSECME charter. > > It took over a year to adopt the updated charter and now the WG is > > chartered for this work with this draft as a possible starting point. > > The text in the charter: > > > > RFC8229, published in 2017, specifies how to encapsulate > > IKEv2 and ESP traffic in TCP. Implementation experience has > > revealed that not all situations are covered in RFC8229, and that may > > lead to interoperability problems or to suboptimal performance. The > > WG > > will provide a document to give implementors more guidance about how > > to use > > reliable stream transport in IKEv2 and clarify some issues that have > > been > > discovered. > > > > However, since it was so long since the WG last discussed the draft, > > the chairs asked me to send a message to the list to determine whether > > there is still an interest in the WG to proceed with this work with > > this draft as a starting point. > > > > Regards, > > Valery. > > > > > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Apr 29 12:54:36 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E67D3A16E3; Wed, 29 Apr 2020 12:54:34 -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 bCLdPt9yO6-6; Wed, 29 Apr 2020 12:54:32 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 739453A16E2; Wed, 29 Apr 2020 12:54:32 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id k1so4053638wrx.4; Wed, 29 Apr 2020 12:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yvqMY0gn5wM6rTvvrcKWTs9iYnQbwdsNjWzgneSY5do=; b=XaRo7zz7qr8e1pBkOyCQynxW6/NUYiscf9hPxVQK/XQ9atcQE/6ameUWd5fBhyjxn8 c1LT94wx89BjTV+v28hU1Rf78UzGbrkK7BXpsdtRtS2EwzuBZ7YKXw/whMPdrEitE7GS RvlcOONjJpnUM8ENxmvpH2sjJInc3zRrtd4+nvysJcGCzjIZUbky7Zg36ITiYSSxwzRX BdAPS4r/IVFhWm2NtRVDp2PY2CaKU45zvXlPEFXA0FZDIJqqK7qlEeauAUtC5vvADwN3 B3wAtM9TASgkEiP62JjB2lBtQfKALHLLYwC6jc50b+mVSM0XZPlCAXS29s5AJzobJXbF h+sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yvqMY0gn5wM6rTvvrcKWTs9iYnQbwdsNjWzgneSY5do=; b=i431TpDCWbh8JfiQokvSuMlBIotoSabiVHQnPGJaOT3n/lT6AMoyqUhEvWuch3ZX3y nCXFb88415HG87HwadyfPVflOYlOqHOkzcixb6m9U1BQ0DZwXPE6kD5riTJW381GlGDE w0iOnXdwFzQlJQWqBC6LNmAU6hXFi+4OvQA3YLzngbIpa+wf7vlwaWK8mOKAk79E8T81 15sp6bVBssO02/Tgh1D65DTCy8qOFbhnDPuYr13Ms8h82mN7FCO/k9XrtFqikzuolT8r E/LJRE2uBCr4JS+vULLp65zmhaGau1nYKBe3o4jHWJVImPgE2BeNOFaAgi4I2qOINy2X AeEg== X-Gm-Message-State: AGi0Puakfe+bgkECUD1J8ufDg5yG38p5oGoNmyXZKP4Qtkm1/80lingz sUVPoxlD623rFLwuPZtVyiQ= X-Google-Smtp-Source: APiQypJPiikueoxmfRvHKEOfBsdAaQdyU+Hn+WOWOC+G0Gra3/04lRzAQOagLYy6+B2OFo7TK8WqzQ== X-Received: by 2002:adf:f4d1:: with SMTP id h17mr39267685wrp.69.1588190070838; Wed, 29 Apr 2020 12:54:30 -0700 (PDT) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id u7sm9879676wmg.41.2020.04.29.12.54.28 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Apr 2020 12:54:29 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Yoav Nir In-Reply-To: <007d01d61e3c$c43a8990$4caf9cb0$@gmail.com> Date: Wed, 29 Apr 2020 22:54:26 +0300 Cc: Tommy Pauly , ipsec@ietf.org, ipsecme-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <69538081-E679-4BE4-A818-6AD424ECBCF0@gmail.com> References: <0b5201d61d43$0f16dfe0$2d449fa0$@gmail.com> <53F12987-8F6B-46B7-831C-A4185E2B3805@apple.com> <007d01d61e3c$c43a8990$4caf9cb0$@gmail.com> To: Valery Smyslov X-Mailer: Apple Mail (2.3608.80.23.2.2) 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: Wed, 29 Apr 2020 19:54:35 -0000 [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.=20 Charters can be modified. Yoav > On 29 Apr 2020, at 18:42, Valery Smyslov = wrote: >=20 > Hi Tommy, >=20 >> Hi Valery, >>=20 >> Thanks for bringing this up again. Would you be interested in making = this > an >> RFC8229bis instead? I think it would be most useful for an = implementer to > fold >> some of these clarifications into the main text itself. How do you = feel > about >> that? >=20 > I'd be happy to do it. I also think that a -bis document is more = useful. > The reason that this draft is not a rfc8229bis is that one and half > year ago it was a general feeling that more experience need to be > collected before -bis document should be issued. Now it is almost > 3 years since rfc8229 is published, I agree that it's probably time to = start > preparing -bis. >=20 > One concern is the current WG charter -=20 > it seems to me that it only allows > clarification document and not a -bis. > It is a question to our chairs and AD - are > we allowed to proceed with rfc8229bis document > with the current charter text or should we update it > and ask for re-chartering? >=20 > Regards, > Valery. >=20 >=20 >> Best, >> Tommy >>=20 >>> On Apr 28, 2020, at 2:54 AM, Valery Smyslov >> wrote: >>>=20 >>> Hi, >>>=20 >>> a one and half year ago at IETF 103 in Bangkok I presented >>> draft-smyslov-ipsecme-tcp-guidelines >>> "Clarifications and Implementation Guidelines for using TCP >>> Encapsulation in IKEv2" >>>=20 > = (https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-tcp-guidelines/). >>>> =46rom my recollection of the meeting and from minutes it was a = general >>> feeling in the room that >>> this document was useful for implementers, since it clarified some >>> subtle issues that were not covered in RFC 8229. However, at that = time >>> no adoption call was issued since this work would require to update >>> the IPSECME charter. >>> It took over a year to adopt the updated charter and now the WG is >>> chartered for this work with this draft as a possible starting = point. >>> The text in the charter: >>>=20 >>> RFC8229, published in 2017, specifies how to encapsulate >>> IKEv2 and ESP traffic in TCP. Implementation experience has >>> revealed that not all situations are covered in RFC8229, and = that > may >>> lead to interoperability problems or to suboptimal performance. = The >>> WG >>> will provide a document to give implementors more guidance about = how >>> to use >>> reliable stream transport in IKEv2 and clarify some issues that = have >>> been >>> discovered. >>>=20 >>> However, since it was so long since the WG last discussed the draft, >>> the chairs asked me to send a message to the list to determine = whether >>> there is still an interest in the WG to proceed with this work with >>> this draft as a starting point. >>>=20 >>> Regards, >>> Valery. >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >=20