From nobody Tue Apr 3 04:09:42 2018 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 9C48A12E89A for ; Tue, 3 Apr 2018 04:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=Np0ycMQ5; dkim=pass (1024-bit key) header.d=ericsson.com header.b=lJabp7+K 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 Xzvq00EL2JTk for ; Tue, 3 Apr 2018 04:09:40 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B004120726 for ; Tue, 3 Apr 2018 04:09:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1522753777; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=awT2ihx4TK1vuv4x18q4KKrvdmLjC97a+vdyMwytlcM=; b=Np0ycMQ5jljGoO+4ENsPJb5rcVobplzUdo7ExBqfoxYE3ngUhAh8eVzQLU21Qc3A HIxssXbikvPG5Yh+RQy9Z1NPFVowrlWKRYRAzYeFfCQXIOA73z0HGtbYonrd/xA4 xaotQRravERRpUlqBzlMABv71EpdDVyQe6iG7A+w9PM=; X-AuditID: c1b4fb3a-e21ff70000005d56-ba-5ac360f1ca24 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id AD.B7.23894.1F063CA5; Tue, 3 Apr 2018 13:09:37 +0200 (CEST) Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESSHC004.ericsson.se (153.88.183.30) with Microsoft SMTP Server (TLS) id 14.3.382.0; Tue, 3 Apr 2018 13:09:37 +0200 Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26; Tue, 3 Apr 2018 13:09:37 +0200 Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26 via Frontend Transport; Tue, 3 Apr 2018 13:09:36 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=awT2ihx4TK1vuv4x18q4KKrvdmLjC97a+vdyMwytlcM=; b=lJabp7+K2hH+1FOPs+BgjcixWblUgcU9iloHXIAGZfkEVDgqvndY7DbGWARXbhxESdo6IWg83bK3Jy2NWiSnHxHmuTtsYgPMIsYcrGtwZ0ZuGJx2gbJX1DQk5NszskP/1fy5oI0stck2x8kb1e0SGySeemxspDUkQjAQIxRI4EM= Received: from HE1PR07MB1307.eurprd07.prod.outlook.com (10.164.51.157) by HE1PR07MB4171.eurprd07.prod.outlook.com (20.176.166.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.5; Tue, 3 Apr 2018 11:09:35 +0000 Received: from HE1PR07MB1307.eurprd07.prod.outlook.com ([fe80::c990:d81a:bd04:40be]) by HE1PR07MB1307.eurprd07.prod.outlook.com ([fe80::c990:d81a:bd04:40be%7]) with mapi id 15.20.0653.005; Tue, 3 Apr 2018 11:09:35 +0000 From: =?utf-8?B?UMOlbCBEYW1tdmlr?= To: "ipsec@ietf.org" Thread-Topic: Question: Inconsistent statements about what the node shall do when receving ESP packets with unknown SPI. Thread-Index: AdPLOtDWg3mxwv2vTUm0771um2usNA== Date: Tue, 3 Apr 2018 11:09:35 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.176.1.90] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB4171; 7:1rPh6zu2gOgCvV1eXh2XsX7tLfT32Qy+xQrKFEIfGBr24DaABu5hpmbok2s0sUv9TtyMNEkEy47Cx9t3gwx/ZT6RtgbnU23KhUV0i76nF/i6iewjomfAKD69x3KuXq2fUyeaxLpEmA2Eyawm2zFstzHdZ3JoXu0bbF9Dic4o8okfyHw18FQsNQaE3Ugs/HxJHLLLF1IICpSoMSy4k8DQrrGI6EoeTRAP8+f9//bdS9kZnuxUsZXJ4t+8hTLe6QQo x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 703c4e75-0821-44be-d9f8-08d59953628d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB4171; x-ms-traffictypediagnostic: HE1PR07MB4171: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pal.dammvik@ericsson.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231221)(944501327)(52105095)(10201501046)(93006095)(93001095)(3002001)(6041310)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:HE1PR07MB4171; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB4171; x-forefront-prvs: 0631F0BC3D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(376002)(396003)(39860400002)(366004)(346002)(85644002)(189003)(199004)(68736007)(66066001)(8936002)(85202003)(1730700003)(81156014)(81166006)(8676002)(316002)(5630700001)(99286004)(97736004)(25786009)(7696005)(5250100002)(6506007)(106356001)(59450400001)(85182001)(478600001)(86362001)(3280700002)(2501003)(105586002)(3660700001)(5660300001)(9686003)(2906002)(7736002)(54896002)(6306002)(14454004)(33656002)(5640700003)(53936002)(2351001)(74316002)(2900100001)(790700001)(486005)(186003)(102836004)(55016002)(26005)(476003)(6116002)(6916009)(486005)(3846002)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4171; H:HE1PR07MB1307.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: f7ki8yBY3KFP6zfzkMTQzdiJtKpqndhKHM0vG7Oq9wL7i4+IkpbZ7NNMJUJMG/kUYbADQWDiE8UPQ+WTDDGFoddR0l2OnDkTWmaZwCOpXTskoWf2TVpASmT++Ven91HOsyhsiGLbSSZpvON1M7dmd5OfMBenlhsV+qlHrEdw1k4syyPzn7vh5edfWCKi1/ssnMgGT/tf+sIuS2Wk6t6MkxqsyIr1chYUnxN9cMOj4/b59gpY0RToje3CSgxPcNik6BO56PLH+0RLueb6v+bcqRFkC9RRHYIEYC+gb/L7mwbviXQxdk9HX/D4vBhwiAkCtUS8OdCu6hPwFEZh8dJ/qUfqq0iHPmsWrdxZ2n4sG36h27w2sFdasdrZ7Civ+ENDHgpKxkYX2WjSHF88XEG8MfbxPP+uMz4jbXyUHK/qx4U= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR07MB13078205BCE2E700DDA3983C8BA50HE1PR07MB1307eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 703c4e75-0821-44be-d9f8-08d59953628d X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2018 11:09:35.6321 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4171 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRTHee69267W4npTPFiazYqS1DQT8w3zkwSBBGXMQJde352xu4n6 aRGGuCwLZ2y1FJ2aZlhqZamp02qZaWhGBVaipiKZDUtD2tr2GPjt9/xfOOfAQ5OsQeBFZ8mV nEIuy5UIXSndmcc+AT9TBqSHLD+OhPd2zAtjUbzR+IdIQFLXqDQuN6uAUwTFpLhm3jfXis6b owsNdyYpNZqPLEMuNDCh0GabRg5mmUEEK6+3lCFXO7cjKLk2IMCP3whemGc3UkYCZq1uDoNi LARoR1YF2NASsFwahhtTCOrerjgbQiYaNHdrCAe7M3thqOGGs7CdUYHJOkNivRh0xgUh5kBo vv3e2aWYPfC8scKZFzNnwdavcTJivOHL6mfKwSTjCZ9mqgl8DwPG7lESswcsTFvtedrOvlA+ LsWyN4xVa5BjT2A6CPheNUthIwCWtVoS50+AfqgIZ8wIrF+vIJzxh/rSMSHeIQmalr6JsJ4D ffX6jbnHwTZ8lcTlehJaW0Y3ltsJtYtPRNiwCaBk7TJRgQL0m47Q24eTTD70/GX1zpvd4JVu hsLyAWh9GoTTu6FSMyXCvB9KbhlEm/UaJGpGHjzH83kZISGBnCIrlefz5YFyTtmG7J+mv2M9 ohP1zx0zIYZGkq3ikzEDUlYgK+CL8kwIaFLiLh7pNklZcZqsqJhT5CcrVLkcb0I7aEriKY5L D5eyTIZMyeVw3HlO8d8laBcvNfL5VR7GHvavPDgxPtF8ujA5f9LX99wF6kNcT5tKzero9Mg+ 267s3vhHc4PZfh8TX8YWWZoureuYxfSmluE6TnUxdm3f9IPQjOuLC0sNibRAk1q1HHcqOaGr HT2M6jvaqN62YiotZ98Y3t1M6ooI9ou3PBN3Bjbes3VVZkd4FCglFJ8pC/YnFbzsH5m9tdww AwAA Archived-At: Subject: [IPsec] Question: Inconsistent statements about what the node shall do when receving ESP packets with unknown SPI. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 11:09:42 -0000 --_000_HE1PR07MB13078205BCE2E700DDA3983C8BA50HE1PR07MB1307eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpbmsgSSBoYXZlIGRpc2NvdmVyZWQgYSBzbWFsbCBpbmNvbnNpc3RlbmN5IGluIFJGQyA3Mjk2 IHdpdGggcmVnYXJkcyB0byB0aGUgYWN0aW9ucyBhIG5vZGUgc2hhbGwgdGFrZSBpZiBpdCByZWNl aXZlZCBFU1AgcGFja2V0cyB3aXRoIGFuIHVua25vd24gU1BJLg0KSW4gc2VjdGlvbiAxLjUgaXTi gJlzIHN0YXRlZDoNCg0K4oCcSW4gdGhlIGZpcnN0IGNhc2UsIGlmIHRoZSByZWNlaXZpbmcgbm9k ZSBoYXMgYW4gYWN0aXZlIElLRSBTQSB0byB0aGUgSVAgYWRkcmVzcyBmcm9tIHdoZW5jZSB0aGUg cGFja2V0IGNhbWUsIGl0IE1BWSBzZW5kIGFuIElOVkFMSURfU1BJIG5vdGlmaWNhdGlvbiBvZiB0 aGUgd2F5d2FyZCBwYWNrZXQgb3ZlciB0aGF0IElLRSBTQSBpbiBhbiBJTkZPUk1BVElPTkFMIGV4 Y2hhbmdlLuKAnQ0KDQpUaGUgd29ya3Mg4oCcSW4gdGhlIGZpcnN0IGNhc2XigJ0gcmVmZXJzIHRv IGEgY2FzZSB3aGVyZSB0aGUgbm9kZSByZWNlaXZlZCBhbiBFU1AgcGFja2V0IHdpdGggdW5rbm93 biBTUEkuDQoNClRodXMgaW4gdGhpcyBjYXNlIGl04oCZcyBhIE1BWSBzdGF0ZW1lbnQgdG8gaW5p dGlhdGUgdGhlIElORk9STUFUSU9OQUwgZXhjaGFuZ2UuDQoNCkluIHNlY3Rpb24gMi4yMS40IGl0 4oCZcyBzdGF0ZWQ6DQoNCuKAnElmIGFuIGVycm9yIG9jY3VycyBvdXRzaWRlIHRoZSBjb250ZXh0 IG9mIGFuIElLRSByZXF1ZXN0IChlLmcuLCB0aGUgbm9kZSBpcyBnZXR0aW5nIEVTUCBtZXNzYWdl cyBvbiBhIG5vbmV4aXN0ZW50IFNQSSksIHRoZSBub2RlIFNIT1VMRCBpbml0aWF0ZSBhbiBJTkZP Uk1BVElPTkFMIGV4Y2hhbmdlIHdpdGggYSBOb3RpZnkgcGF5bG9hZCBkZXNjcmliaW5nIHRoZSBw cm9ibGVtLuKAnQ0KDQpTbyBpbiB0aGlzIGNhc2UgaXTigJlzIGEgU0hPVUxEIHN0YXRlbWVudCB0 byBpbml0aWF0ZSB0aGUgSU5GT1JNQVRJT05BTCBleGNoYW5nZS4NCg0KVG8gbWUgdGhlc2Ugc3Rh dGVtZW50IGFyZSBhIGJpdCBjb25mdXNpbmcsIGlzIGl0IGEgU0hPVUxEIG9yIE1BWSB0byBpbml0 aWF0ZSBhbiBJTkZPUk1BVElPTkFMIGV4Y2hhbmdlIHdoZW4gcmVjZWl2aW5nIEVTUCBwYWNrZXRz IHdpdGggdW5rbm93biBTUEk/IChhc3N1bWluZyBhbiBJS0UgU0EgaXMgZXN0YWJsaXNoZWQpLg0K DQpJbiBteSBodW1ibGUgb3BpbmlvbiBzZWN0aW9uIDIuMjEuNCBzaG91bGQgYmUgdXBkYXRlZCB0 byBzYXkgTUFZIGJ1dCBJIG1pZ2h0IGhhdmUgbWlzc2VkIHNvbWV0aGluZyDwn5iKDQoNCg0KDQoN Cg== --_000_HE1PR07MB13078205BCE2E700DDA3983C8BA50HE1PR07MB1307eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEg TWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0 IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iU1YiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGluayBJIGhhdmUgZGlzY292ZXJlZCBhIHNtYWxsIGlu Y29uc2lzdGVuY3kgaW4gUkZDIDcyOTYgd2l0aCByZWdhcmRzIHRvIHRoZSBhY3Rpb25zIGEgbm9k ZSBzaGFsbCB0YWtlIGlmIGl0IHJlY2VpdmVkIEVTUCBwYWNrZXRzIHdpdGggYW4gdW5rbm93biBT UEkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPkluIHNlY3Rpb24gMS41IGl04oCZcyBzdGF0ZWQ6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij7igJxJbiB0aGUgZmlyc3QgY2FzZSwgaWYgdGhlIHJlY2VpdmluZyBub2RlIGhhcyBhbiBhY3Rp dmUgSUtFIFNBIHRvIHRoZSBJUCBhZGRyZXNzIGZyb20gd2hlbmNlIHRoZSBwYWNrZXQgY2FtZSwg aXQgTUFZIHNlbmQgYW4gSU5WQUxJRF9TUEkgbm90aWZpY2F0aW9uIG9mIHRoZSB3YXl3YXJkIHBh Y2tldCBvdmVyIHRoYXQgSUtFIFNBIGluIGFuIElORk9STUFUSU9OQUwgZXhjaGFuZ2Uu4oCdPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5UaGUgd29ya3Mg4oCcSW4gdGhlIGZpcnN0IGNhc2XigJ0gcmVmZXJz IHRvIGEgY2FzZSB3aGVyZSB0aGUgbm9kZSByZWNlaXZlZCBhbiBFU1AgcGFja2V0IHdpdGggdW5r bm93biBTUEkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaHVzIGluIHRoaXMgY2FzZSBpdOKAmXMgYSBN QVkgc3RhdGVtZW50IHRvIGluaXRpYXRlIHRoZSBJTkZPUk1BVElPTkFMIGV4Y2hhbmdlLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+SW4gc2VjdGlvbiAyLjIxLjQgaXTigJlzIHN0YXRlZDo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPuKAnElmIGFuIGVycm9yIG9jY3VycyBvdXRzaWRlIHRoZSBjb250ZXh0IG9mIGFu IElLRSByZXF1ZXN0IChlLmcuLCB0aGUgbm9kZSBpcyBnZXR0aW5nIEVTUCBtZXNzYWdlcyBvbiBh IG5vbmV4aXN0ZW50IFNQSSksIHRoZSBub2RlIFNIT1VMRCBpbml0aWF0ZSBhbiBJTkZPUk1BVElP TkFMIGV4Y2hhbmdlIHdpdGggYSBOb3RpZnkgcGF5bG9hZCBkZXNjcmliaW5nIHRoZSBwcm9ibGVt LuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+U28gaW4gdGhpcyBjYXNlIGl04oCZcyBhIFNIT1VMRCBz dGF0ZW1lbnQgdG8gaW5pdGlhdGUgdGhlIElORk9STUFUSU9OQUwgZXhjaGFuZ2UuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5UbyBtZSB0aGVzZSBzdGF0ZW1lbnQgYXJlIGEgYml0IGNvbmZ1c2luZywgaXMg aXQgYSBTSE9VTEQgb3IgTUFZIHRvIGluaXRpYXRlIGFuIElORk9STUFUSU9OQUwgZXhjaGFuZ2Ug d2hlbiByZWNlaXZpbmcgRVNQIHBhY2tldHMgd2l0aCB1bmtub3duIFNQST8gKGFzc3VtaW5nIGFu IElLRSBTQSBpcyBlc3RhYmxpc2hlZCkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JbiBteSBodW1ibGUg b3BpbmlvbiBzZWN0aW9uIDIuMjEuNCBzaG91bGQgYmUgdXBkYXRlZCB0byBzYXkgTUFZIGJ1dCBJ IG1pZ2h0IGhhdmUgbWlzc2VkIHNvbWV0aGluZw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkgRW1vamkmcXVvdDssc2Fucy1zZXJpZiI+ 8J+Yijwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_HE1PR07MB13078205BCE2E700DDA3983C8BA50HE1PR07MB1307eurp_-- From nobody Tue Apr 3 13:58:31 2018 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D7D2912D87F for ; Tue, 3 Apr 2018 13:58:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152278910987.22726.4104935238590027493.idtracker@ietfa.amsl.com> Date: Tue, 03 Apr 2018 13:58:29 -0700 From: IETF Secretariat Archived-At: Subject: [IPsec] Milestones changed for ipsecme WG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 20:58:30 -0000 Changed milestone "IETF Last Call on Split-DNS Configuration for IKEv2", set due date to April 2018 from February 2017. Changed milestone "IETF Last Call on Implicit IV in IPsec", set due date to April 2018 from February 2017. Changed milestone "IETF Last Call on partially quantum resistant IKEv2", set due date to May 2018 from June 2017, added draft-ietf-ipsecme-qr-ikev2 to milestone. URL: https://datatracker.ietf.org/wg/ipsecme/about/ From nobody Tue Apr 3 16:23:52 2018 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 A9E6F1241FC for ; Tue, 3 Apr 2018 16:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 v-mQz_8ifxb1 for ; Tue, 3 Apr 2018 16:23:47 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 DF5AF1201F2 for ; Tue, 3 Apr 2018 16:23:46 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w33NNdrl000199 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 4 Apr 2018 02:23:39 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w33NNa5A000848; Wed, 4 Apr 2018 02:23:36 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <23236.3320.905089.567798@fireball.acr.fi> Date: Wed, 4 Apr 2018 02:23:36 +0300 From: Tero Kivinen To: =?iso-8859-1?Q?P=E5l?= Dammvik Cc: "ipsec\@ietf.org" In-Reply-To: References: X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 14 min X-Total-Time: 24 min Archived-At: Subject: [IPsec] Question: Inconsistent statements about what the node shall do when receving ESP packets with unknown SPI. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 23:23:50 -0000 P=E5l Dammvik writes: > Think I have discovered a small inconsistency in RFC 7296 with > regards to the actions a node shall take if it received ESP packets > with an unknown SPI. Those cases are not exactly same. I.e., the section 1.5 explictly talks about receiving ESP packet with unknown SPI. The section 2.21.4 talks about errors outside the context of an IKE request, and gives one example of such case, which happens to be the ESP messages on nonexisting SPI. On the hand, I am not sure if there are any other errors outside of IKE request than invalid SPIs... > To me these statement are a bit confusing, is it a SHOULD or MAY to i= nitiate > an INFORMATIONAL exchange when receiving ESP packets with unknown SPI= =3F > (assuming an IKE SA is established). Note, that SHOULD includes MAY. I.e., if some text says you SHOULD do something, and other text say you MAY do that, they are not conflicting, the MAY is included as part of SHOULD. So when you implement the SHOULD you also happen to implement the MAY too...=20 > In my humble opinion section 2.21.4 should be updated to say MAY but = I might > have missed something=20 We did discussed about this in 2008-2010 before publishing RFC5996. The section 2.21 got written at that point, as we wanted to expand the text covering the error cases. Then I did point out before publication that the text is bit confusing and that sections 1.5 and 2.21.4 should be combined, as we same rules in two different places. The editor responded that he didn't want to do that big change in that late phases [2]. [1] https://trac.ietf.org/trac/ipsecme/ticket/26 [2] https://www.ietf.org/mail-archive/web/ipsec/current/msg05669.html When we were making RFC7296 we could have combined those two sections but never got to do that even then. Anyways I think SHOULD is good there, as those messages are rate limited, and sending information to the other end that you are sending me stuff, I do not know anything about is good thing, as then it can do some actions to fix things.=20 --=20 kivinen@iki.fi From nobody Wed Apr 4 02:53:05 2018 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 049B2124E15 for ; Wed, 4 Apr 2018 02:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.121 X-Spam-Level: X-Spam-Status: No, score=-0.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_AFFORDABLE=1, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8y7ychgz8NlC for ; Wed, 4 Apr 2018 02:53:00 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 3A7A91242F5 for ; Wed, 4 Apr 2018 02:53:00 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w349qu54029947 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 4 Apr 2018 12:52:56 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w349qrQM029791; Wed, 4 Apr 2018 12:52:53 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23236.41077.38545.504873@fireball.acr.fi> Date: Wed, 4 Apr 2018 12:52:53 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 1 min Archived-At: Subject: [IPsec] Minutes of the IETF #101 meeting posted X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 09:53:04 -0000 Thanks for all the people writing minutes to the etherpad. Here is the minutes for the IETF #101 IPsecME meeting: ---------------------------------------------------------------------- IETF 101 IPsecME WG meeting in London Friday, March 23, 2018 11:50-13:20 Park Suite - Agenda bashing, Logistics -- Chairs (5 min) - Rechartering (5 min) - Draft status -- Chairs, Valery (10 min) - Update on QR IKEv2 - Valery Smyslov - draft-ietf-ipseme-qr-ikev2 - Work / Other items (70 min) - Postquantum Key Exchange to IKE - CJ Tjhai - draft-tjhai-ipsecme-hybrid-qske-ikev2 - Labeled IPsec - Paul Wouters - draft-sprasad-ipsecme-labeled-ipsec - Auxiliary Exchange in the IKEv2 Protocol - Valery Smyslov - draft-smyslov-ipsecme-ikev2-aux - Group Key Management using IKEv2 - Valery Smyslov - draft-yeung-g-ikev2 - IKE_SA_INIT privacy concerns - David Schinazi - draft-dschinazi-ipsecme-sa-init-privacy-addition - Dynamic IPsec PMTU PLPMTUD - Shibu Piriyath, Ron Bonica - draft-spiriyath-ipsecme-dynamic-ipsec-pmtu WG Actions: ----------- Update QR Ikev2 to Standards track in datatracker. - Done. Session Notes: -------------- Chair Slides - Chairs https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-chair-slides-01 split-dns waiting for ad Ready for WGLC on implicit IV (no new comments). 6 or 7 reviewers raised hands. Most Milestones of old charter completed New Milestones on new charter MOBIKE and privacy not included in the charter due to ongoing discussion, can be added later. Update on QR IKEv2 - Valery Smyslov https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-quantum-resistant-ikev2-00 Changes from -00: - Most important is the change from prf to prf+ At least 4 vendors implemented the draft Some interop-tests where done Ready for last call? Paul W.: - negotiation of authentication mechanism needed - Should we do this negotiation more generic? --> offering two authentication does not scale Tommy Pauly: - Some of the text should be more clear about the structure of the Auth_Data (just the latter portion of auth payload, not the type) --> Tommy volunteers to provide the text Postquantum Key Exchange to IKE - CJ Tjhai https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-framework-to-interate-post-quantum-key-exchange-into-ikev2-01 New Design criteria based on the various feedback, mainly due to interoperability concerns and handling fragmentation in version -00 Needs to be future proof, and work in parallel with existing mechanisms (hybrid algorithms). Try to keep the amount of data as minimal as possible Backwards compability: no new transform type, no new payload. Notification is OK. New approach uses new DH group number that denotes hybrid approach in first INIT exchange. Second round would be quantum safe. Fragmentation only applies to IKE_AUTH onwards. Proposing adding a fragmentation pointer. Yoav: - how large is large? --> Some 1KB or more - No trouble with payload length? --> No Tommy: - What message type for second exchange (with regards to new DH and Fragmentation Bit)? Tero: - Two different Key Exchange labels in two different packets? - Better not to overlap KE payload --> introducing new payload type Paul W.: - would be nicer to have the two different KE payloads in the INIT --> If not understood, should ignore that Yoav: - could have done that for all new groups we support and we didn't. Doesn't introduce something fundamentaliy different to e.g. curve2559 Question to the WG: how to deal with Fragmentation? --> Valery will have a talk on that Mark: - seems sufficient Valery: - prefers different approach for fragmentation issue. Not a good idea to rely on some buggy implementations around for such a long-term solution Yoav: - do you actually achieve FIPS compliance? --> Yes Tero: - Mentioned use the existing INVALID_KE_PAYLOAD style mechanism; we don't want an explosion of combinations. ?: Fragmentation reassembly is an attack vector, how do we handle that? Tero: We use no fragmentation on INIT, and the reassembly we do is in the encrypted AUTH payloads Tero (Chair): Wait for Valery's presentation for fragmentation discussion Auxiliary Exchange in the IKEv2 Protocol - Valery Smyslov https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-auxiliary-exchange-in-ikev2-protocol-00 Fragmentation for IKE_AUTH is possible, as they tend to be much larger than IKE_INIT Driver behind this idea is quantum safe key exchange, as it will most likely have larger pub keys Add a new exchange between IKE_INIT and IKE_AUTH called IKE_AUX Integrity protected and encrypted Paul W: They are not integrity protected? -> they are not authenticated but integrity protected Yoav: You assume they are strong against Quantum Computers. Tero: Delayed authentication of IKE_AUX Approach is ment to be generic, not only for QSKE (but of coursed inspired by QSKE) additional skeyseed after IKE_AUX ?: How does the initiator know when to move to ike_auth? Tero: - Responder cannot change, because the responder requires another request. - How to prevent x-times SKEYSEED after every IKE_AUX - Maybe you not only one request-response for QSKE Tommy: - should we specify the responder behaviour as in IKE_AUTH? Responders in not allowed to initiate its own IKE_AUX. - Do we assume that there is always a new key after IKE_AUX? Should be generic - maybe we should just specify that it is mandatory to get keys, as the point about IKE_AUX is to secure IKE_AUTH. Michael R.: - doesn't seem to be generic cause of the re-key. - why not do a re-key after IKE_AUTH - As DH is broken, this approach does not seem to protect it. Tero: - discussion to the list Valery: if IKE_INIT can be broken in real-time Paul W.: Do we need the same for CREATE_CHILD_SA? It already can be fragmented, so no issue there. Summary: IKE_AUX seems simple and doesn't need fragmentation. Adds round-trips but seems affordable. Labeled IPsec - Paul Wouters https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-labeled-ipsec-00 Idea: Move an SA from one machine to the other (already in IKEv1, need it in IKEv2 to let IKEv1 die) Valery: need different selectors (Tobias: don't know if I got the question correctly) Tero: IP ranges are an issue. Jared Lu (?): Concern about deployment with exact vs inexact match for secret channels, and downgrade attacks. Group Key Management using IKEv2 - Brian Weis https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-group-key-management-using-ikev2-01 Motivation: GDOI should die along with IKEv1. This covers multicast security. There are two protocols (registration to join the group, and rekey to roll the keys) Would add GSA_AUTH (like IKE_AUTH with new payloads) and GSA_REGISTRATION (like CREATE_CHILD_SA) two re-keys (INBAND and "normal") - INBAND: new key distributed unicast - REKEY: new key distributed in multicast new Payloads: - GSA_PAYLOAD sending the sa information to the clients (no negotiation as in IKEv2) - KD Payload distributing the keys, - some optimizations for key distribution in the groups exist (e.g. LKH) - issues with IVs (solution so called sender-ids) Re-used payloads: - ID Payload for Group ID - Notify Tero: harmonizing with IKEv2 Yoav: harmoinizing the names for the keys - multicast? - CRFG has some proposals without the need the sender ids Who has read the draft? (about 7-10 hands) Ask for reviews on the list IKE_SA_INIT privacy concerns - David Schinazi https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-privacy-additions-to-the-ikev2-ike-sa-init-exchange-00 Concerns around privacy of the peers (who the initiator is, and if the responder is running IKE) IDi can be leaked to the entity that intercepted your IKE_SA_INIT. Initiator identity is leaked. Servers can hide behind TCP using TCP encapsulation, allowing someone to connect in with IKEv2 unbeknownst to anyone. Traffic could be recognized as IKE rather than HTTP. The privacy issue is that these could be probed to discover who is running VPNs behind websites. Proposal is to add a shared secret and a PRF. These are added as an optional notify in the IKE_SA_INIT. Responder can silently drop the packet, or choose to verify. If the initiator doesn't get back the reply, it will refuse to do IKE_AUTH. MAC based on shared key, a constant string, and the nonces. Vulnerable to reply attack for the initial IKE_SA_INIT. This is okay for the hidden server case, which could be protected from on-path attackers via TLS encaps. Michael Richardson: Smells like IKEv1 PSK with XAUTH. Unhappy about that. Seems that you're able to provision PSKs to the clients. I would prefer to provision a raw public key than a PSK. In the case of a TLS connection, you already have a public key the server can sign with. I don't want more PSKs, let's do public key instead. Tero: The problem is that when the responder validates the the INIT, the server can't scale if it has to check all of the options. I think the identity case is more important than the hidden server. Could use a random identity to protect the user. Have a scheme of psuedonyms. Hidden server problems seems not to be a good idea, as you can analyze the packet otherwise Valery: ? Tommy: Client authentication in TLS? -> that's also clear-text Privacy of the IDi would be the better and clearer focus. Daniel M.: splitting to two different solutions is better, especially the privacy of the IDi Dynamic IPsec PMTU PLPMTUD - Shibu Piriyath, Ron Bonica https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-packetization-layer-path-mtu-discovery-01 Problem: IPsec Tunnel has an PMTU as any other tunnel. Solution in Transport Area: Inband Path discovery -- kivinen@iki.fi From nobody Wed Apr 4 14:23:22 2018 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 62A14126BF0 for ; Wed, 4 Apr 2018 14:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 XqBqodk7peIn for ; Wed, 4 Apr 2018 14:23:17 -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 96614120454 for ; Wed, 4 Apr 2018 14:23:17 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 50A3B20091 for ; Wed, 4 Apr 2018 17:33:06 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A60718106E for ; Wed, 4 Apr 2018 17:23:16 -0400 (EDT) From: Michael Richardson To: ipsec@ietf.org X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.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: [IPsec] use of IKE_AUX vs rekey of IKE Parent SA in draft-smyslov-ipsecme-ikev2-aux X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 21:23:19 -0000 --=-=-= Content-Type: text/plain Tero Kivinen wrote: > Michael R.: > - doesn't seem to be generic cause of the re-key. > - why not do a re-key after IKE_AUTH > - As DH is broken, this approach does not seem to protect it. I suggested in the mic line that the use of IKE_AUX seemed to introduce more issues than it solved. It must defend against all the various attacks which IKEv2 already defends against today. Instead we should do some kind of IKE_AUTH round trip (without CHILDSA) with "classic" authentication methods, and using "classic" DH methods. Then use RFC7383 to get the larger QM exponents across, and then do a IKE_AUTH "rekey" to switch to the QM exponents. This just feels cleaner to me. This would work far better today as it would resist all sorts of resource exhaustion attacks that we currently defend easily against. Of course, the way that we defend against them today is by use of DH methods and authentication methods that might be defeated by quantum computers. So the question becomes: in a post-QM world, do we think that the attackers will be able to defeat our pre-QM methods in real time and thus attack us? If the answer is no, then I think that we can use this multi-level security mechanism to advantage. If the answer is yes (they can decrypt in real time), then we need to build all the fragmentation protections into IKE_AUX anyway. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlrFQkQACgkQgItw+93Q 3WUb6Qf/bjqXIjm99pXyybE0JyBaFXdLdgqb7TTSIZOkptvDukY5uY+zLNhg3Zm5 bs3y76/BGXTDZfdmNPZwqJSmXQeVeUhCgbBgO02ER9Kuwuyko5p7Q0VfrJ3PtQUH 9dt+S6vqv3QA+f6rAl8YuAcT9XjL7SywvBYu/6FiwFHklU/pjQrrnAmp8+KwWw0q MjEoA26s/C+duq/LxsTKzTuTaidB280TK8BxADomAVWG/JLghWZfQbe9U5SxcaqC ONN1y1Q6327x7UszOy+w965v32oDTIhPWxY6yukghuYfH4HKh9/W2q3Qj+cWoT7m mIrTaYTV67GMD9ZkmUDE0+5LKg/HoA== =hHbV -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Apr 4 14:35:26 2018 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 085131267BB for ; Wed, 4 Apr 2018 14:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 p7bNmWzb84Zn for ; Wed, 4 Apr 2018 14:35:22 -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 C24E2120454 for ; Wed, 4 Apr 2018 14:35:22 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 09F7E20091; Wed, 4 Apr 2018 17:45:11 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 695968110C; Wed, 4 Apr 2018 17:35:21 -0400 (EDT) From: Michael Richardson To: ipsec@ietf.org CC: Ronald Bonica X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.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: [IPsec] PLMTUD probes for IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 21:35:25 -0000 --=-=-= Content-Type: text/plain > Dynamic IPsec PMTU PLPMTUD - Shibu Piriyath, Ron Bonica > https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-packetization-layer-path-mtu-discovery-01 > Problem: IPsec Tunnel has an PMTU as any other tunnel. > Solution in Transport Area: Inband Path discovery I spoke to Ron afterwards, and I'm very enthusiatic about getting PLPMTUD widely deployed. We didn't get to this slides, so we didn't figure out what he needs. Slides talk about an IP-level probe that IPsec encapsulators can use to get estimate for tunnel inner MTU. But, if we can get PLMTUD deployed for all traffic, then the end-nodes can do appropriate PMTU probing and can figure out what the inner MTU is. i.e. just get everyone to enable plpmtu (4821). It's a knob on most systems, which has been left in the off state because of lack of evidence that it isn't harmful. There seems to be some sticking points among the high-speed about CDNs: they hate all PMTUD as it screws with tx scheduling into hardware. (TCP segment offload issues) So they just use 1280 is what I was told. That's good for the network, but it removes them as strong allies for getting PLPMTUD enabled by default everywhere. It would be nice if we could get a BCP out of them. Such BCP could also bless PLPMTUD for everyone else. I was pushing for this with RFC8200/STD86 but there was insufficient evidence of deployment. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlrFRRkACgkQgItw+93Q 3WWLbQgAsHofXwW0J1yfWrAqtNBXCJSKOboqT3HholdhwsmAUZH2MZyrzee6vmyS K2T8T4Ofip18Fy/wF5Lfrf9v5wEdSkgjShsTGS091b9zvixXtixJUpHiLdsYN6ii fdUjsewpjQq+l23B4BtbPvzpMJVwl2E29vsf9zq3lSzmmx200goXdlxBTkSAW1oB 7t1LyCgK8LeaMD9/blucrCLEiU0kNTTz5Ox/LA0SknwwyjcDYJAjewL1QR32FVnE j/HMFP3HPD00tNvMJKubIQHbMGpPGYOcrE4125wD2LKMJ6E94wAbg1xDKUd0Cvn1 9FNvGZFVl19dThyO237BxWLa7n0nPw== =ExdY -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Apr 4 14:36:25 2018 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 C8DBF126BF0 for ; Wed, 4 Apr 2018 14:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 20_4k0SvOh9y for ; Wed, 4 Apr 2018 14:36:19 -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 936571267BB for ; Wed, 4 Apr 2018 14:36:19 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 8296620090 for ; Wed, 4 Apr 2018 17:46:08 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E5FFD8110C for ; Wed, 4 Apr 2018 17:36:18 -0400 (EDT) From: Michael Richardson To: ipsec@ietf.org In-Reply-To: <23236.41077.38545.504873@fireball.acr.fi> References: <23236.41077.38545.504873@fireball.acr.fi> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.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: [IPsec] initiator privacy vs responder stealth X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 21:36:22 -0000 --=-=-= Content-Type: text/plain Tero Kivinen wrote: > IKE_SA_INIT privacy concerns - David Schinazi > https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-privacy-additions-to-the-ikev2-ike-sa-init-exchange-00 > Concerns around privacy of the peers (who the initiator is, and if the > responder is running IKE) I think that we had some consensus that we should split the document into two problem statements. Protecting the initiator identity against MITM attackers can be solved a whole bunch of ways. A zero-knowledge proof would seem to be a better way to start to me. The problem of making the IKE responders stealthed seems like a different problem entirely. > Proposal is to add a shared secret and a PRF. These are added as an ... > Michael Richardson: Smells like IKEv1 PSK with XAUTH. Unhappy about > that. Seems that you're able to provision PSKs to the clients. I would > prefer to provision a raw public key than a PSK. > In the case of a TLS connection, you already have a public key the > server can sign with. I don't want more PSKs, let's do public key > instead. I just want to repeat this. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlrFRVIACgkQgItw+93Q 3WV+PQf8DO4wRaShrKS5VXOHF8OTvShWbwlFtT+OHJdu0/qxDTqQIyQxjUgrpokc BsJ+iKMI+7KbLmKQaWB2gzr7JRXhiKWywlLw8JtNGP0u7PFH3JAF7kR8XPFT/IYu aUPNpUnmo4wM5NSNlw4LBwZlteTzJiVlU6s2RWydzfe7rMc8VqSNHzbJfyJGWq3t PrSDzKHKJhq1X+sDeahvpOhakorGHMSepWnb3OgkDwP5NrGNjNgjhjK9RWzVKfx3 HaKUrbN/9alTTR9rI2iBGkV9w/sNxl6qBaXXVqLtqsPe1qG5FVqRGbGQ+ADLv1V1 PywEWDfFRBpoPqQPNoS409nE60mHLg== =huQx -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 5 04:21:51 2018 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 3FFCF12D7ED for ; Thu, 5 Apr 2018 04:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oakB4KMHQJs for ; Thu, 5 Apr 2018 04:21:47 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50CCE12D87B for ; Thu, 5 Apr 2018 04:21:47 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id p142-v6so24014266lfd.6 for ; Thu, 05 Apr 2018 04:21:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=v9EqOFxn71kdQPl/PGD/RhXxmto6O2T0rWyULjOd+KY=; b=aNgDiaYqEnSPNI66aKp89RjBwpKPtZurkIsQ7jSlKpaqySTRXuQhR9AV4ujAx09dtk wAZemrcUKrhzLbjwSYLXMtkSKvw8ukugIfI8d5y/NRLbVBmY9iiultlw5OUJSkjzTwrR 6fvues68ypa/+hozaFANDcSgN2hwzyjGsWjZCjk36e4AtoYrHCdJhNw9+ychAyr3Nx8s sqO1CwE+y662/DwZuY+r5AYHU36rK+xHFup3aS3kCC7JX/l2BYNnwysX1phzwOjIuuqc 0NcmvNuGWxgHax/cx5kHIWT/F82BFT8u7YvA2SeAslP6GCSiWXizgTURNzsIR0rIcjbR u6/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=v9EqOFxn71kdQPl/PGD/RhXxmto6O2T0rWyULjOd+KY=; b=s74zVGoeTm6HzZ2oZHgNoCZnEShdJ1OMruijwCFBTfPQFjLJUUoVydlXIJiPIR41nX 9F30/qRZ3O0PgU3o2b3MesPcPsQ3WLinpQeZjap2pe7NAtnqd1HAj+OqtoeDCvUxiFp9 NktGW4YI7EkCm750VakvQom45yH2Md5T/oAqleIZ5JuyUrhHDIyb2HLnhnRBC8ha9V4l 4CT2TJtGAPxIJNaq+lIwl6OU/+ec5N7PKi3Rv9/zQbtWNdyb2VELtkOqoKM59MPM2td7 VVdph5Cqju65FWm3Sr5M/Yie91K36sOkyBZ6cutfP9Oik4xq//hWnP/Y4DFdLJlJssTf LODg== X-Gm-Message-State: ALQs6tBO4LSisQe9l3S90LZamlYBf5+pshLLiSnrnUfS9ZMfuJX7SrN2 0O8tuIzd5wRZ6FvLlEs9r7KnVg== X-Google-Smtp-Source: AIpwx4/MGaH6HJf2HMABztUM4hExNbIavkfgkhMJxQ79Ic0q8s43ki9qdzilkX+0lZ7w2rIav2Un0w== X-Received: by 2002:a19:d911:: with SMTP id q17-v6mr2795257lfg.99.1522927305167; Thu, 05 Apr 2018 04:21:45 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id p74-v6sm1477328lfe.42.2018.04.05.04.21.43 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 05 Apr 2018 04:21:44 -0700 (PDT) From: "Valery Smyslov" To: "'Michael Richardson'" , References: <8413.1522876996@obiwan.sandelman.ca> In-Reply-To: <8413.1522876996@obiwan.sandelman.ca> Date: Thu, 5 Apr 2018 14:21:18 +0300 Message-ID: <003a01d3ccd0$385b5590$a91200b0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKATV1BnUrLQJe1tE6fMBHKrcmiZKKYxbMg Content-Language: ru Archived-At: Subject: Re: [IPsec] use of IKE_AUX vs rekey of IKE Parent SA in draft-smyslov-ipsecme-ikev2-aux X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 11:21:49 -0000 Hi Michael, > > Michael R.: > > - doesn't seem to be generic cause of the re-key. > > - why not do a re-key after IKE_AUTH > > - As DH is broken, this approach does not seem to protect it. > > I suggested in the mic line that the use of IKE_AUX seemed to introduce more > issues than it solved. It must defend against all the various attacks which > IKEv2 already defends against today. Please, elaborate, where do you think it fails to do this. > Instead we should do some kind of IKE_AUTH round trip (without CHILDSA) > with "classic" authentication methods, and using "classic" DH methods. > Then use RFC7383 to get the larger QM exponents across, and then do > a IKE_AUTH "rekey" to switch to the QM exponents. > > This just feels cleaner to me. I can see some issues with this approach. First, currently there is no such thing as "IKE_AUTH rekey". IKE SA rekey via CREATE_CHILD_SA doesn't perform authentication of the peers. So, you need to modify protocol to add an additional authentication exchange after IKE SA is created. This is more serious modification than introducing IKE_AUX. Then, if you perform authentication twice (first with "classic methods" and then some kind of post-authentication) then you need to have two sets of credentials for the peers, or use AUTH_NULL in the initial IKE_AUTH. The former is problematic from operation point of view (see Section 5.2 of draft-ietf-ipsecme-qr-ikev2), the latter increases vulnerability to DoS attacks (see Section 10 of RFC8019). Third, your proposal adds more round trips and require more CPU resources (to perform additional authentication). > This would work far better today as it would resist all sorts of resource > exhaustion attacks that we currently defend easily against. Not exactly, please see above. > Of course, the way that we defend against them today is by use of DH methods and > authentication methods that might be defeated by quantum computers. > > So the question becomes: in a post-QM world, do we think that the attackers > will be able to defeat our pre-QM methods in real time and thus attack us? > If the answer is no, then I think that we can use this multi-level security > mechanism to advantage. > > If the answer is yes (they can decrypt in real time), then we need to build > all the fragmentation protections into IKE_AUX anyway. If an attacker is equipped with a QC that can break initial (EC)DH in real time, then he/she will know the keys for the IKE_AUX and thus can modify its content and send bogus packets. However, this modification will be detected in the IKE_AUTH if auth method used is QC-safe (like hash based signatures). Cryptographers tell us that PQ authentication is much more well studied than PQ key exchange and that they are pretty sure in security of such schemes. I see no reason why these schemes cannot be used even in the current IKEv2, so I presume that even if an attacker breaks initial DH in the IKE_SA_INIT, it will be detected. So, the only real benefit the attacker gets in this case is that he/she can mount DoS attack, so in this regard the IKE_AUX is no worse than performing fragmentation in the IKE_SA_INIT. Moreover, in this case your proposal will be vulnerable as well (an attacker breaks classic (EC)DH and modifies IKE_AUTH messages; if it is also breaks classic auth, then DoS attacks would be even worse than in case of IKE_AUX). And I hope that by the time the attacker can break classical (EC)DH in real time, some PQ key exchange schemes with relatively small public key would appear, so that we could replace classical (EC)DH with one of such scheme. There is no need that this scheme be super-secure (since more PQ exchanges can be done in IKE_AUX) , it's enough if it withstands breaking in real time having relatively small public key. Regards, Valery. > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- From nobody Thu Apr 5 04:28:05 2018 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 5BB0012D87F for ; Thu, 5 Apr 2018 04:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 520dkyWn60qg for ; Thu, 5 Apr 2018 04:28:03 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF292126CD8 for ; Thu, 5 Apr 2018 04:28:02 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id m13so27804173wrj.5 for ; Thu, 05 Apr 2018 04:28:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=P3wMpJ3G5/OAVRwLRcrkytQ6I7VPpxaZvKMQgkoxNX4=; b=Y6I0VibTv/Xe7zu8mWgbeSbqoabbeKfThgYWkrlmmrhVeIorWMOdg+VprhBHpjaglP Skp81yw+b9krgsPuqS1EfhDsF/pmAWSJ8tx6trUNdT8SZIHkYr6vdLED+RTFkYhEhYo3 /sNbnO9Fn6iEulLkKOBatAh+1rkvskJEJb+XK/EjHW5hVhYoi4Y0/7Z7yeNph8TUdBT0 rAWlGmINVQBcIiqs61Gj/xdzK67vcjFTpRhD+eBA04Mzt8Py3ejQPyzrrRXBYEekcbZ0 smB3RjQ6kuKihsBxWzN2gtq0Mr5+N9OVn5CQmeIRaQluwRdG28gkorewjGC4eNkGznKx +Oxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=P3wMpJ3G5/OAVRwLRcrkytQ6I7VPpxaZvKMQgkoxNX4=; b=Z04AtzmLRmNeW7Jcktp9Juk+K5qCtbD6p0p3/+9anNTbVQfRry+DxpgfbrpqwR3Dnb ZLXhoX9muD9hOpRZfbGNsOylvfrnDzK2StHCIHGUMGp4zZJB1eFiJIMYhFvsK8BbBP0S QApY+ArTbH6hxgBkffZTRghCccZk4mVR+eSB77M+kwyaG8wWu7+3lcTCG3JPQQ5Ye/YQ 17QZZI8E9hsS5/U26u5RyYsWbXF/zuefv7nooOiOqnTjFydTL5KZQUwgfEChE8UePYAX cgBfIn/xKmBcdjRnlhbnB3qHfWhAoxLeqbOT76oRIB7qykRn5B2fAyIgOMABQhMVmjsK BgzA== X-Gm-Message-State: ALQs6tAlyq9nzlK4ng4OSA0XTWhob16gqGFn5Ox1f2lptO3zpWtbaBxR UbWkVKJVWzIIa7Eu0QbFu87jBA== X-Google-Smtp-Source: AIpwx4/OoUiElc506xunZV9hjMhEpQ+2BsYswf8IxWMHMYgk4rHtYkE5vk4Swc+DaqDxX/tIEM5wOg== X-Received: by 2002:a19:1903:: with SMTP id 3-v6mr13058316lfz.59.1522927680935; Thu, 05 Apr 2018 04:28:00 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id f26-v6sm1469228lfl.83.2018.04.05.04.28.00 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 05 Apr 2018 04:28:00 -0700 (PDT) From: "Valery Smyslov" To: "'Michael Richardson'" , References: <23236.41077.38545.504873@fireball.acr.fi> <11263.1522877778@obiwan.sandelman.ca> In-Reply-To: <11263.1522877778@obiwan.sandelman.ca> Date: Thu, 5 Apr 2018 14:27:34 +0300 Message-ID: <003b01d3ccd1$18818950$49849bf0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGoyccBHjv3vMlVevaBS7eVb7rfeQIsuQVtpDaon2A= Content-Language: ru Archived-At: Subject: Re: [IPsec] initiator privacy vs responder stealth X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 11:28:04 -0000 Hi Michael, > > IKE_SA_INIT privacy concerns - David Schinazi > > https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-privacy-additions-to-the-ikev2- > ike-sa-init-exchange-00 > > > Concerns around privacy of the peers (who the initiator is, and if the > > responder is running IKE) > > I think that we had some consensus that we should split the document into two > problem statements. Protecting the initiator identity against MITM attackers > can be solved a whole bunch of ways. A zero-knowledge proof would seem to > be a better way to start to me. > > The problem of making the IKE responders stealthed seems like a different > problem entirely. +1. Regards, Valery. From nobody Thu Apr 5 04:40:43 2018 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 5D94E12D87F for ; Thu, 5 Apr 2018 04:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bs8C0K1SHqCa for ; Thu, 5 Apr 2018 04:40:39 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 7432C12D82F for ; Thu, 5 Apr 2018 04:40:39 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id i3so6125026wmf.3 for ; Thu, 05 Apr 2018 04:40:39 -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=TJ2zRfWmnKroosPYQVHkp8yk/Vuh/VSi+tVLZ3N201A=; b=BV2SaUIdwC9JAqTskTiEGhqnXmRc2eLm+eJZn1DX4BBXwnDi4UnZn4XLx7+e9EIvrW BEB0Ya+631Pyll+ILyRBf+FkYaK1V6gX56AfNz3EX0QERigUq5RAaRYG3nnv5uvcHdLS 1xv/E9Oo7D1ZQLCfrJEZQI3WggOjC4ZjMv5U9lSOwPMexrzVleMMk45oZe/1crkdAzH6 6XRGrlyApH/MflfTuld6ZbmkdUuZWGYg/wj3mLiX6KGicG3jcagXa4zttNRSxJJWdyKA qJKHVHADyDzd0AAEl+wS6x92/CRLaOpNMWHEC+TRxcsIw5YHSTPH/EGKYAeXiIIRsMXS zYyg== 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=TJ2zRfWmnKroosPYQVHkp8yk/Vuh/VSi+tVLZ3N201A=; b=Rrccj8A7bTYDk1ltqM3xqwsr/KHitGyYj3lRZ71zh2f+ZPj97BLkmDWdbpCBRtoxDb Hsro1alQO2Y8UQfoi40qAOxBdjFfk+nREk7IyXyfVQ7K3QU498xz2qy3D+ZyTiuQhwAZ 3nLIvfGr0r+DtCOgnLVDncJOVSPlh3cbvfhuNVDfedDjB+XQyPW+nIBJ5y3mee4CCImr 63Nf3yQ5g320Kv5PZSfIeZoDPrZEbfWWIMAaoLkP/Y2+6253uVK6ZKQP7k6BkjnB1UFT ShtV01N9l4JkCnyDepUQXMVA5Ji6t10iTXpjXojAvrxJz/FYz0bd39uf9aKv5zw4tMPu UfvQ== X-Gm-Message-State: ALQs6tBCe0cK2F7cHUKLs+1tnAqki3kIWTI9mil61f/Hvo+3ZPIZRCVe B2HEyxNGRBIzg54dpRu8g1dT2Q== X-Google-Smtp-Source: AIpwx4/SWNBqwbnaTd3+J56OllwXuhSszMaxtRgZALLq/B2nmQB490wzuzruNvma2GG3CNo8gBoK2w== X-Received: by 10.46.134.205 with SMTP id n13mr45996ljj.115.1522928437639; Thu, 05 Apr 2018 04:40:37 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id e97-v6sm1496020lfi.10.2018.04.05.04.40.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 05 Apr 2018 04:40:36 -0700 (PDT) From: "Valery Smyslov" To: "'Michael Richardson'" , Cc: "'Ronald Bonica'" References: <11057.1522877721@obiwan.sandelman.ca> In-Reply-To: <11057.1522877721@obiwan.sandelman.ca> Date: Thu, 5 Apr 2018 14:40:11 +0300 Message-ID: <003c01d3ccd2$db7c20e0$927462a0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHmG7ZZeeXklvSuJytvO9qNpqEvt6PNbZvA Content-Language: ru Archived-At: Subject: Re: [IPsec] PLMTUD probes for IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 11:40:41 -0000 Hi Michael, > > Dynamic IPsec PMTU PLPMTUD - Shibu Piriyath, Ron Bonica > > https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-packetization-layer-path-mtu- > discovery-01 > > > Problem: IPsec Tunnel has an PMTU as any other tunnel. > > Solution in Transport Area: Inband Path discovery > > I spoke to Ron afterwards, and I'm very enthusiatic about getting PLPMTUD > widely deployed. We didn't get to this slides, so we didn't figure > out what he needs. Slides talk about an IP-level probe that IPsec > encapsulators can use to get estimate for tunnel inner MTU. Why IKE messages cannot be used for this purpose? Regards, Valery. > But, if we can get PLMTUD deployed for all traffic, then the end-nodes can > do appropriate PMTU probing and can figure out what the inner MTU is. > i.e. just get everyone to enable plpmtu (4821). It's a knob on most > systems, which has been left in the off state because of lack of evidence > that it isn't harmful. > > There seems to be some sticking points among the high-speed about CDNs: > they hate all PMTUD as it screws with tx scheduling into hardware. > (TCP segment offload issues) > > So they just use 1280 is what I was told. That's good for the network, but > it removes them as strong allies for getting PLPMTUD enabled by default > everywhere. It would be nice if we could get a BCP out of them. Such > BCP could also bless PLPMTUD for everyone else. I was pushing for this > with RFC8200/STD86 but there was insufficient evidence of deployment. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > From nobody Thu Apr 5 05:01:02 2018 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 C0C7F124BE8 for ; Thu, 5 Apr 2018 05:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zo7wiuanDW3J for ; Thu, 5 Apr 2018 05:00:59 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C570012D947 for ; Thu, 5 Apr 2018 05:00:58 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id c24so27951784wrc.6 for ; Thu, 05 Apr 2018 05:00:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=vor73NbXj/nDbzqtbDGBJrlhprT2DdVPVgOdQ4jk9sA=; b=PcyZueFYwmXj881EK8GlhLZdHBEf9gzkyiIs3RP+4M2uYwr2coHF8zcwBnFrOE2kyI sPGnb4Wug2hCrSVJNpB1HhIEJ5HG7hwXDaIXlmiPfFgGjEY2zs/b7j8QNa/t5sM15an3 aCs7FXUMPTsq+u32xaoXtzEgOkP+6Yp7X49qQhviY1BWferjDKuBalkiLwnHA8VVJ5o9 b0/C0fGd0ydJ3HSeT7nZSBvsLUfnaG2ORdZFkQ7Yu4vlhKlUdCwCxI+hrZ8N3qVTZmTx bSVaKgTwgvjbyuhVs03dYgLENIzH3BW9kzeiAcOTs4tEC1093chXei10hdIxDmCuRONN gGoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=vor73NbXj/nDbzqtbDGBJrlhprT2DdVPVgOdQ4jk9sA=; b=alIqLG45fo5g/jECshVReEw6ue7ef4rm/iwuARixpx54bLB4BFd07BPB1s4ee29kQL PPwNfP56LtBCNl7TB0srYwCQTChkP7pv1uaO3pO5eU6Rua7J7sxx6LbKMptCcjFTSJ6F 1T8nCzUQqXxTmv0G3vmmKzilZBt7wMfrECb4QzKbY0Al25h/ggv7yKBKb6VTUV9hJTeH jVrZV3LaF2Lmvrf5IztjtZz/bqect5n5gqeQLWMHhImVW9k8NAQInJTZC7WOufc5wPnR IflC/vrBvausnT7tIU7bY7Ter1kLRkZX/Hvxf3ezCoM0fZBK6ywNNJ/mCO+wpdpS00Me qbZg== X-Gm-Message-State: ALQs6tAVoj6fOsR6knrKJbHSE1Css3smzkTPqKC13QeJx66D/A7yqQI8 jryEKwbCvjj15R7eROp3n8Mf+Q== X-Google-Smtp-Source: AIpwx4/BljpVxVCWI5keS+WiYskVkbffx00aBqQlrxjwpVU617HKGtExydZvmyNjc34K/9RnDQykLQ== X-Received: by 2002:a19:9d12:: with SMTP id g18-v6mr13090959lfe.142.1522929657022; Thu, 05 Apr 2018 05:00:57 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id p74-v6sm1492385lfe.42.2018.04.05.05.00.55 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 05 Apr 2018 05:00:56 -0700 (PDT) From: "Valery Smyslov" To: Date: Thu, 5 Apr 2018 15:00:30 +0300 Message-ID: <003d01d3ccd5$b23ba4f0$16b2eed0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdPM0w8OT6u0CfHeTWejG0q4T3liSw== Content-Language: ru Archived-At: Subject: [IPsec] RFC8229 (IKE over TCP) and retransmissions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 12:01:01 -0000 Hi, after re-reading RFC8229 several times I cannot find any language about retransmitting IKE messages in case of TCP. Clearly, the behavior described in Section 2.1 is wrong in case of TCP, since TCP provides a reliable transport. Blindly following these recommendations would only make things worse, in case of network congestion, since it increases the amount of data TCP would try to resend, and thus increasing congestion even more. Ideally, some text should have been added, similar to the text clarifying using IKE fragmentation in case of TCP. Something like that: TCP provides reliable transport, so there is no need for application to deal with retransmissions. Moreover, performing retransmissions by IKE in case of TCP on congested networks could further increase congestion and degrade performance. For this reason IKE initiator SHOULD NOT retransmit requests if they are sent over TCP. However, IKE responder MUST correctly handle retransmitted request messages received over TCP, but it SHOULD NOT resend response messages in this case. I think not having such a recommendation in RFC8229 is an oversight. I'm not sure though it's worth filling in errata... What the WG thinks? Regards, Valery. From nobody Thu Apr 5 05:08:59 2018 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 996521272E1 for ; Thu, 5 Apr 2018 05:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] 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 zQ2X7sEyEenN for ; Thu, 5 Apr 2018 05:08:57 -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 D0BEF1271FD for ; Thu, 5 Apr 2018 05:08:56 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 40H1ny4KHzz2Cg; Thu, 5 Apr 2018 14:08:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1522930134; bh=2chqSdi2BtQG34/qfe3Nj1t/UtF//WfKdRWbih6vSlo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=dzRiGmKEKrxdPm2BoEnTH0ntvefBvzeUBCtc4Aj0/x8E5MrtJkaFNu8snbcUhD/nl NUMz8MuwSmxhhPLPY5D2hfRH2wANGsVFZiKt4G9jxTKe6XA6LY561BN+nwuMiqI5u3 AbeMu9oq8AqWX5qVVTinCqRuMlcVU/FqvjNy4Cv8= 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 uQM7TUJYVSS4; Thu, 5 Apr 2018 14:08:53 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 5 Apr 2018 14:08:53 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id B5AD93531DD; Thu, 5 Apr 2018 08:08:52 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca B5AD93531DD Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id AD73C4095AA6; Thu, 5 Apr 2018 08:08:52 -0400 (EDT) Date: Thu, 5 Apr 2018 08:08:52 -0400 (EDT) From: Paul Wouters To: Valery Smyslov cc: "ipsec@ietf.org WG" In-Reply-To: <003c01d3ccd2$db7c20e0$927462a0$@gmail.com> Message-ID: References: <11057.1522877721@obiwan.sandelman.ca> <003c01d3ccd2$db7c20e0$927462a0$@gmail.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] PLMTUD probes for IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 12:08:58 -0000 On Thu, 5 Apr 2018, Valery Smyslov wrote: > Why IKE messages cannot be used for this purpose? IKE messages might not take the same path, eg ESP goes through hardware offload or other things, or intermediary routers might have different rules for UDP vs ESP. Paul From tobias.brunner@hsr.ch Thu Apr 5 05:26:52 2018 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 839CC12D87F for ; Thu, 5 Apr 2018 05:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Hkdm9UjLUWUC for ; Thu, 5 Apr 2018 05:26:49 -0700 (PDT) Received: from mx1.hsr.ch (mx1.hsr.ch [152.96.36.31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CB1E126CC7 for ; Thu, 5 Apr 2018 05:26:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.hsr.ch (Postfix) with ESMTP id C490A23B294C; Thu, 5 Apr 2018 14:26:47 +0200 (CEST) Received: from mx1.hsr.ch ([127.0.0.1]) by localhost (mx1.hsr.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kSDCcPzAtA_U; Thu, 5 Apr 2018 14:26:46 +0200 (CEST) Received: from webmail.hsr.ch (sid00233.hsr.ch [152.96.21.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.hsr.ch (Postfix) with ESMTPS id 0CBDB23B294B; Thu, 5 Apr 2018 14:26:46 +0200 (CEST) Received: from [192.168.2.100] (152.96.21.199) by sid00233.hsr.ch (152.96.21.236) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1261.35; Thu, 5 Apr 2018 14:26:45 +0200 To: Valery Smyslov , References: <003d01d3ccd5$b23ba4f0$16b2eed0$@gmail.com> From: Tobias Brunner Message-ID: <1c0066f6-9bcf-75f1-a540-6babc03c481f@hsr.ch> Date: Thu, 5 Apr 2018 14:26:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <003d01d3ccd5$b23ba4f0$16b2eed0$@gmail.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [152.96.21.199] X-ClientProxiedBy: sid00234.hsr.ch (152.96.21.234) To sid00233.hsr.ch (152.96.21.236) Archived-At: Subject: Re: [IPsec] RFC8229 (IKE over TCP) and retransmissions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 12:42:27 -0000 Hi Valery, I agree that generally retransmits are not useful or needed with TCP encapsulation. But as I see it, retransmits might actually be required in some situations. If the client sends e.g. a CREATE_CHILD_SA request but the TCP connection is closed or gets unusable for some reason before the server's response is received, the client has to reestablish the TCP connection. And the only way to do this (with window size 1, so no DPD or MOBIKE update can be sent) is to send a retransmit of the already sent message (otherwise the server might not know which TCP connection to use to send the CREATE_CHILD_SA response - I guess ESP packets could be used for that too, if there are any and there is a way to get notified in userland). On the other hand, RFC 8229 explicitly says that a responder should not consider retransmitted messages when deciding which TCP connections should be used...so I guess there is no way to recover properly if the TCP connection is severed mid-exchange (e.g. because a NAT device is rebooted or the client device roams between networks). Regards, Tobias From nobody Thu Apr 5 05:48:35 2018 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 C9B65127201 for ; Thu, 5 Apr 2018 05:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19vE_scXnd13 for ; Thu, 5 Apr 2018 05:48:32 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EFC11273B1 for ; Thu, 5 Apr 2018 05:48:32 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id c24so28195864wrc.6 for ; Thu, 05 Apr 2018 05:48:32 -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=0gj8BUEwIxKkvQLfbR09GA+pgibDqu5/cqnYiz2ioLs=; b=q5A9HSRrupuGvGOskqenkk88YxADjXsLpxGX81LqgkbNbM8i2Yrifdgix8g8BSCpfb cx+uYBX8omPiFGjAi95DjUUuLJEwop1XwuPD9r5Zbc6FUSiiqbGTGv9CEORU3NO6aqIN hmW1lTMdvnnwB157495w3mMBCQN0X/2jIDBIYMVZNB0tPLFDp3mGGjqzuiVU5LJK1F23 hxESLV7hZdwjwuxbJrz1d8eHU5UGwlx7GsGQMcNhwnB2tJn3oH+cwXxyOAbj78Rb1s2n 4tj74Hl0s01CEja0D2oxdEH+XLT5xctUjR31Ko1G7cqXg7iBQMmmXo8tr7gPQYH5pW98 Ln9g== 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=0gj8BUEwIxKkvQLfbR09GA+pgibDqu5/cqnYiz2ioLs=; b=h+r3Rl744hE21JFIO9oBpaOGQ9QjK5f31vXwkV/SXneLEdYJFeJD/8GQ1WwLiB4zNX 9lkTB+9jMn1rX3ZZsZ+fkSbMq3Tid2IlBr2ESBjEkpw7Jc0bZJ3DcdLZK7Tfx1g956Jc 5UAjBRUyxTNkPF4UpUG/xbpTmo64hLJiZCMH09RrVz5zjm/shL5MaBtIzHU/lMbIspdn BLo2ZbhSou9sFhNcuru69UmHmcBC6z+FpDeeEqQRnGTrjjpYbsbLkj73HsU+ELMHSIh0 ge42et3bYP0n+Bo6Of+Klq1513kmcXJudQmEpr2jvlrVn4/QOhJXZYl/wLnZOq7MHFAg 5qkA== X-Gm-Message-State: ALQs6tDkSwXtCzu/11x2/Df8/PiH9fgA5O4wxe+hopra5kF/Yv96WHTj 6vLhRywxIxc2Enn3paHT2IFa0g== X-Google-Smtp-Source: AIpwx48HdtTxBTelo06VPSlW5p9YIjhVeEDvWdfCNWiUuI4THjkws0wuq8sRO/Kb8h97t/aACpy8Zw== X-Received: by 2002:a19:7904:: with SMTP id u4-v6mr13997871lfc.129.1522932510577; Thu, 05 Apr 2018 05:48:30 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id h10sm1283774ljc.96.2018.04.05.05.48.29 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 05 Apr 2018 05:48:29 -0700 (PDT) From: "Valery Smyslov" To: "'Paul Wouters'" Cc: References: <11057.1522877721@obiwan.sandelman.ca> <003c01d3ccd2$db7c20e0$927462a0$@gmail.com> In-Reply-To: Date: Thu, 5 Apr 2018 15:48:04 +0300 Message-ID: <004201d3ccdc$572dd810$05898830$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHmG7ZZeeXklvSuJytvO9qNpqEvtwJ2ehx1Athn4PijowmE8A== Content-Language: ru Archived-At: Subject: Re: [IPsec] PLMTUD probes for IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 12:48:34 -0000 Hi Paul, > > Why IKE messages cannot be used for this purpose? > > IKE messages might not take the same path, eg ESP goes through hardware > offload or other things, or intermediary routers might have different > rules for UDP vs ESP. True, unless UDP encapsulation is used... Regards, Valery. > Paul From nobody Thu Apr 5 06:11:21 2018 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 6C36912751F for ; Thu, 5 Apr 2018 06:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtjCfENSWn_c for ; Thu, 5 Apr 2018 06:11:19 -0700 (PDT) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::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 156AA127241 for ; Thu, 5 Apr 2018 06:11:19 -0700 (PDT) Received: by mail-wr0-x232.google.com with SMTP id l49so28315802wrl.4 for ; Thu, 05 Apr 2018 06:11:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=hvYaxJnTPTv9eQSH48CoYgN8JqkVDoOY+yP5ngiFTt8=; b=SLZTWHoIgOoD3PSizJYtdHGfn55spZed4vNlqXAzRvY7NJJV761nwVmF7zjdevRSy9 bgAlxSQQy2aVZS8ZsbQhwihUTM8dl6HGvbjlkppFtcIBw7ZaX/5ooaqQQ1aABS8vmk8x xeCPbMR0+GFcRbqE3/0oqe+zgE1SxhCVH8Yzxm6t70w7lSyY3Y6qr5p59UfDnRRfuqxC V2P4cWR+Oqqo6iqbORTZc/y30F8Jo3p8RU44VsuPlOUoMgxQpFd6JjH/850PMQ0hfnq1 sdMIcKFbdVIThpcyZYvmYvmB27NbTgnSrPO24Svrf4LcHlZDUY0AK8eGqaNWRHuu9g6M lOAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=hvYaxJnTPTv9eQSH48CoYgN8JqkVDoOY+yP5ngiFTt8=; b=X47AbXVkZFDu4ujCtdz0f8bYtDxq/0vApvNn3m26CJ5BmFzqJm4uD5EZYA9PfsfJf1 j29b+1sbUzQjzykTjj8gjWNSQtc7eGwp5LTqqN6EDBOVYB/nFJ+4i9lHj336wuQRl5x4 SD2VEekdiD7lAGUdEzD5iKtRUEklTNBOPVlMYJG5lz99HRFye5Y46i0d3fVEepB5oH+F +moReC3sTG7Ovstu4IuqfcPy8zOz8O+4dJIjiUpSRWiJu13o4HKZnUrIlpEwuzNWIE1h G0L61wHtVvzyco/TrxqMDxA/PPh4i76Y1GB/iOKVXLpWjjwkdrgBYursl5hPbSdPyP5v O3Tw== X-Gm-Message-State: ALQs6tBjkCGURIJed/a9zPXzaQDvtk955XRvGuhxkVjH8LRz4vO5kC9P C9msBEPqqhF797xYymuUdHxPTw== X-Google-Smtp-Source: AIpwx48CoCCHqcMTgsou3+WhYU19/Xi0w3/GWK89sk2lMpng1d4jhoXpGuCWOV5VkBKplXuZ1pvEGw== X-Received: by 2002:a19:101a:: with SMTP id f26-v6mr14097954lfi.42.1522933877307; Thu, 05 Apr 2018 06:11:17 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id h28-v6sm1522108lfb.8.2018.04.05.06.11.16 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 05 Apr 2018 06:11:16 -0700 (PDT) From: "Valery Smyslov" To: "'Tobias Brunner'" , References: <003d01d3ccd5$b23ba4f0$16b2eed0$@gmail.com> <1c0066f6-9bcf-75f1-a540-6babc03c481f@hsr.ch> In-Reply-To: <1c0066f6-9bcf-75f1-a540-6babc03c481f@hsr.ch> Date: Thu, 5 Apr 2018 16:10:50 +0300 Message-ID: <004701d3ccdf$85bf33b0$913d9b10$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDE/XaJJ0pqNUMnBkikS/JKiX14TALoWEGHpfiAW/A= Content-Language: ru Archived-At: Subject: Re: [IPsec] RFC8229 (IKE over TCP) and retransmissions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 13:11:20 -0000 Hi Tobias, > Hi Valery, > > I agree that generally retransmits are not useful or needed with TCP > encapsulation. But as I see it, retransmits might actually be required > in some situations. If the client sends e.g. a CREATE_CHILD_SA request > but the TCP connection is closed or gets unusable for some reason before > the server's response is received, the client has to reestablish the TCP > connection. And the only way to do this (with window size 1, so no DPD > or MOBIKE update can be sent) is to send a retransmit of the already > sent message (otherwise the server might not know which TCP connection That's why I suggested SHOULD :-) > to use to send the CREATE_CHILD_SA response - I guess ESP packets could > be used for that too, if there are any and there is a way to get > notified in userland). On the other hand, RFC 8229 explicitly says that > a responder should not consider retransmitted messages when deciding > which TCP connections should be used...so I guess there is no way to > recover properly if the TCP connection is severed mid-exchange (e.g. > because a NAT device is rebooted or the client device roams between > networks). Yes, there may be situations which are difficult to recover from... Regards, Valery. > Regards, > Tobias From nobody Thu Apr 5 08:08:50 2018 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 2627312762F for ; Thu, 5 Apr 2018 08:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 kRp_QRyKStKr for ; Thu, 5 Apr 2018 08:08:48 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52084127522 for ; Thu, 5 Apr 2018 08:08:48 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id BD6B120090; Thu, 5 Apr 2018 11:18:39 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9896E8105F; Thu, 5 Apr 2018 11:08:47 -0400 (EDT) From: Michael Richardson To: "Valery Smyslov" cc: ipsec@ietf.org, "'Ronald Bonica'" In-Reply-To: <003c01d3ccd2$db7c20e0$927462a0$@gmail.com> References: <11057.1522877721@obiwan.sandelman.ca> <003c01d3ccd2$db7c20e0$927462a0$@gmail.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.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] PLMTUD probes for IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 15:08:50 -0000 --=-=-= Content-Type: text/plain Valery Smyslov wrote: >> > Dynamic IPsec PMTU PLPMTUD - Shibu Piriyath, Ron Bonica >> > https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-packetization-layer-path-mtu- >> discovery-01 >> >> > Problem: IPsec Tunnel has an PMTU as any other tunnel. >> > Solution in Transport Area: Inband Path discovery >> >> I spoke to Ron afterwards, and I'm very enthusiatic about getting PLPMTUD >> widely deployed. We didn't get to this slides, so we didn't figure >> out what he needs. Slides talk about an IP-level probe that IPsec >> encapsulators can use to get estimate for tunnel inner MTU. > Why IKE messages cannot be used for this purpose? I think that possibly it can, and this is the kind of discussion that I think we should have. The advantage of doing that is that it requires no new code on the responder! That's a big win for deploying. It means that this can be done unilaterally, no new specification, just implementation advice. The slight implementation challenge is making sure that the IKE traffic is going along the same path as the ESP traffic. I'd like to hear from Ron about whether this is an issue. I also thought about using having some plpmtud on each end make a TCP connection *within* the tunnel and use the already defined plpmtu for TCP. That might be really easy for systems without user/kernel divisions (some router kernels). It would require some notifications to indicate that the responder has a TCP port open. And of course, the traffic would have to fit into the tunnel as well. > Regards, > Valery. >> But, if we can get PLMTUD deployed for all traffic, then the end-nodes can >> do appropriate PMTU probing and can figure out what the inner MTU is. >> i.e. just get everyone to enable plpmtu (4821). It's a knob on most >> systems, which has been left in the off state because of lack of evidence >> that it isn't harmful. >> >> There seems to be some sticking points among the high-speed about CDNs: >> they hate all PMTUD as it screws with tx scheduling into hardware. >> (TCP segment offload issues) >> >> So they just use 1280 is what I was told. That's good for the network, but >> it removes them as strong allies for getting PLPMTUD enabled by default >> everywhere. It would be nice if we could get a BCP out of them. Such >> BCP could also bless PLPMTUD for everyone else. I was pushing for this >> with RFC8200/STD86 but there was insufficient evidence of deployment. >> >> -- >> Michael Richardson , Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlrGO/8ACgkQgItw+93Q 3WVUjQgAvc68ODkw63IqMmBhIG9Yay9sOXJBcuyozdJ2xkwoZjcw8aD5mxsO9Ze+ 0cIqtOh9L/aMQlPMXv+GKRyr9FbQ1Pi5uYiISPYQDke52KxknS+TFMykgSG/peI+ RGD9dM4gdLCvtpJAP4pjvGhuH/baBBHkqsfIZ6EDiXostoX6724tD8NB8ppp1+JM 2HW8f5SwjUcucoiFTaSxhiQq9cE/MnY3j3FnhBbjckMcuc7HVmWJ1w4TedaK4LFN GvQNy9jnUFPYEOQplHmc5laIWvYvg7TBj0+oSE5Puegw1gNFUfkPjfthcO6CRrQy 4NOwSrw2ABBd4VXc3mfBdZ7M6/o/qQ== =ftgJ -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 5 08:59:30 2018 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 CFA0D12D953 for ; Thu, 5 Apr 2018 08:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 JxD1p9lVoYRQ for ; Thu, 5 Apr 2018 08:59:26 -0700 (PDT) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (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 5DB9D12DA02 for ; Thu, 5 Apr 2018 08:59:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1522943964; x=2386857564; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=dI2gluFDubfwBY1TAJ1sun2gBFGhO35y8EJ5a9O4S2Y=; b=styHsHwaSTYAqR0YciDNlw6UWr5AnrkB6+18vWmyqnM+hG/RECQlcgAaqS9c97ox PAnZCsLaD0GktX2C/H2ohf40lV6M9imB8TVyMptVg+J6bdq/yCrcm5yOMapTjBdr jmiabBk+559OvSnV3wmH9c1zyaQ5hC+2HYTus1uHYwN0OEwPEWCgr2YF4Qqz1pvk gNgNjOS7JVz+7qWEmbKV0uwAJ59/MxmCfzi55ZEF0qU9UOiBSyq3AbQnBcCM4a2O b7Nkk+1BuaXRlVTouN+NDLZ+WTqedg7ocQQJj20dRsgD+gOahJ35HDYO7JlNRwTL aRsjl4jP44YdgZhc01N4Ng==; Received: from relay7.apple.com (relay7.apple.com [17.128.113.101]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 2D.F2.28259.CD746CA5; Thu, 5 Apr 2018 08:59:24 -0700 (PDT) X-AuditID: 11973e15-a0bff70000006e63-37-5ac647dc0e02 Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by relay7.apple.com (Apple SCV relay) with SMTP id 24.2B.21982.BD746CA5; Thu, 5 Apr 2018 08:59:24 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.234.98.217] (unknown [17.234.98.217]) by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180130 64bit (built Jan 30 2018)) with ESMTPSA id <0P6P008F1Z2Y7N20@nwk-mmpp-sz10.apple.com>; Thu, 05 Apr 2018 08:59:23 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: <004701d3ccdf$85bf33b0$913d9b10$@gmail.com> Date: Thu, 05 Apr 2018 08:59:21 -0700 Cc: Tobias Brunner , ipsec@ietf.org Content-transfer-encoding: quoted-printable Message-id: <57E5EDE3-55A4-4A9A-BCEF-BA0A80386D20@apple.com> References: <003d01d3ccd5$b23ba4f0$16b2eed0$@gmail.com> <1c0066f6-9bcf-75f1-a540-6babc03c481f@hsr.ch> <004701d3ccdf$85bf33b0$913d9b10$@gmail.com> To: Valery Smyslov X-Mailer: Apple Mail (2.3458) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUi2FCYqnvH/ViUwbdtHBb7t7xgs9h4Zim7 xeO7UxgdmD12zrrL7tEw8xG7x5IlP5kCmKO4bFJSczLLUov07RK4Mp7efcFS8Fus4uWc38wN jJuEuhg5OSQETCQWvJ/JBmILCaxhkri8RwsmPnnVEpYuRi6g+AYmiQ23ljCCJHgFBCV+TL4H lODgYBZQl5gyJReiZiKTRNuGtawgcWEBCYnNexJByoUF7CUW797PCmKzCahIHP+2gRmkhFPA QuLe7WSQMIuAqsT5+xBhZgEriRU90iBhZgFtiSfvLoAN5BWwkXh12hriyKmMElev5ILYIkAl VzvvskMcLCuxcvZdVpBjJASmsEm8bX7COoFReBaSm2ch3DwLyYYFjMyrGIVyEzNzdDPzzPQS CwpyUvWS83M3MYKCfLqd6A7GM6usDjEKcDAq8fA2fDsSJcSaWFZcmXuIUZqDRUmc96jY0Sgh gfTEktTs1NSC1KL4otKc1OJDjEwcnFINjBuOuD9bf1H3/tSn1xu3C91fpR/NwP6ooSJEes7i awsflD5/YDXP5b68/pXciav5dze89rnqwF9e+UJR4s7vJd8PrJZ12Htrs0NjePZKnWc39fWW TnsqVrrhzsIZHV4FWWmWf5NKfx5V5dx0aiZDx1EbLdbQu8+nvxXk+1+a8Lcj89ovk/e+ymxK LMUZiYZazEXFiQBt7qmwUwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUi2FBcpXvH/ViUwZ7JrBb7t7xgs9h4Zim7 xeO7UxgdmD12zrrL7tEw8xG7x5IlP5kCmKO4bFJSczLLUov07RK4Mp7efcFS8Fus4uWc38wN jJuEuhg5OSQETCQmr1rC0sXIxSEksIFJYsOtJYwgCV4BQYkfk+8BJTg4mAXUJaZMyYWomcgk 0bZhLStIXFhAQmLznkSQcmEBe4nFu/ezgthsAioSx79tYAYp4RSwkLh3OxkkzCKgKnH+PkSY WcBKYkWPNEiYWUBb4sm7C2ADeQVsJF6dtgYJCwlMZZS4eiUXxBYBKrnaeZcd4mBZiZWz77JO YBSYheTMWQhnzkIydAEj8ypGgaLUnMRKc73EgoKcVL3k/NxNjOCwLEzdwdi43OoQowAHoxIP b8O3I1FCrIllxZW5hxglOJiVRHgjtI5FCfGmJFZWpRblxxeV5qQWH2KU5mBREuedufpolJBA emJJanZqakFqEUyWiYNTqoFxqvSvaT0eqtKMM15N8NbSZM87+Hhf6HPzc6UbpWJW5Kqvff+/ ooNfwTzIcenkGZzHai7z+GalaVx8pWf45BbDEYUWl5eWZ/03Rqtou080u6iwmHP5X5aYmxOn ci1IWHDA/Yhfywrx/1JTt7xqX1goxyZ0pyYoZ6rNUjXNiUp2eimLtYM8ZygrsRRnJBpqMRcV JwIAjzf8kUcCAAA= Archived-At: Subject: Re: [IPsec] RFC8229 (IKE over TCP) and retransmissions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 15:59:29 -0000 Hi Valery, Thanks for bringing this up with the WG! I agree that retransmissions of IKE packets within the TCP stream may be = pointless, and add to congestion. We do mention this for ESP packets = over the TCP stream (Section 12.2 Added Reliability for Unreliable = Protocols), but it doesn=E2=80=99t call out IKE specifically. Depending on how TCP encapsulation is implemented on each peer, it may = be safe to assume that the entire end-to-end communication is reliable, = but it may not be. In our testing of the protocol, we have placed boxes = in front of IKEv2 responders that handle the TCP encapsulation and = translate them into UDP packets to pass on to the vanilla IKEv2 = responder. In this case, the end-to-end reliability can=E2=80=99t be = guaranteed, and the initiator of a message then may still need to = retransmit IKE packets. If we did want to add a recommendation here, I=E2=80=99d be tempted to = say that an implementation should certainly be less aggressive with = retransmissions in IKE, but may still send them if there is a lack of = response from the remote peer. I=E2=80=99m not overly concerned with the = impact of retransmitting IKE packets on the stream to overall tunnel = performance, since these generally only account for a few packets. Thanks, Tommy > On Apr 5, 2018, at 6:10 AM, Valery Smyslov = wrote: >=20 > Hi Tobias, >=20 >> Hi Valery, >>=20 >> I agree that generally retransmits are not useful or needed with TCP >> encapsulation. But as I see it, retransmits might actually be = required >> in some situations. If the client sends e.g. a CREATE_CHILD_SA = request >> but the TCP connection is closed or gets unusable for some reason = before >> the server's response is received, the client has to reestablish the = TCP >> connection. And the only way to do this (with window size 1, so no = DPD >> or MOBIKE update can be sent) is to send a retransmit of the already >> sent message (otherwise the server might not know which TCP = connection >=20 > That's why I suggested SHOULD :-) >=20 >> to use to send the CREATE_CHILD_SA response - I guess ESP packets = could >> be used for that too, if there are any and there is a way to get >> notified in userland). On the other hand, RFC 8229 explicitly says = that >> a responder should not consider retransmitted messages when deciding >> which TCP connections should be used...so I guess there is no way to >> recover properly if the TCP connection is severed mid-exchange (e.g. >> because a NAT device is rebooted or the client device roams between >> networks). >=20 > Yes, there may be situations which are difficult to recover from... >=20 > Regards, > Valery. >=20 >> Regards, >> Tobias >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Apr 5 13:01:22 2018 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 733BD12D779 for ; Thu, 5 Apr 2018 13:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GN-KPwMrjDal for ; Thu, 5 Apr 2018 13:01:17 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 1EBE7127058 for ; Thu, 5 Apr 2018 13:01:17 -0700 (PDT) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w35JxZ2Z015490; Thu, 5 Apr 2018 13:01:14 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=g/QEYz32TS1Y0s1tX3X4bjQkLqeOG7UaMH3JI5HBbd4=; b=R3tNDTbvwi9Oyi1yfX8G4P2FPwfvi46swjuh4Pzrk2oRd+DNxcXkcpI7DIR9Kd+zhLuE zRzVqUuyxFDdM/0el2qb4J+PyuhcoPUvrvkZTkakBxpjaMJKPvu0TfL4i+y2V2t2+pEV Ggezw/5WkPXHDWuKrUGwIR78T7S0n9JP42t7kD8LbYxX9K+fsEu8+ISA0f6P4h8/BRWH vAv6ma8IvUlNZD0hNfxFzJTNKoFJZ2+ErEISJYrUyscVjrZMlCWOGhfpmWl2KoIJEk1W zluP4b6IkBzvIcOZ3YdqHadgCv4GTZia+zXQaCXOtGCpPv4AXu5GEKAFzma871944ol2 ZA== Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0088.outbound.protection.outlook.com [207.46.163.88]) by mx0a-00273201.pphosted.com with ESMTP id 2h5r2tragh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 05 Apr 2018 13:01:14 -0700 Received: from SN6PR05MB4240.namprd05.prod.outlook.com (52.135.67.146) by SN6PR05MB4415.namprd05.prod.outlook.com (52.135.74.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.631.10; Thu, 5 Apr 2018 20:01:12 +0000 Received: from SN6PR05MB4240.namprd05.prod.outlook.com ([fe80::59a2:13ab:6110:35af]) by SN6PR05MB4240.namprd05.prod.outlook.com ([fe80::59a2:13ab:6110:35af%13]) with mapi id 15.20.0675.004; Thu, 5 Apr 2018 20:01:12 +0000 From: Ron Bonica To: Michael Richardson , Valery Smyslov CC: "ipsec@ietf.org" Thread-Topic: [IPsec] PLMTUD probes for IPsec Thread-Index: AQHTzFzZgVjUC3J1w0emDs0mik2FjKPyDPuAgAA6SYCAAE+HAA== Date: Thu, 5 Apr 2018 20:01:11 +0000 Message-ID: References: <11057.1522877721@obiwan.sandelman.ca> <003c01d3ccd2$db7c20e0$927462a0$@gmail.com> <1172.1522940927@obiwan.sandelman.ca> In-Reply-To: <1172.1522940927@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR05MB4415; 7:ltRcH9MSRNiWk1o0MwKwZ+QBiZ3X3xcHqnY0eJJ2idkv6sZcnRBrtd1LHuN+6KHFB7yjWqueZLHe4p1do6ksPSh8jGD9mmA8IITfVmkPt/JUWqb5GL1oHEl9OtjyAmLohCsyn7mjhi7Jxe8uVnTPjlNC5urluaj2LpwyvDKAZGCuG6M0T4iZdu6W+WGHT6d2ztp4IC87slS4K2AoaQBrFkIeCWszIiQUGzx2gkQtdoQOMuCdyhCD6QV/y3HDsFo1 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 562cc7c2-38f4-4db8-f090-08d59b2ffb0b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:SN6PR05MB4415; x-ms-traffictypediagnostic: SN6PR05MB4415: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(138986009662008)(85827821059158); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231221)(944501327)(52105095)(10201501046)(3002001)(6055026)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:SN6PR05MB4415; BCL:0; PCL:0; RULEID:; SRVR:SN6PR05MB4415; x-forefront-prvs: 06339BAE63 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(39860400002)(346002)(396003)(39380400002)(13464003)(51444003)(189003)(199004)(14454004)(186003)(7736002)(99286004)(26005)(106356001)(81166006)(446003)(81156014)(25786009)(97736004)(3660700001)(5660300001)(8676002)(7696005)(102836004)(68736007)(4326008)(74316002)(2900100001)(76176011)(66066001)(86362001)(53546011)(6506007)(305945005)(3280700002)(110136005)(9686003)(6436002)(478600001)(55016002)(33656002)(316002)(6306002)(53936002)(105586002)(5250100002)(486006)(6246003)(39060400002)(966005)(8936002)(229853002)(2906002)(11346002)(6116002)(3846002)(476003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR05MB4415; H:SN6PR05MB4240.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: yNW7qToia1dLh8Qg1TdpBGd7I+G9yk5f3io1UQXDQUU1UhQ31WNuM0y7hvVsvYdT08CfhNSWLqZ00rBCkcyRicJEluZKy20MvA7WQvXmW/9wlCj/DNfzct7hQXJ2d9bOZpUnLnl9FHR4QztOqXII0FjzlbUBaUKJt2h4wXCklfqkdKIO5lIoVoYyJg1BXfsdJtxSpZ3QPq2TEC1dc+3k989lkDc0pb6iRo2qCaajlpJOERQE1IyjFqaZO6oUY/OP9dtfKlEdtrgbcpQxCC5YelUsw+oUYo0NV/oMLvYSN85dmyqdmNktp7dcCXIBZfLuDRzMq8aCbv+oLhesHgDBV/2zkVmW9dpYwqko67t903DdYeeZ0KvjzOI6J83LINM2ECGOihZr8cqt4r5XCBYioUxdiDvk6XDpztdxjdLcKvk= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 562cc7c2-38f4-4db8-f090-08d59b2ffb0b X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2018 20:01:11.9674 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR05MB4415 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-05_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804050203 Archived-At: Subject: Re: [IPsec] PLMTUD probes for IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 20:01:19 -0000 Folks, In the first version of this draft, we leveraged IKE to exchange messages. = And provided with a good enough reason, we might go back to that position! We moved away from IKE for the following reasons: - The path between the encrypting and decrypting nodes might include ECMP. = If so, IKE messages might take a different path than actual encrypted data - The current method provides the same level of protection as IKE and possi= bly better performance - The current doesn't require changes to IKE Are these reasonable assumptions. If not, we would be happy to return to th= e IKE solution. Ron > -----Original Message----- > From: Michael Richardson > Sent: Thursday, April 5, 2018 11:09 AM > To: Valery Smyslov > Cc: ipsec@ietf.org; Ron Bonica > Subject: Re: [IPsec] PLMTUD probes for IPsec >=20 >=20 > Valery Smyslov wrote: > >> > Dynamic IPsec PMTU PLPMTUD - Shibu Piriyath, Ron Bonica > >> > https://datatracker.ietf.org/meeting/101/materials/slides-101- > ipsecme-packetization-layer-path-mtu- > >> discovery-01 > >> > >> > Problem: IPsec Tunnel has an PMTU as any other tunnel. > >> > Solution in Transport Area: Inband Path discovery > >> > >> I spoke to Ron afterwards, and I'm very enthusiatic about getting > PLPMTUD > >> widely deployed. We didn't get to this slides, so we didn't figur= e > >> out what he needs. Slides talk about an IP-level probe that IPsec > >> encapsulators can use to get estimate for tunnel inner MTU. >=20 > > Why IKE messages cannot be used for this purpose? >=20 > I think that possibly it can, and this is the kind of discussion that > I think we should have. The advantage of doing that is that it requires > no new code on the responder! That's a big win for deploying. > It means that this can be done unilaterally, no new specification, just > implementation advice. >=20 > The slight implementation challenge is making sure that the IKE traffic i= s going > along the same path as the ESP traffic. I'd like to hear from Ron about > whether this is an issue. >=20 > I also thought about using having some plpmtud on each end make a TCP > connection *within* the tunnel and use the already defined plpmtu for TCP= . > That might be really easy for systems without user/kernel divisions (some > router kernels). It would require some notifications to indicate that the > responder has a TCP port open. And of course, the traffic would have to = fit > into the tunnel as well. >=20 >=20 >=20 >=20 > > Regards, > > Valery. >=20 > >> But, if we can get PLMTUD deployed for all traffic, then the end-n= odes > can > >> do appropriate PMTU probing and can figure out what the inner MTU = is. > >> i.e. just get everyone to enable plpmtu (4821). It's a knob on mos= t > >> systems, which has been left in the off state because of lack of > evidence > >> that it isn't harmful. > >> > >> There seems to be some sticking points among the high-speed about > CDNs: > >> they hate all PMTUD as it screws with tx scheduling into hardware. > >> (TCP segment offload issues) > >> > >> So they just use 1280 is what I was told. That's good for the net= work, > but > >> it removes them as strong allies for getting PLPMTUD enabled by > default > >> everywhere. It would be nice if we could get a BCP out of them. = Such > >> BCP could also bless PLPMTUD for everyone else. I was pushing for= this > >> with RFC8200/STD86 but there was insufficient evidence of > deployment. > >> > >> -- > >> Michael Richardson , Sandelman Software > Works > >> -=3D IPv6 IoT consulting =3D- > >> > >> >=20 >=20 >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 From nobody Thu Apr 5 16:47:49 2018 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 E7D6912D87C for ; Thu, 5 Apr 2018 16:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 JNTc3kDfvlyI for ; Thu, 5 Apr 2018 16:47:47 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 9C0AB12DA72 for ; Thu, 5 Apr 2018 16:47:46 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w35NlhrF026014 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 6 Apr 2018 02:47:43 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w35NlhpY023516; Fri, 6 Apr 2018 02:47:43 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23238.46495.368974.995247@fireball.acr.fi> Date: Fri, 6 Apr 2018 02:47:43 +0300 From: Tero Kivinen To: "Valery Smyslov" Cc: In-Reply-To: <003d01d3ccd5$b23ba4f0$16b2eed0$@gmail.com> References: <003d01d3ccd5$b23ba4f0$16b2eed0$@gmail.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 2 min X-Total-Time: 2 min Archived-At: Subject: [IPsec] RFC8229 (IKE over TCP) and retransmissions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 23:47:49 -0000 [WG chair hat off] Valery Smyslov writes: > TCP provides reliable transport, so there is no need for application to > deal with retransmissions. Moreover, performing retransmissions by IKE > in case of TCP on congested networks could further increase congestion > and degrade performance. For this reason IKE initiator SHOULD NOT > retransmit requests if they are sent over TCP. However, IKE responder MUST > correctly handle retransmitted request messages received over TCP, but > it SHOULD NOT resend response messages in this case. I think such text should have been added to the RFC8229. > I think not having such a recommendation in RFC8229 is an oversight. > I'm not sure though it's worth filling in errata... What the WG thinks? I am not sure if it would be enough to make errata, I would actually think it might be better to make RFC8229bis to fix this issue. The problem with errata is that there are lots of people who do not notice it... So I think you should make errata of it, and we most likely should make new version of 8229 and add that text, but that is just my personal view of the issue. -- kivinen@iki.fi From nobody Thu Apr 5 23:50:12 2018 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 CF37812DA3F for ; Thu, 5 Apr 2018 23:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKrpFbrxrQBB for ; Thu, 5 Apr 2018 23:50:10 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BA4A12D86C for ; Thu, 5 Apr 2018 23:50:10 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id z73so249366wrb.0 for ; Thu, 05 Apr 2018 23:50:10 -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=v50jdkivNsoMGSTK1m1m3CeGn0qrdpAxOGyhIZ/4IG4=; b=EPmnr2sZhQp1OFjpB1OI3IUAx7gOvoX9QWURGlQrYzK9Gem2HoJQvg2JpQH41M5TwE JNBCAVU8ZZXbQbZC4SCTTpcRZeljFyysuK3g8NZOiWPf9lV4702igFDucVus/VV1y6BR L/f/8aaAmBQdiOyg1vlRzDE754tb6LpguN2tufXY5CtgYewiZaL5rzyPPS60fnVRqbE/ KG2b4iQYGA5p+sNDVX4zeTSrJG7Bd/GZ2ntRx+ut67Qj7C1onDv6SrcoUHlIGyY/MSdO 3/tJy5QHyYofMll3SNXS0yJHHTV4Ht3JsmURt/QB8Ept0rG28s5LpU7bYbWd2KAKKKdy +a9Q== 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=v50jdkivNsoMGSTK1m1m3CeGn0qrdpAxOGyhIZ/4IG4=; b=nLaS11cwj3G69my0p1WOi8pOo1xBHOvcoYmSlDGO5qnhbpiKiZ1pHcIizdh0GPsb+7 LLz+52JULgk83SfplZjBhBDS6q58BPWirOpCBxdBRu5HyNZ00hfYcomaYTyCBQL6wzU0 bq/ZK3rWxoEg5xVVuN50ot6V94XYoBuLU+O47Bv2ZHPHglf/lKWafRh58x5UVoTmYHvS xLIs3Wzzm6ewbOrUm9JlQGW4oFWewXG4PcMpPBmcB8hjX8AIx+/J74587XboBq1985FT bJ8Q5rbOkw7JCVZB9U/cVGy39tyV2cxWu2Q+vc1JjKgWkOrnmfyKQYYiu1WQm5PnNfxS lmow== X-Gm-Message-State: ALQs6tBp91n8dD7bi/dg5v+78073NNUrrm38S4PTKMpPos1GCiMctCus ScF0vEV2+2JC4QWbHk7elruI7A== X-Google-Smtp-Source: AIpwx4+AXas28qR9jCGfAzdWlLSRWrfM9Pfrcmw0cvAp+l/SaQ5evzG0bFh2p2ZTfmpaLXRLONFLsg== X-Received: by 2002:a19:9c0d:: with SMTP id f13-v6mr15376568lfe.9.1522997408454; Thu, 05 Apr 2018 23:50:08 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id q24sm1592908ljj.68.2018.04.05.23.50.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 05 Apr 2018 23:50:07 -0700 (PDT) From: "Valery Smyslov" To: Cc: "'Tobias Brunner'" , References: <003d01d3ccd5$b23ba4f0$16b2eed0$@gmail.com> <1c0066f6-9bcf-75f1-a540-6babc03c481f@hsr.ch> <004701d3ccdf$85bf33b0$913d9b10$@gmail.com> <57E5EDE3-55A4-4A9A-BCEF-BA0A80386D20@apple.com> In-Reply-To: <57E5EDE3-55A4-4A9A-BCEF-BA0A80386D20@apple.com> Date: Fri, 6 Apr 2018 09:49:42 +0300 Message-ID: <011d01d3cd73$716d2db0$54478910$@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: AQDE/XaJJ0pqNUMnBkikS/JKiX14TALoWEGHAcOV0ZoCEwXMj6Xa8xGA Content-Language: ru Archived-At: Subject: Re: [IPsec] RFC8229 (IKE over TCP) and retransmissions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 06:50:12 -0000 Hi Tommy, > Hi Valery, >=20 > Thanks for bringing this up with the WG! >=20 > I agree that retransmissions of IKE packets within the TCP stream may = be pointless, and add to congestion. > We do mention this for ESP packets over the TCP stream (Section 12.2 = Added Reliability for Unreliable > Protocols), but it doesn=E2=80=99t call out IKE specifically. >=20 > Depending on how TCP encapsulation is implemented on each peer, it may = be safe to assume that the entire > end-to-end communication is reliable, but it may not be. In our = testing of the protocol, we have placed boxes > in front of IKEv2 responders that handle the TCP encapsulation and = translate them into UDP packets to pass > on to the vanilla IKEv2 responder. In this case, the end-to-end = reliability can=E2=80=99t be guaranteed, and the initiator > of a message then may still need to retransmit IKE packets. Yeah, but it's quite unusual setting outside test lab, isn't it? > If we did want to add a recommendation here, I=E2=80=99d be tempted to = say that an implementation should certainly > be less aggressive with retransmissions in IKE, but may still send = them if there is a lack of response from the > remote peer. I=E2=80=99m not overly concerned with the impact of = retransmitting IKE packets on the stream to overall > tunnel performance, since these generally only account for a few = packets. That's why I suggested SHOULD NOT :-) Anyway, it's easy to add = recommendation that the initiator MAY retransmit message if no response is received for some (not too short) = period of time. Regards, Valery. > Thanks, > Tommy >=20 > > On Apr 5, 2018, at 6:10 AM, Valery Smyslov = wrote: > > > > Hi Tobias, > > > >> Hi Valery, > >> > >> I agree that generally retransmits are not useful or needed with = TCP > >> encapsulation. But as I see it, retransmits might actually be = required > >> in some situations. If the client sends e.g. a CREATE_CHILD_SA = request > >> but the TCP connection is closed or gets unusable for some reason = before > >> the server's response is received, the client has to reestablish = the TCP > >> connection. And the only way to do this (with window size 1, so no = DPD > >> or MOBIKE update can be sent) is to send a retransmit of the = already > >> sent message (otherwise the server might not know which TCP = connection > > > > That's why I suggested SHOULD :-) > > > >> to use to send the CREATE_CHILD_SA response - I guess ESP packets = could > >> be used for that too, if there are any and there is a way to get > >> notified in userland). On the other hand, RFC 8229 explicitly says = that > >> a responder should not consider retransmitted messages when = deciding > >> which TCP connections should be used...so I guess there is no way = to > >> recover properly if the TCP connection is severed mid-exchange = (e.g. > >> because a NAT device is rebooted or the client device roams between > >> networks). > > > > Yes, there may be situations which are difficult to recover from... > > > > Regards, > > Valery. > > > >> Regards, > >> Tobias > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Apr 5 23:58:29 2018 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 064D6128961 for ; Thu, 5 Apr 2018 23:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcV9vS7dwL-b for ; Thu, 5 Apr 2018 23:58:26 -0700 (PDT) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::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 660A8124234 for ; Thu, 5 Apr 2018 23:58:26 -0700 (PDT) Received: by mail-wr0-x232.google.com with SMTP id u46so251990wrc.11 for ; Thu, 05 Apr 2018 23:58:26 -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=kqjzmu7+dI5VfOZLzdBtbMCMKJx2kpFA+1uh03ZEROs=; b=bmdUbY2Cn4TGRpEdyr0JzkEJSjP9W6QUyg53iOoU00wieW8mVHSpJ789tiHjm8nJE5 8RtCedjj0wnZvr0RueZcyr/UdceiA+eQPyfvK8C/l2mgxjq1/25CTAN8CkVR5Y78E8SP UPvGDu2M/tSFOyomKEdQJAepIfjED79jDrZJl/Ly+iW38j5CzYXbRlMNUy0gBbPepHbS PlWe9d5eT1QCvh84opshRpD9xdnsfPlgQ+6HlPWRX1138kvOIFoi9HLuMQP0ZYBRuNXk m/GlijY8GIoyhPrnWNJ3XyekooFbCdNtPUU52TPlCsDSczh/NQfecwOsf8Nck3Mna62I LAng== 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=kqjzmu7+dI5VfOZLzdBtbMCMKJx2kpFA+1uh03ZEROs=; b=CfmrXfzdgVFumcpUnk2jGl8ktjO+eV/gclt/dgpuyYUhw0ZE3rb3YRpSabv18ncXZU kGfht7UncB4Ii/AjjZYjtO1Ou81Qad6EGEw1stzTgabub60/VAnP+9rCz20JA97syei2 c7Poa8xiyvI6N28ZS8PIgytHnaG0uMID1wLxeDbzFcvaVaEJzTLs228Gn1sYnaWoU5e0 Go/PVbPNnmRcMgDD4K9BeRWlBrZX/Z8oSQ8EYKQrXw2bPjhBn4hTLQoXpqHesVXVoVqe 5j44aY7OisJdFyoLnTwmlTqWmUu/KlpJsjhgGGFDnLWNW8R3j3z8yZnMYIZfaAekgWNt 846w== X-Gm-Message-State: ALQs6tA2IS4oPpBXk4xpz4F4yQMMaEF3pmsTLLsxI1L5fPNc3jaueGv9 4C8xzrmBwK+nVJd8utj3icQ6vQ== X-Google-Smtp-Source: AIpwx4/z/7kFoiOlmBYrm9FhLsoyEIC0/GwubV/XkSLUOWUb51lujwgnb31zT+4Xu/hwu6qmk8JPcg== X-Received: by 2002:a19:730d:: with SMTP id o13-v6mr15727221lfc.88.1522997904698; Thu, 05 Apr 2018 23:58:24 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id h10sm1618096ljc.96.2018.04.05.23.58.23 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 05 Apr 2018 23:58:24 -0700 (PDT) From: "Valery Smyslov" To: "'Tero Kivinen'" Cc: References: <003d01d3ccd5$b23ba4f0$16b2eed0$@gmail.com> <23238.46495.368974.995247@fireball.acr.fi> In-Reply-To: <23238.46495.368974.995247@fireball.acr.fi> Date: Fri, 6 Apr 2018 09:57:58 +0300 Message-ID: <011e01d3cd74$9955e500$cc01af00$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDE/XaJJ0pqNUMnBkikS/JKiX14TAFt8DsbpgV8d/A= Content-Language: ru Archived-At: Subject: Re: [IPsec] RFC8229 (IKE over TCP) and retransmissions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 06:58:28 -0000 Hi Tero, > [WG chair hat off] > > Valery Smyslov writes: > > TCP provides reliable transport, so there is no need for application to > > deal with retransmissions. Moreover, performing retransmissions by IKE > > in case of TCP on congested networks could further increase congestion > > and degrade performance. For this reason IKE initiator SHOULD NOT > > retransmit requests if they are sent over TCP. However, IKE responder MUST > > correctly handle retransmitted request messages received over TCP, but > > it SHOULD NOT resend response messages in this case. > > I think such text should have been added to the RFC8229. > > > I think not having such a recommendation in RFC8229 is an oversight. > > I'm not sure though it's worth filling in errata... What the WG thinks? > > I am not sure if it would be enough to make errata, I would actually > think it might be better to make RFC8229bis to fix this issue. The > problem with errata is that there are lots of people who do not notice > it... I don't disagree with making RFC8229bis, however I'd rather not to do it right now, but instead wait some time to gain more experience with IKE over TCP. My gut feeling is that changing TCP connections on a live IKE SA will probably need more clarifications based on real life scenarios. > So I think you should make errata of it, and we most likely should > make new version of 8229 and add that text, but that is just my > personal view of the issue. So, I'll submit errata unless someone disagree and have better proposal. I think the errata can then be marked as "Hold for document update". Regards, Valery. > -- > kivinen@iki.fi From nobody Fri Apr 6 00:24:19 2018 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 A2965126D05 for ; Fri, 6 Apr 2018 00:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A34brMqm5btu for ; Fri, 6 Apr 2018 00:24:15 -0700 (PDT) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::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 4918C126CE8 for ; Fri, 6 Apr 2018 00:24:15 -0700 (PDT) Received: by mail-wr0-x232.google.com with SMTP id c24so368306wrc.6 for ; Fri, 06 Apr 2018 00:24:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=FwLhOJujQYsWJEm1uMin6H/g6aeYfuD+OSRJlEuttIs=; b=RVxtzLgjrf/pkwpSRSSJvYqmYHBVYSPjFVD6zf2Vp97VdMQVZYcOHEZ4cNijt6LSmH xGzZtLVriVh7LT/74WIfnumji3LVgOUF/33tQdY+X45uqDzq995fvG/qNf5Lz7uMfMTr YwgjT2FDLOaCJdGPKCQuUtZKRfNWdGX7+9nMU7Vv36YVLq18UwRanUMNUAV1khBiesTr XM8XqvO8HcmPWZSNOYkrMmIGRXxCGBi/B3UBTSmqlwisAVXdLIpLaX7MnhcLIMGSUST3 XskNLR88pQU0zJ3oVK+wscm65hf2NZTu3BK9WPtoB0ceOBVzh/CI/DbIWaRQaeXS8k/R /Pfw== 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=FwLhOJujQYsWJEm1uMin6H/g6aeYfuD+OSRJlEuttIs=; b=BbdYbzMrt3Hvxg85QiRR/D24tnYVBcKJ3AepSPo64LJnc13nTFN4mimg1jWqDRW/vb HExzL1PIKEW4z7Y30JNnv7FL/xYIVXZCj6x7yV8vRe/fsfszKKgyCoekh3uqZMhgRf14 GbE7nrRmpVDSgUwnGgHBOIXNqtzn/tu+ogon4U4aBWsT/KTKellQmfX6f7EOF08ptDXZ a/srlk5IfnaaXxMskNTepDzpbUpRuR+3BZLCE8JKooFXdbsOot0ErEJlSxLoBwb7U/DB T8HQO5MhiJjnZ95pSDbO9ACKV2/JtBKhTkILTKqpF7uxFYqlbgaEaf0fV9iffnn052Qw AZnw== X-Gm-Message-State: ALQs6tAwuFavF2FOTAbAsqEANeksBzs+2y6fBVBNMhx9cDUMwcrdDCmd W8WpAUu2dvINkHj3AtJhNmn2pA== X-Google-Smtp-Source: AIpwx49TdQhhiv1bgW6zoiR1p2MTF/A9DHrXdOF4EFdhQFr1WxBENu01JmNq53skQ5U2Gw1XihAxkg== X-Received: by 2002:a19:c713:: with SMTP id x19-v6mr15919115lff.32.1522999453144; Fri, 06 Apr 2018 00:24:13 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id u3-v6sm1937021lfu.41.2018.04.06.00.24.12 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 06 Apr 2018 00:24:12 -0700 (PDT) From: "Valery Smyslov" To: "'Ron Bonica'" , "'Michael Richardson'" Cc: References: <11057.1522877721@obiwan.sandelman.ca> <003c01d3ccd2$db7c20e0$927462a0$@gmail.com> <1172.1522940927@obiwan.sandelman.ca> In-Reply-To: Date: Fri, 6 Apr 2018 10:23:47 +0300 Message-ID: <012601d3cd78$343cdd50$9cb697f0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHmG7ZZeeXklvSuJytvO9qNpqEvtwJ2ehx1AfUWGT4B/u7FiaObYSPA Content-Language: ru Archived-At: Subject: Re: [IPsec] PLMTUD probes for IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 07:24:18 -0000 Hi Ron, > Folks, > > In the first version of this draft, we leveraged IKE to exchange messages. And provided with a good enough > reason, we might go back to that position! > > We moved away from IKE for the following reasons: > > - The path between the encrypting and decrypting nodes might include ECMP. If so, IKE messages might take a > different path than actual encrypted data That's a valid concern. The only time when you can be sure that the paths are the same is when NAT traversal is in use (either because some NAT is in between, or you force it on the peers). > - The current method provides the same level of protection as IKE and possibly better performance > - The current doesn't require changes to IKE True. But with your current proposal some changes to the IPSec in kernel are needed too (or you need to have standalone client and server applications to exchange probes). Not sure what is easier. > Are these reasonable assumptions. If not, we would be happy to return to the IKE solution. I think one problem with the suggested approach is that the tunnel selectors might not allow sending packets over UDP. Consider you have "narrow" ESP SA that only allows TCP packets to go through and drops all UDP. In this case your approach won't work, or some additional heuristics would be needed. Regards, Valery. > Ron > > > > -----Original Message----- > > From: Michael Richardson > > Sent: Thursday, April 5, 2018 11:09 AM > > To: Valery Smyslov > > Cc: ipsec@ietf.org; Ron Bonica > > Subject: Re: [IPsec] PLMTUD probes for IPsec > > > > > > Valery Smyslov wrote: > > >> > Dynamic IPsec PMTU PLPMTUD - Shibu Piriyath, Ron Bonica > > >> > https://datatracker.ietf.org/meeting/101/materials/slides-101- > > ipsecme-packetization-layer-path-mtu- > > >> discovery-01 > > >> > > >> > Problem: IPsec Tunnel has an PMTU as any other tunnel. > > >> > Solution in Transport Area: Inband Path discovery > > >> > > >> I spoke to Ron afterwards, and I'm very enthusiatic about getting > > PLPMTUD > > >> widely deployed. We didn't get to this slides, so we didn't figure > > >> out what he needs. Slides talk about an IP-level probe that IPsec > > >> encapsulators can use to get estimate for tunnel inner MTU. > > > > > Why IKE messages cannot be used for this purpose? > > > > I think that possibly it can, and this is the kind of discussion that > > I think we should have. The advantage of doing that is that it requires > > no new code on the responder! That's a big win for deploying. > > It means that this can be done unilaterally, no new specification, just > > implementation advice. > > > > The slight implementation challenge is making sure that the IKE traffic is going > > along the same path as the ESP traffic. I'd like to hear from Ron about > > whether this is an issue. > > > > I also thought about using having some plpmtud on each end make a TCP > > connection *within* the tunnel and use the already defined plpmtu for TCP. > > That might be really easy for systems without user/kernel divisions (some > > router kernels). It would require some notifications to indicate that the > > responder has a TCP port open. And of course, the traffic would have to fit > > into the tunnel as well. > > > > > > > > > > > Regards, > > > Valery. > > > > >> But, if we can get PLMTUD deployed for all traffic, then the end-nodes > > can > > >> do appropriate PMTU probing and can figure out what the inner MTU is. > > >> i.e. just get everyone to enable plpmtu (4821). It's a knob on most > > >> systems, which has been left in the off state because of lack of > > evidence > > >> that it isn't harmful. > > >> > > >> There seems to be some sticking points among the high-speed about > > CDNs: > > >> they hate all PMTUD as it screws with tx scheduling into hardware. > > >> (TCP segment offload issues) > > >> > > >> So they just use 1280 is what I was told. That's good for the network, > > but > > >> it removes them as strong allies for getting PLPMTUD enabled by > > default > > >> everywhere. It would be nice if we could get a BCP out of them. Such > > >> BCP could also bless PLPMTUD for everyone else. I was pushing for this > > >> with RFC8200/STD86 but there was insufficient evidence of > > deployment. > > >> > > >> -- > > >> Michael Richardson , Sandelman Software > > Works > > >> -= IPv6 IoT consulting =- > > >> > > >> > > > > > > > > -- > > Michael Richardson , Sandelman Software Works > > -= IPv6 IoT consulting =- > > > > From nobody Fri Apr 6 13:09:06 2018 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 028C8127342; Fri, 6 Apr 2018 13:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fTtQ2frVrZX; Fri, 6 Apr 2018 13:09:01 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 85793124D68; Fri, 6 Apr 2018 13:08:57 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w36K8peZ022295 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 6 Apr 2018 23:08:51 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w36K8pBF010616; Fri, 6 Apr 2018 23:08:51 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23239.54227.814560.228778@fireball.acr.fi> Date: Fri, 6 Apr 2018 23:08:51 +0300 From: Tero Kivinen To: ipsec@ietf.org CC: draft-ietf-ipsecme-implicit-iv@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 33 min X-Total-Time: 33 min Archived-At: Subject: [IPsec] Comments about draft-ietf-ipsecme-implicit-iv-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 20:09:04 -0000 While doing my IANA review on the document I found some small nits about it. Here are my comments to the document: -- Typo in abstract: This avoids sending the nonce itself, and savec in the case of AES-GCM, AES-CCM, ^^^^^ I assume it should be "saves". -- In section 2 missing closing parenthesis and period: ... The same applies for ChaCha20-Poly1305 ([RFC7634]. Currently this nonce is sent in each ^ add missing ")". -- In section 4, I think SA is better word than SPI to describe the IPsec security association. SPI is just the number identifying the SA, SA is the actual security association which includes sequence number, key, direction, algorithms etc. So change: As the IV MUST NOT repeat for one SPI when Counter-Mode ciphers are used, Implicit IV as described in this document MUST NOT be used in setups with the chance that the Sequence Number overlaps for one SPI. Multicast as described in [RFC5374], [RFC6407] and [I-D.yeung-g-ikev2] is a prominent example, where many senders share one secret and thus one SPI. with As the IV MUST NOT repeat for one SA when Counter-Mode ciphers are used, Implicit IV as described in this document MUST NOT be used in setups with the chance that the Sequence Number overlaps for one SA. Multicast as described in [RFC5374], [RFC6407] and [I-D.yeung-g-ikev2] is a prominent example, where many senders share one secret and thus one SA. -- This text is bit misleading A similar mechanism could be used by associating the most significant byte of the Sequence Number to a sender, while the 3 remaining bytes will be used to carry the counter value. Such mechanism prevents the use of Extended Sequence Number and limits the number of packet to be sent to 2** 24 = 16777216, that is 16 M. To solve the issue you could of course move the sender byte as the least significant byte in the sequence number, i.e., in that case the system could use extended sequence numbers, and the limit of the packet would not be that bad. Of course this still has the issue that normal replay window processing does not work with cases where sequence numbers are not used in numeric order (this same issue is in the normal RFC6407 cases). On the other hand, I think it might be better to just forbid the implicit IV on multicast cases, and we do not need to explain all the issues there. -- Section 5 and 6 need more text. I.e., you do not actually describe how the Implicit IV is negotiated in the IKE. You just tell that yes, it is negotiated, and there is no issues. So I suggest rewriting them as follows: ---------------------------------------------------------------------- 5. Initiator Behavior An initiator supporting this feature SHOULD propose implicit IV algorithms in the Transform Type 1 (Encryption Algorithm) Substructure of the Proposal Substructure inside the SA Payload. To facilitate backward compatibility with non-supporting peers the initiator SHOULD also include those same algorithms without Implicit IV (IIV) as separate transforms. 6. Responder Behavior The rules of SA Payload processing require that responder picks its algorithms from the proposal sent by the initiator, thus this will ensure that the responder will never send an SA payload containing the IIV transform to an initiator that did not propose it. -- In section 8 I do not understand what the first sentence is trying to say. I think it should be better to rewrite the 1st paragraph in IANA fConsiderations section as follows: This section assigns new code points to the recommended AEAD suites provided in [RFC8221], thus the new Transform Type 1 - Encryption Algorithm Transform IDs [IANA] are as defined below: -- kivinen@iki.fi From nobody Sun Apr 8 11:36:41 2018 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 B62DA12D77E for ; Sun, 8 Apr 2018 11:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5MG3zn-Q9Ls for ; Sun, 8 Apr 2018 11:36:36 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::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 B9B6312422F for ; Sun, 8 Apr 2018 11:36:36 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id y23so2104710ywy.4 for ; Sun, 08 Apr 2018 11:36:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8LWMuaHKgtaRnNAsxIvagX0OACobPUOF657JueWlg48=; b=KyZXOcshJJ9UvWfvrLBFVcKlwHPeGv1SlhWr4XC235Jnl1PcQoASVKM5uZhetBY+zG +PMKim8YBc7YNh9ar4suWebQYGpZ/SFuHv428w7FKNw7m5h45b71DketukeIwXGLkAIX L37lxpxo4jMLYNtSFXIQ7ORrA5xnlNfhWt/t0AfU+lCOAJeIfALD0Mm159YuEefUrjMG owRe1t0vK4lgKWc8xvttRePYQMJsDxG4CEN3V/YpljOVh3SnV1iTbXGRV2S/2HH/Tv+B fENpCRcQYYysKqDsiDal5JJVbw6uV0wT8h2NPZH5aVsjx1ZFJtyX8uOQS0uYC7Hx3GAn TnIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8LWMuaHKgtaRnNAsxIvagX0OACobPUOF657JueWlg48=; b=rWuO0EX5NhCY4XvTeKOv81X2p8gVbqqK1ufVit38NBQ0EORJnf5JNLZVbjRbJuHAa6 t7Rh3tBNdF33cvsDxbSsRBVVF0lljdnxhvS5lQOlseNNBu3PbWVM05WKiM9VOGynYdQo zgXwtvyrWx4ESVpwQaiar/1sd8oPTqJzSf2/B76GyA/sQlDrvPvVllzL6TZENI74Z9sY XGvpskc0Rbi9MinnsCs5wT3SMHu05reyNfMB3ioUgm1gXbmO2sNfy/wwrH3ILU//ntt6 1eba79J8D6CyNMtol2IGwShmMDDiggKjv2LJtnRZLrGp7umgeIplvtvEXEwJQusR24Te b9ow== X-Gm-Message-State: ALQs6tAhY7eJRK1FeZ4GW2giat5ZUlQXRreZ8v12IyCcOIjUsmSua9C8 pSAsh3HIvKjK4tudVibrE0yxxVk84XhgoiYkYhc= X-Google-Smtp-Source: AIpwx4/ux8/njrsSDUpa4kNGaOsankwMeSmV1PwjsAmsuOMt6+/YgjycVWoB0ovBuo7n36Y9KIyKppap7Ye+6ka7j/s= X-Received: by 10.13.240.197 with SMTP id z188mr10185250ywe.79.1523212595830; Sun, 08 Apr 2018 11:36:35 -0700 (PDT) MIME-Version: 1.0 References: <23236.41077.38545.504873@fireball.acr.fi> <11263.1522877778@obiwan.sandelman.ca> <003b01d3ccd1$18818950$49849bf0$@gmail.com> In-Reply-To: <003b01d3ccd1$18818950$49849bf0$@gmail.com> From: Christopher Wood Date: Sun, 08 Apr 2018 18:36:25 +0000 Message-ID: To: smyslov.ietf@gmail.com Cc: mcr+ietf@sandelman.ca, IPsecME WG Content-Type: multipart/alternative; boundary="94eb2c036234b1237305695a917f" Archived-At: Subject: Re: [IPsec] initiator privacy vs responder stealth X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2018 18:36:39 -0000 --94eb2c036234b1237305695a917f Content-Type: text/plain; charset="UTF-8" On Thu, Apr 5, 2018 at 4:28 AM Valery Smyslov wrote: > Hi Michael, > > > > IKE_SA_INIT privacy concerns - David Schinazi > > > > https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-privacy-additions-to-the-ikev2- > > ike-sa-init-exchange-00 > > > > > Concerns around privacy of the peers (who the initiator is, and if > the > > > responder is running IKE) > > > > I think that we had some consensus that we should split the document > into two > > problem statements. Protecting the initiator identity against MITM > attackers > > can be solved a whole bunch of ways. A zero-knowledge proof would seem > to > > be a better way to start to me. > > > > The problem of making the IKE responders stealthed seems like a different > > problem entirely. > > +1. > +1 to treating these problems separately. Best, Chris --94eb2c036234b1237305695a917f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu= , Apr 5, 2018 at 4:28 AM Valery Smyslov <smyslov.ietf@gmail.com> wrote:
Hi Michael,

>=C2=A0 =C2=A0 =C2=A0> IKE_SA_INIT privacy concerns - David Schinazi<= br> >=C2=A0 =C2=A0 =C2=A0> https://datatracker.ietf.org/meeting/101/mate= rials/slides-101-ipsecme-privacy-additions-to-the-ikev2-
> ike-sa-init-exchange-00
>
>=C2=A0 =C2=A0 =C2=A0> Concerns around privacy of the peers (who the = initiator is, and if the
>=C2=A0 =C2=A0 =C2=A0> responder is running IKE)
>
> I think that we had some consensus that we should split the document i= nto two
> problem statements.=C2=A0 Protecting the initiator identity against MI= TM attackers
> can be solved a whole bunch of ways.=C2=A0 A zero-knowledge proof woul= d seem to
> be a better way to start to me.
>
> The problem of making the IKE responders stealthed seems like a differ= ent
> problem entirely.

+1.

+1 to treating these problems separ= ately.

Best,
Chris
--94eb2c036234b1237305695a917f-- From nobody Mon Apr 9 01:34:04 2018 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 BF2B8126C19 for ; Mon, 9 Apr 2018 01:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ZOYh19pnlRit for ; Mon, 9 Apr 2018 01:34:00 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E28491242F7 for ; Mon, 9 Apr 2018 01:34:00 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E69EDB80DB4; Mon, 9 Apr 2018 01:33:25 -0700 (PDT) To: tpauly@apple.com, samy.touati@ericsson.com, ramantha@cisco.com, kaduk@mit.edu, ekr@rtfm.com, david.waltermire@nist.gov, kivinen@iki.fi X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: valery@smyslov.net, ipsec@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180409083325.E69EDB80DB4@rfc-editor.org> Date: Mon, 9 Apr 2018 01:33:25 -0700 (PDT) Archived-At: Subject: [IPsec] [Technical Errata Reported] RFC8229 (5320) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 08:34:03 -0000 The following errata report has been submitted for RFC8229, "TCP Encapsulation of IKE and IPsec Packets". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5320 -------------------------------------- Type: Technical Reported by: Valery Smyslov Section: GLOBAL Original Text ------------- Corrected Text -------------- TCP provides reliable transport, so there is no need for applications to deal with retransmissions. Moreover, sending retransmissions by IKE in case of TCP on congested networks could further increase congestion and degrade performance. For this reason IKE initiators SHOULD NOT retransmit requests if they are sent over TCP. However, both IKE initiators and responders MUST correctly handle retransmitted messages received over TCP, but responders SHOULD NOT resend response messages in this case. If IKE initiators still choose to retransmit requests over TCP, then the retransmission policy SHOULD be less aggressive than it would have been in case of UDP. Notes ----- While Section 12.2 discusses some implications that TCP transport could have on ESP protocol, the IKE retransmission behavior, described in Section 2.1 of RFC7296, is not redefined by this RFC. This is an oversight and some recommendations for implementers should have been given. The suggested text should be placed in a new section, presumably between sections 8 and 9. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8229 (draft-ietf-ipsecme-tcp-encaps-10) -------------------------------------- Title : TCP Encapsulation of IKE and IPsec Packets Publication Date : August 2017 Author(s) : T. Pauly, S. Touati, R. Mantha Category : PROPOSED STANDARD Source : IP Security Maintenance and Extensions Area : Security Stream : IETF Verifying Party : IESG From nobody Mon Apr 9 10:22:50 2018 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 0BA041271FD for ; Mon, 9 Apr 2018 10:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGit43HrYhbS for ; Mon, 9 Apr 2018 10:22:46 -0700 (PDT) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 B861E12702E for ; Mon, 9 Apr 2018 10:22:46 -0700 (PDT) Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w39HGUoS003965; Mon, 9 Apr 2018 10:22:45 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=CGm5vsUw7v7nYaBr6nbEeSQqcc7fE8M1EJ3mMeXGPs4=; b=PAyy4cBEzrozklI7ZsEblRCVpZyX0Ja3GGtTYUEAloJW3wnuIkEPUZQjWWnhKK5ZCgrg /w25y3kA379vVpxHLTqk0It5WNK4NGuhamF9ZRaxo3TMataYXUvUzRpTEJnckAP3g3/G VZV1l5S/PWW3vXvaXJ1rl9LlWQoOkqzxvvk8keLxPPZ5sPQ7mupAh/5lU3mNNIjT1Zom wXkjmQuAX8aLnUw2FuUZfqPF9dZ5kMrBVCY7dZ9sGMKMoJ62d4EoAGS8dl+mU+U15mDb 35q7gcRXwO5pAytRV9Brb9MG14vcfbfTaErsA/jCWmmTAFqoUnpOZDsfhJv0uNqeFhQ6 tg== Received: from nam03-dm3-obe.outbound.protection.outlook.com (mail-dm3nam03lp0019.outbound.protection.outlook.com [207.46.163.19]) by mx0a-00273201.pphosted.com with ESMTP id 2h84t4s2q3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 09 Apr 2018 10:22:45 -0700 Received: from SN6PR05MB4240.namprd05.prod.outlook.com (52.135.67.146) by SN6PR05MB4206.namprd05.prod.outlook.com (52.135.67.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.675.4; Mon, 9 Apr 2018 17:22:43 +0000 Received: from SN6PR05MB4240.namprd05.prod.outlook.com ([fe80::59a2:13ab:6110:35af]) by SN6PR05MB4240.namprd05.prod.outlook.com ([fe80::59a2:13ab:6110:35af%13]) with mapi id 15.20.0675.008; Mon, 9 Apr 2018 17:22:43 +0000 From: Ron Bonica To: Valery Smyslov , 'Michael Richardson' CC: "ipsec@ietf.org" Thread-Topic: [IPsec] PLMTUD probes for IPsec Thread-Index: AQHTzFzZgVjUC3J1w0emDs0mik2FjKPyDPuAgAA6SYCAAE+HAIAAwOKAgAVdP4A= Date: Mon, 9 Apr 2018 17:22:43 +0000 Message-ID: References: <11057.1522877721@obiwan.sandelman.ca> <003c01d3ccd2$db7c20e0$927462a0$@gmail.com> <1172.1522940927@obiwan.sandelman.ca> <012601d3cd78$343cdd50$9cb697f0$@gmail.com> In-Reply-To: <012601d3cd78$343cdd50$9cb697f0$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR05MB4206; 7:rIj974sQomSHduH/r/MEtHigNKZtqhteCLVBvzlvpn+LYfO3/X5beC1yIrZYP93lkxOa9cWBv0CFyVpdEI8HhL3E3lWLyUgf5X4VhPdASV88iGx/Tn2a/sufbk+/BxA1S5LxjVxpS3YyqYe+uYPfoJBcI4NCHmBTk4Ljhfl8iqwIthfAuvZRFUhRg6yN0qvWIQV2D1Vkwu7LwlJitJhCn+zKeZCUWPS7r7QUC57yIXiHZGq0pDirkVp1Ti8wH/2P x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant X-MS-Office365-Filtering-Correlation-Id: 72f0b0b5-a521-4927-03e0-08d59e3e80ed x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:SN6PR05MB4206; x-ms-traffictypediagnostic: SN6PR05MB4206: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(138986009662008)(85827821059158)(10436049006162); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231221)(944501327)(52105095)(3002001)(10201501046)(6055026)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:SN6PR05MB4206; BCL:0; PCL:0; RULEID:; SRVR:SN6PR05MB4206; x-forefront-prvs: 0637FCE711 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39380400002)(366004)(39860400002)(346002)(376002)(13464003)(51444003)(189003)(199004)(110136005)(105586002)(74316002)(55016002)(5250100002)(7736002)(305945005)(14454004)(478600001)(6306002)(9686003)(93886005)(39060400002)(4326008)(6436002)(6246003)(966005)(5660300001)(99286004)(316002)(53936002)(66066001)(59450400001)(68736007)(53546011)(6506007)(76176011)(229853002)(7696005)(8676002)(81166006)(81156014)(2900100001)(3846002)(6116002)(446003)(186003)(575784001)(86362001)(2906002)(561944003)(26005)(106356001)(3660700001)(8936002)(3280700002)(25786009)(102836004)(33656002)(486006)(11346002)(97736004)(476003)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR05MB4206; H:SN6PR05MB4240.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: VopIRA2GH2PgXbbjRO7ihdXvpTEayczuQ+eULw6sBdCLHMdahmbeXV+MFPa8JKAsZuSNI17q055TmOa7JjxJGszU7zJT1GdR2R9+nPrCMifQlDMKYhl1a/laRJEU6eelk4xlr6ZO/KF86D5k+lpQKKTbTyEfBAJIErob4MSSabtpZMvSFhIZHkTXanL6A5yPUM3ybO2GvZEN6gUx4R9WXh0BXluElRdXRhnVmb42tIIUM+LIgdlAj8SPH4KYnTby2zyADmQ1Y23WtTTU69wnm0Hp+vTPfvK7WZSg4hu5fJxA2IM15hbtJlcmIN7aRd32iErz/YWnjrhWrLlse5d5ZJfKQHvShjABgZL1c4q9UjJa3ubktrehYTqpLLdZkwKfD4LlolGcqXrYKMoSnr62+C99n4qqiJ/0Nu0zFMxqR9I= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 72f0b0b5-a521-4927-03e0-08d59e3e80ed X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2018 17:22:43.0502 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR05MB4206 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-09_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804090176 Archived-At: Subject: Re: [IPsec] PLMTUD probes for IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 17:22:49 -0000 Valery, Both good points. So, it appears that we have the following choices: - leverage IKE for exchanging probes and acks (But risk sending probes and= acks over a different path than encrypted data) - send probes and acks in-band. Try UDP probes first. If that doesn't work,= try TCP probes. Which do you think is better? Ron > -----Original Message----- > From: Valery Smyslov > Sent: Friday, April 6, 2018 3:24 AM > To: Ron Bonica ; 'Michael Richardson' > > Cc: ipsec@ietf.org > Subject: RE: [IPsec] PLMTUD probes for IPsec >=20 > Hi Ron, >=20 > > Folks, > > > > In the first version of this draft, we leveraged IKE to exchange > > messages. And provided with a good enough reason, we might go back to > that position! > > > > We moved away from IKE for the following reasons: > > > > - The path between the encrypting and decrypting nodes might include > > ECMP. If so, IKE messages might take a different path than actual > > encrypted data >=20 > That's a valid concern. The only time when you can be sure that the paths= are > the same is when NAT traversal is in use (either because some NAT is in > between, or you force it on the peers). >=20 > > - The current method provides the same level of protection as IKE and > > possibly better performance > > - The current doesn't require changes to IKE >=20 > True. But with your current proposal some changes to the IPSec in kernel = are > needed too (or you need to have standalone client and server applications= to > exchange probes). > Not sure what is easier. >=20 > > Are these reasonable assumptions. If not, we would be happy to return t= o > the IKE solution. >=20 > I think one problem with the suggested approach is that the tunnel select= ors > might not allow sending packets over UDP. Consider you have "narrow" ESP > SA that only allows TCP packets to go through and drops all UDP. In this = case > your approach won't work, or some additional heuristics would be needed. >=20 > Regards, > Valery. >=20 > > Ron > > > > > > > -----Original Message----- > > > From: Michael Richardson > > > Sent: Thursday, April 5, 2018 11:09 AM > > > To: Valery Smyslov > > > Cc: ipsec@ietf.org; Ron Bonica > > > Subject: Re: [IPsec] PLMTUD probes for IPsec > > > > > > > > > Valery Smyslov wrote: > > > >> > Dynamic IPsec PMTU PLPMTUD - Shibu Piriyath, Ron Bonica > > > >> > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ie= t > > > f.org_meeting_101_materials_slides-2D101- > 2D&d=3DDwICAg&c=3DHAkYuh63rsuhr > > > 6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3DFch9FQ82sir-BoLx84hKuKwl- > AWF2EfpHcA > > > > wrDThKP8&m=3DQoSMQregi2cS6qaSUZ1ttnd_izUvFwYYoIA80K3xgI8&s=3DYXPwE > w5OTeG > > > sOP8sS0P463jWQ-OhKpYEK9LUnAWcQgA&e=3D > > > ipsecme-packetization-layer-path-mtu- > > > >> discovery-01 > > > >> > > > >> > Problem: IPsec Tunnel has an PMTU as any other tunnel. > > > >> > Solution in Transport Area: Inband Path discovery > > > >> > > > >> I spoke to Ron afterwards, and I'm very enthusiatic about > > > getting PLPMTUD > > > >> widely deployed. We didn't get to this slides, so we didn't f= igure > > > >> out what he needs. Slides talk about an IP-level probe that IP= sec > > > >> encapsulators can use to get estimate for tunnel inner MTU. > > > > > > > Why IKE messages cannot be used for this purpose? > > > > > > I think that possibly it can, and this is the kind of discussion that > > > I think we should have. The advantage of doing that is that it requ= ires > > > no new code on the responder! That's a big win for deploying. > > > It means that this can be done unilaterally, no new specification, > > > just implementation advice. > > > > > > The slight implementation challenge is making sure that the IKE > > > traffic is going along the same path as the ESP traffic. I'd like > > > to hear from Ron about whether this is an issue. > > > > > > I also thought about using having some plpmtud on each end make a > > > TCP connection *within* the tunnel and use the already defined plpmtu > for TCP. > > > That might be really easy for systems without user/kernel divisions > > > (some router kernels). It would require some notifications to > > > indicate that the responder has a TCP port open. And of course, the > > > traffic would have to fit into the tunnel as well. > > > > > > > > > > > > > > > > Regards, > > > > Valery. > > > > > > >> But, if we can get PLMTUD deployed for all traffic, then the > > > end-nodes can > > > >> do appropriate PMTU probing and can figure out what the inner > MTU is. > > > >> i.e. just get everyone to enable plpmtu (4821). It's a knob on= most > > > >> systems, which has been left in the off state because of lack > > > of evidence > > > >> that it isn't harmful. > > > >> > > > >> There seems to be some sticking points among the high-speed > > > about > > > CDNs: > > > >> they hate all PMTUD as it screws with tx scheduling into hardw= are. > > > >> (TCP segment offload issues) > > > >> > > > >> So they just use 1280 is what I was told. That's good for > > > the network, but > > > >> it removes them as strong allies for getting PLPMTUD enabled > > > by default > > > >> everywhere. It would be nice if we could get a BCP out of th= em. > Such > > > >> BCP could also bless PLPMTUD for everyone else. I was pushing= for > this > > > >> with RFC8200/STD86 but there was insufficient evidence of > > > deployment. > > > >> > > > >> -- > > > >> Michael Richardson , Sandelman > > > Software Works > > > >> -=3D IPv6 IoT consulting =3D- > > > >> > > > >> > > > > > > > > > > > > -- > > > Michael Richardson , Sandelman Software > Works > > > -=3D IPv6 IoT consulting =3D- > > > > > > From nobody Mon Apr 9 23:57:44 2018 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 8F209124F57 for ; Mon, 9 Apr 2018 23:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nyjglr7pEIsH for ; Mon, 9 Apr 2018 23:57:40 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::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 9F733120454 for ; Mon, 9 Apr 2018 23:57:39 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id g203-v6so10055922lfg.11 for ; Mon, 09 Apr 2018 23:57:39 -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=9rHLVDNyNZRlPblcTo+2QjZVygc7hgFOKDzHsSb9kH0=; b=EsjI5FfxkVTzAA/8n+aUCIdEMjGGOHTwv8NY5+7cBU/R8KamBHxog5EaUneImXb2JB kVouvIrRloPdLT0x8zkSoNAfpz4jTwP3mraU5KqFMHAaziIsybH1VawwIjvnvOC7e54g gm8kxvGVIimVi+2s/K+t9E0aifSlXwv2FNlpOzUk4Xv2RVXwd84sZrwk+pcYafYjlfnz amioQPi+oy1jxVBHcvAPAJzhKvJyjQMhXQaq2p3k/tAuzktYvWwKOtw/W+ldw29fRdUA IerEvVZ4hy4oUmjdxpfskAMt+YE2jNhyoWd+xKxOXEA1H6pqaKZ/3QCpNDzByqxE/B72 HS4g== 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=9rHLVDNyNZRlPblcTo+2QjZVygc7hgFOKDzHsSb9kH0=; b=KNq7mr22G/5e99j2m5uVHEiMOMuC1HhDdfxfgwZrQUWZ7ZPts/7OzkwWra+eA2hSOE S6GfOjr+GvKh8Npi8Uo0e6S3tIZDuZy8h6GsSo1pMCUXud48/fr1zdsYh8KcD/b48uYP uoL9TKz0GQppiyX0KqRH0HYwT8aiTNu4XglVPmOmcuzU7qkfvxQk5frfpdsk/6ZjKyUK w0SMxDShBhOYMWlH3wd4CIDBy3ghQ2Jj7Vh+g7PVeJtJyldAZXnvqzOY1lkhqyzSaDad bkHAPKtV/kkQdVBAcynaEYzrlJBNfL6DzvLV9+vGdqTKpZIIhubfb235VgCW4rPFenwo E5dw== X-Gm-Message-State: ALQs6tD660Khkf15CNG7BEmfd1/MTGN/U7CCbs/8iXnwTwEQnA6PT1DK so6AqAx3kHnGsChKnbMJX68Ofg== X-Google-Smtp-Source: AIpwx48yd8CEhyeKCuS6PVM/DP+DXnKMbXiV1wif1eFPjIREXcQxB69YI18bgRYj69utHfoDsW+EVg== X-Received: by 2002:a19:2041:: with SMTP id g62-v6mr1055122lfg.133.1523343457577; Mon, 09 Apr 2018 23:57:37 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id e8-v6sm423711lfc.88.2018.04.09.23.57.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 09 Apr 2018 23:57:36 -0700 (PDT) From: "Valery Smyslov" To: "'Ron Bonica'" , "'Michael Richardson'" Cc: References: <11057.1522877721@obiwan.sandelman.ca> <003c01d3ccd2$db7c20e0$927462a0$@gmail.com> <1172.1522940927@obiwan.sandelman.ca> <012601d3cd78$343cdd50$9cb697f0$@gmail.com> In-Reply-To: Date: Tue, 10 Apr 2018 09:57:13 +0300 Message-ID: <02e401d3d099$281d2a10$78577e30$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHmG7ZZeeXklvSuJytvO9qNpqEvtwJ2ehx1AfUWGT4B/u7FiQH/bqMMAtA1VOqjex/HQA== Content-Language: ru Archived-At: Subject: Re: [IPsec] PLMTUD probes for IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 06:57:43 -0000 Hi Ron, > Both good points. So, it appears that we have the following choices: > > - leverage IKE for exchanging probes and acks (But risk sending probes and acks over a different path than > encrypted data) > - send probes and acks in-band. Try UDP probes first. If that doesn't work, try TCP probes. What about ICMP-only SAs (yeah, it's weird, but possible)? > Which do you think is better? Both don't look ideal. I slightly prefer the former, as it looks simpler to implement (at least for me), but the issue with different paths can outweigh all. One potential solution to this issue would be to always use UDP encapsulation, but I'm not sure we may impose such a requirement... Your opinion? Regards, Valery. > Ron > > > > -----Original Message----- > > From: Valery Smyslov > > Sent: Friday, April 6, 2018 3:24 AM > > To: Ron Bonica ; 'Michael Richardson' > > > > Cc: ipsec@ietf.org > > Subject: RE: [IPsec] PLMTUD probes for IPsec > > > > Hi Ron, > > > > > Folks, > > > > > > In the first version of this draft, we leveraged IKE to exchange > > > messages. And provided with a good enough reason, we might go back to > > that position! > > > > > > We moved away from IKE for the following reasons: > > > > > > - The path between the encrypting and decrypting nodes might include > > > ECMP. If so, IKE messages might take a different path than actual > > > encrypted data > > > > That's a valid concern. The only time when you can be sure that the paths are > > the same is when NAT traversal is in use (either because some NAT is in > > between, or you force it on the peers). > > > > > - The current method provides the same level of protection as IKE and > > > possibly better performance > > > - The current doesn't require changes to IKE > > > > True. But with your current proposal some changes to the IPSec in kernel are > > needed too (or you need to have standalone client and server applications to > > exchange probes). > > Not sure what is easier. > > > > > Are these reasonable assumptions. If not, we would be happy to return to > > the IKE solution. > > > > I think one problem with the suggested approach is that the tunnel selectors > > might not allow sending packets over UDP. Consider you have "narrow" ESP > > SA that only allows TCP packets to go through and drops all UDP. In this case > > your approach won't work, or some additional heuristics would be needed. > > > > Regards, > > Valery. > > > > > Ron > > > > > > > > > > -----Original Message----- > > > > From: Michael Richardson > > > > Sent: Thursday, April 5, 2018 11:09 AM > > > > To: Valery Smyslov > > > > Cc: ipsec@ietf.org; Ron Bonica > > > > Subject: Re: [IPsec] PLMTUD probes for IPsec > > > > > > > > > > > > Valery Smyslov wrote: > > > > >> > Dynamic IPsec PMTU PLPMTUD - Shibu Piriyath, Ron Bonica > > > > >> > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.iet > > > > f.org_meeting_101_materials_slides-2D101- > > 2D&d=DwICAg&c=HAkYuh63rsuhr > > > > 6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl- > > AWF2EfpHcA > > > > > > wrDThKP8&m=QoSMQregi2cS6qaSUZ1ttnd_izUvFwYYoIA80K3xgI8&s=YXPwE > > w5OTeG > > > > sOP8sS0P463jWQ-OhKpYEK9LUnAWcQgA&e= > > > > ipsecme-packetization-layer-path-mtu- > > > > >> discovery-01 > > > > >> > > > > >> > Problem: IPsec Tunnel has an PMTU as any other tunnel. > > > > >> > Solution in Transport Area: Inband Path discovery > > > > >> > > > > >> I spoke to Ron afterwards, and I'm very enthusiatic about > > > > getting PLPMTUD > > > > >> widely deployed. We didn't get to this slides, so we didn't figure > > > > >> out what he needs. Slides talk about an IP-level probe that IPsec > > > > >> encapsulators can use to get estimate for tunnel inner MTU. > > > > > > > > > Why IKE messages cannot be used for this purpose? > > > > > > > > I think that possibly it can, and this is the kind of discussion that > > > > I think we should have. The advantage of doing that is that it requires > > > > no new code on the responder! That's a big win for deploying. > > > > It means that this can be done unilaterally, no new specification, > > > > just implementation advice. > > > > > > > > The slight implementation challenge is making sure that the IKE > > > > traffic is going along the same path as the ESP traffic. I'd like > > > > to hear from Ron about whether this is an issue. > > > > > > > > I also thought about using having some plpmtud on each end make a > > > > TCP connection *within* the tunnel and use the already defined plpmtu > > for TCP. > > > > That might be really easy for systems without user/kernel divisions > > > > (some router kernels). It would require some notifications to > > > > indicate that the responder has a TCP port open. And of course, the > > > > traffic would have to fit into the tunnel as well. > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > Valery. > > > > > > > > >> But, if we can get PLMTUD deployed for all traffic, then the > > > > end-nodes can > > > > >> do appropriate PMTU probing and can figure out what the inner > > MTU is. > > > > >> i.e. just get everyone to enable plpmtu (4821). It's a knob on most > > > > >> systems, which has been left in the off state because of lack > > > > of evidence > > > > >> that it isn't harmful. > > > > >> > > > > >> There seems to be some sticking points among the high-speed > > > > about > > > > CDNs: > > > > >> they hate all PMTUD as it screws with tx scheduling into hardware. > > > > >> (TCP segment offload issues) > > > > >> > > > > >> So they just use 1280 is what I was told. That's good for > > > > the network, but > > > > >> it removes them as strong allies for getting PLPMTUD enabled > > > > by default > > > > >> everywhere. It would be nice if we could get a BCP out of them. > > Such > > > > >> BCP could also bless PLPMTUD for everyone else. I was pushing for > > this > > > > >> with RFC8200/STD86 but there was insufficient evidence of > > > > deployment. > > > > >> > > > > >> -- > > > > >> Michael Richardson , Sandelman > > > > Software Works > > > > >> -= IPv6 IoT consulting =- > > > > >> > > > > >> > > > > > > > > > > > > > > > > -- > > > > Michael Richardson , Sandelman Software > > Works > > > > -= IPv6 IoT consulting =- > > > > > > > > From nobody Tue Apr 10 03:52:11 2018 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 DBD67126579 for ; Tue, 10 Apr 2018 03:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 NNH6KDf4XjJ4 for ; Tue, 10 Apr 2018 03:52:07 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 7AC53120724 for ; Tue, 10 Apr 2018 03:52:07 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w3AAq3XP024793 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 10 Apr 2018 13:52:03 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w3AApwsq027517; Tue, 10 Apr 2018 13:51:58 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23244.38734.270422.683057@fireball.acr.fi> Date: Tue, 10 Apr 2018 13:51:58 +0300 From: Tero Kivinen To: "Valery Smyslov" Cc: "'Ron Bonica'" , "'Michael Richardson'" , ipsec@ietf.org In-Reply-To: <02e401d3d099$281d2a10$78577e30$@gmail.com> References: <11057.1522877721@obiwan.sandelman.ca> <003c01d3ccd2$db7c20e0$927462a0$@gmail.com> <1172.1522940927@obiwan.sandelman.ca> <012601d3cd78$343cdd50$9cb697f0$@gmail.com> <02e401d3d099$281d2a10$78577e30$@gmail.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 8 min X-Total-Time: 8 min Archived-At: Subject: Re: [IPsec] PLMTUD probes for IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 10:52:10 -0000 Valery Smyslov writes: > > Both good points. So, it appears that we have the following choices: > > > > - leverage IKE for exchanging probes and acks (But risk sending probes and acks over a different path than > > encrypted data) > > - send probes and acks in-band. Try UDP probes first. If that doesn't work, try TCP probes. > > What about ICMP-only SAs (yeah, it's weird, but possible)? > > > Which do you think is better? > > Both don't look ideal. I slightly prefer the former, as it looks > simpler to implement (at least for me), but the issue with different > paths can outweigh all. One potential solution to this issue would > be to always use UDP encapsulation, but I'm not sure we may impose > such a requirement... Your opinion? I would just use IKE packets, and ignore the cases where ESP and IKE get different routes which have different MTUs. I would expect that in most cases if there is something in the middle using different MTUs then the routes are not equal cost anymore, thus routing will use only one of the routes. Usually the issues with MTU comes with road warriors connecting from random locations around the world, and in most of the cases there will be NAT for IPv4 in the middle, which will move all traffic to UDP anyways. Do we have any real world examples where the ESP and IKE packets consistently take different routes, and those different routes have different MTUs? And does all ESP traffic follow always one route, and all IKE traffic follow another route, or is it more random or based on the SPI or something? I do not know enough to really say whether such cases exists or do not exists, but before we start to make complicated protocols to cope with cases which are very rare, I want to get more information. If those cases are very rare, I might still want to make sure IPsec works somehow, even if it is not as efficient as it could be (i.e., there might be extra fragmentation happening or finding proper MTU might take more time). -- kivinen@iki.fi From nobody Wed Apr 11 07:56:52 2018 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 F1110120725 for ; Wed, 11 Apr 2018 07:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUbRJyqm6vXn for ; Wed, 11 Apr 2018 07:56:46 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 79A1F1200F1 for ; Wed, 11 Apr 2018 07:56:46 -0700 (PDT) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3BEthe5016908; Wed, 11 Apr 2018 07:56:44 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=6jkTJDGnbj858xuF4zekKjQFDq7ihung9gauW5+jYoQ=; b=MxY9bvKv44nWlm9kHRf2STOQE0vqWoZuN+yhSYd/okGTFTrZ/oq2XlMNTEQO6HzOhGHy IlugRMa3SOYzIYiJI2S04TUn34MbL0d1p3IifCGzsSP0BTySSk3cLhwHXHQZ4qdbwSkS uJFizPeJJflmIVL8U4tU7CvchtbLnxYBX9SHIt88bw41Zy4Aa2MW0/0AmDb5Fbrdjp2X SziFV1SLSpWmBOacDL6pjlBljs2J2wKt3zJkCHlIwckkzgkX21yc4/opDyOF7jSFm9th aMdMH9+ULC7Cz6PE94fYaSXQlR26ZZ0PeOoX+5b6tdA/xxlbqt1XqijUCTiVGITdBx4R Hg== Received: from nam03-dm3-obe.outbound.protection.outlook.com (mail-dm3nam03lp0023.outbound.protection.outlook.com [207.46.163.23]) by mx0a-00273201.pphosted.com with ESMTP id 2h9jx386tp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 11 Apr 2018 07:56:44 -0700 Received: from SN6PR05MB4240.namprd05.prod.outlook.com (52.135.67.146) by SN6PR05MB3951.namprd05.prod.outlook.com (52.132.125.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.675.3; Wed, 11 Apr 2018 14:56:42 +0000 Received: from SN6PR05MB4240.namprd05.prod.outlook.com ([fe80::59a2:13ab:6110:35af]) by SN6PR05MB4240.namprd05.prod.outlook.com ([fe80::59a2:13ab:6110:35af%13]) with mapi id 15.20.0675.009; Wed, 11 Apr 2018 14:56:42 +0000 From: Ron Bonica To: Valery Smyslov , 'Michael Richardson' CC: "ipsec@ietf.org" Thread-Topic: [IPsec] PLMTUD probes for IPsec Thread-Index: AQHTzFzZgVjUC3J1w0emDs0mik2FjKPyDPuAgAA6SYCAAE+HAIAAwOKAgAVdP4CAAOSogIACCAQA Date: Wed, 11 Apr 2018 14:56:42 +0000 Message-ID: References: <11057.1522877721@obiwan.sandelman.ca> <003c01d3ccd2$db7c20e0$927462a0$@gmail.com> <1172.1522940927@obiwan.sandelman.ca> <012601d3cd78$343cdd50$9cb697f0$@gmail.com> <02e401d3d099$281d2a10$78577e30$@gmail.com> In-Reply-To: <02e401d3d099$281d2a10$78577e30$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR05MB3951; 7:CZaIuFxU+STKB2yBsicwWmKqgWSx3OBaSdHqOEXVmaPgMu7gzwbUgXLLob1fr0XGHj22gybB50HMVHya296LwMy4RFPTC+Fjr3yVH9q82XhWi7IHBShuBFknA62/4VQ8f9NWu3NlFPhn32+6wywp7vpYk008WG1iS3byDVUPqHyFzpiN4ZOi/99hvTeJMugMYmm5YVfW2bLYLcXI6bntGjCQAxZzpN3rAYkXrxYppF6/ml6mhtBAf55+P0ekIris x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7153060)(7193020); SRVR:SN6PR05MB3951; x-ms-traffictypediagnostic: SN6PR05MB3951: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(138986009662008)(85827821059158)(15185016700835)(10436049006162); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231221)(944501327)(52105095)(6055026)(6041310)(20161123560045)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011); SRVR:SN6PR05MB3951; BCL:0; PCL:0; RULEID:; SRVR:SN6PR05MB3951; x-forefront-prvs: 0639027A9E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(376002)(366004)(39380400002)(346002)(199004)(51444003)(13464003)(189003)(110136005)(97736004)(486006)(476003)(5250100002)(26005)(106356001)(446003)(11346002)(6506007)(6246003)(53546011)(59450400001)(2900100001)(76176011)(39060400002)(53936002)(105586002)(86362001)(575784001)(66066001)(55016002)(4326008)(8676002)(561944003)(2906002)(478600001)(305945005)(33656002)(6436002)(99286004)(14454004)(966005)(6306002)(9686003)(68736007)(229853002)(81156014)(74316002)(7696005)(186003)(5660300001)(102836004)(316002)(3846002)(8936002)(7736002)(25786009)(81166006)(6116002)(3660700001)(3280700002)(93886005)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR05MB3951; H:SN6PR05MB4240.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: z3/VDThM9uEEgqiPDha3rcdkKdEag8spnllN8Qdt1vpVFLpARPb6zqeBni1CXr1lLrtWpHN1VebJSSD3c4pws1X2FK1skHnF+MhFluJRcc+D4XHG0rLHbdchWGVlzu4Xq3aAn4GHSrwpap0qZU8lyus+BzdssDJHJVJ/Et24JRqBcO5Z8eieail/UtgKW1eKLo50Ha2WuxZj2ZL8uCiUWBCeovdRGrJiCJ/40KvBMasH1hlxnbiOmAMqA3flKqCsJmZiUKXJAsCzjJjR/xb48nMFZqrVChob2U88OP4AXl5J8E6OaKBgfJVaHEwFw0JkOIBkOn9M3ulRfgVWlrP3i6cff9aP3OuslAxQXih5u4W4lyIt9BzvT0jm31NL+Mw+EoUbDPFP46vcAro/7IkvO7h4e2Nw64Kkj6GWZpTThuY= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: e8f9288e-6648-4e60-af00-08d59fbc7031 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: e8f9288e-6648-4e60-af00-08d59fbc7031 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2018 14:56:42.7296 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR05MB3951 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-11_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804110140 Archived-At: Subject: Re: [IPsec] PLMTUD probes for IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 14:56:50 -0000 Hi Valery, I am thinking like this....... - If we do nothing, tunnel performance is acceptable but suboptimal. We ca= n prevent blackholing by statically configuring the tunnel MTU to a suffici= ently low value. However, we cannot take advantage of tunnels with larger P= MTUs. - If we use IKE to exchange probes and acks, tunnel performance may become = totally unacceptable. In the situation where a) IKE messages traverse a dif= ferent path than encrypted payloads and b) the PMTU associated with the IKE= path is greater than the PMTU associated with encrypted payload path, we m= ay produce an inflated estimate of the Tunnel MTU. This may lead to black h= oling. So, our probe and acks have to be exchanged over the IPSEC tunnel. At first= I thought that the best way to do this was by exchanging UDP messages. But= you have a point. If we exchanged encrypted ICMP Echo / Echo Response mess= ages instead of UDP messages, there would be slightly less code to write. F= urthermore, we wouldn't need to allocate a new UDP port. = Ron > -----Original Message----- > From: Valery Smyslov > Sent: Tuesday, April 10, 2018 2:57 AM > To: Ron Bonica ; 'Michael Richardson' > > Cc: ipsec@ietf.org > Subject: RE: [IPsec] PLMTUD probes for IPsec >=20 > Hi Ron, >=20 > > Both good points. So, it appears that we have the following choices: > > > > - leverage IKE for exchanging probes and acks (But risk sending > > probes and acks over a different path than encrypted data) > > - send probes and acks in-band. Try UDP probes first. If that doesn't w= ork, > try TCP probes. >=20 > What about ICMP-only SAs (yeah, it's weird, but possible)? >=20 > > Which do you think is better? >=20 > Both don't look ideal. I slightly prefer the former, as it looks simpler = to > implement (at least for me), but the issue with different paths can outw= eigh > all. One potential solution to this issue would be to always use UDP > encapsulation, but I'm not sure we may impose such a requirement... Your > opinion? >=20 > Regards, > Valery. >=20 > > > > Ron > > > > > > > -----Original Message----- > > > From: Valery Smyslov > > > Sent: Friday, April 6, 2018 3:24 AM > > > To: Ron Bonica ; 'Michael Richardson' > > > > > > Cc: ipsec@ietf.org > > > Subject: RE: [IPsec] PLMTUD probes for IPsec > > > > > > Hi Ron, > > > > > > > Folks, > > > > > > > > In the first version of this draft, we leveraged IKE to exchange > > > > messages. And provided with a good enough reason, we might go back > > > > to > > > that position! > > > > > > > > We moved away from IKE for the following reasons: > > > > > > > > - The path between the encrypting and decrypting nodes might > > > > include ECMP. If so, IKE messages might take a different path than > > > > actual encrypted data > > > > > > That's a valid concern. The only time when you can be sure that the > > > paths are the same is when NAT traversal is in use (either because > > > some NAT is in between, or you force it on the peers). > > > > > > > - The current method provides the same level of protection as IKE > > > > and possibly better performance > > > > - The current doesn't require changes to IKE > > > > > > True. But with your current proposal some changes to the IPSec in > > > kernel are needed too (or you need to have standalone client and > > > server applications to exchange probes). > > > Not sure what is easier. > > > > > > > Are these reasonable assumptions. If not, we would be happy to > > > > return to > > > the IKE solution. > > > > > > I think one problem with the suggested approach is that the tunnel > > > selectors might not allow sending packets over UDP. Consider you > > > have "narrow" ESP SA that only allows TCP packets to go through and > > > drops all UDP. In this case your approach won't work, or some additio= nal > heuristics would be needed. > > > > > > Regards, > > > Valery. > > > > > > > Ron > > > > > > > > > > > > > -----Original Message----- > > > > > From: Michael Richardson > > > > > Sent: Thursday, April 5, 2018 11:09 AM > > > > > To: Valery Smyslov > > > > > Cc: ipsec@ietf.org; Ron Bonica > > > > > Subject: Re: [IPsec] PLMTUD probes for IPsec > > > > > > > > > > > > > > > Valery Smyslov wrote: > > > > > >> > Dynamic IPsec PMTU PLPMTUD - Shibu Piriyath, Ron Bonica > > > > > >> > > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracke= r > > > > > .iet > > > > > f.org_meeting_101_materials_slides-2D101- > > > 2D&d=3DDwICAg&c=3DHAkYuh63rsuhr > > > > > 6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3DFch9FQ82sir-BoLx84hKuKwl- > > > AWF2EfpHcA > > > > > > > > > wrDThKP8&m=3DQoSMQregi2cS6qaSUZ1ttnd_izUvFwYYoIA80K3xgI8&s=3DYXPwE > > > w5OTeG > > > > > sOP8sS0P463jWQ-OhKpYEK9LUnAWcQgA&e=3D > > > > > ipsecme-packetization-layer-path-mtu- > > > > > >> discovery-01 > > > > > >> > > > > > >> > Problem: IPsec Tunnel has an PMTU as any other tunnel. > > > > > >> > Solution in Transport Area: Inband Path discovery > > > > > >> > > > > > >> I spoke to Ron afterwards, and I'm very enthusiatic about > > > > > getting PLPMTUD > > > > > >> widely deployed. We didn't get to this slides, so we didn= 't figure > > > > > >> out what he needs. Slides talk about an IP-level probe tha= t IPsec > > > > > >> encapsulators can use to get estimate for tunnel inner MTU= . > > > > > > > > > > > Why IKE messages cannot be used for this purpose? > > > > > > > > > > I think that possibly it can, and this is the kind of discussion = that > > > > > I think we should have. The advantage of doing that is that it = requires > > > > > no new code on the responder! That's a big win for deploying. > > > > > It means that this can be done unilaterally, no new > > > > > specification, just implementation advice. > > > > > > > > > > The slight implementation challenge is making sure that the IKE > > > > > traffic is going along the same path as the ESP traffic. I'd > > > > > like to hear from Ron about whether this is an issue. > > > > > > > > > > I also thought about using having some plpmtud on each end make > > > > > a TCP connection *within* the tunnel and use the already defined > > > > > plpmtu > > > for TCP. > > > > > That might be really easy for systems without user/kernel > > > > > divisions (some router kernels). It would require some > > > > > notifications to indicate that the responder has a TCP port > > > > > open. And of course, the traffic would have to fit into the tunn= el as > well. > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > Valery. > > > > > > > > > > >> But, if we can get PLMTUD deployed for all traffic, then > > > > > the end-nodes can > > > > > >> do appropriate PMTU probing and can figure out what the > > > > > inner > > > MTU is. > > > > > >> i.e. just get everyone to enable plpmtu (4821). It's a kno= b on > most > > > > > >> systems, which has been left in the off state because of > > > > > lack of evidence > > > > > >> that it isn't harmful. > > > > > >> > > > > > >> There seems to be some sticking points among the > > > > > high-speed about > > > > > CDNs: > > > > > >> they hate all PMTUD as it screws with tx scheduling into > hardware. > > > > > >> (TCP segment offload issues) > > > > > >> > > > > > >> So they just use 1280 is what I was told. That's good > > > > > for the network, but > > > > > >> it removes them as strong allies for getting PLPMTUD > > > > > enabled by default > > > > > >> everywhere. It would be nice if we could get a BCP out o= f them. > > > Such > > > > > >> BCP could also bless PLPMTUD for everyone else. I was > > > > > pushing for > > > this > > > > > >> with RFC8200/STD86 but there was insufficient evidence of > > > > > deployment. > > > > > >> > > > > > >> -- > > > > > >> Michael Richardson , Sandelman > > > > > Software Works > > > > > >> -=3D IPv6 IoT consulting =3D- > > > > > >> > > > > > >> > > > > > > > > > > > > > > > > > > > > -- > > > > > Michael Richardson , Sandelman Software > > > Works > > > > > -=3D IPv6 IoT consulting =3D- > > > > > > > > > > From nobody Wed Apr 11 08:36:46 2018 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 4486A124BFA for ; Wed, 11 Apr 2018 08:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DB7U5wCYIs02 for ; Wed, 11 Apr 2018 08:36:43 -0700 (PDT) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 837521200FC for ; Wed, 11 Apr 2018 08:36:43 -0700 (PDT) Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3BFZUsB016800; Wed, 11 Apr 2018 08:36:41 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=3vznZ74uFq6DPVhxV9yimWNi+L5krf9Ck7r4keb5pew=; b=nxExwTuutI9oAPU/Bm8du6HzMXaP1Ffhd+m2DyVDJtowY++kvHz8UvME/jewBgSXKxYc 5ROR6ilWjL4NQqbLpV9Inp2ueOQH5DYrYLUpcnK8imPwLvyDpto23rvXlCNoLySPQeI0 unkgrRNC9gL8gDthJydHKQPUvmMnZnmrAJhYu7PLJhCItT13UtZAtcUnPOP+BzzpxCp4 C0M4IhcW8LAhRai3a0OvYEGlSxXZPuoLNoWlUqw9Na0BMiAfQTfR7sTa3ov4SRpMhKPY PNtzKqbpxPqGjQhu03FgTlYUb4HAUjF33DXUfLGE6IysmBj+WTND5msy4/nz2aPnbdx8 fQ== Received: from nam03-co1-obe.outbound.protection.outlook.com (mail-co1nam03lp0022.outbound.protection.outlook.com [216.32.181.22]) by mx0a-00273201.pphosted.com with ESMTP id 2h9kkcr7d5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 11 Apr 2018 08:36:41 -0700 Received: from SN6PR05MB4240.namprd05.prod.outlook.com (52.135.67.146) by SN6PR05MB4494.namprd05.prod.outlook.com (52.135.74.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.675.7; Wed, 11 Apr 2018 15:36:39 +0000 Received: from SN6PR05MB4240.namprd05.prod.outlook.com ([fe80::59a2:13ab:6110:35af]) by SN6PR05MB4240.namprd05.prod.outlook.com ([fe80::59a2:13ab:6110:35af%13]) with mapi id 15.20.0675.009; Wed, 11 Apr 2018 15:36:39 +0000 From: Ron Bonica To: Tero Kivinen , Valery Smyslov CC: 'Michael Richardson' , "ipsec@ietf.org" Thread-Topic: [IPsec] PLMTUD probes for IPsec Thread-Index: AQHTzFzZgVjUC3J1w0emDs0mik2FjKPyDPuAgAA6SYCAAE+HAIAAwOKAgAVdP4CAAOSogIAAQZcAgAHdsZA= Date: Wed, 11 Apr 2018 15:36:39 +0000 Message-ID: References: <11057.1522877721@obiwan.sandelman.ca> <003c01d3ccd2$db7c20e0$927462a0$@gmail.com> <1172.1522940927@obiwan.sandelman.ca> <012601d3cd78$343cdd50$9cb697f0$@gmail.com> <02e401d3d099$281d2a10$78577e30$@gmail.com> <23244.38734.270422.683057@fireball.acr.fi> In-Reply-To: <23244.38734.270422.683057@fireball.acr.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR05MB4494; 7:8Vh4V97MUsgoTeRNFcaPtYWbxWsei/p4nxWbtH+cHtfjuwrNhl6yfOkbcBQ9RnrDHaxxJ+qMHXiIHcEV+RuVFXvgnfSAAlRaY40y7+FKk9yadBoVPbBn2Mb/eiuoyMXeIkGX/JR8rwieYKld9+q4/jy59+JCz7pzGEzAJXyj10NNTJQnh5Hk/GI3VtsaannnSWWHo5Cbxp90KbMuRFEGk55umB817/eW4srrGsTKyaVfwstPZ1rsLYhrKGkBOUNr x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(3008032)(2017052603328)(7153060)(7193020); SRVR:SN6PR05MB4494; x-ms-traffictypediagnostic: SN6PR05MB4494: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(85827821059158); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231221)(944501327)(52105095)(93006095)(93001095)(6055026)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(6072148)(201708071742011); SRVR:SN6PR05MB4494; BCL:0; PCL:0; RULEID:; SRVR:SN6PR05MB4494; x-forefront-prvs: 0639027A9E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(366004)(396003)(376002)(39380400002)(189003)(199004)(13464003)(74316002)(54906003)(316002)(6436002)(3280700002)(110136005)(2906002)(5250100002)(9686003)(229853002)(3660700001)(53936002)(59450400001)(86362001)(186003)(6506007)(486006)(476003)(11346002)(446003)(7736002)(102836004)(305945005)(26005)(478600001)(55016002)(53546011)(76176011)(2900100001)(97736004)(81156014)(81166006)(8936002)(5660300001)(106356001)(68736007)(93886005)(33656002)(14454004)(105586002)(4326008)(25786009)(99286004)(6246003)(8676002)(3846002)(66066001)(7696005)(6116002)(39060400002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR05MB4494; H:SN6PR05MB4240.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: +kJllzMyhAng6EqxngHOsALnch4591nxqHyRraMsVxME8kHBI6Pen8cE14wQ9/mhD60kHkb3T5pSz6M0nDAdEoF5Rq623CHQIACcBv9ZfwW7WA2kNE7UHsZbiV55Wl9zQ755h1vMjs1PNA0C5+zUxHiMe6WdkOrD7nJcrAOsftEfqLR2txTvHG1IC5M6uts2+4d5NWPbAQZGxPt0OqGMemHRO23pSH7ozvB9mAhiEJyeJo3x7x2T7gCivretQ8D/jqTXnSXpUzfFOLRb7kyPbPAHAqhX7QOhb4YpCkUfSuvNkE1nra4fyjUnhVenbvb1g/3g9p7B73nsC/8LYeBp2pCGJk/BdpUQ2Rv6g+ExFumCfbHIB/w+r4Bn7oPb2D8KovdmtN9HGicMrJ8e3vJqiNfMT/ppeFSqnuDRvgyD7mM= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 02ed5a08-6980-48ad-a261-08d59fc20499 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 02ed5a08-6980-48ad-a261-08d59fc20499 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2018 15:36:39.1817 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR05MB4494 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-11_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804110145 Archived-At: Subject: Re: [IPsec] PLMTUD probes for IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 15:36:45 -0000 Hi Tero, In 99.9% of cases you are probably correct. If there is an ECMP between the= encrypting node and the decrypting node, all ECMPs have the same PMTU. And because this is true in such a vast majority of cases, none of us have = seen a situation where one ECMP has a larger PMTU than then next. However, we still need to be prepared for that rare situation where one ECM= P does have a greater PMTU that the next. Although black swans are rare, th= ey bite very hard! = Ron > -----Original Message----- > From: Tero Kivinen > Sent: Tuesday, April 10, 2018 6:52 AM > To: Valery Smyslov > Cc: Ron Bonica ; 'Michael Richardson' > ; ipsec@ietf.org > Subject: Re: [IPsec] PLMTUD probes for IPsec >=20 > Valery Smyslov writes: > > > Both good points. So, it appears that we have the following choices: > > > > > > - leverage IKE for exchanging probes and acks (But risk sending > > > probes and acks over a different path than encrypted data) > > > - send probes and acks in-band. Try UDP probes first. If that doesn't > work, try TCP probes. > > > > What about ICMP-only SAs (yeah, it's weird, but possible)? > > > > > Which do you think is better? > > > > Both don't look ideal. I slightly prefer the former, as it looks > > simpler to implement (at least for me), but the issue with different > > paths can outweigh all. One potential solution to this issue would be > > to always use UDP encapsulation, but I'm not sure we may impose such a > > requirement... Your opinion? >=20 > I would just use IKE packets, and ignore the cases where ESP and IKE get > different routes which have different MTUs. I would expect that in most > cases if there is something in the middle using different MTUs then the > routes are not equal cost anymore, thus routing will use only one of the > routes. Usually the issues with MTU comes with road warriors connecting > from random locations around the world, and in most of the cases there wi= ll > be NAT for IPv4 in the middle, which will move all traffic to UDP anyways= . >=20 > Do we have any real world examples where the ESP and IKE packets > consistently take different routes, and those different routes have diffe= rent > MTUs? And does all ESP traffic follow always one route, and all IKE traff= ic > follow another route, or is it more random or based on the SPI or somethi= ng? >=20 > I do not know enough to really say whether such cases exists or do not > exists, but before we start to make complicated protocols to cope with ca= ses > which are very rare, I want to get more information. >=20 > If those cases are very rare, I might still want to make sure IPsec works > somehow, even if it is not as efficient as it could be (i.e., there might= be extra > fragmentation happening or finding proper MTU might take more time). > -- > kivinen@iki.fi From nobody Thu Apr 12 04:34:35 2018 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 369CB12025C for ; Thu, 12 Apr 2018 04:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHvrPsZExeir for ; Thu, 12 Apr 2018 04:34:30 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34A471200F1 for ; Thu, 12 Apr 2018 04:34:30 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id q9-v6so7188460lfk.9 for ; Thu, 12 Apr 2018 04:34:30 -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=am8uls86lb2NbaZe8rQqXzABoFJXVKgpyaUjSs7CNE8=; b=e6O9B5Am97ArZTQ3yoCvNyKh5b+6bIbNQTC0R3dC9zYQ+tMutednuCjlxkvRTmI7yL GDvqxC9yaFG5v3hOpA7jmlwLAJk9D5xClOEu/+H2mDlEB9qiOjdLv7WeRI9r2e8UOIKk 38TqnolZHBCkO5uzwboRgirrXDB1ROoN26zpWJgvP8xsprTvxvZyuOqR/bVto7k/fbNk vI6Xjzo2weP/7WJM6XY5b2N6b3PY0A9B4x9yprrwVQ1RSv6lUSl/PpAzZwXt3xWBAt1o e44cMFwJPUJSXB1ToP6BXOh4BChaqaZPmTC8cEvS0qIaM9HO+6ppZNiZHg7stnpiW5Pb xBSA== 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=am8uls86lb2NbaZe8rQqXzABoFJXVKgpyaUjSs7CNE8=; b=rM5zMA8RNOWUSSca05k+uHcOb2JUn/Sco8Qw1aIpiNQ/MjgGvPuVQMhIxGnBR07ifN yBr60zO6A2LDJ2ubnG+TZwhLY91PLTeFiGzIvw/SQdBqARbMUyvvYPgs/8gi5V2hpKM3 FfyEbmCtz7VfuO2fX4vIF4Yvwdv6kY9igAoPPRodQ2v+1Rw8gxU6faitXOKq4VUMOuLq SgA6K+AR4i3LAdaE8zBQ38fmiZjE7/WowRTclFvtdTH+bcQUea8xbRlEY/xZGn6mURbv 7cwDKwKD3rLVgAgg9SoID0T7tBdteV5uP6lG5XqTZyLEFCsSab3rUyeAjJsQd4sD31Pd 5iSA== X-Gm-Message-State: ALQs6tD5Uvhkuaan8gQvf+c05g4W/mTs9rIjwsODPs7AI2f1GsqbUF47 5bNYyOrk1QlVQ85AL06SiIkM3A== X-Google-Smtp-Source: AIpwx49qPHXUB3Scyutz1urv1JPwNovNOC7LavDLfOtIioASXFxZoXxw7cnhUR1qaNTNXhqvPqQYtA== X-Received: by 10.46.134.14 with SMTP id a14mr447443lji.23.1523532868159; Thu, 12 Apr 2018 04:34:28 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id w73-v6sm680121lfi.60.2018.04.12.04.34.26 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 12 Apr 2018 04:34:27 -0700 (PDT) From: "Valery Smyslov" To: "'Ron Bonica'" , "'Michael Richardson'" Cc: References: <11057.1522877721@obiwan.sandelman.ca> <003c01d3ccd2$db7c20e0$927462a0$@gmail.com> <1172.1522940927@obiwan.sandelman.ca> <012601d3cd78$343cdd50$9cb697f0$@gmail.com> <02e401d3d099$281d2a10$78577e30$@gmail.com> In-Reply-To: Date: Thu, 12 Apr 2018 14:34:05 +0300 Message-ID: <04ea01d3d252$2a398400$7eac8c00$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHmG7ZZeeXklvSuJytvO9qNpqEvtwJ2ehx1AfUWGT4B/u7FiQH/bqMMAtA1VOoCQqOWNwFcPFCRo2GigvA= Content-Language: ru Archived-At: Subject: Re: [IPsec] PLMTUD probes for IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 11:34:33 -0000 Hi Ron, > I am thinking like this....... > > - If we do nothing, tunnel performance is acceptable but suboptimal. We can prevent blackholing by statically > configuring the tunnel MTU to a sufficiently low value. However, we cannot take advantage of tunnels with > larger PMTUs. > > - If we use IKE to exchange probes and acks, tunnel performance may become totally unacceptable. In the > situation where a) IKE messages traverse a different path than encrypted payloads and b) the PMTU > associated with the IKE path is greater than the PMTU associated with encrypted payload path, we may > produce an inflated estimate of the Tunnel MTU. This may lead to black holing. Then it is possible to couple PLMTUD with NAT traversal. In other words - send probes over IKE, but only if NAT was detected in between (or NAT traversal is forced by local configuration). In case of NAT traversal all ESP packets will be encapsulated in UDP and sent over the IKE connection (same UDP ports). So in this case we are sure that IKE and ESP paths are the same. > So, our probe and acks have to be exchanged over the IPSEC tunnel. At first I thought that the best way to do > this was by exchanging UDP messages. But you have a point. If we exchanged encrypted ICMP Echo / Echo > Response messages instead of UDP messages, there would be slightly less code to write. Furthermore, we > wouldn't need to allocate a new UDP port. Yes. but if your tunnel allows only TCP (or UDP), then sending ICMP Echo won't work. You still need to be able to send probes over all major transport protocol, otherwise some SPD configurations would prevent this to work. Regards, Valery. > Ron > > > > -----Original Message----- > > From: Valery Smyslov > > Sent: Tuesday, April 10, 2018 2:57 AM > > To: Ron Bonica ; 'Michael Richardson' > > > > Cc: ipsec@ietf.org > > Subject: RE: [IPsec] PLMTUD probes for IPsec > > > > Hi Ron, > > > > > Both good points. So, it appears that we have the following choices: > > > > > > - leverage IKE for exchanging probes and acks (But risk sending > > > probes and acks over a different path than encrypted data) > > > - send probes and acks in-band. Try UDP probes first. If that doesn't work, > > try TCP probes. > > > > What about ICMP-only SAs (yeah, it's weird, but possible)? > > > > > Which do you think is better? > > > > Both don't look ideal. I slightly prefer the former, as it looks simpler to > > implement (at least for me), but the issue with different paths can outweigh > > all. One potential solution to this issue would be to always use UDP > > encapsulation, but I'm not sure we may impose such a requirement... Your > > opinion? > > > > Regards, > > Valery. > > > > > > > > Ron > > > > > > > > > > -----Original Message----- > > > > From: Valery Smyslov > > > > Sent: Friday, April 6, 2018 3:24 AM > > > > To: Ron Bonica ; 'Michael Richardson' > > > > > > > > Cc: ipsec@ietf.org > > > > Subject: RE: [IPsec] PLMTUD probes for IPsec > > > > > > > > Hi Ron, > > > > > > > > > Folks, > > > > > > > > > > In the first version of this draft, we leveraged IKE to exchange > > > > > messages. And provided with a good enough reason, we might go back > > > > > to > > > > that position! > > > > > > > > > > We moved away from IKE for the following reasons: > > > > > > > > > > - The path between the encrypting and decrypting nodes might > > > > > include ECMP. If so, IKE messages might take a different path than > > > > > actual encrypted data > > > > > > > > That's a valid concern. The only time when you can be sure that the > > > > paths are the same is when NAT traversal is in use (either because > > > > some NAT is in between, or you force it on the peers). > > > > > > > > > - The current method provides the same level of protection as IKE > > > > > and possibly better performance > > > > > - The current doesn't require changes to IKE > > > > > > > > True. But with your current proposal some changes to the IPSec in > > > > kernel are needed too (or you need to have standalone client and > > > > server applications to exchange probes). > > > > Not sure what is easier. > > > > > > > > > Are these reasonable assumptions. If not, we would be happy to > > > > > return to > > > > the IKE solution. > > > > > > > > I think one problem with the suggested approach is that the tunnel > > > > selectors might not allow sending packets over UDP. Consider you > > > > have "narrow" ESP SA that only allows TCP packets to go through and > > > > drops all UDP. In this case your approach won't work, or some additional > > heuristics would be needed. > > > > > > > > Regards, > > > > Valery. > > > > > > > > > Ron > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Michael Richardson > > > > > > Sent: Thursday, April 5, 2018 11:09 AM > > > > > > To: Valery Smyslov > > > > > > Cc: ipsec@ietf.org; Ron Bonica > > > > > > Subject: Re: [IPsec] PLMTUD probes for IPsec > > > > > > > > > > > > > > > > > > Valery Smyslov wrote: > > > > > > >> > Dynamic IPsec PMTU PLPMTUD - Shibu Piriyath, Ron Bonica > > > > > > >> > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker > > > > > > .iet > > > > > > f.org_meeting_101_materials_slides-2D101- > > > > 2D&d=DwICAg&c=HAkYuh63rsuhr > > > > > > 6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl- > > > > AWF2EfpHcA > > > > > > > > > > > > wrDThKP8&m=QoSMQregi2cS6qaSUZ1ttnd_izUvFwYYoIA80K3xgI8&s=YXPwE > > > > w5OTeG > > > > > > sOP8sS0P463jWQ-OhKpYEK9LUnAWcQgA&e= > > > > > > ipsecme-packetization-layer-path-mtu- > > > > > > >> discovery-01 > > > > > > >> > > > > > > >> > Problem: IPsec Tunnel has an PMTU as any other tunnel. > > > > > > >> > Solution in Transport Area: Inband Path discovery > > > > > > >> > > > > > > >> I spoke to Ron afterwards, and I'm very enthusiatic about > > > > > > getting PLPMTUD > > > > > > >> widely deployed. We didn't get to this slides, so we didn't figure > > > > > > >> out what he needs. Slides talk about an IP-level probe that IPsec > > > > > > >> encapsulators can use to get estimate for tunnel inner MTU. > > > > > > > > > > > > > Why IKE messages cannot be used for this purpose? > > > > > > > > > > > > I think that possibly it can, and this is the kind of discussion that > > > > > > I think we should have. The advantage of doing that is that it requires > > > > > > no new code on the responder! That's a big win for deploying. > > > > > > It means that this can be done unilaterally, no new > > > > > > specification, just implementation advice. > > > > > > > > > > > > The slight implementation challenge is making sure that the IKE > > > > > > traffic is going along the same path as the ESP traffic. I'd > > > > > > like to hear from Ron about whether this is an issue. > > > > > > > > > > > > I also thought about using having some plpmtud on each end make > > > > > > a TCP connection *within* the tunnel and use the already defined > > > > > > plpmtu > > > > for TCP. > > > > > > That might be really easy for systems without user/kernel > > > > > > divisions (some router kernels). It would require some > > > > > > notifications to indicate that the responder has a TCP port > > > > > > open. And of course, the traffic would have to fit into the tunnel as > > well. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > Valery. > > > > > > > > > > > > >> But, if we can get PLMTUD deployed for all traffic, then > > > > > > the end-nodes can > > > > > > >> do appropriate PMTU probing and can figure out what the > > > > > > inner > > > > MTU is. > > > > > > >> i.e. just get everyone to enable plpmtu (4821). It's a knob on > > most > > > > > > >> systems, which has been left in the off state because of > > > > > > lack of evidence > > > > > > >> that it isn't harmful. > > > > > > >> > > > > > > >> There seems to be some sticking points among the > > > > > > high-speed about > > > > > > CDNs: > > > > > > >> they hate all PMTUD as it screws with tx scheduling into > > hardware. > > > > > > >> (TCP segment offload issues) > > > > > > >> > > > > > > >> So they just use 1280 is what I was told. That's good > > > > > > for the network, but > > > > > > >> it removes them as strong allies for getting PLPMTUD > > > > > > enabled by default > > > > > > >> everywhere. It would be nice if we could get a BCP out of them. > > > > Such > > > > > > >> BCP could also bless PLPMTUD for everyone else. I was > > > > > > pushing for > > > > this > > > > > > >> with RFC8200/STD86 but there was insufficient evidence of > > > > > > deployment. > > > > > > >> > > > > > > >> -- > > > > > > >> Michael Richardson , Sandelman > > > > > > Software Works > > > > > > >> -= IPv6 IoT consulting =- > > > > > > >> > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Michael Richardson , Sandelman Software > > > > Works > > > > > > -= IPv6 IoT consulting =- > > > > > > > > > > > > From nobody Thu Apr 12 06:51:59 2018 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 5A9D21273E2 for ; Thu, 12 Apr 2018 06:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 Vji5K35Bexv6 for ; Thu, 12 Apr 2018 06:51:57 -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 2D3FC127136 for ; Thu, 12 Apr 2018 06:51:57 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 40MMlb6Twxz1jM for ; Thu, 12 Apr 2018 15:51:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1523541115; bh=fUOPOZb4DaffdpuhGILX8oBvkYAhFfYITkXzZ9lnu6w=; h=Date:From:To:Subject:In-Reply-To:References; b=aeNncC/i97PtK8sr50EwsFHcDhrg/+HDQGr0fAIShszr1EajbAhKVDtrCUtZUy0f6 TTwB3W8jPIstcUBJ5jmHjgDKFVa3hkTiEKI+h6bfSC6Xia7VE4tK36gQvvBCNfeexo oBL2ILSJ7POvc6OjMaPr1wECRzc6pxuwPMbdb6+Y= 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 kiqRpL4sHI4X for ; Thu, 12 Apr 2018 15:51:55 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Thu, 12 Apr 2018 15:51:55 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 485A530B3EA; Thu, 12 Apr 2018 09:51:54 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 485A530B3EA Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 3EAB9400169C for ; Thu, 12 Apr 2018 09:51:54 -0400 (EDT) Date: Thu, 12 Apr 2018 09:51:54 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" In-Reply-To: Message-ID: References: <11057.1522877721@obiwan.sandelman.ca> <003c01d3ccd2$db7c20e0$927462a0$@gmail.com> <1172.1522940927@obiwan.sandelman.ca> <012601d3cd78$343cdd50$9cb697f0$@gmail.com> <02e401d3d099$281d2a10$78577e30$@gmail.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] PLMTUD probes for IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 13:51:58 -0000 On Wed, 11 Apr 2018, Ron Bonica wrote: > - If we do nothing, tunnel performance is acceptable but suboptimal. We can prevent blackholing by statically configuring the tunnel MTU to a sufficiently low value. However, we cannot take advantage of tunnels with larger PMTUs. > > - If we use IKE to exchange probes and acks, tunnel performance may become totally unacceptable. In the situation where a) IKE messages traverse a different path than encrypted payloads and b) the PMTU associated with the IKE path is greater than the PMTU associated with encrypted payload path, we may produce an inflated estimate of the Tunnel MTU. This may lead to black holing. Using IKE also has a disandvantage for for those implementations that only support a window size of one. If those IKE messages are lost - which is highly likely because we are trying out larger window sizes until we find something that works - things get tricky (even trickier then the current liveness + mobike situation) Paul From nobody Fri Apr 13 01:14:32 2018 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 98AC7126B6E for ; Fri, 13 Apr 2018 01:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNWhUA9-B5VM for ; Fri, 13 Apr 2018 01:14:28 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 5AB77124234 for ; Fri, 13 Apr 2018 01:14:27 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w3D8ELYv013788 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 13 Apr 2018 11:14:21 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w3D8EKpq002754; Fri, 13 Apr 2018 11:14:20 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23248.26332.562067.784381@fireball.acr.fi> Date: Fri, 13 Apr 2018 11:14:20 +0300 From: Tero Kivinen To: Ron Bonica Cc: Valery Smyslov , "'Michael Richardson'" , "ipsec\@ietf.org" In-Reply-To: References: <11057.1522877721@obiwan.sandelman.ca> <003c01d3ccd2$db7c20e0$927462a0$@gmail.com> <1172.1522940927@obiwan.sandelman.ca> <012601d3cd78$343cdd50$9cb697f0$@gmail.com> <02e401d3d099$281d2a10$78577e30$@gmail.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 4 min Archived-At: Subject: Re: [IPsec] PLMTUD probes for IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 08:14:31 -0000 Ron Bonica writes: > Hi Valery, > > I am thinking like this....... > > - If we do nothing, tunnel performance is acceptable but > suboptimal. We can prevent blackholing by statically configuring > the tunnel MTU to a sufficiently low value. However, we cannot > take advantage of tunnels with larger PMTUs. > > - If we use IKE to exchange probes and acks, tunnel performance may > become totally unacceptable. In the situation where a) IKE > messages traverse a different path than encrypted payloads and b) > the PMTU associated with the IKE path is greater than the PMTU > associated with encrypted payload path, we may produce an inflated > estimate of the Tunnel MTU. This may lead to black holing. And same happens, if the ESP packet path gots broken, but IKE path does not. This will lead to black holing. Or if the IKE path is broken but ESP works, the IKE will tear down the whole IKE SA (along with all Child SAs) and start over. Also as we are running TCP or similar inside the IPsec tunnel, that will most likely also notice that packets do not go through with that big MTU and will make packets smaller, or does something here disable end to end PMTUD... > So, our probe and acks have to be exchanged over the IPSEC tunnel. > At first I thought that the best way to do this was by exchanging > UDP messages. But you have a point. If we exchanged encrypted ICMP > Echo / Echo Response messages instead of UDP messages, there would > be slightly less code to write. Furthermore, we wouldn't need to > allocate a new UDP port. I am not really convinced about that yet. -- kivinen@iki.fi From nobody Fri Apr 13 01:18:05 2018 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 7CDED126C2F for ; Fri, 13 Apr 2018 01:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-3uROMsE90J for ; Fri, 13 Apr 2018 01:18:03 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 621F9124234 for ; Fri, 13 Apr 2018 01:18:03 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w3D8I045017778 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 13 Apr 2018 11:18:00 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w3D8I0St003490; Fri, 13 Apr 2018 11:18:00 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23248.26552.790605.595114@fireball.acr.fi> Date: Fri, 13 Apr 2018 11:18:00 +0300 From: Tero Kivinen To: Ron Bonica Cc: Valery Smyslov , "ipsec\@ietf.org" , "'Michael Richardson'" In-Reply-To: References: <11057.1522877721@obiwan.sandelman.ca> <003c01d3ccd2$db7c20e0$927462a0$@gmail.com> <1172.1522940927@obiwan.sandelman.ca> <012601d3cd78$343cdd50$9cb697f0$@gmail.com> <02e401d3d099$281d2a10$78577e30$@gmail.com> <23244.38734.270422.683057@fireball.acr.fi> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 3 min Archived-At: Subject: Re: [IPsec] PLMTUD probes for IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 08:18:04 -0000 Ron Bonica writes: > In 99.9% of cases you are probably correct. If there is an ECMP > between the encrypting node and the decrypting node, all ECMPs have > the same PMTU. Is it 99.9%, or 99.9999%? > And because this is true in such a vast majority of cases, none of > us have seen a situation where one ECMP has a larger PMTU than then > next. If none has not yet been seen it is much closer to 100% than 99.9%. Depending of course how many setups people have seen... > However, we still need to be prepared for that rare situation where > one ECMP does have a greater PMTU that the next. Although black > swans are rare, they bite very hard! There is also option to say that network is so broken that we fall back to IPsec over TCP, and in that case both ESP and IKE packets go inside same TCP stream and MTU discovery is done simlarly for both, so things work. I.e., that might be acceptable solution for those rare really broken cases. -- kivinen@iki.fi From nobody Fri Apr 13 01:21:00 2018 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 E42621241FC for ; Fri, 13 Apr 2018 01:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BO6Mq2_i8j2p for ; Fri, 13 Apr 2018 01:20:59 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 B1998124234 for ; Fri, 13 Apr 2018 01:20:58 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w3D8Kuux027901 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 13 Apr 2018 11:20:56 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w3D8KueG008109; Fri, 13 Apr 2018 11:20:56 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23248.26728.849312.586523@fireball.acr.fi> Date: Fri, 13 Apr 2018 11:20:56 +0300 From: Tero Kivinen To: Paul Wouters Cc: "ipsec\@ietf.org WG" In-Reply-To: References: <11057.1522877721@obiwan.sandelman.ca> <003c01d3ccd2$db7c20e0$927462a0$@gmail.com> <1172.1522940927@obiwan.sandelman.ca> <012601d3cd78$343cdd50$9cb697f0$@gmail.com> <02e401d3d099$281d2a10$78577e30$@gmail.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 1 min Archived-At: Subject: Re: [IPsec] PLMTUD probes for IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 08:21:00 -0000 Paul Wouters writes: > Using IKE also has a disandvantage for for those implementations that > only support a window size of one. If those IKE messages are lost - > which is highly likely because we are trying out larger window sizes > until we find something that works - things get tricky (even trickier > then the current liveness + mobike situation) That is good reason for requiring bigger window size if we do this in IKE for implementations supporting this. Actually if you do mobike, you most likely also want to use bigger window sizes... And of course the protocol needs to be designed to work with IKE packets. -- kivinen@iki.fi From nobody Sun Apr 15 19:21:38 2018 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 29B2B12D887 for ; Sun, 15 Apr 2018 19:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 buxr_MtYzp5p for ; Sun, 15 Apr 2018 19:21:34 -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 AAC6512D77A for ; Sun, 15 Apr 2018 19:21:34 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 40PXF81gWGz1Gp; Mon, 16 Apr 2018 04:21:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1523845292; bh=cinjpYxYh47iQxYtH49KNl4kVy3+IGnsNmfjVGWSdfo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=hpu81z4t4ChI09yD0leZjB1/onA/CfLHc/T3G9kn3VntMB+Xu4VRM/MiRW7J4CC/u 2DVBWQQztqnCyTz2g/XxAhwLU9Q4MhvQlGfHgag1oK0TzgsxdtclLczWqZS9jZYbjI qmRsgwXVVdfWHqZjyyDWwBtU5ESQssoN9SgtomEg= 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 cm3coPshUL4A; Mon, 16 Apr 2018 04:21:31 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 16 Apr 2018 04:21:31 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 1982762D29; Sun, 15 Apr 2018 22:21:30 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 1982762D29 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0E1D340D358A; Sun, 15 Apr 2018 22:21:30 -0400 (EDT) Date: Sun, 15 Apr 2018 22:21:30 -0400 (EDT) From: Paul Wouters To: Tero Kivinen cc: "ipsec@ietf.org WG" In-Reply-To: <23248.26728.849312.586523@fireball.acr.fi> Message-ID: References: <11057.1522877721@obiwan.sandelman.ca> <003c01d3ccd2$db7c20e0$927462a0$@gmail.com> <1172.1522940927@obiwan.sandelman.ca> <012601d3cd78$343cdd50$9cb697f0$@gmail.com> <02e401d3d099$281d2a10$78577e30$@gmail.com> <23248.26728.849312.586523@fireball.acr.fi> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] PLMTUD probes for IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 02:21:37 -0000 On Fri, 13 Apr 2018, Tero Kivinen wrote: > Paul Wouters writes: >> Using IKE also has a disandvantage for for those implementations that >> only support a window size of one. If those IKE messages are lost - >> which is highly likely because we are trying out larger window sizes >> until we find something that works - things get tricky (even trickier >> then the current liveness + mobike situation) > > That is good reason for requiring bigger window size if we do this in > IKE for implementations supporting this. Actually if you do mobike, > you most likely also want to use bigger window sizes... Perhaps such a requirement could help. I still feel the whole msgid handling in IKEv2 requires some clarification document, or perhaps even a change in the specification. Paul