From nobody Thu Mar 1 10:15: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 8DA0012EC3B; Thu, 1 Mar 2018 10:15:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mC8jYTvLe8Vh; Thu, 1 Mar 2018 10:15:37 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0712.outbound.protection.outlook.com [IPv6:2a01:111:f400:fd00::712]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66C7F12EC45; Thu, 1 Mar 2018 10:15:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9LqCwVecO7/p8RVlUfW5T52XTPO2LYi0jW15lrmNJ40=; b=RFubn4a+uCwKbFz4VZIto2a95LnOyClopw2/nPWHqbZgiUXc5GEaNqtltOfWa3uB2tiOa3B+Qhca9xBfXw0qsj0Ta9hIGEe2hqn3Xn6iAV4Le8WI1K9FsT/jOicZ1hiSRSD54EhgXo0XjasDKTX9f6jtT0uY03mu5/Kbr8LmfDQ= Received: from MW2PR0901MB2313.namprd09.prod.outlook.com (52.132.147.27) by MW2PR0901MB2313.namprd09.prod.outlook.com (52.132.147.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.548.13; Thu, 1 Mar 2018 18:15:35 +0000 Received: from MW2PR0901MB2313.namprd09.prod.outlook.com ([fe80::70c1:9b22:8b43:4053]) by MW2PR0901MB2313.namprd09.prod.outlook.com ([fe80::70c1:9b22:8b43:4053%13]) with mapi id 15.20.0548.014; Thu, 1 Mar 2018 18:15:35 +0000 From: "Waltermire, David A. (Fed)" To: "paul@nohats.ca" , Tommy Pauly CC: IPsecME WG , "draft-ietf-ipsecme-split-dns.authors@ietf.org" Thread-Topic: [IPsec] Shepherd Review of draft-ietf-ipsecme-split-dns-06 Thread-Index: AdOvZInWFoVQAJXuTMqN+ApYo9CCsQBVlrKAAAExxoAAAOP9gAAxWW7w Date: Thu, 1 Mar 2018 18:15:35 +0000 Message-ID: References: <26997F56-977F-4958-B720-2DDBC811D887@apple.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.224.58] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MW2PR0901MB2313; 6:slZDwP4nEKAS39JQ0O2e/MwhqvWXNDlOjHViciH2aEKD7sd5EwAuECQzdfzLofDWRBjehfeOv+fBsMFErWXNz6NpPhK5E32BRr5p2FRMUplPAjxnEdKAP/YP1P2GMlRSyqXt3/FAwroWhxiuZ1+xAUiHsoiPl9/0RsAEBS2wjjLXr/+MISOXEvr/pg5LzgbYyQB4yVFQmZMMb0GAZS5t4XV5K0oy6hC9eAaWv1u9X8RoyytgEBwEm7jn//l4F4VIxKZ71Dmfi5dWbsstEaD8Vhm3pB9TPN3+p1JJyBR9pwAdqq3g+mKbM3nHDbjXpmjrqLD/PnCZt/nfzp0Jkrmt1ei9PcVKWafl7sk/SxY5FZeuZ225hrCWJFVP0wJ7NHjU; 5:WEophQtlx9952pkiNg+lbQfir69kJYzoPR7vkzOlD527KqeoVcotWcbc0Lr8Qw5GUyAPXVNi3iwvm9ej7dE5tRZ2e+uKxty9TG3l4PXZAaPg47F66annKHZlXlNf6ruON0NpFKKfcq5EcjtLHCOc5sb5O4Ohq8d5ObHLDgI5wbI=; 24:fhSvQmtbqU3OjVhls37YplIjjQKOixbwO+Q2wOCyG8eUeqZaQqb5/DMAVnHtqRBDsuq6aNdKHwMyRVM7XjpJlrug7o1bkwuiCQ5x2DkuZEY=; 7:ayeZysyDbI7ORWUeF9QOq67VKzweJTYBikyht0QhP3oTxOv4dP740WFTcEoCqBh9fMPmBR3tymlh0X+X41LIlCiFWI54Ak7K3TegcxgSJ7t7SIL0z1y8Rcb8jpQ2No8u8K+Iw5Z2LL0b1obi5DrjxmdSzppahUg5tbRd+4jG6piGDNmtDogmJstwXi76t8f6Eue/hj+OEjxz6S7gxdL0bwtXTpHMOI39pDw8p8TKGsJjJQvFjsQ9TmpYABXEdNnc x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: eb6d961b-0800-4a11-7474-08d57fa06d93 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:MW2PR0901MB2313; x-ms-traffictypediagnostic: MW2PR0901MB2313: x-ld-processed: 2ab5d82f-d8fa-4797-a93e-054655c61dec,ExtAddr x-exchange-antispam-report-cfa: BCL:0; PCL:0; RULEID:(3231001); SRVR:MW2PR0901MB2313; BCL:0; PCL:0; RULEID:; SRVR:MW2PR0901MB2313; x-forefront-prvs: 05986C03E0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(189003)(199004)(13464003)(86362001)(575784001)(8676002)(8936002)(81156014)(45080400002)(3846002)(6116002)(5660300001)(4326008)(7736002)(14454004)(966005)(66066001)(74316002)(305945005)(2900100001)(25786009)(6436002)(105586002)(33656002)(186003)(8666007)(97736004)(229853002)(7696005)(2950100002)(54906003)(93886005)(106356001)(99286004)(110136005)(3280700002)(5250100002)(6246003)(68736007)(3660700001)(55016002)(9686003)(59450400001)(76176011)(2501003)(6306002)(102836004)(26005)(6506007)(53546011); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR0901MB2313; H:MW2PR0901MB2313.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-microsoft-antispam-message-info: mg4TFVN5Z0oURigsIOjFjvw8v4yzPcsNRvxBhn3LFZR3Rd1gqOKaCF6bNdYCSEjIxstrp/a+vuYSXq3cJzW0YRokSic6oDyOzR5oqy9hfpKJ3YRL787WevhTqvD71HdtWwq3crwU7bTGJi2HmiKliQTtBQzHmm5zfIgo2M6Ix7s= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: eb6d961b-0800-4a11-7474-08d57fa06d93 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2018 18:15:35.2199 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR0901MB2313 Archived-At: Subject: Re: [IPsec] Shepherd Review of draft-ietf-ipsecme-split-dns-06 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, 01 Mar 2018 18:15:40 -0000 VG9tbXkgYW5kIFBhdWwsDQoNCkkgaGF2ZSB0aGUgc2hlcGhlcmQgd3JpdGUtdXAgcmVhZHkuDQoN ClBsZWFzZSBjb25maXJtIGFzIGF1dGhvcnMgdGhhdCAiYW55IGFuZCBhbGwgYXBwcm9wcmlhdGUg SVBSIGRpc2Nsb3N1cmVzIHJlcXVpcmVkIGZvciBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlIHBy b3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkgaGF2ZSBhbHJlYWR5IGJlZW4gZmlsZWQuIg0K DQpJIHdpbGwgc2VuZCBpdCBmb3J3YXJkIG9uY2UgSSBoZWFyIGZyb20gZWFjaCBvZiB5b3UuDQoN ClRoYW5rcywNCkRhdmUNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBQ YXVsIFdvdXRlcnMgW21haWx0bzpwYXVsQG5vaGF0cy5jYV0NCj4gU2VudDogV2VkbmVzZGF5LCBG ZWJydWFyeSAyOCwgMjAxOCAxOjM4IFBNDQo+IFRvOiBUb21teSBQYXVseSA8dHBhdWx5QGFwcGxl LmNvbT4NCj4gQ2M6IFdhbHRlcm1pcmUsIERhdmlkIEEuIChGZWQpIDxkYXZpZC53YWx0ZXJtaXJl QG5pc3QuZ292PjsgSVBzZWNNRSBXRw0KPiA8aXBzZWNAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLWlw c2VjbWUtc3BsaXQtZG5zLmF1dGhvcnNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtJUHNlY10g U2hlcGhlcmQgUmV2aWV3IG9mIGRyYWZ0LWlldGYtaXBzZWNtZS1zcGxpdC1kbnMtMDYNCj4gDQo+ IE9uIFdlZCwgMjggRmViIDIwMTgsIFRvbW15IFBhdWx5IHdyb3RlOg0KPiANCj4gPiBJ4oCZdmUg dXBkYXRlZCB0aGUgZHJhZnQgd2l0aCB5b3VyIGNvbW1lbnRzIGFzIHZlcnNpb24gLQ0KPiAwNzrC oGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBz JTNBJTJGJTJGd3d3DQo+IC5pZXRmLm9yZyUyRmlkJTJGZHJhZnQtaWV0Zi1pcHNlY21lLXNwbGl0 LWRucy0NCj4gMDcudHh0JmRhdGE9MDIlN0MwMSU3Q2RhdmlkLndhbHRlcm1pcmUlNDBuaXN0Lmdv diU3QzdmOWM0MmI2ODYyMTQzYw0KPiBlNTU0ZDA4ZDU3ZWRhNjI1ZiU3QzJhYjVkODJmZDhmYTQ3 OTdhOTNlMDU0NjU1YzYxZGVjJTdDMSU3QzAlNw0KPiBDNjM2NTU0Mzk4Nzg1NzIwMjk4JnNkYXRh PUlnZ2hMRSUyQkZlTzUlMkIxU3RpMFFxekpLRW9nVmdRJTJGdGxlDQo+IGljdlpFeHZEWjZRJTNE JnJlc2VydmVkPTANCj4gDQo+IFRoYW5rcyBmb3IgZG9pbmcgdGhpcy4gSSB3b3VsZCBtYWtlIG9u ZSBjaGFuZ2UgKGJ1dCBpdCBjYW4gYmUgZG9uZSBhZnRlciBJRVRGLQ0KPiBMQykNCj4gDQo+ICAJ Wy4uLl0gdGhlIGNvbnRlbnQgU0hPVUxEIGJlIGNvbnNpZGVyZWQgdW50cnVzdGVkIGFuZCBoYW5k bGVkDQo+IGFjY29yZGluZ2x5Lg0KPiANCj4gWW91IGNoYW5nZWQgc2hvdWxkIHRvIFNIT1VMRCwg YnV0IGluIHRoaXMgY2FzZSBpdCByZWFsbHkgaXMgYSBNVVNULg0KPiANCj4gUGF1bA0K From nobody Thu Mar 1 10:22:47 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 BC1B212EC56; Thu, 1 Mar 2018 10:22:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjM-RaqBQBoq; Thu, 1 Mar 2018 10:22:43 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8471412EC4C; Thu, 1 Mar 2018 10:22:43 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3zsglM59GQz3Fq; Thu, 1 Mar 2018 19:22:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1519928559; bh=ZIwpJYiAQt3E3odNsmn5H/XmFaogWV+xDGf/0nBiDMo=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=mD7PkAeO5bbzqYPu+ViK9e4nm5ZT4EjjTmP7tBLBLkrVcsmZKhbE92bjYmf0rzgA3 OHjftLd9DW+hSZ1eeTo7XjaAGQ50LhrhiR7bYdVEtCtQx55cP6h28ZeeMfOlOdFA2J btT/vWRbqpTcvIlhEjYhfP9X6MFg4baBtM9zxZb0= 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 ZyCANG6hcnCh; Thu, 1 Mar 2018 19:22:36 +0100 (CET) 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, 1 Mar 2018 19:22:35 +0100 (CET) Received: from [10.159.97.255] (unknown [199.119.232.223]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id BD3FA366715; Thu, 1 Mar 2018 13:22:34 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca BD3FA366715 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (15D100) In-Reply-To: Date: Thu, 1 Mar 2018 13:22:32 -0500 Cc: Tommy Pauly , IPsecME WG , "draft-ietf-ipsecme-split-dns.authors@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <26997F56-977F-4958-B720-2DDBC811D887@apple.com> To: "Waltermire, David A. (Fed)" Archived-At: Subject: Re: [IPsec] Shepherd Review of draft-ietf-ipsecme-split-dns-06 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, 01 Mar 2018 18:22:46 -0000 I have no IPR whatsoever on this document and don=E2=80=99t know of anyone w= ho does Sent from my iPhone > On Mar 1, 2018, at 13:15, Waltermire, David A. (Fed) wrote: >=20 > Tommy and Paul, >=20 > I have the shepherd write-up ready. >=20 > Please confirm as authors that "any and all appropriate IPR disclosures re= quired for full conformance with the provisions of BCP 78 and BCP 79 have al= ready been filed." >=20 > I will send it forward once I hear from each of you. >=20 > Thanks, > Dave >=20 >> -----Original Message----- >> From: Paul Wouters [mailto:paul@nohats.ca] >> Sent: Wednesday, February 28, 2018 1:38 PM >> To: Tommy Pauly >> Cc: Waltermire, David A. (Fed) ; IPsecME WG >> ; draft-ietf-ipsecme-split-dns.authors@ietf.org >> Subject: Re: [IPsec] Shepherd Review of draft-ietf-ipsecme-split-dns-06 >>=20 >>> On Wed, 28 Feb 2018, Tommy Pauly wrote: >>>=20 >>> I=E2=80=99ve updated the draft with your comments as version - >> 07: https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= w >> .ietf.org%2Fid%2Fdraft-ietf-ipsecme-split-dns- >> 07.txt&data=3D02%7C01%7Cdavid.waltermire%40nist.gov%7C7f9c42b6862143c >> e554d08d57eda625f%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7 >> C636554398785720298&sdata=3DIgghLE%2BFeO5%2B1Sti0QqzJKEogVgQ%2Ftle >> icvZExvDZ6Q%3D&reserved=3D0 >>=20 >> Thanks for doing this. I would make one change (but it can be done after I= ETF- >> LC) >>=20 >> [...] the content SHOULD be considered untrusted and handled >> accordingly. >>=20 >> You changed should to SHOULD, but in this case it really is a MUST. >>=20 >> Paul > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Mar 1 11:04: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 E555E12EB58 for ; Thu, 1 Mar 2018 11:04:23 -0800 (PST) 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 c--FUK5MgHAy for ; Thu, 1 Mar 2018 11:04:22 -0800 (PST) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (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 4F87E12ECA8 for ; Thu, 1 Mar 2018 11:04:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1519931062; x=2383844662; 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=RmHLfx3q+aJ8vtAjtypQpsMd8muKHtMdudLVmfESthE=; b=z5+aX9HJmGJzxR41NzdZoc3HJ2yRUwUPHCn0JuFELDCSRmShzW1xyLgxPhOojxmq XK30KVpWfZLwPoLnKIc9vE0qW92nHT2ZdFk0ALLR4kO/c235jVd1WQo+z1tQZi7O zw+dcJJJSchhhZ1QWlLdGobDbP4az1VG11PL3tYypLKtk5GepxPEQl2ZJuAYGCvC v26v7JDQSjx0gWhpw6elXFBYrXvIxOmhxIDHDjD5luE1mugUnk5VnVW0ReHTNYo0 RhVlm0P+FwmJ+vt53oF35eZkA1gsB5n3HZQY5vVpRqwNDaetrlYnjkfpZArubreR KuDCAykYO0tb/Bpf7FYs2Q==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 59.DA.13704.6BE489A5; Thu, 1 Mar 2018 11:04:22 -0800 (PST) X-AuditID: 11973e13-3f68e9e000003588-8c-5a984eb64f23 Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by relay5.apple.com (Apple SCV relay) with SMTP id 5E.59.23499.5BE489A5; Thu, 1 Mar 2018 11:04:22 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.192.171.234] (unknown [17.192.171.234]) by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180130 64bit (built Jan 30 2018)) with ESMTPSA id <0P4X00J52EB94V30@nwk-mmpp-sz11.apple.com>; Thu, 01 Mar 2018 11:04:21 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: Date: Thu, 01 Mar 2018 11:04:21 -0800 Cc: "Waltermire, David A. (Fed)" , IPsecME WG , "draft-ietf-ipsecme-split-dns.authors@ietf.org" Content-transfer-encoding: quoted-printable Message-id: <3607065D-D036-4F23-86FB-350A0C226943@apple.com> References: <26997F56-977F-4958-B720-2DDBC811D887@apple.com> To: Paul Wouters X-Mailer: Apple Mail (2.3466) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUi2FAYobvNb0aUwbP7HBYbe/6xWSydVGyx f8sLNov3ty4xObB4LFnyk8nj2sm/rB7f5zEFMEdx2aSk5mSWpRbp2yVwZVzq+sRccEqw4uui O0wNjPf4uhg5OSQETCSm3brD3MXIxSEksJpJYt2d5WwwiQ2/L7NCJA4xSiy838MCkuAVEJT4 MfkekM3BwSygLjFlSi5EzWQmiVfbrrGCxIUFJCQ270mEMN0lNszIAelkE1CROP5tAzOIzSlg K7Fn1hqwVSwCqhKdU6cxgYxhFtjHKPHk9nR2kASzgLbEk3cXWCHW2kg8vNHKBrGrk1niwavj YN0iAooSk848YoE4Wlai5ftcsKMlBGawSTRv38A0gVF4FpK7ZyHcPQvJjgWMzKsYhXITM3N0 M/NM9RILCnJS9ZLzczcxgoJ+up3wDsbTq6wOMQpwMCrx8ArwzIgSYk0sK67MPcQozcGiJM6r vn5KlJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGv+Ceyd1/k5/Hxs9Vip25S3RK1baLPxYx eNffFgyL17uaLu1S5XZs8xVr4+CLoqd3dL5kkX0nreqhoylrz8yQLfB9e9S9M3+3C0TvYzsz qfiHw9sz6f2BgofjToX9iS4pnHXvk/qJmCPWKWH/EuZuf5u88ICjzkzGfB6HC+/P7yz7Jnf0 oPF7JZbijERDLeai4kQASKj8hVsCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNLMWRmVeSWpSXmKPExsUi2FA8W3eb34wog2cdbBYbe/6xWSydVGyx f8sLNov3ty4xObB4LFnyk8nj2sm/rB7f5zEFMEdx2aSk5mSWpRbp2yVwZVzq+sRccEqw4uui O0wNjPf4uhg5OSQETCQ2/L7M2sXIxSEkcIhRYuH9HhaQBK+AoMSPyfeAbA4OZgF1iSlTciFq JjNJvNp2jRUkLiwgIbF5TyKE6S6xYUYOSCebgIrE8W8bmEFsTgFbiT2z1rCB2CwCqhKdU6cx gYxhFtjHKPHk9nR2kASzgLbEk3cXWCHW2kg8vNHKBrGrk1niwavjYN0iAooSk848YoE4Wlai 5ftc1gmMArOQnDoL4dRZSMYuYGRexShQlJqTWGmql1hQkJOql5yfu4kRHKSFETsY/y+zOsQo wMGoxMMrwDMjSog1say4MhcYFhzMSiK8p7dPixLiTUmsrEotyo8vKs1JLT7EKM3BoiTO2+jR GyUkkJ5YkpqdmlqQWgSTZeLglGpgLC5pO7vddX37L9UT9WXBtudNFDMVGNY9ORnm7hX+92jE sf+Bi2M3vJusszDc6+c8jTN1h8r2F9epL/5r8s0/4c47wQfv03ujGGoP3zi8PflnaEBlvHy3 wIeXynMuTXbX33Ty83fn1HLW1ZEzypJSUwLlraWZ55/5oho0i0UixWdJoKW3aQKjEktxRqKh FnNRcSIAdnW8DE4CAAA= Archived-At: Subject: Re: [IPsec] Shepherd Review of draft-ietf-ipsecme-split-dns-06 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, 01 Mar 2018 19:04:24 -0000 I as well have no IPR on this document and am not aware of any that = exists. Thanks, Tommy > On Mar 1, 2018, at 10:22 AM, Paul Wouters wrote: >=20 > I have no IPR whatsoever on this document and don=E2=80=99t know of = anyone who does >=20 > Sent from my iPhone >=20 >> On Mar 1, 2018, at 13:15, Waltermire, David A. (Fed) = wrote: >>=20 >> Tommy and Paul, >>=20 >> I have the shepherd write-up ready. >>=20 >> Please confirm as authors that "any and all appropriate IPR = disclosures required for full conformance with the provisions of BCP 78 = and BCP 79 have already been filed." >>=20 >> I will send it forward once I hear from each of you. >>=20 >> Thanks, >> Dave >>=20 >>> -----Original Message----- >>> From: Paul Wouters [mailto:paul@nohats.ca] >>> Sent: Wednesday, February 28, 2018 1:38 PM >>> To: Tommy Pauly >>> Cc: Waltermire, David A. (Fed) ; IPsecME = WG >>> ; draft-ietf-ipsecme-split-dns.authors@ietf.org >>> Subject: Re: [IPsec] Shepherd Review of = draft-ietf-ipsecme-split-dns-06 >>>=20 >>>> On Wed, 28 Feb 2018, Tommy Pauly wrote: >>>>=20 >>>> I=E2=80=99ve updated the draft with your comments as version - >>> 07: = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww >>> .ietf.org%2Fid%2Fdraft-ietf-ipsecme-split-dns- >>> 07.txt&data=3D02%7C01%7Cdavid.waltermire%40nist.gov%7C7f9c42b6862143c >>> e554d08d57eda625f%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7 >>> C636554398785720298&sdata=3DIgghLE%2BFeO5%2B1Sti0QqzJKEogVgQ%2Ftle >>> icvZExvDZ6Q%3D&reserved=3D0 >>>=20 >>> Thanks for doing this. I would make one change (but it can be done = after IETF- >>> LC) >>>=20 >>> [...] the content SHOULD be considered untrusted and handled >>> accordingly. >>>=20 >>> You changed should to SHOULD, but in this case it really is a MUST. >>>=20 >>> Paul >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Mar 1 13:11:40 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 4616D12FAB4; Thu, 1 Mar 2018 13:11:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: David Waltermire To: X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Cc: ipsec@ietf.org, David Waltermire , ipsecme-chairs@ietf.org, iesg-secretary@ietf.org, david.waltermire@nist.gov Message-ID: <151993869928.21706.1586771739606638650.idtracker@ietfa.amsl.com> Date: Thu, 01 Mar 2018 13:11:39 -0800 Archived-At: Subject: [IPsec] Publication has been requested for draft-ietf-ipsecme-split-dns-07 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: Thu, 01 Mar 2018 21:11:39 -0000 David Waltermire has requested publication of draft-ietf-ipsecme-split-dns-07 as Proposed Standard on behalf of the IPSECME working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/ From nobody Fri Mar 2 02:06:09 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 BC9C7120725 for ; Fri, 2 Mar 2018 02:06:07 -0800 (PST) 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 PEIfRJncLXfF for ; Fri, 2 Mar 2018 02:06:05 -0800 (PST) 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 B063E127601 for ; Fri, 2 Mar 2018 02:06:03 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w22A5vY7014900 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 2 Mar 2018 12:05:57 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w22A5vMq002220; Fri, 2 Mar 2018 12:05:57 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23193.8709.433275.111834@fireball.acr.fi> Date: Fri, 2 Mar 2018 12:05:57 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 3 min Archived-At: Subject: [IPsec] Presentations for IETF 101 for IPsecME 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, 02 Mar 2018 10:06:08 -0000 If you want to present something in the IETF 101, send your request for agenda slots to the us (WG chairs). We have already received two requests (from Valery and Scott), but if there is something else you think needs to be presented, please say so... I will try to put up the agenda for the meeting next week. -- kivinen@iki.fi From nobody Fri Mar 2 22:51: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 A778A126C19 for ; Fri, 2 Mar 2018 22:51:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 U8XNZFIqRcxl for ; Fri, 2 Mar 2018 22:51:16 -0800 (PST) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 271C0124D68 for ; Fri, 2 Mar 2018 22:51:16 -0800 (PST) Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w236oPxS031235 for ; Fri, 2 Mar 2018 22:51:15 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=O0TpVp35g03sesvvvE6QywQfuk6GdFWSr0KXaXO0qZM=; b=SIcn/OSCyEaT6KvHRPyULt4wTgfEh5dqQQBf847J8Hf2pAyYmRZCIpQAUfjM83cxm7WD FWiLngHzST0lkkrZIGETaVuO1vKKjJ6dqK7h7ddrGyjcY4F8wZGSSCERlpIL1mEcCIOL +FumPSnsJNkaJs7Xu6QWUjykmc/2BaXK3rHSGnMww7hCgSyxjldnZYfAHMU430ttMjfJ Vff+3J8pxDZGcTHZOhEztCo0GhIVP7i1n3P/yJM/GdhqS6XEg0/fZ1lqk2m+avGXYH7z V44gPfpF5CRZ0buJ3l/kFtaivziS7ghsHUSgZWzYY3a4Fg9fWhmw+zkiKPOri4JVwkJM WA== Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0117.outbound.protection.outlook.com [207.46.163.117]) by mx0b-00273201.pphosted.com with ESMTP id 2gfds6rseg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Fri, 02 Mar 2018 22:51:15 -0800 Received: from CY1PR05MB1867.namprd05.prod.outlook.com (10.162.167.145) by CY1PR05MB2443.namprd05.prod.outlook.com (10.167.10.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.567.6; Sat, 3 Mar 2018 06:51:13 +0000 Received: from CY1PR05MB1867.namprd05.prod.outlook.com ([10.162.167.145]) by CY1PR05MB1867.namprd05.prod.outlook.com ([10.162.167.145]) with mapi id 15.20.0567.006; Sat, 3 Mar 2018 06:51:13 +0000 From: Shibu Piriyath To: "ipsec@ietf.org" Thread-Topic: New Version Notification for draft-spiriyath-ipsecme-dynamic-ipsec-pmtu-01.txt Thread-Index: AQHTsWljbXk3l9UmIkaRPHJNyuO06KO+E5cR Date: Sat, 3 Mar 2018 06:51:13 +0000 Message-ID: References: <151991442914.10105.17307594217060279966.idtracker@ietfa.amsl.com> In-Reply-To: <151991442914.10105.17307594217060279966.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR05MB2443; 7:decXfxdyd4xJSFviuXcQlOt6jjw3yyUqEiJRcwSBfO6M85x8X+oSLHI6UlybXARwJOgItih9uy1lhCgH2acj44UKfojcqELOoQel2amoBbVpXM1mpOMZRWODf+qI83DsTlTkFm9gbc6lM5HHMn2uz0qV8lUqB+L3S4yyjgx508FY52VKI5f+CSQpKrkeX2Ud/w2ErSdC6JOL+Nj4mLFXPQSok1v9PuCvWWbUWx/PRa+epwWPJdFnTOdrOSY6W7v0 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: b4824e13-483e-4fdd-529b-08d580d327c2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:CY1PR05MB2443; x-ms-traffictypediagnostic: CY1PR05MB2443: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231220)(944501244)(52105095)(10201501046)(6055026)(6041288)(20161123560045)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011); SRVR:CY1PR05MB2443; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2443; x-forefront-prvs: 0600F93FE1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(396003)(346002)(366004)(39380400002)(377424004)(189003)(199004)(966005)(8936002)(1730700003)(81166006)(81156014)(76176011)(5640700003)(8676002)(478600001)(99286004)(7696005)(186003)(6436002)(606006)(86362001)(14454004)(316002)(2501003)(97736004)(6606003)(229853002)(2351001)(3660700001)(5660300001)(102836004)(3280700002)(59450400001)(15650500001)(19627405001)(6916009)(106356001)(53546011)(2950100002)(2906002)(55016002)(68736007)(6506007)(2473003)(3846002)(9686003)(54896002)(25786009)(6306002)(74316002)(6116002)(236005)(77096007)(26005)(2900100001)(66066001)(7736002)(53936002)(33656002)(105586002)(6346003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2443; H:CY1PR05MB1867.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: /4IXOYOa6iVlW/A5RF+c3aiGAy9P+vNAMAr94LGa4niaKSgIlLIcEwIII2SuSlLdI1sp1+R4mYZXIcEzVYRe6DJvqTvbmUkl3Tcgg0biSI0ZSee44cYdWvYfmZlkx+30aek4bWajvYF0x50dYzm/WhvgrqWaJyCxpkT7ZTBMfHk= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR05MB18675B67800A73660B9A751BA1C40CY1PR05MB1867namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: b4824e13-483e-4fdd-529b-08d580d327c2 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2018 06:51:13.5323 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2443 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-03_04:, , 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-1803030084 Archived-At: Subject: [IPsec] Fw: New Version Notification for draft-spiriyath-ipsecme-dynamic-ipsec-pmtu-01.txt 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: Sat, 03 Mar 2018 06:51:19 -0000 --_000_CY1PR05MB18675B67800A73660B9A751BA1C40CY1PR05MB1867namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello IPSECME, We have posted a new version of the draft incorporating comments received f= or version 0. Please review and let us know your thoughts, Thank you. Shibu. ________________________________ From: internet-drafts@ietf.org Sent: Thursday, March 1, 2018 7:57 PM To: Shibu Piriyath; Ron Bonica; Suresh Melam; Umesh Mangla; Subject: New Version Notification for draft-spiriyath-ipsecme-dynamic-ipsec= -pmtu-01.txt A new version of I-D, draft-spiriyath-ipsecme-dynamic-ipsec-pmtu-01.txt has been successfully submitted by Ron Bonica and posted to the IETF repository. Name: draft-spiriyath-ipsecme-dynamic-ipsec-pmtu Revision: 01 Title: Packetization Layer Path Maximum Transmission Unit Discover= y (PLPMTUD) For IPsec Tunnels Document date: 2018-02-28 Group: Individual Submission Pages: 13 URL: https://www.ietf.org/internet-drafts/draft-spiriyath-ipsecm= e-dynamic-ipsec-pmtu-01.txt Status: https://datatracker.ietf.org/doc/draft-spiriyath-ipsecme-dy= namic-ipsec-pmtu/ draft-spiriyath-ipsecme-dynamic-ipsec-pmtu-00 - Path ... datatracker.ietf.org Path Maximum Transmission Unit Discovery (PMTUD) For IPsec Tunnels Using Th= e Internet Key Exchange Protocol (IKE) Version 2 (Internet-Draft, 2018) Htmlized: https://tools.ietf.org/html/draft-spiriyath-ipsecme-dynamic= -ipsec-pmtu-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-spiriyath-ipsec= me-dynamic-ipsec-pmtu-01 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-spiriyath-ipsecme= -dynamic-ipsec-pmtu-01 Abstract: This document describes Packetization Layer PMTU Discovery (PLPMTUD) procedures for IPSec tunnels. In these procedures, the encrypting node discovers and maintains a running estimate of the tunnel MTU. In order to do this, the encrypting nodes sends Probe Packets of various size through the IPSec tunnel. If the size of Probe Packet exceeds the tunnel MTU, a downstream node discards the packet and sends an ICMP PTB message to the encrypting node. The encrypting node ignores the ICMP PTB message. If the size of the Probe Packet does not exceed the tunnel MTU and the decrypting node receives the Probe Packet, the decrypting node sends an Acknowledgement Packet to encrypting node through the IPSec tunnel. The Acknowledgement Packet indicates the size of the Probe Packet. The procedures described in this document are applicable to IPSec tunnels that are signaled by IKEv2 and provide authentication services. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_CY1PR05MB18675B67800A73660B9A751BA1C40CY1PR05MB1867namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello IPSECME,


We have posted a new version of t= he draft incorporating comments received for version 0.

Please review and let us know you= r thoughts,


Thank you.

Shibu.



From: internet-drafts@iet= f.org <internet-drafts@ietf.org>
Sent: Thursday, March 1, 2018 7:57 PM
To: Shibu Piriyath; Ron Bonica; Suresh Melam; Umesh Mangla;
Subject: New Version Notification for draft-spiriyath-ipsecme-dynami= c-ipsec-pmtu-01.txt
 

A new version of I-D, draft-spiriyath-ipsecme-dynamic-ipsec-pmtu-01.txt
has been successfully submitted by Ron Bonica and posted to the
IETF repository.

Name:           draft-spi= riyath-ipsecme-dynamic-ipsec-pmtu
Revision:       01
Title:          Packetization = Layer Path Maximum Transmission Unit Discovery (PLPMTUD) For IPsec Tunnels<= br> Document date:  2018-02-28
Group:          Individual Sub= mission
Pages:          13
URL:            https://www.ietf.org/internet-drafts/draft-spiriyath-ipsecme-dynamic-ipsec-= pmtu-01.txt
Status:         https://datatracker.ietf.org/doc/draft-spiriyath-ipsecme-dynamic-ipsec-pmtu= /
datatracker.ietf.org
Path Maximum Transmission Unit Discovery (PMTUD) For IPsec Tunnels Using Th= e Internet Key Exchange Protocol (IKE) Version 2 (Internet-Draft, 2018)

Htmlized:       https://tools.ietf.org/html/draft-spiriyath-ipsecme-dynamic-ipsec-pmtu-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-spiriyath-ipsecme-dynamic-ipsec= -pmtu-01
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-spiriyath-ipsecme-dynamic-ipsec-p= mtu-01

Abstract:
   This document describes Packetization Layer PMTU Discovery (PL= PMTUD)
   procedures for IPSec tunnels.  In these procedures, the e= ncrypting
   node discovers and maintains a running estimate of the tunnel = MTU.
   In order to do this, the encrypting nodes sends Probe Packets = of
   various size through the IPSec tunnel.  If the size of Pr= obe Packet
   exceeds the tunnel MTU, a downstream node discards the packet = and
   sends an ICMP PTB message to the encrypting node.  The en= crypting
   node ignores the ICMP PTB message.  If the size of the Pr= obe Packet
   does not exceed the tunnel MTU and the decrypting node receive= s the
   Probe Packet, the decrypting node sends an Acknowledgement Pac= ket to
   encrypting node through the IPSec tunnel.  The Acknowledg= ement Packet
   indicates the size of the Probe Packet.

   The procedures described in this document are applicable to IP= Sec
   tunnels that are signaled by IKEv2 and provide authentication<= br>    services.

            &nb= sp;            =             &nb= sp;            =             &nb= sp;            =       


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--_000_CY1PR05MB18675B67800A73660B9A751BA1C40CY1PR05MB1867namp_-- From nobody Sun Mar 4 12:19: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 A34A41242F5 for ; Sun, 4 Mar 2018 12:18:58 -0800 (PST) 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 45gDqlxIJO2S for ; Sun, 4 Mar 2018 12:18:55 -0800 (PST) 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 605D4126BFD for ; Sun, 4 Mar 2018 12:18:55 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w24KIlXK028433 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 4 Mar 2018 22:18:47 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w24KIl4P012706; Sun, 4 Mar 2018 22:18:47 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23196.21671.588501.57113@fireball.acr.fi> Date: Sun, 4 Mar 2018 22:18:47 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 19 min X-Total-Time: 29 min Archived-At: Subject: [IPsec] Summary of charter discussion 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, 04 Mar 2018 20:18:59 -0000 There was very little discussion about the "ready" parts of the charter (one comment from Wouters, but no new text or explination why "mesh" is different than host-to-host. Additional items: Item 1 responder MOBIKE We had some discussion already on the list, and several people commented (Paul Wouters, Hu Jun) that they do want to have more discussion about the goal before going to the the solutions. I also think that the item is not well enough explained in the charter that we can work on it, so perhaps we leave this out for now and continue discussion in the list and in the next meeting about what we really want. Item 2 Address Failure Errors We got some support (Michael Richardson), and Paul Wouters wanted to have more discussion about this. I myself think this is clear enough and we can add it to the charter. Item 3 Labeled IPsec We had concerns (Yoav Nir, Valery Smyslov) that this should not affect implementations which do not implement this, so I think the charter item should be modified to explictly say so. I.e., add text which says there will not be any need to change old implementations. Item 4 Mitigating privacy concerns We had very little support for this and some concerns about this getting in the arms race with goverments etc. I myself do not think this item is ready yet to be taken as charter item, we need research on this before we can actually start working on the protocol changes. ---------------------------------------------------------------------- This means the final proposed chater would be: ---------------------------------------------------------------------- The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs, IKEv1 is now obsoleted), IKEv2 (RFC 7296), and the IPsec security architecture (RFC 4301). IPsec is widely deployed in VPN gateways, VPN remote access clients, and as a substrate for host-to-host, host-to-network, and network-to-network security. The IPsec Maintenance and Extensions Working Group continues the work of the earlier IPsec Working Group which was concluded in 2005. Its purpose is to maintain the IPsec standard and to facilitate discussion of clarifications, improvements, and extensions to IPsec, mostly to ESP and IKEv2. The working group also serves as a focus point for other IETF Working Groups who use IPsec in their own protocols. The current work items include: IKEv1 using shared secret authentication was partially resistant to quantum computers. IKEv2 removed this feature to make the protocol more usable. The working group will add a mode to IKEv2 or otherwise modify IKEv2 to have similar quantum resistant properties than IKEv1 had. Split-DNS is a common configuration for VPN deployments, in which only one or a few private DNS domains are accessible and resolvable via the tunnel. Adding new configuration attributes to IKEv2 for configuring Split-DNS would allow more deployments to adopt IKEv2. This configuration should also allow verification of the domains using DNSSEC. Working group will specify needed configuration attributes for IKEv2. Currently, widely used counter mode based ciphers send both the ESP sequence number and IV in form of counter, as they are very commonly the same. There has been interest to work on a document that will compress the packet and derive IV from the sequence number instead of sending it in separate field. The working group will specify how this compression can be negotiated in the IKEv2, and specify how the encryption algorithm and ESP format is used in this case. The Group Domain of Interpretation (GDOI - RFC 6407) is an IKEv1-based protocol for negotiating group keys for both multicast and unicast uses. The Working Group will develop an IKEv2-based alternative that will include cryptographic updates. A possible starting point is draft-yeung-g-ikev2 Postquantum Cryptography brings new key exchange methods. Most of these methods that are known to date have much larger public keys then conventional Diffie-Hellman public keys. Direct using these methods in IKEv2 might lead to a number of problems due to the increased size of initial IKEv2 messages. The working group will analyze the possible problems and develop a solution, that will make adding Postquantum key exchange methods more easy. The solution will allow post quantum key exchange to be performed in parallel with (or instead of) the existing Diffie-Hellman key exchange. A growing number of use cases for constraint network - but not limited to - have shown interest in reducing ESP (resp. IKEv2) overhead by compressing ESP (resp IKEv2) fields. The WG will define extensions of ESP and IKEv2 to enable ESP header compression. draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-diet-esp-extension are expected to be good starting points for ESP compression. draft-smyslov-ipsecme-ikev2-compression and draft-smyslov-ipsecme-ikev2-compact are good starting point for IKEv2 compression. RFC7427 allows peers to indicate hash algorithms they support, thus eliminating ambiguity in selecting a hash function for digital signature authentication. However, recent advances in cryptography lead to a situation when some signature algorithms have several signature formats. A prominent example is RSASSA-PKCS#1 and RSASSA-PSS, however it is envisioned that the same situation may repeat in future with other signature algorithms. Currently IKE peers have no explicit way to indicate each other which signature format(s) the support, that leads to ineroperability problems. The WG will investigate the situation and come up with a solution that allows peers to deal with the problem in an interoperable way. RFC7296 defines a generic notification code that is related to a failure to handle an internal address failure. That code does not explicitly allow an initiator to determine why a given address family is not assigned, nor whether it should try using another address family. The Working Group will specify a set of more specific notification codes that will provide sufficient information to the IKEv2 initiator about the encountered failure. draft-boucadair-ipsecme-ipv6-ipv4-codes could be used as a starting point for this item. Some systems support security labels (aka security context) as one of the selectors of the SPD. This label needs to be part of the IKE negotiation for the IPsec SA. non-standard implementations exist for IKEv1 (formerly abusing IPSEC Security Association Attribute 10, now using private space IPSEC Security Association Attribute 32001). The work is to standarize this for IKEv2, in a way that will be backwards compatible with old implementations, meaning it must not require any changes to implementations not supporting this. This charter will expire in December 2019. If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. -- kivinen@iki.fi From nobody Mon Mar 5 07:35:53 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 01FB512D86E for ; Mon, 5 Mar 2018 07:35:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkMWEN1A0mAz for ; Mon, 5 Mar 2018 07:35:50 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6B97127201 for ; Mon, 5 Mar 2018 07:35:49 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3zw3ry5wHqzDk6; Mon, 5 Mar 2018 16:35:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1520264146; bh=F/BLrqm3hp1Hi+O8hEBY+xY7IQdrTqc7zhhDncx0+90=; h=Date:From:To:cc:Subject; b=CGMyczIQ06Gbs/D0YYTcZTzMKUY7KzfVSBRG/Waj+AOgWs41RN+YdM4DOdlPOFX5+ 9mo7UB8VdmhtRtHy46eKXwryUlB0QHQde6JCUZsXNiszPRntc5Dah8mPgGjeVadezJ mP6mU25k1LydNk6lJBtipBzMi1BafWfmIr5fniro= 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 cCJkfVTIBFj8; Mon, 5 Mar 2018 16:35:44 +0100 (CET) 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, 5 Mar 2018 16:35:44 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 7BC2436671C; Mon, 5 Mar 2018 10:35:43 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 7BC2436671C Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 72C5C44DA271; Mon, 5 Mar 2018 10:35:43 -0500 (EST) Date: Mon, 5 Mar 2018 10:35:43 -0500 (EST) From: Paul Wouters To: "ipsec@ietf.org WG" cc: Sahana Prasad Message-ID: 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: [IPsec] Fwd: New Version Notification for draft-sprasad-ipsecme-labeled-ipsec-00.txt (fwd) 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, 05 Mar 2018 15:35:52 -0000 Sahana and I wrote the initial draft for Labeled IPsec. I'm not sure why it didn't auto-email the list, so links follow below. Please discuss :) Paul A new version of I-D, draft-sprasad-ipsecme-labeled-ipsec-00.txt has been successfully submitted by Sahana Prasad and posted to the IETF repository. Name: draft-sprasad-ipsecme-labeled-ipsec Revision: 00 Title: Labeled IPsec Traffic Selector support for IKEv2 Document date: 2018-03-04 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-sprasad-ipsecme-labeled-ipsec-00.txt Status: https://datatracker.ietf.org/doc/draft-sprasad-ipsecme-labeled-ipsec/ Htmlized: https://tools.ietf.org/html/draft-sprasad-ipsecme-labeled-ipsec-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-sprasad-ipsecme-labeled-ipsec-00 Abstract: Some IPsec implementations support Security Labels otherwise known as Security Contexts, to be configured as a selector within the Security Policy Database (SPD) for IPsec SAs. This document adds support to IKEv2 to negotiate these Security Labels or Contexts using a new Traffic Selector (TS) Type TS_SECLABEL. The approach is named "Labeled IPsec". It assumes that the SPD processing of RFC 4303 is already extended to support Security Labels. This document only adds the ability for IKE to negotiate the Security Labels used with the SPD. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon Mar 5 09:01: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 2434512D86D for ; Mon, 5 Mar 2018 09:01:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 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, 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 ssitm3pZm5Ee for ; Mon, 5 Mar 2018 09:01:16 -0800 (PST) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (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 B7B9C12895E for ; Mon, 5 Mar 2018 09:01:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1520269276; x=2384182876; 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=jFYn8jPD3JReT/bm+JSWT6s48sZBh+i1GDSUsIr41P4=; b=R2RxI1JsmFAUIqKfke+6E7gUN13QtCq/uiQVl26Wsv9206S1EjOPI0XjxJTnNMWo 2WAHPsTfvrd3TgdBp9roRlUuE/rmfF22NPpy+C3J5WozdPZWvPXmaSWRtoPGhy02 yaczBhU6m5RKDMzc41H3rvzj4rAeqaJqB4Vbh/ylx+YkVS/LbqzU2M7e/TaWvSwj H244WSm8Ohslx4mR9VChvUQ5ErDf3+JmyS5O2xPqRwOBfU6WQ2gyhmM17buI8Ixz gB4BY92yPBpkIdFSuAaFsd8nnKJ4J51Rm4+rrs7JXtYplkbg833um3PmFLXOZ//1 OJB9pItmP8WXUg90Syfg9Q==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id AB.6C.13823.CD77D9A5; Mon, 5 Mar 2018 09:01:16 -0800 (PST) X-AuditID: 11973e11-d4eb59e0000035ff-d7-5a9d77dc7af9 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by relay6.apple.com (Apple SCV relay) with SMTP id 86.B2.23861.CD77D9A5; Mon, 5 Mar 2018 09:01:16 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_r1HxEMwQc6gYaals3k4diA)" Received: from [17.192.155.180] (unknown [17.192.155.180]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180130 64bit (built Jan 30 2018)) with ESMTPSA id <0P5400HCTNA4PK00@nwk-mmpp-sz09.apple.com>; Mon, 05 Mar 2018 09:01:16 -0800 (PST) Sender: dschinazi@apple.com From: David Schinazi Message-id: <07092007-C0E0-4A3D-9582-23EAF2CC5EFB@apple.com> Date: Mon, 05 Mar 2018 09:01:15 -0800 In-reply-to: <23196.21671.588501.57113@fireball.acr.fi> Cc: ipsec@ietf.org To: Tero Kivinen References: <23196.21671.588501.57113@fireball.acr.fi> X-Mailer: Apple Mail (2.3445.5.20) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUi2FAYpXunfG6Uwe8V6hb7t7xgszh6/jmb A5PHkiU/mTwOf13IEsAUxWWTkpqTWZZapG+XwJVx5dQnpoK5ixgr7i+dyN7AeKGTsYuRk0NC wERi15ObzCC2kMBqJomLjVww8e5bnSxdjFxA8YOMEgsmvGQBSfAKCEr8mHwPyObgYBYIkzjX IwjRO5lJ4u9FERBbWEBaouvCXVaQEjYBLYkDa4wgOm0k/v17ygJRYiRx8NU0VhCbRUBVorHt DBuIzSlgLrHv/wkwm1lASGLhgq1gZ4oIKErsfrKVCWKVmcSnD21sEGcqSUz/fpsN5EwJgQVs Eh9Xr2KfwCg0C8mlsxAunQU2Vkvi+6NWqLC8xMHzshBhTYln9z6xQ9jaEk/eXWBdwMi2ilEo NzEzRzczz0gvsaAgJ1UvOT93EyMoDqbbCe5gPL7K6hCjAAejEg/vBo+5UUKsiWXFlbmHGKU5 WJTEebfcnBklJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgfE8R/LUycsyP53oWL0gueei+U22 X5KPprC21XMf0q4493nmqrCz15unRLsfmVtodpxpp9q701O8vy3s546ZdNNrcjuP8Ywagd9T youOyEyI8/OLyQoK3sGyjyH+0mcL7g5fyxUhL+Q5axn/Mnq5rDDmMHz358td8ZXh/iXegXUT jwkwKXfrhymxFGckGmoxFxUnAgBpJ45eZAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKLMWRmVeSWpSXmKPExsUi2FAcoHunfG6UQes9ZYv9W16wWRw9/5zN gcljyZKfTB6Hvy5kCWCK4rJJSc3JLEst0rdL4Mq4cuoTU8HcRYwV95dOZG9gvNDJ2MXIySEh YCLRfauTpYuRi0NI4CCjxIIJL1lAErwCghI/Jt8Dsjk4mAXCJM71CIKEhQQmM0n8vSgCYgsL SEt0XbjLClLCJqAlcWCNEUSnjcS/f09ZIEqMJA6+msYKYrMIqEo0tp1hA7E5Bcwl9v0/AWYz CwhJLFywFewcEQFFid1PtjJBrDKT+PShjQ3iTCWJ6d9vs01g5J+F5LhZCMfNApukJfH9UStU WF7i4HlZiLCmxLN7n9ghbG2JJ+8usC5gZFvFKFCUmpNYaaaXWFCQk6qXnJ+7iREcuIVROxgb llsdYhTgYFTi4d3gMTdKiDWxrLgy9xCjBAezkghvXSRQiDclsbIqtSg/vqg0J7X4EKM0B4uS OG/zz5lRQgLpiSWp2ampBalFMFkmDk6pBkb3KZGCzf5S/kqLl23gXrjpz+SZnl43d+yZk3f+ +0+GTMEp+w/4TuY1ySjvO13/tNo6bi6zt1YB67IAkVv353ip5SwJeeeV9ZGjvTQ23/hLX8Vx 29ZnGdPWPf54dnOBVexLceVDmTeEnuWJST3suvq+dvbdvbwN0XWqPfUC5ZU6op8M65lOnlRi Kc5INNRiLipOBABfCeaCWAIAAA== Archived-At: Subject: Re: [IPsec] Summary of charter discussion 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, 05 Mar 2018 17:01:20 -0000 --Boundary_(ID_r1HxEMwQc6gYaals3k4diA) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hello Tero, Regarding charter item 4 (mitigating privacy concerns), I have submitted the following draft: https://tools.ietf.org/html/draft-dschinazi-ipsecme-sa-init-privacy-addition I'd like to discuss the problem statement and potential solution in London. I would personally recommend not deciding on its addition to the charter until this has been discussed. Thanks, David Schinazi > On Mar 4, 2018, at 12:18, Tero Kivinen wrote: > > There was very little discussion about the "ready" parts of the > charter (one comment from Wouters, but no new text or explination why > "mesh" is different than host-to-host. > > Additional items: > > > Item 1 responder MOBIKE > > We had some discussion already on the list, and several people > commented (Paul Wouters, Hu Jun) that they do want to have > more discussion about the goal before going to the the > solutions. I also think that the item is not well enough > explained in the charter that we can work on it, so perhaps we > leave this out for now and continue discussion in the list and > in the next meeting about what we really want. > > Item 2 Address Failure Errors > > We got some support (Michael Richardson), and Paul Wouters > wanted to have more discussion about this. I myself think this > is clear enough and we can add it to the charter. > > Item 3 Labeled IPsec > > We had concerns (Yoav Nir, Valery Smyslov) that this should > not affect implementations which do not implement this, so I > think the charter item should be modified to explictly say so. > I.e., add text which says there will not be any need to change > old implementations. > > Item 4 Mitigating privacy concerns > > We had very little support for this and some concerns about > this getting in the arms race with goverments etc. I myself do > not think this item is ready yet to be taken as charter item, > we need research on this before we can actually start working > on the protocol changes. > > ---------------------------------------------------------------------- > > This means the final proposed chater would be: > > ---------------------------------------------------------------------- > > The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated > RFCs, IKEv1 is now obsoleted), IKEv2 (RFC 7296), and the IPsec > security architecture (RFC 4301). IPsec is widely deployed in VPN > gateways, VPN remote access clients, and as a substrate for > host-to-host, host-to-network, and network-to-network security. > > The IPsec Maintenance and Extensions Working Group continues the work > of the earlier IPsec Working Group which was concluded in 2005. Its > purpose is to maintain the IPsec standard and to facilitate discussion > of clarifications, improvements, and extensions to IPsec, mostly to > ESP and IKEv2. The working group also serves as a focus point for > other IETF Working Groups who use IPsec in their own protocols. > > The current work items include: > > IKEv1 using shared secret authentication was partially resistant to > quantum computers. IKEv2 removed this feature to make the protocol > more usable. The working group will add a mode to IKEv2 or otherwise > modify IKEv2 to have similar quantum resistant properties than IKEv1 > had. > > Split-DNS is a common configuration for VPN deployments, in which only > one or a few private DNS domains are accessible and resolvable via the > tunnel. Adding new configuration attributes to IKEv2 for configuring > Split-DNS would allow more deployments to adopt IKEv2. This > configuration should also allow verification of the domains using > DNSSEC. Working group will specify needed configuration attributes for > IKEv2. > > Currently, widely used counter mode based ciphers send both the ESP > sequence number and IV in form of counter, as they are very commonly > the same. There has been interest to work on a document that will > compress the packet and derive IV from the sequence number instead of > sending it in separate field. The working group will specify how this > compression can be negotiated in the IKEv2, and specify how the > encryption algorithm and ESP format is used in this case. > > The Group Domain of Interpretation (GDOI - RFC 6407) is an IKEv1-based > protocol for negotiating group keys for both multicast and unicast > uses. The Working Group will develop an IKEv2-based alternative that > will include cryptographic updates. A possible starting point is > draft-yeung-g-ikev2 > > Postquantum Cryptography brings new key exchange methods. Most of > these methods that are known to date have much larger public keys then > conventional Diffie-Hellman public keys. Direct using these methods in > IKEv2 might lead to a number of problems due to the increased size of > initial IKEv2 messages. The working group will analyze the possible > problems and develop a solution, that will make adding Postquantum key > exchange methods more easy. The solution will allow post quantum key > exchange to be performed in parallel with (or instead of) the existing > Diffie-Hellman key exchange. > > A growing number of use cases for constraint network - but not limited > to - have shown interest in reducing ESP (resp. IKEv2) overhead by > compressing ESP (resp IKEv2) fields. The WG will define extensions of > ESP and IKEv2 to enable ESP header compression. > > draft-mglt-ipsecme-diet-esp and > draft-mglt-ipsecme-ikev2-diet-esp-extension are expected to be good > starting points for ESP compression. > draft-smyslov-ipsecme-ikev2-compression and > draft-smyslov-ipsecme-ikev2-compact are good starting point for IKEv2 > compression. > > RFC7427 allows peers to indicate hash algorithms they support, thus > eliminating ambiguity in selecting a hash function for digital > signature authentication. However, recent advances in cryptography > lead to a situation when some signature algorithms have several > signature formats. A prominent example is RSASSA-PKCS#1 and > RSASSA-PSS, however it is envisioned that the same situation may > repeat in future with other signature algorithms. Currently IKE peers > have no explicit way to indicate each other which signature format(s) > the support, that leads to ineroperability problems. The WG will > investigate the situation and come up with a solution that allows > peers to deal with the problem in an interoperable way. > > RFC7296 defines a generic notification code that is related to a > failure to handle an internal address failure. That code does not > explicitly allow an initiator to determine why a given address family > is not assigned, nor whether it should try using another address > family. The Working Group will specify a set of more specific > notification codes that will provide sufficient information to the > IKEv2 initiator about the encountered failure. > draft-boucadair-ipsecme-ipv6-ipv4-codes could be used as a starting > point for this item. > > Some systems support security labels (aka security context) as one of > the selectors of the SPD. This label needs to be part of the IKE > negotiation for the IPsec SA. non-standard implementations exist for > IKEv1 (formerly abusing IPSEC Security Association Attribute 10, now > using private space IPSEC Security Association Attribute 32001). The > work is to standarize this for IKEv2, in a way that will be backwards > compatible with old implementations, meaning it must not require any > changes to implementations not supporting this. > > This charter will expire in December 2019. If the charter is not > updated before that time, the WG will be closed and any remaining > documents revert back to individual Internet-Drafts. > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Boundary_(ID_r1HxEMwQc6gYaals3k4diA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Hello= Tero,

Regarding = charter item 4 (mitigating privacy concerns), I have submitted the = following draft:

https://tools.ietf.org/html/draft-dschinazi-ipsecme-sa-init-pri= vacy-addition

I'd like to discuss the problem statement and potential = solution in London.
I would personally recommend = not deciding on its addition to the charter until this has been = discussed.

Thanks,
David Schinazi


On Mar 4, 2018, at 12:18, Tero Kivinen <kivinen@iki.fi> = wrote:

There was very little discussion about the "ready" parts of = the
charter (one comment from Wouters, but no new text or = explination why
"mesh" is different than host-to-host.

Additional items:


Item 1 responder MOBIKE

= We had some discussion already on the list, and several people
= commented (Paul Wouters, Hu Jun) that they do want to have
= more discussion about the goal before going to the the
= solutions. I also think that the item is not well enough
= explained in the charter that we can work on it, so perhaps we
= leave this out for now and continue discussion in the list and
= in the next meeting about what we really want.

Item 2 Address Failure Errors

= We got some support (Michael Richardson), and Paul Wouters
= wanted to have more discussion about this. I myself think this
= is clear enough and we can add it to the charter.
Item 3 Labeled IPsec

We had = concerns (Yoav Nir, Valery Smyslov) that this should
not = affect implementations which do not implement this, so I
= think the charter item should be modified to explictly say so.
= I.e., add text which says there will not be any need to change
= old implementations.

Item 4 = Mitigating privacy concerns

We had = very little support for this and some concerns about
this = getting in the arms race with goverments etc. I myself do
= not think this item is ready yet to be taken as charter item,
= we need research on this before we can actually start working
= on the protocol changes.

---------------------------------------------------------------= -------

This means the final proposed = chater would be:

---------------------------------------------------------------= -------

The IPsec suite of protocols = includes IKEv1 (RFC 2409 and associated
RFCs, IKEv1 is now = obsoleted), IKEv2 (RFC 7296), and the IPsec
security = architecture (RFC 4301). IPsec is widely deployed in VPN
gateways, VPN remote access clients, and as a substrate = for
host-to-host, host-to-network, and network-to-network = security.

The IPsec Maintenance and = Extensions Working Group continues the work
of the earlier = IPsec Working Group which was concluded in 2005. Its
purpose= is to maintain the IPsec standard and to facilitate discussion
of clarifications, improvements, and extensions to IPsec, = mostly to
ESP and IKEv2. The working group also serves as = a focus point for
other IETF Working Groups who use IPsec = in their own protocols.

The current work = items include:

IKEv1 using shared secret = authentication was partially resistant to
quantum = computers. IKEv2 removed this feature to make the protocol
more usable. The working group will add a mode to IKEv2 or = otherwise
modify IKEv2 to have similar quantum resistant = properties than IKEv1
had.

Split-DNS is a common configuration for VPN deployments, in = which only
one or a few private DNS domains are accessible = and resolvable via the
tunnel. Adding new configuration = attributes to IKEv2 for configuring
Split-DNS would allow = more deployments to adopt IKEv2. This
configuration should = also allow verification of the domains using
DNSSEC. = Working group will specify needed configuration attributes for
IKEv2.

Currently, widely used = counter mode based ciphers send both the ESP
sequence = number and IV in form of counter, as they are very commonly
the same. There has been interest to work on a document that = will
compress the packet and derive IV from the sequence = number instead of
sending it in separate field. The = working group will specify how this
compression can be = negotiated in the IKEv2, and specify how the
encryption = algorithm and ESP format is used in this case.

The Group Domain of Interpretation (GDOI - RFC 6407) is an = IKEv1-based
protocol for negotiating group keys for both = multicast and unicast
uses. The Working Group will develop = an IKEv2-based alternative that
will include cryptographic = updates. A possible starting point is
draft-yeung-g-ikev2
Postquantum Cryptography brings new key = exchange methods. Most of
these methods that are known to = date have much larger public keys then
conventional = Diffie-Hellman public keys. Direct using these methods in
IKEv2 might lead to a number of problems due to the increased = size of
initial IKEv2 messages. The working group will = analyze the possible
problems and develop a solution, that = will make adding Postquantum key
exchange methods more = easy. The solution will allow post quantum key
exchange to = be performed in parallel with (or instead of) the existing
Diffie-Hellman key exchange.

A = growing number of use cases for constraint network - but not limited
to - have shown interest in reducing ESP (resp. IKEv2) = overhead by
compressing ESP (resp IKEv2) fields. The WG = will define extensions of
ESP and IKEv2 to enable ESP = header compression.

draft-mglt-ipsecme-diet-esp and
draft-mglt-ipsecme-ikev2-diet-esp-extension are expected to = be good
starting points for ESP compression.
draft-smyslov-ipsecme-ikev2-compression and
draft-smyslov-ipsecme-ikev2-compact are good starting point = for IKEv2
compression.

RFC7427 = allows peers to indicate hash algorithms they support, thus
eliminating ambiguity in selecting a hash function for = digital
signature authentication. However, recent advances = in cryptography
lead to a situation when some signature = algorithms have several
signature formats. A prominent = example is RSASSA-PKCS#1 and
RSASSA-PSS, however it is = envisioned that the same situation may
repeat in future = with other signature algorithms. Currently IKE peers
have = no explicit way to indicate each other which signature format(s)
the support, that leads to ineroperability problems. The WG = will
investigate the situation and come up with a solution = that allows
peers to deal with the problem in an = interoperable way.

RFC7296 defines a = generic notification code that is related to a
failure to = handle an internal address failure. That code does not
explicitly allow an initiator to determine why a given = address family
is not assigned, nor whether it should try = using another address
family. The Working Group will = specify a set of more specific
notification codes that = will provide sufficient information to the
IKEv2 initiator = about the encountered failure.
draft-boucadair-ipsecme-ipv6-ipv4-codes could be used as a = starting
point for this item.

Some systems support security labels (aka security context) = as one of
the selectors of the SPD. This label needs to be = part of the IKE
negotiation for the IPsec SA. non-standard = implementations exist for
IKEv1 (formerly abusing IPSEC = Security Association Attribute 10, now
using private space = IPSEC Security Association Attribute 32001). The
work is = to standarize this for IKEv2, in a way that will be backwards
compatible with old implementations, meaning it must not = require any
changes to implementations not supporting = this.

This charter will expire in December = 2019. If the charter is not
updated before that time, the = WG will be closed and any remaining
documents revert back = to individual Internet-Drafts.
--
kivinen@iki.fi

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

= --Boundary_(ID_r1HxEMwQc6gYaals3k4diA)-- From nobody Tue Mar 6 15:52:17 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 958CE12741D for ; Tue, 6 Mar 2018 15:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUPucv4Ug-KZ for ; Tue, 6 Mar 2018 15:52:13 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30118.outbound.protection.outlook.com [40.107.3.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9BCF1200FC for ; Tue, 6 Mar 2018 15:52:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ejw+U0p9tT65sk2yH7vHDs96Y1v1lln/+cpJ9yVGoNs=; b=ixu5+pkKLVUTOe9qsoeH6kqw8onL6va7pflUZszxevLoXGb7M561ti6z3HHEy/Umbhg1htEn6Bhsl4IB+Y8pzexy6XtRom3xDMK902SHNncVu6hXsI/lulyYpwTvpNBQj66VBT74r5mcTYW+w0jz++i1+MQL08Vac7mWPsHAPg0= Received: from AM4PR07MB3153.eurprd07.prod.outlook.com (10.171.188.142) by AM4PR07MB1601.eurprd07.prod.outlook.com (10.166.132.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.567.6; Tue, 6 Mar 2018 23:52:08 +0000 Received: from AM4PR07MB3153.eurprd07.prod.outlook.com ([fe80::296d:e6a1:bfb4:33e1]) by AM4PR07MB3153.eurprd07.prod.outlook.com ([fe80::296d:e6a1:bfb4:33e1%4]) with mapi id 15.20.0567.011; Tue, 6 Mar 2018 23:52:08 +0000 From: "Hu, Jun (Nokia - US/Mountain View)" To: Paul Wouters , "ipsec@ietf.org WG" CC: Sahana Prasad Thread-Topic: [IPsec] Fwd: New Version Notification for draft-sprasad-ipsecme-labeled-ipsec-00.txt (fwd) Thread-Index: AQHTtJeqhTVG2/q3s0KFzP/xTL/aWKPD2oug Date: Tue, 6 Mar 2018 23:52:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.245.20.4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR07MB1601; 6:9nTY+xBchFSA5Dnw3Lt6o3a+8Cekc3/viKf0BXvCXE5gt3B8zgQFKO7MPTWQ/oLg46jrE4+mZvjNfeykyecRzCeRQP89bUtuRAuZs1r9LpLt6Bg31DJvLmXoviP0JMJlGyViMqKHVma/3Fq9S4iMoywCjvxVH8A34CgaPt8fr58owPe/jzOLaUuQcQU+G6a5udQXRATyzhE9l0gryB02Ppkav/nbLCxvX3mH+W7CvxI/CHrTvM8IGTpnOljO8iGgFyIOvFuZRT3tLEmK1dJC+hdacBwkuiTJ7Uc5JQncmVUzQ5cZ1HW8VveQqvh7eM/imUp62cBgaX0QJxm5TQherzdW1i/y9zk0F75WMmSYHt4ZMYOxUBxHb0zHQcNm8g6p; 5:DJnBurkSWuvTT1uri0asUf32qN1EZkyjagOu5sVRG3x3WkPOZOapeJrQLwkPEv9O8Ann796qW6KcKiYrWXPEV/1MQ9c0xG2mN6QytleqZyOsW1ce01GlN0JaTS/NkfwhDbb74AIqdpv/nx/jJckrf6sOTOZSbdkNgvsHS7uli3M=; 24:1ckQLqub1ReqNeI0xidQISgeANmbBt54T5Ee44/bXKUZ6urAy9/lwhH7X2OyEwKaHiz5IUf/iA6AXl8LSPcUXpZ3N7Ggh2emg0W+aAmPYOI=; 7:AkiGet0g6jhyBLAGDf29ShvpE1A8eYVR+Gm0nYEmseeYe2RzxecKnTV3Ghe8uJcJyNJdItjh0/s9emBNb4cxyFWtWsD4N81a/D1lOHSGN4N5driHU9bcMaZbhROHtXPKr3LExC1mm4hpw53GIuC1B83ZMvut/YLUUNbGCGlLotC8jQiWD+42I8HNnyrBnMLHp1m6l8TZLHTCEMQhTWApZhWbIbxDh3z2WmU5hv1JYZ6sfemRI2l0qjw8T/4tTg4+ x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 7a695863-9a7f-4514-cbef-08d583bd4609 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:AM4PR07MB1601; x-ms-traffictypediagnostic: AM4PR07MB1601: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jun.hu@nokia.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705)(85827821059158); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(3231220)(11241501184)(806099)(944501244)(52105095)(10201501046)(93006095)(93001095)(6055026)(6041288)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:AM4PR07MB1601; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB1601; x-forefront-prvs: 06036BD506 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(39380400002)(39860400002)(376002)(366004)(377424004)(13464003)(199004)(189003)(5250100002)(229853002)(2906002)(97736004)(8936002)(478600001)(6306002)(55016002)(8676002)(81156014)(2950100002)(76176011)(66066001)(5660300001)(6436002)(106356001)(26005)(81166006)(966005)(86362001)(186003)(53546011)(6506007)(316002)(59450400001)(102836004)(39060400002)(7736002)(33656002)(6116002)(3846002)(99286004)(6246003)(53936002)(14454004)(25786009)(7696005)(9686003)(74316002)(3280700002)(105586002)(4326008)(110136005)(15650500001)(68736007)(2900100001)(3660700001)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB1601; H:AM4PR07MB3153.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: OhZqPXz9QQdi7HSmYQyTGYgKwjOZtAAni0tC5CTAkmDpVE2mwB0h81LkmmPLn0pHY/wbic5u5Ff4md3QOWbDcxCWWF0yLdD8hlh3C2TFvaj1/eJzj5muGT1KdHi01OIDYHXZWqIXYdcyyVTRLxd0VJly66Wtp47K+QDMJqn4skEax18blFdr6hY5gYOvz1kWVXPTdHJZW3okiNyf/+0sTEzNbMa2f/7YNO96xbbqiLMnXMN7lXxmitorgeSX9wfUJIWNXCfIne62IXixGO+cGfnPuiq7ILiAcp9iOdyjkoG28aakmHVOBWh2Cs9OkjpWVdHbjZehsAIzHD7lakmo0dKuKRoY/1gSsXbznvRx4xk+q9cS11wPUMyaKg0LAwLd spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7a695863-9a7f-4514-cbef-08d583bd4609 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2018 23:52:08.9127 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1601 Archived-At: Subject: Re: [IPsec] Fwd: New Version Notification for draft-sprasad-ipsecme-labeled-ipsec-00.txt (fwd) 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, 06 Mar 2018 23:52:16 -0000 U29tZSBpbml0aWFsIHF1ZXN0aW9ucy9jb21tZW50czoNCjEuIHNlY3VyaXR5IGxhYmVsIGlzIGRl ZmluZWQgYXMgb3BhcXVlIGRhdGEgaW4gdGhlIGRyYWZ0LCBidXQgdGhlbiBob3cgd291bGQgbmFy cm93aW5nIHdvcmsgaW4gYW4gaW50ZXItb3Agd2F5IHdpdGggb3BhcXVlIGRhdGE/IE9yIHNob3Vs ZCB3ZSBkZWZpbmUgdGhlIGZvcm1hdCBmb3Igc29tZSBjb21tb24gdXNlIGNhc2VzIChsaWtlIHNl Y3VyaXR5IGVuZm9yY2VtZW50LCBRb1MgLi4uKSAsIGFuZCBhZGRpbmcgYSBzdWItdHlwZSBpbiBU U19TRUNMQUJFTA0KMi4gY3VycmVudGx5IHRoZXJlIGFyZSBUU2kgKDQ0KSBhbmQgVFNyICg0NSkg cGF5bG9hZCwgZG9lcyBpdCBtYWtlIHNlbnNlIHRvIGluY2x1ZGUgVFNfU0VDTEFCRUwgaW4gZWl0 aGVyIFRTaSBvciBUU3I/IElzIHRoZXJlIHNlbWFudGljIHRvIGhhdmUgc2VwYXJhdGUgImluaXRp YXRvciBTRUNMQUJFTCIgYW5kICJyZXNwb25kZXIgU0VDTEFCRUwiPyBPciBkb2VzIGl0IG1ha2Ug bW9yZSBzZW5zZSB0byBvbmx5IGFsbG93IHNpbmdsZSBUU19TRUNMQUJFTCBwZXIgbWVzc2FnZS9D SElMRF9TQSwgYW5kIGNyZWF0ZSBhIG5ldyBUUyBwYXlsb2FkIHR5cGUgLCBwdXQgVFNfU0VDTEFC RUwgaW4gaXQgPw0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSVBz ZWMgW21haWx0bzppcHNlYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUGF1bCBXb3V0 ZXJzDQo+IFNlbnQ6IE1vbmRheSwgTWFyY2ggMDUsIDIwMTggNzozNiBBTQ0KPiBUbzogaXBzZWNA aWV0Zi5vcmcgV0cgPGlwc2VjQGlldGYub3JnPg0KPiBDYzogU2FoYW5hIFByYXNhZCA8c2FoYW5h LnByYXNhZDA3QGdtYWlsLmNvbT4NCj4gU3ViamVjdDogW0lQc2VjXSBGd2Q6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc3ByYXNhZC1pcHNlY21lLQ0KPiBsYWJlbGVkLWlwc2Vj LTAwLnR4dCAoZndkKQ0KPiANCj4gDQo+IA0KPiBTYWhhbmEgYW5kIEkgd3JvdGUgdGhlIGluaXRp YWwgZHJhZnQgZm9yIExhYmVsZWQgSVBzZWMuIEknbSBub3Qgc3VyZSB3aHkgaXQgZGlkbid0DQo+ IGF1dG8tZW1haWwgdGhlIGxpc3QsIHNvIGxpbmtzIGZvbGxvdyBiZWxvdy4gUGxlYXNlIGRpc2N1 c3MgOikNCj4gDQo+IFBhdWwNCj4gDQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1zcHJh c2FkLWlwc2VjbWUtbGFiZWxlZC1pcHNlYy0wMC50eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5 IHN1Ym1pdHRlZCBieSBTYWhhbmEgUHJhc2FkIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYNCj4gcmVw b3NpdG9yeS4NCj4gDQo+IE5hbWU6CQlkcmFmdC1zcHJhc2FkLWlwc2VjbWUtbGFiZWxlZC1pcHNl Yw0KPiBSZXZpc2lvbjoJMDANCj4gVGl0bGU6CQlMYWJlbGVkIElQc2VjIFRyYWZmaWMgU2VsZWN0 b3Igc3VwcG9ydCBmb3IgSUtFdjINCj4gRG9jdW1lbnQgZGF0ZToJMjAxOC0wMy0wNA0KPiBHcm91 cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiBQYWdlczoJCTYNCj4gVVJMOiAgICAgICAgICAg IGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1zcHJhc2FkLWlwc2Vj bWUtDQo+IGxhYmVsZWQtaXBzZWMtMDAudHh0DQo+IFN0YXR1czogICAgICAgICBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zcHJhc2FkLWlwc2VjbWUtbGFiZWxlZC0NCj4g aXBzZWMvDQo+IEh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtc3ByYXNhZC1pcHNlY21lLWxhYmVsZWQtDQo+IGlwc2VjLTAwDQo+IEh0bWxpemVkOiAgICAg ICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXNwcmFzYWQtaXBz ZWNtZS0NCj4gbGFiZWxlZC1pcHNlYy0wMA0KPiANCj4gDQo+IEFic3RyYWN0Og0KPiAgICAgU29t ZSBJUHNlYyBpbXBsZW1lbnRhdGlvbnMgc3VwcG9ydCBTZWN1cml0eSBMYWJlbHMgb3RoZXJ3aXNl IGtub3duIGFzDQo+ICAgICBTZWN1cml0eSBDb250ZXh0cywgdG8gYmUgY29uZmlndXJlZCBhcyBh IHNlbGVjdG9yIHdpdGhpbiB0aGUgU2VjdXJpdHkNCj4gICAgIFBvbGljeSBEYXRhYmFzZSAoU1BE KSBmb3IgSVBzZWMgU0FzLiAgVGhpcyBkb2N1bWVudCBhZGRzIHN1cHBvcnQgdG8NCj4gICAgIElL RXYyIHRvIG5lZ290aWF0ZSB0aGVzZSBTZWN1cml0eSBMYWJlbHMgb3IgQ29udGV4dHMgdXNpbmcg YSBuZXcNCj4gICAgIFRyYWZmaWMgU2VsZWN0b3IgKFRTKSBUeXBlIFRTX1NFQ0xBQkVMLiAgVGhl IGFwcHJvYWNoIGlzIG5hbWVkDQo+ICAgICAiTGFiZWxlZCBJUHNlYyIuICBJdCBhc3N1bWVzIHRo YXQgdGhlIFNQRCBwcm9jZXNzaW5nIG9mIFJGQyA0MzAzIGlzDQo+ICAgICBhbHJlYWR5IGV4dGVu ZGVkIHRvIHN1cHBvcnQgU2VjdXJpdHkgTGFiZWxzLiAgVGhpcyBkb2N1bWVudCBvbmx5IGFkZHMN Cj4gICAgIHRoZSBhYmlsaXR5IGZvciBJS0UgdG8gbmVnb3RpYXRlIHRoZSBTZWN1cml0eSBMYWJl bHMgdXNlZCB3aXRoIHRoZQ0KPiAgICAgU1BELg0KPiANCj4gDQo+IA0KPiBQbGVhc2Ugbm90ZSB0 aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJt aXNzaW9uDQo+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFi bGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPiANCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gSVBzZWMg bWFpbGluZyBsaXN0DQo+IElQc2VjQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaXBzZWMNCg== From nobody Tue Mar 6 17:53:09 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 BBA1D12E036 for ; Tue, 6 Mar 2018 17:53:04 -0800 (PST) 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 SFK7ifujlvKc for ; Tue, 6 Mar 2018 17:53:03 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6DD4129C6C for ; Tue, 6 Mar 2018 17:53:02 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3zwxVh0KX9z4Kc; Wed, 7 Mar 2018 02:53:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1520387580; bh=tlQ040bZqpH59ISWoVe+84g29xhUcDjDUPtHQUucY30=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=EuXX9RNcb5+i654r1niYcvWsyN7gwO48h49r+wCPxF2iuaKc7BQtgn+LyeePQuXyP dHSI3Xgw12ZFV8HDTJJI061qZvKa+V2qDiGgF+myTsEJoYbfE0r/KQ09RfurLvhQZ2 ob/wP1/sZWOIwkBg3pWyZgAflxqWJYs/BctnrocM= 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 I4ZgkrMtyJsM; Wed, 7 Mar 2018 02:52:57 +0100 (CET) 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; Wed, 7 Mar 2018 02:52:56 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 05AF7395AB6; Tue, 6 Mar 2018 20:52:55 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 05AF7395AB6 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id EFF7E4023303; Tue, 6 Mar 2018 20:52:55 -0500 (EST) Date: Tue, 6 Mar 2018 20:52:55 -0500 (EST) From: Paul Wouters To: "Hu, Jun (Nokia - US/Mountain View)" cc: "ipsec@ietf.org WG" , Sahana Prasad In-Reply-To: Message-ID: References: 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] Fwd: New Version Notification for draft-sprasad-ipsecme-labeled-ipsec-00.txt (fwd) 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, 07 Mar 2018 01:53:08 -0000 On Tue, 6 Mar 2018, Hu, Jun (Nokia - US/Mountain View) wrote: > Some initial questions/comments: > 1. security label is defined as opaque data in the draft, but then how would narrowing work in an inter-op way with opaque data? Or should we define the format for some common use cases (like security enforcement, QoS ...) , and adding a sub-type in TS_SECLABEL The idea was that people should be able to define this outside of IKE as they wish. And IKE just transports the label as-is. Of course, if IKE can interpret it to do something, then it can possibly do more, like narrowing. I think usually the two endpoints will only have one type of SECLABEL, so the type is implicit to the IKE protocol. If you have different subtypes, then presumably if the subtype is wrong, you can't accept it, so the type is already known on both ends and doesn't need to have its own registry? > 2. currently there are TSi (44) and TSr (45) payload, does it make sense to include TS_SECLABEL in either TSi or TSr? Is there semantic to have separate "initiator SECLABEL" and "responder SECLABEL"? Or does it make more sense to only allow single TS_SECLABEL per message/CHILD_SA, and create a new TS payload type , put TS_SECLABEL in it ? That would be giving it another Payload Type. I think it is really a traffic selector type payload, and not a non-traffic-selector payload. Even if it is true that the label on both ends have to always match. But that's kind of similar to address family always needing to match. Although there might be a case where one end is allowed to send traffic with SECLABEL Foo, but not allowed to receive traffic with that label, where TSi could contain a TS_SECLABEL entry, and TSr would not. Another case that probably needs some attention is when there is more then one TS_SECLABEL. Does it mean two different types of security labels are meant, and both have to match? Or is it okay to pick any one of the labels? Paul From nobody Tue Mar 6 20:19: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 54858126DED for ; Tue, 6 Mar 2018 20:19:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLPXLbwyLOoi for ; Tue, 6 Mar 2018 20:19:03 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0132.outbound.protection.outlook.com [104.47.0.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF2C3126DD9 for ; Tue, 6 Mar 2018 20:19:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CKPQHqUBuSBgXNh/aDJq6vUgRYoJivJFoJgEANocUkc=; b=aaV59qkkWQYElX8mK+7e+ItpRlULgjzDp0w43/mcuyo4jaPJ0KPOg75W2DEumhksLoy7nl07zzXOYu/vy7pXnllRrq6XjRsfEtHZyABcB9jFkDw1z8IupSRYcf+E30WLcThoyE/AX+VyN6jS59wVGva2MRgg0dcdbGzct0zEIVE= Received: from AM4PR07MB3153.eurprd07.prod.outlook.com (10.171.188.142) by AM4PR07MB3298.eurprd07.prod.outlook.com (10.171.189.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.567.6; Wed, 7 Mar 2018 04:19:00 +0000 Received: from AM4PR07MB3153.eurprd07.prod.outlook.com ([fe80::296d:e6a1:bfb4:33e1]) by AM4PR07MB3153.eurprd07.prod.outlook.com ([fe80::296d:e6a1:bfb4:33e1%4]) with mapi id 15.20.0567.011; Wed, 7 Mar 2018 04:19:00 +0000 From: "Hu, Jun (Nokia - US/Mountain View)" To: Paul Wouters CC: "ipsec@ietf.org WG" , Sahana Prasad Thread-Topic: [IPsec] Fwd: New Version Notification for draft-sprasad-ipsecme-labeled-ipsec-00.txt (fwd) Thread-Index: AQHTtJeqhTVG2/q3s0KFzP/xTL/aWKPD2ouggAAqSoCAACVpAA== Date: Wed, 7 Mar 2018 04:19:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2601:646:8780:b0d4:c02f:3267:16e2:a8ce] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR07MB3298; 7:inTGBg8xihCNeZXjmi4tjdKKsGUlWTn9BS426NhZCFjWMe9c6JM6PCbkzmvvqUrhy1KpY07TQMESlh0g2CfNSDBAFJ5P8TJmXbJt8NjOni0+0TQL2CO4MCCdDPiTdb8FzJGyRBhtNFev2hLNzH2He2lyu4Iq2xPzHlXpYcKlSKH94aLFpgRoP3J+mum77EkF+vEhK/HhMXuLPUrnyvXTxzyM/0pMTidR2PFtin1OcEMgkDeW/8tP74KpASe6G6TC x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 3a851189-e5fc-4ac8-ea30-08d583e28d8f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:AM4PR07MB3298; x-ms-traffictypediagnostic: AM4PR07MB3298: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(82608151540597)(85827821059158); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231220)(11241501184)(806099)(944501244)(52105095)(3002001)(6055026)(6041288)(20161123564045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:AM4PR07MB3298; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB3298; x-forefront-prvs: 0604AFA86B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(39380400002)(346002)(376002)(366004)(13464003)(199004)(189003)(305945005)(74316002)(25786009)(39060400002)(229853002)(2950100002)(15650500001)(8936002)(5250100002)(97736004)(5660300001)(105586002)(81166006)(6346003)(106356001)(59450400001)(8676002)(6916009)(81156014)(14454004)(54906003)(186003)(4326008)(6506007)(2900100001)(102836004)(53546011)(6116002)(6436002)(3280700002)(76176011)(7696005)(316002)(68736007)(46003)(53936002)(7736002)(6246003)(86362001)(9686003)(3660700001)(478600001)(55016002)(99286004)(2906002)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB3298; H:AM4PR07MB3153.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=jun.hu@nokia.com; x-microsoft-antispam-message-info: EwpJFtfrBy/nHSfDT2LoPmqjG4Ju6WkOErZCec9fGIinjol7rAdBXpyzGiWQRyTUG9rLeMVhHXtbJ3tcvQxnq2em/mA5Bf/KhTzSnioP4zsOcJRLPWJBI1NANjSQ/7rMI0z2hpsc9Mu9vV/3wFQzONHjv9/u3+QaRIjxGY3oSNKfQ7h62OmCtM+NFOfomPpoC55AEh5HUp9W7ikMKSp5foLLZ8iWVZDfvuXefwlaVcl9nH7Ka5zYfOvoEMPmTcvVqr+ebdaVDTBIxepgfVtsl/BF2iPTqM1UDKqgjJgiYAQu5efn+PZyubkMK+bcE6+CtTuk2GELUj5+kVXEc7HeEUA/dOkQBSBjcOc0KiJ6ZznInRNKK3XKtmmsweSK0b3f spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3a851189-e5fc-4ac8-ea30-08d583e28d8f X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Mar 2018 04:19:00.2089 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3298 Archived-At: Subject: Re: [IPsec] Fwd: New Version Notification for draft-sprasad-ipsecme-labeled-ipsec-00.txt (fwd) 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, 07 Mar 2018 04:19:05 -0000 DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFBhdWwgV291dGVycyBbbWFp bHRvOnBhdWxAbm9oYXRzLmNhXQ0KPiBTZW50OiBUdWVzZGF5LCBNYXJjaCAwNiwgMjAxOCA1OjUz IFBNDQo+IFRvOiBIdSwgSnVuIChOb2tpYSAtIFVTL01vdW50YWluIFZpZXcpIDxqdW4uaHVAbm9r aWEuY29tPg0KPiBDYzogaXBzZWNAaWV0Zi5vcmcgV0cgPGlwc2VjQGlldGYub3JnPjsgU2FoYW5h IFByYXNhZA0KPiA8c2FoYW5hLnByYXNhZDA3QGdtYWlsLmNvbT4NCj4gU3ViamVjdDogUkU6IFtJ UHNlY10gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNwcmFzYWQtaXBz ZWNtZS0NCj4gbGFiZWxlZC1pcHNlYy0wMC50eHQgKGZ3ZCkNCj4gDQo+IE9uIFR1ZSwgNiBNYXIg MjAxOCwgSHUsIEp1biAoTm9raWEgLSBVUy9Nb3VudGFpbiBWaWV3KSB3cm90ZToNCj4gDQo+ID4g U29tZSBpbml0aWFsIHF1ZXN0aW9ucy9jb21tZW50czoNCj4gPiAxLiBzZWN1cml0eSBsYWJlbCBp cyBkZWZpbmVkIGFzIG9wYXF1ZSBkYXRhIGluIHRoZSBkcmFmdCwgYnV0IHRoZW4gaG93DQo+ID4g d291bGQgbmFycm93aW5nIHdvcmsgaW4gYW4gaW50ZXItb3Agd2F5IHdpdGggb3BhcXVlIGRhdGE/ IE9yIHNob3VsZCB3ZQ0KPiA+IGRlZmluZSB0aGUgZm9ybWF0IGZvciBzb21lIGNvbW1vbiB1c2Ug Y2FzZXMgKGxpa2Ugc2VjdXJpdHkNCj4gPiBlbmZvcmNlbWVudCwgUW9TIC4uLikgLCBhbmQgYWRk aW5nIGEgc3ViLXR5cGUgaW4gVFNfU0VDTEFCRUwNCj4gDQo+IFRoZSBpZGVhIHdhcyB0aGF0IHBl b3BsZSBzaG91bGQgYmUgYWJsZSB0byBkZWZpbmUgdGhpcyBvdXRzaWRlIG9mIElLRSBhcyB0aGV5 DQo+IHdpc2guIEFuZCBJS0UganVzdCB0cmFuc3BvcnRzIHRoZSBsYWJlbCBhcy1pcy4gT2YgY291 cnNlLCBpZiBJS0UgY2FuIGludGVycHJldCBpdCB0bw0KPiBkbyBzb21ldGhpbmcsIHRoZW4gaXQg Y2FuIHBvc3NpYmx5IGRvIG1vcmUsIGxpa2UgbmFycm93aW5nLg0KPiANCj4gSSB0aGluayB1c3Vh bGx5IHRoZSB0d28gZW5kcG9pbnRzIHdpbGwgb25seSBoYXZlIG9uZSB0eXBlIG9mIFNFQ0xBQkVM LCBzbyB0aGUNCj4gdHlwZSBpcyBpbXBsaWNpdCB0byB0aGUgSUtFIHByb3RvY29sLiBJZiB5b3Ug aGF2ZSBkaWZmZXJlbnQgc3VidHlwZXMsIHRoZW4NCj4gcHJlc3VtYWJseSBpZiB0aGUgc3VidHlw ZSBpcyB3cm9uZywgeW91IGNhbid0IGFjY2VwdCBpdCwgc28gdGhlIHR5cGUgaXMgYWxyZWFkeQ0K PiBrbm93biBvbiBib3RoIGVuZHMgYW5kIGRvZXNuJ3QgbmVlZCB0byBoYXZlIGl0cyBvd24gcmVn aXN0cnk/DQo+IA0KW0hKXSBzb3VuZCBsaWtlIHlvdSB3YW50IHRvIHRyZWF0IHRoaXMgYXMgdmVu ZG9yIHNwZWNpZmljLCBJIGFtIGZpbmUgaWYgZm9yIGNlcnRhaW4gdXNlIGNhc2UgeW91IGRvbid0 IHdhbnQgdG8gaW5jbHVkZSBpbnRlcnByZXRhdGlvbiBvZiBTRUNMQUJMRSBpbiB0aGUgZHJhZnQ7 DQpCdXQgZm9yIGNlcnRhaW4gY29tbW9uIHVzZSBjYXNlLCBsaWtlIFFvcyAob3Igc2VydmljZSBj bGFzcyksIGlmIHdlIHdhbnQgaW1wbGVtZW50YXRpb24gZnJvbSBkaWZmZXJlbnQgdmVuZG9yIHRv IGludGVyLW9wLCB3ZSBzaG91bGQgZGVmaW5lIGEgY2xlYXIgZm9ybWF0IGZvciBpdDsgZWl0aGVy IGluIHRoaXMgZHJhZnQsIG9yIHdlIGNvdWxkIGhhdmUgc2VwYXJhdGUgZHJhZnQgdG8gZGVmaW5l IHVzZSBjYXNlICxmb3JtYXQgYW5kIG5hcnJvd2luZyBydWxlOw0KVGhhdCdzIHdoeSBJIHRoaW5r IHdlIGNvdWxkIGhhdmUgYSBzdWItdHlwZSBoZXJlLCBsZWF2ZSBvbmUgdmFsdWUgZm9yIHZlbmRv ciBzcGVjaWZpYywgYnV0IGRlZmluZSBzb21lIG90aGVyIHN1Yi10eXBlcyBmb3IgY29tbW9uIHVz ZSBjYXNlcw0KDQoNCj4gPiAyLiBjdXJyZW50bHkgdGhlcmUgYXJlIFRTaSAoNDQpIGFuZCBUU3Ig KDQ1KSBwYXlsb2FkLCBkb2VzIGl0IG1ha2Ugc2Vuc2UgdG8NCj4gaW5jbHVkZSBUU19TRUNMQUJF TCBpbiBlaXRoZXIgVFNpIG9yIFRTcj8gSXMgdGhlcmUgc2VtYW50aWMgdG8gaGF2ZSBzZXBhcmF0 ZQ0KPiAiaW5pdGlhdG9yIFNFQ0xBQkVMIiBhbmQgInJlc3BvbmRlciBTRUNMQUJFTCI/IE9yIGRv ZXMgaXQgbWFrZSBtb3JlIHNlbnNlDQo+IHRvIG9ubHkgYWxsb3cgc2luZ2xlIFRTX1NFQ0xBQkVM IHBlciBtZXNzYWdlL0NISUxEX1NBLCBhbmQgY3JlYXRlIGEgbmV3DQo+IFRTIHBheWxvYWQgdHlw ZSAsIHB1dCBUU19TRUNMQUJFTCBpbiBpdCA/DQo+IA0KPiBUaGF0IHdvdWxkIGJlIGdpdmluZyBp dCBhbm90aGVyIFBheWxvYWQgVHlwZS4gSSB0aGluayBpdCBpcyByZWFsbHkgYSB0cmFmZmljDQo+ IHNlbGVjdG9yIHR5cGUgcGF5bG9hZCwgYW5kIG5vdCBhIG5vbi10cmFmZmljLXNlbGVjdG9yIHBh eWxvYWQuDQo+IA0KPiBFdmVuIGlmIGl0IGlzIHRydWUgdGhhdCB0aGUgbGFiZWwgb24gYm90aCBl bmRzIGhhdmUgdG8gYWx3YXlzIG1hdGNoLg0KPiBCdXQgdGhhdCdzIGtpbmQgb2Ygc2ltaWxhciB0 byBhZGRyZXNzIGZhbWlseSBhbHdheXMgbmVlZGluZyB0byBtYXRjaC4NCj4gDQo+IEFsdGhvdWdo IHRoZXJlIG1pZ2h0IGJlIGEgY2FzZSB3aGVyZSBvbmUgZW5kIGlzIGFsbG93ZWQgdG8gc2VuZCB0 cmFmZmljIHdpdGgNCj4gU0VDTEFCRUwgRm9vLCBidXQgbm90IGFsbG93ZWQgdG8gcmVjZWl2ZSB0 cmFmZmljIHdpdGggdGhhdCBsYWJlbCwgd2hlcmUgVFNpDQo+IGNvdWxkIGNvbnRhaW4gYSBUU19T RUNMQUJFTCBlbnRyeSwgYW5kIFRTciB3b3VsZCBub3QuDQo+IA0KPiBBbm90aGVyIGNhc2UgdGhh dCBwcm9iYWJseSBuZWVkcyBzb21lIGF0dGVudGlvbiBpcyB3aGVuIHRoZXJlIGlzIG1vcmUgdGhl bg0KPiBvbmUgVFNfU0VDTEFCRUwuIERvZXMgaXQgbWVhbiB0d28gZGlmZmVyZW50IHR5cGVzIG9m IHNlY3VyaXR5IGxhYmVscyBhcmUNCj4gbWVhbnQsIGFuZCBib3RoIGhhdmUgdG8gbWF0Y2g/IE9y IGlzIGl0IG9rYXkgdG8gcGljayBhbnkgb25lIG9mIHRoZSBsYWJlbHM/DQo+IA0KW0hKXSBhZ2Fp biwgSSB0aGluayB0aGlzIGRlcGVuZHMgb24gdGhlIHVzZSBjYXNlIG9mIFNFQ0xBQkVMLCBpbiBj YXNlIG9mIHNlcnZpY2UgY2xhc3MsIHNpbmdsZSBTRUNMQUJFTCBtYWtlIHNlbnNlLCBidXQgZm9y IG90aGVyIGNhc2VzLCBtYXliZSB0d28gZGlmZmVyZW50IGxhYmVsIG1ha2Ugc2Vuc2UgDQo+IFBh dWwNCg== From nobody Wed Mar 7 13:20: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 1E4111277BB for ; Wed, 7 Mar 2018 13:20:34 -0800 (PST) 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 zfvAgsOcYOV4 for ; Wed, 7 Mar 2018 13:20:30 -0800 (PST) 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 AA35412422F for ; Wed, 7 Mar 2018 13:20:29 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w27LKNuv022256 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 7 Mar 2018 23:20:23 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w27LKNR0021329; Wed, 7 Mar 2018 23:20:23 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23200.22423.300448.949259@fireball.acr.fi> Date: Wed, 7 Mar 2018 23:20:23 +0200 From: Tero Kivinen To: "Valery Smyslov" Cc: In-Reply-To: <043901d3ab29$8c980c20$a5c82460$@gmail.com> References: <23175.7252.256625.885691@fireball.acr.fi> <02c501d3a95e$a5d73200$f1859600$@gmail.com> <23179.8656.330909.562547@fireball.acr.fi> <038e01d3aa5e$ec66bc80$c5343580$@gmail.com> <23180.40426.204224.108279@fireball.acr.fi> <043901d3ab29$8c980c20$a5c82460$@gmail.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 44 min X-Total-Time: 49 min Archived-At: Subject: Re: [IPsec] Additional charter items 1/4: Responder MOBIKE 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, 07 Mar 2018 21:20:34 -0000 Valery Smyslov writes: > > There is no timers in the RFC specified for any of these operations, > > all of them are implementation details. This is something that will > > NOT affect interoperability, but will affect how well your > > implementation works. If this is important matter for your > > implementation you should research and study the problem and tune the > > parameters suitable for your normal use case. > > We are talking about different things. You are trying to convince > me that the cluster functionality _can_ be achieved with the current > MOBIKE. I don't disagree, but I'm pointing out, that in this case > it is relied on completely _optional_ features specified in RFC > and there is no indication whether and how peer supports > these features. These features don't affect MOBIKE interoperability, > but they do affect whether unmodified MOBIKE can be used > for cluster scenario. You are using lots of optional features too, things like NAT traversal and Configuration payloads. Implementations implement features they think are useful, and if you think features that allow MOBIKE movement is useful then you will implement them. > Again, I'm not insisting that my proposal is the only and the best > solution. Probably we can use the approach you suggested, > but in this case some extension to the MOBIKE should be added > that will make these features non optional and will add > a negotiation (or announcement) mechanism, so that > implementations can rely on peer's behavior. Actually your cluster will see keepalive packets for both IP-addresses, and can use this to indicate whether the client keeps both addresses active through NAT. Also your cluster can actually test it by sending empty informational exchange to the 2nd address first few times, and then replacing it with 1st address if no reply (which would indicate that 2nd ip address does not work). So those features can detected if needed to. > > It should detect it in few tens of seconds, and probes should find the > > working path in tens of seconds more, or so. I.e., this should happen > > in well under a minute. > > That was my conclusion too. And I don't think that about a minute is > a "short delay". I have much longer delays in my network connections several times a day. Especially when using mobile networks, or roaming between mobile networks and wifi. Yes, if you have streaming video or audio ongoing that will be annoing, but even those usually buffer data for minute or so. For conference calls or similar, minute is really noticeable break. > > If you care about real-time traffic, then you should keep your NAT > > mappings up for all peers, so you will get the address update message, > > and can move to new address immediately when you receive it. > > It won't help much. The MOBIKE client doesn't know that it must > switch to a just received additional address once he receives it. The > event that usually triggers this movement is an availability of current > path. So you still will have a the delay while the client detects that > the current path is not working and the new path works. > You'll still have about 10-20 seconds delay at best. No. The switch will be triggered immediately when the cluster / server sends MOBIKE update using the 2nd ip address and does NOT include the currently used IP address in the address list. If that message goes through the client will start switch immediately, and probing the that it works is just one round trip, so the delay should be less than second. I.e. Initiator Responder --------- --------- <-- HDR(IPr2, IPi), SK { N(NO_ADDITIONAL_ADDRESSES) } HDR(IPi, IPr2), SK { } --> This will immediately trigger the initiator to switch to IPr2, as IPr1 is no longer available. Note, that IPsec traffic can be switched to new address at this point already. HDR(IPi, IPr2), SK { N(UPDATE_SA_ADDRESSES), [N(NAT_DETECTION_SOURCE_IP), N(NAT_DETECTION_DESTINATION_IP)], [N(COOOKIE2)] } --> <-- HDR(IPr2, IPi), SK { [N(NAT_DETECTION_SOURCE_IP), N(NAT_DETECTION_DESTINATION_IP)], [N(COOKIE2)] } and after that move is finished. So if client is keeping NAT mappings alive address change can be done without any lost packets. And the fact that it keeps mappings alive can either be tested, or you can use the fact that you get keepalive packets to the 2nd address as indication of that. > > > Then the IKE SA state must be transferred to a new node and the > > > current node must stop responding to this client. > > > > You need to move the IKE SA anyways, and you need to move it before > > you send any update which says there is another IP address to be used. > > And both ends MUST be able to process IKE and IPsec SA packets at the > > same time if we want to make sure no packets are lost during the > > transition (if you really care about real-time traffic). > > No, in your case the first node must stop responding to the client, > so that client understands that it should switch to the other address. > With my proposal the client is explicitly asked to do that, > so the whole procedure should take less time and be more reliable. > so that it is easier to make the event atomic from cluster point of view. Not true. Changing addresses can also be triggered by events within IKEv2. At least the following events can cause the initiator to re-evaluate its local address selection policy, possibly leading to changing the addresses. ... o An INFORMATIONAL request containing an ADDITIONAL_IP4_ADDRESS, ADDITIONAL_IP6_ADDRESS, or NO_ADDITIONAL_ADDRESSES notification is received. This means the peer's addresses may have changed. This is particularly important if the announced set of addresses no longer contains the currently used address. > > > Then the cluster would wait until the client detects the failure and > > > switches itself to a new node. And there is also a chance that there > > > are some IKE exchanges in progress, so if the node stops responding > > > the exchanges could time out the and the IKE SA would be deleted > > > before the movement takes place (in my proposal the MOBIKE is > > > combined with RFC6311 exchange to make this working)... > > > > If you are using MOBIKE, then the IKE exchange should not time out > > before it has tried all possible addresses, thus there is no issue in > > there. > > Can you please point me where RFC4555 requires that > _any_ exchange must try all possible addresses before > timing out? Path testing is described in Sections 3.10 and 3.12 > and these sections only tell about using INFORMATIONAL > DPD exchanges for this purpose. I do not think it says that directly, but that is only way to get MOBIKE working. It does that explictly for the initial IKE exchange: 3.1. Initial IKE Exchange ... If either or both of the peers have multiple addresses, some combinations may not work. Thus, the initiator SHOULD try various source and destination address combinations when retransmitting the IKE_SA_INIT request. For the other exchanges this can be seen in the section 3.5. I.e. one of the triggers for the address change is: o An IKEv2 request has been re-transmitted several times, but no valid reply has been received. This suggests the current path is no longer working. Note, that this is done BEFORE the exchange times out. So in the next step you pick address you want to try next, and go forward, and update IKE SA with new addresses, and then: o If there are outstanding IKEv2 requests (requests for which the initiator has not yet received a reply), continues retransmitting them using the addresses in the IKE_SA (the new addresses). I.e., you start sending them out with new IP address. If you have space in your window you might also send address update, but quite often implementations only support window size of 1, so you send your original packet for 2nd IP address pair for some time, and if it still does not work, you go back to beginning, and notice this address pair does not work, lets pick next one. And you continue doing that until you time out the whole exchange after several minutes. Note, that you might run out of ip-address pairs during the process so you might end up going back to beginning again. After you do get reply to your IKEv2 request, then you now do have space in your window and you do send UPDATE_SA_ADDRESSES packet to the other end... > Broken implementations is not an issue here (although it is always big issue :-(). > The issue is that RFC4555 in its current form is too vague to be used > for cluster use case. This use case requires some additions to RFC4555 > or some clarifications in any case (if the cluster use case is solved > using MOBIKE, that is not the only possible way). I am not sure about that. Note, that we did work quite long to get the rules in section 3.5 correct, and there are things there that will make things work correctly if you follow the rules, even if not everything is explained there (i.e., it does not explain why you need to do things exactly like it says, it just assumes you do). RFC4621 explains the design rational behind the MOBIKE, and it explains why we did some things in RFC4555. For example the section 6.2 of the RFC4621 explains that we need to use any existing IKE exchange as path testing message and explains why we did it. > OK. How about the following? > > MOBIKE protocol [RFC4555] is used to move existing IKE/IPsec SA from > one IP address to another. However, in MOBIKE it is the initiator of > the IKE SA (i.e. remote access client) that controls this process. > While the responder can try to instruct the initiator to switch to a different > IP address, the whole process is not reliable enough, especially > in presence of NAT or firewalls. If there are several responders each having > own IP address and acting together as a load sharing cluster, then it is desirable > for them to have ability to request initiator to switch to a particular member. > The working group will analyze the possibility to extend MOBIKE > protocol or to develop new IKE extension that will allow to build load > sharing clusters in an interoperable way. > > Is it better? Much better, but I still think that this can be done without modification to the MOBIKE itself, and you already implement it in the cluster end without any need to modify client end. It will work better if the client will send keepalives for all IP-addresses instead of just using the one, or if the client probes other paths than what is used every now and then. -- kivinen@iki.fi From nobody Wed Mar 7 14:03:16 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 0C2EC12D86D for ; Wed, 7 Mar 2018 14:03:14 -0800 (PST) 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 T7KHe51BRqW3 for ; Wed, 7 Mar 2018 14:03:13 -0800 (PST) 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 EAE6F12D7EF for ; Wed, 7 Mar 2018 14:03:12 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w27M32dW001003 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 8 Mar 2018 00:03:07 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w27M2vKV018418; Thu, 8 Mar 2018 00:02:57 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23200.24977.600854.89081@fireball.acr.fi> Date: Thu, 8 Mar 2018 00:02:57 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 8 min X-Total-Time: 25 min Archived-At: Subject: [IPsec] Preliminary agenda for IPsecME in IETF 101 in London 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, 07 Mar 2018 22:03:14 -0000 Here is the preliminary agenda. If I missed any request for timeslot, send me email ASAP, so I will check if I can add it... We have quite a lot of presentations and it is possible we will not be able to cover all of them (i.e., the ones in the end might be dropped out). I would like to get all slides before the Friday next week (16th of March) and if you do not provide slides, your presentation will be automatically dropped (does not apply the chairs :-) ---------------------------------------------------------------------- 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 (15 min) Scott Fluhrer - draft-tjhai-ipsecme-hybrid-qske-ikev2 - Labeled IPsec (5 min) Paul Wouters - Auxiliary Exchange in the IKEv2 Protocol (15 min) Valery Smyslov - draft-smyslov-ipsecme-ikev2-aux - Group Key Management using IKEv2 (15 min) Valery Smyslov - draft-yeung-g-ikev2 - IKE_SA_INIT privacy concerns (10 min) David Schinazi - draft-dschinazi-ipsecme-sa-init-privacy-addition - Dynamic IPsec PMTU PLPMTUD (10 min) Shibu Piriyath, Ron Bonica - draft-spiriyath-ipsecme-dynamic-ipsec-pmtu -- kivinen@iki.fi From nobody Mon Mar 12 01:23: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 96ED612706D for ; Mon, 12 Mar 2018 01:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 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] 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 6dM75MQIVHOr for ; Mon, 12 Mar 2018 01:23:09 -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 115F7126BFD for ; Mon, 12 Mar 2018 01:23:07 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id e28-v6so12886748lfc.3 for ; Mon, 12 Mar 2018 01:23:07 -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=WLBaOVi1ar9HjbNYLHjqH7q+6Q/vRPfA9STnlrzjjM8=; b=Eoh9ThgcbSOp8Dk9Wl55DubzANFzVUaxndeXJyFK55B/pFJ+aBk5J9wRhJxgsO9EoG O4fo55fXVjo2PjkOI654HkekaZT4S0k1SBEG+rWMv1DvxU24tDgVAb4usv/y7sV5XDkU +MgCUWfQT1U54LUsFThQ8M6EJCsdkdLZXkch07+8y0e4qrVHUhv0x9m9gJLMRA5s9oUa St3kqGzCd7uQ7fkhylOZWFexePjs1HejvQnBB5SNvesdN2WDViTJFcJF44w0frOncpq5 YLrmCo3t1iWJkb0P15AU761LCcuuvYYTe6bnOwFEIeAtm2+EL/9aErNHQQ+doePpLs9I GFag== 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=WLBaOVi1ar9HjbNYLHjqH7q+6Q/vRPfA9STnlrzjjM8=; b=hfjvezlDFn/7gjWiEDfM7qrvqJDFzSHPI77Aa6lKSOzoP13lS+1KQlKHyQPDGAoFvy Q4xAkizhHwSH1KHbkKisxOSEE3WFRjCRsCN9QuAkJLzvg4/htxvgZeMsGu5pOduzZSVR 7mKGKJZC7PbffpfVL1DflYb7tufhH/YnchgcgD0aW4yj1sEtgtz0WPvsTnPqUwrMiBZ+ gXQigskekN2eiHe6l4Jt78p+rYhxM8rD8RYx6OyukNsSqClOuI5tdnN2qUH1l2Q1m62r DBzagkiuSWMXjbd5G9siIPHYzQtOF90nPBs07+h/XbATT588wHt81iH1pQZK1bVtMLtm 7iIg== X-Gm-Message-State: AElRT7EKADcXTzwMyawLY/PGjxUdT5MEJmFw6fyy1NrBRmmJWe7HTqCB kOXsYbLDumQpJ/126Cqo4Yfnxw== X-Google-Smtp-Source: AG47ELtNM1zyb8TatbEOVEyppqk60XKV/lF+o+AfgQz/zV9QDJ6oFSrW/2CKqLrUiOJgxY4eQ4/Fdw== X-Received: by 2002:a19:590c:: with SMTP id n12-v6mr4642468lfb.10.1520842985704; Mon, 12 Mar 2018 01:23:05 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id p67sm1593471ljb.95.2018.03.12.01.23.04 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 12 Mar 2018 01:23:04 -0700 (PDT) From: "Valery Smyslov" To: "'Tero Kivinen'" Cc: References: <23175.7252.256625.885691@fireball.acr.fi> <02c501d3a95e$a5d73200$f1859600$@gmail.com> <23179.8656.330909.562547@fireball.acr.fi> <038e01d3aa5e$ec66bc80$c5343580$@gmail.com> <23180.40426.204224.108279@fireball.acr.fi> <043901d3ab29$8c980c20$a5c82460$@gmail.com> <23200.22423.300448.949259@fireball.acr.fi> In-Reply-To: <23200.22423.300448.949259@fireball.acr.fi> Date: Mon, 12 Mar 2018 11:23:04 +0300 Message-ID: <0a2601d3b9db$58583af0$0908b0d0$@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: AQJXnlQnOgkoKoWaf0xqED6y+ZUK7AHZIA6IAi7r5FoC17kq+wLRnswoAqvC3IYB4aweT6JSblWQ Content-Language: ru Archived-At: Subject: Re: [IPsec] Additional charter items 1/4: Responder MOBIKE 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, 12 Mar 2018 08:23:11 -0000 Hi, [I trimmed the message] > > It won't help much. The MOBIKE client doesn't know that it must > > switch to a just received additional address once he receives it. The > > event that usually triggers this movement is an availability of current > > path. So you still will have a the delay while the client detects that > > the current path is not working and the new path works. > > You'll still have about 10-20 seconds delay at best. > > No. The switch will be triggered immediately when the cluster / server > sends MOBIKE update using the 2nd ip address and does NOT include the > currently used IP address in the address list. If that message goes > through the client will start switch immediately, and probing the that > it works is just one round trip, so the delay should be less than > second. I believe this interpretation is wrong. The IP address from the IP is always implicitly included into the list of host's IP addresses (Section 3.6): If the exchange initiator has only a single IP address, it is placed in the IP header, and the message contains the NO_ADDITIONAL_ADDRESSES notification. If the exchange initiator has several addresses, one of them is placed in the IP header, and the rest in ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications. So, according to the RFC4555 the currently used IP address must not be included into the ADDITIONAL_IP*_ADDRESS notification. So, the client won't switch to a new address immediately, it's first test an old path and if it works it'll most probably do nothing. > Initiator Responder > --------- --------- > <-- HDR(IPr2, IPi), SK { N(NO_ADDITIONAL_ADDRESSES) } > HDR(IPi, IPr2), SK { } --> > > This will immediately trigger the initiator to switch to IPr2, as IPr1 > is no longer available. Note, that IPsec traffic can be switched to > new address at this point already. With NO_ADDITIONAL_ADDRESSES it will work, but only in case the mapping for IPr2 exists. That's the issue. > and after that move is finished. So if client is keeping NAT mappings > alive address change can be done without any lost packets. And the > fact that it keeps mappings alive can either be tested, or you can use > the fact that you get keepalive packets to the 2nd address as > indication of that. You are oversimplifying the problem. To make periodic tests by responder you must have a copy of IKE SA on all the cluster nodes and continuously sync them. And the client won't send any NAT keepalives until it gets reply from the cluster, so the IKE SA again needs to be present (and synced!) on all cluster nodes all the time. While this is possible, it is a headache and to some extent it makes the whole idea of the load-sharing cluster meaningless. Another problem is that with MOBIKE the initiator is free to switch to any path it wants in any moment. So, to encourage the client to send NAT KA to all cluster's addresses you must include all of them into ADDITIONAL_IP*_ADDRESS notification, so that the client knows all of them. You must also reply to requests sent to any of these addresses, otherwise the client won't start sending NAT KA. But it means that now the client can switch to any of these addresses on its own discretion - that's completely kill the idea of load sharing cluster: it is the cluster that must control when and where to move client. > > Can you please point me where RFC4555 requires that > > _any_ exchange must try all possible addresses before > > timing out? Path testing is described in Sections 3.10 and 3.12 > > and these sections only tell about using INFORMATIONAL > > DPD exchanges for this purpose. > > I do not think it says that directly, but that is only way to get > MOBIKE working. It does that explictly for the initial IKE exchange: > > 3.1. Initial IKE Exchange > ... > If either or both of the peers have multiple addresses, some > combinations may not work. Thus, the initiator SHOULD try various > source and destination address combinations when retransmitting the > IKE_SA_INIT request. These must be different requests (with different SPIs), at least if the initiator changes a destination IP, since the NAT_DETECTION_DESTINATION_IP would be different. So it is not a retransmission, it's a new request. Section 2.1 of RFC7296: A retransmission from the initiator MUST be bitwise identical to the original request. That is, everything starting from the IKE header (the IKE SA initiator's SPI onwards) must be bitwise identical; items before it (such as the IP and UDP headers) do not have to be identical. > For the other exchanges this can be seen in the section 3.5. > > I.e. one of the triggers for the address change is: > > o An IKEv2 request has been re-transmitted several times, but no > valid reply has been received. This suggests the current path is > no longer working. > > Note, that this is done BEFORE the exchange times out. > > So in the next step you pick address you want to try next, and go > forward, and update IKE SA with new addresses, and then: > > o If there are outstanding IKEv2 requests (requests for which the > initiator has not yet received a reply), continues > retransmitting them using the addresses in the IKE_SA (the new > addresses). > > I.e., you start sending them out with new IP address. If you have > space in your window you might also send address update, but quite > often implementations only support window size of 1, so you send your > original packet for 2nd IP address pair for some time, and if it still > does not work, you go back to beginning, and notice this address pair > does not work, lets pick next one. And you continue doing that until > you time out the whole exchange after several minutes. Note, that you > might run out of ip-address pairs during the process so you might end > up going back to beginning again. There are additional complications not mentioned in the RFC. If the exchange is a MOBIKE probe and NAT is supported, then it will include NAT_DETECTION_DESTINATION_IP. When the exchange initiator tries different destination IP addresses it must re-calculate this notification, so that NAT is detected properly. This leads to a direct violation of Section 2.1 of RFC7296 (see above). > > Broken implementations is not an issue here (although it is always big issue :-(). > > The issue is that RFC4555 in its current form is too vague to be used > > for cluster use case. This use case requires some additions to RFC4555 > > or some clarifications in any case (if the cluster use case is solved > > using MOBIKE, that is not the only possible way). > > I am not sure about that. Note, that we did work quite long to get the > rules in section 3.5 correct, and there are things there that will > make things work correctly if you follow the rules, even if not > everything is explained there (i.e., it does not explain why you need > to do things exactly like it says, it just assumes you do). > > RFC4621 explains the design rational behind the MOBIKE, and it > explains why we did some things in RFC4555. For example the section > 6.2 of the RFC4621 explains that we need to use any existing IKE > exchange as path testing message and explains why we did it. Sorry, but there are still some unclear places. And I don't think in its current form it suites well for building load-sharing cluster. You are trying to convince me otherwise, and I agree that it would probably _somehow_ work in _some_ situations, but the quality of such a solution leaves much to be desired, IMHO. > > OK. How about the following? > > > > MOBIKE protocol [RFC4555] is used to move existing IKE/IPsec SA from > > one IP address to another. However, in MOBIKE it is the initiator of > > the IKE SA (i.e. remote access client) that controls this process. > > While the responder can try to instruct the initiator to switch to a different > > IP address, the whole process is not reliable enough, especially > > in presence of NAT or firewalls. If there are several responders each having > > own IP address and acting together as a load sharing cluster, then it is desirable > > for them to have ability to request initiator to switch to a particular member. > > The working group will analyze the possibility to extend MOBIKE > > protocol or to develop new IKE extension that will allow to build load > > sharing clusters in an interoperable way. > > > > Is it better? > > Much better, but I still think that this can be done without > modification to the MOBIKE itself, and you already implement it in the > cluster end without any need to modify client end. It will work better > if the client will send keepalives for all IP-addresses instead of > just using the one, or if the client probes other paths than what is > used every now and then. Too many "if" for which the cluster end cannot be sure - client does it or not on its own discretion. That's what I'm complaining about. > -- > kivinen@iki.fi Regards, Valery. From nobody Mon Mar 12 08:10: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 879391205F0 for ; Mon, 12 Mar 2018 08:10:58 -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 aX1sUzs5rouP for ; Mon, 12 Mar 2018 08:10:55 -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 274ED1201FA for ; Mon, 12 Mar 2018 08:10:54 -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 w2CFAktX019872 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 12 Mar 2018 17:10:46 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w2CFAk0F014007; Mon, 12 Mar 2018 17:10:46 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23206.39029.998845.849191@fireball.acr.fi> Date: Mon, 12 Mar 2018 17:10:45 +0200 From: Tero Kivinen To: "Valery Smyslov" Cc: ipsec@ietf.org In-Reply-To: <0a2601d3b9db$58583af0$0908b0d0$@gmail.com> References: <23175.7252.256625.885691@fireball.acr.fi> <02c501d3a95e$a5d73200$f1859600$@gmail.com> <23179.8656.330909.562547@fireball.acr.fi> <038e01d3aa5e$ec66bc80$c5343580$@gmail.com> <23180.40426.204224.108279@fireball.acr.fi> <043901d3ab29$8c980c20$a5c82460$@gmail.com> <23200.22423.300448.949259@fireball.acr.fi> <0a2601d3b9db$58583af0$0908b0d0$@gmail.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 28 min X-Total-Time: 35 min Archived-At: Subject: Re: [IPsec] Additional charter items 1/4: Responder MOBIKE 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, 12 Mar 2018 15:10:58 -0000 Valery Smyslov writes: > > No. The switch will be triggered immediately when the cluster / server > > sends MOBIKE update using the 2nd ip address and does NOT include the > > currently used IP address in the address list. If that message goes > > through the client will start switch immediately, and probing the that > > it works is just one round trip, so the delay should be less than > > second. > > I believe this interpretation is wrong. The IP address from the IP > is always implicitly included into the list of host's IP addresses (Section 3.6): > > If the exchange initiator has only a single IP address, it is placed > in the IP header, and the message contains the > NO_ADDITIONAL_ADDRESSES notification. If the exchange initiator has > several addresses, one of them is placed in the IP header, and the > rest in ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications. Yes, thats why the notify needs to be sent from address pair NOT in use. In my example the header said IPr2, not IPr1. The IPr1 is the currently used address, IPr2 was the additional address before. Sending this notify will indicate that IPr1 is no longer in use and because it is no longer in use it needs to be send from IPr2 as source address. > So, according to the RFC4555 the currently used IP address must not > be included into the ADDITIONAL_IP*_ADDRESS notification. So, the > client won't switch to a new address immediately, it's first test an > old path and if it works it'll most probably do nothing. Not true. > > Initiator Responder > > --------- --------- > > <-- HDR(IPr2, IPi), SK { N(NO_ADDITIONAL_ADDRESSES) } > > HDR(IPi, IPr2), SK { } --> > > > > This will immediately trigger the initiator to switch to IPr2, as IPr1 > > is no longer available. Note, that IPsec traffic can be switched to > > new address at this point already. > > With NO_ADDITIONAL_ADDRESSES it will work, but only in case the mapping > for IPr2 exists. That's the issue. Yes the mapping for IPr2 needs to work. Note, that if the mapping for IPr2 does not work, then this message will get thrown away by NAT, and as there is no response to the notify the responder will at some point assume that this path it switched to is broken and switch to use another IP, and is does not have any other IP, it needs to trigger some special code there to add IPr1 back to the list of allowed addresses, and then it will retransmit this address again using (IPr1, IPi) as addresses. This will then reach the initiator and for his point of view this was just removing the IPr2 from the address list. On the other hand after that the responder will know that this method will not work as initiator does not keep mappings up, and can give up with the load balancing for this client, and rather move the clients which support faster redirect. Or if it thinks load balancing is more important than the a minute breakage, it can simply keep retransmitting it on the IPr2, and stop responding to any packets to IPr1. After a while the initiator will notice this and it will try to probe on IPr2 too, and that will create the NAT mapping, and then responder can retransmit its notify to that port, and it will reach the initiator. > > and after that move is finished. So if client is keeping NAT mappings > > alive address change can be done without any lost packets. And the > > fact that it keeps mappings alive can either be tested, or you can use > > the fact that you get keepalive packets to the 2nd address as > > indication of that. > > You are oversimplifying the problem. To make periodic tests by responder you > must have a copy of IKE SA on all the cluster nodes and continuously sync them. > And the client won't send any NAT keepalives until it gets reply from the cluster, > so the IKE SA again needs to be present (and synced!) on all cluster nodes all the time. > While this is possible, it is a headache and to some extent it makes the > whole idea of the load-sharing cluster meaningless. Load balancing issues are really hard, and I assumed that those have been taken care of by the cluster, as otherwise there is no point of any of this. As client can at any point decide to use whatever address the cluster gives it, the cluster MUST be able to process packets arriving to any of its addreses always. So load balancing issues inside the cluster is outside the scope of this dicussion. > Another problem is that with MOBIKE the initiator is free to switch to any path > it wants in any moment. So, to encourage the client to send NAT KA to all cluster's > addresses you must include all of them into ADDITIONAL_IP*_ADDRESS > notification, so that the client knows all of them. You must also reply > to requests sent to any of these addresses, otherwise the client won't > start sending NAT KA. But it means that now the client can switch > to any of these addresses on its own discretion - that's completely > kill the idea of load sharing cluster: it is the cluster that must control > when and where to move client. Yes. If you want to have load balancing, you need to do it properly. > > I do not think it says that directly, but that is only way to get > > MOBIKE working. It does that explictly for the initial IKE exchange: > > > > 3.1. Initial IKE Exchange > > ... > > If either or both of the peers have multiple addresses, some > > combinations may not work. Thus, the initiator SHOULD try various > > source and destination address combinations when retransmitting the > > IKE_SA_INIT request. > > These must be different requests (with different SPIs), at least if the initiator > changes a destination IP, since the NAT_DETECTION_DESTINATION_IP would > be different. So it is not a retransmission, it's a new request. > Section 2.1 of RFC7296: > > A retransmission from the initiator MUST be > bitwise identical to the original request. That is, everything > starting from the IKE header (the IKE SA initiator's SPI onwards) > must be bitwise identical; items before it (such as the IP and UDP > headers) do not have to be identical. Only if the destination address changes. Usually the client using MOBIKE has only one destination address, and multiple source addresses, so it will include all of its source addresses in the NAT_DETECTION_SOURCE_IP notifies, and the one destination address for the NAT_DETECTION_DESTINATION_IP. In that case there is no need to change packet after it is sent, and it will be same request transmitted over different source IP addresses. If client do have multiple destination addresses, then it must assume each of those is different, and create separate IKE_SA_INIT messages for each of them. > > I.e., you start sending them out with new IP address. If you have > > space in your window you might also send address update, but quite > > often implementations only support window size of 1, so you send your > > original packet for 2nd IP address pair for some time, and if it still > > does not work, you go back to beginning, and notice this address pair > > does not work, lets pick next one. And you continue doing that until > > you time out the whole exchange after several minutes. Note, that you > > might run out of ip-address pairs during the process so you might end > > up going back to beginning again. > > There are additional complications not mentioned in the RFC. > If the exchange is a MOBIKE probe and NAT is supported, then > it will include NAT_DETECTION_DESTINATION_IP. When the exchange > initiator tries different destination IP addresses it must re-calculate > this notification, so that NAT is detected properly. This leads to a direct > violation of Section 2.1 of RFC7296 (see above). It will never re-calculate the packet. It will note this fact, and mark this request as failed, thus it will run it through sending it to the other end without modification, but after the process finishes, it will throw away the result, and immediately start over with correct destination address and correctly calculated NAT_DETECTION_DESTINATION_IP address field. I.e., following point in RFC4555: o If a new address change occurs while waiting for the response, starts again from the first step (and ignores responses to this UPDATE_SA_ADDRESSES request). will tell that if any change to addresses happened while it was sending UPDATE_SA_ADDRESSES notify, then it will start over immediately when reply is received. If while we were sending UPDATE_SA_ADDRESSES we needed to switch to next destination address, that means the "new address change" has occurred, thus we go back to beginning. > > I am not sure about that. Note, that we did work quite long to get the > > rules in section 3.5 correct, and there are things there that will > > make things work correctly if you follow the rules, even if not > > everything is explained there (i.e., it does not explain why you need > > to do things exactly like it says, it just assumes you do). > > > > RFC4621 explains the design rational behind the MOBIKE, and it > > explains why we did some things in RFC4555. For example the section > > 6.2 of the RFC4621 explains that we need to use any existing IKE > > exchange as path testing message and explains why we did it. > > Sorry, but there are still some unclear places. > And I don't think in its current form it suites well for building > load-sharing cluster. You are trying to convince me otherwise, > and I agree that it would probably _somehow_ work in _some_ > situations, but the quality of such a solution leaves much to be desired, IMHO. Load balancing was explictly mentioned as out of scope for the MOBIKE, we did say that the method we are using in MOBIKE should try to support load balancing, but we never meant it to be generic solution for load balancing. There are lots of additional issues in the load balancing which needs to be solved than just this. I.e. RFC4621 says: Note that MOBIKE does not aim to support load balancing between multiple IP addresses. That is, each peer uses only one of the available address pairs at a given point in time. ... Load balancing is currently outside the scope of MOBIKE; however, future work might include support for it. The selected format needs to be flexible enough to include additional information in future versions of the protocol (e.g., to enable load balancing). This may be realized with an reserved field, which can later be used to store additional information. As other information may arise that may have to be tied to an address in the future, a reserved field seems like a prudent design in any case. and RFC4555 says: MOBIKE allows both parties to be multihomed; however, only one pair of addresses is used for an SA at a time. In particular, load balancing is beyond the scope of this specification. For example MOBIKE always assumes that both peers are same entity, i.e., even when there is multiple IP-addresses, they all reach the same entity in the other end, thus either end can process any packet sent to any of its IP-addresses. -- kivinen@iki.fi From nobody Tue Mar 13 00:42: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 A07CC12D77D for ; Tue, 13 Mar 2018 00:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 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] 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 M6VlIAT7xKTs for ; Tue, 13 Mar 2018 00:42:46 -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 7F0CF12D778 for ; Tue, 13 Mar 2018 00:42:45 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id t132-v6so10775238lfe.2 for ; Tue, 13 Mar 2018 00:42:45 -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=H+6G0zB7OLga2sQZtDNdjQczDS45C+ISJLyMYirx7+k=; b=RZmddjBUBiDBQ22lB26qYpQ9k3l/LnmY6MQih9Gefuo68dRl1rpd6izlhhl+teSAQN vxU14ktApOKtrSjgQph5dR6RP32wr283XfGdHXU0Tq0bgYazy1gK1Woi9rrZ9aqFNGu5 dKvilRU3rWO/cBo6jVqUUAL5cTulH3z4LH+P4XvPK+OdEbABTvtc4uCbiR9i1JbOtXdK VwzRUxX6RrWWnhJMyaC04QOdqYEFPmsWwlsD0m3hxVl2wlDvvy9/hUNRQZpXlgbVzskF 8AqLVc3EAZwEVSF39tKmzo7P02HGpoMisvf3SkO87k2VeHFYoXMSyBHmjWfLzBGjZFkI 5kaA== 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=H+6G0zB7OLga2sQZtDNdjQczDS45C+ISJLyMYirx7+k=; b=UZrkZpF/a3XtbiI+bII7IAfNHKWY3KxODbwIQj2K/G5vUfRyWX/p/oHGQtWoS14Sh2 LdDYW9f75t38uyNCPg1qcvZVDf2JE9M83bEIegADFwn6gyYSp0zaxNo1l2X9+IxVeu3A mbXUqahJ/qiPDOUxCDIyLKkZkO6D0cadfHx2MBbMh7PFvdnCSrQRmAg5PzDfkMRvK/vQ famxzbhgdADxtzfiCnIbn3zdKd6JeoeAMtjBa8xXgdPRdhS5j67jn0DCowf3RXm77LcE 4FJ10j692+3btNbdWAqsbXLyziNeyJwM7M2cIiGBbcksUXkn0nbcucDWR9dP1LygqzN1 Vd7g== X-Gm-Message-State: AElRT7H4rm3w18aLzDcucE1q3w/GRVxe+AlmZgV97cNae8ma5aPurtBB ow3nJqy2LdH7c5HIXs1aXtIJZQ== X-Google-Smtp-Source: AG47ELsMqkG7K65tocmxiQyQ7ascqnzcKZdwwC4dhlYgHZhU22g8zkKuUmPUHi0xH30zvrY0F/66dQ== X-Received: by 2002:a19:be4b:: with SMTP id o72-v6mr452489lff.20.1520926963168; Tue, 13 Mar 2018 00:42:43 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id o14sm2191745ljc.52.2018.03.13.00.42.41 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 13 Mar 2018 00:42:42 -0700 (PDT) From: "Valery Smyslov" To: "'Tero Kivinen'" Cc: References: <23175.7252.256625.885691@fireball.acr.fi> <02c501d3a95e$a5d73200$f1859600$@gmail.com> <23179.8656.330909.562547@fireball.acr.fi> <038e01d3aa5e$ec66bc80$c5343580$@gmail.com> <23180.40426.204224.108279@fireball.acr.fi> <043901d3ab29$8c980c20$a5c82460$@gmail.com> <23200.22423.300448.949259@fireball.acr.fi> <0a2601d3b9db$58583af0$0908b0d0$@gmail.com> <23206.39029.998845.849191@fireball.acr.fi> In-Reply-To: <23206.39029.998845.849191@fireball.acr.fi> Date: Tue, 13 Mar 2018 10:42:34 +0300 Message-ID: <000b01d3ba9e$da4a7c30$8edf7490$@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: AQJXnlQnOgkoKoWaf0xqED6y+ZUK7AHZIA6IAi7r5FoC17kq+wLRnswoAqvC3IYB4aweTwJrK7JiAdXUC6CiMfWcYA== Content-Language: ru Archived-At: Subject: Re: [IPsec] Additional charter items 1/4: Responder MOBIKE 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, 13 Mar 2018 07:42:48 -0000 > > > Initiator Responder > > > --------- --------- > > > <-- HDR(IPr2, IPi), SK { N(NO_ADDITIONAL_ADDRESSES) } > > > HDR(IPi, IPr2), SK { } --> > > > > > > This will immediately trigger the initiator to switch to IPr2, as IPr1 > > > is no longer available. Note, that IPsec traffic can be switched to > > > new address at this point already. > > > > With NO_ADDITIONAL_ADDRESSES it will work, but only in case the mapping > > for IPr2 exists. That's the issue. > > Yes the mapping for IPr2 needs to work. Note, that if the mapping for > IPr2 does not work, then this message will get thrown away by NAT, and > as there is no response to the notify the responder will at some point > assume that this path it switched to is broken and switch to use > another IP, and is does not have any other IP, it needs to trigger > some special code there to add IPr1 back to the list of allowed > addresses, and then it will retransmit this address again using (IPr1, > IPi) as addresses. This will then reach the initiator and for his > point of view this was just removing the IPr2 from the address list. Yes, quite a lot of movements for a simple task. > On the other hand after that the responder will know that this method > will not work as initiator does not keep mappings up, and can give up > with the load balancing for this client, and rather move the clients > which support faster redirect. Again, better to know this beforehand. > Or if it thinks load balancing is more important than the a minute > breakage, it can simply keep retransmitting it on the IPr2, and stop > responding to any packets to IPr1. After a while the initiator will > notice this and it will try to probe on IPr2 too, and that will create > the NAT mapping, and then responder can retransmit its notify to that > port, and it will reach the initiator. You repeat the scenario I described a couple of messages ago. Let me cite myself once more - your explanations only support my opinion, that it _is_ possible to use MOBIKE AS IS for load sharing, but it comes out to be cumbersome and unreliable. > > You are oversimplifying the problem. To make periodic tests by responder you > > must have a copy of IKE SA on all the cluster nodes and continuously sync them. > > And the client won't send any NAT keepalives until it gets reply from the cluster, > > so the IKE SA again needs to be present (and synced!) on all cluster nodes all the time. > > While this is possible, it is a headache and to some extent it makes the > > whole idea of the load-sharing cluster meaningless. > > Load balancing issues are really hard, and I assumed that those have > been taken care of by the cluster, as otherwise there is no point of > any of this. As client can at any point decide to use whatever address > the cluster gives it, the cluster MUST be able to process packets > arriving to any of its addreses always. I don't think so. If we define an extension to MOBIKE for cluster, then the client will know that the selection of destination IP is under cluster control and won't randomly switch from one IP to another. Of course the selection of client's source IP is a client's prerogative. > > > If either or both of the peers have multiple addresses, some > > > combinations may not work. Thus, the initiator SHOULD try various > > > source and destination address combinations when retransmitting the > > > IKE_SA_INIT request. > > > > These must be different requests (with different SPIs), at least if the initiator > > changes a destination IP, since the NAT_DETECTION_DESTINATION_IP would > > be different. So it is not a retransmission, it's a new request. > > Section 2.1 of RFC7296: > > > > A retransmission from the initiator MUST be > > bitwise identical to the original request. That is, everything > > starting from the IKE header (the IKE SA initiator's SPI onwards) > > must be bitwise identical; items before it (such as the IP and UDP > > headers) do not have to be identical. > > Only if the destination address changes. Usually the client using > MOBIKE has only one destination address, and multiple source > addresses, so it will include all of its source addresses in the > NAT_DETECTION_SOURCE_IP notifies, and the one destination address for > the NAT_DETECTION_DESTINATION_IP. In that case there is no need to > change packet after it is sent, and it will be same request > transmitted over different source IP addresses. > > If client do have multiple destination addresses, then it must assume > each of those is different, and create separate IKE_SA_INIT messages > for each of them. That's what I said. > > There are additional complications not mentioned in the RFC. > > If the exchange is a MOBIKE probe and NAT is supported, then > > it will include NAT_DETECTION_DESTINATION_IP. When the exchange > > initiator tries different destination IP addresses it must re-calculate > > this notification, so that NAT is detected properly. This leads to a direct > > violation of Section 2.1 of RFC7296 (see above). > > It will never re-calculate the packet. It will note this fact, and > mark this request as failed, thus it will run it through sending it to > the other end without modification, but after the process finishes, it > will throw away the result, and immediately start over with correct > destination address and correctly calculated > NAT_DETECTION_DESTINATION_IP address field. So, the first exchange is in fact timed out, but the client just ignores this fact and instead of deleting IKE SA it starts a new exchange with a next MID, right? Or do you mean that the new exchange will have the same MID? RFC is silent about this detail. Anyway, both cases lead to possible problems unless the responder is treated these exchanges specially and ignores some RFC7296 rules. For example, consider that the client first creates exchange with MID=5 and sends it to IP address IP1. Let's assume that the request reaches the responder and responders sends back a reply, but the reply packet cannot get through due to routing asymmetry and the client never got it. From responder's point of view the exchange has completed successfully and it marks MID=5 as used. If the client reuses this MID for the new exchange to IP2, then the responder according to RFC7296 throws away new request messages, as the MID=5 is already seen. On the other hand, if the first request fails because the request messages cannot reach the responder and the client uses next MID (6) for its second request and this request reaches the responder, then the responder would never got the request with MID=5, so it will have a gat in its window and according to the RFC7296 at some point it'll stop responding waiting for that MID. Well, these issues aren't concerned with our topic of discussion, they are just MOBIKE's complications not mentioned in the RFC. > > Sorry, but there are still some unclear places. > > And I don't think in its current form it suites well for building > > load-sharing cluster. You are trying to convince me otherwise, > > and I agree that it would probably _somehow_ work in _some_ > > situations, but the quality of such a solution leaves much to be desired, IMHO. > > Load balancing was explictly mentioned as out of scope for the MOBIKE, > we did say that the method we are using in MOBIKE should try to > support load balancing, but we never meant it to be generic solution > for load balancing. There are lots of additional issues in the load > balancing which needs to be solved than just this. > > I.e. RFC4621 says: > > Note that MOBIKE does not aim to support load balancing between > multiple IP addresses. That is, each peer uses only one of the > available address pairs at a given point in time. > ... > Load balancing is currently outside the scope of MOBIKE; however, > future work might include support for it. The selected format needs > to be flexible enough to include additional information in future > versions of the protocol (e.g., to enable load balancing). This may > be realized with an reserved field, which can later be used to > store additional information. As other information may arise that > may have to be tied to an address in the future, a reserved field > seems like a prudent design in any case. Excellent quote. That's exactly what I suggest - a "future work that includes support for load balancing in MOBIKE". And I don't understand why you oppose it so strongly. Regards, Valery. From nobody Sun Mar 18 05:17:59 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 237D112D7E5; Sun, 18 Mar 2018 05:17:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.75.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152137547214.15831.13662814454002809106.idtracker@ietfa.amsl.com> Date: Sun, 18 Mar 2018 05:17:52 -0700 Archived-At: Subject: [IPsec] The IPSECME WG has placed draft-moran-suit-architecture in state "Call For Adoption By WG Issued" 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: Sun, 18 Mar 2018 12:17:52 -0000 The IPSECME WG has placed draft-moran-suit-architecture in state Call For Adoption By WG Issued (entered by David Waltermire) The document is available at https://datatracker.ietf.org/doc/draft-moran-suit-architecture/ From nobody Sun Mar 18 05:26: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 DE5D612704A; Sun, 18 Mar 2018 05:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.089 X-Spam-Level: X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1sv0iio1jfzV; Sun, 18 Mar 2018 05:26:01 -0700 (PDT) Received: from GCC01-DM2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0090.outbound.protection.outlook.com [23.103.201.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 771D312778E; Sun, 18 Mar 2018 05:25:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MTE2TPNBA/jyQwZOEEXYEbYN22UhlcU7rlG6BxChJyc=; b=llcwuw5DKdYE/PH16l1tWELeEQ9kE90XYyfK4YsdU1L9h7eYVDlSGXWu/WEtzTCHbobhwBIm6lIF/qbd8PvS6B+vlEN8JLDqDdhPYwW6lVQZyjQBnIkIr4WVUIGUcXMZSRvuWgCpg9dBrOuR3gpv8A+nJ9hu4ERQryfvGZ1cLZQ= Received: from BL0PR0901MB2306.namprd09.prod.outlook.com (52.132.18.148) by BL0PR0901MB2306.namprd09.prod.outlook.com (52.132.18.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.588.14; Sun, 18 Mar 2018 12:25:44 +0000 Received: from BL0PR0901MB2306.namprd09.prod.outlook.com ([fe80::a493:b067:10e0:5d51]) by BL0PR0901MB2306.namprd09.prod.outlook.com ([fe80::a493:b067:10e0:5d51%13]) with mapi id 15.20.0588.016; Sun, 18 Mar 2018 12:25:44 +0000 From: "Waltermire, David A. (Fed)" To: IETF Secretariat , "ipsec@ietf.org" , "ipsecme-chairs@ietf.org" , "draft-moran-suit-architecture@ietf.org" Thread-Topic: The IPSECME WG has placed draft-moran-suit-architecture in state "Call For Adoption By WG Issued" Thread-Index: AQHTvrMqS0SLO4hE/0+bjR3+zfZ9WKPV6r5O Date: Sun, 18 Mar 2018 12:25:43 +0000 Message-ID: References: <152137547214.15831.13662814454002809106.idtracker@ietfa.amsl.com> In-Reply-To: <152137547214.15831.13662814454002809106.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.218.240] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR0901MB2306; 7:XwRE7tWaGsx+MPILOi6rWqg2IgArPauDdZw/L6zuqLCKcUpRXkq1nhR8g3i4UKkkmVB10vgGK8/+IAYa63pGrIL03sT0itnXaynCiT5HXl7As5UwbCT0mJklpS1my0sozjP/gTcACqGxdb0QGqAhnGVJALLpd86GJ7w1M2zfvBFyYEn/0J8AN5OonARmh2U9wvf0DVTjbk0JFywlNwMbyWkqUbPYYikPjP48qccHgOBfQzdBUS5xqpkYWOECwtFs x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 9f9dd749-f7b5-474a-a9e2-08d58ccb5ed9 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BL0PR0901MB2306; x-ms-traffictypediagnostic: BL0PR0901MB2306: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078)(219752817060721); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231221)(944501300)(52105095)(6055026)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:BL0PR0901MB2306; BCL:0; PCL:0; RULEID:; SRVR:BL0PR0901MB2306; x-forefront-prvs: 06157D541C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39380400002)(346002)(39850400004)(376002)(396003)(189003)(199004)(2906002)(3280700002)(102836004)(450100002)(26005)(186003)(2900100001)(3660700001)(106356001)(105586002)(33656002)(19627405001)(316002)(53936002)(229853002)(2501003)(5250100002)(6606003)(97736004)(55016002)(6246003)(6116002)(3846002)(236005)(6306002)(54896002)(8936002)(7736002)(76176011)(86362001)(66066001)(8676002)(966005)(110136005)(14454004)(478600001)(74316002)(45080400002)(68736007)(99286004)(7696005)(81156014)(5660300001)(25786009)(81166006)(53546011)(6506007)(2201001)(606006)(9686003)(2950100002)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR0901MB2306; H:BL0PR0901MB2306.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-microsoft-antispam-message-info: 9pEriD3v73RcvcNeNBdsNWhrfjYwrNCl2dmvGYvT+NHcHpz1E2fbosPE8Cg6/LgE+rd5NdhLFl2bHz++MmITC3jmilgLLduASnvuhT9OvdvEpXmAYKiBKfguc1oqBIUFFrO13A8sbncEhJnBUVFgUZbUAKFEmH5WchBvCVVEuzWkYSAmn5oBjkhsBhOTgMBgDvgGIdk3P5vEsttAF7tvO/U38pDi81N0IReOx4y+abRnjiuyjDEXParrGwoYlZJS3xzX/l2HlC5f6/1WMSzkHinWXdnqq9PkO+pgi1W5agNLshyl05cxH1w+EN2LA0M22iBPXl7SM7gMTjQ/uzFX/w== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BL0PR0901MB2306797F64BD9F7B00FC9467F0D50BL0PR0901MB2306_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 9f9dd749-f7b5-474a-a9e2-08d58ccb5ed9 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Mar 2018 12:25:43.9116 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR0901MB2306 Archived-At: Subject: Re: [IPsec] The IPSECME WG has placed draft-moran-suit-architecture in state "Call For Adoption By WG Issued" 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, 18 Mar 2018 12:26:04 -0000 --_000_BL0PR0901MB2306797F64BD9F7B00FC9467F0D50BL0PR0901MB2306_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please disregard this email. I assigned this draft to the wrong working gro= up. Deepest apologies for the spam. Regards, Dave ________________________________ From: IETF Secretariat Sent: Sunday, March 18, 2018 8:17:52 AM To: ipsec@ietf.org; ipsecme-chairs@ietf.org; draft-moran-suit-architecture@= ietf.org Subject: The IPSECME WG has placed draft-moran-suit-architecture in state "= Call For Adoption By WG Issued" The IPSECME WG has placed draft-moran-suit-architecture in state Call For Adoption By WG Issued (entered by David Waltermire) The document is available at https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatrac= ker.ietf.org%2Fdoc%2Fdraft-moran-suit-architecture%2F&data=3D02%7C01%7Cdavi= d.waltermire%40nist.gov%7C26911bde1e684d56acd808d58cca4610%7C2ab5d82fd8fa47= 97a93e054655c61dec%7C1%7C0%7C636569722744587165&sdata=3DbcAXchvDcj7rSTp6xHb= I2R6dgHI8QPM3UC%2F4FmSxGYo%3D&reserved=3D0 --_000_BL0PR0901MB2306797F64BD9F7B00FC9467F0D50BL0PR0901MB2306_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please disregard this ema= il. I assigned this draft to the wrong working group.


Deepest apologies for the= spam.


Regards,

Dave

From: IETF Secretariat <= ietf-secretariat-reply@ietf.org>
Sent: Sunday, March 18, 2018 8:17:52 AM
To: ipsec@ietf.org; ipsecme-chairs@ietf.org; draft-moran-suit-archit= ecture@ietf.org
Subject: The IPSECME WG has placed draft-moran-suit-architecture in = state "Call For Adoption By WG Issued"
 

The IPSECME WG has placed draft-moran-suit-architecture in state
Call For Adoption By WG Issued (entered by David Waltermire)

The document is available at
https= ://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatracker.i= etf.org%2Fdoc%2Fdraft-moran-suit-architecture%2F&data=3D02%7C01%7Cdavid= .waltermire%40nist.gov%7C26911bde1e684d56acd808d58cca4610%7C2ab5d82fd8fa479= 7a93e054655c61dec%7C1%7C0%7C636569722744587165&sdata=3DbcAXchvDcj7rSTp6= xHbI2R6dgHI8QPM3UC%2F4FmSxGYo%3D&reserved=3D0

--_000_BL0PR0901MB2306797F64BD9F7B00FC9467F0D50BL0PR0901MB2306_-- From nobody Mon Mar 19 05:54: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 ED28112DA06 for ; Mon, 19 Mar 2018 05:53:59 -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 nF1q5CXi-Hsu for ; Mon, 19 Mar 2018 05:53:58 -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 ACC7B1242F5 for ; Mon, 19 Mar 2018 05:53: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 w2JCrpSa024710 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 19 Mar 2018 14:53:54 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w2JCrkmS000196; Mon, 19 Mar 2018 14:53:46 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23215.45786.700149.963006@fireball.acr.fi> Date: Mon, 19 Mar 2018 14:53:46 +0200 From: Tero Kivinen To: ipsec@ietf.org 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: [IPsec] Final agenda, and slides submitted for IETF 101 London 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, 19 Mar 2018 12:54:02 -0000 The final agenda and all the slides have now been submitted to the datatracker meeting materials page. There might be updated versions of the slides later, but at least you should be able to check initial versions of them now. I would really like to people to read at least following drafts before meeting: WG: drafts draft-ietf-ipseme-qr-ikev2 draft-ietf-ipsecme-implicit-iv New items to be added to charter: draft-yeung-g-ikev2 draft-tjhai-ipsecme-hybrid-qske-ikev2 draft-sprasad-ipsecme-labeled-ipsec draft-smyslov-ipsecme-ikev2-aux Items not in the charter: draft-dschinazi-ipsecme-sa-init-privacy-addition draft-spiriyath-ipsecme-dynamic-ipsec-pmtu Meeting materials page can be found in the https://datatracker.ietf.org/meeting/101/session/ipsecme -- kivinen@iki.fi From nobody Tue Mar 20 06:07:34 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 0CA531270AE for ; Tue, 20 Mar 2018 06:07:33 -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.75.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152155125304.9901.13778976007840491342.idtracker@ietfa.amsl.com> Date: Tue, 20 Mar 2018 06:07:33 -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, 20 Mar 2018 13:07:33 -0000 Changed milestone "IETF Last Call on Using EdDSA in the IKEv2", resolved as "Done". URL: https://datatracker.ietf.org/wg/ipsecme/about/ From nobody Thu Mar 22 10:40: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 B7BA3126579 for ; Thu, 22 Mar 2018 10:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kviKIhmi8S9f for ; Thu, 22 Mar 2018 10:40:42 -0700 (PDT) Received: from GCC01-DM2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0726.outbound.protection.outlook.com [IPv6:2a01:111:f400:fd01::726]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36C89126DC2 for ; Thu, 22 Mar 2018 10:40:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MTF41UllgCNH8mZb9f4Zg34CaICHatU85pqBtB2ISJw=; b=JCBB4zFd43xCCYNvB2apVsZ5OjVM/7jjtNzTSP+eM1gsXdIrFyYHDp+6UX2koiVVJ1rHgzVqf1jMTNXWDMQLFl1L2k+RUBGr+cVTiBXS8xjEArM6k9LmRvjGmf32YaGcPEWI3+SrHkdBC8i4id99zqyw5HdCHuewNrjJdzjgKkI= Received: from BL0PR0901MB2306.namprd09.prod.outlook.com (52.132.18.148) by BL0PR0901MB2305.namprd09.prod.outlook.com (52.132.18.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.609.10; Thu, 22 Mar 2018 17:40:40 +0000 Received: from BL0PR0901MB2306.namprd09.prod.outlook.com ([fe80::a493:b067:10e0:5d51]) by BL0PR0901MB2306.namprd09.prod.outlook.com ([fe80::a493:b067:10e0:5d51%13]) with mapi id 15.20.0609.012; Thu, 22 Mar 2018 17:40:40 +0000 From: "Waltermire, David A. (Fed)" To: IPsecME WG Thread-Topic: Review of draft-ietf-ipsecme-implicit-iv-00 Thread-Index: AQHTwgSEuOTOxwh4J06DEid5JWV20Q== Date: Thu, 22 Mar 2018 17:40:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.220.105] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR0901MB2305; 7:S8NNROIWpjU9HrdXZmvdBqfkcuzUbMyzLhPox0oxv2I3YFMiKUqVF2NR5i6iUtGzrnbIKdpLOi+JAre2gzPN4P4c5kL4kHSSQbHg5lK9J1LzbHsaMoLkepDva3NUmeX5sbRNSzHySe1S99LQtXR2ibBZQL1R+OiAVFvOPGG+ikV32PbUQUzQ61mTh69tOxp59qjJWjyb9JpfYwDvGms/iEzrYj+VVgtGhzBhglHphfjSTwK6e2PKEPPD+jJwmDNa x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 3a0fbdee-ba19-4de2-b82f-08d5901c079d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BL0PR0901MB2305; x-ms-traffictypediagnostic: BL0PR0901MB2305: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231221)(944501327)(52105095)(93006095)(93001095)(6055026)(6041310)(20161123562045)(16040078)(6059035)(20161123558120)(20161123564045)(201703131423095)(201703011903075)(20161123555045)(201703061421075)(201703151056150)(201703061814153)(9142020)(20161123560045)(16045075)(16043105)(16046073)(6072148)(201708071742011); SRVR:BL0PR0901MB2305; BCL:0; PCL:0; RULEID:; SRVR:BL0PR0901MB2305; x-forefront-prvs: 0619D53754 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7966004)(366004)(346002)(396003)(376002)(39860400002)(34036004)(448600002)(189003)(199004)(5250100002)(55016002)(66066001)(25786009)(105586002)(81166006)(81156014)(586005)(8676002)(8936002)(6436002)(97736004)(38610400001)(7696005)(86362001)(2906002)(3280700002)(68736007)(3660700001)(186003)(26005)(102836004)(19627405001)(6506007)(3846002)(5660300001)(106356001)(6116002)(59450400001)(2900100001)(53936002)(9686003)(74316002)(99286004)(54896002)(14454004)(7736002)(33656002)(6606003)(6916009)(102460200001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR0901MB2305; H:BL0PR0901MB2306.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-microsoft-antispam-message-info: 2MDvfZSZIqUP29riy9UH1F/vANYJ32ABUbVmeF62d5MZR+8u7oVWUdY9foLmyozAaG6ajGtK31V7+QP1pf8hRLY1XThRDTbAR1aGQjUsIISPd5KxBQNJvPwyzr/bT/OEQhMuM39Xzu07IRPumrlDKmQk32K33c8QmWpSUH92V8LKLgwPNYSdlrUeD2M49sIjxU4D47PyAWGtriPikxCSMZXvpQEJPboywkHMuNcV+5fT/KcHgwqEgvChsbKAU48QNetyYCOlP+DmMZSrc58CMoshrBZBIE5I6FZh8hoPyH7l/dOOS3sWHLNsIhzX2LSnQMxbKodc3w09h2uZBzDOSw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BL0PR0901MB2306ADF2F6559C49728C95C8F0A90BL0PR0901MB2306_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 3a0fbdee-ba19-4de2-b82f-08d5901c079d X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2018 17:40:40.2804 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR0901MB2305 Archived-At: Subject: [IPsec] Review of draft-ietf-ipsecme-implicit-iv-00 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, 22 Mar 2018 17:40:45 -0000 --_000_BL0PR0901MB2306ADF2F6559C49728C95C8F0A90BL0PR0901MB2306_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable After reviewing this document, I think the draft looks fairly good. I found= a few small issues which should be addressed in the next revision. Comment= s on these issues are below. We adopted this draft at IETF 100 and I haven't seen any discussion on it s= ince. I'd like to see more review by the working group before sending it fo= rward to the IESG. Are there any concerns with starting a WG last call on t= he draft? -- Comments 1 - There are lowercase RFC2119 keywords in teh draft that don't appear to = be normative (e.g., "may" in section 5). You should use text from RFC8174 t= o indicate that lowercase versions of the keywords are not normative. Something like the following would work: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 5 - IIV is not spelled out on first use. 7 - "as long as certain security requirements are met" It would be useful t= o clarify what "certain" means here. Maybe a reference to section 2 would s= uffice? Or a reference to where the text in the next paragraph lands? See n= ext comment. 7 - The second paragraph contains normative requirements in the Security Co= nsiderations. This is typically frowned upon. It might make sense to move t= hese requirements to an earlier section (e.g., section 4). 9 - "woudl" replace with "would" Regards, Dave --_000_BL0PR0901MB2306ADF2F6559C49728C95C8F0A90BL0PR0901MB2306_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

After reviewing this docu= ment, I think the draft looks fairly good. I found a few small is= sues which should be addressed in the next revision. Comments on these issu= es are below.


We adopted this draft at IETF 100 and I haven't seen any discussion on i= t since. I'd like to see more review by the working group before sending it= forward to the IESG. Are there any concerns with starting a WG last call o= n the draft?


-- Comments

1 - There are lowercase RFC2119 keywords in teh draft that don't appear = to be normative (e.g., "may" in section 5). You should use text f= rom RFC8174 to indicate that lowercase versions of the
keywords are not normative.


Something like the following would work:


   The key words "MUST", "MUST NOT", "= ;REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED&= quot;, "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as= described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all=
   capitals, as shown here.


5 - IIV is not spelled out on first use.


7 - "as long as certain security requirements are met" It woul= d be useful to clarify what "certain" means here. Maybe a referen= ce to section 2 would suffice? Or a reference to where the text in the next= paragraph lands? See next comment.


7 - The second paragraph contains normative requirements in the Security= Considerations. This is typically frowned upon. It might make sense to mov= e these requirements to an earlier section (e.g., section 4).


9 - "woudl" replace with "would"


Regards,

Dave


--_000_BL0PR0901MB2306ADF2F6559C49728C95C8F0A90BL0PR0901MB2306_-- From nobody Fri Mar 23 15:25:56 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 0AB1812D94D; Fri, 23 Mar 2018 15:25:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.76.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152184395398.30051.15264290639332441621@ietfa.amsl.com> Date: Fri, 23 Mar 2018 15:25:54 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-implicit-iv-01.txt 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: Fri, 23 Mar 2018 22:25:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Implicit IV for Counter-based Ciphers in Encapsulating Security Payload (ESP) Authors : Daniel Migault Tobias Guggemos Yoav Nir Filename : draft-ietf-ipsecme-implicit-iv-01.txt Pages : 7 Date : 2018-03-23 Abstract: Encapsulating Security Payload (ESP) sends an initialization vector (IV) or nonce in each packet. The size of IV depends on the applied transform, being usually 8 or 16 octets for the transforms defined by the time this document is written. Some algorithms such as AES-GCM, AES-CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do not require an unpredictable nonce. When using such algorithms the packet counter value can be used to generate a nonce. This avoids sending the nonce itself, and savec in the case of AES-GCM, AES-CCM, AES-CTR and ChaCha20-Poly1305 8 octets per packet. This document describes how to do this. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-01 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-implicit-iv-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-implicit-iv-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Mar 23 15:33:57 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 92E2F12E034 for ; Fri, 23 Mar 2018 15:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrTwu23BkzB4 for ; Fri, 23 Mar 2018 15:33:53 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35ECB12D94D for ; Fri, 23 Mar 2018 15:33:53 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id m16-v6so16699060lfc.4 for ; Fri, 23 Mar 2018 15:33:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=YPdQq8GtgM92AH67Eo2Z6PDdKCpV3IZkgkuuSoOaJFM=; b=odYn+QHXI+8eCT+1gPJDKwgLsm8r2QQ8pEuJQo9mC5u4hU5cg6iVCJdjbvTr3gVhaB nNUL0ezuEPXHTpv+vu81S7PnfWi4VAoSPQ4ufufLkTP9LSyslaxczjYXJg5q9/5iLXy5 0at1G98v8GqIg2TeD2Bt7Ddf3FJg1MImHzFZcArmbsvOuqmIYzJ5Wkp5SLUFv+SvV5of 5nggMEWoaugbRWrl+B7CbyOEyvSXbfTV6IbGjuWaOsb1iaE6HQmPnxv66MKSr1KLoWz7 /vHXLi27GUXGD3VV0Q0LMSu7lgoPA3Zn9qK53K8hicJKgvTC5LwBoK4w1XiRgfQ04A1C L4IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=YPdQq8GtgM92AH67Eo2Z6PDdKCpV3IZkgkuuSoOaJFM=; b=FgdL/ORXrhnzIao/hKzNIFUOKcaOgll607GAqIsA+2psLAntXiARpKhgHkcMvHZMba Al2pFQL8PYNd8tIEfgb4hOgbYA0UHrpF91cy+MUdQAXc1jkBmoJmQAXe0DjkMfoHQKB9 mCZZQm62iBFqQp0fV3W9afBlwaj11xuqLQoAmupSSd8qjRIeykpsBVsOnM+qDkbT+By/ sLKAaFrjBI+yVHCS8D14HF2I7uOimDNTkDlnh7mtpNHbpKWSA/IYuAgff4wEULa3sla+ Z1L3fX5gp4d9g7WXH9sKw+C6uLOgIXCbiS9F8bj0QpryRoO3nv6mddcV65OwQu3mrP6I yuZA== X-Gm-Message-State: AElRT7FKuH4t1gXWPRWT4iibibPd3yVNqyP9WFNsctqLloe3UaDEwB2j PN58q4Fpip3cT6IILhVIzIeKJXhn8cndierFwA0= X-Google-Smtp-Source: AG47ELt4PUXBmCiVelWNL9oirA4Wesk7SwBHhPyGWqeU52LJTow5pc43TeE/KVcan1kcsOvL1OVi2Qe1ScRjJTqE96g= X-Received: by 10.46.122.15 with SMTP id v15mr5366743ljc.141.1521844431479; Fri, 23 Mar 2018 15:33:51 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.129.5 with HTTP; Fri, 23 Mar 2018 15:33:50 -0700 (PDT) In-Reply-To: References: From: Daniel Migault Date: Fri, 23 Mar 2018 18:33:50 -0400 X-Google-Sender-Auth: ipxKi491hrgbfC_ynjO9y6zX4Bs Message-ID: To: "Waltermire, David A. (Fed)" Cc: IPsecME WG Content-Type: multipart/alternative; boundary="f4f5e8067d90bde70e05681c047c" Archived-At: Subject: Re: [IPsec] Review of draft-ietf-ipsecme-implicit-iv-00 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, 23 Mar 2018 22:33:55 -0000 --f4f5e8067d90bde70e05681c047c Content-Type: text/plain; charset="UTF-8" Hi David, Thank you for the review. I believe the version 01 [1] addresses your concerns. Yours, Daniel [1] https://tools.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-implicit-iv-01.txt On Thu, Mar 22, 2018 at 1:40 PM, Waltermire, David A. (Fed) < david.waltermire@nist.gov> wrote: > After reviewing this document, I think the draft looks fairly good. I > found a few small issues which should be addressed in the next revision. > Comments on these issues are below. > > > We adopted this draft at IETF 100 and I haven't seen any discussion on it > since. I'd like to see more review by the working group before sending it > forward to the IESG. Are there any concerns with starting a WG last call on > the draft? > > > -- Comments > > 1 - There are lowercase RFC2119 keywords in teh draft that don't appear to > be normative (e.g., "may" in section 5). You should use text from RFC8174 > to indicate that lowercase versions of the > keywords are not normative. > > > Something like the following would work: > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in BCP > 14 [RFC2119] [RFC8174] when, and only when, they appear in all > capitals, as shown here. > > > 5 - IIV is not spelled out on first use. > > > 7 - "as long as certain security requirements are met" It would be useful > to clarify what "certain" means here. Maybe a reference to section 2 would > suffice? Or a reference to where the text in the next paragraph lands? See > next comment. > > > 7 - The second paragraph contains normative requirements in the Security > Considerations. This is typically frowned upon. It might make sense to move > these requirements to an earlier section (e.g., section 4). > > > 9 - "woudl" replace with "would" > > > Regards, > > Dave > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > --f4f5e8067d90bde70e05681c047c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi David,

Thank you for the r= eview. I believe the version 01 [1] addresses your concerns.

Yours,=
Daniel



On Thu, Mar 22,= 2018 at 1:40 PM, Waltermire, David A. (Fed) <david.waltermire@ni= st.gov> wrote:

After reviewing this document= , I think the draft looks fairly good. I found=C2=A0a few=C2=A0small issues= which should be addressed in the next revision. Comments on these issues a= re below.


We adopted this draft at IETF 100 and I haven't seen any discussion = on it since. I'd like to see more review by the working group before se= nding it forward to the IESG. Are there any concerns with starting a WG las= t call on the draft?


-- Comments

1 - There are lowercase RFC2119 keywords in teh draft that don't app= ear to be normative (e.g., "may" in section 5). You should use te= xt from RFC8174 to indicate that lowercase versions of the
keywords are not normative.


Something like the following would work:


=C2=A0=C2=A0 The key words "MUST", "MUST NOT", "= ;REQUIRED", "SHALL", "SHALL NOT",
=C2=A0=C2=A0 "SHOULD", "SHOULD NOT", "RECOMMENDED&= quot;, "NOT RECOMMENDED", "MAY", and
=C2=A0=C2=A0 "OPTIONAL" in this document are to be interpreted as= described in BCP
=C2=A0=C2=A0 14 [RFC2119] [RFC8174] when, and only when, they appear in all=
=C2=A0=C2=A0 capitals, as shown here.


5 - IIV is not spelled out on first use.


7 - "as long as certain security requirements are met" It woul= d be useful to clarify what "certain" means here. Maybe a referen= ce to section 2 would suffice? Or a reference to where the text in the next= paragraph lands? See next comment.


7 - The second paragraph contains normative requirements in the Security= Considerations. This is typically frowned upon. It might make sense to mov= e these requirements to an earlier section (e.g., section 4).


9 - "woudl" replace with "would"


Regards,

Dave



_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


--f4f5e8067d90bde70e05681c047c-- From nobody Sun Mar 25 10:36:31 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 3A6311200F1 for ; Sun, 25 Mar 2018 10:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 K0eGGg18Gdin for ; Sun, 25 Mar 2018 10:36:28 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92816126DFB for ; Sun, 25 Mar 2018 10:36:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3987; q=dns/txt; s=iport; t=1521999388; x=1523208988; h=from:to:subject:date:message-id:mime-version; bh=xH1Mc/18SlvTHVmAO27d0tTXS4Whig3Ar9Hlz+W3REs=; b=f5WqYxDUSCbTnd06M5P/d1AthRrGPB03kDDmUKpyEzAPM2D8ajmMRPEq t2p501bdgESz6sJgsdScU6Z0a8bKNj2oRKg5uE/Tfb9Byf9a0OKf4S/Tt bi9W9FjcZAVTmSetr/MSwpJiE2FJFGbrDNbhiHGorL7sb2+UmQdfLlfz3 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAQD43bda/40NJK1eGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJNdGFwMotSjQ2CaRyNbIRlggYLiHchNBgBAgEBAQEBAQJ?= =?us-ascii?q?rKIVZXgEMdCYBBBuEImStGog/ghqHWIFUQIEMglMGhH6FeAOXPwgCjieMQY9?= =?us-ascii?q?PAhETAYEkARw4gVJwFYJ+kE+HKIEXAQE?= X-IronPort-AV: E=Sophos;i="5.48,361,1517875200"; d="scan'208,217";a="372114667" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Mar 2018 17:36:06 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id w2PHa5jH020255 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sun, 25 Mar 2018 17:36:06 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sun, 25 Mar 2018 13:36:05 -0400 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1320.000; Sun, 25 Mar 2018 13:36:05 -0400 From: "Scott Fluhrer (sfluhrer)" To: "IPsecme WG (ipsec@ietf.org)" Thread-Topic: Clarification on my comments during the WG about possible KE payloads > 64k Thread-Index: AdPEW8VykPpS3KUtT66wGmoEAi02VQ== Date: Sun, 25 Mar 2018 17:36:05 +0000 Message-ID: <4617c0b8f86c4269a1ad3f8adf0097c3@XCH-RTP-006.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.53] Content-Type: multipart/alternative; boundary="_000_4617c0b8f86c4269a1ad3f8adf0097c3XCHRTP006ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [IPsec] Clarification on my comments during the WG about possible KE payloads > 64k 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, 25 Mar 2018 17:36:30 -0000 --_000_4617c0b8f86c4269a1ad3f8adf0097c3XCHRTP006ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable During the WG meeting in London, somebody (I forget who) asked me whether K= E payloads larger than 64k. I thought I ought to clarify matters (as they = are more complex than the brief answer I gave indicated). Of the proposed postquantum key exchange (and public key encryption algorit= hms, which can be used to transport keys) submitted to NIST, the majority o= f them have key shares (or public keys/ciphertexts) smaller than 64k; there= are a handful that are larger. Now, it is possible (albeit unlikely) that= all the algorithms with key shares < 64k will be broken; unless this happe= ns, it would be reasonable (IMHO) that we mandate that any algorithm he all= ow have a KE payload that fits within 64k. Now, in the event that we feel = the need to support larger key shares, there are possible ways to support t= hat; I don't feel that we need to talk about those options now. --_000_4617c0b8f86c4269a1ad3f8adf0097c3XCHRTP006ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

During the WG meeting in London, somebody (I forget = who) asked me whether KE payloads larger than 64k.  I thought I ought = to clarify matters (as they are more complex than the brief answer I gave i= ndicated).

 

Of the proposed postquantum key exchange (and public= key encryption algorithms, which can be used to transport keys) submitted = to NIST, the majority of them have key shares (or public keys/ciphertexts) = smaller than 64k; there are a handful that are larger.  Now, it is possible (albeit unlikely) that all the = algorithms with key shares < 64k will be broken; unless this happens, it= would be reasonable (IMHO) that we mandate that any algorithm he allow hav= e a KE payload that fits within 64k.  Now, in the event that we feel the need to support larger key shares, there are= possible ways to support that; I don’t feel that we need to talk abo= ut those options now.

--_000_4617c0b8f86c4269a1ad3f8adf0097c3XCHRTP006ciscocom_-- From nobody Sun Mar 25 11:10: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 62947127337 for ; Sun, 25 Mar 2018 11:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 GiieVUYh6Xaj for ; Sun, 25 Mar 2018 11:10:37 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44A31124BFA for ; Sun, 25 Mar 2018 11:10:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8685; q=dns/txt; s=iport; t=1522001437; x=1523211037; h=from:to:subject:date:message-id:mime-version; bh=+XvrDA2I9rtouclNSCAgxpDO2HoXLs+mDXpnhh5KyfM=; b=bKZ5hx6OLF0bzFhQkKTKBOmmHwDSRcjwGXyv5ZURQMb50O06yRM5DTA/ Ksni9oiKRWMkNnGbnwohh6i4kxJF5+tigZe3SkBSTBA/FhfPlxHB4uypl 9u0Xiaodono9vWM355z4v3uPrKl0cnnrJrihBzXDBFNLxy0DjBt9pRItO Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAQCU5Lda/51dJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJNdGFwMotSjQ2DBY1shGWCBguIdyE0GAECAQEBAQEBAmsohVl?= =?us-ascii?q?eAYEAJgEEG4QiZK0YiD+CGodYgVRAiF+FfAOXPwgCgTGMdoxBj08CERMBgSQBH?= =?us-ascii?q?DiBUnAVOoJEgiAYjheFeYEvgRcBAQ?= X-IronPort-AV: E=Sophos; i="5.48,361,1517875200"; d="scan'208,217"; a="89213586" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Mar 2018 18:10:36 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id w2PIAZUw011714 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sun, 25 Mar 2018 18:10:35 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sun, 25 Mar 2018 14:10:35 -0400 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1320.000; Sun, 25 Mar 2018 14:10:34 -0400 From: "Scott Fluhrer (sfluhrer)" To: "IPsecme WG (ipsec@ietf.org)" Thread-Topic: Comments on draft-ietf-ipsecme-implicit-iv Thread-Index: AdPEYabaslSsDVKJSGW5Eb13uZxLnQ== Date: Sun, 25 Mar 2018 18:10:34 +0000 Message-ID: <4c9091a6469945478d0fbce30447da94@XCH-RTP-006.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.53] Content-Type: multipart/alternative; boundary="_000_4c9091a6469945478d0fbce30447da94XCHRTP006ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [IPsec] Comments on draft-ietf-ipsecme-implicit-iv 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, 25 Mar 2018 18:10:39 -0000 --_000_4c9091a6469945478d0fbce30447da94XCHRTP006ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable - Section 4: "Section 3.5 of [RFC6407] explains how repetition MAY= BE prevented by using a prefix for each group member" Actually, RFC6407 just refers to RFC6054; that has the SID in the top 8 bit= s of the 8 byte sequence number. Used literally, this doesn't work, as the= top 8 bits of the 8 byte sequence number are never expressed in the packet= in implicit-iv. You could put them in the top 8 bits of the 4 byte sequen= ce number (which means you can't use ESN, but it didn't work in the multise= nder case anyways), but that would mean that each sender would be limited t= o 16M packets. I believe that these details are distinct enough that (if th= is is considered a viable alternative) they should be explicitly listed (in= cluding the 16M packet restriction). Alternatively, we can just forbid thi= s transform in the multisender case. - Section 6: "The rules of SA payload processing ensure that the r= esponder will never send an SA payload containing the IIV indicator to an i= nitiator that does not support IIV" I believe that this is stale text; the current draft doesn't use an indicat= or; instead, it defines separate transforms IDs. - Section 8 has "AES-CTR ... [is] likely to implement the implicit= IV described in this document"; however the transform ENCR_AES_CTR_IIV is = not defined. Is this intended? Should we either remove the AES-CTR algori= thm from the list of "likely to implement", or should we actually define th= e transform id for it? --_000_4c9091a6469945478d0fbce30447da94XCHRTP006ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

-     &= nbsp;    Section 4: “Section 3.5 of [RFC6407] explains= how repetition MAY BE prevented by using a prefix for each group member= 221;

Actually, RFC6407 just re= fers to RFC6054; that has the SID in the top 8 bits of the 8 byte sequence = number.  Used literally, this doesn’t work, as the top 8 bits of= the 8 byte sequence number are never expressed in the packet in implicit-iv.  You could put them in the top 8 bits o= f the 4 byte sequence number (which means you can’t use ESN, but it d= idn’t work in the multisender case anyways), but that would mean that= each sender would be limited to 16M packets. I believe that these details are distinct enough that (if this is considered a viabl= e alternative) they should be explicitly listed (including the 16M packet r= estriction).  Alternatively, we can just forbid this transform in the = multisender case.

 

-     &= nbsp;    Section 6: “The rules of SA payload processin= g ensure that the responder will never send an SA payload containing the II= V indicator to an initiator that does not support IIV”

I believe that this is stale text; the curren= t draft doesn’t use an indicator; instead, it defines separate transf= orms IDs.

 

-     &= nbsp;    Section 8 has “AES-CTR … [is] likely to= implement the implicit IV described in this document”; however the t= ransform ENCR_AES_CTR_IIV is not defined.  Is this intended?  Sho= uld we either remove the AES-CTR algorithm from the list of “likely to implement”, or should we actually define the transf= orm id for it?

 

--_000_4c9091a6469945478d0fbce30447da94XCHRTP006ciscocom_-- From nobody Sun Mar 25 12:01: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 673E3127AD4 for ; Sun, 25 Mar 2018 12:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 T69v8c_y2Apu for ; Sun, 25 Mar 2018 12:01:29 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E10E126CC7 for ; Sun, 25 Mar 2018 12:01:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7089; q=dns/txt; s=iport; t=1522004489; x=1523214089; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=VCHPIbcl8vVgRc6pTC1xdAR1o4aLh16rtF8oHHS4VT8=; b=Fsn3qPMTpnyIreKP+3ZylTIosYyFqMc/4U3Z48yPQCPZAyahNDqTkTjD PDJv0qFhOJD5tNncaJQL4LSOfEu2y0PlGLsqS5n13WNneJaWwlXBqbk8R 3p5gGnn4gwyZ4j0mwDdUEaMlKmvtyg/hMeLIKHrJ003g8wuDuQhyoMvYm 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKAQDV8Lda/4cNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJNdGFwKAqLUo0NgXSBEY1shGWCBguFBQKDcCE0GAECAQEBAQE?= =?us-ascii?q?BAmsohSUBAQEELVwCAQgRBAEBLzIdCAEBBBMIhCJkrRqIP4Iah1iBVECEE4pIA?= =?us-ascii?q?5c/CAKOJ4xBj08CERMBgSQBHDiBUnAVgn2CIRiOF2+GOYEXAQE?= X-IronPort-AV: E=Sophos; i="5.48,361,1517875200"; d="scan'208,217"; a="89191460" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Mar 2018 19:01:28 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w2PJ1SSR012933 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sun, 25 Mar 2018 19:01:28 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sun, 25 Mar 2018 15:01:27 -0400 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1320.000; Sun, 25 Mar 2018 15:01:27 -0400 From: "Scott Fluhrer (sfluhrer)" To: "IPsecme WG (ipsec@ietf.org)" Thread-Topic: Comments on draft-ietf-ipsecme-implicit-iv Thread-Index: AdPEYabaslSsDVKJSGW5Eb13uZxLnQACdpsg Date: Sun, 25 Mar 2018 19:01:27 +0000 Message-ID: <9b8f999cbed84fc6b1b84267ecac2b5f@XCH-RTP-006.cisco.com> References: <4c9091a6469945478d0fbce30447da94@XCH-RTP-006.cisco.com> In-Reply-To: <4c9091a6469945478d0fbce30447da94@XCH-RTP-006.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.53] Content-Type: multipart/alternative; boundary="_000_9b8f999cbed84fc6b1b84267ecac2b5fXCHRTP006ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-implicit-iv 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, 25 Mar 2018 19:01:31 -0000 --_000_9b8f999cbed84fc6b1b84267ecac2b5fXCHRTP006ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Rereading this, I have to do one correction: From: IPsec On Behalf Of Scott Fluhrer (sfluhrer) Sent: Sunday, March 25, 2018 2:11 PM To: IPsecme WG (ipsec@ietf.org) Subject: [IPsec] Comments on draft-ietf-ipsecme-implicit-iv - Section 4: "Section 3.5 of [RFC6407] explains how repetition MAY= BE prevented by using a prefix for each group member" Actually, RFC6407 just refers to RFC6054; that has the SID in the top 8 bit= s of the 8 byte sequence number. I meant "the top 8 bits of the 8 byte explicit IV"... Sorry about that... --_000_9b8f999cbed84fc6b1b84267ecac2b5fXCHRTP006ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Rereading this, I have= to do one correction:<= o:p>

 

From: IPsec <ipsec-bounces@ietf.org> On Behalf Of Scott Fluhrer (sfluhrer)
Sent: Sunday, March 25, 2018 2:11 PM
To: IPsecme WG (ipsec@ietf.org) <ipsec@ietf.org>
Subject: [IPsec] Comments on draft-ietf-ipsecme-implicit-iv

 

-     &= nbsp;    Section 4: “Section 3.5 of [RFC6407] explains= how repetition MAY BE prevented by using a prefix for each group member= 221;

Actually, RFC6407 just re= fers to RFC6054; that has the SID in the top 8 bits of the 8 byte sequence = number. 

I meant “the top= 8 bits of the 8 byte explicit IV”…

 

Sorry about that…= ;

--_000_9b8f999cbed84fc6b1b84267ecac2b5fXCHRTP006ciscocom_-- From nobody Sun Mar 25 13:00: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 62EB3126CC7 for ; Sun, 25 Mar 2018 13:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BlywQOf2kHFl for ; Sun, 25 Mar 2018 13:00:18 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 A7C7A124234 for ; Sun, 25 Mar 2018 13:00:17 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id e194so11729382wmd.3 for ; Sun, 25 Mar 2018 13:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=xqxPi8AWEk/bO9Gwt3izorbIj0No0Z5ZDPnt2+2FfEU=; b=d5uQUeuwFLdJzZzzOz8PwuDsozyPHdEDnTdzIaYR63ZguQPoKiCURJkDkrU7fbxDhu ZKnxkyN62CmlMEU7VlZJZsdMZOe4TwzindOt3omzRqthA0zGnChKDRj0zO6Qv8E1+3ZF 98cYlolgduViU7h64bheE6W3tdgU7QunDLLrCMslohhI9RV0RDnYYJLrlnNgUtGWqPd1 tf/TSRITKEgwv95w45eP0YBvsBVzJZgmT5QoNLH0LjU7qxebWjxfCLYXOJmMCpJ936o0 9mITBaaNwqKnVLwY0+2har1dWZo35fgcMGHKTAzsWTDJPnaN6tbXV2Pb0YSVvLWI5k0Q kOBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=xqxPi8AWEk/bO9Gwt3izorbIj0No0Z5ZDPnt2+2FfEU=; b=Qn5l1zUDiI+QOQW8WgQljyE0YLBdQvaJQd797KNkyrAfe9/dw0oA0zN8X8YEuIE1J9 h7r1leEzEBBDcYhVMb7EIjtcS+GocS1Al2crO37+Ir1QxGflA11OjeHdSje1kVZQR4kA PiCJF/V4aeMW0XCcg7lMU8nxpWmci5wS3YwK0+62kplqoudqJH78PQeYm6KVyC2p0DLG VRAvr8tl2L1d+NX/qvuG3E2RaqGpr77DpEhw3xMBKJ9yWMO4ydam8/DUT8uCWJqPzrU/ wvw1HDblWjcf2bSYDcnCPr8fuf1l9EYHmE+NwZpCOUc1qPZjRvHQJaS9y5cthYNFNUOt 3DHw== X-Gm-Message-State: AElRT7FNT5oJQjmmAYjbqH9QWnZqSgPNfsZjscKl9CvxHXDOovpVHhB6 8TZ4goJgvTk5aQx+mde4DRryGO3z X-Google-Smtp-Source: AG47ELtQQEw/ljaijvrw04jEqSdGvoSpvYPkOpXwyiXRB+ByGQFZnzSxQX5cWmMeq8mCmE+Nl4wp5A== X-Received: by 10.80.216.196 with SMTP id y4mr15253650edj.260.1522008016219; Sun, 25 Mar 2018 13:00:16 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id z4sm9153240edm.44.2018.03.25.13.00.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Mar 2018 13:00:14 -0700 (PDT) From: Yoav Nir Message-Id: <2772CD9B-9C7F-4DCC-B9FB-ED7CCF6BE3FD@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_01DEA984-E068-4265-8A70-6EF653FEB49D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Sun, 25 Mar 2018 23:00:12 +0300 In-Reply-To: <4617c0b8f86c4269a1ad3f8adf0097c3@XCH-RTP-006.cisco.com> Cc: "IPsecme WG (ipsec@ietf.org)" To: "Scott Fluhrer (sfluhrer)" References: <4617c0b8f86c4269a1ad3f8adf0097c3@XCH-RTP-006.cisco.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [IPsec] Clarification on my comments during the WG about possible KE payloads > 64k 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, 25 Mar 2018 20:00:20 -0000 --Apple-Mail=_01DEA984-E068-4265-8A70-6EF653FEB49D Content-Type: multipart/alternative; boundary="Apple-Mail=_6F5B060C-AFB1-45EE-83A4-9D438296A34D" --Apple-Mail=_6F5B060C-AFB1-45EE-83A4-9D438296A34D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Scott. That was me. When they started talking about about PQC a decade ago, = they mentioned algorithms like McEliece with public keys around 1MB. Not that this is a deal-killer. If necessary, we would come up with an = IKE extension to have =E2=80=9Cjumbo-sized payloads=E2=80=9D that had = 24-bit lengths. IKE over TCP (RFC 8229) can handle this easily. But anyway, since the current state of the art seems to not need such an = extension, I guess there=E2=80=99s no point it bringing this up now. Yoav > On 25 Mar 2018, at 20:36, Scott Fluhrer (sfluhrer) = wrote: >=20 > During the WG meeting in London, somebody (I forget who) asked me = whether KE payloads larger than 64k. I thought I ought to clarify = matters (as they are more complex than the brief answer I gave = indicated). >=20 > Of the proposed postquantum key exchange (and public key encryption = algorithms, which can be used to transport keys) submitted to NIST, the = majority of them have key shares (or public keys/ciphertexts) smaller = than 64k; there are a handful that are larger. Now, it is possible = (albeit unlikely) that all the algorithms with key shares < 64k will be = broken; unless this happens, it would be reasonable (IMHO) that we = mandate that any algorithm he allow have a KE payload that fits within = 64k. Now, in the event that we feel the need to support larger key = shares, there are possible ways to support that; I don=E2=80=99t feel = that we need to talk about those options now. > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec = --Apple-Mail=_6F5B060C-AFB1-45EE-83A4-9D438296A34D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, = Scott.

That was me. = When they started talking about about PQC a decade ago, they mentioned = algorithms like McEliece with public keys around 1MB.  

Not that this is a = deal-killer. If necessary, we would come up with an IKE extension to = have =E2=80=9Cjumbo-sized payloads=E2=80=9D that had 24-bit lengths. IKE = over TCP (RFC 8229) can handle this easily.

But anyway, since the current state of = the art seems to not need such an extension, I guess there=E2=80=99s no = point it bringing this up now.

Yoav

On 25 = Mar 2018, at 20:36, Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com> = wrote:

During the WG meeting in London, somebody (I forget who) = asked me whether KE payloads larger than 64k.  I thought I ought to = clarify matters (as they are more complex than the brief answer I gave = indicated).
 
Of the proposed postquantum key exchange (and public key = encryption algorithms, which can be used to transport keys) submitted to = NIST, the majority of them have key shares (or public keys/ciphertexts) = smaller than 64k; there are a handful that are larger.  Now, it is = possible (albeit unlikely) that all the algorithms with key shares < = 64k will be broken; unless this happens, it would be reasonable (IMHO) = that we mandate that any algorithm he allow have a KE payload that fits = within 64k.  Now, in the event that we feel the need to support = larger key shares, there are possible ways to support that; I don=E2=80=99= t feel that we need to talk about those options now.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

= --Apple-Mail=_6F5B060C-AFB1-45EE-83A4-9D438296A34D-- --Apple-Mail=_01DEA984-E068-4265-8A70-6EF653FEB49D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE9OWnAqT2UIzvSbaAuEkLFQpYzJkFAlq3/8wACgkQuEkLFQpY zJl8Swf/XJ4lwgwp4HhUx9dCKqY5+uS+mvd9zTA57xusD3jkQjkkyqVK27w3MT3m WVCNdkUUiEbyYJroHWlV1rR50dAIRUf/0dTOVkLNlKrieNWLLMw+DceLmv6ra4R6 tQxY6+fWDH4/SLfDJpVFC+PLE8Cgew4cqKQKudBJYt9BKgd5NsTv3OB88V9KDmOY j1LzWT+uHEbiV6DDP64/kgbQxum2woUNRmF5pFRL8UWx0ybG099zX9LNwbuWxDW9 wz1xtJrzd3SNJ7DCCb6mzsmvG4GsKM5nIfjS9XYbVbzhyjM8am401k+amKaMmlYz Ntgahw2wE4jd+yVuS4y9R9HRq7GzcA== =1D5r -----END PGP SIGNATURE----- --Apple-Mail=_01DEA984-E068-4265-8A70-6EF653FEB49D-- From nobody Mon Mar 26 00:27: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 1044E1252BA for ; Mon, 26 Mar 2018 00:27:50 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 SPzr8QjiehND for ; Mon, 26 Mar 2018 00:27:48 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A9AC1243F6 for ; Mon, 26 Mar 2018 00:27:48 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id j68-v6so26578026lfg.13 for ; Mon, 26 Mar 2018 00:27:48 -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:thread-index:content-language; bh=IX3LHIDa9ZzD6CdWn2nGPJbCbMFt3att8wePoTmT9gg=; b=Eiflw9wTacru8t1+dewX0+X3tMVbPttXL9qNMUPEq+LZqO/H3/QGVEWUyNUna+UieG cdYYpLDDO6BRa3cpHgWBTOSgXPoooyF1HPdpOlEzFF+tOOiA8O3vgbVEPnNpv7z1Of6F ZTNXt6N0KQgp4B8hbJ3NoXEH/1nVU/PAczZw9JWwaCUaImK+mIFlqi1xvYMpbXJB5AT2 IRVheR+uprMC3I00CsKbEYV9fpC+Z56MAsm8jNzKs5rSGsy4x5N5eoUtHnXEFpsqjqeI pLyjfMDvfXoe42iMRzgQQVNZr1Y5kRz26UAPdpNSwFolmZvVtXj1AK54gxElTywyiCYX E9eQ== 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:thread-index:content-language; bh=IX3LHIDa9ZzD6CdWn2nGPJbCbMFt3att8wePoTmT9gg=; b=FObEw2bQyaar6BuhRqUQs7ohZe8NAC9HJhG4giHiSvMyyKcguqNttscmmnacT7FnOa uoTmeiE7Vrswj69SRpBBHXoo/QkwlosQxOgOFcC221RYCbDWm6PF8luuA73hSywDvgrz KQVRA0cqWoYA0HT7XOJbom9WBBp+TNsTUJsuMWE49Np6Ld6NTqNvQpgGkQRKStJ7+rtX 5qDlIHN48rYRPDNxHs4NsjmI9MXmoHpyktomJWX78Xh+O4hJfoOm7DXeYwvVXnCvsG4b q9Fbww20g2ojao6lFop4I1LvjOXjJB9kDQN/BeEgg6CH65ydiK/Z4tgjL7LoIxb2IVek oX4Q== X-Gm-Message-State: AElRT7HiST2o8vnUJO9zVvaQ1zOps4SwUYVv+76y5QwMv8LrMHV/lBbe isxt9BQA5eNeVEO280vWe1982g== X-Google-Smtp-Source: AG47ELs06hHSR0vXgmBTPwR5/wNV4tLeQTsWLSsX7rk7JcHLRPru9/bztOoyqgGHpVQXFgi101LqeQ== X-Received: by 10.46.151.72 with SMTP id f8mr18315339ljj.53.1522049266179; Mon, 26 Mar 2018 00:27:46 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id b4sm1129264ljk.64.2018.03.26.00.27.44 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 26 Mar 2018 00:27:45 -0700 (PDT) From: "Valery Smyslov" To: "'Yoav Nir'" , "'Scott Fluhrer \(sfluhrer\)'" Cc: "'IPsecme WG'" References: <4617c0b8f86c4269a1ad3f8adf0097c3@XCH-RTP-006.cisco.com> <2772CD9B-9C7F-4DCC-B9FB-ED7CCF6BE3FD@gmail.com> In-Reply-To: <2772CD9B-9C7F-4DCC-B9FB-ED7CCF6BE3FD@gmail.com> Date: Mon, 26 Mar 2018 10:27:45 +0300 Message-ID: <0aa201d3c4d3$ef924340$ceb6c9c0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0AA3_01D3C4ED.14E71C60" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNFS3lY4miM3I5hdH2aVZL3gQjT9gHTkrtLoPByBLA= Content-Language: ru Archived-At: Subject: Re: [IPsec] Clarification on my comments during the WG about possible KE payloads > 64k 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, 26 Mar 2018 07:27:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0AA3_01D3C4ED.14E71C60 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Yoav, =20 just for clarification: =20 That was me. When they started talking about about PQC a decade ago, = they mentioned algorithms like McEliece with public keys around 1MB. =20 =20 Not that this is a deal-killer. If necessary, we would come up with an = IKE extension to have =E2=80=9Cjumbo-sized payloads=E2=80=9D that had = 24-bit lengths. IKE over TCP (RFC 8229) can handle this easily. =20 Actually, not so easily. Despite the fact that IKE Message = header has a length field of 32 bits,=20 the message prefix in RFC 8229 is only 16 bits in size, so no = single IKE message transferred over TCP can be greater than 64K. IKE fragmentation could help = in this case, but RFC 8229 says that =E2=80=9Cimplementation SHOULD NOT = send fragments when going over a TCP=E2=80=9D. However the good news is that =E2=80=9Cit MUST support = receiving fragments.=E2=80=9D So we just need to violate that SHOULD. =20 Regards, Valery. =20 =20 =20 But anyway, since the current state of the art seems to not need such an = extension, I guess there=E2=80=99s no point it bringing this up now. =20 Yoav On 25 Mar 2018, at 20:36, Scott Fluhrer (sfluhrer) = wrote: =20 During the WG meeting in London, somebody (I forget who) asked me = whether KE payloads larger than 64k. I thought I ought to clarify = matters (as they are more complex than the brief answer I gave = indicated). =20 Of the proposed postquantum key exchange (and public key encryption = algorithms, which can be used to transport keys) submitted to NIST, the = majority of them have key shares (or public keys/ciphertexts) smaller = than 64k; there are a handful that are larger. Now, it is possible = (albeit unlikely) that all the algorithms with key shares < 64k will be = broken; unless this happens, it would be reasonable (IMHO) that we = mandate that any algorithm he allow have a KE payload that fits within = 64k. Now, in the event that we feel the need to support larger key = shares, there are possible ways to support that; I don=E2=80=99t feel = that we need to talk about those options now. _______________________________________________ IPsec mailing list IPsec@ietf.org = https://www.ietf.org/mailman/listinfo/ipsec =20 ------=_NextPart_000_0AA3_01D3C4ED.14E71C60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Yoav,

 

just for clarification:

 

That was me. When they started talking = about about PQC a decade ago, they mentioned algorithms like McEliece = with public keys around 1MB.  

 

Not that this is a deal-killer. If necessary, we would = come up with an IKE extension to have =E2=80=9Cjumbo-sized = payloads=E2=80=9D that had 24-bit lengths. IKE over TCP (RFC 8229) can = handle this easily.

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Actually, not = so easily. Despite the fact that IKE Message header has a length field = of 32 bits,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the message = prefix in RFC 8229 is only 16 bits in size, so no single IKE message = transferred

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 over TCP can = be greater than 64K. IKE fragmentation could help in this = case,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 but RFC 8229 says that =E2=80=9Cimplementation SHOULD NOT send fragments when =
going over a TCP=E2=80=9D.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 However the = good news is that =E2=80=9Cit MUST support = receiving fragments.=E2=80=9D So we just need to violate that = SHOULD.

 

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

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

 

 

 

But anyway, since the current state = of the art seems to not need such an extension, I guess there=E2=80=99s = no point it bringing this up now.

 

Yoav



On 25 = Mar 2018, at 20:36, Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com> = wrote:

 

During the = WG meeting in London, somebody (I forget who) asked me whether KE = payloads larger than 64k.  I thought I ought to clarify matters (as = they are more complex than the brief answer I gave = indicated).

 =

Of the = proposed postquantum key exchange (and public key encryption algorithms, = which can be used to transport keys) submitted to NIST, the majority of = them have key shares (or public keys/ciphertexts) smaller than 64k; = there are a handful that are larger.  Now, it is possible (albeit = unlikely) that all the algorithms with key shares < 64k will be = broken; unless this happens, it would be reasonable (IMHO) that we = mandate that any algorithm he allow have a KE payload that fits within = 64k.  Now, in the event that we feel the need to support larger key = shares, there are possible ways to support that; I don=E2=80=99t feel = that we need to talk about those options = now.

__________= _____________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

<= /div>

 

------=_NextPart_000_0AA3_01D3C4ED.14E71C60-- From nobody Mon Mar 26 00:58:28 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 95E4D126DED for ; Mon, 26 Mar 2018 00:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.01 X-Spam-Level: X-Spam-Status: No, score=-3.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=philips.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 3quhYa5YdDJp for ; Mon, 26 Mar 2018 00:58:23 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50129.outbound.protection.outlook.com [40.107.5.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFA4F1200C5 for ; Mon, 26 Mar 2018 00:58:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=philips.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=voDha1HT3Ta0gqYlYjHZs9x1URDJmuKeYLMr35ZjFSk=; b=gH1GEP7vU6vkeQCaNJ36el9pgrYKuM1L0gh5/KMvW01W75KtZn9CAmN/OLMMek/F3MAjnIPOIGbIP2wZYL9VG67uW9YkaqR+Q4bxZuq6Jtk0ssZeC8nXbuyZrSI9gkVpf4O8dibm3R+aAcYuCwgQ6wwSiY7dKudLN/yF1KWKbcU= Received: from DB5P122MB0087.EURP122.PROD.OUTLOOK.COM (129.75.164.154) by DB5P122MB0088.EURP122.PROD.OUTLOOK.COM (129.75.164.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.609.12; Mon, 26 Mar 2018 07:58:20 +0000 Received: from DB5P122MB0087.EURP122.PROD.OUTLOOK.COM ([fe80::38c8:4025:ed07:9c27]) by DB5P122MB0087.EURP122.PROD.OUTLOOK.COM ([fe80::38c8:4025:ed07:9c27%13]) with mapi id 15.20.0609.012; Mon, 26 Mar 2018 07:58:20 +0000 From: "Garcia-Morchon O, Oscar" To: "Scott Fluhrer (sfluhrer)" , "IPsecme WG (ipsec@ietf.org)" Thread-Topic: Clarification on my comments during the WG about possible KE payloads > 64k Thread-Index: AdPEW8VykPpS3KUtT66wGmoEAi02VQAe3mBg Date: Mon, 26 Mar 2018 07:58:20 +0000 Message-ID: References: <4617c0b8f86c4269a1ad3f8adf0097c3@XCH-RTP-006.cisco.com> In-Reply-To: <4617c0b8f86c4269a1ad3f8adf0097c3@XCH-RTP-006.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.112] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB5P122MB0088; 7:lW7p1VB7IvNpIKnkaLJobbcRHtDfs2tagC0mlgnWf+j0BwxVxF6VjrxXmkmUekF1AA1ZQSllbzY/vR+0BDWKq/duL6L3L/rVVmHGTznjWwDqAums2mr+OdX5OgnDhlLyqJotKyyu9XEH3p3kMbuXQOk4695xq8WdOsMaA1JDubYvr75w4TZg6mG+BM8LfoqhwByQIWx9IvDwydMA8KyC05zLnH+Nib43zNUaIgDVWQo564Ddod/0Y+jxt4QHms5Q x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 35ed6e63-57ec-4c8f-74b0-08d592ef5787 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989060)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(2017052603328)(7153060)(7193020); SRVR:DB5P122MB0088; x-ms-traffictypediagnostic: DB5P122MB0088: authentication-results: spf=none (sender IP is ) smtp.mailfrom=oscar.garcia-morchon@philips.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(278428928389397)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231221)(944501327)(52105095)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:DB5P122MB0088; BCL:0; PCL:0; RULEID:; SRVR:DB5P122MB0088; x-forefront-prvs: 06237E4555 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(39860400002)(39380400002)(396003)(346002)(374574003)(55904004)(51444003)(199004)(189003)(110136005)(229853002)(68736007)(86362001)(2906002)(7736002)(3660700001)(478600001)(53546011)(5660300001)(74316002)(14454004)(6506007)(33656002)(25786009)(3280700002)(316002)(97736004)(8936002)(81166006)(81156014)(8676002)(9326002)(7696005)(76176011)(99286004)(5250100002)(11346002)(106356001)(446003)(2900100001)(59450400001)(105586002)(54896002)(6116002)(790700001)(6306002)(9686003)(66066001)(102836004)(3846002)(6246003)(53936002)(186003)(55016002)(6436002)(26005); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5P122MB0088; H:DB5P122MB0087.EURP122.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: philips.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 9PR8YMchdDzIOjmCWtN9Is7huyKQ2ArtQOLgkOjvAaiZtnKjOHkYEJ23y6ouYi5GQqvsmGV9bZHM/lXik7tcnpIfJIARw4qyQFImcvcFMzBG0D+teZ3gJpbp/20siigIdKf3zl0x6q5gZW3d00zwGrVnDEelxdwJQlZvTUtYhNBNOcX1DpPrZ5++lRFnKDMNqqHpXp07W9gvIn8M7olPb/2XJovMnV+pi9ETrR/W0Uc1Rn+zXkYJfHI5KfA+S+Fac8z7GtyaMabCSeWbcDDbBYAQjtblqK8f+MgpqCCtVb+q1q1COwJGXwUsuPlenuBIRYwQImD1LKVHaimlhwVyPg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB5P122MB008736CB653DB8519519055CC8AD0DB5P122MB0087EURP_" MIME-Version: 1.0 X-OriginatorOrg: philips.com X-MS-Exchange-CrossTenant-Network-Message-Id: 35ed6e63-57ec-4c8f-74b0-08d592ef5787 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2018 07:58:20.5346 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5P122MB0088 Archived-At: Subject: Re: [IPsec] Clarification on my comments during the WG about possible KE payloads > 64k 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, 26 Mar 2018 07:58:27 -0000 --_000_DB5P122MB008736CB653DB8519519055CC8AD0DB5P122MB0087EURP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Scott, I see your point. But I can imagine that very conservative users (critical applications) migh= t want to use some of the schemes that have been out there for a longer per= iod of time (e.g., McEliece). This can be specially true at the beginning, = while other more efficient schemes get more verification. >From this point, I think that if the requirements (>64k) of those schemes n= eed to be taken into account, then those should be taken into account now. Regards, Oscar. From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Scott Fluhrer (sfl= uhrer) Sent: Sunday, March 25, 2018 7:36 PM To: IPsecme WG (ipsec@ietf.org) Subject: [IPsec] Clarification on my comments during the WG about possible = KE payloads > 64k During the WG meeting in London, somebody (I forget who) asked me whether K= E payloads larger than 64k. I thought I ought to clarify matters (as they = are more complex than the brief answer I gave indicated). Of the proposed postquantum key exchange (and public key encryption algorit= hms, which can be used to transport keys) submitted to NIST, the majority o= f them have key shares (or public keys/ciphertexts) smaller than 64k; there= are a handful that are larger. Now, it is possible (albeit unlikely) that= all the algorithms with key shares < 64k will be broken; unless this happe= ns, it would be reasonable (IMHO) that we mandate that any algorithm he all= ow have a KE payload that fits within 64k. Now, in the event that we feel = the need to support larger key shares, there are possible ways to support t= hat; I don't feel that we need to talk about those options now. ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_DB5P122MB008736CB653DB8519519055CC8AD0DB5P122MB0087EURP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Scott,

 

I see your point.

 

But I can imagine that= very conservative users (critical applications) might want to use some of = the schemes that have been out there for a longer period of time (e.g., McE= liece). This can be specially true at the beginning, while other more efficient schemes get more verification. <= o:p>

 

From this point, I thi= nk that if the requirements (>64k) of those schemes need to be taken int= o account, then those should be taken into account now.

 

Regards, Oscar.

 

From: IPsec [mailto:ipsec-bounces@ietf.org] <= b>On Behalf Of Scott Fluhrer (sfluhrer)
Sent: Sunday, March 25, 2018 7:36 PM
To: IPsecme WG (ipsec@ietf.org) <ipsec@ietf.org>
Subject: [IPsec] Clarification on my comments during the WG about po= ssible KE payloads > 64k

 

During the WG meeting in London, somebody (I forget = who) asked me whether KE payloads larger than 64k.  I thought I ought = to clarify matters (as they are more complex than the brief answer I gave i= ndicated).

 

Of the proposed postquantum key exchange (and public= key encryption algorithms, which can be used to transport keys) submitted = to NIST, the majority of them have key shares (or public keys/ciphertexts) = smaller than 64k; there are a handful that are larger.  Now, it is possible (albeit unlikely) that all the = algorithms with key shares < 64k will be broken; unless this happens, it= would be reasonable (IMHO) that we mandate that any algorithm he allow hav= e a KE payload that fits within 64k.  Now, in the event that we feel the need to support larger key shares, there are= possible ways to support that; I don’t feel that we need to talk abo= ut those options now.


The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_DB5P122MB008736CB653DB8519519055CC8AD0DB5P122MB0087EURP_-- From nobody Mon Mar 26 12:05:20 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 BD86A1272E1 for ; Mon, 26 Mar 2018 12:05:18 -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 zsUFsK92Bv8R for ; Mon, 26 Mar 2018 12:05:17 -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 9AE10127136 for ; Mon, 26 Mar 2018 12:05:16 -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 w2QJ562V027158 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 26 Mar 2018 22:05:06 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w2QJ51lh007414; Mon, 26 Mar 2018 22:05:01 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23225.17500.788892.126682@fireball.acr.fi> Date: Mon, 26 Mar 2018 22:05:00 +0300 From: Tero Kivinen To: "Garcia-Morchon O\, Oscar" Cc: "Scott Fluhrer \(sfluhrer\)" , "IPsecme WG \(ipsec\@ietf.org\)" In-Reply-To: References: <4617c0b8f86c4269a1ad3f8adf0097c3@XCH-RTP-006.cisco.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 17 min X-Total-Time: 17 min Archived-At: Subject: Re: [IPsec] Clarification on my comments during the WG about possible KE payloads > 64k 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, 26 Mar 2018 19:05:19 -0000 Garcia-Morchon O, Oscar writes: > From this point, I think that if the requirements (>64k) of those > schemes need to be taken into account, then those should be taken > into account now. I think the best way to make them work is to keep the individual payload length less than 64k, but QSKE (or whatever the new payload is called) so that it can provide separate pieces of actual KE payload. This way we also get acks etc for each piece, and if there is errors we do not need to resend the whole n MB message, but instead we resend (and reassemble and buffer) <64kB piece of the KE inside one fragmented ike exchange. I.e. instead of having: Original Message: HDR(MID=n), SK(NextPld=PLD) {PLD(2MB)} Fragmented Message: HDR(MID=n), SKF(NextPld=PLD, Frag#=1, TotalFrags=128) {first 16kB of PLD} --> HDR(MID=n), SKF(NextPld=0, Frag#=2, TotalFrags=128) {next 16kB of PLD } --> ... HDR(MID=n), SKF(NextPld=0, Frag#=128, TotalFrags=128) {last 16kB of PLD} --> <-- HDR(MID=n) response ack (and here would need to assume that 16kB UDP packet would get properly IP-fragmented as IKE fragmentation supports only at maximum of 255 fragments). We could do something like this: HDR(MID=n), SKF(NextPld=PLD, Frag#=1, TotalFrags=16) {first 1kB of PLD(0/128, first 16kB of PLD)} --> HDR(MID=n), SKF(NextPld=0, Frag#=2, TotalFrags=16) {next 1kB of PLD(0/128, first 16kB of PLD)} --> ... HDR(MID=n), SKF(NextPld=0, Frag#=16, TotalFrags=16) {last 1kB of PLD(0/128, first 16kB of PLD)} --> <-- HDR(MID=n) ACK HDR(MID=n+1), SKF(NextPld=PLD, Frag#=1, TotalFrags=16) {first 1kB of PLD(1/128, next 16kB of PLD)} --> HDR(MID=n+1), SKF(NextPld=0, Frag#=2, TotalFrags=16) {next 1kB of PLD(1/128, next 16kB of PLD)} --> ... HDR(MID=n+1), SKF(NextPld=0, Frag#=16, TotalFrags=16) {last 1kB of PLD(1/128, next 16kB of PLD)} --> <-- HDR(MID=n+1) response ack ... HDR(MID=n+128), SKF(NextPld=PLD, Frag#=1, TotalFrags=16) {first 1kB of PLD(128/128, last 16kB of PLD)} --> HDR(MID=n+128), SKF(NextPld=0, Frag#=2, TotalFrags=16) {next 1kB of PLD(128/128, last 16kB of PLD)} --> ... HDR(MID=n+128), SKF(NextPld=0, Frag#=16, TotalFrags=16) {last 1kB of PLD(128/128, last 16kB of PLD)} --> <-- HDR(MID=n+128) response ack I.e., we use normal IKEv2 fragmentation and send for example 16kB pieces in each of the IKE_AUX exchange, but we have multiple IKE_AUX exchanges, and each of them will deliver one piece of the full QSKE to the other end, so if each piece is 16 kB, we will have 128 of those 16kB pieces. The normal fragmentation code will not be changed and IKEv2 exchanges are still processed normally without any special handling, only think that requires special handling is the QSKE payloads which can contain multiple pieces where each piece is delivered in separate exchange. There are some other complications if responder also needs to send large things back, thus the initiator needs to know to do empty requests to responder until final pieces of the responders QSKE arrives (in case responders QSKE was bigger than initiators). -- kivinen@iki.fi From nobody Tue Mar 27 00:48:58 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 0C1AA12D872 for ; Tue, 27 Mar 2018 00:48:57 -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 Gxw6JJV05hld for ; Tue, 27 Mar 2018 00:48:55 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 8646C12D86F for ; Tue, 27 Mar 2018 00:48:53 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id a22-v6so31876785lfg.9 for ; Tue, 27 Mar 2018 00:48:53 -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=g8jod4q7QwiuTMK7itRTr5LnPMTj5JUXPnKs3+66+L4=; b=frwJBw/YWgnmeIpedyVbu1DcJ+O09C+II11I8BfHGjnJtsCFi5w10TZROtMbG1GMBq RqjqBC7uslBSIhBLMKXJBTrjUTaTZ0ccVm/xrZX5y/l5EPRwqYSNJEWXeouYuriTDL6k E14pwphXqf469cUDpQRlFCM9KBH/ioXHIIVoBxzxz0of37II42VRM9yYzpPPbMrIxifz 2vV6bmcOywhmoNUCu6+8swecjPLWZAhhUcdlcw5be99neKH13EugxPOwKg6XHD5Ct1a9 f51qlUa5y+HXxfa18mpQhKBAM+MO8GCmtoUDyTc5m9DU2bqDDUpIHnbgz/kGdJXjgoHM 9Fqw== 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=g8jod4q7QwiuTMK7itRTr5LnPMTj5JUXPnKs3+66+L4=; b=Hwk9npwRRDEVMiDlwt/Dj0J208rP0HFGW2Q81kEo+jJk3SZOX79gsYQsQ58mSLsXqf lC546FHB1GCa/JiHwog6TOEEioB7zS5L06ANNLViUVJKJXkoyyY2lM01pK1ClIrYkthH 47O5x7UjYIi3wxHugTybHlwE6Shj0NlCEAY8YUAW8oHBL0VCDazgtgDX1Ewxtr5sNnSz ZtoWXfLuRo2jmMUyMJLiDe6U5oaaRaXAr2exFhvKq2gp/kwizUcmpk4fY3RM67A0EsQq fuys8x0ZkrYmRvsZavij+KjppbbAXlvYW07e0C3LQCK71OITTKhoJ8FNc7OECiXieVsZ 3ivw== X-Gm-Message-State: AElRT7HwaoGV2dNmQT5+2lPpDwhU0SiC3kma4PBQLMH0ZvNIPL/CPMl/ UaNnlmTenhs+byrq24lgZ+SKEg== X-Google-Smtp-Source: AIpwx49GVOzT7M+QN0eRjZjgFd7AB2nDUM10GTMYcmzvg7bcEC63KK5vC50Ijcgw2GfCQVKeZheviA== X-Received: by 2002:a19:cf89:: with SMTP id f131-v6mr5935000lfg.130.1522136931490; Tue, 27 Mar 2018 00:48:51 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id i18-v6sm122812lfj.50.2018.03.27.00.48.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 27 Mar 2018 00:48:50 -0700 (PDT) From: "Valery Smyslov" To: "'Tero Kivinen'" , "'Garcia-Morchon O, Oscar'" Cc: "'IPsecme WG '" , "'Scott Fluhrer \(sfluhrer\)'" References: <4617c0b8f86c4269a1ad3f8adf0097c3@XCH-RTP-006.cisco.com> <23225.17500.788892.126682@fireball.acr.fi> In-Reply-To: <23225.17500.788892.126682@fireball.acr.fi> Date: Tue, 27 Mar 2018 10:48:50 +0300 Message-ID: <0be701d3c5a0$0c8a8440$259f8cc0$@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: AQNFS3lY4miM3I5hdH2aVZL3gQjT9gHEpfO3AUP7zseg6FNnkA== Content-Language: ru Archived-At: Subject: Re: [IPsec] Clarification on my comments during the WG about possible KE payloads > 64k 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, 27 Mar 2018 07:48:57 -0000 Hi, > I think the best way to make them work is to keep the individual > payload length less than 64k, but QSKE (or whatever the new payload is > called) so that it can provide separate pieces of actual KE payload. That's exactly what I suggested in https://mailarchive.ietf.org/arch/msg/ipsec/jahWqh_dvPkqAXnA4-C9LndtWWk > This way we also get acks etc for each piece, and if there is errors > we do not need to resend the whole n MB message, but instead we resend > (and reassemble and buffer) <64kB piece of the KE inside one > fragmented ike exchange. > > I.e. instead of having: > > Original Message: > > HDR(MID=n), SK(NextPld=PLD) {PLD(2MB)} > > Fragmented Message: > > HDR(MID=n), SKF(NextPld=PLD, Frag#=1, TotalFrags=128) > {first 16kB of PLD} --> > HDR(MID=n), SKF(NextPld=0, Frag#=2, TotalFrags=128) > {next 16kB of PLD } --> > ... > HDR(MID=n), SKF(NextPld=0, Frag#=128, TotalFrags=128) > {last 16kB of PLD} --> > > <-- HDR(MID=n) response ack > > (and here would need to assume that 16kB UDP packet would get properly > IP-fragmented as IKE fragmentation supports only at maximum of 255 > fragments). No, IKE fragmentation allows to have up to 2^16 fragments, so it possible to transfer up to ~60MB of key data with no IP fragmentation (assuming each IKE fragment contains ~1000 bytes of key data). > We could do something like this: > > HDR(MID=n), SKF(NextPld=PLD, Frag#=1, TotalFrags=16) > {first 1kB of PLD(0/128, first 16kB of PLD)} --> > HDR(MID=n), SKF(NextPld=0, Frag#=2, TotalFrags=16) > {next 1kB of PLD(0/128, first 16kB of PLD)} --> > ... > HDR(MID=n), SKF(NextPld=0, Frag#=16, TotalFrags=16) > {last 1kB of PLD(0/128, first 16kB of PLD)} --> > > <-- HDR(MID=n) ACK > > HDR(MID=n+1), SKF(NextPld=PLD, Frag#=1, TotalFrags=16) > {first 1kB of PLD(1/128, next 16kB of PLD)} --> > HDR(MID=n+1), SKF(NextPld=0, Frag#=2, TotalFrags=16) > {next 1kB of PLD(1/128, next 16kB of PLD)} --> > ... > HDR(MID=n+1), SKF(NextPld=0, Frag#=16, TotalFrags=16) > {last 1kB of PLD(1/128, next 16kB of PLD)} --> > > <-- HDR(MID=n+1) response ack > ... > HDR(MID=n+128), SKF(NextPld=PLD, Frag#=1, TotalFrags=16) > {first 1kB of PLD(128/128, last 16kB of PLD)} --> > HDR(MID=n+128), SKF(NextPld=0, Frag#=2, TotalFrags=16) > {next 1kB of PLD(128/128, last 16kB of PLD)} --> > ... > HDR(MID=n+128), SKF(NextPld=0, Frag#=16, TotalFrags=16) > {last 1kB of PLD(128/128, last 16kB of PLD)} --> > > <-- HDR(MID=n+128) response ack > > I.e., we use normal IKEv2 fragmentation and send for example 16kB > pieces in each of the IKE_AUX exchange, but we have multiple IKE_AUX > exchanges, and each of them will deliver one piece of the full QSKE to > the other end, so if each piece is 16 kB, we will have 128 of those > 16kB pieces. > > The normal fragmentation code will not be changed and IKEv2 exchanges > are still processed normally without any special handling, only think > that requires special handling is the QSKE payloads which can contain > multiple pieces where each piece is delivered in separate exchange. > > There are some other complications if responder also needs to send > large things back, thus the initiator needs to know to do empty > requests to responder until final pieces of the responders QSKE > arrives (in case responders QSKE was bigger than initiators). Or probably change roles for a while and make the responder to initiate a reverse requests to transfer its large KE to initiator. Not sure it is better though... If the particular QSKE is DH-like (assuming that initiator's and responder's public keys are of the same size and are computed independently), then the much better approach is possible: HDR (IKE_AUX, MID = 1), SK {KE(1st piece of initiator's public key)} --> <-- HDR (IKE_AUX, MID = 1), SK {KE(1st piece of responder's public key)} HDR (IKE_AUX, MID = 2), SK { KE(2nd piece of initiator's public key)} --> <-- HDR (IKE_AUX, MID = 2), SK {KE(2nd piece of responder's public key)} HDR (IKE_AUX, MID = 3), SK {KE(3rd piece of initiator's public key)} --> <-- HDR (IKE_AUX, MID = 3), SK { KE(3rd piece of responder's public key)} ... HDR (IKE_AUX, MID = 3), SK {KE(last piece of initiator's public key)} --> <-- HDR (IKE_AUX, MID = 3), SK { KE(last piece of responder's public key)} Pieces can be made very small to avoid fragmentation at all, or larger, so that IKE fragmentation will take place, but the number of fragments each message is divided info is small, so that the initiator would not need to resend large amount of data in case of packet loss. Regards, Valery. From nobody Tue Mar 27 10:22:15 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 E5D2A12D0C3 for ; Tue, 27 Mar 2018 10:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1liO4OkZmfus for ; Tue, 27 Mar 2018 10:22:11 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 858591289B0 for ; Tue, 27 Mar 2018 10:22:10 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id v207-v6so34425201lfa.10 for ; Tue, 27 Mar 2018 10:22:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=EC0wRgr0mW+r0M8HYG55kTlb+yflxgks56tyxL3LpwM=; b=bxkcPcgnDVWo7UQpYXlE8dDPEFCtAgqdQ60hGdKdfvT34/rCVGfkttS7KNelH4JsWA V13yTr2+nkYHSHAOcYNQoizElrjofWLDrmsAAjAV6qhlZYdJsbQcFkWCv567d3xvAbJo bBhPoZ14CDd0UpWwKKaP+EcKARumOGLBD3s4Sdg3DhQKg8C/saFCcHciuDeaoCYqJzVT d0yoZr8/Ub2QEeiRqkH3eXVipLcnuUFMCFDs6syYQs5iFhcaXHtAhdB0rl648PzMB+Ks C7wFN/M2R0LiFuhk6UjgPSc3bWOXKpTJzXwB5msVieTfkdaf45BYNoxryiyLS9FPT8wu 1AuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=EC0wRgr0mW+r0M8HYG55kTlb+yflxgks56tyxL3LpwM=; b=ockfeq1U0WfyGwacGBEmNVicTTSVpF6ytXgyKJgwmFjXynTWCx8poDgbDal2bh7UKq LCI6MHqGh6oSZbcjX2wUNmVUeD0AHJIv8WFJv5eks1qJdq6XdZ5u3Xo89HyltWh7j20/ WOxDuyKA4Q9X5zWuqY99hstIfWy3CPIRDVAMJvJEfhJI1fmG+yrB4u4FIr5AMPweq1Wa ZEnOJBRZ76KjlvUBvoxNFM+Fxs6fxma3TBjA7gSixsy6l1od6+jGhlVPs82szeJC7PRE IC1xIAp8R6WTPs381bEqvW7AtQoawPnwMLrYZmBx1WR631vhg2CSt1N1G5fdfPDH9349 qLfA== X-Gm-Message-State: AElRT7ElgX1sGL+eSCls+Q8xYjmHHigYndsumnhuzc7U97keaPWtTkV+ lYNc7BmFXrHtwPjQYg2mXRvVg+EeHBjLZJMtLESizg== X-Google-Smtp-Source: AIpwx48yqkHpupyT571gyKgidOjzMIvlW8DPkl3goA0myQS+UjIVS4sTm0IYD7mx7kFqI29r62c4YCM/uLdIYiE8quM= X-Received: by 2002:a19:4350:: with SMTP id m16-v6mr84387lfj.73.1522171328723; Tue, 27 Mar 2018 10:22:08 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.158.19 with HTTP; Tue, 27 Mar 2018 10:22:08 -0700 (PDT) In-Reply-To: <4c9091a6469945478d0fbce30447da94@XCH-RTP-006.cisco.com> References: <4c9091a6469945478d0fbce30447da94@XCH-RTP-006.cisco.com> From: Daniel Migault Date: Tue, 27 Mar 2018 13:22:08 -0400 X-Google-Sender-Auth: ahVbaRfO_sBBVEeKQXMCRscQhl8 Message-ID: To: "Scott Fluhrer (sfluhrer)" Cc: "IPsecme WG (ipsec@ietf.org)" Content-Type: multipart/alternative; boundary="00000000000055ff53056868216a" Archived-At: Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-implicit-iv 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, 27 Mar 2018 17:22:14 -0000 --00000000000055ff53056868216a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you Scott for your comments. I understand the first comment as a text clarification to comment on the mechanism provided by section 3.5 of RFC6407 and explicitely mention that is does not apply here. Does the replacement below addresses your concern ? OLD: Section 3.5 of [RFC6407] explains how repetition MAY BE prevented by using a prefix for each group member, which could be prefixed to the Sequence Number. Otherwise, Implicit IV MUST NOT be used in multicast scenarios. NEW: Section 3.5 of [RFC6407] provides a mechanism that MAY be used to prevent IV collisions when the same key is used by multiple users. The mechanism consists in partitioning the IV space between users by assigning the most significant byte to a user. When implicit IV transforms are used, such mechanism cannot be applied as the IV is not sent, but instead it is derived from the Sequence Number. 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 =3D 16777216, that is 16 M. Unless some mechanism are provided to avoid collision between Sequence Number, ( and so IV ), Implicit IV MUST NOT be used. Regarding the second comment, I guess the idea was to mention that a responser cannot select a IIV Transform unless being sent by the initiator. I propose the following text. Do it address your comment ? OLD: The rules of SA payload processing ensure that the responder will never send an SA payload containing the IIV indicator to an initiator that does not support IIV. NEW: The rules of SA payload processing ensure that the responder will never send an SA payload containing the IIV transform to an initiator that does not support IIV. The reason for not having AES_CTR was that the transform is on its way to be retired. I propose to remove AES-CTR, but if there is a need to provide AES-CTR with implicit IV we coudl also add additional code points. I am currently proposing the following text: OLD: AES-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to implement the implicit IV described in this document. NEW: AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to implement the implicit IV described in this document. Yours, Daniel On Sun, Mar 25, 2018 at 2:10 PM, Scott Fluhrer (sfluhrer) < sfluhrer@cisco.com> wrote: > - Section 4: =E2=80=9CSection 3.5 of [RFC6407] explains how repe= tition > MAY BE prevented by using a prefix for each group member=E2=80=9D > > Actually, RFC6407 just refers to RFC6054; that has the SID in the top 8 > bits of the 8 byte sequence number. Used literally, this doesn=E2=80=99t= work, as > the top 8 bits of the 8 byte sequence number are never expressed in the > packet in implicit-iv. You could put them in the top 8 bits of the 4 byt= e > sequence number (which means you can=E2=80=99t use ESN, but it didn=E2=80= =99t work in the > multisender case anyways), but that would mean that each sender would be > limited to 16M packets. I believe that these details are distinct enough > that (if this is considered a viable alternative) they should be explicit= ly > listed (including the 16M packet restriction). Alternatively, we can jus= t > forbid this transform in the multisender case. > > > > - Section 6: =E2=80=9CThe rules of SA payload processing ensure = that the > responder will never send an SA payload containing the IIV indicator to a= n > initiator that does not support IIV=E2=80=9D > > I believe that this is stale text; the current draft doesn=E2=80=99t use = an > indicator; instead, it defines separate transforms IDs. > > > > - Section 8 has =E2=80=9CAES-CTR =E2=80=A6 [is] likely to implem= ent the implicit > IV described in this document=E2=80=9D; however the transform ENCR_AES_CT= R_IIV is > not defined. Is this intended? Should we either remove the AES-CTR > algorithm from the list of =E2=80=9Clikely to implement=E2=80=9D, or shou= ld we actually > define the transform id for it? > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > --00000000000055ff53056868216a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Scott for your comments.

I understand th= e first comment as a text clarification to comment on the mechanism provide= d by section 3.5 of RFC6407 and explicitely mention that is does not apply = here. Does the replacement below addresses your concern ?

OLD:
= =C2=A0=C2=A0 Section 3.5 of [RFC6407] explains how
=C2=A0=C2=A0 repetiti= on MAY BE prevented by using a prefix for each group member,
=C2=A0=C2= =A0 which could be prefixed to the Sequence Number.=C2=A0 Otherwise, Implic= it
=C2=A0=C2=A0 IV MUST NOT be used in multicast scenarios.

NEW:<= br>=C2=A0=C2=A0 Section 3.5 of [RFC6407] provides a mechanism that MAY be u= sed to prevent IV collisions when the same key is used by multiple users. T= he mechanism consists in partitioning the IV space between users by assigni= ng the most significant byte to a user. When implicit IV transforms are use= d, such mechanism cannot be applied as the IV is not sent, but instead it i= s derived from the Sequence Number. A similar mechanism could be used by as= sociating the most significant byte of the Sequence Number to a sender, whi= le the 3 remaining bytes will be used to carry the counter value. Such mech= anism prevents the use of Extended Sequence Number and limits the number of= packet to be sent to 2** 24 =3D=C2=A0 16777216, that is 16 M.

Unle= ss some mechanism are provided to avoid collision between Sequence Number, = ( and so IV ), Implicit IV MUST NOT be used.


Regarding the seco= nd comment, I guess the idea was to mention that a responser cannot select = a IIV Transform unless being sent by the initiator. I propose the following= text. Do it address your comment ?

OLD:

=C2=A0=C2=A0 The rul= es of SA payload processing ensure that the responder will
=C2=A0=C2=A0 = never send an SA payload containing the IIV indicator to an initiator
= =C2=A0=C2=A0 that does not support IIV.


NEW:

=C2=A0=C2=A0= The rules of SA payload processing ensure that the responder will
=C2= =A0=C2=A0 never send an SA payload containing the IIV transform to an initi= ator
=C2=A0=C2=A0 that does not support IIV.


The reason for n= ot having AES_CTR was that the transform is on its way to be retired. I pro= pose to remove AES-CTR, but if there is a need to provide AES-CTR with impl= icit IV we coudl also add additional code points.

I am currently pr= oposing the following text:

OLD:
=C2=A0=C2=A0 AES-CTR, AES-CCM, A= ES-GCM and ChaCha20-Poly1305 are likely to
=C2=A0=C2=A0 implement the im= plicit IV described in this document.=C2=A0

NEW:

=C2=A0=C2= =A0 AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to
=C2=A0=C2=A0 im= plement the implicit IV described in this document.=C2=A0


Yours,
Daniel

On Sun, Mar 25, 2018 at 2:10 PM, Scott Fluhrer (sflu= hrer) <sfluhrer@cisco.com> wrote:

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Section 4: =E2=80=9CSection 3.5 of [RFC6407] explains = how repetition MAY BE prevented by using a prefix for each group member=E2= =80=9D

Actually, RFC6407 just r= efers to RFC6054; that has the SID in the top 8 bits of the 8 byte sequence= number.=C2=A0 Used literally, this doesn=E2=80=99t work, as the top 8 bits= of the 8 byte sequence number are never expressed in the packet in implicit-iv.=C2=A0 You could put them in the top 8 bits o= f the 4 byte sequence number (which means you can=E2=80=99t use ESN, but it= didn=E2=80=99t work in the multisender case anyways), but that would mean = that each sender would be limited to 16M packets. I believe that these details are distinct enough that (if this is considered a viabl= e alternative) they should be explicitly listed (including the 16M packet r= estriction).=C2=A0 Alternatively, we can just forbid this transform in the = multisender case.

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Section 6: =E2=80=9CThe rules of SA payload processing= ensure that the responder will never send an SA payload containing the IIV= indicator to an initiator that does not support IIV=E2=80=9D=

I believe that this is stale text; the current draft doesn=E2=80=99t us= e an indicator; instead, it defines separate transforms IDs.<= /p>

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Section 8 has =E2=80=9CAES-CTR =E2=80=A6 [is] likely t= o implement the implicit IV described in this document=E2=80=9D; however th= e transform ENCR_AES_CTR_IIV is not defined.=C2=A0 Is this intended?=C2=A0 = Should we either remove the AES-CTR algorithm from the list of =E2=80=9Clikely to implement=E2=80=9D, or should we actually define the tr= ansform id for it?

=C2=A0


_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


--00000000000055ff53056868216a-- From nobody Tue Mar 27 11:05: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 5122E12E877 for ; Tue, 27 Mar 2018 11:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.799 X-Spam-Level: X-Spam-Status: No, score=-6.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: DNS error: SERVFAIL)" header.d=cisco.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 R5b5lSDjkAoU for ; Tue, 27 Mar 2018 11:05:05 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BCA912E858 for ; Tue, 27 Mar 2018 11:05:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22652; q=dns/txt; s=iport; t=1522173905; x=1523383505; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=nBiyoYTWhBr4lv3opkCyMsmNiYGjg5skD9mTq8I3K+0=; b=HvDJYNBvK5N1CyEPJAdqD9Jxd7WSIBfxxC5dDloZndq+sE9V8GXq681/ ifS/XuYi12p1O1gcOKR8k5py31eDqDNhpT/hIu6Hmeg+wBngi7zmsg5V/ +hZ8B5C0ubeitPeHiYG1xBOOzXtfW/Gig5Q+R3ZlFNvB2epLDZ+6suswR E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAQCYh7pa/4MNJK1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJNdGFwKAqDUogAjRaBdIEPhmCHDIRlggMLGAEKhGECGoN?= =?us-ascii?q?pITQYAQIBAQEBAQECayiFJQEBAQQBASEKQQsQAgEIEQQBASgDAgICHwYLFAk?= =?us-ascii?q?IAQEEDgUIhCJMAxUPq2GCIIcQDYEsghIFhT6CGoFUQIQTglFCAQGBNz4fgku?= =?us-ascii?q?CVAOHColDhkcuCAKLNYJ0jESJUIYGAhETAYEkARw4gVJwFTqCQ4IeAxiOF2+?= =?us-ascii?q?NP4EvgRcBAQ?= X-IronPort-AV: E=Sophos; i="5.48,367,1517875200"; d="scan'208,217"; a="90247862" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Mar 2018 18:04:44 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w2RI4hpZ018193 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 27 Mar 2018 18:04:44 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 27 Mar 2018 14:04:43 -0400 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1320.000; Tue, 27 Mar 2018 14:04:43 -0400 From: "Scott Fluhrer (sfluhrer)" To: Daniel Migault CC: "IPsecme WG (ipsec@ietf.org)" Thread-Topic: [IPsec] Comments on draft-ietf-ipsecme-implicit-iv Thread-Index: AdPEYabaslSsDVKJSGW5Eb13uZxLnQBsAJgAAAdEYyA= Date: Tue, 27 Mar 2018 18:04:43 +0000 Message-ID: <157d7bd1e99b4044bec2ba4412d8e873@XCH-RTP-006.cisco.com> References: <4c9091a6469945478d0fbce30447da94@XCH-RTP-006.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.53] Content-Type: multipart/alternative; boundary="_000_157d7bd1e99b4044bec2ba4412d8e873XCHRTP006ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-implicit-iv 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, 27 Mar 2018 18:05:19 -0000 --_000_157d7bd1e99b4044bec2ba4412d8e873XCHRTP006ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpGcm9tOiBtZ2x0LmlldGZAZ21haWwuY29tIDxtZ2x0LmlldGZAZ21haWwuY29tPiBPbiBCZWhh bGYgT2YgRGFuaWVsIE1pZ2F1bHQNClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDI3LCAyMDE4IDE6MjIg UE0NClRvOiBTY290dCBGbHVocmVyIChzZmx1aHJlcikgPHNmbHVocmVyQGNpc2NvLmNvbT4NCkNj OiBJUHNlY21lIFdHIChpcHNlY0BpZXRmLm9yZykgPGlwc2VjQGlldGYub3JnPg0KU3ViamVjdDog UmU6IFtJUHNlY10gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1pcHNlY21lLWltcGxpY2l0LWl2DQoN ClRoYW5rIHlvdSBTY290dCBmb3IgeW91ciBjb21tZW50cy4NCg0KSSB1bmRlcnN0YW5kIHRoZSBm aXJzdCBjb21tZW50IGFzIGEgdGV4dCBjbGFyaWZpY2F0aW9uIHRvIGNvbW1lbnQgb24gdGhlIG1l Y2hhbmlzbSBwcm92aWRlZCBieSBzZWN0aW9uIDMuNSBvZiBSRkM2NDA3IGFuZCBleHBsaWNpdGVs eSBtZW50aW9uIHRoYXQgaXMgZG9lcyBub3QgYXBwbHkgaGVyZS4gRG9lcyB0aGUgcmVwbGFjZW1l bnQgYmVsb3cgYWRkcmVzc2VzIHlvdXIgY29uY2VybiA/DQoNCk9MRDoNCiAgIFNlY3Rpb24gMy41 IG9mIFtSRkM2NDA3XSBleHBsYWlucyBob3cNCiAgIHJlcGV0aXRpb24gTUFZIEJFIHByZXZlbnRl ZCBieSB1c2luZyBhIHByZWZpeCBmb3IgZWFjaCBncm91cCBtZW1iZXIsDQogICB3aGljaCBjb3Vs ZCBiZSBwcmVmaXhlZCB0byB0aGUgU2VxdWVuY2UgTnVtYmVyLiAgT3RoZXJ3aXNlLCBJbXBsaWNp dA0KICAgSVYgTVVTVCBOT1QgYmUgdXNlZCBpbiBtdWx0aWNhc3Qgc2NlbmFyaW9zLg0KDQpORVc6 DQogICBTZWN0aW9uIDMuNSBvZiBbUkZDNjQwN10gcHJvdmlkZXMgYSBtZWNoYW5pc20gdGhhdCBN QVkgYmUgdXNlZCB0byBwcmV2ZW50IElWIGNvbGxpc2lvbnMgd2hlbiB0aGUgc2FtZSBrZXkgaXMg dXNlZCBieSBtdWx0aXBsZSB1c2Vycy4gVGhlIG1lY2hhbmlzbSBjb25zaXN0cyBpbiBwYXJ0aXRp b25pbmcgdGhlIElWIHNwYWNlIGJldHdlZW4gdXNlcnMgYnkgYXNzaWduaW5nIHRoZSBtb3N0IHNp Z25pZmljYW50IGJ5dGUgdG8gYSB1c2VyLiBXaGVuIGltcGxpY2l0IElWIHRyYW5zZm9ybXMgYXJl IHVzZWQsIHN1Y2ggbWVjaGFuaXNtIGNhbm5vdCBiZSBhcHBsaWVkIGFzIHRoZSBJViBpcyBub3Qg c2VudCwgYnV0IGluc3RlYWQgaXQgaXMgZGVyaXZlZCBmcm9tIHRoZSBTZXF1ZW5jZSBOdW1iZXIu IEEgc2ltaWxhciBtZWNoYW5pc20gY291bGQgYmUgdXNlZCBieSBhc3NvY2lhdGluZyB0aGUgbW9z dCBzaWduaWZpY2FudCBieXRlIG9mIHRoZSBTZXF1ZW5jZSBOdW1iZXIgdG8gYSBzZW5kZXIsIHdo aWxlIHRoZSAzIHJlbWFpbmluZyBieXRlcyB3aWxsIGJlIHVzZWQgdG8gY2FycnkgdGhlIGNvdW50 ZXIgdmFsdWUuIFN1Y2ggbWVjaGFuaXNtIHByZXZlbnRzIHRoZSB1c2Ugb2YgRXh0ZW5kZWQgU2Vx dWVuY2UgTnVtYmVyIGFuZCBsaW1pdHMgdGhlIG51bWJlciBvZiBwYWNrZXQgdG8gYmUgc2VudCB0 byAyKiogMjQgPSAgMTY3NzcyMTYsIHRoYXQgaXMgMTYgTS4NCg0KVW5sZXNzIHNvbWUgbWVjaGFu aXNtIGFyZSBwcm92aWRlZCB0byBhdm9pZCBjb2xsaXNpb24gYmV0d2VlbiBTZXF1ZW5jZSBOdW1i ZXIsICggYW5kIHNvIElWICksIEltcGxpY2l0IElWIE1VU1QgTk9UIGJlIHVzZWQuDQoNClRoYXQg d29ya3PigKYNCg0KDQoNClJlZ2FyZGluZyB0aGUgc2Vjb25kIGNvbW1lbnQsIEkgZ3Vlc3MgdGhl IGlkZWEgd2FzIHRvIG1lbnRpb24gdGhhdCBhIHJlc3BvbnNlciBjYW5ub3Qgc2VsZWN0IGEgSUlW IFRyYW5zZm9ybSB1bmxlc3MgYmVpbmcgc2VudCBieSB0aGUgaW5pdGlhdG9yLiBJIHByb3Bvc2Ug dGhlIGZvbGxvd2luZyB0ZXh0LiBEbyBpdCBhZGRyZXNzIHlvdXIgY29tbWVudCA/DQoNCk9MRDoN Cg0KICAgVGhlIHJ1bGVzIG9mIFNBIHBheWxvYWQgcHJvY2Vzc2luZyBlbnN1cmUgdGhhdCB0aGUg cmVzcG9uZGVyIHdpbGwNCiAgIG5ldmVyIHNlbmQgYW4gU0EgcGF5bG9hZCBjb250YWluaW5nIHRo ZSBJSVYgaW5kaWNhdG9yIHRvIGFuIGluaXRpYXRvcg0KICAgdGhhdCBkb2VzIG5vdCBzdXBwb3J0 IElJVi4NCg0KDQpORVc6DQoNCiAgIFRoZSBydWxlcyBvZiBTQSBwYXlsb2FkIHByb2Nlc3Npbmcg ZW5zdXJlIHRoYXQgdGhlIHJlc3BvbmRlciB3aWxsDQogICBuZXZlciBzZW5kIGFuIFNBIHBheWxv YWQgY29udGFpbmluZyB0aGUgSUlWIHRyYW5zZm9ybSB0byBhbiBpbml0aWF0b3INCiAgIHRoYXQg ZG9lcyBub3Qgc3VwcG9ydCBJSVYuDQoNCknigJltIHdvbmRlcmluZyB3aGV0aGVyIHRoaXMgaXMg bmVjZXNzYXJ5IHRvIHN0YXRlIHRoaXMuICBGb3IgZXhhbXBsZSwgUkZDIDc2MzQgKHRoZSBDaGFD aGEgSVBzZWMgdHJhbnNmb3JtKSBkb2VzIG5vdCBoYXZlIGFueSBzaW1pbGFyIGxhbmd1YWdlLCBl dmVuIHRob3VnaCAobGlrZSB0aGlzIGRyYWZ0KSB0aGV5IGRlZmluZSBhIG5ldyB0cmFuc2Zvcm0g aWQuDQoNCkhvd2V2ZXIsIEnigJltIG5vdCBkZW1hbmRpbmcgYW55IGNoYW5nZTsgdGhlIHRleHQg anVzdCBzb3VuZHMgcmVkdW5kYW50IHRvIG1l4oCmDQoNCg0KDQpUaGUgcmVhc29uIGZvciBub3Qg aGF2aW5nIEFFU19DVFIgd2FzIHRoYXQgdGhlIHRyYW5zZm9ybSBpcyBvbiBpdHMgd2F5IHRvIGJl IHJldGlyZWQuIEkgcHJvcG9zZSB0byByZW1vdmUgQUVTLUNUUiwgYnV0IGlmIHRoZXJlIGlzIGEg bmVlZCB0byBwcm92aWRlIEFFUy1DVFIgd2l0aCBpbXBsaWNpdCBJViB3ZSBjb3VkbCBhbHNvIGFk ZCBhZGRpdGlvbmFsIGNvZGUgcG9pbnRzLg0KDQpJIGFtIGN1cnJlbnRseSBwcm9wb3NpbmcgdGhl IGZvbGxvd2luZyB0ZXh0Og0KDQpPTEQ6DQogICBBRVMtQ1RSLCBBRVMtQ0NNLCBBRVMtR0NNIGFu ZCBDaGFDaGEyMC1Qb2x5MTMwNSBhcmUgbGlrZWx5IHRvDQogICBpbXBsZW1lbnQgdGhlIGltcGxp Y2l0IElWIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50Lg0KDQpORVc6DQoNCiAgIEFFUy1DQ00s IEFFUy1HQ00gYW5kIENoYUNoYTIwLVBvbHkxMzA1IGFyZSBsaWtlbHkgdG8NCiAgIGltcGxlbWVu dCB0aGUgaW1wbGljaXQgSVYgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQuDQoNCldvcmtzIGZv ciBtZS4NCg0KDQpZb3VycywNCkRhbmllbA0KT24gU3VuLCBNYXIgMjUsIDIwMTggYXQgMjoxMCBQ TSwgU2NvdHQgRmx1aHJlciAoc2ZsdWhyZXIpIDxzZmx1aHJlckBjaXNjby5jb208bWFpbHRvOnNm bHVocmVyQGNpc2NvLmNvbT4+IHdyb3RlOg0KDQotICAgICAgICAgIFNlY3Rpb24gNDog4oCcU2Vj dGlvbiAzLjUgb2YgW1JGQzY0MDddIGV4cGxhaW5zIGhvdyByZXBldGl0aW9uIE1BWSBCRSBwcmV2 ZW50ZWQgYnkgdXNpbmcgYSBwcmVmaXggZm9yIGVhY2ggZ3JvdXAgbWVtYmVy4oCdDQpBY3R1YWxs eSwgUkZDNjQwNyBqdXN0IHJlZmVycyB0byBSRkM2MDU0OyB0aGF0IGhhcyB0aGUgU0lEIGluIHRo ZSB0b3AgOCBiaXRzIG9mIHRoZSA4IGJ5dGUgc2VxdWVuY2UgbnVtYmVyLiAgVXNlZCBsaXRlcmFs bHksIHRoaXMgZG9lc27igJl0IHdvcmssIGFzIHRoZSB0b3AgOCBiaXRzIG9mIHRoZSA4IGJ5dGUg c2VxdWVuY2UgbnVtYmVyIGFyZSBuZXZlciBleHByZXNzZWQgaW4gdGhlIHBhY2tldCBpbiBpbXBs aWNpdC1pdi4gIFlvdSBjb3VsZCBwdXQgdGhlbSBpbiB0aGUgdG9wIDggYml0cyBvZiB0aGUgNCBi eXRlIHNlcXVlbmNlIG51bWJlciAod2hpY2ggbWVhbnMgeW91IGNhbuKAmXQgdXNlIEVTTiwgYnV0 IGl0IGRpZG7igJl0IHdvcmsgaW4gdGhlIG11bHRpc2VuZGVyIGNhc2UgYW55d2F5cyksIGJ1dCB0 aGF0IHdvdWxkIG1lYW4gdGhhdCBlYWNoIHNlbmRlciB3b3VsZCBiZSBsaW1pdGVkIHRvIDE2TSBw YWNrZXRzLiBJIGJlbGlldmUgdGhhdCB0aGVzZSBkZXRhaWxzIGFyZSBkaXN0aW5jdCBlbm91Z2gg dGhhdCAoaWYgdGhpcyBpcyBjb25zaWRlcmVkIGEgdmlhYmxlIGFsdGVybmF0aXZlKSB0aGV5IHNo b3VsZCBiZSBleHBsaWNpdGx5IGxpc3RlZCAoaW5jbHVkaW5nIHRoZSAxNk0gcGFja2V0IHJlc3Ry aWN0aW9uKS4gIEFsdGVybmF0aXZlbHksIHdlIGNhbiBqdXN0IGZvcmJpZCB0aGlzIHRyYW5zZm9y bSBpbiB0aGUgbXVsdGlzZW5kZXIgY2FzZS4NCg0KDQotICAgICAgICAgIFNlY3Rpb24gNjog4oCc VGhlIHJ1bGVzIG9mIFNBIHBheWxvYWQgcHJvY2Vzc2luZyBlbnN1cmUgdGhhdCB0aGUgcmVzcG9u ZGVyIHdpbGwgbmV2ZXIgc2VuZCBhbiBTQSBwYXlsb2FkIGNvbnRhaW5pbmcgdGhlIElJViBpbmRp Y2F0b3IgdG8gYW4gaW5pdGlhdG9yIHRoYXQgZG9lcyBub3Qgc3VwcG9ydCBJSVbigJ0NCg0KSSBi ZWxpZXZlIHRoYXQgdGhpcyBpcyBzdGFsZSB0ZXh0OyB0aGUgY3VycmVudCBkcmFmdCBkb2VzbuKA mXQgdXNlIGFuIGluZGljYXRvcjsgaW5zdGVhZCwgaXQgZGVmaW5lcyBzZXBhcmF0ZSB0cmFuc2Zv cm1zIElEcy4NCg0KDQotICAgICAgICAgIFNlY3Rpb24gOCBoYXMg4oCcQUVTLUNUUiDigKYgW2lz XSBsaWtlbHkgdG8gaW1wbGVtZW50IHRoZSBpbXBsaWNpdCBJViBkZXNjcmliZWQgaW4gdGhpcyBk b2N1bWVudOKAnTsgaG93ZXZlciB0aGUgdHJhbnNmb3JtIEVOQ1JfQUVTX0NUUl9JSVYgaXMgbm90 IGRlZmluZWQuICBJcyB0aGlzIGludGVuZGVkPyAgU2hvdWxkIHdlIGVpdGhlciByZW1vdmUgdGhl IEFFUy1DVFIgYWxnb3JpdGhtIGZyb20gdGhlIGxpc3Qgb2Yg4oCcbGlrZWx5IHRvIGltcGxlbWVu dOKAnSwgb3Igc2hvdWxkIHdlIGFjdHVhbGx5IGRlZmluZSB0aGUgdHJhbnNmb3JtIGlkIGZvciBp dD8NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpJUHNlYyBtYWlsaW5nIGxpc3QNCklQc2VjQGlldGYub3JnPG1haWx0bzpJUHNlY0BpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMNCg0K --_000_157d7bd1e99b4044bec2ba4412d8e873XCHRTP006ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAuZ21haWwtbS04MDE4Mzg1 OTgzNjU2NDE1ODltLTQ2ODI5NzIyNTg5NTA2NDgxODVtc29saXN0cGFyYWdyYXBoLCBsaS5nbWFp bC1tLTgwMTgzODU5ODM2NTY0MTU4OW0tNDY4Mjk3MjI1ODk1MDY0ODE4NW1zb2xpc3RwYXJhZ3Jh cGgsIGRpdi5nbWFpbC1tLTgwMTgzODU5ODM2NTY0MTU4OW0tNDY4Mjk3MjI1ODk1MDY0ODE4NW1z b2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwtbV8tODAxODM4NTk4MzY1NjQx NTg5bV8tNDY4Mjk3MjI1ODk1MDY0ODE4NW1zb2xpc3RwYXJhZ3JhcGg7DQoJbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow aW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4gbWdsdC5pZXRmQGdtYWlsLmNvbSAmbHQ7bWdsdC5pZXRmQGdtYWlsLmNv bSZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+RGFuaWVsIE1pZ2F1bHQ8YnI+DQo8Yj5TZW50Ojwv Yj4gVHVlc2RheSwgTWFyY2ggMjcsIDIwMTggMToyMiBQTTxicj4NCjxiPlRvOjwvYj4gU2NvdHQg Rmx1aHJlciAoc2ZsdWhyZXIpICZsdDtzZmx1aHJlckBjaXNjby5jb20mZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiBJUHNlY21lIFdHIChpcHNlY0BpZXRmLm9yZykgJmx0O2lwc2VjQGlldGYub3JnJmd0Ozxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0lQc2VjXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLWlw c2VjbWUtaW1wbGljaXQtaXY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhhbmsgeW91IFNjb3R0IGZvciB5b3VyIGNvbW1lbnRzLiA8YnI+DQo8 YnI+DQpJIHVuZGVyc3RhbmQgdGhlIGZpcnN0IGNvbW1lbnQgYXMgYSB0ZXh0IGNsYXJpZmljYXRp b24gdG8gY29tbWVudCBvbiB0aGUgbWVjaGFuaXNtIHByb3ZpZGVkIGJ5IHNlY3Rpb24gMy41IG9m IFJGQzY0MDcgYW5kIGV4cGxpY2l0ZWx5IG1lbnRpb24gdGhhdCBpcyBkb2VzIG5vdCBhcHBseSBo ZXJlLiBEb2VzIHRoZSByZXBsYWNlbWVudCBiZWxvdyBhZGRyZXNzZXMgeW91ciBjb25jZXJuID88 YnI+DQo8YnI+DQpPTEQ6PGJyPg0KJm5ic3A7Jm5ic3A7IFNlY3Rpb24gMy41IG9mIFtSRkM2NDA3 XSBleHBsYWlucyBob3c8YnI+DQombmJzcDsmbmJzcDsgcmVwZXRpdGlvbiBNQVkgQkUgcHJldmVu dGVkIGJ5IHVzaW5nIGEgcHJlZml4IGZvciBlYWNoIGdyb3VwIG1lbWJlciw8YnI+DQombmJzcDsm bmJzcDsgd2hpY2ggY291bGQgYmUgcHJlZml4ZWQgdG8gdGhlIFNlcXVlbmNlIE51bWJlci4mbmJz cDsgT3RoZXJ3aXNlLCBJbXBsaWNpdDxicj4NCiZuYnNwOyZuYnNwOyBJViBNVVNUIE5PVCBiZSB1 c2VkIGluIG11bHRpY2FzdCBzY2VuYXJpb3MuPGJyPg0KPGJyPg0KTkVXOjxicj4NCiZuYnNwOyZu YnNwOyBTZWN0aW9uIDMuNSBvZiBbUkZDNjQwN10gcHJvdmlkZXMgYSBtZWNoYW5pc20gdGhhdCBN QVkgYmUgdXNlZCB0byBwcmV2ZW50IElWIGNvbGxpc2lvbnMgd2hlbiB0aGUgc2FtZSBrZXkgaXMg dXNlZCBieSBtdWx0aXBsZSB1c2Vycy4gVGhlIG1lY2hhbmlzbSBjb25zaXN0cyBpbiBwYXJ0aXRp b25pbmcgdGhlIElWIHNwYWNlIGJldHdlZW4gdXNlcnMgYnkgYXNzaWduaW5nIHRoZSBtb3N0IHNp Z25pZmljYW50IGJ5dGUgdG8gYSB1c2VyLiBXaGVuDQogaW1wbGljaXQgSVYgdHJhbnNmb3JtcyBh cmUgdXNlZCwgc3VjaCBtZWNoYW5pc20gY2Fubm90IGJlIGFwcGxpZWQgYXMgdGhlIElWIGlzIG5v dCBzZW50LCBidXQgaW5zdGVhZCBpdCBpcyBkZXJpdmVkIGZyb20gdGhlIFNlcXVlbmNlIE51bWJl ci4gQSBzaW1pbGFyIG1lY2hhbmlzbSBjb3VsZCBiZSB1c2VkIGJ5IGFzc29jaWF0aW5nIHRoZSBt b3N0IHNpZ25pZmljYW50IGJ5dGUgb2YgdGhlIFNlcXVlbmNlIE51bWJlciB0byBhIHNlbmRlciwg d2hpbGUNCiB0aGUgMyByZW1haW5pbmcgYnl0ZXMgd2lsbCBiZSB1c2VkIHRvIGNhcnJ5IHRoZSBj b3VudGVyIHZhbHVlLiBTdWNoIG1lY2hhbmlzbSBwcmV2ZW50cyB0aGUgdXNlIG9mIEV4dGVuZGVk IFNlcXVlbmNlIE51bWJlciBhbmQgbGltaXRzIHRoZSBudW1iZXIgb2YgcGFja2V0IHRvIGJlIHNl bnQgdG8gMioqIDI0ID0mbmJzcDsgMTY3NzcyMTYsIHRoYXQgaXMgMTYgTS4NCjxicj4NCjxicj4N ClVubGVzcyBzb21lIG1lY2hhbmlzbSBhcmUgcHJvdmlkZWQgdG8gYXZvaWQgY29sbGlzaW9uIGJl dHdlZW4gU2VxdWVuY2UgTnVtYmVyLCAoIGFuZCBzbyBJViApLCBJbXBsaWNpdCBJViBNVVNUIE5P VCBiZSB1c2VkLg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhdCB3b3Jrc+KApjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NClJlZ2FyZGluZyB0 aGUgc2Vjb25kIGNvbW1lbnQsIEkgZ3Vlc3MgdGhlIGlkZWEgd2FzIHRvIG1lbnRpb24gdGhhdCBh IHJlc3BvbnNlciBjYW5ub3Qgc2VsZWN0IGEgSUlWIFRyYW5zZm9ybSB1bmxlc3MgYmVpbmcgc2Vu dCBieSB0aGUgaW5pdGlhdG9yLiBJIHByb3Bvc2UgdGhlIGZvbGxvd2luZyB0ZXh0LiBEbyBpdCBh ZGRyZXNzIHlvdXIgY29tbWVudCA/PGJyPg0KPGJyPg0KT0xEOjxicj4NCjxicj4NCiZuYnNwOyZu YnNwOyBUaGUgcnVsZXMgb2YgU0EgcGF5bG9hZCBwcm9jZXNzaW5nIGVuc3VyZSB0aGF0IHRoZSBy ZXNwb25kZXIgd2lsbDxicj4NCiZuYnNwOyZuYnNwOyBuZXZlciBzZW5kIGFuIFNBIHBheWxvYWQg Y29udGFpbmluZyB0aGUgSUlWIGluZGljYXRvciB0byBhbiBpbml0aWF0b3I8YnI+DQombmJzcDsm bmJzcDsgdGhhdCBkb2VzIG5vdCBzdXBwb3J0IElJVi48YnI+DQo8YnI+DQo8YnI+DQpORVc6PGJy Pg0KPGJyPg0KJm5ic3A7Jm5ic3A7IFRoZSBydWxlcyBvZiBTQSBwYXlsb2FkIHByb2Nlc3Npbmcg ZW5zdXJlIHRoYXQgdGhlIHJlc3BvbmRlciB3aWxsPGJyPg0KJm5ic3A7Jm5ic3A7IG5ldmVyIHNl bmQgYW4gU0EgcGF5bG9hZCBjb250YWluaW5nIHRoZSBJSVYgdHJhbnNmb3JtIHRvIGFuIGluaXRp YXRvcjxicj4NCiZuYnNwOyZuYnNwOyB0aGF0IGRvZXMgbm90IHN1cHBvcnQgSUlWLjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPknigJltIHdvbmRlcmluZyB3aGV0aGVyIHRoaXMgaXMgbmVjZXNzYXJ5IHRvIHN0YXRl IHRoaXMuJm5ic3A7IEZvciBleGFtcGxlLCBSRkMgNzYzNCAodGhlIENoYUNoYSBJUHNlYyB0cmFu c2Zvcm0pIGRvZXMgbm90IGhhdmUgYW55IHNpbWlsYXIgbGFuZ3VhZ2UsIGV2ZW4gdGhvdWdoIChs aWtlDQogdGhpcyBkcmFmdCkgdGhleSBkZWZpbmUgYSBuZXcgdHJhbnNmb3JtIGlkLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SG93ZXZlciwgSeKAmW0gbm90IGRl bWFuZGluZyBhbnkgY2hhbmdlOyB0aGUgdGV4dCBqdXN0IHNvdW5kcyByZWR1bmRhbnQgdG8gbWXi gKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KVGhlIHJlYXNvbiBmb3Igbm90IGhhdmluZyBBRVNf Q1RSIHdhcyB0aGF0IHRoZSB0cmFuc2Zvcm0gaXMgb24gaXRzIHdheSB0byBiZSByZXRpcmVkLiBJ IHByb3Bvc2UgdG8gcmVtb3ZlIEFFUy1DVFIsIGJ1dCBpZiB0aGVyZSBpcyBhIG5lZWQgdG8gcHJv dmlkZSBBRVMtQ1RSIHdpdGggaW1wbGljaXQgSVYgd2UgY291ZGwgYWxzbyBhZGQgYWRkaXRpb25h bCBjb2RlIHBvaW50cy4NCjxicj4NCjxicj4NCkkgYW0gY3VycmVudGx5IHByb3Bvc2luZyB0aGUg Zm9sbG93aW5nIHRleHQ6PGJyPg0KPGJyPg0KT0xEOjxicj4NCiZuYnNwOyZuYnNwOyBBRVMtQ1RS LCBBRVMtQ0NNLCBBRVMtR0NNIGFuZCBDaGFDaGEyMC1Qb2x5MTMwNSBhcmUgbGlrZWx5IHRvPGJy Pg0KJm5ic3A7Jm5ic3A7IGltcGxlbWVudCB0aGUgaW1wbGljaXQgSVYgZGVzY3JpYmVkIGluIHRo aXMgZG9jdW1lbnQuJm5ic3A7IDxicj4NCjxicj4NCk5FVzo8YnI+DQo8YnI+DQombmJzcDsmbmJz cDsgQUVTLUNDTSwgQUVTLUdDTSBhbmQgQ2hhQ2hhMjAtUG9seTEzMDUgYXJlIGxpa2VseSB0bzxi cj4NCiZuYnNwOyZuYnNwOyBpbXBsZW1lbnQgdGhlIGltcGxpY2l0IElWIGRlc2NyaWJlZCBpbiB0 aGlzIGRvY3VtZW50LiZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ V29ya3MgZm9yIG1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPllvdXJzLCA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+RGFuaWVsPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU3VuLCBN YXIgMjUsIDIwMTggYXQgMjoxMCBQTSwgU2NvdHQgRmx1aHJlciAoc2ZsdWhyZXIpICZsdDs8YSBo cmVmPSJtYWlsdG86c2ZsdWhyZXJAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+c2ZsdWhyZXJA Y2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iZ21haWwtbS04MDE4Mzg1OTgzNjU2NDE1ODltLTQ2ODI5NzIy NTg5NTA2NDgxODVtc29saXN0cGFyYWdyYXBoIj4tJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNlY3Rpb24gNDog4oCcU2VjdGlvbiAzLjUgb2Yg W1JGQzY0MDddIGV4cGxhaW5zIGhvdyByZXBldGl0aW9uIE1BWSBCRSBwcmV2ZW50ZWQgYnkgdXNp bmcgYSBwcmVmaXggZm9yIGVhY2ggZ3JvdXAgbWVtYmVy4oCdPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQpBY3R1YWxseSwgUkZDNjQwNyBq dXN0IHJlZmVycyB0byBSRkM2MDU0OyB0aGF0IGhhcyB0aGUgU0lEIGluIHRoZSB0b3AgOCBiaXRz IG9mIHRoZSA4IGJ5dGUgc2VxdWVuY2UgbnVtYmVyLiZuYnNwOyBVc2VkIGxpdGVyYWxseSwgdGhp cyBkb2VzbuKAmXQgd29yaywgYXMgdGhlIHRvcCA4IGJpdHMgb2YgdGhlIDggYnl0ZSBzZXF1ZW5j ZSBudW1iZXIgYXJlIG5ldmVyIGV4cHJlc3NlZCBpbiB0aGUgcGFja2V0IGluIGltcGxpY2l0LWl2 LiZuYnNwOyBZb3UgY291bGQgcHV0DQogdGhlbSBpbiB0aGUgdG9wIDggYml0cyBvZiB0aGUgNCBi eXRlIHNlcXVlbmNlIG51bWJlciAod2hpY2ggbWVhbnMgeW91IGNhbuKAmXQgdXNlIEVTTiwgYnV0 IGl0IGRpZG7igJl0IHdvcmsgaW4gdGhlIG11bHRpc2VuZGVyIGNhc2UgYW55d2F5cyksIGJ1dCB0 aGF0IHdvdWxkIG1lYW4gdGhhdCBlYWNoIHNlbmRlciB3b3VsZCBiZSBsaW1pdGVkIHRvIDE2TSBw YWNrZXRzLiBJIGJlbGlldmUgdGhhdCB0aGVzZSBkZXRhaWxzIGFyZSBkaXN0aW5jdCBlbm91Z2gN CiB0aGF0IChpZiB0aGlzIGlzIGNvbnNpZGVyZWQgYSB2aWFibGUgYWx0ZXJuYXRpdmUpIHRoZXkg c2hvdWxkIGJlIGV4cGxpY2l0bHkgbGlzdGVkIChpbmNsdWRpbmcgdGhlIDE2TSBwYWNrZXQgcmVz dHJpY3Rpb24pLiZuYnNwOyBBbHRlcm5hdGl2ZWx5LCB3ZSBjYW4ganVzdCBmb3JiaWQgdGhpcyB0 cmFuc2Zvcm0gaW4gdGhlIG11bHRpc2VuZGVyIGNhc2UuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJnbWFpbC1tLTgwMTgzODU5ODM2NTY0MTU4OW0tNDY4Mjk3MjI1ODk1MDY0ODE4 NW1zb2xpc3RwYXJhZ3JhcGgiPi0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgU2VjdGlvbiA2OiDigJxUaGUgcnVsZXMgb2YgU0EgcGF5bG9hZCBw cm9jZXNzaW5nIGVuc3VyZSB0aGF0IHRoZSByZXNwb25kZXIgd2lsbCBuZXZlciBzZW5kIGFuIFNB IHBheWxvYWQgY29udGFpbmluZyB0aGUgSUlWIGluZGljYXRvciB0byBhbiBpbml0aWF0b3IgdGhh dCBkb2VzIG5vdCBzdXBwb3J0IElJVuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWls LW0tODAxODM4NTk4MzY1NjQxNTg5bS00NjgyOTcyMjU4OTUwNjQ4MTg1bXNvbGlzdHBhcmFncmFw aCI+SSBiZWxpZXZlIHRoYXQgdGhpcyBpcyBzdGFsZSB0ZXh0OyB0aGUgY3VycmVudCBkcmFmdCBk b2VzbuKAmXQgdXNlIGFuIGluZGljYXRvcjsgaW5zdGVhZCwgaXQgZGVmaW5lcyBzZXBhcmF0ZSB0 cmFuc2Zvcm1zIElEcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDouNWluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0t ODAxODM4NTk4MzY1NjQxNTg5bS00NjgyOTcyMjU4OTUwNjQ4MTg1bXNvbGlzdHBhcmFncmFwaCI+ LSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBT ZWN0aW9uIDggaGFzIOKAnEFFUy1DVFIg4oCmIFtpc10gbGlrZWx5IHRvIGltcGxlbWVudCB0aGUg aW1wbGljaXQgSVYgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnTigJ07IGhvd2V2ZXIgdGhlIHRy YW5zZm9ybSBFTkNSX0FFU19DVFJfSUlWIGlzIG5vdCBkZWZpbmVkLiZuYnNwOyBJcyB0aGlzIGlu dGVuZGVkPyZuYnNwOyBTaG91bGQNCiB3ZSBlaXRoZXIgcmVtb3ZlIHRoZSBBRVMtQ1RSIGFsZ29y aXRobSBmcm9tIHRoZSBsaXN0IG9mIOKAnGxpa2VseSB0byBpbXBsZW1lbnTigJ0sIG9yIHNob3Vs ZCB3ZSBhY3R1YWxseSBkZWZpbmUgdGhlIHRyYW5zZm9ybSBpZCBmb3IgaXQ/PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iZ21haWwtbS04MDE4Mzg1OTgzNjU2NDE1ODltLTQ2ODI5NzIyNTg5NTA2 NDgxODVtc29saXN0cGFyYWdyYXBoIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxi cj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K SVBzZWMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOklQc2VjQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+SVBzZWNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNlYyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWM8L2E+PG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_157d7bd1e99b4044bec2ba4412d8e873XCHRTP006ciscocom_-- From nobody Tue Mar 27 11:10:36 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 2C7E612D77C for ; Tue, 27 Mar 2018 11:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1VokLXfmLp1 for ; Tue, 27 Mar 2018 11:10:30 -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 340B312778E for ; Tue, 27 Mar 2018 11:10:30 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id q5-v6so9382401lff.12 for ; Tue, 27 Mar 2018 11:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=XU40LUUjBW+ckbGCqeU+YVKvYw3LFrBmMDQLZ9+X150=; b=mJZaeK+voIsLo24tmhcG7cNsfuefJoFf2TLBpxI5wcChYVYec1HXqLc+tbgQmz0S9S JHiwyutR70P5sGrA/SvJUvTWkhKAqLzrl9UbUN3HzjayliP+TMtJXOyr5fR+nuPY+oBw kb/L3u6BDBBW955ehdDGUFexpH9UNFn9j5/C4Y5IO1iXTuNhocGiC7xPh64a6YM2vumF jOyD0Nbj2VyUGQsWKvKQDk/bwdAc5wPgDIyHclk2F2IxH3zj0rt4YTi2SMqHJQsh4en7 cVvOBwszCI0hzriaEnl79ANZ2KuQq0el5fuhCbiLaGWpAU6A7fvKQ2s+hRgVIVuFi9BM t57g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=XU40LUUjBW+ckbGCqeU+YVKvYw3LFrBmMDQLZ9+X150=; b=O0dvPEXWrgzMsauBvnKU2tJlbTzVtYWNrwNNaH6jfEK3IFReuZZDiytVuV53KQFcDR LnN/HohHXuf7HMyMiqfW/utGJSBeRFGI3uZf7sJZqay+KhbMjboc2JjtNnNKjn7Gq6SU 1IFEzdJ3hQcXD8dXRn7/ijJ1x0Xr1CnDhjr0IY5ogGskAagB/B0kr16ixqHR03ya8Q0h JEnMCXYGyvZG6x7+Lmzx2yHGEDcTesxCPeYGWa+9A7cYvcRY8OP6FdD3pOl6gcs9wyEb VMDKtxTxtTkVOiepxVsBNZ9+zaNdb3vH6dnAqCPfQ3KYL/zDz7hGaavNzL1j6kABlc+T 7MhQ== X-Gm-Message-State: AElRT7HgyP0klQmq18DmgB2V16WRneHFQrh4km/H4bm0Zye650Fr46UF T9dq4a1QFxiNh+gIA/qwlTbJJddi5Ok8da0hum0= X-Google-Smtp-Source: AIpwx4/PHEPG6cmgQdASVXY+SznEF8EB0Ic7ULItcmWEW5KLk9LJ6KkDw4UtGtiduKe7tBCMBT8WJ1t7EI7xaqa3enM= X-Received: by 10.46.122.15 with SMTP id v15mr231210ljc.7.1522174228448; Tue, 27 Mar 2018 11:10:28 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.158.19 with HTTP; Tue, 27 Mar 2018 11:10:27 -0700 (PDT) In-Reply-To: <157d7bd1e99b4044bec2ba4412d8e873@XCH-RTP-006.cisco.com> References: <4c9091a6469945478d0fbce30447da94@XCH-RTP-006.cisco.com> <157d7bd1e99b4044bec2ba4412d8e873@XCH-RTP-006.cisco.com> From: Daniel Migault Date: Tue, 27 Mar 2018 14:10:27 -0400 X-Google-Sender-Auth: ALA0ZtmiXMhIAoJbaZwUvwnWiJo Message-ID: To: "Scott Fluhrer (sfluhrer)" Cc: "IPsecme WG (ipsec@ietf.org)" Content-Type: multipart/alternative; boundary="f4f5e8067d902c4ebc056868ce21" Archived-At: Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-implicit-iv 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, 27 Mar 2018 18:10:34 -0000 --f4f5e8067d902c4ebc056868ce21 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks a lot Scott for the response. I am publishing the draft asap. Yours, Daniel On Tue, Mar 27, 2018 at 2:04 PM, Scott Fluhrer (sfluhrer) < sfluhrer@cisco.com> wrote: > > > *From:* mglt.ietf@gmail.com *On Behalf Of *Daniel > Migault > *Sent:* Tuesday, March 27, 2018 1:22 PM > *To:* Scott Fluhrer (sfluhrer) > *Cc:* IPsecme WG (ipsec@ietf.org) > *Subject:* Re: [IPsec] Comments on draft-ietf-ipsecme-implicit-iv > > > > Thank you Scott for your comments. > > I understand the first comment as a text clarification to comment on the > mechanism provided by section 3.5 of RFC6407 and explicitely mention that > is does not apply here. Does the replacement below addresses your concern= ? > > OLD: > Section 3.5 of [RFC6407] explains how > repetition MAY BE prevented by using a prefix for each group member, > which could be prefixed to the Sequence Number. Otherwise, Implicit > IV MUST NOT be used in multicast scenarios. > > NEW: > Section 3.5 of [RFC6407] provides a mechanism that MAY be used to > prevent IV collisions when the same key is used by multiple users. The > mechanism consists in partitioning the IV space between users by assignin= g > the most significant byte to a user. When implicit IV transforms are used= , > such mechanism cannot be applied as the IV is not sent, but instead it is > derived from the Sequence Number. 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 =3D 16777216, that is 16 M. > > Unless some mechanism are provided to avoid collision between Sequence > Number, ( and so IV ), Implicit IV MUST NOT be used. > > > > That works=E2=80=A6 > > > > > Regarding the second comment, I guess the idea was to mention that a > responser cannot select a IIV Transform unless being sent by the initiato= r. > I propose the following text. Do it address your comment ? > > OLD: > > The rules of SA payload processing ensure that the responder will > never send an SA payload containing the IIV indicator to an initiator > that does not support IIV. > > > NEW: > > The rules of SA payload processing ensure that the responder will > never send an SA payload containing the IIV transform to an initiator > that does not support IIV. > > > > I=E2=80=99m wondering whether this is necessary to state this. For examp= le, RFC > 7634 (the ChaCha IPsec transform) does not have any similar language, eve= n > though (like this draft) they define a new transform id. > > > > However, I=E2=80=99m not demanding any change; the text just sounds redun= dant to > me=E2=80=A6 > > > > > > The reason for not having AES_CTR was that the transform is on its way to > be retired. I propose to remove AES-CTR, but if there is a need to provid= e > AES-CTR with implicit IV we coudl also add additional code points. > > I am currently proposing the following text: > > OLD: > AES-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to > implement the implicit IV described in this document. > > NEW: > > AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to > implement the implicit IV described in this document. > > > > Works for me. > > > > > > Yours, > > Daniel > > On Sun, Mar 25, 2018 at 2:10 PM, Scott Fluhrer (sfluhrer) < > sfluhrer@cisco.com> wrote: > > - Section 4: =E2=80=9CSection 3.5 of [RFC6407] explains how repe= tition > MAY BE prevented by using a prefix for each group member=E2=80=9D > > Actually, RFC6407 just refers to RFC6054; that has the SID in the top 8 > bits of the 8 byte sequence number. Used literally, this doesn=E2=80=99t= work, as > the top 8 bits of the 8 byte sequence number are never expressed in the > packet in implicit-iv. You could put them in the top 8 bits of the 4 byt= e > sequence number (which means you can=E2=80=99t use ESN, but it didn=E2=80= =99t work in the > multisender case anyways), but that would mean that each sender would be > limited to 16M packets. I believe that these details are distinct enough > that (if this is considered a viable alternative) they should be explicit= ly > listed (including the 16M packet restriction). Alternatively, we can jus= t > forbid this transform in the multisender case. > > > > - Section 6: =E2=80=9CThe rules of SA payload processing ensure = that the > responder will never send an SA payload containing the IIV indicator to a= n > initiator that does not support IIV=E2=80=9D > > I believe that this is stale text; the current draft doesn=E2=80=99t use = an > indicator; instead, it defines separate transforms IDs. > > > > - Section 8 has =E2=80=9CAES-CTR =E2=80=A6 [is] likely to implem= ent the implicit > IV described in this document=E2=80=9D; however the transform ENCR_AES_CT= R_IIV is > not defined. Is this intended? Should we either remove the AES-CTR > algorithm from the list of =E2=80=9Clikely to implement=E2=80=9D, or shou= ld we actually > define the transform id for it? > > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > --f4f5e8067d902c4ebc056868ce21 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks a lot Scott for the response. I am publis= hing the draft asap.
Yours,
Daniel

On Tue, Mar 27, 2018 at 2:0= 4 PM, Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com> wrote:<= br>

=C2=A0

From: mglt.ietf@gmail.com <mglt.ietf@gmail.com> On Behalf Of Daniel Migault
Sent: Tuesday, March 27, 2018 1:22 PM
To: Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com>
Cc: IPsecme WG (= ipsec@ietf.org) <ipsec@ietf.org>
Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-implicit-iv

=C2=A0

Thank you Scott for your comments.

I understand the first comment as a text clarification to comment on the me= chanism provided by section 3.5 of RFC6407 and explicitely mention that is = does not apply here. Does the replacement below addresses your concern ?
OLD:
=C2=A0=C2=A0 Section 3.5 of [RFC6407] explains how
=C2=A0=C2=A0 repetition MAY BE prevented by using a prefix for each group m= ember,
=C2=A0=C2=A0 which could be prefixed to the Sequence Number.=C2=A0 Otherwis= e, Implicit
=C2=A0=C2=A0 IV MUST NOT be used in multicast scenarios.

NEW:
=C2=A0=C2=A0 Section 3.5 of [RFC6407] provides a mechanism that MAY be used= to prevent IV collisions when the same key is used by multiple users. The = mechanism consists in partitioning the IV space between users by assigning = the most significant byte to a user. When implicit IV transforms are used, such mechanism cannot be applied as the I= V is not sent, but instead it is derived from the Sequence Number. A simila= r mechanism could be used by associating the most significant byte of the S= equence Number to a sender, while the 3 remaining bytes will be used to carry the counter value. Such mechan= ism prevents the use of Extended Sequence Number and limits the number of p= acket to be sent to 2** 24 =3D=C2=A0 16777216, that is 16 M.

Unless some mechanism are provided to avoid collision between Sequence Numb= er, ( and so IV ), Implicit IV MUST NOT be used.

=C2=A0

That works=E2=80=A6<= /u>




Regarding the second comment, I guess the idea was to mention that a respon= ser cannot select a IIV Transform unless being sent by the initiator. I pro= pose the following text. Do it address your comment ?

OLD:

=C2=A0=C2=A0 The rules of SA payload processing ensure that the responder w= ill
=C2=A0=C2=A0 never send an SA payload containing the IIV indicator to an in= itiator
=C2=A0=C2=A0 that does not support IIV.


NEW:

=C2=A0=C2=A0 The rules of SA payload processing ensure that the responder w= ill
=C2=A0=C2=A0 never send an SA payload containing the IIV transform to an in= itiator
=C2=A0=C2=A0 that does not support IIV.

=C2=A0

I=E2=80=99m wondering whether = this is necessary to state this.=C2=A0 For example, RFC 7634 (the ChaCha IP= sec transform) does not have any similar language, even though (like this draft) they define a new transform id.

=C2=A0

However, I=E2=80=99m not demanding an= y change; the text just sounds redundant to me=E2=80=A6

=C2=A0



The reason for not having AES_CTR was that the transform is on its way to b= e retired. I propose to remove AES-CTR, but if there is a need to provide A= ES-CTR with implicit IV we coudl also add additional code points.

I am currently proposing the following text:

OLD:
=C2=A0=C2=A0 AES-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to<= br> =C2=A0=C2=A0 implement the implicit IV described in this document.=C2=A0
NEW:

=C2=A0=C2=A0 AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to
=C2=A0=C2=A0 implement the implicit IV described in this document.=C2=A0

=C2=A0

Works for me.

=C2=A0

=C2=A0<= /p>

Yours,

Daniel<= /p>

On Sun, Mar 25, 2018 at 2:10 PM, Scott Fluhrer (sflu= hrer) <sfluhrer@= cisco.com> wrote:

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Section 4: =E2=80=9CSection 3.5 of [RFC6407] explains how repetition MA= Y BE prevented by using a prefix for each group member=E2=80=9D

Actually, RFC6407 just refers to RFC6054; that has the SID in the top 8 bit= s of the 8 byte sequence number.=C2=A0 Used literally, this doesn=E2=80=99t= work, as the top 8 bits of the 8 byte sequence number are never expressed = in the packet in implicit-iv.=C2=A0 You could put them in the top 8 bits of the 4 byte sequence number (which means you can= =E2=80=99t use ESN, but it didn=E2=80=99t work in the multisender case anyw= ays), but that would mean that each sender would be limited to 16M packets.= I believe that these details are distinct enough that (if this is considered a viable alternative) they should be explicitl= y listed (including the 16M packet restriction).=C2=A0 Alternatively, we ca= n just forbid this transform in the multisender case.

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Section 6: =E2=80=9CThe rules of SA payload processing ensure that the = responder will never send an SA payload containing the IIV indicator to an = initiator that does not support IIV=E2=80=9D

I believe that this is stale text; the current draft = doesn=E2=80=99t use an indicator; instead, it defines separate transforms I= Ds.

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Section 8 has =E2=80=9CAES-CTR =E2=80=A6 [is] likely to implement the i= mplicit IV described in this document=E2=80=9D; however the transform ENCR_= AES_CTR_IIV is not defined.=C2=A0 Is this intended?=C2=A0 Should we either remove the AES-CTR algorithm from the list of =E2=80=9Clikely to= implement=E2=80=9D, or should we actually define the transform id for it?<= u>

=C2=A0


_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec

=C2=A0


_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


--f4f5e8067d902c4ebc056868ce21-- From nobody Tue Mar 27 13:21:27 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 CEB8212E8A8; Tue, 27 Mar 2018 13:21:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.76.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152218208077.5155.3699452751039821417@ietfa.amsl.com> Date: Tue, 27 Mar 2018 13:21:20 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-implicit-iv-02.txt 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, 27 Mar 2018 20:21:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Implicit IV for Counter-based Ciphers in Encapsulating Security Payload (ESP) Authors : Daniel Migault Tobias Guggemos Yoav Nir Filename : draft-ietf-ipsecme-implicit-iv-02.txt Pages : 7 Date : 2018-03-27 Abstract: Encapsulating Security Payload (ESP) sends an initialization vector (IV) or nonce in each packet. The size of IV depends on the applied transform, being usually 8 or 16 octets for the transforms defined by the time this document is written. Some algorithms such as AES-GCM, AES-CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do not require an unpredictable nonce. When using such algorithms the packet counter value can be used to generate a nonce. This avoids sending the nonce itself, and savec in the case of AES-GCM, AES-CCM, AES-CTR and ChaCha20-Poly1305 8 octets per packet. This document describes how to do this. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-02 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-implicit-iv-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-implicit-iv-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/