From nobody Tue Aug 1 00:24:07 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F0A1329D5; Tue, 1 Aug 2017 00:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bRx_ia1-kjl; Tue, 1 Aug 2017 00:24:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 346821329D0; Tue, 1 Aug 2017 00:24:02 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML713-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLR40871; Tue, 01 Aug 2017 07:23:59 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 1 Aug 2017 08:23:58 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Tue, 1 Aug 2017 15:23:53 +0800 From: Sheng Jiang To: "anima@ietf.org" CC: "anima-chairs@ietf.org" Thread-Topic: Result of WGLC on draft-ietf-anima-stable-connectivity-03 - Respond by July 28, 2017 Thread-Index: AdMKleelDDiuTNvHRt24j9Uwizs6zg== Date: Tue, 1 Aug 2017 07:23:52 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927CE3D7BA@NKGEML515-MBX.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.124.96] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B927CE3D7BANKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.59802C90.00C4, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 950a78b148f5c41b14758da38314ccfd Archived-At: Subject: [Anima] Result of WGLC on draft-ietf-anima-stable-connectivity-03 - Respond by July 28, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 07:24:06 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B927CE3D7BANKGEML515MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIGFsbA0KDQpXZSByZWNlaXZlZCBubyBuZWdhdGl2ZSByZXNwb25zZSB0byB0aGUgV0dMQyBv biBkcmFmdC1pZXRmLWFuaW1hLXN0YWJsZS1jb25uZWN0aXZpdHktMDMgZHVyaW5nIHRoZSB0d28t d2VlayBXR0xDIGFuZCB3ZSBkaWQgcmVjZWl2ZSBnb29kIHJldmlld3MgdGhyb3VnaCB0aGUgV0cg ZG9jdW1lbnQgc3RhZ2UsIHRocm91Z2ggdGhlIHNoZXBoZXJkIHJldmlldyBwcm9jZXNzIGFuZCBX R0xDIHBlcmlvZC4gQ29uc2lkZXJpbmcgdGhlIHBhc3QgaGlzdG9yeSBvZiB0aGlzIHdvcmssIEks IHdpdGggbXkgQU5JTUEgY2hhaXIgY2FwIG9uLCBmZWVsIGl0IGlzIGhhcyBwYXNzZWQgdGhlIFdH TEMgYW5kIHNob3VsZCBhZHZhbmNlLiBUaGlzIGNvbmNsdXNpb24gaXMgbWFkZSB3aXRoIHRoZSBj b25kaXRpb24gdGhhdCB0aGUgYXV0aG9ycyB3b3VsZCBzb2x2ZSB0aGUgY29tbWVudHMgcmVjZWl2 ZWQgZHVyaW5nIHRoZSBXR0xDIGFuZCB0aGVzZSBtb2RpZmljYXRpb25zIHdlcmUgbm90IHN1YnN0 YW50aWFsIGNoYW5nZXMgZnJvbSAwMyB2ZXJzaW9uLiBJZiB0aGVyZSBhcmUgYmlnIGNoYW5nZXMs IGEgc2hvcnRlciBzZWNvbmQgV0dMQyBtYXkgYmUgbmVlZGVkLg0KDQpVcCB0byBub3csIHRoZXJl IGlzIG5vIElQUiBkaXNjbG9zdXJlIGxpbmtlZCB0byB0aGlzIGRvY3VtZW50Lg0KDQpPbmNlIHRo ZSB1cGRhdGUgaXMgcHVibGlzaGVkIGFuZCBpdCBtZWV0cyB0aGUgYWJvdmUgY29uZGl0aW9uLCBm b3Igd2hpY2ggdGhlIHNlY29uZCBXR0xDIGlzIG5vdCBuZWVkZWQsIGFzIHRoZSBkb2N1bWVudCBz aGVwaGVyZCwgSSB3aWxsIGZpbmFsaXplIHRoZSBzaGVwaGVyZCBkb2N1bWVudCBhbmQgc2VuZCB0 aGUgZG9jdW1lbnQgb24uDQoNCkJlc3QgcmVnYXJkcywNCg0KU2hlbmcgKGNvLWNoYWlyLCBUb2Vy bGVzcyB3aG8gYXMgYSBjby1hdXRob3Igc3RheWVkIG5ldXRyYWwgb24gdGhlIGNvbnRlbnQgc2lk ZSkNCg0K --_000_5D36713D8A4E7348A7E10DF7437A4B927CE3D7BANKGEML515MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0Kc3Bhbi5IVE1MQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTorr7m oLzlvI8gQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIOmihOiuvuagvOW8jyI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5 Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjVwdDtiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzMzMzMzMyI+SGksIGFs bDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjVw dDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29s b3I6IzMzMzMzMyI+V2UgcmVjZWl2ZWQgbm8gbmVnYXRpdmUgcmVzcG9uc2UgdG8gdGhlIFdHTEMg b24gZHJhZnQtaWV0Zi1hbmltYS1zdGFibGUtY29ubmVjdGl2aXR5LTAzIGR1cmluZyB0aGUgdHdv LXdlZWsgV0dMQyBhbmQgd2UgZGlkIHJlY2VpdmUgZ29vZCByZXZpZXdzIHRocm91Z2ggdGhlIFdH IGRvY3VtZW50IHN0YWdlLCB0aHJvdWdoIHRoZSBzaGVwaGVyZCByZXZpZXcgcHJvY2VzcyBhbmQg V0dMQyBwZXJpb2QuIENvbnNpZGVyaW5nIHRoZSBwYXN0IGhpc3Rvcnkgb2YgdGhpcyB3b3JrLCBJ LCB3aXRoIG15IEFOSU1BIGNoYWlyIGNhcCBvbiwgZmVlbCBpdCBpcyBoYXMgcGFzc2VkIHRoZSBX R0xDIGFuZCBzaG91bGQgYWR2YW5jZS4gVGhpcyBjb25jbHVzaW9uIGlzIG1hZGUgd2l0aCB0aGUg Y29uZGl0aW9uIHRoYXQgdGhlIGF1dGhvcnMgd291bGQgc29sdmUgdGhlIGNvbW1lbnRzIHJlY2Vp dmVkIGR1cmluZyB0aGUgV0dMQyBhbmQgdGhlc2UgbW9kaWZpY2F0aW9ucyB3ZXJlIG5vdCBzdWJz dGFudGlhbCBjaGFuZ2VzIGZyb20gMDMgdmVyc2lvbi4gSWYgdGhlcmUgYXJlIGJpZyBjaGFuZ2Vz LCBhIHNob3J0ZXIgc2Vjb25kIFdHTEMgbWF5IGJlIG5lZWRlZC48bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny41cHQ7YmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMzMzMzMzMiPlVwIHRvIG5v dywgdGhlcmUgaXMgbm8gSVBSIGRpc2Nsb3N1cmUgbGlua2VkIHRvIHRoaXMgZG9jdW1lbnQuPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuNXB0O2Jh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjoj MzMzMzMzIj5PbmNlIHRoZSB1cGRhdGUgaXMgcHVibGlzaGVkIGFuZCBpdCBtZWV0cyB0aGUgYWJv dmUgY29uZGl0aW9uLCBmb3Igd2hpY2ggdGhlIHNlY29uZCBXR0xDIGlzIG5vdCBuZWVkZWQsIGFz IHRoZSBkb2N1bWVudCBzaGVwaGVyZCwgSSB3aWxsIGZpbmFsaXplIHRoZSBzaGVwaGVyZCBkb2N1 bWVudCBhbmQgc2VuZCB0aGUgZG9jdW1lbnQgb24uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuNXB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMzMzMzMzIj5CZXN0IHJlZ2FyZHMsPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuNXB0O2Jh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjoj MzMzMzMzIj5TaGVuZyAoY28tY2hhaXIsIFRvZXJsZXNzIHdobyBhcyBhIGNvLWF1dGhvciBzdGF5 ZWQgbmV1dHJhbCBvbiB0aGUgY29udGVudCBzaWRlKTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_5D36713D8A4E7348A7E10DF7437A4B927CE3D7BANKGEML515MBXchi_-- From nobody Tue Aug 1 01:02:04 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C05A5132AD0; Tue, 1 Aug 2017 01:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhkdVDGoeqaD; Tue, 1 Aug 2017 01:01:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EED9D132AFC; Tue, 1 Aug 2017 01:01:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml709-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DSL71947; Tue, 01 Aug 2017 08:01:42 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 1 Aug 2017 09:01:41 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Tue, 1 Aug 2017 16:01:35 +0800 From: Sheng Jiang To: "6tisch@ietf.org" <6tisch@ietf.org>, "netconf@ietf.org" CC: "anima@ietf.org" , "anima-chairs@ietf.org" Thread-Topic: Cross-WGs WGLC (second) on draft-ietf-anima-voucher-04 - Respond by Aug 08, 2017 Thread-Index: AdMKmFTPR22MviVNQvGwNG9FbFt4tQ== Date: Tue, 1 Aug 2017 08:01:34 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927CE3D826@NKGEML515-MBX.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.124.96] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B927CE3D826NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.59803567.009B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: e3604ba37f96eec4d40b5a84bc8b5b05 Archived-At: Subject: [Anima] Cross-WGs WGLC (second) on draft-ietf-anima-voucher-04 - Respond by Aug 08, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 08:01:50 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B927CE3D826NKGEML515MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIDZ0aXNjaCwgbmV0Y29uZiwNCg0KVGhpcyBtZXNzYWdlIHN0YXJ0cyBhbiBvbmUtd2VlayBj cm9zcy1XR3MgV29ya2luZyBHcm91cCBMYXN0IENhbGwgb24gZHJhZnQtaWV0Zi1hbmltYS12b3Vj aGVyLTA0LCBWb3VjaGVyIFByb2ZpbGUgZm9yIEJvb3RzdHJhcHBpbmcgUHJvdG9jb2xzLCB3aGlj aCBwYXNzZWQgdHdvLXdlZWsgQU5JTUEgV0dMQyBpbiBKdW5lLCBidXQgcmVsZXZhbnQgdG8gNnRp c2NoIGFuZCBuZXRjb25mLiBUaGlzIGRvY3VtZW50J3MgaW50ZW5kZWQgc3RhdHVzIGlzIFN0YW5k YXJkcyBUcmFjay4gQXQgcHJlc2VudCwgdGhlcmUgaXMgbm8gSVBSIGZpbGUgYWdhaW5zdCB0aGlz IGRvY3VtZW50Lg0KDQpQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIGJ5IEF1Z3VzdCAwOCwgMjAx Ny4gSWYgeW91IGRvIG5vdCBmZWVsIHRoaXMgIGRvY3VtZW50IHNob3VsZCBhZHZhbmNlLCBwbGVh c2Ugc3RhdGUgeW91ciByZWFzb25zIHdoeS4NCg0KU2hlbmcgSklBTkcgKEFOSU1BIGNvLWNoYWly KSBpcyB0aGUgYXNzaWduZWQgc2hlcGhlcmQuDQoNClJlZ2FyZHMsDQoNClNoZW5nIChhbm90aGVy IEFOSU1BIGNvLWNoYWlyLCBUb2VybGVzcywgd2hvIGFzIGEgY28tYXV0aG9yIGlzIHN0YXlpbmcg bmV1dHJhbCkNCg== --_000_5D36713D8A4E7348A7E10DF7437A4B927CE3D826NKGEML515MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KaDMNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6Iuagh+mimCAzIENoYXIiOw0KCW1zby1tYXJnaW4t dG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMy41cHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3Nl Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0Kc3Bhbi4zQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi5qCH6aKYIDMgQ2hhciI7DQoJbXNvLXN0 eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6Iuagh+mimCAzIjsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCglmb250LXdlaWdodDpib2xkO30NCnAubXNnLWhl YWRlciwgbGkubXNnLWhlYWRlciwgZGl2Lm1zZy1oZWFkZXINCgl7bXNvLXN0eWxlLW5hbWU6bXNn LWhlYWRlcjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4u cGlwZQ0KCXttc28tc3R5bGUtbmFtZTpwaXBlO30NCnNwYW4uSFRNTENoYXINCgl7bXNvLXN0eWxl LW5hbWU6IkhUTUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8iOw0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5 MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny41 cHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzO2Nv bG9yOiMzMzMzMzMiPkhpLCA2dGlzY2gsIG5ldGNvbmYsPG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuNXB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMzMzMzMzIj5UaGlzIG1lc3NhZ2Ug c3RhcnRzIGFuIG9uZS13ZWVrIGNyb3NzLVdHcyBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBvbiBk cmFmdC1pZXRmLWFuaW1hLXZvdWNoZXItMDQsIFZvdWNoZXIgUHJvZmlsZSBmb3IgQm9vdHN0cmFw cGluZyBQcm90b2NvbHMsIHdoaWNoIHBhc3NlZCB0d28td2VlayBBTklNQSBXR0xDIGluIEp1bmUs IGJ1dCByZWxldmFudCB0byA2dGlzY2ggYW5kIG5ldGNvbmYuIFRoaXMgZG9jdW1lbnQncyBpbnRl bmRlZCBzdGF0dXMgaXMgU3RhbmRhcmRzIFRyYWNrLiBBdCBwcmVzZW50LCB0aGVyZSBpcyBubyBJ UFIgZmlsZSBhZ2FpbnN0IHRoaXMgZG9jdW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuNXB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMzMzMzMzIj5QbGVhc2Ugc2VuZCB5b3Vy IGNvbW1lbnRzIGJ5IEF1Z3VzdCAwOCwgMjAxNy4gSWYgeW91IGRvIG5vdCBmZWVsIHRoaXMmbmJz cDsgZG9jdW1lbnQgc2hvdWxkIGFkdmFuY2UsIHBsZWFzZSBzdGF0ZSB5b3VyIHJlYXNvbnMgd2h5 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjVw dDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29s b3I6IzMzMzMzMyI+U2hlbmcgSklBTkcgKEFOSU1BIGNvLWNoYWlyKSBpcyB0aGUgYXNzaWduZWQg c2hlcGhlcmQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjcuNXB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25z b2xhcztjb2xvcjojMzMzMzMzIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjVwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzMzMzMzMyI+U2hlbmcgKGFub3RoZXIgQU5J TUEgY28tY2hhaXIsIFRvZXJsZXNzLCB3aG8gYXMgYSBjby1hdXRob3IgaXMgc3RheWluZyBuZXV0 cmFsKTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5D36713D8A4E7348A7E10DF7437A4B927CE3D826NKGEML515MBXchi_-- From nobody Tue Aug 1 03:48:25 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31326132CF3; Tue, 1 Aug 2017 03:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yb7cO65eUrjt; Tue, 1 Aug 2017 03:48:05 -0700 (PDT) Received: from lb3-smtp-cloud8.xs4all.net (lb3-smtp-cloud8.xs4all.net [194.109.24.29]) (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 5AE84132064; Tue, 1 Aug 2017 03:48:03 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:205]) by smtp-cloud8.xs4all.net with ESMTPA id cUiWdOLY5Qs3acUiWdTur7; Tue, 01 Aug 2017 12:48:02 +0200 Received: from 2001:983:a264:1:e02d:215:e37:a526 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 01 Aug 2017 12:48:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 01 Aug 2017 12:48:00 +0200 From: peter van der Stok To: Sheng Jiang Cc: 6tisch@ietf.org, netconf@ietf.org, anima-chairs@ietf.org, anima@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B927CE3D826@NKGEML515-MBX.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B927CE3D826@NKGEML515-MBX.china.huawei.com> Message-ID: <76229c58f5d60d3a0c185c6645ba4355@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfBocXnfmrunqhWmJuSA5f25kfkgY+sNieHNwxtC0lfEWhjta0wohLS6No42V/TrN932K/oDYWuY/cEIZKr/KNe2hmZTojlWN96zh4oFZtgPZYTk//9Zd PppD7T/njVxEO97CdfJ+cEhKIUrfePQe4cNT37XL1MxulGwVKYAFSIw6iOfUx47NNyq3jskAWSHzubGQDNHNFB+bxh5PAVoj9F/A4tosljqm14e7OD1ljUlz Xv1F5EPx2mXqEkTXMxynCPWFVYcKOkZTfOS4YD2wbngGY1L04BQ3CLW4LRaZa1a+sdvdMQmk8ejHhDVzID66jQ== Archived-At: Subject: Re: [Anima] Cross-WGs WGLC (second) on draft-ietf-anima-voucher-04 - Respond by Aug 08, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 10:48:07 -0000 Hi all, I read this document, and find it well written and understandable. I do have some remarks about the content and several editing remarks. Content remarks: section 6, leaf prior-signed-voucher, at the end: The MASA SHOULD remove all "prior-signed-voucher". I would encourage a "MUST" instead of a "SHOULD" when thinking of transporting vouchers over constrained networks. section 6.3: leaf idevid-issuer, description, paragraph 2, "populated for serial numbers that are not otherwise unique" to be replaced by "populated when serial numbers are not unique". My proposed text is less selective, and consequently less error prone. Can a discussion section about "manufacturer additions" be added. Pointing out the consequences for interoperability when using "Augment" to add manufacturer specifics can be helpful. Editing remarks: Introduction, first phrase: pledge -> candidate device (pledge) page 3, PKCS#7 add RFC2315 reference, and may be add RFC7154 as JSON reference. Section 2; mention terminology from RFC7950 page 4 line 5; "process. i Typically" remove the "i" page 4, Voucher: add: that "acknowledges ownership of the pledge and" indicates... page 5 Authentication of: First appearances of PKIX, DNS-ID, and CN-ID abbreviations. page 5, add (MiTM) after Man-in-The-Middle. page 6 table: Voucher name -> Voucher type Nonceless Audit Voucher: "to support network partitions" -> "to withstand network partitions" Owenership audit Voucher: "Voucher's" -> "Vouchers", and remove "an ideal" otherwise explain what that means and why it is true. Add type in: Ownership ID voucher "type" is named Bearer Voucher "type" is named section 6 "The voucher is signing structure that" -> "The voucher signing structure" section 6, paragraph 6, all "of" the certificate, remove "of" section 6 page 7 below, First appearance of CA and JWS abbreviations section 6.1 (see section 4) add "see" section 6.3 page 10, module description: "securely assign one or more pledges to an 'owner'" seems to contradict section 7.2 voucher per pledge section 7.1 last line: "there is a delay" is that delay between creation and consumption and when is the delay unacceptable? the text is (on purpose?) vague. section 8.1 first paragraph: "no understandING of time", add "ing" section 8.1 paragraph 2: ephermal -> ephemeral section 8.2 compromized -> compromised? Hope this helps peter From nobody Tue Aug 1 12:57:54 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA612131C84; Tue, 1 Aug 2017 12:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3FxIJ5qGFwx; Tue, 1 Aug 2017 12:57:46 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::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 EC15F132301; Tue, 1 Aug 2017 12:57:45 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id o86so8467379pfj.1; Tue, 01 Aug 2017 12:57:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=48bcLC8P+I7Ak5paR+mvVLdodOKl5OZ0JwyG5sZzRqU=; b=bQO+TjvER8LateUMbj0iSXXZPw/6C8Qh36xsO3VRmvru9VUEpigXMCMDPeuB40EeZm uwGeuCFf0avcEwDVrRHP//MW+1AIULD10Sgnx0AEI/0fu4Di//ye6LNtaqaqPgV9IyIn of3V8qTNrA2wimgIKmunAv4ZdDdSLJoNZniVPEJa8AL7IdJT058SqWpm1aHASLOtS43z 0icLxxZsOyu9DPgAtNoNxk/XIOBYMICwqml3jl/8oB1X5hSxvt6YpFZOhEUCzhBDaXhs aH6Hy8HE9Z/uwMpxA1NDEFV+r2LbYtoQvDw06M507IuBPzE0S0nsGRCgD4mXuhq1qZp1 /bFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=48bcLC8P+I7Ak5paR+mvVLdodOKl5OZ0JwyG5sZzRqU=; b=Qqo8ghoVoAWm+q8fNGpwYoj6mrkTL/oTVAIJbH+AOO875d0SugPEqDYlam8SNV8HWV jArr5qhaCLCHph5ckgxwscE9usmkFQY0jc+sS5tXKz8SEKzepG8jxmi65VHEcBSvG7c7 K0encAAfkQ9jli1f9J1Ilk9JHgZtjPuBas6OQvj65zFEtoNSj0Ix/w3jA0bfkIkTio/y WsrwD8ecTP0vMr2uMkaLsTRoIF/vE3gnTTKPRUa8HpGPGHwwlsEBD7sROdpMwNNoOsqE 4nfNxOw5DOsDisDElK5qx05A/++PhtnSoldPJG6czwFjvK1OArFmve9/ys/XmJM8yf+V E9zA== X-Gm-Message-State: AIVw113q87qkCqK822jVf1n0i4RgBkDIDJPWbfw33hMvRCorx7czFDEN mpiOU9yqiICdU1G6 X-Received: by 10.84.212.150 with SMTP id e22mr22227546pli.398.1501617465051; Tue, 01 Aug 2017 12:57:45 -0700 (PDT) Received: from ?IPv6:2406:e007:521f:1:28cc:dc4c:9703:6781? ([2406:e007:521f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id q80sm45399566pfj.187.2017.08.01.12.57.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Aug 2017 12:57:44 -0700 (PDT) To: Sheng Jiang , "anima@ietf.org" Cc: "anima-chairs@ietf.org" References: <5D36713D8A4E7348A7E10DF7437A4B927CE3D7BA@NKGEML515-MBX.china.huawei.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <820cae24-23f3-2d26-1942-736694de08f5@gmail.com> Date: Wed, 2 Aug 2017 07:57:44 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B927CE3D7BA@NKGEML515-MBX.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Result of WGLC on draft-ietf-anima-stable-connectivity-03 - Respond by July 28, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 19:57:48 -0000 Just to be clear, the -04 version already published does *not* deal with the comments in my review of -03: https://mailarchive.ietf.org/arch/msg/anima/QCgeaEDFQlEgX_JsWzzjdWRNoHo Regards Brian On 01/08/2017 19:23, Sheng Jiang wrote: > Hi, all > > We received no negative response to the WGLC on draft-ietf-anima-stable-connectivity-03 during the two-week WGLC and we did receive good reviews through the WG document stage, through the shepherd review process and WGLC period. Considering the past history of this work, I, with my ANIMA chair cap on, feel it is has passed the WGLC and should advance. This conclusion is made with the condition that the authors would solve the comments received during the WGLC and these modifications were not substantial changes from 03 version. If there are big changes, a shorter second WGLC may be needed. > > Up to now, there is no IPR disclosure linked to this document. > > Once the update is published and it meets the above condition, for which the second WGLC is not needed, as the document shepherd, I will finalize the shepherd document and send the document on. > > Best regards, > > Sheng (co-chair, Toerless who as a co-author stayed neutral on the content side) > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Tue Aug 1 17:38:46 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5611D13167B for ; Tue, 1 Aug 2017 17:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vo96aH0uEn3J for ; Tue, 1 Aug 2017 17:38:43 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45DF7129B25 for ; Tue, 1 Aug 2017 17:38:43 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9DCE2E009 for ; Tue, 1 Aug 2017 20:40:31 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id F383480B17 for ; Tue, 1 Aug 2017 20:38:41 -0400 (EDT) From: Michael Richardson To: anima@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] proxy discovery of registrar X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 00:38:45 -0000 --=-=-= Content-Type: text/plain Brian, I opened issue https://github.com/anima-wg/anima-bootstrap/issues/23 to close the question about how the BRSKI proxy finds the Join Registrar. 1) Toerless needs to remove that text from ACP document. It does not belong. BTW, I was reviewing https://www.rfc-editor.org/cluster_info.php?cid=C325 and GRASP is going to wait for the ACP document. Ick. I thought it was just CDDL. The more speculative text that can be removed from the ACP document, the faster it will progress. 2) M_FLOOD vs M_DISCOVER. Your issue https://github.com/anima-wg/anima-bootstrap/issues/22 point 3, about how we did things wrong is well taken. I think that I prefer to use M_DISCOVER to find the Registrar, as the information about it is most likely cached in a nearby node. Toerless has instead written the M_FLOOD mechanism. We started a thread a few weeks ago about this... what happened to it, I would have to look. In either case, I would like to please discuss this in the context of the BRSKI document, not the ACP. Brian, we selected M_DISCOVER/M_NEG_SYN method because: a) we didn't think the location of the Registrar would change frequently, or perhaps ever. Of course the responses have TTLs, so it's not really a big deal. b) your experiences with mcast at IETF98 has made me concerned that we should not use flooding if we don't have to. OTOH, the proxy is going to discover the registrar over the ACP, and we won't have any L2 switches directly in the path to like we had at IETF98. The process is supposed to be: proxy: M_DISCOVER---> neighbor: M_DISCOVER---> registrar <--- M_RESPONSE-- neighbor (caches) <--- M_RESPONSE-- I think. I don't know anymore... Do we want: o a discovery objective option (Section 2.10.1). o a negotiation objective option (Section 2.10.1). o a synchronization objective option ?? I think that I concluded we needed the third option, which is why I think that I wound up into M_REQ_SYN. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmBHxEACgkQgItw+93Q 3WVlUgf/URvYjJgLw4c8mWJynxx+WwBqWftD3yWvg8N+YDISQgJvrnbA9BVuq9mq AtaPuAlOmmqspdr1qZhCarlwNeY5c0wG8qHFytIsjI4IiY/j+Drs9rtm4cZu7n5N 6JbeCDfshEbWSFPvBp5ok+aGUlqWKS63lrM6sXBK3r4xM5wWuuWwAMTtVOZIqmWn Uls1m1gpdZ14iL0+ehsfpftoB+lnl+L2TsIACrmuz7S5eBLcHfk+DTAT9AvRe85b mcL8f30X58TUlc7ul+oc3r1kqxkZWf18VRYvd3GeLGiLnzIxWTC6zmG6ah2Nmswk ccrKMc/1i11RFXut33cbq/w9WdyFwg== =lj98 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 1 18:04:11 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589F612F287 for ; Tue, 1 Aug 2017 18:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 rOHu5cFwIsh1 for ; Tue, 1 Aug 2017 18:04:07 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69FB512EB8C for ; Tue, 1 Aug 2017 18:04:07 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id l64so14450462pge.5 for ; Tue, 01 Aug 2017 18:04:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=hDZ95VqTkbxbLoPL9wb4ABxlr/WGEAVmr9d9l9iJufI=; b=H5RmYrdS4mTL7mb3yFmS16NjC+/ZygZR7Sh/h72Wz5cxif7vFM03anX6KO7VZoKB5D /8zJ4c+oRXtQL0BOrA3kYXGHfiymdvoYRR1rtBC8QRbPtvzWmT4lFBbyc0UCV4rwsJr2 6O84xzpTiWJS3gCdFH/0Ya2SYF/YdT1Dp2AGt3Nmq7TUOmzXtualVU33gpbMd+m+WfoO UXM2/x0wE6lFGHofHA9tZ8/VVt+lnfACEI4ijfOzGHgetATg2sHuhOw9i7xBSXhlQRfE pXTV+WYSnFnUmfVcLV3d9b3NQjA5s7A/gXiX9Qlpx/3rHSCv0hAlNds6d/04rm16pZy/ Xgww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=hDZ95VqTkbxbLoPL9wb4ABxlr/WGEAVmr9d9l9iJufI=; b=QU+a+gNFFFRB58ihuUoTcZSP2YrBAfSIk3YzK0zrA7mgxkIJmgloKZlmMvgIpZKW5u KCpePdfu3FC/pvug24qi/aqdL3WmLsvcFm/tQF07UEE+7uDsD2NUbm59kmySy047o5xM DIoGuwPQH9SM6QmU/FXQFr9DA3DK0K81Ze/K5iio5AUrgmYgFBw22HGWebeLSsajxZe9 M5fCe5t7Yl/lrXVjZ6wJkiR+WZ/Jc2IgeqwACIFRYvmGJCLpcF6BLFsS4WdC1m9Wwh0T M5yy7DfNVOzYcMfPAS2qCkvKnCKkwitotoxf6JjggRSM38LVWHPuuq2w2l7e5SVFTeB3 dqNg== X-Gm-Message-State: AIVw113MhNi8X1+4zJsryR46sag0n90pHWoduyoGD92JX5RchAX6u2ob gPMVguH18t7BeaCC X-Received: by 10.99.99.7 with SMTP id x7mr21104584pgb.81.1501635846646; Tue, 01 Aug 2017 18:04:06 -0700 (PDT) Received: from [130.216.38.9] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.9]) by smtp.gmail.com with ESMTPSA id a125sm49106971pgc.37.2017.08.01.18.04.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Aug 2017 18:04:06 -0700 (PDT) To: Michael Richardson , anima@ietf.org References: <9024.1501634321@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <59bab2b2-5cf7-2f5f-d36d-9a7d0956c8b6@gmail.com> Date: Wed, 2 Aug 2017 13:04:06 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <9024.1501634321@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] proxy discovery of registrar X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 01:04:09 -0000 On 02/08/2017 12:38, Michael Richardson wrote: > > Brian, I opened issue https://github.com/anima-wg/anima-bootstrap/issues/23 > to close the question about how the BRSKI proxy finds the Join Registrar. > > 1) Toerless needs to remove that text from ACP document. It does not belong. I agree. (I am in the middle of typing in my comments about ACP draft -08.) > BTW, I was reviewing https://www.rfc-editor.org/cluster_info.php?cid=C325 > and GRASP is going to wait for the ACP document. Ick. I thought it was > just CDDL. It was, but Eric Rescorla insisted on the ACP becoming normative, and I think he was correct. I don't think it matters much in practice; we need the ACP done anyway! > The more speculative text that can be removed from the ACP document, the > faster it will progress. > > 2) M_FLOOD vs M_DISCOVER. Your issue > https://github.com/anima-wg/anima-bootstrap/issues/22 point 3, about how > we did things wrong is well taken. > > I think that I prefer to use M_DISCOVER to find the Registrar, as the > information about it is most likely cached in a nearby node. > > Toerless has instead written the M_FLOOD mechanism. > We started a thread a few weeks ago about this... what happened to it, I > would have to look. In either case, I would like to please discuss this > in the context of the BRSKI document, not the ACP. Sure. My understanding was discover/synchronize which is what I put in draft-carpenter-anima-ani-objectives-03 (and in the latest demo code if anyone cares: https://github.com/becarpenter/graspy/blob/master/brski-demo.pdf ). But this needs to be a firm consensus in the BRSKI team. > Brian, we selected M_DISCOVER/M_NEG_SYN method because: > a) we didn't think the location of the Registrar would change frequently, > or perhaps ever. Of course the responses have TTLs, so it's not really > a big deal. > > b) your experiences with mcast at IETF98 has made me concerned that we > should not use flooding if we don't have to. > OTOH, the proxy is going to discover the registrar over the ACP, > and we won't have any L2 switches directly in the path to like we > had at IETF98. > > > The process is supposed to be: > proxy: M_DISCOVER---> > neighbor: M_DISCOVER---> > registrar > <--- M_RESPONSE-- > neighbor (caches) > <--- M_RESPONSE-- > > I think. I don't know anymore... > > Do we want: > o a discovery objective option (Section 2.10.1). That only gets you the address. > o a negotiation objective option (Section 2.10.1). That implies the proxy has something to discuss with the registrar. > o a synchronization objective option That implies that the registrar has something to announce to the proxy (such as "I support foobar and barfoo"). > > ?? > > I think that I concluded we needed the third option, which is why I think > that I wound up into M_REQ_SYN. I concur. Brian From nobody Tue Aug 1 19:39:13 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42928127B60; Tue, 1 Aug 2017 19:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yquVlTbL3oSY; Tue, 1 Aug 2017 19:39:08 -0700 (PDT) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (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 F15BC120724; Tue, 1 Aug 2017 19:39:04 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id l64so15274325pge.5; Tue, 01 Aug 2017 19:39:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:cc:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=OpTTtKELwWT6v6Ga6LK8VwNhfPuXRL+U5tBH/U/5t0s=; b=ZA9L2k91LQsUZEJPf9U3r31Vsaqbs11DN5C6TJFc2ja/Ke/AF0eF3x8Xjm8MB+uc2j HbVEFCyVc/d3GS8Hzdcr8/qbFKO7ccCOI8xBQqQ4ZiZUXt6/A/TF9LmHYnLx+i77jNxQ +E9XIOS2fviooEIu+9lgHe9Ff2DrkR1dqQm7lcNPJiLa3vo518Fs1dEKF+g59frb82oV pogn+PGZWpVWVDGSNPB6ttSjJ0bQQ5qMFZT0UJh8q172UTHQ85tSRvlTnfzJhFYTqkhq cPuD3wgluYxPhrWKhPCP7Gy8VqIQDT6HYFCX71zLUxeE/2GEZwvzkfOxbJcj9l2Ozpw3 /Q/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization:cc :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=OpTTtKELwWT6v6Ga6LK8VwNhfPuXRL+U5tBH/U/5t0s=; b=rJJFHIqQDiUlG9VObY1FWTxsxex3gzkM2uM/31TAoVVWBzX2hnpBk5wgsxanGoMSl/ S5JYvWUTDnBY9n/WK7swXgsixIQfM+r2OuKMNen/6sQnJKhLKjYAaPJpzDqa2nQRpdkp v6ojSFlvNKKRLYVSfGoDZqgqYMDf8m3Ds7g0WhRKUNqm3lECuufBNGXie2gB1y+h6U1r sQNU2fyIQM6J9djqAdMYEGdM7/XX34LR4wdEW4gI5jtKlkmeiAIx/QbCSm/nBpFBHsCH XhJsiHt0PiEIJXg0eQFkhn9t6pQDsE9YfcUkFBf6R696NzuPm/Pc89aEmBGTV1LiI2+B NA/w== X-Gm-Message-State: AIVw110KyAWhsLqjmKfHmNcxin3y23sYyEAeGHbDEuEir6RRFgAxVCm2 X8pf/ISgJ4N0xLnM X-Received: by 10.84.210.203 with SMTP id a69mr23091589pli.397.1501641543965; Tue, 01 Aug 2017 19:39:03 -0700 (PDT) Received: from [130.216.38.9] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.9]) by smtp.gmail.com with ESMTPSA id n19sm23178838pfi.35.2017.08.01.19.39.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Aug 2017 19:39:03 -0700 (PDT) To: draft-ietf-anima-autonomic-control-plane@ietf.org References: <150044138257.25233.12391471568614147773@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Cc: anima@ietf.org Message-ID: Date: Wed, 2 Aug 2017 14:39:03 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <150044138257.25233.12391471568614147773@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 02:39:10 -0000 Hi, Here are my comments on ACP version -08. First the ones I rank as substantive isssues, then a few nits. Issues: ------- > 2. Terminology ... > ULA "Unique Local Address". The IPv6 equivalent to RFC1918 IPv4 > addresses. ACP addresses are ULA. No, they are *not* equivalent to RFC1918, because those are ambiguous and ULAs are not. Please avoid controversy, just cite RFC4193. > 3.2. Secure Bootstrap over an Unconfigured Network ... > ...This does not require any configuration > on intermediate nodes, because they can communicate through the ACP. s/they can communicate/they can communicate securely/ > 4. Requirements ... > ACP4: The ACP MUST be generic. Usable by all the functions and > protocols of the AN infrastructure. It MUST NOT be tied to a > particular protocol. I'm not sure what the last sentence is saying. Do you mean "MUST NOT be tied to a particular transport protocol" or "MUST NOT be tied to a particular security protocol"? Or do you mean "MUST NOT restrict the choice of upper layer protocol"? Or do you simply mean "MUST provide a generic IPv6 service"? Also, there's no requirement about performance or the expected traffic density. Should we say something either in the Requirements section or in the Notes in the Overview section? I assume that performance is not critical and ACP traffic density is expected to be low. > 5. Overview ... > Default policy is: To all adjacent nodes in the > same domain. I know this is explained later, but I think both "adjacent" and "domain" need some qualification. For example: Default policy is: To all adjacent link-layer autonomic nodes in the same autonomic domain. ... > 5. Inside the ACP VRF, each node sets up a virtual (loopback) > interface with its ULA IPv6 address. I think we have cases where a node has multiple ULAs. > 6.1. Domain Certificate > > To establish an ACP securely, an ACP device MUST have a globally > unique domain certificate (LDevID),... You need a normative reference for the LDevID format. > 6.1.1. ACP information > > The domain certificate (LDevID) of an autonomic node MUST contain ACP > specific information, specifically the domain name, the address of > the device in the ACP with the Zone-ID set to zero ("ACP address"). You need a cross-reference for Zone-ID, which is undefined at this point. ... > anima.acp+{+{+}}@ What notation is that? Is {} supposed to be an optional item? If so, why not use [] as in ABNF, and cite ABNF. > is used to indicate... Is that required to respect DNS syntax? If so, please say so. > {.} That's wrong. is preceded by "@" in your syntax, and in your example, the dot is in the element "area51.research". Is there a length limit on the rfc822Name ? > 6.1.2. Maintenance As Michael R said, all the stuff about the registrar should be in BRSKI, not duplicated here. In fact, it's very confusing to have it here. If we want a cert renewal mechanism, surely that's part of BRSKI? [One detail however: > The loop-count MUST be sete to 255. When an ACP node > receives the M_FLOOD, it will have been reduced by the number of hops > from the EST server. I don't like that. The role of the loop count is loop prevention, so it should be set to a reasonable upper bound on the "radius" of the network. GRASP has two measures for loop detection, this one and detection of duplicate session IDs, but that was intentional redundancy.] > 6.2. AN Adjacency Table > > To know to which nodes to establish an ACP channel, every autonomic > node maintains an adjacency table. The adjacency table contains > information about adjacent autonomic nodes, at a minimum: node-ID, IP > address, domain, certificate. Please specify which IP address(es) you mean. Link-Local, ACP Address(es), or both? Can you also indicate that an API to this table is needed (at least by the GRASP core, and possibly by any ASA that wants to make direct use of the ACP)? > 6.3. Neighbor Discovery with DULL GRASP ... > [M_FLOOD, 12340815, h'fe80000000000000c0011001FEEF0000, 1, > ["AN_ACP", SYNCH-FLAG, 1, "IKEv2"], > [O_IPv6_LOCATOR, > h'fe80000000000000c0011001FEEF0000, UDP, 15000] > ] Once we are fully settled on this I can generate an example and its binary value for complete clarity. I have one comment which is that when I last updated draft-carpenter-anima-ani-objectives, I replaced "SYNCH-FLAG" with "5" (the actual value of the flag byte) - otherwise you have to define SYNCH-FLAG. Actually the value 5 indicates discovery+synchronization; everything should work just the same if it was 4 (synchronization alone), since it's flooded. I don't know if we care about that difference. ... > The ttl and loop-count are fixed at 1 since this is a link-local > operation. No, the ttl is milliseconds - the valid lifetime of the flood. You have that correct in your version of AN_join_registrar. > 6.8.2. ACP as the Security and Transport substrate for GRASP ... > GRASP inside the ACP uses link-local UDP IPv6 multicast across the > ACP virtual interfaces for GRASP neighbor discovery... and flooding Also, you might want to add a reminder that GRASP does its own relaying of multicast packets between interfaces; the ACP is not required to provide multicast routing. > ...and IPv6 over TLS > across the ACP virtual interfaces for any of its unicast messages. Wait, what are you saying here? Do you really mean IPv6 over TLS, or TLS over TCP over IPv6? As Eric Rescorla asked us at one point, please draw a ladder diagram of the protocol stack. ... > TLS is mandated for GRASP because the ACP secure channel mandatory > authentication and encryption protects only against attacks from the > outside but not against attacks from the inside - compromised ACP > members I think the threat model really needs a clearer explanation. I assume that Bob and Alice are good guys, and Eve is a malicious ACP member. So a packet from Alice to Bob is encrypted from Alice to Eve, decrypted by Eve, then encrypted from Eve to Bob. So Eve can do what she wants with the decrypted packet. Now, who does the TLS wrapping? Will that be done by the ACP, or by the GRASP core? If the latter, you still need to explain how the ACP conveys the cert information to GRASP. > 6.10.1. Fundamental Concepts of Autonomic Addressing ... > o Addresses in the ACP are permanent, and do not support temporary > addresses as defined in [RFC4941]. Add something like: o Addresses in the ACP are not considered sensitive on privacy grounds, so do not need to be pseudo-random as discussed in [RFC7721]. (You probably also need to discuss why the ACP is not subject to scanning attacks: because ULAs are not propagated across domain boundaries.) > 6.10.2. The ACP Addressing Base Scheme > > The Base ULA addressing scheme for autonomic nodes has the following > format: > > 8 40 2 78 > +--+-----------------+------+------------------------------------------+ > |FD| hash(subdomain) | Type | (sub-scheme) | > +--+-----------------+------+------------------------------------------+ > > Figure 2: ACP Addressing Base Scheme > > The first 48 bits follow the ULA scheme, as defined in [RFC4193], to > which a type field is added: > > o "FD" identifies a locally defined ULA address. For the Nth time, please s/FD/fd/ as required by RFC5952 > > o Type: This field allows different address sub-schemes in the > future. The goal is to start with a single sub-schemes, but to > allow for extensions later if and when required. This addresses > the "upgradability" requirement. Assignment of types for this > field should be maintained by IANA. You need to write precise directions to IANA. > 6.10.3. ACP Zone Addressing Sub-Scheme > > The sub-scheme defined here is defined by the Type value 0 (zero) in > the base scheme. > > 51 1 13 63 1 > +---------------------+---+---------+-----------------------------+---+ > | (base scheme) | Z | Zone-ID | Device-ID | V | > | | | | Registrar-ID | Device-Number| | > +---------------------+---+---------+--------------+--------------+---+ > 48 15 s/51/50/ Although I think it would be simpler to do this: 48 2 1 13 63 1 +----------------+----+---+---------+-----------------------------+---+ | ULA prefix |Type| Z | Zone-ID | Device-ID | V | | | 00 | | | Registrar-ID | Device-Number| | +----------------+----+---+---------+--------------+--------------+---+ 48 15 > > 6.10.4. ACP V8 Addressing Sub-Scheme > > The sub-scheme defined here is defined by the Type value 1 (one) in > the base scheme. > > 51 63 8 > +---------------------+-----------------------------+----------+ > | (base scheme) | Device-ID | V | > | | Registrar-ID | Device-Number| | > +---------------------+--------------+--------------+----------+ > 46 32 Same comments. > 6.10.5. Other ACP Addressing Sub-Schemes > > Other ACP addressing sub-schemes can be defined if and when required. > IANA would need to assign a new "type" for each new addressing sub- > scheme. With the current allocations, 5 more schemes are possible That's confusing. In your terminology, only two more types are possible (10 and 11). It would be simpler to simply define 3 type bits. A general remark: when a wider audience looks at this, there will be complaints that we are re-creating classful addressing. I suggest adding some text about this. (Along the lines of: it's true, and here is why it doesn't matter.) > Every ACP device (RPL node) announces an IPv7 prefix Forward into the future! > 6.12.4. ACP interfaces ... > These packets are of course redundant (unnecessary) and would be > discarded by GRASP on receipt as duplicates. ...by use of the GRASP Session ID. > 7.2. How (per L2 port DULL GRASP) ... > L3/L2 devices SHOULD support per-L2 port ACP. Clarify that ACP (and GRASP) capable devices do not need to depend on MLD snooping, since they catch LL multicasts directly per port. But non-ACP switches MUST either support MLDv2 snooping or operate as pure L2 bridges for all multicast packets. Also, is there anything to say here about VLANs? > 11. Security Considerations I think you need to insert cross-references to various security discussions elswhere in the draft. > 12. IANA Considerations TBD! Nits: ----- > 2. Terminology ... > ACP VRF The ACP is modelled in this document as a "Virtual Routing > and Forwarding" (VRF) component in a network device. I suggest listing this alphabetically as VRF, not under A. > AN "Autonomic Network". A network according to > [I-D.ietf-anima-reference-model]. Its main components are Intent, > Autonomic Functions and ANI. I find the second sentence doesn't help, especially by referring to Intent. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Regards Brian From nobody Tue Aug 1 23:37:00 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A112126CB6; Tue, 1 Aug 2017 23:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TA86fAc6jtmO; Tue, 1 Aug 2017 23:36:58 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FF7D124C27; Tue, 1 Aug 2017 23:36:58 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0BF282009E; Wed, 2 Aug 2017 02:38:48 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8A6F08076D; Wed, 2 Aug 2017 02:36:57 -0400 (EDT) From: Michael Richardson To: anima@ietf.org, roll@ietf.org cc: Pascal Thubert In-Reply-To: References: <150044138257.25233.12391471568614147773@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] ANIMA ACP -08 -- estimating depth of DODAG in storing mode X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 06:37:00 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Brian E Carpenter wrote: > [One detail however: >> The loop-count MUST be sete to 255. When an ACP node >> receives the M_FLOOD, it will have been reduced by the number of hops >> from the EST server. > I don't like that. The role of the loop count is loop prevention, > so it should be set to a reasonable upper bound on the "radius" > of the network. GRASP has two measures for loop detection, this > one and detection of duplicate session IDs, but that was > intentional redundancy.] If we were using RPL in non-storing mode, we'd get DAO messages from the leaves directly to the root indicating their parent. The DODAG root would therefore know exactly what the deepest leaf was. That would be the radius From=20the root to the furthest node, but of course discovery might happen = from edge to edge, so the longest path would therefore be 2x that size (up the tree to the top and down again). As we are using RPL in storing mode, the DAOs are summarized at each level, we won't know that information. That's kind too bad I think, because each node knows how deep it is, they just don't report it to the root in anyway. It would be easy to add a CHILD_MAX_RANK DAO option to the DAO packet. It wouldn't make it to the top unless all nodes supported it, but it still might be worth writing it down. Unless someone else can figure out a way with existing information for a DODAG root to know how deep the network is? =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmBcwkACgkQgItw+93Q 3WVG1Qf+MNryOI1Db7kUJb63SzGVp8k55wvK2bVdc17//CRXwbgMuZ8attv5Vb82 UGRuOgezk84I5YU2fWtYdXZc6agpiSuVqp/TtRDCaWlYv8ymtWhGclb2ZnUXw7pl rOR39LKedociP78M2f5qdFQxYo9CJwyvut975d6uEdCtA/W42eFCUQ3OUNtReKUw 4ztSeO8QEWUWpwhaDqTTP0RY1eYGbQiFkzfEmGH69c9OC0Dbtp/3wsiNCX5Y5t2Z wn28TEpKKUM+Ykt/LHcVm6mFDdY3aSkIdQwsfZdZvYCE8xXe7wHidbZ65FWAyDMN q8uBX0igTmPVRv2iREqmpirlGLRIhg== =8Xsu -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 1 23:57:47 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26CC9131C4F for ; Tue, 1 Aug 2017 23:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4SrKZPT-KNh for ; Tue, 1 Aug 2017 23:57:44 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF8A3124C27 for ; Tue, 1 Aug 2017 23:57:44 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 98CBD2009E for ; Wed, 2 Aug 2017 02:59:34 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 16E408076D for ; Wed, 2 Aug 2017 02:57:44 -0400 (EDT) From: Michael Richardson To: anima@ietf.org In-Reply-To: References: <150044138257.25233.12391471568614147773@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] VLANs and draft-ietf-anima-autonomic-control-plane-08.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 06:57:46 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > Although I think it would be simpler to do this: > 48 2 1 13 63 1 > +----------------+----+---+---------+-----------------------------+---+ > | ULA prefix |Type| Z | Zone-ID | Device-ID | V | > | | 00 | | | Registrar-ID | Device-Number| | > +----------------+----+---+---------+--------------+--------------+---+ > 48 15 I like this much better. > A general remark: when a wider audience looks at this, there will > be complaints that we are re-creating classful addressing. I suggest > adding some text about this. (Along the lines of: it's true, and > here is why it doesn't matter.) Agreed. But they are assignment classes, not routing classes. > Clarify that ACP (and GRASP) capable devices do > not need to depend on MLD snooping, since they > catch LL multicasts directly per port. But non-ACP > switches MUST either support MLDv2 snooping or > operate as pure L2 bridges for all multicast > packets. > Also, is there anything to say here about VLANs? There are some chicken and egg problems here. On the one hand (other hand in next email), there may be a variety of L2 technologies ("LAN EXTENSION") which may be provided by other providers which the ACP should "bridge" across as if it was just a wire. A configuration which is not-uncommon (but seemed to surprise more than multiple sales engineers from more than three major companies) is for an (incumbent) telco to offer a service that connects one location (the datacenter, DC) to many locations. The central location has a VLAN tag that leads to each other locations, and at that other location (customer premises, CP), the VLAN tag does not appear. Now, hook things up and do not tell the devices at either end about this scenario ("remote hands" have just unpacked the drop-shipped equipment). This is a *PRIME* use for autonomic networking. (I actually tried to do this all with DHCP/TFTP for unconfigured devices, btw, with some success, but then the manufacturer of the high-quality $300 CPE device screwed up their platform OS making it a low-quality $300 device) On the CP side it's all good, because the freshly unpacked equipment would see the GRASP M_FLOODs (whether proxy announcements for an unimprinted device, or AN_ACP announcements for an imprinted device) without a VLAN tag. But, the DC device has a problem. All it knows about is a fiber of 1GbE or 10GbE Ethernet here. Any untagged packets it sent will be dropped. If the CP device would send some kind of traffic, then the DC device would see it, with the VLAN tag, and could autonomically configure a VLAN interface for it, and begin to talk to it. That would be great. If the CP device is imprinted, the AN_ACPs would just go out, and it would be all well. But, in the bootstrapping case, we've said that the pledge should remain quiet... so maybe we want to revise that? On the other hand, the pledge actually won't be completely quiet. It will send out DADs for any LL addresses it might have configured. (Today, we wrote that Pledges should configure fresh RFC4941 temporary addresses for use in enrollment. And that they should try new addresses whenever all of their prospects fail, in case some of the problems are related in some way to their choices of address) So, perhaps we should write is that, on an unconfigured interface, if one sees VLAN encapsulated traffic on an interface on which, and one *would* send out the AN_ACP/AN_Proxy messages, that one should start sending some M_FLOODs for awhile on that VLAN interface. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmBd+cACgkQgItw+93Q 3WVRtggAody32y9SrRTr7f5H072+DWuGAg9KiMtsxk59i3uUSp3iqSHfqQOC4NRs jB0UTKJhZKsgUzfpI0mCMSNmjmrJ9jTpb0XnvY8ccJnJK8UHNYF9ci2lwdGsL+0/ 7br/K8R0mn8iuEl2U1iedvkYkuFue0Zqcq9saQs/mixOUjh6RxF41UfjDVi/GngD +4UGD6TOFGWx4oKdbGilZVH0tGYu8Kw8jGgP3qb7WbLT0Lm6YWyd4t5/JQFsd5VJ CriknDTJxGcPAh8jFx2rNoWi/vcj53dvAPCabKOgptcwVSpH+rBOuB4xHJKq63iL zqWyFNEORoCkiDM6mjQ3O/6yan0FLQ== =O3yv -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 2 00:18:35 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC19131D24 for ; Wed, 2 Aug 2017 00:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJINgI1zYGnA for ; Wed, 2 Aug 2017 00:18:32 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 679F9131D19 for ; Wed, 2 Aug 2017 00:18:32 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 035F92009E for ; Wed, 2 Aug 2017 03:20:22 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 660028076D for ; Wed, 2 Aug 2017 03:18:31 -0400 (EDT) From: Michael Richardson to: anima@ietf.org In-Reply-To: <31582.1501657064@obiwan.sandelman.ca> References: <150044138257.25233.12391471568614147773@ietfa.amsl.com> <31582.1501657064@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] VLANs and draft-ietf-anima-autonomic-control-plane-08.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 07:18:34 -0000 --=-=-= Content-Type: text/plain Michael Richardson wrote: > There are some chicken and egg problems here. > On the one hand (other hand in next email), there may be a variety of L2 > technologies ("LAN EXTENSION") which may be provided by other providers which > the ACP should "bridge" across as if it was just a wire. A > configuration Now, let's look at the question from the point of view of the the LAN EXTENSION provider. Of course they are also using autonomic switches, and they'd like to be able to plug stuff together randomly and have their ACPs formed so that they can maintain service. The LAN EXTENSION provider also may have a drop-ship device to the customer premises (which, using the previous example, is both the "DC" and the "CP" ends, because both ends are their customer, being the L3-ISP that bought the L2 transport). The LAN EXTENSION customer doesn't always know if the fiber will plug directly into the customer's equipment, or if some kind of media converter from copper to fiber will be used. The straight media converters are remarkably unreliable because they attempt by fail to pass MII across and fail, and you have to lock ports to HD, etc. Meanwhile multiport switches with SFP ports are common, and sometimes one winds up serving multiple customers from the same demark... So that means that the tagged side of the circuit, which is at the DC, probably has AN_ACP messages coming out *untagged* from the L2-provider. The L3-ISP's device is going to see them, but of course the ACP connection ought to fail. (baring some kind of out of band arrangement, which is out of scope here) At the previously mentioned "CP" side of things, despite the media converters *trying* to be stupid optical to electrical converts, it turns out that they often have a management VLAN on the optical side, and if an AN_ACP packet were to arrive with that preconfigured VLAN ID, it would be accepted. The customer's traffic actually might also arrive in another VLAN tag, and that media-converter device would be charged with removing the tag. Or, everyone might agree that the extra device is stupid, and plug things directly into the real CPE. Once the LAN EXTENSION provider has their ACP up to the demark devices, the sensible thing for them to do is to disable ACP messages on their "access" ports. Sensible, but maybe not reliable... I think that a device that loses all ACP connectivity *SHOULD* disable that disabling, and starting sending some AN_ACP messages on all ports.... I should say that I assumed a flat ethernet on the fiber side of things, but it could also be a wide variety of metro-ethernet-ring technologies... PBB, TRILL, and six or so other 802.FOO things. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmBfMcACgkQgItw+93Q 3WXYnAf/etKQB7YtMT9GlHQks+946epsW5FU5GCn/IAfnAe35iaYH7ja6vxrw454 UEMOGBOyCtj87eYKYz/jv1tyKXS+hF8gxFfpYDyzHKyK8P2kSyNAQRSjljo0BVyu PEtM2n1gbiGUHxtzD8gDQbDwlBwSWE4eZ0DynoSoAmO8+u1M0iUhHZN1MDY9A2WN MvmWv/msKl9/5ENh0L/Ys35i0RmMFhMRPMCaYltx1iD3l+VeRFXKlnD3PVWYvVh3 bmacob4c8iLTRouuABWXxoV/KoaDAVKwpd4I4iLFYDzJ3gL5BWRoCkmeHppNdt4D FBEppjqApznggRI9hNJ/Wtuzt2eqRg== =ffgX -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 2 02:43:13 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA75312EC13; Wed, 2 Aug 2017 02:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53Nxox_1K-fa; Wed, 2 Aug 2017 02:42:57 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25863127978; Wed, 2 Aug 2017 02:42:57 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id CA75EE00C; Wed, 2 Aug 2017 05:44:46 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D981E8076D; Wed, 2 Aug 2017 05:42:55 -0400 (EDT) From: Michael Richardson To: consultancy@vanderstok.org cc: Sheng Jiang , anima-chairs@ietf.org, 6tisch@ietf.org, netconf@ietf.org, anima@ietf.org In-Reply-To: <76229c58f5d60d3a0c185c6645ba4355@xs4all.nl> References: <5D36713D8A4E7348A7E10DF7437A4B927CE3D826@NKGEML515-MBX.china.huawei.com> <76229c58f5d60d3a0c185c6645ba4355@xs4all.nl> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] [6tisch] Cross-WGs WGLC (second) on draft-ietf-anima-voucher-04 - Respond by Aug 08, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 09:42:59 -0000 --=-=-= Content-Type: text/plain peter van der Stok wrote: > section 6, leaf prior-signed-voucher, at the end: > The MASA SHOULD remove all "prior-signed-voucher". > I would encourage a "MUST" instead of a "SHOULD" when thinking of > transporting vouchers over constrained networks. I believe that users of vouchers over constrained networks will want to "sub-class" the voucher. (I'm sure that's the wrong YANG term) There will be an example of how to do this in BRSKI, so we don't need to do that. > Hope this helps It does. Also proves you read every word. We also accept patches via github :-) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmBnp8ACgkQgItw+93Q 3WUZiQf+L/t8Sfd0Fi0Rhpf6E4ilPZiDZ86LnF59tAYtf6KA8w0dn5hfpUw4wgWw EdeBh/lqNYo3qMDls68ZOHgOapocCMZavGprz3x5WLUs3zcIBQpMeLroM5OSF79m UNmvb/ofTVbUAVa+nsN5C38a8hNfMJOM75Qfy4LEwcDBl8IuDn9wde76/w9Yw+gH l4PMKatjUdvMAKHE75sE5OpFBxeCNbd2uvo/UC5dNp0Rpb2X/lwiWYAksF/UJl+p QLMZ0vEjHZQVbUDS+ONR7qdF0WGGrqMNlL5X2FrHGJrkQhIwEyibutzrBJRPiRZ7 ZmAKoPQi/rlZ8s87UbOrog9kyducDg== =SYJC -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 2 12:46:35 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE723132034 for ; Wed, 2 Aug 2017 12:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJ_BvClZ4uQT for ; Wed, 2 Aug 2017 12:46:31 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A7F6127869 for ; Wed, 2 Aug 2017 12:46:31 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 93E5CE032; Wed, 2 Aug 2017 15:48:22 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 47AFB80631; Wed, 2 Aug 2017 15:46:30 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: anima@ietf.org In-Reply-To: <59bab2b2-5cf7-2f5f-d36d-9a7d0956c8b6@gmail.com> References: <9024.1501634321@obiwan.sandelman.ca> <59bab2b2-5cf7-2f5f-d36d-9a7d0956c8b6@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] proxy discovery of registrar X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 19:46:34 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> Toerless has instead written the M_FLOOD mechanism. >> We started a thread a few weeks ago about this... what happened to it, I >> would have to look. In either case, I would like to please discuss this >> in the context of the BRSKI document, not the ACP. > Sure. My understanding was discover/synchronize which is what > I put in draft-carpenter-anima-ani-objectives-03 (and in > the latest demo code if anyone cares: > https://github.com/becarpenter/graspy/blob/master/brski-demo.pdf ). > But this needs to be a firm consensus in the BRSKI team. I did take a look at the code yesterday in the end, and I'll like run it sometime soon, but I decided I didn't want to reverse engineer the spec from the code :-) >> o a synchronization objective option > That implies that the registrar has something to announce to > the proxy (such as "I support foobar and barfoo"). Do we have some preference for "AN_join_register" (and AN_Proxy and AN_ACP), or is the AN_ prefix unwanted? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmCLBUACgkQgItw+93Q 3WVU6Qf/ePxzKKQVz8E1mh3Om5/Om3i3smAr1d2WMp7kyL6TBl9pO8pGT37t7Ty/ uF0sA4INjyz4Zdt30fHIUBJ0a2GU8G51nQgi8E5626twEqjlCUtHG0cEVZL1GgZi NEsNvQvfTMs40xOzf+czGqiiirOIHsMqiIxyZoEt7aypkZrOAyfkcWa8xz2dGzTd s8jwSpoXehtviixaQn9aVPh2T06JYng62mURcU2vN/1rsx5Rgd6IvctMEVOhifVB cw0/Hhn8GxwfO5a7wbjXov+lrokbHs+DZrIoJvFGx+1++sOppIQepAjftMvL5oc0 5f/inEe/oRj3yZvJgk7/hqlLU/A3Ug== =8Fn3 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 2 13:25:08 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1808F13216D for ; Wed, 2 Aug 2017 13:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 paKSc1c8tEmv for ; Wed, 2 Aug 2017 13:25:04 -0700 (PDT) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (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 8CA64131C84 for ; Wed, 2 Aug 2017 13:25:04 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id v77so19736876pgb.3 for ; Wed, 02 Aug 2017 13:25:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=XKU0lMWMsSpL/6bBdUIWfqqO9CiME/psxYWPrVhScCA=; b=lmKsLaWKP/O8SfncFBAwKgGOfOK7p6JLbWgzzMsFW7hoIrDze//oKeQGxWFttU7SjH CwqAbxElLQTS1z4C9c8CC/9YJNlqmX71qzwFffVRmW9bc+b+ukYly4HHGJiOsTRnek0E 3yH+2OP0xa6rYKrAVR8dfH3DUO1rAug3iaC5YYBTTU3vI8DKjAOmSqPR/3ySzQOdFprW DlBo2rtkgqTFQoh7QH1Sib4xbtAqMhfHrT4yNjiy2pMkRvATJDML9r6Yq500LHK7mEzP VX5HtZ63XcAyAU24CRLswOua+bQk1yRSaPIwwYJzn7nj98dHXrxuAIskPlwZjaHAWgQP 9E2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=XKU0lMWMsSpL/6bBdUIWfqqO9CiME/psxYWPrVhScCA=; b=sQf1NZaQGyu22TV+UuYXnOSAxSMLhI86PbASaijz2JT86uCekIiYdMTKDvZEbDV6e4 oJj601Pb1GDaIrSKlhY1o21inBxn1NOn4Ilzt/IIBwLCQ/YOjvoEuXFhjWPHgUD+SlSA F6suJtOh5R+Z/wKmQGVufn12c0eJRfRoHmOSO50hsoNe/ROxNf7DmGzBYwYg5Ma03xjx k+v4WX6FKQw+wdPJ1SNfiR0bRMlyhujEikkmONEJ/LfKu/PIo0IWubGfmx6fdOX5jcft lhImdekUF6EbUF3Z92y3BiR1J6PW3D6KVOFtBOO8Yljs69ez44EKVBSwKEUl9Z61zI+g iq/g== X-Gm-Message-State: AIVw110mvHfGZR3zldUdHI62dA8Bn7kHzHWkg8pOFd8Y8MqeQ6RWHoKI Z4orU1M+cfqAwC71 X-Received: by 10.84.194.129 with SMTP id h1mr26125174pld.237.1501705503475; Wed, 02 Aug 2017 13:25:03 -0700 (PDT) Received: from ?IPv6:2406:e007:521f:1:28cc:dc4c:9703:6781? ([2406:e007:521f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id s11sm42830516pfi.24.2017.08.02.13.25.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Aug 2017 13:25:02 -0700 (PDT) To: Michael Richardson Cc: anima@ietf.org References: <9024.1501634321@obiwan.sandelman.ca> <59bab2b2-5cf7-2f5f-d36d-9a7d0956c8b6@gmail.com> <13869.1501703190@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <4930cc46-6a5f-cd13-7883-ea7e798bf940@gmail.com> Date: Thu, 3 Aug 2017 08:25:04 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <13869.1501703190@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] proxy discovery of registrar X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 20:25:06 -0000 On 03/08/2017 07:46, Michael Richardson wrote: > > Brian E Carpenter wrote: > >> Toerless has instead written the M_FLOOD mechanism. > >> We started a thread a few weeks ago about this... what happened to it, I > >> would have to look. In either case, I would like to please discuss this > >> in the context of the BRSKI document, not the ACP. > > > Sure. My understanding was discover/synchronize which is what > > I put in draft-carpenter-anima-ani-objectives-03 (and in > > the latest demo code if anyone cares: > > https://github.com/becarpenter/graspy/blob/master/brski-demo.pdf ). > > > But this needs to be a firm consensus in the BRSKI team. > > I did take a look at the code yesterday in the end, and I'll like run it > sometime soon, but I decided I didn't want to reverse engineer the spec from > the code :-) > > >> o a synchronization objective option > > > That implies that the registrar has something to announce to > > the proxy (such as "I support foobar and barfoo"). > > Do we have some preference for "AN_join_register" (and AN_Proxy and AN_ACP), > or is the AN_ prefix unwanted? It's only a name, so we can do what we want. I put the prefix just to mark the fact that they are ANI components but I have no strong feelings about it. Brian From nobody Wed Aug 2 17:55:16 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE49129B25; Wed, 2 Aug 2017 17:55:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150172171433.5795.10066069657609599242@ietfa.amsl.com> Date: Wed, 02 Aug 2017 17:55:14 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-09.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 00:55:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : An Autonomic Control Plane (ACP) Authors : Michael H. Behringer Toerless Eckert Steinthor Bjarnason Filename : draft-ietf-anima-autonomic-control-plane-09.txt Pages : 76 Date : 2017-08-02 Abstract: Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Control Plane should ideally be self-managing, and as independent as possible of configuration. This document defines an "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out of band channel" for OAM communications over a network that is not configured, or mis-configured. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-09 https://datatracker.ietf.org/doc/html/draft-ietf-anima-autonomic-control-plane-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-09 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 Wed Aug 2 17:58:07 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D3FDD12EB9B; Wed, 2 Aug 2017 17:58:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150172188084.5703.6367146083234554972@ietfa.amsl.com> Date: Wed, 02 Aug 2017 17:58:00 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-stable-connectivity-05.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 00:58:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : Using Autonomic Control Plane for Stable Connectivity of Network OAM Authors : Toerless Eckert Michael H. Behringer Filename : draft-ietf-anima-stable-connectivity-05.txt Pages : 21 Date : 2017-08-02 Abstract: OAM (Operations, Administration and Maintenance - as per BCP161, [RFC6291]) processes for data networks are often subject to the problem of circular dependencies when relying on connectivity provided by the network to be managed for the OAM purposes. Provisioning while bringing up devices and networks tends to be more difficult to automate than service provisioning later on, changes in core network functions impacting reachability cannot be automated because of ongoing connectivity requirements for the OAM equipment itself, and widely used OAM protocols are not secure enough to be carried across the network without security concerns. This document describes how to integrate OAM processes with the autonomic control plane (ACP) in Autonomic Networks (AN) in order to provide stable and secure connectivity for those OAM processes. This connectivity is not subject to aforementioned circular dependencies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-stable-connectivity/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-stable-connectivity-05 https://datatracker.ietf.org/doc/html/draft-ietf-anima-stable-connectivity-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-stable-connectivity-05 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 Wed Aug 2 18:08:21 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A0B128BC8 for ; Wed, 2 Aug 2017 18:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqkbNWZj2JED for ; Wed, 2 Aug 2017 18:08:15 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE3CD131B79 for ; Wed, 2 Aug 2017 18:08:14 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 1B7BF58C4BC; Thu, 3 Aug 2017 03:08:10 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id EBEABB0C792; Thu, 3 Aug 2017 03:08:09 +0200 (CEST) Date: Thu, 3 Aug 2017 03:08:09 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: Anima WG Message-ID: <20170803010809.GA12136@faui40p.informatik.uni-erlangen.de> References: <5D36713D8A4E7348A7E10DF7437A4B927CDFE66F@NKGEML515-MBX.china.huawei.com> <136a3ebd-dedb-9e2b-86be-a7d5fd12ad9b@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <136a3ebd-dedb-9e2b-86be-a7d5fd12ad9b@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] WGLC on draft-ietf-anima-stable-connectivity-03 - Respond by July 28, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 01:08:19 -0000 Thanks a lot for the thorogh review Brian. I hope your was the last mayor content change rev i have to do for the stable connectivity. Turned out that when i went through your comments, the mayority of changes i had to do was in the ACP draft because that was underspecified (ACP connect) and in result there was a bunch of loose suggestive stuff in stable-connectivity. In the end i could delete hpefully all underspecified stuff from stable-connectivity and this is now in ACP draft -09 well specified. Mohamed changes where into -04, but there was no conflict with what you wrote, so yours is now -05, changes: http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-04.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-05.txt Everything else inline below (responding to your points). Btw: If there are any additional points, i highly recommend to open issues in github: https://github.com/anima-wg/autonomic-control-plane/issues That github is for both the ACP doc and stable connectivity. Maybe not the best choice to combine them, but it is what it is. Cheers Toerless > Hi, > > Here are my comments on this draft. In general it seems to be ready, > but there are some issues that IMHO need fixing. Here they are, > followed by a few nits that I noticed. > > Technical issues: > ----------------- > > > 2.1.3. Simultaneous ACP and data plane connectivity > ...> If the data-plane of the network is also supporting IPv6, then the > > NOC devices that need access to the ACP should have a dual-homing > > IPv6 setup. One option is to make the NOC devices multi-homed with > > one logical or physical IPv6 interface connecting to the data-plane, > > and another into the ACP. > > I don't understand the need to call this "dual-homing". That generally > implies a physical topology with multiple links and/or routers. I think > all you mean is that the nodes happen to have at least two addresses > in different IPv6 prefixes (one for the data plane and one for the > ACP). Having multiple addresses is a standard feature of IPv6. It might > be done with multiple (virtual or real) interfaces, but it doesn't need > to be. So I suggest: > > If the data-plane of the network also supports IPv6, then the > NOC devices that need access to the ACP should have both data-plane > and ACP IPv6 addresses. One option is to set up the NOC devices with > one logical or physical IPv6 interface connecting to the data-plane, > and another into the ACP. The ACP is meant to be an isolated network, so the fundamental idea is that whenever possible, all adddresses routed across the ACP are non-overlapping with Data Plane addresses so that its clear what traffic is for ACP and what not. The first thing which for security reasons should be out of scope is a non-ACP router that connects Data-Plane and ACP and could therefore arbitrarily leak ACP traffic: ACP Connect Interface ACP --------- Wrong Edge Router ---- NMS host Router --------- Data plane interface There is of course only limited abilities to prohibit this, but it is explicitly not desired. When i started to answer to your questions below, there was really no way to fix up the stable connectivity draft because it could only hint or suggest things that where not written correctly in the ACP draft. And thats wrong. So i went back and effectively had to fix up a lot of things in the ACP draft. So see ACP-09 changelong in ACP-09 first, then go back to the following inline answers: > > The LAN that provides access to the ACP > > should then be given an IPv6 prefix that shares a common prefix with > > the IPv6 ULA... > > 1) It is surely a virtual interface, not a LAN. Well, it can be physical or virtual. Replaced LAN with subnet. Thats the correct term. The ACP-09 text is now also more specific to physical vs. virtual so those are two clear separate options re. their securitty impact. > 2) I think it is better to say > "should then be given an IPv6 prefix that lies within the ULA prefix..." Done. I now also use the therm "covered by" in the acp doc. I hope that term is also correct. > (In fact, it doesn't matter that it's a ULA - what matters is that > it's the prefix that covers the whole ACP. That really goes for the whole > document; a ULA prefix is just another prefix, after all. It might be > clearer to just say "ACP prefix" everywhere.) Right. In the main text. the whole security section is specific to ULA address benefits (isolation), so i didn't change it on behalf of this point. > > ... so that the standard IPv6 > > interface selection rules on the NOC host > > Cite [RFC6724] for complete clarity. Ack. > > If this can not be achieved > > automatically, then it needs to be done via simple IPv6 static routes > > in the NOC host. > > But it can. That's why RFC6724 exists. Do we really need to say this? As outlined above, the explanation for this all is now in the ACP connect section of ACP-09. Primarily because it didn't make sense to describe a lot of wonderful functional aspects of the ACP edge device in an informational document when they are missing in the normative standards track document. But there is a single sentence summarizing the issue in the stable connectivity doc now as well: | This setup may not work | with autoconfiguration and all NOC host network stacks due to limitations in | those network stacks. They need to be able to perform RFC6724 source address selection | rule 5.5 including caching of next-hop information. See the ACP document text for more details. > > Providing two virtual (eg: dot1q subnet) connections into NOC hosts > > may be seen as undesired complexity. > > Either you have to explain 'dot1q' and give a reference, or delete it. > I'd delete it. I always annoyed by unspecific terms like virtual, but it clicks for me when i read practical descriptions like 802.1q. So there is a reference to it now. > > In that case the routing policy > > to provide access to both ACP and data-plane via IPv6 needs to happen > > in the NOC network itself: The NMS host gets a single attachment > > interface but still with the same two IPv6 addresses as in before - > > one for use towards the ACP, one towards the data-plane. The first- > > hop router connecting to the NMS host would then have separate > > interfaces: one towards the data-plane, one towards the ACP. Routing > > of traffic from NMS hosts would then have to be based on the source > > IPv6 address of the host: Traffic from the address designated for ACP > > use would get routed towards the ACP, traffic from the designated > > data-plane address towards the data-plane. > > That seems like an explanation of very basic routing - does it need to > be said? This is all gone from stable connectivity now and hopefully better structured text in the ACP connect section in acp-09. > > In the most simple case, we get the following topology:... > > This part isn't very clear to follow. The ASCII art of Fig. 1 > and Fig. 2 is a bit scrappy, and the explanation is a bit short. > It would be better to start with an explanation of the terms > like 'NOClan' and 'Rtr1'. And you suddenly start discssing VRFs > without any definition. Likewise gone, replaced by better picture in acp-09. > > 2.1.4. IPv4 only NMS hosts > ... > > The downside of this architectural decision is the potential need for > > short-term workarounds when the operational practices in a network > > that can not meet these target expectations. This section motivates > > when and why these workarounds may be necessary and describes them. > > All the workarounds described in this section are HIGHLY UNDESIRABLE. > > The only long term solution is to enable IPv6 on NMS hosts. > > I full agree with the message but I think the wording has the wrong tone. > The goal should be to welcome NOCs to the new world of IPv6, not to > tell them they are dinosaurs. Something like: > > The implication of this architectural decision is the potential need for > short-term workarounds when the operational practices in a network > do not yet meet these target expectations. This section explains > when and why these workarounds may be operationally necessary and > describes them. However, the long term goal is to upgrade all > NMS hosts to native IPv6, so the workarounds described in this > section should not be considered permanent. Love text suggestions. Copied. > > To bridge an IPv4 only management plane with the ACP, IPv4 to IPv6 > > NAT can be used. This NAT setup could for example be done in Rt1r1 > > in above picture to also support IPv4 only NMS hots connected to > > NOClan. > > I think this (and the following paragraph) is underspecified. It isn't > clear to me whether this would be described as a NAT64 or a NAT46 scenario > (which side is the client and which side is the server, in other words). > There's a lot more to specify to make this work - maybe the details are > out of scope, which should be stated if so. Also, it would be better > to say 'IP/ICMP translation' not 'NAT' and cite RFC7915. Make that > clearly separate from the issue of how addresses are mapped. > > (Incidentally, recall that (a) IPv4 addresses are only 32 bits and > (b) we own the ACP address plan. So algorithmic mapping of IPv4 > addresses into a special /96 in the ACP address plan is possible. > Of course that would be an insecure zone in ACP terms.) *sigh*. Yes. As i tried to explain to Mohamed, i was specifically not trying to get sucked into individual NAT method description. But i gave up now with your feedback as well and improved the NAT text to refer to SIIT and explain the requirements better, eg: v6 initiator -> v4 responder requirement and v4 initiator -> v4 responder requirement. And then suggesting to use EAM as the most flexible mapping option. Hope this improves the IPv4 section a lot. > > 2.1.5. Path selection policies > > A lot of this section comes across almost as hand-waving. I did > wonder whether it would have been enough just to state the > problem. Well, the primary problem is that first round implementations of ACP may not be high performance, so the use of ACP should be prioritized for critical actions and otherwise Data Plane be used. I though the text says that. Then the text goes into mechanisms how NOC equipment would select how to decide whether to use ACP and/or data plane for some action and it suggests that without changning NOC equipment software, it might be possible to achieve this by using different names for the devices, eg: names that map to ACP or to data plane or first to data-plane then to ACP addresses. And then use the right name in a particular piece of NOC equipment or action on a NOC equipment to get the desired use of ACP and/or data plane. If the above explanation makes sense to you but you do not see this best reflected, maybe you can suggest better text to explain this. > ... > > MP-TCP (Multipath TCP -see [RFC6824]) is a very attractive candidate > > to automate the use of both data-plane and ACP... > > I'm not sure... you seem to be asking for new intelligence in > MPTCP's choice of candidate addresses, not just a policy but > a whole mechanism in support of that policy. And will you really > benefit from MPTCP's main point, which is automatic load management > between alternative paths. Wouldn't SCTP be a better match? This was just one example for an alternative mechanism to the use of different names, eg: embody the path selection policy into the transport protocol. Of course the way how exactly to do this is hand waiving, and MP-TCP was just the one most well known protocol that also most likely can be stuffed under existing TCP applications without them knowing. I would of course like that this is not seen as handwaiving but as interesting areas of further work/research. > > 2.1.8. Long term direction of the solution > ...> 1. NMS hosts should at least support IPv6. IPv4/IPv6 NAT in the > > network to enable use of ACP is long term undesirable. Having > > IPv4 only applications automatically leverage IPv6 connectivity > > via host-stack options is likely non-feasible (NOTE: this has > > still to be vetted more). > > That NOTE needs to be cleared up. Something like 464XLAT (RFC6877) > might be a good compromise. See the rewritten SIIT section. IMHO, there can be no simpler "network" based address translation. Where network based means that the translation happens in some device he network operator needs to provision. Like the ACP edge device. Or even an additional address translation device. So, the only IMHO easier option is when the OS of the NMS host would internally have IPv4/IPv6 translation so the device/VM looks to the outside like full IPv6. Alas, i didn't have the time to investigate these options. And most likely if at all you could only make those work for linux. So, for now i just remove the note and clarified the last sentence a bit. If there is anything specific to be said bout why 464XLAT might be better longer term, let me know and i can add it. For now it looks like yet another network device configured option to me, but i have not tried to understand it all the way. > > 3. Security Considerations > ... > > ULA addressing as proposed in this document is preferred over... > > Was this pasted from the ACP draft? Surely that is where ULA is proposed. Probably long time ago. This paragraph was already improved in -04 by Mohameds feeedback. > > Randomn ULA addressing provides more than sufficient protection > > against address collision even though there is no central assignment > > authority. > > I don't like that phrase: it isn't the *address* that's random, > it's the /48 prefix. Also, somebody is always ready to complain > about the collision risk. Suggest: > > The random nature of a ULA prefix provides strong protection > against address collision even though there is no central assignment > authority. Thanks, fixed. > > If packets with unexpected ULA addresses are seen and one expects > > them to be from another networks ACP from which they leaked, then > > some form of ULA prefix registrastion (not allocation) can be > > beneficial. Some voluntary registries exist, for example > > https://www.sixxs.net/tools/grh/ula/, although none of them is > > preferrable because of being operated by some recognized authority. > > If an operator would want to make its ULA prefix known, it might need > > to register it with multiple existing registries. > > > > ULA Centrally assigned ULA addresses (ULA-C) was an attempt to > > introduce centralized registration of randomly assigned addresses and > > potentially even carve out a different ULA prefix for such addresses. > > This proposal is currently not proceeding, and it is questionable > > whether the stable connectivity use case provides sufficient > > motivation to revive this effort. > > I think all that is a red herring. I suggest replacing it by a simple > statement: > > If packets with unexpected ULA addresses are seen they should > be discarded. > > (Even that is not really needed, since all border routers should > discard such packets anyway.) I remember we had long discussions about this so i kinda want to refrain from removing the text. Instead: The filtering you mentioned should vbe in ACP spec but where not. So i added into acp-09: - mandate that ACP edge devices must filter based on source IPv6 address. - Mandating/explain that RPL roots can diagnose unknown destination IPv6 addresses in the ACP. (Aka: if your filtering did mean the destinationa address, then this is NOT possible on the border router due to RPL. Can't have minimum routing table and full route prefix visibility at the same time ;-( So, with that text there, i changed the stable connectivity paragraphs above to read: The ACP specification demands that only packets from configured ACP prefixes are permitted from ACP connect interfaces. It also requires that RPL root ACP devices need to be able to diagnose unknown ACP destination addresses. To help diagnose packets that unexpectedly leaked for example from another ACP (that was meant to be deployed separately), it can be useful to voluntarily list your own the ULA ACP prefixes in one of the sites on the Internet, for example https://www.sixxs.net/tools/grh/ula/. Note that this does not constitute registration and if you want to ensure that your leaked ACP packets can be recognized to come from you, you may need to list your prefixes in multiple of those sites. Note that there is a provision in for non-locally assigned address space (L bit = 0), but there is no existing standardization for this, so these ULA prefixes must not be used. > > Using current registration options implies that there will not be > > reverse DNS mapping for ACP addresses. > > Really? I assume we're talking about two-faced DNS, and afaik nothing > stops an operator providing reverse mapping in the private DNS. > That seems to be implied by the following paragraphs, so the text > seems inconsistent anyway. I know it under the name "split-horizon DNS". Is there any reference ? I changed the two paragraphs to read as follows, i hope this eliminates any real or perceived conflicts: According to RFC4193 section 4.4, PTR records for ULA addresses should not be installed into the global DNS (no guaranteed ownership). Hence also the need to rely on voluntary lists (and in prior paragraph) to make the use of an ULA prefix globally known. Nevertheless, some legacy OAM applications running across the ACP may rely on reverse DNS lookup for authentication of requests (eg: TFTP for download of network firmware/config/software). Operators may therefore use split horizon DNS to provide global PTR records for their own ULA prefixes only into their own domain to continue relying on this method. Given the security of the ACP, this may even increase the security of such legacy methods. > > 4. No IPv4 for ACP > > This section seems out of place stuck between Security Considerations > and IANA Considerations. Maybe it should be an Appendix, referenced > in section 2.1.4. "IPv4 only NMS hosts". Michael Richardson made the argument that nobody reads beyond the list of authors, and i kinda agree, so i am trying to avoid appendices. Like in the ACP document i have now moved this section before the standard Security/IANA considerations and put it under the label "Architectural considerations". Which kinda should show its closeness to all the other following "Considerations". Hope this is fine. If not, yell. > Nits/English: > ------------- > > (There are probably other nits as well as these, which the RFC Editor > will fix...) Right. Lets agree on "code complete", i will do more spell checker later as well. > > Abstract > ... > > ... Provisioning during device/network bring > > up tends to be far less easy to automate than service provisioning > > later on, changes in core network functions impacting reachability > > can not be automated either because of ongoing connectivity > > requirements for the OAM equipment itself, and widely used OAM > > protocols are not secure enough to be carried across the network > > without security concerns. > > Suggested: > > Provisioning while bringing up devices and networks > tends to be more difficult to automate than service provisioning > later on, changes in core network functions impacting reachability > cannot be automated because of ongoing connectivity > requirements for the OAM equipment itself, and widely used OAM > protocols are not secure enough to be carried across the network > without security concerns. Thanks. Copied. > > This document describes how to integrate OAM processes with the > > autonomic control plane (ACP) in Autonomic Networks (AN). to provide > > stable and secure connectivity for those OAM processes. > > Suggested: > > This document describes how to integrate OAM processes with the > autonomic control plane (ACP) in Autonomic Networks (AN) in order to provide > stable and secure connectivity for those OAM processes. Thanks. Copied. > > 1.2. Data Communication Networks (DCNs) > > > > In the late 1990'th and early 2000, IP networks became the method of > > choice to build separate OAM networks for the communications > > infrastructure in service providers. This concept was standardized > > in G.7712/Y.1703 > > This needs a complete informational reference. Also, according to > https://www.itu.int/rec/T-REC-G.7712-200303-S/en it is a superseded > reference, so maybe there is a better one? Reference now points to the oldest version of the series because that is the purpose of the text (since when is this done). Annotation in reference points to the home page of the series - https://www.itu.int/rec/T-REC-G.7712/en > > 2.1.1. Simple connectivity for non-autonomic NMS hosts > ... > > For example, if DNS in the network was set up with > > names for network devices as devicename.noc.example.com, then the ACP > > address of that device could be mapped to devicename- > > acp.noc.exmaple.com. > > ... acp.noc.example.com Ack. > > 2.1.2. Challenges and limitation of simple connectivity > ...> Note that these challenges and limitations exist because the ACP is > > primarily designed to support distributed ASA ... > > Define "ASA" when first used. Ack. > Regards, > Brian > > From nobody Wed Aug 2 18:14:11 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8D2129B2A; Wed, 2 Aug 2017 18:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-EAKHrLArcH; Wed, 2 Aug 2017 18:14:07 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 105CB128BC8; Wed, 2 Aug 2017 18:14:07 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 30B5E58C4BC; Thu, 3 Aug 2017 03:14:03 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 13F0BB0C792; Thu, 3 Aug 2017 03:14:02 +0200 (CEST) Date: Thu, 3 Aug 2017 03:14:02 +0200 From: Toerless Eckert To: mohamed.boucadair@orange.com Cc: "draft-ietf-anima-stable-connectivity@ietf.org" , "anima@ietf.org" Message-ID: <20170803011402.GB12136@faui40p.informatik.uni-erlangen.de> References: <20170727185150.GZ3889@faui40p.informatik.uni-erlangen.de> <787AE7BB302AE849A7480A190F8B93300A014351@OPEXCLILMA3.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A014351@OPEXCLILMA3.corporate.adroot.infra.ftgroup> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] review comments draft-ietf-anima-stable-connectivity-03-rev Med.doc X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 01:14:09 -0000 On Fri, Jul 28, 2017 at 12:02:25PM +0000, mohamed.boucadair@orange.com wrote: > Hi Toerless, > > The new version looks much more better. Thanks. Great. > Some comments about these two minor point: > > - "IPv4 to IPv6 NAT can be used." - Do you mean RFC7915 > I intentionally did not want to elaborate on the details of which of the 15? different > NAT options can be used best. When i worked on this, i got a working setup with NAT-PT and i think > also NAT64 statefull (RFC6146). This was mostly driven by whatever old router OS versions > where available.Also your note re. rfc7757. The main issue is that the stateless translations would > require matching address structures in he ACP, and i certainly would not want to fudge the ACP design > to support NAT better. Rather use some horrific NAT option. That should even accelerate pushing IPv6 > into NOC/OAM equipment. > > So, i didn't add any pointers to those RFCs you mentioned. I think its good if this is > left as an exercise to the reader ;-) > > Med: Fair. Please change "IPv4 to IPv6 NAT can be used" to "IPv4 to IPv6 translation can be used" because it is more than "Address" translation. Please check out the just posted -05. After Brian also complained about the use of NAT i gave in (aka: both you and brians desire to get this redone where critical mass ;-)). There should now be no use of "NAT" in the doc, instead SIIT and EAM and how we would suggest to build a solution with them for ACP connect (aka: suggetions for prefixes to be mapped via EAM), but that the details of the solution are out of scope. > - "I'm afraid NoO " - i did not get that. > > Med: This was related to this part of your text: > > == > Overall, the use of NAT is especially subject to the RoI (Return of > Investment) considerations, > ======== > > The reasoning about NAT and RoI may seem to be intuitive, but I'm afraid it does not reflect the deployment reality. The use of NAT may even come for free or be a function of the traffic and so on. > I would delete the mention of RoI. Well, i did not mean to imply that NAT/SIIT would be too expensive to deploy, i rather wanted to be neutral because i too had a customer that said "i am happy to use NAT when you give me a working recipe". Which i was able to do. But i also do not want to promote this of course. If you could suggest any better text to keep the balance, i'd happliy take it ;-) Cheers Toerless > > Cheers, > Med > > > -----Message d'origine----- > > De : Toerless Eckert [mailto:tte@cs.fau.de] > > Envoyé : jeudi 27 juillet 2017 20:52 > > À : BOUCADAIR Mohamed IMT/OLN > > Cc : anima@ietf.org; draft-ietf-anima-stable-connectivity@ietf.org > > Objet : Re: review comments draft-ietf-anima-stable-connectivity-03-rev > > Med.doc > > > > Thanks a lot, Mohamed for the thorough review! > > > > I pushed -04 of the draft out with your changes incorporated. IMHO it's > > all great textual improvements but no logical changes, aka: should be fine > > for prior reviewers. > > > > Diff: > > > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.o > > rg/id/draft-ietf-anima-stable-connectivity- > > 03.txt&url2=https://www.ietf.org/id/draft-ietf-anima-stable-connectivity- > > 04.txt > > > > Your original review doc: > > > > https://github.com/anima-wg/autonomic-control-plane/blob/master/draft- > > ietf-anima-stable-connectivity/03-review-mohamed.boucadair.doc > > > > My reply comments: > > > > https://github.com/anima-wg/autonomic-control-plane/blob/master/draft- > > ietf-anima-stable-connectivity/03-review-mohamed.boucadair-reply.txt > > > > While incorporating your review, i also figured that it would be good if > > ACP connect > > would allow auto-configuration of NMS hosts, so i added a paragraph to > > mandate RFC4191, > > but i didn't rev ACP draft just for that yet, so here's just diff on > > github for that; > > > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.o > > rg/id/draft-ietf-anima-autonomic-control-plane- > > 08.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control- > > plane/af74117400b6a5a7fca1acf2ab910d64a580a5c9/draft-ietf-anima-autonomic- > > control-plane/draft-ietf-anima-autonomic-control-plane.txt > > > > Cheers > > Toerless > > > > On Mon, Jul 24, 2017 at 05:49:07AM +0000, mohamed.boucadair@orange.com > > wrote: > > > Dear Toreless, > > > > > > I'm resending this document as I didn't receive an ACK from your side. > > > > > > Please consider those as part of the WGLC comments. > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De : BOUCADAIR Mohamed IMT/OLN > > > > Envoyé : vendredi 7 juillet 2017 14:58 > > > > À : 'tte+ietf@cs.fau.de' > > > > Objet : Envoi d?un message : draft-ietf-anima-stable-connectivity-03- > > rev > > > > Med.doc > > > > > > > > Dear Toreless, > > > > > > > > Please find some comments about this draft. > > > > > > > > Cheers, > > > > Med > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Wed Aug 2 18:21:01 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADC6129B2A for ; Wed, 2 Aug 2017 18:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvtRuWu5t2P0 for ; Wed, 2 Aug 2017 18:20:59 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0906129ADD for ; Wed, 2 Aug 2017 18:20:58 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id C9A2E58C4BC; Thu, 3 Aug 2017 03:20:54 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id ABB42B0C792; Thu, 3 Aug 2017 03:20:54 +0200 (CEST) Date: Thu, 3 Aug 2017 03:20:54 +0200 From: Toerless Eckert To: Michael Richardson Cc: anima@ietf.org, Pascal Thubert Message-ID: <20170803012054.GC12136@faui40p.informatik.uni-erlangen.de> References: <32649.1500771022@dooku.sandelman.ca> <25703.1501546371@obiwan.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25703.1501546371@obiwan.sandelman.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] ACP document --- 07 to 08 changes X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 01:21:01 -0000 Thanks, Michael for the thorough review. Answers to your mail point by point below. There was a bunch of stuff i did put into acp-09 because of Brians review, and then in finished with your review. Here is just the diffs from your stuff (see below, i need more git help to pull stuff like yours in directly, so i just did it manually, and i already see i missed one typo...): http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/0fb8510386f0557702a00fb45ea145015bd92db5/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/2da05c288065608d1781ec4cc66e238f503e8e12/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.txt Rest below: > All of my minor edits and a few smallish friendly amendments are at: > https://github.com/anima-wg/autonomic-control-plane/pull/3 Yeah... because i was already finished doing all my changes from acp-08 -> acp 09 due to Brian Carpenters review, and still a total greenhorn on git, i could not figure out how to resolve the conflict. There was also no way to individually try to merge the commits, and of course it was the first commit with all the whitespace stuff that failed. So i ended up doing all the commits manually via one single commit: https://github.com/anima-wg/autonomic-control-plane/tree/063938e3b697185da2ceec4caad69a3de5de4572 Hopefully i did copy all your changes correctly. I did change the sentence about the RPL "needs to go through RPL root" to something like "needs to go along DODAG (tree) rooted in NOC"... Aka: it really depends on topology so i don't think your "unless its a descendant" was correct. > Now to the changes in -08: > > AN "Autonomic Network". A network according to > [I-D.ietf-anima-reference-model]. Its main components are Intent, > Autonomic Functions and ANI. > > So, I had an initial problem with this, that it referes to something we have > no idea about, "Intent". Then I wondered if this was well defined in the > reference, and I find that actually the reference model has no terminology > section.... maybe one could consider the entire document a terminology > section. But, it seems strange to be definining this way in *this* document. > I think that it should end at the first period. If the second sentence is > needed, it should go into the reference. 1. opened a git issue for the reference model about this. 2. I'd like to pledge with you not having to change this: There are a couple historic places in the ACP spec that i would paraphrase as "magic future intent can improve this". I did not want to change/eliminate them. But i wanted to make sure that we make it as clear as possible that nothing in the ACP depends on intent. WHich i think i did in a bunch of the other explanations in the terminology section. And just because i restate something from the reference model does not mean i define it here. Its explicitly referring to the reference model and just restating. Aka: I would like the ACP doc to be read standalone, and the reader should get away with the following overview from the terminology section: AN = Intent, Autonomic Functions, ANI Autonomic Functions = made up of software called ASA -> You do not need to care about Intent, Autonomic Functions to use ANI ANI = ACP, BRSKI, GRASP ACP = needs GRASP but does not mandate use of BRSKI > On this topic (which is not "ACP document"), I'm concerned about the amount > of (*) text in the reference model document! opened issue in github, with suggested resolution: Toerless: Should try to find a place in the doc to justify the existiance of all those (*): We wanted to spell out the parts of autonomic networks that we had conceptually in mind not to further refine them, but to be able to vet what impacts they could have on the definition of the ANI charter items. For example, the structuring of the ACP via subdomains goes back to the reference model. > AN Domain Name A string name (typically in a format of a DNS domain > name) identifying an Autonomic Network. It is stored in the > ACP information field of an ANI devices LDevID. > > re (typically..) either it's an FQDN (with all the QNAME restrictions and a > reference), or it's just a string. Let's decide one way or the other, rather > than "typically". Ack. FQDN. Normative section about certificate now says so and says that if you don't own any FQDN, make one up that is unique (exercise left up to the reader ;-). > I think that there are a number of other terms which should not be introduced > definitatively in this document.... If you give me some hints on merging git commits feel free to add them. Else let me know and i can do it. > 5. Inside the ACP VRF, each node sets up a virtual (loopback) > interface with its ULA IPv6 address. > > I think we should say that it's a /128. > > section 6.1.2 says "Maintenance" but, it's about AN_join_registrar. > > I don't think that the AN_join_registrar definition belongs in this document. > I agree that some minor bit of text should exist, but I don't think this > belongs here. This belongs in BRSKI. > Perhaps it got clipped out in editing, but that's a bug. So... This has nothing to do with BRSKI and is not implying the need for BRSKI in any way! This is purely about the need to have an EST server for certificate renewal and be able to find it dynamically via GRASP. The way i am proposing the encoding of the objective is that the cert renewal function is looking for objective=AN_join_registrar and option="EST-TLS" BRSKI would look for for objective=AN_join_registrar and option="BRSKI-TLS" And of course this would be a single GRASP announcement with just a list of options. So in the end, the BRSKI draft would need to be changed to say option=["BRSKI-TLS","EST-TLS"] So, this i felt was best inline with the fact that BRSKI is a superset of EST. Aka: with the terminology we use in BRSKI... Of course, we could equally define a separate objective, eg: EST_Server. IMHO, the best "logical" term would the AN_Registrar because an AN_Registrar that can only do EST (renewal), but not BRSKI is not a _join_ registrar. But i did not do this because the discussion about the ter AN_join_registrar was already so long. So, let me know whatever term you think is best, objective name and/or option name... > section 6.6: > If our devices certificate indicates a CDP or OCSP then the peers > certificate must be valid occrding to those (eg: OCSP check across > the ACP or not listed in the CRL). > {see git for a grammar fix to above} > > Somewhere, I think that we should be saying that Certificate > Distribution Points (CDPs) or OCSP servers (whichever is used) SHOULD be > available via the connections inside the ACP. BUT, as those things are > usually referenced with names there are some MIF-like isues that I think the > ACP document should address: > 1) DNS. > 2) address preferences. > (Homenet's naming architecture is dealing with the same questions, but I > think the answers may be different) Well, -08 already does says one minimal option: The ACP device MUST support Certificate Revocation Lists via HTTPs from one or more Certificate Distribution Points. These CDPs MUST be indicated in the Domain Certificate when used. If the CDP URL uses an IPv6 ULA, the ACP device will try to reach it via the ACP. In that case the ACP address in the domain certificate of the CDP as learned by the ACP device during the HTTPs TLS handshake MUST match that ULA address in the HTTPs URL. Aka: Automatically discover that the address is reachable via ACP because its an IPv6 ULA. Thats kinda lame but easy and does not bring us into more troublesome options. The next best option IMHO would be to have CDP proxy service announced via GRASP, eg: AN_Registrars are manually configured for the service, so in that config you do some box-local decision whether to reach the CDP via data plane or ACP, and then the registrar announces itself as the TCP endpoint for the CDP and proxies it to the actual CDP. Aka: make things auto-discovered across the ACP and then use the registrars as the proxies into the legacy landscape. Same solution as for enrolment... Let me know what you like/want. Text proposals welcome. > 6.8.1. GRASP as a core service of the ACP > > I think that this section is really important. > Too important to belong buried in a document about to build secure tunnels > for IP traffic. At the least, this belongs prominently in the reference > model document. At the largest, it needs a new document with a title like: > "The ACP profile of GRASP as a core service" > > along with 6.8.2. I did open an issue for the reference model. I am not sure i understand the proposal for a separate document. I had some thoughts on how to proceed with promoting the idea of ACP+GRASP as a core way to do distributed service discovery as opposed to the current unicast DNS-SD that requires "well managed DNS server"... Is that the direction you where thinking of as well ? > re 6.10.2: > -> 8+40+2 = 50 bits. > so why in 6.10.3 says, "51 bits" for subscheme. > > I don't find the rational for the V bit very convincing. I don't think you > need any real justification for it. This came from actual prototypng work where we wanted to add ACP as a virtual router to an existing system and then we first figured we needed to use the XXX (forgot name, the thing they use with docker and other container stuff...) p2p virtual interface pair in linux - one interface for the application side, one interface for the ACP virtual router. Now i didn't specifically mention this .. maybe i should The decoupling of the port space looked like the easir justification example. > 6.10.4. ACP V8 Addressing Sub-Scheme > The sub-scheme defined here is defined by the Type value 1 (one) in > the base scheme. > > I think you mean, "Type value 01 (one)", since there are two type bits. > I find the use of 1 confusing, given that we also have the Z bit. > You've made me happy with the address definition. I changed this to 00b and 01b in the text. See also in -09 i have modified the V8 to Vlong because it now has the option of either /8 or /16 V space. (given our IPinIP example or me wanting automatic ACP connect subinterfaces and 8 bit might not be enough - eg: i remember controllers that had also more than 256 virtual functions each with its own address). > I sent some text via pull request to clarify some of the no-artifact choice > in RPL. most of the rest of the text looks great to me... > (I just learnt that "artefact" was british spelling for artifact.. I guess we > just need to pick one or the other.) Ok, changed to artifact. Don't want any british english, it always empties up my supply of vovels. > I'll have to ask Pascal why he suggested: > Trickle: Not used. If i understand it correctly its because the profile does like "regular" IGPs try to track up/down state changes and triggers route recalc... But if not, then i am also interested in the explanation. > 7.1 --- a pretty important section. > One consideration that might be worth doing in a future document is > registering a TLV for LLDP (CDP) that could carry GRASP M_FLOOD ACP > messages. That would please switch fabric vendors because then making the > topologies follow physical would be very easy. LLDP does not get forwarded. > > I wonder who knows the right IEEE incantations to do this. We can ask Norm Finn when we run into him, he would know if IEEE would like such piggybacking. > > section 10.1: it seems like it's all been said already. No, absolutely not! There is some duplication from the normative text, but hopefully a lot easier to read. But there is also the key paragraphs about why BRSKI is really the best companion of ACP. I couldn't say this in the normative part of the doc because we want BRSKI to be optional from the normative perspective. The best buddy text is about the fact that you do not need cert revocation because with BRSKI and short lived certs you can achieve the same thing much easier. And it depends on ACP+BRSKI collaborating to make re-enrollment totally painless. > section 10.2 ---> move to an appendix. > section 10.3 ---> appendix or cut. > I see that it all *WAS* in an appendix. I don't know why you moved it. ;-)) Hey, it was YOU who persuaded me that "nobody reads beyond the authors list", thats why i moved the appendices into the main text. But i specifically marked all sections as "Normative" vs. "Informative". So now there is now two "Informational" sections. One is the "Benefit", the other is "Further Considerations". If you want me to move the whole "Further Considerations" out as appendices i can do that, but if you want to break it up because you like some sections in there more than others... i think that would make the doc look more complex than it looks now". I wonder if i can mark the "IANA/Security Considerations" as "Legislative" or if IESG would take offense at that. But it would nicely mark all sections with the right TIVE ;-) > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- Cheers toerless From nobody Wed Aug 2 18:24:50 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C336131C2F; Wed, 2 Aug 2017 18:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44K94puFHJdC; Wed, 2 Aug 2017 18:24:48 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 659DA129B2A; Wed, 2 Aug 2017 18:24:48 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id B96E858C4EA; Thu, 3 Aug 2017 03:24:44 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 9E3ECB0C792; Thu, 3 Aug 2017 03:24:44 +0200 (CEST) Date: Thu, 3 Aug 2017 03:24:44 +0200 From: Toerless Eckert To: Sheng Jiang Cc: "anima@ietf.org" , "anima-chairs@ietf.org" Message-ID: <20170803012444.GD12136@faui40p.informatik.uni-erlangen.de> References: <5D36713D8A4E7348A7E10DF7437A4B927CE3D7BA@NKGEML515-MBX.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B927CE3D7BA@NKGEML515-MBX.china.huawei.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Result of WGLC on draft-ietf-anima-stable-connectivity-03 - Respond by July 28, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 01:24:49 -0000 Thanks, Sheng I think i was just posting version -04 when Sheng posted this, it had all the textual fixes from Mohamed. Then i continued with Brian Carpenters feedback that i just posted as version -05, so pls. review version -05. The changelog in the file summarizes all the points. The change from -04 to -05 did go along leveraging the now hopefully a lot better "ACP connect" (interface & addressing & security) text in draft-ietf-anima-autonomic-control-plane-09 that i also posted. As already said to Brians review: If you can, it would be great to not only post to the list, but also open an issue in github for any outstanding issues: https://github.com/anima-wg/autonomic-control-plane/issues Cheers Toerless On Tue, Aug 01, 2017 at 07:23:52AM +0000, Sheng Jiang wrote: > Hi, all > > We received no negative response to the WGLC on draft-ietf-anima-stable-connectivity-03 during the two-week WGLC and we did receive good reviews through the WG document stage, through the shepherd review process and WGLC period. Considering the past history of this work, I, with my ANIMA chair cap on, feel it is has passed the WGLC and should advance. This conclusion is made with the condition that the authors would solve the comments received during the WGLC and these modifications were not substantial changes from 03 version. If there are big changes, a shorter second WGLC may be needed. > > Up to now, there is no IPR disclosure linked to this document. > > Once the update is published and it meets the above condition, for which the second WGLC is not needed, as the document shepherd, I will finalize the shepherd document and send the document on. > > Best regards, > > Sheng (co-chair, Toerless who as a co-author stayed neutral on the content side) > -- --- tte@cs.fau.de From nobody Thu Aug 3 16:31:38 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42AD6131E9F for ; Thu, 3 Aug 2017 16:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAS5ztnfGBwP for ; Thu, 3 Aug 2017 16:31:34 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85957131EBA for ; Thu, 3 Aug 2017 16:31:34 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id u5so738219pgn.0 for ; Thu, 03 Aug 2017 16:31:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FkKdpTmaVMHnP6sAkXKiSCzX68+BIZWgUiyWdkI4jPA=; b=Ip8spMK89UlEfnO4avu2OsfqQI6IQYB1CyCAmpmPBhNtLx1K6noOz5U8fuQQATFqgM 1NsfBQz1CUtqC8S8c5XvJ0xsilc9ySsEC6uVC3e49cnRHBfGoGHsMZ7S1tjtScSGd4WE TAUBNkug6q0QbadNfwRi06bf58B0dY2yltgzVwXPQZoLlwrFvj/9UOzIW6iYf5h3LKKK rF5A5LCeobxoI/Etj9+FP6eKNYczQx547GSV/pZS/4ZNitbUYCwVM/fYsF3ZZYtD10b7 psBxiw5KVU7BX7miry2YMFAy9KXIegHB+qBbUFaq2fVjkbi+SeeMFrPAyPDzb+cpbXss yeNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=FkKdpTmaVMHnP6sAkXKiSCzX68+BIZWgUiyWdkI4jPA=; b=sd4cTesYbSHom7Ga2JKoa+XXA1L30r4gO1DrPNXPdvT4BK//ztCx1mMyDhQyN6VLy+ UGAeZF0m82fQqpTzcAkw7dgxCF3hygTOB+8qcGtBf7H18FrvLetrEGZrIKlOaAvD3XEo XkRyQT3k/jKKrAS5T7x7stSREYqLFWsrnCUMKhZ6UnnTA8BXMIBcV5vbxH9UvAuBd3ZH WlD4M/nu7ZjazfS+zrF/NUyIQ8T0XYhbdrfVuhvvQ41x14uWnK1AXSngrzHWQ5zg0Jxk BQydUSnxk1pU4oUymluQ19DUR5h2ZT3+KaBApdsSagYnOhhoo+s0Xn3yrB/GfUuQ5exo 5PaA== X-Gm-Message-State: AIVw1112grgYd6bRdwboh0BZ8bBTPy9TP3DnugDtYqUl20sXYtc2WL/H 9td3d7SEW/TUpckf X-Received: by 10.84.229.79 with SMTP id d15mr476125pln.355.1501803093922; Thu, 03 Aug 2017 16:31:33 -0700 (PDT) Received: from ?IPv6:2406:e007:521f:1:28cc:dc4c:9703:6781? ([2406:e007:521f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id s18sm117898pfg.166.2017.08.03.16.31.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Aug 2017 16:31:32 -0700 (PDT) To: Toerless Eckert Cc: Anima WG References: <5D36713D8A4E7348A7E10DF7437A4B927CDFE66F@NKGEML515-MBX.china.huawei.com> <136a3ebd-dedb-9e2b-86be-a7d5fd12ad9b@gmail.com> <20170803010809.GA12136@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 4 Aug 2017 11:31:37 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170803010809.GA12136@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] WGLC on draft-ietf-anima-stable-connectivity-03 - Respond by July 28, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 23:31:36 -0000 I'm just coming back on a couple of points. Generally -04 is almost there... On 03/08/2017 13:08, Toerless Eckert wrote: ...>>> 2.1.8. Long term direction of the solution >> ...> 1. NMS hosts should at least support IPv6. IPv4/IPv6 NAT in the >>> network to enable use of ACP is long term undesirable. Having >>> IPv4 only applications automatically leverage IPv6 connectivity >>> via host-stack options is likely non-feasible (NOTE: this has >>> still to be vetted more). >> >> That NOTE needs to be cleared up. Something like 464XLAT (RFC6877) >> might be a good compromise. > > See the rewritten SIIT section. IMHO, there can be no simpler "network" based > address translation. Where network based means that the translation happens > in some device he network operator needs to provision. Like the ACP edge device. > Or even an additional address translation device. > > So, the only IMHO easier option is when the OS of the NMS host would internally > have IPv4/IPv6 translation so the device/VM looks to the outside like full IPv6. Yes, that is exactly the effect of 464XLAT in the end-system (not in the router). > Alas, i didn't have the time to investigate these options. And most likely if at > all you could only make those work for linux. Linux or Windows, yes. In a vendor's router o/s, who knows? But maybe they will all support IPv6 anyway? > > So, for now i just remove the note and clarified the last sentence a bit. > > If there is anything specific to be said bout why 464XLAT might be better > longer term, let me know and i can add it. For now it looks like yet another > network device configured option to me, but i have not tried to understand it > all the way. I think you'd need one of the 464XLAT authors to have a look at the scenario, because I don't claim to understand it all. ... >>> Using current registration options implies that there will not be >>> reverse DNS mapping for ACP addresses. >> >> Really? I assume we're talking about two-faced DNS, and afaik nothing >> stops an operator providing reverse mapping in the private DNS. >> That seems to be implied by the following paragraphs, so the text >> seems inconsistent anyway. > > I know it under the name "split-horizon DNS". Is there any reference ? The DNS community in the IETF hates split DNS so much that not much has been written about it. I did find these: https://tools.ietf.org/html/rfc6950#section-4 https://tools.ietf.org/html/rfc7157#section-6.3 https://tools.ietf.org/html/draft-richardson-homenet-secret-gardens Regards, Brian From nobody Thu Aug 3 16:34:57 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A299131C2C for ; Thu, 3 Aug 2017 16:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sB_TqmRyJo-k for ; Thu, 3 Aug 2017 16:34:53 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B73861318A2 for ; Thu, 3 Aug 2017 16:34:53 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id v77so713783pgb.3 for ; Thu, 03 Aug 2017 16:34:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=DrvHV02OfCCCJaked7lgrWEGAX9QWVmtv1jDz1fcB5E=; b=QTp0LKFj0FXccAnIa/jWbnw4izBjDHFxkzbyhdDUimJYqoHJ0Cx7iiIVXf4F5tOxG2 4gClbMPbp92Da94HYr8brORDjrmZTwEcIEHHofJg158zocTKayo3eRuKHXgERdKdVmeO y5/X8b1h557f6wlpPbyOQw6Dp1KwaScSpI2A4TvkcxzKCJC2cCL9WlGERB1f2VRHiUKN 8J/Pkz+yYgi9jIHTk6x+nhwPGrkhqm5XMWlU6kIl6x3HmMlmIU1oOxORzk+YAfZC81W3 tjCAiDkxNwrwnDyWz5+odfenxG3SN/vioNHA8/HJU1wMDGL0Gbzl3uhSgNoM+hq375E3 k4BA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=DrvHV02OfCCCJaked7lgrWEGAX9QWVmtv1jDz1fcB5E=; b=riKHqxc0gBkWVxrjqRZl52WRD9YB+VnkcUlU9Xks9TCaJWfH478O2SwoGCQN6x2hBQ EbqfwEUCjsHLNgK0X6TYkOznh4y/IbOtSjJwWOKMiIEux4X8lfYLMgBaa+ZYQcD311p/ Z+wCLI/yjscn4UuMstSLlmaPrj73ZT4n80D/D0y4up8dTUMG/VV0bCNDnm9yQJPL5wIR 39MnwHkTzCG3gxJHZzebrcZE7sm02EVNpLaYbrlVn+T9xKO+Ymv7Tf9iWiLOPOdSL/5V wqcFaPlsDg0dOo3RpaUXbPLykU6iKFKcxEICaF/CwqZle25vwg6hLzyCgxcyXHImbWBC jFTA== X-Gm-Message-State: AIVw110+RWgOD8xXuzvD2Z+pEFEEMQdoy+gdnm0gI/RrMHgtsSn2UL8O K4Z70P/HCcVWdyt+ X-Received: by 10.84.167.2 with SMTP id c2mr494366plb.371.1501803293136; Thu, 03 Aug 2017 16:34:53 -0700 (PDT) Received: from ?IPv6:2406:e007:521f:1:28cc:dc4c:9703:6781? ([2406:e007:521f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id d4sm143839pfj.59.2017.08.03.16.34.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Aug 2017 16:34:52 -0700 (PDT) To: Toerless Eckert Cc: Anima WG References: <5D36713D8A4E7348A7E10DF7437A4B927CDFE66F@NKGEML515-MBX.china.huawei.com> <136a3ebd-dedb-9e2b-86be-a7d5fd12ad9b@gmail.com> <20170803010809.GA12136@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 4 Aug 2017 11:34:57 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] WGLC on draft-ietf-anima-stable-connectivity-03 - Respond by July 28, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 23:34:55 -0000 I wrote: "Generally -04 is almost there..." I meant: Generally -05 is almost there... Regards Brian On 04/08/2017 11:31, Brian E Carpenter wrote: > I'm just coming back on a couple of points. Generally -04 is almost there... > > On 03/08/2017 13:08, Toerless Eckert wrote: > ...>>> 2.1.8. Long term direction of the solution >>> ...> 1. NMS hosts should at least support IPv6. IPv4/IPv6 NAT in the >>>> network to enable use of ACP is long term undesirable. Having >>>> IPv4 only applications automatically leverage IPv6 connectivity >>>> via host-stack options is likely non-feasible (NOTE: this has >>>> still to be vetted more). >>> >>> That NOTE needs to be cleared up. Something like 464XLAT (RFC6877) >>> might be a good compromise. >> >> See the rewritten SIIT section. IMHO, there can be no simpler "network" based >> address translation. Where network based means that the translation happens >> in some device he network operator needs to provision. Like the ACP edge device. >> Or even an additional address translation device. >> >> So, the only IMHO easier option is when the OS of the NMS host would internally >> have IPv4/IPv6 translation so the device/VM looks to the outside like full IPv6. > > Yes, that is exactly the effect of 464XLAT in the end-system (not in the > router). > >> Alas, i didn't have the time to investigate these options. And most likely if at >> all you could only make those work for linux. > > Linux or Windows, yes. In a vendor's router o/s, who knows? But maybe they > will all support IPv6 anyway? > >> >> So, for now i just remove the note and clarified the last sentence a bit. >> >> If there is anything specific to be said bout why 464XLAT might be better >> longer term, let me know and i can add it. For now it looks like yet another >> network device configured option to me, but i have not tried to understand it >> all the way. > > I think you'd need one of the 464XLAT authors to have a look at the scenario, > because I don't claim to understand it all. > > ... >>>> Using current registration options implies that there will not be >>>> reverse DNS mapping for ACP addresses. >>> >>> Really? I assume we're talking about two-faced DNS, and afaik nothing >>> stops an operator providing reverse mapping in the private DNS. >>> That seems to be implied by the following paragraphs, so the text >>> seems inconsistent anyway. >> >> I know it under the name "split-horizon DNS". Is there any reference ? > > The DNS community in the IETF hates split DNS so much that > not much has been written about it. I did find these: > https://tools.ietf.org/html/rfc6950#section-4 > https://tools.ietf.org/html/rfc7157#section-6.3 > https://tools.ietf.org/html/draft-richardson-homenet-secret-gardens > > Regards, > Brian > From nobody Mon Aug 7 20:57:18 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28CDA120727; Mon, 7 Aug 2017 20:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 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 T37XW5F0se4H; Mon, 7 Aug 2017 20:57:14 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD4A8120721; Mon, 7 Aug 2017 20:57:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DSX91216; Tue, 08 Aug 2017 03:57:12 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 8 Aug 2017 04:57:11 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Tue, 8 Aug 2017 11:57:05 +0800 From: Sheng Jiang To: "anima@ietf.org" CC: "anima-chairs@ietf.org" Thread-Topic: ANIMA minutes - IETF 99, Prague Thread-Index: AdMP+mNE2hh8hiCRTlmiIBmCH3zn3Q== Date: Tue, 8 Aug 2017 03:57:05 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927CE40A7C@NKGEML515-MBX.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.119] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B927CE40A7CNKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.59893698.0036, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 9364a4a447afc802fa5e265efc6e611a Archived-At: Subject: [Anima] ANIMA minutes - IETF 99, Prague X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 03:57:16 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B927CE40A7CNKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, all, The minutes for the ANIMA sessions at IETF99 in Prague can be found at: https://datatracker.ietf.org/meeting/99/materials/minutes-99-anima Many thanks to Bing Liu for taking minutes. Please send any corrections to the chairs. Best regards, Sheng + Toerless --_000_5D36713D8A4E7348A7E10DF7437A4B927CE40A7CNKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, all,

 

The minutes for the ANIMA sessi= ons at IETF99 in Prague can be found at:

 

https://datatracker.ietf.org/me= eting/99/materials/minutes-99-anima

 

Many thanks to Bing Liu for tak= ing minutes.

 

Please send any corrections to = the chairs.

 

Best regards,=

 

Sheng + Toerless=

 

 

--_000_5D36713D8A4E7348A7E10DF7437A4B927CE40A7CNKGEML515MBXchi_-- From nobody Thu Aug 10 17:09:17 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D8F1324B4 for ; Thu, 10 Aug 2017 17:09:16 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sy64JSjpisqH for ; Thu, 10 Aug 2017 17:09:11 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D7241324B7 for ; Thu, 10 Aug 2017 17:09:11 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 964492009E for ; Thu, 10 Aug 2017 20:11:30 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A033E806BA for ; Thu, 10 Aug 2017 20:09:10 -0400 (EDT) From: Michael Richardson To: anima@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] draft minutes from bootstrap design team X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 00:09:16 -0000 --=-=-= Content-Type: text/plain This set of minutes covers design team meetings from: 2017-03-09, and includes discussions from IETF98 (and hackathon) and IETF99. The previous (draft) minutes are at: https://www.ietf.org/mail-archive/web/anima-bootstrap/current/msg00474.html Raw minutes can be found at: https://github.com/anima-wg/anima-bootstrap/blob/master/minutes/anima-20170502/anima-bootstrap.txt https://github.com/anima-wg/anima-bootstrap/blob/master/minutes/anima-20170808/raw-minutes.txt We no longer use the anima-bootstrap list, btw. We had best results using appear.in/anima-boostrap, but at times it did not work, but Max's personal webex was sufficiently webrtc to compensate. Meetings occured on: 2017-03-14: max, kent, mcr, m.behringer 2017-03-21: mcr, kent,max 2017-03-25: Hackathon 2017-04-18: mcr, max, (others, unrecorded) 2017-04-25: mcr, peter, mbehringer, kent 2017-05-02: mcr, Michael Behringer 2017-05-09: max, Michael Behringer, mcr, kent 2017-05-16: mcr, max (joining), peter, 2017-05-23: mcr, toerless, kent, peter, max 2017-05-30: mcr, toerless, max 2017-06-02: mcr, toerless 2017-06-06: mcr, toerless, max, michaelbehringer, kent 2016-06-13: not sure if we met 2017-06-20: mcr, toerless, kent (joining) 2017-06-27: mcr, kent, max (coming in), toerless, peter July 4th, etc. prep for IETF99 2017-07-25: kent, mcr, max, toerless, 2017-08-01: mcr, max, kent 2017-08-08: mcr, max, kent, toerless Executive summary: 1) no more discussion about revocation of vouchers; preference for short-expiry vouchers with easy renewals. 2) Enumeration attack against the MASA audit log is not protected against * there was a hackathon on vouchers at the IETF98 (Chicago) Hackathon. We had minimal interaction between a voucher request and a voucher among a Registrar and a MASA using pkcs7 signed JSON. * Pledge and Registrar (really all) SHOULD be tolerant (ignore) PEM headers * around base64 encoded certificates? * Base64 decoding SHOULD be tolerant (ignore) line breaks and white space. * Is there a normative reference for this that we can point to to ensure this works? * The Pledge voucher response validation needs to explicitely state that the nonce MAY be empty (removed by the Registrar). * Clarify that the voucher request is just anything that is parsable as a voucher according to the voucher document. every single field in it is a *request* by the registrar and the server MUST NOT simply sign the request and return it. The MASA MAY read the values in the request to inform the MASA of policy requests by the client. * Max experiemented post-hackathon with JWT, and found that it was rather easy to do/use (2017-04-18). * 2017-04-18, around this time it became clear that: The Registrar then signs this and sends it to the MASA to be turned into a voucher. see [35]https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-05#section-7.1 A voucher request is a voucher that is not signed by the MASA. A voucher request MUST be signed by the Registrar. This is equivalent to the current pkcs7 signing mandate. A new thing: A voucher request MAY be signed by the Pledge. * con: additional crypto operation by the pledge * pro: proof to the masa of physical possession * An option to be discussed. * Another new thing: A voucher MAY include a "previous form of the voucher request" sub-field. e.g. a JSON of the full previously signed voucher. e.g. we add to the YANG model a field that could be a full JSON etc voucher; which itself might have been signed. Thus: * SIDE NOTE: verification of the TLS client cert as being the same as the voucher request might be(!?) assumed in the current 7.2 text. Two reasons for this: * - we avoid having to deal with replay attacks * - and the domain CA cert isn't sent in the TLS handshake but is sent in the signature header ("pkcs7" or "x5c"). * Max: recap of list is that we need a definitive form for the voucher request.... "it's just a voucher" , Max: signed certificate requests mean that the registrar can not change it, and this has caused a mess. * https://tools.ietf.org/html/rfc7950#section-11 (updating a yang module) o A "mandatory" statement may be removed or changed from "true" to "false". ACTIONs from 2017-04-25: * 1) add version field to the voucher * 2) define voucher request in BRSKI (as a voucher) * 3) define any additional fields in BRSKI: * 2017-05-02, mbehringer and (maybe max) mcr go through EDNOTES together Discussion/Question: * Is there a relationship between the TLS Server Certificate of the MASA, and the Issuer Certificate from the IDevID. * Cases: * - pledge contains URL of MASA * - step 1: registrar follows URL (default) * - option 1: redirect: should it be allowed? (if not, cannot deploy anti-DDOS re-direct) * - option 2: manual override of URL: should it be allowed? * Tentatively: Neither option 1 or 2 have an impact on security ("stealing" a device). * HTTP/2, TLS upgrade. * Can/should the registrar connect to MASA, online to the TLS connection to the Pledge, to get the certificate chain to validate the pledge? * 2017-05-09 ACTION: Need normative language that the registrar<->MASA communication is secured using a "web pki" * Going to JWT discussion. Discussion of Kent's email from may2: about JWS and the like. * 2017-05-16: we dealt with email/review from Sheng of the voucher document, and acted on many items. There are emails on the list dealing with the results. **Continued on 2017-05-19 (Friday) using Max's personal webex.** * 2017-05-23: continued to edit voucher document. * we then began to deal with unsolicited rewrite from Toerless. For Toerless: [20]http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-ietf-an ima-bootstrapping-keyinfra-05&url2=https://raw.githubusercontent.com/an ima-wg/anima-bootstrap/concise/dtbootstrap-anima-keyinfra.txt * 2017-05-30: max, Michael Behringer, Toerless Eckert We continued to deal with the rewrite, absorbing as much text as we could until we ran into technical protocol changes in the middle. We Dealt with many of the questions marked "Qx" below. As the rewrite changed how the protocol was presented, back to how it was before -04, and we had just rewritten it to be different the rest of the changes were not accepted. Q1: Is there any statement that the MASA can be optional, eg: is it clear what would need to be implemented on pledge and registrar for pledges that do not require a MASA ? " A Registrar MAY be configured to ignore the history of the device but it is RECOMMENDED that this only be configured if hardware assisted NEA [RFC5209] is supported." and 4.2. New Entity security reductions " The Pledge MAY have an operational mode where it skips Voucher validation one time. For example if a physical button is depressed during the bootstrapping operation. This can be useful if the vendor service is unavailable. This behavior SHOULD be available via local configuration or physical presence methods to ensure new entities can always be deployed even when autonomic methods fail. This allows for unsecured imprint. It is RECOMMENDED that this only be available if hardware assisted NEA [RFC5209] is supported." Q2: Is there any statement how a device without an IDevID could be used, pledge/registrar ? 4.3. Registrar security reductions 2. A registrar MAY choose to accept devices that claim a unique identity without the benefit of authenticating that claimed identity. This could occur when the Pledge does not include an X.509 IDevID factory installed credential. New Entities without an X.509 IDevID credential MAY form the Section 3.2 request using the Section 3.3 format to ensure the Pledge's serial number information is provided to the Registar (this includes the IDevIDAuthorityKeyIdentifier value which would be statically configured on the Pledge). The Pledge MAY refuse to provide a TLS client certificate (as one is not available). The Pledge SHOULD support HTTP-based or certificate-less TLS authentication as described in EST RFC7030 section 3.3.2. A Registrar MUST NOT accept unauthenticated New Entities unless it has been configured to do so by an administrator that has verified that only expected new entities can communicate with a Registrar (presumably via a physically secured perimeter). Q3: Is there a list of assignments needed ? Page 13: id-mod-MASAURLExtn2016 - who assigns this ? 5. IANA Considerations 5.1. PKIX Registry This document requests a number for id-mod-MASAURLExtn2016(TBD) from the pkix(7) id-mod(0) Registry. [[EDNOTE: fix names]] This document requests a number from the id-pe registry for id-pe- masa-url. XXX --------------------------------- N2: "storing an X.509 root certificate". Does this need to be a "root" certificate ? Consider the most likely simple enterprise or SP deployment of BRSKI. Organization has some root-CA. for the purpose of a particular ANI, a sub-CA is created, which becomes the assigning CA that the registrar uses. The root-CA itself is likely never online except when both Data Centers with the asigning CAs burn down. In these environments, it is not suffficient to only store on the pledge the root-CA, because that root-CA will also assign other subCA that create certificates, and those certificates would not be valid for our ANI. So, the pledge could either just store the assigning-CA, which becomes a virtual root CA, and if it burns down the ANI is frozen (no new pledges possible, re-enroll whole ANI with new CA), or the pledges need to store the CA-chain with root-CA and assigning CA. WHich is the best solution because it allows revocation/renewal of assigning CA in desaster cases. I did not modify any text, but i am worried about this problem for actual deployments so i would like to make sure we have documented an actual working solution. Agreed: Remove the word "root". TBD: Move example of root CA and assigning CA into voucher document The current text of the voucher document is (description of the relevant field in the yang module): leaf-list pinned-domain-cert { type binary; min-elements 1; description "An X.509 v3 certificate structure as specified by RFC 5280, Section 4 encoded using the ASN.1 distinguished encoding rules (DER), as specified in ITU-T X.690. This certificate is used by a pledge to trust a public key infrastructure, in order to verify a domain certificate. In BRSKI terms: "in order to verify that the registrar is a member of the domain by verifying it has a certificate that can be verified using pinned-domain-cert". In BRSKI -06 it indicates: "The maximum lifetime of the voucher issued SHOULD NOT exceed the lifetime of the Registrar's revocation validation (for example if the Registrar revocation status is indicated in a CRL that is valid for two weeks then that is an appropriate lifetime for the voucher)." I think this is ok. The voucher document doesn't include this because it is a MASA behavior discussion. -------------------------------- N3: The intro says "and local access control lists. The Pledge actions"... What "and local access control lists" does this talk about ? If nobody knows, maybe delete ? Suggest: (eg: whitelist or blacklist on registrar). * * - lists. The Pledge actions derive from a cryptographically protected * + lists (administratively defined white or black lists). The Pledge actions derive from a cryptographically protected * -------------------------------- N4: I think the "Other Bootstrapping Approaches" is also a level of brackground information that hurts the "ease of digestion" flow for the reader, so i have moved it into an appendix and left a breadcrump in the intro section. Otherwise unchanged. Not clear if we want to accept this change at all. MCR made it less destructive by moving it to the last appendix in Toerless's suggested XML. Here the git best practices of individual commits (via pull requests) would be helpful. -------------------------------- N5: "In many target applications, the systems involved are ".... this section in secion 1.3 is i think quite crucial and one of the biggest benefits of BRSKI and a great reasoning why we have new complex elements like proxy and MASA, but i think it is more suggestive than descriptive and raises more questions than it answers. And even tthat is already divesting the readers attention by being in the beginning of the document. This topic IMHO deserves a more thorough explanation. I have suggested an appendix section "Flexible SKU management" that tries to do this. I think it is appropriate for an appendix, because it seems that to enable this functionality, we would need some more functionality eg: across ACP, in MASA and so on. TODO: Change text to indicate the overall property is an ANIMA feature where both BRSKI and ACP need to collaborate to improbe ove existing bootstraps. -------------------------------- N6: The "Scope of the solution" section is really a discussion about the applicability to constrained environments. This IMHO also is not necessary to be at the top, so i also moved it into an appendix and left a breadcrump in the introduction. Also changed the name to "Applicability to constrained environments" as this is more descriptive of the actual content. This diff shows the text being changed/absorbed: [28]https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-ietf-a nima-bootstrapping-keyinfra-06&url2=https://raw.githubusercontent.com/a nima-wg/anima-bootstrap/toerless_review_20170530/dtbootstrap-anima-keyi nfra.txt at end of 2017-06-02: [29]https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-ietf-a nima-bootstrapping-keyinfra-06&url2=https://raw.githubusercontent.com/a nima-wg/anima-bootstrap/toerless_review_20170530/dtbootstrap-anima-keyi nfra.txt at the end of 2017-06-06: [30]https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw. githubusercontent.com/anima-wg/anima-bootstrap/toerless_review_20170530 /dtbootstrap-anima-keyinfra.txt&url2=https://raw.githubusercontent.com/ anima-wg/anima-bootstrap/toerless_review_section3_20160606/dtbootstrap- anima-keyinfra.txt [31]https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-ietf-a nima-bootstrapping-keyinfra-06&url2=https://raw.githubusercontent.com/a nima-wg/anima-bootstrap/toerless_review_section3_20160606/dtbootstrap-a nima-keyinfra.txt * Pushed voucher document to address last call comments. post-IETF99 ACTION: max to write up description of proposed voucher and BRSKI changes to WGLC thread. * - discussion about proximity * BRSKI will import the YANG voucher model, and will refine it to produce a voucherrequest. Will use "deviation", not refine. [see [39]https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-13 ] ACTION: Kent to produce some suggested text for the 'voucher request' so we can evaluate * We believe that the VR being signed by the same identity as the TLS Client Certificate. * The MASA verifies that the Registrar making the claim is the same registrar that the pledge sees. This ensures that the asokan etc attack is not occuring. It is not a freshness check. * What is verified is: The pledge and the MASA are seeing the same registrar. * ACTION: mcr to write up concern for security considerations, and to explain why the above solves the problem. * Added text ref RFC4941 temporary addresses (s3.3): * Found final resolution for Content-Type in Auguest, will be application/pkcs7-mime; smime-type=voucher (voucher is new definition for IANA) see https://www.iana.org/assignments/media-type-sub-parameters/media-type-sub-parameters.xhtml OPEN QUESTION: do what do we say about the 'content-transfer-encoding'? Content-Transfer-Encoding: base64 smime-type is originally defined in RFC3851 but the more recent reference is RFC5751, RFC7030, 3851 etc. But RFC7114 defines the IANA registry. For unsigned vouchers, we discussed if we should be using application/json, or something else. We concluded that we'd use application/json. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmM9aYACgkQgItw+93Q 3WWQIgf9GsEFWYMH8pqtDuv3Xu7Cf62i0hsblttUi/zi25/KMtg3+CDlRbk40Fwr ZsvIertpohyb+4yW8yOzYBiuiyd0YKdRFhr5Tjn4CHAWrZ7F0r+RrfXNP4AjPdGY Id4jaidkJ1SqRAVNbwqQwm1QuqJ8sq7cvAefE+tPQosfo9Lr1jB5h3KBHAlyMVDP C60k2hYsl2nP8MP/JLe+J8ss/oMakLVUhNIn1dOS6Sv9lXhoudhf0qzOOWzJR1mA F+48UznGRaPSVOXihlfwa521tNvIu55OfFgANAPcOZYRuKFiWgTiMKEablWB8uX7 ur/o7z7Qy0Gcw6w1A6MkGR90NbguxA== =vhBy -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 11 18:48:08 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A1A1200F3 for ; Fri, 11 Aug 2017 18:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8T_vZs3Iqme for ; Fri, 11 Aug 2017 18:48:05 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F049132195 for ; Fri, 11 Aug 2017 18:48:05 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id v77so21536224pgb.3 for ; Fri, 11 Aug 2017 18:48:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:organization:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=FZkW+lieEp6GjUSanu9qmN9i8KEWSGtr17Sjdh0jAf8=; b=TtguFnjYCetOxsptYGDFhY2xVnQdtuYtADosmHG0AsYWxTP2CSY2IBPqji6W0oinPW C3xXFB+UvYZmKgTZlUxlMD0dXc/AReIaKO8dh/JpFqWUNaz6P0igLqASfKPVsLWtwPmC V8gQsMopxIhBSq1vMF+9/5/0onS8As8ICoKPmkg40008vNWvvOLQWYxtqtJW/+k/HHrD +vXexVbeVvXfEZxAryh6Yn1DnTVJWne5tOapi6NBatwhKz0/NpP7yWOMyclxu2euinjM ipKZHPf1mfizD9FrEXMcLWpu7KFpYKi5hGtjRxldF8spdEd0907R6kw+ZQWl3yulAH7z MFMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:organization:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=FZkW+lieEp6GjUSanu9qmN9i8KEWSGtr17Sjdh0jAf8=; b=hMu+IsbJOpABW+QxKB6urXhwaCGjsg1A0XLMpT1i3WNoRNWFbtJhXkMUGJFrCMlPx2 UM3yXjdZdlC7alyQj7rx0CPGy68M+0NoJUI+XPOqWAYB5VnvWwdt9wEWFJ1YtzuDdJ95 pRj4Pcxkh9AiIUvRB2kivVKNfb6c7EHcXQQUWwsk+43o/Y3rUkhnv+JTnl9hTG1wVBcX vRqfOW4FXPSY301CnO0ePsZWRv72iCNcyl/6rawr3D3gpLQ2Ly34YuaSu2tP1brrw0XC FS45Lpih5EiTHGhl/sFJ3+tElRewpRK+mogH0gMfizny2JP+6xBOYFKvO01Pl8nCGfCp xSVg== X-Gm-Message-State: AHYfb5hxrD1nWW7WJVxAVud4Kg4q2UVPl0Qlm5lBdsSO1OQ0A/58dPWf OoI7qu2BUWSG5o2/ X-Received: by 10.98.57.66 with SMTP id g63mr18346101pfa.5.1502502484667; Fri, 11 Aug 2017 18:48:04 -0700 (PDT) Received: from ?IPv6:2406:e007:521f:1:28cc:dc4c:9703:6781? ([2406:e007:521f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id f74sm4886257pfk.131.2017.08.11.18.48.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Aug 2017 18:48:04 -0700 (PDT) From: Brian E Carpenter To: Anima WG Organization: University of Auckland Message-ID: Date: Sat, 12 Aug 2017 13:48:10 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Message size limit in GRASP - is it a problem? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Aug 2017 01:48:07 -0000 Hi, I assume everyone is aware that GRASP limits its message size to 2000 bytes. In case anybody thinks that could be a problem, I don't think it is. Or at least, it's easily overcome for objectives that might become large. Recently I've coded a pair of demonstration ASAs to check the feasibility of capturing DNS-SD information in an autonomic node, and relaying it to other autonomic nodes via a GRASP objective. That is fairly straightforward, and allows one "smart" ASA to handle the complexities of DNS-SD lookup for any number of dumb client ASAs that don't want to bother with details of the lookup process. In the course of testing this I managed to generate a GRASP message that significantly exceeded the 2000 byte limit set by the GRASP spec. Then I realised that for a negotiation objective, this can easily and reliably be overcome, by fragmenting the reply at ASA level. The process is as follows: - the client ASA opens a GRASP negotiation by requesting a DNS-SD lookup via a GRASP objective. - the "smart" ASA performs the lookup sequence (which involves some parsing of the results) and prepares the value to be returned. It is a sequence of DNS records (as described in RFC6763), which GRASP of course encodes in CBOR for transmission. - if the result will fit in a single GRASP message, it is returned as the objective value in a single GRASP Negotiate message, and we're done. - if the result is too long, it is fragmented, and the first fragment has a marker appended to it (in my test, I simply appended a dummy DNS record 'MORE'). - in that case, the client continues the negotiation (for example, by sending back an objective that contains the value 'ACK') - repeat until done. Coding this added about 25 lines of Python to each ASA. It's reliable because all the transactions run over a TCP connection. Regards Brian From nobody Sat Aug 12 17:26:10 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C769C132406 for ; Sat, 12 Aug 2017 17:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1kbVKlE44MW for ; Sat, 12 Aug 2017 17:26:06 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DAF51323FD for ; Sat, 12 Aug 2017 17:26:06 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 91FFDE223 for ; Sat, 12 Aug 2017 20:28:32 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C8465806BA for ; Sat, 12 Aug 2017 20:26:05 -0400 (EDT) From: Michael Richardson To: anima X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] does BRSKI need three-way handshake before MASA commits? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Aug 2017 00:26:09 -0000 --=-=-= Content-Type: text/plain Max, in the process of writing up the security considerations for freshness of voucher requests, which is here, and attached below. https://github.com/anima-wg/anima-bootstrap/commit/17724acb3a1810c09f113eb652cb66e274f9c640#diff-ea76ed1df307bcbcc86a5d34c5547032 It occurs to me that the problem outlined in the last paragraph, that the MASA winds up with a voucher issued that was never successfully used, could be solved if: a) the Voucher Status in section 3.5 was a signed artifact! b) that it contained some freshness present in the voucher. c) that a voucher that was not confirmed to have been used prior to expiring would be marked as such. I think that this *could* be added as an extension in the future. If we were going to say something today, it would be that successful Status Telemetry SHOULD be relayed by the Registrar to the MASA, (?even if the Registrar does not understand the contents?) 6.1. Freshness in Voucher Requests + + A concern has been raised that the voucher request produced by the + Pledge should contain some content (a nonce) from the Registrar and/ + or MASA in order for those actors to verify that the voucher request + is fresh. + + There are a number of operational problems with getting a nonce from + the MASA to the pledge. It is somewhat easier to collect a random + value from the Registrar, but as the Registrar is not yet at this + point validated, such a Registrar nonce has little value. There are + privacy and logistical challenges to the process, so if such a thing + were to be considered, it would have to provide some clear value. + This section examines the impacts of not having a fresh voucher + request from the pledge. + + Consider the case where a MITM is between the Pledge and the + legitimate Registrar. This fake Registrar will obtain from the + Pledge a signed voucher request. The pledge will have accepted the + fake Registrar as legitimate up to this point as the EST connection + will still be at the provisional state. + + The fake Registrar (Ra) can communicate the signed voucher request to + a collaborator, perhaps located in another network, and communicate + with a some Registrar (Rb) to obtain a voucher signed by the MASA. + Assuming that the MASA accepts the voucher request (either because + this is the legitimate Registrar according to supply chain + information, or because the MASA is in audit-log only mode), then a + voucher linking the pledge to the Registrar Rb. + + Such a voucher, when passed back to the Pledge, would link the pledge + to Registrar Rb, and would permit the Pledge to attempt to end the + provisional state. The pledge will then attempt to validate the + pinned-domain-certificate linked to in the voucher. That certificate + will point at Registrar Rb. But the pledge will have a provisional + TLS/EST connection to the MITM Registrar Ra. The pledge will fail + the process, close the provisional connection unsuccessfully, and + restart. + + The conclusion is that lack of MASA provided freshness does cause a + pledge to join the wrong network. + + There is an additional concern when the MASA is in audit-log only + mode. When the unfortunate pledge above does connect to directly to + a legitimate Registrar, that Registrar will discover that a voucher + was previously issued. If the legimate Registrar is actually Rb, + then all is well. Otherwise, there is a fault as the Registrar has + to consider whether or not to accept a previously owned device. This + may involve consulting a human. If a large number of devices are + attacked in such a way, a human might just accept all the devices in + a batch mode, permitting an actually compromise device through. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmPnJ0ACgkQgItw+93Q 3WW/LQgAqGYID36NOeKK33h4ILSrDB2KXtszBe+51ijgVQpQUqu2RmK4HbnCs7HY xHTyOXMqJR9ZGY39xMtdxEnoRdIgXFDft9M56+/0P6cQoJ4anFkgbjjTtkR+S5bR r+x+gVkdHs9OQSJA9doIcPst4Z9Wi1byiGfFDJG4o2XjLKReAaxfyhQxnfYz0g9n 2xBuP2K7Ckz3uM+/r18mAsPovdKWFsBKLr96FEaDW/rGQf+by6TplTbnupnEaXH6 pHMXjU7FKVGZhX/J7/7DrIKjchu2CAh08lZeEDZVNFJWXX/dt+JoxICZIFHs+/bd 5fiOASgdaBia3mNSKgk/TwhCXkutvw== =j6lx -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Aug 13 21:47:34 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0365F124B0A for ; Sun, 13 Aug 2017 21:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHzfAwVo8VAM for ; Sun, 13 Aug 2017 21:47:30 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89CC81241F5 for ; Sun, 13 Aug 2017 21:47:30 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 9A92C58C4B1; Mon, 14 Aug 2017 06:47:23 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 7D1C4B0C898; Mon, 14 Aug 2017 06:47:23 +0200 (CEST) Date: Mon, 14 Aug 2017 06:47:23 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: Anima WG Message-ID: <20170814044723.GA31383@faui40p.informatik.uni-erlangen.de> References: <9fa5abbe-368d-1433-2ea8-f6622fd22573@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9fa5abbe-368d-1433-2ea8-f6622fd22573@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] The open issue in draft-ietf-anima-prefix-management X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 04:47:32 -0000 Reaffirming my preference for 1. On Fri, Jul 21, 2017 at 05:17:21PM +1200, Brian E Carpenter wrote: > As a reminder, we have two options in the draft for adding support > of IPv4 prefix management: > > 1. Add a version number flag to the objective > 2. Add a second objective specific to IPv4 > > So far the preferences I have heard (including my own) are for option 1, > because it's simpler to implement. I think the authors will go that way for the > next version, but of course it's a WG choice. Comments please! > > Quick link: > https://tools.ietf.org/html/draft-ietf-anima-prefix-management-04#section-5.2 > > Regards > Brian > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Sun Aug 13 22:11:20 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C97C124217 for ; Sun, 13 Aug 2017 22:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XPid6oJ9NBY for ; Sun, 13 Aug 2017 22:11:15 -0700 (PDT) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::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 5790812008A for ; Sun, 13 Aug 2017 22:11:15 -0700 (PDT) Received: by mail-pg0-x22d.google.com with SMTP id v77so39643388pgb.3 for ; Sun, 13 Aug 2017 22:11:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=LM8nXUUNTL7AHDdcrUc3Xno3Q0FZK23Mysoy5vE10Os=; b=SGXlEid8mcOpDSYQP1ILAHdvXck9Uk+xvqJJNUyHv8yUXl2DW3W8zrIV1XZjJRTAjJ tyiASHg/CMGzHZTEMCF5XBSvPRZe6giYqSeLJe4MZ2AGqnLXmFNUwq9XMC5hM8Gj/hYI lbVEgagSkookTPcizP5yJkpXAyweqb88K7n30WI/J+9xgACjDZIopn6oHYCa14I0W+Os jPj4NH2pezc9Fc9cKQt3PAk3hyFff2D23m5I7qbIJFHFCbMpAx/DQLmfEMI6M9y36jPL ZMUMqBQNvP5e5/N1lOmaC7QpnWLfBzijMH2yPxoHZCE6W5E+v7nUfVN6dybpf6Ndus/r J+dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=LM8nXUUNTL7AHDdcrUc3Xno3Q0FZK23Mysoy5vE10Os=; b=IW7Dgvv00CtQIBH5yYK5vK3/OlZN13nTy+4jVoI0LLW3YAZ2tT9pJlfOaN83dgBst6 NRoVd1bR3PlA9hsw2rL9ycL3PToMFj7BVUodrrjERktsKGKQEGFVcaVwABUFPpESSzcV VJvZK0MWNGEAoI70kf6PYn400DcNwyZyPpxsSOCQueHqZmGcIWLDkca9JXP8RKk1VwCs 1IdrKQN8PT3TC4LDuNtInfPjuKKo1FLxaB4cpCGF69GHVvnUY8JmEyydUsSi1XrGmlxD 1Awow8cM6gg8r/eZ6fFOPfImJ0UOUTe5guAiJgLwv+5/6f5SQ6WMad+IqQEDmz1Bbmd9 CSEQ== X-Gm-Message-State: AHYfb5hwFYmOjvB+f/bjBBnF64TEQQ6Tb4VtgakHZ/I9txYJWNi3Ltsb rh2IvA7crBGXCpgc X-Received: by 10.84.141.129 with SMTP id 1mr26463350plv.375.1502687474566; Sun, 13 Aug 2017 22:11:14 -0700 (PDT) Received: from ?IPv6:2406:e007:521f:1:28cc:dc4c:9703:6781? ([2406:e007:521f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id r62sm11673651pfr.111.2017.08.13.22.11.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Aug 2017 22:11:14 -0700 (PDT) To: Toerless Eckert Cc: Anima WG References: <9fa5abbe-368d-1433-2ea8-f6622fd22573@gmail.com> <20170814044723.GA31383@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: <3c57a157-72a3-4f34-8a4d-f8e585f586c6@gmail.com> Date: Mon, 14 Aug 2017 17:11:09 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170814044723.GA31383@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] The open issue in draft-ietf-anima-prefix-management X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 05:11:18 -0000 Thanks Toerless. I'm not hearing any disagreement so that will be in the next version. With your WG Chair hat on, are there any other changes required? Regards Brian On 14/08/2017 16:47, Toerless Eckert wrote: > Reaffirming my preference for 1. > > On Fri, Jul 21, 2017 at 05:17:21PM +1200, Brian E Carpenter wrote: >> As a reminder, we have two options in the draft for adding support >> of IPv4 prefix management: >> >> 1. Add a version number flag to the objective >> 2. Add a second objective specific to IPv4 >> >> So far the preferences I have heard (including my own) are for option 1, >> because it's simpler to implement. I think the authors will go that way for the >> next version, but of course it's a WG choice. Comments please! >> >> Quick link: >> https://tools.ietf.org/html/draft-ietf-anima-prefix-management-04#section-5.2 >> >> Regards >> Brian >> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > From nobody Sun Aug 13 23:08:48 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B712126BF0 for ; Sun, 13 Aug 2017 23:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5f1znO81HdGf for ; Sun, 13 Aug 2017 23:08:44 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36EF11200B9 for ; Sun, 13 Aug 2017 23:08:44 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 218A558C4B1; Mon, 14 Aug 2017 08:08:40 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 089A3B0C89F; Mon, 14 Aug 2017 08:08:39 +0200 (CEST) Date: Mon, 14 Aug 2017 08:08:39 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: Anima WG Message-ID: <20170814060839.GA765@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: [Anima] draft-ietf-anima-prefix-management: normaive/informational X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 06:08:47 -0000 Only the references. Some are outdated. BRSKI to me is not normative. Neither is I-D.ietf-core-yang-cbor. ACP may or may be normative. I am not quite clear on the rules: IMHO, prefix-management is not a full solution spec which is why it's also informational. rhe spec part of it relates to how to use GRASP, so only GRASP is logically normative to me. But you may have better insights ito how the IESG judges this. Cheers Toerless On Mon, Aug 14, 2017 at 05:11:09PM +1200, Brian E Carpenter wrote: > Thanks Toerless. I'm not hearing any disagreement so that will be > in the next version. With your WG Chair hat on, are there any other > changes required? > > Regards > Brian > > On 14/08/2017 16:47, Toerless Eckert wrote: > > Reaffirming my preference for 1. > > > > On Fri, Jul 21, 2017 at 05:17:21PM +1200, Brian E Carpenter wrote: > >> As a reminder, we have two options in the draft for adding support > >> of IPv4 prefix management: > >> > >> 1. Add a version number flag to the objective > >> 2. Add a second objective specific to IPv4 > >> > >> So far the preferences I have heard (including my own) are for option 1, > >> because it's simpler to implement. I think the authors will go that way for the > >> next version, but of course it's a WG choice. Comments please! > >> > >> Quick link: > >> https://tools.ietf.org/html/draft-ietf-anima-prefix-management-04#section-5.2 > >> > >> Regards > >> Brian > >> > >> > >> _______________________________________________ > >> Anima mailing list > >> Anima@ietf.org > >> https://www.ietf.org/mailman/listinfo/anima > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Mon Aug 14 10:45:38 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB3DF1323C0 for ; Mon, 14 Aug 2017 10:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lkrc91Vbgl5W for ; Mon, 14 Aug 2017 10:45:33 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 B914E1323B6 for ; Mon, 14 Aug 2017 10:45:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id CF52362177 for ; Mon, 14 Aug 2017 13:45:32 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id V4PFyQUav9rf for ; Mon, 14 Aug 2017 13:45:26 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id C6D6062174 for ; Mon, 14 Aug 2017 13:45:25 -0400 (EDT) To: anima@ietf.org From: Robert Moskowitz Message-ID: Date: Mon, 14 Aug 2017 13:44:42 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Anima] creating iDevID certs with openssl X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 17:45:37 -0000 I have just joined this list. So if this is covered in the archives anywhere, my weak search foo did not uncover it... Has anyone created iDevID certs with openssl including subjectAltName with hardwareModuleName? I have been working on this for a few days and have worked out HOW to even get certs to contain SAN, particularly going the csr route. I have learned on the openssl list that HMN is not directly supported and that you have to use othername. Something like [ req_ext ] subjectAltName = otherName:1.3.6.1.5.5.7.8.4;SEQ:hmodname [ hmodname ] hwType = OID:1.2.3.4 # Whatever OID you want. hwSerialNum = FORMAT:HEX,OCT:01020304 # Some hex But I am not sure what exactly to do with hwType and hwSerialNum Are there any extant examples? Currently there is no way to feed any SAN value in at the command like 'openssl req'. It has to go into the config file, so once I work out WHAT to but into these fields, I will have to do some kludgly stuff to stuff values into the config then run the command. There are examples of this around for SANs of IP, DNS, etc. BTW, so far I have a simple guide for making a pki of ECDSA certs using openssl. I would be willing to share what I have done todate. The 802.1AR cert section is understandably incomplete... Bob From nobody Mon Aug 14 12:03:21 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C931323D7 for ; Mon, 14 Aug 2017 12:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYR_24WhxheL for ; Mon, 14 Aug 2017 12:03:18 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 BDB15132399 for ; Mon, 14 Aug 2017 12:03:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id D903362170 for ; Mon, 14 Aug 2017 15:03:17 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id r2oqZdm6PpTq for ; Mon, 14 Aug 2017 15:03:13 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id BB9B06216C for ; Mon, 14 Aug 2017 15:03:12 -0400 (EDT) From: Robert Moskowitz To: anima@ietf.org References: Message-ID: <3a5adc64-1737-9ecc-5c13-b310b48c2ba0@htt-consult.com> Date: Mon, 14 Aug 2017 15:03:09 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Anima] creating iDevID certs with openssl X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 19:03:20 -0000 Making some progress. On 08/14/2017 01:44 PM, Robert Moskowitz wrote: > I have just joined this list. So if this is covered in the archives > anywhere, my weak search foo did not uncover it... > > Has anyone created iDevID certs with openssl including subjectAltName > with hardwareModuleName? > > I have been working on this for a few days and have worked out HOW to > even get certs to contain SAN, particularly going the csr route. I > have learned on the openssl list that HMN is not directly supported > and that you have to use othername. Something like > > [ req_ext ] > subjectAltName = otherName:1.3.6.1.5.5.7.8.4;SEQ:hmodname > > [ hmodname ] > hwType = OID:1.2.3.4 # Whatever OID you want. > hwSerialNum = FORMAT:HEX,OCT:01020304 # Some hex This produces a subjectAltName content of: 0:d=0 hl=2 l= 27 cons: SEQUENCE 2:d=1 hl=2 l= 25 cons: cont [ 0 ] 4:d=2 hl=2 l= 8 prim: OBJECT :1.3.6.1.5.5.7.8.4 14:d=2 hl=2 l= 13 cons: cont [ 0 ] 16:d=3 hl=2 l= 11 cons: SEQUENCE 18:d=4 hl=2 l= 3 prim: OBJECT :1.2.3.4 23:d=4 hl=2 l= 4 prim: OCTET STRING [HEX DUMP]:01020304 I suspect that hwtype is a full vendor OID for registering this device. Say my company, HTT Consulting makes sensor widgets. The OID for that could be: 1.3.6.1.4.1.6715.10.1 (where 10 is HTT's devices and 1 is the sensor widget). > But I am not sure what exactly to do with hwType and hwSerialNum > > Are there any extant examples? So googling around for examples and not finding any. But then my search foo has always been weak. > > Currently there is no way to feed any SAN value in at the command like > 'openssl req'. It has to go into the config file, so once I work out > WHAT to but into these fields, I will have to do some kludgly stuff to > stuff values into the config then run the command. There are examples > of this around for SANs of IP, DNS, etc. > > BTW, so far I have a simple guide for making a pki of ECDSA certs > using openssl. I would be willing to share what I have done todate. > The 802.1AR cert section is understandably incomplete... > > Bob From nobody Mon Aug 14 12:53:17 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6453813240F for ; Mon, 14 Aug 2017 12:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ViPiVuOOYoRp for ; Mon, 14 Aug 2017 12:53:14 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 613ED1323D4 for ; Mon, 14 Aug 2017 12:53:14 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id i12so2619232pgr.3 for ; Mon, 14 Aug 2017 12:53:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=JQueGE0U21Z9+r96bZ65PBQTwvdAxonfEMFvyBxfCBM=; b=ubeVJE+Wjfip+cRYdOjECcIzPOTXEJ5KgFDYwgQahEJNGkKrnV1/YHBwLiX6gsl7H9 2buttgO0D+6bzwUbXqWnz1cM9ZDFdsSRub7SR+D5z+V2TaENhq/Z74MJqw9lRQ3cQSq5 O7mazXwfWQyRdf+ocoC02I2UiqE3kyuDDxn9RZlAAgG/lTqGpLIqg4GtjsuYBpNwSCyn tcFPw300/N0T9ywvfSR9nLLTRnMBBhLsjK/M8nzBJyslmdvFWNRsMsi9+u1kiDcTHWuR lUOj/Mu5tCd4XivvvXAWC/FQRjJx1X3xNhNx10PDfMHCLulxFNry4Rc02h9+gGB1omNy XC+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=JQueGE0U21Z9+r96bZ65PBQTwvdAxonfEMFvyBxfCBM=; b=AQRKzdVJ9ZMvTFuTW0XfrnlK+gHkbFF4Y/nFOZbZlv1mODdUlg29GWX5O1b5TtWBfN fIR22VcqdmDSiGpfI957QOqRKkRbB1Q4nu9ARphqeOrmCQumxqd9+dJ4Ao4KRVP6AIXh Z58jF+MROda+4OlN4Z9bAguutfUvzy41KtAY2u5F828dJSKXt6iua/cZKeAry5Ezzh4/ 99nQcvqBtEj6XCuRFD1Q5I0AGeLS0dGKR1N4ajqmxywTrhJ9yHRRZESGjj5VDmpv8f9h sjvcbP1fr4n8GBcLdDeNr8PbXLHT3CuLWnf2lqF1Hztm+R63LLqchKlBwMtkOcOvK94S aThw== X-Gm-Message-State: AHYfb5hdBOlVCZQpi9Poppmo6/LJvAbu2SPgjVEFu3MZFLvsHsVniLgF 6LSK1azoCCAA9HLJ X-Received: by 10.84.142.131 with SMTP id 3mr29254524plx.130.1502740393761; Mon, 14 Aug 2017 12:53:13 -0700 (PDT) Received: from ?IPv6:2406:e007:521f:1:28cc:dc4c:9703:6781? ([2406:e007:521f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id w24sm15273591pfk.183.2017.08.14.12.53.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Aug 2017 12:53:13 -0700 (PDT) To: Toerless Eckert Cc: Anima WG References: <20170814060839.GA765@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: <45abfa82-5b29-694b-a0a7-c58587d5f167@gmail.com> Date: Tue, 15 Aug 2017 07:53:09 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170814060839.GA765@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] draft-ietf-anima-prefix-management: normaive/informational X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 19:53:16 -0000 On 14/08/2017 18:08, Toerless Eckert wrote: > Only the references. Some are outdated. > > BRSKI to me is not normative. Neither is I-D.ietf-core-yang-cbor. > > ACP may or may be normative. I am not quite clear on the rules: The rules are not so important for Informational RFCs anyway. > IMHO, prefix-management is not a full solution spec which is why it's also informational. > rhe spec part of it relates to how to use GRASP, so only GRASP is logically normative to > me. But you may have better insights ito how the IESG judges this. No, I think you're right. Seeing no comments from the co-authors, I will push a version with those changes today. Regards Brian > > Cheers > Toerless > > On Mon, Aug 14, 2017 at 05:11:09PM +1200, Brian E Carpenter wrote: >> Thanks Toerless. I'm not hearing any disagreement so that will be >> in the next version. With your WG Chair hat on, are there any other >> changes required? >> >> Regards >> Brian >> >> On 14/08/2017 16:47, Toerless Eckert wrote: >>> Reaffirming my preference for 1. >>> >>> On Fri, Jul 21, 2017 at 05:17:21PM +1200, Brian E Carpenter wrote: >>>> As a reminder, we have two options in the draft for adding support >>>> of IPv4 prefix management: >>>> >>>> 1. Add a version number flag to the objective >>>> 2. Add a second objective specific to IPv4 >>>> >>>> So far the preferences I have heard (including my own) are for option 1, >>>> because it's simpler to implement. I think the authors will go that way for the >>>> next version, but of course it's a WG choice. Comments please! >>>> >>>> Quick link: >>>> https://tools.ietf.org/html/draft-ietf-anima-prefix-management-04#section-5.2 >>>> >>>> Regards >>>> Brian >>>> >>>> >>>> _______________________________________________ >>>> Anima mailing list >>>> Anima@ietf.org >>>> https://www.ietf.org/mailman/listinfo/anima >>> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > From nobody Mon Aug 14 13:32:49 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 784B2126E64; Mon, 14 Aug 2017 13:32:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150274276246.10469.12071253868944031521@ietfa.amsl.com> Date: Mon, 14 Aug 2017 13:32:42 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-prefix-management-05.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 20:32:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : Autonomic IPv6 Edge Prefix Management in Large-scale Networks Authors : Sheng Jiang Zongpeng Du Brian Carpenter Qiong Sun Filename : draft-ietf-anima-prefix-management-05.txt Pages : 21 Date : 2017-08-14 Abstract: This document describes an autonomic solution for IPv6 prefix management at the edge of large-scale ISP networks, with an extension to support IPv4 prefixes. An important purpose of the document is to use it for validation of the design of various components of the autonomic networking infrastructure. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-prefix-management/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-prefix-management-05 https://datatracker.ietf.org/doc/html/draft-ietf-anima-prefix-management-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-prefix-management-05 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 Wed Aug 16 09:43:21 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0AE132351 for ; Wed, 16 Aug 2017 09:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, 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=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 RDtG47aDqjfA for ; Wed, 16 Aug 2017 09:43:17 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0092.outbound.protection.outlook.com [104.47.40.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19A85132332 for ; Wed, 16 Aug 2017 09:43:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VXYnNaP+aVrJFUjTqhVVNLcJ42kdXJqxZMMoXhHW+AQ=; b=M6uDh+WbKMViK8Ry64vCDT/pWhYB8gvyti440AbPUs9cEEEEnFLq38PGnbr8YGFlWEvj6LNCuOBfuhgqY4pv4ze1wdRiEKByOaElOrAQ/7u85tprD0PrEriKhK0tBeOSOxsQAq9TEqe0in9t0jUpinNaa4ImAgsQIyYg2q+vHss= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1348.namprd05.prod.outlook.com (10.160.183.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1362.12; Wed, 16 Aug 2017 16:43:15 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.1362.018; Wed, 16 Aug 2017 16:43:15 +0000 From: Kent Watsen To: Robert Moskowitz , "anima@ietf.org" Thread-Topic: [Anima] creating iDevID certs with openssl Thread-Index: AQHTFSUlAUd6DuxmKkeSAjMNgXmwoaKENaWAgAK6hYA= Date: Wed, 16 Aug 2017 16:43:15 +0000 Message-ID: <31E4D893-7438-4EF4-85DF-4F47D70FF3CF@juniper.net> References: <3a5adc64-1737-9ecc-5c13-b310b48c2ba0@htt-consult.com> In-Reply-To: <3a5adc64-1737-9ecc-5c13-b310b48c2ba0@htt-consult.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-originating-ip: [66.129.241.13] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1348; 6:R98VWNEkrKriQ2COWlGJga4aJvISfYIZ0HvOgl4ZF2DuiSwP+97WROi/oBXY2SVSGlLUTElz4E/TJXqCRQMNjgegsDR0l0GLHtIBlQhnp8gxbSQtRsTeXJi2+u+4i1KuQXSvbb1lL1GLMxyFnjIZc0CDxnm9sa3zTt87ueeZF+16Rk5ZiM8LEXkcG9guRy1tKZVGqqseNarFPhtl+bnCfb+57haNMMPGRC+TSjbQruXWTVfvfAu7Rto9SilwsNJk4bwOJwx1z1ZRCZVxkmRCxDawpieyZUbOCd+g03ueQihuSJD8WNBdXcKVAgWP8joXmEosfJXKptJ1HjPFr2G7Gw==; 5:GvmO0tQ5pf6mrXS0kUgBqdzXgebWTne4ZROH/GoS3jEmuwNSjNx8hC1Ks+Z5MPGf7sPzx+ZC9RS2j0k9ahMsIJww78W23X748QcWZB4xXBM4zAcYPMp4uxdjjr6O8z23b+pk9F7kN8jRGdsj/pRFkw==; 24:cHJZELHYeBMGoESG6qKLhhlTfXdN9O1PsPTdHMVTGLwisab4UtkqsGx9moOvUlltLL9WthFndliYhppm5h1P6FCwmi006MHdwQIBWJHmgPs=; 7:czE6D4Vqu6wo45HxeXtZLsFGmrXGqFK8l7Xa1roHRwgyq9TPVa7oc9+x6d478/lGZrFOr/27DQ3eMwmhwZg+AtTeR8fESq2gOtk5t/E4zec0ZPuAuBRzCHq96K7aR89jHTaWkO0pYZA29DuTSkVvAqpDfTzqVr8iyS4OG0HufAF4CvQGsJquhW4DaUI+Vv9HU6a3esgy9/Tq+IoN0MVUtS0a3eZOjQeZScZAfdPz9Io= x-ms-office365-filtering-correlation-id: ac5372a1-761a-4d24-e328-08d4e4c5e439 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1348; x-ms-traffictypediagnostic: BN3PR0501MB1348: x-exchange-antispam-report-test: UriScan:(166708455590820); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(20161123564025)(20161123555025)(20161123562025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1348; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1348; x-forefront-prvs: 0401647B7F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(189002)(377454003)(24454002)(199003)(189998001)(33656002)(36756003)(97736004)(478600001)(7736002)(68736007)(4001350100001)(305945005)(25786009)(82746002)(2906002)(6246003)(2501003)(53546010)(86362001)(83716003)(6116002)(83506001)(102836003)(3846002)(6436002)(2950100002)(101416001)(53936002)(50986999)(6512007)(6506006)(966005)(54356999)(76176999)(2900100001)(3280700002)(106356001)(6486002)(5660300001)(6306002)(66066001)(14454004)(99286003)(229853002)(81156014)(3660700001)(8936002)(81166006)(77096006)(105586002)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1348; H:BN3PR0501MB1442.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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <3BACA63EB05C2E45BA263DC26932170F@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2017 16:43:15.3365 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1348 Archived-At: Subject: Re: [Anima] creating iDevID certs with openssl X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 16:43:20 -0000 SGkgQm9iLA0KDQpJJ20gd2F0Y2hpbmcgdGhpcyB0aHJlYWQgd2l0aCBpbnRlcmVzdC4gIE15IHRh a2Ugb24gdGhpcyBbMV0gaXMgYSBsaXR0bGUNCmRpZmZlcmVudCB0aGFuIHlvdXJzLCBidXQgSSB3 YXMganVzdCBwcm90b3R5cGluZyBhIHJvdWdoIHNvbHV0aW9uLCBJDQpuZXZlciB0b29rIGl0IHRv IGNvbXBsZXRpb24uLi4NCg0KWzFdIGh0dHBzOi8vZ2l0aHViLmNvbS9uZXRjb25mLXdnL3plcm8t dG91Y2gvYmxvYi9tYXN0ZXIvb3BlbnNzbC10ZXN0L3ZlbmRvci9pZGV2aWQtY2VydGlmaWNhdGUt cGtpL2ludGVybWVkaWF0ZS1jYS9vcGVuc3NsLmNuZiNMNTUNCg0KS2VudA0KDQotLQ0KDQpNYWtp bmcgc29tZSBwcm9ncmVzcy4NCg0KDQpPbiAwOC8xNC8yMDE3IDAxOjQ0IFBNLCBSb2JlcnQgTW9z a293aXR6IHdyb3RlOg0KPiBJIGhhdmUganVzdCBqb2luZWQgdGhpcyBsaXN0LiAgU28gaWYgdGhp cyBpcyBjb3ZlcmVkIGluIHRoZSBhcmNoaXZlcyANCj4gYW55d2hlcmUsIG15IHdlYWsgc2VhcmNo IGZvbyBkaWQgbm90IHVuY292ZXIgaXQuLi4NCj4NCj4gSGFzIGFueW9uZSBjcmVhdGVkIGlEZXZJ RCBjZXJ0cyB3aXRoIG9wZW5zc2wgaW5jbHVkaW5nIHN1YmplY3RBbHROYW1lIA0KPiB3aXRoIGhh cmR3YXJlTW9kdWxlTmFtZT8NCj4NCj4gSSBoYXZlIGJlZW4gd29ya2luZyBvbiB0aGlzIGZvciBh IGZldyBkYXlzIGFuZCBoYXZlIHdvcmtlZCBvdXQgSE9XIHRvIA0KPiBldmVuIGdldCBjZXJ0cyB0 byBjb250YWluIFNBTiwgcGFydGljdWxhcmx5IGdvaW5nIHRoZSBjc3Igcm91dGUuIEkgDQo+IGhh dmUgbGVhcm5lZCBvbiB0aGUgb3BlbnNzbCBsaXN0IHRoYXQgSE1OIGlzIG5vdCBkaXJlY3RseSBz dXBwb3J0ZWQgDQo+IGFuZCB0aGF0IHlvdSBoYXZlIHRvIHVzZSBvdGhlcm5hbWUuICBTb21ldGhp bmcgbGlrZQ0KPg0KPiBbIHJlcV9leHQgXQ0KPiBzdWJqZWN0QWx0TmFtZSA9IG90aGVyTmFtZTox LjMuNi4xLjUuNS43LjguNDtTRVE6aG1vZG5hbWUNCj4NCj4gWyBobW9kbmFtZSBdDQo+IGh3VHlw ZSA9IE9JRDoxLjIuMy40ICMgV2hhdGV2ZXIgT0lEIHlvdSB3YW50Lg0KPiBod1NlcmlhbE51bSA9 IEZPUk1BVDpIRVgsT0NUOjAxMDIwMzA0ICMgU29tZSBoZXgNCg0KVGhpcyBwcm9kdWNlcyBhIHN1 YmplY3RBbHROYW1lIGNvbnRlbnQgb2Y6DQoNCiAgICAgMDpkPTAgIGhsPTIgbD0gIDI3IGNvbnM6 IFNFUVVFTkNFDQogICAgIDI6ZD0xICBobD0yIGw9ICAyNSBjb25zOiAgY29udCBbIDAgXQ0KICAg ICA0OmQ9MiAgaGw9MiBsPSAgIDggcHJpbTogICBPQkpFQ1QgICAgICAgICAgICA6MS4zLjYuMS41 LjUuNy44LjQNCiAgICAxNDpkPTIgIGhsPTIgbD0gIDEzIGNvbnM6ICAgY29udCBbIDAgXQ0KICAg IDE2OmQ9MyAgaGw9MiBsPSAgMTEgY29uczogICAgU0VRVUVOQ0UNCiAgICAxODpkPTQgIGhsPTIg bD0gICAzIHByaW06ICAgICBPQkpFQ1QgICAgICAgICAgICA6MS4yLjMuNA0KICAgIDIzOmQ9NCAg aGw9MiBsPSAgIDQgcHJpbTogICAgIE9DVEVUIFNUUklORyAgICAgIFtIRVggRFVNUF06MDEwMjAz MDQNCg0KDQpJIHN1c3BlY3QgdGhhdCBod3R5cGUgaXMgYSBmdWxsIHZlbmRvciBPSUQgZm9yIHJl Z2lzdGVyaW5nIHRoaXMgZGV2aWNlLiAgDQpTYXkgbXkgY29tcGFueSwgSFRUIENvbnN1bHRpbmcg bWFrZXMgc2Vuc29yIHdpZGdldHMuICBUaGUgT0lEIGZvciB0aGF0IA0KY291bGQgYmU6DQoNCjEu My42LjEuNC4xLjY3MTUuMTAuMSAod2hlcmUgMTAgaXMgSFRUJ3MgZGV2aWNlcyBhbmQgMSBpcyB0 aGUgc2Vuc29yIA0Kd2lkZ2V0KS4NCg0KPiBCdXQgSSBhbSBub3Qgc3VyZSB3aGF0IGV4YWN0bHkg dG8gZG8gd2l0aCBod1R5cGUgYW5kIGh3U2VyaWFsTnVtDQo+DQo+IEFyZSB0aGVyZSBhbnkgZXh0 YW50IGV4YW1wbGVzPw0KDQpTbyBnb29nbGluZyBhcm91bmQgZm9yIGV4YW1wbGVzIGFuZCBub3Qg ZmluZGluZyBhbnkuICBCdXQgdGhlbiBteSBzZWFyY2ggDQpmb28gaGFzIGFsd2F5cyBiZWVuIHdl YWsuDQoNCj4NCj4gQ3VycmVudGx5IHRoZXJlIGlzIG5vIHdheSB0byBmZWVkIGFueSBTQU4gdmFs dWUgaW4gYXQgdGhlIGNvbW1hbmQgbGlrZSANCj4gJ29wZW5zc2wgcmVxJy4gIEl0IGhhcyB0byBn byBpbnRvIHRoZSBjb25maWcgZmlsZSwgc28gb25jZSBJIHdvcmsgb3V0IA0KPiBXSEFUIHRvIGJ1 dCBpbnRvIHRoZXNlIGZpZWxkcywgSSB3aWxsIGhhdmUgdG8gZG8gc29tZSBrbHVkZ2x5IHN0dWZm IHRvIA0KPiBzdHVmZiB2YWx1ZXMgaW50byB0aGUgY29uZmlnIHRoZW4gcnVuIHRoZSBjb21tYW5k LiBUaGVyZSBhcmUgZXhhbXBsZXMgDQo+IG9mIHRoaXMgYXJvdW5kIGZvciBTQU5zIG9mIElQLCBE TlMsIGV0Yy4NCj4NCj4gQlRXLCBzbyBmYXIgSSBoYXZlIGEgc2ltcGxlIGd1aWRlIGZvciBtYWtp bmcgYSBwa2kgb2YgRUNEU0EgY2VydHMgDQo+IHVzaW5nIG9wZW5zc2wuICBJIHdvdWxkIGJlIHdp bGxpbmcgdG8gc2hhcmUgd2hhdCBJIGhhdmUgZG9uZSB0b2RhdGUuICANCj4gVGhlIDgwMi4xQVIg Y2VydCBzZWN0aW9uIGlzIHVuZGVyc3RhbmRhYmx5IGluY29tcGxldGUuLi4NCj4NCj4gQm9iDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpBbmltYSBt YWlsaW5nIGxpc3QNCkFuaW1hQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2FuaW1hDQoNCg0K From nobody Wed Aug 16 10:43:27 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A173313218F for ; Wed, 16 Aug 2017 10:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqM6QUrujP5U for ; Wed, 16 Aug 2017 10:43:22 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 C76301200F3 for ; Wed, 16 Aug 2017 10:43:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 54674607D4; Wed, 16 Aug 2017 13:43:19 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id M3fu-S82QjGv; Wed, 16 Aug 2017 13:43:13 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 719CA61FDA; Wed, 16 Aug 2017 13:43:12 -0400 (EDT) To: Kent Watsen , "anima@ietf.org" References: <3a5adc64-1737-9ecc-5c13-b310b48c2ba0@htt-consult.com> <31E4D893-7438-4EF4-85DF-4F47D70FF3CF@juniper.net> From: Robert Moskowitz Message-ID: <7a2bbf4e-e4f1-a0d0-690d-982ea22003bc@htt-consult.com> Date: Wed, 16 Aug 2017 13:43:08 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <31E4D893-7438-4EF4-85DF-4F47D70FF3CF@juniper.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Anima] creating iDevID certs with openssl X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 17:43:26 -0000 Kent, Thanks for the reply. They don't have it right with: [ alt_names ] otherName = 1.3.6.1.5.5.7.8.4;UTF8:EX320 Go to: http://www.htt-consult.com/pki.html And see my 802.1AR setup. I am much further along. I got to this point yesterday. There are a number of things you need to match the 1AR profile. I believe I am making hardwareModuleName per RFC4108. I believe I have hwType right as an OID. The thing is what to use for hwSerialNum. There are a lot of pieces in the cnf file so I am not posting it here. But I am making a CSR with the HMN in it and the intermediate CA is signing that, making a cert. All my certs are ECDSA P-256. I also put the proper 'forever' enddate value in. THe SAN can only be specified within the cnf file, so you need a hack to add it to the file prior to making the CSR. There are a number of 'next steps'. I can develop this for an offline system on one of my Cubieboard2s running Fedora26 so I could bring it to Singapore. But I would like to put together a group that want to develop this. There is no interest, but there is help, on the openssl-user list. On 08/16/2017 12:43 PM, Kent Watsen wrote: > Hi Bob, I'm watching this thread with interest. My take on this [1] is > a little different than yours, but I was just prototyping a rough > solution, I never took it to completion... [1] > https://github.com/netconf-wg/zero-touch/blob/master/openssl-test/vendor/idevid-certificate-pki/intermediate-ca/openssl.cnf#L55Kent > -- Making some progress. On 08/14/2017 01:44 PM, Robert Moskowitz wrote: >> I have just joined this list. So if this is covered in the archives >> anywhere, my weak search foo did not uncover it... >> >> Has anyone created iDevID certs with openssl including subjectAltName >> with hardwareModuleName? >> >> I have been working on this for a few days and have worked out HOW to >> even get certs to contain SAN, particularly going the csr route. I >> have learned on the openssl list that HMN is not directly supported >> and that you have to use othername. Something like >> >> [ req_ext ] >> subjectAltName = otherName:1.3.6.1.5.5.7.8.4;SEQ:hmodname >> >> [ hmodname ] >> hwType = OID:1.2.3.4 # Whatever OID you want. >> hwSerialNum = FORMAT:HEX,OCT:01020304 # Some hex > This produces a subjectAltName content of: > > 0:d=0 hl=2 l= 27 cons: SEQUENCE > 2:d=1 hl=2 l= 25 cons: cont [ 0 ] > 4:d=2 hl=2 l= 8 prim: OBJECT :1.3.6.1.5.5.7.8.4 > 14:d=2 hl=2 l= 13 cons: cont [ 0 ] > 16:d=3 hl=2 l= 11 cons: SEQUENCE > 18:d=4 hl=2 l= 3 prim: OBJECT :1.2.3.4 > 23:d=4 hl=2 l= 4 prim: OCTET STRING [HEX DUMP]:01020304 > > > I suspect that hwtype is a full vendor OID for registering this device. > Say my company, HTT Consulting makes sensor widgets. The OID for that > could be: > > 1.3.6.1.4.1.6715.10.1 (where 10 is HTT's devices and 1 is the sensor > widget). > >> But I am not sure what exactly to do with hwType and hwSerialNum >> >> Are there any extant examples? > So googling around for examples and not finding any. But then my search > foo has always been weak. > >> Currently there is no way to feed any SAN value in at the command like >> 'openssl req'. It has to go into the config file, so once I work out >> WHAT to but into these fields, I will have to do some kludgly stuff to >> stuff values into the config then run the command. There are examples >> of this around for SANs of IP, DNS, etc. >> >> BTW, so far I have a simple guide for making a pki of ECDSA certs >> using openssl. I would be willing to share what I have done todate. >> The 802.1AR cert section is understandably incomplete... >> >> Bob > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > > From nobody Wed Aug 16 10:47:05 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894DD126CB6 for ; Wed, 16 Aug 2017 10:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHYHkZLheQyU for ; Wed, 16 Aug 2017 10:47:01 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 6738E1200F3 for ; Wed, 16 Aug 2017 10:47:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 360836219C; Wed, 16 Aug 2017 13:47:00 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zOn2TtK5aLiF; Wed, 16 Aug 2017 13:46:52 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 93BFB6219B; Wed, 16 Aug 2017 13:46:51 -0400 (EDT) From: Robert Moskowitz To: Kent Watsen , "anima@ietf.org" References: <3a5adc64-1737-9ecc-5c13-b310b48c2ba0@htt-consult.com> <31E4D893-7438-4EF4-85DF-4F47D70FF3CF@juniper.net> <7a2bbf4e-e4f1-a0d0-690d-982ea22003bc@htt-consult.com> Message-ID: Date: Wed, 16 Aug 2017 13:46:46 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <7a2bbf4e-e4f1-a0d0-690d-982ea22003bc@htt-consult.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Anima] creating iDevID certs with openssl X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 17:47:03 -0000 I would love to tackle Ed25519 certs, but that is still in dev in openssl. Also I don't like that they used SHA512, rather than SHAKE128. It is ok for big systems, but not for the little stuff. On 08/16/2017 01:43 PM, Robert Moskowitz wrote: > Kent, > > Thanks for the reply. They don't have it right with: > > [ alt_names ] > otherName = 1.3.6.1.5.5.7.8.4;UTF8:EX320 > > Go to: http://www.htt-consult.com/pki.html > > And see my 802.1AR setup. I am much further along. I got to this > point yesterday. > > There are a number of things you need to match the 1AR profile. I > believe I am making hardwareModuleName per RFC4108. I believe I have > hwType right as an OID. The thing is what to use for hwSerialNum. > > There are a lot of pieces in the cnf file so I am not posting it here. > > But I am making a CSR with the HMN in it and the intermediate CA is > signing that, making a cert. > > All my certs are ECDSA P-256. I also put the proper 'forever' enddate > value in. > > THe SAN can only be specified within the cnf file, so you need a hack > to add it to the file prior to making the CSR. > > There are a number of 'next steps'. I can develop this for an offline > system on one of my Cubieboard2s running Fedora26 so I could bring it > to Singapore. > > But I would like to put together a group that want to develop this. > There is no interest, but there is help, on the openssl-user list. > > On 08/16/2017 12:43 PM, Kent Watsen wrote: >> Hi Bob, I'm watching this thread with interest. My take on this [1] >> is a little different than yours, but I was just prototyping a rough >> solution, I never took it to completion... [1] >> https://github.com/netconf-wg/zero-touch/blob/master/openssl-test/vendor/idevid-certificate-pki/intermediate-ca/openssl.cnf#L55Kent >> -- Making some progress. On 08/14/2017 01:44 PM, Robert Moskowitz wrote: >>> I have just joined this list. So if this is covered in the archives >>> anywhere, my weak search foo did not uncover it... >>> >>> Has anyone created iDevID certs with openssl including subjectAltName >>> with hardwareModuleName? >>> >>> I have been working on this for a few days and have worked out HOW to >>> even get certs to contain SAN, particularly going the csr route. I >>> have learned on the openssl list that HMN is not directly supported >>> and that you have to use othername. Something like >>> >>> [ req_ext ] >>> subjectAltName = otherName:1.3.6.1.5.5.7.8.4;SEQ:hmodname >>> >>> [ hmodname ] >>> hwType = OID:1.2.3.4 # Whatever OID you want. >>> hwSerialNum = FORMAT:HEX,OCT:01020304 # Some hex >> This produces a subjectAltName content of: >> >> 0:d=0 hl=2 l= 27 cons: SEQUENCE >> 2:d=1 hl=2 l= 25 cons: cont [ 0 ] >> 4:d=2 hl=2 l= 8 prim: OBJECT :1.3.6.1.5.5.7.8.4 >> 14:d=2 hl=2 l= 13 cons: cont [ 0 ] >> 16:d=3 hl=2 l= 11 cons: SEQUENCE >> 18:d=4 hl=2 l= 3 prim: OBJECT :1.2.3.4 >> 23:d=4 hl=2 l= 4 prim: OCTET STRING [HEX DUMP]:01020304 >> >> >> I suspect that hwtype is a full vendor OID for registering this device. >> Say my company, HTT Consulting makes sensor widgets. The OID for that >> could be: >> >> 1.3.6.1.4.1.6715.10.1 (where 10 is HTT's devices and 1 is the sensor >> widget). >> >>> But I am not sure what exactly to do with hwType and hwSerialNum >>> >>> Are there any extant examples? >> So googling around for examples and not finding any. But then my search >> foo has always been weak. >> >>> Currently there is no way to feed any SAN value in at the command like >>> 'openssl req'. It has to go into the config file, so once I work out >>> WHAT to but into these fields, I will have to do some kludgly stuff to >>> stuff values into the config then run the command. There are examples >>> of this around for SANs of IP, DNS, etc. >>> >>> BTW, so far I have a simple guide for making a pki of ECDSA certs >>> using openssl. I would be willing to share what I have done todate. >>> The 802.1AR cert section is understandably incomplete... >>> >>> Bob >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> >> > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Wed Aug 16 11:24:48 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED704132396; Wed, 16 Aug 2017 11:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.011 X-Spam-Level: X-Spam-Status: No, score=-3.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 vNtqnQqwEQ_Q; Wed, 16 Aug 2017 11:24:44 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0135.outbound.protection.outlook.com [104.47.42.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 473FB13236E; Wed, 16 Aug 2017 11:24:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=H0/fmDme6sgMCxhTEYxVkdV33CsQd5KmFleERR0f4PE=; b=R4prDRqXt9f6+azBBQgSLRRyAVuWS1y9pTzJQB6O7REIYO93r2R8QsxB5LWOXGIxx5jZRscEFvRYyOyPokURqOL0N6xXxQ99UTRI0d3BJXIO3UlHkw/QiNaP6BV1YghhPzKq+M3+xUD9SOlnzdcjPe4AoLIULkXUeYdRbZoof8A= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1172.namprd05.prod.outlook.com (10.160.113.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1362.12; Wed, 16 Aug 2017 18:24:43 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.1362.018; Wed, 16 Aug 2017 18:24:43 +0000 From: Kent Watsen To: "consultancy@vanderstok.org" , Sheng Jiang CC: "anima-chairs@ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org>, "netconf@ietf.org" , "anima@ietf.org" Thread-Topic: [Netconf] [Anima] Cross-WGs WGLC (second) on draft-ietf-anima-voucher-04 - Respond by Aug 08, 2017 Thread-Index: AdMKmFTPR22MviVNQvGwNG9FbFt4tQAG0+8AAvnwfwA= Date: Wed, 16 Aug 2017 18:24:42 +0000 Message-ID: <3F9D68E6-57C9-48EF-A4EB-3CA8B613D42D@juniper.net> References: <5D36713D8A4E7348A7E10DF7437A4B927CE3D826@NKGEML515-MBX.china.huawei.com> <76229c58f5d60d3a0c185c6645ba4355@xs4all.nl> In-Reply-To: <76229c58f5d60d3a0c185c6645ba4355@xs4all.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-originating-ip: [66.129.241.13] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1172; 6:MWnHxsBWuJeJSNd5Jgx+JU9ZjwEI7BKQZMpkxEBEMLu8ME9nZG7mtWU4Id+oQLmHWczVOKQQM3yPN2ZT4zeaBEX+ZWI4cP5nvs54AijNv15hG8YFsofNn0WmDfioUoDUvZVKyvCsVKVpqrp4taqJwdQ+5W6WhSqAZfYXe0pr/2mldmwE3Zmdr+60wL5rTUXUYsBIVDjVcgVSXJibCVYCJrUNVmGVgFwTOQmL7y3fgosloyEMAnzoDf6VqA4xGD9FJgGR9DUg6qSqUY9XmW9e+L+Iies/EEOy/SkHEHLs/Ty+SDgkPeCdtzA/Sd7DHqVIKjLJ9/x90sRW+0rprXFc4Q==; 5:aG+d/XdY+C+lpCUM6MtRyEnAaY55BFylq6zRuYdDqjiz3VSxSAwUGCeB8SeUvme5IbJgIvHJKIZK4LoZvbl8zOuwG53ODOzq3e7RxtyAN2/k8xmr9Dpk5hVaZUhz2bj57qLBSP2OjIsPMZ/4AT/TLw==; 24:OD3pcLZxbksicQkgcDmuf8cUCUZb3DAq5IPRvGTVVT1MV/YzhXmTjg4jYNYes9vHjAzcaHWJsQvW7dRnqj56zzLDHdedx+ccxZRiiFHNMu4=; 7:U8oVOtNAsQ2x/95YIGv57E0Kmr/+0QEeFobk5u2E7uiA/BBg7ur7rSg/cMXZMQLXV+CtI44E19OsZzYwAfcartiS7sdXLkpIlk7YUOcb4+yebFYqq/rgbX5qSsr8F8pwUtgBwRYWxLFQXx6y6vVYsHsmxfrLCrvZMY60OLCSC1yauQ+PjOsJxmMob4iMFaH+q4YsHSmJEP+cpJrz9kQKrUkuQSDkLZS6a4nZMuz8njA= x-ms-office365-filtering-correlation-id: afedee4f-fcd3-4c40-f364-08d4e4d410b1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1172; x-ms-traffictypediagnostic: BN3PR0501MB1172: x-exchange-antispam-report-test: UriScan:(60795455431006); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1172; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1172; x-forefront-prvs: 0401647B7F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(189002)(199003)(51444003)(43544003)(40224003)(53754006)(189998001)(2900100001)(33656002)(66066001)(82746002)(25786009)(6246003)(53936002)(6512007)(99286003)(4326008)(6436002)(54906002)(230783001)(106356001)(105586002)(101416001)(50986999)(76176999)(54356999)(6486002)(77096006)(6506006)(36756003)(14454004)(2950100002)(229853002)(83716003)(2501003)(5660300001)(86362001)(8936002)(81166006)(83506001)(81156014)(4001350100001)(8676002)(7736002)(3660700001)(68736007)(2906002)(97736004)(3846002)(478600001)(102836003)(6116002)(305945005)(3280700002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1172; H:BN3PR0501MB1442.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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2017 18:24:42.9598 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1172 Archived-At: Subject: Re: [Anima] [Netconf] Cross-WGs WGLC (second) on draft-ietf-anima-voucher-04 - Respond by Aug 08, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 18:24:47 -0000 SGkgUGV0ZXIsDQoNClRoYW5rcyBmb3IgeW91ciByZXZpZXcuICAgUGxlYXNlIGZpbmQgcmVzcG9u c2VzDQp0byB5b3VyIGNvbW1lbnRzIGJlbG93Lg0KDQpNYXgsIHBsZWFzZSBub3RlIHlvdXIgYXR0 ZW50aW9uIGlzIG5lZWRlZC4NCg0KVGhhbmtzLA0KS2VudA0KDQoNCi0tDQoNCkhpIGFsbCwNCg0K SSByZWFkIHRoaXMgZG9jdW1lbnQsIGFuZCBmaW5kIGl0IHdlbGwgd3JpdHRlbiBhbmQgdW5kZXJz dGFuZGFibGUuDQpJIGRvIGhhdmUgc29tZSByZW1hcmtzIGFib3V0IHRoZSBjb250ZW50IGFuZCBz ZXZlcmFsIGVkaXRpbmcgcmVtYXJrcy4NCg0KQ29udGVudCByZW1hcmtzOg0KDQpzZWN0aW9uIDYs IGxlYWYgcHJpb3Itc2lnbmVkLXZvdWNoZXIsIGF0IHRoZSBlbmQ6DQpUaGUgTUFTQSBTSE9VTEQg cmVtb3ZlIGFsbCAicHJpb3Itc2lnbmVkLXZvdWNoZXIiLg0KSSB3b3VsZCBlbmNvdXJhZ2UgYSAi TVVTVCIgaW5zdGVhZCBvZiBhICJTSE9VTEQiIHdoZW4gdGhpbmtpbmcgb2YgDQp0cmFuc3BvcnRp bmcgdm91Y2hlcnMgb3ZlciBjb25zdHJhaW5lZCBuZXR3b3Jrcy4NCg0KPEtlbnQ+IHRoaXMgbGVh ZiBoYXMgYmVlbiBtb3ZlZCB0byB0aGUgQlJTS0kgZHJhZnQsIHNvIHRoaXMgY29tbWVudA0KaXMg bm8gbG9uZ2VyIGFuIGlzc3VlIG9uIHRoaXMgZHJhZnQuDQoNCg0Kc2VjdGlvbiA2LjM6IGxlYWYg aWRldmlkLWlzc3VlciwgZGVzY3JpcHRpb24sIHBhcmFncmFwaCAyLA0KICJwb3B1bGF0ZWQgZm9y IHNlcmlhbCBudW1iZXJzIHRoYXQgYXJlIG5vdCBvdGhlcndpc2UgdW5pcXVlIg0KdG8gYmUgcmVw bGFjZWQgYnkNCiAicG9wdWxhdGVkIHdoZW4gc2VyaWFsIG51bWJlcnMgYXJlIG5vdCB1bmlxdWUi Lg0KTXkgcHJvcG9zZWQgdGV4dCBpcyBsZXNzIHNlbGVjdGl2ZSwgYW5kIGNvbnNlcXVlbnRseSBs ZXNzIGVycm9yIHByb25lLg0KDQo8S2VudD4gRmluZSwgdGV4dCB1cGRhdGVkLg0KDQoNCj4gQ2Fu IGEgZGlzY3Vzc2lvbiBzZWN0aW9uIGFib3V0ICJtYW51ZmFjdHVyZXIgYWRkaXRpb25zIiBiZQ0K PiBhZGRlZC4gUG9pbnRpbmcgb3V0IHRoZSBjb25zZXF1ZW5jZXMgZm9yIGludGVyb3BlcmFiaWxp dHkNCj4gd2hlbiB1c2luZyAiQXVnbWVudCIgdG8gYWRkIG1hbnVmYWN0dXJlciBzcGVjaWZpY3Mg Y2FuIGJlDQo+IGhlbHBmdWwuDQoNCkknbSBjb25mdXNlZCwgd2hpY2ggc2VjdGlvbiBkb2VzIHRo aXMgY29tbWVudCByZWdhcmQ/DQoNCg0KRWRpdGluZyByZW1hcmtzOg0KDQpJbnRyb2R1Y3Rpb24s IGZpcnN0IHBocmFzZTogcGxlZGdlIC0+IGNhbmRpZGF0ZSBkZXZpY2UgKHBsZWRnZSkNCg0KPEtF TlQ+IGRvbmUuDQoNCg0KcGFnZSAzLCBQS0NTIzcgYWRkIFJGQzIzMTUgcmVmZXJlbmNlLCBhbmQg bWF5IGJlIGFkZCBSRkM3MTU0IGFzIEpTT04gDQpyZWZlcmVuY2UuDQoNCjxLRU5UPiBkb25lLg0K DQoNClNlY3Rpb24gMjsgbWVudGlvbiB0ZXJtaW5vbG9neSBmcm9tIFJGQzc5NTANCg0KPEtFTlQ+ IFdoYXQgaXMgdGhpcz8gIEFyZSB5b3UgYXNraW5nIGZvciB0aGUgZHJhZnQgdG8gaW1wb3J0IHRl cm1zDQpmcm9tIFJGQzc5NTA/ICBXaGljaCB0ZXJtcyANCg0KDQpwYWdlIDQgbGluZSA1OyAicHJv Y2Vzcy4gaSBUeXBpY2FsbHkiIHJlbW92ZSB0aGUgImkiDQoNCjxLRU5UPiBmaXhlZC4NCg0KDQpw YWdlIDQsIFZvdWNoZXI6IGFkZDogdGhhdCAiYWNrbm93bGVkZ2VzIG93bmVyc2hpcCBvZiB0aGUg cGxlZGdlIGFuZCIgDQppbmRpY2F0ZXMuLi4NCg0KPEtFTlQ+IHdoYXQgZG9lcyAiYWNrbm93bGVk Z2VzIG93bmVyc2hpcCBvZiB0aGUgcGxlZGdlIiBtZWFuPyAgaG93DQppcyBpdCBkaWZmZXJlbnQg dGhhbiAiaW5kaWNhdGVzIHRvIGEgUGxlZGdlIHRoZSBjcnlwdG9ncmFwaGljIGlkZW50aXR5DQpv ZiB0aGUgRG9tYWluIGl0IHNob3VsZCB0cnVzdCI/DQoNCg0KcGFnZSA1IEF1dGhlbnRpY2F0aW9u IG9mOiBGaXJzdCBhcHBlYXJhbmNlcyBvZiBQS0lYLCBETlMtSUQsIGFuZCBDTi1JRCANCmFiYnJl dmlhdGlvbnMuDQoNCjxLRU5UPiBJIGFkZGVkIGEgZGVmaW5pdGlvbiBmb3IgUEtJWCwgYnV0IEkg dGhpbmsgdGhhdCBNYXggbmVlZHMgdG8gdGFrZQ0KY2FyZSBvZiB0aGUgRE5TLUlEIGFuZCBDTi1J RCBwYXJ0cy4gIEl0J3MgaGlzIHRleHQsIGFuZCB0aGVyZSB0aGluZ3MgaGF2ZQ0Kc2luY2UgYmVl biByZW1vdmVkIGZyb20gdGhlIFlBTkcuICBNYXgsIHRoZXNlIHNob3cgdXAgaW4gdGhyZWUgcGxh Y2VzLi4uDQoNCg0KcGFnZSA1LCBhZGQgKE1pVE0pIGFmdGVyIE1hbi1pbi1UaGUtTWlkZGxlLg0K DQo8S0VOVD4gYWRkZWQuDQoNCg0KcGFnZSA2IHRhYmxlOiBWb3VjaGVyIG5hbWUgLT4gVm91Y2hl ciB0eXBlDQoNCjxLRU5UPiBjaGFuZ2VkLg0KDQoNCk5vbmNlbGVzcyBBdWRpdCBWb3VjaGVyOiAi dG8gc3VwcG9ydCBuZXR3b3JrIHBhcnRpdGlvbnMiIC0+ICJ0byANCndpdGhzdGFuZCBuZXR3b3Jr IHBhcnRpdGlvbnMiDQoNCjxLRU5UPiBjaGFuZ2VkLg0KDQoNCk93ZW5lcnNoaXAgYXVkaXQgVm91 Y2hlcjogIlZvdWNoZXIncyIgLT4gIlZvdWNoZXJzIiwgYW5kIHJlbW92ZSAiYW4gDQppZGVhbCIg b3RoZXJ3aXNlIGV4cGxhaW4gd2hhdCB0aGF0IG1lYW5zIGFuZCB3aHkgaXQgaXMgdHJ1ZS4NCg0K PEtFTlQ+IEknbGwgbGVhdmUgdGhpcyBmb3IgTWF4Lg0KDQoNCj4gQWRkIHR5cGUgaW46DQo+IE93 bmVyc2hpcCBJRCB2b3VjaGVyICJ0eXBlIiBpcyBuYW1lZA0KPiBCZWFyZXIgVm91Y2hlciAidHlw ZSIgaXMgbmFtZWQNCg0KPEtFTlQ+IHlvdSBvbmx5IG1lbnRpb24gdGhlc2UgdHdvLCBidXQgbm9u ZSBvZiB0aGUgdm91Y2hlciB0eXBlIA0KZGVzY3JpcHRpb25zIGhhdmUgInR5cGUiIGluIHRoZW0s IG9yIG1heWJlIEknbSBtaXNzaW5nIHNvbWV0aGluZy4NCg0KDQo+IHNlY3Rpb24gNg0KPiAiVGhl IHZvdWNoZXIgaXMgc2lnbmluZyBzdHJ1Y3R1cmUgdGhhdCIgLT4gIlRoZSB2b3VjaGVyIHNpZ25p bmcgDQo+IHN0cnVjdHVyZSINCg0KPEtFTlQ+IGRvbmUuDQoNCg0Kc2VjdGlvbiA2LCBwYXJhZ3Jh cGggNiwgYWxsICJvZiIgdGhlIGNlcnRpZmljYXRlLCByZW1vdmUgIm9mIg0KDQo8S0VOVD4gZG9u ZS4NCg0KDQpzZWN0aW9uIDYgcGFnZSA3IGJlbG93LCBGaXJzdCBhcHBlYXJhbmNlIG9mIENBIGFu ZCBKV1MgYWJicmV2aWF0aW9ucw0KDQo8S0VOVD4gYWNyb255bSBleHBhbnNpb25zIGludHJvZHVj ZWQuDQoNCg0Kc2VjdGlvbiA2LjEgKHNlZSBzZWN0aW9uIDQpIGFkZCAic2VlIg0KDQo8S0VOVD4g ZG9uZS4NCg0KDQpzZWN0aW9uIDYuMyBwYWdlIDEwLCBtb2R1bGUgZGVzY3JpcHRpb246ICJzZWN1 cmVseSBhc3NpZ24gb25lIG9yIG1vcmUgDQpwbGVkZ2VzIHRvIGFuICdvd25lciciIHNlZW1zIHRv IGNvbnRyYWRpY3Qgc2VjdGlvbiA3LjIgdm91Y2hlciBwZXIgDQpwbGVkZ2UNCg0KPEtFTlQ+IGNv cnJlY3QsIGZpeGVkLg0KDQoNCj4gc2VjdGlvbiA3LjEgbGFzdCBsaW5lOiAidGhlcmUgaXMgYSBk ZWxheSIgaXMgdGhhdCBkZWxheSBiZXR3ZWVuIGNyZWF0aW9uIA0KPiBhbmQgY29uc3VtcHRpb24g YW5kIHdoZW4gaXMgdGhlIGRlbGF5IHVuYWNjZXB0YWJsZT8gdGhlIHRleHQgaXMgKG9uIA0KPiBw dXJwb3NlPykgdmFndWUuDQoNCjxLRU5UPiBUaGUgcHJldmlvdXMgc2VudGVuY2Ugc2F5cyAiLi4u dGhlcmUgbWF5IGJlIGEgc2lnbmlmaWNhbnQNCmRlbGF5IGJldHdlZW4gd2hlbiBhIHZvdWNoZXIg aXMgY3JlYXRlZCBhbmQgd2hlbiBpdCBpcyBjb25zdW1lZC4iDQphbmQgdGhlIHJlbWFpbmRlciBv ZiB0aGUgbGluZSB5b3UncmUgY2l0aW5nIHNheXMgInRvIGVuc3VyZSB0aGF0DQp0aGUgYXNzZXJ0 aW9ucyBtYWRlIHdoZW4gdGhlIHZvdWNoZXIgd2FzIGNyZWF0ZWQgYXJlIHN0aWxsIHZhbGlkIA0K d2hlbiBpdCBpcyBjb25zdW1lZC4iICAgVGhpcyBpcyB2YWd1ZT8NCg0KDQpzZWN0aW9uIDguMSBm aXJzdCBwYXJhZ3JhcGg6ICJubyB1bmRlcnN0YW5kSU5HIG9mIHRpbWUiLCBhZGQgImluZyINCg0K PEtFTlQ+IGRvbmUuDQoNCg0Kc2VjdGlvbiA4LjEgcGFyYWdyYXBoIDI6IGVwaGVybWFsIC0+IGVw aGVtZXJhbA0KDQo8S0VOVD4gZml4ZWQuDQoNCnNlY3Rpb24gOC4yIGNvbXByb21pemVkIC0+IGNv bXByb21pc2VkPw0KDQo8S0VOVD4gZml4ZWQuDQoNCg0KDQoNCg== From nobody Fri Aug 18 00:45:52 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995B9132144; Fri, 18 Aug 2017 00:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwcnWMbjCggX; Fri, 18 Aug 2017 00:45:48 -0700 (PDT) Received: from lb1-smtp-cloud8.xs4all.net (lb1-smtp-cloud8.xs4all.net [194.109.24.21]) (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 885BD12EC06; Fri, 18 Aug 2017 00:45:46 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:207]) by smtp-cloud8.xs4all.net with ESMTPA id ibyRdFVTccQyLibyRdQQfr; Fri, 18 Aug 2017 09:45:45 +0200 Received: from ip565c6c1e.direct-adsl.nl ([86.92.108.30]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 18 Aug 2017 09:45:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 18 Aug 2017 09:45:43 +0200 From: peter van der Stok To: Kent Watsen Cc: consultancy@vanderstok.org, Sheng Jiang , anima-chairs@ietf.org, 6tisch@ietf.org, netconf@ietf.org, anima@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <3F9D68E6-57C9-48EF-A4EB-3CA8B613D42D@juniper.net> References: <5D36713D8A4E7348A7E10DF7437A4B927CE3D826@NKGEML515-MBX.china.huawei.com> <76229c58f5d60d3a0c185c6645ba4355@xs4all.nl> <3F9D68E6-57C9-48EF-A4EB-3CA8B613D42D@juniper.net> Message-ID: <1fee7f82c855def7345d506fbb720dbc@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfLvmp/uAoE0ESmd6fJb69jJaqfYQYNjthF/bPbChbMOo6X8V+92q4gysxaVLdSHZoAZqvJ97wIlO/F9kjiRCsQiKQleF/0ZxNZiFvcsxS97VTWtB8W76 WTs3UUTJ7YheaDrrY4M6R6o73ZQzr2XcHlw3PRGwhAcAfg3V3OCuf0OEEPhvtgoD+zwtkU+wy5AV+jTI9QyKGoam7c4ba3egyQCRnm8L60lB/TJ1PMLJmSLj Jddq95rAaCLF8dLy8K9x2Aq5aoNRLwF8AFhT8dHvC5x+TqmAxWsisRhZV47qEqCw2xktdar+nhBhxi+VG4W8dN7/g33Mgh7F5ngjSBaPXxnotz4+OwpOuw2g oWePRlq3 Archived-At: Subject: Re: [Anima] [6tisch] [Netconf] Cross-WGs WGLC (second) on draft-ietf-anima-voucher-04 - Respond by Aug 08, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 07:45:51 -0000 >> Can a discussion section about "manufacturer additions" be >> added. Pointing out the consequences for interoperability >> when using "Augment" to add manufacturer specifics can be >> helpful. > > I'm confused, which section does this comment regard? It refers to the document as a whole and especially section 7. Usually, manufacturers want manufacturer-specific additions to documents. They may consider to use Augment for that purpose. My suggestion is to discuss ways to add manufacturer additions to the voucher and the consequences. That may turn out to be a big NO-NO to manufacturer additions. I think it would be worthwhile to point that out. > Section 2; mention terminology from RFC7950 > > What is this? Are you asking for the draft to import terms > from RFC7950? Which terms Reading RFC7950 is useful to understand section 4 for example; and needed when reading the voucher YANG text. So not especially terms, but complete knowledge of RFC7950 is required. > > > page 4, Voucher: add: that "acknowledges ownership of the pledge and" > indicates... > > what does "acknowledges ownership of the pledge" mean? how > is it different than "indicates to a Pledge the cryptographic identity > of the Domain it should trust"? Now I am confused. I thought it was 2 ways. Pledge trusts domain, and domain partners trust pledge. > >> Add type in: >> Ownership ID voucher "type" is named >> Bearer Voucher "type" is named > > you only mention these two, but none of the voucher type > descriptions have "type" in them, or maybe I'm missing something. The name of the voucher is taken from the type I understand. Only ownership ID voucher and Bearer voucher have text starting with "xxxx is named". I see that I forgot: An audit voucher "type" is named ..... > >> section 7.1 last line: "there is a delay" is that delay between >> creation >> and consumption and when is the delay unacceptable? the text is (on >> purpose?) vague. > > The previous sentence says "...there may be a significant > delay between when a voucher is created and when it is consumed." > and the remainder of the line you're citing says "to ensure that > the assertions made when the voucher was created are still valid > when it is consumed." This is vague? To me yes. It sounds like a circular definition. To paraphrase: When the voucher is consumed, the assertions are valid by definition. I would expect a pointer to a delay definition and then an assertion that states: when consumption time is larger than the creation time + delay, the voucher is invalid. > From nobody Fri Aug 18 06:21:23 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508F313235B; Fri, 18 Aug 2017 06:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, 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=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 4iVWWSz41g2N; Fri, 18 Aug 2017 06:21:20 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0137.outbound.protection.outlook.com [104.47.33.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8D7E1204DA; Fri, 18 Aug 2017 06:21:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8Sot/wKNZ6NceRCtCuixpjZtZX9vs+ca51hEMhb5mqA=; b=hkB0UbArPm/zjyImPDJTCkl/nrvjGQq3c3Qd5QEAvRe65LI7eA/MDL5ZgPre2hGwbkGR17WXQYXFNChz+FFWggWC5bftNYaVp83NWwrgtDfSdCxBt7w+lDkRmvgFcncwllmXLEyO/NYoBU59hbarI1ZH44SvqrNj7GhxSz63+Ew= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1395.namprd05.prod.outlook.com (10.160.117.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1362.12; Fri, 18 Aug 2017 13:21:17 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.1385.003; Fri, 18 Aug 2017 13:21:17 +0000 From: Kent Watsen To: "consultancy@vanderstok.org" CC: Sheng Jiang , "anima-chairs@ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org>, "netconf@ietf.org" , "anima@ietf.org" Thread-Topic: [6tisch] [Netconf] [Anima] Cross-WGs WGLC (second) on draft-ietf-anima-voucher-04 - Respond by Aug 08, 2017 Thread-Index: AdMKmFTPR22MviVNQvGwNG9FbFt4tQAG0+8AAvnwfwAAVqYFgAADVm+A Date: Fri, 18 Aug 2017 13:21:17 +0000 Message-ID: <8168023A-AC1F-4A7E-B8BA-026651EFEF33@juniper.net> References: <5D36713D8A4E7348A7E10DF7437A4B927CE3D826@NKGEML515-MBX.china.huawei.com> <76229c58f5d60d3a0c185c6645ba4355@xs4all.nl> <3F9D68E6-57C9-48EF-A4EB-3CA8B613D42D@juniper.net> <1fee7f82c855def7345d506fbb720dbc@xs4all.nl> In-Reply-To: <1fee7f82c855def7345d506fbb720dbc@xs4all.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-originating-ip: [66.129.241.13] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1395; 6:NVHr/MOUAmN7XZAeF8vdcAFr3yxKGBSxLRwUgga0Yo2TZoYHiE4c4HMAOlQBEfgdtc0VrBuAXy3nu4/8VHUxipItDZDsf3rPthjviFKaxB4wQhhEMgVWRZctMdidFMw+y5qkRrWq0OM9tz5u08ZFuRAaUky8kyw83UIMfC3y4Mh8VHM57YlUuXcR+ZffVMtfQ7QY+0HlGMMTAcvsdt01nHzq4SWupv/bEQoYlyPPJcpSKSTa2iwlr+DsTN1I5gKhjxv4DptlZVo8runk8071U2D1XPizLvWeWSstu4Bpztu4aoLYa3m5Cx6NdF6vserqj2lwDmNQSJU8j3dnkX0yxg==; 5:P2BmF6rx77MIjQoaY8RcJwa4DZy9DZSOuUaiBp9q7LElzkXXDC9RPOsDDs6AofFNQrXb1dIUBYycrmiLK0I+rEKOwZesXc9ARm2CWKWGr+TQF1UGfcJtuwsB7Vft80SwJmUgSDZEHyzWEscse+E9ig==; 24:xDk2T0g5cCk0bU7hlBgDP0SAeNHJBYX6eJ5zJFv59H5g1og0qYJHBjXYFn4oVq9HjpQKX0kQEdgRF1D28MYw4OA5u7o3gx6s8Nhm5ilmRvE=; 7:6BFTE9bLGApxQfW7OGY6HJfWZqVakQZdt7wkMluZk9m3QzCcFWZ0vtSaiTIgupF5LlxUDC1/A3cAMikN8YwDlm8wDbEgrNzehhPkemBFRtlN0abhAynXAwO+ru6dy+C6RVbcUh1erHSyuRdcNdRCiRocxciGnCvDV4iIgpV0gVZ8f4HYPsyOU+4UkElnV7oAH9L6dO9ToRqajwk+AluBLZc3vwQMFjsQgmhJbNlLVUM= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 493efde7-dab9-47a9-4e29-08d4e63c024a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1395; x-ms-traffictypediagnostic: BN3PR0501MB1395: x-exchange-antispam-report-test: UriScan:(60795455431006)(17755550239193); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123558100)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1395; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1395; x-forefront-prvs: 040359335D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(199003)(189002)(25786009)(6436002)(54356999)(6506006)(33656002)(101416001)(50986999)(76176999)(77096006)(6486002)(97736004)(6246003)(81166006)(81156014)(1730700003)(4001350100001)(110136004)(8676002)(230783001)(8936002)(2501003)(7736002)(305945005)(14454004)(4326008)(229853002)(54906002)(99286003)(2950100002)(6512007)(68736007)(6916009)(53936002)(105586002)(106356001)(5640700003)(2351001)(478600001)(102836003)(3846002)(3660700001)(6116002)(2906002)(2900100001)(5660300001)(83506001)(189998001)(83716003)(3280700002)(82746002)(93886005)(66066001)(36756003)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1395; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2017 13:21:17.6307 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1395 Archived-At: Subject: Re: [Anima] [6tisch] [Netconf] Cross-WGs WGLC (second) on draft-ietf-anima-voucher-04 - Respond by Aug 08, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 13:21:22 -0000 SGkgUGV0ZXIsDQoNCg0KPj4gQ2FuIGEgZGlzY3Vzc2lvbiBzZWN0aW9uIGFib3V0ICJtYW51ZmFj dHVyZXIgYWRkaXRpb25zIiBiZQ0KPj4gYWRkZWQuIFBvaW50aW5nIG91dCB0aGUgY29uc2VxdWVu Y2VzIGZvciBpbnRlcm9wZXJhYmlsaXR5DQo+PiB3aGVuIHVzaW5nICJBdWdtZW50IiB0byBhZGQg bWFudWZhY3R1cmVyIHNwZWNpZmljcyBjYW4gYmUNCj4+IGhlbHBmdWwuDQo+IA0KPiBJJ20gY29u ZnVzZWQsIHdoaWNoIHNlY3Rpb24gZG9lcyB0aGlzIGNvbW1lbnQgcmVnYXJkPw0KDQpJdCByZWZl cnMgdG8gdGhlIGRvY3VtZW50IGFzIGEgd2hvbGUgYW5kIGVzcGVjaWFsbHkgc2VjdGlvbiA3Lg0K VXN1YWxseSwgbWFudWZhY3R1cmVycyB3YW50IG1hbnVmYWN0dXJlci1zcGVjaWZpYyBhZGRpdGlv bnMgdG8gDQpkb2N1bWVudHMuDQpUaGV5IG1heSBjb25zaWRlciB0byB1c2UgQXVnbWVudCBmb3Ig dGhhdCBwdXJwb3NlLg0KTXkgc3VnZ2VzdGlvbiBpcyB0byBkaXNjdXNzIHdheXMgdG8gYWRkIG1h bnVmYWN0dXJlciBhZGRpdGlvbnMgdG8gdGhlIA0Kdm91Y2hlciBhbmQgdGhlIGNvbnNlcXVlbmNl cy4NClRoYXQgbWF5IHR1cm4gb3V0IHRvIGJlIGEgYmlnIE5PLU5PIHRvIG1hbnVmYWN0dXJlciBh ZGRpdGlvbnMuDQpJIHRoaW5rIGl0IHdvdWxkIGJlIHdvcnRod2hpbGUgdG8gcG9pbnQgdGhhdCBv dXQuDQoNCjxLRU5UPiBBcmUgeW91IGFza2luZyBmb3IgdGhlIHZvdWNoZXIgdG8gY29udGFpbiBh IG5vZGUNCmNhbGxlZCBzb21ldGhpbmcgbGlrZSAnb3BhcXVlJyBoYXZpbmcgWUFORyB0eXBlICdh bnlEYXRhJz8NCkEgc2FuY3Rpb25lZCBwbGFjZSB3aGVyZSB0aGUgTUFTQSBjYW4gc3Rhc2ggc29t ZSBleHRyYQ0Kc3R1ZmYgbm90IGRlZmluZWQgYnkgdGhpcyBkb2N1bWVudD8gIFJlY2FsbCB0aGF0 IHNvbWUgb2YNCnRoZSBtb3RpdmF0aW9uIGZvciB0aGlzIHdvcmsgYmVpbmcgc3RhbmRhcmRpemVk IGlzIHRvDQplbmFibGUgaW5zcGVjdGlvbiBieSBpbnRlcm1lZGlhdGVzLCBhbmQgd2hpbGUgdGhl IG9wYXF1ZQ0KZGF0YSBjb3VsZCBiZSBwcmVzZW50ZWQgdG8gYSBodW1hbiwgaXQgbWlnaHQgYmUg YmFzZTY0DQpkYXRhLiAgQW55IGNvbmNlcm5zIGJvdXQgdGhhdD8NCg0KDQo+IFNlY3Rpb24gMjsg bWVudGlvbiB0ZXJtaW5vbG9neSBmcm9tIFJGQzc5NTANCj4gDQo+IDxLRU5UPiBXaGF0IGlzIHRo aXM/ICBBcmUgeW91IGFza2luZyBmb3IgdGhlIGRyYWZ0IHRvIGltcG9ydCB0ZXJtcw0KPiBmcm9t IFJGQzc5NTA/ICBXaGljaCB0ZXJtcw0KDQpSZWFkaW5nIFJGQzc5NTAgaXMgdXNlZnVsIHRvIHVu ZGVyc3RhbmQgc2VjdGlvbiA0IGZvciBleGFtcGxlOyBhbmQgDQpuZWVkZWQgd2hlbiByZWFkaW5n IHRoZSB2b3VjaGVyIFlBTkcgdGV4dC4NClNvIG5vdCBlc3BlY2lhbGx5IHRlcm1zLCBidXQgY29t cGxldGUga25vd2xlZGdlIG9mIFJGQzc5NTAgaXMgcmVxdWlyZWQuDQoNCjxLRU5UPiBJIGFkZGVk IGFuIGludHJvZHVjdG9yeSBzZW50ZW5jZSB0byBTZWN0aW9uIDYuMzoNCg0KICAgRm9sbG93aW5n IGlzIGEgWUFORyBbUkZDNzk1MF0gbW9kdWxlIGZvcm1hbGx5IGRlc2NyaWJpbmcgdGhlDQogICB2 b3VjaGVyJ3MgSlNPTiBkb2N1bWVudCBzdHJ1Y3R1cmUuDQoNCkdvb2Q/DQoNCg0KPiBwYWdlIDQs IFZvdWNoZXI6IGFkZDogdGhhdCAiYWNrbm93bGVkZ2VzIG93bmVyc2hpcCBvZiB0aGUgcGxlZGdl IGFuZCINCj4gaW5kaWNhdGVzLi4uDQo+IA0KPiA8S0VOVD4gd2hhdCBkb2VzICJhY2tub3dsZWRn ZXMgb3duZXJzaGlwIG9mIHRoZSBwbGVkZ2UiIG1lYW4/ICBob3cNCj4gaXMgaXQgZGlmZmVyZW50 IHRoYW4gImluZGljYXRlcyB0byBhIFBsZWRnZSB0aGUgY3J5cHRvZ3JhcGhpYyBpZGVudGl0eQ0K PiBvZiB0aGUgRG9tYWluIGl0IHNob3VsZCB0cnVzdCI/DQoNCk5vdyBJIGFtIGNvbmZ1c2VkLiBJ IHRob3VnaHQgaXQgd2FzIDIgd2F5cy4gUGxlZGdlIHRydXN0cyBkb21haW4sIGFuZCANCmRvbWFp biBwYXJ0bmVycyB0cnVzdCBwbGVkZ2UuDQoNCjxLRU5UPiBUaGUgcGxlZGdlIHRydXN0cyB0aGUg TUFTQSAod2hpY2ggc2lnbnMgdGhlIHZvdWNoZXIpIGFuZCB0aGVuDQp0aGUgcGxlZGdlIHRydXN0 cyB0aGUgZG9tYWluICh3aG9zZSBjZXJ0IGlzIGluc2lkZSB0aGUgdm91Y2hlcikuDQpQZXJoYXBz IHlvdSdyZSBjb25mbGF0aW5nIHNpZ25pbmcgdGhlIHZvdWNoZXIgd2l0aCBhY2tub3dsZWRnaW5n DQpvd25lcnNoaXA/DQoNCg0KPj4gQWRkIHR5cGUgaW46DQo+PiBPd25lcnNoaXAgSUQgdm91Y2hl ciAidHlwZSIgaXMgbmFtZWQNCj4+IEJlYXJlciBWb3VjaGVyICJ0eXBlIiBpcyBuYW1lZA0KPiAN Cj4gPEtFTlQ+IHlvdSBvbmx5IG1lbnRpb24gdGhlc2UgdHdvLCBidXQgbm9uZSBvZiB0aGUgdm91 Y2hlciB0eXBlDQo+IGRlc2NyaXB0aW9ucyBoYXZlICJ0eXBlIiBpbiB0aGVtLCBvciBtYXliZSBJ J20gbWlzc2luZyBzb21ldGhpbmcuDQoNClRoZSBuYW1lIG9mIHRoZSB2b3VjaGVyIGlzIHRha2Vu IGZyb20gdGhlIHR5cGUgSSB1bmRlcnN0YW5kLg0KT25seSBvd25lcnNoaXAgSUQgdm91Y2hlciBh bmQgQmVhcmVyIHZvdWNoZXIgaGF2ZSB0ZXh0IHN0YXJ0aW5nIHdpdGggDQoieHh4eCBpcyBuYW1l ZCIuDQpJIHNlZSB0aGF0IEkgZm9yZ290OiBBbiBhdWRpdCB2b3VjaGVyICJ0eXBlIiBpcyBuYW1l ZCAuLi4uLg0KDQo8S0VOVD4gTWF4LCB0aGlzIGlzIHlvdXIgc2VjdGlvbiwgY2FuIHlvdSByZXBs eSB0byBQZXRlciBvbiB0aGlzPw0KDQoNCj4+IHNlY3Rpb24gNy4xIGxhc3QgbGluZTogInRoZXJl IGlzIGEgZGVsYXkiIGlzIHRoYXQgZGVsYXkgYmV0d2VlbiANCj4+IGNyZWF0aW9uDQo+PiBhbmQg Y29uc3VtcHRpb24gYW5kIHdoZW4gaXMgdGhlIGRlbGF5IHVuYWNjZXB0YWJsZT8gdGhlIHRleHQg aXMgKG9uDQo+PiBwdXJwb3NlPykgdmFndWUuDQo+IA0KPiA8S0VOVD4gVGhlIHByZXZpb3VzIHNl bnRlbmNlIHNheXMgIi4uLnRoZXJlIG1heSBiZSBhIHNpZ25pZmljYW50DQo+IGRlbGF5IGJldHdl ZW4gd2hlbiBhIHZvdWNoZXIgaXMgY3JlYXRlZCBhbmQgd2hlbiBpdCBpcyBjb25zdW1lZC4iDQo+ IGFuZCB0aGUgcmVtYWluZGVyIG9mIHRoZSBsaW5lIHlvdSdyZSBjaXRpbmcgc2F5cyAidG8gZW5z dXJlIHRoYXQNCj4gdGhlIGFzc2VydGlvbnMgbWFkZSB3aGVuIHRoZSB2b3VjaGVyIHdhcyBjcmVh dGVkIGFyZSBzdGlsbCB2YWxpZA0KPiB3aGVuIGl0IGlzIGNvbnN1bWVkLiIgICBUaGlzIGlzIHZh Z3VlPw0KDQpUbyBtZSB5ZXMuIEl0IHNvdW5kcyBsaWtlIGEgY2lyY3VsYXIgZGVmaW5pdGlvbi4N ClRvIHBhcmFwaHJhc2U6IFdoZW4gdGhlIHZvdWNoZXIgaXMgY29uc3VtZWQsIHRoZSBhc3NlcnRp b25zIGFyZSB2YWxpZCBieSANCmRlZmluaXRpb24uICAgSSB3b3VsZCBleHBlY3QgYSBwb2ludGVy IHRvIGEgZGVsYXkgZGVmaW5pdGlvbiBhbmQgdGhlbiBhbg0KYXNzZXJ0aW9uIHRoYXQgc3RhdGVz OiB3aGVuIGNvbnN1bXB0aW9uIHRpbWUgaXMgbGFyZ2VyIHRoYW4gdGhlIGNyZWF0aW9uIHRpbWUg KyBkZWxheSwgdGhlIHZvdWNoZXIgaXMgaW52YWxpZC4NCg0KPEtFTlQ+IEknbSBtb2RpZmllZCB0 aGUgcGFyYWdyYXBoIHNsaWdodGx5IChzL2RlbGF5L3RpbWUgZGVsYXkvICsgZW5kDQpvZiBsYXN0 IHNlbnRlbmNlKToNCg0KICAgVGhlIGxpZmV0aW1lcyBvZiB2b3VjaGVycyBtYXkgdmFyeS4gIElu IHNvbWUgYm9vdHN0cmFwcGluZyBwcm90b2NvbHMsDQogICB0aGUgdm91Y2hlcnMgbWF5IGJlIGNy ZWF0ZWQgYW5kIGNvbnN1bWVkIGltbWVkaWF0ZWx5IHdoZXJlYXMsIGluDQogICBvdGhlciBib290 c3RyYXBwaW5nIHNvbHV0aW9ucywgdGhlcmUgbWF5IGJlIGEgc2lnbmlmaWNhbnQgdGltZSBkZWxh eQ0KICAgYmV0d2VlbiB3aGVuIGEgdm91Y2hlciBpcyBjcmVhdGVkIGFuZCB3aGVuIGl0IGlzIGNv bnN1bWVkLiAgSW4gY2FzZXMNCiAgIHdoZW4gdGhlcmUgaXMgYSB0aW1lIGRlbGF5LCB0aGVyZSBp cyBhIG5lZWQgZm9yIHRoZSBwbGVkZ2UgdG8gZW5zdXJlDQogICB0aGF0IHRoZSBhc3NlcnRpb25z IG1hZGUgd2hlbiB0aGUgdm91Y2hlciB3YXMgY3JlYXRlZCBhcmUgc3RpbGwNCiAgIHZhbGlkLg0K DQphbmQgdGhlIDNyZCBwYXJhZ3JhcGgsIHRvIGNhbGwgb3V0IHRoZSAnZXhwaXJlcy1vbicgbGVh ZjoNCg0KICAgQWRkcmVzc2luZyB0aGUgc2hvcnQtY29taW5ncyBvZiByZXZvY2F0aW9ucywgdGhp cyBkb2N1bWVudCByZWNvbW1lbmRzDQogICBpbnN0ZWFkIHRoZSB1c2Ugb2YgbGlnaHR3ZWlnaHQg cmVuZXdhbHMgb2Ygc2hvcnQtbGl2ZWQgbm9uLXJldm9jYWJsZQ0KICAgdm91Y2hlcnMuICBUaGF0 IGlzLCByYXRoZXIgdGhhbiBpc3N1ZSBhIGxvbmctbGl2ZWQgdm91Y2hlciwgd2hlcmUgdGhlDQog ICAnZXhwaXJlcy1vbicgbGVhZiBpcyBzZXQgdG8gc29tZSBkaXN0YW50IGRhdGUsIHRoZSBleHBl Y3RhdGlvbiBpcyBmb3INCiAgIHRoZSBNQVNBIHRvIGluc3RlYWQgaXNzdWUgYSBzaG9ydC1saXZl ZCB2b3VjaGVyLCB3aGVyZSB0aGUgJ2V4cGlyZXMtDQogICBvbicgbGVhZiBpcyBzZXQgdG8gYSBy ZWxhdGl2ZWx5IG5lYXIgZGF0ZSwgYWxvbmcgd2l0aCBhIHByb21pc2UNCiAgIChyZWZsZWN0ZWQg aW4gdGhlICdsYXN0LXJlbmV3YWwtZGF0ZScgZmllbGQpIHRvIHJlLWlzc3VlIHRoZSB2b3VjaGVy DQogICBhZ2FpbiB3aGVuIG5lZWRlZC4gIEltcG9ydGFudGx5LCB3aGlsZSBpc3N1aW5nIHRoZSBp bml0aWFsIHZvdWNoZXINCg0KQmV0dGVyPw0KDQoNCktlbnQNCg0KDQo= From nobody Fri Aug 18 12:29:43 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68BE01321B8 for ; Fri, 18 Aug 2017 12:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3n3rRQXnMWF for ; Fri, 18 Aug 2017 12:29:38 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 E4FBF1321A6 for ; Fri, 18 Aug 2017 12:29:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id E3F0A62244; Fri, 18 Aug 2017 15:29:36 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id X10Jbf7w6M4P; Fri, 18 Aug 2017 15:29:29 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 0EB466223F; Fri, 18 Aug 2017 15:29:28 -0400 (EDT) To: Kent Watsen , "anima@ietf.org" References: <3a5adc64-1737-9ecc-5c13-b310b48c2ba0@htt-consult.com> <31E4D893-7438-4EF4-85DF-4F47D70FF3CF@juniper.net> From: Robert Moskowitz Message-ID: <5ae589f2-5524-df9c-cd18-d621e012749f@htt-consult.com> Date: Fri, 18 Aug 2017 15:29:26 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <31E4D893-7438-4EF4-85DF-4F47D70FF3CF@juniper.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Anima] creating iDevID certs with openssl X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 19:29:41 -0000 I want to share my work on building a generic ECDSA pki with an 802.1AR leaf. You can see my work at: http://www.htt-consult.com/pki.html I believe I have iDevID properly constructed, but I am not sure about hwSerailNumber plus its relationship to the DN's serialNumber. I am interested in feedback on this. I am willing to turn it into an ID. First I have to do CRL and OCSP support. openssl is NOT so easy to use for all this. :( Rich Salz and others on the openssl-user list were a great help. Bob On 08/16/2017 12:43 PM, Kent Watsen wrote: > Hi Bob, > > I'm watching this thread with interest. My take on this [1] is a little > different than yours, but I was just prototyping a rough solution, I > never took it to completion... > > [1] https://github.com/netconf-wg/zero-touch/blob/master/openssl-test/vendor/idevid-certificate-pki/intermediate-ca/openssl.cnf#L55 > > Kent > > -- > > Making some progress. > > > On 08/14/2017 01:44 PM, Robert Moskowitz wrote: >> I have just joined this list. So if this is covered in the archives >> anywhere, my weak search foo did not uncover it... >> >> Has anyone created iDevID certs with openssl including subjectAltName >> with hardwareModuleName? >> >> I have been working on this for a few days and have worked out HOW to >> even get certs to contain SAN, particularly going the csr route. I >> have learned on the openssl list that HMN is not directly supported >> and that you have to use othername. Something like >> >> [ req_ext ] >> subjectAltName = otherName:1.3.6.1.5.5.7.8.4;SEQ:hmodname >> >> [ hmodname ] >> hwType = OID:1.2.3.4 # Whatever OID you want. >> hwSerialNum = FORMAT:HEX,OCT:01020304 # Some hex > This produces a subjectAltName content of: > > 0:d=0 hl=2 l= 27 cons: SEQUENCE > 2:d=1 hl=2 l= 25 cons: cont [ 0 ] > 4:d=2 hl=2 l= 8 prim: OBJECT :1.3.6.1.5.5.7.8.4 > 14:d=2 hl=2 l= 13 cons: cont [ 0 ] > 16:d=3 hl=2 l= 11 cons: SEQUENCE > 18:d=4 hl=2 l= 3 prim: OBJECT :1.2.3.4 > 23:d=4 hl=2 l= 4 prim: OCTET STRING [HEX DUMP]:01020304 > > > I suspect that hwtype is a full vendor OID for registering this device. > Say my company, HTT Consulting makes sensor widgets. The OID for that > could be: > > 1.3.6.1.4.1.6715.10.1 (where 10 is HTT's devices and 1 is the sensor > widget). > >> But I am not sure what exactly to do with hwType and hwSerialNum >> >> Are there any extant examples? > So googling around for examples and not finding any. But then my search > foo has always been weak. > >> Currently there is no way to feed any SAN value in at the command like >> 'openssl req'. It has to go into the config file, so once I work out >> WHAT to but into these fields, I will have to do some kludgly stuff to >> stuff values into the config then run the command. There are examples >> of this around for SANs of IP, DNS, etc. >> >> BTW, so far I have a simple guide for making a pki of ECDSA certs >> using openssl. I would be willing to share what I have done todate. >> The 802.1AR cert section is understandably incomplete... >> >> Bob > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Mon Aug 21 00:37:12 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B734113291F; Mon, 21 Aug 2017 00:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qs8YItuFIbDd; Mon, 21 Aug 2017 00:37:01 -0700 (PDT) Received: from lb3-smtp-cloud9.xs4all.net (lb3-smtp-cloud9.xs4all.net [194.109.24.30]) (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 96E12132926; Mon, 21 Aug 2017 00:37:00 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:211]) by smtp-cloud9.xs4all.net with ESMTPA id jhGadHPCLdRLjjhGadi5Yz; Mon, 21 Aug 2017 09:36:58 +0200 Received: from ip565c6c1e.direct-adsl.nl ([86.92.108.30]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 21 Aug 2017 09:36:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 21 Aug 2017 09:36:55 +0200 From: peter van der Stok To: Kent Watsen Cc: consultancy@vanderstok.org, anima-chairs@ietf.org, 6tisch@ietf.org, netconf@ietf.org, anima@ietf.org, Sheng Jiang Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <8168023A-AC1F-4A7E-B8BA-026651EFEF33@juniper.net> References: <5D36713D8A4E7348A7E10DF7437A4B927CE3D826@NKGEML515-MBX.china.huawei.com> <76229c58f5d60d3a0c185c6645ba4355@xs4all.nl> <3F9D68E6-57C9-48EF-A4EB-3CA8B613D42D@juniper.net> <1fee7f82c855def7345d506fbb720dbc@xs4all.nl> <8168023A-AC1F-4A7E-B8BA-026651EFEF33@juniper.net> Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfKVxOchUAcQPO0lWmeROLpqCYU1XK6J4PVreOUm4jbZpUXdmglHiAY9oXaQEPJtSYmg93cLy3H2qEHs0pSH7oEw32FQlsO+aLrmo9mrk9SjuJmuL+qsZ Eiftn2NTfweBEXwHCN6epIYiT+uZprCOd/C1BX/IxkotfZpRn7zdufarhJHQhWdhl8+eFSVfut+DprQcmr7wIgYWmyYj4fvHtNBw1HbIyAZlDFfAxpwOC5U7 e+2FpQoZnuWLgY2fMwj3yASPQytxyLf+LGOW+fzKsEwvpV5Ybjtj0Di2D9H/KlH/zvUfOb0trVMAa9YB3rs3K/aKjm2INOIP1i9StzGEv8NJ/TVy3rzusyWv INzLHI+q8bAY/f+MhxPS3KIMDwS8G46ZR/jaMpR7hNnoD/UueAztB4HCNnDqfYBlLkx1E9vE Archived-At: Subject: Re: [Anima] [6tisch] [Netconf] Cross-WGs WGLC (second) on draft-ietf-anima-voucher-04 - Respond by Aug 08, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 07:37:04 -0000 Hi Kent, >>> Can a discussion section about "manufacturer additions" be >>> added. Pointing out the consequences for interoperability >>> when using "Augment" to add manufacturer specifics can be >>> helpful. >> >> I'm confused, which section does this comment regard? > > It refers to the document as a whole and especially section 7. > Usually, manufacturers want manufacturer-specific additions to > documents. > They may consider to use Augment for that purpose. > My suggestion is to discuss ways to add manufacturer additions to the > voucher and the consequences. > That may turn out to be a big NO-NO to manufacturer additions. > I think it would be worthwhile to point that out. > > Are you asking for the voucher to contain a node > called something like 'opaque' having YANG type 'anyData'? > A sanctioned place where the MASA can stash some extra > stuff not defined by this document? Recall that some of > the motivation for this work being standardized is to > enable inspection by intermediates, and while the opaque > data could be presented to a human, it might be base64 > data. Any concerns bout that? My suggestion is a discussion not a standardization. So, no additions to the voucher in this document. However, pointing out the base64 format would be helpful for those thinking about an addition with opaque. > >> page 4, Voucher: add: that "acknowledges ownership of the pledge and" >> indicates... >> >> what does "acknowledges ownership of the pledge" mean? how >> is it different than "indicates to a Pledge the cryptographic identity >> of the Domain it should trust"? > > Now I am confused. I thought it was 2 ways. Pledge trusts domain, and > domain partners trust pledge. > > The pledge trusts the MASA (which signs the voucher) and then > the pledge trusts the domain (whose cert is inside the voucher). > Perhaps you're conflating signing the voucher with acknowledging > ownership? I am afraid, that I made the voucher responsible for all keyinfra protocol objectives. Sorry, for the confusion. > > From nobody Mon Aug 21 08:50:30 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B0613213F; Mon, 21 Aug 2017 08:50:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150333062773.6857.3941034251634482441@ietfa.amsl.com> Date: Mon, 21 Aug 2017 08:50:27 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-voucher-05.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 15:50:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : Voucher Profile for Bootstrapping Protocols Authors : Kent Watsen Michael C. Richardson Max Pritikin Toerless Eckert Filename : draft-ietf-anima-voucher-05.txt Pages : 19 Date : 2017-08-21 Abstract: This document defines a strategy to securely assign a pledge to an owner, using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher". The voucher artifact is a YANG-defined JSON document that has (by default) been signed using a PKCS#7 structure. The voucher artifact is normally generated by the pledge's manufacturer or delegate (i.e. the Manufacturer Authorized Signing Authority). This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-voucher/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-voucher-05 https://datatracker.ietf.org/doc/html/draft-ietf-anima-voucher-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-voucher-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 21 08:53:09 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A28513213F; Mon, 21 Aug 2017 08:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.011 X-Spam-Level: X-Spam-Status: No, score=-3.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 4vKqtksR6Xv5; Mon, 21 Aug 2017 08:53:05 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0109.outbound.protection.outlook.com [104.47.33.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD3E9132026; Mon, 21 Aug 2017 08:53:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pytki0EiuGJ36EWRO2PDAeEwvuTS9sft70xTuIVPR6w=; b=Hcsvf3LEajESu1gR2a7xTZngXODk0AK/DrheNHFg4cqhbdUtecM9FbIUnXi2SZmnV6QdPJhVT+0iMnDiTGOsrqNt/B4EwM+z/qt6LnzXJsmYI3/dLI7qa/tGBiA1AfX7l1E62kp1OM4SFMKgpHlGzPq3EBGoTL2io5dgaCDgy5U= Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB2170.namprd05.prod.outlook.com (10.164.3.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.4; Mon, 21 Aug 2017 15:53:02 +0000 Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.1385.008; Mon, 21 Aug 2017 15:53:02 +0000 From: Kent Watsen To: "consultancy@vanderstok.org" CC: "anima-chairs@ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org>, "netconf@ietf.org" , "anima@ietf.org" , Sheng Jiang Thread-Topic: [6tisch] [Netconf] [Anima] Cross-WGs WGLC (second) on draft-ietf-anima-voucher-04 - Respond by Aug 08, 2017 Thread-Index: AdMKmFTPR22MviVNQvGwNG9FbFt4tQAG0+8AAvnwfwAAVqYFgAADVm+AAJM6s4AACPICgA== Date: Mon, 21 Aug 2017 15:53:02 +0000 Message-ID: <599334D6-083B-45B2-B3CB-0D048D2BAEAF@juniper.net> References: <5D36713D8A4E7348A7E10DF7437A4B927CE3D826@NKGEML515-MBX.china.huawei.com> <76229c58f5d60d3a0c185c6645ba4355@xs4all.nl> <3F9D68E6-57C9-48EF-A4EB-3CA8B613D42D@juniper.net> <1fee7f82c855def7345d506fbb720dbc@xs4all.nl> <8168023A-AC1F-4A7E-B8BA-026651EFEF33@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR0501MB2170; 6:i5lPY6YKR+ZSiZiYLFevsNIhiDjjsGgZk/eyhnag5z40+L9PlV2J9eOTxuBKnh+P0WepJZnDHTSXCWP0R2EEgMEr1qG9qbn8zxSuFXf19EeKGgTIsaMnCNO7pEqqHdEipTyGwbM27cNn1d1NCOlr7g7P1ONUVIoA8MUzceQHkjVzwxXn7zUb2IdOq4y+ApORiA9Dy8/paoA2u8wRE4enf4B/dvlz7dngQ7Lw9onbjziI1XKeMPocl7i9lnIAXV/+tFijnRhtob31UprYCzf3ds8egcAIjpOXOQX31WdLaqFVv4zwE3r9pPx4RT1oKlIoCUm0UDMTxbcP/1842lpvag==; 5:yOkTMQCtKbhzO6lHjeFALFoBa6GlTDMfKb5taawseC/3HOdoATrCtQexelJx01oNBHMfMk++pdm+1+PdphtriNJya7jBN/4kPMDh1yWsx0mKtE/FzB+cBFfV2LEWr/VexJgzesD1bXaVk0umdkPd0w==; 24:wVMMFD6zGpNUxVqiLW8EdToZKLMoPtZ+FS3+ySrbnjRCx6sGinBlptxBuK4hO9VZZvjeJiXCuEm4Gn1bS7BP7Pb7qiK8Bw7uoqlzHiPyOFQ=; 7:JX2juk1BOk5evGC+VCWNeowdvFde45n3NxChiUQVfYv277ofkJnmg86Gp6HmgGv7wlk50Icq+EVjeoG6jM8AUH+qjvKIbHz+06yXSNjwjxtgDWaNB4pkBZ3CRgzcm+ZhpL2urAHGP/AE8h6rY4QqMW7Y+87xtSP34ze3pMQG2PK74cUUATmk9UwZ5caoMa3WPmPXGiUSh6A6LYroMfvcMlYdd2HVzmhN5238mzDnsEk= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 2da59772-b817-4f03-9955-08d4e8acb481 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR0501MB2170; x-ms-traffictypediagnostic: CY1PR0501MB2170: x-exchange-antispam-report-test: UriScan:(60795455431006)(17755550239193); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6055026)(6041248)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123555025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR0501MB2170; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR0501MB2170; x-forefront-prvs: 040655413E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(199003)(43784003)(189002)(68736007)(81166006)(25786009)(83506001)(7736002)(105586002)(305945005)(83716003)(110136004)(8936002)(4326008)(3660700001)(230783001)(2900100001)(33656002)(2501003)(6246003)(106356001)(93886005)(8676002)(1730700003)(478600001)(36756003)(81156014)(2351001)(3846002)(66066001)(966005)(102836003)(6116002)(86362001)(82746002)(6306002)(2906002)(6506006)(53936002)(6486002)(77096006)(5660300001)(6436002)(229853002)(99286003)(6512007)(101416001)(2950100002)(5640700003)(6916009)(3280700002)(54906002)(54356999)(189998001)(97736004)(4001350100001)(50986999)(76176999)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB2170; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <66B6EA7E9F9E2E44B5158E44B15A2DD0@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Aug 2017 15:53:02.4306 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB2170 Archived-At: Subject: Re: [Anima] [6tisch] [Netconf] Cross-WGs WGLC (second) on draft-ietf-anima-voucher-04 - Respond by Aug 08, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 15:53:09 -0000 SGkgUGV0ZXIsDQoNClRoYW5rcywgSSB0aGluayB3ZSd2ZSByZWFjaGVkIGNsb3N1cmUuDQpQbGVh c2UgcmV2aWV3IHRoZSBkaWZmcyB0byB0aGUgbGF0ZXN0Lg0KDQogIGh0dHBzOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWFuaW1hLXZvdWNoZXItMDUNCg0KVGhhbmtzIGFn YWluLA0KS2VudA0KDQoNCi0tDQoNCkhpIEtlbnQsDQoNCj4+PiBDYW4gYSBkaXNjdXNzaW9uIHNl Y3Rpb24gYWJvdXQgIm1hbnVmYWN0dXJlciBhZGRpdGlvbnMiIGJlDQo+Pj4gYWRkZWQuIFBvaW50 aW5nIG91dCB0aGUgY29uc2VxdWVuY2VzIGZvciBpbnRlcm9wZXJhYmlsaXR5DQo+Pj4gd2hlbiB1 c2luZyAiQXVnbWVudCIgdG8gYWRkIG1hbnVmYWN0dXJlciBzcGVjaWZpY3MgY2FuIGJlDQo+Pj4g aGVscGZ1bC4NCj4+IA0KPj4gSSdtIGNvbmZ1c2VkLCB3aGljaCBzZWN0aW9uIGRvZXMgdGhpcyBj b21tZW50IHJlZ2FyZD8NCj4gDQo+IEl0IHJlZmVycyB0byB0aGUgZG9jdW1lbnQgYXMgYSB3aG9s ZSBhbmQgZXNwZWNpYWxseSBzZWN0aW9uIDcuDQo+IFVzdWFsbHksIG1hbnVmYWN0dXJlcnMgd2Fu dCBtYW51ZmFjdHVyZXItc3BlY2lmaWMgYWRkaXRpb25zIHRvDQo+IGRvY3VtZW50cy4NCj4gVGhl eSBtYXkgY29uc2lkZXIgdG8gdXNlIEF1Z21lbnQgZm9yIHRoYXQgcHVycG9zZS4NCj4gTXkgc3Vn Z2VzdGlvbiBpcyB0byBkaXNjdXNzIHdheXMgdG8gYWRkIG1hbnVmYWN0dXJlciBhZGRpdGlvbnMg dG8gdGhlDQo+IHZvdWNoZXIgYW5kIHRoZSBjb25zZXF1ZW5jZXMuDQo+IFRoYXQgbWF5IHR1cm4g b3V0IHRvIGJlIGEgYmlnIE5PLU5PIHRvIG1hbnVmYWN0dXJlciBhZGRpdGlvbnMuDQo+IEkgdGhp bmsgaXQgd291bGQgYmUgd29ydGh3aGlsZSB0byBwb2ludCB0aGF0IG91dC4NCj4gDQo+IDxLRU5U PiBBcmUgeW91IGFza2luZyBmb3IgdGhlIHZvdWNoZXIgdG8gY29udGFpbiBhIG5vZGUNCj4gY2Fs bGVkIHNvbWV0aGluZyBsaWtlICdvcGFxdWUnIGhhdmluZyBZQU5HIHR5cGUgJ2FueURhdGEnPw0K PiBBIHNhbmN0aW9uZWQgcGxhY2Ugd2hlcmUgdGhlIE1BU0EgY2FuIHN0YXNoIHNvbWUgZXh0cmEN Cj4gc3R1ZmYgbm90IGRlZmluZWQgYnkgdGhpcyBkb2N1bWVudD8gIFJlY2FsbCB0aGF0IHNvbWUg b2YNCj4gdGhlIG1vdGl2YXRpb24gZm9yIHRoaXMgd29yayBiZWluZyBzdGFuZGFyZGl6ZWQgaXMg dG8NCj4gZW5hYmxlIGluc3BlY3Rpb24gYnkgaW50ZXJtZWRpYXRlcywgYW5kIHdoaWxlIHRoZSBv cGFxdWUNCj4gZGF0YSBjb3VsZCBiZSBwcmVzZW50ZWQgdG8gYSBodW1hbiwgaXQgbWlnaHQgYmUg YmFzZTY0DQo+IGRhdGEuICBBbnkgY29uY2VybnMgYm91dCB0aGF0Pw0KDQo8cHZkcz4NCk15IHN1 Z2dlc3Rpb24gaXMgYSBkaXNjdXNzaW9uIG5vdCBhIHN0YW5kYXJkaXphdGlvbi4gU28sIG5vIGFk ZGl0aW9ucyB0byANCnRoZSB2b3VjaGVyIGluIHRoaXMgZG9jdW1lbnQuDQpIb3dldmVyLCBwb2lu dGluZyBvdXQgdGhlIGJhc2U2NCBmb3JtYXQgd291bGQgYmUgaGVscGZ1bCBmb3IgdGhvc2UgDQp0 aGlua2luZyBhYm91dCBhbiBhZGRpdGlvbiB3aXRoIG9wYXF1ZS4NCjwvcHZkcz4NCj4gDQo+PiBw YWdlIDQsIFZvdWNoZXI6IGFkZDogdGhhdCAiYWNrbm93bGVkZ2VzIG93bmVyc2hpcCBvZiB0aGUg cGxlZGdlIGFuZCINCj4+IGluZGljYXRlcy4uLg0KPj4gDQo+PiA8S0VOVD4gd2hhdCBkb2VzICJh Y2tub3dsZWRnZXMgb3duZXJzaGlwIG9mIHRoZSBwbGVkZ2UiIG1lYW4/ICBob3cNCj4+IGlzIGl0 IGRpZmZlcmVudCB0aGFuICJpbmRpY2F0ZXMgdG8gYSBQbGVkZ2UgdGhlIGNyeXB0b2dyYXBoaWMg aWRlbnRpdHkNCj4+IG9mIHRoZSBEb21haW4gaXQgc2hvdWxkIHRydXN0Ij8NCj4gDQo+IE5vdyBJ IGFtIGNvbmZ1c2VkLiBJIHRob3VnaHQgaXQgd2FzIDIgd2F5cy4gUGxlZGdlIHRydXN0cyBkb21h aW4sIGFuZA0KPiBkb21haW4gcGFydG5lcnMgdHJ1c3QgcGxlZGdlLg0KPiANCj4gPEtFTlQ+IFRo ZSBwbGVkZ2UgdHJ1c3RzIHRoZSBNQVNBICh3aGljaCBzaWducyB0aGUgdm91Y2hlcikgYW5kIHRo ZW4NCj4gdGhlIHBsZWRnZSB0cnVzdHMgdGhlIGRvbWFpbiAod2hvc2UgY2VydCBpcyBpbnNpZGUg dGhlIHZvdWNoZXIpLg0KPiBQZXJoYXBzIHlvdSdyZSBjb25mbGF0aW5nIHNpZ25pbmcgdGhlIHZv dWNoZXIgd2l0aCBhY2tub3dsZWRnaW5nDQo+IG93bmVyc2hpcD8NCg0KPHB2ZHM+DQpJIGFtIGFm cmFpZCwgdGhhdCBJIG1hZGUgdGhlIHZvdWNoZXIgcmVzcG9uc2libGUgZm9yIGFsbCBrZXlpbmZy YSANCnByb3RvY29sIG9iamVjdGl2ZXMuDQpTb3JyeSwgZm9yIHRoZSBjb25mdXNpb24uDQo8L3B2 ZHM+DQo+IA0KPiANCg0KDQo= From nobody Mon Aug 21 23:43:03 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3D01321A3; Mon, 21 Aug 2017 23:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 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 VmI1tibwVg8f; Mon, 21 Aug 2017 23:42:58 -0700 (PDT) Received: from lb3-smtp-cloud8.xs4all.net (lb3-smtp-cloud8.xs4all.net [194.109.24.29]) (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 2F79B132063; Mon, 21 Aug 2017 23:42:57 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:203]) by smtp-cloud8.xs4all.net with ESMTPA id k2tqdgfeQcQyLk2tqdc7FH; Tue, 22 Aug 2017 08:42:55 +0200 Received: from ip565c6c1e.direct-adsl.nl ([86.92.108.30]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 22 Aug 2017 08:42:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 22 Aug 2017 08:42:53 +0200 From: peter van der Stok To: Kent Watsen Cc: consultancy@vanderstok.org, anima-chairs@ietf.org, 6tisch@ietf.org, netconf@ietf.org, anima@ietf.org, Sheng Jiang Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <599334D6-083B-45B2-B3CB-0D048D2BAEAF@juniper.net> References: <5D36713D8A4E7348A7E10DF7437A4B927CE3D826@NKGEML515-MBX.china.huawei.com> <76229c58f5d60d3a0c185c6645ba4355@xs4all.nl> <3F9D68E6-57C9-48EF-A4EB-3CA8B613D42D@juniper.net> <1fee7f82c855def7345d506fbb720dbc@xs4all.nl> <8168023A-AC1F-4A7E-B8BA-026651EFEF33@juniper.net> <599334D6-083B-45B2-B3CB-0D048D2BAEAF@juniper.net> Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfDc8oNaiazrr/FhhBYnA0smw6VxESOwE9ynzDByo0WKkZMF42cA+cOyHal7SW+mk9WFaZRLI1zafhqBw2lxIcKQSsAwWOtl80m2gYt6JHtr92cKH5Q5K HRfVTsgDQ6kbBzmwDe/FPn1Y51P3rIHw0s7hM5n3qfmqYbuxQalxcGXrB+4wVPv++t+Yc6lT23s71ZDwrYu904l+7Nbr4ILFarf6Lg7pMNtgnaUiPu6Yhc0G m3tSepirBbcidR131Kj3qvktQTACbAO4Yl2+hRIW/lRinOD3Bz9Op51RLcxfcxcC Archived-At: Subject: Re: [Anima] [6tisch] [Netconf] Cross-WGs WGLC (second) on draft-ietf-anima-voucher-04 - Respond by Aug 08, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 06:43:02 -0000 Hi Kent, Thanks for your work, Peter Kent Watsen schreef op 2017-08-21 17:53: > Hi Peter, > > Thanks, I think we've reached closure. > Please review the diffs to the latest. > > https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-voucher-05 > > Thanks again, > Kent > > > -- > > Hi Kent, > >>>> Can a discussion section about "manufacturer additions" be >>>> added. Pointing out the consequences for interoperability >>>> when using "Augment" to add manufacturer specifics can be >>>> helpful. >>> >>> I'm confused, which section does this comment regard? >> >> It refers to the document as a whole and especially section 7. >> Usually, manufacturers want manufacturer-specific additions to >> documents. >> They may consider to use Augment for that purpose. >> My suggestion is to discuss ways to add manufacturer additions to the >> voucher and the consequences. >> That may turn out to be a big NO-NO to manufacturer additions. >> I think it would be worthwhile to point that out. >> >> Are you asking for the voucher to contain a node >> called something like 'opaque' having YANG type 'anyData'? >> A sanctioned place where the MASA can stash some extra >> stuff not defined by this document? Recall that some of >> the motivation for this work being standardized is to >> enable inspection by intermediates, and while the opaque >> data could be presented to a human, it might be base64 >> data. Any concerns bout that? > > > My suggestion is a discussion not a standardization. So, no additions > to > the voucher in this document. > However, pointing out the base64 format would be helpful for those > thinking about an addition with opaque. > >> >>> page 4, Voucher: add: that "acknowledges ownership of the pledge and" >>> indicates... >>> >>> what does "acknowledges ownership of the pledge" mean? how >>> is it different than "indicates to a Pledge the cryptographic >>> identity >>> of the Domain it should trust"? >> >> Now I am confused. I thought it was 2 ways. Pledge trusts domain, and >> domain partners trust pledge. >> >> The pledge trusts the MASA (which signs the voucher) and then >> the pledge trusts the domain (whose cert is inside the voucher). >> Perhaps you're conflating signing the voucher with acknowledging >> ownership? > > > I am afraid, that I made the voucher responsible for all keyinfra > protocol objectives. > Sorry, for the confusion. > >> >> > > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch From nobody Wed Aug 23 05:28:46 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF04D132964 for ; Wed, 23 Aug 2017 05:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2myG9Si5_Ec for ; Wed, 23 Aug 2017 05:28:41 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 8455B132992 for ; Wed, 23 Aug 2017 05:28:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 747FB615E4 for ; Wed, 23 Aug 2017 08:28:40 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 54za8PQp-3kB for ; Wed, 23 Aug 2017 08:28:35 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id C09E36210C for ; Wed, 23 Aug 2017 08:28:34 -0400 (EDT) From: Robert Moskowitz To: anima@ietf.org References: Message-ID: <581cee9d-2004-e684-45c3-404f5bbbe297@htt-consult.com> Date: Wed, 23 Aug 2017 08:28:17 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Anima] creating iDevID certs with openssl X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2017 12:28:45 -0000 I have updated my guide for building a little ECDSA pki, including iDevID certs. You can see it at: www.htt-consult.com/pki PEM works. DER does not work. I have been finding problems with openssl command line support for DER. Which brings up a question for this list: What format do you expect to see for: draft-ietf-anima-bootstrapping-keyinfra PEM or DER? PEM supports cert chains, DER does not. DER is nice and small for small devices. A PEM non-password P-256 private key object is 241 bytes. DER is 121 bytes (DER does not support encrypting the private key object). This is a real cost of secure storage for some devices. What format are the various bootstrap objects (eg vouchers)? Has anyone built any of these for PoC? On 08/14/2017 01:44 PM, Robert Moskowitz wrote: > I have just joined this list. So if this is covered in the archives > anywhere, my weak search foo did not uncover it... > > Has anyone created iDevID certs with openssl including subjectAltName > with hardwareModuleName? > > I have been working on this for a few days and have worked out HOW to > even get certs to contain SAN, particularly going the csr route. I > have learned on the openssl list that HMN is not directly supported > and that you have to use othername. Something like > > [ req_ext ] > subjectAltName = otherName:1.3.6.1.5.5.7.8.4;SEQ:hmodname > > [ hmodname ] > hwType = OID:1.2.3.4 # Whatever OID you want. > hwSerialNum = FORMAT:HEX,OCT:01020304 # Some hex > > But I am not sure what exactly to do with hwType and hwSerialNum > > Are there any extant examples? > > Currently there is no way to feed any SAN value in at the command like > 'openssl req'. It has to go into the config file, so once I work out > WHAT to but into these fields, I will have to do some kludgly stuff to > stuff values into the config then run the command. There are examples > of this around for SANs of IP, DNS, etc. > > BTW, so far I have a simple guide for making a pki of ECDSA certs > using openssl. I would be willing to share what I have done todate. > The 802.1AR cert section is understandably incomplete... > > Bob > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Wed Aug 23 20:23:09 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE236132814 for ; Wed, 23 Aug 2017 20:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GH1r9ZiLZV6w for ; Wed, 23 Aug 2017 20:23:05 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 919531321BE for ; Wed, 23 Aug 2017 20:23:05 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 73C00E1A7; Wed, 23 Aug 2017 23:26:08 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1CA56842A0; Wed, 23 Aug 2017 23:23:04 -0400 (EDT) From: Michael Richardson To: Robert Moskowitz cc: anima@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] creating iDevID certs with openssl X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 03:23:08 -0000 --=-=-= Content-Type: text/plain Robert Moskowitz wrote: > I have just joined this list. So if this is covered in the archives > anywhere, my weak search foo did not uncover it... > Has anyone created iDevID certs with openssl including subjectAltName with > hardwareModuleName? Not exactly, I was also adding my own PEN OID with the Serial Number. # the OID: 1.3.6.1.4.1.46930.1 is a Private Enterprise Number OID: # iso.org.dod.internet.private.enterprise . SANDELMAN=46930 . 1 # subjectAltName=otherName:1.2.3.4;UTF8:some other identifier I added: > [ req_ext ] > subjectAltName = otherName:1.3.6.1.5.5.7.8.4;SEQ:hmodname My ruby code looks like: # include the official HardwareModule OID: 1.3.6.1.5.5.7.8.4 @idevid.add_extension(ef.create_extension( "subjectAltName", sprintf("otherName:1.3.6.1.5.5.7.8.4;UTF8:%s", self.sanitized_eui64), false)) see: https://github.com/mcr/highway/blob/master/app/models/device.rb#L43 I include what I think is an IDevID for a device with EUI-48 12-00-00-66-4D-02. I'm not 100% sure that's a valid hwSerialNumber, which is why I had used my own OID :-) https://github.com/mcr/fountain/tree/master/spec/certs has the public key that signed the cert attached (and the cert as well) The thing I found impossible to do programmatically was to create the Registrar CA cert with the cmcRA bit set. I had to resort to configuration files like yours, see: https://github.com/mcr/fountain/blob/master/trialra.sh -----BEGIN CERTIFICATE----- MIICLTCCAbOgAwIBAgIBATAKBggqhkjOPQQDAjBNMRIwEAYKCZImiZPyLGQBGRYC Y2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHDAaBgNVBAMME1Vuc3RydW5n IEhpZ2h3YXkgQ0EwIBcNMTcwODI0MDI1MDI5WhgPMjk5OTEyMzEwMDAwMDBaMEsx EjAQBgoJkiaJk/IsZAEZFgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRlbG1hbjEa MBgGA1UEAwwRMTItMDAtMDAtNjYtNEQtMDIwVjAQBgcqhkjOPQIBBgUrgQQACgNC AASfhqT+9Zz3Zy2nKwIm1dm+rDZZJ7d+JuCzAu7B3VN2RZvwESyku+0rmNYfNkCB D9NejMCMEOuUAmvOgYirUj3Bo4GGMIGDMB0GA1UdDgQWBBSyfPSc8Zj02BLgEy9x sm9DApe7QzAJBgNVHRMEAjAAMCsGA1UdEQQkMCKgIAYJKwYBBAGC7lIBoBMMETEy LTAwLTAwLTY2LTRELTAyMCoGA1UdEQQjMCGgHwYIKwYBBQUHCASgEwwRMTItMDAt MDAtNjYtNEQtMDIwCgYIKoZIzj0EAwIDaAAwZQIwa2ZnBc85oOLibxoQSaV8g9aw uP8alLY8UNq+ysfgl1Iw2JeAsabxSBz/9nK7WgvUAjEA3dBLrp0RRuZfUTtkMCSG 5kbwg6A+R8yPAxGT7WVZeSlN2Xz9DX6FfPzRHv5QtOHz -----END CERTIFICATE----- -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmeRpcACgkQgItw+93Q 3WWtRgf+NYlwHX0a+L96BVzfICDVhmEDOSm069YEyB/iSEzIpx0DB26RDmSaPZ5f eFgjOt3rtomYz+o1qpMCuUYhR/VrYiS/Gl8i/9eEMvM+dLJTLxj/UbLMQsLqI8Vk +DlRtBBjNL+MzCqiVKJnWNrgKBqYVDFl+vFlSYXoYf/JrArCyMVH3XbICzVnjuq3 UXSkMSbHPUw0Mu4Xfya8abHNF1gyjJpwEor4WpSzpH2q6+XmbOCOWuNUD2mN8Gt7 3SPrl9JWfiLv4Eoqfw8ttMns4ryRRJE+H3ciGHf6UfNXF/j7XA2Lj5KxSOPcSoDh Qif1O1nAp0G/YdVQjTz4wiwEbIJZzA== =iITn -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 23 20:24:37 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 547A11321BE for ; Wed, 23 Aug 2017 20:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IpXOjL_9Ap6D for ; Wed, 23 Aug 2017 20:24:35 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCB93131D27 for ; Wed, 23 Aug 2017 20:24:34 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 59891E1A7; Wed, 23 Aug 2017 23:27:38 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 28468842A0; Wed, 23 Aug 2017 23:24:34 -0400 (EDT) From: Michael Richardson To: Robert Moskowitz cc: "anima\@ietf.org" In-Reply-To: <7a2bbf4e-e4f1-a0d0-690d-982ea22003bc@htt-consult.com> References: <3a5adc64-1737-9ecc-5c13-b310b48c2ba0@htt-consult.com> <31E4D893-7438-4EF4-85DF-4F47D70FF3CF@juniper.net> <7a2bbf4e-e4f1-a0d0-690d-982ea22003bc@htt-consult.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] creating iDevID certs with openssl X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 03:24:36 -0000 --=-=-= Content-Type: text/plain Robert Moskowitz wrote: > But I would like to put together a group that want to develop > this. There is no interest, but there is help, on the openssl-user > list. So, you mean something like "anima-implementers", or "idevid-hackers" or some list like that? Or a more formal group? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmeRvEACgkQgItw+93Q 3WXgMwf/frejeMEsDE3T4SKqToL9WJSxl0tSL64A2IA4STuoCqHCazNEAN0/qpYx 6fLiXhwIMzr8UX9/WC+2F9vvrfZLH9SDHAbvPq+i8E7Zeznf6+tFX/6FpoD665PP k+7jVmYyi+RWdbu42A0W9ynSDdAxOCiirrqViYS22P6GYAWdCNqADOiALIVDRBHo Kh0G+4/eIw9WTZBOIhnQaP66VP+UQewiYF7Cwt1Exs/83IOPE69lRFL020M0q5LG 9YH385hgyk9hbpwnnCgKlHFxe6fxeikD8m/L4Apdv3Z0LSQNIFoVGgZtGNGYRT2Z RtXtGh9KlvYXd9D3c9V4DbWrQJUlGA== =TUo8 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 23 20:45:40 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C081323A2 for ; Wed, 23 Aug 2017 20:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YsdfcSndJ9hP for ; Wed, 23 Aug 2017 20:45:36 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B71E712700F for ; Wed, 23 Aug 2017 20:45:36 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 19D58E20F; Wed, 23 Aug 2017 23:48:40 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CD885842A0; Wed, 23 Aug 2017 23:45:35 -0400 (EDT) From: Michael Richardson To: Robert Moskowitz cc: anima@ietf.org In-Reply-To: <581cee9d-2004-e684-45c3-404f5bbbe297@htt-consult.com> References: <581cee9d-2004-e684-45c3-404f5bbbe297@htt-consult.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] creating iDevID certs with openssl X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 03:45:38 -0000 --=-=-= Content-Type: text/plain Robert Moskowitz wrote: > PEM works. DER does not work. I have been finding problems with > openssl command line support for DER. Which brings up a question for > this list: > What format do you expect to see for: > draft-ietf-anima-bootstrapping-keyinfra > PEM or DER? > PEM supports cert chains, DER does not. I'm confused by this. PEM, to me, is base64 encoded DER, probably with the BEGIN CERTIFICATE stuff. If you are saying that PEM files can contain multiple certs, there are DER ways to that. TLS just concatenates I believe. Here is where you'd find objects in BRSKI: 1) TLS ClientCertificate. This should be just the IDevID blob, and in TLS, it's in DER format, if the Registrar needs anything else in the chain, it must chase them down itself. 2) TLS ServerCertificate. https://tools.ietf.org/html/rfc5246#section-7.4.2 Note: PKCS #7 [PKCS7] is not used as the format for the certificate vector because PKCS #6 [PKCS6] extended certificates are not used. Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task of parsing the list more difficult. 3) The plege's Voucher Request may be signed using JOSE (using the IDevID) The IDevID is not sent, it's the one from ClientCertificate. 4) The registar's Voucher Request may be signed using JOSE, using the Domain Owner's key. That might not be the same key the Registrar uses to form the EST connection to the MASA (if the Registrar uses client authentication at all). The Domain Owner is within the pinned-domain-cert field. We define it as being DER binary. In JSON format, that turns into base64 encoded. The reason we go there is that we do not want the ----BEGIN... stuff in there for JSON, in another encoding (CBOR), binary is just fine. 5) The resulting voucher also uses pinned-domain-cert as well, now signed by the MASA. > What format are the various bootstrap objects (eg vouchers)? Has > anyone built any of these for PoC? PoC? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmeS98ACgkQgItw+93Q 3WW5Dwf9FourcZQ6PAa/kXeEtBsOl+ZqCZHeF5jOmogP18xsje06XVr46v5xszec mvIIcdmsnf0OFZnDY2NKBgbN4+LiR6PIn++UVeNYk110qIKxt4GJTylcBI6DYNrh PDBnd7e7RfIQhG3Zl7AV5M3S54RY4oQpm3AfoM0/OlAT0Qe+wzksd/GTqEbzc0ui eRNASMwU7a8Zyu+tSAJCSWddtbcsUC4xdbn5abQmVkfUKI18V6BK+z+zZ5RceGK9 4Uf3/cdhFWMLbwFrb5/43V4XeCl4kWQD3z9z/C38rQZokbLiaLkzqB34M4Gc+qmm cYe0tKx9zkODOTo2QLrQPbzVg/AYbg== =t/2Z -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 24 03:02:41 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1DD1323A6 for ; Thu, 24 Aug 2017 03:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMN1PnsqJsU7 for ; Thu, 24 Aug 2017 03:02:36 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 94A8E126B71 for ; Thu, 24 Aug 2017 03:02:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 296C16218F; Thu, 24 Aug 2017 06:02:35 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Q4opop7ma6Ki; Thu, 24 Aug 2017 06:02:29 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 954B162165; Thu, 24 Aug 2017 06:02:26 -0400 (EDT) To: Michael Richardson Cc: anima@ietf.org References: <581cee9d-2004-e684-45c3-404f5bbbe297@htt-consult.com> <3748.1503546335@obiwan.sandelman.ca> From: Robert Moskowitz Message-ID: Date: Thu, 24 Aug 2017 06:02:21 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <3748.1503546335@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Anima] creating iDevID certs with openssl X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 10:02:39 -0000 On 08/23/2017 11:45 PM, Michael Richardson wrote: > Robert Moskowitz wrote: > > PEM works. DER does not work. I have been finding problems with > > openssl command line support for DER. Which brings up a question for > > this list: > > > What format do you expect to see for: > > draft-ietf-anima-bootstrapping-keyinfra > > > PEM or DER? > > > PEM supports cert chains, DER does not. > > I'm confused by this. > PEM, to me, is base64 encoded DER, probably with the BEGIN CERTIFICATE stuff. > If you are saying that PEM files can contain multiple certs, there are DER > ways to that. TLS just concatenates I believe. On the openssl-user list, the claim was made that concatinating DER certs for a cert chain like you do with PEM does not work with applications. You have to use PKCS#12, but that includes the private key and is passworded. I should be able to get the pointer to Viktor's post about this. > > Here is where you'd find objects in BRSKI: > > 1) TLS ClientCertificate. > This should be just the IDevID blob, and in TLS, it's in DER format, > if the Registrar needs anything else in the chain, it must chase them down > itself. > > 2) TLS ServerCertificate. > https://tools.ietf.org/html/rfc5246#section-7.4.2 > Note: PKCS #7 [PKCS7] is not used as the format for the certificate > vector because PKCS #6 [PKCS6] extended certificates are not used. > Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task > of parsing the list more difficult. > > 3) The plege's Voucher Request may be signed using JOSE (using the IDevID) > The IDevID is not sent, it's the one from ClientCertificate. > > 4) The registar's Voucher Request may be signed using JOSE, using the > Domain Owner's key. That might not be the same key the Registrar uses > to form the EST connection to the MASA (if the Registrar uses client > authentication at all). > The Domain Owner is within the pinned-domain-cert field. > We define it as being DER binary. In JSON format, that turns into base64 > encoded. The reason we go there is that we do not want the > ----BEGIN... stuff in there for JSON, in another encoding (CBOR), binary > is just fine. > > 5) The resulting voucher also uses pinned-domain-cert as well, now signed > by the MASA. > > > What format are the various bootstrap objects (eg vouchers)? Has > > anyone built any of these for PoC? > > PoC? > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > From nobody Fri Aug 25 06:36:51 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37378132BF0 for ; Fri, 25 Aug 2017 06:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 ccMClod6enui for ; Fri, 25 Aug 2017 06:36:47 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0127.outbound.protection.outlook.com [104.47.36.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91208132BED for ; Fri, 25 Aug 2017 06:36:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=htUskCnbfE9e28uQN/1lAk15UMGP6JKJk/fKTJx2yZg=; b=djuO9I6Ck7Tq2S94jaKekRIs2GfbErOGhZJOo0XEP3TApqPdSW/X1r+7TkaHSE6yvaA7nW1HWiLTBXoUZNqFO01lBv8ojvlB/8gSdyeoUFzp46F8t4u/PFzY0JLWWBP1zoIVlp22KrHir6HEk09Pp0igWIVACz+lpjQNvYUXrE8= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1252.namprd05.prod.outlook.com (10.160.183.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.2; Fri, 25 Aug 2017 13:36:46 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.20.0013.005; Fri, 25 Aug 2017 13:36:46 +0000 From: Kent Watsen To: Robert Moskowitz , Michael Richardson CC: "anima@ietf.org" Thread-Topic: [Anima] creating iDevID certs with openssl Thread-Index: AQHTFSUlAUd6DuxmKkeSAjMNgXmwoaKR7E2AgAEAS4CAAGlEgIABiy0A Date: Fri, 25 Aug 2017 13:36:45 +0000 Message-ID: <2FF545F0-6618-4CE3-8416-273A5EDD1C53@juniper.net> References: <581cee9d-2004-e684-45c3-404f5bbbe297@htt-consult.com> <3748.1503546335@obiwan.sandelman.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1252; 6:plwSTlDEhCxpBKFQfhjkCTxyQbiBuUDv+RGPiTq6w5HWCaWQhtTwDHDJNjVSCXrNHYR6cM0/v2hLNxqEaXusVuxi8btvVkFkrdTBvy247dygnwEwNq5Mfl4NqEtiTHBF+XHDWkZSvCr8i+884oB28lSpRNkSmC1BkddnJicqwS1VZbzP7Xk8NW3ksbzpar10G4PKlfVXmBcc/FlNtXbUMWKV3y1tzMI7KIcLb/Ywa7kiOyHnou11w9DIa/a2mBOThZXJcAtE866JQVjnQBdxS9AYgrCX0G0Cq79oY7lvlfp0q9bCoWTh9nlOfiR4fFzblg3feCSLgQwiRtAgpqQ0BA==; 5:rQ2UBtq43MZ0cC67Fp424YJjDLawZAusuduvuUP6Y132f/8COTUAQe05A7aX+hdkzEMnn62FGCytlGXAlAjTtqbeHkfyBQknO/ZXJpOfp8SRicycorDepy4YX44DHfmFg4vllEHWccs63czZTW85hw==; 24:8DfLgUYKbQbkKyZd5eBwu8GatSh5+UAvu1I1S8sjG6QGK0lzQU9a8g0eAOrPuWAGBKKBrQGmegyOEu2AoZk+kF1IRd2V+tn6zRoYAb0KOS4=; 7:3U2q3XS9vDfl6ZU6W3OmJUZefzvGY5+9255+xYtcy71WqT1uIcLi55D4EefhAiwdAs13ru3NYsmQvofgPFEdBuA3aC3mI4ZJ7Ogg6mrZeGv9BJCRpUaLPdeQ2peVI9NPeg0SZAt6RYRB/MyBMzQgin3Y0BRxJLJpSwxA9jBJsUk1cDwNXkf+uK9vxHGI0nBekp8j7E1sPwHO4ezyL/v1EHrgxy3cIkXiUYdlkDjFqtk= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 30109f4e-7a56-43a5-87bf-08d4ebbe5481 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1252; x-ms-traffictypediagnostic: BN3PR0501MB1252: x-exchange-antispam-report-test: UriScan:(166708455590820); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1252; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1252; x-forefront-prvs: 041032FF37 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(199003)(189002)(6436002)(8936002)(81166006)(8676002)(83506001)(83716003)(229853002)(2906002)(77096006)(6486002)(2900100001)(101416001)(76176999)(54356999)(50986999)(2950100002)(5660300001)(81156014)(105586002)(6506006)(3280700002)(106356001)(6116002)(102836003)(3660700001)(3846002)(53936002)(66066001)(36756003)(478600001)(6512007)(6306002)(33656002)(97736004)(6246003)(966005)(189998001)(99286003)(82746002)(86362001)(4326008)(14454004)(4001350100001)(68736007)(93886005)(7736002)(25786009)(305945005)(551544002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1252; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <92E6504E5EB8B1439466A171E5BCD0AF@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2017 13:36:45.9077 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1252 Archived-At: Subject: Re: [Anima] creating iDevID certs with openssl X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 13:36:50 -0000 DQoNCg0KDQo+IE9uIHRoZSBvcGVuc3NsLXVzZXIgbGlzdCwgdGhlIGNsYWltIHdhcyBtYWRlIHRo YXQgY29uY2F0aW5hdGluZyBERVIgDQo+IGNlcnRzIGZvciBhIGNlcnQgY2hhaW4gbGlrZSB5b3Ug ZG8gd2l0aCBQRU0gZG9lcyBub3Qgd29yayB3aXRoIA0KPiBhcHBsaWNhdGlvbnMuICBZb3UgaGF2 ZSB0byB1c2UgUEtDUyMxMiwgYnV0IHRoYXQgaW5jbHVkZXMgdGhlIHByaXZhdGUgDQo+IGtleSBh bmQgaXMgcGFzc3dvcmRlZC4gIEkgc2hvdWxkIGJlIGFibGUgdG8gZ2V0IHRoZSBwb2ludGVyIHRv IFZpa3RvcidzIA0KPiBwb3N0IGFib3V0IHRoaXMuDQoNCkNvbmNhdGVuYXRpbmcgUEVNIGVuY29k aW5ncyBpbnRvIGEgc2luZ2xlIGZpbGUgaXMgYSBoYWNrLCBhbGJlaXQgYSBzdXBlcg0KY29udmVu aWVudCBvbmUuICBJbnN0ZWFkIG9mIFBLQ1MjMTIsIGhhdmUgeW91IGxvb2tlZCBpbnRvIFBLQ1Mj Nz8gLSB0aGlzDQppcyB3aGF0IGlzIHVzZWQgaW4gdGhlIG5ldGNvbmYtemVyb3RvdWNoIGRyYWZ0 IGZvciBiaW5hcnkgY2VydGlmaWNhdGUNCmNoYWlucy4NCg0KDQo+IEhlcmUgaXMgd2hlcmUgeW91 J2QgZmluZCBvYmplY3RzIGluIEJSU0tJOg0KPg0KPiAxKSBUTFMgQ2xpZW50Q2VydGlmaWNhdGUu DQo+ICAgICBUaGlzIHNob3VsZCBiZSBqdXN0IHRoZSBJRGV2SUQgYmxvYiwgYW5kIGluIFRMUywg aXQncyBpbiBERVIgZm9ybWF0LA0KPiAgICAgaWYgdGhlIFJlZ2lzdHJhciBuZWVkcyBhbnl0aGlu ZyBlbHNlIGluIHRoZSBjaGFpbiwgaXQgbXVzdCBjaGFzZSB0aGVtIGRvd24NCj4gICAgIGl0c2Vs Zi4NCg0KRldJVywgdGhlIG5ldGNvbmYtemVyb3RvdWNoIGRyYWZ0IHNwZWNpZmllcyB0aGF0IHRo ZSBkZXZpY2UgcG9zc2Vzc2VzIHRoZQ0KSURldklEIGNlcnQgKmFuZCogYWxsIHRoZSBpbnRlcm1l ZGlhdGUgY2VydHMgbGVhZGluZyB0byB0aGUgbWFudWZhY3R1cmVyJ3MNCndlbGwta25vd24gdHJ1 c3QtYW5jaG9yLCBhbGwgb2Ygd2hpY2ggaXQgcHJvdmlkZXMgZHVyaW5nIGNyeXB0byBoYW5kc2hh a2UuDQoNCg0KPiAyKSBUTFMgU2VydmVyQ2VydGlmaWNhdGUuDQo+ICAgICBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjNTI0NiNzZWN0aW9uLTcuNC4yDQo+ICAgICAgIE5vdGU6IFBLQ1Mg IzcgW1BLQ1M3XSBpcyBub3QgdXNlZCBhcyB0aGUgZm9ybWF0IGZvciB0aGUgY2VydGlmaWNhdGUN Cj4gICAgICAgdmVjdG9yIGJlY2F1c2UgUEtDUyAjNiBbUEtDUzZdIGV4dGVuZGVkIGNlcnRpZmlj YXRlcyBhcmUgbm90IHVzZWQuDQo+ICAgICAgIEFsc28sIFBLQ1MgIzcgZGVmaW5lcyBhIFNFVCBy YXRoZXIgdGhhbiBhIFNFUVVFTkNFLCBtYWtpbmcgdGhlIHRhc2sNCj4gICAgICAgb2YgcGFyc2lu ZyB0aGUgbGlzdCBtb3JlIGRpZmZpY3VsdC4NCg0KSSBkb24ndCB1bmRlcnN0YW5kIGhvdyB0aGlz IHJlbGF0ZXMgdG8gUEtDUyM2LiAgVHJ1ZSBhYm91dCB0aGUgU0VULCBidXQgdGhpcw0KaXMgbWlu b3IgcmVsYXRpdmUgdG8gdGhlIHRyYWRlb2Zmcy4gIENhbiB5b3Ugc2F5IHNvbWUgbW9yZSBhYm91 dCB0aGlzPw0KDQoNCj4gMykgVGhlIHBsZWdlJ3MgVm91Y2hlciBSZXF1ZXN0IG1heSBiZSBzaWdu ZWQgdXNpbmcgSk9TRSAodXNpbmcgdGhlIElEZXZJRCkNCj4gICAgIFRoZSBJRGV2SUQgaXMgbm90 IHNlbnQsIGl0J3MgdGhlIG9uZSBmcm9tIENsaWVudENlcnRpZmljYXRlLg0KPg0KPiA0KSBUaGUg cmVnaXN0YXIncyBWb3VjaGVyIFJlcXVlc3QgbWF5IGJlIHNpZ25lZCB1c2luZyBKT1NFLCB1c2lu ZyB0aGUNCj4gICAgIERvbWFpbiBPd25lcidzIGtleS4gIFRoYXQgbWlnaHQgbm90IGJlIHRoZSBz YW1lIGtleSB0aGUgUmVnaXN0cmFyIHVzZXMNCj4gICAgIHRvIGZvcm0gdGhlIEVTVCBjb25uZWN0 aW9uIHRvIHRoZSBNQVNBIChpZiB0aGUgUmVnaXN0cmFyIHVzZXMgY2xpZW50DQo+ICAgICBhdXRo ZW50aWNhdGlvbiBhdCBhbGwpLg0KPiAgICAgVGhlIERvbWFpbiBPd25lciBpcyB3aXRoaW4gdGhl IHBpbm5lZC1kb21haW4tY2VydCBmaWVsZC4NCj4gICAgIFdlIGRlZmluZSBpdCBhcyBiZWluZyBE RVIgYmluYXJ5LiAgSW4gSlNPTiBmb3JtYXQsIHRoYXQgdHVybnMgaW50byBiYXNlNjQNCj4gICAg IGVuY29kZWQuICBUaGUgcmVhc29uIHdlIGdvIHRoZXJlIGlzIHRoYXQgd2UgZG8gbm90IHdhbnQg dGhlDQo+ICAgICAtLS0tQkVHSU4uLi4gc3R1ZmYgaW4gdGhlcmUgZm9yIEpTT04sIGluIGFub3Ro ZXIgZW5jb2RpbmcgKENCT1IpLCBiaW5hcnkNCj4gICAgIGlzIGp1c3QgZmluZS4NCg0KQ29ycmVj dCwgcHV0dGluZyBQRU0tdGV4dCBpbnRvIHByb3RvY29scyBpcyBpbmFwcHJvcHJpYXRlLg0KDQoN Cj4gNSkgVGhlIHJlc3VsdGluZyB2b3VjaGVyIGFsc28gdXNlcyBwaW5uZWQtZG9tYWluLWNlcnQg YXMgd2VsbCwgbm93IHNpZ25lZA0KPiAgICAgYnkgdGhlIE1BU0EuDQo+DQo+ICAgICAgPiBXaGF0 IGZvcm1hdCBhcmUgdGhlIHZhcmlvdXMgYm9vdHN0cmFwIG9iamVjdHMgKGVnIHZvdWNoZXJzKT8g IEhhcw0KPiAgICAgID4gYW55b25lIGJ1aWx0IGFueSBvZiB0aGVzZSBmb3IgUG9DPw0KPg0KPiBQ b0M/DQoNCkFyZW4ndCB0aGUgZm9ybWF0cyBkZWZpbmVkIGluIHRoZSBkcmFmdHM/ICBFLmcuLCB0 aGUgdm91Y2hlciBkcmFmdA0Kc2F5cyBpdOKAmXMgYSBQS0NTIzcuDQoNClJlZ2FyZGluZyBQb0Ms IGhlcmUncyBzb21lIGNvZGUgdG8gY3JlYXRlL3ZhbGlkYXRlIHZvdWNoZXJzOiANCmh0dHBzOi8v Z2l0aHViLmNvbS9uZXRjb25mLXdnL3plcm8tdG91Y2gvdHJlZS9tYXN0ZXIvb3BlbnNzbC10ZXN0 Lg0KDQoNCksuDQoNCg0KDQo= From nobody Fri Aug 25 10:46:46 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256E6132BD3 for ; Fri, 25 Aug 2017 10:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-ln0MNJ5QWV for ; Fri, 25 Aug 2017 10:46:39 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 45000132961 for ; Fri, 25 Aug 2017 10:46:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 2265762282; Fri, 25 Aug 2017 13:46:38 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pGI6SZ09mPmJ; Fri, 25 Aug 2017 13:46:30 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 269A86226D; Fri, 25 Aug 2017 13:46:28 -0400 (EDT) To: Kent Watsen , Michael Richardson Cc: "anima@ietf.org" References: <581cee9d-2004-e684-45c3-404f5bbbe297@htt-consult.com> <3748.1503546335@obiwan.sandelman.ca> <2FF545F0-6618-4CE3-8416-273A5EDD1C53@juniper.net> From: Robert Moskowitz Message-ID: <99b486aa-b1ec-d488-13f3-2f7bede32e88@htt-consult.com> Date: Fri, 25 Aug 2017 13:46:24 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <2FF545F0-6618-4CE3-8416-273A5EDD1C53@juniper.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Anima] creating iDevID certs with openssl X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 17:46:46 -0000 On 08/25/2017 09:36 AM, Kent Watsen wrote: > > > >> On the openssl-user list, the claim was made that concatinating DER >> certs for a cert chain like you do with PEM does not work with >> applications. You have to use PKCS#12, but that includes the private >> key and is passworded. I should be able to get the pointer to Viktor's >> post about this. > Concatenating PEM encodings into a single file is a hack, albeit a super > convenient one. Instead of PKCS#12, have you looked into PKCS#7? - this > is what is used in the netconf-zerotouch draft for binary certificate > chains. Please read: https://mta.openssl.org/pipermail/openssl-users/2017-August/006374.html VIktor gives his views of what works in the field. I have found Viktor to be a great help, and tends to really know what works. Besides on the openssl-user list, he is on the postfix-user list. > > >> Here is where you'd find objects in BRSKI: >> >> 1) TLS ClientCertificate. >> This should be just the IDevID blob, and in TLS, it's in DER format, >> if the Registrar needs anything else in the chain, it must chase them down >> itself. > FWIW, the netconf-zerotouch draft specifies that the device possesses the > IDevID cert *and* all the intermediate certs leading to the manufacturer's > well-known trust-anchor, all of which it provides during crypto handshake. Most systems running netconf have the storage capacity for this. I would think. In my auto meetings, many of the devices they are discussing do not have this option. > >> 2) TLS ServerCertificate. >> https://tools.ietf.org/html/rfc5246#section-7.4.2 >> Note: PKCS #7 [PKCS7] is not used as the format for the certificate >> vector because PKCS #6 [PKCS6] extended certificates are not used. >> Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task >> of parsing the list more difficult. > I don't understand how this relates to PKCS#6. True about the SET, but this > is minor relative to the tradeoffs. Can you say some more about this? > > >> 3) The plege's Voucher Request may be signed using JOSE (using the IDevID) >> The IDevID is not sent, it's the one from ClientCertificate. >> >> 4) The registar's Voucher Request may be signed using JOSE, using the >> Domain Owner's key. That might not be the same key the Registrar uses >> to form the EST connection to the MASA (if the Registrar uses client >> authentication at all). >> The Domain Owner is within the pinned-domain-cert field. >> We define it as being DER binary. In JSON format, that turns into base64 >> encoded. The reason we go there is that we do not want the >> ----BEGIN... stuff in there for JSON, in another encoding (CBOR), binary >> is just fine. > Correct, putting PEM-text into protocols is inappropriate. > > >> 5) The resulting voucher also uses pinned-domain-cert as well, now signed >> by the MASA. >> >> > What format are the various bootstrap objects (eg vouchers)? Has >> > anyone built any of these for PoC? >> >> PoC? > Aren't the formats defined in the drafts? E.g., the voucher draft > says it’s a PKCS#7. I think PKCS is mentioned twice in the bootstrap draft. Nothing about iDevID format, for example. 802.1AR does not say anything about iDevID (or lDevID) format. > Regarding PoC, here's some code to create/validate vouchers: > https://github.com/netconf-wg/zero-touch/tree/master/openssl-test. For next week. Bob From nobody Mon Aug 28 10:17:43 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2CE1326EC for ; Mon, 28 Aug 2017 10:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jaod_dlWFDfR for ; Mon, 28 Aug 2017 10:17:41 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BF50132942 for ; Mon, 28 Aug 2017 10:17:41 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id A60C9E19F; Mon, 28 Aug 2017 13:20:59 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D2FC88430C; Mon, 28 Aug 2017 13:17:39 -0400 (EDT) From: Michael Richardson To: Kent Watsen cc: Robert Moskowitz , "anima\@ietf.org" In-Reply-To: <2FF545F0-6618-4CE3-8416-273A5EDD1C53@juniper.net> References: <581cee9d-2004-e684-45c3-404f5bbbe297@htt-consult.com> <3748.1503546335@obiwan.sandelman.ca> <2FF545F0-6618-4CE3-8416-273A5EDD1C53@juniper.net> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] creating iDevID certs with openssl X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 17:17:43 -0000 --=-=-= Content-Type: text/plain Kent Watsen wrote: >> 2) TLS ServerCertificate. >> https://tools.ietf.org/html/rfc5246#section-7.4.2 Note: PKCS #7 >> [PKCS7] is not used as the format for the certificate vector because >> PKCS #6 [PKCS6] extended certificates are not used. Also, PKCS #7 >> defines a SET rather than a SEQUENCE, making the task of parsing the >> list more difficult. > I don't understand how this relates to PKCS#6. True about the SET, but > this is minor relative to the tradeoffs. Can you say some more about > this? I was simply quoting rfc5246. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmkUDMACgkQgItw+93Q 3WWoFgf/S7UA+xHewN8SsH9H12n5OMEA5Teea7kfxD+p681VQM3LdaLIPQtBAZVU TK4S4jPvG7O/sBIeI+JWnbZcjphc30h9wqK+hBAVREcKfzE8W3XQjaRCE6l8frcT ntfyelYqIX7sbKMPi1j48btp+Q3TjuxFDVsIgOmaltneE3lD2gNjYJQ9Pp6c4Px0 zuFMmAcXMOdzWzQ6JQ4uRNiJtY5+goFK5aPGxYwmCEdnJhJm2blG03F5qDeG5GyA 6kGjNpeXnPWKmaKFIybewHEEzGyewBYHBe6TF7Gj53DbvKoGftCrq7diIth8EwmD fG7Gxop2Tp2begDPvcFKlqjU3zFARg== =q1Ls -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 28 10:19:18 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 142A013293F for ; Mon, 28 Aug 2017 10:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSlTqoQ0Vzwn for ; Mon, 28 Aug 2017 10:19:16 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BC421326EC for ; Mon, 28 Aug 2017 10:19:16 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id B24932009E; Mon, 28 Aug 2017 13:22:35 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E03018430C; Mon, 28 Aug 2017 13:19:15 -0400 (EDT) From: Michael Richardson To: Robert Moskowitz cc: Kent Watsen , "anima\@ietf.org" In-Reply-To: <99b486aa-b1ec-d488-13f3-2f7bede32e88@htt-consult.com> References: <581cee9d-2004-e684-45c3-404f5bbbe297@htt-consult.com> <3748.1503546335@obiwan.sandelman.ca> <2FF545F0-6618-4CE3-8416-273A5EDD1C53@juniper.net> <99b486aa-b1ec-d488-13f3-2f7bede32e88@htt-consult.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] creating iDevID certs with openssl X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 17:19:18 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Robert Moskowitz wrote: >> Aren't the formats defined in the drafts? E.g., the voucher draft >> says it=E2=80=99s a PKCS#7. > I think PKCS is mentioned twice in the bootstrap draft. Nothing about > iDevID format, for example. 802.1AR does not say anything about iDev= ID > (or lDevID) format. BTW: Doesn't rfc2315 officially replaced PKCS7 from a reference point of vi= ew? =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmkUJMACgkQgItw+93Q 3WVjOgf8DQR8c5vZLTruP6JghLJU31i/jAct+x6BipIchH/GQ8XKSwoL2Jlu8GDi LrVjlNfxnVuUnEbI3J7EwW34K6/0yEQwKTnHH9cexrIVL4PS/Uc4lM3YuP0b3g6d a1GX3X64BmgDOlKc3cSqUahdGuK8gu84ynUaGZcG5cn2oiSCXrFTDBEhevknLxu2 ZavdgbtRcaRL8U39UlSsxfh/1BQe7L5zvHpnYUWnWlPC9eWKf8qHJMi0TsvhBG0I nBleg6/SPXKJB59xr7bV8MzRowpCtiZHzC+Qp3jTDt2D+m4ZNVsXK4r8MSsEgnNa RkvJS2jMVwDHTeXMXj8l4/EbGVbxwQ== =6P3a -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 28 11:29:00 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0875C132195 for ; Mon, 28 Aug 2017 11:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UONMq5MsHH8R for ; Mon, 28 Aug 2017 11:28:56 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 AD29B132153 for ; Mon, 28 Aug 2017 11:28:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 8E941621CF; Mon, 28 Aug 2017 14:28:55 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id KAXeBfK9AvNB; Mon, 28 Aug 2017 14:28:51 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id A2101621AE; Mon, 28 Aug 2017 14:28:50 -0400 (EDT) To: Michael Richardson Cc: Kent Watsen , "anima@ietf.org" References: <581cee9d-2004-e684-45c3-404f5bbbe297@htt-consult.com> <3748.1503546335@obiwan.sandelman.ca> <2FF545F0-6618-4CE3-8416-273A5EDD1C53@juniper.net> <99b486aa-b1ec-d488-13f3-2f7bede32e88@htt-consult.com> <14722.1503940755@obiwan.sandelman.ca> From: Robert Moskowitz Message-ID: <5f38a6c8-9b29-cc5b-6d18-d0c0a37e2bde@htt-consult.com> Date: Mon, 28 Aug 2017 14:28:47 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <14722.1503940755@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Anima] creating iDevID certs with openssl X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 18:28:59 -0000 On 08/28/2017 01:19 PM, Michael Richardson wrote: > Robert Moskowitz wrote: > >> Aren't the formats defined in the drafts? E.g., the voucher draft > >> says it’s a PKCS#7. > > > I think PKCS is mentioned twice in the bootstrap draft. Nothing about > > iDevID format, for example. 802.1AR does not say anything about iDevID > > (or lDevID) format. > > BTW: Doesn't rfc2315 officially replaced PKCS7 from a reference point of view? It does for IETFers, but not the rest of the world. Everyone will say PKCS#7. In fact IETFers don't refer to this as RFC2315 format... All 2315 means is we have a public long-lived source for how to build and parse PKCS#7. IMHO. And is it still working with current PKCS#7 content? Bob From nobody Tue Aug 29 13:31:53 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA8D8132D95 for ; Tue, 29 Aug 2017 13:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGtIDIv-OGYc for ; Tue, 29 Aug 2017 13:31:49 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78602132D91 for ; Tue, 29 Aug 2017 13:31:49 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C2852E1AB for ; Tue, 29 Aug 2017 16:35:11 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 209AD8430C for ; Tue, 29 Aug 2017 16:31:48 -0400 (EDT) From: Michael Richardson To: anima X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] two EST question/suggestions X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 20:31:51 -0000 --=-=-= Content-Type: text/plain Max, I suggest that we add some text to section 2 to indicate that BRSKI EST connections SHOULD be HTTP 1.1 persistent connections. I wrote: Establishment of the TLS connection for bootstrapping is as specified in EST section 4.1.1 "Bootstrap Distribution of CA Certificates" . While EST section 3.2 does not insist upon use of HTTP 1.1 persistent connections, BRSKI connections SHOULD use persistent connections. This is due to the provisional state that occurs in the TLS connection. The following extensions are added for automation: We may also want to say something about HTTP 2.0's multiplexed request/responses (I think we don't want them). I'm not sure exactly what the list of things we don't want yet, or how to express this. I am sure that we don't want QUIC (or SPDY) or other stuff like that! I don't know if the binary-ness of HTTP2 matters to use at all in the end, and we should just let that upgrade path simply proceeed. The other question is about the use of 102 Processing codes, and 201 Created codes. I think that we discussed making /requestvoucher more RESTful by returning a 201 Created, along with a Location: header, and decided against it. I think that I'm partly re-opening this question. (Shall I make it a ticket) The reason for my question is about Registrar->MASA interactions that need to occur, and timeouts that might occur. Returning a 201 Created pointing to a URL that could be used to retrieve the resulting voucher would provide a nice way to do things. If upon the pledge issuing the GET, the voucher still isn't ready, a 102 Processing code could be returned. I'm particularly concerned that the pledge not set too-short timeouts here, as the only recourse it would have is to close the connection. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmlzzMACgkQgItw+93Q 3WWaoQgAuxeFUO9FbiwaLitkdTu0iNJKX2jyz9IZTQohv3MZeUg4eTyZcPVpQNFB +XPTg9RoiUUz1nc09AnnfiPKqyi29tSo60UWk29LEy9elBXQxVBRWo0ct1SwUhPs YkXjA4pN8b85MM6EP+U3dY9uROR4f1vS4NHNcWu5UkGdjaEnf2toa63UdynnW5bp j1zCILGy0qeaNxScS6oCxekWa97hOtpzOptbBzy6r28iZ9M7ezbcCUd1O9BDoyku ohpKyUcPkHM4OH5ufV+DSGBS4X+Y5VyDQN0UJw0y2XJ8IbhD2979wtdgLCSkb7Gb MBXK1A4J0id52NZHGqkDBWOYFz4vpg== =nWMJ -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 30 07:07:02 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5BC132E6B for ; Wed, 30 Aug 2017 07:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1P7DH5EjkIVU for ; Wed, 30 Aug 2017 07:06:59 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 469A7132C2F for ; Wed, 30 Aug 2017 07:06:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 97FA7621A0 for ; Wed, 30 Aug 2017 10:06:58 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0rUs-MMUmCa3 for ; Wed, 30 Aug 2017 10:06:48 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 9987962161 for ; Wed, 30 Aug 2017 10:06:47 -0400 (EDT) To: anima From: Robert Moskowitz Message-ID: <9781d449-90a9-08ab-43d7-66a1b072de08@htt-consult.com> Date: Wed, 30 Aug 2017 10:06:45 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------86155ABCD2705F411E865AA9" Content-Language: en-US Archived-At: Subject: [Anima] New draft - Guide to creating an ECDSA pki X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 14:07:01 -0000 This is a multi-part message in MIME format. --------------86155ABCD2705F411E865AA9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I have created an ID with the steps to create an ECDSA pki including 802.1AR certs. I welcome your comments. In particular, I am not 100% that I have the SAN right: [ req_ext ] subjectAltName = otherName:1.3.6.1.5.5.7.8.4;SEQ:hmodname [ hmodname ] hwType = OID:$ENV::hwType hwSerialNum = FORMAT:HEX,OCT:$ENV::hwSerialNum Do take a look at Appendix A.3. -------- Forwarded Message -------- Subject: New Version Notification for draft-moskowitz-ecdsa-pki-00.txt Date: Wed, 30 Aug 2017 06:53:03 -0700 From: internet-drafts@ietf.org To: Robert Moskowitz , Liang Xia , Henk Birkholz , Liang Xia A new version of I-D, draft-moskowitz-ecdsa-pki-00.txt has been successfully submitted by Robert Moskowitz and posted to the IETF repository. Name: draft-moskowitz-ecdsa-pki Revision: 00 Title: Guide for building an ECC pki Document date: 2017-08-30 Group: Individual Submission Pages: 26 URL: https://www.ietf.org/internet-drafts/draft-moskowitz-ecdsa-pki-00.txt Status: https://datatracker.ietf.org/doc/draft-moskowitz-ecdsa-pki/ Htmlized: https://tools.ietf.org/html/draft-moskowitz-ecdsa-pki-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-ecdsa-pki-00 Abstract: This memo provides a guide for building a PKI (Public Key Infrastructure) using openSSL. All certificates in this guide are ECDSA, P-256, with SHA256 certificates. Along with common End Entity certificates, this guide provides instructions for creating IEEE 802.1AR [IEEE.802.1AR_2009] iDevID Secure Device certificates. 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 --------------86155ABCD2705F411E865AA9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I have created an ID with the steps to create an ECDSA pki including 802.1AR certs.

I welcome your comments.  In particular, I am not 100% that I have the SAN right:

[ req_ext ]
subjectAltName = otherName:1.3.6.1.5.5.7.8.4;SEQ:hmodname

[ hmodname ]
hwType = OID:$ENV::hwType
hwSerialNum = FORMAT:HEX,OCT:$ENV::hwSerialNum

Do take a look at Appendix A.3.




-------- Forwarded Message --------
Subject: New Version Notification for draft-moskowitz-ecdsa-pki-00.txt
Date: Wed, 30 Aug 2017 06:53:03 -0700
From: internet-drafts@ietf.org
To: Robert Moskowitz <rgm@labs.htt-consult.com>, Liang Xia <frank.xialiang@huawei.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, Liang Xia <Frank.xialiang@huawei.com> 


A new version of I-D, draft-moskowitz-ecdsa-pki-00.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name:		draft-moskowitz-ecdsa-pki
Revision:	00
Title:		Guide for building an ECC pki
Document date:	2017-08-30
Group:		Individual Submission
Pages:		26
URL:            https://www.ietf.org/internet-drafts/draft-moskowitz-ecdsa-pki-00.txt
Status:         https://datatracker.ietf.org/doc/draft-moskowitz-ecdsa-pki/
Htmlized:       https://tools.ietf.org/html/draft-moskowitz-ecdsa-pki-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-moskowitz-ecdsa-pki-00


Abstract:
   This memo provides a guide for building a PKI (Public Key
   Infrastructure) using openSSL.  All certificates in this guide are
   ECDSA, P-256, with SHA256 certificates.  Along with common End Entity
   certificates, this guide provides instructions for creating IEEE
   802.1AR [IEEE.802.1AR_2009] iDevID Secure Device certificates.

                                                                                  


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


--------------86155ABCD2705F411E865AA9-- From nobody Thu Aug 31 04:02:03 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D4B132D5D for ; Thu, 31 Aug 2017 04:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9r_fujd5vSNu for ; Thu, 31 Aug 2017 04:01:58 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3C6E132D4F for ; Thu, 31 Aug 2017 04:01:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML710-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DNQ97725; Thu, 31 Aug 2017 11:01:48 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 31 Aug 2017 12:01:47 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Thu, 31 Aug 2017 19:01:41 +0800 From: Sheng Jiang To: "anima@ietf.org" CC: "draft-ietf-anima-auotnomic-data-plane.authors@ietf.org" Thread-Topic: Review on draft-ietf-anima-auotnomic-data-plane-09 Thread-Index: AdMiSHjQMpRRgzBpQqO/ui3lCiSMRg== Date: Thu, 31 Aug 2017 11:01:25 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927CE86398@NKGEML515-MBX.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.119] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B927CE86398NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.59A7EC9D.0160, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 3aa212f9e5e9ee98ab47c169b7477386 Archived-At: Subject: [Anima] Review on draft-ietf-anima-auotnomic-data-plane-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 11:02:02 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B927CE86398NKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, authors of draft-ietf-anima-auotnomic-data-plane, I am doing a thorough review as the document shepherd with my ANIMA chair h= at on. Please address the below comments so that we could process this docu= ment further. This is a petty long document. Therefore, my review may be a = little bit disordered. Overall, I think this document has been in a good sh= arp although I cannot claim all my comments are minor. I believe they are n= ot difficult to address. In introduction section, it is better to reference the "Autonomic Control P= lane" definition & description in Section 5 of RFC7575, rather than "[RFC75= 75] calls it the 'Autonomic Control Plane'" . The ACP could actually be communication channel for both management and con= trol plane. So, the name seems be mis-leading. My understanding is that we = could not change the name in such late stage. But it worth to see more on t= his in the introduction, even in the abstract. "This document describes options for a ... ACP". I am confused by the word = "option". What option does it actually mean? At least, it is not clear from= the context. "It therefore remains operational even in...". My understanding for "it" is= the network, but from the context, my first expression for "it" is ACP. Used short for the first appearance, ANI, VRF, IKE, TLS/dTLS, SDN, NOC, OAM= , NMS, CA and although GRASP, BRSKI, EST, ULA, are defined in Section 2, bu= t their first appearance is before their terminologies. Section 2, "ACP provides secure zero-touch network wide IPv6 connectivity between devi= ces supporting it." This is not accurate. These two devices must be in the = same autonomic network. Actually, we did not define an important concept ye= t - the domain of autonomic network. We were always assume there is only on= e domain within the connectivity range or the autonomic network would natur= ally be separated by non-AN devices. But it would not always be the case if= AN technologies become widely deployed In Section 3, "certain AAA misconfigurations can lock an administrator out of a device", = I am not sure how ACP helps in this use case. It seems for me the only way = is to log in with another admin account, then change the misconfig. It is n= o different through normal data plane. This can still be recovered remotely= without ACP. "The ACP provides reachability that is largely independent of the data plan= e." Why "largely"? It implies that is still partially (maybe small proporti= on) dependent on the data plane. "ACP MUST NOT be tied to a particular protocol." ACP does need support from= some specific protocol, GRASP, IPv6. I am sure you did not mean them. But = the description should be improved to be more precise. "The ACP MUST provide security". I am not sure the "MUST". In many scenario= s, for example, some layer has very strong layer 2 security mechanism, or n= etwork with physics isolation/protection. The connectivity is the vital fun= ctionality that ACP could provide, while security provided by ACP is redund= ant or not necessary. "The default mode of operation of the ACP is hop-by-hop." I guess you mean = "basic" or "fundamental" rather than "default". The multiple connectivity i= s made up by hop-by-hop connections. " ULA "Unique Local Address". The IPv6 equivalent to RFC1918 IPv4 addresse= s. ACP addresses are ULA."Please don't consider ULA as an equivalent to RF= C1918. We used to have relevant discussion in v6ops WG, and people had stro= ng consensus on ULAs !=3D RFC1918. (see https://tools.ietf.org/html/draft-i= etf-v6ops-ula-usage-considerations-02#section-3.1) The content of section 3.3 reads like the essential benefit rather than a s= pecific use case, especially comparing to Section 3.1 and 3.2. More proper = place for this may be Section 9 (Benefits). "ACP loopback interface" and "ACP virtual interface" refer to different thi= ngs as defined in the Terminology section. However, in the main text, somet= imes they are mixed together ((E.g. in section 5, Item 5 and 6). Either the= y should be used in a canonical way in this document, or other more disting= uished terminologies should be used to refer the two things. The terminology "ACP connect" same not proper. It would be more proper to c= all the connect/channel for non-ACP device joining the ACP through an ACP d= evice "ACP bridge"? In section 6, Initially, it must have a ... as well as an adjacency table."The word here = is misleading. The authors should mean the functionality of an adjacency ta= ble. But it reads like an adjacency table with already learned neighbor inf= ormation. Inadvert -> inadvertent The term "Autonomic Domain" first appears at section 6.1, it should be defi= ned in section 3. acp-address within ACP information should be optional. It may be the addres= s is generated by AN after getting the domain certificate. It is worthy to clarify that although the LDevID contains ACP-information, = it is not specific for ACP only; it is generic for other functions that req= uest node-level authentication. "To establish an ACP securely, an ACP device MUST have a globally unique do= main certificate (LDevID)"I think the requirement in this sentence is too s= trong in two perspective: why globally unique, secondly it is not necessary= to be a domain certificate that newly assigned in this domain. Furthermore= , this seems imply ACP depend on BRSKI as pre-step, which I don't think is = in authors original meaning. "The ACP network MUST have one or more nodes that support EST server throug= h which ACP nodes can renew their domain certificate." The work "MUST" is f= ar too strong here. "it should choose am FQDN" -> it should choose "an" FQDN "The format of the rfc822Name is choosen" -> The format of the rfc822Name i= s "chosen". There are another 4 instance of "choosen". "The loop-count MUST be sete to 255" -> The loop-count MUST be "set" to 255 "When it is time for domain certificate reneal" -> When it is time for doma= in certificate "renewal" "the primarily imiting factor for shorter certificate lifetimes", my guess = is "limiting" "the assigning CA has enough performance" -> the assigning CA has enough "p= erformance" "See Section 10.1 for further optimizationss" -> See Section 10.1 for furth= er "optimizations" The first sentence of section 6.3, "Because of the the considerations", th= e second "the"should be deleted "ACP discovery MUST NOT be enabled by default on any non-physical interface= s." This seems rule out the possibility of applying ACP with virtual device= s. My suggestion would be deleted the sentence since we ready have the foll= ow up sentence "ACP discovery MUST NOT run inside the ACP." Or not deleting= , we should at least soften it to be "SHOULD NOT". Section 6.5, "the next step after discoving" -> the next step after "discovering" "The roles of Bob abd Alice" -> The roles of Bob "and" Alice "It is not up to Alice to devide" -> It is not up to Alice to "divide" "interfaces are the ame devices" -> interfaces are the "same" devices Section 6.6, "certificate must be valid occording to"-> certificate must be valid "accor= ding" to Section 6.7, "the ACP secure channel protocol" -> the ACP secure channel "protocol" "ACP mechanisms they support" -> ACP mechanisms they "support" "ACP secure channel MUST imediately be terminated" -> ACP secure channel MU= ST "immediately" be terminated "Note that is is not standard behavior" -> Note that is not standard behavi= or Section 6.8, "Authentication is via the the domain" -> Authentication is via the domain Section 6.10, "65536 different virtualized adddresses" -> 65536 different virtualized "ad= dresses" Section 6.11, on-RPL-aware leafs (or "Internet") accoding to -> on-RPL-aware leafs (or "I= nternet") "according" to "the ACP will only accommodate" -> the ACP will only "accommodate" Routeable - > routable; at least two instances "The multi-access ACP virtual interace" -> The multi-access ACP virtual "in= terface" Thanks for your hand work and good contribution to the ANIMA group. Regards, Sheng --_000_5D36713D8A4E7348A7E10DF7437A4B927CE86398NKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, authors of draft-ietf-an= ima-auotnomic-data-plane,

 

I am doing a thorough review= as the document shepherd with my ANIMA chair hat on. Please address the be= low comments so that we could process this document further. This is a pett= y long document. Therefore, my review may be a little bit disordered. Overall, I think this document has been in= a good sharp although I cannot claim all my comments are minor. I believe = they are not difficult to address.

 

In introduction section, it = is better to reference the "Autonomic Control Plane" definition &= amp; description in Section 5 of RFC7575, rather than “[RFC7575] calls it the ‘Autonomic Control Plane’” .

 

The ACP could actually be co= mmunication channel for both management and control plane. So, the name see= ms be mis-leading. My understanding is that we could not change the name in= such late stage. But it worth to see more on this in the introduction, even in the abstract.<= /p>

 

“This document describ= es options for a … ACP”.= I am confused by the word “option”. What option does it actually mean? At least, it is not clear from the co= ntext.

 

“It therefore remains = operational even in…”. My understan= ding for “it” is= the network, but from the context, my first expression for “it” is= ACP.

 

Used short for the first app= earance, ANI, VRF, IKE, TLS/dTLS, SDN, NOC, OAM, NMS, CA and although GRASP= , BRSKI, EST, ULA, are defined in Section 2, but their first appearance is = before their terminologies.

 

Section 2,=

 

“ACP provides secure z= ero-touch network wide IPv6 connectivity between devices supporting it.” This is not accurate. These two devices mus= t be in the same autonomic network. Actually, we did not define an importan= t concept yet – the domain of autonomic network. We wer= e always assume there is only one domain within the connectivity range or t= he autonomic network would naturally be separated by non-AN devices. But it= would not always be the case if AN technologies become widely deployed

 

In Section 3,

 

“certain AAA misconfig= urations can lock an administrator out of a device”, I am not sure how ACP helps in this use case. It seems for me = the only way is to log in with another admin account, then change the misconfig. It is no different through normal data plane. T= his can still be recovered remotely without ACP.

 

“The ACP provides reac= hability that is largely independent of the data plane.” Why “largely”? It implies that is still partially (maybe small proportion) dependent o= n the data plane.

 

“ACP MUST NOT be tied = to a particular protocol.” ACP does need = support from some specific protocol, GRASP, IPv6. I am sure you did not mea= n them. But the description should be improved to be more precise.

 

“The ACP MUST provide = security”. I am not sure the “MUST”.= In many scenarios, for example, some layer has very strong layer 2 securit= y mechanism, or network with physics isolation/protection. The connectivity= is the vital functionality that ACP could provide, while security provided by ACP is redundant or not necessary. <= /span>

 

“The default mode of o= peration of the ACP is hop-by-hop.” I gue= ss you mean “basic”= or “fundamental” rather than “default”. The multiple connectivity is made up by hop-by-hop connections.

 

“ ULA "Unique Loc= al Address".  The IPv6 equivalent to RFC1918 IPv4 addresses. = ; ACP addresses are ULA.”Please don’t consider ULA as an equiva= lent to RFC1918. We used to have relevant discussion in v6ops WG, and peopl= e had strong consensus on ULAs !=3D RFC1918. (see https://tools.ietf.or= g/html/draft-ietf-v6ops-ula-usage-considerations-02#section-3.1)=

 

The content of section 3.3 r= eads like the essential benefit rather than a specific use case, especially= comparing to Section 3.1 and 3.2. More proper place for this may be Sectio= n 9 (Benefits).

 

“ACP loopback interface= &= #8221; and &= #8220;ACP virtual interface” refer to different things as defined in the Terminology sect= ion. However, in the main text, sometimes they are mixed together ((E.g. in sec= tion 5, Item 5 and 6). Either they should be used in a canonical way in thi= s document, or other more distinguished terminologies should be used to ref= er the two things.

 

The terminology “ACP connect” same no= t proper. It would be more proper to call the connect/channel for non-ACP device joi= ning the ACP through an ACP device &= #8220;ACP bridge”?

 

In section 6,

 

Initially, it must have a &#= 8230; as well as an adjacency table.”The word here is misleading. The= authors should mean the functionality of an adjacency table. But it reads = like an adjacency table with already learned neighbor information.

 

Inadvert -> inadvertent

 

The term “Autonomic Do= main” first appears at section 6.1, it should be defined in section 3= .

 

acp-address within ACP infor= mation should be optional. It may be the address is generated by AN after g= etting the domain certificate.

 

It is worthy to clarify that= although the LDevID contains ACP-information, it is not specific for ACP o= nly; it is generic for other functions that request node-level authenticati= on.

 

“To establish an ACP s= ecurely, an ACP device MUST have a globally unique domain certificate (LDev= ID)”I think the requirement in this sentence is too strong in two per= spective: why globally unique, secondly it is not necessary to be a domain certificate that newly assigned in this domain. F= urthermore, this seems imply ACP depend on BRSKI as pre-step, which I don&#= 8217;t think is in authors original meaning.

 

“The ACP network MUST h= ave one or more nodes that support EST server through which ACP nodes can r= enew their domain certificate.” The work “MUST” is far too strong here.

 

“it should choose am FQDN” -> it should choose &#= 8220;an” FQDN

 

“The format of the rfc= 822Name is choosen” -> The format of the rfc822Name is “chos= en”. There are another 4 instance of “choosen”.

 

“The loop-count MUST b= e sete to 255” -> The loop-count MUST be “set” to 255<= o:p>

 

“When it is time for d= omain certificate reneal” -> When it is time for domain certificat= e “renewal”

 

“the primarily imiting factor for shorter certificate lifetimes̶= 1;, my guess is “limiting”

 

“the assigning CA has = enough performance” -> the assigning CA has enough “performa= nce”

 

“See Section 10.1 for = further optimizationss” -> See Section 10.1 for further “opt= imizations”

 

The first sentence of  = section 6.3, “Because of the the considerations”, the second &#= 8220;the”should be deleted

 

“ACP discovery MUST NO= T be enabled by default on any non-physical interfaces.” This seems rule out the poss= ibility of applying ACP with virtual devices. My suggestion would be delete= d the sentence since we ready have the follow up sentence “ACP discovery MUST NOT run inside the ACP.” Or not deleting, we should at = least soften it to be “SHOULD NOT”.

 

Section 6.5,

 

“the next step after discoving” -> the next step after= “discovering”

 

“The roles of Bob abd = Alice” -> The roles of Bob “and” Alice

 

“It is not up to Alice= to devide” -> It is not up to Alice to “divide”<= /o:p>

 

“interfaces are the am= e devices” -> interfaces are the “same” devices

 

Section 6.6,

 

“certificate must be v= alid occording to”-> certificate must be valid “according= 221; to

 

Section 6.7,

 

“the ACP secure channel protocol” -> the ACP secure channel = “protocol”

 

“ACP mechanisms they s= upport” -> ACP mechanisms they “support”

 

“ACP= secure channel MUST imediately be terminated” -> ACP secure chann= el MUST “immediately” be terminated

 

“Note that is is not s= tandard behavior” -> Note that is not standard behavior=

 

Section 6.8,

 

“Authentication is via= the the domain” -> Authentication is via the domain

 

Section 6.10,

 

“65536 different virtu= alized adddresses” -> 65536 different virtualized “addresses”

 

Section 6.11,

 

on-RPL-aware leafs (or "= ;Internet") accoding to -> on-RPL-aware leafs (or "Internet&qu= ot;) “according” to

 

“the ACP will only acc= ommodate” -> the ACP will only “accommodate”

 

Routeable - > routable; a= t least two instances

 

“The multi-access ACP virtual interace” -> The multi-access AC= P virtual “interface”

 

Thanks for your hand work an= d good contribution to the ANIMA group.

 

Regards,

 

Sheng=

--_000_5D36713D8A4E7348A7E10DF7437A4B927CE86398NKGEML515MBXchi_-- From nobody Thu Aug 31 18:21:55 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78662132E55; Thu, 31 Aug 2017 18:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.117 X-Spam-Level: X-Spam-Status: No, score=-4.117 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=0.093, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iyvf5nO33hPM; Thu, 31 Aug 2017 18:21:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B83D132F2E; Thu, 31 Aug 2017 18:21:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DUO12005; Fri, 01 Sep 2017 01:21:47 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 1 Sep 2017 02:21:46 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Fri, 1 Sep 2017 09:21:42 +0800 From: Sheng Jiang To: "anima@ietf.org" CC: "draft-ietf-anima-autonomic-control-plane.authors@ietf.org" , "anima-chairs@ietf.org" Thread-Topic: Review on draft-ietf-anima-autonomic-control-plane-09 Thread-Index: AQHTIsCrTg9CrwO2e0yFjZhb5671Kw== Date: Fri, 1 Sep 2017 01:21:25 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927CE869BC@NKGEML515-MBX.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B927CE86398@NKGEML515-MBX.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B927CE86398@NKGEML515-MBX.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.119] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B927CE869BCNKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.59A8B62C.000B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: fcc27eaab1cb03717a81c2d1896d0199 Archived-At: Subject: Re: [Anima] Review on draft-ietf-anima-autonomic-control-plane-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 01:21:55 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B927CE869BCNKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Somehow, I don't know how, I misspelled the name of the draft. Resend my re= view comments with the right name in title and to the right authors alias. Sheng From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Sheng Jiang Sent: Thursday, August 31, 2017 7:01 PM To: anima@ietf.org Cc: draft-ietf-anima-auotnomic-data-plane.authors@ietf.org Subject: [Anima] Review on draft-ietf-anima-auotnomic-data-plane-09 Hi, authors of draft-ietf-anima-auotnomic-data-plane, I am doing a thorough review as the document shepherd with my ANIMA chair h= at on. Please address the below comments so that we could process this docu= ment further. This is a petty long document. Therefore, my review may be a = little bit disordered. Overall, I think this document has been in a good sh= arp although I cannot claim all my comments are minor. I believe they are n= ot difficult to address. In introduction section, it is better to reference the "Autonomic Control P= lane" definition & description in Section 5 of RFC7575, rather than "[RFC75= 75] calls it the 'Autonomic Control Plane'" . The ACP could actually be communication channel for both management and con= trol plane. So, the name seems be mis-leading. My understanding is that we = could not change the name in such late stage. But it worth to see more on t= his in the introduction, even in the abstract. "This document describes options for a ... ACP". I am confused by the word = "option". What option does it actually mean? At least, it is not clear from= the context. "It therefore remains operational even in...". My understanding for "it" is= the network, but from the context, my first expression for "it" is ACP. Used short for the first appearance, ANI, VRF, IKE, TLS/dTLS, SDN, NOC, OAM= , NMS, CA and although GRASP, BRSKI, EST, ULA, are defined in Section 2, bu= t their first appearance is before their terminologies. Section 2, "ACP provides secure zero-touch network wide IPv6 connectivity between devi= ces supporting it." This is not accurate. These two devices must be in the = same autonomic network. Actually, we did not define an important concept ye= t - the domain of autonomic network. We were always assume there is only on= e domain within the connectivity range or the autonomic network would natur= ally be separated by non-AN devices. But it would not always be the case if= AN technologies become widely deployed In Section 3, "certain AAA misconfigurations can lock an administrator out of a device", = I am not sure how ACP helps in this use case. It seems for me the only way = is to log in with another admin account, then change the misconfig. It is n= o different through normal data plane. This can still be recovered remotely= without ACP. "The ACP provides reachability that is largely independent of the data plan= e." Why "largely"? It implies that is still partially (maybe small proporti= on) dependent on the data plane. "ACP MUST NOT be tied to a particular protocol." ACP does need support from= some specific protocol, GRASP, IPv6. I am sure you did not mean them. But = the description should be improved to be more precise. "The ACP MUST provide security". I am not sure the "MUST". In many scenario= s, for example, some layer has very strong layer 2 security mechanism, or n= etwork with physics isolation/protection. The connectivity is the vital fun= ctionality that ACP could provide, while security provided by ACP is redund= ant or not necessary. "The default mode of operation of the ACP is hop-by-hop." I guess you mean = "basic" or "fundamental" rather than "default". The multiple connectivity i= s made up by hop-by-hop connections. " ULA "Unique Local Address". The IPv6 equivalent to RFC1918 IPv4 addresse= s. ACP addresses are ULA."Please don't consider ULA as an equivalent to RF= C1918. We used to have relevant discussion in v6ops WG, and people had stro= ng consensus on ULAs !=3D RFC1918. (see https://tools.ietf.org/html/draft-i= etf-v6ops-ula-usage-considerations-02#section-3.1) The content of section 3.3 reads like the essential benefit rather than a s= pecific use case, especially comparing to Section 3.1 and 3.2. More proper = place for this may be Section 9 (Benefits). "ACP loopback interface" and "ACP virtual interface" refer to different thi= ngs as defined in the Terminology section. However, in the main text, somet= imes they are mixed together ((E.g. in section 5, Item 5 and 6). Either the= y should be used in a canonical way in this document, or other more disting= uished terminologies should be used to refer the two things. The terminology "ACP connect" same not proper. It would be more proper to c= all the connect/channel for non-ACP device joining the ACP through an ACP d= evice "ACP bridge"? In section 6, Initially, it must have a ... as well as an adjacency table."The word here = is misleading. The authors should mean the functionality of an adjacency ta= ble. But it reads like an adjacency table with already learned neighbor inf= ormation. Inadvert -> inadvertent The term "Autonomic Domain" first appears at section 6.1, it should be defi= ned in section 3. acp-address within ACP information should be optional. It may be the addres= s is generated by AN after getting the domain certificate. It is worthy to clarify that although the LDevID contains ACP-information, = it is not specific for ACP only; it is generic for other functions that req= uest node-level authentication. "To establish an ACP securely, an ACP device MUST have a globally unique do= main certificate (LDevID)"I think the requirement in this sentence is too s= trong in two perspective: why globally unique, secondly it is not necessary= to be a domain certificate that newly assigned in this domain. Furthermore= , this seems imply ACP depend on BRSKI as pre-step, which I don't think is = in authors original meaning. "The ACP network MUST have one or more nodes that support EST server throug= h which ACP nodes can renew their domain certificate." The work "MUST" is f= ar too strong here. "it should choose am FQDN" -> it should choose "an" FQDN "The format of the rfc822Name is choosen" -> The format of the rfc822Name i= s "chosen". There are another 4 instance of "choosen". "The loop-count MUST be sete to 255" -> The loop-count MUST be "set" to 255 "When it is time for domain certificate reneal" -> When it is time for doma= in certificate "renewal" "the primarily imiting factor for shorter certificate lifetimes", my guess = is "limiting" "the assigning CA has enough performance" -> the assigning CA has enough "p= erformance" "See Section 10.1 for further optimizationss" -> See Section 10.1 for furth= er "optimizations" The first sentence of section 6.3, "Because of the the considerations", th= e second "the"should be deleted "ACP discovery MUST NOT be enabled by default on any non-physical interface= s." This seems rule out the possibility of applying ACP with virtual device= s. My suggestion would be deleted the sentence since we ready have the foll= ow up sentence "ACP discovery MUST NOT run inside the ACP." Or not deleting= , we should at least soften it to be "SHOULD NOT". Section 6.5, "the next step after discoving" -> the next step after "discovering" "The roles of Bob abd Alice" -> The roles of Bob "and" Alice "It is not up to Alice to devide" -> It is not up to Alice to "divide" "interfaces are the ame devices" -> interfaces are the "same" devices Section 6.6, "certificate must be valid occording to"-> certificate must be valid "accor= ding" to Section 6.7, "the ACP secure channel protocol" -> the ACP secure channel "protocol" "ACP mechanisms they support" -> ACP mechanisms they "support" "ACP secure channel MUST imediately be terminated" -> ACP secure channel MU= ST "immediately" be terminated "Note that is is not standard behavior" -> Note that is not standard behavi= or Section 6.8, "Authentication is via the the domain" -> Authentication is via the domain Section 6.10, "65536 different virtualized adddresses" -> 65536 different virtualized "ad= dresses" Section 6.11, on-RPL-aware leafs (or "Internet") accoding to -> on-RPL-aware leafs (or "I= nternet") "according" to "the ACP will only accommodate" -> the ACP will only "accommodate" Routeable - > routable; at least two instances "The multi-access ACP virtual interace" -> The multi-access ACP virtual "in= terface" Thanks for your hand work and good contribution to the ANIMA group. Regards, Sheng --_000_5D36713D8A4E7348A7E10DF7437A4B927CE869BCNKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Somehow= , I don’t know how, I misspelled the name of the draft. Resend my rev= iew comments with the right name in title and to the right authors alias.

&n= bsp;

Sheng

&n= bsp;

From: Anima [mailt= o:anima-bounces@ietf.org] On Behalf Of Sheng Jiang
Sent: Thursday, August 31, 2017 7:01 PM
To: anima@ietf.org
Cc: draft-ietf-anima-auotnomic-data-plane.authors@ietf.org
Subject: [Anima] Review on draft-ietf-anima-auotnomic-data-plane-09<= o:p>

 

Hi, authors of draft-ietf-an= ima-auotnomic-data-plane,

 

I am doing a thorough review= as the document shepherd with my ANIMA chair hat on. Please address the be= low comments so that we could process this document further. This is a pett= y long document. Therefore, my review may be a little bit disordered. Overall, I think this document has been in= a good sharp although I cannot claim all my comments are minor. I believe = they are not difficult to address.

 

In introduction section, it = is better to reference the "Autonomic Control Plane" definition &= amp; description in Section 5 of RFC7575, rather than “[RFC7575] calls it the ‘Autonomic Control Plane’” .

 

The ACP could actually be co= mmunication channel for both management and control plane. So, the name see= ms be mis-leading. My understanding is that we could not change the name in= such late stage. But it worth to see more on this in the introduction, even in the abstract.<= /p>

 

“This document describ= es options for a … ACP”.= I am confused by the word “option”. What option does it actually mean? At least, it is not clear from the co= ntext.

 

“It therefore remains = operational even in…”. My understan= ding for “it” is= the network, but from the context, my first expression for “it” is= ACP.

 

Used short for the first app= earance, ANI, VRF, IKE, TLS/dTLS, SDN, NOC, OAM, NMS, CA and although GRASP= , BRSKI, EST, ULA, are defined in Section 2, but their first appearance is = before their terminologies.

 

Section 2,=

 

“ACP provides secure z= ero-touch network wide IPv6 connectivity between devices supporting it.” This is not accurate. These two devices mus= t be in the same autonomic network. Actually, we did not define an important concept yet – th= e domain of autonomic network. We were always assume there is only one doma= in within the connectivity range or the autonomic network would naturally b= e separated by non-AN devices. But it would not always be the case if AN technologies become widely deployed

 

In Section 3,

 

“certain AAA misconfig= urations can lock an administrator out of a device”, I am not sure how ACP helps in this use case. It seems for me = the only way is to log in with another admin account, then change the misconfig. It is no different through normal data plane. T= his can still be recovered remotely without ACP.

 

“The ACP provides reac= hability that is largely independent of the data plane.” Why “largely”? It implies that is still partially (maybe small proportion) dependent o= n the data plane.

 

“ACP MUST NOT be tied = to a particular protocol.” ACP does need = support from some specific protocol, GRASP, IPv6. I am sure you did not mea= n them. But the description should be improved to be more precise.

 

“The ACP MUST provide = security”. I am not sure the “MUST”.= In many scenarios, for example, some layer has very strong layer 2 securit= y mechanism, or network with physics isolation/protection. The connectivity= is the vital functionality that ACP could provide, while security provided by ACP is redundant or not necessary. <= /span>

 

“The default mode of o= peration of the ACP is hop-by-hop.” I gue= ss you mean “basic”= or “fundamental” rather than “default”. The multiple connectivity is made up by hop-by-hop connections.

 

“ ULA "Unique Loc= al Address".  The IPv6 equivalent to RFC1918 IPv4 addresses. = ; ACP addresses are ULA.”Please don’t consider ULA as an equivalent to RFC1918. We= used to have relevant discussion in v6ops WG, and people had strong consensus o= n ULAs !=3D RFC1918. (see https://tools.ietf.or= g/html/draft-ietf-v6ops-ula-usage-considerations-02#section-3.1)=

 

The content of section 3.3 r= eads like the essential benefit rather than a specific use case, especially= comparing to Section 3.1 and 3.2. More proper place for this may be Sectio= n 9 (Benefits).

 

“ACP loopback interface= &= #8221; and &= #8220;ACP virtual interface” refer to different things as defined in the Terminology sect= ion. However, in the main text, sometimes they are mixed together ((E.g. in sec= tion 5, Item 5 and 6). Either they should be used in a canonical way in thi= s document, or other more distinguished terminologies should be used to ref= er the two things.

 

The terminology “ACP connect” same no= t proper. It would be more proper to call the connect/channel for non-ACP device joi= ning the ACP through an ACP device &= #8220;ACP bridge”?

 

In section 6,

 

Initially, it must have a … as well as an adjacency table.R= 21;The word here is misleading. The authors should mea= n the functionality of an adjacency table. But it reads like an adjacency table with already learned neighbor information.

 

Inadvert -> inadvertent

 

The term “Autonomic Domain” first a= ppears at section 6.1, it should be defined in section 3.=

 

acp-address within ACP infor= mation should be optional. It may be the address is generated by AN after g= etting the domain certificate.

 

It is worthy to clarify that= although the LDevID contains ACP-information, it is not specific for ACP o= nly; it is generic for other functions that request node-level authenticati= on.

 

“To establish an ACP s= ecurely, an ACP device MUST have a globally unique domain certificate (LDev= ID)”I think the requirement in this sente= nce is too strong in two perspective: why globally unique, secondly it is not necessary to be a domain certificate that newly= assigned in this domain. Furthermore, this seems imply ACP depend on BRSKI= as pre-step, which I don’t think is in a= uthors original meaning.

 

“The ACP network MUST h= ave one or more nodes that support EST server through which ACP nodes can r= enew their domain certificate.” The work “MUST” is far too strong here.

 

“it should choose am F= QDN” -> it should choose “an” FQ= DN

 

“The format of the rfc= 822Name is choosen” -> The format of t= he rfc822Name is “chosen”. There are another 4 instance of “choosen”.

 

“The loop-count MUST b= e sete to 255” -> The loop-count MUST = be “set” t= o 255

 

“When it is time for d= omain certificate reneal” -> When it i= s time for domain certificate “renewal”

 

“the primarily imiting= factor for shorter certificate lifetimes”, my guess is “limiting”

 

“the assigning CA has = enough performance” -> the assigning C= A has enough “performance”

 

“See Section 10.1 for = further optimizationss” -> See Section= 10.1 for further “optimizations”

 

The first sentence of  = section 6.3, “Because of the the considerations”= , the second “the”sh= ould be deleted

 

“ACP discovery MUST NO= T be enabled by default on any non-physical interfaces.” This seems rule out the possibility of applying ACP with vi= rtual devices. My suggestion would be deleted the sentence since we ready have the follow up sentence “ACP discovery MUST NOT run inside the ACP.” Or not deleting, we should at least soften it to be “SHOULD NOT”.

 

Section 6.5,

 

“the next step after d= iscoving” -> the next step after “discovering”

 

“The roles of Bob abd = Alice” -> The roles of Bob “and” A= lice

 

“It is not up to Alice= to devide” -> It is not up to Alice t= o “divide”

 

“interfaces are the am= e devices” -> interfaces are the “same” = devices

 

Section 6.6,

 

“certificate must be v= alid occording to”-> certificate must = be valid “according” to

 

Section 6.7,

 

“the ACP secure channe= l protocol” -> the ACP secure channel “protocol”

 

“ACP mechanisms they s= upport” -> ACP mechanisms they “support”

 

“ACP= secure channel MUST imediately be terminated” -> ACP secure channel MUST “immediately” be terminated

 

“Note that is is not s= tandard behavior” -> Note that is not = standard behavior

 

Section 6.8,

 

“Authentication is via= the the domain” -> Authentication is = via the domain

 

Section 6.10,

 

“65536 different virtu= alized adddresses” -> 65536 different = virtualized “addresses”

 

Section 6.11,

 

on-RPL-aware leafs (or "= ;Internet") accoding to -> on-RPL-aware leafs (or "Internet&qu= ot;) “according” to

 

“the ACP will only acc= ommodate” -> the ACP will only “accommodate”

 

Routeable - > routable; a= t least two instances

 

“The multi-access ACP = virtual interace” -> The multi-access = ACP virtual “interface”

 

Thanks for your hand work an= d good contribution to the ANIMA group.

 

Regards,

 

Sheng=

--_000_5D36713D8A4E7348A7E10DF7437A4B927CE869BCNKGEML515MBXchi_--