From nobody Tue Nov 1 01:23:27 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A36129422; Tue, 1 Nov 2016 01:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 OHIioEjB6Ddo; Tue, 1 Nov 2016 01:23:22 -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 8C034129411; Tue, 1 Nov 2016 01:23:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUH57805; Tue, 01 Nov 2016 08:23:19 +0000 (GMT) Received: from SZXEMA417-HUB.china.huawei.com (10.82.72.34) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 1 Nov 2016 08:23:18 +0000 Received: from SZXEMA501-MBX.china.huawei.com ([169.254.1.186]) by SZXEMA417-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0235.001; Tue, 1 Nov 2016 16:23:07 +0800 From: "Chenrui (Richard)" To: "adrian@olddog.co.uk" , "'opsawg@ietf.org'" Thread-Topic: [OPSAWG] Soliciting thoughts on draft-ietf-netmod-yang-model-classification Thread-Index: AdIzbq9EP4RJAzxtQQ667SmsQfy/OwApfFVg Date: Tue, 1 Nov 2016 08:23:06 +0000 Message-ID: <0D5441A3DF1544449089458210966F29788F30C0@SZXEMA501-MBX.china.huawei.com> References: <00f701d2336e$d892e390$89b8aab0$@olddog.co.uk> In-Reply-To: <00f701d2336e$d892e390$89b8aab0$@olddog.co.uk> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.55.144] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.581850F7.00F3, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.186, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 95130ad8535bc70a4509abed764f5874 Archived-At: Cc: Hui Li , Songxiaolin , "draft-wu-opsawg-service-model-explained@ietf.org" Subject: [OPSAWG] =?gb2312?b?tPC4tDogIFNvbGljaXRpbmcgdGhvdWdodHMgb24JZHJh?= =?gb2312?b?ZnQtaWV0Zi1uZXRtb2QteWFuZy1tb2RlbC1jbGFzc2lmaWNhdGlvbg==?= X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 08:23:25 -0000 SGkgQWRyaWFuLA0KDQpJIHRoaW5rIGl0J3MgcmVhc29uYWJsZSB0byBzZXBhcmF0ZSB0aGUgbW9k ZWwgaW50byBjdXN0b21lciBzZXJ2aWNlIG1vZGVscywgc2VydmljZSBkZWxpdmVyeSBtb2RlbHMs IGFuZCBuZXR3b3JrL2RldmljZSBjb25maWd1cmF0aW9uIG1vZGVscy4gVGhleSBjYW4gZm9jdXMg b24gZGlmZmVyZW50IHB1cnBvc2Ugd2hpbGUgb3BlcmF0b3JzIGhhdmUgdGhlbSBjb29yZGluYXRl ZCBpbiB0aGVpciBCU1MvT1NTIHN5c3RlbSB0byBzZWxsIHRlbGVjb20gcHJvZHVjdCwgb3BlcmF0 ZSBhbmQgbWFpbnRhaW4gdGhlaXIgY2FwYWJpbGl0aWVzIG9mIGluZnJhc3RydWN0dXJlcyBhbmQg Y29uZmlndXJlIG5ldHdvcmsgYW5kIGRldmljZXMuIFRoZXNlIGFyZSBkaWZmZXJlbnQgdGFza3Mg ZmFjaW5nIGRpZmZlcmVudCB1c2VycyBhbmQgcmVxdWlyZW1lbnRzLg0KVE1GJk1FRiBhbGwgaGFz IGRpZmZlcmVudCB0ZXJtcyhwcm9kdWN0IG1vZGVsL3NlcnZpY2UgbW9kZWwgYW5kIHJlc291cmNl IG1vZGVsKSB3aGljaCBJIGJlbGlldmUgYXJlIGNvcnJlc3BvbmRpbmcgdG8gYWJvdmUgMyBtb2Rl bCBmdW5jdGlvbnMuDQoNCldlIGRvIGhhdmUgY29udHJpYnV0ZSBhIGRyYWZ0KGh0dHBzOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1jaGVuLW9wc2F3Zy1jb21wb3NpdGUtdnBu LWRtLTAwLnR4dCkgd2hpY2ggcmVmZXJzIHRvIHRoZSBjb25jZXB0IG9mIHNlcnZpY2UgZGVsaXZl cnkgbW9kZWwgdG8gcHJvdmlkZSBhIGlkZWEgb24gaG93IHRvIGRlcGxveW1lbnQgTDIvTDNWUE4g dG8gYSBtdWx0aXBsZSBkb21haW4vdGVjaG5vbG9naWVzIG5ldHdvcmsgaW4gYSBFMkUgb3JjaGVz dHJhdGVkIHdheS4NClBsZWFzZSByZXZpZXcgYW5kIGNvbW1lbnQgaXQgdG8gc2VlIGlmIHdlIGFy ZSBhdCBzYW1lIHBhZ2Ugb24gdGhpcyBpc3N1ZXMuDQoNClRoYW5rcy4NClJpY2hhcmQNCg0KDQoN Cruqzqq8vMr109DP3rmry74gSHVhd2VpIFRlY2hub2xvZ2llcyBDby4sIEx0ZC4NCrXY1rejusnu 29rK0MH6uNrH+NvgzO+7qs6qu/m12CDTyrHgo7o1MTgxMjkNCkh1YXdlaSBUZWNobm9sb2dpZXMg Q28uLCBMdGQuDQpCYW50aWFuLCBMb25nZ2FuZyBEaXN0cmljdCxTaGVuemhlbiA1MTgxMjksIFAu Ui5DaGluYQ0KaHR0cDovL3d3dy5odWF3ZWkuY29tIA0KDQqxvtPKvP68sMbkuL28/rqs09C7qs6q uavLvrXEsaPD3NDFz6KjrL32z97T2reiy824+MnPw+a12Na31tDB0LP2tcS49sjLu/LIutfpoaO9 +w0K1rnIzrrOxuTL+8jL0tTIzrrO0M7Kvcq508OjqLD8wKi1q7K7z97T2sirsr+78rK/t9a12NC5 wrahori01sahorvyyaK3oqOpsb7Tyrz+1tANCrXE0MXPoqGjyOe5+8T6tO3K1cHLsb7Tyrz+o6zH 68T6waK8tLXnu7C78tPKvP7NqNaqt6K8/sjLsqLJvrP9sb7Tyrz+o6ENClRoaXMgZS1tYWlsIGFu ZCBpdHMgYXR0YWNobWVudHMgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbSBI VUFXRUksIHdoaWNoIA0KaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiBvciBlbnRpdHkg d2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUuIEFueSB1c2Ugb2YgdGhlIA0KaW5mb3JtYXRp b24gY29udGFpbmVkIGhlcmVpbiBpbiBhbnkgd2F5IChpbmNsdWRpbmcsIGJ1dCBub3QgbGltaXRl ZCB0bywgdG90YWwgb3IgcGFydGlhbCANCmRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlz c2VtaW5hdGlvbikgYnkgcGVyc29ucyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCANCnJlY2lwaWVu dChzKSBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZSB0aGlzIGUtbWFpbCBpbiBlcnJvciwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5IA0KcGhvbmUgb3IgZW1haWwgaW1tZWRpYXRlbHkg YW5kIGRlbGV0ZSBpdCENCg0KPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gt6K8/sjLOiBPUFNBV0cg W21haWx0bzpvcHNhd2ctYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBBZHJpYW4gRmFycmVsDQo+ILei y83KsbzkOiAyMDE2xOoxMNTCMzHI1SAyMDowNA0KPiDK1bz+yMs6ICdvcHNhd2dAaWV0Zi5vcmcn DQo+ILOty806IGRyYWZ0LXd1LW9wc2F3Zy1zZXJ2aWNlLW1vZGVsLWV4cGxhaW5lZEBpZXRmLm9y Zw0KPiDW98ziOiBbT1BTQVdHXSBTb2xpY2l0aW5nIHRob3VnaHRzIG9uDQo+IGRyYWZ0LWlldGYt bmV0bW9kLXlhbmctbW9kZWwtY2xhc3NpZmljYXRpb24NCj4gDQo+IEhpLA0KPiANCj4gV2UgcHJl dmlvdXNseSBkaXNjdXNzZWQgZHJhZnQtd3Utb3BzYXdnLXNlcnZpY2UtbW9kZWwtZXhwbGFpbmVk IGEgYml0IG9uDQo+IHRoaXMgbGlzdCBhbmQgYWxzbyBhdCBhIGZhY2UtdG8tZmFjZSBtZWV0aW5n Lg0KPiANCj4gU2luY2UgdGhlbiB0aGUgSS1EIGhhcyBtb3ZlZCBvbiB0byBhIC0wMyByZXZpc2lv biBwaWNraW5nIHVwIGFuZCBhZGRyZXNzaW5nDQo+IGNvbW1lbnRzIGZyb20gdGhlIGxpc3QsIHBy aXZhdGUgZW1haWxzLCBhbmQgdGhlIGF1dGhvcnMnIGdyYWR1YWwNCj4gdW5kZXJzdGFuZGluZyBv ZiB0aGUgZmllbGQuDQo+IA0KPiBXZSBkbyBub3QgdGhpbmsgdGhhdCB0aGlzIEktRCBpcyBjb25m bGljdGVkIGJ5LCB3aXRoLCBvciBmcm9tDQo+IGRyYWZ0LWlldGYtbmV0bW9kLXlhbmctbW9kZWwt Y2xhc3NpZmljYXRpb24gKHdoaWNoIHdlIHVuZGVyc3RhbmQgbWF5IGJlDQo+IGFwcHJvYWNoaW5n IFdHIGxhc3QgY2FsbCBpbiBORVRNT0QpLg0KPiANCj4gV2UgYmVsaWV2ZSB0aGVyZSBhcmUgc29t ZSBpc3N1ZXMgdGhhdCB3b3VsZCBiZW5lZml0IGZyb20gZm9jdXNlZCBkaXNjdXNzaW9uDQo+IGlu IHRoZSBPUFNBV0cuDQo+IA0KPiBJcyB0aGVyZSBhZ3JlZW1lbnQgb24gb3VyIHNlcGFyYXRpb24g b2YgbW9kZWxzIGludG8gY3VzdG9tZXIgc2VydmljZQ0KPiBtb2RlbHMsIHNlcnZpY2UgZGVsaXZl cnkgbW9kZWxzLCBhbmQgbmV0d29yay9kZXZpY2UgY29uZmlndXJhdGlvbiBtb2RlbHM/DQo+IFdl IHRoaW5rIHRoYXQgd2UgaGF2ZSB0aGUgcmlnaHQgc3BsaXQgb2YgZnVuY3Rpb24sIGJ1dCBub3Qg bmVjZXNzYXJpbHkgdGhlIHJpZ2h0DQo+IG5hbWVzIGZvciB0aGUgdGVybXMuDQo+IA0KPiBDYW4g d2UgcmVmaW5lIHRoZSBkZWZpbml0aW9uIG9mICJzZXJ2aWNlIj8gVGhlcmUgd2FzIHNvbWUgZGlz Y3Vzc2lvbiBvZiB0aGlzDQo+IGF0IHRoZSBsYXN0IG1lZXRpbmcsIGFuZCBpdCBsZWQgdXMgdG8g cmVmaW5lIHRoZSBsYW5ndWFnZSBhIGJpdCwgYnV0IGl0IHdvdWxkIGJlDQo+IGhlbHBmdWwgdG8g aGF2ZSBtb3JlIGZlZWRiYWNrLg0KPiANCj4gSXMgdGhpcyBzdHVmZiAib2J2aW91cyIgb3IgaXMg dGhlcmUgdmFsdWUgaW4gcHVibGlzaGluZyBhbiBSRkM/IE91ciBleHBlcmllbmNlDQo+IHdvcmtp bmcgaW4gTDNTTSBoYXMgYmVlbiB0aGF0IHRoZXJlIGlzIGEgdGVuc2lvbiB3aXRoIHRoZSBwcm90 b2NvbCB3b3JraW5nDQo+IGdyb3VwcyAocGFydGljdWxhcmx5IEJFU1MpIHRoYXQgYXJpc2VzIGZy b20gdGhlIGVxdWlwbWVudCB2ZW5kb3JzIGJlaW5nDQo+IGNsb3NlciB0byBob3cgc2VydmljZXMg YXJlIGRlbGl2ZXJlZCB3aXRoaW4gYSBuZXR3b3JrIChpLmUuLCBieSBjb25maWd1cmluZyBhDQo+ IHNldCBvZiBkZXZpY2VzIGluIHRoZSBuZXR3b3JrKSB0aGFuIHRoZXkgYXJlIHRvIGFuIHVuZGVy c3RhbmRpbmcgb2YgaG93IGFuDQo+IG9wZXJhdG9yIHByZXNlbnRzIGEgc2VydmljZSBmb3IgY29u c3VtcHRpb24gYnkgdGhlaXIgY3VzdG9tZXIuIE91ciBpbnRlbnRpb24NCj4gaXMgdG8gbWFrZSB0 aGF0IGRpc3RpbmN0aW9uIGNsZWFyZXIuDQo+IA0KPiBIYXZlIHdlIGdvdCB0aGUgY29ycmVsYXRp b24gd2l0aCB0aGUgTUVGJ3MgTFNPIHJpZ2h0PyBXZSBoYXZlIGhlYXJkIGENCj4gY29uZmxpY3Rp bmcgdmlldyB0byB3aGF0IHdlIGhhdmUgd3JpdHRlbiwgYnV0IHdlIGhhdmUgYWxzbyBoZWFyZCBz dXBwb3J0aW5nDQo+IHZpZXdzLiBTaG91bGQgd2UgZHJvcCBhbGwgZGlzY3Vzc2lvbiBvZiB0aGUg TUVGJ3MgbW9kZWwgYXMgaXQgaXMgb3V0IG9mIHNjb3BlDQo+IGZvciB0aGUgSUVURj8NCj4gDQo+ IFRoYW5rcyBmb3IgYW55IG9waW5pb25zLg0KPiANCj4gQWRyaWFuDQo+IA0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBPUFNBV0cgbWFpbGluZyBs aXN0DQo+IE9QU0FXR0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29wc2F3Zw0K From nobody Tue Nov 1 02:16:30 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D291299BC; Tue, 1 Nov 2016 02:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 iV9Bq2kK3z4G; Tue, 1 Nov 2016 02:16:26 -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 3D7C81299B8; Tue, 1 Nov 2016 02:16:26 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZL79963; Tue, 01 Nov 2016 09:16:24 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 1 Nov 2016 09:16:23 +0000 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, 1 Nov 2016 17:16:14 +0800 From: Zhoutianran To: "opsawg@ietf.org" Thread-Topic: [nmrg] Review of draft-irtf-nmrg-location-ipfix-07.txt Thread-Index: AQHSMvaTKS0lXpEpEEi2z9KL4BBsv6DD2E5Q Date: Tue, 1 Nov 2016 09:16:13 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.58185D68.012B, 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: 4f65df9ba337c25d547aefcfbe059c50 Archived-At: Cc: "nmrg-chairs@ietf.org" Subject: [OPSAWG] FW: [nmrg] Review of draft-irtf-nmrg-location-ipfix-07.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 09:16:30 -0000 SGkgT1BTQVdHZXJzLA0KDQpXZSBnb3QgdGhpcyByZXZpZXcgcmVxdWVzdCBmcm9tIHRoZSBOTVJH LiBUaGVyZSBpcyBzaW1pbGFyIHdvcmsgb24gSVBGSVggZXh0ZW5zaW9uIGluIG91ciBXRy4NCkNv dWxkIHRoZSBJUEZJWCBleHBlcnRzIGluIHRoaXMgV0cgcGxlYXNlIGhlbHAgdG8gcHJvdmlkZSBj b21tZW50cyBmb3IgdGhpcyBJLUQ/DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pcnRmLW5tcmctbG9jYXRpb24taXBmaXgNCg0KDQpUaGFua3MsDQpUaWFucmFuDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBubXJnIFttYWlsdG86bm1yZy1ib3VuY2Vz QGlydGYub3JnXSBPbiBCZWhhbGYgT2YgTGlzYW5kcm8gWmFtYmVuZWRldHRpIEdyYW52aWxsZQ0K U2VudDogTW9uZGF5LCBPY3RvYmVyIDMxLCAyMDE2IDU6NDIgQU0NClRvOiBvcHNhd2ctY2hhaXJz QGlldGYub3JnDQpDYzogbm1yZ0BpcnRmLm9yZzsgaWVzZ0BpZXRmLm9yZzsgTGF1cmVudCBDaWF2 YWdsaWENClN1YmplY3Q6IFtubXJnXSBSZXZpZXcgb2YgZHJhZnQtaXJ0Zi1ubXJnLWxvY2F0aW9u LWlwZml4LTA3LnR4dA0KDQpEZWFyIE9QU0FXRyBjaGFpcnMNCg0KVGhlIGF1dGhvcnMgb2YgSS1E IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlydGYtbm1yZy1sb2NhdGlv bi1pcGZpeC8gaGFzIHB1Ymxpc2hlZCB0b2RheSBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVu dCwgYXMgY2PigJllZCBhdCB0aGUgZW5kIG9mIHRoaXMgbWVzc2FnZS4gVGhpcyBJLUQgaXMgYW4g Tk1SRyBkb2N1bWVudCB3aGljaCB3ZW50IHRyb3VnaCBhIGxhc3QgY2FsbCBhbmQgSVJTRyByZXZp ZXcuIFRoZSBtYWluIGNvbmNlcm4gZnJvbSBJUlNHIGlzIHdldGhlciB0aGUgZG9jdW1lbnQgd291 bGRu4oCZdCBhY3R1YWxseSBiZWxvbmcgdG8gSUVURi4gRm9sbG93aW5nIHN1Z2dlc3Rpb25zIGZy b20gcHJldmlvdXMgbWVzc2FnZXMgZXhjaGFuZ2VkLCB3ZSB3b3VsZCBsaWtlIHRvIGNvbGxlY3Qg dGhlIG9waW5pb24gb2YgT1BTQVdHIGFib3V0IHRoaXMgSS1ELg0KDQpUaGFua3MsDQoNCkxpc2Fu ZHJvIGFuZCBMYXVyZW50DQoNCj4gRW0gMzAgZGUgb3V0IGRlIDIwMTYsIMOgKHMpIDEzOjU2LCBp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgZXNjcmV2ZXU6DQo+IA0KPiANCj4gQSBOZXcgSW50ZXJu ZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRp cmVjdG9yaWVzLg0KPiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBOZXR3b3JrIE1h bmFnZW1lbnQgb2YgdGhlIElFVEYuDQo+IA0KPiAgICAgICAgVGl0bGUgICAgICAgICAgIDogRXh0 ZW5kaW5nIElQIEZsb3ctQmFzZWQgTmV0d29yayBNb25pdG9yaW5nIHdpdGggTG9jYXRpb24gSW5m b3JtYXRpb24NCj4gICAgICAgIEF1dGhvcnMgICAgICAgICA6IE9saXZpZXIgRmVzdG9yDQo+ICAg ICAgICAgICAgICAgICAgICAgICAgICBBYmRlbGthZGVyIExhaG1hZGkNCj4gICAgICAgICAgICAg ICAgICAgICAgICAgIFJpY2sgSG9mc3RlZGUNCj4gICAgICAgICAgICAgICAgICAgICAgICAgIEFp a28gUHJhcw0KPiAJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaXJ0Zi1ubXJnLWxvY2F0aW9uLWlw Zml4LTA3LnR4dA0KPiAJUGFnZXMgICAgICAgICAgIDogMjUNCj4gCURhdGUgICAgICAgICAgICA6 IDIwMTYtMTAtMzANCj4gDQo+IEFic3RyYWN0Og0KPiAgIElQIEZsb3ctYmFzZWQgbW9uaXRvcmlu ZyBsYWNrcyBhIG1lY2hhbmlzbSB0byBhc3NvY2lhdGUgbWVhc3VyZWQgSVANCj4gICBGbG93IGlu Zm9ybWF0aW9uIHdpdGggdGhlIGdlb2dyYXBoaWMgbG9jYXRpb24gb2YgdGhlIGRldmljZSB3aGVy ZSB0aGUNCj4gICBJUCBGbG93cyBoYXZlIGJlZW4gb2JzZXJ2ZWQuIFRoaXMgZG9jdW1lbnQgZGVm aW5lcyBhIHNldCBvZg0KPiAgIGd1aWRlbGluZXMgYW5kIGJlc3QgcHJhY3RpY2VzIHRvIGV4dGVu ZCBJUCBGbG93IG1vbml0b3JpbmcgcHJvdG9jb2xzDQo+ICAgd2l0aCBsb2NhdGlvbiBpbmZvcm1h dGlvbiBvZiB0aGUgZGV2aWNlIChib3RoIGZpeGVkIGFuZCBtb2JpbGUpIHRoYXQNCj4gICBhY3Rz IGFzIGFuIElQIEZsb3cgbWV0ZXJpbmcgcHJvY2Vzcy4NCj4gDQo+IA0KPiBUaGUgSUVURiBkYXRh dHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4gaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaXJ0Zi1ubXJnLWxvY2F0aW9uLWlwZml4Lw0KPiANCj4g VGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+IGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pcnRmLW5tcmctbG9jYXRpb24taXBmaXgtMDcNCj4g DQo+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlydGYtbm1yZy1sb2NhdGlv bi1pcGZpeC0wNw0KPiANCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3Vw bGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIA0KPiBzdWJtaXNzaW9uIHVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcu DQo+IA0KPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBG VFAgYXQ6DQo+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBubXJnIG1haWxp bmcgbGlzdA0KPiBubXJnQGlydGYub3JnDQo+IGh0dHBzOi8vd3d3LmlydGYub3JnL21haWxtYW4v bGlzdGluZm8vbm1yZw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0Kbm1yZyBtYWlsaW5nIGxpc3QNCm5tcmdAaXJ0Zi5vcmcNCmh0dHBzOi8vd3d3Lmly dGYub3JnL21haWxtYW4vbGlzdGluZm8vbm1yZw0K From nobody Wed Nov 2 01:42:23 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D75C21294BD for ; Wed, 2 Nov 2016 01:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.086 X-Spam-Level: X-Spam-Status: No, score=-4.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, 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 gkwBS7FmQOpI for ; Wed, 2 Nov 2016 01:42:20 -0700 (PDT) Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id 83C54129453 for ; Wed, 2 Nov 2016 01:42:19 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.17]) by rmmx-syy-dmz-app05-12005 (RichMail) with SMTP id 2ee55819a6ea048-5be7b; Wed, 02 Nov 2016 16:42:18 +0800 (CST) X-RM-TRANSID: 2ee55819a6ea048-5be7b X-RM-SPAM-FLAG: 00000000 Received: from cmcc-PC (unknown[223.69.29.24]) by rmsmtp-syy-appsvr09-12009 (RichMail) with SMTP id 2ee95819a6e9ea5-446af; Wed, 02 Nov 2016 16:42:17 +0800 (CST) X-RM-TRANSID: 2ee95819a6e9ea5-446af Date: Wed, 2 Nov 2016 16:44:00 +0800 From: "lizhenqiang@chinamobile.com" To: opsawg , gurong , "Dongjie (Jimmy)" X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 7, 164[cn] Mime-Version: 1.0 Message-ID: <2016110216435748441313@chinamobile.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart642682330437_=----" Archived-At: Subject: [OPSAWG] Fw: New Version Notification for draft-li-opsawg-ipfix-bgp-community-01.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 08:42:22 -0000 This is a multi-part message in MIME format. ------=_001_NextPart642682330437_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkEgbmV3IHZlcnNpb24gb2YgIGRyYWZ0LWxpLW9wc2F3Zy1pcGZpeC1iZ3AtY29t bXVuaXR5IGhhcyBiZWVuIHN1Ym1pdHRlZCBmb3IgdGhlIGNvbWluZyBtZWV0aW5nLiBZb3VyIGNv bW1lbnRzIGFyZSB3ZWxjb21lZC4NCg0KVGhpcyBkcmFmdCBpbnRyb2R1Y2VzIHRocmVlIElFcyB0 byBleHBvcnQgZmxvdyByZWxhdGVkIEJHUCBjb21tdW5pdHkgaW5mb3JtYXRpb24gaW4gSVBGSVgu IFRoZSB0eXBlIG9mIGJhc2ljTGlzdCBkZWZpbmVkIGluIFJGQzYzMTMgaXMgdXNlZC4gSW4gdGhp cyB2ZXJzaW9uLCBJRSBmb3IgQkdQIGNvbW11bml0eSBpcyBhZGRlZCBhbmQgYW4gZXhhbXBlIGlu IGdpdmVuIGluIHRoZSBhcHBlbmRpeCB0byBzaG93IHRoZSBlbmNvZGluZyBmb3JtYXQgb2YgdGhl IGludHJvZHVjZWQgSUVzLg0KDQpCZXN0IFJlZ2FyZHMsDQoNCg0KDQpsaXpoZW5xaWFuZ0BjaGlu YW1vYmlsZS5jb20NCiANCkZyb206IGludGVybmV0LWRyYWZ0cw0KRGF0ZTogMjAxNi0xMC0yOCAx ODoxOA0KVG86IFpoZW5xaWFuZyBMaTsgSmllIERvbmc7IFJvbmcgR3UNClN1YmplY3Q6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGktb3BzYXdnLWlwZml4LWJncC1jb21tdW5p dHktMDEudHh0DQogDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbGktb3BzYXdnLWlwZml4 LWJncC1jb21tdW5pdHktMDEudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5 IFpoZW5xaWFuZyBMaSBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KIA0KTmFt ZTogZHJhZnQtbGktb3BzYXdnLWlwZml4LWJncC1jb21tdW5pdHkNClJldmlzaW9uOiAwMQ0KVGl0 bGU6IEV4cG9ydCBCR1AgY29tbXVuaXR5IGluZm9ybWF0aW9uIGluIElQIEZsb3cgSW5mb3JtYXRp b24gRXhwb3J0IChJUEZJWCkNCkRvY3VtZW50IGRhdGU6IDIwMTYtMTAtMjgNCkdyb3VwOiBJbmRp dmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiA5DQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxpLW9wc2F3Zy1pcGZpeC1iZ3AtY29tbXVu aXR5LTAxLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWxpLW9wc2F3Zy1pcGZpeC1iZ3AtY29tbXVuaXR5Lw0KSHRtbGl6ZWQ6ICAgICAg IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saS1vcHNhd2ctaXBmaXgtYmdwLWNv bW11bml0eS0wMQ0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1saS1vcHNhd2ctaXBmaXgtYmdwLWNvbW11bml0eS0wMQ0KIA0KQWJzdHJhY3Q6 DQogICBUaGlzIGRyYWZ0IHNwZWNpZmllcyBhbiBleHRlbnNpb24gdG8gdGhlIElQRklYIGluZm9y bWF0aW9uIG1vZGVsDQogICBkZWZpbmVkIGluIFtSRkM3MDEyXSB0byBleHBvcnQgdGhlIEJHUCBj b21tdW5pdHkgaW5mb3JtYXRpb24uICBUaHJlZQ0KICAgaW5mb3JtYXRpb24gZWxlbWVudHMsIGJn cENvbW11bml0eSwgYmdwU291cmNlQ29tbXVuaXR5TGlzdCBhbmQNCiAgIGJncERlc3RpbmF0aW9u Q29tbXVuaXR5TGlzdCwgYXJlIGludHJvZHVjZWQgaW4gdGhpcyBkb2N1bWVudCB0byBjYXJyeQ0K ICAgdGhlIGNvbW11bml0eSBpbmZvcm1hdGlvbiBmb3IgdGhlIHNvdXJjZSBJUCBhbmQgZGVzdGlu YXRpb24gSVANCiAgIHJlc3BlY3RpdmVseS4NCiANCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN CiANCiANClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBm cm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFu ZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQogDQpUaGUgSUVURiBTZWNy ZXRhcmlhdA0KIA0KIA0K ------=_001_NextPart642682330437_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A
Hello,

A new version of&nbs= p; draft-li-opsawg-ipfix-bgp-community has been subm= itted for the coming meeting. Your comments are welcomed.

This draft introduces three IEs to export= flow related BGP community information in IPFIX. The type of basicList de= fined in RFC6313 is used. In this version, IE for BGP community is added a= nd an exampe in given in the appendix to show the encoding format of the i= ntroduced IEs.
=0A

Best Regards,
=
=0A
lizhenqiang@chinamobile.com
<= /span>
=0A
 
From= : internet-drafts=
Date: 2016-10-28 18:18
Subject: New Version Not= ification for draft-li-opsawg-ipfix-bgp-community-01.txt
=
 
=0A
A new version of I-D, draft-li-opsawg-ipfix-= bgp-community-01.txt
=0A
has been successfully submitted by Zhenq= iang Li and posted to the
=0A
IETF repository.
=0A
 = ;
=0A
Name: draft-li-opsawg-ipfix-bgp-community
=0A
Rev= ision: 01
=0A
Title: Export BGP community information in IP Flow= Information Export (IPFIX)
=0A
Document date: 2016-10-28
= =0A
Group: Individual Submission
=0A
Pages: 9
=0A
= URL:            htt= ps://www.ietf.org/internet-drafts/draft-li-opsawg-ipfix-bgp-community-01.t= xt
=0A
Status:         ht= tps://datatracker.ietf.org/doc/draft-li-opsawg-ipfix-bgp-community/
= =0A
Htmlized:       https://tools.ietf.o= rg/html/draft-li-opsawg-ipfix-bgp-community-01
=0A
Diff: &nb= sp;         https://www.ietf.org/r= fcdiff?url2=3Ddraft-li-opsawg-ipfix-bgp-community-01
=0A
 =0A
Abstract:
=0A
   This draft specifies an ex= tension to the IPFIX information model
=0A
   defined i= n [RFC7012] to export the BGP community information.  Three
=0A<= div>   information elements, bgpCommunity, bgpSourceCommunityLis= t and
=0A
   bgpDestinationCommunityList, are introduce= d in this document to carry
=0A
   the community inform= ation for the source IP and destination IP
=0A
   respe= ctively.
=0A
 
=0A
     &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp; 
=0A
 
=0A
 
=0A
Please no= te that it may take a couple of minutes from the time of submission
= =0A
until the htmlized version and diff are available at tools.ietf.or= g.
=0A
 
=0A
The IETF Secretariat
=0A
&nbs= p;
=0A
 
=0A
=0A ------=_001_NextPart642682330437_=------ From nobody Wed Nov 2 16:10:10 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D82EF126FDC; Wed, 2 Nov 2016 16:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.397 X-Spam-Level: X-Spam-Status: No, score=-8.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497] 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 gguP1ZROcx5K; Wed, 2 Nov 2016 16:10:06 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 CAC2912954B; Wed, 2 Nov 2016 16:10:06 -0700 (PDT) Received: from [128.9.184.167] ([128.9.184.167]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id uA2N9Vc0009476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 2 Nov 2016 16:09:32 -0700 (PDT) To: Duzongpeng References: <78f07b6d-3c78-e002-b2f5-487da9c8be72@isi.edu> From: Joe Touch Message-ID: <6f49f923-1b2a-f053-dfa6-429772b2ee09@isi.edu> Date: Wed, 2 Nov 2016 16:09:30 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "opsawg@ietf.org" , "draft-ietf-opsawg-capwap-alt-tunnel.all@ietf.org" Subject: Re: [OPSAWG] TSV ART IETF LC review of draft-ietf-opsawg-capwap-alt-tunnel X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 23:10:09 -0000 Hi, On 10/18/2016 12:48 AM, Duzongpeng wrote: > Hello, Joe > > Although not as an author of the draft, I would like to talk about your suggestions. > > Please see inline. > > Best Regards > Zongpeng Du > >> Major issues: >> >> As already noted in draft-intarea-tunnels, many existing tunnel >> mechanisms are inconsistent or incorrect in their support for IPv6 MTU >> requirements, both as transits for IP packets and as IP endpoints. >> Although this document cites existing standards, the inconsistency and >> incorrectness of these standards should be addressed. It might be >> sufficient to indicate that any tunneling mechanism selected MUST >> support the minimum IPv6 MTU requirements independent of this >> signalling mechanism (i.e, the signalling mechanism doesn't address or >> correct any errors or inconsistencies in the tunnel mechanism selected). >> > [duzongpeng] > Would it ok if the authors add a section to declare that every tunneling mechanism > MUST support the minimum IPv6 MTU requirements said in "draft-ietf-intarea-tunnels-03" It can, but draft-intarea is Informational. If you need normative refs, you should cite the docs draft-intarea cites to determine these requirements. > If the draft, the tunnel between the WTP and Access Router needs to be established, and the WTP and AC already have a CAPWAP connection. > According to the tunneling mechanism supported, MTU information perhaps can be computed by the AR. > AC can have the information, and inform the WTP in the "Tunnel Info Element" field. OK. > [duzongpeng] > > >> Regarding IP endpoint requirements, it might be useful to consider >> whether this protocol could be extended to indicate the receiver >> payload reassembly limit when indicating support for each tunnel type, >> to assist the source in determining whether the resulting tunnel will >> be IPv6 compliant (rather than becoming a black hole for valid packet sizes). >> > [duzongpeng] > Is it the same information talked above? Yes. > I think it is flexible to indicate something in the "Tunnel Info Element" field. OK. > If you can provide detailed modification suggestions, perhaps the author will be glad to accept it. > BTW, I have also given some suggestions to the draft. I don't have any specific suggestions of how to extend the protocol to accomplish this task. > [duzongpeng] > >> Additionally, for the transport protocol-based tunnels, it would be >> useful to consider whether the protocol could indicate not only the >> endpoint IP address but the port number as well. >> > [duzongpeng] > If any tunnel type needs this port information, it should be ok to carry it in the "Tunnel Info Element" field. OK. > [duzongpeng] > >> Minor issues: >> >> It might be useful to consider IPsec TLS, and DTLS tunnels as well as >> those already listed. > [duzongpeng] > According to my understanding, it is ok to add some tunnel types. > However, the authors have decided to only talk some essential ones in this draft, and perhaps talk about others in latter drafts if necessary. It might be helpful to indicate that this is how other tunnel types are being handled, so they don't appear to be omitted for other reasons. > [duzongpeng] > > > -----Original Message----- > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Warren Kumari > Sent: Tuesday, October 04, 2016 5:50 AM > To: Joe Touch > Cc: opsawg@ietf.org; draft-ietf-opsawg-capwap-alt-tunnel.all@ietf.org > Subject: Re: [OPSAWG] TSV ART IETF LC review of draft-ietf-opsawg-capwap-alt-tunnel > > [ - Discuss, tsv-art (first for clutter, second because I'm not subscribed) ] Dear authors, > > I just wanted to make sure that you had seen these are well... > > W > > On Mon, Sep 26, 2016 at 5:36 PM, Joe Touch wrote: >> CC'ing tsv-art... >> >> >> On 9/26/2016 2:34 PM, Joe Touch wrote: >> >> Hi, all, >> >> I've reviewed this document as part of the Transport Area Review >> Team's >> (TSVART) ongoing effort to review key IETF documents. These comments >> were written primarily for the transport area directors, but are >> copied to the document's authors for their information and to allow >> them to address any issues raised. When done at the time of IETF Last >> Call, the authors should consider this review together with any other >> last-call comments they receive. Please always CC tsv-art@ietf.org if >> you reply to or forward this review. >> >> Please resolve these comments along with any other Last Call comments >> you may receive. Please wait for direction from your document shepherd >> or AD before posting a new version of the draft. >> >> Document: draft-ietf-opsawg-capwap-alt-tunnel >> Title: Alternate Tunnel Encapsulation for Data Frames in CAPWAP >> Reviewer: J. Touch >> Review Date: Sept 26, 2016 >> IETF Last Call Date: Sept 16, 2016 >> >> Summary: This doc refers to existing tunneling specifications, many of >> which are inconsistent or incorrect. In particular, there are >> potential complicatinos with MTU support and signalling that could >> affect transport protocols. >> >> Major issues: >> >> As already noted in draft-intarea-tunnels, many existing tunnel >> mechanisms are inconsistent or incorrect in their support for IPv6 MTU >> requirements, both as transits for IP packets and as IP endpoints. >> Although this document cites existing standards, the inconsistency and >> incorrectness of these standards should be addressed. It might be >> sufficient to indicate that any tunneling mechanism selected MUST >> support the minimum IPv6 MTU requirements independent of this >> signalling mechanism (i.e, the signalling mechanism doesn't address or >> correct any errors or inconsistencies in the tunnel mechanism selected). >> >> Regarding IP endpoint requirements, it might be useful to consider >> whether this protocol could be extended to indicate the receiver >> payload reassembly limit when indicating support for each tunnel type, >> to assist the source in determining whether the resulting tunnel will >> be IPv6 compliant (rather than becoming a black hole for valid packet sizes). >> >> Additionally, for the transport protocol-based tunnels, it would be >> useful to consider whether the protocol could indicate not only the >> endpoint IP address but the port number as well. >> >> Minor issues: >> >> It might be useful to consider IPsec TLS, and DTLS tunnels as well as >> those already listed. >> >> --- >> >> > > > -- > I don't think the execution is relevant when it was obviously a bad idea in the first place. > This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. > ---maf > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From prvs=01144809f3=alex@digriz.org.uk Wed Nov 2 16:14:54 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3D29129681; Wed, 2 Nov 2016 16:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digriz.org.uk 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 9ZjwP45IlVjS; Wed, 2 Nov 2016 16:14:52 -0700 (PDT) Received: from marmot.wormnet.eu (marmot.wormnet.eu [IPv6:2a03:9800:10:2d:3203:b3a5:8bdc:5b68]) (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 1B40F129652; Wed, 2 Nov 2016 16:14:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=digriz.org.uk; s=wopr; h=Content-Type:MIME-Version:Message-ID:Subject:Cc:To :From:Date; bh=v4SDtG7zYLVC2xflel4r4ibZkNx6PXsynGnLA3Q2TMw=; b=hEpCFYBIbAtF9i 1HUPn/jhOUud58LL7g4hZC1nXkY9r0xr2vUNF6AWYHPuZLv0t054mFmaKTr9f/CXHTc+tdgNPwhGH 9F5OauVr2WikOcn7INm9tJk/hreFZR4TbifEt/YxkvTKdtfoEpqy3QefdwS9Kzws50rLy8sYKKOOb EG4=; Received: from [2a01:348:45:10:e100:ea7f:ffe6:cdf3] (helo=quatermain.digriz.wormnet.eu) by marmot.wormnet.eu with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86) (envelope-from ) id 1c24k3-00043h-Nt; Wed, 02 Nov 2016 23:14:47 +0000 Date: Wed, 2 Nov 2016 23:14:46 +0000 From: Alexander Clouter To: draft-ietf-opsawg-tacacs@ietf.org Message-ID: <20161102231446.GA3842@quatermain.digriz.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline X-Auto-Response-Suppress: OOF Organization: WormNET Jabber-ID: alex@digriz.org.uk User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: opsawg@ietf.org Subject: [OPSAWG] implementing from reading draft-ietf-opsawg-tacacs-05 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 23:19:02 -0000 Hello, I am working on implementing the TACACS+ protocol. I do of course have a reference (pam_tacplus) to crib from and a pile of lab equipment, but thought as the draft your have authored seem aims to be a living standard you might be interested in hearing some feedback from the trenches of someone right now trying to implement from it. Below are my thoughts on various sections, though no doubt might follow up later as my work progresses and other questions arise. Thanks! > 3.4. The TACACS+ Packet Header > > ... > > seq_no > > This is the sequence number of the current packet for the current > session. The first packet in a session MUST have the sequence number > 1 and each subsequent packet will increment the sequence number by > one. Thus clients only send packets containing odd sequence numbers, > and TACACS+ servers only send packets containing even sequence > numbers. If a client or server observes this condition not being met, is it okay to tear down the connection immediately? As a receiver of these packets, should I enforce this draft, or be flexible? > session_id > > The Id for this TACACS+ session. The session id is to be selected > randomly. This field does not change for the duration of the TACACS+ > session. (If this value is not a cryptographically strong random > number, it will compromise the protocol's security, see RFC 1750 > [RFC1750] ) What is the attack vector here? Why does this need to be cryptographically strong and how does it compromise the protocol's security? As it is present in the clear in the header and the TCP session its-self is wrapped in a (supposedly) suitable number, I can not see what I am protecting against here. Is there any problems treating this as an opaque bitfield as it seems to only be used in the MD5 XOR or is there some undocumented authentication mechanism that makes use of this I will find in the field? > There will be no padding in any of the fields or at the end of a packet. If I see padding, do I kill the connection? Is this a SHOULD NOT? > 3.6. Encryption > > In this case, the packet body is encrypted by XOR-ing it byte-wise > with a pseudo random pad. > > ENCRYPTED {data} == data ^ pseudo_pad I know it, you know it, everyone on OPSAWG probably knows it, but the poor fresh out of university intern is going to really appreciate if you add: : The packet can then be decrypted by repeating the same process but : on the encrypted data. : : data == ENCRYPTED {data} ^ pseudo_pad :) > The version number is the one byte concatenation of the major and > minor version numbers. > > The session id is used in network byte order. Easier to simply state 'as is in the header'? > After a packet body is decrypted, the lengths of the component values > in the packet are summed. If the sum is not identical to the > cleartext datalength value from the header, the packet MUST be > discarded, and an error signalled. The underlying TCP connection MAY > also be closed, if it is not being used for other sessions in single- > connect mode. > > Commonly such failures are seen when the keys are mismatched between > the client and the TACACS+ server. If the keys are mis-matched, how could any of the other sessions be valid? Also keeping the connection open surely is just going to produce a stream of errors? Is it not safer to simply tear down the connection here; after sending the terminating message? > If an error must be declared but the type of the incoming packet > cannot be determined, a packet with the identical cleartext header > but with a sequence number incremented by one and the length set to > zero MUST be returned to indicate an error. Wow, this is well hidden! Would this not be better around section 3.4? I cannot see how the packet would become valid after the XORing process, maybe I am missing something here? > 4.4.1. Version Behaviour > > The TACACS+ protocol is versioned to allow revisions while > maintaining backwards compatibility. The version number is in every > packet header. The changes between minor_version 0 and 1 apply only > to the authentication process, and all deal with the way that CHAP > and PAP authentications are handled. minor_version 1 may only be used > for authentication kinds that explicitly call for it in the table > below: > > LOGIN CHPASS SENDAUTH > ASCII v0 v0 - > PAP v1 - v1 > CHAP v1 - v1 > MS-CHAPv1/2 v1 - v1 > > > The '-' symbol represents that the option is not valid. > > When a server receives a packet with a minor_version that it does not > support, it will return an ERROR status with the minor_version set to > the closest supported value. Is it okay to tear down the connection if a non-valid but technically could be supported combination is requested? > NOTE: Only those requests which have changed from their minor_version > 0 implementation (i.e. CHAP, MS-CHAP and PAP authentications) will > use the new minor_version number of 1. All other requests (i.e. all > authorisation and accounting and ASCII authentication) MUST continue > to use the same minor_version number of 0. The removal of SENDPASS > was prompted by security concerns, and is no longer considered part > of the TACACS+ protocol. Where can I read about SENDPASS? Will I see it out in the field? Though it is not considered part of the protocol (vendor extension?) should it be supported still? > 4.4.2. Common Authentication Flows > > Inbound CHAP login > > ... > > The length of the challenge value can be determined from the length > of the data field minus the length of the id (always 1 octet) and the > length of the response field (always 16 octets). "note that unlike in RFC 1334, the length is not included in the value and is derived instead from...". If you are pointing people at RFC's then for me it helps me to have it explicitly stated where those deviations are. Maybe this is just me though. > Inbound MS-CHAP v2 login > > ... > > To perform the authentication, the server will use a the algorithm > specified RFC2759 [RFC2759] on the user's secret and challenge and > then compare the resulting value with the response. The REPLY from > the server MUST be a PASS or FAIL. nit: '...will use -a- the algorithm specified...' > 4.4.3. Aborting an Authentication Session > > ... > > When the status equals TAC_PLUS_AUTHEN_STATUS_FOLLOW the packet > indicates that the TACACS+ server requests that authentication is > performed with an alternate server. The data field MUST contain > ASCII text describing one or more servers. A server description > appears like this: > > [@@]>[@] > > If more than one host is specified, they MUST be separated into rows > by an ASCII Carriage Return (0x0D). > > Use of the hosts in a TAC_PLUS_AUTHEN_STATUS_FOLLOW packet is at the > discretion of the TACACS+ client. It may choose to use any one, all > or none of these hosts. If it chooses to use none, then it MUST > treat the authentication as if the return status was > TAC_PLUS_AUTHEN_STATUS_FAIL. > > While the order of hosts in this packet indicates a preference, but > the client is not obliged to use that ordering. This does not tell me what to actually do when I receive a list of more than one host. Is this a client configuration which is coupled by the administrator to the server configuration? If multiple hosts are actually for failover purposes, what do I do if I get an TAC_PLUS_AUTHEN_STATUS_FAIL from the first one? Do I take it as gospel and not bother trying the other targets, or do I assume that it is broken and I should retry against the other systems to seek a TAC_PLUS_AUTHEN_STATUS_PASS? > If the status equals TAC_PLUS_AUTHEN_STATUS_ERROR, then the host is > indicating that it is experiencing an unrecoverable error and the > authentication will proceed as if that host could not be contacted. > The data field may contain a message to be printed on an > administrative console or log. ...and TAC_PLUS_AUTHEN_STATUS_FAIL could come back as the backend DB is bust so "try other hosts too"? > 5. Authorization > > 6. Accounting I have not gotten this far in my development work so I'll get back to you. > 9. TACACS+ Security Considerations > > ... > > To use IPsec where available. ...boo! :) > Because of the security issues with TACACS+, the authors intend to > follow up this document with an enhanced specification of the > protocol employing modern security mechanisms. Where can I find out about the TLS approach? I saw in an earlier draft TAC_PLUS_START_TLS but then in the OPSAWG mailing list archives it looks like you are going for a dedicated port instead? Does TLS actually exist yet anywhere or do I just ignore it for now? From nobody Wed Nov 2 19:20:47 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A390E1293FB for ; Wed, 2 Nov 2016 19:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 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=-1.497, 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 6H20h9F0DrlM for ; Wed, 2 Nov 2016 19:20:43 -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 2A6CF12987D for ; Wed, 2 Nov 2016 19:20:42 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUK41750; Thu, 03 Nov 2016 02:20:39 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Nov 2016 02:20:36 +0000 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0235.001; Wed, 2 Nov 2016 19:20:29 -0700 From: Linda Dunbar To: "'opsawg@ietf.org'" Thread-Topic: request a presentation slot at the OPSarea & OPSAwg joint meeting in IETF97 Thread-Index: AdI1YqhAnW2bOEwNSeCp70u8NZndHgAFfllQ Date: Thu, 3 Nov 2016 02:20:28 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657F66DBE@dfweml501-mbb> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.147.61] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657F66DBEdfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.581A9EF8.00D5, 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: 65d5b5794b1cff92cc03b929cec73717 Archived-At: Subject: [OPSAWG] request a presentation slot at the OPSarea & OPSAwg joint meeting in IETF97 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 02:20:46 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657F66DBEdfweml501mbb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re-sent CC'ed to OPSAwg ------------------------ Joel, Benoit, Warren, and TianRan, We would like a 10-minutes slot at the OPSarea & OPSAwg joint meeting in IE= TF97 to describe the operations and management aspects of a type of private= network service: https://datatracker.ietf.org/doc/draft-dunbar-opsawg-pri= vate-networks-over-thin-cpe/ In a nutshell, this new type of private network service - is like SD-WAN in the way that IP tunnels are automatically established f= rom a thin-CPE at customer site, - but different from SD-WAN because there are interactions with the underla= y network (even though the interaction to underlay network is transparent t= o users), and there are gateways (for private networks) instantiated in th= e underlay network to establish secure connections between Thin-CPEs and th= e gateways, and guaranteed QoS from the underlay networks. In another word, it is a private network laid over multiple Thin CPEs (or= Overlay VPN for easy of description). "Overlay VPN" is a type of private networks that interconnect thin CPEs at = multiple client sites by IP tunnels, or more specifically, lay over multipl= e client sites' Thin CPEs via IP tunnels. Those private overlay networks no= t only interconnect those sites by secure IP tunnels but can also enforce t= he client specified policies to govern how applications or hosts within tho= se sites communicate and how to access public internet. Thank you very much. Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F657F66DBEdfweml501mbb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Re-sent CC’ed to= OPSAwg

 

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

Joel, Benoit, Warren, and TianRan,

 

We would like a 10-minutes slot at the OPSarea &= OPSAwg joint meeting in IETF97 to describe the operations and management a= spects of a type of private network service:  https://datatr= acker.ietf.org/doc/draft-dunbar-opsawg-private-networks-over-thin-cpe/<= /span>

 

In a nutshell, this new type of private network serv= ice

- is like SD-WAN in the way that IP tunnels are auto= matically established from a thin-CPE at customer site,

- but different from SD-WAN because there are intera= ctions with the underlay network (even though the interaction to underlay n= etwork is transparent to users), and  there are gateways (for private = networks) instantiated in the underlay network to establish secure connections between Thin-CPEs and the gateways= , and guaranteed QoS from the underlay networks.

 

In another word, it is a private network laid over m= ultiple Thin CPEs   (or Overlay VPN for easy of description).

"Overlay VPN" is a type of private network= s that interconnect thin CPEs at multiple client sites by IP tunnels, or mo= re specifically, lay over multiple client sites’ Thin CPEs via IP tun= nels. Those private overlay networks not only interconnect those sites by secure IP tunnels but can also enforce the client specified= policies to govern how applications or hosts within those sites communicat= e and how to access public internet. 

 

 

Thank you very much.

 

Linda Dunbar

 

 

 

--_000_4A95BA014132FF49AE685FAB4B9F17F657F66DBEdfweml501mbb_-- From nobody Thu Nov 3 00:57:53 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFC82129482 for ; Thu, 3 Nov 2016 00:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 bEDvlxJDaXDB for ; Thu, 3 Nov 2016 00:57:50 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BEB4129473 for ; Thu, 3 Nov 2016 00:49:33 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id b14so31004026lfg.2 for ; Thu, 03 Nov 2016 00:49:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=aVJfL2rCo5ULlhZaWf16L6VeSAzgH/QB/uKRsiz18Zg=; b=nY5gthJMSh9hD5oZpuPxLTzkdnfJHXWGykCAOthK2uEz5UmhkzdGitXO6+iRRGW+0u bgRo3rq98V5xu2y6v0YPusNzht1jPNhqn6tmkhZSc5Cq4crravYwzIa1XA3w4qs7qSQ9 ooMdvq7HS09lNh9VLppzxD7mqlbZcuuVDSmIh/n5lzYqzxezwHkg96UmqO9AiAQJrx7m KTKgA2ORRb3ys1In7fQsBgGBb4klEolYi9fhNubtqXxNO3vS2vemMS4vUg4XrQwYnKTh 9uSw5dfa8z1iSYa6YLBHIF8PQnmKfJ1XE4aNPTV3BjsNqHU4NXhgu6H1BrUCFIzlFl1v +j3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=aVJfL2rCo5ULlhZaWf16L6VeSAzgH/QB/uKRsiz18Zg=; b=ZZZWOBBiyxGEhsWUIG9xSmldAL5J1HrUBfVsTNpiVfg+MHxqfSxoNpfg4iLC8fQ8nK uYe8zNEm3x8rh9tf7xUp8YvrbKBYTR3TzbNxTPpIpqPci6+00L9jsK7tKGxab9B7tNH3 vJbFpESwwCAo252r6r9f0x29W+5fflwhimW2PnM41NQ2wtcDLX1ugTUlBjof+N1UXoBt j9+LPBJ2iZ2EgLhQ4t/k6v2/gjyj9bMsE9pRnjkzoXOFqkiKxdQIa527eOCBtIoeDSZR 5U3FFQgffYm5IGstgDWG8j0NOHxMY4fz6XLdVddeH7Gb3JhDv6qw37MLWTbHrUgMbqlB uoEQ== X-Gm-Message-State: ABUngvcE7LIf4o8b/Ft7m2ZNjRSvhjNPNBeaAth9yPzigkHlDGpXkzT7MWvZ2facSgKsnJsUYsX0Qkp6AMPgqzhZ X-Received: by 10.25.134.139 with SMTP id i133mr104077lfd.79.1478159371424; Thu, 03 Nov 2016 00:49:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.89.211 with HTTP; Thu, 3 Nov 2016 00:49:01 -0700 (PDT) In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657F66DBE@dfweml501-mbb> References: <4A95BA014132FF49AE685FAB4B9F17F657F66DBE@dfweml501-mbb> From: Warren Kumari Date: Thu, 3 Nov 2016 08:49:01 +0100 Message-ID: To: Linda Dunbar Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] request a presentation slot at the OPSarea & OPSAwg joint meeting in IETF97 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 07:57:52 -0000 On Thu, Nov 3, 2016 at 3:20 AM, Linda Dunbar wrot= e: > Re-sent CC=E2=80=99ed to OPSAwg > > > > ------------------------ > > Joel, Benoit, Warren, and TianRan, > > > > We would like a 10-minutes slot at the OPSarea & OPSAwg joint meeting in > IETF97 to describe the operations and management aspects of a type of > private network service: > https://datatracker.ietf.org/doc/draft-dunbar-opsawg-private-networks-ove= r-thin-cpe/ > > Unfortunately the OpsAWG agenda is full. There may still be space in the OpsArea part of the agenda (which Benoit and Joel are responsible for). This is a -00 document (technically it is -01, but both the 00 and 01 were submitted on the same day, the draft cutoff day). It looks interesting, but very light on the details, and many of actual detail sections are still "To be added". i'd encourage people to read it and provide feedback. W > > In a nutshell, this new type of private network service > > - is like SD-WAN in the way that IP tunnels are automatically established > from a thin-CPE at customer site, > > - but different from SD-WAN because there are interactions with the under= lay > network (even though the interaction to underlay network is transparent t= o > users), and there are gateways (for private networks) instantiated in th= e > underlay network to establish secure connections between Thin-CPEs and th= e > gateways, and guaranteed QoS from the underlay networks. > > > > In another word, it is a private network laid over multiple Thin CPEs (= or > Overlay VPN for easy of description). > > "Overlay VPN" is a type of private networks that interconnect thin CPEs a= t > multiple client sites by IP tunnels, or more specifically, lay over multi= ple > client sites=E2=80=99 Thin CPEs via IP tunnels. Those private overlay net= works not > only interconnect those sites by secure IP tunnels but can also enforce t= he > client specified policies to govern how applications or hosts within thos= e > sites communicate and how to access public internet. > > > > > > Thank you very much. > > > > Linda Dunbar > > > > > > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu Nov 3 06:12:33 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9492C12959F; Thu, 3 Nov 2016 06:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBxwedMeDLWR; Thu, 3 Nov 2016 06:12:30 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45B33129552; Thu, 3 Nov 2016 06:12:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12469; q=dns/txt; s=iport; t=1478178750; x=1479388350; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1wJaSp5SvpeH3SB3LKG+W0/WEYttM00IE2qTbBxFinM=; b=DYfa6H0mnsSB5y43AIw8ExOH1IKjZddE5W29nQKFuPO6SdJJOdaWgXHZ 6Nvcwj0+LCFMDWf/OzdSBfjHrlvzyBe9JLGQ7kDyylUfLhsAa0p5d5zyx xbokBR4WXqlB0/jzhLp9EIgoD9xEc9l7h3EFDx1I1Ym3LMzdQQMADKGSl s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CtAQCENxtY/4QNJK1dGwEBAQMBAQEJA?= =?us-ascii?q?QEBgzABAQEBAR+BVAeNMJcAlEeCCIYiAoIlPxQBAgEBAQEBAQFiKIRiAQEDAR1?= =?us-ascii?q?KBwsFCwIBCC4BARYyJQIEAQ0FiE4IuwsBAQEBAQEBAQEBAQEBAQEBAQEBAQEch?= =?us-ascii?q?BuGeYQxXgEFhRIFdo4WhTaFXgGJPYJ4hAeBboRvgzuFco0dhAMBHjdrgyEGG4F?= =?us-ascii?q?dcoVBDReBCYEMAQEB?= X-IronPort-AV: E=Sophos;i="5.31,438,1473120000"; d="scan'208";a="342929933" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Nov 2016 13:12:14 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id uA3DCEkl013435 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 3 Nov 2016 13:12:14 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 3 Nov 2016 08:12:13 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Thu, 3 Nov 2016 08:12:13 -0500 From: "Douglas Gash (dcmgash)" To: Alexander Clouter , "draft-ietf-opsawg-tacacs@ietf.org" Thread-Topic: implementing from reading draft-ietf-opsawg-tacacs-05 Thread-Index: AQHSNdPkU1lDpJuYnUusg3ahXnkhyA== Date: Thu, 3 Nov 2016 13:12:13 +0000 Message-ID: References: <20161102231446.GA3842@quatermain.digriz.org.uk> In-Reply-To: <20161102231446.GA3842@quatermain.digriz.org.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.8.160830 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.1.3] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <06ED14C32DB0EA4083065E25AFC50572@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] implementing from reading draft-ietf-opsawg-tacacs-05 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 13:12:32 -0000 Thanks Alexander. We have had a good set of feedback also from other members (Thanks in particular to Alan DeKok) and will be uploading a new version shortly. We will also mix in the comments from yourself. Please see some comments inline, feel free to shout if you think I=B9ve misunderstood or just plain to something askew. On 02/11/2016 23:14, "Alexander Clouter" wrote: >Hello, > >I am working on implementing the TACACS+ protocol. I do of course have a >reference (pam_tacplus) to crib from and a pile of lab equipment, but >thought=20 >as the draft your have authored seem aims to be a living standard you >might be=20 >interested in hearing some feedback from the trenches of someone right >now=20 >trying to implement from it. > >Below are my thoughts on various sections, though no doubt might follow >up=20 >later as my work progresses and other questions arise. > >Thanks! > >> 3.4. The TACACS+ Packet Header >> >> ... >> >> seq_no >> >> This is the sequence number of the current packet for the current >> session. The first packet in a session MUST have the sequence number >> 1 and each subsequent packet will increment the sequence number by >> one. Thus clients only send packets containing odd sequence numbers, >> and TACACS+ servers only send packets containing even sequence >> numbers. > >If a client or server observes this condition not being met, is it okay >to tear=20 >down the connection immediately? As a receiver of these packets, should >I=20 >enforce this draft, or be flexible? The problem you will have if you get an even seq_no from a client is that, if you increment in your response, you=B9ll need to contravene the spec in sending an odd number response. So the recommendation is to reject in this case. I would not be flexible here. As to dropping the connection, really the only reason you may not do that is in single connection mode if there are other sessions that are well behaved on the connection, if they are already in progress. So the next upload will propose a compromise: if there is some error that would close the connection in non single connect mode, then we MUST NOT accept any more connections, but established sessions that are legal may complete, the connection should be closed then. > >> session_id >> >> The Id for this TACACS+ session. The session id is to be selected >> randomly. This field does not change for the duration of the TACACS+ >> session. (If this value is not a cryptographically strong random >> number, it will compromise the protocol's security, see RFC 1750 >> [RFC1750] ) > >What is the attack vector here? Why does this need to be >cryptographically=20 >strong and how does it compromise the protocol's security? As it is >present in=20 >the clear in the header and the TCP session its-self is wrapped in a >(supposedly) suitable number, I can not see what I am protecting against >here. > >Is there any problems treating this as an opaque bitfield as it seems to >only=20 >be used in the MD5 XOR or is there some undocumented authentication >mechanism=20 >that makes use of this I will find in the field? > >> There will be no padding in any of the fields or at the end of a >>packet. > >If I see padding, do I kill the connection? Is this a SHOULD NOT? Padding may lead to make the Encryption even easier to decrypt, to the recommendation at this time would be to reject. However, Realistically, your data may have values that just happen to look like padding, so I suspect no one enforces this. This is one item that will get obsoleted by secure TACACS. > >> 3.6. Encryption >> >> In this case, the packet body is encrypted by XOR-ing it byte-wise >> with a pseudo random pad. >> >> ENCRYPTED {data} =3D=3D data ^ pseudo_pad > >I know it, you know it, everyone on OPSAWG probably knows it, but the >poor=20 >fresh out of university intern is going to really appreciate if you add: > >: The packet can then be decrypted by repeating the same process but >: on the encrypted data. >: >: data =3D=3D ENCRYPTED {data} ^ pseudo_pad > >:) Good catch ;-) > >> The version number is the one byte concatenation of the major and >> minor version numbers. >> >> The session id is used in network byte order. > >Easier to simply state 'as is in the header'? Agreed. > >> After a packet body is decrypted, the lengths of the component values >> in the packet are summed. If the sum is not identical to the >> cleartext datalength value from the header, the packet MUST be >> discarded, and an error signalled. The underlying TCP connection MAY >> also be closed, if it is not being used for other sessions in single- >> connect mode. >> >> Commonly such failures are seen when the keys are mismatched between >> the client and the TACACS+ server. > >If the keys are mis-matched, how could any of the other sessions be >valid? =20 This point has been made by other commentors. As mentioned above, revision will be to close connection after any legit sessions already established complete. >Also keeping the connection open surely is just going to produce a stream >of=20 >errors? Is it not safer to simply tear down the connection here; after >sending=20 >the terminating message? Yup, see above. > >> If an error must be declared but the type of the incoming packet >> cannot be determined, a packet with the identical cleartext header >> but with a sequence number incremented by one and the length set to >> zero MUST be returned to indicate an error. > >Wow, this is well hidden! Would this not be better around section 3.4? Agreed. > I=20 >cannot see how the packet would become valid after the XORing process, >maybe I=20 >am missing something here? > >> 4.4.1. Version Behaviour >> >> The TACACS+ protocol is versioned to allow revisions while >> maintaining backwards compatibility. The version number is in every >> packet header. The changes between minor_version 0 and 1 apply only >> to the authentication process, and all deal with the way that CHAP >> and PAP authentications are handled. minor_version 1 may only be used >> for authentication kinds that explicitly call for it in the table >> below: >> >> LOGIN CHPASS SENDAUTH >> ASCII v0 v0 - >> PAP v1 - v1 >> CHAP v1 - v1 >> MS-CHAPv1/2 v1 - v1 >> >> >> The '-' symbol represents that the option is not valid. >> >> When a server receives a packet with a minor_version that it does not >> support, it will return an ERROR status with the minor_version set to >> the closest supported value. > >Is it okay to tear down the connection if a non-valid but technically >could be=20 >supported combination is requested? Sure, with provisos above. In your case I assume you mean, a condition that would not be helped if same request was sent to any other method. (I.e. Bad password). > >> NOTE: Only those requests which have changed from their minor_version >> 0 implementation (i.e. CHAP, MS-CHAP and PAP authentications) will >> use the new minor_version number of 1. All other requests (i.e. all >> authorisation and accounting and ASCII authentication) MUST continue >> to use the same minor_version number of 0. The removal of SENDPASS >> was prompted by security concerns, and is no longer considered part >> of the TACACS+ protocol. > >Where can I read about SENDPASS? Will I see it out in the field? Though >it is=20 >not considered part of the protocol (vendor extension?) should it be >supported=20 >still? It should be deprecated. You can read about it in the Draft spec. I=B9ve stopped supporting it in last couple of versions of out T+ server, since 2007. > >> 4.4.2. Common Authentication Flows >> >> Inbound CHAP login >> >> ... >> >> The length of the challenge value can be determined from the length >> of the data field minus the length of the id (always 1 octet) and the >> length of the response field (always 16 octets). > >"note that unlike in RFC 1334, the length is not included in the value >and is=20 >derived instead from...". If you are pointing people at RFC's then for >me it=20 >helps me to have it explicitly stated where those deviations are. Maybe >this=20 >is just me though. Agreed. > >> Inbound MS-CHAP v2 login >> >> ... >> >> To perform the authentication, the server will use a the algorithm >> specified RFC2759 [RFC2759] on the user's secret and challenge and >> then compare the resulting value with the response. The REPLY from >> the server MUST be a PASS or FAIL. > >nit: '...will use -a- the algorithm specified...' Thanks. > >> 4.4.3. Aborting an Authentication Session >> >> ... >> >> When the status equals TAC_PLUS_AUTHEN_STATUS_FOLLOW the packet >> indicates that the TACACS+ server requests that authentication is >> performed with an alternate server. The data field MUST contain >> ASCII text describing one or more servers. A server description >> appears like this: >> >> [@@]>[@] >> >> If more than one host is specified, they MUST be separated into rows >> by an ASCII Carriage Return (0x0D). >> >> Use of the hosts in a TAC_PLUS_AUTHEN_STATUS_FOLLOW packet is at the >> discretion of the TACACS+ client. It may choose to use any one, all >> or none of these hosts. If it chooses to use none, then it MUST >> treat the authentication as if the return status was >> TAC_PLUS_AUTHEN_STATUS_FAIL. >> >> While the order of hosts in this packet indicates a preference, but >> the client is not obliged to use that ordering. > >This does not tell me what to actually do when I receive a list of more >than=20 >one host. Is this a client configuration which is coupled by the >administrator=20 >to the server configuration? I view this as an optional feature these days. I suspect it was a bit of an experiment in the first draft. But to answer your q: > >If multiple hosts are actually for failover purposes, what do I do if I >get an=20 >TAC_PLUS_AUTHEN_STATUS_FAIL from the first one? Do I take it as gospel >and not=20 >bother trying the other targets, or do I assume that it is broken and I >should=20 >retry against the other systems to seek a TAC_PLUS_AUTHEN_STATUS_PASS? The next upload will have more detail on FAIL vs ERROR. FAIL means: the process worked but the result was negative, so accept the FAIL and stop processing ERROR: means: the process broke for some reason, so try alternatives if you have them (I.e. As if this server was to contactable). > >> If the status equals TAC_PLUS_AUTHEN_STATUS_ERROR, then the host is >> indicating that it is experiencing an unrecoverable error and the >> authentication will proceed as if that host could not be contacted. >> The data field may contain a message to be printed on an >> administrative console or log. > >...and TAC_PLUS_AUTHEN_STATUS_FAIL could come back as the backend DB is >bust so=20 >"try other hosts too"? In real world situations, you=B9d probably want to make it tunable as to whether you returned FAIL or ERROR if backend DB is bust, but in most situations I think you=B9d default to ERROR here. > >> 5. Authorization >> >> 6. Accounting > >I have not gotten this far in my development work so I'll get back to you. > >> 9. TACACS+ Security Considerations >> >> ... >> >> To use IPsec where available. > >...boo! :) Tell me ;-) > >> Because of the security issues with TACACS+, the authors intend to >> follow up this document with an enhanced specification of the >> protocol employing modern security mechanisms. > >Where can I find out about the TLS approach? I saw in an earlier draft >TAC_PLUS_START_TLS but then in the OPSAWG mailing list archives it looks >like=20 >you are going for a dedicated port instead? Does TLS actually exist yet >anywhere or do I just ignore it for now? We have agreed to make an informational note for Opsawg of old protocol first, Secure TACACS+ will be hot on its heels. > From nobody Fri Nov 4 10:23:03 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B047129582; Fri, 4 Nov 2016 10:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digriz.org.uk 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 SX4UK0cPNyV6; Fri, 4 Nov 2016 10:23:00 -0700 (PDT) Received: from marmot.wormnet.eu (marmot.wormnet.eu [IPv6:2a03:9800:10:2d:3203:b3a5:8bdc:5b68]) (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 A31D2129505; Fri, 4 Nov 2016 10:23:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=digriz.org.uk; s=wopr; h=In-Reply-To:Content-Transfer-Encoding:Content-Type :MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=UjQnW4WB0cLT1p24N9PASV1DUEqiUbU++/qn1YTYKKs=; b=tuL84A6J0k9vzF3VTq+prz7Jn1 IRmReT99nrjnVLw2/q95Oqk2ixKwmXKqDQYXYVuPKUtbSHr/uiwJjB/+C3o2MqDTz/aQ5WT7Za5Z7 E+qYuMJFE8MQDKfc8wbOlj5nwjoYEiLxelfGD+8bMdFARnu7xy6h8xHnn1ErICUAdmrA=; Received: from [2a01:348:45:10:c982:bd21:949d:a2f] (helo=quatermain.digriz.wormnet.eu) by marmot.wormnet.eu with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86) (envelope-from ) id 1c2iCf-0006rU-S0; Fri, 04 Nov 2016 17:22:57 +0000 Date: Fri, 4 Nov 2016 17:22:56 +0000 From: Alexander Clouter To: "Douglas Gash (dcmgash)" Message-ID: <20161104172256.GC26023@quatermain.digriz.org.uk> References: <20161102231446.GA3842@quatermain.digriz.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Auto-Response-Suppress: OOF Organization: WormNET Jabber-ID: alex@digriz.org.uk User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "opsawg@ietf.org" , "draft-ietf-opsawg-tacacs@ietf.org" Subject: Re: [OPSAWG] implementing from reading draft-ietf-opsawg-tacacs-05 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 17:23:02 -0000 Thanks for the reply, just two or three notes on your reply. Thanks! On Thu, Nov 03, 2016 at 01:12:13PM +0000, Douglas Gash (dcmgash) wrote: >> >>> session_id >>> >>> The Id for this TACACS+ session. The session id is to be selected >>> randomly. This field does not change for the duration of the TACACS+ >>> session. (If this value is not a cryptographically strong random >>> number, it will compromise the protocol's security, see RFC 1750 >>> [RFC1750] ) >> >>What is the attack vector here? Why does this need to be >>cryptographically >>strong and how does it compromise the protocol's security? As it is >>present in >>the clear in the header and the TCP session its-self is wrapped in a >>(supposedly) suitable number, I can not see what I am protecting against >>here. The padding bit I knew, its why the session_id needs to come from a cryptographically strong source that I cannot understand the reasoning behind. >>If multiple hosts are actually for failover purposes, what do I do if I >>get an TAC_PLUS_AUTHEN_STATUS_FAIL from the first one? Do I take it as >>gospel and not bother trying the other targets, or do I assume that it is >>broken and I should retry against the other systems to seek a >>TAC_PLUS_AUTHEN_STATUS_PASS? > >The next upload will have more detail on FAIL vs ERROR. > >FAIL means: the process worked but the result was negative, so accept the >FAIL and stop processing >ERROR: means: the process broke for some reason, so try alternatives if >you have them (I.e. As if this server was to contactable). So multiple hosts here mean "only one needs to succeed to authenticate the use" as its purpose is for resilence? >>> If the status equals TAC_PLUS_AUTHEN_STATUS_ERROR, then the host is >>> indicating that it is experiencing an unrecoverable error and the >>> authentication will proceed as if that host could not be contacted. >>> The data field may contain a message to be printed on an >>> administrative console or log. >> >>...and TAC_PLUS_AUTHEN_STATUS_FAIL could come back as the backend DB is >>bust so "try other hosts too"? > >In real world situations, you¹d probably want to make it tunable as to >whether you returned FAIL or ERROR if backend DB is bust, but in most >situations I think you¹d default to ERROR here. My thinking is more tolerance of buggy third party equipment rather than how I should respond. From nobody Sun Nov 6 22:29:36 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16D48129C65; Sun, 6 Nov 2016 22:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 wOZHDbVbTe-h; Sun, 6 Nov 2016 22:29:32 -0800 (PST) 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 8EF78129C60; Sun, 6 Nov 2016 22:29:31 -0800 (PST) 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 CZV33475; Mon, 07 Nov 2016 06:29:28 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 7 Nov 2016 06:29:27 +0000 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; Mon, 7 Nov 2016 14:29:19 +0800 From: Zhoutianran To: "opsawg@ietf.org" , opsawg-chairs , "OPS-AREA@ietf.org" Thread-Topic: OPSAWG and OPS Area meeting agenda Thread-Index: AdI4wETwSIX1RMZQSMGOs1pE0HSnFQ== Date: Mon, 7 Nov 2016 06:29:18 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.58201F49.002A, 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: a0955c849419699fd3c4a2d222148556 Archived-At: Subject: [OPSAWG] OPSAWG and OPS Area meeting agenda X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 06:29:35 -0000 Hi All, =20 The meeting agenda is here: https://datatracker.ietf.org/doc/agenda-97-opsawg/ Welcome to join us for the discussion. Could the speakers please send your slides to the chairs before the meeting= ? =20 Thanks, Warren & Tianran From nobody Tue Nov 8 03:49:05 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6486D129A95; Tue, 8 Nov 2016 03:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJjZMhbOhQRP; Tue, 8 Nov 2016 03:49:03 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4577A129978; Tue, 8 Nov 2016 03:49:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4520; q=dns/txt; s=iport; t=1478605743; x=1479815343; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=D/D/eaYvP5CBK7/+mKiYiBO8L7/4lurEp1t/iJ2E16A=; b=EiXKlUf6Jd1ie82kFoIkSg5rmCQYYqe6+p54EW6F3weyKGwcTQNBCZhy D3c3rLAQX3L4x3Zisr22z7mTNHIFOEjF53aWmdfZybqP3qw4ZcEI0L6G4 Ca6owuR2iuOflBLFiIPOBbz6GnTSsvLVuBbrXFsxxIfgD0Fn6Qle6EpD+ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BrAQBfuiFY/5BdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgy8BAQEBAR+BVweNMpcDlFOCCIYkAhqBej8UAQIBAQEBAQEBYiiEYgE?= =?us-ascii?q?BBDRFEAIBCBgEKAICMCUCBA4FiFyUQp03BoJCi0gBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEfgQOKEoQyLYJngmIFmi8BkEeBboRyiTSNMIQFAR43KFKFKnKGLoEMAQEB?= X-IronPort-AV: E=Sophos;i="5.31,609,1473120000"; d="scan'208";a="345849680" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Nov 2016 11:49:02 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id uA8Bn2Um001240 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 8 Nov 2016 11:49:02 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 8 Nov 2016 05:49:01 -0600 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Tue, 8 Nov 2016 05:49:01 -0600 From: "Douglas Gash (dcmgash)" To: Alexander Clouter Thread-Topic: implementing from reading draft-ietf-opsawg-tacacs-05 Thread-Index: AQHSNdPkU1lDpJuYnUusg3ahXnkhyA== Date: Tue, 8 Nov 2016 11:49:01 +0000 Message-ID: References: <20161102231446.GA3842@quatermain.digriz.org.uk> <20161104172256.GC26023@quatermain.digriz.org.uk> In-Reply-To: <20161104172256.GC26023@quatermain.digriz.org.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.8.160830 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.1.3] Content-Type: text/plain; charset="euc-kr" Content-ID: <013282BF299E784A93C912D85F9C40AE@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "opsawg@ietf.org" , "draft-ietf-opsawg-tacacs@ietf.org" Subject: Re: [OPSAWG] implementing from reading draft-ietf-opsawg-tacacs-05 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 11:49:04 -0000 SGksDQoNClBsZWFzZSBzZWUgaW5saW5lLi4uDQoNCg0KT24gMDQvMTEvMjAxNiAxNzoyMiwgIkFs ZXhhbmRlciBDbG91dGVyIiA8YWxleCtvcHNhd2dAZGlncml6Lm9yZy51az4gd3JvdGU6DQoNCj5U aGFua3MgZm9yIHRoZSByZXBseSwganVzdCB0d28gb3IgdGhyZWUgbm90ZXMgb24geW91ciByZXBs eS4NCj4NCj5UaGFua3MhDQo+DQo+T24gVGh1LCBOb3YgMDMsIDIwMTYgYXQgMDE6MTI6MTNQTSAr MDAwMCwgRG91Z2xhcyBHYXNoIChkY21nYXNoKSB3cm90ZToNCj4+Pg0KPj4+PiAgIHNlc3Npb25f aWQNCj4+Pj4NCj4+Pj4gICBUaGUgSWQgZm9yIHRoaXMgVEFDQUNTKyBzZXNzaW9uLiAgVGhlIHNl c3Npb24gaWQgaXMgdG8gYmUgc2VsZWN0ZWQNCj4+Pj4gICByYW5kb21seS4gIFRoaXMgZmllbGQg ZG9lcyBub3QgY2hhbmdlIGZvciB0aGUgZHVyYXRpb24gb2YgdGhlDQo+Pj4+VEFDQUNTKw0KPj4+ PiAgIHNlc3Npb24uICAoSWYgdGhpcyB2YWx1ZSBpcyBub3QgYSBjcnlwdG9ncmFwaGljYWxseSBz dHJvbmcgcmFuZG9tDQo+Pj4+ICAgbnVtYmVyLCBpdCB3aWxsIGNvbXByb21pc2UgdGhlIHByb3Rv Y29sJ3Mgc2VjdXJpdHksIHNlZSBSRkMgMTc1MA0KPj4+PiAgIFtSRkMxNzUwXSApDQo+Pj4NCj4+ PldoYXQgaXMgdGhlIGF0dGFjayB2ZWN0b3IgaGVyZT8gIFdoeSBkb2VzIHRoaXMgbmVlZCB0byBi ZQ0KPj4+Y3J5cHRvZ3JhcGhpY2FsbHkNCj4+PnN0cm9uZyBhbmQgaG93IGRvZXMgaXQgY29tcHJv bWlzZSB0aGUgcHJvdG9jb2wncyBzZWN1cml0eT8gIEFzIGl0IGlzDQo+Pj5wcmVzZW50IGluDQo+ Pj50aGUgY2xlYXIgaW4gdGhlIGhlYWRlciBhbmQgdGhlIFRDUCBzZXNzaW9uIGl0cy1zZWxmIGlz IHdyYXBwZWQgaW4gYQ0KPj4+KHN1cHBvc2VkbHkpIHN1aXRhYmxlIG51bWJlciwgSSBjYW4gbm90 IHNlZSB3aGF0IEkgYW0gcHJvdGVjdGluZyBhZ2FpbnN0DQo+Pj5oZXJlLg0KPg0KPlRoZSBwYWRk aW5nIGJpdCBJIGtuZXcsIGl0cyB3aHkgdGhlIHNlc3Npb25faWQgbmVlZHMgdG8gY29tZSBmcm9t IGENCj5jcnlwdG9ncmFwaGljYWxseSBzdHJvbmcgc291cmNlIHRoYXQgSSBjYW5ub3QgdW5kZXJz dGFuZCB0aGUgcmVhc29uaW5nDQo+YmVoaW5kLg0KDQogVGhpcyBpcyBhbiBpbnRlcmVzdGluZyBw b2ludC4gV2UgbWF5IGhhdmUgZ29uZSBvdmVyYm9hcmQgdGhlcmUsIGFmdGVyDQphbGwsIGFzIHlv dSBzYXksIHRoZSBzZXNzaW9uIGlkIGlzIGluIHBsYWludGV4dCBhbnl3YXkuDQoNCg0KPg0KPj4+ SWYgbXVsdGlwbGUgaG9zdHMgYXJlIGFjdHVhbGx5IGZvciBmYWlsb3ZlciBwdXJwb3Nlcywgd2hh dCBkbyBJIGRvIGlmIEkNCj4+PmdldCBhbiBUQUNfUExVU19BVVRIRU5fU1RBVFVTX0ZBSUwgZnJv bSB0aGUgZmlyc3Qgb25lPyAgRG8gSSB0YWtlIGl0IGFzDQo+Pj5nb3NwZWwgYW5kIG5vdCBib3Ro ZXIgdHJ5aW5nIHRoZSBvdGhlciB0YXJnZXRzLCBvciBkbyBJIGFzc3VtZSB0aGF0IGl0DQo+Pj5p cyANCj4+PmJyb2tlbiBhbmQgSSBzaG91bGQgcmV0cnkgYWdhaW5zdCB0aGUgb3RoZXIgc3lzdGVt cyB0byBzZWVrIGENCj4+PlRBQ19QTFVTX0FVVEhFTl9TVEFUVVNfUEFTUz8NCj4+DQo+PlRoZSBu ZXh0IHVwbG9hZCB3aWxsIGhhdmUgbW9yZSBkZXRhaWwgb24gRkFJTCB2cyBFUlJPUi4NCj4+DQo+ PkZBSUwgbWVhbnM6IHRoZSBwcm9jZXNzIHdvcmtlZCBidXQgdGhlIHJlc3VsdCB3YXMgbmVnYXRp dmUsIHNvIGFjY2VwdCB0aGUNCj4+RkFJTCBhbmQgc3RvcCBwcm9jZXNzaW5nDQo+PkVSUk9SOiBt ZWFuczogdGhlIHByb2Nlc3MgYnJva2UgZm9yIHNvbWUgcmVhc29uLCBzbyB0cnkgYWx0ZXJuYXRp dmVzIGlmDQo+PnlvdSBoYXZlIHRoZW0gKEkuZS4gQXMgaWYgdGhpcyBzZXJ2ZXIgd2FzIHRvIGNv bnRhY3RhYmxlKS4NCj4NCj5TbyBtdWx0aXBsZSBob3N0cyBoZXJlIG1lYW4gIm9ubHkgb25lIG5l ZWRzIHRvIHN1Y2NlZWQgdG8gYXV0aGVudGljYXRlDQo+dGhlIHVzZSIgDQo+YXMgaXRzIHB1cnBv c2UgaXMgZm9yIHJlc2lsZW5jZT8NCg0KWWVzLiBKdXN0IGxpa2Ugb24gZGV2aWNlIG1ldGhvZCBs aXN0cyB0aGV5IG1heSBoYXZlIGEgc2V0IG9mIHNlcnZlcnMgdGhleQ0KdHJ5IHVudGlsIHRoZXkg Z2V0IGEgUEFTUyBvciBGQUlMLg0KDQo+DQo+Pj4+ICAgSWYgdGhlIHN0YXR1cyBlcXVhbHMgVEFD X1BMVVNfQVVUSEVOX1NUQVRVU19FUlJPUiwgdGhlbiB0aGUgaG9zdCBpcw0KPj4+PiAgIGluZGlj YXRpbmcgdGhhdCBpdCBpcyBleHBlcmllbmNpbmcgYW4gdW5yZWNvdmVyYWJsZSBlcnJvciBhbmQg dGhlDQo+Pj4+ICAgYXV0aGVudGljYXRpb24gd2lsbCBwcm9jZWVkIGFzIGlmIHRoYXQgaG9zdCBj b3VsZCBub3QgYmUgY29udGFjdGVkLg0KPj4+PiAgIFRoZSBkYXRhIGZpZWxkIG1heSBjb250YWlu IGEgbWVzc2FnZSB0byBiZSBwcmludGVkIG9uIGFuDQo+Pj4+ICAgYWRtaW5pc3RyYXRpdmUgY29u c29sZSBvciBsb2cuDQo+Pj4NCj4+Pi4uLmFuZCBUQUNfUExVU19BVVRIRU5fU1RBVFVTX0ZBSUwg Y291bGQgY29tZSBiYWNrIGFzIHRoZSBiYWNrZW5kIERCIGlzDQo+Pj5idXN0IHNvICJ0cnkgb3Ro ZXIgaG9zdHMgdG9vIj8NCj4+DQo+PkluIHJlYWwgd29ybGQgc2l0dWF0aW9ucywgeW91qfZkIHBy b2JhYmx5IHdhbnQgdG8gbWFrZSBpdCB0dW5hYmxlIGFzIHRvDQo+PndoZXRoZXIgeW91IHJldHVy bmVkIEZBSUwgb3IgRVJST1IgaWYgYmFja2VuZCBEQiBpcyBidXN0LCBidXQgaW4gbW9zdA0KPj5z aXR1YXRpb25zIEkgdGhpbmsgeW91qfZkIGRlZmF1bHQgdG8gRVJST1IgaGVyZS4NCj4NCj5NeSB0 aGlua2luZyBpcyBtb3JlIHRvbGVyYW5jZSBvZiBidWdneSB0aGlyZCBwYXJ0eSBlcXVpcG1lbnQg cmF0aGVyIHRoYW4NCj5ob3cgSSANCj5zaG91bGQgcmVzcG9uZC4NCg0KdGhhdKGvcyB3aGF0IEkg dGhvdWdodCwgd2hpY2ggaXMgd2h5IGluIHJlYWwgd29ybGQgeW91IG1heSB3YW50IHRvIG1ha2Ug aXQNCnR1bmVhYmxlLiBJbiB0aGlzIGNhc2UgYXJlIHlvdSBtZWFuaW5nIHRoZSBjbGllbnQgd2hp Y2ggbmVlZHMgdG8gZGVhbCB3aXRoDQphIHNlcnZlciB0aGF0IGlzIHNlbmRpbmcgYmFjayBGQUlM IHJhdGhlciB0aGFibiBFUlJPUiBpbiBjYXNlIGEgYmFja2VuZCBEQg0KaXMgZG93biAod2hlcmUg SaGvZCBzYXkgaXQgc2hvdWxkICBzZW5kIEVSUk9SKSwgb3IgYSBzZXJ2ZXIgZGV0ZXJtaW5pbmcg aG93DQpiZXN0IHRvIGRlYWwgd2l0aCBhIGJhY2tlbmQgREIgaXMgZG93biAobm9ybWFsbHkgRVJS T1IsIGJ1dCB3b3VsZCBjb25zaWRlcg0KdG8gbWFrZSBpdCB0dW5lYWJsZSkuDQoNCj4NCg0K From nobody Tue Nov 8 08:44:43 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 231DA12957F; Tue, 8 Nov 2016 08:44:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 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=-1.497, 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 GyyAmVfilgXq; Tue, 8 Nov 2016 08:44:34 -0800 (PST) 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 06D751294FF; Tue, 8 Nov 2016 08:44:33 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUT85900; Tue, 08 Nov 2016 16:44:31 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 8 Nov 2016 16:44:30 +0000 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Tue, 8 Nov 2016 08:44:26 -0800 From: Linda Dunbar To: "'opsawg@ietf.org'" , "'ops-dir@ietf.org'" Thread-Topic: solicit feedback to a new type of private network: like SD-WAN, but different in a way that many key properties of private network can be guaranteed ... Thread-Index: AdI53pqP2YGPap6SSGCSqYj0Rbi2ug== Date: Tue, 8 Nov 2016 16:44:25 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657F697CD@dfweml501-mbb> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.128] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657F697CDdfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.582200F0.0046, 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: 0e32dabbb6696592f37f893622f74393 Archived-At: Subject: [OPSAWG] solicit feedback to a new type of private network: like SD-WAN, but different in a way that many key properties of private network can be guaranteed ... X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 16:44:41 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657F697CDdfweml501mbb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Ops-area experts, Many of you probably have heard of SD-WAN lately. Not sure if people are aw= are that without proper interaction with the underlay network, some key pro= perties of private network can't be guaranteed. https://datatracker.ietf.org/doc/draft-dunbar-opsawg-private-networks-over-= thin-cpe/ describes a new types of private network service, which - is like SD-WAN in the way that IP tunnels are automatically established f= rom a thin-CPE at customer site, - but different from SD-WAN because there are interactions with the underla= y network (even though the interaction to underlay network is transparent t= o users), and there are gateways (for private networks) instantiated in th= e underlay network to establish secure connections between Thin-CPEs and th= e gateways, and guaranteed QoS from the underlay networks. The draft describes a private network laid over multiple Thin CPEs (or Ov= erlay VPN for easy of description). "Overlay VPN" is a type of private networks that interconnect thin CPEs at = multiple client sites by IP tunnels, or more specifically, lay over multipl= e client sites' Thin CPEs via IP tunnels. Those private overlay networks no= t only interconnect those sites by secure IP tunnels but can also enforce t= he client specified policies to govern how applications or hosts within tho= se sites communicate and how to access public internet. We are looking for feedback for the operation aspects described in the draf= t, and suggestions on potenial work listed in the draft. Thank you very much. Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F657F697CDdfweml501mbb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Ops-area experts,

Many of you probably have heard of SD-WA= N lately. Not sure if people are aware that without proper interaction with= the underlay network, some key properties of private network can’t be guaranteed.

https://datatracker.ietf.= org/doc/draft-dunbar-opsawg-private-networks-over-thin-cpe/ describes a new types of privat= e network service, which

- is like SD-WAN in= the way that IP tunnels are automatically established from a thin-CPE at c= ustomer site,

- but different fro= m SD-WAN because there are interactions with the underlay network (even tho= ugh the interaction to underlay network is transparent to users), and  = ;there are gateways (for private networks) instantiated in the underlay network to establish secure connections betwe= en Thin-CPEs and the gateways, and guaranteed QoS from the underlay network= s.

 

 

The draft describes= a private network laid over multiple Thin CPEs   (or Overlay VPN= for easy of description).

"Overlay VPN&q= uot; is a type of private networks that interconnect thin CPEs at multiple = client sites by IP tunnels, or more specifically, lay over multiple client = sites’ Thin CPEs via IP tunnels. Those private overlay networks not only interconnect those sites by secure IP tunnels bu= t can also enforce the client specified policies to govern how applications= or hosts within those sites communicate and how to access public internet.=  

 

 

We are looking for = feedback for the operation aspects described in the draft, and suggestions = on potenial work listed in the draft.

 

Thank you very much= .

 

Linda Dunbar

 

--_000_4A95BA014132FF49AE685FAB4B9F17F657F697CDdfweml501mbb_-- From nobody Thu Nov 10 22:19:15 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549811299DD for ; Thu, 10 Nov 2016 22:19:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 fAmWQ-3NPqHm for ; Thu, 10 Nov 2016 22:19:12 -0800 (PST) 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 434091299D8 for ; Thu, 10 Nov 2016 22:19:12 -0800 (PST) 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 DAE04889; Fri, 11 Nov 2016 06:19:09 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 11 Nov 2016 06:19:09 +0000 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; Fri, 11 Nov 2016 14:19:03 +0800 From: Zhoutianran To: "opsawg@ietf.org" Thread-Topic: discussions on OAM considerations for draft-chen-opsawg-composite-vpn-dm-00 Thread-Index: AQHSO+N/CLEN3JlgQEa0fW3mQD3JgQ== Date: Fri, 11 Nov 2016 06:19:02 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.582562DE.002C, 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: 1874882af19375f52c1f763181b5512b Archived-At: Subject: [OPSAWG] discussions on OAM considerations for draft-chen-opsawg-composite-vpn-dm-00 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 06:19:14 -0000 Hi, I was CCed with some interesting discussion on draft-chen-opsawg-composite-= vpn-dm-00. I got permit to share them in this mailing list. Regards, Tianran -----Original Message----- From: Fioccola Giuseppe [mailto:giuseppe.fioccola@telecomitalia.it]=20 Sent: Thursday, November 10, 2016 12:22 AM To: Lucy yong; Chenrui (Richard) Cc: Zhoutianran Subject: R: Welcome Giuseppe to the composite VPN work Hi Lucy, Yes, you got it right. So the OAM example is useful to strengthen the need for this work. Because the operator may want to monitor IP Metro and IP Core separately, o= r in same circumstances it is not possible to monitor end-to-end service an= d you can monitor only the different domains. Giuseppe -----Messaggio originale----- Da: Lucy yong [mailto:lucy.yong@huawei.com] Inviato: mercoled=EC 9 novembre 2016 15:16 A: Fioccola Giuseppe; Chenrui (Richard) Cc: Zhoutianran Oggetto: RE: Welcome Giuseppe to the composite VPN work Hi Giuseppe, When using L2VPN to construct AC link for an L3VPN, should we separate l2 O= AM (link) and L3 OAM (e2e)? Lucy -----Original Message----- From: Fioccola Giuseppe [mailto:giuseppe.fioccola@telecomitalia.it] Sent: Wednesday, November 09, 2016 5:25 AM To: Chenrui (Richard); Lucy yong Cc: Zhoutianran Subject: R: Welcome Giuseppe to the composite VPN work Hi Richard, For sure, we are on the same basis. My first suggestion about the requirements is that the composite VPN raises= a new topic that is the NNI between L2VPN and L3VPN. >From an operator point of view, it is important to model also the interface= between the two VPNs, other than for the service definition, there is a ne= ed of coordination also for the end-to-end OAM in case of different VPN (BF= D/RFC6374 for L3VPN and CFM/Y.1731 for L2VPN) in order to be conform to en= d-to-end SLA targets. Thanks Giuseppe From nobody Fri Nov 11 01:36:33 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25094129A9A; Fri, 11 Nov 2016 01:36:31 -0800 (PST) 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] 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 NWDba-W6uSZJ; Fri, 11 Nov 2016 01:36:30 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACCB112940D; Fri, 11 Nov 2016 01:36:29 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id uAB9aSbA030056; Fri, 11 Nov 2016 09:36:28 GMT Received: from 950129200 (host217-36-58-153.in-addr.btopenworld.com [217.36.58.153]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id uAB9aGSL030021 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 11 Nov 2016 09:36:25 GMT From: "Adrian Farrel" To: "'opsawg@ietf.org'" Date: Fri, 11 Nov 2016 09:36:13 -0000 Message-ID: <0ac301d23bff$11c024f0$35406ed0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdI7/u1pNuWTMdmkQv2A101isKQxmw== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22692.006 X-TM-AS-Result: No--3.227-10.0-31-10 X-imss-scan-details: No--3.227-10.0-31-10 X-TMASE-MatchedRID: CSP2yg+Ty9POf6FUr/HJkVPjo7D4SFg4vNY4Opm8STkKXKtfi06bFKPF jJEFr+olfeZdJ1XsorgUBfgS1SLQ+AtuKBGekqUpbGVEmIfjf3supnOYk//i2EdScQ1CDpgOSaU XAaABw7Ueyfhi0Zt1Vo+N4DlhKQwQh8f9+fd10RPkvmU7gj2frT4n7o4CNd3aPbiTch0pm34= Archived-At: Cc: l2sm-chairs@ietf.org Subject: [OPSAWG] Formation of "L2VPN as a service" working group X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 09:36:31 -0000 Hi operational people, Please note that the L2SM working group has been formed and will meet in Seoul on Thursday at 9:30. The focus is the development of a YANG model for the provision of L2VPN services on the interface between operator and customer. Thanks, Adrian From nobody Mon Nov 14 03:07:49 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DACB81297CB; Mon, 14 Nov 2016 03:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 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=-1.497, 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 LoqgH-2gJ-kx; Mon, 14 Nov 2016 03:07:47 -0800 (PST) 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 6584F129608; Mon, 14 Nov 2016 03:07:45 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAI40972; Mon, 14 Nov 2016 11:07:42 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 14 Nov 2016 11:06:10 +0000 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; Mon, 14 Nov 2016 19:06:05 +0800 From: Zhoutianran To: "opsawg@ietf.org" , opsawg-chairs Thread-Topic: opsawg meeting slides Thread-Index: AdI+ZxeUNvQJnsffRZq1nRu2VHx49g== Date: Mon, 14 Nov 2016 11:06:04 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_etPan58299a9c57455920355iPhone6_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.58299AFF.0067, 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: 49990b96e10ae20b6e09cd2239608422 Archived-At: Subject: [OPSAWG] opsawg meeting slides X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 11:07:49 -0000 --_000_etPan58299a9c57455920355iPhone6_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBTcGVha2VycywNCg0KQ291bGQgeW91IHBsZWFzZSBtYWtlIHN1cmUgeW91IHNlbmQgdGhl IHNsaWRlcyBpbiB0aW1lPw0KDQpCZXN0LA0KVGlhbnJhbg0KDQoNClNlbnQgZnJvbSBIVUFXRUkg QW55T2ZmaWNlDQo= --_000_etPan58299a9c57455920355iPhone6_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdj5EZWFyJm5i c3A7U3BlYWtlcnMsPGJyPg0KPGJyPg0KQ291bGQmbmJzcDt5b3UmbmJzcDtwbGVhc2UmbmJzcDtt YWtlJm5ic3A7c3VyZSZuYnNwO3lvdSZuYnNwO3NlbmQmbmJzcDt0aGUmbmJzcDtzbGlkZXMmbmJz cDtpbiZuYnNwO3RpbWU/PGJyPg0KPGJyPg0KQmVzdCw8YnI+DQpUaWFucmFuPGJyPg0KPGJyPg0K PGJyPg0KU2VudCZuYnNwO2Zyb20mbmJzcDtIVUFXRUkmbmJzcDtBbnlPZmZpY2U8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_etPan58299a9c57455920355iPhone6_-- From nobody Tue Nov 15 00:19:55 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7692129502 for ; Tue, 15 Nov 2016 00:19:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.017 X-Spam-Level: X-Spam-Status: No, score=-16.017 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPXbjjQ3VJF9 for ; Tue, 15 Nov 2016 00:19:52 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B77A1294E3 for ; Tue, 15 Nov 2016 00:19:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1570; q=dns/txt; s=iport; t=1479197992; x=1480407592; h=from:to:subject:date:message-id:mime-version; bh=Hyc7Pz7K3NmWYKZJCPRX3yWwsMmUUlZTTzvCKMa/uO4=; b=i8qxBu5fx1BFuq3TvHBUDalKy3/et6d/Mn8Xl2t/dEL61aQkRFz4rHkj dcqaex6djiFG6BveaJpaUWUydje2izZpB2KWqvMdVxB/lOucOE2hUMnHR zQvX2F6KZ53lYyJfPPu7y9mpm97Pdxemc0bzpXLUiQHeytFajD0QvmlZ4 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DnAQCfxCpY/5JdJa1dHAEBBAEBCgEBg?= =?us-ascii?q?zQBAQEBAR9YgQCNPqZQhRyCByiGF4IWPxQBAgEBAQEBAQFiHQuEWBAjaAELAT4?= =?us-ascii?q?CBDAnBIh6Dp9oj3yCKYtcAQEBAQEBBAEBAQEBAQEBAQEBHIY8gX0IiiEtgjAFm?= =?us-ascii?q?kEBhjuKJZAiiTqIFgEeN4EEhThyAYc9AQEB?= X-IronPort-AV: E=Sophos;i="5.31,641,1473120000"; d="scan'208,217";a="174251116" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Nov 2016 08:19:51 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id uAF8Jpia027467 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 15 Nov 2016 08:19:51 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 15 Nov 2016 02:19:50 -0600 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1210.000; Tue, 15 Nov 2016 02:19:50 -0600 From: "Joe Clarke (jclarke)" To: "opsawg@ietf.org" Thread-Topic: iOAM and SFC KPI stamping Thread-Index: AQHSPxkJmlZdnoTJKkSEaexvFiepoA== Date: Tue, 15 Nov 2016 08:19:50 +0000 Message-ID: <21165448-F000-4E64-9C6A-54A0D006ED10@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_21165448F0004E649C6A54A0D006ED10ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [OPSAWG] iOAM and SFC KPI stamping X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 08:19:54 -0000 --_000_21165448F0004E649C6A54A0D006ED10ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Um9yeSBCcm93bmUgcHJlc2VudGVkIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1i cm93bmUtc2ZjLW5zaC1rcGktc3RhbXAtMDAuaHRtbCBpbiBTRkMsIGFuZCBJIHdvbmRlciBob3cg dGhpcyBwbGF5cyB3aXRoIEluIFNpdHUgT0FNPyAgSXQgc2VlbXMgdGhhdCBpT0FNIG1pZ2h0IGJl IGFibGUgdG8gc3Vic3VtZSB0aGlzPw0KDQpKb2UNCg0KUEdQIEtleSA6IGh0dHA6Ly93d3cubWFy Y3VzY29tLmNvbS9wZ3AuYXNjDQo= --_000_21165448F0004E649C6A54A0D006ED10ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PlJvcnkgQnJvd25lIHByZXNlbnRlZCZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1icm93bmUtc2ZjLW5zaC1rcGktc3RhbXAtMDAuaHRtbCI+aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJyb3duZS1zZmMtbnNoLWtwaS1zdGFtcC0wMC5o dG1sPC9hPiZuYnNwO2luIFNGQywgYW5kIEkgd29uZGVyIGhvdyB0aGlzIHBsYXlzIHdpdGggSW4g U2l0dSBPQU0/ICZuYnNwO0l0IHNlZW1zIHRoYXQgaU9BTSBtaWdodCBiZQ0KIGFibGUgdG8gc3Vi c3VtZSB0aGlzPzwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj48YnI+DQo8L2Rp dj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+Sm9lPGJyPg0KPGJyPg0KUEdQIEtleSA6 IDxhIGhyZWY9Imh0dHA6Ly93d3cubWFyY3VzY29tLmNvbS9wZ3AuYXNjIj5odHRwOi8vd3d3Lm1h cmN1c2NvbS5jb20vcGdwLmFzYzwvYT48L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_21165448F0004E649C6A54A0D006ED10ciscocom_-- From nobody Tue Nov 15 00:25:04 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 665E31294E3 for ; Tue, 15 Nov 2016 00:25:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 yTRizW-fXEE1 for ; Tue, 15 Nov 2016 00:25:01 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1830B1294F3 for ; Tue, 15 Nov 2016 00:25:00 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id uAF8Oupc021762; Tue, 15 Nov 2016 08:24:56 GMT Received: from 950129200 (dhcp-8717.meeting.ietf.org [31.133.135.23]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id uAF8OpXW021689 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 15 Nov 2016 08:24:53 GMT From: "Adrian Farrel" To: "'Joe Clarke \(jclarke\)'" , References: <21165448-F000-4E64-9C6A-54A0D006ED10@cisco.com> In-Reply-To: <21165448-F000-4E64-9C6A-54A0D006ED10@cisco.com> Date: Tue, 15 Nov 2016 08:24:49 -0000 Message-ID: <03d801d23f19$bda33dd0$38e9b970$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03D9_01D23F19.BDA6C040" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFKdhOODMm80cU0OwuO4upb+661pqHpRw+g Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22700.004 X-TM-AS-Result: No--20.251-10.0-31-10 X-imss-scan-details: No--20.251-10.0-31-10 X-TMASE-MatchedRID: Kx0w2sAofbunykMun0J1wlz+axQLnAVBkT7cMJfe6JvnnSt+j12Clmrr AGyO72KP+H5zDDs0S2pWT9FmHCYatNbPpD88bJhVylAqNTt8FdVr9+Kgn2XgeDA4N9SXuYkpS1T j+kqv+huVu5TRVGSDEdtaN8VSEQvzw1hXve9gEVCO0rt0LpQGeRSpYqhygmjp6ygMMToK892nhZ ybKoFsXELduO9IO73n36y5gCD1lYkzG8Dg48sJ/vIVL3+KSNgwkTzAgHG5eNKgJH974mpbq6gTk LgTtTggXql2hIcwl2sTHy/6jlpjHT4gGkEowIKZNs3S39zaoXYU2wesiIXyuxW+93iqRvX7VD4I X3GhzkucTZGiBUd8fawQUp5/xlTGlyrPeDQDh/K6kMgL3jbYOtMxD/3e8TxdRtqpRW8sWyKakVW YYDXrTswMS4ODXmCsnuOhtEsGi0ZP5mzaUz6wQBD3+0w1DhqK3kR1SkDo278ML9Wb3Qh/ha0QmL 2wrxWPWU8XtC6NtyQqhZrv4f7cO34FjWYN+jMve5NWR5iixe05LRtPnepd1TdHHXXKh5RCeUQNv U47zui7sLiGJ4XBUoAy6p60ZV620u+wqOGzSV3x0Der+6P8v9mzcdRxL+xweSC65CityAz/c6NY ClMjhtGLQnMYz/10eBgbDTi/0ZDAVkI6OPuvVX7cGd19dSFd Archived-At: Subject: Re: [OPSAWG] iOAM and SFC KPI stamping X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 08:25:03 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03D9_01D23F19.BDA6C040 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thanks Joe, And to add to that, the SFC WG seems to be building a head of steam to = work on OAM, and now looks like a good time to influence that work. =20 Adrian =20 From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Joe Clarke = (jclarke) Sent: 15 November 2016 08:20 To: opsawg@ietf.org Subject: [OPSAWG] iOAM and SFC KPI stamping =20 Rory Browne presented = https://tools.ietf.org/html/draft-browne-sfc-nsh-kpi-stamp-00.html in = SFC, and I wonder how this plays with In Situ OAM? It seems that iOAM = might be able to subsume this? =20 Joe PGP Key : http://www.marcuscom.com/pgp.asc ------=_NextPart_000_03D9_01D23F19.BDA6C040 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Thanks = Joe,

And to add to that, the SFC WG = seems to be building a head of steam to work on OAM, and now looks like = a good time to influence that work.

 

Adrian

 

From: OPSAWG = [mailto:opsawg-bounces@ietf.org] On Behalf Of Joe Clarke = (jclarke)
Sent: 15 November 2016 08:20
To: = opsawg@ietf.org
Subject: [OPSAWG] iOAM and SFC KPI = stamping

 

Rory Browne = presented https://tools.ietf.org/html/draft-browne-sfc-nsh-kpi-stamp-00.html=  in SFC, and I wonder how this plays with In Situ OAM?  It = seems that iOAM might be able to subsume = this?

 

------=_NextPart_000_03D9_01D23F19.BDA6C040-- From nobody Tue Nov 15 00:40:33 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36FEB12965D; Tue, 15 Nov 2016 00:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 EQOX2sqDz4u8; Tue, 15 Nov 2016 00:40:30 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C0FE129450; Tue, 15 Nov 2016 00:40:30 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id uAF8ePan001851; Tue, 15 Nov 2016 08:40:26 GMT Received: from 950129200 (dhcp-8717.meeting.ietf.org [31.133.135.23]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id uAF8eLZb001787 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 15 Nov 2016 08:40:24 GMT From: "Adrian Farrel" To: "Frank Brockners \(fbrockne\)" Date: Tue, 15 Nov 2016 08:40:19 -0000 Message-ID: <03f601d23f1b$e8939a60$b9bacf20$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdI/G+N+iqxJrmbkT+CXwKU015D7Ew== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22700.004 X-TM-AS-Result: No--4.435-10.0-31-10 X-imss-scan-details: No--4.435-10.0-31-10 X-TMASE-MatchedRID: Kwpr3ciGJDslO3FWVopgW5U7Bltw5qVL6Jj6zYvfFASmmLSQRiN07EH1 3sTd5nmQlRpUC3Taq0lbdrmQgOENAGResrHRY7dKngIgpj8eDcC063Wh9WVqgpgZQ9043V5e+gt Hj7OwNO2OhzOa6g8KrZIxOFupPsdDSx8mkC1/NvMZQOsCQRC6iHlCmr8g5jcQRASQJN9HVgLkP2 yapUEP3KKWedUMQI938fsC+xPFkxvsNp90fT4EjrAUyUg9ogFt Archived-At: Cc: opsawg@ietf.org, rtgwg@ietf.org Subject: [OPSAWG] Random numbers and In-situ OAM X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 08:40:32 -0000 Hi Frank, Thought I had possibly mis-heard in RTGWG, but heard you again in OPSAWG say something about "using part of a random number" . I just ran off to look at draft-brockners*.txt and searched "random". I see some discussion of random numbers that looks fine, but I don't see anything (which may be my eyesight :-) about taking part of a random number. Do you have a pointer or a quick explanation? (Or you can tell me that my hearing is impaired!) Thanks, Adrian From nobody Tue Nov 15 00:55:05 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85DE129A5A; Tue, 15 Nov 2016 00:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id auBKtlaOHqT6; Tue, 15 Nov 2016 00:55:02 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70C09129A54; Tue, 15 Nov 2016 00:55:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1227; q=dns/txt; s=iport; t=1479200102; x=1480409702; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=6Aaf4/hhyGZJirEiegMhN7UcXYWiMRDsc+5okbUndJU=; b=Ior4V0NysJBCcoDal0g8gc9/yKubptwGNOHfx+yrFGhvTM+pEv7t5FzZ 2BxhitRbhGN8TiDky3Vzf8s+5LOzDoMeJO6ztO9as/pmLyQaO72h1kMBP G5koogh3bWZwm2Ue9EKi9SgYT3tHY7KxSK+LDTrraqgCthyLjtc/pBKUI 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BtAQBCzCpY/4YNJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgykLAQEBAQEfWIEAB403lwqUYoIHKoV5AoIwPxQBAgEBAQEBAQFiHQu?= =?us-ascii?q?EYQEBAQQ6PwwEAgEIEQQBAR8JBzIUCQgBAQQOBQiIXw6yGYtcAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBFwWGPIRaiikFmkEBhjuKHpApjUeECQEeN4EEhThyAYYxgQw?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.31,641,1473120000"; d="scan'208";a="169425249" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Nov 2016 08:55:01 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id uAF8t1VR007148 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 15 Nov 2016 08:55:01 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 15 Nov 2016 02:55:00 -0600 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1210.000; Tue, 15 Nov 2016 02:55:00 -0600 From: "Frank Brockners (fbrockne)" To: "adrian@olddog.co.uk" Thread-Topic: Random numbers and In-situ OAM Thread-Index: AdI/G+N+iqxJrmbkT+CXwKU015D7EwAAUggw Date: Tue, 15 Nov 2016 08:55:00 +0000 Message-ID: <70bf34c2da6b4c0fb39499f8970d75c6@XCH-RCD-008.cisco.com> References: <03f601d23f1b$e8939a60$b9bacf20$@olddog.co.uk> In-Reply-To: <03f601d23f1b$e8939a60$b9bacf20$@olddog.co.uk> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.99.91] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "opsawg@ietf.org" , "rtgwg@ietf.org" Subject: Re: [OPSAWG] Random numbers and In-situ OAM X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 08:55:03 -0000 Hi Adrian, what I was referring to was protecting against preplay attacks - see sectio= n 8.4 of draft-brockners-proof-of-transit-02: https://tools.ietf.org/html/draft-brockners-proof-of-transit-02#section-8.4 To protect against pre-play, we suggest to leverage a part of the HMAC of a= part of the packet which isn't modified as it traverses the network for th= e random number RND which serves as a unique identifier for the packet for = POT. Regards, Frank -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Dienstag, 15. November 2016 17:40 To: Frank Brockners (fbrockne) Cc: opsawg@ietf.org; rtgwg@ietf.org Subject: Random numbers and In-situ OAM Hi Frank, Thought I had possibly mis-heard in RTGWG, but heard you again in OPSAWG sa= y something about "using part of a random number" . I just ran off to look at draft-brockners*.txt and searched "random". I see some discussion of random numbers that looks fine, but I don't see an= ything (which may be my eyesight :-) about taking part of a random number. Do you have a pointer or a quick explanation? (Or you can tell me that my h= earing is impaired!) Thanks, Adrian From nobody Tue Nov 15 00:59:55 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000E0129A4F; Tue, 15 Nov 2016 00:59:54 -0800 (PST) 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] 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 IHcRY34Ek6Uv; Tue, 15 Nov 2016 00:59:53 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF50E129A14; Tue, 15 Nov 2016 00:59:52 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id uAF8xlKd016670; Tue, 15 Nov 2016 08:59:48 GMT Received: from 950129200 (dhcp-8717.meeting.ietf.org [31.133.135.23]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id uAF8xhAs016560 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 15 Nov 2016 08:59:46 GMT From: "Adrian Farrel" To: "'Frank Brockners \(fbrockne\)'" References: <03f601d23f1b$e8939a60$b9bacf20$@olddog.co.uk> <70bf34c2da6b4c0fb39499f8970d75c6@XCH-RCD-008.cisco.com> In-Reply-To: <70bf34c2da6b4c0fb39499f8970d75c6@XCH-RCD-008.cisco.com> Date: Tue, 15 Nov 2016 08:59:42 -0000 Message-ID: <042301d23f1e$9d0d9ed0$d728dc70$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGW8rctjXCJp3bwDahVlYNGQSFWtQE8B2izoUZ3NwA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22700.004 X-TM-AS-Result: No--2.504-10.0-31-10 X-imss-scan-details: No--2.504-10.0-31-10 X-TMASE-MatchedRID: +c13yJDs902nykMun0J1wk0jzafXv7tTt3aeg7g/usAutoY2UtFqGFdV hcU0C7v47rYjKjSGs+00XpaalahVvWQexWkOikPfIQrubkFPQdn4uJ1REX4MHcj0Eew4TN42T2S tOYQOF4xomunNhX9ozFgVldL/B76CTX7PJ/OU3vL+xOhjarOnHmrz/G/ZSbVq+gtHj7OwNO0HTT +SR4FPAKa+cSIr8y71phXG7EO+bhPm9rG7E3AeLDvslVKsqoiGNCz4s9JbQsvuH5vc+njcTiJXe 5ZKsmOiFJU+DpUzDG5q+2ErM4E74IfH/fn3ddET5L5lO4I9n60+J+6OAjXd2j24k3IdKZt+ Archived-At: Cc: opsawg@ietf.org, rtgwg@ietf.org Subject: Re: [OPSAWG] Random numbers and In-situ OAM X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 08:59:55 -0000 Brilliant, thanks Frank. My eyesight failed me. I'll read and digest. Adrian > -----Original Message----- > From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com] > Sent: 15 November 2016 08:55 > To: adrian@olddog.co.uk > Cc: opsawg@ietf.org; rtgwg@ietf.org > Subject: RE: Random numbers and In-situ OAM > > Hi Adrian, > > what I was referring to was protecting against preplay attacks - see section 8.4 of > draft-brockners-proof-of-transit-02: > https://tools.ietf.org/html/draft-brockners-proof-of-transit-02#section-8.4 > > To protect against pre-play, we suggest to leverage a part of the HMAC of a part > of the packet which isn't modified as it traverses the network for the random > number RND which serves as a unique identifier for the packet for POT. From nobody Wed Nov 16 18:00:58 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B1C1293D8; Wed, 16 Nov 2016 18:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 6iXTVazSbqlp; Wed, 16 Nov 2016 18:00:54 -0800 (PST) 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 E52541293F9; Wed, 16 Nov 2016 18:00:53 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAR45425; Thu, 17 Nov 2016 02:00:51 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 17 Nov 2016 02:00:51 +0000 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; Thu, 17 Nov 2016 10:00:45 +0800 From: Zhoutianran To: "adrian@olddog.co.uk" , "l2sm@ietf.org" Thread-Topic: [L2sm] The I-D we mentioned that discussed "service models" Thread-Index: AdJAdOwHxn/mPPqOTZ60iHj+kJtYcgAAIk0Y Date: Thu, 17 Nov 2016 02:00:45 +0000 Message-ID: References: <092601d24074$f0a40230$d1ec0690$@olddog.co.uk> In-Reply-To: <092601d24074$f0a40230$d1ec0690$@olddog.co.uk> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.112.153] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.582D0F54.0051, 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: d9dfe5c3556fbf20bf8bcd39f8ebe296 Archived-At: Cc: "opsawg@ietf.org" Subject: [OPSAWG] FW: [L2sm] The I-D we mentioned that discussed "service models" X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 02:00:56 -0000 WWVzLiBJIGFtIHNpdHRpbmcgaW4gdGhlIEwyU00gbWVldGluZyByb29tLCBhbmQgaGVhcmQgbWFu eSBkaXNjdXNzaW9ucyBhYm91dCB0aGUgdGVybWlub2xvZ3kgd3J0IHRoZSBzZXJ2aWNlIG1vZGVs LiANCk9idmlvdXNseSwgdGhvc2UgdGVybXMgYW5kIGRlZmluaXRpb25zIGFyZSBjb25mdXNpb24s IGJ1dCBpbXBvcnRhbnQgYW5kIG5lZWQgd2lkZWx5IGRpc2N1c3NlZC4NClBsZWFzZSBjb21lIHRv IHRoZSBvcHNhd2cgbWFpbGluZyBsaXN0LCBhbmQgaGVscCB0aGUgYXV0aG9ycyB0byBpbXByb3Zl IHRoZSBkb2N1bWVudC4NCg0KQmVzdCwNClRpYW5yYW4NCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBMMnNtIFtsMnNtLWJvdW5jZXNAaWV0Zi5vcmdd ILT6se0gQWRyaWFuIEZhcnJlbCBbYWRyaWFuQG9sZGRvZy5jby51a10NCreiy83KsbzkOiAyMDE2 xOoxMdTCMTfI1SA5OjUwDQrK1bz+yMs6IGwyc21AaWV0Zi5vcmcNCtb3zOI6IFtMMnNtXSBUaGUg SS1EIHdlIG1lbnRpb25lZCB0aGF0IGRpc2N1c3NlZCAic2VydmljZSBtb2RlbHMiDQoNCkhpLA0K DQpCZW5vaXQgcG9pbnRlZCBvdXIgZGlzY3Vzc2lvbiBvZiAid2hhdCBpcyBhIHNlcnZpY2UgbW9k ZWwiIHRvOg0KLSBUaGUgT1BTQVdHIG1haWxpbmcgbGlzdA0KLSBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC13dS1vcHNhd2ctc2VydmljZS1tb2RlbC1leHBsYWluZWQvDQoN Ck5vdGluZyB0aGF0IHRoaXMgaXMgbm90IGFuIE9QU0FXRyBkcmFmdCBhdCB0aGUgbW9tZW50LCBi dXQgdGhhdCB0aGVyZSB3YXMNCihhcHBhcmVudGx5KSBzb21lIHN1cHBvcnQgZm9yIHdvcmtpbmcg b24gaXQgd2hlbiBpdCB3YXMgcHJlc2VudGVkIGluIHRoZSBPUFNBV0cNCm1lZXRpbmcgdGhpcyB3 ZWVrLg0KDQpTZWUgYWxzbyB0aGUgc2xpZGVzIGZvciB0aGF0IHByZXNlbnRhdGlvbiBhdA0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTcvc2xpZGVzL3NsaWRlcy05Ny1vcHNhd2ct c2VydmljZS1tb2RlbC1leHBsYWkNCm5lZC0wMC5wZGYNCg0KSSB0aGluayB3aGF0IEJlbm9pdCBt ZWFucyBpcyAiUGxlYXNlIGhhdmUgdGhlIGRpc2N1c3Npb24gaW4gT1BTQVdHIHNvIHRoYXQgd2UN CmNhbiByZWFjaCBhbiBBcmVhLXdpZGUgZGVjaXNpb24gYW5kIHRoZW4gYXBwbHkgaXQgdG8gTDJT TS4iDQoNClRoYW5rcywNCkFkcmlhbg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KTDJzbSBtYWlsaW5nIGxpc3QNCkwyc21AaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbDJzbQ== From nobody Fri Nov 18 21:06:14 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C0912949E; Fri, 18 Nov 2016 21:06:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 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=-1.497, 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 zXh_EluoGEpi; Fri, 18 Nov 2016 21:06:08 -0800 (PST) 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 1A01B129478; Fri, 18 Nov 2016 21:06:07 -0800 (PST) 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 DAX72720; Sat, 19 Nov 2016 05:06:05 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sat, 19 Nov 2016 05:06:05 +0000 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; Sat, 19 Nov 2016 13:05:58 +0800 From: Lizhenbin To: "sdn@irtf.org" , "rtgwg@ietf.org" , "opsawg@ietf.org" Thread-Topic: Introduction of Network Artificial Intelligence (draft-li-rtgwg-network-ai-arch) Thread-Index: AdJCHa2bCAzKbGz9RBiOWdIH1vai8w== Date: Sat, 19 Nov 2016 05:05:58 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D8DE9A34A@NKGEML515-MBX.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.115.180] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D8DE9A34ANKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.582FDDBE.009E, 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: b7749d3ac8d6b7827dda270d027a2958 Archived-At: Subject: [OPSAWG] Introduction of Network Artificial Intelligence (draft-li-rtgwg-network-ai-arch) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2016 05:06:11 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D8DE9A34ANKGEML515MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgU0ROUkdlcnMvUlRHV0dlcnMvT1BTQVdHZXJzLA0KDQoNCg0KRm9yIFJUR1dHIHNpbmNlIEkg c3RheWVkIHVwIHRoZSB3aG9sZSBuaWdodCBmb3Igc29tZSByZWFzb24sIHNvcnJ5IGZvciB0aGF0 IEkgY291bGQgbm90IHJldmlldyB0aGUgcHJlc2VudGF0aW9uIHNsaWRlIG9mIGRyYWZ0LCBkcmFm dC1saS1ydGd3Zy1uZXR3b3JrLWFpLWFyY2gsDQoNCmNhcmVmdWxseSBhbmQgY29ycmVjdCB0aGUg cG9zc2libGUgZXJyb3JzIGJlZm9yZSBJIGRpZCB0aGUgcHJlc2VudGF0aW9uIGluIHRoZSBSVEdX RyBzZXNzaW9uIG1lZXRpbmcuIE5vdyBJIGhhdmUgbW9kaWZpZWQgdGhlIHNsaWRlIGFuZCB0aGUg Y2hhaXIgYWxyZWFkeSBoZWxwZWQNCg0KdXBkYXRlIHRoZSBzbGlkZSBpbiB0aGUgSUVURiBwYWdl IChUaGFuayB5b3UgSmVmZikuDQoNCg0KDQpJIGhvcGUgeW91IHdobyBoYXZlIGludGVyZXN0IGlu IHRoZSB3b3JrIGNhbiBnZXQgdGhlIHNsaWRlIG9mIHRoZSBTRE5SRyBzZXNzaW9uIG1lZXRpbmcg c2luY2UgSSBwcmVzZW50ZWQgdGhlIGRyYWZ0IGluIGJvdGggU0ROUkcgYW5kIFJUR1dHIHNlc3Np b24NCg0KbWVldGluZ3MgaW4gSUVURjk3Lg0KDQotLSBnYW1lc2xpZGVzLTk3LXNkbnJnLTM0LWFu LWFyY2hpdGVjdHVyZS1vZi1uZXR3b3JrLWFydGlmaWNpYWwtaW50ZWxsaWdlbmNlbmFpLTAwDQoN Cg0KDQpGb3IgTmV0d29yayBBcnRpZmljaWFsIEludGVsbGlnZW50LCB3ZSBoYXZlIGZpbmlzaGVk IHNvbWUgcHJvdG90eXBlJ3MgaW1wbGVtZW50YXRpb24gc2hvd24gaW4gdGhlIHBhZ2UgOCBvZiB0 aGUgc2xpZGUsIGdhbWVzbGlkZXMtOTctc2RucmctMzQtYW4tDQoNCmFyY2hpdGVjdHVyZS1vZi1u ZXR3b3JrLWFydGlmaWNpYWwtaW50ZWxsaWdlbmNlbmFpLTAwLiBXZSBpbXBsZW1lbnRlZCB0aGUg RUxLLWJhc2VkIExvZyBTZWFyY2ggRW5naW5lIGFuZCBvbmUgdHlwaWNhbCB1c2VjYXNlIG9mIGRl dGVjdGluZyBhYm5vcm1hbCBsb2cNCg0KYmFzZWQgb24gdGhlIE9wZW4gU291cmNlIEJpZyBEYXRh LCBEYXRhYmFzZSwgTWFjaGluZSBMZWFybmluZyBhbmQgRGlzdHJpYnV0ZWQgQ29tbXVuaWNhdGlv biwgZXRjLiwgdGVjaG5vbG9naWVzLg0KDQoNCg0KVGhyb3VnaCB0aGUgcHJvdG90eXBlIHdvcmss IHdlIGJlbGlldmUgdGhlIGlkZWEgb2YgTmV0d29yayBBcnRpZmljaWFsIEludGVsbGlnZW5jZSBk b3NlIHdvcmsgYW5kIHdlIGFyZSBhd2FyZSB0aGF0IHRoZSBzdWNjZXNzIG9mIE5BSSBuZWVkIGh1 Z2UgdHJhZGl0aW9uYWwvDQoNCmFkdmFuY2VkIGtub3dsZWRnZS90ZWNobm9sb2dpZXMvYmFzaWMg c2NpZW5jZSBhbmQgaXQgd2lsbCBhbHNvIHRha2UgaHVnZSBlZmZvcnQgdG8gY29taW5lIHRoZXNl IHdvcmsgdG9nZXRoZXIgdG8gbWFrZSBpdCBkb2VzIHdvcmsgZm9yIGh1Z2UgdXNlY2FzZXMuDQoN ClRoZW4gd2UgYmVnYW4gdG8gYXBwbHkgZm9yIGNoYXJ0ZXIgb2YgdGhlIHByb2plY3QsIE5BSSwg ZnJvbSB0aGUgT3BlbiBTb3VyY2UgQ29udHJvbGxlciBwcm9qZWN0LCBPTk9TKE9wZW4gTmV0d29y ayBPcGVyYXRpbmcgU3lzdGVtKS4gV2UgaG9wZSBpdCBjYW4NCg0KYmUgYSBwbGF0Zm9ybSB0byBj b21iaW5lIHRoZSBjb250cmlidXRpb24gZnJvbSBkaWZmZXJlbnQgcGFydGllcyBvZiBpbmR1c3Ry eSBhbmQgYWNhZGVtaWEgaW5jbHVkaW5nIG9wZXJhdG9ycywgaW50ZXJuZXQgY29tcGFuaWVzLCB1 bml2ZXJzaXRpZXMsIHJlc2VhcmNoDQoNCm9yZ2FuaXphdGlvbnMgYW5kICBpbmRpdmlkdWFsIGNv bnRyaWJ1dG9ycyAocGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd2lraS5vbm9zcHJvamVjdC5vcmcv ZGlzcGxheS9PTk9TL05ldHdvcmsrQXJ0aWZpY2lhbCtJbnRlbGxpZ2VuY2UpLg0KDQoNCg0KQXQg dGhlIHNhbWUgdGltZSB3ZSBzZXQgdXAgYSBtYXRyaXggY29tbXVuaXRpZXMgY2FsbGVkIGFzIFNE Ti9ORlYgTWFuaXRvKE1hc3RlcikgSG9yZGVzIHNob3duIGluIHRoZSBwYWdlIDExIG9mIHRoZSBz bGlkZSwgZ2FtZXNsaWRlcy05Ny1zZG5yZy0zNC1hbi0NCg0KYXJjaGl0ZWN0dXJlLW9mLW5ldHdv cmstYXJ0aWZpY2lhbC1pbnRlbGxpZ2VuY2VuYWktMDAgdGhyb3VnaCBXZUNoYXQgKHRoZSBtb3N0 IGZhbW91cyBDaGluZXNlIEluc3RhbnQgTWVzc2FnZSBUb29sIGxpa2UgV2hhdHNBcHAgdGhhdCBy dW5zIG9uIHRoZSBTbWFydA0KDQpQaG9uZXMgYW5kIFBDcykuIE5vdyB0aGVyZSBhcmUgb25lIENo aW5lc2UgV2VjaGF0IEdyb3VwIGNhbGxlZCBhcyAiU0ROL05GVry8yvWyv8LkIiB3aXRoIDEyMDAr IG1lbWJlcnMgYW5kIHRoZXJlIGFyZSBvbmUgRW5nbGlzaCBHcm91cCBjYWxsZWQgYXMNCg0KIlNE Ti9ORlYgTWFuaXRvIEhvcmRlcyIgd2l0aCA0NTArIG1lbWJlcnMuIFRoZSBjb21tdW5pdHkgbWVt YmVycyBhcmUgZnJvbSBhbGwga2luZHMgb2YgYWNhZGVtaWMgYW5kIGluZHVzdHJpYWwgb3JnYW5p emF0aW9ucywgYW5kIGluZGl2aWR1YWwNCg0KY29udHJpYnV0b3JzIHdoaWNoIGNhbiBiZSBvZiBn cmVhdCBvZiBoZWxwIHRvIHRoZSBTRE4vTkZWIHdvcmssIGluY2x1ZGluZyBOQUkgd29yay4gTW9y ZW92ZXIgdGhlIGhvcmRlcyB3ZW50IG9uIHRvIGJlIGRpdmlkZWQgaW50byBzdWItaG9yZGVzIHRv IGRpc2N1c3MNCg0KdGhlIGlzc3VlcyBvZiB0aGUgc3BlY2lmaWMgYXJlYXMgb2YgU0ROL05GVi4g VGhvdWdoIHRoZXJlIGFyZSBodWdlIHdvcmsgaGFzIGJlZW4gZG9uZSBpbiB0aGUgcGFzdCA4IHll YXJzIHNpbmNlIHRoZSBjb25jZXB0IG9mIE9wZW5GbG93IGFuZCBTRE4gd2FzDQoNCnByb3Bvc2Vk IGluIDIwMDgsIHRoaW5raW5nIGFib3V0IHRoZSBncmVhdCBvYmplY3RpdmUgb2YgTmV0d29yayBB cnRpZmljaWFsIEludGVsbGlnZW5jZSAoTWFrZSB0aGUgbmV0d29yayBjb250cm9sbGVyIGFzIHRo ZSB0cnVlIE5ldHdvcmsgQnJhaW4pIHRvIGxpYmVyYXRlIHRoZQ0KDQpuZXR3b3JrIGN1c3RvbWVy cyBhbmQgbmV0d29yayBhZG1pbmlzdHJhdG9ycyAgZnJvbSB0aGUgaGFyZCwgdGltZS1jb25zdW1p bmcsIGVycm9yLXByb25lIHdvcmsgb2YgbmV0d29yayBzZXJ2aWNlIHByb3Zpc2lvbiwgbmV0d29y ayBBZG1pbmlzdHJhdGlvbiBhbmQNCg0KTWFpbnRlbmFuY2UgYW5kIG1ha2UgbmV0d29yayBzZXJ2 aWNlcyBmbG91cmlzaGluZywgaW4gbXkgb3duIG9waW5pb24gd2UgYXJlIHN0aWxsIGluIHRoZSBl YXJseSBwaGFzZSBvZiBTRE4gb3IgTmV0d29yayBDZW50cmFsIENvbnRyb2wsIGFuZCB3ZSBtYXli ZSBoYXZlDQoNCnRvIHRha2UgYSB2ZXJ5IHZlcnkgbG9uZyBwcm9jZXNzIHRvIGFjaGlldmUgdGhl IHBlcmZlY3QgbGV2ZWwgb2YgTkFJLiBXZSBuZWVkIHlvdSBhbGwncyBoZWxwIGFuZCBjb250cmli dXRpb24gLiBBbmQgSSB0cnVseSBnb3Qgd2FybSByZXNwb25zZSBhbmQgbWFueSBjb25zdHJ1Y3Rp dmUNCg0Kc3VnZ2VzdGlvbnMgYWZ0ZXIgbXkgcHJlc2VudGF0aW9uIG9mIHRoZSBOQUkgd29yayBp biB0aGUgU0ROUkcgYW5kIFJUR1dHIHNlc3Npb24gbWVldGluZ3MuIEkgd291bGQgbGlrZSB0byBz aW5jZXJlbHkgd2VsY29tZSB5b3UsIHdobyBoYXZlIGludGVyZXN0IGluDQoNClNETi9ORlYgYW5k IGxpa2UgdG8gdGFrZSB0aGUgY2hhbGxlbmdlcyBvZiBOQUksIGpvaW4gb3VyIGNvbW11bml0eSAi U0ROL05GViBNYW5pdG8gSG9yZGVzIiB0byBjb25uZWN0IHRocm91Z2ggdGhlIE1hdHJpeCB0byBo ZWxwIGVhY2ggb3RoZXIgKGluc3RhbGwNCg0KV2VDaGF0IEFwcCBvbiB5b3VyIHNtYXJ0IHBob25l cywgZmluZCB1cyB0aHJvdWdoIHRoZSBXZUNoYXQgSUQ6IDEzNjUxMDE3NzQ1IGFuZCB3ZSB3aWxs IGludml0ZSB5b3Ugam9pbiB0aGUgYXBwcm9wcmlhdGUgY29tbXVuaXRpZXMgc2hvd24gaW4gdGhl IHBhZ2UNCg0KMTEgb2YgdGhlIHNsaWRlLCBnYW1lc2xpZGVzLTk3LXNkbnJnLTM0LWFuLWFyY2hp dGVjdHVyZS1vZi1uZXR3b3JrLWFydGlmaWNpYWwtaW50ZWxsaWdlbmNlbmFpLTAwKSBhbmQgdGhl IE9wZW4gU291cmNlIFByb2plY3QsIE5BSSwgaW4gT05PUy4NCg0KDQoNCkxldCB1cyBtYWtlIGl0 IGhhcHBlbiENCg0KDQoNClRoYW5rcywNClpoZW5iaW4oUm9iaW4pDQo= --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D8DE9A34ANKGEML515MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi SDNRGers/RTGWGers/OPSAWGers,

 

For RTGWG since I stayed up the whole night for some reason, sorry for t= hat I could not review the presentation slide of draft, draft-li-rtgwg-netw= ork-ai-arch, 

carefully and correct the possible errors before I did the presentation = in the RTGWG session meeting. Now I have modified the slide and the chair&n= bsp;already helped

update the slide in the IETF page (Thank you Jeff).

 

I hope you who have interest in the work can get the slide of the S= DNRG session meeting since I presented the draft in both SDNRG and RTGWG se= ssion

meetings in IETF97.

-- gameslides-97-sdnrg-34-an-architecture-of-network-artificial-intellig= encenai-00

 

For Network Artificial Intelligent, we have finished some prototype's im= plementation shown in the page 8 of the slide, gameslides-97-sdnrg-34-an-

architecture-of-network-artificial-intelligencenai-00. We implemented th= e ELK-based Log Search Engine and one typical usecase of detecting abnormal= log

based on the Open Source Big Data, Database, Machine Learning and Distri= buted Communication, etc., technologies.

 

Through the prototype work, we believe the idea of Network Artificial In= telligence dose work and we are aware that the success of NAI need huge tra= ditional/

advanced knowledge/technologies/basic science and it will also take= huge effort to comine these work together to make it does work for huge us= ecases.

Then we began to apply for charter of the project, NAI, from the Open So= urce Controller project, ONOS(Open Network Operating System). We hope it ca= n

be a platform to combine the contribution from different parties of indu= stry and academia including operators, internet companies, universities, re= search

organizations and  individual contributors (please refer to https://wiki.onosproject.org/display/ONOS/Network+Artificial+Intell= igence).

 

At the same time we set up a matrix communities called as SDN/NFV Manito= (Master) Hordes shown in the page 11 of the slide, gameslides-97-sdnrg-34-a= n-

architecture-of-network-artificial-intelligencenai-00 through WeChat (th= e most famous Chinese Instant Message Tool like WhatsApp that runs on the S= mart

Phones and PCs). Now there are one Chinese Wechat Group called as "= SDN/NFV=BC=BC=CA=F5=B2=BF=C2=E4" with 1200+ members and there are = one English Group called as

"SDN/NFV Manito Hordes" with 450+ members. The community m= embers are from all kinds of academic and industrial organizations, and ind= ividual

contributors which can be of great of help to the SDN/NFV work, inc= luding NAI work. Moreover the hordes went on to be divided into s= ub-hordes to discuss

the issues of the specific areas of SDN/NFV. Though there are huge work = has been done in the past 8 years since the concept of OpenFlow and SDN&nbs= p;was

proposed in 2008, thinking about the great objective of Network Artifici= al Intelligence (Make the network controller as the true Network Brain) to = liberate the

network customers and network administrators  from the hard, time-c= onsuming, error-prone work of network service provision, network Administra= tion and

Maintenance and make network services flourishing, in my own opinion we = are still in the early phase of SDN or Network Central Control, and we mayb= e have

to take a very very long process to achieve the perfect level of NAI. We= need you all's help and contribution . And I truly got warm response and m= any constructive

suggestions after my presentation of the NAI work in the SDNRG and RTGWG= session meetings. I would like to sincerely welcome you, who have interest= in

SDN/NFV and like to take the challenges of NAI, join our community = "SDN/NFV Manito Hordes" to connect through the Matrix to help eac= h other (install

WeChat App on your smart phones, find us through the WeChat ID: 136= 51017745 and we will invite you join the appropriate communities shown in t= he page

11 of the slide, gameslides-97-sdnrg-34-an-architecture-of-network-artif= icial-intelligencenai-00) and the Open Source Project, NAI, in ONOS. 

 

Let us make it happen!

 

Thanks,
Zhenbin(Robin)

--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D8DE9A34ANKGEML515MBXchi_-- From nobody Wed Nov 23 15:24:26 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1E412945C; Wed, 23 Nov 2016 15:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digriz.org.uk 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 eiOXLnqQFMee; Wed, 23 Nov 2016 15:24:20 -0800 (PST) Received: from marmot.wormnet.eu (marmot.wormnet.eu [IPv6:2a03:9800:10:2d:3203:b3a5:8bdc:5b68]) (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 095FF1294A5; Wed, 23 Nov 2016 15:24:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=digriz.org.uk; s=wopr; h=In-Reply-To:Content-Type:MIME-Version:References: Message-ID:Subject:To:From:Date; bh=pPIeriKl+dCl4bBpJtNYLq665xN0c5GR3y+BdpbGH6w=; b=O3gey2NY6ebXqrV36MIV9Ff//p /OPosQFVTfRhiupnj2OeZ43XT222LZUp2f0Nllr77cSMYKxulaBynBSVDqLW3CJ4UDjlsWS5jAoZ4 PSIrKL5dDbbQagth32s7qcMhdlVVrZle6RjP1K9k9e6OVvl7yGAgbQ0YVpGWkJ4goO7E=; Received: from [2a01:348:45:10:343b:fb21:620a:dfd4] (helo=quatermain.digriz.wormnet.eu) by marmot.wormnet.eu with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86) (envelope-from ) id 1c9gtf-00019E-9x; Wed, 23 Nov 2016 23:24:11 +0000 Date: Wed, 23 Nov 2016 23:24:08 +0000 From: Alexander Clouter To: draft-ietf-opsawg-tacacs@ietf.org, opsawg@ietf.org Message-ID: <20161123232408.GC30063@quatermain.digriz.org.uk> References: <20161102231446.GA3842@quatermain.digriz.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20161102231446.GA3842@quatermain.digriz.org.uk> X-Auto-Response-Suppress: OOF Organization: WormNET Jabber-ID: alex@digriz.org.uk User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [OPSAWG] implementing from reading draft-ietf-opsawg-tacacs-05 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 23:24:25 -0000 Hi, On Wed, Nov 02, 2016 at 11:14:46PM +0000, Alexander Clouter wrote: > >Below are my thoughts on various sections, though no doubt might follow up >later as my work progresses and other questions arise. > > [snipped] > >>5. Authorization >> >>6. Accounting > >I have not gotten this far in my development work so I'll get back to you. In the Accounting REQUEST packet, the status field is 8 bits, and the table only describes considering the first 3 bits. It is clear what to do about the INVALID sections, but nothing seems to be mentions about what to do if any of the other 5 bits are set. Should I treat these bits also as INVALID and send the client a status error message, or are they reserved and should be just ignored? Thanks From nobody Wed Nov 30 05:00:04 2016 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E74D012971B; Wed, 30 Nov 2016 04:59:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.38.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148051079994.6815.17061866243809468798.idtracker@ietfa.amsl.com> Date: Wed, 30 Nov 2016 04:59:59 -0800 Archived-At: Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-02.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 13:00:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group of the IETF. Title : Manufacturer Usage Description Specification Authors : Eliot Lear Ralph Droms Dan Romascanu Filename : draft-ietf-opsawg-mud-02.txt Pages : 37 Date : 2016-11-30 Abstract: This memo specifies the necessary components to implement manufacturer usage descriptions (MUD). This includes two YANG modules, IPv4 and IPv6 DHCP options, an LLDP TLV, a URL suffix specification, an X.509 certificate extension and a means to sign and verify the descriptions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-opsawg-mud-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-mud-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 30 05:07:02 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D34112941D; Wed, 30 Nov 2016 05:06:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlX_ud1mf6B0; Wed, 30 Nov 2016 05:06:55 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D7AE129781; Wed, 30 Nov 2016 05:06:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8181; q=dns/txt; s=iport; t=1480511200; x=1481720800; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=pQQJ5vB2xi3vAV8zCEL+J2+m76ezp6QRFOtA+CB5oYk=; b=jkQSI9p2sN4T8aS7tQ0PumVbI8WkggxLobvwFTHYYymDPS0i7Y5be1CL MrpwXdFEb9TS04wfn49LCGpmNidtENA3p6lfVHuq84JE1MCZlKYxT5YV9 uAii/XkcTfbLII/CX2KyOk4oQW6zmBlRLMRqRLJvb4cp1PnBieleb/5S+ 0=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAQBczj5Y/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzgBAQEBAXeBA41FlwmPV4UfggceAQqFL0oCgj8UAQIBAQEBAQE?= =?us-ascii?q?BYiiEaQEBBAEBASBLCxALGCoCAicwBwwGAgEBiGkOrD2CKS+LIgEBAQEBAQEBA?= =?us-ascii?q?gEBAQEBAQEBAQEBDg6IOwiCVoMLhEKCXQWIYpFzg16BenKKRIFyT4Qogx6GK41?= =?us-ascii?q?yhAweNzBIEwwUDoUxPTSITwEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,574,1473120000"; d="asc'?scan'208,217";a="647490166" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Nov 2016 13:06:33 +0000 Received: from [10.61.229.88] ([10.61.229.88]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id uAUD6WOG007525; Wed, 30 Nov 2016 13:06:32 GMT To: internet-drafts@ietf.org, i-d-announce@ietf.org References: <148051079994.6815.17061866243809468798.idtracker@ietfa.amsl.com> From: Eliot Lear Message-ID: <0478aac5-f059-9726-5b03-8a670e840b14@cisco.com> Date: Wed, 30 Nov 2016 14:06:32 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <148051079994.6815.17061866243809468798.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WL8OTcm6uibQP3rt8TusE3QgQLXdvA1Po" Archived-At: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-02.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 13:06:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WL8OTcm6uibQP3rt8TusE3QgQLXdvA1Po Content-Type: multipart/mixed; boundary="d6hNI1G9EtCUNI8TrRxnr0anO1I20mojS"; protected-headers="v1" From: Eliot Lear To: internet-drafts@ietf.org, i-d-announce@ietf.org Cc: opsawg@ietf.org Message-ID: <0478aac5-f059-9726-5b03-8a670e840b14@cisco.com> Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-02.txt References: <148051079994.6815.17061866243809468798.idtracker@ietfa.amsl.com> In-Reply-To: <148051079994.6815.17061866243809468798.idtracker@ietfa.amsl.com> --d6hNI1G9EtCUNI8TrRxnr0anO1I20mojS Content-Type: multipart/alternative; boundary="------------D45C65D3EE712F03B0E9E12A" This is a multi-part message in MIME format. --------------D45C65D3EE712F03B0E9E12A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, As the draft mentions, there are a number of changes. Here are a few of the highlights: * The IANA section has been updated with what assignments have been made. More to come. * Russ Housley completely rewrote the X.509 extension section.=20 Thanks, Russ. * Adrian Farrel provided the basis for the privacy considerations secti= on. To be done: * We are pondering a number of extensions. One possibility would be to indicate the manner in which the MUD file is intended to be transported. In this way, if one device claims to be another device that only makes use of X.509, the controller can spot a problem. I think this may be a corner case, but it is also pretty cheap to implement. * More security considerations. * Perhaps a slight refresh on the introduction, given all of the hoo haa around Mirai. Eliot On 11/30/16 1:59 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the Operations and Management Area Working= Group of the IETF. > > Title : Manufacturer Usage Description Specification > Authors : Eliot Lear > Ralph Droms > Dan Romascanu > Filename : draft-ietf-opsawg-mud-02.txt > Pages : 37 > Date : 2016-11-30 > > Abstract: > This memo specifies the necessary components to implement > manufacturer usage descriptions (MUD). This includes two YANG > modules, IPv4 and IPv6 DHCP options, an LLDP TLV, a URL suffix > specification, an X.509 certificate extension and a means to sign an= d > verify the descriptions. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-opsawg-mud-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-mud-02 > > > Please note that it may take a couple of minutes from the time of submi= ssion > 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/ > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --------------D45C65D3EE712F03B0E9E12A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi,

As the draft mentions, there are a number of changes.=C2=A0 Here a= re a few of the highlights:

  • The IANA section has been updated with what assignments have been made.=C2=A0 More to come.
  • Russ Housley completely rewrote the X.509 extension section.=C2= =A0 Thanks, Russ.
  • Adrian Farrel provided the basis for the privacy considerations section.

To be done:

  • We are pondering a number of extensions.=C2=A0 One possibility would be to indicate the manner in which the MUD file is intended to be transported.=C2=A0 In this way, if one device clai= ms to be another device that only makes use of X.509, the controller can spot a problem.=C2=A0 I think this may be a corner= case, but it is also pretty cheap to implement.
  • More security considerations.
  • Perhaps a slight refresh on the introduction, given all of the hoo haa around Mirai.

Eliot


On 11/30/16 1:59 PM, internet-drafts@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
This draft is a work item of the Operations and Management Area Working G=
roup of the IETF.

        Title           : Manufacturer Usage Description Specification
        Authors         : Eliot Lear
                          Ralph Droms
                          Dan Romascanu
	Filename        : draft-ietf-opsawg-mud-02.txt
	Pages           : 37
	Date            : 2016-11-30

Abstract:
   This memo specifies the necessary components to implement
   manufacturer usage descriptions (MUD).  This includes two YANG
   modules, IPv4 and IPv6 DHCP options, an LLDP TLV, a URL suffix
   specification, an X.509 certificate extension and a means to sign and
   verify the descriptions.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-op=
sawg-mud/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-opsawg-mud=
-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft=
-ietf-opsawg-mud-02


Please note that it may take a couple of minutes from the time of submiss=
ion
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/

_______________________________________________
OPSAWG mailing list
OPS=
AWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

--------------D45C65D3EE712F03B0E9E12A-- --d6hNI1G9EtCUNI8TrRxnr0anO1I20mojS-- --WL8OTcm6uibQP3rt8TusE3QgQLXdvA1Po Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJYPs7YAAoJEIe2a0bZ0nozzGgIAIDC3EDC9mz1opM3UW2cGn2X OZIi4j03kNY5vhRfB5mQ0a7MwAop0M6ia9lOslGYpuxD+SLU2y//NOgyqGRd6uhE HQwHor1dHSSucazDIYZjMtomvi2qQMj+V89vK3ooM28m+rX93kyKjemRHosELfqo 7NZQfvvD0plwwF9QpOTg6v8JZA//PZ3OYqaR/a28dpxZFDjLdgN+h/mnx0rGjxPF WLvLO6upKRHbJO4At8LPhXpYH4wE+8RZ8KJpbvFNLxaTYY/nlEi/P3T6wIjdus44 9YrS9i/5Ir7vSi3SeLhfyVTzIWaKrUDH8uWcHSjfc6i1rVz0/LcJbbibFOOhGWU= =r2uR -----END PGP SIGNATURE----- --WL8OTcm6uibQP3rt8TusE3QgQLXdvA1Po-- From nobody Wed Nov 30 08:49:09 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 125A7129888; Wed, 30 Nov 2016 08:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digriz.org.uk 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 pG-Zrn1a1muy; Wed, 30 Nov 2016 08:49:04 -0800 (PST) Received: from marmot.wormnet.eu (marmot.wormnet.eu [IPv6:2a03:9800:10:2d:3203:b3a5:8bdc:5b68]) (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 849941299BF; Wed, 30 Nov 2016 08:44:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=digriz.org.uk; s=wopr; h=In-Reply-To:Content-Type:MIME-Version:References: Message-ID:Subject:To:From:Date; bh=B8F/H86BkZxzhezDjbEfWIeauoojMedh7UAKW+ldrc4=; b=OBXmTfAzXPChxhwq0yRyo+E5Aj 4vYR19GUjEH+qFwLp2Xp9xN0HCso/jxXACOICOpWJ50Vxt0pIBKLZr7aNVJwCKedYY6jiifksDmUt 1JY+aFEXyGq5tyx9jqv8+eiv9MC9jShwdlKRf9/Hjf1HUDFTEKhsDXpZ5O1mNkAWMUdU=; Received: from [2a01:348:45:10:b19d:a92a:9c6e:76ca] (helo=quatermain.digriz.wormnet.eu) by marmot.wormnet.eu with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86) (envelope-from ) id 1cC7zE-0003k9-NQ; Wed, 30 Nov 2016 16:44:00 +0000 Date: Wed, 30 Nov 2016 16:43:59 +0000 From: Alexander Clouter To: draft-ietf-opsawg-tacacs@ietf.org, opsawg@ietf.org Message-ID: <20161130164359.GD5808@quatermain.digriz.org.uk> References: <20161102231446.GA3842@quatermain.digriz.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20161102231446.GA3842@quatermain.digriz.org.uk> X-Auto-Response-Suppress: OOF User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [OPSAWG] implementing from reading draft-ietf-opsawg-tacacs-05 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 16:49:07 -0000 Hello, I cannot find the guidance in the draft, but I am looking on how to handle authentication session state. Of course the session_id is part of it but the question is should the source IP and maybe also the TCP port make up that tuple? Nothing about the definition of the sequence_id hints at if different TCP connections from the same client could carry *different* authentications with the *same* session_id. For example, is it valid to have in a SINGLE CONNECT situation multiple TCP connections from the same client to the server? Should I consider it expected behaviour that the following CONTINUE packets can vary over which TCP connection they traverse over (ie. should the port be part of the tuple)? If TCP port to be part of the tuple, what happens if the TCP connection is killed (network reasons rather that protocol)? Should any state associated with it also be destroyed or is the following sequence of events on the same session_id valid: TCP connection 1 opened seq 1 -> start seq 2 -> reply TCP connection 1 RST TCP connection 2 opened seq 3 -> cont Should an authentication with multiple continuation packets be forcible made to do this operation over the same TCP connection or have to restart afresh if there is an interruption? Thanks On Wed, Nov 02, 2016 at 11:14:46PM +0000, Alexander Clouter wrote: > >I am working on implementing the TACACS+ protocol. I do of course >have a reference (pam_tacplus) to crib from and a pile of lab >equipment, but thought as the draft your have authored seem aims to be >a living standard you might be interested in hearing some feedback >from the trenches of someone right now trying to implement from it. > >Below are my thoughts on various sections, though no doubt might >follow up later as my work progresses and other questions arise. > >> [snipped] From nobody Wed Nov 30 09:32:24 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAE8F1295EF; Wed, 30 Nov 2016 09:32:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.518 X-Spam-Level: X-Spam-Status: No, score=-15.518 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8iAO_zmJUfI; Wed, 30 Nov 2016 09:32:22 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3568129561; Wed, 30 Nov 2016 09:32:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3032; q=dns/txt; s=iport; t=1480527142; x=1481736742; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=9ZwJ37bpjFbQW8X53orkVh7u7JI3tg2SVPbBTW/+/ZY=; b=IjL6bipQIyU+WDkcTFthGL+Q6vJEKLAazTAntyBsfzPD/7TqRkQ7SXaU dZNmOc7zfpL396ofXuALMQaD42aPyEZiIDpUBoq43U4xIjZv1mT3PkhZw Pv4WUwm+xgsrzN6H50A529iIHX61u3Qs7ggJQp5aLoiuoLGsAsLdvD3rC Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQDHDD9Y/4cNJK1UCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM4AQEBAQEfgVsHjT6XCJJogg6CCIYiAoF8PxQBAgEBAQEBAQF?= =?us-ascii?q?iKIRoAQEBAwEnVwsCAQgYLjIlAgQBEohlCK8QPYtHAQEBAQEBAQMBAQEBAQEBI?= =?us-ascii?q?IsZhCIRCQ2FYQEEmlcBkQ6BcoR3iUmHWYYahAsBHjcwZ4VScoVvgS6BDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,574,1473120000"; d="scan'208";a="353048776" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Nov 2016 17:32:21 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id uAUHWLwZ000624 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 30 Nov 2016 17:32:21 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 30 Nov 2016 11:32:20 -0600 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Wed, 30 Nov 2016 11:32:20 -0600 From: "Douglas Gash (dcmgash)" To: Alexander Clouter , "draft-ietf-opsawg-tacacs@ietf.org" , "opsawg@ietf.org" Thread-Topic: [OPSAWG] implementing from reading draft-ietf-opsawg-tacacs-05 Thread-Index: AQHSSymtpVU/1ehVZ0iS8vw6BHoEjqDyLaIA Date: Wed, 30 Nov 2016 17:32:20 +0000 Message-ID: References: <20161102231446.GA3842@quatermain.digriz.org.uk> <20161130164359.GD5808@quatermain.digriz.org.uk> In-Reply-To: <20161130164359.GD5808@quatermain.digriz.org.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.8.160830 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.1.3] Content-Type: text/plain; charset="Windows-1252" Content-ID: <89C9AE9487987B4DA72570E2BEF980B4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [OPSAWG] implementing from reading draft-ietf-opsawg-tacacs-05 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 17:32:24 -0000 Hi, Please see inline, this is my interpretation, would welcome other points of view. I think this is all determinable from the doc but will check/update if it is a little hidden. On 30/11/2016 16:43, "Alexander Clouter" wrote: >Hello, > >I cannot find the guidance in the draft, but I am looking on how to >handle=20 >authentication session state. > >Of course the session_id is part of it but the question is should the >source IP=20 >and maybe also the TCP port make up that tuple? Nothing about the >definition=20 >of the sequence_id hints at if different TCP connections from the same >client=20 >could carry *different* authentications with the *same* session_id. The session_id and TCP connection must be sufficient to uniquely identity every session. > >For example, is it valid to have in a SINGLE CONNECT situation multiple >TCP=20 >connections from the same client to the server? A SINGLE CONNECT does not link multiple TCP sessions, it is a facet of a single TCP connection (I.e. A TCP connection can be upgraded to SINGLE CONNECT). A client can have multiple connections to a server, and those connections may be SIGNLE CONNECT or NOT. The session_id only identifies a session within a connection. > Should I consider it expected >behaviour that the following CONTINUE packets can vary over which TCP >connection they traverse over (ie. should the port be part of the tuple)? > >If TCP port to be part of the tuple, what happens if the TCP connection >is=20 >killed (network reasons rather that protocol)? Should any state >associated=20 >with it also be destroyed or is the following sequence of events on the >same=20 >session_id valid: Sessions are =B3inside=B2 connections=8A they cannot span multiple TCP connections. > >TCP connection 1 opened >seq 1 -> start >seq 2 -> reply >TCP connection 1 RST >TCP connection 2 opened >seq 3 -> cont > >Should an authentication with multiple continuation packets be forcible >made to=20 >do this operation over the same TCP connection or have to restart afresh >if=20 >there is an interruption? I think that is n AND rather than or ;-) =8Aauthentication with multiple continuation packets MUST be on the same TC= P connection AND client has to restart afresh if there is an interruption=8A so server should clear its sessions to accommodate that. > >Thanks > >On Wed, Nov 02, 2016 at 11:14:46PM +0000, Alexander Clouter wrote: >> >>I am working on implementing the TACACS+ protocol. I do of course >>have a reference (pam_tacplus) to crib from and a pile of lab >>equipment, but thought as the draft your have authored seem aims to be >>a living standard you might be interested in hearing some feedback >>from the trenches of someone right now trying to implement from it. >> >>Below are my thoughts on various sections, though no doubt might >>follow up later as my work progresses and other questions arise. >> >>> [snipped]