From nobody Thu Jul 1 22:08:49 2021 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7073A0657; Thu, 1 Jul 2021 22:08:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.33.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sfc@ietf.org Message-ID: <162520249751.11980.17715821525306358422@ietfa.amsl.com> Date: Thu, 01 Jul 2021 22:08:17 -0700 Archived-At: Subject: [sfc] I-D Action: draft-ietf-sfc-nsh-integrity-06.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2021 05:08:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining WG of the IETF. Title : Integrity Protection for the Network Service Header (NSH) and Encryption of Sensitive Context Headers Authors : Mohamed Boucadair Tirumaleswar Reddy Dan Wing Filename : draft-ietf-sfc-nsh-integrity-06.txt Pages : 28 Date : 2021-07-01 Abstract: This specification adds integrity protection directly to the Network Service Header (NSH) used for Service Function Chaining (SFC). Also, this specification allows to encrypt sensitive metadata that is carried in the NSH. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-sfc-nsh-integrity-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-integrity-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 1 22:10:20 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3893A0766; Thu, 1 Jul 2021 22:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.796 X-Spam-Level: X-Spam-Status: No, score=-2.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSrD_-TV7t9G; Thu, 1 Jul 2021 22:10:13 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (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 72B023A0763; Thu, 1 Jul 2021 22:10:13 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr22.francetelecom.fr (ESMTP service) with ESMTPS id 4GGNSM2S76z115h; Fri, 2 Jul 2021 07:10:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1625202611; bh=sLa4GBoaAuht4brsNJFjyaYf/y0l1forBl77UhUR+z0=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=f9u07kYda310/MyxcO7rz1rotkteC8M8ZmuutVnV+OcKiyXoGRF2YoTN3ukB19pVR bKSRBF+6C9Vp5oSMYrA7ohNhBl/b48VSpp5hqiGRUMjlpB8xD4YvkuUSqY++3GJrdx xvvhUKAz2aNUrDEh97q49URO3ZXE3rJP07IdNQbvOYD2b1oWPvJkCdMUOOd5lrwLtk fweVes33fx2ncVv/cavs/VL0J4+mxA2p9sR25iDv0ZBw/wFLWqlEsfoQvgj5HfxWX5 8GE+OLwyF624oN5wihnkd9orZafMOZXZWFu/3rJcty08CO+h6Du/nqJcF+ZNpRc4pC grm8dsk4QLX/Q== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfednr01.francetelecom.fr (ESMTP service) with ESMTPS id 4GGNSM1GsQzDq80; Fri, 2 Jul 2021 07:10:11 +0200 (CEST) From: To: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= , "ops-dir@ietf.org" CC: "draft-ietf-sfc-nsh-integrity.all@ietf.org" , "sfc@ietf.org" Thread-Topic: Opsdir last call review of draft-ietf-sfc-nsh-integrity-05 Thread-Index: AQHXaZqmmf8m3HMDQ0yGRnjG/jASQaskZ+mwgArFoKA= Date: Fri, 2 Jul 2021 05:10:10 +0000 Message-ID: <24262_1625202611_60DE9FB3_24262_195_1_787AE7BB302AE849A7480A190F8B9330353B4F52@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162460909273.657.16151989326348143956@ietfa.amsl.com> <9774_1624614936_60D5A818_9774_471_2_787AE7BB302AE849A7480A190F8B9330353B0E12@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <9774_1624614936_60D5A818_9774_471_2_787AE7BB302AE849A7480A190F8B9330353B0E12@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Opsdir last call review of draft-ietf-sfc-nsh-integrity-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2021 05:10:19 -0000 SGkgSsO8cmdlbiwgDQoNCkZZSSwgdGhlIGNoYW5nZXMgYXJlIG5vdyBpbXBsZW1lbnRlZCBpbiB0 aGUgcHVibGljIHZlcnNpb246IA0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy YWZ0LWlldGYtc2ZjLW5zaC1pbnRlZ3JpdHktMDYgDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0t TWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tDQo+IFttYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbV0NCj4gRW52b3nDqcKg OiB2ZW5kcmVkaSAyNSBqdWluIDIwMjEgMTE6NTYNCj4gw4DCoDogSsO8cmdlbiBTY2jDtm53w6Rs ZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+OyBvcHMtDQo+IGRpckBp ZXRmLm9yZw0KPiBDY8KgOiBkcmFmdC1pZXRmLXNmYy1uc2gtaW50ZWdyaXR5LmFsbEBpZXRmLm9y ZzsgbGFzdC1jYWxsQGlldGYub3JnOw0KPiBzZmNAaWV0Zi5vcmcNCj4gT2JqZXTCoDogUkU6IE9w c2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtc2ZjLW5zaC1pbnRlZ3JpdHktDQo+ IDA1DQo+IA0KPiBIaSBKw7xyZ2VuLA0KPiANCj4gVGhhbmsgeW91IGZvciB0aGUgcmV2aWV3LiBZ b3UgY2FuIHRyYWNrIHRoZSBjaGFuZ2VzIGF0Og0KPiBodHRwczovL3Rpbnl1cmwuY29tL25zaC1p bnRlZ3JpdHktbGF0ZXN0DQo+IA0KPiBQbGVhc2Ugc2VlIGlubGluZS4NCj4gDQo+IENoZWVycywN Cj4gTWVkDQo+IA0KPiA+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+IERlwqA6IErD vHJnZW4gU2Now7Zud8OkbGRlciB2aWEgRGF0YXRyYWNrZXIgW21haWx0bzpub3JlcGx5QGlldGYu b3JnXQ0KPiA+IEVudm95w6nCoDogdmVuZHJlZGkgMjUganVpbiAyMDIxIDEwOjE4IMOAwqA6IG9w cy1kaXJAaWV0Zi5vcmcgQ2PCoDoNCj4gPiBkcmFmdC1pZXRmLXNmYy1uc2gtaW50ZWdyaXR5LmFs bEBpZXRmLm9yZzsgbGFzdC1jYWxsQGlldGYub3JnOw0KPiA+IHNmY0BpZXRmLm9yZyBPYmpldMKg OiBPcHNkaXIgbGFzdCBjYWxsIHJldmlldyBvZg0KPiA+IGRyYWZ0LWlldGYtc2ZjLW5zaC1pbnRl Z3JpdHktMDUNCj4gPg0KPiA+IFJldmlld2VyOiBKw7xyZ2VuIFNjaMO2bnfDpGxkZXINCj4gPiBS ZXZpZXcgcmVzdWx0OiBIYXMgSXNzdWVzDQo+ID4NCj4gPiBUaGUgZG9jdW1lbnQgaXMgdmVyeSB3 ZWxsIHdyaXR0ZW4gYW5kIG9yZ2FuaXplZCwgdGhhbmtzIGZvciB0aGF0Lg0KPiBJDQo+ID4gaGF2 ZSBzb21lIGNvbW1lbnRzIGFuZCBhIGZldyBuaXRzLiBUaGUgaXNzdWVzIEkgaGF2ZSBhIG1pbm9y LCBJDQo+IHRoaW5rDQo+ID4gdGhlIGRvY3VtZW50IG92ZXJhbGwgaXMgaW4gYSBnb29kIHNoYXBl Lg0KPiA+DQo+ID4gLSBGcm9tIGFuIG9wZXJhdGlvbmFsIHBlcnNwZWN0aXZlLCBJIHZlcnkgbXVj aCBhcHByZWNpYXRlIHRoYXQNCj4gdGhlcmUNCj4gPiAgIGlzIHNvbWUgdGV4dCBkaXNjdXNzaW5n IGVycm9yIGFuZCBmYWlsdXJlIHJlcG9ydGluZyBhbmQgdGhhdA0KPiB0aGVyZQ0KPiA+ICAgYXJl IHNvbWUgTVRVIGNvbmZpZ3VyYXRpb24gZ3VpZGVsaW5lcy4NCj4gPg0KPiA+IC0gVGhlIGRvY3Vt ZW50IGNsYWltczoNCj4gPg0KPiA+ICAgICBBcyBkZXBpY3RlZCBpbiBUYWJsZSAxLCBTRkZzIGFy ZSBub3QgaW52b2x2ZWQgaW4gZGF0YQ0KPiBlbmNyeXB0aW9uLg0KPiA+ICAgICBUaGlzIGRvY3Vt ZW50IGVuZm9yY2VzIHRoaXMgZGVzaWduIGFwcHJvYWNoIGJ5IGVuY3J5cHRpbmcNCj4gQ29udGV4 dA0KPiA+ICAgICBIZWFkZXJzIHdpdGgga2V5cyB0aGF0IGFyZSBub3Qgc3VwcGxpZWQgdG8gU0ZG cywgdGh1cw0KPiBlbmZvcmNpbmcNCj4gPiB0aGlzDQo+ID4gICAgIGxpbWl0YXRpb24gYnkgcHJv dG9jb2wgKHJhdGhlciB0aGFuIHJlcXVpcmVtZW50cyBsYW5ndWFnZSkuDQo+ID4NCj4gPiAgIEkg YW0gYSBiaXQgcHV6emxlZCBhYm91dCB0aGlzIHN0YXRlbWVudCBzaW5jZSBhIHByb3RvY29sDQo+ IGRlZmluaXRpb24NCj4gPiAgIGF0IHRoZSBlbmQgaXMganVzdCBzb21lIGZvcm0gb2YgcmVxdWly ZW1lbnRzIGxhbmd1YWdlLg0KPiANCj4gW01lZF0gRldJVywgdGhhdCBzZW50ZW5jZSB3YXMgZHJh d24gY29tcGFyZWQgdG8gYW4gYWx0ZXJuYXRpdmUNCj4gZGVzaWduIHdlIGNvbnNpZGVyZWQgaW4g dGhlIHBhc3QgKHVzZSBvZiBBRUFEIHdoaWNoIHJlbGllcyB1cG9uIGENCj4gc2luZ2xlIGtleSBm b3IgYm90aCBlbmNyeXB0aW9uIGFuZCBpbnRlZ3JpdHkpIGFuZCBmb3Igd2hpY2ggd2UNCj4gaW5k aWNhdGVkIHRoZSBmb2xsb3dpbmcgYXQgdGhhdCB0aW1lOg0KPiANCj4gICAgICAgSW4gb3JkZXIg dG8gYXZvaWQgdGhlIG92ZXJoZWFkIG9mIG11bHRpcGxlIGF1dGhlbnRpY2F0aW9uIHRhZ3MNCj4g YW5kDQo+ICAgICAgIG11bHRpcGxlIGtleXMsIGFuZCB0byBwcmV2ZW50IFNGRnMgZnJvbSBhY3F1 aXJpbmcgdGhlIHNlY3JldA0KPiBrZXkNCj4gICAgICAgdG8gZGVjcnlwdCB0aGUgbWV0YWRhdGEs IHRoZSByZWNvbW1lbmRhdGlvbiBpcyBub3QgdG8NCj4gaW50ZWdyaXR5DQo+ICAgICAgIHByb3Rl Y3QgdGhlIGJhc2UgaGVhZGVyLiAgU3VjaCBhcHByb2FjaCBkb2VzIG5vdCByZXF1aXJlIHRvDQo+ ICAgICAgIHJlY29tcHV0ZSB0aGUgTUFDIGVhY2ggdGltZSBUVEwgaXMgZGVjcmVtZW50ZWQgYnkg YW4gU0ZGLiAgQXMNCj4gYQ0KPiAgICAgICByZW1pbmRlciwgYW4gU0ZGIGlzIG5vdCBzdXBwb3Nl ZCB0byBhY3Qgb24gdGhlIG1ldGFkYXRhIG9yDQo+IGxvb2sNCj4gICAgICAgaW50byB0aGUgY29u dGVudCBvZiB0aGUgbWV0YWRhdGEuDQo+IA0KPiBXZSB3ZXJlIGNvbmNlcm5lZCB3aXRoIHJlbHlp bmcgb24gdGhlIHJlcXVpcmVtZW50IGxhbmd1YWdlIChtYWlubHkNCj4gdGhlIGxhc3Qgc2VudGVu Y2UpIGZvciB0aGUgY29ycmVjdCBwcm90b2NvbCBiZWhhdmlvci4gV2UgY2hhbmdlZCB0aGUNCj4g ZGVzaWduIHNvIHRoYXQgdGhlIGxpbWl0YXRpb24gaXMgaW1wb3NlZCBieSB0aGUgcHJvdG9jb2w6 IHVzZQ0KPiBkaXN0aW5jdCBrZXlzIGZvciBlbmNyeXB0aW9uIChFTkNfS0VZKSBhbmQgaW50ZWdy aXR5IChNQUNfS0VZKS4NCj4gDQo+IFdlIGRvIGhhdmUgdGhlIGZvbGxvd2luZzoNCj4gDQo+ICAg IFRoZSBvdGhlciBhZHZhbnRhZ2UgaXMNCj4gICAgdGhhdCBTRkZzIGRvIG5vdCBoYXZlIGFjY2Vz cyB0byB0aGUgRU5DX0tFWSBhbmQgY2Fubm90IGFjdCBvbiB0aGUNCj4gICAgZW5jcnlwdGVkIENv bnRleHQgSGVhZGVycyBhbmQsIG9ubHkgaW4gY2FzZSBvZiB0aGUgc2Vjb25kIGxldmVsDQo+IG9m DQo+ICAgIGFzc3VyYW5jZSwgU0ZGcyBkbyBoYXZlIGFjY2VzcyB0byB0aGUgTUFDX0tFWS4gIFNp bWlsYXJseSwgYW4NCj4gTlNILQ0KPiAgICBhd2FyZSBTRiBvciBTRkMgUHJveHkgbm90IGFsbG93 ZWQgdG8gZGVjcnlwdCB0aGUgQ29udGV4dCBIZWFkZXJzDQo+IHdpbGwNCj4gICAgbm90IGhhdmUg YWNjZXNzIHRvIHRoZSBFTkNfS0VZLg0KPiANCj4gYnV0IC4uLg0KPiANCj4gIFdlbGwsDQo+ID4g cHV0dGluZw0KPiA+ICAgdGhhdCByZW1hcmsgYXNpZGUsIEkgZG8gbm90IHJlYWxseSBzZWUgYW55 dGhpbmcgaW4gdGhlDQo+IHNwZWNpZmljYXRpb24NCj4gPiAgIHRoYXQgZW5zdXJlcyB0aGF0IFNG RnMgd29uJ3QgZ2V0IHRoZSBrZXlzLiBXZSBhbHNvIHJlYWQ6DQo+ID4NCj4gPiAgICAgWy4uLl0g RW5jcnlwdGlvbiBrZXlpbmcgbWF0ZXJpYWwgaXMgb25seSBwcm92aWRlZCB0bw0KPiA+ICAgICB0 aGVzZSBTRkMgZGF0YSBwbGFuZSBlbGVtZW50cy4NCj4gPg0KPiA+ICAgV2VsbCwgdGhlIHNwZWNp ZmljYXRpb24gaXMgYWN0dWFsbHkgc2lsZW50IGFib3V0IGhvdyBrZXlzIGFyZQ0KPiA+ICAgZGlz dHJpYnV0ZWQuIFNlY3Rpb24gNC40LiBzYXlzOg0KPiA+DQo+ID4gICAgIFRoZSBwcm9jZWR1cmUg Zm9yIHRoZSBhbGxvY2F0aW9uL3Byb3Zpc2lvbmluZyBvZiBzZWNyZXQga2V5cw0KPiAoSykNCj4g PiBhbmQNCj4gPiAgICAgYXV0aGVudGljYXRlZCBlbmNyeXB0aW9uIGFsZ29yaXRobSBvciBNQUNf S0VZIGFuZCBITUFDDQo+IGFsZ29yaXRobQ0KPiA+IGlzDQo+ID4gICAgIG91dHNpZGUgdGhlIHNj b3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4gIEFzIHN1Y2gsIHRoaXMNCj4gPiBzcGVjaWZpY2F0 aW9uDQo+ID4gICAgIGRvZXMgbm90IG1hbmRhdGUgdGhlIHN1cHBvcnQgb2YgYW55IHNwZWNpZmlj IG1lY2hhbmlzbS4NCj4gPg0KPiA+ICAgVG8gbWUsIGl0IHNlZW1zIHRoZSBjbGFpbXMgbWFkZSBp biBzZWN0aW9uIDQuNC4gZG8gbm90IHJlYWxseQ0KPiBob2xkLg0KPiANCj4gW01lZF0gLi4uIEkg YWdyZWUgdGhhdCB3ZSBzdGlsbCBkZXBlbmQgb24gdGhlIHByb3Zpc2lvbmluZy4gUmVtb3ZlZA0K PiB0aGF0IHNlbnRlbmNlLg0KPiANCj4gPg0KPiA+IC0gSW4gc2VjdGlvbiA2LCB5b3UgcGlja2Vk IGFzIHRoZSBlcG9jaCAxOTcwLTAxLTAxVDAwOjAwWiB3aGlsZQ0KPiBOVFANCj4gPiAgIHVzZXMg dGhlIGVwb2NoIDE5MDAtMDEtMDFUMDA6MDBaLiBUaGlzIGxlYWRzIHRvIHJvbGxvdmVycyBpbiB0 aGUNCj4gPiAgIHllYXIgMjEwNiBmb3IgeW91ciB0aW1lc3RhbXBzIHdoaWxlIHRoZSBOVFAgcm9s bG92ZXIgd291bGQgYmUgaW4NCj4gPiAgIDIwMzYuIEdpdmVuIHRoYXQgeW91IHVzZSBhbiBOVFAg Y29tcGF0aWJsZSBmb3JtYXQgYW5kIGENCj4gZGlmZmVyZW50DQo+ID4gICBlcG9jaCwgSSB0aGlu ayB0aGlzIGRlc2VydmVzIHRvIGJlIHNwZWxsZWQgb3V0IGV4cGxpY2l0bHkgc28NCj4gdGhhdA0K PiA+ICAgcGVvcGxlIHVuZGVyc3RhbmQgdGhhdCB0aGV5IGhhdmUgdG8gZG8gY29udmVyc2lvbnMu DQo+ID4NCj4gPiAgIChBbHRlcm5hdGl2ZWx5LCB5b3UgY291bGQgYWRvcHQgdGhlIGVwb2NoIE5U UCBpcyB1c2luZyBhbmQgdGhlDQo+IG5lZWQNCj4gPiAgIGZvciBjb252ZXJzaW9ucyBnb2VzIGF3 YXkgYXQgdGhlIHByaWNlIG9mIGFuIGVhcmxpZXIgcm9sbG92ZXIuKQ0KPiA+DQo+ID4gICBBbnl3 YXksIHdoYXQgSSBhbSBzYXlpbmcgaXMgdGhhdCBpZiB5b3UgcGljayBhIGRpZmZlcmVudCBlcG9j aCwNCj4gSQ0KPiA+ICAgc3VnZ2VzdCB0byBzcGVsbCB0aGlzIG91dCBleHBsaWNpdGx5IGFuZCB0 byBub3QgcmVseSBvbg0KPiA+ICAgaW1wbGVtZW50ZXJzIHRvIGRpc2NvdmVyIHRoaXMuDQo+ID4N Cj4gDQo+IFtNZWRdIEZhaXIgcG9pbnQuIEFkZGVkIGEgbm90ZS4NCj4gDQo+ID4gTWlub3Igbml0 czoNCj4gPg0KPiA+IC0gSW4gc2VjdGlvbiA1LjIsIGl0IHNob3VsZCBzYXk6DQo+ID4NCj4gPiAg IE9MRA0KPiA+DQo+ID4gICBJbiByZWZlcmVuY2UgdG8gRmlndXJlIDUNCj4gPg0KPiA+ICAgTkVX DQo+ID4NCj4gPiAgIEluIHJlZmVyZW5jZSB0byBGaWd1cmUgNw0KPiA+DQo+IA0KPiBbTWVkXSBG b3IgYm90aCA1LjEgYW5kIDUuMiB3ZSBwcm92aWRlIGEgcmVmZXJlbmNlIHRvIHRoZSBmaWd1cmUg d2l0aA0KPiB0aGUgZm9ybWF0IG9mIHRoZSBjb250ZXh0IGhlYWRlciAoaS5lLiwgRmlndXJlIDUp LiBGaWd1cmVzIDYvNyBjb3Zlcg0KPiB0aGUgTlNIIGhlYWRlciBhbmQgc28gb24uDQo+IA0KPiA+ IC0gSW4gc2VjdGlvbiA3LjMsIEkgc3VnZ2VzdCB0aGlzIGNoYW5nZSB0byBtYWtlIGl0IGNsZWFy IGFnYWluIHRvDQo+IHRoZQ0KPiA+ICAgcmVhZGVyIHdoYXQgSyBpczoNCj4gPg0KPiA+ICAgT0xE DQo+ID4NCj4gPiAgIFVzaW5nIEsgYW5kDQo+ID4NCj4gPiAgIE5FVw0KPiA+DQo+ID4gICBVc2lu ZyB0aGUgc2VjcmV0IGtleSBLIGFuZA0KPiANCj4gW01lZF0gRml4ZWQuIFRoYW5rcy4NCj4gDQo+ IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiANCj4gQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMg cGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zDQo+IGNvbmZpZGVudGllbGxlcyBvdSBw cml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlDQo+IGRpZmZ1c2VzLCBleHBs b2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdQ0KPiBj ZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVy IGV0IGxlDQo+IGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNz YWdlcyBlbGVjdHJvbmlxdWVzDQo+IGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sIE9y YW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlDQo+IHNpIGNlIG1lc3NhZ2UgYSBldGUg YWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCj4gDQo+IFRoaXMgbWVzc2FnZSBh bmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvcg0KPiBwcml2aWxl Z2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxk IG5vdA0KPiBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0 aW9uLg0KPiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXINCj4gYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh Y2htZW50cy4NCj4gQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJs ZSBmb3IgbWVzc2FnZXMgdGhhdA0KPiBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFs c2lmaWVkLg0KPiBUaGFuayB5b3UuDQoNCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVj ZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVs bGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMs IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1 IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRl dXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3Nh Z2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3Jhbmdl IGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUs IGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo bWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24g dGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1 dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQg ZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJl IGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVl biBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From nobody Thu Jul 1 23:49:58 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B927C3A1079; Thu, 1 Jul 2021 23:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=jacobsuniversity.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1SN2q0GxYqA; Thu, 1 Jul 2021 23:49:51 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60040.outbound.protection.outlook.com [40.107.6.40]) (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 6DF853A1078; Thu, 1 Jul 2021 23:49:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=F2S6NSnDYDm8EHaFkpAW7yTLmtM3nHdEnzvxHl8DaC2URjTnQTVQnqtonIKk/4MUIoi8yHJSz5ryBWvk48aBO8YE16/rhpnfE1mzJgQUc9SvTt998EGdpMCVlzRtjVUJYIRdEC8ZzbWHC2zwcoPd62fIzN0bu919/MJ4NU4ToY+ZB5ZpS3eHhywwEFkGUFF1HBu8UQFTpmQ0DPvBO9va8A0pj0xR3yC2P6h8T8WnZdBgKL3GogRDenEeyassVYsoVZZFYJ4T3R0FF0UgGepXWL6PPLkDRp48aJqKkIQtRws1GmP3fI5DgGzRUzl0vnBFtn2XnXeM63S+30z9tkImBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OuGZgrxnOoe+D6/8frfKqIteVSftFuUgV4uU2J+NvGk=; b=i5PnahyrVxx22RJ7ZFeq/IDO9a+pEa4iiK4b0+OW2th8n4vSPXi5GEEWBO0A1HQLKtvpGG+B4zxsMQu0ur3e+XoYrBbesCJpvacvQJqA4+f6PJX3wqKn8dvjBK4ozvcD4YDHk3KScaQLA/yFvB1rSxLN4WHIv+dh+nBzBVHajYM2KY/CfyjEHbOoQB/I+EAIHCe0STk6HONxjXRh2j3NwRrPPCpa8RWgOulMTxaadYM7QcAMgiLDSpHn1heBQnWnFoQSA0+QUL4ICY1X3Fey1bPTmzJjA2hfdxuspTKmA6TYY+NhGyB7wlpkL3KKKDkWmSqSmyZ8Cqeo73BZikYvrA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OuGZgrxnOoe+D6/8frfKqIteVSftFuUgV4uU2J+NvGk=; b=HUbX5xlkER17wff5OIXw5uha4NcMoZWB5mXIflKeOyFOUeCXg3kLN+dUrRtlpFf2f7V63p3Zq3bsWv6TyRE0KkBM2KBkQazZwWP5CJZZAnFlBbxsm3K1YhqDtzGRbU1C2j/3EDWCNqrtiOl1UZp9kDc1FFtbwqRtWrvDcpF0Wd0= Authentication-Results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM9P190MB1569.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:3e7::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4287.23; Fri, 2 Jul 2021 06:49:48 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::fd93:9b33:ac92:ea58]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::fd93:9b33:ac92:ea58%8]) with mapi id 15.20.4264.027; Fri, 2 Jul 2021 06:49:48 +0000 Date: Fri, 2 Jul 2021 08:49:44 +0200 From: Juergen Schoenwaelder To: mohamed.boucadair@orange.com Cc: "ops-dir@ietf.org" , "draft-ietf-sfc-nsh-integrity.all@ietf.org" , "sfc@ietf.org" Message-ID: <20210702064944.a7k5tu6q4uwrvvol@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: mohamed.boucadair@orange.com, "ops-dir@ietf.org" , "draft-ietf-sfc-nsh-integrity.all@ietf.org" , "sfc@ietf.org" References: <162460909273.657.16151989326348143956@ietfa.amsl.com> <9774_1624614936_60D5A818_9774_471_2_787AE7BB302AE849A7480A190F8B9330353B0E12@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <24262_1625202611_60DE9FB3_24262_195_1_787AE7BB302AE849A7480A190F8B9330353B4F52@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <24262_1625202611_60DE9FB3_24262_195_1_787AE7BB302AE849A7480A190F8B9330353B4F52@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: FR3P281CA0023.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:1c::7) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by FR3P281CA0023.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:1c::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.8 via Frontend Transport; Fri, 2 Jul 2021 06:49:47 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5b3f0aaf-5a64-49d5-a908-08d93d25955b X-MS-TrafficTypeDiagnostic: AM9P190MB1569: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: cY9+PXYhhMF67+F1OA/JTxFOFIQ1SrJqbpoNo/NL9eZHBVhS5xaLbO2zj2ZSvYLBtOfAbpcJO0KnOMVp/5p+4Tx928AZVyU2tco8FsAqMAjZkuMM/Uvq3htPDG5CqCYmStOWfMOQ2JaivnJpTvv7NvVjcDnTGXLLLQLde0Gd6YjGPNg3aVhds6+V2A7qSxqDlVOe6n7KFqy+YHzbFdhDp8u1TkqZ/GnV6OYincdI9TXkFDkuBIh6FodlOTSQ6dnJvlf5hcxwMNg8tT4QiMaNlnX3l3awNScG08ZeFHIlrfEIaWsL2NV1U2HkuN4rrd9iOHytASGNKI1pf5jrqO9UA/rk8VWz0fOAm/TjVo2PK0r7p5FqdlQyHFGokIjDZGV5lt4LENTcKubaPjVeDc8qH80mqFz2FyViaqHORXKFbPXhcfTxwkJSnVcyOLB1STMcBom5aCaT3uK7ktsM1WiORjMxfKV+20p/jJVf7S9XlUhXkYn70q4BiewQBOh9IuYQRL63I3kRVfIFxRkexWMgf48UMBz1V3QXq7ELsIoNHuv76TnVNMdQk1h023BWZLF7Pn2VI0BIdtTJECVOH0vS94wISJC21AeR/itlcR4jlvsf5ZCO7KkdugfyF8H7YmRaGCDKR53EhC9umFoSvyeXNvo394tzaHQpZshVO0CAJqloT9S1PqvbAHoFxRQVj+WKUVKzEDPVB/WqtpBsQU3iei2774YFgLA9bZKywH15bFMu9guSG+p862bXzzLjDWVk6oKH369kWBs2MEFkR0QjiVcLsxRxNnJISclBl2HDtQ5eW4OtRuQ7WLnglGkxjuo5lSq6UX8fC94vUF3VPG4yv7ij6n0JCSFvGsbFpN7GgQQ= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(346002)(396003)(366004)(39850400004)(376002)(136003)(3450700001)(66574015)(54906003)(83380400001)(26005)(6496006)(186003)(52116002)(16526019)(4326008)(956004)(2906002)(6486002)(66556008)(5660300002)(966005)(316002)(1076003)(478600001)(66946007)(8676002)(6916009)(786003)(66476007)(8936002)(38350700002)(6666004)(86362001)(38100700002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?iso-8859-1?Q?GE3jt8gY/qyAQk4H6qFbkqYGg/xeIEA7f5S/mn141Nf2WtsRK1JfWkVFA/?= =?iso-8859-1?Q?PfDIkUpFZCPrPxBKtUjjrGY+GqrgbTS0MS8+ffie47OLyN7QYgqdPMJ+Cg?= =?iso-8859-1?Q?bjDXmPJ4N8SoQ6ijTPx7c162YEF0WeHGJH5z9oBrHW5081ZS4wMIJ/yapf?= =?iso-8859-1?Q?1VQxxrejkSS+FS3K0UzpnA9nB6N70VHu5LAUe36nsXj3NwXerR7Rr0KJPg?= =?iso-8859-1?Q?EdZzBZ6jCpLZIHVpjZHIAQDsMC2MXlMq5A6s6HkBG7TkkYzVVJ9GxZslQx?= =?iso-8859-1?Q?Jh524g9tWfmQ4JT/NGJH1hFsA84c3etuytQP0kxLDKT+59Oiq8cW5kngMQ?= =?iso-8859-1?Q?3lXifQji7PoN/HZaxUkR5csT8u8boRWWV2jDi74D8tvN4SRk2U0ZDiAt/I?= =?iso-8859-1?Q?vsZD3+vf3GnnzO4L5jHL0lL8z7MoRgCwLyvcXVeCr26MrisGB754ZhKzGv?= =?iso-8859-1?Q?x9+KNi3j+wYCEXKys+wilN+6VRpsPK7iik0xmkDhvr40/i0hbSl1WehoAn?= =?iso-8859-1?Q?4krsGPVgJCl1VEnl6i2I2hDfHeZPsPV/HNjCd/sVJX36b97z7U2DqMPmKx?= =?iso-8859-1?Q?Outq55xGAv1QbES95dNp8mODMcyHUpmbfU8DoXScJ0YoQmkhRygLRtZQXd?= =?iso-8859-1?Q?t1LJPZavXEHiHYAVMxYML4g0VwgB8Uvgf06qhSZTg+3kV7b0pA++SAUkxi?= =?iso-8859-1?Q?aNGftvyKUo54d9aaWkiITLMXgsQM1ycdU9LmruXPPka1JNdZEocR8LbVPp?= =?iso-8859-1?Q?bAqqgKjFMP4ff6P920iW85o8r5gLOvvMBELS+0ZuSY2zbQ7pO6Gvt05nc4?= =?iso-8859-1?Q?MtHtWGTnaY0pI64MsvUs2q4oUjSrxV8Wu54CPpXwFV8U7ZT5sRqhPTOiqs?= =?iso-8859-1?Q?w92JSnF8fhg7eIZrzHwlB7r8vFaA+mNn1O3beQzTPZGFCFAI9CehPKoE32?= =?iso-8859-1?Q?pYAuSMEXMTOd3wy/vaTwo5jgFaNFoC7cYWaG6oMPj2/QAT0hRwyJjWgHSf?= =?iso-8859-1?Q?0k977Q6nK6K7U6SPa3VTUa2KQKOhulSD2mJaOTuLpPmnD1dTzvYWHTRUj2?= =?iso-8859-1?Q?CUCMt2whH/7tk2Zh04H/QLNytEFBhMsWdyP5nqDODk46Q/WMsnjEst3+vX?= =?iso-8859-1?Q?rSTDsy7Dd3XbSKR3JduJEBiYs0owfuJLkngkICEt+H1A8LouMGI3GNOddg?= =?iso-8859-1?Q?VLg9B8G+0/I1tnEvEw5YP32SDjCSIAzj1NEam57p5DE/OFuyupeebOMsYd?= =?iso-8859-1?Q?zDe4IWPLerIIce1Zoor6Top1g6h8YLAhLXGWJWUMwxZwrdv4MYC+R/KpFy?= =?iso-8859-1?Q?WGxPEnlr75Vgzzp7RrTWu1RkkbPUGbgUeXENMRYoI/h/aMpnShYhjp43r7?= =?iso-8859-1?Q?NxvsPNQ0dk?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 5b3f0aaf-5a64-49d5-a908-08d93d25955b X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jul 2021 06:49:48.0513 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: HX84VUVfWSI/Cbhol7mDwGbtLnBrr3bNMUmzySm1HbKILErlG47gQesU3972xct7icKEij+q441gkXAraeamDKMUvvSvDVPz5lFA7Gi7ypk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1569 Archived-At: Subject: Re: [sfc] Opsdir last call review of draft-ietf-sfc-nsh-integrity-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2021 06:49:57 -0000 Med, looks good, thanks for taking my comments into account. /js On Fri, Jul 02, 2021 at 05:10:10AM +0000, mohamed.boucadair@orange.com wrote: > Hi Jürgen, > > FYI, the changes are now implemented in the public version: > https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-integrity-06 > > Cheers, > Med > > > -----Message d'origine----- > > De : mohamed.boucadair@orange.com > > [mailto:mohamed.boucadair@orange.com] > > Envoyé : vendredi 25 juin 2021 11:56 > > Ŕ : Jürgen Schönwälder ; ops- > > dir@ietf.org > > Cc : draft-ietf-sfc-nsh-integrity.all@ietf.org; last-call@ietf.org; > > sfc@ietf.org > > Objet : RE: Opsdir last call review of draft-ietf-sfc-nsh-integrity- > > 05 > > > > Hi Jürgen, > > > > Thank you for the review. You can track the changes at: > > https://tinyurl.com/nsh-integrity-latest > > > > Please see inline. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De : Jürgen Schönwälder via Datatracker [mailto:noreply@ietf.org] > > > Envoyé : vendredi 25 juin 2021 10:18 Ŕ : ops-dir@ietf.org Cc : > > > draft-ietf-sfc-nsh-integrity.all@ietf.org; last-call@ietf.org; > > > sfc@ietf.org Objet : Opsdir last call review of > > > draft-ietf-sfc-nsh-integrity-05 > > > > > > Reviewer: Jürgen Schönwälder > > > Review result: Has Issues > > > > > > The document is very well written and organized, thanks for that. > > I > > > have some comments and a few nits. The issues I have a minor, I > > think > > > the document overall is in a good shape. > > > > > > - From an operational perspective, I very much appreciate that > > there > > > is some text discussing error and failure reporting and that > > there > > > are some MTU configuration guidelines. > > > > > > - The document claims: > > > > > > As depicted in Table 1, SFFs are not involved in data > > encryption. > > > This document enforces this design approach by encrypting > > Context > > > Headers with keys that are not supplied to SFFs, thus > > enforcing > > > this > > > limitation by protocol (rather than requirements language). > > > > > > I am a bit puzzled about this statement since a protocol > > definition > > > at the end is just some form of requirements language. > > > > [Med] FWIW, that sentence was drawn compared to an alternative > > design we considered in the past (use of AEAD which relies upon a > > single key for both encryption and integrity) and for which we > > indicated the following at that time: > > > > In order to avoid the overhead of multiple authentication tags > > and > > multiple keys, and to prevent SFFs from acquiring the secret > > key > > to decrypt the metadata, the recommendation is not to > > integrity > > protect the base header. Such approach does not require to > > recompute the MAC each time TTL is decremented by an SFF. As > > a > > reminder, an SFF is not supposed to act on the metadata or > > look > > into the content of the metadata. > > > > We were concerned with relying on the requirement language (mainly > > the last sentence) for the correct protocol behavior. We changed the > > design so that the limitation is imposed by the protocol: use > > distinct keys for encryption (ENC_KEY) and integrity (MAC_KEY). > > > > We do have the following: > > > > The other advantage is > > that SFFs do not have access to the ENC_KEY and cannot act on the > > encrypted Context Headers and, only in case of the second level > > of > > assurance, SFFs do have access to the MAC_KEY. Similarly, an > > NSH- > > aware SF or SFC Proxy not allowed to decrypt the Context Headers > > will > > not have access to the ENC_KEY. > > > > but ... > > > > Well, > > > putting > > > that remark aside, I do not really see anything in the > > specification > > > that ensures that SFFs won't get the keys. We also read: > > > > > > [...] Encryption keying material is only provided to > > > these SFC data plane elements. > > > > > > Well, the specification is actually silent about how keys are > > > distributed. Section 4.4. says: > > > > > > The procedure for the allocation/provisioning of secret keys > > (K) > > > and > > > authenticated encryption algorithm or MAC_KEY and HMAC > > algorithm > > > is > > > outside the scope of this specification. As such, this > > > specification > > > does not mandate the support of any specific mechanism. > > > > > > To me, it seems the claims made in section 4.4. do not really > > hold. > > > > [Med] ... I agree that we still depend on the provisioning. Removed > > that sentence. > > > > > > > > - In section 6, you picked as the epoch 1970-01-01T00:00Z while > > NTP > > > uses the epoch 1900-01-01T00:00Z. This leads to rollovers in the > > > year 2106 for your timestamps while the NTP rollover would be in > > > 2036. Given that you use an NTP compatible format and a > > different > > > epoch, I think this deserves to be spelled out explicitly so > > that > > > people understand that they have to do conversions. > > > > > > (Alternatively, you could adopt the epoch NTP is using and the > > need > > > for conversions goes away at the price of an earlier rollover.) > > > > > > Anyway, what I am saying is that if you pick a different epoch, > > I > > > suggest to spell this out explicitly and to not rely on > > > implementers to discover this. > > > > > > > [Med] Fair point. Added a note. > > > > > Minor nits: > > > > > > - In section 5.2, it should say: > > > > > > OLD > > > > > > In reference to Figure 5 > > > > > > NEW > > > > > > In reference to Figure 7 > > > > > > > [Med] For both 5.1 and 5.2 we provide a reference to the figure with > > the format of the context header (i.e., Figure 5). Figures 6/7 cover > > the NSH header and so on. > > > > > - In section 7.3, I suggest this change to make it clear again to > > the > > > reader what K is: > > > > > > OLD > > > > > > Using K and > > > > > > NEW > > > > > > Using the secret key K and > > > > [Med] Fixed. Thanks. > > > > > > ____________________________________________________________________ > > _____________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc pas etre > > diffuses, exploites ou copies sans autorisation. Si vous avez recu > > ce message par erreur, veuillez le signaler a l'expediteur et le > > detruire ainsi que les pieces jointes. Les messages electroniques > > etant susceptibles d'alteration, Orange decline toute responsabilite > > si ce message a ete altere, deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; they should not > > be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender > > and delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that > > have been modified, changed or falsified. > > Thank you. > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Jul 9 16:50:09 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D493A0E21 for ; Fri, 9 Jul 2021 16:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.196 X-Spam-Level: X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=intel.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhlVTeU6u5KH for ; Fri, 9 Jul 2021 16:50:03 -0700 (PDT) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8125D3A0E1D for ; Fri, 9 Jul 2021 16:49:59 -0700 (PDT) X-IronPort-AV: E=McAfee;i="6200,9189,10040"; a="295437378" X-IronPort-AV: E=Sophos;i="5.84,228,1620716400"; d="scan'208,217";a="295437378" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Jul 2021 16:49:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.84,228,1620716400"; d="scan'208,217";a="647241217" Received: from orsmsx602.amr.corp.intel.com ([10.22.229.15]) by fmsmga006.fm.intel.com with ESMTP; 09 Jul 2021 16:49:55 -0700 Received: from orsmsx609.amr.corp.intel.com (10.22.229.22) by ORSMSX602.amr.corp.intel.com (10.22.229.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Fri, 9 Jul 2021 16:49:55 -0700 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by orsmsx609.amr.corp.intel.com (10.22.229.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10 via Frontend Transport; Fri, 9 Jul 2021 16:49:55 -0700 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.173) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.4; Fri, 9 Jul 2021 16:49:42 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Qm6GyJHVTXKjn407WqCry0aM3+TyKYylaPyqGRrJ2tilYscjcGptd9vfNR6KbVRaFR96f5u2hVz6YuOqse3EbfxqA97jxh8rsuOgSiOUgPjIG2ZPYTmzDUdM2XVeixAGoX74SpZAuLxULsxtYKHu7iVWnaWFavWlItsJCLBuwDJlkJ5iQgRYdtAFZDpSL4Kw1Abg4GV19PLTqIukvCTP/egNgGjWrKd38/bELo7A2es819tSbqscloGAZWbBO659GLZ4olQch8z1VkZNR7iXkx45sFx95XWQCkueNPOs6nl1HvmpO5IZsnYLqM2SNX9PAuWpu65au1VMjpy/dzeIiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8kMsEWmQaX/Nfhd0/JHwa9Bpr/QGs5irxzRJycV8muc=; b=C/2VCzN6Zs4OcdIrKevsUU8r6z/ZJPAZJtYGBZItzEd59OaqribCALj7fLsj8RdPwnDzPLZATeSXBQ8nHN/6nHj1dRLGAr8d/6GKo4UcKYPrULQX/+u5doMUUUtNUP/B/3eIY9VzwE0RUPlMIS28sOQkUomsU4RHAgDMN/UEwF3e9SjDp3aqDNMabzAsG2ToIfi9K4SvgZ5uT9akAoauqRSsiHyzjKGMNyeh/+9cdsCGTIFEtmJAeThhg7WM2CKCTWQce8Z6QIGa625zbhpncatKFICXbKhSzFH76j5+X04bbyWwv66QCsa3zQyB+mSGT5WpNBk3yIumnhZobZ/d/A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8kMsEWmQaX/Nfhd0/JHwa9Bpr/QGs5irxzRJycV8muc=; b=F014/E2t3WHUz39yIRDluXV82K4A6VDmRrnfmVoiSHIhzIsEsoOxvS8p7CbF3dH0kEG05eZIr7/t9hOLhQ8ii/+Wfm87Lop4kyipifUzHEgbXuMQMkRLeJEsKs8Q3DdBYrEdzGCsd/niF7BZBrpQSbkq+1I+m52AqU3ce9Bjjxk= Received: from MN2PR11MB3630.namprd11.prod.outlook.com (2603:10b6:208:f4::19) by MN2PR11MB4693.namprd11.prod.outlook.com (2603:10b6:208:261::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.22; Fri, 9 Jul 2021 23:49:37 +0000 Received: from MN2PR11MB3630.namprd11.prod.outlook.com ([fe80::fd4c:1579:2427:a2ed]) by MN2PR11MB3630.namprd11.prod.outlook.com ([fe80::fd4c:1579:2427:a2ed%5]) with mapi id 15.20.4308.023; Fri, 9 Jul 2021 23:49:37 +0000 From: "Elzur, Uri" To: "Carlos Pignataro (cpignata)" , "sfc@ietf.org" Thread-Topic: [sfc] IPR Confirmation for Re: Completing WG last call for draft-ietf-sfc-nsh-tlv Thread-Index: AQHXW8oDM9PTu6ku7Ueq4LmHSa+ot6s7gk7g Date: Fri, 9 Jul 2021 23:49:37 +0000 Message-ID: References: <3518A7AB-E589-417C-9DB7-EC5C45575E59@cisco.com> In-Reply-To: <3518A7AB-E589-417C-9DB7-EC5C45575E59@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-version: 11.5.1.3 dlp-reaction: no-action dlp-product: dlpe-windows authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9a17f07e-54ab-44c8-e9cb-08d94334362f x-ms-traffictypediagnostic: MN2PR11MB4693: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3968; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: clYhnVvO0V2zW6RFOLj+s6vm9k5MB/Amx4DfiaxjD5qajsnEQign7lS+Z6K6ddF/73kOTAufEev8yhly7M12QEvhntX/w6r7X3R2PwgO4kKBDYMXFyOiBvJYe//VKRKmBdzZ8vAh0kGKbYniFYnXOf/HjIOIi50p7e+b42o/Htinks0Mzps17aMbRiEO8wbuN/pk4U63L57Vvb/26l22fkE0GZh6U5esXmOWBKX90BivmQzgPxob5RU3aDtwcQUJTh7emtw8ZTwqU5/U1i4HSMvFqJupkbxtDKfpt7WvYr7/R3/xHyN8MgnmTp5QO9IpMqRHjgX4jMPs9go6Tqebo98o5vBK+6T+bXhXO3NgCfXQzQBP2dal89kW1LVD9DuwiUDMmr4dwnXs1PYYmubo2bXjDBHTsGbwFYr0dEw3T7ff91Myp1n4Xsq7l3sMQQqAaBJ8RwdwsWKCtNjwNyyPciljOHPnG7TDdz6yqNVYNACUOHPIjYcKKfVUgorx6jeWOcATKYDe4M1ojMhtn0m0ZmUPrltFT7iaZ8Mj1f8KYcU8fs+b0T5Doy/M7y5YrJgKChkj1FpSuxMIyjedExaVt9xXk0YkqRUC083HBBWbkUuP0ZdVr4CoZUytFDVBu/NIiPrb9lJ7tN2D8SPmhjLyp3XCbhNemR7cLUPWW135x1o8xllTKvVWV8JknRb3JgJtRl+S7sLF7hRdhKDnqdZDD6MQvtqs0xih4iJSmhjQBuE= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB3630.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(346002)(39860400002)(396003)(376002)(136003)(4744005)(52536014)(122000001)(8936002)(6506007)(2906002)(478600001)(38100700002)(71200400001)(33656002)(53546011)(8676002)(166002)(66446008)(83380400001)(76116006)(66556008)(64756008)(5660300002)(110136005)(55016002)(66946007)(9686003)(316002)(186003)(966005)(66476007)(7696005)(86362001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?cSiiJgiNNwFWj2eJfmSnG/d0GU5YlX38s+0/M9swxFPfZjPHh05/xSn4TbJm?= =?us-ascii?Q?sneYuW5+kPXdnnPsLjT5HGEsCH+yn3vLB8ubaqF91Ze53Q1ENvv8kyaf/G0t?= =?us-ascii?Q?GHIqKdN2x3aiHISf/rE8Bac2Ez8ECGx6ivMqkSZV+m/ZpBOwROMH5yZqg8XH?= =?us-ascii?Q?EenPVnZAwYTYMqDrewKgIavrfQgMYR5YCHxmS7CPa3rjB1AVzL6fbot5F3wQ?= =?us-ascii?Q?fb/Kextrp/snhiGSMjkyjK2oLhDU4LD/sV271Yn1pp2jc6B3rY8+MweqQFPY?= =?us-ascii?Q?EtamIsX1YaiNNVzs+v4B1SVUXkM0HrQzjERTa8kxAJpS07e6XQqOne0m8cVW?= =?us-ascii?Q?6POS/KO2GhUQIQZqEV9LxOWGEJPIv3UOIn8T9rw3Jqw+wiEwet3UADmFNijc?= =?us-ascii?Q?9fz4Pa+F1wZnVGAjlTWosMgPNeYcOY+50AIQ9WvCA7QbB1pSbEUDf32Mg45j?= =?us-ascii?Q?/LdHrPqynPKm3grJRco4v/7gIgI1hZ8+j7Da99+dz+apo2U7znpSQQ6YwiI9?= =?us-ascii?Q?Vf/NNVjhKIi1muZraPZYASnbR8xjUHMa3+8aEnG+jzBICwbvX0Jpz65mLvS7?= =?us-ascii?Q?JdNPXX86yOc+xWrsrhOO2F70bXB6xhaHFa9elophAR5MMyThl3dShq3EqznZ?= =?us-ascii?Q?LNYDeoRKDIncpVe+dusBU857A2irJhziHYXeIDbJn9bitIBe5TKCHcUvUhYX?= =?us-ascii?Q?9srdjunvPkYN3pN7Y8R4REzU5LlnlQQGF/aXZXotB2ThJs7j5+yXW34QUbiu?= =?us-ascii?Q?2eknI16EyFL8nxJ3cYhPUTC6SZB/b10AcPnoJYIq97CuYo67C3lYD8d73H6A?= =?us-ascii?Q?v7XWPH0N7o41WGfh0xQUHO+0HR4J4/EhFuRkfA5K5NuoCQyXyoi1jTnNy+DH?= =?us-ascii?Q?/iKHfIB8E7P6P/RzNBzEpaLcak9P8zezGBm7nq97R1H0JT4nmIa2AD8ii/2D?= =?us-ascii?Q?wMHa+sqL7V+DLZpxj/9R+qm1a598EeM0lbz1R7ZlW80EAbSyEk2O3peZLqY6?= =?us-ascii?Q?dTpW6IqB+zR7mpsyk/cp9VRkmuGF4PeJ0rVSqACogprCoXpCG35TscumuVYo?= =?us-ascii?Q?2dObqXGbguKC9C9cErRpzH0YBnNyrBIddyu7/4cK2arP2A9ZQDh0Sx09JvME?= =?us-ascii?Q?tOQV9nM/sJP8UP9wJ4SbZY6qIo21qR4hPvjF+XWoF5GCNVcwtLHKGTSDvpw9?= =?us-ascii?Q?7czKBbPsJGW9JNbOBf32UvOVa2OE8q3Dc7Ab72X2eSLdvqbBpfZFoVXTsXU4?= =?us-ascii?Q?RFTcKYeBoHHqBjgqFBWplinkBh7k90MKk+Dkk7VVKRLDXRXkAeszA4+Q8oQ/?= =?us-ascii?Q?8PTHMc61dd1zWPDDJGoUAZO8Qe35VvttFM2bC0O695ihNUVxWjMZTO/Qq9mp?= =?us-ascii?Q?LZLXDmkKc/WVFPBVWO77YgFeoIgx?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB3630A59DA704E97AD78C3FC9FB189MN2PR11MB3630namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB3630.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9a17f07e-54ab-44c8-e9cb-08d94334362f X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2021 23:49:37.5326 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: AFsOBkOzLqEBNANOzqgQX8d1YezDOES/WMOIKtPiyLjG7ubICZooGRYtXC17hqDDLWHG9kXYFyFt7w/7NdxJag== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4693 X-OriginatorOrg: intel.com Archived-At: Subject: Re: [sfc] IPR Confirmation for Re: Completing WG last call for draft-ietf-sfc-nsh-tlv X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2021 23:50:08 -0000 --_000_MN2PR11MB3630A59DA704E97AD78C3FC9FB189MN2PR11MB3630namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Joel I'm not aware of any IPR relating to the NSH TLV definition document Apologize for the delay! Thx Uri ("Oo-Ree") C: 949-378-7568 From: sfc On Behalf Of Carlos Pignataro (cpignata) Sent: Monday, June 7, 2021 11:22 AM To: sfc@ietf.org Subject: [sfc] IPR Confirmation for Re: Completing WG last call for draft-i= etf-sfc-nsh-tlv Hi, Joel, SFC, I am not aware of any IPR relating this NSH TLV definition document. https://mailarchive.ietf.org/arch/msg/sfc/-m_KdgI0WmK2rEhSV406-crT4hA/# Thanks! Carlos. --_000_MN2PR11MB3630A59DA704E97AD78C3FC9FB189MN2PR11MB3630namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Joel

 

I’m not aware of any IPR relating to the NSH T= LV definition document

 

Apologize for the delay!

 

Thx

 

Uri (“Oo-Ree”)

C: 949-378-7568

 

From: sfc <sfc-bounces@ietf.org> On = Behalf Of Carlos Pignataro (cpignata)
Sent: Monday, June 7, 2021 11:22 AM
To: sfc@ietf.org
Subject: [sfc] IPR Confirmation for Re: Completing WG last call for = draft-ietf-sfc-nsh-tlv

 

Hi, Joel, SFC,

 

I am not aware of any IPR relating this NSH TLV defi= nition document.

 

https://mailarchive.ietf.org/arch/msg/sfc/-m= _KdgI0WmK2rEhSV406-crT4hA/#

 

Thanks!

 

Carlos.

--_000_MN2PR11MB3630A59DA704E97AD78C3FC9FB189MN2PR11MB3630namp_-- From nobody Fri Jul 9 20:03:51 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1975C3A16D9; Fri, 9 Jul 2021 20:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTI5vixOHGr2; Fri, 9 Jul 2021 20:03:35 -0700 (PDT) Received: from mxus.zteusa.com (mxus.zteusa.com [4.14.134.162]) (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 3D9883A16F4; Fri, 9 Jul 2021 20:03:33 -0700 (PDT) Received: from mse-us.zte.com.cn (unknown [10.36.11.29]) by Forcepoint Email with ESMTPS id BA7366C1F78F68296AEC; Sat, 10 Jul 2021 11:03:32 +0800 (CST) Received: from mgapp02.zte.com.cn ([10.36.9.143]) by mse-us.zte.com.cn with SMTP id 16A33TTD004869; Sat, 10 Jul 2021 11:03:29 +0800 (GMT-8) (envelope-from gregory.mirsky@ztetx.com) Received: from mapi (mgapp02[null]) by mapi (Zmail) with MAPI id mid81; Sat, 10 Jul 2021 11:03:28 +0800 (CST) Date: Sat, 10 Jul 2021 11:03:28 +0800 (CST) X-Zmail-TransId: 2afa60e90e00237a8798 X-Mailer: Zmail v1.0 Message-ID: <202107101103288922038@zte.com.cn> Mime-Version: 1.0 From: To: , , Content-Type: multipart/mixed; boundary="=====_001_next=====" X-MAIL: mse-us.zte.com.cn 16A33TTD004869 Archived-At: Subject: [sfc] =?utf-8?q?The_first_version_of_the_Shepherd_review_of_draf?= =?utf-8?q?t-ietf-sfc-nsh-tlv_is_ready?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jul 2021 03:03:49 -0000 --=====_001_next===== Content-Type: multipart/related; boundary="=====_002_next=====" --=====_002_next===== Content-Type: multipart/alternative; boundary="=====_003_next=====" --=====_003_next===== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 RGVhciBBbGwsDQoNCg0KSSd2ZSBwdWJsaXNoZWQgdGhlIGZpcnN0IHZlcnNpb24gb2YgdGhlIFNo ZXBoZXJkIHJldmlldyBvZiBkcmFmdC1pZXRmLXNmYy1uc2gtdGx2LiBQbGVhc2UgdGFrZSBhIGxv b2sgYW5kIHNoYXJlIHlvdXIgY29tbWVudHMsIGxldCBtZSBrbm93IGlmIHlvdSBoYXZlIGFueSBx dWVzdGlvbnMsIHN1Z2dlc3Rpb25zLg0KDQoNCg0KDQoNCg0KRGVhciBBdXRob3JzIGFuZCBFZGl0 b3JzLA0KDQoNCg0KcGxlYXNlIGZlZWwgZnJlZSB0byBwdWJsaXNoIHRoZSB3b3JraW5nIHZlcnNp b24gb2YgdGhlIGRyYWZ0IHRoYXQgYWRkcmVzc2VzIG15IGVhcmxpZXIgY29tbWVudHMgKGVudGly ZWx5IGVkaXRvcmlhbCBuaXRzKS4gSSd2ZSByZXZpZXdlZCBwcm9wb3NlZCB1cGRhdGVzIGFuZCBj b21wbGV0ZWx5IGFncmVlIHdpdGggYWxsIG9mIHRoZW0uDQoNCg0KDQoNCg0KDQoNCg0KUmVnYXJk cywNCg0KDQpHcmVnIE1pcnNreQ0KDQoNCg0KDQoNCg0KU3IuIFN0YW5kYXJkaXphdGlvbiBFeHBl cnQNCumihOeglOagh+WHhumDqC/mnInnur/noJTnqbbpmaIv5pyJ57q/5Lqn5ZOB57uP6JCl6YOo IFN0YW5kYXJkIFByZXJlc2VhcmNoIERlcHQuL1dpcmVsaW5lIFByb2R1Y3QgUiZEIEluc3RpdHV0 ZS9XaXJlbGluZSBQcm9kdWN0IE9wZXJhdGlvbiBEaXZpc2lvbg0KDQoNCg0KDQoNCg0KDQoNCg0K RTogZ3JlZ29yeS5taXJza3lAenRldHguY29tIA0Kd3d3Lnp0ZS5jb20uY24= --=====_003_next===== Content-Type: text/html ; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iemNvbnRlbnRSb3ciPjxwIHN0eWxlPSJmb250LXNpemU6MTJweDtmb250LWZh bWlseTpzYW5zLXNlcmlmOyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsiPkRlYXIgQWxs LDwvc3Bhbj48L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToxMnB4O2ZvbnQtZmFtaWx5OnNhbnMtc2Vy aWY7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyI+SSd2ZSBwdWJsaXNoZWQgdGhlIGZp cnN0IHZlcnNpb24gb2YgdGhlIFNoZXBoZXJkIHJldmlldyBvZiBkcmFmdC1pZXRmLXNmYy1uc2gt dGx2LiBQbGVhc2UgdGFrZSBhIGxvb2sgYW5kIHNoYXJlIHlvdXIgY29tbWVudHMsIGxldCBtZSBr bm93IGlmIHlvdSBoYXZlIGFueSBxdWVzdGlvbnMsIHN1Z2dlc3Rpb25zLjwvc3Bhbj48L3A+PHAg c3R5bGU9ImZvbnQtc2l6ZToxMnB4O2ZvbnQtZmFtaWx5OnNhbnMtc2VyaWY7Ij48YnI+PC9wPjxw IHN0eWxlPSJmb250LXNpemU6MTJweDtmb250LWZhbWlseTpzYW5zLXNlcmlmOyI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogMTZweDsiPkRlYXIgQXV0aG9ycyBhbmQgRWRpdG9ycyw8YnI+PC9zcGFu PjwvcD48cCBzdHlsZT0iZm9udC1zaXplOjEycHg7Zm9udC1mYW1pbHk6c2Fucy1zZXJpZjsiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDE0cHg7Ij5wbGVhc2UgZmVlbCBmcmVlIHRvIHB1Ymxpc2gg dGhlIHdvcmtpbmcgdmVyc2lvbiBvZiB0aGUgZHJhZnQgdGhhdCBhZGRyZXNzZXMgbXkgZWFybGll ciBjb21tZW50cyAoZW50aXJlbHkgZWRpdG9yaWFsIG5pdHMpLiBJJ3ZlIHJldmlld2VkIHByb3Bv c2VkIHVwZGF0ZXMgYW5kIGNvbXBsZXRlbHkgYWdyZWUgd2l0aCBhbGwgb2YgdGhlbS48L3NwYW4+ PC9wPjxwIHN0eWxlPSJmb250LXNpemU6MTJweDtmb250LWZhbWlseTpzYW5zLXNlcmlmOyI+PGJy PjwvcD48ZGl2IGNsYXNzPSJ6TWFpbFNpZ24iIHVub25hbWVjaD0iR3JlZ29yeTEwMjExOTE1IiB1 bm9uYW1lZW49ImdyZWdvcnkgbWlyc2t5MTAyMTE5MTUiPjxkaXYgY2xhc3M9InpNYWlsU2lnbkNv bnRlbnQiPjxkaXY+PGRpdj48ZGl2PjxwIHN0eWxlPSJmb250LWZhbWlseTog5a6L5L2TOyBmb250 LXNpemU6MTRweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgd2lkb3dzOiAxOyI+PHNwYW4gc3R5bGU9 ImNvbG9yOiByZ2IoODgsIDg5LCA5MSk7IGZvbnQtZmFtaWx5OiDlvq7ova/pm4Xpu5E7IGZvbnQt c2l6ZTogMTRweDsiPlJlZ2FyZHMsPC9zcGFuPjwvcD48cCBzdHlsZT0iZm9udC1mYW1pbHk6IOWu i+S9kzsgZm9udC1zaXplOjE0cHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IHdpZG93czogMTsiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDE0cHg7IGNvbG9yOiByZ2IoODgsIDg5LCA5MSk7IGZvbnQt ZmFtaWx5OiDlvq7ova/pm4Xpu5E7Ij5HcmVnIE1pcnNreTwvc3Bhbj48L3A+PHAgc3R5bGU9ImZv bnQtc2l6ZToxNHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyB3aWRvd3M6IDE7Ij48c3BhbiBzdHls ZT0iY29sb3I6IHJnYig4OCwgODksIDkxKTsgZm9udC1mYW1pbHk6IOW+rui9r+mbhem7kTsgZm9u dC1zaXplOiAxNHB4OyI+PGJyPjwvc3Bhbj48L3A+PHAgc3R5bGU9IndpZG93czogMTsiPjxmb250 IGNvbG9yPSIjNTg1OTViIiBmYWNlPSLlvq7ova/pm4Xpu5EiPlNyLiBTdGFuZGFyZGl6YXRpb24g RXhwZXJ0PC9mb250Pjxicj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IOW+rui9r+mbhem7kTsg Zm9udC1zaXplOiAxMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBjb2xvcjogcmdiKDg4LCA4OSwg OTEpOyI+PHNwYW4gY2xhc3M9InNpZ25lZGl0IiBpZD0ic2lnbl9kZXB0Ij7pooTnoJTmoIflh4bp g6gv5pyJ57q/56CU56m26ZmiL+aciee6v+S6p+WTgee7j+iQpemDqDwvc3Bhbj4gPHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OkFyaWFsIj4gPHNwYW4gY2xhc3M9InNpZ25lZGl0IiBpZD0ic2lnbl9k ZXB0X2VuZyI+U3RhbmRhcmQgUHJlcmVzZWFyY2ggRGVwdC4vV2lyZWxpbmUgUHJvZHVjdCBSJmFt cDtEIEluc3RpdHV0ZS9XaXJlbGluZSBQcm9kdWN0IE9wZXJhdGlvbiBEaXZpc2lvbjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwvcD48cCBzdHlsZT0iZm9udC1zaXplOjE0cHg7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7IHdpZG93czogMTsiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDg4LCA4OSwgOTEpOyBm b250LWZhbWlseTog5b6u6L2v6ZuF6buROyBmb250LXNpemU6IDE0cHg7Ij48YnI+PC9zcGFuPjwv cD48cCBzdHlsZT0iZm9udC1zaXplOjE0cHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IHdpZG93czog MTsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTRweDtjb2xvcjojNTg1OTVCO2ZvbnQtZmFtaWx5 OuW+rui9r+mbhem7kTtmb250LXNpemU6MTRweDsiPjwvc3Bhbj48L3A+PHRhYmxlIHN0eWxlPSJj b2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTog5a6L5L2TOyB3aWRvd3M6IDE7Ij48dGJv ZHk+PHRyIGNsYXNzPSJmaXJzdFJvdyI+PHRkIHZhbGlnbj0idG9wIiB3aWR0aD0iMTAwIj48aW1n IGlkPSJzaWduLWljb24iIHdpZHRoPSIxMzAiIGhlaWdodD0iMTIwIiBzaWduPSJzaWduOjlhZTNl MjE0YzE3ZDQ5ZWQ5MzVkODdjNjc0YmEzZWUyIiBzcmM9ImNpZDo5YWUzZTIxNGMxN2Q0OWVkOTM1 ZDg3YzY3NGJhM2VlMiI+PC90ZD48dGQgdmFsaWduPSJ0b3AiIHdpZHRoPSI1MDAiIHN0eWxlPSJ3 b3JkLWJyZWFrOiBicmVhay1hbGw7Ij48aW1nIGlkPSJzaWduLWxvZ28iIHdpZHRoPSIxMTUiIGhl aWdodD0iMzgiIHNpZ249InNpZ246MjQyNDJlNTYzN2FmNDI4ODkxYzRkYjczMWU3NzY1YWQiIHNy Yz0iY2lkOjI0MjQyZTU2MzdhZjQyODg5MWM0ZGI3MzFlNzc2NWFkIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxNHB4OyBjb2xvcjogcmdiKDg4LCA4OSwgOTEpOyBmb250LWZhbWlseTogQXJpYWw7 Ij48YnI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDhGRDQiPkU8L3NwYW4+OiA8c3BhbiBjbGFzcz0i c2lnbmVkaXQiIGlkPSJzaWduX2VtYWlsIj48YSBocmVmPSJtYWlsdG86Z3JlZ29yeS5taXJza3lA enRldHguY29tIj5ncmVnb3J5Lm1pcnNreUB6dGV0eC5jb208L2E+PC9zcGFuPiA8YnI+PHNwYW4g c3R5bGU9ImNvbG9yOiMwMDhGRDQiPjxhIGhyZWY9Imh0dHA6Ly93d3cuenRlLmNvbS5jbi8iIHRh cmdldD0iX2JsYW5rIj53d3cuenRlLmNvbS5jbjwvYT48L3NwYW4+PC9zcGFuPjwvdGQ+PC90cj48 L3Rib2R5PjwvdGFibGU+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiBub3JtYWw7IHdpZG93czog MTsgZm9udC1zaXplOjE0cHg7O2NvbG9yOiM1ODU5NWI7Zm9udC1zaXplOjEwcHgiPjwvc3Bhbj48 L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48ZGl2IGNsYXNzPSJ6TWFpbEZyb20iPjwvZGl2 PjwvZGl2Pg== --=====_003_next=====-- --=====_002_next===== Content-Type: image/jpeg; name="=?UTF-8?B?MjQyNDJlNTYzN2FmNDI4ODkxYzRkYjczMWU3NzY1YWQuanBn?=" Content-Disposition: inline; filename="=?UTF-8?B?MjQyNDJlNTYzN2FmNDI4ODkxYzRkYjczMWU3NzY1YWQuanBn?=" Content-Transfer-Encoding: base64 Content-ID: <24242e5637af428891c4db731e7765ad> R0lGODlhcwAmAPcAAAAAAP///wCP1QCP1Pf7/vL5/QCP1gWR1gqT1gyU2AyU1w6V1xWY2BeZ2R6c 2iGd2iyi3C6j3TOl3Tqo3kWt4Emv4Uyw4U2x4lOz4ly35F645GO65WW75me85m6/53XC6IHH64XJ 64bK7IzM7I/N7JXQ7ZfR7pnS7pzT7p3U76PW8KPW76XX8K7b8bDc8rff87vh9Lzh9L7i9cnn9tLr +Nnu+eDx+uf0++n1++33/PD4/PT6/fj8/gKQ1AWR1QeS1QiT1QmT1g+W1xCW1xOX1xia2Bub2Ryb 2R+d2SCd2SKe2iSf2iag2ymh2yqh2yui3DSm3Tio3Typ3j2q3j6q3kCr30Os30eu4Euw4U6x4U+y 4k+y4VGz4lCy4Va141W04li241q341245F+55GW75Ga85Wm95mi95Gq+5Wu+5m2/5m/A53HB6HDA 53HB5nLB53PC53XC53bD53nE6HvF6X3G6X/H6YHI6oHI6YLI6oLI6YbK64TJ6YnL64rM64zM65HP 7JPQ7ZbR7ZrT7qXX76bY8KfY76jZ8Kra8azb8a/c8bDc8bHd8rLd8rXe8rXe8bjg87zi9Lzh873i 88Dj9MPl9cXm9cfm9cnn9c3p9s/q987p9tHr99Lr99Xt+Nbt+Nrv+d/x+eDx+eX0++Tz+u/4/OHy +ePz+ur2+/b7/fr9/vz+/v7//////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAK0ALAAAAABzACYA Rwj/AAMIHEiwoMGDCBMqXMiwoUOGiti0mUhxopcBAgZoHKAglcATFaVg3DgAC0U2hgKsKkJyiZqK FUV4bHijx4AHDFmN0BiJ4A2NRFYRJKAAo6WFKzJibOCQEclMB1WxxOgDUQEeqbKm2sEDoQaMhAqS sonE4B2MeQ7WmGlwj0YKCv0oHeDkIUGnAvJCNShVowA7dgXyyXKhsGEJG6kYNqxFUEImGSsQDJFR gOSClUj61cx5wAmEBKJk9JIwTefTaxzaGNnQxhIBex0WAUPwRZoOZnLr3q27Q6CBKXgL742mhUBW e3AP771HlcNSaDjQCVwwByQc1A2+9vtbodONsQn2/8UI2O6F03lP+/1QcEpeJgMbabwyMEzeOQuJ bBSAyC5ejeENNN5GQzBAxIEHNgAGAQZ9JQAlBvUggBIGlYDWQBtYoKGGW1yw4YZacPGhBVjsIRAB B4xEV3YCfZdRgAKNJ0ATLBo01gBlOXSIARgpohAEeQkgSo1EFmnkkUgmqeSSCKkxl3qaMRUBZ5V1 llcHAaQ40lxP+uXQWALkmB0HGplhECYHWADDQ24oJYAVClHilwCgRMVSXiYGhgIZG/TZZxlXaNTD F2X4+adxA+Fg0wBkEGTfACkQhNgAKzR0iop0MvQdgHZu5EdgXw0AYUE2UViQhQKkVdAcQZYSAA9D GP/xxQ4B1KHRFg1h4OYYDzHiJowBDKgiSZXlSZAGeYVFEJhiDnRHXnoM5EOXxO7HmQMGdRJkRtj5 txmwMqoRWBZPplftuXEkxIUJBj2CxUJSVPkGi5sOAO5UA6hqJCql2sVKEBilcRCyAxhQB0GFqEet X3IglAhJlxzEAwPoaSaABV+S1VAmQ+RlREOTBHkGkySXbPLJKKes8sosC6TJllCS9JshC8NsbSUB eFAzZ244FIpSNfrRxADsGoRKQS/ETCWWIShspSMBUGyteu82dGOzCr3AR0EyaESFQU4OAJdDcBC7 SEJjuJmuQTzg+0SSNmG7ECuQDZBAQUlo9AlBg2D/BMVDm2wpQA4KOUISJ53mpa9DJVRmLkZcUgv1 QDRjRMNAI2SUmkAzYDSEcw3xMVcEmj7VqUblPSRGRl2ooMIKK6hAh0Y/kMBC7K9PkBceBeGwUaUB gLKRc/xqZIpD7vkFR0Obwna6AGiAqlEhBY1iUxIG5YFRtAZh1IYOAh090AIY9cRQAUBALsBRzM91 734CICDEAvQvoMAQGNBaELICKDvQ1Wa5kEBi4IJGNMITmTCgAhvhgg8o5QsvMKALcHaQSKRHAAro SlO+ZafHQQ5mAuhDg8AiFo0VBAQCDAAIMWWuKlWGKQZJg5vg5C2/vI92LujKKna4CtAdRAwa8QIL 7YY4xLPErwREHGIVMMI7km0nL4CgjovsdboBiNAumbPYsKpkLUQZRAZ5+dtAOrEAAXwtITjgkiey U68bDiB1RSKARo4QmEOkR3wDOUNlMnCQQrgJPvQyHV+KUCwkAfAhYMjLD4RyECxUJhEESeRmBCAB mMCkBAlpnhsHwAQPWHIifWCQ1UzIEFAEqQsLwQEQ8gIBgWiBS0qbI0JeMJcaHGQV04plXr6kEbkp hBVTEkAPjtcQOWSEVwGQxBw+wMxmOvOZHxiEQnIAgj1o8JZ/gKY2SeDDhejgDW1YnEI+AUm7fIKR LUunOtfJThYFBAA7 --=====_002_next===== Content-Type: image/jpeg; name="=?UTF-8?B?OWFlM2UyMTRjMTdkNDllZDkzNWQ4N2M2NzRiYTNlZTIuanBn?=" Content-Disposition: inline; filename="=?UTF-8?B?OWFlM2UyMTRjMTdkNDllZDkzNWQ4N2M2NzRiYTNlZTIuanBn?=" Content-Transfer-Encoding: base64 Content-ID: <9ae3e214c17d49ed935d87c674ba3ee2> R0lGODlhggB4AHcAACH/C05FVFNDQVBFMi4wAwEAAAAh+QQICgAAACwAAAAAggB4AIcATr79vg2j x+twuSDo8tdNjNSk0mTQ57AojVB4uI7+1GPI3/P+6rKPxan9yjsBes4/gtD+34y61u9jm9rr9vva 7Pek0aolccv///8Baccki9Sj0FwSfM6DtOOAv2Wy1e9Mo92axurf78n9xisLacf+2XNwpN33+vE7 m9r9zkv+89Q0jNWMvebh7/nL5KPR5vbC3vP+5Jxks+NbpN10u+UDg9Gqzuyi0YLx9+aTvuYkhNF/ wDbZ7L0cjNQAdccAZMUlkta73Y0Ybsn+z1CUyk5LnNpiqd88k9f9whz+3YNNqt9EnNr0+/18vOaF weczm9oBjNQae879xzK426PV7fjc8vqIxCek0u79zEP+5qR8r+Cd0u5ss+O84vT+8Mlbqd8Le87M 6fdTnNrl8dMrg9G22e8BXcMKdMsrdcyUyuuMy+xtqd+s1vAsktb+9t3+1muy2Hqs1XTt+f1xsdvE 4/X9012BwQ3u9uIwjelDkteKxTTW6rr+23tTo939xCNEo91ro92DvPd7wOcchNKEwoQ8jNRtvOZN ltg8o90sm9qIvui02YOm0/kri9QLgM/m+f1dseIUg9EMjNQOZsZUqd8NW8I0k9cSdMv+4ZObzOwk fM/H6ff+6Ku24PN1wunV8frz+esyhNHN5quDvOZcnNrU6vczeM2bzVpxr+y/35R7viO73PLb7cOn 0mz++OTE4Z2s2vHj8/oSbsphpN6TyTwAbMmU0O6r05rb7vn9wRTN7PlDi9Ti8M1Dltj+7LvT6LRK ktaTxene+Pw3od2EyetbrOHL5fV0reAse86d2PF6vSlzteMCk9am2PEtldigz/Eckdaz1/Gt1IW6 3IRjreGz3PkBVMBNseEzltg8mOH9yC9sreFVrOBSltgcdMs9ltgkldmKwOdhueUeftAAddCMw+mB v+kNbcnn89ir0+6jzex6tOP90E/q9NyVyPBEqd7R56+k0nH9yTSz2/ILftB8w+mAvyP92G390VQK hNEBdMuEw+kAfdARftD+/v7///8I/wAxCBxIsKDBgwgTKlzIsKHDhxAJMimHAgaGckvoYNgHgg6T JktKMaFRpBSGZSBKyeECogIFLn1iYeDyxSW1LxRiFeMmh8kXarGq9KHGBNdPDLH6cImFC8QyDC9A 0MBABUQTJsaWNMFAZ8koDFn3MemyJBiGVX/SYJiHItNaFFsiLkwH4goTarXSYZihjw2GPvrSyQFx xiMKfRaPgFkV69slY7Es0aOCoVEkY1UaaYpValAkCnIG6SjVeQUFY5E0FAXTBtcmDnmYrHrwhKu+ IhTmnenDJJ0+EBg+1OJ9pdY2DMH0ycCQptayibW+ZvozT67BJrW4gFXXgusVmXS+c/9NR+HslfKr 0slMT0E2GyZr2bRf9YEJkw/RBKaLZj/aKgwUpFNdb/MwIUc6FgX4HwVX/BcLgkhd0QVS6mgUiw3G YICLOhnickWGpahTwUw1uGXdWcGU8kIaGp3o4oswMsSEEpKsUkoT1UVUzAMmxujjjz5SoUMtsFzx ADVyZfLFf0A26eRDxswTxhrArGJME/lBSUd5T3YZC3xdFtSUDuowBSYT8zC5EBMgaGBRmE3OM0sw XMKJQRP6RAemQKvkg8KeCTExgyUt2hkjE1xY0wguhlLRiD5PbFJQVto1xMSXhv54BQo01NnlRA/w eJB9Db3gUaY/XiqHobGAoI8zlBn/REEzOSokxiVZogrjKtzs4+mTqP0gw6oGrXJJHgzRgEKhup6I aAYrjAhnUhr4dVApXJi1UE6ANisXBcXU0kascFYhUqDdHmTMKr96CxEFkOiTCLldzgPJFQnFkkmu CYnhDb+6VlFPPYw6RMEXPzRi0kNXGMKsQhQYYY0l7fKpzxEMdSDGw6iyUUsGejnERDBkzCKTQ1UU Ys1xlqpDilgIlbJNOO5CtMouBXQRS8UHUdAJvQvF8skxppQD0SbEvkhHNDzbyUQYYawyAw0nF8QE FfPYUh0uIaRT1BZX0FF1QVfMEIwuW4q8yhqZpCtQLGlYq9Af+nxQ80Cj/KAP1QRV/wELSJHoA4S+ ZuiAyyj6PIANNVvoAmgzGphxBNBBI+zM2AStoo8lDIHEcbPzAFHLA50KVMoMD+SpzyW94ALDEUux EMUZqrehzkDz9FALGII0fVAslECK+UAVcGH03RGFro8+acQixxWa/NDDH4bYIilSq8YCSz3XgHPG D7MwQUEYooPBN0SxcKMPIr43tG77mc7TRiQg9EJDGKNQM0/SCDGhiyfcSFMf3gGNSPROLunTxzCG 97Z9MaQIl5Ab8qgShmVUQgfGIJVAVBCDJCShBAp4Ax8w4QWB2IcC67CGBmBxLgSqLxEMxEAZZIGs hYyiDxmaoOmoYIxllKNOWVCAA//8II8I4CMXSPADEkZQB04MZBViaB4V3MYQnfzAEjGsQBN6FCj4 xa8NjdgfmHyhgBH4YQQjkEcS+CCPETjAAW1EAj5KiJRYUIMM++DfQ9jQh2BQEQN/JAgd2BDDgP1h dLDYIB+kQEQ4ysMBUsBHDCJQhwjEoAR1SGMWTHiEH0Qikdapgh77tg98LaQIZ7Ab8iayPBnIxBUx wAIS5IEFB9QhCW9QQAmScA985DIFSYhAEmMgEHVEIgMgqEJEmHCFOVFRc5xbCAtmkcO7GaMNtYCV QDiByzfIEguYiEEddukANyoRCxHIAj4CMIJNMgESZwCDWt7VB2tgg2e4WAcXdZj/EDnsI3H7EIg6 bRmDN+AjAkI8IxbQSMs68OGhJXBAABzgBq4AIQN/oJxCZKPPQDZkFeK5G/B+0BoMeCEFSpRHCdLJ h1yMAB/4wEIJMBnOOsgDH5gogTxu6YqZZOCTEYmFRgcSi2CETCGHAeXd2ACCeSbBD1gYgjzkoYAy yuMenKCkF2KQgqrKAwkO4IMHIzACJ9JBDFxQ5kN00gs1GWQetYimQpoAgmq6KxZhUCsGFIAEEQ7x jG/AxBvekAIHYKKMSXRAYV+ahSTkogRvo0IVPEoQWOgjAzA7SPGOx0+FLIMDAcWAG/CBBD5koQ4p wIcCJimPRmKBD5eEIxZSIA8p/2BCmCmoaFZK4hCd1CISbjUIZcEyDy++qCcCkQMFllsFQFSCNwLh KxYGiwlOvAGODsBCLUeggDXyAR+0dAA7kmDVEqphEqaIhnJBAx8DYaAKm5AJBfZRA31Q4o8tCIYp bSWL2xlDHYxhQgX2EwtMuYgOf5ABBeighCcg4gnFUMcHCoWJJNIyBQ+VrXa164BcpCALb3CjTOvw RnkwAAO6SEMImoCIPyBiGGlgQibqwgXQrmR5PajVQVZBQ48GgxppuFIPuNEJY2QCGyCYxxWkdaIQ mOEMpQiBLDKgD73JQBgFeQMStjzR645gwxzuawzwoQ3tFvaN2tgkIGFBBr3V4v8HRfgEKczQhyWY YRmxEIMZejDPhFRgFLdb03rDAIstUQAX89CZgU9kjBlw4TTUWEIfvoCCfPRCx67IAghDSFgzErG1 KvUFJ1Lw5Vpmt5ybjMUyNJCIGdS5CJmQgzrEIKFyZGgV4VjFcD+aCeO6aGeRxUUskuGIWoSWIK5I thtU4AVu4mMEKSjBG9aYhDoQccMOWKIvuDIkQzCFCrho72QBOZDhtqAc+03IEs4QXF3RQQP6qIdD VJBV8mIBqhHgQznTmIKuVnQVjyJGkzSHAob82CP20WCmuqCBB8j7ISpAqRTayAdOhLAE+BArJgQC i4YLHEi42GJvq0ByybrbEvr/EEdEMHHGwmJBtZY0aApOjAE15AMMcanZKtJQigL7XFe4KMIPnlBI hPAhsQ7QhmIXGgAFDEQGP9CBjmN0uEAjVR/tRhUT1iGLPvhaIK7ggxmnasYA5KIOPRXIMkhQBL36 aB76+AZDylGMFyAvDPuYkHWCiIWpyoMdmEi7QIxhiHT7CBfm2Gf/9rRrH9knFlfw2omanQUGVLTc Si66ixSeEBikQWck/8S4DRXyfYTjHOMIg5OoEApjN94hVWeIGM7RNjkERfM+ioUMaqGDYjQCBbgP KggeIIkkD/xYDEkDFxamq1hA4gG1QAFkwkCHguXeGB7SQcIM/6JYqOGo6HLX/zpqUYsn6F0dOgBB 8BlysEbgKxxgEJdSdcWGclgfVZCoBTb0zoRRUPkqMbIPD/ADT0EBTQAGP3AEqhcjpbAMfZYQvVAL bRMUogcjuJAGnrAP+1APnjCBTfB5W6B3g4cNv5UGo2cdbDAI4sIkBsgBS+B2LgJXbcAQmXAMdGB7 VVCBCNQE1OAh8RcqeRIFXZAJP8ABzEcQufMAPQAC+mMdq+AM+pAP6TYrSrYN3BcR52Z1mRIGZ2AG mUAHRxAFGjCGUZAHhIYMCogQ9SAJoVJ+n6MQuLAEP0A66SIHS2ANS/B6LhINmbB+MTMPxrANVYIB m5AMsDAPsNAMGcIEzdAFVP/UBT1QA8xQAw/AWQ5RAUPiSj0zCrvAAnooJoDGECiQFy7SFP2QBnLw CJ84EMbQcFBQAzWgLQ0RC11AB2lwPqPyCauYObWAMQuRBpSwP0FRBX7IBP+UAQD4IojCAanTB0e4 EOWwG7sYERWwDzm3EDhIcroAg3B4GM6wgDAyXwn2jBs1CpWwAn4II5yHEPPQhyfSJw43jcJFVJgi B2pFASRXBbhAB13QBegGdB/IEIcgCwDzEFvwADUwfz8SC/vwBG3QNk0ABAXCBeCQCE/wBIPAAU4g j8lzDrGxEJmwDCZhe6vyeO1BRSMzOlMXI1XADWCQAT9ADVUADNZQDrHQCHr/szx6Yw7eoi+qtCZ0 0AlNYAlcUItXUARfMA/NwI0CMQ+RoE1N0gSpowFGoGuZAAgekQkz8AWGQAM04I6dZRDpsA/zUAXp sAyZIFl0MAq2ljajQgfkCCMVMIpPAAsncykmVGCgMUqZggvLIIvq1hcmxHgeFQtbIBhNEgYaQIDu sgevMAagwAup8As4gAOvkApjcAJj4AINQA7ZQINNEJcNoQ4/cAlZ5yIvcWnNcgKsEAcGIAKgsAdx 8Art0A5BAAesAAqsMA23EAwF6SSrUADdYHdNUgVhEAxr8B7pQAMDUw800AQZpA7Q+SKg8Au/wAt7 wAongAGg0A53IBB30A6g/8Cd7YADDpEOihAGBqJcfJkQxNglcpAHACADVXAEZrA8efIDo1AKoWAG AbWLr0AEogARVPCXDLEEtYCKOagLuthbadBrT9J/efAd20AGbXChjRAK6oALgFAIWzAPowCOEJEK qTCeD6EbNaQQ6nA/gMSeD5EJu3Oa6khUdFCj/Kie7yVUnTQVETEGvIBAaQB+geIsaaAPNSBBubcF LEJZYYBNxRARd+ACY2AdyDUX4XB/EJEJD5APK3lcMpAP+jAIlsiOPaAPlfIQonAKIiAXFbANY3oQ h3AOppRwL7qlXeoiVzAI/AAFm2NXBoEL8RIJircQe5AK7SAXq+CRDPEBNP9Qlgt6giCJkHd6IvtA D5L4AGE0V3lCCV+HAeFpHQ8ioxKxni7qEM2hDwoJI/PgijXQAzKQCUwpKGagASL4EHeQmXCSCTTA ZBFBB70gBrx6KGkwCOujBBwQBYjgCVtglzUHAgA2CqnaEL+wCFMaEaXwBV+xECQopBChC0OljDRg CQ3SCBlQC/oQCZqwDlWAAgAwA+3ZEC4QB9UKEXAnVwlxBSyApQ9BBTRgk0+CV/DRBSShA9DXdplA CuowjWPAAyaKPg7UEPZIjEHxrgWRCWZQC2/SJPi4J1ijBp6QI6pInQ3bJekwCl2Qg6JHBesHA2Iw A6L5IqNQCFr4JLzwCyP/6xAywwIMEYES9HrC8Ahdsg7IEAJ28gqtMK8PsQpnkKL3SjAncjh08q9U 0KkRcQBBcKhBdQWTKhEuAqOL8SSHxpEL0Q5I+y6UdQU0cIPD6IdFWgNbS6ng8Ax2wgoEYB3Xmq0K cQgkUHsk54dayqVPQgP54A5wkgpxgLXJcwa94FHpEAz66hB/+7Zy0Q434AFTcLM/0g6t8AonQgET 5jRpsKXV0CRjcApWYAWqEAeYS53YqZ2Gonzf+ou14AMWwAPfiQ6ikJu6eQDtcAJ3cAC5yZoHMKV3 8At7gAOgMAa/YAD2oAdEMAA7AA/tIAqQ+bt7MJ4iMLyeygPHiwFjIAo//xqblIkBv7ABQfCdLlIK lLAVC4GgtXd7+4oKcyANuBmbrXC17ZAKrZCbrHC/Y3AHrxAHooADrAAH1Dq9cKAHVkALp7ADypAK PNAKv9AOBTwNvADAAnwHIrAIi3DBomAALnCrixAHF2y1ZYuoDyB3CzEP5aC2OciU/RQLY8AK33kH PMALJxCZNOyprMALoJC8rHCod8AKsHkC7SACcKAMqkALqrADv2DDvYsDIsALOKCZQXwCBFzE7cAD vQsKIsAKVby635IOomo1dPoQL3AM65CODNEO8aAKdmAFiyDGYfmLInkiFlsLZTy5hIAACUDHE/QC s4C3gfmb7sMNS/EkjP+AB4FQxwVhLMDAEPUnEnJAkhDxCWxsMLhAsRNEAYUmIxT4CZ+wjVAyFJns EDDwAVSbKcvFECGwfIPZeGmQAWcguaG0C8jwhhNkDH9wpgkRp4acfEZqy9+yDD3oyHyytAyxCltw yhgQuWGyXLiQDi9bMwtGnOznOplQlhRABftBclQEzXASDEJwDMjsEOUAZHRgCJJwDfNgi+CACGyw BY/LBG0brUASDWLgFsLWWcZQBE+xEIeRBgumNcRYCsuKC6XAM5lAZXusjF9iDIVgBKu8wpAgA7Y8 G9jAENEQDM6saniGKsYQCjixClzgIGLzXl1QHlVwgxqSNvsIHzGNFFv/gA2hsgLVwUOmcyphkEEU wAYP/Wtd4Di6wgRwiQE0kAFfwQJkcDssgAx20QRkIAEnQQZ2sw6hoGt3lCGjwIyvaKYUsA2FMCJ9 UAjGIAeksAt2N1zBsA3YDBHBEAUzUNEvYtIawQIaigE5AAFeMwpTjQFYbTcdAAGrIAfbEApcHQUP 8IoPsAxhPdZ7kQcvIAcTAAyk0QfrIJDnQNUQYSAsMAmNELuZEgu6UB4UcC54lT1ThBRELVTtVdPL YwnVQdoCUQWrLcoYsAChMAMM0Y4Su1zOY0LEcik5QQflUCFq0AznfCLzQAkB1BC5ocsEoS/FUAwy IAPFwAVhQAHlwAUt/zARXyAD3AAEPxAFxLzcDNgH7KsQbPAH8bc80HcOTaALmmAG6RAGoZCT+nAG 0ofeqAIDUVAEDFEMZ9AGKJAIFgkNzqAebbIl3KDgT0AJmfC4/h2hdCCiCAFSKpuPuDBuTPE2uCBs dF3hEVGlMiK2JO4kuDALBVDNAxEMRzCzKa5DcTgIfooQTcABDzjj/LQuw1UBZWniPF4zsVAOo9Cp HOqJQ343jgIG0r1jF9ANJbnkWkcHkJEGTsDG+lJcmTAKMlFgtX0y75mjYS4Q/cwEY37mai4TRVEe V1MecoALbj61gLTah2badm7n4QYg49bN8BG2SLHnHx7oGFABK/CCMP9CBYWABmEQCzMw14JiBAU2 C8eBC0rBBC3QB45dCkWQ2f+c2Zx+Ff/8FavgFVyxBOUgG73gFmywBEQ7D9/QNumQB3qRCb1wO+rw Dfhi6/8RDL2QH8GwBAVSDr3A1d9gEaOwBDDQf0UQbtvwDS/QAt0wAxT+EBSQCUaDC2QQCrHwCBBQ CKWACxBQAFgxCLFRCqZwCLFAB8gwAWfhDWLAFWgw16uABoCAAVfgDfcuARewDc9zAR2AASHgDZmt Dt5wFSFwAWYxCt6gszngDak+ChcgABhwDN5wO1pw8UxwDGjwHzPgDVRtAt7gNYBgCgvABGIwDv9h e00yFqdSo/ZRo4BJVIsC0QUZNBaqRwFdoHo4DyCdYBKxYCM+Txk+A/TzQBmxMA+MkvQyUQVKjxTz 0PRRTxU6oyGdIBNYsyphUFxUXx6lwPWusYsBAQA7 --=====_002_next=====-- --=====_001_next=====-- From nobody Mon Jul 12 07:46:34 2021 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB8C63A1AA5; Mon, 12 Jul 2021 07:46:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Lars Eggert via Datatracker To: "The IESG" Cc: draft-ietf-sfc-nsh-integrity@ietf.org, sfc-chairs@ietf.org, sfc@ietf.org, gregimirsky@gmail.com, gregimirsky@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Lars Eggert Message-ID: <162610118774.23532.4225033232156129750@ietfa.amsl.com> Date: Mon, 12 Jul 2021 07:46:27 -0700 Archived-At: Subject: [sfc] Lars Eggert's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 14:46:28 -0000 Lars Eggert has entered the following ballot position for draft-ietf-sfc-nsh-integrity-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1. , paragraph 6, comment: > This specification fills that gap. Concretely, this document adds > integrity protection and optional encryption of sensitive metadata > directly to the NSH (Section 4); integrity protects the packet > payload and provides replay protection (Section 7.4). Thus, the NSH > does not have to rely upon an underlying transport encapsulation for > security and confidentiality. Given that, I am surprised this document doesn't formally update RFC8300? Section 6. , paragraph 16, comment: > This timestamp format is affected by leap seconds. The timestamp > represents the number of seconds elapsed since the epoch minus the > number of leap seconds. Any particular reason why leap seconds are being excluded here? This is unusual and also requires care with synchronized clocks (as identified below). Found terminology that should be reviewed for inclusivity: * Term "master"; alternatives might be "active", "central", "initiator", "leader", "main", "orchestrator", "parent", "primary", "server". * Term "man"; alternatives might be "individual", "people", "person". See https://www.rfc-editor.org/part2/#inclusive_language for background and more guidance. ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. "SFC ", paragraph 2, nit: > Also, this specification allows to encrypt sensitive metadata that is carrie > ^^^^^^^^^^ Did you mean "encrypting"? Or maybe you should add a pronoun? In active voice, "allow" + "to" takes an object, usually a pronoun. Section 2. , paragraph 7, nit: > ng a service path. The NSH allows to share context information (a.k.a., metad > ^^^^^^^^ Did you mean "sharing"? Or maybe you should add a pronoun? In active voice, "allow" + "to" takes an object, usually a pronoun. Section 9. , paragraph 10, nit: > ts This document was edited as a follow up to the discussion in IETF#104: ht > ^^^^^^^^^ This noun is spelled as one word. From nobody Mon Jul 12 11:36:27 2021 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D063A0332; Mon, 12 Jul 2021 11:36:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Alvaro Retana via Datatracker To: "The IESG" Cc: draft-ietf-sfc-nsh-integrity@ietf.org, sfc-chairs@ietf.org, sfc@ietf.org, gregimirsky@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alvaro Retana Message-ID: <162611498183.7775.3562397379733537345@ietfa.amsl.com> Date: Mon, 12 Jul 2021 11:36:22 -0700 Archived-At: Subject: [sfc] Alvaro Retana's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 18:36:23 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-sfc-nsh-integrity-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) Given the required behavior specified in the Security Considerations section... NSH data are exposed to several threats: o A man-in-the-middle attacker modifying the NSH data. o Attacker spoofing the NSH data. o Attacker capturing and replaying the NSH data. o Data carried in Context Headers revealing privacy-sensitive information to attackers. o Attacker replacing the packet on which the NSH is imposed with a bogus packet. In an SFC-enabled domain where the above attacks are possible, (1) NSH data MUST be integrity-protected and replay-protected, and (2) privacy-sensitive NSH metadata MUST be encrypted for confidentiality preservation purposes. The Base and Service Path headers are not encrypted. Why doesn't this document formally update rfc8300? Concerns that eventually led to this solution have been expressed for several other documents, including rfc8459 and rfc8979. It looks like the WG didn't consider the question of Updating the base NSH specification. I believe that this document specifies a required update to NSH, and would like the WG to consider formally Updating rfc8300. [My search of the archive didn't find any related discussion -- did I miss it?] [Even though I consider this omission a serious oversight, I don't think this issue raises to the level of a DISCUSS.] (2) §3: I find the use of normative language to describe requirements (that are met in this same document) not the best use of rfc2119 language because any interoperability concerns would result from the specification itself and not the requirements. The use of rfc2119 keywords to describe requirements may result in confusion. For example, "The solution MAY provide integrity protection for the Base Header." -- as described later, protecting the Base Header is optional, but the solution *does* provide integrity protection for it. IOW, the specification is what is reflected in the requirement, but referring to the solution, not the protection: providing integrity protection is not optional, using it is. A better working would be: "The solution must provide optional integrity protection for the Base Header." From nobody Mon Jul 12 11:52:45 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C0A3A1034; Mon, 12 Jul 2021 11:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGTgDbba1lCd; Mon, 12 Jul 2021 11:52:29 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (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 761DA3A0E5B; Mon, 12 Jul 2021 11:52:24 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr24.francetelecom.fr (ESMTP service) with ESMTPS id 4GNtDQ04pyz1yNb; Mon, 12 Jul 2021 20:52:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1626115942; bh=fAESZK3cNMThXh+GguEMy6VQUNWvwdUe8MQ5YQeL4H4=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=WML+lK0iAqf0qDwwwr5qpxbI/HBWHcp5R6dwDd05dPV71zKvy6BsBEj4ujlpJdNNg rRrRm6XzRbgg74xw8YF+o/9l8qoI8w40SaHvWzt09eY2NG1KcLLs9KMMnTEHA1iMfD zEj7zFKa522j9EC0QF+Hya+OvIu5SkTgoi8aTfWNU+nBk7zOnnaFTeTn61CMlTW+eh U3jCXx+RqQyLU3Kbgf/cqQIbYtvUBzWFr7Ru0EbRsXk2Iziwt5OidA5bCQrZ5M358I e17oBGVcYINuMaOYdo3W7SjWo5fIjtTH2dHGpgxZpzuXrfaFz5jbYSs9mqBVLYzCA6 Y2gGj3LJlqEqA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfednr05.francetelecom.fr (ESMTP service) with ESMTPS id 4GNtDP5lQxzyQ3; Mon, 12 Jul 2021 20:52:21 +0200 (CEST) From: To: Alvaro Retana , The IESG CC: "draft-ietf-sfc-nsh-integrity@ietf.org" , "sfc-chairs@ietf.org" , "sfc@ietf.org" , "gregimirsky@gmail.com" Thread-Topic: Alvaro Retana's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) Thread-Index: AQHXd0zRVHfyNHLhwkyOd3irdChUIqs/rJuQ Date: Mon, 12 Jul 2021 18:52:20 +0000 Message-ID: <23837_1626115941_60EC8F65_23837_478_1_787AE7BB302AE849A7480A190F8B9330353BD8C2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162611498183.7775.3562397379733537345@ietfa.amsl.com> In-Reply-To: <162611498183.7775.3562397379733537345@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Alvaro Retana's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 18:52:39 -0000 SGkgQWx2YXJvLCANCg0KVGhhbmsgeW91IGZvciB0aGUgcmV2aWV3LiANCg0KUGxlYXNlIHNlZSBp bmxpbmUuIA0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0N Cj4gRGXCoDogQWx2YXJvIFJldGFuYSB2aWEgRGF0YXRyYWNrZXIgW21haWx0bzpub3JlcGx5QGll dGYub3JnXQ0KPiBFbnZvecOpwqA6IGx1bmRpIDEyIGp1aWxsZXQgMjAyMSAyMDozNg0KPiDDgMKg OiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCj4gQ2PCoDogZHJhZnQtaWV0Zi1zZmMtbnNoLWlu dGVncml0eUBpZXRmLm9yZzsgc2ZjLWNoYWlyc0BpZXRmLm9yZzsNCj4gc2ZjQGlldGYub3JnOyBn cmVnaW1pcnNreUBnbWFpbC5jb20NCj4gT2JqZXTCoDogQWx2YXJvIFJldGFuYSdzIE5vIE9iamVj dGlvbiBvbiBkcmFmdC1pZXRmLXNmYy1uc2gtDQo+IGludGVncml0eS0wNjogKHdpdGggQ09NTUVO VCkNCj4gDQo+IEFsdmFybyBSZXRhbmEgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3Qg cG9zaXRpb24gZm9yDQo+IGRyYWZ0LWlldGYtc2ZjLW5zaC1pbnRlZ3JpdHktMDY6IE5vIE9iamVj dGlvbg0KPiANCj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5l IGludGFjdCBhbmQgcmVwbHkgdG8NCj4gYWxsIGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0 aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvDQo+IGN1dCB0aGlzIGludHJvZHVjdG9y eSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiANCj4gDQo+IFBsZWFzZSByZWZlciB0byBodHRwczov L3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLQ0KPiBjcml0ZXJpYS5odG1sDQo+ IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25z Lg0KPiANCj4gDQo+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRp b25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1zZmMtbnNoLWludGVncml0eS8NCj4gDQo+IA0KPiANCj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4gLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0NCj4gDQo+IA0KPiAoMSkg R2l2ZW4gdGhlIHJlcXVpcmVkIGJlaGF2aW9yIHNwZWNpZmllZCBpbiB0aGUgU2VjdXJpdHkNCj4g Q29uc2lkZXJhdGlvbnMgc2VjdGlvbi4uLg0KPiANCj4gICAgTlNIIGRhdGEgYXJlIGV4cG9zZWQg dG8gc2V2ZXJhbCB0aHJlYXRzOg0KPiANCj4gICAgbyAgQSBtYW4taW4tdGhlLW1pZGRsZSBhdHRh Y2tlciBtb2RpZnlpbmcgdGhlIE5TSCBkYXRhLg0KPiANCj4gICAgbyAgQXR0YWNrZXIgc3Bvb2Zp bmcgdGhlIE5TSCBkYXRhLg0KPiANCj4gICAgbyAgQXR0YWNrZXIgY2FwdHVyaW5nIGFuZCByZXBs YXlpbmcgdGhlIE5TSCBkYXRhLg0KPiANCj4gICAgbyAgRGF0YSBjYXJyaWVkIGluIENvbnRleHQg SGVhZGVycyByZXZlYWxpbmcgcHJpdmFjeS1zZW5zaXRpdmUNCj4gICAgICAgaW5mb3JtYXRpb24g dG8gYXR0YWNrZXJzLg0KPiANCj4gICAgbyAgQXR0YWNrZXIgcmVwbGFjaW5nIHRoZSBwYWNrZXQg b24gd2hpY2ggdGhlIE5TSCBpcyBpbXBvc2VkIHdpdGgNCj4gYQ0KPiAgICAgICBib2d1cyBwYWNr ZXQuDQo+IA0KPiAgICBJbiBhbiBTRkMtZW5hYmxlZCBkb21haW4gd2hlcmUgdGhlIGFib3ZlIGF0 dGFja3MgYXJlIHBvc3NpYmxlLA0KPiAoMSkNCj4gICAgTlNIIGRhdGEgTVVTVCBiZSBpbnRlZ3Jp dHktcHJvdGVjdGVkIGFuZCByZXBsYXktcHJvdGVjdGVkLCBhbmQNCj4gKDIpDQo+ICAgIHByaXZh Y3ktc2Vuc2l0aXZlIE5TSCBtZXRhZGF0YSBNVVNUIGJlIGVuY3J5cHRlZCBmb3INCj4gY29uZmlk ZW50aWFsaXR5DQo+ICAgIHByZXNlcnZhdGlvbiBwdXJwb3Nlcy4gIFRoZSBCYXNlIGFuZCBTZXJ2 aWNlIFBhdGggaGVhZGVycyBhcmUgbm90DQo+ICAgIGVuY3J5cHRlZC4NCj4gDQo+IFdoeSBkb2Vz bid0IHRoaXMgZG9jdW1lbnQgZm9ybWFsbHkgdXBkYXRlIHJmYzgzMDA/ICBDb25jZXJucyB0aGF0 DQo+IGV2ZW50dWFsbHkgbGVkIHRvIHRoaXMgc29sdXRpb24gaGF2ZSBiZWVuIGV4cHJlc3NlZCBm b3Igc2V2ZXJhbA0KPiBvdGhlciBkb2N1bWVudHMsIGluY2x1ZGluZw0KPiByZmM4NDU5IGFuZCBy ZmM4OTc5Lg0KPiANCj4gSXQgbG9va3MgbGlrZSB0aGUgV0cgZGlkbid0IGNvbnNpZGVyIHRoZSBx dWVzdGlvbiBvZiBVcGRhdGluZyB0aGUNCj4gYmFzZSBOU0ggc3BlY2lmaWNhdGlvbi4gIEkgYmVs aWV2ZSB0aGF0IHRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGENCj4gcmVxdWlyZWQgdXBkYXRlIHRv IE5TSCwgYW5kIHdvdWxkIGxpa2UgdGhlIFdHIHRvIGNvbnNpZGVyIGZvcm1hbGx5DQo+IFVwZGF0 aW5nIHJmYzgzMDAuICBbTXkgc2VhcmNoIG9mIHRoZSBhcmNoaXZlIGRpZG4ndCBmaW5kIGFueSBy ZWxhdGVkDQo+IGRpc2N1c3Npb24gLS0gZGlkIEkgbWlzcyBpdD9dDQoNCltNZWRdIFdlIGRvbid0 IHVzZSB0aGUgdXBkYXRlIGhlYWRlciBhcyB3ZSBkb24ndCBmb3JtYWxseSB1cGRhdGUgYW55IHRl eHQgaW4gODMwMC4gSSBrbm93IHRoYXQgd2UgY2FuIGludGVycHJldCB0aGUgdXBkYXRlIGFzICJh bWVuZHMiLCBidXQgdW5sZXNzIEknbSBtaXN0YWtlbiB0aGVyZSBpcyBubyBmb3JtYWwgSUVURiBj b25zZW5zdXMgb24gdGhpcy4gDQoNCj4gDQo+IFtFdmVuIHRob3VnaCBJIGNvbnNpZGVyIHRoaXMg b21pc3Npb24gYSBzZXJpb3VzIG92ZXJzaWdodCwgSSBkb24ndA0KPiB0aGluayB0aGlzIGlzc3Vl IHJhaXNlcyB0byB0aGUgbGV2ZWwgb2YgYSBESVNDVVNTLl0NCj4gDQo+ICgyKSDCpzM6IEkgZmlu ZCB0aGUgdXNlIG9mIG5vcm1hdGl2ZSBsYW5ndWFnZSB0byBkZXNjcmliZQ0KPiByZXF1aXJlbWVu dHMgKHRoYXQgYXJlIG1ldCBpbiB0aGlzIHNhbWUgZG9jdW1lbnQpIG5vdCB0aGUgYmVzdCB1c2UN Cj4gb2YgcmZjMjExOSBsYW5ndWFnZSBiZWNhdXNlIGFueSBpbnRlcm9wZXJhYmlsaXR5IGNvbmNl cm5zIHdvdWxkDQo+IHJlc3VsdCBmcm9tIHRoZSBzcGVjaWZpY2F0aW9uIGl0c2VsZiBhbmQgbm90 IHRoZSByZXF1aXJlbWVudHMuDQo+IA0KPiBUaGUgdXNlIG9mIHJmYzIxMTkga2V5d29yZHMgdG8g ZGVzY3JpYmUgcmVxdWlyZW1lbnRzIG1heSByZXN1bHQgaW4NCj4gY29uZnVzaW9uLg0KPiBGb3Ig ZXhhbXBsZSwgIlRoZSBzb2x1dGlvbiBNQVkgcHJvdmlkZSBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBm b3IgdGhlDQo+IEJhc2UgSGVhZGVyLiIgLS0gYXMgZGVzY3JpYmVkIGxhdGVyLCBwcm90ZWN0aW5n IHRoZSBCYXNlIEhlYWRlciBpcw0KPiBvcHRpb25hbCwgYnV0IHRoZSBzb2x1dGlvbiAqZG9lcyog cHJvdmlkZSBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBmb3INCj4gaXQuICBJT1csIHRoZSBzcGVjaWZp Y2F0aW9uIGlzIHdoYXQgaXMgcmVmbGVjdGVkIGluIHRoZSByZXF1aXJlbWVudCwNCj4gYnV0IHJl ZmVycmluZyB0byB0aGUgc29sdXRpb24sIG5vdCB0aGUNCj4gcHJvdGVjdGlvbjogcHJvdmlkaW5n IGludGVncml0eSBwcm90ZWN0aW9uIGlzIG5vdCBvcHRpb25hbCwgdXNpbmcgaXQNCj4gaXMuICBB IGJldHRlciB3b3JraW5nIHdvdWxkIGJlOiAiVGhlIHNvbHV0aW9uIG11c3QgcHJvdmlkZSBvcHRp b25hbA0KPiBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBmb3IgdGhlIEJhc2UgSGVhZGVyLiINCg0KW01l ZF0gR29vZCBwb2ludC4gRml4ZWQuIFRoYW5rcy4NCg0KCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQg c2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25m aWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBk aWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBh dmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwn ZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBM ZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9u LApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRl IGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0 cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZv cm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUg ZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWls cyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQg aGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Mon Jul 12 12:04:31 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD023A1082; Mon, 12 Jul 2021 12:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6opVjQI_fEJR; Mon, 12 Jul 2021 12:04:24 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (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 1E4563A17F1; Mon, 12 Jul 2021 12:02:32 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr25.francetelecom.fr (ESMTP service) with ESMTPS id 4GNtS62tclzCr5S; Mon, 12 Jul 2021 21:02:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1626116550; bh=BW5moahu3aNbV6yCsF8XsKuoCK98Rm1U8OHINgytSQc=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=If5YN8Tu5Jpm2EAOZ/aFaJJ9UKtCrxhjaBayYjY0SB4hoi1iLQCkoIweyIirM68Gx Hq7D/HOoT3UveVXqnPxi11HW+3jNAOt0ABS9ylnqtWULkBN4Bo2htnY/JtLa+AFs/V F8L+YQ4Wst0jNXjAP3oTP06yich/zavYZc7FveHCNhxZ0syjekuSGHvVT0Qs7d9ZYQ DcKdMUrZkFywasKT80f6hMBK4nPMf67294R8l1PVmwaJgD6a/WyMbC9eMlCkQohK72 N1Uq2lrtDwBwJteJ6CAleRNNlg9HhGOGhwjAsKOT1tbED0g4gqO6RzFoCCJJ8K9yxE NBZPDv+3MVhzg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfednr07.francetelecom.fr (ESMTP service) with ESMTPS id 4GNtS6248zzFpWX; Mon, 12 Jul 2021 21:02:30 +0200 (CEST) From: To: Lars Eggert , The IESG CC: "draft-ietf-sfc-nsh-integrity@ietf.org" , "sfc-chairs@ietf.org" , "sfc@ietf.org" , "gregimirsky@gmail.com" Thread-Topic: Lars Eggert's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) Thread-Index: AQHXdyy02AmcqC8DpUGKm7cOgjGdDqs/cXBg Date: Mon, 12 Jul 2021 19:02:28 +0000 Message-ID: <5351_1626116550_60EC91C6_5351_270_1_787AE7BB302AE849A7480A190F8B9330353BD911@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162610118774.23532.4225033232156129750@ietfa.amsl.com> In-Reply-To: <162610118774.23532.4225033232156129750@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Lars Eggert's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 19:04:30 -0000 SGkgTGFycywNCg0KVGhhbmsgeW91IGZvciB0aGUgcmV2aWV3LiANCg0KUGxlYXNlIHNlZSBpbmxp bmUuDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBE ZcKgOiBMYXJzIEVnZ2VydCB2aWEgRGF0YXRyYWNrZXIgW21haWx0bzpub3JlcGx5QGlldGYub3Jn XQ0KPiBFbnZvecOpwqA6IGx1bmRpIDEyIGp1aWxsZXQgMjAyMSAxNjo0Ng0KPiDDgMKgOiBUaGUg SUVTRyA8aWVzZ0BpZXRmLm9yZz4NCj4gQ2PCoDogZHJhZnQtaWV0Zi1zZmMtbnNoLWludGVncml0 eUBpZXRmLm9yZzsgc2ZjLWNoYWlyc0BpZXRmLm9yZzsNCj4gc2ZjQGlldGYub3JnOyBncmVnaW1p cnNreUBnbWFpbC5jb207IGdyZWdpbWlyc2t5QGdtYWlsLmNvbQ0KPiBPYmpldMKgOiBMYXJzIEVn Z2VydCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLXNmYy1uc2gtaW50ZWdyaXR5LQ0KPiAw NjogKHdpdGggQ09NTUVOVCkNCj4gDQo+IExhcnMgRWdnZXJ0IGhhcyBlbnRlcmVkIHRoZSBmb2xs b3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiBkcmFmdC1pZXRmLXNmYy1uc2gtaW50ZWdyaXR5 LTA2OiBObyBPYmplY3Rpb24NCj4gDQo+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhl IHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvDQo+IGFsbCBlbWFpbCBhZGRyZXNzZXMg aW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0bw0KPiBjdXQgdGhp cyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4gDQo+IA0KPiBQbGVhc2UgcmVm ZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy0NCj4gY3Jp dGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBESVNDVVNTIGFuZCBDT01N RU5UIHBvc2l0aW9ucy4NCj4gDQo+IA0KPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIg YmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2ZjLW5zaC1pbnRlZ3JpdHkvDQo+IA0KPiANCj4g DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+IC0tDQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tDQo+ IA0KPiBTZWN0aW9uIDEuICwgcGFyYWdyYXBoIDYsIGNvbW1lbnQ6DQo+ID4gICAgVGhpcyBzcGVj aWZpY2F0aW9uIGZpbGxzIHRoYXQgZ2FwLiAgQ29uY3JldGVseSwgdGhpcyBkb2N1bWVudA0KPiBh ZGRzDQo+ID4gICAgaW50ZWdyaXR5IHByb3RlY3Rpb24gYW5kIG9wdGlvbmFsIGVuY3J5cHRpb24g b2Ygc2Vuc2l0aXZlDQo+IG1ldGFkYXRhDQo+ID4gICAgZGlyZWN0bHkgdG8gdGhlIE5TSCAoU2Vj dGlvbiA0KTsgaW50ZWdyaXR5IHByb3RlY3RzIHRoZSBwYWNrZXQNCj4gPiAgICBwYXlsb2FkIGFu ZCBwcm92aWRlcyByZXBsYXkgcHJvdGVjdGlvbiAoU2VjdGlvbiA3LjQpLiAgVGh1cywNCj4gdGhl IE5TSA0KPiA+ICAgIGRvZXMgbm90IGhhdmUgdG8gcmVseSB1cG9uIGFuIHVuZGVybHlpbmcgdHJh bnNwb3J0DQo+IGVuY2Fwc3VsYXRpb24gZm9yDQo+ID4gICAgc2VjdXJpdHkgYW5kIGNvbmZpZGVu dGlhbGl0eS4NCj4gDQo+IEdpdmVuIHRoYXQsIEkgYW0gc3VycHJpc2VkIHRoaXMgZG9jdW1lbnQg ZG9lc24ndCBmb3JtYWxseSB1cGRhdGUNCj4gUkZDODMwMD8NCg0KW01lZF0gQWx2YXJvIHJhaXNl ZCBhIHNpbWlsYXIgY29tbWVudC4gTm90IHJlaXRlcmF0aW5nIHRoZSBzYW1lIGFuc3dlciBoZXJl LiAgDQoNCj4gDQo+IFNlY3Rpb24gNi4gLCBwYXJhZ3JhcGggMTYsIGNvbW1lbnQ6DQo+ID4gICAg ICAgVGhpcyB0aW1lc3RhbXAgZm9ybWF0IGlzIGFmZmVjdGVkIGJ5IGxlYXAgc2Vjb25kcy4gIFRo ZQ0KPiB0aW1lc3RhbXANCj4gPiAgICAgICByZXByZXNlbnRzIHRoZSBudW1iZXIgb2Ygc2Vjb25k cyBlbGFwc2VkIHNpbmNlIHRoZSBlcG9jaA0KPiBtaW51cyB0aGUNCj4gPiAgICAgICBudW1iZXIg b2YgbGVhcCBzZWNvbmRzLg0KPiANCj4gQW55IHBhcnRpY3VsYXIgcmVhc29uIHdoeSBsZWFwIHNl Y29uZHMgYXJlIGJlaW5nIGV4Y2x1ZGVkIGhlcmU/IFRoaXMNCj4gaXMgdW51c3VhbCBhbmQgYWxz byByZXF1aXJlcyBjYXJlIHdpdGggc3luY2hyb25pemVkIGNsb2NrcyAoYXMNCj4gaWRlbnRpZmll ZCBiZWxvdykuDQoNCltNZWRdIFdlIGFyZSBmb2xsb3dpbmcgdGhlIGd1aWRlbGluZXMgaW4gU2Vj dGlvbiA0LjIuMSBvZiBSRkM4ODc3IChVc2luZyBhIFJlY29tbWVuZGVkIFRpbWVzdGFtcCBGb3Jt YXQpLiANCg0KPiANCj4gRm91bmQgdGVybWlub2xvZ3kgdGhhdCBzaG91bGQgYmUgcmV2aWV3ZWQg Zm9yIGluY2x1c2l2aXR5Og0KPiAgKiBUZXJtICJtYXN0ZXIiOyBhbHRlcm5hdGl2ZXMgbWlnaHQg YmUgImFjdGl2ZSIsICJjZW50cmFsIiwNCj4gImluaXRpYXRvciIsDQoNCltNZWRdIE5vdCBzdXJl IHdoYXQgaXMgcHJvYmxlbWF0aWMgaW4gc2F5aW5nICIuLi4gbWFzdGVyIHRoZWlyIGNvbXBsZXhp dHkgLi4iDQoNCj4gICAgImxlYWRlciIsICJtYWluIiwgIm9yY2hlc3RyYXRvciIsICJwYXJlbnQi LCAicHJpbWFyeSIsICJzZXJ2ZXIiLg0KPiAgKiBUZXJtICJtYW4iOyBhbHRlcm5hdGl2ZXMgbWln aHQgYmUgImluZGl2aWR1YWwiLCAicGVvcGxlIiwNCj4gInBlcnNvbiIuDQoNCltNZWRdIE1hZGUg dGhpcyBjaGFuZ2U6IHMvQSBtYW4taW4tdGhlLW1pZGRsZSBhdHRhY2tlci9BbiBvbi1wYXRoIGF0 dGFja2VyLiBUaGFua3MuDQoNCj4gU2VlIGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3BhcnQy LyNpbmNsdXNpdmVfbGFuZ3VhZ2UgZm9yDQo+IGJhY2tncm91bmQgYW5kIG1vcmUgZ3VpZGFuY2Uu DQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLS0tLS0tLS0tLQ0KPiBBbGwgY29tbWVudHMgYmVsb3cg YXJlIGFib3V0IHZlcnkgbWlub3IgcG90ZW50aWFsIGlzc3VlcyB0aGF0IHlvdQ0KDQpbTWVkXSBB bGwgZ29vZCBvbmVzLiBGaXhlZC4gVGhhbmsgeW91LiANCg0KCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2Ug ZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBj b25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRy ZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91 cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgph IGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVz LiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0 aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEg ZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5k IGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBp bmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3Qg YmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVt YWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRo YXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Mon Jul 12 12:23:38 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 028893A1229; Mon, 12 Jul 2021 12:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 4RIKnYn6Om24; Mon, 12 Jul 2021 12:23:28 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 350C53A11D1; Mon, 12 Jul 2021 12:23:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4GNtwH6cHSz1ntHm; Mon, 12 Jul 2021 12:23:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1626117807; bh=WAoV8gKEeeXrsP4zs/ohZ/fiHHo3jfdwrzoJRl+N1vs=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=o+qUKS6YOCFlHoRTSVe/jjaa7t+gs90ksXQ3UvTmHEvdUGZrglf3Ln1AZK2I1kx1E ePwLkjstys1pFPDGfILEpl9/hMjzMpXVOM+O83suzuuJ5d+6hfbi5YbsdB/r45c+ji FyDRc9aWGjRmtnBDrjzt8yIZGqLjkAQv8Tynrqno= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4GNtwH1BnXz1ntRq; Mon, 12 Jul 2021 12:23:27 -0700 (PDT) To: Alvaro Retana , The IESG Cc: gregimirsky@gmail.com, draft-ietf-sfc-nsh-integrity@ietf.org, sfc@ietf.org References: <162611498183.7775.3562397379733537345@ietfa.amsl.com> From: "Joel M. Halpern" Message-ID: Date: Mon, 12 Jul 2021 15:23:25 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <162611498183.7775.3562397379733537345@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] Alvaro Retana's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 19:23:34 -0000 I find your description of this as a "required update to 8300" rather odd. The working group did not agree to make implementation of this mandatory for 8300. That would, indeed, be an update to 8300. This is just another feature that can be used with NSH. A useful feature. The security considerations do give lots of reasons to do this. But that is not the same as making it "required" for all implementations of 8300. Yours, Joel On 7/12/2021 2:36 PM, Alvaro Retana via Datatracker wrote: > Alvaro Retana has entered the following ballot position for > draft-ietf-sfc-nsh-integrity-06: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > (1) Given the required behavior specified in the Security Considerations > section... > > NSH data are exposed to several threats: > > o A man-in-the-middle attacker modifying the NSH data. > > o Attacker spoofing the NSH data. > > o Attacker capturing and replaying the NSH data. > > o Data carried in Context Headers revealing privacy-sensitive > information to attackers. > > o Attacker replacing the packet on which the NSH is imposed with a > bogus packet. > > In an SFC-enabled domain where the above attacks are possible, (1) > NSH data MUST be integrity-protected and replay-protected, and (2) > privacy-sensitive NSH metadata MUST be encrypted for confidentiality > preservation purposes. The Base and Service Path headers are not > encrypted. > > Why doesn't this document formally update rfc8300? Concerns that eventually > led to this solution have been expressed for several other documents, including > rfc8459 and rfc8979. > > It looks like the WG didn't consider the question of Updating the base NSH > specification. I believe that this document specifies a required update to > NSH, and would like the WG to consider formally Updating rfc8300. [My search > of the archive didn't find any related discussion -- did I miss it?] > > [Even though I consider this omission a serious oversight, I don't think this > issue raises to the level of a DISCUSS.] > > (2) §3: I find the use of normative language to describe requirements (that are > met in this same document) not the best use of rfc2119 language because any > interoperability concerns would result from the specification itself and not > the requirements. > > The use of rfc2119 keywords to describe requirements may result in confusion. > For example, "The solution MAY provide integrity protection for the Base > Header." -- as described later, protecting the Base Header is optional, but the > solution *does* provide integrity protection for it. IOW, the specification is > what is reflected in the requirement, but referring to the solution, not the > protection: providing integrity protection is not optional, using it is. A > better working would be: "The solution must provide optional integrity > protection for the Base Header." > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Mon Jul 12 12:26:57 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F873A120C; Mon, 12 Jul 2021 12:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4NHJzXnFeXy; Mon, 12 Jul 2021 12:26:50 -0700 (PDT) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (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 B475B3A1209; Mon, 12 Jul 2021 12:26:49 -0700 (PDT) Received: by mail-ej1-x62f.google.com with SMTP id gn32so36774114ejc.2; Mon, 12 Jul 2021 12:26:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=zrAMwT95S/c2NlGaye7etfqCe1STk9CxdulPvIaJzCk=; b=m1bmppqxwX8mIJUarxUkEwF8XBgsTH69iIrwkv+RxMqFxWZ5dvULKfvmtXWsIQgnVk W4CDJjWa1OFKgng5e9STKzy5/EfXjnbHsYzfPatLcD1t3OCopN9dBsjzCrNzAr8pZB41 dZI8yHuKMIYGQdy8/lHXpNK6qefX32dLmHPtnKLGq7a28wHMjpOrMgoLixPIFJcgAHDV 42d8hmZoj/CU0uI/6+ppg6yNNXE0uhaUmWffXJc3LuV3qhJV/cNoMFggapdG/SDI6N97 95DLVIWZgQ91As/aZatD9vw0yvMD0hRsqnPeTK97qTHq4dfcMkxBcFLcnsK8uMOam1B3 Urdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=zrAMwT95S/c2NlGaye7etfqCe1STk9CxdulPvIaJzCk=; b=aJb/NF0bYxGxbEj7Ojfv7lv85heOS0JWo3fiWqMq8bmXklxfk0U8fI3by5icfb6283 8cJWqtry+oIignCtkTrzT7mc+Fgl7MgBF/8r85YC4imHOZN2xO7ESff8RjK7z+0mzRFN d/5RaqaOP2XYMyNJW08bFCrYtbNohmfwBQ644guLGY7AtVY3iX7VK6TuyHKUoKlTcgI8 qiC+5ik96Tr0aTBlpRALjjlP70Ydxqy2ZQqoelhHqiDwAtYOIJRZWFR3ELaHLyOd7GmB XBh5y5KRm/f7thWjk1bMl8rdtvfyatzz28Q8sLmjT3kTytDon4+aydLuDBXv4I9x7oj8 TSWA== X-Gm-Message-State: AOAM532YFy4dzRSjqxvewfv89unyAcDnhfU5sTjO0n3gb7li5CVYr+FY Z7IV0Yxu2vhput1c6S5GsU7+Lb2rkn5kmTXdEZI= X-Google-Smtp-Source: ABdhPJxg7KsSoDYFGmL17d1ytgAXxoHTckh6j0Hwpm87XGkIDbdMylI2Ud7EvbIduCmjWLhJu867zY9uBdLEjAufh90= X-Received: by 2002:a17:906:1cd5:: with SMTP id i21mr717232ejh.478.1626118006493; Mon, 12 Jul 2021 12:26:46 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 12 Jul 2021 12:26:45 -0700 From: Alvaro Retana In-Reply-To: <23837_1626115941_60EC8F65_23837_478_1_787AE7BB302AE849A7480A190F8B9330353BD8C2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162611498183.7775.3562397379733537345@ietfa.amsl.com> <23837_1626115941_60EC8F65_23837_478_1_787AE7BB302AE849A7480A190F8B9330353BD8C2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Date: Mon, 12 Jul 2021 12:26:45 -0700 Message-ID: To: mohamed.boucadair@orange.com, The IESG Cc: "draft-ietf-sfc-nsh-integrity@ietf.org" , "sfc-chairs@ietf.org" , "gregimirsky@gmail.com" , "sfc@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sfc] Alvaro Retana's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 19:26:56 -0000 On July 12, 2021 at 2:52:22 PM, mohamed.boucadair@orange.com wrote: Med: Hi! ... > > (1) Given the required behavior specified in the Security > > Considerations section... > > > > NSH data are exposed to several threats: > > > > o A man-in-the-middle attacker modifying the NSH data. > > > > o Attacker spoofing the NSH data. > > > > o Attacker capturing and replaying the NSH data. > > > > o Data carried in Context Headers revealing privacy-sensitive > > information to attackers. > > > > o Attacker replacing the packet on which the NSH is imposed with a > > bogus packet. > > > > In an SFC-enabled domain where the above attacks are possible, (1) > > NSH data MUST be integrity-protected and replay-protected, and (2) > > privacy-sensitive NSH metadata MUST be encrypted for confidentiality > > preservation purposes. The Base and Service Path headers are not > > encrypted. > > > > Why doesn't this document formally update rfc8300? Concerns that > > eventually led to this solution have been expressed for several other > > documents, including rfc8459 and rfc8979. > > > > It looks like the WG didn't consider the question of Updating the > > base NSH specification. I believe that this document specifies a > > required update to NSH, and would like the WG to consider formally > > Updating rfc8300. [My search of the archive didn't find any related > > discussion -- did I miss it?] > > [Med] We don't use the update header as we don't formally update any text > in 8300. Updating text is not the only reason to formally Update another specificati= on. This document requires the use of both integrity and encryption if specific attacks are possible (text above). =C2=A0It is reasonable to interpret that as cases where the "operator deems protection is required", which is the text that rfc8300 uses when it talks about the need for integrity protection (similar text can also be found about encryption). =C2=A0IOW, the formal Update that I'm suggesting here is to provide more insight into when integrity protection and encryption are required, and the mechanism to use. As I look into this further, I believe there is a normative inconsistency between this document and rfc8300: - rfc8300 requires the use of an encapsulating transport protocol that can provide integrity protection and/or encryption, as needed. - This document requires protection as specified in the text above. =C2=A0A stated goal of this specification is so that "the NSH does not have to rely upon an underlying transport encapsulation for security and confidentiality". The outcome is that the requirements in rfc8300 would result in not using this specification. > I know that we can interpret the update as "amends", but unless I'm mista= ken > there is no formal IETF consensus on this. True. Without at least some text explaining the relationship between the requirements in this document and how they may be considered instead of the ones in rfc8300, I don't think this document is complete. =C2=A0For better or worse, the only tool we have right now to make that link clear is the Updates tag. Thanks! Alvaro. From nobody Mon Jul 12 12:29:41 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E48643A126D; Mon, 12 Jul 2021 12:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Td2IproHC-E; Mon, 12 Jul 2021 12:29:29 -0700 (PDT) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 15B2C3A129C; Mon, 12 Jul 2021 12:29:26 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id s15so29623080edt.13; Mon, 12 Jul 2021 12:29:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=OqHSkBgwTpIHpDbM1Dg7Krf7Igxydn/1i4j/DyPm4xU=; b=YAiJzElD6tLl78CbHs3J2+BUST97tgpUpQFFFhjCuZDrXpQVS5qWX30bYTlyOAiTRn HGJTofiAjCfc47pHaJQptTktRfMds7bPTM3bgwZEA/XoQC7y6uYzW3e5bgdUWlZy4cV4 +O1niqB3ScI6uogKiSDpmFHiWELq1ROs7HmFZRnvQhZUQyVwMuPrS5RAafhuQTiSEVU3 iiZKZgyqi5QRZ1g+qDx6vq3gNSJE+KPT87dWSaEgidmU1SVIqnKTuNTOdknwdF6m/Og4 gPxRZ/RO1TYKuCngXk/+Ij2KlO9NQ6gJtdAq95WvFCZeoS4gcnQzBcUSZ1HVJ8o3Izsz FVZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=OqHSkBgwTpIHpDbM1Dg7Krf7Igxydn/1i4j/DyPm4xU=; b=OBrMvivOOJbC3PWjKquxoHqVXZJgREvwgsuVltTVJ6g57gTkydUzwFH86mEp8RbxN+ QKkM10IXzsfjzIeRMvQix+xITVFFiYI+4NbT5eMMr3QwARR05JMVez6cmHl2PkBdWl9I 9mfAsoVa86BLx5MaGgrx/dgb/lA75J0OZNF6rc6kte7Frk0lOZfmqRBUdJw+rUYsm7F6 dmEUVijpcSJtNzLHrO5F3ZiupU7B1wK8TwAeQR0SmcR3xYl3yhgS4FBnN9Zg3YN+daoW 1nulzyH39njXlRb+atQdIJ8DbIcLBZcPEcAMvjOEseXIPfqKcIdGLhJtuti0NnAoE002 oehw== X-Gm-Message-State: AOAM533jZPlokgKg0+2m7Xz/6dGhw/z4GEJTWkVDO2d8Y7wZaFHJEBQ7 3ifrMvmq3vPhipwRJxYdBm9mnrXbuSEjzQF5Rwtu/k1TJrY= X-Google-Smtp-Source: ABdhPJzRmYPWDouBH5/+pGz8iMZrjQRdaYFBMWZe7Xmfztr/JLFBzN7Ht3gcVRny5/hUPbEU15S6SO01gJ6BgMLgXBE= X-Received: by 2002:a05:6402:1692:: with SMTP id a18mr544555edv.344.1626118163690; Mon, 12 Jul 2021 12:29:23 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 12 Jul 2021 12:29:23 -0700 From: Alvaro Retana In-Reply-To: References: <162611498183.7775.3562397379733537345@ietfa.amsl.com> MIME-Version: 1.0 Date: Mon, 12 Jul 2021 12:29:23 -0700 Message-ID: To: The IESG , "Joel M. Halpern" Cc: sfc@ietf.org, gregimirsky@gmail.com, draft-ietf-sfc-nsh-integrity@ietf.org Content-Type: multipart/alternative; boundary="0000000000008278a405c6f2233a" Archived-At: Subject: Re: [sfc] Alvaro Retana's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 19:29:39 -0000 --0000000000008278a405c6f2233a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Joel: Hi! I guess I missed where that discussion happened =E2=80=94 probably buried i= n one of the threads. Can you please point me to it? Thanks! Alvaro. On July 12, 2021 at 3:23:28 PM, Joel M. Halpern (jmh@joelhalpern.com) wrote= : I find your description of this as a "required update to 8300" rather odd. The working group did not agree to make implementation of this mandatory for 8300. That would, indeed, be an update to 8300. This is just another feature that can be used with NSH. A useful feature. The security considerations do give lots of reasons to do this. But that is not the same as making it "required" for all implementations of 8300. Yours, Joel On 7/12/2021 2:36 PM, Alvaro Retana via Datatracker wrote: > Alvaro Retana has entered the following ballot position for > draft-ietf-sfc-nsh-integrity-06: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > (1) Given the required behavior specified in the Security Considerations > section... > > NSH data are exposed to several threats: > > o A man-in-the-middle attacker modifying the NSH data. > > o Attacker spoofing the NSH data. > > o Attacker capturing and replaying the NSH data. > > o Data carried in Context Headers revealing privacy-sensitive > information to attackers. > > o Attacker replacing the packet on which the NSH is imposed with a > bogus packet. > > In an SFC-enabled domain where the above attacks are possible, (1) > NSH data MUST be integrity-protected and replay-protected, and (2) > privacy-sensitive NSH metadata MUST be encrypted for confidentiality > preservation purposes. The Base and Service Path headers are not > encrypted. > > Why doesn't this document formally update rfc8300? Concerns that eventually > led to this solution have been expressed for several other documents, including > rfc8459 and rfc8979. > > It looks like the WG didn't consider the question of Updating the base NSH > specification. I believe that this document specifies a required update to > NSH, and would like the WG to consider formally Updating rfc8300. [My search > of the archive didn't find any related discussion -- did I miss it?] > > [Even though I consider this omission a serious oversight, I don't think this > issue raises to the level of a DISCUSS.] > > (2) =C2=A73: I find the use of normative language to describe requirement= s (that are > met in this same document) not the best use of rfc2119 language because any > interoperability concerns would result from the specification itself and not > the requirements. > > The use of rfc2119 keywords to describe requirements may result in confusion. > For example, "The solution MAY provide integrity protection for the Base > Header." -- as described later, protecting the Base Header is optional, but the > solution *does* provide integrity protection for it. IOW, the specification is > what is reflected in the requirement, but referring to the solution, not the > protection: providing integrity protection is not optional, using it is. A > better working would be: "The solution must provide optional integrity > protection for the Base Header." > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > --0000000000008278a405c6f2233a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Joel= :

=
Hi!

I guess I missed where that disc= ussion happened =E2=80=94 probably buried in one of the threads.=C2=A0 Can = you please point me to it?

Thanks!

Alv= aro.

On July 12, 2021 at 3:23:28 PM, Joel= M. Halpern (jmh@joelhalpern.com= ) wrote:

<= /div>
I find your description of this as a "required update to 830= 0" rather =20
odd. The working group did not agree to make implementation of this = =20
mandatory for 8300. That would, indeed, be an update to 8300. This i= s =20
just another feature that can be used with NSH. A useful feature.

The security considerations do give lots of reasons to do this. But tha= t =20
is not the same as making it "required" for all implementatio= ns of 8300.

Yours,
Joel

On 7/12/2021 2:36 PM, Alvaro Retana via Datatracker wrote:
> Alvaro Retana has entered the following ballot position for
> draft-ietf-sfc-nsh-integrity-06: No Objection
> =20
> When responding, please keep the subject line intact and reply to = all
> email addresses included in the To and CC lines. (Feel free to cut= this
> introductory paragraph, however.)
> =20
> =20
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml
> for more information about DISCUSS and COMMENT positions.
> =20
> =20
> The document, along with other ballot positions, can be found here= :
> https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/
> =20
> =20
> =20
> ------------------------------------------------------------------= ----
> COMMENT:
> ------------------------------------------------------------------= ----
> =20
> =20
> (1) Given the required behavior specified in the Security Consider= ations
> section...
> =20
> NSH data are exposed to several threats:
> =20
> o A man-in-the-middle attacker modifying the NSH data.
> =20
> o Attacker spoofing the NSH data.
> =20
> o Attacker capturing and replaying the NSH data.
> =20
> o Data carried in Context Headers revealing privacy-sensitive
> information to attackers.
> =20
> o Attacker replacing the packet on which the NSH is imposed w= ith a
> bogus packet.
> =20
> In an SFC-enabled domain where the above attacks are possible,= (1)
> NSH data MUST be integrity-protected and replay-protected, and= (2)
> privacy-sensitive NSH metadata MUST be encrypted for confident= iality
> preservation purposes. The Base and Service Path headers are = not
> encrypted.
> =20
> Why doesn't this document formally update rfc8300? Concerns t= hat eventually
> led to this solution have been expressed for several other documen= ts, including
> rfc8459 and rfc8979.
> =20
> It looks like the WG didn't consider the question of Updating = the base NSH
> specification. I believe that this document specifies a required = update to
> NSH, and would like the WG to consider formally Updating rfc8300. = [My search
> of the archive didn't find any related discussion -- did I mis= s it?]
> =20
> [Even though I consider this omission a serious oversight, I don&#= 39;t think this
> issue raises to the level of a DISCUSS.]
> =20
> (2) =C2=A73: I find the use of normative language to describe requ= irements (that are
> met in this same document) not the best use of rfc2119 language be= cause any
> interoperability concerns would result from the specification itse= lf and not
> the requirements.
> =20
> The use of rfc2119 keywords to describe requirements may result in= confusion.
> For example, "The solution MAY provide integrity protection f= or the Base
> Header." -- as described later, protecting the Base Header is= optional, but the
> solution *does* provide integrity protection for it. IOW, the spe= cification is
> what is reflected in the requirement, but referring to the solutio= n, not the
> protection: providing integrity protection is not optional, using = it is. A
> better working would be: "The solution must provide optional = integrity
> protection for the Base Header."
> =20
> =20
> =20
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.= ietf.org/mailman/listinfo/sfc
> =20
<= /body> --0000000000008278a405c6f2233a-- From nobody Mon Jul 12 12:38:12 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 319EC3A1360; Mon, 12 Jul 2021 12:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 kLHUC8d_QHf7; Mon, 12 Jul 2021 12:38:05 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 5EA003A1404; Mon, 12 Jul 2021 12:37:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4GNvDv0R9gz1nscD; Mon, 12 Jul 2021 12:37:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1626118671; bh=i4xsu7nPZHtdQGmB5AAa8p/pFOuR/m9nOMwFv049kZQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=QgDiJstfarc680AAliZ1xWSAvqGr01pe4sEIpYlTTfi01XKASZ0M1MJggWFR7u8UC UFNw+rhgtKHsqx3zPOsyCaDDk5qKKhceNOiL8OMMFcxfP8bCUWjSivflhxLaX2Yjp4 ecZKdUiDge5oaSOSY4Wr0doVnZJDdQXfCq/JdpV0= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4GNvDt1hD5z1nsQX; Mon, 12 Jul 2021 12:37:50 -0700 (PDT) To: Alvaro Retana , The IESG Cc: gregimirsky@gmail.com, draft-ietf-sfc-nsh-integrity@ietf.org, sfc@ietf.org References: <162611498183.7775.3562397379733537345@ietfa.amsl.com> From: "Joel M. Halpern" Message-ID: <1a5ae768-bf12-6d94-819c-7923e1f816ee@joelhalpern.com> Date: Mon, 12 Jul 2021 15:37:48 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] Alvaro Retana's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 19:38:10 -0000 Depending upon what you mean, either 1) The discussion never happened, because the action was not suggested. or, with a longer view 2) The discussion happened when 8300 was being approved. We agreed with the IESG that we would not define a mandatory-to-implement NSH security mechanism, but that we would add an optional NSH security mechanism. Which this draft does. Yours, Joel On 7/12/2021 3:29 PM, Alvaro Retana wrote: > Joel: > > Hi! > > I guess I missed where that discussion happened — probably buried in one > of the threads.  Can you please point me to it? > > Thanks! > > Alvaro. > > On July 12, 2021 at 3:23:28 PM, Joel M. Halpern (jmh@joelhalpern.com > ) wrote: > >> I find your description of this as a "required update to 8300" rather >> odd. The working group did not agree to make implementation of this >> mandatory for 8300. That would, indeed, be an update to 8300. This is >> just another feature that can be used with NSH. A useful feature. >> >> The security considerations do give lots of reasons to do this. But that >> is not the same as making it "required" for all implementations of 8300. >> >> Yours, >> Joel >> >> On 7/12/2021 2:36 PM, Alvaro Retana via Datatracker wrote: >> > Alvaro Retana has entered the following ballot position for >> > draft-ietf-sfc-nsh-integrity-06: No Objection >> > >> > When responding, please keep the subject line intact and reply to all >> > email addresses included in the To and CC lines. (Feel free to cut this >> > introductory paragraph, however.) >> > >> > >> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> >> > for more information about DISCUSS and COMMENT positions. >> > >> > >> > The document, along with other ballot positions, can be found here: >> > https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/ >> >> > >> > >> > >> > ---------------------------------------------------------------------- >> > COMMENT: >> > ---------------------------------------------------------------------- >> > >> > >> > (1) Given the required behavior specified in the Security Considerations >> > section... >> > >> > NSH data are exposed to several threats: >> > >> > o A man-in-the-middle attacker modifying the NSH data. >> > >> > o Attacker spoofing the NSH data. >> > >> > o Attacker capturing and replaying the NSH data. >> > >> > o Data carried in Context Headers revealing privacy-sensitive >> > information to attackers. >> > >> > o Attacker replacing the packet on which the NSH is imposed with a >> > bogus packet. >> > >> > In an SFC-enabled domain where the above attacks are possible, (1) >> > NSH data MUST be integrity-protected and replay-protected, and (2) >> > privacy-sensitive NSH metadata MUST be encrypted for confidentiality >> > preservation purposes. The Base and Service Path headers are not >> > encrypted. >> > >> > Why doesn't this document formally update rfc8300? Concerns that eventually >> > led to this solution have been expressed for several other documents, including >> > rfc8459 and rfc8979. >> > >> > It looks like the WG didn't consider the question of Updating the base NSH >> > specification. I believe that this document specifies a required update to >> > NSH, and would like the WG to consider formally Updating rfc8300. [My search >> > of the archive didn't find any related discussion -- did I miss it?] >> > >> > [Even though I consider this omission a serious oversight, I don't think this >> > issue raises to the level of a DISCUSS.] >> > >> > (2) §3: I find the use of normative language to describe requirements (that are >> > met in this same document) not the best use of rfc2119 language because any >> > interoperability concerns would result from the specification itself and not >> > the requirements. >> > >> > The use of rfc2119 keywords to describe requirements may result in confusion. >> > For example, "The solution MAY provide integrity protection for the Base >> > Header." -- as described later, protecting the Base Header is optional, but the >> > solution *does* provide integrity protection for it. IOW, the specification is >> > what is reflected in the requirement, but referring to the solution, not the >> > protection: providing integrity protection is not optional, using it is. A >> > better working would be: "The solution must provide optional integrity >> > protection for the Base Header." >> > >> > >> > >> > _______________________________________________ >> > sfc mailing list >> > sfc@ietf.org >> > https://www.ietf.org/mailman/listinfo/sfc >> >> > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Mon Jul 12 12:41:25 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F8E3A1381; Mon, 12 Jul 2021 12:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1oqAY8tVf8K; Mon, 12 Jul 2021 12:41:19 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (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 B16913A1389; Mon, 12 Jul 2021 12:41:18 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfedar26.francetelecom.fr (ESMTP service) with ESMTPS id 4GNvJn3cZ3zFqFG; Mon, 12 Jul 2021 21:41:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1626118873; bh=QevUMLTQ5a34kTJaNWNJlaF79Lb4iae29PdjiBINAFo=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=OvVNyUiWs9cYO7poyKmTl4K4rvjGva2jgAkkcVrsMgVBK5437nSoVI9HMCtENgTAU A7aeDE/cjvDHwrOj8wETOGEIg2Ppgj7nAFEXR+W3bQNnIKKcm+yKOs7RodxiNSBaQx EwLijGEXW0tsk6nCWpEk0bzThzJ4sEMw7oWfwzhq5gOC/QGn+oVoRxb1Nc1PE0PxCL W6o748ZAE4MqpWEMZ1mvRNr3Nx+bki2y1WWqXdCzxSqMAoMi7aOGVnxmj7ynWBblgy XJIhPul15CRcB6J0C+AXc2xA7+qPeIjZZhnwgkec2rnJOVIMtnvrRmfYgDwBZf2C/p AV4Z0BFzuehNQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfedar00.francetelecom.fr (ESMTP service) with ESMTPS id 4GNvJn26hMzCqk9; Mon, 12 Jul 2021 21:41:13 +0200 (CEST) From: To: Alvaro Retana , The IESG CC: "draft-ietf-sfc-nsh-integrity@ietf.org" , "sfc-chairs@ietf.org" , "gregimirsky@gmail.com" , "sfc@ietf.org" Thread-Topic: Alvaro Retana's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) Thread-Index: AQHXd1Pbs7Sb3jEX8kSZOT/s+TE0/as/uzNg Date: Mon, 12 Jul 2021 19:41:11 +0000 Message-ID: <13781_1626118873_60EC9AD9_13781_9_1_787AE7BB302AE849A7480A190F8B9330353BDA95@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162611498183.7775.3562397379733537345@ietfa.amsl.com> <23837_1626115941_60EC8F65_23837_478_1_787AE7BB302AE849A7480A190F8B9330353BD8C2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Alvaro Retana's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 19:41:24 -0000 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVz c2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBBbHZhcm8gUmV0YW5hIFttYWlsdG86YXJldGFu YS5pZXRmQGdtYWlsLmNvbV0NCj4gRW52b3nDqcKgOiBsdW5kaSAxMiBqdWlsbGV0IDIwMjEgMjE6 MjcNCj4gw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQgSU5OT1YvTkVUIDxtb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tPjsgVGhlDQo+IElFU0cgPGllc2dAaWV0Zi5vcmc+DQo+IENjwqA6IGRyYWZ0 LWlldGYtc2ZjLW5zaC1pbnRlZ3JpdHlAaWV0Zi5vcmc7IHNmYy1jaGFpcnNAaWV0Zi5vcmc7DQo+ IGdyZWdpbWlyc2t5QGdtYWlsLmNvbTsgc2ZjQGlldGYub3JnDQo+IE9iamV0wqA6IFJFOiBBbHZh cm8gUmV0YW5hJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtc2ZjLW5zaC0NCj4gaW50ZWdy aXR5LTA2OiAod2l0aCBDT01NRU5UKQ0KPiANCj4gT24gSnVseSAxMiwgMjAyMSBhdCAyOjUyOjIy IFBNLCBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIHdyb3RlOg0KPiANCj4gDQo+IE1lZDoN Cj4gDQo+IEhpIQ0KPiANCj4gLi4uDQo+ID4gPiAoMSkgR2l2ZW4gdGhlIHJlcXVpcmVkIGJlaGF2 aW9yIHNwZWNpZmllZCBpbiB0aGUgU2VjdXJpdHkNCj4gPiA+IENvbnNpZGVyYXRpb25zIHNlY3Rp b24uLi4NCj4gPiA+DQo+ID4gPiBOU0ggZGF0YSBhcmUgZXhwb3NlZCB0byBzZXZlcmFsIHRocmVh dHM6DQo+ID4gPg0KPiA+ID4gbyBBIG1hbi1pbi10aGUtbWlkZGxlIGF0dGFja2VyIG1vZGlmeWlu ZyB0aGUgTlNIIGRhdGEuDQo+ID4gPg0KPiA+ID4gbyBBdHRhY2tlciBzcG9vZmluZyB0aGUgTlNI IGRhdGEuDQo+ID4gPg0KPiA+ID4gbyBBdHRhY2tlciBjYXB0dXJpbmcgYW5kIHJlcGxheWluZyB0 aGUgTlNIIGRhdGEuDQo+ID4gPg0KPiA+ID4gbyBEYXRhIGNhcnJpZWQgaW4gQ29udGV4dCBIZWFk ZXJzIHJldmVhbGluZyBwcml2YWN5LXNlbnNpdGl2ZQ0KPiA+ID4gaW5mb3JtYXRpb24gdG8gYXR0 YWNrZXJzLg0KPiA+ID4NCj4gPiA+IG8gQXR0YWNrZXIgcmVwbGFjaW5nIHRoZSBwYWNrZXQgb24g d2hpY2ggdGhlIE5TSCBpcyBpbXBvc2VkIHdpdGgNCj4gYQ0KPiA+ID4gYm9ndXMgcGFja2V0Lg0K PiA+ID4NCj4gPiA+IEluIGFuIFNGQy1lbmFibGVkIGRvbWFpbiB3aGVyZSB0aGUgYWJvdmUgYXR0 YWNrcyBhcmUgcG9zc2libGUsDQo+ICgxKQ0KPiA+ID4gTlNIIGRhdGEgTVVTVCBiZSBpbnRlZ3Jp dHktcHJvdGVjdGVkIGFuZCByZXBsYXktcHJvdGVjdGVkLCBhbmQNCj4gKDIpDQo+ID4gPiBwcml2 YWN5LXNlbnNpdGl2ZSBOU0ggbWV0YWRhdGEgTVVTVCBiZSBlbmNyeXB0ZWQgZm9yDQo+IGNvbmZp ZGVudGlhbGl0eQ0KPiA+ID4gcHJlc2VydmF0aW9uIHB1cnBvc2VzLiBUaGUgQmFzZSBhbmQgU2Vy dmljZSBQYXRoIGhlYWRlcnMgYXJlIG5vdA0KPiA+ID4gZW5jcnlwdGVkLg0KPiA+ID4NCj4gPiA+ IFdoeSBkb2Vzbid0IHRoaXMgZG9jdW1lbnQgZm9ybWFsbHkgdXBkYXRlIHJmYzgzMDA/IENvbmNl cm5zIHRoYXQNCj4gPiA+IGV2ZW50dWFsbHkgbGVkIHRvIHRoaXMgc29sdXRpb24gaGF2ZSBiZWVu IGV4cHJlc3NlZCBmb3Igc2V2ZXJhbA0KPiA+ID4gb3RoZXIgZG9jdW1lbnRzLCBpbmNsdWRpbmcg cmZjODQ1OSBhbmQgcmZjODk3OS4NCj4gPiA+DQo+ID4gPiBJdCBsb29rcyBsaWtlIHRoZSBXRyBk aWRuJ3QgY29uc2lkZXIgdGhlIHF1ZXN0aW9uIG9mIFVwZGF0aW5nDQo+IHRoZQ0KPiA+ID4gYmFz ZSBOU0ggc3BlY2lmaWNhdGlvbi4gSSBiZWxpZXZlIHRoYXQgdGhpcyBkb2N1bWVudCBzcGVjaWZp ZXMgYQ0KPiA+ID4gcmVxdWlyZWQgdXBkYXRlIHRvIE5TSCwgYW5kIHdvdWxkIGxpa2UgdGhlIFdH IHRvIGNvbnNpZGVyDQo+IGZvcm1hbGx5DQo+ID4gPiBVcGRhdGluZyByZmM4MzAwLiBbTXkgc2Vh cmNoIG9mIHRoZSBhcmNoaXZlIGRpZG4ndCBmaW5kIGFueQ0KPiByZWxhdGVkDQo+ID4gPiBkaXNj dXNzaW9uIC0tIGRpZCBJIG1pc3MgaXQ/XQ0KPiA+DQo+ID4gW01lZF0gV2UgZG9uJ3QgdXNlIHRo ZSB1cGRhdGUgaGVhZGVyIGFzIHdlIGRvbid0IGZvcm1hbGx5IHVwZGF0ZQ0KPiBhbnkNCj4gPiB0 ZXh0IGluIDgzMDAuDQo+IA0KPiBVcGRhdGluZyB0ZXh0IGlzIG5vdCB0aGUgb25seSByZWFzb24g dG8gZm9ybWFsbHkgVXBkYXRlIGFub3RoZXINCj4gc3BlY2lmaWNhdGlvbi4NCj4gDQo+IFRoaXMg ZG9jdW1lbnQgcmVxdWlyZXMgdGhlIHVzZSBvZiBib3RoIGludGVncml0eSBhbmQgZW5jcnlwdGlv biBpZg0KPiBzcGVjaWZpYyBhdHRhY2tzIGFyZSBwb3NzaWJsZSAodGV4dCBhYm92ZSkuIMKgSXQg aXMgcmVhc29uYWJsZSB0bw0KPiBpbnRlcnByZXQgdGhhdCBhcyBjYXNlcyB3aGVyZSB0aGUgIm9w ZXJhdG9yIGRlZW1zIHByb3RlY3Rpb24gaXMNCj4gcmVxdWlyZWQiLCB3aGljaCBpcyB0aGUgdGV4 dCB0aGF0IHJmYzgzMDAgdXNlcyB3aGVuIGl0IHRhbGtzIGFib3V0DQo+IHRoZSBuZWVkIGZvciBp bnRlZ3JpdHkgcHJvdGVjdGlvbiAoc2ltaWxhciB0ZXh0IGNhbiBhbHNvIGJlIGZvdW5kDQo+IGFi b3V0IGVuY3J5cHRpb24pLiDCoElPVywgdGhlIGZvcm1hbCBVcGRhdGUgdGhhdCBJJ20gc3VnZ2Vz dGluZyBoZXJlDQo+IGlzIHRvIHByb3ZpZGUgbW9yZSBpbnNpZ2h0IGludG8gd2hlbiBpbnRlZ3Jp dHkgcHJvdGVjdGlvbiBhbmQNCj4gZW5jcnlwdGlvbiBhcmUgcmVxdWlyZWQsIGFuZCB0aGUgbWVj aGFuaXNtIHRvIHVzZS4NCj4gDQo+IA0KPiBBcyBJIGxvb2sgaW50byB0aGlzIGZ1cnRoZXIsIEkg YmVsaWV2ZSB0aGVyZSBpcyBhIG5vcm1hdGl2ZQ0KPiBpbmNvbnNpc3RlbmN5IGJldHdlZW4gdGhp cyBkb2N1bWVudCBhbmQgcmZjODMwMDoNCj4gDQo+IC0gcmZjODMwMCByZXF1aXJlcyB0aGUgdXNl IG9mIGFuIGVuY2Fwc3VsYXRpbmcgdHJhbnNwb3J0IHByb3RvY29sDQo+IHRoYXQgY2FuIHByb3Zp ZGUgaW50ZWdyaXR5IHByb3RlY3Rpb24gYW5kL29yIGVuY3J5cHRpb24sIGFzIG5lZWRlZC4NCj4g DQo+IC0gVGhpcyBkb2N1bWVudCByZXF1aXJlcyBwcm90ZWN0aW9uIGFzIHNwZWNpZmllZCBpbiB0 aGUgdGV4dA0KPiBhYm92ZS4gwqBBIHN0YXRlZCBnb2FsIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBp cyBzbyB0aGF0ICJ0aGUgTlNIIGRvZXMNCj4gbm90IGhhdmUgdG8gcmVseSB1cG9uIGFuIHVuZGVy bHlpbmcgdHJhbnNwb3J0IGVuY2Fwc3VsYXRpb24gZm9yDQo+IHNlY3VyaXR5IGFuZCBjb25maWRl bnRpYWxpdHkiLg0KPiANCj4gVGhlIG91dGNvbWUgaXMgdGhhdCB0aGUgcmVxdWlyZW1lbnRzIGlu IHJmYzgzMDAgd291bGQgcmVzdWx0IGluIG5vdA0KPiB1c2luZyB0aGlzIHNwZWNpZmljYXRpb24u DQo+IA0KDQpbTWVkXSBOb3Qgc3VyZSBhYm91dCB0aGlzIGdpdmVuIHRoYXQgUkZDODMwMCBzYXlz IHRoZSBmb2xsb3dpbmc6ICANCg0KICAgICAgTlNIIGl0c2VsZiBkb2VzIG5vdCBtYW5kYXRlIHBy b3RvY29sLXNwZWNpZmljIGludGVncml0eQ0KICAgICAgcHJvdGVjdGlvbi4gIEhvd2V2ZXIsIGlm IGFuIG9wZXJhdG9yIGRlZW1zIHByb3RlY3Rpb24gaXMgcmVxdWlyZWQsDQogICAgICBzZXZlcmFs IG9wdGlvbnMgYXJlIHZpYWJsZToNCg0KICAgICAgMS4gIFNGRi9TRiBOU0ggdmVyaWZpY2F0aW9u DQogICAgICAuLi4NCiAgICAgIDIuICBUcmFuc3BvcnQgU2VjdXJpdHkNCiAgICAgIC4uLg0KICAg ICAgMy4gIE5TSCBWYXJpYWJsZSBIZWFkZXItQmFzZWQgSW50ZWdyaXR5DQoNCiAgICAgICAgICBM YXN0bHksIE5TSCBNRCBUeXBlIDIgcHJvdmlkZXMsIHZpYSB2YXJpYWJsZS1sZW5ndGggaGVhZGVy cywNCiAgICAgICAgICB0aGUgYWJpbGl0eSB0byBhcHBlbmQgY3J5cHRvZ3JhcGhpYyBpbnRlZ3Jp dHkgcHJvdGVjdGlvbiB0bw0KICAgICAgICAgIHRoZSBOU0ggcGFja2V0LiAgVGhlIGltcGxlbWVu dGF0aW9uIG9mIHN1Y2ggYSBzY2hlbWUgaXMNCiAgICAgICAgICBvdXRzaWRlIHRoZSBzY29wZSBv ZiB0aGlzIGRvY3VtZW50Lg0KDQpUaGUgSS1EIGlzIGJhc2ljYWxseSB0aGUgdGhpcmQgb3B0aW9u LiANCg0KPiANCj4gPiBJIGtub3cgdGhhdCB3ZSBjYW4gaW50ZXJwcmV0IHRoZSB1cGRhdGUgYXMg ImFtZW5kcyIsIGJ1dCB1bmxlc3MNCj4gSSdtDQo+ID4gbWlzdGFrZW4gdGhlcmUgaXMgbm8gZm9y bWFsIElFVEYgY29uc2Vuc3VzIG9uIHRoaXMuDQo+IA0KPiBUcnVlLg0KPiANCj4gV2l0aG91dCBh dCBsZWFzdCBzb21lIHRleHQgZXhwbGFpbmluZyB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhl DQo+IHJlcXVpcmVtZW50cyBpbiB0aGlzIGRvY3VtZW50IGFuZCBob3cgdGhleSBtYXkgYmUgY29u c2lkZXJlZCBpbnN0ZWFkDQo+IG9mIHRoZSBvbmVzIGluIHJmYzgzMDAsIEkgZG9uJ3QgdGhpbmsg dGhpcyBkb2N1bWVudCBpcw0KPiBjb21wbGV0ZS4gwqBGb3IgYmV0dGVyIG9yIHdvcnNlLCB0aGUg b25seSB0b29sIHdlIGhhdmUgcmlnaHQgbm93IHRvDQo+IG1ha2UgdGhhdCBsaW5rIGNsZWFyIGlz IHRoZSBVcGRhdGVzIHRhZy4NCj4gDQo+IA0KPiBUaGFua3MhDQo+IA0KPiBBbHZhcm8uDQoKX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBk ZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9p dmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0 b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWls bGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBs ZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2Nl cHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRl IHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4K ClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlh bCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7 CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBh dXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJs ZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lm aWVkLgpUaGFuayB5b3UuCgo= From nobody Mon Jul 12 13:08:48 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14BDB3A15F2; Mon, 12 Jul 2021 13:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Veb3OtxbW9Ao; Mon, 12 Jul 2021 13:08:42 -0700 (PDT) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 829503A15E6; Mon, 12 Jul 2021 13:08:41 -0700 (PDT) Received: by mail-ed1-x534.google.com with SMTP id ee25so11642655edb.5; Mon, 12 Jul 2021 13:08:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=nl9ff1cx8a/E1YYd3oZCG94UofikPo9QUIK3yEVlg1Y=; b=PyH1vujGzWh66EA9FYNRnT9rYlk49dt2wcYi3gkjGK/ULtHy+0wQ1lut9eE+UuDMNG QZUEeqM20YrzSwYqZaOT6z6x8sp+y0pYT6esOdNNIswLIf0HPf7ZQSGBkKh6DBlm/YU9 IgxH6QKgjgZh46N7b1fXeoma49HPMM6MSGp0pAkpzdWWLzuiK41jIlKn7cdWCXhwahrm IR+qhDokDqzuPBjQTFTNaG/FR2MBqk+GYtmtY2agGFecr6UG80fvkl31NOmBffWly39/ tffsYyNZs3sN2bgXAZoDflWWPvbW8BGyfIraxBV+BhgFLrzUIKHqd//gzMK2auFI9M1z vdRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=nl9ff1cx8a/E1YYd3oZCG94UofikPo9QUIK3yEVlg1Y=; b=dEb+S5CyMhBHKa6sVuzXxWSJD40kj9wD3MCQ6qnbAAnWH8Upo2meaXhWzGXRof/Wiw 8Z2M0P86EUW1Xeuh8fSQSWjJ+VgMiHDg5HS1aWU1XlvoFKCgdnjuO+POnIeDc/jCuT3x AwcyKCSFnrhRgLq3rADGL8hF6Q4UHaqka+ejFd+lh3Vrm5bdzv59zYSr+6ZemxtwFgzp uBnTE5BqJTwn+WpF2YpueenbjgNz3S0wsKvipzEruhEF+o55Z4p/IFofLh0/wd/MhOHF MDn4EKr2RO++e8o+5kniQjLIxYG8bdDI2lQfoLLstZ9EDV+r6aKqhnSQ3nfpWpbyFLnB Ll1g== X-Gm-Message-State: AOAM5332R2beRfPfP3TJpAclxwbwVVW/f4m/RNEX/qDcgx8NB6FqhNNx aNyVSe2nywuoat8Yw2sVxStBP8xujEwRL9mGXW1tzejVBsM= X-Google-Smtp-Source: ABdhPJzoup7DePpH8mAZ7Cf6Kkxs2ZnwLuZONsjxcKagRd1tdhx9Uu3hbebTGTwuCd4Qj4X0qviDigK7NWmvA+L5rXQ= X-Received: by 2002:a05:6402:40f:: with SMTP id q15mr744952edv.86.1626120518284; Mon, 12 Jul 2021 13:08:38 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 12 Jul 2021 13:08:37 -0700 From: Alvaro Retana In-Reply-To: <1a5ae768-bf12-6d94-819c-7923e1f816ee@joelhalpern.com> References: <162611498183.7775.3562397379733537345@ietfa.amsl.com> <1a5ae768-bf12-6d94-819c-7923e1f816ee@joelhalpern.com> MIME-Version: 1.0 Date: Mon, 12 Jul 2021 13:08:37 -0700 Message-ID: To: The IESG , "Joel M. Halpern" Cc: sfc@ietf.org, gregimirsky@gmail.com, draft-ietf-sfc-nsh-integrity@ietf.org Content-Type: multipart/alternative; boundary="000000000000dabbe005c6f2af33" Archived-At: Subject: Re: [sfc] Alvaro Retana's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 20:08:47 -0000 --000000000000dabbe005c6f2af33 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi! I meant the discussion about this draft formally Updating rfc8300 =E2=80=94= which I would have hopped happened when processing/discussing this document (not before). I=E2=80=99m assuming that discussion never happened. BTW, I=E2=80=99m not asking for the new mechanism to be MTI =E2=80=94 the c= urrent text (at least to me) reads as if it is not. I=E2=80=99m ok with that. [IOW, an Up= date to rfc8300 would =E2=80=9Cinherit=E2=80=9D that characteristic.] Alvaro. On July 12, 2021 at 3:37:51 PM, Joel M. Halpern (jmh@joelhalpern.com) wrote= : Depending upon what you mean, either 1) The discussion never happened, because the action was not suggested. or, with a longer view 2) The discussion happened when 8300 was being approved. We agreed with the IESG that we would not define a mandatory-to-implement NSH security mechanism, but that we would add an optional NSH security mechanism. Which this draft does. Yours, Joel On 7/12/2021 3:29 PM, Alvaro Retana wrote: > Joel: > > Hi! > > I guess I missed where that discussion happened =E2=80=94 probably buried= in one > of the threads. Can you please point me to it? > > Thanks! > > Alvaro. > > On July 12, 2021 at 3:23:28 PM, Joel M. Halpern (jmh@joelhalpern.com > ) wrote: > >> I find your description of this as a "required update to 8300" rather >> odd. The working group did not agree to make implementation of this >> mandatory for 8300. That would, indeed, be an update to 8300. This is >> just another feature that can be used with NSH. A useful feature. >> >> The security considerations do give lots of reasons to do this. But that >> is not the same as making it "required" for all implementations of 8300. >> >> Yours, >> Joel >> >> On 7/12/2021 2:36 PM, Alvaro Retana via Datatracker wrote: >> > Alvaro Retana has entered the following ballot position for >> > draft-ietf-sfc-nsh-integrity-06: No Objection >> > >> > When responding, please keep the subject line intact and reply to all >> > email addresses included in the To and CC lines. (Feel free to cut this >> > introductory paragraph, however.) >> > >> > >> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> >> > for more information about DISCUSS and COMMENT positions. >> > >> > >> > The document, along with other ballot positions, can be found here: >> > https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/ >> >> > >> > >> > >> > ---------------------------------------------------------------------- >> > COMMENT: >> > ---------------------------------------------------------------------- >> > >> > >> > (1) Given the required behavior specified in the Security Considerations >> > section... >> > >> > NSH data are exposed to several threats: >> > >> > o A man-in-the-middle attacker modifying the NSH data. >> > >> > o Attacker spoofing the NSH data. >> > >> > o Attacker capturing and replaying the NSH data. >> > >> > o Data carried in Context Headers revealing privacy-sensitive >> > information to attackers. >> > >> > o Attacker replacing the packet on which the NSH is imposed with a >> > bogus packet. >> > >> > In an SFC-enabled domain where the above attacks are possible, (1) >> > NSH data MUST be integrity-protected and replay-protected, and (2) >> > privacy-sensitive NSH metadata MUST be encrypted for confidentiality >> > preservation purposes. The Base and Service Path headers are not >> > encrypted. >> > >> > Why doesn't this document formally update rfc8300? Concerns that eventually >> > led to this solution have been expressed for several other documents, including >> > rfc8459 and rfc8979. >> > >> > It looks like the WG didn't consider the question of Updating the base NSH >> > specification. I believe that this document specifies a required update to >> > NSH, and would like the WG to consider formally Updating rfc8300. [My search >> > of the archive didn't find any related discussion -- did I miss it?] >> > >> > [Even though I consider this omission a serious oversight, I don't think this >> > issue raises to the level of a DISCUSS.] >> > >> > (2) =C2=A73: I find the use of normative language to describe requirem= ents (that are >> > met in this same document) not the best use of rfc2119 language because any >> > interoperability concerns would result from the specification itself and not >> > the requirements. >> > >> > The use of rfc2119 keywords to describe requirements may result in confusion. >> > For example, "The solution MAY provide integrity protection for the Base >> > Header." -- as described later, protecting the Base Header is optional, but the >> > solution *does* provide integrity protection for it. IOW, the specification is >> > what is reflected in the requirement, but referring to the solution, not the >> > protection: providing integrity protection is not optional, using it is. A >> > better working would be: "The solution must provide optional integrity >> > protection for the Base Header." >> > >> > >> > >> > _______________________________________________ >> > sfc mailing list >> > sfc@ietf.org >> > https://www.ietf.org/mailman/listinfo/sfc >> >> > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > --000000000000dabbe005c6f2af33 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Hi!<= /div>

I meant the discuss= ion about this draft formally Updating rfc8300 =E2=80=94 which I would have= hopped happened when processing/discussing this document (not before).

I=E2=80=99m assuming t= hat discussion never happened.


BTW, I=E2=80=99m not asking for the new mechanism to be MTI =E2=80=94 = the current text (at least to me) reads as if it is not.=C2=A0 I=E2=80=99m = ok with that. =C2=A0[IOW, an Update to rfc8300 would =E2=80=9Cinherit=E2=80= =9D that characteristic.]

Alvaro.

On July 12, 2021 at 3:37:5= 1 PM, Joel M. Halpern (jmh@joelhalpe= rn.com) wrote:

<= div>
Depending upon what you mean, either

1) The discussion never happened, because the action was not suggested.

or, with a longer view

2) The discussion happened when 8300 was being approved. We agreed wit= h =20
the IESG that we would not define a mandatory-to-implement NSH security= =20
mechanism, but that we would add an optional NSH security mechanism. = =20
Which this draft does.

Yours,
Joel

On 7/12/2021 3:29 PM, Alvaro Retana wrote:
> Joel:
> =20
> Hi!
> =20
> I guess I missed where that discussion happened =E2=80=94 probably= buried in one =20
> of the threads.=C2=A0 Can you please point me to it?
> =20
> Thanks!
> =20
> Alvaro.
> =20
> On July 12, 2021 at 3:23:28 PM, Joel M. Halpern (jmh@joelhalpern.com =20
> <mailto:jmh@joelhalpern.= com>) wrote:
> =20
>> I find your description of this as a "required update to = 8300" rather
>> odd. The working group did not agree to make implementation of= this
>> mandatory for 8300. That would, indeed, be an update to 8300. = This is
>> just another feature that can be used with NSH. A useful featu= re.
>>
>> The security considerations do give lots of reasons to do this= . But that
>> is not the same as making it "required" for all impl= ementations of 8300.
>>
>> Yours,
>> Joel
>>
>> On 7/12/2021 2:36 PM, Alvaro Retana via Datatracker wrote:
>> > Alvaro Retana has entered the following ballot position f= or
>> > draft-ietf-sfc-nsh-integrity-06: No Objection
>> > =20
>> > When responding, please keep the subject line intact and = reply to all
>> > email addresses included in the To and CC lines. (Feel fr= ee to cut this
>> > introductory paragraph, however.)
>> > =20
>> > =20
>> > Please refer to https://www.ietf.org/iesg/statement/discuss-cr= iteria.html =20
>> <https://www.ietf.org/iesg/statement/discuss-criteria.html&g= t;
>> > for more information about DISCUSS and COMMENT positions.
>> > =20
>> > =20
>> > The document, along with other ballot positions, can be f= ound here:
>> > https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integ= rity/ =20
>> <https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integr= ity/>
>> > =20
>> > =20
>> > =20
>> > ---------------------------------------------------------= -------------
>> > COMMENT:
>> > ---------------------------------------------------------= -------------
>> > =20
>> > =20
>> > (1) Given the required behavior specified in the Security= Considerations
>> > section...
>> > =20
>> > NSH data are exposed to several threats:
>> > =20
>> > o A man-in-the-middle attacker modifying the NSH dat= a.
>> > =20
>> > o Attacker spoofing the NSH data.
>> > =20
>> > o Attacker capturing and replaying the NSH data.
>> > =20
>> > o Data carried in Context Headers revealing privacy-= sensitive
>> > information to attackers.
>> > =20
>> > o Attacker replacing the packet on which the NSH is = imposed with a
>> > bogus packet.
>> > =20
>> > In an SFC-enabled domain where the above attacks are = possible, (1)
>> > NSH data MUST be integrity-protected and replay-prote= cted, and (2)
>> > privacy-sensitive NSH metadata MUST be encrypted for = confidentiality
>> > preservation purposes. The Base and Service Path hea= ders are not
>> > encrypted.
>> > =20
>> > Why doesn't this document formally update rfc8300? C= oncerns that eventually
>> > led to this solution have been expressed for several othe= r documents, including
>> > rfc8459 and rfc8979.
>> > =20
>> > It looks like the WG didn't consider the question of = Updating the base NSH
>> > specification. I believe that this document specifies a = required update to
>> > NSH, and would like the WG to consider formally Updating = rfc8300. [My search
>> > of the archive didn't find any related discussion -- = did I miss it?]
>> > =20
>> > [Even though I consider this omission a serious oversight= , I don't think this
>> > issue raises to the level of a DISCUSS.]
>> > =20
>> > (2) =C2=A73: I find the use of normative language to desc= ribe requirements (that are
>> > met in this same document) not the best use of rfc2119 la= nguage because any
>> > interoperability concerns would result from the specifica= tion itself and not
>> > the requirements.
>> > =20
>> > The use of rfc2119 keywords to describe requirements may = result in confusion.
>> > For example, "The solution MAY provide integrity pro= tection for the Base
>> > Header." -- as described later, protecting the Base = Header is optional, but the
>> > solution *does* provide integrity protection for it. IOW= , the specification is
>> > what is reflected in the requirement, but referring to th= e solution, not the
>> > protection: providing integrity protection is not optiona= l, using it is. A
>> > better working would be: "The solution must provide = optional integrity
>> > protection for the Base Header."
>> > =20
>> > =20
>> > =20
>> > _______________________________________________
>> > sfc mailing list
>> > sfc@ietf.org <mail= to:sfc@ietf.org>
>> > htt= ps://www.ietf.org/mailman/listinfo/sfc =20
>> <http= s://www.ietf.org/mailman/listinfo/sfc>
>> > =20
> =20
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.= ietf.org/mailman/listinfo/sfc
> =20
<= /body> --000000000000dabbe005c6f2af33-- From nobody Mon Jul 12 13:13:40 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCDD43A177D; Mon, 12 Jul 2021 13:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9lfNmutLYIT; Mon, 12 Jul 2021 13:13:22 -0700 (PDT) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 C780C3A1736; Mon, 12 Jul 2021 13:13:08 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id ca14so12950301edb.2; Mon, 12 Jul 2021 13:13:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=zxbrGkyEvvW/R371j89VH7nT96k5mR36qR0J39iNlpA=; b=Fgevrgben4BJkiiXs7R0kMTO3VqMCQv0P25gKVmD8GAjnQ1VDvFk7z7f7ygRIre+d1 G/GX6kFft2X+3/uB9RWm5aBzgGysHyaV37p73Y0nqRRQRtqJL202F0g85LVHWQzmD23u IG/Y+rAFJTs7BOV46GsUiBG7+sSJHjS39hSLOOu+TJGlWVckLjp04Q3DsgbJXMoWV8Kq roNM1pyyrPtEhXPCsD12GSa9ME2iscKXl2wmLEzuUVqIv51WwB6csRA1WKFB94vRkhoO h08RTT6fa+WnvH/u/vEdke90KSkvgBMQNaAOaHAkOcX68q1lrMWul/dcL2fuaHEjBk/A 1ZBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=zxbrGkyEvvW/R371j89VH7nT96k5mR36qR0J39iNlpA=; b=eIf0F6KNyElcn4O+/R9frK7zRIPam/jlIDEWu+0WBHn1fEeetmTUDla9F9spV9V29C ksFuSzvCY2/infCj7MatPxQ2aB+M8XvyI9Rs5tIGvzfwb84tBwLuwN5MoQsJr8hPUGMz Gs8Umtt16YdsS9b477gGDpXR2fYS7nv0wD2C7V2Fzljb0pYAuydJpv9+K4xPM92Ec5dI Xm7sgoOjXjZHCOnr6pvPnrQI9G2AguWUExtL/m3YURxCRqIxD3CYTHtxNA0pj+2kmhce ehWgcFmB6CoLMlh0eAcsaroIYLyqgjfTcY++tKJebU6LXH7BKqTTDMKim0wbjBGJwa2E IYFg== X-Gm-Message-State: AOAM53335vg9yHCeO3s8lRkj90xpwrNZGGe37tZ2Mdv3x7be/dxKcsFQ EQZNzpuhltRn/B1OwSTpMXkrEiipBnNZzTx5xVk= X-Google-Smtp-Source: ABdhPJyVTEQowgcMOTzrz3Gvtx+g6xpcUQtagXdQyv6ioL0/nZuG2bfqVMmZVx5pwc5nRRzCIvHHn54jxbKzEb4rtbE= X-Received: by 2002:a05:6402:40f:: with SMTP id q15mr768373edv.86.1626120782244; Mon, 12 Jul 2021 13:13:02 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 12 Jul 2021 13:13:01 -0700 From: Alvaro Retana In-Reply-To: <13781_1626118873_60EC9AD9_13781_9_1_787AE7BB302AE849A7480A190F8B9330353BDA95@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162611498183.7775.3562397379733537345@ietfa.amsl.com> <23837_1626115941_60EC8F65_23837_478_1_787AE7BB302AE849A7480A190F8B9330353BD8C2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <13781_1626118873_60EC9AD9_13781_9_1_787AE7BB302AE849A7480A190F8B9330353BDA95@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Date: Mon, 12 Jul 2021 13:13:01 -0700 Message-ID: To: mohamed.boucadair@orange.com, The IESG Cc: "sfc@ietf.org" , "gregimirsky@gmail.com" , "sfc-chairs@ietf.org" , "draft-ietf-sfc-nsh-integrity@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sfc] Alvaro Retana's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 20:13:35 -0000 On July 12, 2021 at 3:41:13 PM, mohamed.boucadair@orange.com (mohamed.boucadair@orange.com (mailto:mohamed.boucadair@orange.com)) wrote: ... > > The outcome is that the requirements in rfc8300 would result in not > > using this specification. > > > > [Med] Not sure about this given that RFC8300 says the following: > > NSH itself does not mandate protocol-specific integrity > protection. However, if an operator deems protection is required, > several options are viable: > > 1. SFF/SF NSH verification > ... > 2. Transport Security > ... > 3. NSH Variable Header-Based Integrity > > Lastly, NSH MD Type 2 provides, via variable-length headers, > the ability to append cryptographic integrity protection to > the NSH packet. The implementation of such a scheme is > outside the scope of this document. > > The I-D is basically the third option. Ok. =C2=A0Please make it extra obvious that this is the case -- using the same words would be ideal. =C2=A78.2.2 (Confidentiality) is a lot less clear. Even though I still think that a formal Update to rfc8300 is the right thing to do, I would be very happy if there was (at least) some additional text included to clarify the expected relationship between the 2 documents. Thanks! Alvaro. > > > I know that we can interpret the update as "amends", but unless > > > I'm mistaken there is no formal IETF consensus on this. > > > > True. > > > > Without at least some text explaining the relationship between the > > requirements in this document and how they may be considered instead > > of the ones in rfc8300, I don't think this document is > > complete. For better or worse, the only tool we have right now to > > make that link clear is the Updates tag. > > > > > > Thanks! > > > > Alvaro. From nobody Mon Jul 12 13:24:13 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 385453A08F3; Mon, 12 Jul 2021 13:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 wONf5XBQsYyh; Mon, 12 Jul 2021 13:24:02 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 4DC113A08E2; Mon, 12 Jul 2021 13:24:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4GNwG95hJ8z1nttV; Mon, 12 Jul 2021 13:24:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1626121441; bh=/Tl97KKfWdBq7js84ZHr+kauYitAZFUx5x0edWqv+i8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=aV7Qf3KLqjt/97zCR2CoRetvGgig/Sx9UUTkdtjxzE1HkJnQ8itIFMuR1+6U8ZDH0 3MgPDUj96nMsBTGjRkiq0YytotSbHdoo9c1QdfnIsi3FvUnMa/bYjMaLF4wx9dp+sK 0otXYk6Fgp0aD5zQ35LPL47HSd4c/GySToxVv+fw= X-Quarantine-ID: <5EfaaaFbvNAH> X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4GNwG80MjKz1nsvf; Mon, 12 Jul 2021 13:23:59 -0700 (PDT) To: Alvaro Retana , The IESG , "Joel M. Halpern" Cc: gregimirsky@gmail.com, draft-ietf-sfc-nsh-integrity@ietf.org, sfc@ietf.org References: <162611498183.7775.3562397379733537345@ietfa.amsl.com> <1a5ae768-bf12-6d94-819c-7923e1f816ee@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <4448fbc9-5f24-9995-ccf5-cd7c9035f69a@joelhalpern.com> Date: Mon, 12 Jul 2021 16:23:57 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] Alvaro Retana's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 20:24:08 -0000 I am not at all sure I understand you. If youa re not arguing that this is somehow mandatory, then maybe you are arguing that this changes the security considerations in 8300 about transport. It doesn't. If it did, then yes, it would indeed update 8300. But the working group did not try to modify the transport requirements from 8300. Maybe someone will at some point. But this document doesn't. If you want it marked "updates" anyway, then I want a strong assurance from the IESG that some other AD won't turn around and tell us to remove the "updates" tag since the document makes no change to 8300. With that assurance, sure, we can give you a useless "updates" tag. Yours, Joel On 7/12/2021 4:08 PM, Alvaro Retana wrote: > Hi! > > I meant the discussion about this draft formally Updating rfc8300 — > which I would have hopped happened when processing/discussing this > document (not before). > > I’m assuming that discussion never happened. > > > BTW, I’m not asking for the new mechanism to be MTI — the current text > (at least to me) reads as if it is not.  I’m ok with that.  [IOW, an > Update to rfc8300 would “inherit” that characteristic.] > > Alvaro. > > On July 12, 2021 at 3:37:51 PM, Joel M. Halpern (jmh@joelhalpern.com > ) wrote: > >> Depending upon what you mean, either >> >> 1) The discussion never happened, because the action was not suggested. >> >> or, with a longer view >> >> 2) The discussion happened when 8300 was being approved. We agreed with >> the IESG that we would not define a mandatory-to-implement NSH security >> mechanism, but that we would add an optional NSH security mechanism. >> Which this draft does. >> >> Yours, >> Joel >> >> On 7/12/2021 3:29 PM, Alvaro Retana wrote: >> > Joel: >> > >> > Hi! >> > >> > I guess I missed where that discussion happened — probably buried in one >> > of the threads.  Can you please point me to it? >> > >> > Thanks! >> > >> > Alvaro. >> > >> > On July 12, 2021 at 3:23:28 PM, Joel M. Halpern (jmh@joelhalpern.com >> > >) wrote: >> > >> >> I find your description of this as a "required update to 8300" rather >> >> odd. The working group did not agree to make implementation of this >> >> mandatory for 8300. That would, indeed, be an update to 8300. This is >> >> just another feature that can be used with NSH. A useful feature. >> >> >> >> The security considerations do give lots of reasons to do this. But that >> >> is not the same as making it "required" for all implementations of 8300. >> >> >> >> Yours, >> >> Joel >> >> >> >> On 7/12/2021 2:36 PM, Alvaro Retana via Datatracker wrote: >> >> > Alvaro Retana has entered the following ballot position for >> >> > draft-ietf-sfc-nsh-integrity-06: No Objection >> >> > >> >> > When responding, please keep the subject line intact and reply to all >> >> > email addresses included in the To and CC lines. (Feel free to cut this >> >> > introductory paragraph, however.) >> >> > >> >> > >> >> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> >> >> > > >> >> > for more information about DISCUSS and COMMENT positions. >> >> > >> >> > >> >> > The document, along with other ballot positions, can be found here: >> >> > https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/ >> >> >> > > >> >> > >> >> > >> >> > >> >> > ---------------------------------------------------------------------- >> >> > COMMENT: >> >> > ---------------------------------------------------------------------- >> >> > >> >> > >> >> > (1) Given the required behavior specified in the Security Considerations >> >> > section... >> >> > >> >> > NSH data are exposed to several threats: >> >> > >> >> > o A man-in-the-middle attacker modifying the NSH data. >> >> > >> >> > o Attacker spoofing the NSH data. >> >> > >> >> > o Attacker capturing and replaying the NSH data. >> >> > >> >> > o Data carried in Context Headers revealing privacy-sensitive >> >> > information to attackers. >> >> > >> >> > o Attacker replacing the packet on which the NSH is imposed with a >> >> > bogus packet. >> >> > >> >> > In an SFC-enabled domain where the above attacks are possible, (1) >> >> > NSH data MUST be integrity-protected and replay-protected, and (2) >> >> > privacy-sensitive NSH metadata MUST be encrypted for confidentiality >> >> > preservation purposes. The Base and Service Path headers are not >> >> > encrypted. >> >> > >> >> > Why doesn't this document formally update rfc8300? Concerns that eventually >> >> > led to this solution have been expressed for several other documents, including >> >> > rfc8459 and rfc8979. >> >> > >> >> > It looks like the WG didn't consider the question of Updating the base NSH >> >> > specification. I believe that this document specifies a required update to >> >> > NSH, and would like the WG to consider formally Updating rfc8300. [My search >> >> > of the archive didn't find any related discussion -- did I miss it?] >> >> > >> >> > [Even though I consider this omission a serious oversight, I don't think this >> >> > issue raises to the level of a DISCUSS.] >> >> > >> >> > (2) §3: I find the use of normative language to describe requirements (that are >> >> > met in this same document) not the best use of rfc2119 language because any >> >> > interoperability concerns would result from the specification itself and not >> >> > the requirements. >> >> > >> >> > The use of rfc2119 keywords to describe requirements may result in confusion. >> >> > For example, "The solution MAY provide integrity protection for the Base >> >> > Header." -- as described later, protecting the Base Header is optional, but the >> >> > solution *does* provide integrity protection for it. IOW, the specification is >> >> > what is reflected in the requirement, but referring to the solution, not the >> >> > protection: providing integrity protection is not optional, using it is. A >> >> > better working would be: "The solution must provide optional integrity >> >> > protection for the Base Header." >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > sfc mailing list >> >> > sfc@ietf.org > > >> >> > https://www.ietf.org/mailman/listinfo/sfc >> >> >> > > >> >> > >> > >> > _______________________________________________ >> > sfc mailing list >> > sfc@ietf.org >> > https://www.ietf.org/mailman/listinfo/sfc >> >> > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Mon Jul 12 14:20:07 2021 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 089543A09C0; Mon, 12 Jul 2021 14:19:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Martin Duke via Datatracker To: "The IESG" Cc: draft-ietf-sfc-nsh-integrity@ietf.org, sfc-chairs@ietf.org, sfc@ietf.org, gregimirsky@gmail.com, gregimirsky@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Martin Duke Message-ID: <162612479801.8954.14059157357100669401@ietfa.amsl.com> Date: Mon, 12 Jul 2021 14:19:58 -0700 Archived-At: Subject: [sfc] Martin Duke's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 21:20:05 -0000 Martin Duke has entered the following ballot position for draft-ietf-sfc-nsh-integrity-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Two nits: Section 3 frequently uses the passive voice (“is instructed” “may be instructed”) and that makes it hard to understand who is doing the instruction. Please add subjects to at least the first of these sentences. You frequently use the structure “allows to [verb]”. There are many ways to fix this gramatically, but recommend simply deleting “allows to” and conjugating the verb correctly. From nobody Mon Jul 12 19:36:12 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3A43A0907 for ; Mon, 12 Jul 2021 19:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jlrxKLnGnF6 for ; Mon, 12 Jul 2021 19:36:06 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 3E71B3A0906 for ; Mon, 12 Jul 2021 19:36:06 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id k11so25271748ioa.5 for ; Mon, 12 Jul 2021 19:36:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=I7L3qWOK8DB7Z2oSliL2+8GOG3RaoWHliJxAB6Vatzc=; b=PprT2a9nd31/62TarBlBERmiEYzy8Hcr0tjrGfEKG5dF12v8p9Hwi+mMOU52DH5wAf MR/Vl5vaRnfC3i85HisFKKyN+fX5AZd2nGZuhNWgmRhXWrJQYvsNGKZrg7qwpZN0DnzL bQrAx9EVOHYdASOzpBSmx02VNxkirEWvsoTVnMeSq1SSTWZCtazx21axk9bNYpuC/ilX /RHYtJ9eAy+4TocMNegK0U5eZ84IlTddbbsR/30jFPNr2Ug4aRA/XX7l9t3QRrXIzvqP SfYnPOHrgY+YbBg8+1yCZbWazV/d1moFXOnehM/NICeVH2w9jPbfL9HclZs5IJK5eV1+ 6mow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=I7L3qWOK8DB7Z2oSliL2+8GOG3RaoWHliJxAB6Vatzc=; b=Vv1sFQfXzOJ7bmUOj63loo7qxw13SZ8x8Umst1iZTif9250HyZdvmT7WOytOuYFQmE umcx7EG1OpcRZTPB37XvAqgJMkSCY436GM482DRk2lf/GSH5St0DPlnqyqx6ofsR5dZ1 lGCcv0byv/08hF6lMW+p21edF0rjQxnIxpGrNvF1J1p/ifct+dF8UQphiQq8fDswiq1N v50PO7OTwbYupvRm3v38ODkEcR2kvLL0yiC1UBSUV9VKq7PIRtd2AkWwtmAkFWKOeX/P XTPbk0fxa8eStvRdXEkHn3GjIGLT+c1NQG3q7ubAULAVyS8A+YivAuxIVqAbzexGuIAj cPAQ== X-Gm-Message-State: AOAM533kAwhZoNsQqzY5pTC5mN0LwzxteTVyR0fBz32IkhVZYx5Gk/vz NUCTzbMG5yVXG9AL9MfrXqzKsn9kffPfglbsMWy84T6z X-Google-Smtp-Source: ABdhPJzFHzn2r2Hyk5ZQRDYa49S12Wh8tSZlkw51+QZ2Kvb+N8DXHLTLodeXXjJgpZSzH7ImkAcbWKrcnno/NPdbvvY= X-Received: by 2002:a6b:d00b:: with SMTP id x11mr1477762ioa.167.1626143764298; Mon, 12 Jul 2021 19:36:04 -0700 (PDT) MIME-Version: 1.0 References: <06d8079e-039e-6c2e-ee54-81c68fe153b9@joelhalpern.com> <40765399-61c1-99c6-9966-9a2a44e3d5ad@joelhalpern.com> In-Reply-To: <40765399-61c1-99c6-9966-9a2a44e3d5ad@joelhalpern.com> From: Donald Eastlake Date: Mon, 12 Jul 2021 22:35:53 -0400 Message-ID: To: "Joel M. Halpern" Cc: "sfc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006cc00305c6f8199f" Archived-At: Subject: Re: [sfc] IPR Confirmation for Re: Completing WG last call for draft-ietf-sfc-nsh-tlv X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2021 02:36:11 -0000 --0000000000006cc00305c6f8199f Content-Type: text/plain; charset="UTF-8" I am not aware of any IPR in this draft that has not been disclosed to the IETF. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Tue, Jun 1, 2021 at 6:56 PM Joel M. Halpern wrote: > Woudl all authors and contributors please confirm that all relevant > known IPR has been disclosed properly per IETF rules? Preferably, > confirm to the list. If there is some reason you can not, please > confirm to Jim, Greg, and me. > > Thank you, > Joel > > On 6/1/2021 11:33 AM, Joel M. Halpern wrote: > > The working group last call for > > https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-tlv/ is now > declared > > complete. While the chairs would have liked to see more response, we > > consider that there was sufficient response to say that the working > > group supports advancing this document to Proposed Standard RFC. > > > > The Editors will work with Greg Mirsky as document shepherd to resolve > > any remaining issues, and we will then pass the document to our area > > director for processing. > > > > Thank you all, > > Yours, > > Joel (and Jim) > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > --0000000000006cc00305c6f8199f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am not aware of any IPR in this draft that has not been = disclosed to the IETF.

Thanks,
Donald
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (= cell)
=C2=A02386 Panoramic Circle, Apopka, FL 32703 USA
=C2=A0d3e3e3@gmail.com


On Tue, Jun 1, 2021 at 6:56 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:
Woudl all authors and co= ntributors please confirm that all relevant
known IPR has been disclosed properly per IETF rules?=C2=A0 Preferably, confirm to the list.=C2=A0 If there is some reason you can not, please
confirm to Jim, Greg, and me.

Thank you,
Joel

On 6/1/2021 11:33 AM, Joel M. Halpern wrote:
> The working group last call for
> https://datatracker.ietf.org/doc/draft-= ietf-sfc-nsh-tlv/ is now declared
> complete.=C2=A0 While the chairs would have liked to see more response= , we
> consider that there was sufficient response to say that the working > group supports advancing this document to Proposed Standard RFC.
>
> The Editors will work with Greg Mirsky as document shepherd to resolve=
> any remaining issues, and we will then pass the document to our area <= br> > director for processing.
>
> Thank you all,
> Yours,
> Joel (and Jim)
>
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc
--0000000000006cc00305c6f8199f-- From nobody Mon Jul 12 22:40:03 2021 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 413233A17AA; Mon, 12 Jul 2021 22:39:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Erik Kline via Datatracker To: "The IESG" Cc: draft-ietf-sfc-nsh-integrity@ietf.org, sfc-chairs@ietf.org, sfc@ietf.org, gregimirsky@gmail.com, gregimirsky@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Erik Kline Message-ID: <162615479473.22691.18418787504447350645@ietfa.amsl.com> Date: Mon, 12 Jul 2021 22:39:55 -0700 Archived-At: Subject: [sfc] Erik Kline's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2021 05:39:56 -0000 Erik Kline has entered the following ballot position for draft-ietf-sfc-nsh-integrity-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [S7.{2,3}] [question] * Is the timestamp a part of the input to the MAC/encrypted metadata generation? If so, perhaps consider adding an explicit mention (perhaps I missed it). For that matter, I can't quite tell of some normalized version of the MAC#1/2 header overall is part of the input to the MAC/AAD generation or not. From nobody Mon Jul 12 23:14:24 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7219E3A18DD; Mon, 12 Jul 2021 23:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81lQ9F_bSAUJ; Mon, 12 Jul 2021 23:14:17 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (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 2842B3A18DB; Mon, 12 Jul 2021 23:14:17 -0700 (PDT) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfedar22.francetelecom.fr (ESMTP service) with ESMTPS id 4GP9MC0SRpz302N; Tue, 13 Jul 2021 08:14:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1626156855; bh=qgnrCqpuftU2owxmjh1FkXOz1Ys0CIweSRJhVcBaXHk=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=BKdFJMPxfC+QO/DjTiXhlUsM+LvzQuWLzmQsAqRRDilfOAu19VDcgquzS8LcHKNqY bw310bljcohIzAHSLSL2r9iWEAUnPPjdeUAxp+27d+2ZmAWLG3hBRW/8nal5GKSRwB 1Q34kXdizfzuPHLOHVKNawfDeWZvWtxSdPyZoNri2byz8YhMfty26d//zFTbzskE9P tWpORRupweCB8DBLJaOqwO7A9KmzGNgDTTMDkkWxe/dbWTRfkV82l0JONSvZZD4Lt/ 8OvJOFTcZB7Dhx69UUo1nJvA3XzUJ6ZZ+b4Xl4d8JfzP1JKowcxS2hm60R4k0EJrzB VSBW/Sx5oEWxA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfedar06.francetelecom.fr (ESMTP service) with ESMTPS id 4GP9MB64RHz3wbZ; Tue, 13 Jul 2021 08:14:14 +0200 (CEST) From: To: Alvaro Retana , The IESG CC: "sfc@ietf.org" , "gregimirsky@gmail.com" , "sfc-chairs@ietf.org" , "draft-ietf-sfc-nsh-integrity@ietf.org" Thread-Topic: Alvaro Retana's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) Thread-Index: AQHXd1pSBYVDUSV5zUqytv6A0CnmKatAbHHA Date: Tue, 13 Jul 2021 06:14:13 +0000 Message-ID: <32760_1626156854_60ED2F36_32760_382_1_787AE7BB302AE849A7480A190F8B9330353BE24E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162611498183.7775.3562397379733537345@ietfa.amsl.com> <23837_1626115941_60EC8F65_23837_478_1_787AE7BB302AE849A7480A190F8B9330353BD8C2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <13781_1626118873_60EC9AD9_13781_9_1_787AE7BB302AE849A7480A190F8B9330353BDA95@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Alvaro Retana's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2021 06:14:23 -0000 SGkgQWx2YXJvLCANCg0KU3VyZS4gSSBtYWRlIHRoZSBjaGFuZ2VzIHRoYXQgeW91IGNhbiB0cmFj ayBhdDogaHR0cHM6Ly90aW55dXJsLmNvbS9uc2gtaW50ZWdyaXR5LWxhdGVzdCANCg0KKiBBZGRl ZCBhIHBvaW50ZXIgdG8gOC4yIHdoZXJlIHRoZSB0cmFuc3BvcnQgc2VjdXJpdHkgaXMgZGlzY3Vz c2VkDQoqIGFkZGVkIGFuIGV4cGxpY2l0IG1lbnRpb24gb2YgdGhlIHRoaXJkIG9wdGlvbiB0aGF0 IHJlZmVycyB0byB0aGlzIEktRA0KDQpXZSBtYXkgdHdlYWsgdGhpcyBhIGxpdHRsZSBtb3JlLiAN Cg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6 IEFsdmFybyBSZXRhbmEgW21haWx0bzphcmV0YW5hLmlldGZAZ21haWwuY29tXQ0KPiBFbnZvecOp wqA6IGx1bmRpIDEyIGp1aWxsZXQgMjAyMSAyMjoxMw0KPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1l ZCBJTk5PVi9ORVQgPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+OyBUaGUNCj4gSUVTRyA8 aWVzZ0BpZXRmLm9yZz4NCj4gQ2PCoDogc2ZjQGlldGYub3JnOyBncmVnaW1pcnNreUBnbWFpbC5j b207IHNmYy1jaGFpcnNAaWV0Zi5vcmc7DQo+IGRyYWZ0LWlldGYtc2ZjLW5zaC1pbnRlZ3JpdHlA aWV0Zi5vcmcNCj4gT2JqZXTCoDogUkU6IEFsdmFybyBSZXRhbmEncyBObyBPYmplY3Rpb24gb24g ZHJhZnQtaWV0Zi1zZmMtbnNoLQ0KPiBpbnRlZ3JpdHktMDY6ICh3aXRoIENPTU1FTlQpDQo+IA0K PiBPbiBKdWx5IDEyLCAyMDIxIGF0IDM6NDE6MTMgUE0sIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20NCj4gKG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gKG1haWx0bzptb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tKSkNCj4gd3JvdGU6DQo+IA0KPiANCj4gLi4uDQo+ID4gPiBUaGUg b3V0Y29tZSBpcyB0aGF0IHRoZSByZXF1aXJlbWVudHMgaW4gcmZjODMwMCB3b3VsZCByZXN1bHQg aW4NCj4gbm90DQo+ID4gPiB1c2luZyB0aGlzIHNwZWNpZmljYXRpb24uDQo+ID4gPg0KPiA+DQo+ ID4gW01lZF0gTm90IHN1cmUgYWJvdXQgdGhpcyBnaXZlbiB0aGF0IFJGQzgzMDAgc2F5cyB0aGUg Zm9sbG93aW5nOg0KPiA+DQo+ID4gTlNIIGl0c2VsZiBkb2VzIG5vdCBtYW5kYXRlIHByb3RvY29s LXNwZWNpZmljIGludGVncml0eQ0KPiBwcm90ZWN0aW9uLg0KPiA+IEhvd2V2ZXIsIGlmIGFuIG9w ZXJhdG9yIGRlZW1zIHByb3RlY3Rpb24gaXMgcmVxdWlyZWQsIHNldmVyYWwNCj4gb3B0aW9ucw0K PiA+IGFyZSB2aWFibGU6DQo+ID4NCj4gPiAxLiBTRkYvU0YgTlNIIHZlcmlmaWNhdGlvbg0KPiA+ IC4uLg0KPiA+IDIuIFRyYW5zcG9ydCBTZWN1cml0eQ0KPiA+IC4uLg0KPiA+IDMuIE5TSCBWYXJp YWJsZSBIZWFkZXItQmFzZWQgSW50ZWdyaXR5DQo+ID4NCj4gPiBMYXN0bHksIE5TSCBNRCBUeXBl IDIgcHJvdmlkZXMsIHZpYSB2YXJpYWJsZS1sZW5ndGggaGVhZGVycywgdGhlDQo+ID4gYWJpbGl0 eSB0byBhcHBlbmQgY3J5cHRvZ3JhcGhpYyBpbnRlZ3JpdHkgcHJvdGVjdGlvbiB0byB0aGUgTlNI DQo+ID4gcGFja2V0LiBUaGUgaW1wbGVtZW50YXRpb24gb2Ygc3VjaCBhIHNjaGVtZSBpcyBvdXRz aWRlIHRoZSBzY29wZQ0KPiBvZg0KPiA+IHRoaXMgZG9jdW1lbnQuDQo+ID4NCj4gPiBUaGUgSS1E IGlzIGJhc2ljYWxseSB0aGUgdGhpcmQgb3B0aW9uLg0KPiANCj4gT2suIMKgUGxlYXNlIG1ha2Ug aXQgZXh0cmEgb2J2aW91cyB0aGF0IHRoaXMgaXMgdGhlIGNhc2UgLS0gdXNpbmcgdGhlDQo+IHNh bWUgd29yZHMgd291bGQgYmUgaWRlYWwuDQo+IA0KPiANCj4gwqc4LjIuMiAoQ29uZmlkZW50aWFs aXR5KSBpcyBhIGxvdCBsZXNzIGNsZWFyLg0KPiANCj4gDQo+IEV2ZW4gdGhvdWdoIEkgc3RpbGwg dGhpbmsgdGhhdCBhIGZvcm1hbCBVcGRhdGUgdG8gcmZjODMwMCBpcyB0aGUNCj4gcmlnaHQgdGhp bmcgdG8gZG8sIEkgd291bGQgYmUgdmVyeSBoYXBweSBpZiB0aGVyZSB3YXMgKGF0IGxlYXN0KQ0K PiBzb21lIGFkZGl0aW9uYWwgdGV4dCBpbmNsdWRlZCB0byBjbGFyaWZ5IHRoZSBleHBlY3RlZCBy ZWxhdGlvbnNoaXANCj4gYmV0d2VlbiB0aGUgMiBkb2N1bWVudHMuDQo+IA0KPiBUaGFua3MhDQo+ IA0KPiBBbHZhcm8uDQo+IA0KPiANCj4gDQo+ID4gPiA+IEkga25vdyB0aGF0IHdlIGNhbiBpbnRl cnByZXQgdGhlIHVwZGF0ZSBhcyAiYW1lbmRzIiwgYnV0DQo+IHVubGVzcw0KPiA+ID4gPiBJJ20g bWlzdGFrZW4gdGhlcmUgaXMgbm8gZm9ybWFsIElFVEYgY29uc2Vuc3VzIG9uIHRoaXMuDQo+ID4g Pg0KPiA+ID4gVHJ1ZS4NCj4gPiA+DQo+ID4gPiBXaXRob3V0IGF0IGxlYXN0IHNvbWUgdGV4dCBl eHBsYWluaW5nIHRoZSByZWxhdGlvbnNoaXAgYmV0d2Vlbg0KPiB0aGUNCj4gPiA+IHJlcXVpcmVt ZW50cyBpbiB0aGlzIGRvY3VtZW50IGFuZCBob3cgdGhleSBtYXkgYmUgY29uc2lkZXJlZA0KPiBp bnN0ZWFkDQo+ID4gPiBvZiB0aGUgb25lcyBpbiByZmM4MzAwLCBJIGRvbid0IHRoaW5rIHRoaXMg ZG9jdW1lbnQgaXMgY29tcGxldGUuDQo+IEZvcg0KPiA+ID4gYmV0dGVyIG9yIHdvcnNlLCB0aGUg b25seSB0b29sIHdlIGhhdmUgcmlnaHQgbm93IHRvIG1ha2UgdGhhdA0KPiBsaW5rDQo+ID4gPiBj bGVhciBpcyB0aGUgVXBkYXRlcyB0YWcuDQo+ID4gPg0KPiA+ID4NCj4gPiA+IFRoYW5rcyENCj4g PiA+DQo+ID4gPiBBbHZhcm8uDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpv aW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBv dSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBs b2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBt ZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0 IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBl bGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNs aW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZv cm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRz IG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQg bWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwg dXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0 ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRl cmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9k aWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Mon Jul 12 23:27:32 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E771C3A194E; Mon, 12 Jul 2021 23:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhCHVsciowdB; Mon, 12 Jul 2021 23:27:26 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (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 160133A194D; Mon, 12 Jul 2021 23:27:25 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr25.francetelecom.fr (ESMTP service) with ESMTPS id 4GP9fM72NHzCr5Z; Tue, 13 Jul 2021 08:27:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1626157644; bh=0UYxP5+jnFSPu1smQ7NS3jppzNHgi79r0px1g4yvBlQ=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=DA8Y7gVnYhV8PU8OSR1imIsxMjqf5K6sVnN4Ctf11CRqO31O+vTjFSVoVG1iindDp KzMyDbvfOs/wR20uFm2bZsq4CgD7W8c76L6hAGRgsGqmwxR/3uiCEp1vMptq5QIzES uY3kNJbLUdt6qkSKXXSvTThf7iNRbemDjDLmdS4RWPgK2V0XJOVRCqyp1XAE3kNyPb /vEV15xsJ99nZtHnTn27O8NgVLr/SPiQPFedrIuA7SbjeXYAicilV3P9wwQEJqEN9D JbDDe7sfCTT5lCKBnDF2wi/IIiWqbbzuz16N6ConOe+qzsXL3Cd4A9MUa3Bb/tjb0b fPA/MLsZV46Kg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfednr02.francetelecom.fr (ESMTP service) with ESMTPS id 4GP9fM67rvz8sYK; Tue, 13 Jul 2021 08:27:23 +0200 (CEST) From: To: Martin Duke , The IESG CC: "draft-ietf-sfc-nsh-integrity@ietf.org" , "sfc-chairs@ietf.org" , "sfc@ietf.org" , "gregimirsky@gmail.com" Thread-Topic: Martin Duke's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) Thread-Index: AQHXd2Oz12VlGFlidEyrJphFP90lA6tAbxaw Date: Tue, 13 Jul 2021 06:27:22 +0000 Message-ID: <19344_1626157643_60ED324B_19344_231_1_787AE7BB302AE849A7480A190F8B9330353BE272@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162612479801.8954.14059157357100669401@ietfa.amsl.com> In-Reply-To: <162612479801.8954.14059157357100669401@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Martin Duke's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2021 06:27:31 -0000 SGkgTWFydGluLA0KDQpUaGFua3MgZm9yIHRoZSBjb21tZW50cy4gDQoNCkZpeGVkIHRoZSBuaXRz IGFzIHlvdSBjYW4gc2VlIGF0OiBodHRwczovL3Rpbnl1cmwuY29tL25zaC1pbnRlZ3JpdHktbGF0 ZXN0Lg0KDQpUaGVyZSBhcmUgc29tZSBmZXcgImluc3RydWN0ZWQiIGluIHRoZSB0ZXh0LCBidXQg SSBwcmVmZXIgdG8gbGVhdmUgdGhlIHRleHQgYXMgaXQgaXMuICANCg0KQ2hlZXJzLA0KTWVkDQoN Cj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IE1hcnRpbiBEdWtlIHZpYSBE YXRhdHJhY2tlciBbbWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmddDQo+IEVudm95w6nCoDogbHVuZGkg MTIganVpbGxldCAyMDIxIDIzOjIwDQo+IMOAwqA6IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0K PiBDY8KgOiBkcmFmdC1pZXRmLXNmYy1uc2gtaW50ZWdyaXR5QGlldGYub3JnOyBzZmMtY2hhaXJz QGlldGYub3JnOw0KPiBzZmNAaWV0Zi5vcmc7IGdyZWdpbWlyc2t5QGdtYWlsLmNvbTsgZ3JlZ2lt aXJza3lAZ21haWwuY29tDQo+IE9iamV0wqA6IE1hcnRpbiBEdWtlJ3MgTm8gT2JqZWN0aW9uIG9u IGRyYWZ0LWlldGYtc2ZjLW5zaC1pbnRlZ3JpdHktDQo+IDA2OiAod2l0aCBDT01NRU5UKQ0KPiAN Cj4gTWFydGluIER1a2UgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24g Zm9yDQo+IGRyYWZ0LWlldGYtc2ZjLW5zaC1pbnRlZ3JpdHktMDY6IE5vIE9iamVjdGlvbg0KPiAN Cj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBh bmQgcmVwbHkgdG8NCj4gYWxsIGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5k IENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvDQo+IGN1dCB0aGlzIGludHJvZHVjdG9yeSBwYXJhZ3Jh cGgsIGhvd2V2ZXIuKQ0KPiANCj4gDQo+IFBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRm Lm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLQ0KPiBjcml0ZXJpYS5odG1sDQo+IGZvciBtb3Jl IGluZm9ybWF0aW9uIGFib3V0IERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiANCj4g DQo+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4g YmUgZm91bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1zZmMtbnNoLWludGVncml0eS8NCj4gDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0N Cj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0NCj4gDQo+IFR3byBuaXRzOg0KPiANCj4g U2VjdGlvbiAzIGZyZXF1ZW50bHkgdXNlcyB0aGUgcGFzc2l2ZSB2b2ljZSAo4oCcaXMgaW5zdHJ1 Y3RlZOKAnSDigJxtYXkgYmUNCj4gaW5zdHJ1Y3RlZOKAnSkgYW5kIHRoYXQgbWFrZXMgaXQgaGFy ZCB0byB1bmRlcnN0YW5kIHdobyBpcyBkb2luZyB0aGUNCj4gaW5zdHJ1Y3Rpb24uDQo+IFBsZWFz ZSBhZGQgc3ViamVjdHMgdG8gYXQgbGVhc3QgdGhlIGZpcnN0IG9mIHRoZXNlIHNlbnRlbmNlcy4N Cj4gDQo+IFlvdSBmcmVxdWVudGx5IHVzZSB0aGUgc3RydWN0dXJlIOKAnGFsbG93cyB0byBbdmVy Yl3igJ0uIFRoZXJlIGFyZSBtYW55DQo+IHdheXMgdG8gZml4IHRoaXMgZ3JhbWF0aWNhbGx5LCBi dXQgcmVjb21tZW5kIHNpbXBseSBkZWxldGluZyDigJxhbGxvd3MNCj4gdG/igJ0gYW5kIGNvbmp1 Z2F0aW5nIHRoZSB2ZXJiIGNvcnJlY3RseS4NCj4gDQo+IA0KDQoKX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2Fn ZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25z IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBl dHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2 b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVy CmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50 ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVy YXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2Ug YSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBh bmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2Vk IGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5v dCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMg ZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMg dGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3Uu Cgo= From nobody Mon Jul 12 23:42:50 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECAAA3A1992; Mon, 12 Jul 2021 23:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdqzTkMVo6kU; Mon, 12 Jul 2021 23:42:44 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (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 4EE643A198C; Mon, 12 Jul 2021 23:42:44 -0700 (PDT) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfedar26.francetelecom.fr (ESMTP service) with ESMTPS id 4GPB0257GczFr4s; Tue, 13 Jul 2021 08:42:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1626158562; bh=1ZDg8/KYIem29BSiHG7aVML0r+8v8l47QPMsYBFwp2M=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=GYHN2KiN3uuMf1458/MANV7HQ6KW8V383briMWiVeSOrBeDwwEActYLr5LaYmxMoX ZVmH/5REykq7WnDvFP+mCDY9fIUzr9F/qdgsK70lk0aQjB8BusAXwae/pF5GHQavCn urChZDIiGFMf7Lu3KIARedSYNdZ8/IDfLL7FUft8956dlO9EzVvqvXSWnEoGEU0YS2 fj983VkojDAhVaYGWjg7pGy42w+jlrUYCA+KQiJ0EXuS/x/oTJ6Bhh41wv18SAbJyt Hc/o4DiOHkZLzczzOD49II/2FNN9NY47ca3AHaXFF/i2m95j1/3JHU3orkg7PT6Aap gs5/7qJhZ79nw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfedar01.francetelecom.fr (ESMTP service) with ESMTPS id 4GPB023gyDzBrLQ; Tue, 13 Jul 2021 08:42:42 +0200 (CEST) From: To: Erik Kline , The IESG CC: "draft-ietf-sfc-nsh-integrity@ietf.org" , "sfc-chairs@ietf.org" , "sfc@ietf.org" , "gregimirsky@gmail.com" Thread-Topic: Erik Kline's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) Thread-Index: AQHXd6mEEuMbRU++qEaPKPnejM/VEqtAbdeA Date: Tue, 13 Jul 2021 06:42:41 +0000 Message-ID: <9944_1626158562_60ED35E2_9944_50_1_787AE7BB302AE849A7480A190F8B9330353BE296@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162615479473.22691.18418787504447350645@ietfa.amsl.com> In-Reply-To: <162615479473.22691.18418787504447350645@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Erik Kline's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2021 06:42:49 -0000 SGkgRXJpaywgDQoNClRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLiANCg0KVGhlIHRpbWVzdGFtcCBp cyBub3QgYW4gaW5wdXQgZm9yIGVuY3J5cHRpbmcgZGF0YS4gSG93ZXZlciwgaXQgaXMgcGFydCBv ZiB0aGUgZGF0YSBjb3ZlcmVkIGJ5IGludGVncml0eS4gVGhpcyBpcyBzaG93biwgZm9yIGV4YW1w bGUsIGluIEZpZ3VyZXMgNiBhbmQgNyBhbmQgdGhlICJNZXNzYWdlIEF1dGhlbnRpY2F0aW9uIENv ZGUiIGRlc2NyaXB0aW9uLiANCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3Jp Z2luZS0tLS0tDQo+IERlwqA6IEVyaWsgS2xpbmUgdmlhIERhdGF0cmFja2VyIFttYWlsdG86bm9y ZXBseUBpZXRmLm9yZ10NCj4gRW52b3nDqcKgOiBtYXJkaSAxMyBqdWlsbGV0IDIwMjEgMDc6NDAN Cj4gw4DCoDogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQo+IENjwqA6IGRyYWZ0LWlldGYtc2Zj LW5zaC1pbnRlZ3JpdHlAaWV0Zi5vcmc7IHNmYy1jaGFpcnNAaWV0Zi5vcmc7DQo+IHNmY0BpZXRm Lm9yZzsgZ3JlZ2ltaXJza3lAZ21haWwuY29tOyBncmVnaW1pcnNreUBnbWFpbC5jb20NCj4gT2Jq ZXTCoDogRXJpayBLbGluZSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLXNmYy1uc2gtaW50 ZWdyaXR5LQ0KPiAwNjogKHdpdGggQ09NTUVOVCkNCj4gDQo+IEVyaWsgS2xpbmUgaGFzIGVudGVy ZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+IGRyYWZ0LWlldGYtc2ZjLW5z aC1pbnRlZ3JpdHktMDY6IE5vIE9iamVjdGlvbg0KPiANCj4gV2hlbiByZXNwb25kaW5nLCBwbGVh c2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8NCj4gYWxsIGVtYWls IGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRv DQo+IGN1dCB0aGlzIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiANCj4gDQo+ IFBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNj dXNzLQ0KPiBjcml0ZXJpYS5odG1sDQo+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IERJU0NV U1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiANCj4gDQo+IFRoZSBkb2N1bWVudCwgYWxvbmcg d2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4gaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zZmMtbnNoLWludGVncml0eS8N Cj4gDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4gLS0NCj4gDQo+IFtTNy57MiwzfV0gW3F1ZXN0aW9uXQ0KPiANCj4gKiBJcyB0aGUgdGlt ZXN0YW1wIGEgcGFydCBvZiB0aGUgaW5wdXQgdG8gdGhlIE1BQy9lbmNyeXB0ZWQgbWV0YWRhdGEN Cj4gICBnZW5lcmF0aW9uPyAgSWYgc28sIHBlcmhhcHMgY29uc2lkZXIgYWRkaW5nIGFuIGV4cGxp Y2l0IG1lbnRpb24NCj4gICAocGVyaGFwcyBJIG1pc3NlZCBpdCkuDQo+IA0KPiAgIEZvciB0aGF0 IG1hdHRlciwgSSBjYW4ndCBxdWl0ZSB0ZWxsIG9mIHNvbWUgbm9ybWFsaXplZCB2ZXJzaW9uIG9m DQo+IHRoZQ0KPiAgIE1BQyMxLzIgaGVhZGVyIG92ZXJhbGwgaXMgcGFydCBvZiB0aGUgaW5wdXQg dG8gdGhlIE1BQy9BQUQNCj4gZ2VuZXJhdGlvbg0KPiAgIG9yIG5vdC4NCj4gDQo+IA0KDQoKX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBk ZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9p dmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0 b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWls bGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBs ZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2Nl cHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRl IHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4K ClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlh bCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7 CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBh dXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJs ZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lm aWVkLgpUaGFuayB5b3UuCgo= From nobody Tue Jul 13 01:29:29 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3AC3A09C0; Tue, 13 Jul 2021 01:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org 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 87czC_xCVWKj; Tue, 13 Jul 2021 01:29:23 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (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 0A9FB3A09B5; Tue, 13 Jul 2021 01:29:22 -0700 (PDT) Received: from smtpclient.apple (unknown [85.131.57.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 1B6B660034E; Tue, 13 Jul 2021 11:29:12 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1626164952; bh=WwL+lbPGbidvQgzQyqhZG/cDwDmB6HbHYBKsxBd1DrQ=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=nM+796vyIVogdjCzG7NGsRvlmUfx4/fWJ3X8+eHyd7IndVNuaJ8hOX8DpetqipFHf zHLaBlce+Fpt3C8XMBjwoqxXj0pJFeYBSgA+iPB5zareqvo71Wh1dWHSeGTUvhJFpT fVfEdhr4/yUo/vFaMfkHIuP4bomwvGUtMCyrrZEI= From: Lars Eggert Message-Id: <13F1FACA-057F-440C-821D-80E69E953754@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_D61150D2-E625-44CF-B505-BEBCDBC8EE2C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Tue, 13 Jul 2021 11:29:11 +0300 In-Reply-To: <5351_1626116550_60EC91C6_5351_270_1_787AE7BB302AE849A7480A190F8B9330353BD911@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Cc: The IESG , "gregimirsky@gmail.com" , "draft-ietf-sfc-nsh-integrity@ietf.org" , "sfc-chairs@ietf.org" , "sfc@ietf.org" To: mohamed.boucadair@orange.com References: <162610118774.23532.4225033232156129750@ietfa.amsl.com> <5351_1626116550_60EC91C6_5351_270_1_787AE7BB302AE849A7480A190F8B9330353BD911@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> X-MailScanner-ID: 1B6B660034E.A6543 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [sfc] Lars Eggert's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2021 08:29:28 -0000 --Apple-Mail=_D61150D2-E625-44CF-B505-BEBCDBC8EE2C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, >> Given that, I am surprised this document doesn't formally update >> RFC8300? >=20 > [Med] Alvaro raised a similar comment. Not reiterating the same answer = here. OK, I will monitor that discussion thread. >> Found terminology that should be reviewed for inclusivity: >> * Term "master"; alternatives might be "active", "central", >> "initiator", >=20 > [Med] Not sure what is problematic in saying "... master their = complexity .." Well, it's a term that some find problematic. Also, wouldn't "control = their complexity" be more precise? Thanks, Lars --Apple-Mail=_D61150D2-E625-44CF-B505-BEBCDBC8EE2C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmDtTtcACgkQVLXDCb9w wVdVdQ//S21NxPoYyWxMbCAcB8t0PyX5ndF/T4kqZhzIR6YJZXXNZAUAFarLYzBs JwSC+p2C7frcbRlt62grJHdVQMXG50Y8l8PaWWxyLkHqRNWWw+3WouJmQ0lTfdL+ xCQYD3+37P27CF1dLDJUGBzyCDvPzK2GkeC9M0QcZ7MhReVJ0PD+2VOt+hbK85jY 9YRaoHG39R6ZvMaRRVBE8f0sX6N/6crwie0qIakDc0Hn4/DKtmNWC5pFbbDBN1cG WsiTPl/cNdEBBP0WuoUc3r/c04lKrvJfSNXFsOjAcsxMH3Wwjk43R87/hJAeVrkZ ZxH71YAp911UjdfoxBhWzC1tUpPQzRHnZ2reYXcjLYc6AHnGgkAkRbqPTOhXlS6X rftDJgJB3DN4k6/4As8HDS1ilcpwayX5gXinH9aVS621DsLkeCqfWr2/Wd/X5Id7 EAowojpWuCcZB4hTd30WeJ3Tniw/pWFB7sTY0Od3Q74GPM/vG6e3Z1w4pQvfGjoI sh6c3wMXhpVgM77/WRVZiG3xWHK8Y1AELTJG6ir2PplEhWxKBH/KChf3fAAQ1U7m FKG7e2XLdBWtukyitEZM3bF5EryeNqGdkkR471kBSYUa4+hippI6PNWKTYPjyUmV 3D13HwLBQoJDTS1sFxdglmqk6E8b2ojt1KBNQzeL9xIQcIyvnZE= =KTVK -----END PGP SIGNATURE----- --Apple-Mail=_D61150D2-E625-44CF-B505-BEBCDBC8EE2C-- From nobody Tue Jul 13 03:36:59 2021 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B357D3A128F; Tue, 13 Jul 2021 03:36:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Zaheduzzaman Sarker via Datatracker To: "The IESG" Cc: draft-ietf-sfc-nsh-integrity@ietf.org, sfc-chairs@ietf.org, sfc@ietf.org, gregimirsky@gmail.com, gregimirsky@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Zaheduzzaman Sarker Message-ID: <162617261371.15907.6050785043086194503@ietfa.amsl.com> Date: Tue, 13 Jul 2021 03:36:53 -0700 Archived-At: Subject: [sfc] Zaheduzzaman Sarker's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2021 10:36:54 -0000 Zaheduzzaman Sarker has entered the following ballot position for draft-ietf-sfc-nsh-integrity-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the efforts on this specification. I have following non-blocking comments those I believe would improve the document if addressed -- * I agree with Alvaro and Lars's comment about updating 8300. Would like to get response(s) to their comments. * I think it will be helpful to explicitly mention if integrity and confidentiality by the transport encapsulation is needed or not when this specification is in use. This specification definitely says that one does not need to relay on the service provided by the transport encapsulation but it does not says that those services are not longer required. * Section 1 : says - "This specification fills that gap. Concretely, this document adds integrity protection and optional encryption of sensitive metadata directly to the NSH (Section 4);" Does this specification extends the use of NSH in multiple SFC domain? My little understanding of NSH says it is SFC domain specific and within one SFC domain the devices a vetted to be trusted. I think it will be very helpful to add zest from the section 3.2.1. of I-D.arkko-farrell-arch-model-t here. * Section 6 : The epoch is 1970-01-01T00:00Z in UTC time. Note this epoch value is different from the one used in Section 6 of [RFC5905]. It would be great if we can add the implications of the difference. Now I don't know what it means. From nobody Tue Jul 13 04:06:34 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A7F3A13C3; Tue, 13 Jul 2021 04:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PGy4xbBHPGR; Tue, 13 Jul 2021 04:06:24 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (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 491A03A13C2; Tue, 13 Jul 2021 04:06:24 -0700 (PDT) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfedar20.francetelecom.fr (ESMTP service) with ESMTPS id 4GPHrG2KYRz8tww; Tue, 13 Jul 2021 13:06:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1626174382; bh=Xx+SNFyykMdTiDpy2wNSLdLrCwoJPm7FgJBWWvLgLsE=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=a2Fi3D+PjTgoWd51u2jt/fT8SB7q5AFwknFvPv2D5X5EJ6DV5odwMueCke87Xz6mM J4FnH73+YQ2l9sxqoBk+380SbdTGQGJCklsIWsh9KrcVzvTKFrIaSDzzcqPOR/YlR0 VoswUR6DNsgWue3UrWEdP45jdbNBQ2V4XfCjt+DNI75ERqq83hf7sVXhehNTn+01uO lJ2lSFTqSMEUGhefEr/nGSuXYLsxz23jaP+eGuB/OL8D/1vab7tU3cigZjf1mzMmm6 9Qv5tPsEtfKDsgxXkXDchv+8biRMaaceUjbE8NnJk7AKqMWw3afWrCWs+H9/ErsHy7 EXuBo22+6l2ZQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfedar02.francetelecom.fr (ESMTP service) with ESMTPS id 4GPHrG0rBWzCqkV; Tue, 13 Jul 2021 13:06:22 +0200 (CEST) From: To: Zaheduzzaman Sarker , The IESG CC: "draft-ietf-sfc-nsh-integrity@ietf.org" , "sfc-chairs@ietf.org" , "sfc@ietf.org" , "gregimirsky@gmail.com" Thread-Topic: Zaheduzzaman Sarker's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) Thread-Index: AQHXd9MBbrum3ehGokamLtK1wKZXz6tAt3dQ Date: Tue, 13 Jul 2021 11:06:21 +0000 Message-ID: <3763_1626174382_60ED73AE_3763_126_1_787AE7BB302AE849A7480A190F8B9330353BE5BA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162617261371.15907.6050785043086194503@ietfa.amsl.com> In-Reply-To: <162617261371.15907.6050785043086194503@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Zaheduzzaman Sarker's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2021 11:06:30 -0000 SGkgWmFoZWQsIA0KDQpUaGFua3MgZm9yIHRoZSByZXZpZXcuIA0KDQpQbGVhc2Ugc2VlIGlubGlu ZS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBE ZcKgOiBaYWhlZHV6emFtYW4gU2Fya2VyIHZpYSBEYXRhdHJhY2tlciBbbWFpbHRvOm5vcmVwbHlA aWV0Zi5vcmddDQo+IEVudm95w6nCoDogbWFyZGkgMTMganVpbGxldCAyMDIxIDEyOjM3DQo+IMOA wqA6IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KPiBDY8KgOiBkcmFmdC1pZXRmLXNmYy1uc2gt aW50ZWdyaXR5QGlldGYub3JnOyBzZmMtY2hhaXJzQGlldGYub3JnOw0KPiBzZmNAaWV0Zi5vcmc7 IGdyZWdpbWlyc2t5QGdtYWlsLmNvbTsgZ3JlZ2ltaXJza3lAZ21haWwuY29tDQo+IE9iamV0wqA6 IFphaGVkdXp6YW1hbiBTYXJrZXIncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1zZmMtbnNo LQ0KPiBpbnRlZ3JpdHktMDY6ICh3aXRoIENPTU1FTlQpDQo+IA0KPiBaYWhlZHV6emFtYW4gU2Fy a2VyIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiBkcmFm dC1pZXRmLXNmYy1uc2gtaW50ZWdyaXR5LTA2OiBObyBPYmplY3Rpb24NCj4gDQo+IFdoZW4gcmVz cG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRv DQo+IGFsbCBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4g KEZlZWwgZnJlZSB0bw0KPiBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVy LikNCj4gDQo+IA0KPiBQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9z dGF0ZW1lbnQvZGlzY3Vzcy0NCj4gY3JpdGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlv biBhYm91dCBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gDQo+IA0KPiBUaGUgZG9j dW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhl cmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2ZjLW5z aC1pbnRlZ3JpdHkvDQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tDQo+IENPTU1FTlQ6 DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+IC0tDQo+IA0KPiBUaGFua3MgZm9yIHRoZSBlZmZvcnRzIG9uIHRo aXMgc3BlY2lmaWNhdGlvbi4NCj4gDQo+IEkgaGF2ZSBmb2xsb3dpbmcgbm9uLWJsb2NraW5nIGNv bW1lbnRzIHRob3NlIEkgYmVsaWV2ZSB3b3VsZCBpbXByb3ZlDQo+IHRoZSBkb2N1bWVudCBpZiBh ZGRyZXNzZWQgLS0NCj4gDQo+ICogSSBhZ3JlZSB3aXRoIEFsdmFybyBhbmQgTGFycydzIGNvbW1l bnQgYWJvdXQgdXBkYXRpbmcgODMwMC4gV291bGQNCj4gbGlrZSB0byBnZXQNCj4gcmVzcG9uc2Uo cykgdG8gdGhlaXIgY29tbWVudHMuDQoNCltNZWRdIEFscmVhZHkgcmVwbGllZCB0byB0aG9zZS4g DQoNCj4gDQo+ICogSSB0aGluayBpdCB3aWxsIGJlIGhlbHBmdWwgdG8gZXhwbGljaXRseSBtZW50 aW9uIGlmIGludGVncml0eSBhbmQNCj4gY29uZmlkZW50aWFsaXR5IGJ5IHRoZSB0cmFuc3BvcnQg ZW5jYXBzdWxhdGlvbiBpcyBuZWVkZWQgb3Igbm90IHdoZW4NCj4gdGhpcyBzcGVjaWZpY2F0aW9u IGlzIGluIHVzZS4gVGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluaXRlbHkgc2F5cw0KPiB0aGF0IG9u ZSBkb2VzIG5vdCBuZWVkIHRvIHJlbGF5IG9uIHRoZSBzZXJ2aWNlIHByb3ZpZGVkIGJ5IHRoZQ0K PiB0cmFuc3BvcnQgZW5jYXBzdWxhdGlvbiBidXQgaXQgZG9lcyBub3Qgc2F5cyB0aGF0IHRob3Nl IHNlcnZpY2VzIGFyZQ0KPiBub3QgbG9uZ2VyIHJlcXVpcmVkLg0KDQpbTWVkXSBXZSBkb24ndCBz YXkgc28gYmVjYXVzZSB0aGlzIGlzIGRlcGxveW1lbnQtc3BlY2lmaWMuIE9uZSBtYXkgZGVwbG95 IGhTRkMgKFJGQzg0NTkpIHdpdGggdHJhbnNwb3J0IHNlY3VyaXR5IHRvIGludGVyY29ubmVjdCBs b3dlci1sZXZlbCBkb21haW5zLCBidXQgdXNlIHRoaXMgc3BlYyB3aXRoaW4gYSBsb3dlci1sZXZl bCBkb21haW4uIA0KDQo+IA0KPiAqIFNlY3Rpb24gMSA6IHNheXMgLQ0KPiAgICAgIlRoaXMgc3Bl Y2lmaWNhdGlvbiBmaWxscyB0aGF0IGdhcC4gIENvbmNyZXRlbHksIHRoaXMgZG9jdW1lbnQNCj4g YWRkcw0KPiAgICBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBhbmQgb3B0aW9uYWwgZW5jcnlwdGlvbiBv ZiBzZW5zaXRpdmUNCj4gbWV0YWRhdGENCj4gICAgZGlyZWN0bHkgdG8gdGhlIE5TSCAoU2VjdGlv biA0KTsiDQo+IA0KPiAgIERvZXMgdGhpcyBzcGVjaWZpY2F0aW9uIGV4dGVuZHMgdGhlIHVzZSBv ZiBOU0ggaW4gbXVsdGlwbGUgU0ZDDQo+IGRvbWFpbj8NCg0KW01lZF0gTm8sIHdlIGRvbid0IGFz IHdlIGFkaGVyZSB0byBSRkM3NjY1IGFuZCBSRkM4MzAwLiANCg0KRnV0dXJlIGRvY3VtZW50cyBt YXkgZGVmaW5lIGFuIHVwZGF0ZWQgNzY2NSB0byBkZXNjcmliZSB0aGUgaW50ZXItZG9tYWluIGNh c2UuIFRoaXMgc3BlYyBtYXkgc29sdmUgc29tZSBvZiB0aGUgaW5oZXJlbnQgaXNzdWVzLCBidXQg aXQgaXMgb3V0IG9mIHNjb3BlIHRvIGRpc2N1c3MgdGhvc2UgaW4gdGhpcyBJLUQuDQoNClRpbGwg dGhpcyBoYXBwZW5zLCB0aGUgc2NvcGUgaXMgc3RpbGwgd2hhdCBpcyByZWNvcmRlZCBpbiBSRkM3 NjY1OiANCg0KPT0NCiAgIFRoZSBhcmNoaXRlY3R1cmUgZGVzY3JpYmVkIGhlcmVpbiBpcyBhc3N1 bWVkIHRvIGJlIGFwcGxpY2FibGUgdG8gYQ0KICAgc2luZ2xlIG5ldHdvcmsgYWRtaW5pc3RyYXRp dmUgZG9tYWluLiAgV2hpbGUgaXQgaXMgcG9zc2libGUgZm9yIHRoZQ0KICAgYXJjaGl0ZWN0dXJh bCBwcmluY2lwbGVzIGFuZCBjb21wb25lbnRzIHRvIGJlIGFwcGxpZWQgdG8gaW50ZXItZG9tYWlu DQogICBTRkNzLCB0aGVzZSBhcmUgbGVmdCBmb3IgZnV0dXJlIHN0dWR5Lg0KPT0NCg0KDQogTXkN Cj4gICBsaXR0bGUgdW5kZXJzdGFuZGluZyBvZiBOU0ggc2F5cyBpdCBpcyBTRkMgZG9tYWluIHNw ZWNpZmljIGFuZA0KPiB3aXRoaW4gb25lIFNGQw0KPiAgIGRvbWFpbiB0aGUgZGV2aWNlcyBhIHZl dHRlZCB0byBiZSB0cnVzdGVkLiBJIHRoaW5rIGl0IHdpbGwgYmUgdmVyeQ0KPiBoZWxwZnVsIHRv DQo+ICAgYWRkIHplc3QgZnJvbSB0aGUgc2VjdGlvbiAzLjIuMS4gb2YgSS1ELmFya2tvLWZhcnJl bGwtYXJjaC1tb2RlbC10DQo+IGhlcmUuDQo+IA0KPiAqIFNlY3Rpb24gNiA6DQo+IA0KPiAgICBU aGUgZXBvY2ggaXMgMTk3MC0wMS0wMVQwMDowMFogaW4gVVRDIHRpbWUuICBOb3RlIHRoaXMgZXBv Y2gNCj4gdmFsdWUNCj4gICAgICAgaXMgZGlmZmVyZW50IGZyb20gdGhlIG9uZSB1c2VkIGluIFNl Y3Rpb24gNiBvZiBbUkZDNTkwNV0uDQo+IA0KPiAgICBJdCB3b3VsZCBiZSBncmVhdCBpZiB3ZSBj YW4gYWRkIHRoZSBpbXBsaWNhdGlvbnMgb2YgdGhlDQo+IGRpZmZlcmVuY2UuIE5vdyBJDQo+ICAg IGRvbid0IGtub3cgd2hhdCBpdCBtZWFucy4NCj4gDQo+IA0KDQpbTWVkXSBUaGUgaW1wbGljYXRp b24gaXMgYmFzaWNhbGx5IHdoYXQgaXMgbWVudGlvbmVkIHVuZGVyIHdyYXBhcm91bmQgYnVsbGV0 OiAiVGhlIG5leHQgd3JhcGFyb3VuZCB3aWxsIG9jY3VyIGluIHRoZSB5ZWFyIDIxMDYiLiBJZiB3 ZSBtYWludGFpbmVkIHRoZSBlcG9jaCBpbiBSRkM1OTA1LCB0aGUgd3JhcGFyb3VuZCB3b3VsZCBi ZSBpbiAyMDM2LiBUd2Vha2VkIHRoZSB0ZXh0IHRvIG1lbnRpb24gdGhpcy4gVGhhbmtzLiANCg0K DQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250 ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQg bmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNh bnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIs IHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNp IHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50 IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNh YmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBN ZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZp ZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBi eSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0 aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVy cm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5k IGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90 IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3Ig ZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Tue Jul 13 05:17:42 2021 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 509B53A0101; Tue, 13 Jul 2021 05:17:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-sfc-nsh-integrity@ietf.org, sfc-chairs@ietf.org, sfc@ietf.org, gregimirsky@gmail.com, gregimirsky@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <162617866082.13596.2398814614966286542@ietfa.amsl.com> Date: Tue, 13 Jul 2021 05:17:41 -0700 Archived-At: Subject: [sfc] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-sfc-n?= =?utf-8?q?sh-integrity-06=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2021 12:17:41 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-sfc-nsh-integrity-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for the work put into this document. Special thanks to Greg Mirsky for his shepherding especially about his summary of the WG consensus. Please find below some blocking DISCUSS point (which should be easy to fix), some non-blocking COMMENT points (but replies would be appreciated), and one nit. I hope that this helps to improve the document, Regards, -éric == DISCUSS == I failed to spot the order of the operations for the integrity and confidentiality operations, e.g., I did not find on what the HMAC is computed: in the unencrypted or encrypted field ? -- Section 5.1 -- What is the unit of "key length", I assume a length expressed in octets but it is not specified. -- Section 7.2 -- What is the "A" used in the HMAC computation ? The formula specifies HMAC-SHA-256-128() but what if another HMAC is used ? Section 7.3 use MAC() which is more flexible. As the MAC field is included in the integrity protected header, please specify the value of this field when computing the HMAC (I assume 0 but let's be clear) -- Section 7.5 -- What is the expected behavior when a NSH does not contain a "MAC and Encrypted Metadata" Context Header ? §1 hints to packet drop ? Should there be a local policy for this case ? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I second Alvaro's and Lars' point about formally updating RFC 8300. Quite often in the text "privacy-sensitive metadata" is used but encryption is not only required for privacy but also to protect operational data from attackers (i.e., not linked to privacy), is there a real need to qualify "metadata" with "privacy-sensitive", i.e., "confidential metadata" may be more appropriate ? -- Section 4.1.1 -- The use of 'metadata' (notably in table 1) for 'context headers' is confusing for a first-time reader. Any chance to be consistent and only use 'context headers' ? -- Section 4.2 -- At first reading, I am confused by the use of the word 'secret key' for what appears to be a 'shared key'. Or is this 'secret key' never shared and simply used to generate the secondary keys, which are then shared ? Even if discussed later, some early explanations would be welcome. -- Section 5.1 -- Is there a good reason why the field name "key length" is not "key ID length" ? I also find very strange to define "Length: variable" as the header field itself as a fixed length, simply state "unsigned integer". As timestamp can include fractions of second, which is a good thing, then please reword "expressed in seconds relative" to indicate that fraction of second is included. The 32-bit epoch will wrap around in 2036, should this I-D already consider what to do at that moment ? -- Section 8 -- Indeed MTU is always an interesting 'problem' but how is this extension different than plain NSH ? The NSH neither increases nor decreases on the fly with this document. == NITS == -- Section 3 -- Should 'figure 1' be 'table 1' per consistency with section 4.1.1 ? From nobody Tue Jul 13 07:09:22 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C463A11E7; Tue, 13 Jul 2021 07:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 TrHJc1hTonw4; Tue, 13 Jul 2021 07:09:12 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2067.outbound.protection.outlook.com [40.107.22.67]) (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 DEA923A11E0; Tue, 13 Jul 2021 07:09:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LndE/+RbG/l2L3r61d3Rr6NKf2h0+cOUxaw41ARTMm0yGaiplDfoj9ZZvOg6TATa+bgAlNjZAKjFdEOJNMkpI8PCwYtTOiMqNkOe4kPK2oYa0zIkhqhiYBQmA/JFMHeQb40yQJ9CUOE+fUFSiJi3sw4APGBSowLSpOrR7z1YSdFU2iZtUXOjEECj7mdFKmhbkyCnwltxtcXomBAWpR9/6uOGnD6b2kId533Pqodc/xAfLRyB+5Kf2Ib2N/nhfiVj9FJBkg+ALTfuFAZ954ldyhpMSequOWgAhDggcyNaUhuSDCpGt+PtA4+hlYfGYVjhmLY4LHIIe0dHg+cVCmCZ6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=meNL0UZ8jZNu3U7Pq6ISdeTYKZrWP4kqfcruS6e8lUY=; b=oa2G6rtTcJfz24WGbXYG/o2xJ/co53NJOky45DNwZXfqgFpwEdTtEkcJh7pmR0XtzSJwFM5MpGw4DxSggpTF9XayzR9gmuigDCtXoi0RLfsWmr9ez2YphyG+SBpkwZ5rRfgl6TOpv5rZfrA0jl8CGsmhCsHJbyaAuBsiJVCfXdjGeHUEkNsb1kLzt1paOV+Ve9cGrW0oF25h73itpRd78qSy4S/a/D2G0gqkbZEBCA2PjgUHMNJysJmdvXsnZY1UsrrHIjzRcZA9XB6UK0THZAg4hK1G75RNS0+xLrBRX1n2NwMGhRASgPQ/t4R9JCG4TsfY1LK5O6fVs1GnVKJ8pg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=meNL0UZ8jZNu3U7Pq6ISdeTYKZrWP4kqfcruS6e8lUY=; b=V/M4TJrGz39Fbm2RX+rFvA7D74yno+M3p/v0+TohvxrqU3SWwm0puMqnIdT/KozYu6rPN65JZZWdEy/V5+3U+Z+1Xb8WsTNGmGo7WLE/QVgL+XCG2TL1THxTQeQU0z8zA+aLg0AJjRCG//O1XY3541UpthGVAH7Q00+NimTomrM= Received: from HE1PR07MB4187.eurprd07.prod.outlook.com (2603:10a6:7:98::23) by HE1PR0701MB2169.eurprd07.prod.outlook.com (2603:10a6:3:28::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.17; Tue, 13 Jul 2021 14:09:07 +0000 Received: from HE1PR07MB4187.eurprd07.prod.outlook.com ([fe80::158:faff:a530:9dcd]) by HE1PR07MB4187.eurprd07.prod.outlook.com ([fe80::158:faff:a530:9dcd%6]) with mapi id 15.20.4331.021; Tue, 13 Jul 2021 14:09:07 +0000 From: Zaheduzzaman Sarker To: "mohamed.boucadair@orange.com" , The IESG CC: "draft-ietf-sfc-nsh-integrity@ietf.org" , "sfc-chairs@ietf.org" , "sfc@ietf.org" , "gregimirsky@gmail.com" Thread-Topic: Zaheduzzaman Sarker's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) Thread-Index: AQHXd9MGZ6YQ3JB9xEC80kobg/6Ve6tAvpKAgABUlwA= Date: Tue, 13 Jul 2021 14:09:06 +0000 Message-ID: <232E3C7F-E4E6-456F-8E02-B9FF61D4B9A9@ericsson.com> References: <162617261371.15907.6050785043086194503@ietfa.amsl.com> <3763_1626174382_60ED73AE_3763_126_1_787AE7BB302AE849A7480A190F8B9330353BE5BA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <3763_1626174382_60ED73AE_3763_126_1_787AE7BB302AE849A7480A190F8B9330353BE5BA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.50.21061301 authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1c5276bf-a5c5-4403-f1a6-08d94607c739 x-ms-traffictypediagnostic: HE1PR0701MB2169: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sCKTRvy9y1dASUJADj6yTSqEgS1t3/5euknaM5XIbY256jVSzLA4ycXohqjceStykKNdUkR2JVkxE2P924pZlxopdBnZeDLnhdYUINpgJkjrhGgH3F3sYOo64IPKdPdhej+t0kAZ4iHUmSi8YKGDoUVkN5e8zpVouJIkhZHjJu+IYHv7qxasfzrVJ+qp6iOMSkmz4+No6QBhWtA2wu7VkHPN2NNlmMECbo/kf25MNQ6oiRkwVElaHGEjLCIUyL/60tazgatH+Ntctwp1nI2AgJzrC22ml0dJtWW75utUaLMrSD48CDQ5rlKbh0SG8xyYIsLWLvKm80JoqVdsrXNrV7kNJ844IIBCFDqIHdktsOQZohEzx3W2gik4uNcTG/TH7kLklPETmBHbxL8hiN2eXCR2SvJ8BPvuBX7h2OSus9YYgQ34Jn/U6wpUr8Q+al8wy4ylNFU+C78loKn5Mju/ktL1vXQpzXEzFmE6xnj9y4YUkhdNq+KzxeQ3zZnUBJqetUvKxfnrKLrFIeQ3QY2TfUiB90orsDS4B+BEaT5aZVxoTDZdapFgc8+vUdbRsT1AxYxDaO5v1ByHEXM+U0pet0VeIAtpxBXZs25HauFrkRB7luHMQ64Z3/qqeMe3Gl2UCB0Tr06212QDGFvmhEa56okHKLIUYRctNm3gG/oqtDd4CND3+/ry2WsvICsIUjFaqBxW9+XzQqN56/hVm3J240wjpfPrGrepQMtCPx5g7E/ajbwj0JO4RfbVznQnKzcH6GvxEeEUOaRCvJE8oIpzCgouIWzeUQ6IN0iHde6kFA+MD0GSE6IV4qflZ4ykF2KWpFNH3MlPx0iZgMRayijH/Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4187.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(366004)(346002)(39860400002)(376002)(83380400001)(6506007)(38100700002)(2906002)(64756008)(76116006)(66946007)(478600001)(122000001)(5660300002)(966005)(86362001)(33656002)(6486002)(36756003)(26005)(110136005)(4326008)(6512007)(71200400001)(66446008)(8676002)(44832011)(66476007)(2616005)(186003)(8936002)(66556008)(54906003)(316002)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?WHZ3QjRtZ0o2aVBveWVGNmgraEI0clRxWnptc1R0cGZ0NDNET0ZWczVrVEoz?= =?utf-8?B?Z1RqaG8yYkQ5U1pnNnJEVGwyc2NzbEY3R1ZiTnBoUHNNT1AvY2ZnMzRmLzVU?= =?utf-8?B?TWtFK2x1dTU4OExBanFOUmhaR2FWUDNrYW1za1ZQUG10RjZvQ1RibTZ4Ly9y?= =?utf-8?B?R1V4NUZnYmpqOVNDQ3Q1bXI1MlFSMGhGTGtKeWJIODIwdm14UUg0eXA4SlhW?= =?utf-8?B?cU5LQW1pS242N0I0YjNUL1cwRHJmaHVzbVIvcFFFZkJtbWRQWXlkYVprYkNO?= =?utf-8?B?N3dtaTQyMmJRaDBSNXhwemJtT291SGpvUTdkeTVBQks1WjdZaDJvZVd3Sk1t?= =?utf-8?B?a0x6Mm85N1VrcUxHQk5wRkJucWY1eHdMRmgxQ0pRY21vMnJpbitVcVFJcDBt?= =?utf-8?B?UU4zcS9oMUJZYXU4b0d0VDVVamozUEVER2c3dlR5WjFUd1ZuekNtUlJGOEVN?= =?utf-8?B?SGZ1ZjA2VTBlNnFXcTdNMFhrNVo3T0ZtUllRa1pZRGdlWHlncDg1ZTBYcTBm?= =?utf-8?B?aDRYTEkrWGFKZ0FscTh6d0Jva1ZQRTE1bjh2aXRMKy8wbk9kMnlxdGFtNmRt?= =?utf-8?B?eE1MRE1rclNGbWo2QktwTlVEcStYcnNTbUFYeVNSajhxbXZldURoVzh4WnlF?= =?utf-8?B?aXFPMS9KZkwrWjRaNXdrcUoyQzJQY0tHYlF1Um8waStpcnFxZnRxQ1huMUhr?= =?utf-8?B?YWVURHp2L2tJRUNFcjk5UVk4dVdGbVJrUTdWdVZOUmFQc1JCYmdqeVU1YTJ0?= =?utf-8?B?aTZtOGEyN2FpbTVIYlVRRTQ3TjNJR0VTdnpMWENvOU5HM21hUHRydWNhQTFC?= =?utf-8?B?WEdPVE9NMU81TGtHMTRnUk42VkFDK1Zlb1dHVkwxZVB2NkY0RE5FT0J4MGFC?= =?utf-8?B?S29SYmlQRmR6N1BpM3VrV3AxM1ZzNHd6Y1NTZjhzOUxtbmQ3b3VQUGJUUDJx?= =?utf-8?B?NjFHWHVGQS9WWU03MHpOY1preGxQSUswWUovcndZZ2xhTGlveWQrWTA0SnJH?= =?utf-8?B?bkNUWmNCSWhSeUZQa3NyOGNiYWNIaG5OclRyb1dNTlYyMnVRd1A2MlBjZ3E3?= =?utf-8?B?ZS9JMFNUWWVuUjQzTW5ZT0M2Qkh5c1FaN1lucjZaWCtCZHFoTlNITEQ2U0M3?= =?utf-8?B?MzJyTGxheG81bng1Q2lnenZab0s1VkFKZTJONWFhY1R5RU51VGNMWFc1SWFr?= =?utf-8?B?VDFaUmJuV0tKSHBiVTM0YTVueSs0ZHZWSlFJeDZTeXQxdEIvSVR3U0EwL24y?= =?utf-8?B?a1NvUVUwU00zN096RjF4U2UyeEdnSkh2SFlaaHlqWndXRVNKMDlLRWQwQUNF?= =?utf-8?B?d2p6ZWs5T2MzMFNZT3pjYW4xQmtIeCtUWTFwYnA2TnVUMlhEY1FKMDBFUnRP?= =?utf-8?B?TGdOcUdrdVdiSXlzT1V1YmdBMStaQzVRc1l0ZFF1SHRYdlhaWkkyZDI2VW1Y?= =?utf-8?B?Q25JNDVTTjNLSmtoMzhmYlJCdWdXY3ViQStCU2JySEpHVTl5NnZVSHB6WlJK?= =?utf-8?B?WHUxZjkxTG80bnU4MFV5SXlieWFoVXFwTWMrcVpCVDd3OXlub2thbU5OaXBF?= =?utf-8?B?b092WnVHUzgvcTdMeXZ6WGQ5dGpURy85VWxnVGJ0MGFLYmNnN2dOWWlObXM1?= =?utf-8?B?SFN6UE1HaG94SnhGSzQxeXF0WlozYXNUczBLdzQ1WXRMUmp0UmNxdkdxRU9x?= =?utf-8?B?TW1nQzQ2VzRURVhYUHE3Z1A3SW5IZUoycldjdmJNM0JNV3FjUU9qVXMwSFlN?= =?utf-8?Q?nQZS5v7bIP3vxIoXBRteLq4eHhunZImHch28bKg?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4187.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1c5276bf-a5c5-4403-f1a6-08d94607c739 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2021 14:09:06.9215 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: +LzoImBnO5Iks3JG9bNOqHf3c29tZmRh3wRLYnW9iHHjvhmQOo4Wq2nEQ4kRsbGQ34azBj8+/6Z0KmL5lkMU6u47ElQ4B3zmemxOrKhNnB0ugaeBCHKRNU0J5V9xfiHj X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2169 Archived-At: Subject: Re: [sfc] Zaheduzzaman Sarker's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2021 14:09:18 -0000 SGksDQoNClRoYW5rcyBmb3IgdGhlIHJlc3BvbnNlcy4gU2VlIGJlbG93IG15IHJlZmxlY3Rpb25z IGlubGluZSBiZWxvdy4NCg0KQlINClphaGVkDQoNCu+7v09uIDIwMjEtMDctMTMsIDEzOjA2LCAi bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSIgPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b20+IHdyb3RlOg0KDQogICAgSGkgWmFoZWQsIA0KDQogICAgVGhhbmtzIGZvciB0aGUgcmV2aWV3 LiANCg0KICAgIFBsZWFzZSBzZWUgaW5saW5lLiANCg0KICAgIENoZWVycywNCiAgICBNZWQNCg0K ICAgID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQogICAgPiBEZSA6IFphaGVkdXp6YW1h biBTYXJrZXIgdmlhIERhdGF0cmFja2VyIFttYWlsdG86bm9yZXBseUBpZXRmLm9yZ10NCiAgICA+ IEVudm95w6kgOiBtYXJkaSAxMyBqdWlsbGV0IDIwMjEgMTI6MzcNCiAgICA+IMOAIDogVGhlIElF U0cgPGllc2dAaWV0Zi5vcmc+DQogICAgPiBDYyA6IGRyYWZ0LWlldGYtc2ZjLW5zaC1pbnRlZ3Jp dHlAaWV0Zi5vcmc7IHNmYy1jaGFpcnNAaWV0Zi5vcmc7DQogICAgPiBzZmNAaWV0Zi5vcmc7IGdy ZWdpbWlyc2t5QGdtYWlsLmNvbTsgZ3JlZ2ltaXJza3lAZ21haWwuY29tDQogICAgPiBPYmpldCA6 IFphaGVkdXp6YW1hbiBTYXJrZXIncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1zZmMtbnNo LQ0KICAgID4gaW50ZWdyaXR5LTA2OiAod2l0aCBDT01NRU5UKQ0KICAgID4gDQogICAgPiBaYWhl ZHV6emFtYW4gU2Fya2VyIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9u IGZvcg0KICAgID4gZHJhZnQtaWV0Zi1zZmMtbnNoLWludGVncml0eS0wNjogTm8gT2JqZWN0aW9u DQogICAgPiANCiAgICA+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3Qg bGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvDQogICAgPiBhbGwgZW1haWwgYWRkcmVzc2VzIGluY2x1 ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8NCiAgICA+IGN1dCB0aGlz IGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KICAgID4gDQogICAgPiANCiAgICA+ IFBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNj dXNzLQ0KICAgID4gY3JpdGVyaWEuaHRtbA0KICAgID4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJv dXQgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQogICAgPiANCiAgICA+IA0KICAgID4g VGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBm b3VuZCBoZXJlOg0KICAgID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1zZmMtbnNoLWludGVncml0eS8NCiAgICA+IA0KICAgID4gDQogICAgPiANCiAgICA+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQogICAgPiAtLQ0KICAgID4gQ09NTUVOVDoNCiAgICA+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQog ICAgPiAtLQ0KICAgID4gDQogICAgPiBUaGFua3MgZm9yIHRoZSBlZmZvcnRzIG9uIHRoaXMgc3Bl Y2lmaWNhdGlvbi4NCiAgICA+IA0KICAgID4gSSBoYXZlIGZvbGxvd2luZyBub24tYmxvY2tpbmcg Y29tbWVudHMgdGhvc2UgSSBiZWxpZXZlIHdvdWxkIGltcHJvdmUNCiAgICA+IHRoZSBkb2N1bWVu dCBpZiBhZGRyZXNzZWQgLS0NCiAgICA+IA0KICAgID4gKiBJIGFncmVlIHdpdGggQWx2YXJvIGFu ZCBMYXJzJ3MgY29tbWVudCBhYm91dCB1cGRhdGluZyA4MzAwLiBXb3VsZA0KICAgID4gbGlrZSB0 byBnZXQNCiAgICA+IHJlc3BvbnNlKHMpIHRvIHRoZWlyIGNvbW1lbnRzLg0KDQogICAgW01lZF0g QWxyZWFkeSByZXBsaWVkIHRvIHRob3NlLiANCg0KVGhhbmtzLCB3YXRjaGluZyB0aGUgdGhyZWFk Lg0KDQogICAgPiANCiAgICA+ICogSSB0aGluayBpdCB3aWxsIGJlIGhlbHBmdWwgdG8gZXhwbGlj aXRseSBtZW50aW9uIGlmIGludGVncml0eSBhbmQNCiAgICA+IGNvbmZpZGVudGlhbGl0eSBieSB0 aGUgdHJhbnNwb3J0IGVuY2Fwc3VsYXRpb24gaXMgbmVlZGVkIG9yIG5vdCB3aGVuDQogICAgPiB0 aGlzIHNwZWNpZmljYXRpb24gaXMgaW4gdXNlLiBUaGlzIHNwZWNpZmljYXRpb24gZGVmaW5pdGVs eSBzYXlzDQogICAgPiB0aGF0IG9uZSBkb2VzIG5vdCBuZWVkIHRvIHJlbGF5IG9uIHRoZSBzZXJ2 aWNlIHByb3ZpZGVkIGJ5IHRoZQ0KICAgID4gdHJhbnNwb3J0IGVuY2Fwc3VsYXRpb24gYnV0IGl0 IGRvZXMgbm90IHNheXMgdGhhdCB0aG9zZSBzZXJ2aWNlcyBhcmUNCiAgICA+IG5vdCBsb25nZXIg cmVxdWlyZWQuDQoNCiAgICBbTWVkXSBXZSBkb24ndCBzYXkgc28gYmVjYXVzZSB0aGlzIGlzIGRl cGxveW1lbnQtc3BlY2lmaWMuIE9uZSBtYXkgZGVwbG95IGhTRkMgKFJGQzg0NTkpIHdpdGggdHJh bnNwb3J0IHNlY3VyaXR5IHRvIGludGVyY29ubmVjdCBsb3dlci1sZXZlbCBkb21haW5zLCBidXQg dXNlIHRoaXMgc3BlYyB3aXRoaW4gYSBsb3dlci1sZXZlbCBkb21haW4uIA0KDQpPaywgdGhlbiBj YW4gd2Ugd3JpdGUgc29tZXRoaW5nIGFsb25nIHRoZSBsaW5lcyB5b3UgaGF2ZSB3cml0dGVuIGhl cmU/IFRoaXMgbWlnaHQgYWN0dWFsIGhlbHAgdGhlIHdoeSBub3QgdXBkYXRpbmcgODMwMCBkaXNj dXNzaW9uIGFzIHdlbGwuDQoNCiAgICA+IA0KICAgID4gKiBTZWN0aW9uIDEgOiBzYXlzIC0NCiAg ICA+ICAgICAiVGhpcyBzcGVjaWZpY2F0aW9uIGZpbGxzIHRoYXQgZ2FwLiAgQ29uY3JldGVseSwg dGhpcyBkb2N1bWVudA0KICAgID4gYWRkcw0KICAgID4gICAgaW50ZWdyaXR5IHByb3RlY3Rpb24g YW5kIG9wdGlvbmFsIGVuY3J5cHRpb24gb2Ygc2Vuc2l0aXZlDQogICAgPiBtZXRhZGF0YQ0KICAg ID4gICAgZGlyZWN0bHkgdG8gdGhlIE5TSCAoU2VjdGlvbiA0KTsiDQogICAgPiANCiAgICA+ICAg RG9lcyB0aGlzIHNwZWNpZmljYXRpb24gZXh0ZW5kcyB0aGUgdXNlIG9mIE5TSCBpbiBtdWx0aXBs ZSBTRkMNCiAgICA+IGRvbWFpbj8NCg0KICAgIFtNZWRdIE5vLCB3ZSBkb24ndCBhcyB3ZSBhZGhl cmUgdG8gUkZDNzY2NSBhbmQgUkZDODMwMC4gDQoNCiAgICBGdXR1cmUgZG9jdW1lbnRzIG1heSBk ZWZpbmUgYW4gdXBkYXRlZCA3NjY1IHRvIGRlc2NyaWJlIHRoZSBpbnRlci1kb21haW4gY2FzZS4g VGhpcyBzcGVjIG1heSBzb2x2ZSBzb21lIG9mIHRoZSBpbmhlcmVudCBpc3N1ZXMsIGJ1dCBpdCBp cyBvdXQgb2Ygc2NvcGUgdG8gZGlzY3VzcyB0aG9zZSBpbiB0aGlzIEktRC4NCg0KICAgIFRpbGwg dGhpcyBoYXBwZW5zLCB0aGUgc2NvcGUgaXMgc3RpbGwgd2hhdCBpcyByZWNvcmRlZCBpbiBSRkM3 NjY1OiANCg0KICAgID09DQogICAgICAgVGhlIGFyY2hpdGVjdHVyZSBkZXNjcmliZWQgaGVyZWlu IGlzIGFzc3VtZWQgdG8gYmUgYXBwbGljYWJsZSB0byBhDQogICAgICAgc2luZ2xlIG5ldHdvcmsg YWRtaW5pc3RyYXRpdmUgZG9tYWluLiAgV2hpbGUgaXQgaXMgcG9zc2libGUgZm9yIHRoZQ0KICAg ICAgIGFyY2hpdGVjdHVyYWwgcHJpbmNpcGxlcyBhbmQgY29tcG9uZW50cyB0byBiZSBhcHBsaWVk IHRvIGludGVyLWRvbWFpbg0KICAgICAgIFNGQ3MsIHRoZXNlIGFyZSBsZWZ0IGZvciBmdXR1cmUg c3R1ZHkuDQogICAgPT0NCg0KT0suIEkgaGF2ZSBzZWVuIHRoZSB1cGRhdGUgd2hlcmUgeW91IG1l bnRpb24gYWJvdXQgdGhlIGdhcHMgdGhhdCB3aWxsIHJlc29sdmUgbXkgcXVlc3Rpb24gYXMgd2Vs bC4NCg0KICAgICBNeQ0KICAgID4gICBsaXR0bGUgdW5kZXJzdGFuZGluZyBvZiBOU0ggc2F5cyBp dCBpcyBTRkMgZG9tYWluIHNwZWNpZmljIGFuZA0KICAgID4gd2l0aGluIG9uZSBTRkMNCiAgICA+ ICAgZG9tYWluIHRoZSBkZXZpY2VzIGEgdmV0dGVkIHRvIGJlIHRydXN0ZWQuIEkgdGhpbmsgaXQg d2lsbCBiZSB2ZXJ5DQogICAgPiBoZWxwZnVsIHRvDQogICAgPiAgIGFkZCB6ZXN0IGZyb20gdGhl IHNlY3Rpb24gMy4yLjEuIG9mIEktRC5hcmtrby1mYXJyZWxsLWFyY2gtbW9kZWwtdA0KICAgID4g aGVyZS4NCiAgICA+IA0KICAgID4gKiBTZWN0aW9uIDYgOg0KICAgID4gDQogICAgPiAgICBUaGUg ZXBvY2ggaXMgMTk3MC0wMS0wMVQwMDowMFogaW4gVVRDIHRpbWUuICBOb3RlIHRoaXMgZXBvY2gN CiAgICA+IHZhbHVlDQogICAgPiAgICAgICBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgb25lIHVzZWQg aW4gU2VjdGlvbiA2IG9mIFtSRkM1OTA1XS4NCiAgICA+IA0KICAgID4gICAgSXQgd291bGQgYmUg Z3JlYXQgaWYgd2UgY2FuIGFkZCB0aGUgaW1wbGljYXRpb25zIG9mIHRoZQ0KICAgID4gZGlmZmVy ZW5jZS4gTm93IEkNCiAgICA+ICAgIGRvbid0IGtub3cgd2hhdCBpdCBtZWFucy4NCiAgICA+IA0K ICAgID4gDQoNCiAgICBbTWVkXSBUaGUgaW1wbGljYXRpb24gaXMgYmFzaWNhbGx5IHdoYXQgaXMg bWVudGlvbmVkIHVuZGVyIHdyYXBhcm91bmQgYnVsbGV0OiAiVGhlIG5leHQgd3JhcGFyb3VuZCB3 aWxsIG9jY3VyIGluIHRoZSB5ZWFyIDIxMDYiLiBJZiB3ZSBtYWludGFpbmVkIHRoZSBlcG9jaCBp biBSRkM1OTA1LCB0aGUgd3JhcGFyb3VuZCB3b3VsZCBiZSBpbiAyMDM2LiBUd2Vha2VkIHRoZSB0 ZXh0IHRvIG1lbnRpb24gdGhpcy4gVGhhbmtzLiANCg0KT2suDQoNCg0KDQogICAgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K DQogICAgQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBk ZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9p dmVudCBkb25jDQogICAgcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2Fu cyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwg dmV1aWxsZXogbGUgc2lnbmFsZXINCiAgICBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBh aW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBl dGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KICAgIE9yYW5nZSBkZWNsaW5lIHRvdXRl IHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZh bHNpZmllLiBNZXJjaS4NCg0KICAgIFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1h eSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5 IGJlIHByb3RlY3RlZCBieSBsYXc7DQogICAgdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVk LCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQogICAgSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFu ZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQogICAgQXMgZW1haWxz IG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBo YXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KICAgIFRoYW5rIHlvdS4N Cg0KDQo= From nobody Tue Jul 13 09:55:00 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB9D73A0C99; Tue, 13 Jul 2021 09:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.796 X-Spam-Level: X-Spam-Status: No, score=-2.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dczBK8xmUhmr; Tue, 13 Jul 2021 09:54:49 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (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 E76693A0C9C; Tue, 13 Jul 2021 09:54:48 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr20.francetelecom.fr (ESMTP service) with ESMTPS id 4GPRZ96L9dz21Nd; Tue, 13 Jul 2021 18:54:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1626195281; bh=p0Iz1dTIHG7RC7rI7yOC7vr7vHNHZH9X9zGJwf0Bhvw=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=UivSF8sACPqEpq/bxr+sbk3c/GdtGYD27gmg/9pLa1SUmJ4OLAHugrjbRu2TMWE0J GFG5bnLHRa4CCl25FnT1LLXABUdC0ipJTNmgVRf605nPEDfv4OOT0ZOsn6fT2qacD7 qXEGOnRFXdzI8EYk8j4Ms4ec4U7e7O8JjSHhvg3hCGltvXsVB6oExolX6StjNa5ukp PfCJR7wLYM5tJZMbARVNM8v6LwXVRg/GQENl9IZOIPvgKzR+qXRnTs7Gr1yMHeWeOJ 5SDS5LT+b8e1B3zyDeZlCxAims1GPDVIGfj+7e2y4TNrrR9/jkUQaa+Yl6mgHx0DiS 9BHAvx3PNSIrA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfednr03.francetelecom.fr (ESMTP service) with ESMTPS id 4GPRZ95kSkzDq7V; Tue, 13 Jul 2021 18:54:41 +0200 (CEST) From: To: =?utf-8?B?w4lyaWMgVnluY2tl?= , The IESG CC: "draft-ietf-sfc-nsh-integrity@ietf.org" , "sfc-chairs@ietf.org" , "sfc@ietf.org" , "gregimirsky@gmail.com" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXNmYy1uc2gt?= =?utf-8?Q?integrity-06:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHXd+EWUzPhovDiy06QVDjdApotHKtBE6GQ Date: Tue, 13 Jul 2021 16:54:40 +0000 Message-ID: <15473_1626195281_60EDC551_15473_51_1_787AE7BB302AE849A7480A190F8B9330353BE8EC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162617866082.13596.2398814614966286542@ietfa.amsl.com> In-Reply-To: <162617866082.13596.2398814614966286542@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-sfc-n?= =?utf-8?q?sh-integrity-06=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2021 16:54:54 -0000 SGkgRXJpYywgDQoNClRoYW5rIHlvdSBmb3IgdGhlIHJldmlldy4gDQoNClBsZWFzZSBzZWUgaW5s aW5lLiANCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ IERlwqA6IMOJcmljIFZ5bmNrZSB2aWEgRGF0YXRyYWNrZXIgW21haWx0bzpub3JlcGx5QGlldGYu b3JnXQ0KPiBFbnZvecOpwqA6IG1hcmRpIDEzIGp1aWxsZXQgMjAyMSAxNDoxOA0KPiDDgMKgOiBU aGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCj4gQ2PCoDogZHJhZnQtaWV0Zi1zZmMtbnNoLWludGVn cml0eUBpZXRmLm9yZzsgc2ZjLWNoYWlyc0BpZXRmLm9yZzsNCj4gc2ZjQGlldGYub3JnOyBncmVn aW1pcnNreUBnbWFpbC5jb207IGdyZWdpbWlyc2t5QGdtYWlsLmNvbQ0KPiBPYmpldMKgOiDDiXJp YyBWeW5ja2UncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtc2ZjLW5zaC1pbnRlZ3JpdHktMDY6DQo+ ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+IA0KPiDDiXJpYyBWeW5ja2UgaGFzIGVudGVy ZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+IGRyYWZ0LWlldGYtc2ZjLW5z aC1pbnRlZ3JpdHktMDY6IERpc2N1c3MNCj4gDQo+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtl ZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvDQo+IGFsbCBlbWFpbCBhZGRy ZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0bw0KPiBj dXQgdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4gDQo+IA0KPiBQbGVh c2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy0N Cj4gY3JpdGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBESVNDVVNTIGFu ZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gDQo+IA0KPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGgg b3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+IGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2ZjLW5zaC1pbnRlZ3JpdHkvDQo+IA0K PiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tDQo+IERJU0NVU1M6DQo+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ IC0tDQo+IA0KPiBUaGFuayB5b3UgZm9yIHRoZSB3b3JrIHB1dCBpbnRvIHRoaXMgZG9jdW1lbnQu DQo+IA0KPiBTcGVjaWFsIHRoYW5rcyB0byBHcmVnIE1pcnNreSBmb3IgaGlzIHNoZXBoZXJkaW5n IGVzcGVjaWFsbHkgYWJvdXQNCj4gaGlzIHN1bW1hcnkgb2YgdGhlIFdHIGNvbnNlbnN1cy4NCj4g DQo+IFBsZWFzZSBmaW5kIGJlbG93IHNvbWUgYmxvY2tpbmcgRElTQ1VTUyBwb2ludCAod2hpY2gg c2hvdWxkIGJlIGVhc3kNCj4gdG8gZml4KSwgc29tZSBub24tYmxvY2tpbmcgQ09NTUVOVCBwb2lu dHMgKGJ1dCByZXBsaWVzIHdvdWxkIGJlDQo+IGFwcHJlY2lhdGVkKSwgYW5kIG9uZSBuaXQuDQo+ IA0KPiBJIGhvcGUgdGhhdCB0aGlzIGhlbHBzIHRvIGltcHJvdmUgdGhlIGRvY3VtZW50LA0KPiAN Cj4gUmVnYXJkcywNCj4gDQo+IC3DqXJpYw0KPiANCj4gPT0gRElTQ1VTUyA9PQ0KPiANCj4gSSBm YWlsZWQgdG8gc3BvdCB0aGUgb3JkZXIgb2YgdGhlIG9wZXJhdGlvbnMgZm9yIHRoZSBpbnRlZ3Jp dHkgYW5kDQo+IGNvbmZpZGVudGlhbGl0eSBvcGVyYXRpb25zLCBlLmcuLCBJIGRpZCBub3QgZmlu ZCBvbiB3aGF0IHRoZSBITUFDIGlzDQo+IGNvbXB1dGVkOg0KPiBpbiB0aGUgdW5lbmNyeXB0ZWQg b3IgZW5jcnlwdGVkIGZpZWxkID8NCg0KW01lZF0gSXNuJ3QgdGhpcyBjb3ZlcmVkIGJ5IHRoaXMg dGV4dDogDQoNCiAgIFVzaW5nIHRoZSBzZWNyZXQga2V5IChLKSBhbmQgYXV0aGVudGljYXRlZCBl bmNyeXB0aW9uIGFsZ29yaXRobSwgdGhlDQogICBOU0ggaW1wb3NlciBlbmNyeXB0cyB0aGUgQ29u dGV4dCBIZWFkZXJzIChhcyBzZXQsIGZvciBleGFtcGxlLCBpbg0KICAgU2VjdGlvbiAzKSwgY29t cHV0ZXMgdGhlIG1lc3NhZ2UgaW50ZWdyaXR5IGZvciB0aGUgdGFyZ2V0IE5TSCBkYXRhLA0KICAg YW5kIGluc2VydHMgdGhlIHJlc3VsdGluZyBwYXlsb2FkIGluIHRoZSAiTUFDIGFuZCBFbmNyeXB0 ZWQgTWV0YWRhdGEiDQogICBDb250ZXh0IEhlYWRlciAoU2VjdGlvbiA1KS4gIFRoZSBlbnRpcmUg Q29udGV4dCBIZWFkZXIgY2FycnlpbmcgYQ0KICAgcHJpdmFjeS1zZW5zaXRpdmUgbWV0YWRhdGEg aXMgZW5jcnlwdGVkICh0aGF0IGlzLCBpbmNsdWRpbmcgdGhlIE1EDQogICBDbGFzcywgVHlwZSwg TGVuZ3RoLCBhbmQgYXNzb2NpYXRlZCBtZXRhZGF0YSBvZiBlYWNoIENvbnRleHQgSGVhZGVyKS4N Cg0KPiANCj4gLS0gU2VjdGlvbiA1LjEgLS0NCj4gV2hhdCBpcyB0aGUgdW5pdCBvZiAia2V5IGxl bmd0aCIsIEkgYXNzdW1lIGEgbGVuZ3RoIGV4cHJlc3NlZCBpbg0KPiBvY3RldHMgYnV0IGl0IGlz IG5vdCBzcGVjaWZpZWQuDQoNCltNZWRdIFllcy4gRml4ZWQuIFRoYW5rIHlvdSBmb3IgY2F0Y2hp bmcgdGhpcy4gDQoNCj4gDQo+IC0tIFNlY3Rpb24gNy4yIC0tDQo+IFdoYXQgaXMgdGhlICJBIiB1 c2VkIGluIHRoZSBITUFDIGNvbXB1dGF0aW9uID8NCg0KW01lZF0gVGhpcyBpczogQWRkaXRpb25h bCBBdXRoZW50aWNhdGVkIERhdGEgKEEpIChtZW50aW9uZWQgaW4gNC4yKS4NCg0KPiANCj4gVGhl IGZvcm11bGEgc3BlY2lmaWVzIEhNQUMtU0hBLTI1Ni0xMjgoKSBidXQgd2hhdCBpZiBhbm90aGVy IEhNQUMgaXMNCj4gdXNlZCA/DQoNCltNZWRdIFBsZWFzZSBub3RlIHRoYXQgdGhlIHRleHQgc2F5 czogImNhbiBiZSBpbGx1c3RyYXRlZCBhcyBmb2xsb3dzOiIuIA0KDQpUaGF0IGlzIGZvciBpbGx1 c3RyYXRpb24gcHVycG9zZXMuIA0KDQo+IFNlY3Rpb24gNy4zIHVzZSBNQUMoKSB3aGljaCBpcyBt b3JlIGZsZXhpYmxlLg0KPiANCj4gQXMgdGhlIE1BQyBmaWVsZCBpcyBpbmNsdWRlZCBpbiB0aGUg aW50ZWdyaXR5IHByb3RlY3RlZCBoZWFkZXIsDQo+IHBsZWFzZSBzcGVjaWZ5IHRoZSB2YWx1ZSBv ZiB0aGlzIGZpZWxkIHdoZW4gY29tcHV0aW5nIHRoZSBITUFDIChJDQo+IGFzc3VtZSAwIGJ1dCBs ZXQncyBiZSBjbGVhcikNCj4gDQo+IC0tIFNlY3Rpb24gNy41IC0tDQo+IFdoYXQgaXMgdGhlIGV4 cGVjdGVkIGJlaGF2aW9yIHdoZW4gYSBOU0ggZG9lcyBub3QgY29udGFpbiBhICJNQUMgYW5kDQo+ IEVuY3J5cHRlZCBNZXRhZGF0YSIgQ29udGV4dCBIZWFkZXIgPyDCpzEgaGludHMgdG8gcGFja2V0 IGRyb3AgPw0KPiBTaG91bGQgdGhlcmUgYmUgYSBsb2NhbCBwb2xpY3kgZm9yIHRoaXMgY2FzZSA/ DQoNCltNZWRdIFRoaXMgaXMgY292ZXJlZCBoZXJlOiANCg0KICAgSXQgTVVTVCBsb2cgYW4gZXJy b3IgYXQgbGVhc3Qgb25jZSBwZXIgdGhlDQogICBTUEkgZm9yIHdoaWNoIHRoZSAiTUFDIGFuZCBF bmNyeXB0ZWQgTWV0YWRhdGEiIENvbnRleHQgSGVhZGVyIGlzDQogICBtaXNzaW5nLg0KDQo+IA0K PiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0N Cj4gDQo+IA0KPiBJIHNlY29uZCBBbHZhcm8ncyBhbmQgTGFycycgcG9pbnQgYWJvdXQgZm9ybWFs bHkgdXBkYXRpbmcgUkZDIDgzMDAuDQo+IA0KPiBRdWl0ZSBvZnRlbiBpbiB0aGUgdGV4dCAicHJp dmFjeS1zZW5zaXRpdmUgbWV0YWRhdGEiIGlzIHVzZWQgYnV0DQo+IGVuY3J5cHRpb24gaXMgbm90 IG9ubHkgcmVxdWlyZWQgZm9yIHByaXZhY3kgYnV0IGFsc28gdG8gcHJvdGVjdA0KPiBvcGVyYXRp b25hbCBkYXRhIGZyb20gYXR0YWNrZXJzIChpLmUuLCBub3QgbGlua2VkIHRvIHByaXZhY3kpLCBp cw0KPiB0aGVyZSBhIHJlYWwgbmVlZCB0byBxdWFsaWZ5ICJtZXRhZGF0YSIgd2l0aCAicHJpdmFj eS1zZW5zaXRpdmUiLA0KPiBpLmUuLCAiY29uZmlkZW50aWFsIG1ldGFkYXRhIiBtYXkgYmUgbW9y ZSBhcHByb3ByaWF0ZSA/DQoNCltNZWRdIFdlIHVzZSB0aGlzIHRlcm0gYmVjYXVzZSB3ZSBjYW4g ZWFzaWx5IGFyZ3VlIHdoeSB3ZSBpbmNsdWRlZCBzdGF0ZW1lbnQgc3VjaCBhczoNCg0KICIgSW4g YW4gU0ZDLWVuYWJsZWQgZG9tYWluIHdoZXJlIHRoZSBhYm92ZSBhdHRhY2tzIGFyZSBwb3NzaWJs ZSwgKDEpDQogICBOU0ggZGF0YSBNVVNUIGJlIGludGVncml0eS1wcm90ZWN0ZWQgYW5kIHJlcGxh eS1wcm90ZWN0ZWQsIGFuZCAoMikNCiAgIHByaXZhY3ktc2Vuc2l0aXZlIE5TSCBtZXRhZGF0YSBN VVNUIGJlIGVuY3J5cHRlZCBmb3IgY29uZmlkZW50aWFsaXR5DQogICBwcmVzZXJ2YXRpb24gcHVy cG9zZXMuIg0KDQpPdGhlciB0eXBlcyBjYW4gYmUgZW5jcnlwdGVkIGFzIHBlcjogDQoNCiAgIENs YXNzaWZpZXIocyksIE5TSC1hd2FyZSBTRnMsIGFuZCBTRkMgcHJveGllcyBhcmUgaW5zdHJ1Y3Rl ZCB3aXRoIHRoZQ0KICAgc2V0IG9mIENvbnRleHQgSGVhZGVycyAocHJpdmFjeS1zZW5zaXRpdmUg bWV0YWRhdGEsIHR5cGljYWxseSkgdGhhdA0KICAgbXVzdCBiZSBlbmNyeXB0ZWQuDQoNCj4gDQo+ IC0tIFNlY3Rpb24gNC4xLjEgLS0NCj4gVGhlIHVzZSBvZiAnbWV0YWRhdGEnIChub3RhYmx5IGlu IHRhYmxlIDEpIGZvciAnY29udGV4dCBoZWFkZXJzJyBpcw0KPiBjb25mdXNpbmcgZm9yIGEgZmly c3QtdGltZSByZWFkZXIuIEFueSBjaGFuY2UgdG8gYmUgY29uc2lzdGVudCBhbmQNCj4gb25seSB1 c2UgJ2NvbnRleHQgaGVhZGVycycgPw0KDQpbTWVkXSBXaWxsIHNlZSBob3cgdG8gbWFrZSB0aGlz IGJldHRlciwgYnV0IHBsZWFzZSB0aGF0IHdlIGRvIGhhdmUgdGhlIGZvbGxvd2luZyBiZWZvcmUg dGFibGUgMTogDQoNCiJDb250ZXh0IEhlYWRlcihzKTogQ2FycmllcyBtZXRhZGF0YS4uLiINCg0K PiANCj4gLS0gU2VjdGlvbiA0LjIgLS0NCj4gQXQgZmlyc3QgcmVhZGluZywgSSBhbSBjb25mdXNl ZCBieSB0aGUgdXNlIG9mIHRoZSB3b3JkICdzZWNyZXQga2V5Jw0KPiBmb3Igd2hhdCBhcHBlYXJz IHRvIGJlIGEgJ3NoYXJlZCBrZXknLiBPciBpcyB0aGlzICdzZWNyZXQga2V5JyBuZXZlcg0KPiBz aGFyZWQgYW5kIHNpbXBseSB1c2VkIHRvIGdlbmVyYXRlIHRoZSBzZWNvbmRhcnkga2V5cywgd2hp Y2ggYXJlDQo+IHRoZW4gc2hhcmVkID8gRXZlbiBpZiBkaXNjdXNzZWQgbGF0ZXIsIHNvbWUgZWFy bHkgZXhwbGFuYXRpb25zIHdvdWxkDQo+IGJlIHdlbGNvbWUuDQoNCltNZWRdIFdlIGFyZSB1c2lu ZyBzaW1pbGFyIHdvcmRpbmcgYXMgaW4gUkZDNzUxOC4NCg0KPiANCj4gLS0gU2VjdGlvbiA1LjEg LS0NCj4gSXMgdGhlcmUgYSBnb29kIHJlYXNvbiB3aHkgdGhlIGZpZWxkIG5hbWUgImtleSBsZW5n dGgiIGlzIG5vdCAia2V5DQo+IElEIGxlbmd0aCIgPw0KDQpbTWVkXSBPbmx5IGZvciBlc3RoZXRp YyBtYXR0ZXJzIG9mIHRoZSBmaWd1cmVzLiBDYW4gZml4IHRoYXQgaWYgeW91IHByZWZlci4gDQoN CnxLZXkgSUQgTGVuZ3RofCB2cyB8IEtleSBMZW5ndGggfA0KDQo+IA0KPiBJIGFsc28gZmluZCB2 ZXJ5IHN0cmFuZ2UgdG8gZGVmaW5lICJMZW5ndGg6IHZhcmlhYmxlIiBhcyB0aGUgaGVhZGVyDQo+ IGZpZWxkIGl0c2VsZiBhcyBhIGZpeGVkIGxlbmd0aCwgc2ltcGx5IHN0YXRlICJ1bnNpZ25lZCBp bnRlZ2VyIi4NCg0KW01lZF0gV2UgYXJlIGVjaG9pbmcgU2VjdGlvbiAyLjUuMSBvZiBSRkM4MzAw Lg0KDQo+IA0KPiBBcyB0aW1lc3RhbXAgY2FuIGluY2x1ZGUgZnJhY3Rpb25zIG9mIHNlY29uZCwg d2hpY2ggaXMgYSBnb29kIHRoaW5nLA0KPiB0aGVuIHBsZWFzZSByZXdvcmQgImV4cHJlc3NlZCBp biBzZWNvbmRzIHJlbGF0aXZlIiB0byBpbmRpY2F0ZSB0aGF0DQo+IGZyYWN0aW9uIG9mIHNlY29u ZCBpcyBpbmNsdWRlZC4NCg0KW01lZF0gT0suDQoNCj4gDQo+IFRoZSAzMi1iaXQgZXBvY2ggd2ls bCB3cmFwIGFyb3VuZCBpbiAyMDM2LCBzaG91bGQgdGhpcyBJLUQgYWxyZWFkeQ0KPiBjb25zaWRl ciB3aGF0IHRvIGRvIGF0IHRoYXQgbW9tZW50ID8NCg0KW01lZF0gSG1tLiBXZSBzYXkgdGhhdCBp dCB3cmFwcyBpbiAyMTA2IDotKQ0KDQo+IA0KPiAtLSBTZWN0aW9uIDggLS0NCj4gSW5kZWVkIE1U VSBpcyBhbHdheXMgYW4gaW50ZXJlc3RpbmcgJ3Byb2JsZW0nIGJ1dCBob3cgaXMgdGhpcw0KPiBl eHRlbnNpb24gZGlmZmVyZW50IHRoYW4gcGxhaW4gTlNIID8gVGhlIE5TSCBuZWl0aGVyIGluY3Jl YXNlcyBub3INCj4gZGVjcmVhc2VzIG9uIHRoZSBmbHkgd2l0aCB0aGlzIGRvY3VtZW50Lg0KDQpb TWVkXSBJdCB2YXJpZXMgYXMgd2UgY2FuIGFkZC9zdHJpcCBjb250ZXh0IGhlYWRlcnMgYXMgdGhl IHBhY2tldCBwcm9ncmVzcyBpbiB0aGUgc2VydmljZSBjaGFpbi4gDQoNCj4gDQo+ID09IE5JVFMg PT0NCj4gDQo+IC0tIFNlY3Rpb24gMyAtLQ0KPiBTaG91bGQgJ2ZpZ3VyZSAxJyBiZSAndGFibGUg MScgcGVyIGNvbnNpc3RlbmN5IHdpdGggc2VjdGlvbiA0LjEuMSA/DQoNCltNZWRdIEl0IHNob3Vs ZC4gV2lsbCBiZSBmaXhlZC4gVGhhbmtzLiANCg0KPiANCj4gDQoNCgpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNz YWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlv bnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFz IGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNp IHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFs ZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9p bnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0 ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2Fn ZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVn ZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQg bm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24u CklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpB cyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdl cyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlv dS4KCg== From nobody Tue Jul 13 11:37:17 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3429E3A089F; Tue, 13 Jul 2021 11:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43LbvahFLp0v; Tue, 13 Jul 2021 11:37:05 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (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 13B373A0891; Tue, 13 Jul 2021 11:37:04 -0700 (PDT) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfedar27.francetelecom.fr (ESMTP service) with ESMTPS id 4GPTrH0jC2z2xn2; Tue, 13 Jul 2021 20:37:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1626201423; bh=pYkOL23Ebh4cwrlPU3RA/5F+bacs6iOs8UE4NKdWqes=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=ZulrMnpB1A0KW+7Nz9sWFpR43APg/dHKoj1RIao7/N0JwQfJNyeZ8PZooTP9AR56K gf+1NNrP3WYDXU49MLhP7A5Pp+QHpQSAVYe85nhBxDZlaZk+geyiKx+ScqM+xt2ijs +oRWAbdzY8Bty+UShuDAzsq0La0dJ3jtyNHxttstCZO3BpVbCL4k4xCXTcLl8RdTsh cpVdhq+hQkI6s5VUiNPlGrKpvhZ24CGAqETfa6uXyIzhA1zc1uUegK3kKqPzXjfjbY LZPOaOrIy6R2VnCbNfGsm1geK+6pJiMS4JcCFDNstc9vbTrATtnrMS3T/HEIHRXe6V q8vLIWcwNVaSw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfedar01.francetelecom.fr (ESMTP service) with ESMTPS id 4GPTrG6Lc7zBrLc; Tue, 13 Jul 2021 20:37:02 +0200 (CEST) From: To: Zaheduzzaman Sarker , The IESG CC: "draft-ietf-sfc-nsh-integrity@ietf.org" , "sfc-chairs@ietf.org" , "sfc@ietf.org" , "gregimirsky@gmail.com" Thread-Topic: Zaheduzzaman Sarker's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) Thread-Index: AQHXd9MGZ6YQ3JB9xEC80kobg/6Ve6tAvpKAgABUlwCAACjAIA== Date: Tue, 13 Jul 2021 18:37:02 +0000 Message-ID: <25943_1626201422_60EDDD4E_25943_119_1_787AE7BB302AE849A7480A190F8B9330353BE9FA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162617261371.15907.6050785043086194503@ietfa.amsl.com> <3763_1626174382_60ED73AE_3763_126_1_787AE7BB302AE849A7480A190F8B9330353BE5BA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <232E3C7F-E4E6-456F-8E02-B9FF61D4B9A9@ericsson.com> In-Reply-To: <232E3C7F-E4E6-456F-8E02-B9FF61D4B9A9@ericsson.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Zaheduzzaman Sarker's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2021 18:37:12 -0000 UmUtLA0KDQpTdXJlLiBBZGRlZCBhIHNlbnRlbmNlIHRvIHRoZSBpbnRyb2R1Y3Rpb246IGh0dHBz Oi8vdGlueXVybC5jb20vbnNoLWludGVncml0eS1sYXRlc3QuDQoNCkNoZWVycywNCk1lZA0KDQo+ IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBaYWhlZHV6emFtYW4gU2Fya2Vy IFttYWlsdG86emFoZWR1enphbWFuLnNhcmtlckBlcmljc3Nvbi5jb21dDQo+IEVudm95w6nCoDog bWFyZGkgMTMganVpbGxldCAyMDIxIDE2OjA5DQo+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIElO Tk9WL05FVCA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IFRoZQ0KPiBJRVNHIDxpZXNn QGlldGYub3JnPg0KPiBDY8KgOiBkcmFmdC1pZXRmLXNmYy1uc2gtaW50ZWdyaXR5QGlldGYub3Jn OyBzZmMtY2hhaXJzQGlldGYub3JnOw0KPiBzZmNAaWV0Zi5vcmc7IGdyZWdpbWlyc2t5QGdtYWls LmNvbQ0KPiBPYmpldMKgOiBSZTogWmFoZWR1enphbWFuIFNhcmtlcidzIE5vIE9iamVjdGlvbiBv biBkcmFmdC1pZXRmLXNmYy0NCj4gbnNoLWludGVncml0eS0wNjogKHdpdGggQ09NTUVOVCkNCj4g DQouLi4NCj4gDQo+ICAgICA+DQo+ICAgICA+ICogSSB0aGluayBpdCB3aWxsIGJlIGhlbHBmdWwg dG8gZXhwbGljaXRseSBtZW50aW9uIGlmDQo+IGludGVncml0eSBhbmQNCj4gICAgID4gY29uZmlk ZW50aWFsaXR5IGJ5IHRoZSB0cmFuc3BvcnQgZW5jYXBzdWxhdGlvbiBpcyBuZWVkZWQgb3INCj4g bm90IHdoZW4NCj4gICAgID4gdGhpcyBzcGVjaWZpY2F0aW9uIGlzIGluIHVzZS4gVGhpcyBzcGVj aWZpY2F0aW9uIGRlZmluaXRlbHkNCj4gc2F5cw0KPiAgICAgPiB0aGF0IG9uZSBkb2VzIG5vdCBu ZWVkIHRvIHJlbGF5IG9uIHRoZSBzZXJ2aWNlIHByb3ZpZGVkIGJ5IHRoZQ0KPiAgICAgPiB0cmFu c3BvcnQgZW5jYXBzdWxhdGlvbiBidXQgaXQgZG9lcyBub3Qgc2F5cyB0aGF0IHRob3NlDQo+IHNl cnZpY2VzIGFyZQ0KPiAgICAgPiBub3QgbG9uZ2VyIHJlcXVpcmVkLg0KPiANCj4gICAgIFtNZWRd IFdlIGRvbid0IHNheSBzbyBiZWNhdXNlIHRoaXMgaXMgZGVwbG95bWVudC1zcGVjaWZpYy4gT25l DQo+IG1heSBkZXBsb3kgaFNGQyAoUkZDODQ1OSkgd2l0aCB0cmFuc3BvcnQgc2VjdXJpdHkgdG8g aW50ZXJjb25uZWN0DQo+IGxvd2VyLWxldmVsIGRvbWFpbnMsIGJ1dCB1c2UgdGhpcyBzcGVjIHdp dGhpbiBhIGxvd2VyLWxldmVsIGRvbWFpbi4NCj4gDQo+IE9rLCB0aGVuIGNhbiB3ZSB3cml0ZSBz b21ldGhpbmcgYWxvbmcgdGhlIGxpbmVzIHlvdSBoYXZlIHdyaXR0ZW4NCj4gaGVyZT8gVGhpcyBt aWdodCBhY3R1YWwgaGVscCB0aGUgd2h5IG5vdCB1cGRhdGluZyA4MzAwIGRpc2N1c3Npb24gYXMN Cj4gd2VsbC4NCj4gDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMg cGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2 aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMg b3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdl IHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRl dHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJv bmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRv dXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91 IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBj b250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJl IHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBv ciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBP cmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQs IGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Tue Jul 13 12:02:54 2021 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 725E03A0E03; Tue, 13 Jul 2021 12:02:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-sfc-nsh-integrity@ietf.org, sfc-chairs@ietf.org, sfc@ietf.org, gregimirsky@gmail.com, gregimirsky@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <162620296297.3569.2501497601980031548@ietfa.amsl.com> Date: Tue, 13 Jul 2021 12:02:43 -0700 Archived-At: Subject: [sfc] Roman Danyliw's Discuss on draft-ietf-sfc-nsh-integrity-06: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2021 19:02:53 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-sfc-nsh-integrity-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- ** Section 4.6. This section explains that an upper NSH can be encapsulated in a lower NSH, and that “the Upper-NSH information is carried along the lower-level chain without modification.” I read this to mean that the upper and lower NSH can independently be protected with different keys. The text even helpfully points out that “Keying material used at the upper-level domain SHOULD NOT be the same as the one used by a lower-level domain.” Such a construct suggests that there are multiple MAC/Encrypted Metadata context headers, one for the upper and another for the lower. However, Section 7.1 later notes that “Only one instance of "MAC and Encrypted Metadata" Context Header (Section 5) is allowed.” This seems like conflict. What am I missing? ** Section 7.2. On computing the HMAC in an integrity only situation: -- This section defines the MAC as “T = HMAC-SHA-256-128(MAC_KEY, A)”. Previously, A was defined as the Additional Authenticated Data (per Section 4.2). Since this isn’t the AEAD use case, there is no A. It seems that this should be something closer to: “T = HMAC-SHA-256-128(MAC_KEY, )”. -- The text would benefit from a description on how to serialize the packet for hashing. For example, Figure 6 and 7 are helpful logical descriptions of the integrity scope. However, the MAC field itself is depicted as part of the what should get hashed. Should that field be zeroed out? Removed? ** Section 9. The attacks discussed in [I-D.nguyen-sfc-security-architecture] are handled owing to the solution specified in this document, except for attacks dropping packets. The above reference highlights the following attackers – “There are many types of compromised switches attack: packet dropping, packet duplicating, packet manipulating, incorrect forwarding, eavesdropping, weight adjusting, man-in-the-middle, state-spoofing, control-channel hijacking, etc.” Per the security services in this document, it doesn’t seem like all are mitigated by this draft as described above: -- packet dropping = noted as not being handled -- packet manipulating, eavesdropping, weight adjusting, man-in the-middle, state-spoofing, and control-channel hijacking = appear to be handled if both security services are applied -- packet duplicating = this draft doesn’t not provide a standardized approach for mitigating this issue -- incorrect forwarding = doesn’t appear to be mitigated. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ** Section 1. Thus, the NSH does not have to rely upon an underlying transport encapsulation for security and confidentiality. Isn’t confidentiality just a subset of the provided security properties, or is something else intended? Recommend s/for security and confidentiality/for security/ ** Section 2. Per “Key Identifier: Is used to identify and deliver keys to authorized entities. See, for example, 'kid' usage in [RFC7635]”. How does a key identifier “delivery keys”? Doesn’t another protocol provide the delivery using the kid as an identifier? ** Section 7.2. How does one serialize the packet data to construct A? Figure 7 is the closest guidance but it includes the MAC itself. ** Section 7.4. … legitimate duplicate packets will be tagged by NSH-aware nodes involved in that segment as replay packets unless sufficient entropy is added to the duplicate packet. What is the prescribed mechanism to add entropy? ** Section 7.5 When an SFC data plane element receives an NSH packet, it MUST first ensure that a "MAC and Encrypted Metadata" Context Header is included. I was under the impression that the security protections specified in this document were optional in the overall SFC architecture. Is there some caveat to add to this section to reminder readers? Perhaps, “When an SFC data plan element conforms to this specification, it MUST first …” ** Section 7.5 and 7.6. What is the error processing for receiving a packet with an unknown key identifier? ** Section 9. Section 9. Can you further clarify how is the reader supposed to interpret the guidance in RFC4107 which frames its scope as guidelines as to be “... use[d] by IETF working groups and protocol authors who are determining whether to mandate automated key management and whether manual key management is acceptable. Informed judgment is needed.” Does this document take a position on automated vs. manual key management? ** Section 9. Per “The secret key (K) must have an expiration time assigned …”: (I suspect many of these issues are out of scope …) -- who assigns that expiration time (the key management system)? -- who knows about that expiration time, is it both the key management system and the participating nodes? If the nodes know the expiration time, should they refuse to decrypt a message with an expired key? This check of expiration is not the Section 7.5 or 7.6 procedures. ** Section 9. In the spirit of inclusive language, please s/A man-in-the-middle/An on-path-attacker/ ** Section 9. In an SFC-enabled domain where the above attacks are possible, (1) NSH data MUST be integrity-protected and replay-protected, and (2) privacy-sensitive NSH metadata MUST be encrypted for confidentiality preservation purposes. Related to the COMMENTs raised by Lars and Alvaro. It’s my understanding that the security protections here are optional for the SFC architecture – is this correct? If so, I don’t follow the above guidance. With the exception of “data carried in the context headers having privacy sensitive information”, all SFC-enabled domains have the potential for the above described attacks. It seems like this document is helpfully making integrity, replay and encrypted meta-data a requirement for the entire SFC architecture (without explicitly updating RFC8300) ** Section 9.1 An active attacker can potentially modify the Base header (e.g., decrement the TTL so the next SFF in the SFP discards the NSH packet). In the meantime, an active attacker can also drop NSH packets. The phrase “In the meantime …” suggests that these two active attackers are coordinating. Both of these sentences seem to be describing independent attackers. ==[ Editorial ** Abstract. Typo. This sentence doesn’t parse. OLD Also, this specification allows to encrypt sensitive metadata that is carried in the NSH. NEW Also, this specification allows for the encryption of sensitive metadata that is carried in the NSH. ** Section 1. Editorial. s/to is an information/to is information/ ** Section 1. Editorial. s/This specification fills that gap/This specification fills that gap for SFC/ ** Section 1. Editorial. s/This specification limits thus access/This specification limits access/ ** Section 3. Editorial. s/The NSH allows to share/The NSH shares/ ** Section 4.1.2. Editorial. s/SFFs are not thus provided/SFFs are not provided/ ** Section 4.2. Editorial. Recommend being clearer on the section – s/The authenticated encryption algorithm defined in [RFC7518]/ The authenticated encryption algorithm defined in Section 5.2 of [RFC7518]/; or you could name the algorithm directly with the reference. ** Section 4.4. Editorial. s/Doing so allows to address the problem/Doing so addresses the problem/ From nobody Tue Jul 13 13:39:00 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7556C3A07D9; Tue, 13 Jul 2021 13:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 jhSFhCmqSy9c; Tue, 13 Jul 2021 13:38:39 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130081.outbound.protection.outlook.com [40.107.13.81]) (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 D0C5D3A07B1; Tue, 13 Jul 2021 13:38:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DfZ3Rk3sbg3Kglcj/zN4jQPOdKg17e++s49Hyfy20OOYMn1sW4XfsMUIo693adNEeulq6xd55Z4JVxa0luNGPu0EUhG9jsu1DS18sUYeU2i8Y1c9wuiAD0h9+apLqX58hNuQyhAVDOr95+tjejHTxX0vftLi9ATQew2ozi3gUfIOemCTgPyXvab+hPucki92NIU8DsdU+rJD442uEN5X2JDIDhRa1qA45e2fzAFkAiTyl1LoVDQaUQuNIAbLRODc/4ZCHaVfk4jzDdnxBbKTs8i3BumLjqOasbuDXpgV/XOK921rcc6sDekIuq3nIak1tIYZFluhvqObOnvYHxFW5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w2XYKbT+Yq2W6mMglisvVuiUvoczNAtxJ4Okh3M79T4=; b=Rrl2fsPDcsSBP05iejq+RSfHnMfNa+u39ybPVRLBbfv0Ab1kualHpOgY3VUZiiWj2qH8RrJ0UqzTXe8+kz4RCd+sfXXJJ05RXKtJM0Y5UHp7j0A+acfJ1CqqX2KndJiEkccOkCuVTBcEBtz03tjnCFe9qe46ZfjedGAMXqODSh0WQgkgucAsjSXnD1qWM5jZMfiBR0VYStp/FDJLHkg7IRYWFr6pb/Py3nL1Rc74fCTTgMSE1aoLMPKD0ympV4U6gr+KCpGmvsDQtuzrmNEemiifpeedWiUXzLOCyVgCOz1nnW1RJy0ykzzUPIdwKmfgoBBc5hkG3x/9+/X6YHr1KQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w2XYKbT+Yq2W6mMglisvVuiUvoczNAtxJ4Okh3M79T4=; b=lnboQR+FInacC5/IIPZ/2ypETMDnYtjHMcsUb5QyychSEBdxqE2G8Ak9chfgwxdK7mKABuFKumFN60n4mNtnRdQYzg+MiCiex+vz+9vz0en7THY4k9YpYwx08mzGauZbAtaYlXBp2hiIUsIuMnhT7NK8D9vClIs4f+ympOylzu0= Received: from HE1PR07MB4187.eurprd07.prod.outlook.com (2603:10a6:7:98::23) by HE1PR0701MB2908.eurprd07.prod.outlook.com (2603:10a6:3:4f::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.14; Tue, 13 Jul 2021 20:38:35 +0000 Received: from HE1PR07MB4187.eurprd07.prod.outlook.com ([fe80::158:faff:a530:9dcd]) by HE1PR07MB4187.eurprd07.prod.outlook.com ([fe80::158:faff:a530:9dcd%6]) with mapi id 15.20.4331.021; Tue, 13 Jul 2021 20:38:35 +0000 From: Zaheduzzaman Sarker To: "mohamed.boucadair@orange.com" , The IESG CC: "draft-ietf-sfc-nsh-integrity@ietf.org" , "sfc-chairs@ietf.org" , "sfc@ietf.org" , "gregimirsky@gmail.com" Thread-Topic: Zaheduzzaman Sarker's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) Thread-Index: AQHXd9MGZ6YQ3JB9xEC80kobg/6Ve6tAvpKAgABUlwCAACjAIIAAIlsO Date: Tue, 13 Jul 2021 20:38:34 +0000 Message-ID: References: <162617261371.15907.6050785043086194503@ietfa.amsl.com> <3763_1626174382_60ED73AE_3763_126_1_787AE7BB302AE849A7480A190F8B9330353BE5BA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <232E3C7F-E4E6-456F-8E02-B9FF61D4B9A9@ericsson.com>, <25943_1626201422_60EDDD4E_25943_119_1_787AE7BB302AE849A7480A190F8B9330353BE9FA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <25943_1626201422_60EDDD4E_25943_119_1_787AE7BB302AE849A7480A190F8B9330353BE9FA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 34fa42bf-e878-4662-d337-08d9463e2fa4 x-ms-traffictypediagnostic: HE1PR0701MB2908: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: eawFXyKnejYwq5+gt9aK5Fnta10DtZWdP2+8KaLMfH9bMyhGrqUhiuxaNWvz6MmVITnkZeduPTqdp2Yo01TTQN7VfsIoHGCCV+lavl2fcMYR+FmftpHIpI/OSXjvoDgmPXZAhPf4KSvpvnTh35XWSQai9L9jDGqCVjl8ffVY257+fLhBp7lqqXzEc1cmXCH3+cP8QjM+M7QC0eX0GsKGG4ur4q9HSib+ATuKBxRfpX5Av2lyrM2xAlbcsduaaOmmS0H+8/YR4TDl05syX8wTbtAukWOUv4OC87ctuyLfU8za6XWxL26jlPQVPklJ3d6SxvPA7a65axPzqMA2Gs1zxfyk6KcrdOu5sbVB3E2zqgIB5gs6pnzwGfIMKAIM0HYApOf4T5NO+Yibn8ziF+cKwuWT+2OI7ctx0+794L6dp9fQf563MuVCOFvSb1XFa7on5xN6zs/l6PiK7ru3bysrGC+m7KoPEhqkLH0W3kc+wkbJ3Luedjuu95fVZ1kLHwU64xKndI/SPr9OZjevcaSI1/obZP2/gQvALDcEWFoQtlpnyTkrauFlQONdkHIPAKa90Ax2aYc2tpNBnbNhQi1qUuKvMARYHLEZunnxcyPohw4i5CoGwJYnZIZAU1mK2lAslNhn5WZqGwGq36pdrz80hb2lGhBms1n1sIz25LUsRzs9Dv+3+h6nr41iAwg9QgKgaumuZsUtJoxdd3ds2SIWTEXj32I3X+Z831BABB2ATkw= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4187.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(376002)(346002)(366004)(39860400002)(66446008)(66946007)(6506007)(166002)(86362001)(53546011)(64756008)(7696005)(54906003)(76116006)(52536014)(9686003)(66476007)(8936002)(4326008)(44832011)(83380400001)(66556008)(316002)(122000001)(110136005)(186003)(26005)(2906002)(38100700002)(5660300002)(966005)(8676002)(55016002)(33656002)(478600001)(71200400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?9MGHALv0Jr+XGATmzDZLnOkdpmvCzX+GY7xSoGyCxYZKw6ZLDgvqpq6vwo?= =?iso-8859-1?Q?hlwEYjZ618KVRWeJFozBTZk3YtOE3K2wUQl2uPg7jNUvjaH0+P4RBTLi7c?= =?iso-8859-1?Q?JXY2VzRtNlRR8XBXM6c0DS5Ehjle1naeFWrZiK1AtSQyeDhAvB9YKswmbR?= =?iso-8859-1?Q?FHWgx5qrKehkn8/FCBwJm/eqB7iAzUFk1yM81SXJ2eMNz1RgqunBMYgyB3?= =?iso-8859-1?Q?7vibf9y0g5L4gKPXQG3pTzCvY6S228bCFVP7Fb3EPGpM2WZBig6JY9VB9c?= =?iso-8859-1?Q?TVlLkf6g+2M4So6udX5kPcVUJEjDKWNtn009QuUosD9Q/QTGaqKnT+YPNp?= =?iso-8859-1?Q?dbHiAECQhRBtrr1FNQxdzbeHayWhFxEqoHimykZO/PQo9wjXiT7SIwEqqo?= =?iso-8859-1?Q?spsotKfENig9CEIHTLK3gAyiaRArYYA9cgIjSVh1zu84XYeeoKvpA6C6+u?= =?iso-8859-1?Q?Q9X6Bb05tU7oRZLyiaJn0KFGrV2eRb7qfyBDMoXa2b6mZ52zwofeVa7iO/?= =?iso-8859-1?Q?cQ3WHth0sPKbnVooDf8dHsnqz+tcX2bey+WY2LUM0phrEBvVBm+cmtwBZd?= =?iso-8859-1?Q?MKbvdlH8LqJgh4YoPwi/6312gHDr22G0MbHfPOBOvS10KaUCnXe9d7ZkS2?= =?iso-8859-1?Q?QvCYgk0z2OEumH5sj9DActTGzTbVJtBKuoidg+7vX0ZD7kkZCU88TRvuGi?= =?iso-8859-1?Q?MCwEatgvdy0OHJXMDbsxTqXOqeOP0fyabnKMXn9DB+xmXyLCzY6dATtEA5?= =?iso-8859-1?Q?532hdvsY+ZSmUfjpNdp9T4QDRmuKpicRaTyW8BNNE8/eK+SyGrgPVLJ7cF?= =?iso-8859-1?Q?v5BDRCaZmmfnMmRPkgPelvo9DzMBb+6JrgNgG/Ak9ozcAILOFES/p/pRo7?= =?iso-8859-1?Q?GC/WpgcfYVe4E9/+mgIB7sRti1VrDLLxHflJzoYCTmRF2lZE9yCrdH1RPM?= =?iso-8859-1?Q?RUsw9aPd/qZtPd7Wpr78uLEGkXabyn1padbRx7gBaLiVw6iY3GjwS9bK5s?= =?iso-8859-1?Q?wR9qxoa7HLLnfLNoKUFdKUQMTrGWuyUMEfnS++n/EhLKsBPvlhvLlDXJS+?= =?iso-8859-1?Q?aKNxI6Cs/m8U0U+pwsegP9Px18IvWR0V79oZBGvKfhlnjXuot5tPrBwj1D?= =?iso-8859-1?Q?jTonJpf7uVXkfEitG3idRmmB4PiSJ9OMXR28TqzsMNJWxf8jZ2KDFUu8ps?= =?iso-8859-1?Q?WxHmscw9W5aroM1esRcs3427piOiPhKRNerImSe8+3wYbL39h3RKsurKaG?= =?iso-8859-1?Q?ZaBdqtoS7opzwtAVjeXyjnuf7DhLhF3welJUm+ePK6r4CDYuQr48l0wCm/?= =?iso-8859-1?Q?geACUKE7C81rigToKlH/8CyZSu3spUJnMtB0Su4JhZ5hZJ+MV3+RvkZslR?= =?iso-8859-1?Q?OjEv5dtbnXI9TJaDzM/ihiU9ofPfu9CA=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_HE1PR07MB4187CCC2281759F37000E13C9F149HE1PR07MB4187eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4187.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 34fa42bf-e878-4662-d337-08d9463e2fa4 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2021 20:38:34.9044 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Aodpfeedb+q2UF4472OvEuVHzEuJnGAbs/SvdSq7MT97uOPbrz5wKzxndvKitSsFGNNhuqhlFsXhRISPa+/NTpyVjSQMrWvwuQtwUA7WabU5uTiEh8C26NJWGBL4UIiF X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2908 Archived-At: Subject: Re: [sfc] Zaheduzzaman Sarker's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2021 20:38:55 -0000 --_000_HE1PR07MB4187CCC2281759F37000E13C9F149HE1PR07MB4187eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for addressing my comments. Looks good to me. BR Zahed ________________________________ From: mohamed.boucadair@orange.com Sent: Tuesday, July 13, 2021 8:37:02 PM To: Zaheduzzaman Sarker ; The IESG Cc: draft-ietf-sfc-nsh-integrity@ietf.org ; sfc-chairs@ietf.org ; sfc@ietf.org ; gregimirsky@gmail.com Subject: RE: Zaheduzzaman Sarker's No Objection on draft-ietf-sfc-nsh-integ= rity-06: (with COMMENT) Re-, Sure. Added a sentence to the introduction: https://protect2.fireeye.com/v1= /url?k=3D8f5926fb-d0c21fd6-8f596660-8692dc8284cb-13fc495eae83f895&q=3D1&e= =3Da8edbcbc-a167-4689-86fa-60282dba2815&u=3Dhttps%3A%2F%2Ftinyurl.com%2Fnsh= -integrity-latest. Cheers, Med > -----Message d'origine----- > De : Zaheduzzaman Sarker [mailto:zaheduzzaman.sarker@ericsson.com] > Envoy=E9 : mardi 13 juillet 2021 16:09 > =C0 : BOUCADAIR Mohamed INNOV/NET ; The > IESG > Cc : draft-ietf-sfc-nsh-integrity@ietf.org; sfc-chairs@ietf.org; > sfc@ietf.org; gregimirsky@gmail.com > Objet : Re: Zaheduzzaman Sarker's No Objection on draft-ietf-sfc- > nsh-integrity-06: (with COMMENT) > ... > > > > > * I think it will be helpful to explicitly mention if > integrity and > > confidentiality by the transport encapsulation is needed or > not when > > this specification is in use. This specification definitely > says > > that one does not need to relay on the service provided by the > > transport encapsulation but it does not says that those > services are > > not longer required. > > [Med] We don't say so because this is deployment-specific. One > may deploy hSFC (RFC8459) with transport security to interconnect > lower-level domains, but use this spec within a lower-level domain. > > Ok, then can we write something along the lines you have written > here? This might actual help the why not updating 8300 discussion as > well. > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_HE1PR07MB4187CCC2281759F37000E13C9F149HE1PR07MB4187eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thanks for addressing my comments. Looks good to me.

BR
Zahed
From: mohamed.boucadair@ora= nge.com <mohamed.boucadair@orange.com>
Sent: Tuesday, July 13, 2021 8:37:02 PM
To: Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com>; Th= e IESG <iesg@ietf.org>
Cc: draft-ietf-sfc-nsh-integrity@ietf.org <draft-ietf-sfc-nsh-int= egrity@ietf.org>; sfc-chairs@ietf.org <sfc-chairs@ietf.org>; sfc@i= etf.org <sfc@ietf.org>; gregimirsky@gmail.com <gregimirsky@gmail.c= om>
Subject: RE: Zaheduzzaman Sarker's No Objection on draft-ietf-sfc-ns= h-integrity-06: (with COMMENT)
 
Re-,

Sure. Added a sentence to the introduction: https://protect2.fireeye.com/v1/url?k=3D8f5926fb-d0c21fd6-8f596660-8692dc82= 84cb-13fc495eae83f895&q=3D1&e=3Da8edbcbc-a167-4689-86fa-60282dba281= 5&u=3Dhttps%3A%2F%2Ftinyurl.com%2Fnsh-integrity-latest.

Cheers,
Med

> -----Message d'origine-----
> De : Zaheduzzaman Sarker [mailto:zaheduzzaman.sarker@ericsson.com]
> Envoy=E9 : mardi 13 juillet 2021 16:09
> =C0 : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.co= m>; The
> IESG <iesg@ietf.org>
> Cc : draft-ietf-sfc-nsh-integrity@ietf.org; sfc-chairs@ietf.org;<= br> > sfc@ietf.org; gregimirsky@gmail.com
> Objet : Re: Zaheduzzaman Sarker's No Objection on draft-ietf-sfc-=
> nsh-integrity-06: (with COMMENT)
>
...
>
>     >
>     > * I think it will be helpful to explicitl= y mention if
> integrity and
>     > confidentiality by the transport encapsul= ation is needed or
> not when
>     > this specification is in use. This specif= ication definitely
> says
>     > that one does not need to relay on the se= rvice provided by the
>     > transport encapsulation but it does not s= ays that those
> services are
>     > not longer required.
>
>     [Med] We don't say so because this is deployme= nt-specific. One
> may deploy hSFC (RFC8459) with transport security to interconnect
> lower-level domains, but use this spec within a lower-level domain. >
> Ok, then can we write something along the lines you have written
> here? This might actual help the why not updating 8300 discussion as > well.
>

___________________________________________________________________________= ______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified.
Thank you.

--_000_HE1PR07MB4187CCC2281759F37000E13C9F149HE1PR07MB4187eurp_-- From nobody Wed Jul 14 02:28:07 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F703A0772; Wed, 14 Jul 2021 02:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDkPdz9ECaaU; Wed, 14 Jul 2021 02:27:58 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F2FA3A0770; Wed, 14 Jul 2021 02:27:56 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id u25so2365843ljj.11; Wed, 14 Jul 2021 02:27:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7VtpBu63Uynh+Z9TSc1eqBvxvYTMzOAtwinmc6rU9NA=; b=RUWSYxG33jRhlWnD3HhjiWxWyEbgEyIyC4LHP8K0+aCFT/sC8xRMY+nJDOV6rIrBrC dqSVeJx35H9A/wM5zEila2lYmE+fA44TxVWIfJ5wMgLxGfJYQgYMnMnQTZf7Ttn7xLwV MqKjC438CmPRa1lR8Ah3t6Vyol2RexwnvBLDSBd24tBmuyAHayCGak5aZLMJc/I5uRGD SAOsqHzoQ4iqpZfiwIyNP4hZ/wLQ9Zm7XSb1qU1IHlFfESI9Pm+Gy/zu0GhCQkbrOVHf D5Jcur5Zf9uz0o5Zci843XVagcsTZ5rRaacPVvGSshK/iUncVkvj3OBApKSunQ14Dkiz c/zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7VtpBu63Uynh+Z9TSc1eqBvxvYTMzOAtwinmc6rU9NA=; b=LZJoylzDJCg6kKB13cctRVTVqw43/FZSbSwwCh4DGkDX6L8c13Psl5kQD/lhzlmFUR Ap9F/2JXAhVFLqD4VTe5EsnFsEoDICeXuTFe6956zYCK9W87QwEZHlSA3w9B07pNGjI8 py0Q+ueauf5ZAbaGm/KIykHqXN378hJbBN4LuAQR0jn5BNvI3EAw3Ts+Lxp2iiscK0px uPiNTWDpyJtFU6apHwberRyaxkZCnkV7hZ+uCSCQd2GtN7/NUKdfyN9o6HJ9O3aQy140 3O/UP/p+YOYpWvK87qdM0xBUdoUOpk445NZXRzw7+aAnOA/vNHD8WcNaDLoIvCpX85Ok T9/Q== X-Gm-Message-State: AOAM530QI7jB2RHaFzQRtygvM9BZgb+XpKXRT4FbfLlRdeCj7NrKlj1y mNmnUFgKagUXuGMozSk/hITdUgwXldLwhYAnb4k= X-Google-Smtp-Source: ABdhPJzwcDq0BxvsXQMyLkZs/GnpEqfAiaMOKxZ01m0GgcPH8xpxx5FuBAMH88SEioag0SG1h82EHct3kYLHnV9HM9A= X-Received: by 2002:a2e:9759:: with SMTP id f25mr8429640ljj.285.1626254873717; Wed, 14 Jul 2021 02:27:53 -0700 (PDT) MIME-Version: 1.0 References: <162620296297.3569.2501497601980031548@ietfa.amsl.com> In-Reply-To: <162620296297.3569.2501497601980031548@ietfa.amsl.com> From: tirumal reddy Date: Wed, 14 Jul 2021 14:57:42 +0530 Message-ID: To: Roman Danyliw Cc: The IESG , draft-ietf-sfc-nsh-integrity@ietf.org, sfc-chairs@ietf.org, sfc@ietf.org, gregimirsky@gmail.com Content-Type: multipart/alternative; boundary="0000000000000ff05605c711f881" Archived-At: Subject: Re: [sfc] Roman Danyliw's Discuss on draft-ietf-sfc-nsh-integrity-06: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2021 09:28:01 -0000 --0000000000000ff05605c711f881 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Roman, Please see inline On Wed, 14 Jul 2021 at 00:33, Roman Danyliw via Datatracker < noreply@ietf.org> wrote: > Roman Danyliw has entered the following ballot position for > draft-ietf-sfc-nsh-integrity-06: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > ** Section 4.6. This section explains that an upper NSH can be > encapsulated in > a lower NSH, and that =E2=80=9Cthe Upper-NSH information is carried along= the > lower-level chain without modification.=E2=80=9D I read this to mean tha= t the > upper > and lower NSH can independently be protected with different keys. The te= xt > even helpfully points out that =E2=80=9CKeying material used at the upper= -level > domain > SHOULD NOT be the same as the one used by a lower-level domain.=E2=80=9D = Such a > construct suggests that there are multiple MAC/Encrypted Metadata context > headers, one for the upper and another for the lower. However, Section 7= .1 > later notes that =E2=80=9COnly one instance of "MAC and Encrypted Metadat= a" Context > Header (Section 5) is allowed.=E2=80=9D This seems like conflict. What = am I > missing? > It means only one instance "MAC and Encrypted Metadata" Context Header (Section 5) is allowed in an NSH-level (one instance in the Upper-NSH and another in the Lower-NSH), we will update text for better clarity. > > ** Section 7.2. On computing the HMAC in an integrity only situation: > > -- This section defines the MAC as =E2=80=9CT =3D HMAC-SHA-256-128(MAC_KE= Y, A)=E2=80=9D. > Previously, A was defined as the Additional Authenticated Data (per Secti= on > 4.2). Since this isn=E2=80=99t the AEAD use case, there is no A. It seem= s that > this > should be something closer to: =E2=80=9CT =3D HMAC-SHA-256-128(MAC_KEY, <= part of the > packet you want to hash>)=E2=80=9D. > Good catch, will update to "T =3D HMAC-SHA-256-128(MAC_KEY, target NSH data= )" > > -- The text would benefit from a description on how to serialize the > packet for > hashing. For example, Figure 6 and 7 are helpful logical descriptions of > the > integrity scope. However, the MAC field itself is depicted as part of th= e > what > should get hashed. Should that field be zeroed out? Removed ? > Yes, we will update text as follows: The NSH imposer sets the MAC field to zero and then computes the message integrity for the target NSH data (depending on the integrity protection scope discussed in Section 5) using MAC_KEY and HMAC algorithm. It inserts the computed digest in the MAC field in the "MAC and Encrypted Metadata" Context Header. > > ** Section 9. > The attacks discussed in [I-D.nguyen-sfc-security-architecture] are > handled owing to the solution specified in this document, except for > attacks dropping packets. > > The above reference highlights the following attackers =E2=80=93 =E2=80= =9CThere are many > types > of compromised switches attack: packet dropping, packet duplicating, pack= et > manipulating, incorrect forwarding, eavesdropping, weight adjusting, > man-in-the-middle, state-spoofing, control-channel hijacking, etc.=E2=80= =9D Per > the > security services in this document, it doesn=E2=80=99t seem like all are = mitigated > by > this draft as described above: > > -- packet dropping =3D noted as not being handled > > -- packet manipulating, eavesdropping, weight adjusting, man-in the-middl= e, > state-spoofing, and control-channel hijacking =3D appear to be handled if > both > security services are applied > Yes. > > -- packet duplicating =3D this draft doesn=E2=80=99t not provide a standa= rdized > approach > for mitigating this issue > Replay attack is detected using timestamp and recording a unique value within the delta window derived from the NSH data and packet (see https://datatracker.ietf.org/doc/html/draft-ietf-sfc-nsh-integrity#section-= 7.4 ). > > -- incorrect forwarding =3D doesn=E2=80=99t appear to be mitigated. > If the context headers are encrypted, an attacker receiving forwarded NSH from an compromised switch will not be able to decrypt the context headers. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > ** Section 1. > Thus, the NSH > does not have to rely upon an underlying transport encapsulation for > security and confidentiality. > > Isn=E2=80=99t confidentiality just a subset of the provided security prop= erties, > or is > something else intended? Recommend s/for security and confidentiality/fo= r > security/ > Yes, I will update the text. > > ** Section 2. Per =E2=80=9CKey Identifier: Is used to identify and deli= ver keys > to > authorized entities. See, for example, 'kid' usage in [RFC7635]=E2=80=9D= . How > does a > key identifier =E2=80=9Cdelivery keys=E2=80=9D? Doesn=E2=80=99t another = protocol provide the > delivery > using the kid as an identifier? > Yes, kid is typically used as an identifier by a KMS protocol. > > ** Section 7.2. How does one serialize the packet data to construct A? > Figure > 7 is the closest guidance but it includes the MAC itself. > The MAC field is set to zero before computing the message integrity, we will update the text. > > ** Section 7.4. > =E2=80=A6 legitimate duplicate packets will be > tagged by NSH-aware nodes involved in that segment as replay packets > unless sufficient entropy is added to the duplicate packet. > > What is the prescribed mechanism to add entropy? Sequence numbers can be used as discussed in the note in Section 7.4 > > ** Section 7.5 > When an SFC data plane element receives an NSH packet, it MUST first > ensure that a "MAC and Encrypted Metadata" Context Header is > included. > > I was under the impression that the security protections specified in thi= s > document were optional in the overall SFC architecture. Is there some > caveat > to add to this section to reminder readers? Perhaps, =E2=80=9CWhen an S= FC data > plan > element conforms to this specification, it MUST first =E2=80=A6=E2=80=9D > Yes, we will update. > > ** Section 7.5 and 7.6. What is the error processing for receiving a > packet > with an unknown key identifier? > An error should be logged, we will update the draft. > > ** Section 9. Section 9. Can you further clarify how is the reader > supposed to > interpret the guidance in RFC4107 which frames its scope as guidelines as > to be > =E2=80=9C... use[d] by IETF working groups and protocol authors who are d= etermining > whether to mandate automated key management and whether manual key > management is acceptable. Informed judgment is needed.=E2=80=9D Does th= is > document > take a position on automated vs. manual key management? > > ** Section 9. Per =E2=80=9CThe secret key (K) must have an expiration ti= me > assigned =E2=80=A6=E2=80=9D: > > (I suspect many of these issues are out of scope =E2=80=A6) > > -- who assigns that expiration time (the key management system)? > Yes. > > -- who knows about that expiration time, is it both the key management > system > and the participating nodes? If the nodes know the expiration time, should > they refuse to decrypt a message with an expired key? This check of > expiration > is not the Section 7.5 or 7.6 procedures. > Yes, a KMS can assign keys for multiple key intervals. > ** Section 9. In the spirit of inclusive language, please s/A > man-in-the-middle/An on-path-attacker/ > Okay. > > ** Section 9. > In an SFC-enabled domain where the above attacks are possible, (1) > NSH data MUST be integrity-protected and replay-protected, and (2) > privacy-sensitive NSH metadata MUST be encrypted for confidentiality > preservation purposes. > > Related to the COMMENTs raised by Lars and Alvaro. > > It=E2=80=99s my understanding that the security protections here are opti= onal for > the > SFC architecture =E2=80=93 is this correct? If so, I don=E2=80=99t follo= w the above > guidance. > With the exception of =E2=80=9Cdata carried in the context headers having= privacy > sensitive information=E2=80=9D, all SFC-enabled domains have the potentia= l for the > above described attacks. It seems like this document is helpfully making > integrity, replay and encrypted meta-data a requirement for the entire SF= C > architecture (without explicitly updating RFC8300) > > ** Section 9.1 > An active attacker can potentially modify the Base header (e.g., > decrement the TTL so the next SFF in the SFP discards the NSH > packet). In the meantime, an active attacker can also drop NSH > packets. > > The phrase =E2=80=9CIn the meantime =E2=80=A6=E2=80=9D suggests that thes= e two active attackers are > coordinating. Both of these sentences seem to be describing independent > attackers. > Yes, I will remove "In the meantime". > > =3D=3D[ Editorial > ** Abstract. Typo. This sentence doesn=E2=80=99t parse. > OLD > Also, > this specification allows to encrypt sensitive metadata that is > carried in the NSH. > > NEW > Also, this specification allows for the encryption of sensitive metadata > that > is carried in the NSH. > > ** Section 1. Editorial. s/to is an information/to is information/ > > ** Section 1. Editorial. s/This specification fills that gap/This > specification fills that gap for SFC/ > > ** Section 1. Editorial. s/This specification limits thus access/This > specification limits access/ > > ** Section 3. Editorial. s/The NSH allows to share/The NSH shares/ > > ** Section 4.1.2. Editorial. s/SFFs are not thus provided/SFFs are not > provided/ > > ** Section 4.2. Editorial. Recommend being clearer on the section =E2=80= =93 s/The > authenticated encryption algorithm defined in [RFC7518]/ The authenticate= d > encryption algorithm defined in Section 5.2 of [RFC7518]/; or you could > name > the algorithm directly with the reference. > > ** Section 4.4. Editorial. s/Doing so allows to address the problem/Doing > so > addresses the problem/ > Thanks, we will fix all the above nits in the next revision. Cheers, -Tiru --0000000000000ff05605c711f881 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Roman,

Please see i= nline

On Wed, 14 Jul 2021 at 00:33, Roman Danyliw via Datatracker <= noreply@ietf.org> wrote:
Roman Danyliw has enter= ed the following ballot position for
draft-ietf-sfc-nsh-integrity-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft= -ietf-sfc-nsh-integrity/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

** Section 4.6.=C2=A0 This section explains that an upper NSH can be encaps= ulated in
a lower NSH, and that =E2=80=9Cthe Upper-NSH information is carried along t= he
lower-level chain without modification.=E2=80=9D=C2=A0 I read this to mean = that the upper
and lower NSH can independently be protected with different keys.=C2=A0 The= text
even helpfully points out that =E2=80=9CKeying material used at the upper-l= evel domain
SHOULD NOT be the same as the one used by a lower-level domain.=E2=80=9D=C2= =A0 Such a
construct suggests that there are multiple MAC/Encrypted Metadata context headers, one for the upper and another for the lower.=C2=A0 However, Sectio= n 7.1
later notes that =E2=80=9COnly one instance of "MAC and Encrypted Meta= data" Context
Header (Section 5) is allowed.=E2=80=9D=C2=A0 This seems like conflict.=C2= =A0 What am I missing?

It means only on= e instance "MAC and Encrypted Metadata" Context Header (Section 5= ) is allowed in an NSH-level (one instance in the=C2=A0Upper-NSH and another in the Lower-NSH), we will update text for better clarity.=C2=A0
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
** Section 7.2.=C2=A0 On computing the HMAC in an integrity only situation:=

-- This section defines the MAC as =E2=80=9CT =3D HMAC-SHA-256-128(MAC_KEY,= A)=E2=80=9D.
Previously, A was defined as the Additional Authenticated Data (per Section=
4.2).=C2=A0 Since this isn=E2=80=99t the AEAD use case, there is no A. It s= eems that this
should be something closer to: =E2=80=9CT =3D HMAC-SHA-256-128(MAC_KEY, <= ;part of the
packet you want to hash>)=E2=80=9D.

= Good catch, will update to "T =3D HMAC-SHA-256-128(MAC_KEY, target NSH= data)"
=C2=A0

-- The text would benefit from a description on how to serialize the packet= for
hashing.=C2=A0 For example, Figure 6 and 7 are helpful logical descriptions= of the
integrity scope.=C2=A0 However, the MAC field itself is depicted as part of= the what
should get hashed.=C2=A0 Should that field be zeroed out? Removed ?

Yes, we will update text as follows:=C2=A0

The NSH imposer= sets the MAC field to zero and then computes the message integrity for the= target NSH data (depending on the integrity protection scope discussed in= =C2=A0Section 5= ) using MAC_KEY and HMAC algorithm.=C2=A0It inserts the computed digest in the MAC field i= n=C2=A0the &quo= t;MAC and Encrypted Metadata" Context Header.=C2=A0
= =C2=A0

** Section 9.
=C2=A0 =C2=A0The attacks discussed in [I-D.nguyen-sfc-security-architecture= ] are
=C2=A0 =C2=A0handled owing to the solution specified in this document, exce= pt for
=C2=A0 =C2=A0attacks dropping packets.

The above reference highlights the following attackers =E2=80=93 =E2=80=9CT= here are many types
of compromised switches attack: packet dropping, packet duplicating, packet=
manipulating, incorrect forwarding,=C2=A0 eavesdropping, weight adjusting,<= br> man-in-the-middle, state-spoofing, control-channel hijacking, etc.=E2=80=9D= =C2=A0 Per the
security services in this document, it doesn=E2=80=99t seem like all are mi= tigated by
this draft as described above:

-- packet dropping =3D noted as not being handled

-- packet manipulating, eavesdropping, weight adjusting, man-in the-middle,=
state-spoofing, and control-channel hijacking =3D appear to be handled if b= oth
security services are applied

Yes.
=C2=A0

-- packet duplicating =3D this draft doesn=E2=80=99t not provide a standard= ized approach
for mitigating this issue

Replay attack= is detected using timestamp and recording a unique value=C2=A0within the d= elta window derived from the NSH=C2=A0data and packet=C2=A0(see https://datatracker.ietf.org/doc/html/draft-ietf-sfc-nsh-integrity#sec= tion-7.4).
=C2=A0

-- incorrect forwarding =3D doesn=E2=80=99t appear to be mitigated.

If the context headers are encrypted, an attac= ker receiving forwarded NSH from an compromised switch will not be able to = decrypt the context headers.=C2=A0
=C2=A0


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

** Section 1.
=C2=A0 =C2=A0Thus, the NSH
=C2=A0 =C2=A0does not have to rely upon an underlying transport encapsulati= on for
=C2=A0 =C2=A0security and confidentiality.

Isn=E2=80=99t confidentiality just a subset of the provided security proper= ties, or is
something else intended?=C2=A0 Recommend s/for security and confidentiality= /for
security/

Yes, I will update the text.= =C2=A0
=C2=A0

** Section 2.=C2=A0 Per =E2=80=9CKey Identifier:=C2=A0 Is used to identify = and deliver keys to
authorized entities.=C2=A0 See, for example, 'kid' usage in [RFC763= 5]=E2=80=9D. How does a
key identifier =E2=80=9Cdelivery keys=E2=80=9D?=C2=A0 Doesn=E2=80=99t anoth= er protocol provide the delivery
using the kid as an identifier?

Yes, ki= d is typically used as an identifier=C2=A0by a KMS protocol.=C2=A0
=C2=A0

** Section 7.2.=C2=A0 How does one serialize the packet data to construct A= ?=C2=A0 Figure
7 is the closest guidance but it includes the MAC itself.
<= div>
The MAC field is set to zero before computing the message integrity, we= will update the text.=C2=A0
=C2=A0

** Section 7.4.
=C2=A0 =C2=A0=E2=80=A6 legitimate duplicate packets will be
=C2=A0 =C2=A0tagged by NSH-aware nodes involved in that segment as replay p= ackets
=C2=A0 =C2=A0unless sufficient entropy is added to the duplicate packet.
What is the prescribed mechanism to add entropy?=C2=A0
Sequence numbers can be used as discussed in the note in Sectio= n 7.4=C2=A0
=C2=A0

** Section 7.5
=C2=A0 =C2=A0When an SFC data plane element receives an NSH packet, it MUST= first
=C2=A0 =C2=A0ensure that a "MAC and Encrypted Metadata" Context H= eader is
=C2=A0 =C2=A0included.

I was under the impression that the security protections specified in this<= br> document were optional in the overall SFC architecture.=C2=A0 Is there some= caveat
to add to this section to reminder readers?=C2=A0 Perhaps,=C2=A0 =E2=80=9CW= hen an SFC data plan
element conforms to this specification, it MUST first =E2=80=A6=E2=80=9D

Yes, we will update.=C2=A0
=C2= =A0

** Section 7.5 and 7.6.=C2=A0 What is the error processing for receiving a = packet
with an unknown key identifier?

An erro= r should be logged, we will update the draft.
=C2=A0

** Section 9. Section 9.=C2=A0 Can you further clarify how is the reader su= pposed to
interpret the guidance in RFC4107 which frames its scope as guidelines as t= o be
=E2=80=9C... use[d] by IETF working groups and protocol authors who are det= ermining
whether to mandate automated key=C2=A0 =C2=A0 management and whether manual= key
management is acceptable.=C2=A0 Informed judgment is needed.=E2=80=9D=C2=A0= Does this document
take a position on automated vs. manual key management?

** Section 9.=C2=A0 Per =E2=80=9CThe secret key (K) must have an expiration= time assigned =E2=80=A6=E2=80=9D:

(I suspect many of these issues are out of scope =E2=80=A6)

-- who assigns that expiration time (the key management system)?

Yes.
=C2=A0

-- who knows about that expiration time, is it both the key management syst= em
and the participating nodes?=C2=A0
If the nodes know the expiration time, should
they refuse to decrypt a message with an expired key?=C2=A0 This check of e= xpiration
is not the Section 7.5 or 7.6 procedures.

Yes, a KMS can assign keys for multiple key intervals.


** Section 9.=C2=A0 In the spirit of inclusive language, please s/A
man-in-the-middle/An on-path-attacker/

= Okay.
=C2=A0=C2=A0

** Section 9.
=C2=A0 =C2=A0In an SFC-enabled domain where the above attacks are possible,= (1)
=C2=A0 =C2=A0NSH data MUST be integrity-protected and replay-protected, and= (2)
=C2=A0 =C2=A0privacy-sensitive NSH metadata MUST be encrypted for confident= iality
=C2=A0 =C2=A0preservation purposes.

Related to the COMMENTs raised by Lars and Alvaro.

It=E2=80=99s my understanding that the security protections here are option= al for the
SFC architecture =E2=80=93 is this correct?=C2=A0 If so, I don=E2=80=99t fo= llow the above guidance.
With the exception of =E2=80=9Cdata carried in the context headers having p= rivacy
sensitive information=E2=80=9D, all SFC-enabled domains have the potential = for the
above described attacks.=C2=A0 It seems like this document is helpfully mak= ing
integrity, replay and encrypted meta-data a requirement for the entire SFC<= br> architecture (without explicitly updating RFC8300)

** Section 9.1
=C2=A0 =C2=A0An active attacker can potentially modify the Base header (e.g= .,
=C2=A0 =C2=A0decrement the TTL so the next SFF in the SFP discards the NSH<= br> =C2=A0 =C2=A0packet).=C2=A0 In the meantime, an active attacker can also dr= op NSH
=C2=A0 =C2=A0packets.

The phrase =E2=80=9CIn the meantime =E2=80=A6=E2=80=9D suggests that these = two active attackers are
coordinating.=C2=A0 Both of these sentences seem to be describing independe= nt
attackers.

Yes, I will remove "In = the meantime".=C2=A0
=C2=A0

=3D=3D[ Editorial
** Abstract.=C2=A0 Typo.=C2=A0 This sentence doesn=E2=80=99t parse.
OLD
Also,
=C2=A0 =C2=A0this specification allows to encrypt sensitive metadata that i= s
=C2=A0 =C2=A0carried in the NSH.

NEW
Also, this specification allows for the encryption of sensitive metadata=C2= =A0 that
is carried in the NSH.

** Section 1.=C2=A0 Editorial. s/to is an information/to is information/
** Section 1.=C2=A0 Editorial.=C2=A0 s/This specification fills that gap/Th= is
specification fills that gap for SFC/

** Section 1.=C2=A0 Editorial.=C2=A0 s/This specification limits thus acces= s/This
specification limits access/

** Section 3.=C2=A0 Editorial.=C2=A0 s/The NSH allows to share/The NSH shar= es/

** Section 4.1.2.=C2=A0 Editorial.=C2=A0 s/SFFs are not thus provided/SFFs = are not
provided/

** Section 4.2. Editorial.=C2=A0 Recommend being clearer on the section =E2= =80=93 s/The
authenticated encryption algorithm defined in [RFC7518]/ The authenticated<= br> encryption algorithm defined in Section 5.2 of [RFC7518]/; or you could nam= e
the algorithm directly with the reference.

** Section 4.4. Editorial. s/Doing so allows to address the problem/Doing s= o
addresses the problem/

Thanks, we will = fix all the above nits in the next revision.

Cheer= s,
-Tiru
--0000000000000ff05605c711f881-- From nobody Wed Jul 14 04:12:08 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 422573A088A; Wed, 14 Jul 2021 04:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.896 X-Spam-Level: X-Spam-Status: No, score=-11.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=kySH531M; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=FpPmc7lj 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 NL2D05WScJGd; Wed, 14 Jul 2021 04:12:01 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4605D3A0889; Wed, 14 Jul 2021 04:12:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14202; q=dns/txt; s=iport; t=1626261121; x=1627470721; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=JwvlKLkyBT/PGyQ+tunm0qB0S3qe9I9koJd1sasG1lI=; b=kySH531M60JjIE6nVpa4ZJjZpB+JVU6IrO3L7RVFZvILkUkEFIPU9t4U 9LvGlBPN5U7xuLVobxDyecTn5GZO3hjk0RXrGQJAcV8+RYnulE0JeJ0Ah 7p1eFg/nfiWfJTZivrmzROVSXx5Zc2yhMhelBw2HXOInaNSVsxAmT/uxn k=; X-IPAS-Result: =?us-ascii?q?A0DhAgBgxe5gl4ENJK1aHQEBAQEJARIBBQUBQIFZgVNRf?= =?us-ascii?q?loTJDGESINIA4U5iFgDgRAWiS+FFIpEgUKBEQNUCwEBAQ0BATUMBAEBhFQCF?= =?us-ascii?q?4JhAiU4EwIEAQEBAQMCAwEBAQEFAQEFAQEBAgEGBBQBAQEBAQEBAWiFOwYnD?= =?us-ascii?q?YZFAQEBAQIBEhERDAEBJRIBCwQCAQgRAwECAwIjAwICAh8RFAEFAwgCBAENB?= =?us-ascii?q?SKCTwGCVQMOIQEOmzIBgToCih96gTKBAYIHAQEGBASBSUGDMg0LgjIDBoEQK?= =?us-ascii?q?oJ7gnFTSoJJhBkIHxyBSUSBFScMEIIrNz6CIEICA4EoARIBIYMXNoIugidsB?= =?us-ascii?q?2MEFA4ZCAgGAg0TXwQVLQgHASMFBQIPKAQ4A5EECBMLB4J0R4hsgy+aSjtbC?= =?us-ascii?q?oMkijOHN4ZqBIVdBSaDY4tckGeGM4U0kFKML4Mxj3UnCAuEdAIEAgQFAg4BA?= =?us-ascii?q?QY1gT0ia1gRB3AVZQGCPlAZDoxlgToJAw0JFYM5hRSFSnM4AgYBCQEBAwkBj?= =?us-ascii?q?AsBAQ?= IronPort-PHdr: A9a23:lYDrxxT0gNXIMydWYgn9HTDS6tpso6PLVj580XJvo7VUe6Ks8tLpO 0mMrflujVqcW4Ld5roEjufNqKnvVCQG5orJq3ENdpFAFnpnwcUblgAtGoiJXEv8KvO5aDYzG stPElRi+iLzPU1cAs2rYVrUrzW75iITHROqMw1zK6z1F4fegt7x2fq1/sjYYh5Dg3y2ZrYhR Cg= IronPort-HdrOrdr: A9a23:/C0pjq8QNW7jN6BwKAduk+AtI+orL9Y04lQ7vn2ZKCYlEfBw+P rCoB1273PJYVUqOE3I++rvBEDoexq1n6KcG+EqVotKNDOW2ldAR7sC0WKN+VLd8gTFh4hg/J YlUZJTTPX2EFhBlM7/pCm+Dto6ytWf7aaywcfYwHEFd3APGthdxjY8KDy2VmVwWQlYBYEkDt 694ddKvDCtYGkQdYCaAXYCNtKzwOHjpdbFWzJDPRI99wWUrTSm7tfBYn2l4is= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.84,239,1620691200"; d="scan'208";a="741187829" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Jul 2021 11:11:59 +0000 Received: from mail.cisco.com (xbe-rcd-004.cisco.com [173.37.102.19]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 16EBBxIr029923 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 14 Jul 2021 11:11:59 GMT Received: from xfe-rcd-003.cisco.com (173.37.227.251) by xbe-rcd-004.cisco.com (173.37.102.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Wed, 14 Jul 2021 06:11:59 -0500 Received: from xfe-aln-004.cisco.com (173.37.135.124) by xfe-rcd-003.cisco.com (173.37.227.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Wed, 14 Jul 2021 06:11:59 -0500 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-004.cisco.com (173.37.135.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Wed, 14 Jul 2021 06:11:59 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GTtva3QSRki7NSgbY1WpSSkQYIDJNP6s00v4NeQmWAVaZgLRcWBDdnpnC6JyNwHjzkdbrLmO3kvlSUDxYsENV/vHIEka6ZllMFeK3+lDf1rktPy8bKyFprekpoXD8jLE3pF3KZQSxIXYO1EUBKv9dW1sN0y45387wJXJ/3McNN48T4laC4ueocgGfdjJAnmTmncMi0vdOZIwde1ITKXWeyJXf97fMzz4wPk7l+Ap3JnbZCbupBJR9hnFeCLhhMpcaVp/MMdQEYnOM1T4zTXC7TKxGPxGmKF7VU0Vw/FRAuIV8LwNtouwzokgoyo7sYIHuiQcMF5A/W4vNBcqY63evQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JwvlKLkyBT/PGyQ+tunm0qB0S3qe9I9koJd1sasG1lI=; b=bfR95sDKodYEZmv5593begeBgvwAh5IqqxPKRDquneQjOneh1J+T9Fj9ahmCTlg5+SbBM/avfq+k9I22fC1asi8JOp0BOyHQ01taGIItwyH/wKX56MF0hXffbSEUuEb8Aao9S2oPx2pT2mgjDvb6nNZ5ZP65xrEy3+BQFenma2hyO0diMw3UjubKEqd2uMu56Owzww2klPb5ymdTMbHwYZqbA3MAaeqLkbVs2kE73sy9mx6GC6XfMNRw4/U6HgiZwHRRfh8HhzO6dfxCGVCLYeov48kVszmopEU77pyR3g0fqZUwRqi8hAGNveOt6xI7svA+8n7b9lGy6Zr6QdWQeg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JwvlKLkyBT/PGyQ+tunm0qB0S3qe9I9koJd1sasG1lI=; b=FpPmc7ljmSVcCh+WaihkTTXzVOQOI+M0YO6rBlovT0R967t4FUrZYJZsPJE1a3AH5VTHmgfKWFeapYnfli0zwy49A++huuippdokSZS1skiynv8y3WAhrNQNoRXuwuQxQmQWRYZLeD3EyYpv2OWeg/Ta77fkvoedFR4AQp04d5U= Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB5111.namprd11.prod.outlook.com (2603:10b6:510:3c::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.26; Wed, 14 Jul 2021 11:11:58 +0000 Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::6d61:c160:def1:bc64]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::6d61:c160:def1:bc64%4]) with mapi id 15.20.4308.027; Wed, 14 Jul 2021 11:11:58 +0000 From: "Eric Vyncke (evyncke)" To: "mohamed.boucadair@orange.com" , The IESG CC: "draft-ietf-sfc-nsh-integrity@ietf.org" , "sfc-chairs@ietf.org" , "sfc@ietf.org" , "gregimirsky@gmail.com" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXNmYy1uc2gt?= =?utf-8?Q?integrity-06:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHXd+EWUzPhovDiy06QVDjdApotHKtBE6GQgAFgQoA= Date: Wed, 14 Jul 2021 11:11:57 +0000 Message-ID: <94FF1F19-7004-42C5-8560-C99A2FEEF71A@cisco.com> References: <162617866082.13596.2398814614966286542@ietfa.amsl.com> <15473_1626195281_60EDC551_15473_51_1_787AE7BB302AE849A7480A190F8B9330353BE8EC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <15473_1626195281_60EDC551_15473_51_1_787AE7BB302AE849A7480A190F8B9330353BE8EC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.51.21071101 authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a9b4c2cf-cc00-419f-c654-08d946b83242 x-ms-traffictypediagnostic: PH0PR11MB5111: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sHW+DINcIePRpe+Xlqz5vfomi1wJooJZ3ji2Lc5VWwGzpeb0xObTm7+AwHGRbLJTRZTdMAWo9ed2SJNsctfa9Uif4vSrqO8i59LSGTxR8Z3y8ncZU2o5h6Olb1UpPT88tEI6e9GJOrxAgD+10rQtGYeRGDC3SsOZW+wyqe646euJpli79PvVfFj232/1wrk+8wuUAZQwtw8WNVXSMGgxoXQP23ijUXYBsApBVX0S44BZrAiX4TvYenDka7S66bU+vArAX5BF6RQAbPX9KSfsUVzQVnLfcBXDLQW4OrBONYOqjsC5hXSXf35jpIlGsILROxEO7mRUjDphhS/yYQxv8v2/PWRuLyfJsDyI4nWLkVXERLSjhatMIEHI/bzMUmk1GlaHlIKRXQ0qHMhZEvS/CyaJf89g+IkqTolFMxSzrhhsUPwxobMT5oUd9IAic3jPDoF67KI47xwDtwvOU8v4WPeIc0M4UwujMIRZiPXmk/PM3FiWV26i/FhI6wOqW6K1Mn85gjtOlARq5SZcdlUX3oLLqxrGPE7Bcf+A88okojKPFManbT3+tUK+5EbufJod+PcazQ7Q9p7I2hIat7XA3zY0w8QGLUSuZ8+W/b3MHg9bDX4tFyKXAflYPEVo/610l6uUEuyrJxi7OB38GptP7avpBx9XrrE7Ii5bIAY9vL04kjwwVQCGLjhJa0PQP4kM2UMHbNvGrOhrq90BGMGW5s4DFyDPc9COrEK/GwArYxV58nE1Np2n27Q1MCZtFbOzeFhbLNir95CPYa0nRuNgM8MmvvGiP5NrRuM/Ddevu8cSk9LLKpDiYIEcbJ6fhoXJzFNTgllRAnWd8FQ+p98CztgUFNupIxJt7vQk3Cu/nmI= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(346002)(136003)(366004)(396003)(376002)(53546011)(6506007)(66556008)(8936002)(224303003)(66946007)(2906002)(66446008)(186003)(66476007)(2616005)(36756003)(110136005)(478600001)(91956017)(54906003)(86362001)(71200400001)(966005)(76116006)(6486002)(64756008)(316002)(5660300002)(4326008)(122000001)(38100700002)(33656002)(83380400001)(6512007)(45980500001)(38070700004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?WFowYmc1MnFISHFKdGlCNjlrdkJzNDNmZTRrSGswUitzenlpckxXZXBRb2xt?= =?utf-8?B?c1BqSmJiZld5dmEreTdaS05OQnhQS0tDUEVDdnpPYWFkazJOcjgvNjZYTzBL?= =?utf-8?B?K1g0c01hSEYxSEtLeXpnREhFNGU2QWVuaDZscG0zenpWeGVQY2lwL3ZvTW1C?= =?utf-8?B?aTR4M1RPTDNDd2JMY0VFbGlSeFRaUUxkWnJXVDhFV0JWNFczaHpmbjk0NGpm?= =?utf-8?B?ckdadmdoOUJBTWlzbU91WUFRNkFMckI2cHIwc01oaE8yOXFrYkFlRTlEb3FE?= =?utf-8?B?L3VxZzJ5WEVWZ0xER3pIWHh5SEJ1V05meTVZNUlJenNjV0JkZ1NKUnBZTXdG?= =?utf-8?B?NWtzQWNvelpHUVg3UnhuOHZJTDdYMkRiT0lnbUxiQU0zZ2RMRWc1Y3hlZ3A2?= =?utf-8?B?STUweE5yUGhKWU5KRWh2YWM3cjl0dWRZeGhYQmRMWTJaa3Vyck05SGVqL2Zn?= =?utf-8?B?b1FxdzJTelpGMnpZSU9SOGZSeTY3eFRMOWlkOUF0djNLcERjcXEzMzcxTUlC?= =?utf-8?B?QzBuMHV0YTRJTjFJL1h0L3Zybnl5ZzduMGdjaFZZdjdhbytpd1dBVEZtQVlT?= =?utf-8?B?emtMM2FNUVVxYllxWmM3ZzJpMVRuRGhZWEFoWUM1cE5TOUlOckdlaHR0Ukha?= =?utf-8?B?bCswbmk5ZUpHTVIvOHl5RlpkQ094RE8vZ2VqTW1VTHhnNTZwQWtlUitzcHYw?= =?utf-8?B?WmlDYld3cWo0ZElPVElJb3JhNVE1R0x1RjErWUNRQjF1UUxaZGRnSzd4TXpj?= =?utf-8?B?cUx4djI3bVBxVjVib3dnVzgzSUREM08rS2FWRnFjMXFzTmh6aFg1U3BBZCtU?= =?utf-8?B?U1FiTmp3YmZ2WmRhZnBjRVByc2hieGRSbEJhY3VzYk9tY1htQ3dPdzA4MTVV?= =?utf-8?B?UkVMbWJrN3Y3VTJrbWRPSWo0aGhZeDQ1cWJjRjVRRUNzYVFxSnpkWkg4QnpR?= =?utf-8?B?RlBza3lCZS9pbVI0RlNzdEd0K254OVdhUURWSis4T0dWaDFOaU4zbzZWUWM1?= =?utf-8?B?MUVZd3ZaSXVyai9KWFV5b1d5TnNqTTdPeDVjOVNxOG9EenZvR2JiM1dxcDE0?= =?utf-8?B?N2pRdVQ4T0tqZWhNdmZITmtPaXJXRmxXT08zUzlzSzI2ZGNLOW5xK1I5Ykdm?= =?utf-8?B?bkw4SjZBbTl6Vk8rdkhpWm9BNHZWbW1UQ2dEc3l3amZSZ2J6QVRxYzZZZEF6?= =?utf-8?B?d0xRWDhkaDBRN2dabGNoaXpyWWdTblNTQWZ2UTdkeXFUeFhvRnNoSWtaQUlW?= =?utf-8?B?RUQycTEzZUtvWkJzTllSL091ejZFbHBRVDFyRk5ESHVZSmo0bVdKclROUi9m?= =?utf-8?B?NWoxOHpmN1BxcDhTSFBOdkdXSHN1VzJaQnpWOEZaN0wwbnZsSi8wa09ab0Nk?= =?utf-8?B?ZlFPVkN5K3hlcW5vZHZDamxZclVYY0VxamtYSTlnWGZaMFF1bll4S3pDRm5J?= =?utf-8?B?T0QySEQvakxFd3pEV2JZYTY2d2QzOVNodzljVmVDdUtKa3A0c2RZcXh3dUNR?= =?utf-8?B?em5YYS9FMVRLTUpPVUE2YkpQenRBRWJtdUZ6Z3VZR0RvS0JRTnQ2ajZPRXp5?= =?utf-8?B?bVQwcWtBbm9FcC9Db3BsWlFPa3dFejl0aTcrVXFieVExRm9RVDJGanhvbC9P?= =?utf-8?B?cCtiVklFWFpaMUV4Yk5sSDBadzJUSEJkVXVLOGdZekVweTN3QVovekNWUDM5?= =?utf-8?B?dmZOZzh4bktFUVhkdEdnTDh5d2NoeFU5SXJlZVRocVlXVUl1T2Z5RWVUYW4r?= =?utf-8?B?VzRONDlaZW5SdFJHQzFnNUNvMlNOTFRscGV4R3BLSGhLNm1TNjlHZUorSE5J?= =?utf-8?B?bFk3YWc2bjVWZzFEc1E2TlVGbzcvK0R1YVVXVHp6M0pjblJ5dnh4RWcxZnFh?= =?utf-8?B?T1RuQ2JWMEt1dWhReHdDd1B4MnlVRXhVRlh3S2lFMFBKZGc9PQ==?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <2BE45D8F4C95B145A05D18692826A14F@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a9b4c2cf-cc00-419f-c654-08d946b83242 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2021 11:11:57.9126 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: H/NKaa36xPu7mBwZuHGbB0LkHwkwOoDdo86oo5UnEYhpC7JQ/a9yOkxYvf05ourTkKV8w8EK9ayy2vQefgr9cw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5111 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.19, xbe-rcd-004.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [sfc] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-sfc-n?= =?utf-8?q?sh-integrity-06=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2021 11:12:06 -0000 SGVsbG8gTWVkLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcHJvbXB0IHJlcGx5Lg0KDQpTZWUgYmVs b3cgZm9yIEVWPiwgc3RpbGwgaG9sZGluZyBteSBESVNDVVNTIG1haW5seSBhcm91bmQgdGhlICJo b3cgdG8gY29tcHV0ZSB0aGUgTUFDIGFzIGl0IGluY2x1ZGVzIHRoZSBNQUMgZmllbGQgaXRzZWxm Ig0KDQpSZWdhcmRzDQoNCi3DqXJpYw0KDQrvu78tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogIm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iIDxtb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tPg0KRGF0ZTogVHVlc2RheSwgMTMgSnVseSAyMDIxIGF0IDE4OjU0DQpUbzogRXJp YyBWeW5ja2UgPGV2eW5ja2VAY2lzY28uY29tPiwgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQpD YzogImRyYWZ0LWlldGYtc2ZjLW5zaC1pbnRlZ3JpdHlAaWV0Zi5vcmciIDxkcmFmdC1pZXRmLXNm Yy1uc2gtaW50ZWdyaXR5QGlldGYub3JnPiwgInNmYy1jaGFpcnNAaWV0Zi5vcmciIDxzZmMtY2hh aXJzQGlldGYub3JnPiwgInNmY0BpZXRmLm9yZyIgPHNmY0BpZXRmLm9yZz4sICJncmVnaW1pcnNr eUBnbWFpbC5jb20iIDxncmVnaW1pcnNreUBnbWFpbC5jb20+DQpTdWJqZWN0OiBSRTogw4lyaWMg VnluY2tlJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXNmYy1uc2gtaW50ZWdyaXR5LTA2OiAod2l0 aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KDQogICAgSGkgRXJpYywgDQoNCiAgICBUaGFuayB5b3Ug Zm9yIHRoZSByZXZpZXcuIA0KDQogICAgUGxlYXNlIHNlZSBpbmxpbmUuIA0KDQogICAgQ2hlZXJz LA0KICAgIE1lZA0KDQogICAgPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCiAgICA+IERl IDogw4lyaWMgVnluY2tlIHZpYSBEYXRhdHJhY2tlciBbbWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmdd DQogICAgPiBFbnZvecOpIDogbWFyZGkgMTMganVpbGxldCAyMDIxIDE0OjE4DQogICAgPiDDgCA6 IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KICAgID4gQ2MgOiBkcmFmdC1pZXRmLXNmYy1uc2gt aW50ZWdyaXR5QGlldGYub3JnOyBzZmMtY2hhaXJzQGlldGYub3JnOw0KICAgID4gc2ZjQGlldGYu b3JnOyBncmVnaW1pcnNreUBnbWFpbC5jb207IGdyZWdpbWlyc2t5QGdtYWlsLmNvbQ0KICAgID4g T2JqZXQgOiDDiXJpYyBWeW5ja2UncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtc2ZjLW5zaC1pbnRl Z3JpdHktMDY6DQogICAgPiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KICAgID4gDQogICAg PiDDiXJpYyBWeW5ja2UgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24g Zm9yDQogICAgPiBkcmFmdC1pZXRmLXNmYy1uc2gtaW50ZWdyaXR5LTA2OiBEaXNjdXNzDQogICAg PiANCiAgICA+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBp bnRhY3QgYW5kIHJlcGx5IHRvDQogICAgPiBhbGwgZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGlu IHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8NCiAgICA+IGN1dCB0aGlzIGludHJv ZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KICAgID4gDQogICAgPiANCiAgICA+IFBsZWFz ZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLQ0K ICAgID4gY3JpdGVyaWEuaHRtbA0KICAgID4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgRElT Q1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQogICAgPiANCiAgICA+IA0KICAgID4gVGhlIGRv Y3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBo ZXJlOg0KICAgID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1z ZmMtbnNoLWludGVncml0eS8NCiAgICA+IA0KICAgID4gDQogICAgPiANCiAgICA+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQogICAgPiAtLQ0KICAgID4gRElTQ1VTUzoNCiAgICA+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgPiAt LQ0KICAgID4gDQogICAgPiBUaGFuayB5b3UgZm9yIHRoZSB3b3JrIHB1dCBpbnRvIHRoaXMgZG9j dW1lbnQuDQogICAgPiANCiAgICA+IFNwZWNpYWwgdGhhbmtzIHRvIEdyZWcgTWlyc2t5IGZvciBo aXMgc2hlcGhlcmRpbmcgZXNwZWNpYWxseSBhYm91dA0KICAgID4gaGlzIHN1bW1hcnkgb2YgdGhl IFdHIGNvbnNlbnN1cy4NCiAgICA+IA0KICAgID4gUGxlYXNlIGZpbmQgYmVsb3cgc29tZSBibG9j a2luZyBESVNDVVNTIHBvaW50ICh3aGljaCBzaG91bGQgYmUgZWFzeQ0KICAgID4gdG8gZml4KSwg c29tZSBub24tYmxvY2tpbmcgQ09NTUVOVCBwb2ludHMgKGJ1dCByZXBsaWVzIHdvdWxkIGJlDQog ICAgPiBhcHByZWNpYXRlZCksIGFuZCBvbmUgbml0Lg0KICAgID4gDQogICAgPiBJIGhvcGUgdGhh dCB0aGlzIGhlbHBzIHRvIGltcHJvdmUgdGhlIGRvY3VtZW50LA0KICAgID4gDQogICAgPiBSZWdh cmRzLA0KICAgID4gDQogICAgPiAtw6lyaWMNCiAgICA+IA0KICAgID4gPT0gRElTQ1VTUyA9PQ0K ICAgID4gDQogICAgPiBJIGZhaWxlZCB0byBzcG90IHRoZSBvcmRlciBvZiB0aGUgb3BlcmF0aW9u cyBmb3IgdGhlIGludGVncml0eSBhbmQNCiAgICA+IGNvbmZpZGVudGlhbGl0eSBvcGVyYXRpb25z LCBlLmcuLCBJIGRpZCBub3QgZmluZCBvbiB3aGF0IHRoZSBITUFDIGlzDQogICAgPiBjb21wdXRl ZDoNCiAgICA+IGluIHRoZSB1bmVuY3J5cHRlZCBvciBlbmNyeXB0ZWQgZmllbGQgPw0KDQogICAg W01lZF0gSXNuJ3QgdGhpcyBjb3ZlcmVkIGJ5IHRoaXMgdGV4dDogDQoNCiAgICAgICBVc2luZyB0 aGUgc2VjcmV0IGtleSAoSykgYW5kIGF1dGhlbnRpY2F0ZWQgZW5jcnlwdGlvbiBhbGdvcml0aG0s IHRoZQ0KICAgICAgIE5TSCBpbXBvc2VyIGVuY3J5cHRzIHRoZSBDb250ZXh0IEhlYWRlcnMgKGFz IHNldCwgZm9yIGV4YW1wbGUsIGluDQogICAgICAgU2VjdGlvbiAzKSwgY29tcHV0ZXMgdGhlIG1l c3NhZ2UgaW50ZWdyaXR5IGZvciB0aGUgdGFyZ2V0IE5TSCBkYXRhLA0KICAgICAgIGFuZCBpbnNl cnRzIHRoZSByZXN1bHRpbmcgcGF5bG9hZCBpbiB0aGUgIk1BQyBhbmQgRW5jcnlwdGVkIE1ldGFk YXRhIg0KICAgICAgIENvbnRleHQgSGVhZGVyIChTZWN0aW9uIDUpLiAgVGhlIGVudGlyZSBDb250 ZXh0IEhlYWRlciBjYXJyeWluZyBhDQogICAgICAgcHJpdmFjeS1zZW5zaXRpdmUgbWV0YWRhdGEg aXMgZW5jcnlwdGVkICh0aGF0IGlzLCBpbmNsdWRpbmcgdGhlIE1EDQogICAgICAgQ2xhc3MsIFR5 cGUsIExlbmd0aCwgYW5kIGFzc29jaWF0ZWQgbWV0YWRhdGEgb2YgZWFjaCBDb250ZXh0IEhlYWRl cikuDQoNCkVWPiB0aGUgdGV4dCBjb3VsZCBiZSBtYWRlIGNsZWFyZXIgYnkgdXNpbmcgInRoZW4i IHJhdGhlciB0aGFuIHNpbXBsZSAiLCINCkVWPiBidXQgSSBTVFJPTkdMWSBzdWdnZXN0IHRvIG1v dmUgdGhpcyBleHBsYW5hdGlvbiBlYXJsaWVyIGF0IHRoZSB2ZXJ5IGJlZ2lubmluZyBvZiBzZWN0 aW9uIDcgKG9yIDcuMSkgYW5kIG5vdCBsaWtlIG5vdyBpbiBzZWN0aW9uIDcuMw0KRVY+IEJUVywg dGhpcyBpcyBpbmRlZWQgdGhlIGV4cGVjdGVkIG9yZGVyIHRvIGF2b2lkIERvUw0KDQogICAgPiAN CiAgICA+IC0tIFNlY3Rpb24gNS4xIC0tDQogICAgPiBXaGF0IGlzIHRoZSB1bml0IG9mICJrZXkg bGVuZ3RoIiwgSSBhc3N1bWUgYSBsZW5ndGggZXhwcmVzc2VkIGluDQogICAgPiBvY3RldHMgYnV0 IGl0IGlzIG5vdCBzcGVjaWZpZWQuDQoNCiAgICBbTWVkXSBZZXMuIEZpeGVkLiBUaGFuayB5b3Ug Zm9yIGNhdGNoaW5nIHRoaXMuIA0KDQpFVj4gX18NCg0KICAgID4gDQogICAgPiAtLSBTZWN0aW9u IDcuMiAtLQ0KICAgID4gV2hhdCBpcyB0aGUgIkEiIHVzZWQgaW4gdGhlIEhNQUMgY29tcHV0YXRp b24gPw0KDQogICAgW01lZF0gVGhpcyBpczogQWRkaXRpb25hbCBBdXRoZW50aWNhdGVkIERhdGEg KEEpIChtZW50aW9uZWQgaW4gNC4yKS4NCg0KRVY+IGZhaXIgZW5vdWdoLCBzdWdnZXN0IHRvIHdy aXRlIHRoYXQgdGhlIHRlcm1pbm9sb2d5IG9mIHNlY3Rpb24gNC4yIGlzIHVzZWQgdGhlcmUuDQog ICAgPiANCiAgICA+IFRoZSBmb3JtdWxhIHNwZWNpZmllcyBITUFDLVNIQS0yNTYtMTI4KCkgYnV0 IHdoYXQgaWYgYW5vdGhlciBITUFDIGlzDQogICAgPiB1c2VkID8NCg0KICAgIFtNZWRdIFBsZWFz ZSBub3RlIHRoYXQgdGhlIHRleHQgc2F5czogImNhbiBiZSBpbGx1c3RyYXRlZCBhcyBmb2xsb3dz OiIuIA0KDQogICAgVGhhdCBpcyBmb3IgaWxsdXN0cmF0aW9uIHB1cnBvc2VzLiANCg0KRVY+IGNv dWxkIGFsc28gYmUgbWFkZSBtb3JlIG9idmlvdXMgd2l0aCAiIFRoZSBNZXNzYWdlIEF1dGhlbnRp Y2F0aW9uIENvZGUgKFQpIGNvbXB1dGF0aW9uIHByb2Nlc3MgZm9yIGFkZGl0aW9uYWwgYXV0aGVu dGljYXRpb24gdGV4dCAoQSkgd2l0aCBITUFDLVNIQS0yNTYtMTI4KCkgY2FuIGJlIGlsbHVzdHJh dGVkIGFzIGZvbGxvd3M6Ig0KDQogICAgPiBTZWN0aW9uIDcuMyB1c2UgTUFDKCkgd2hpY2ggaXMg bW9yZSBmbGV4aWJsZS4NCiAgICA+IA0KICAgID4gQXMgdGhlIE1BQyBmaWVsZCBpcyBpbmNsdWRl ZCBpbiB0aGUgaW50ZWdyaXR5IHByb3RlY3RlZCBoZWFkZXIsDQogICAgPiBwbGVhc2Ugc3BlY2lm eSB0aGUgdmFsdWUgb2YgdGhpcyBmaWVsZCB3aGVuIGNvbXB1dGluZyB0aGUgSE1BQyAoSQ0KICAg ID4gYXNzdW1lIDAgYnV0IGxldCdzIGJlIGNsZWFyKQ0KDQpFVj4gc3RpbGwgd2FpdGluZyBmb3Ig YW4gYW5zd2VyIG9uIHRoaXMgaXNzdWUgKHNvIGtlZXBpbmcgbXkgRElTQ1VTUyBiYWxsb3QpDQoN CiAgICA+IA0KICAgID4gLS0gU2VjdGlvbiA3LjUgLS0NCiAgICA+IFdoYXQgaXMgdGhlIGV4cGVj dGVkIGJlaGF2aW9yIHdoZW4gYSBOU0ggZG9lcyBub3QgY29udGFpbiBhICJNQUMgYW5kDQogICAg PiBFbmNyeXB0ZWQgTWV0YWRhdGEiIENvbnRleHQgSGVhZGVyID8gwqcxIGhpbnRzIHRvIHBhY2tl dCBkcm9wID8NCiAgICA+IFNob3VsZCB0aGVyZSBiZSBhIGxvY2FsIHBvbGljeSBmb3IgdGhpcyBj YXNlID8NCg0KICAgIFtNZWRdIFRoaXMgaXMgY292ZXJlZCBoZXJlOiANCg0KICAgICAgIEl0IE1V U1QgbG9nIGFuIGVycm9yIGF0IGxlYXN0IG9uY2UgcGVyIHRoZQ0KICAgICAgIFNQSSBmb3Igd2hp Y2ggdGhlICJNQUMgYW5kIEVuY3J5cHRlZCBNZXRhZGF0YSIgQ29udGV4dCBIZWFkZXIgaXMNCiAg ICAgICBtaXNzaW5nLg0KDQpFVj4gaG9uZXN0bHksIG5vdCBjbGVhciBmcm9tIHRoZSB0ZXh0LiBQ bGVhc2UgY29uc2lkZXIgYWRkaW5nICJJbiB0aGlzIGNhc2UsIGl0IE1VU1QuLi4iDQoNCiAgICA+ IA0KICAgID4gDQogICAgPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgID4gLS0NCiAgICA+IENPTU1FTlQ6DQog ICAgPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KICAgID4gLS0NCiAgICA+IA0KICAgID4gDQogICAgPiBJIHNlY29u ZCBBbHZhcm8ncyBhbmQgTGFycycgcG9pbnQgYWJvdXQgZm9ybWFsbHkgdXBkYXRpbmcgUkZDIDgz MDAuDQogICAgPiANCiAgICA+IFF1aXRlIG9mdGVuIGluIHRoZSB0ZXh0ICJwcml2YWN5LXNlbnNp dGl2ZSBtZXRhZGF0YSIgaXMgdXNlZCBidXQNCiAgICA+IGVuY3J5cHRpb24gaXMgbm90IG9ubHkg cmVxdWlyZWQgZm9yIHByaXZhY3kgYnV0IGFsc28gdG8gcHJvdGVjdA0KICAgID4gb3BlcmF0aW9u YWwgZGF0YSBmcm9tIGF0dGFja2VycyAoaS5lLiwgbm90IGxpbmtlZCB0byBwcml2YWN5KSwgaXMN CiAgICA+IHRoZXJlIGEgcmVhbCBuZWVkIHRvIHF1YWxpZnkgIm1ldGFkYXRhIiB3aXRoICJwcml2 YWN5LXNlbnNpdGl2ZSIsDQogICAgPiBpLmUuLCAiY29uZmlkZW50aWFsIG1ldGFkYXRhIiBtYXkg YmUgbW9yZSBhcHByb3ByaWF0ZSA/DQoNCiAgICBbTWVkXSBXZSB1c2UgdGhpcyB0ZXJtIGJlY2F1 c2Ugd2UgY2FuIGVhc2lseSBhcmd1ZSB3aHkgd2UgaW5jbHVkZWQgc3RhdGVtZW50IHN1Y2ggYXM6 DQoNCiAgICAgIiBJbiBhbiBTRkMtZW5hYmxlZCBkb21haW4gd2hlcmUgdGhlIGFib3ZlIGF0dGFj a3MgYXJlIHBvc3NpYmxlLCAoMSkNCiAgICAgICBOU0ggZGF0YSBNVVNUIGJlIGludGVncml0eS1w cm90ZWN0ZWQgYW5kIHJlcGxheS1wcm90ZWN0ZWQsIGFuZCAoMikNCiAgICAgICBwcml2YWN5LXNl bnNpdGl2ZSBOU0ggbWV0YWRhdGEgTVVTVCBiZSBlbmNyeXB0ZWQgZm9yIGNvbmZpZGVudGlhbGl0 eQ0KICAgICAgIHByZXNlcnZhdGlvbiBwdXJwb3Nlcy4iDQoNCiAgICBPdGhlciB0eXBlcyBjYW4g YmUgZW5jcnlwdGVkIGFzIHBlcjogDQoNCiAgICAgICBDbGFzc2lmaWVyKHMpLCBOU0gtYXdhcmUg U0ZzLCBhbmQgU0ZDIHByb3hpZXMgYXJlIGluc3RydWN0ZWQgd2l0aCB0aGUNCiAgICAgICBzZXQg b2YgQ29udGV4dCBIZWFkZXJzIChwcml2YWN5LXNlbnNpdGl2ZSBtZXRhZGF0YSwgdHlwaWNhbGx5 KSB0aGF0DQogICAgICAgbXVzdCBiZSBlbmNyeXB0ZWQuDQoNCkVWPiBsZXQncyBzYXkgdGhhdCB3 ZSBkaXNhZ3JlZSBfXyBidXQgdGhpcyBpcyBub24tYmxvY2tpbmcgYW55d2F5DQoNCiAgICA+IA0K ICAgID4gLS0gU2VjdGlvbiA0LjEuMSAtLQ0KICAgID4gVGhlIHVzZSBvZiAnbWV0YWRhdGEnIChu b3RhYmx5IGluIHRhYmxlIDEpIGZvciAnY29udGV4dCBoZWFkZXJzJyBpcw0KICAgID4gY29uZnVz aW5nIGZvciBhIGZpcnN0LXRpbWUgcmVhZGVyLiBBbnkgY2hhbmNlIHRvIGJlIGNvbnNpc3RlbnQg YW5kDQogICAgPiBvbmx5IHVzZSAnY29udGV4dCBoZWFkZXJzJyA/DQoNCiAgICBbTWVkXSBXaWxs IHNlZSBob3cgdG8gbWFrZSB0aGlzIGJldHRlciwgYnV0IHBsZWFzZSB0aGF0IHdlIGRvIGhhdmUg dGhlIGZvbGxvd2luZyBiZWZvcmUgdGFibGUgMTogDQoNCiAgICAiQ29udGV4dCBIZWFkZXIocyk6 IENhcnJpZXMgbWV0YWRhdGEuLi4iDQoNCiAgICA+IA0KICAgID4gLS0gU2VjdGlvbiA0LjIgLS0N CiAgICA+IEF0IGZpcnN0IHJlYWRpbmcsIEkgYW0gY29uZnVzZWQgYnkgdGhlIHVzZSBvZiB0aGUg d29yZCAnc2VjcmV0IGtleScNCiAgICA+IGZvciB3aGF0IGFwcGVhcnMgdG8gYmUgYSAnc2hhcmVk IGtleScuIE9yIGlzIHRoaXMgJ3NlY3JldCBrZXknIG5ldmVyDQogICAgPiBzaGFyZWQgYW5kIHNp bXBseSB1c2VkIHRvIGdlbmVyYXRlIHRoZSBzZWNvbmRhcnkga2V5cywgd2hpY2ggYXJlDQogICAg PiB0aGVuIHNoYXJlZCA/IEV2ZW4gaWYgZGlzY3Vzc2VkIGxhdGVyLCBzb21lIGVhcmx5IGV4cGxh bmF0aW9ucyB3b3VsZA0KICAgID4gYmUgd2VsY29tZS4NCg0KICAgIFtNZWRdIFdlIGFyZSB1c2lu ZyBzaW1pbGFyIHdvcmRpbmcgYXMgaW4gUkZDNzUxOC4NCg0KRVY+IEkgZmFpbCB0byBzZWUgdGhp cyB3b3JkaW5nIGluIFJGQyA3NTE4DQoNCiAgICA+IA0KICAgID4gLS0gU2VjdGlvbiA1LjEgLS0N CiAgICA+IElzIHRoZXJlIGEgZ29vZCByZWFzb24gd2h5IHRoZSBmaWVsZCBuYW1lICJrZXkgbGVu Z3RoIiBpcyBub3QgImtleQ0KICAgID4gSUQgbGVuZ3RoIiA/DQoNCiAgICBbTWVkXSBPbmx5IGZv ciBlc3RoZXRpYyBtYXR0ZXJzIG9mIHRoZSBmaWd1cmVzLiBDYW4gZml4IHRoYXQgaWYgeW91IHBy ZWZlci4gDQoNCiAgICB8S2V5IElEIExlbmd0aHwgdnMgfCBLZXkgTGVuZ3RoIHwNCg0KRVY+IHRo aXMgd291bGQgYmUgY2xlYXJlciBJTUhPIGJ1dCBlZGl0b3JpYWwgaGVuY2Ugbm9uLWJsb2NraW5n DQoNCiAgICA+IA0KICAgID4gSSBhbHNvIGZpbmQgdmVyeSBzdHJhbmdlIHRvIGRlZmluZSAiTGVu Z3RoOiB2YXJpYWJsZSIgYXMgdGhlIGhlYWRlcg0KICAgID4gZmllbGQgaXRzZWxmIGFzIGEgZml4 ZWQgbGVuZ3RoLCBzaW1wbHkgc3RhdGUgInVuc2lnbmVkIGludGVnZXIiLg0KDQogICAgW01lZF0g V2UgYXJlIGVjaG9pbmcgU2VjdGlvbiAyLjUuMSBvZiBSRkM4MzAwLg0KDQpFVj4gbGlrZSBhYm92 ZSwgSSBmYWlsIHRvIHNlZSB0aGlzIHNpbWlsYXJpdHkgaW4gdGhlIHNlY3Rpb24gMi41LjEgb2Yg UkZDIDgzMDAgIkluZGljYXRlcyB0aGUgbGVuZ3RoIG9mIHRoZSB2YXJpYWJsZS1sZW5ndGggbWV0 YWRhdGEsIGluIGJ5dGVzLiINCiAgICA+IA0KICAgID4gQXMgdGltZXN0YW1wIGNhbiBpbmNsdWRl IGZyYWN0aW9ucyBvZiBzZWNvbmQsIHdoaWNoIGlzIGEgZ29vZCB0aGluZywNCiAgICA+IHRoZW4g cGxlYXNlIHJld29yZCAiZXhwcmVzc2VkIGluIHNlY29uZHMgcmVsYXRpdmUiIHRvIGluZGljYXRl IHRoYXQNCiAgICA+IGZyYWN0aW9uIG9mIHNlY29uZCBpcyBpbmNsdWRlZC4NCg0KICAgIFtNZWRd IE9LLg0KDQogICAgPiANCiAgICA+IFRoZSAzMi1iaXQgZXBvY2ggd2lsbCB3cmFwIGFyb3VuZCBp biAyMDM2LCBzaG91bGQgdGhpcyBJLUQgYWxyZWFkeQ0KICAgID4gY29uc2lkZXIgd2hhdCB0byBk byBhdCB0aGF0IG1vbWVudCA/DQoNCiAgICBbTWVkXSBIbW0uIFdlIHNheSB0aGF0IGl0IHdyYXBz IGluIDIxMDYgOi0pDQoNCkVWPiBJIHNob3VsZCBoYXZlIHNwb3QgdGhlIGRpZmZlcmVudCBlcG9j aCA7LSkNCg0KICAgID4gDQogICAgPiAtLSBTZWN0aW9uIDggLS0NCiAgICA+IEluZGVlZCBNVFUg aXMgYWx3YXlzIGFuIGludGVyZXN0aW5nICdwcm9ibGVtJyBidXQgaG93IGlzIHRoaXMNCiAgICA+ IGV4dGVuc2lvbiBkaWZmZXJlbnQgdGhhbiBwbGFpbiBOU0ggPyBUaGUgTlNIIG5laXRoZXIgaW5j cmVhc2VzIG5vcg0KICAgID4gZGVjcmVhc2VzIG9uIHRoZSBmbHkgd2l0aCB0aGlzIGRvY3VtZW50 Lg0KDQogICAgW01lZF0gSXQgdmFyaWVzIGFzIHdlIGNhbiBhZGQvc3RyaXAgY29udGV4dCBoZWFk ZXJzIGFzIHRoZSBwYWNrZXQgcHJvZ3Jlc3MgaW4gdGhlIHNlcnZpY2UgY2hhaW4uIA0KDQpFVj4g QW1hemluZyB0aGF0IHRoaXMgd2FzIGFjY2VwdGVkIGJ5IHRoZSBJRVNHIGluIFJGQyA4MzAwIHll YXJzIGFnby4uLiB3aGVuIG5ldC1wZ20gUkZDIGhhZCB0byByZW1vdmUgdGhlIGhlYWRlciBpbnNl cnRpb24uDQoNCiAgICA+IA0KICAgID4gPT0gTklUUyA9PQ0KICAgID4gDQogICAgPiAtLSBTZWN0 aW9uIDMgLS0NCiAgICA+IFNob3VsZCAnZmlndXJlIDEnIGJlICd0YWJsZSAxJyBwZXIgY29uc2lz dGVuY3kgd2l0aCBzZWN0aW9uIDQuMS4xID8NCg0KICAgIFtNZWRdIEl0IHNob3VsZC4gV2lsbCBi ZSBmaXhlZC4gVGhhbmtzLiANCg0KICAgID4gDQogICAgPiANCg0KDQogICAgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQog ICAgQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMg aW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVu dCBkb25jDQogICAgcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBh dXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1 aWxsZXogbGUgc2lnbmFsZXINCiAgICBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5z aSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFu dCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KICAgIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJl c3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNp ZmllLiBNZXJjaS4NCg0KICAgIFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBj b250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJl IHByb3RlY3RlZCBieSBsYXc7DQogICAgdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1 c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQogICAgSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBk ZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQogICAgQXMgZW1haWxzIG1h eSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZl IGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KICAgIFRoYW5rIHlvdS4NCg0K DQo= From nobody Wed Jul 14 04:58:46 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAE003A0855; Wed, 14 Jul 2021 04:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpeuYTxyAFBR; Wed, 14 Jul 2021 04:58:37 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 9FF8A3A0853; Wed, 14 Jul 2021 04:58:36 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id u13so3108524lfs.11; Wed, 14 Jul 2021 04:58:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7Hiq2t/VNs0ZFaxhm3TiOLb6h8uKtEBKYGz3aa4naLc=; b=cZPEXCTAjJR3MPsCtOBdnC/cjeqOYsxvTkwmhizlCCK6tCTlXP1q6DjJ3aYPPiYvre 6Yp4EhEvkfRZIyYgSmmzDT1yI1AIEfApeL0LYMGxJbKHnKiVEGKrfxVxrTyybjH7pIcT xZvESPZFfgfzeSxoWPtndbU+2z4ATfw5Dcb3ggNjn4oGWcxTs1kLrBeE9giU1sUmgtDV F4qWrVikktO0jVyXzH+VHFrAqHf9y4fkQ8Bq57yZX/RBQeHbvL22CJngqjb4iyD+bo30 FgRf0jIcfD0XN5eQDPWPdSxRt2uLQcVtC01XkQ6KS2zCmoYkwBak97tbe/KXYfnXf+VO +rIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7Hiq2t/VNs0ZFaxhm3TiOLb6h8uKtEBKYGz3aa4naLc=; b=GvNu7OSj4nH+DIHyEmnEQnn1sXe0e9VTvy+u2I2ovOYt5kLWGOJT075QB4GRO8qgzt lisbhHV8v/6ogQwnRGtvddu7/uoRsmcXE1BCVeJYE8+H7JJnsuNm/ywwh0cplROSP0hK Xzc48Gkbc/96C5Ppqj3bFnoHvfC1ba+F1q00HNgtZ4+9Vu6VfWkohwd+Bp0Ni4JHMN7Z I5l+5BuyESX0k14xR5aZM6nTcU77x6262sdQihEjeVMuX4/ipppq28y4EyqxfhY8mJ17 EKhlOGpJWqD8KmvICOrjhbMf99+8bJaaVM16x39xV9L7kThZzYiWFo9CViBC6C9EBZ64 x0bQ== X-Gm-Message-State: AOAM532CWraXWAqwaztgwAFNFER2E8A+ycU+D/d59uxpDGaUqmUrgAqO 4xt5Kb8oXP8WXbgw1AoemsvGtWCMjxx3wqckOOc= X-Google-Smtp-Source: ABdhPJyCWL3QJgEGPIZi5RFNnbM923c+irzgVZTxzbkpxCplkDyY9vvKbHENz0OnE2BuUgR/xCIUpIMtDMTBBZTCV6w= X-Received: by 2002:ac2:4564:: with SMTP id k4mr7771220lfm.129.1626263912715; Wed, 14 Jul 2021 04:58:32 -0700 (PDT) MIME-Version: 1.0 References: <162617866082.13596.2398814614966286542@ietfa.amsl.com> <15473_1626195281_60EDC551_15473_51_1_787AE7BB302AE849A7480A190F8B9330353BE8EC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <94FF1F19-7004-42C5-8560-C99A2FEEF71A@cisco.com> In-Reply-To: <94FF1F19-7004-42C5-8560-C99A2FEEF71A@cisco.com> From: tirumal reddy Date: Wed, 14 Jul 2021 17:28:21 +0530 Message-ID: To: "Eric Vyncke (evyncke)" Cc: "mohamed.boucadair@orange.com" , The IESG , "draft-ietf-sfc-nsh-integrity@ietf.org" , "sfc-chairs@ietf.org" , "sfc@ietf.org" , "gregimirsky@gmail.com" Content-Type: multipart/alternative; boundary="000000000000d4199f05c71412b8" Archived-At: Subject: Re: [sfc] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-sfc-n?= =?utf-8?q?sh-integrity-06=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2021 11:58:44 -0000 --000000000000d4199f05c71412b8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Eric, We will update text in Section 7.2 as follows to address the comment : The NSH imposer sets the MAC field to zero and then computes the message integrity for the target NSH data (depending on the integrity protection scope discussed in Section 5) using MAC_KEY and HMAC algorithm. It then inserts the computed digest in the MAC field in the "MAC and Encrypted Metadata" Context Header. Cheers, -Tiru On Wed, 14 Jul 2021 at 16:42, Eric Vyncke (evyncke) wrote: > Hello Med, > > Thank you for your prompt reply. > > See below for EV>, still holding my DISCUSS mainly around the "how to > compute the MAC as it includes the MAC field itself" > > Regards > > -=C3=A9ric > > =EF=BB=BF-----Original Message----- > From: "mohamed.boucadair@orange.com" > Date: Tuesday, 13 July 2021 at 18:54 > To: Eric Vyncke , The IESG > Cc: "draft-ietf-sfc-nsh-integrity@ietf.org" < > draft-ietf-sfc-nsh-integrity@ietf.org>, "sfc-chairs@ietf.org" < > sfc-chairs@ietf.org>, "sfc@ietf.org" , " > gregimirsky@gmail.com" > Subject: RE: =C3=89ric Vyncke's Discuss on draft-ietf-sfc-nsh-integrity-0= 6: > (with DISCUSS and COMMENT) > > Hi Eric, > > Thank you for the review. > > Please see inline. > > Cheers, > Med > > > -----Message d'origine----- > > De : =C3=89ric Vyncke via Datatracker [mailto:noreply@ietf.org] > > Envoy=C3=A9 : mardi 13 juillet 2021 14:18 > > =C3=80 : The IESG > > Cc : draft-ietf-sfc-nsh-integrity@ietf.org; sfc-chairs@ietf.org; > > sfc@ietf.org; gregimirsky@gmail.com; gregimirsky@gmail.com > > Objet : =C3=89ric Vyncke's Discuss on draft-ietf-sfc-nsh-integrity-= 06: > > (with DISCUSS and COMMENT) > > > > =C3=89ric Vyncke has entered the following ballot position for > > draft-ietf-sfc-nsh-integrity-06: Discuss > > > > When responding, please keep the subject line intact and reply to > > all email addresses included in the To and CC lines. (Feel free to > > cut this introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss- > > criteria.html > > for more information about DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/ > > > > > > > > -------------------------------------------------------------------= - > > -- > > DISCUSS: > > -------------------------------------------------------------------= - > > -- > > > > Thank you for the work put into this document. > > > > Special thanks to Greg Mirsky for his shepherding especially about > > his summary of the WG consensus. > > > > Please find below some blocking DISCUSS point (which should be easy > > to fix), some non-blocking COMMENT points (but replies would be > > appreciated), and one nit. > > > > I hope that this helps to improve the document, > > > > Regards, > > > > -=C3=A9ric > > > > =3D=3D DISCUSS =3D=3D > > > > I failed to spot the order of the operations for the integrity and > > confidentiality operations, e.g., I did not find on what the HMAC i= s > > computed: > > in the unencrypted or encrypted field ? > > [Med] Isn't this covered by this text: > > Using the secret key (K) and authenticated encryption algorithm, t= he > NSH imposer encrypts the Context Headers (as set, for example, in > Section 3), computes the message integrity for the target NSH data= , > and inserts the resulting payload in the "MAC and Encrypted > Metadata" > Context Header (Section 5). The entire Context Header carrying a > privacy-sensitive metadata is encrypted (that is, including the MD > Class, Type, Length, and associated metadata of each Context > Header). > > EV> the text could be made clearer by using "then" rather than simple "," > EV> but I STRONGLY suggest to move this explanation earlier at the very > beginning of section 7 (or 7.1) and not like now in section 7.3 > EV> BTW, this is indeed the expected order to avoid DoS > > > > > -- Section 5.1 -- > > What is the unit of "key length", I assume a length expressed in > > octets but it is not specified. > > [Med] Yes. Fixed. Thank you for catching this. > > EV> __ > > > > > -- Section 7.2 -- > > What is the "A" used in the HMAC computation ? > > [Med] This is: Additional Authenticated Data (A) (mentioned in 4.2). > > EV> fair enough, suggest to write that the terminology of section 4.2 is > used there. > > > > The formula specifies HMAC-SHA-256-128() but what if another HMAC i= s > > used ? > > [Med] Please note that the text says: "can be illustrated as > follows:". > > That is for illustration purposes. > > EV> could also be made more obvious with " The Message Authentication Cod= e > (T) computation process for additional authentication text (A) with > HMAC-SHA-256-128() can be illustrated as follows:" > > > Section 7.3 use MAC() which is more flexible. > > > > As the MAC field is included in the integrity protected header, > > please specify the value of this field when computing the HMAC (I > > assume 0 but let's be clear) > > EV> still waiting for an answer on this issue (so keeping my DISCUSS > ballot) > > > > > -- Section 7.5 -- > > What is the expected behavior when a NSH does not contain a "MAC an= d > > Encrypted Metadata" Context Header ? =C2=A71 hints to packet drop ? > > Should there be a local policy for this case ? > > [Med] This is covered here: > > It MUST log an error at least once per the > SPI for which the "MAC and Encrypted Metadata" Context Header is > missing. > > EV> honestly, not clear from the text. Please consider adding "In this > case, it MUST..." > > > > > > > -------------------------------------------------------------------= - > > -- > > COMMENT: > > -------------------------------------------------------------------= - > > -- > > > > > > I second Alvaro's and Lars' point about formally updating RFC 8300. > > > > Quite often in the text "privacy-sensitive metadata" is used but > > encryption is not only required for privacy but also to protect > > operational data from attackers (i.e., not linked to privacy), is > > there a real need to qualify "metadata" with "privacy-sensitive", > > i.e., "confidential metadata" may be more appropriate ? > > [Med] We use this term because we can easily argue why we included > statement such as: > > " In an SFC-enabled domain where the above attacks are possible, (1) > NSH data MUST be integrity-protected and replay-protected, and (2) > privacy-sensitive NSH metadata MUST be encrypted for confidentiali= ty > preservation purposes." > > Other types can be encrypted as per: > > Classifier(s), NSH-aware SFs, and SFC proxies are instructed with > the > set of Context Headers (privacy-sensitive metadata, typically) tha= t > must be encrypted. > > EV> let's say that we disagree __ but this is non-blocking anyway > > > > > -- Section 4.1.1 -- > > The use of 'metadata' (notably in table 1) for 'context headers' is > > confusing for a first-time reader. Any chance to be consistent and > > only use 'context headers' ? > > [Med] Will see how to make this better, but please that we do have th= e > following before table 1: > > "Context Header(s): Carries metadata..." > > > > > -- Section 4.2 -- > > At first reading, I am confused by the use of the word 'secret key' > > for what appears to be a 'shared key'. Or is this 'secret key' neve= r > > shared and simply used to generate the secondary keys, which are > > then shared ? Even if discussed later, some early explanations woul= d > > be welcome. > > [Med] We are using similar wording as in RFC7518. > > EV> I fail to see this wording in RFC 7518 > > > > > -- Section 5.1 -- > > Is there a good reason why the field name "key length" is not "key > > ID length" ? > > [Med] Only for esthetic matters of the figures. Can fix that if you > prefer. > > |Key ID Length| vs | Key Length | > > EV> this would be clearer IMHO but editorial hence non-blocking > > > > > I also find very strange to define "Length: variable" as the header > > field itself as a fixed length, simply state "unsigned integer". > > [Med] We are echoing Section 2.5.1 of RFC8300. > > EV> like above, I fail to see this similarity in the section 2.5.1 of RFC > 8300 "Indicates the length of the variable-length metadata, in bytes." > > > > As timestamp can include fractions of second, which is a good thing= , > > then please reword "expressed in seconds relative" to indicate that > > fraction of second is included. > > [Med] OK. > > > > > The 32-bit epoch will wrap around in 2036, should this I-D already > > consider what to do at that moment ? > > [Med] Hmm. We say that it wraps in 2106 :-) > > EV> I should have spot the different epoch ;-) > > > > > -- Section 8 -- > > Indeed MTU is always an interesting 'problem' but how is this > > extension different than plain NSH ? The NSH neither increases nor > > decreases on the fly with this document. > > [Med] It varies as we can add/strip context headers as the packet > progress in the service chain. > > EV> Amazing that this was accepted by the IESG in RFC 8300 years ago... > when net-pgm RFC had to remove the header insertion. > > > > > =3D=3D NITS =3D=3D > > > > -- Section 3 -- > > Should 'figure 1' be 'table 1' per consistency with section 4.1.1 ? > > [Med] It should. Will be fixed. Thanks. > > > > > > > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous ave= z > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, > deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender an= d > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > Thank you. > > > --000000000000d4199f05c71412b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Eric,

We= will update text in Section 7.2 as follows to address the comment :=C2=A0<= /div>

<= /div>
The NSH impo= ser sets the MAC field to zero and then computes the message integrity for = the target NSH data (depending on the integrity protection scope discussed = in=C2=A0Section= 5) using MAC_KEY and HMAC algorithm.=C2=A0It then inserts the computed digest in the MAC = field in=C2=A0t= he "MAC and Encrypted Metadata" Context Header.=C2=A0
<= /div>

<= /div>
Cheers,
-Tiru

On Wed, 14 Jul 2021 at 16:42, Eric Vyncke (evyncke) <evyncke@cisco.com> wrote:
Hello Med,

Thank you for your prompt reply.

See below for EV>, still holding my DISCUSS mainly around the "how = to compute the MAC as it includes the MAC field itself"

Regards

-=C3=A9ric

=EF=BB=BF-----Original Message-----
From: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com> Date: Tuesday, 13 July 2021 at 18:54
To: Eric Vyncke <= evyncke@cisco.com>, The IESG <iesg@ietf.org>
Cc: "draft-ietf-sfc-nsh-integrity@ietf.org" <draft-ietf-= sfc-nsh-integrity@ietf.org>, "sfc-chairs@ietf.org" <sfc-chairs@ietf.org>, "= sfc@ietf.org" &l= t;sfc@ietf.org>, &= quot;gregimirsky= @gmail.com" <gregimirsky@gmail.com>
Subject: RE: =C3=89ric Vyncke's Discuss on draft-ietf-sfc-nsh-integrity= -06: (with DISCUSS and COMMENT)

=C2=A0 =C2=A0 Hi Eric,

=C2=A0 =C2=A0 Thank you for the review.

=C2=A0 =C2=A0 Please see inline.

=C2=A0 =C2=A0 Cheers,
=C2=A0 =C2=A0 Med

=C2=A0 =C2=A0 > -----Message d'origine-----
=C2=A0 =C2=A0 > De : =C3=89ric Vyncke via Datatracker [mailto:noreply@ietf.org]
=C2=A0 =C2=A0 > Envoy=C3=A9 : mardi 13 juillet 2021 14:18
=C2=A0 =C2=A0 > =C3=80 : The IESG <iesg@ietf.org>
=C2=A0 =C2=A0 > Cc : draft-ietf-sfc-nsh-integrity@ietf.org; sfc-chairs@ietf.org;<= br> =C2=A0 =C2=A0 > sfc@ie= tf.org; greg= imirsky@gmail.com; gregimirsky@gmail.com
=C2=A0 =C2=A0 > Objet : =C3=89ric Vyncke's Discuss on draft-ietf-sfc= -nsh-integrity-06:
=C2=A0 =C2=A0 > (with DISCUSS and COMMENT)
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > =C3=89ric Vyncke has entered the following ballot positi= on for
=C2=A0 =C2=A0 > draft-ietf-sfc-nsh-integrity-06: Discuss
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > When responding, please keep the subject line intact and= reply to
=C2=A0 =C2=A0 > all email addresses included in the To and CC lines. (Fe= el free to
=C2=A0 =C2=A0 > cut this introductory paragraph, however.)
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Please refer to https://www.ietf.org/= iesg/statement/discuss-
=C2=A0 =C2=A0 > criteria.html
=C2=A0 =C2=A0 > for more information about DISCUSS and COMMENT positions= .
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > The document, along with other ballot positions, can be = found here:
=C2=A0 =C2=A0 > https://datatracker= .ietf.org/doc/draft-ietf-sfc-nsh-integrity/
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > --------------------------------------------------------= ------------
=C2=A0 =C2=A0 > --
=C2=A0 =C2=A0 > DISCUSS:
=C2=A0 =C2=A0 > --------------------------------------------------------= ------------
=C2=A0 =C2=A0 > --
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Thank you for the work put into this document.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Special thanks to Greg Mirsky for his shepherding especi= ally about
=C2=A0 =C2=A0 > his summary of the WG consensus.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Please find below some blocking DISCUSS point (which sho= uld be easy
=C2=A0 =C2=A0 > to fix), some non-blocking COMMENT points (but replies w= ould be
=C2=A0 =C2=A0 > appreciated), and one nit.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > I hope that this helps to improve the document,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Regards,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > -=C3=A9ric
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > =3D=3D DISCUSS =3D=3D
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > I failed to spot the order of the operations for the int= egrity and
=C2=A0 =C2=A0 > confidentiality operations, e.g., I did not find on what= the HMAC is
=C2=A0 =C2=A0 > computed:
=C2=A0 =C2=A0 > in the unencrypted or encrypted field ?

=C2=A0 =C2=A0 [Med] Isn't this covered by this text:

=C2=A0 =C2=A0 =C2=A0 =C2=A0Using the secret key (K) and authenticated encry= ption algorithm, the
=C2=A0 =C2=A0 =C2=A0 =C2=A0NSH imposer encrypts the Context Headers (as set= , for example, in
=C2=A0 =C2=A0 =C2=A0 =C2=A0Section 3), computes the message integrity for t= he target NSH data,
=C2=A0 =C2=A0 =C2=A0 =C2=A0and inserts the resulting payload in the "M= AC and Encrypted Metadata"
=C2=A0 =C2=A0 =C2=A0 =C2=A0Context Header (Section 5).=C2=A0 The entire Con= text Header carrying a
=C2=A0 =C2=A0 =C2=A0 =C2=A0privacy-sensitive metadata is encrypted (that is= , including the MD
=C2=A0 =C2=A0 =C2=A0 =C2=A0Class, Type, Length, and associated metadata of = each Context Header).

EV> the text could be made clearer by using "then" rather than= simple ","
EV> but I STRONGLY suggest to move this explanation earlier at the very = beginning of section 7 (or 7.1) and not like now in section 7.3
EV> BTW, this is indeed the expected order to avoid DoS

=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > -- Section 5.1 --
=C2=A0 =C2=A0 > What is the unit of "key length", I assume a l= ength expressed in
=C2=A0 =C2=A0 > octets but it is not specified.

=C2=A0 =C2=A0 [Med] Yes. Fixed. Thank you for catching this.

EV> __

=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > -- Section 7.2 --
=C2=A0 =C2=A0 > What is the "A" used in the HMAC computation ?=

=C2=A0 =C2=A0 [Med] This is: Additional Authenticated Data (A) (mentioned i= n 4.2).

EV> fair enough, suggest to write that the terminology of section 4.2 is= used there.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > The formula specifies HMAC-SHA-256-128() but what if ano= ther HMAC is
=C2=A0 =C2=A0 > used ?

=C2=A0 =C2=A0 [Med] Please note that the text says: "can be illustrate= d as follows:".

=C2=A0 =C2=A0 That is for illustration purposes.

EV> could also be made more obvious with " The Message Authenticati= on Code (T) computation process for additional authentication text (A) with= HMAC-SHA-256-128() can be illustrated as follows:"

=C2=A0 =C2=A0 > Section 7.3 use MAC() which is more flexible.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > As the MAC field is included in the integrity protected = header,
=C2=A0 =C2=A0 > please specify the value of this field when computing th= e HMAC (I
=C2=A0 =C2=A0 > assume 0 but let's be clear)

EV> still waiting for an answer on this issue (so keeping my DISCUSS bal= lot)

=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > -- Section 7.5 --
=C2=A0 =C2=A0 > What is the expected behavior when a NSH does not contai= n a "MAC and
=C2=A0 =C2=A0 > Encrypted Metadata" Context Header ? =C2=A71 hints = to packet drop ?
=C2=A0 =C2=A0 > Should there be a local policy for this case ?

=C2=A0 =C2=A0 [Med] This is covered here:

=C2=A0 =C2=A0 =C2=A0 =C2=A0It MUST log an error at least once per the
=C2=A0 =C2=A0 =C2=A0 =C2=A0SPI for which the "MAC and Encrypted Metada= ta" Context Header is
=C2=A0 =C2=A0 =C2=A0 =C2=A0missing.

EV> honestly, not clear from the text. Please consider adding "In t= his case, it MUST..."

=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > --------------------------------------------------------= ------------
=C2=A0 =C2=A0 > --
=C2=A0 =C2=A0 > COMMENT:
=C2=A0 =C2=A0 > --------------------------------------------------------= ------------
=C2=A0 =C2=A0 > --
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > I second Alvaro's and Lars' point about formally= updating RFC 8300.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Quite often in the text "privacy-sensitive metadata= " is used but
=C2=A0 =C2=A0 > encryption is not only required for privacy but also to = protect
=C2=A0 =C2=A0 > operational data from attackers (i.e., not linked to pri= vacy), is
=C2=A0 =C2=A0 > there a real need to qualify "metadata" with &= quot;privacy-sensitive",
=C2=A0 =C2=A0 > i.e., "confidential metadata" may be more appr= opriate ?

=C2=A0 =C2=A0 [Med] We use this term because we can easily argue why we inc= luded statement such as:

=C2=A0 =C2=A0 =C2=A0" In an SFC-enabled domain where the above attacks= are possible, (1)
=C2=A0 =C2=A0 =C2=A0 =C2=A0NSH data MUST be integrity-protected and replay-= protected, and (2)
=C2=A0 =C2=A0 =C2=A0 =C2=A0privacy-sensitive NSH metadata MUST be encrypted= for confidentiality
=C2=A0 =C2=A0 =C2=A0 =C2=A0preservation purposes."

=C2=A0 =C2=A0 Other types can be encrypted as per:

=C2=A0 =C2=A0 =C2=A0 =C2=A0Classifier(s), NSH-aware SFs, and SFC proxies ar= e instructed with the
=C2=A0 =C2=A0 =C2=A0 =C2=A0set of Context Headers (privacy-sensitive metada= ta, typically) that
=C2=A0 =C2=A0 =C2=A0 =C2=A0must be encrypted.

EV> let's say that we disagree __ but this is non-blocking anyway
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > -- Section 4.1.1 --
=C2=A0 =C2=A0 > The use of 'metadata' (notably in table 1) for &= #39;context headers' is
=C2=A0 =C2=A0 > confusing for a first-time reader. Any chance to be cons= istent and
=C2=A0 =C2=A0 > only use 'context headers' ?

=C2=A0 =C2=A0 [Med] Will see how to make this better, but please that we do= have the following before table 1:

=C2=A0 =C2=A0 "Context Header(s): Carries metadata..."

=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > -- Section 4.2 --
=C2=A0 =C2=A0 > At first reading, I am confused by the use of the word &= #39;secret key'
=C2=A0 =C2=A0 > for what appears to be a 'shared key'. Or is thi= s 'secret key' never
=C2=A0 =C2=A0 > shared and simply used to generate the secondary keys, w= hich are
=C2=A0 =C2=A0 > then shared ? Even if discussed later, some early explan= ations would
=C2=A0 =C2=A0 > be welcome.

=C2=A0 =C2=A0 [Med] We are using similar wording as in RFC7518.

EV> I fail to see this wording in RFC 7518

=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > -- Section 5.1 --
=C2=A0 =C2=A0 > Is there a good reason why the field name "key leng= th" is not "key
=C2=A0 =C2=A0 > ID length" ?

=C2=A0 =C2=A0 [Med] Only for esthetic matters of the figures. Can fix that = if you prefer.

=C2=A0 =C2=A0 |Key ID Length| vs | Key Length |

EV> this would be clearer IMHO but editorial hence non-blocking

=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > I also find very strange to define "Length: variabl= e" as the header
=C2=A0 =C2=A0 > field itself as a fixed length, simply state "unsig= ned integer".

=C2=A0 =C2=A0 [Med] We are echoing Section 2.5.1 of RFC8300.

EV> like above, I fail to see this similarity in the section 2.5.1 of RF= C 8300 "Indicates the length of the variable-length metadata, in bytes= ."
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > As timestamp can include fractions of second, which is a= good thing,
=C2=A0 =C2=A0 > then please reword "expressed in seconds relative&q= uot; to indicate that
=C2=A0 =C2=A0 > fraction of second is included.

=C2=A0 =C2=A0 [Med] OK.

=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > The 32-bit epoch will wrap around in 2036, should this I= -D already
=C2=A0 =C2=A0 > consider what to do at that moment ?

=C2=A0 =C2=A0 [Med] Hmm. We say that it wraps in 2106 :-)

EV> I should have spot the different epoch ;-)

=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > -- Section 8 --
=C2=A0 =C2=A0 > Indeed MTU is always an interesting 'problem' bu= t how is this
=C2=A0 =C2=A0 > extension different than plain NSH ? The NSH neither inc= reases nor
=C2=A0 =C2=A0 > decreases on the fly with this document.

=C2=A0 =C2=A0 [Med] It varies as we can add/strip context headers as the pa= cket progress in the service chain.

EV> Amazing that this was accepted by the IESG in RFC 8300 years ago... = when net-pgm RFC had to remove the header insertion.

=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > =3D=3D NITS =3D=3D
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > -- Section 3 --
=C2=A0 =C2=A0 > Should 'figure 1' be 'table 1' per consi= stency with section 4.1.1 ?

=C2=A0 =C2=A0 [Med] It should. Will be fixed. Thanks.

=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >


=C2=A0 =C2=A0 _____________________________________________________________= ____________________________________________________________

=C2=A0 =C2=A0 Ce message et ses pieces jointes peuvent contenir des informa= tions confidentielles ou privilegiees et ne doivent donc
=C2=A0 =C2=A0 pas etre diffuses, exploites ou copies sans autorisation. Si = vous avez recu ce message par erreur, veuillez le signaler
=C2=A0 =C2=A0 a l'expediteur et le detruire ainsi que les pieces jointe= s. Les messages electroniques etant susceptibles d'alteration,
=C2=A0 =C2=A0 Orange decline toute responsabilite si ce message a ete alter= e, deforme ou falsifie. Merci.

=C2=A0 =C2=A0 This message and its attachments may contain confidential or = privileged information that may be protected by law;
=C2=A0 =C2=A0 they should not be distributed, used or copied without author= isation.
=C2=A0 =C2=A0 If you have received this email in error, please notify the s= ender and delete this message and its attachments.
=C2=A0 =C2=A0 As emails may be altered, Orange is not liable for messages t= hat have been modified, changed or falsified.
=C2=A0 =C2=A0 Thank you.


--000000000000d4199f05c71412b8-- From nobody Wed Jul 14 10:55:55 2021 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B753A0E5F; Wed, 14 Jul 2021 10:55:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Warren Kumari via Datatracker To: "The IESG" Cc: draft-ietf-sfc-nsh-integrity@ietf.org, sfc-chairs@ietf.org, sfc@ietf.org, gregimirsky@gmail.com, gregimirsky@gmail.com, j.schoenwaelder@jacobs-university.de X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Warren Kumari Message-ID: <162628534840.21882.4452533905992394703@ietfa.amsl.com> Date: Wed, 14 Jul 2021 10:55:48 -0700 Archived-At: Subject: [sfc] Warren Kumari's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2021 17:55:49 -0000 Warren Kumari has entered the following ballot position for draft-ietf-sfc-nsh-integrity-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Roman and Eric's DISCUSS points. I also found: "Note that some transport encapsulations (e.g., IPsec) only provide hop-by-hop security between two SFC data plane elements (e.g., two Service Function Forwarders (SFFs), SFF to SF) and do not provide SF-to-SF security of NSH metadata. For example, if IPsec is used, SFFs or SFs within a Service Function Path (SFP) that are not authorized to access the privacy-sensitive metadata will have access to the metadata." to be incredibly hard to read/parse. I think that my confusion comes in around the "that are not authorized to access the privacy-sensitive metadata will have access to the metadata." test, and thing that the last sentence should be rewritten to start with "Because IPsec does not... it exposes privacy-sensitive metadata to..." Also, thanks to Jürgen Schönwälder for the OpsDir review, and to the authors for addressing the comments. From nobody Wed Jul 14 14:25:57 2021 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B723A0D7A; Wed, 14 Jul 2021 14:25:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-sfc-nsh-integrity@ietf.org, sfc-chairs@ietf.org, sfc@ietf.org, gregimirsky@gmail.com, gregimirsky@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <162629795136.25767.17850752260179612361@ietfa.amsl.com> Date: Wed, 14 Jul 2021 14:25:51 -0700 Archived-At: Subject: [sfc] Benjamin Kaduk's Discuss on draft-ietf-sfc-nsh-integrity-06: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2021 21:25:52 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-sfc-nsh-integrity-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (0) (I came to this realization rather late in my review process, so there may be places where the COMMENT and this discuss point are in disagreement; this DISCUS takes precedence.) I fear that the construction that separately distributes ENC_KEY and MAC_KEY in an attempt to achieve privilege separation is fatally flawed. In particular, the CBC encryption mode is a malleable encryption mode, in that flipping a bit of ciphertext will filp the corresponding bit of the next block of recovered plaintext (at the cost of completely garbling the recovered block containing the bit that was modified). Subsequent blocks are unaffected. Typically we combine CBC mode with a MAC such as HMAC in order to prevent such modifications from being exposed as attack vectors, and while we do use HMAC here for that purpose, we also introduce a separate class of actors that have access to the HMAC key but not the encryption key. Accordingly, those actors can produce a new, valid, integrity tag after making a modification to the ciphertext, allowing them to engage in attacks that make use of ciphertext malleability. Ciphertext malleability is particularly useful as an attack vector when the structure of the plaintext being encrypted is known, and there are portions of the plaintext that the application will either ignore if they are garbled or are expected to be near random in the normal case (and thus for which garbled output does not cause rejection by the application). In a SFC environment it seems highly likely that the structure of the plaintext will be known or guessable, and we don't have any real mechanisms to control what types of metadata go into encrypted context headers, so it seems that we must act as if we are exposed to this risk. While §4.3 does have a note that use of GCM with HMAC is undesirable due to the additional authentication tag, it may be unavoidable in order to provide the properties that we need. (1) Section 5.1 describes the MAC as: Message Authentication Code: Covers the entire NSH data, excluding the Base header. The Additional Authenticated Data (defined in [RFC7518]) MUST be the Service Path header, the unencrypted Context headers, and the inner packet on which the NSH is imposed. This description seems to exclude from the MAC most of the MAC context header itself (if we go by the corresponding figure), which is very bad for security. We definitely need to include under the MAC the MAC context header bits from metadata class through and including at least timestamp, and I think IV length as well. (The IV itself would be incorporated via the ciphertext, since the IV is an input to encryption, but since the IV length field indicates whether or not encryption was performed, we'd need to protect that information.) Similarly, Section 5.2 has the description: Message Authentication Code: Coves the entire NSH data. The Additional Authenticated Data (defined in [RFC7518]) MUST be the entire NSH data (i.e., including the Base Header) excluding the Context Headers to be encrypted. which on the face of it includes the field that holds the MAC itself (and is not yet populated), i.e., is self-referential. I think we need to be much more precise about the construction of the AAD in both cases. It's possible that the HMAC construction for the no-encrypted-context-headers case can inherit a definition from the AAD description, but if not we'll need to have some more precision there as well. (2) In order for the MAC-only construction in §7.2 to be compatible with the AEAD integrity tag construction, we would need to include the 64-bit AL after A. While HMAC is intrinsically immune to length-extension attacks, I think that having the explicit AL is useful to avoid any risk of malleability, since the same MAC_KEY is used for constructing both types of MACs. (3) Section 5.1 describes the Timestamp field as an "unsigned 64-bit integer value", which is inconsistent with the actual format given in Section 6. (4) Section 7.5 directs the verifier to check if "the value of the newly generated digest is identical to the one enclosed in the NSH". It is critical for the security of the system that this comparison be done in a constant-time manner that does not provide a side channel into whether the generated digest and the value in the NSH share a common substring. (5) Do the MAC context headers always have to be the last metadata entries in the packet (to simplify the cryptographic calculations)? Certainly the diagrams only show "unencrypted context headers" appearing prior to the MAC context header, so if we expect unencrypted context headers to appear after the MAC context header as well, we should be clear about that both in the figures and in the specification for how to prepare the AAD. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 3 o Both encrypted and unencrypted Context Headers MAY be included in the same NSH. That is, some Context Headers may be protected while others do not need to be protected. In the security area we're pretty strongly moved towards a stance of "encrypt everything that doesn't have a strong need to be plaintext (since we don't want to assume that we can predict all threats and attacks in advance), and QUIC has even taken that to new levels. It's quite surprising to see "don't need to be protected" as a justification for lack of encryption, rather than "need to be unprotected". Given that we're going to be solving key distribution for integrity protection anyway, it remains unclear to me why we wouldn't just encrypt everything. Section 4.1.1 Is the column heading for the middle column of Table 1 referring to the Base Header and "Service Path Header"? I'm not sure how to interpret just "Service Header" other than the entire NSH, which doesn't seem right... The Service Path Header (Section 2 of [RFC8300]) is not encrypted because SFFs use Service Index (SI) in conjunction with Service Path Identifier (SPI) for determining the next SF in the path. It's good to see this spelled out like this; I'd love to have this kind of explanation for every un-encrypted protocol element. Section 4.1.2 The solution provides integrity protection for the NSH data. Two levels of assurance (LoAs) are supported. I see (reading onward) that the two LoAs just differ in what is covered by the integrity tag, but each involve only a single MAC. There's a reasonable argument that when there are overlapping needs for what data needs protecting and who needs access to it, that multiple MACs (or encryption, if needed) are most appropriate, which can be tailored to the respective needs. This is something that Phillip Hallam-Baker has ascribed as the "short-blanket theory" of cryptography, in that it's like a blanket that's too short to cover everything you want, so you need to have more than one and put them in partially overlapping layers. Perhaps this "short-blanket theory" is more applicable to Discuss point (0) than what is covered by the MAC, though... The first level of assurance where all NSH data except the Base Header are integrity protected (Figure 2). In this case, the NSH imposer may be a Classifier, an NSH-aware SF, or an SFC Proxy. SFFs are not thus provided with authentication material. [...] There seems to be a gap in the chain of reasoning as to why SFFs are not provided with authentication material. It seems that the intent is something along the lines of considering which entities need access to the key material in order to successfully add an NSH or update context headers, but that alone is not itself cause to say that other entities can never be provided with the keys (subject to the security considerations of group-shared PSKs, of course). Furthermore, if a particular SFF is trusted, it may have grounds to verify the integrity tag even if it is administratively prohibited from writing such a tag. In both levels of assurance, the unencrypted Context Headers and the packet on which the NSH is imposed are subject to integrity protection. Surely any encrypted Context Headers are also given integrity protection, as excluding them from the MAC computation would be quite complex. I see that the encrypted context headers are not part of the AAD input, but in the AEAD model the ciphertext is still given integrity protection! Section 4.2 The authenticated encryption algorithm defined in [RFC7518] is used to provide NSH data integrity and to encrypt the Context Headers that carry privacy-sensitive metadata. RFC 7518 (JSON Web Algorithms) is a very surprising reference for generic AEAD encryption. Continuing on, it becomes clear that we in fact do not want a generic AEAD operation here, but instead have need for separation of encryption and integrity protection due to the various separations of roles that are possible. Because this is a divergence from current best practices (use of native AEAD cipher modes like GCM, SIV, etc.), I might suggest a rather different introductory material: % The AEAD interface specified in RFC 5116 is a very powerful tool for % providing strong confidentiality and integrity protection for protocol % messages, and has become quite widely adopted as a result. For % protecting NSH data we adhere to the spirit of the AEAD interface but % use a slightly modified version in order to remain consistent with the % privilege separation needed (e.g., in the second level of assurance, % SFFs need to be able to update the message integrity tag but do not % need access to the decrypted plaintext). Accordingly, a compound AEAD % mechanism combining CBC encryption and HMAC integrity tag is used, so % that distribution of the encryption key can be limited. Rather than % define a new scheme from scratch, the AES_CBC_HMAC_SHA2 scheme from % [RFC7518] is used. In order to simplify key distribution, a single % secret key material seed K is used, which can be kept private % centrally or distributed to all parties that will have access to % decrypted plaintext, and the secondary keys MAC_KEY and ENC_KEY are % derived from K as discussed in Section 5.2.2.1 of [RFC7518]. Entities % that need to update the integrity tag but are not authorized to see % the decrypted plaintext will only receive MAC_KEY and not K or % ENC_KEY. o If the Context Headers are not encrypted, the Hashed Message Authentication Mode (HMAC) algorithm discussed in [RFC4868] is used to protect the integrity of the NSH data. It's not clear to me that this is adding much value; HMAC is used whether or not there are encrypted headers, and the RFC 4868 reference is rather odd (see also my Discuss point (2)). The advantage of using the authenticated encryption algorithm is that NSH-aware SFs and SFC proxies only need to re-compute the message integrity of the NSH data after decrementing the Service Index (SI) and do not have to re-compute the ciphertext. The other advantage is that SFFs do not have access to the ENC_KEY and cannot act on the encrypted Context Headers and, only in case of the second level of assurance, SFFs do have access to the MAC_KEY. Similarly, an NSH- aware SF or SFC Proxy not allowed to decrypt the Context Headers will not have access to the ENC_KEY. [If my above suggestion is used, this text has probably become mostly redundant and could be trimmed down or removed.] The authenticated encryption process takes as input four-octet strings: a secret key (K), a plaintext (P), Additional Authenticated Data (A) (which contains the data to be authenticated, but not encrypted), and an Initialization Vector (IV). The ciphertext value (E) and the Authentication Tag value (T) are provided as outputs. In order to decrypt and verify, the cipher takes as input K, IV, A, T, and E. The output is either the plaintext or an error indicating that the decryption failed as described in Section 5.2.2.2 of [RFC7518]. This seems true for the abstract AEAD interface, but since we're peeling off the HMAC integrity tag for standalone use, we may need to say something about what inputs/outputs are needed for just using the integrity tag without doing decryption. In particular, we cannot use K as an input for standalone HMAC verification! Also, this is just the generic AEAD interface, so RFC 5116 is probably a more apropos reference than RFC 7518. Section 4.3 Note: The use of Advanced Encryption Standard (AES) in Galois/ Counter Mode (GCM) + HMAC may have CPU and packet size implications (need for a second 128-bit authentication tag). [This might also be redundant if my earlier proposal is accepted.] Section 4.4 The document does not assume nor preclude the following: o The same keying material is used for all the service functions used within an SFC-enabled domain. o Distinct keying material is used per SFP by all involved SFC data path elements. o Per-tenant keys are used. I suggest a forward reference to the security considerations with a brief note that the risk involved in using a group-shared symmetric key increases with the size of the group to which it is shared. In order to accommodate deployments relying upon keying material per SFC/SFP and also the need to update keys after encrypting NSH data for a certain amount of time, this document uses key identifiers to unambiguously identify the appropriate keying material. Doing so allows to address the problem of synchronization of keying material. I'd suggest making a statement about the scope in which key identifiers need to be unique. Section 4.5 An NSH-aware SF or SFC Proxy that needs to decrypt some Context Headers uses ENC_Key and the decryption algorithm for the key identifier being carried in the NSH. I think we need to say that decryption MUST NOT proceed unless the integrity tag has been successfully validated. To decrypt without checking the integrity tag violates the AEAD interface. Alternately, we could only ever describe decryption as the AEAD operation that uses K as input (not just ENC_KEY) -- §7.6 seems to attempt to take this latter approach, but the document as a whole is not consistent about it. Section 5, 5.x I strongly suggest changing "Key Length" to "keyid length", since there is already convention on "key length" (e.g., for AES-128 vs AES-192 vs AES-256). Section 5.1 Key Identifier: Carries a variable-length Key Identifier object used to identify and deliver keys to SFC data plane elements. This identifier is helpful to accommodate deployments relying upon keying material per SFC/SFP. The key identifier helps in resolving the problem of synchronization of keying material. I suggest clarifying that a single key identifier is used to lookup both the associated ENC_KEY and the associated MAC_KEY (or, alternately, that it is logically bound to K and remind the reader that ENC_KEY and MAC_KEY are extracted from K and might be separately distributed). Key Length: Variable. Carries the length of the key identifier. [...] IV Length: Carries the length of the IV (Section 5.2 of [RFC7518]). If encryption is not used, IV length is set to zero (that is, no "Initialization Vector" is included). Please also specify that the Key/IV lengths are measured in bytes (the reference for IV length, at least, talks about IVs in bits). I strongly suggest using a value other than zero as the sentinel value for "no encryption" -- there already exist modes like AES-SIV (RFC 5297) that do not require an IV input, which would be a natural use for zero-length IV. Additionally, one might imagine using a non-zero-length IV as input to an HMAC calculation as a per-message nonce. On cursory examination, since we are already using timestamp-based replay detection, the additional nonce is unlikely to add much value, but I'm not willing to completely rule it out on the basis of the minimal analysis I performed. Section 7.1 Only one instance of "MAC and Encrypted Metadata" Context Header (Section 5) is allowed. If multiple instances of "MAC and Encrypted Metadata" Context Header are included in an NSH packet, the SFC data I think Roman may have mentioned this already, but please clarify if this is one instance per NSH or per packet (e.g., in hierarchical SFC we might have more than one NSH in a packet). Please also clarify it if is permitted to have both MAC#1 and MAC#2 present in the same packet. (IIUC there are not obvious situations where such a setup would be useful, but it's still good to be clear about expectations.) Section 7.2 If the Context Headers are not encrypted, the HMAC algorithm discussed in [RFC4868] is used to integrity protect the target NSH data. [...] It's not really clear to me why RFC 4868 is the right reference here, as opposed to (e.g.) RFC 2104. In particular, see my Discuss point (2). The Message Authentication Code (T) computation process can be illustrated as follows: T = HMAC-SHA-256-128(MAC_KEY, A) I agree with the other reviewer that wondered about just using "MAC" (or maybe "HMAC") rather than "HMAC-SHA-256-128" here (I do see the "can be illustrated as" qualifier). It's also a little weird to reuse T and A from the AEAD construction (or RFC 4868) here without additional discussion on how they apply and how the value of A is constructed. An entity in the SFP that intends to update the NSH MUST follow the above behavior to maintain message integrity of the NSH for subsequent validations. I'm not sure that "intends to" is needed; the requirement applies to actions, not intent. Section 7.3 In an SFC-enabled domain where pervasive monitoring [RFC7258] is possible, all Context Headers carrying privacy-sensitive metadata MUST be encrypted; [...] I agree with the other reviewer that noted that this seems to effectively be an unqualified "MUST", since there is always some possibility of monitoring. MAC_KEY = initial MAC_KEY_LEN octets of K, ENC_KEY = final ENC_KEY_LEN octets of K, E = CBC-PKCS7-ENC(ENC_KEY, P), M = MAC(MAC_KEY, A || IV || E || AL), T = initial T_LEN octets of M. MAC and Encrypted Metadata = E || T I recognize that this is just copy+paste from RFC 7518 (with the addition of the last line), but it seems a glaring omission that the CBC-PKCS7-ENC() invocation does not include the IV as an input! (In §5.2.2.1 of RFC 7518 we do see that "The plaintext is CBC encrypted using PKCS #7 padding using ENC_KEY as the key and the IV", so it's just the figure/formula that omits the IV.) We also don't define or mention T_LEN in this document other than in this formula and the analogous one for MAC-without-encryption, which might be worth remedying. Section 7.4 I suggest adding another word (like "Prevention") to the section title. The received NSH is accepted by an NSH-aware node if the Timestamp (TS) in the NSH is recent enough to the reception time of the NSH (TSrt). The following formula is used for this check: -Delta < (TSrt - TS) < +Delta (There's no real reason why the accepted timestamp skew parameter Delta needs to be symmetric in the positive and negative directions.) Replay attacks within the Delta window may be detected by an NSH- aware node by recording a unique value derived, for example, from the NSH data and Original packet (e.g., using SHA2). [...] Note that the unique value MUST NOT use as input any bits that are not covered by the MAC. Indeed, just using the MAC itself as the unique value would be a fairly straightforward scheme, I think. Section 7.5 When an SFC data plane element receives an NSH packet, it MUST first ensure that a "MAC and Encrypted Metadata" Context Header is included. [...] This sort of requirement (as written) would seem to support the position of some other reviewers that this document would need to formally update RFC 8300. Section 9 We might discuss that this mechanism is only for metadata type 2 and not type 1 (as well as that with the relatively small fixed length of type 1 metadata, it's quite challenging to provide useful cryptographic protection), so that type-1 metadata still has no generic protection mechanism. A given metadata element could define its own protection scheme, of course. The attacks discussed in [I-D.nguyen-sfc-security-architecture] are handled owing to the solution specified in this document, except for attacks dropping packets. [...] >From a very quick read, draft-nguyen-sfc-security-architecture proposes a probe-based scheme that monitors all middleboxes (or at least those in the expected path) to detect a middlebox-bypass attack and verify that the probe traversed the expected SFP. I am not sure that this document on its own suffices to prevent the middlebox-bypass attack for all traffic (i.e., the probe-based scheme might still be needed). If some network entities know what the expected service index will be for a given SPI at a given node, then middlebox-bypass attacks could be natively detected, but my understanding was that such advance knowledge of expected service index was not going to be available. The solution specified in this document does not provide data origin authentication. I would have expected more in-depth discussion of the security considerations for a group-shared PSK scheme, including how the risk of key loss/compromise goes up when the key is distributed to more locations. Section 9.1 No device other than the NSH-aware SFs in the SFC-enabled domain should be able to update the integrity protected NSH data. What about classifiers and SFC proxies? Section 9.2 I expected to see some remarks here analogous to the second paragraph of §9.1 (even if just by reference to that section). Section 9.3 Section 5.6 of [RFC8633] describes best current practices to be considered in deployments where SFC data plane elements use NTP for time synchronization purposes. The referenced section covers NTP symmetric mode only. Is client/server mode not a BCP for trusted networks and broadcast/symmetric the only options? NITS Section 1 network infrastructures against them, network slicing, etc. Because of the proliferation of such advanced SFs together with complex service deployment constraints that demand more agile service delivery procedures, operators need to rationalize their service delivery logics and master their complexity while optimising service activation time cycles. The overall problem space is described in [RFC7498]. The "their" in "master their complexity" is a bit ambiguous between "operators" and "service delivery logics" (noting that the previous use of "their" did refer to "operators"). (The sentence as a whole reads a bit like marketing language, but that's not intended to be an actionable comment.) This specification fills that gap. Concretely, this document adds integrity protection and optional encryption of sensitive metadata directly to the NSH (Section 4); integrity protects the packet payload and provides replay protection (Section 7.4). [...] The clause after the semicolon needs to be able to stand alone as a complete sentence in order to be grammatical, but it currently has no subject. Maybe prefixing "it also" would be enough to fix it. Section 4.1.2 The integrity protection scope is explicitly signaled to NSH-aware SFs and SFC proxies in the NSH by means of a dedicated MD Type (Section 5). Signaled to SFFs as well, since in the second LoA they can use it. Section 4.6 As discussed in [RFC8459], an SFC-enabled domain (called, upper-level domain) may be decomposed into many sub-domains (called, lower-level domains). In order to avoid maintaining state to restore back upper- lower NSH information at the boundaries of lower-level domains, two I think s/upper-lower/upper-layer/ (across the line break)? Section 5.1 MAC#1 Context Header is a variable-length Context Header that carries the Message Authentication Code (MAC) for the Service Path Header, Context Headers, and the inner packet on which NSH is imposed, calculated using MAC_KEY and optionally Context Headers encrypted using ENC_KEY. [...] Comma after "calculated using MAC_KEY", please. ("optionally Context Headers [...]" are not used along with MAC_KEY in the calculation) Section 5.2 Message Authentication Code: Coves the entire NSH data. The s/Coves/Covers/ Section 6 The epoch is 1970-01-01T00:00Z in UTC time. [...] (IIUC, the "in UTC time" is redundant with the trailing 'Z'.) Section 7.1 element. The details of sending notification alarms (i.e., the parameters affecting the transmission of the notification alarms depend on the information in the context header such as frequency, thresholds, and content in the alarm) SHOULD be configurable. The grammar in the parenthetical seems off to me. Possibly s/depend/depending/ would be a fix, but I'm not sure. NSH-aware SFs and SFC proxies MUST re-apply the integrity protection if any modification is made to the Context Headers (strip a Context Header, update the content of an existing Context Header, insert a new Context Header). I think maybe an "e.g.," in the parenthetical is in order, since this doesn't seem to include things like "decrement the TTL". Section 9 The interaction between the SFC data plane elements and a key management system MUST NOT be transmitted in clear since this would completely destroy the security benefits of the integrity protection solution defined in this document. The secret key (K) must have an expiration time assigned as the latest point in time before which the This first sentence seems like it could probably be a paragraph of its own; the subsequent discussion of expiration time seems to be mostly unrelated. We might also add another sentence to reiterate that "the security and integrity of the key-distribution mechanism is vital to the security of the system as a whole". o Attacker replacing the packet on which the NSH is imposed with a bogus packet. I'd probably say "modified or bogus". In an SFC-enabled domain where the above attacks are possible, (1) This is perhaps ambiguous about whether an "any" or "all" criterion should be used. Perhaps that's desired :) From nobody Wed Jul 14 16:16:07 2021 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1033A0C55; Wed, 14 Jul 2021 16:16:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: John Scudder via Datatracker To: "The IESG" Cc: draft-ietf-sfc-nsh-integrity@ietf.org, sfc-chairs@ietf.org, sfc@ietf.org, gregimirsky@gmail.com, gregimirsky@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: John Scudder Message-ID: <162630455957.5451.359442420121368370@ietfa.amsl.com> Date: Wed, 14 Jul 2021 16:16:00 -0700 Archived-At: Subject: [sfc] John Scudder's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2021 23:16:00 -0000 John Scudder has entered the following ballot position for draft-ietf-sfc-nsh-integrity-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1. Section 4.2 The authenticated encryption process takes as input four-octet strings: a secret key (K), a plaintext (P), Additional Authenticated Data (A) (which contains the data to be authenticated, but not encrypted), and an Initialization Vector (IV). The ciphertext value (E) and the Authentication Tag value (T) are provided as outputs. As written, this means that each of these quantities is a 32 bit string, even P and A. I think you don’t mean that. If you mean each quantity is a string of octets, then move the hyphen: “takes as input four octet-strings“. (In the unlikely event you really do mean each quantity is a string of four octets, then “… takes as input four strings, each of four octets.”) 2. Section 9 Regarding your use of the term “man-in-the-middle attacker”, you might want to take into consideration that this language may be seen as exclusionary by some readers, see also https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/. I’ve seen “on-path attacker“ used as a replacement in some cases, but I understand there may be nuances that make this inappropriate for some uses; it also appears you might just be able to use “attacker” in your case. The RFC Editor may have further guidance. 3. Section 9.1 You use “should“ in several places. As written, it isn’t clear if you’re indicating expectation, or requirement. After reading the whole section, I think you’re indicating requirement. This seems like a good place for use of the RFC 2119 style SHOULD keyword. From nobody Wed Jul 14 21:48:41 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB6073A1B84; Wed, 14 Jul 2021 21:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvDsVU1lOwTp; Wed, 14 Jul 2021 21:48:30 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (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 7AA2E3A1B82; Wed, 14 Jul 2021 21:48:29 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr23.francetelecom.fr (ESMTP service) with ESMTPS id 4GQMMD29Jzz5w2K; Thu, 15 Jul 2021 06:48:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1626324504; bh=PGLvL+sF8EDvz+91GKqpL0SYDcDdjXu1L0gxK1rppLw=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=CspeMwZfit6Qmaasmm1gpy9HuxV2pOUirOomATgvaM4Yz+2zhv4WR84xZ17gLNL0y 4q/V17PpsKvPKFO3Q0nDwLcF3mHzqJMI0GqmabG2QNYYOHTo+Mh/NNAAzl1iFijwn6 7VNK6Nha/vd+o66xQf5TEzJ3hV6Rr6GrgItMUmJgIoda6wrLZUS3MAt0nLtgKeMjFJ vBqoQOKlxhwShmXDBafprCxeGPm+WSnPerf1izpi1J2SlviQHeSgnhr1dXT6qYbTk/ XS1jnSBAWNXbf+nyPgbxIj48hm4yPmAe2el2lH7dCcUlhPFWKBpVRdqmBupnLgJel5 hq2Ovpe5X9jKA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfednr07.francetelecom.fr (ESMTP service) with ESMTPS id 4GQMMD1D4rzFpWq; Thu, 15 Jul 2021 06:48:24 +0200 (CEST) From: To: tirumal reddy , Roman Danyliw CC: The IESG , "draft-ietf-sfc-nsh-integrity@ietf.org" , "sfc-chairs@ietf.org" , "sfc@ietf.org" , "gregimirsky@gmail.com" Thread-Topic: Roman Danyliw's Discuss on draft-ietf-sfc-nsh-integrity-06: (with DISCUSS and COMMENT) Thread-Index: AQHXeJKM+kghL6GQcEOKgKF5y7vAVKtDdiAg Date: Thu, 15 Jul 2021 04:48:23 +0000 Message-ID: <23928_1626324504_60EFBE18_23928_377_1_787AE7BB302AE849A7480A190F8B9330353BF404@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162620296297.3569.2501497601980031548@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330353BF404OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Roman Danyliw's Discuss on draft-ietf-sfc-nsh-integrity-06: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 04:48:35 -0000 --_000_787AE7BB302AE849A7480A190F8B9330353BF404OPEXCAUBMA2corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9tYW4sIGFsbCwNCg0KQSB2ZXJzaW9uIHRoYXQgYWRkcmVzc2VzIHlvdXIgcmV2aWV3IGNh biBiZSB0cmFja2VkIGF0OiBodHRwczovL3Rpbnl1cmwuY29tL25zaC1pbnRlZ3JpdHktbGF0ZXN0 Lg0KDQpQbGVhc2Ugc2VlIGlubGluZSBmb3IgdHdvIG1vcmUgY29tbWVudHMgaW4gYWRkaXRpb24g dG8gdGhlIGNsYXJpZmljYXRpb25zIHByb3ZpZGVkIGJ5IFRpcnUuDQoNCkNoZWVycywNCk1lZA0K DQpEZSA6IHRpcnVtYWwgcmVkZHkgW21haWx0bzprb25kdGlyQGdtYWlsLmNvbV0NCkVudm95w6kg OiBtZXJjcmVkaSAxNCBqdWlsbGV0IDIwMjEgMTE6MjgNCsOAIDogUm9tYW4gRGFueWxpdyA8cmRk QGNlcnQub3JnPg0KQ2MgOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz47IGRyYWZ0LWlldGYtc2Zj LW5zaC1pbnRlZ3JpdHlAaWV0Zi5vcmc7IHNmYy1jaGFpcnNAaWV0Zi5vcmc7IHNmY0BpZXRmLm9y ZzsgZ3JlZ2ltaXJza3lAZ21haWwuY29tDQpPYmpldCA6IFJlOiBSb21hbiBEYW55bGl3J3MgRGlz Y3VzcyBvbiBkcmFmdC1pZXRmLXNmYy1uc2gtaW50ZWdyaXR5LTA2OiAod2l0aCBESVNDVVNTIGFu ZCBDT01NRU5UKQ0KDQpIaSBSb21hbiwNCg0KUGxlYXNlIHNlZSBpbmxpbmUNCg0KT24gV2VkLCAx NCBKdWwgMjAyMSBhdCAwMDozMywgUm9tYW4gRGFueWxpdyB2aWEgRGF0YXRyYWNrZXIgPG5vcmVw bHlAaWV0Zi5vcmc8bWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmc+PiB3cm90ZToNClJvbWFuIERhbnls aXcgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQpkcmFmdC1p ZXRmLXNmYy1uc2gtaW50ZWdyaXR5LTA2OiBEaXNjdXNzDQoNCldoZW4gcmVzcG9uZGluZywgcGxl YXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KZW1haWwg YWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8g Y3V0IHRoaXMNCmludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KDQoNClBsZWFzZSBy ZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRl cmlhLmh0bWwNCmZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IERJU0NVU1MgYW5kIENPTU1FTlQg cG9zaXRpb25zLg0KDQoNClRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9z aXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtc2ZjLW5zaC1pbnRlZ3JpdHkvDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpE SVNDVVNTOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoqKiBTZWN0aW9uIDQuNi4gIFRoaXMgc2VjdGlvbiBl eHBsYWlucyB0aGF0IGFuIHVwcGVyIE5TSCBjYW4gYmUgZW5jYXBzdWxhdGVkIGluDQphIGxvd2Vy IE5TSCwgYW5kIHRoYXQg4oCcdGhlIFVwcGVyLU5TSCBpbmZvcm1hdGlvbiBpcyBjYXJyaWVkIGFs b25nIHRoZQ0KbG93ZXItbGV2ZWwgY2hhaW4gd2l0aG91dCBtb2RpZmljYXRpb24u4oCdICBJIHJl YWQgdGhpcyB0byBtZWFuIHRoYXQgdGhlIHVwcGVyDQphbmQgbG93ZXIgTlNIIGNhbiBpbmRlcGVu ZGVudGx5IGJlIHByb3RlY3RlZCB3aXRoIGRpZmZlcmVudCBrZXlzLiAgVGhlIHRleHQNCmV2ZW4g aGVscGZ1bGx5IHBvaW50cyBvdXQgdGhhdCDigJxLZXlpbmcgbWF0ZXJpYWwgdXNlZCBhdCB0aGUg dXBwZXItbGV2ZWwgZG9tYWluDQpTSE9VTEQgTk9UIGJlIHRoZSBzYW1lIGFzIHRoZSBvbmUgdXNl ZCBieSBhIGxvd2VyLWxldmVsIGRvbWFpbi7igJ0gIFN1Y2ggYQ0KY29uc3RydWN0IHN1Z2dlc3Rz IHRoYXQgdGhlcmUgYXJlIG11bHRpcGxlIE1BQy9FbmNyeXB0ZWQgTWV0YWRhdGEgY29udGV4dA0K aGVhZGVycywgb25lIGZvciB0aGUgdXBwZXIgYW5kIGFub3RoZXIgZm9yIHRoZSBsb3dlci4gIEhv d2V2ZXIsIFNlY3Rpb24gNy4xDQpsYXRlciBub3RlcyB0aGF0IOKAnE9ubHkgb25lIGluc3RhbmNl IG9mICJNQUMgYW5kIEVuY3J5cHRlZCBNZXRhZGF0YSIgQ29udGV4dA0KSGVhZGVyIChTZWN0aW9u IDUpIGlzIGFsbG93ZWQu4oCdICBUaGlzIHNlZW1zIGxpa2UgY29uZmxpY3QuICBXaGF0IGFtIEkg bWlzc2luZz8NCg0KSXQgbWVhbnMgb25seSBvbmUgaW5zdGFuY2UgIk1BQyBhbmQgRW5jcnlwdGVk IE1ldGFkYXRhIiBDb250ZXh0IEhlYWRlciAoU2VjdGlvbiA1KSBpcyBhbGxvd2VkIGluIGFuIE5T SC1sZXZlbCAob25lIGluc3RhbmNlIGluIHRoZSBVcHBlci1OU0ggYW5kIGFub3RoZXIgaW4gdGhl IExvd2VyLU5TSCksIHdlIHdpbGwgdXBkYXRlIHRleHQgZm9yIGJldHRlciBjbGFyaXR5Lg0KDQoN CioqIFNlY3Rpb24gNy4yLiAgT24gY29tcHV0aW5nIHRoZSBITUFDIGluIGFuIGludGVncml0eSBv bmx5IHNpdHVhdGlvbjoNCg0KLS0gVGhpcyBzZWN0aW9uIGRlZmluZXMgdGhlIE1BQyBhcyDigJxU ID0gSE1BQy1TSEEtMjU2LTEyOChNQUNfS0VZLCBBKeKAnS4NClByZXZpb3VzbHksIEEgd2FzIGRl ZmluZWQgYXMgdGhlIEFkZGl0aW9uYWwgQXV0aGVudGljYXRlZCBEYXRhIChwZXIgU2VjdGlvbg0K NC4yKS4gIFNpbmNlIHRoaXMgaXNu4oCZdCB0aGUgQUVBRCB1c2UgY2FzZSwgdGhlcmUgaXMgbm8g QS4gSXQgc2VlbXMgdGhhdCB0aGlzDQpzaG91bGQgYmUgc29tZXRoaW5nIGNsb3NlciB0bzog4oCc VCA9IEhNQUMtU0hBLTI1Ni0xMjgoTUFDX0tFWSwgPHBhcnQgb2YgdGhlDQpwYWNrZXQgeW91IHdh bnQgdG8gaGFzaD4p4oCdLg0KDQpHb29kIGNhdGNoLCB3aWxsIHVwZGF0ZSB0byAiVCA9IEhNQUMt U0hBLTI1Ni0xMjgoTUFDX0tFWSwgdGFyZ2V0IE5TSCBkYXRhKSINCg0KDQotLSBUaGUgdGV4dCB3 b3VsZCBiZW5lZml0IGZyb20gYSBkZXNjcmlwdGlvbiBvbiBob3cgdG8gc2VyaWFsaXplIHRoZSBw YWNrZXQgZm9yDQpoYXNoaW5nLiAgRm9yIGV4YW1wbGUsIEZpZ3VyZSA2IGFuZCA3IGFyZSBoZWxw ZnVsIGxvZ2ljYWwgZGVzY3JpcHRpb25zIG9mIHRoZQ0KaW50ZWdyaXR5IHNjb3BlLiAgSG93ZXZl ciwgdGhlIE1BQyBmaWVsZCBpdHNlbGYgaXMgZGVwaWN0ZWQgYXMgcGFydCBvZiB0aGUgd2hhdA0K c2hvdWxkIGdldCBoYXNoZWQuICBTaG91bGQgdGhhdCBmaWVsZCBiZSB6ZXJvZWQgb3V0PyBSZW1v dmVkID8NCg0KWWVzLCB3ZSB3aWxsIHVwZGF0ZSB0ZXh0IGFzIGZvbGxvd3M6DQoNClRoZSBOU0gg aW1wb3NlciBzZXRzIHRoZSBNQUMgZmllbGQgdG8gemVybyBhbmQgdGhlbiBjb21wdXRlcyB0aGUg bWVzc2FnZSBpbnRlZ3JpdHkgZm9yIHRoZSB0YXJnZXQgTlNIIGRhdGEgKGRlcGVuZGluZyBvbiB0 aGUgaW50ZWdyaXR5IHByb3RlY3Rpb24gc2NvcGUgZGlzY3Vzc2VkIGluIFNlY3Rpb24gNSkgdXNp bmcgTUFDX0tFWSBhbmQgSE1BQyBhbGdvcml0aG0uIEl0IGluc2VydHMgdGhlIGNvbXB1dGVkIGRp Z2VzdCBpbiB0aGUgTUFDIGZpZWxkIGluIHRoZSAiTUFDIGFuZCBFbmNyeXB0ZWQgTWV0YWRhdGEi IENvbnRleHQgSGVhZGVyLg0KDQoNCioqIFNlY3Rpb24gOS4NCiAgIFRoZSBhdHRhY2tzIGRpc2N1 c3NlZCBpbiBbSS1ELm5ndXllbi1zZmMtc2VjdXJpdHktYXJjaGl0ZWN0dXJlXSBhcmUNCiAgIGhh bmRsZWQgb3dpbmcgdG8gdGhlIHNvbHV0aW9uIHNwZWNpZmllZCBpbiB0aGlzIGRvY3VtZW50LCBl eGNlcHQgZm9yDQogICBhdHRhY2tzIGRyb3BwaW5nIHBhY2tldHMuDQoNClRoZSBhYm92ZSByZWZl cmVuY2UgaGlnaGxpZ2h0cyB0aGUgZm9sbG93aW5nIGF0dGFja2VycyDigJMg4oCcVGhlcmUgYXJl IG1hbnkgdHlwZXMNCm9mIGNvbXByb21pc2VkIHN3aXRjaGVzIGF0dGFjazogcGFja2V0IGRyb3Bw aW5nLCBwYWNrZXQgZHVwbGljYXRpbmcsIHBhY2tldA0KbWFuaXB1bGF0aW5nLCBpbmNvcnJlY3Qg Zm9yd2FyZGluZywgIGVhdmVzZHJvcHBpbmcsIHdlaWdodCBhZGp1c3RpbmcsDQptYW4taW4tdGhl LW1pZGRsZSwgc3RhdGUtc3Bvb2ZpbmcsIGNvbnRyb2wtY2hhbm5lbCBoaWphY2tpbmcsIGV0Yy7i gJ0gIFBlciB0aGUNCnNlY3VyaXR5IHNlcnZpY2VzIGluIHRoaXMgZG9jdW1lbnQsIGl0IGRvZXNu 4oCZdCBzZWVtIGxpa2UgYWxsIGFyZSBtaXRpZ2F0ZWQgYnkNCnRoaXMgZHJhZnQgYXMgZGVzY3Jp YmVkIGFib3ZlOg0KDQotLSBwYWNrZXQgZHJvcHBpbmcgPSBub3RlZCBhcyBub3QgYmVpbmcgaGFu ZGxlZA0KDQotLSBwYWNrZXQgbWFuaXB1bGF0aW5nLCBlYXZlc2Ryb3BwaW5nLCB3ZWlnaHQgYWRq dXN0aW5nLCBtYW4taW4gdGhlLW1pZGRsZSwNCnN0YXRlLXNwb29maW5nLCBhbmQgY29udHJvbC1j aGFubmVsIGhpamFja2luZyA9IGFwcGVhciB0byBiZSBoYW5kbGVkIGlmIGJvdGgNCnNlY3VyaXR5 IHNlcnZpY2VzIGFyZSBhcHBsaWVkDQoNClllcy4NCg0KDQotLSBwYWNrZXQgZHVwbGljYXRpbmcg PSB0aGlzIGRyYWZ0IGRvZXNu4oCZdCBub3QgcHJvdmlkZSBhIHN0YW5kYXJkaXplZCBhcHByb2Fj aA0KZm9yIG1pdGlnYXRpbmcgdGhpcyBpc3N1ZQ0KDQpSZXBsYXkgYXR0YWNrIGlzIGRldGVjdGVk IHVzaW5nIHRpbWVzdGFtcCBhbmQgcmVjb3JkaW5nIGEgdW5pcXVlIHZhbHVlIHdpdGhpbiB0aGUg ZGVsdGEgd2luZG93IGRlcml2ZWQgZnJvbSB0aGUgTlNIIGRhdGEgYW5kIHBhY2tldCAoc2VlIGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1zZmMtbnNoLWlu dGVncml0eSNzZWN0aW9uLTcuNCkuDQoNCg0KLS0gaW5jb3JyZWN0IGZvcndhcmRpbmcgPSBkb2Vz buKAmXQgYXBwZWFyIHRvIGJlIG1pdGlnYXRlZC4NCg0KSWYgdGhlIGNvbnRleHQgaGVhZGVycyBh cmUgZW5jcnlwdGVkLCBhbiBhdHRhY2tlciByZWNlaXZpbmcgZm9yd2FyZGVkIE5TSCBmcm9tIGFu IGNvbXByb21pc2VkIHN3aXRjaCB3aWxsIG5vdCBiZSBhYmxlIHRvIGRlY3J5cHQgdGhlIGNvbnRl eHQgaGVhZGVycy4NCltNZWRdIGluY29ycmVjdCBmb3J3YXJkaW5nIGlzIHByZXZlbnRlZCBhcyBh bnkgbWFuaXB1bGF0aW9uIHRvIHRoZSBzZXJ2aWNlIGluZGV4IGlzIGRldGVjdGVkIGJ5IFNGcy4g VGhpcyBpcyBhbHJlYWR5IGRpc2N1c3NlZCBpbiB0aGUgdGV4dDoNCg0KICAgQWxzbywgaWYgU0ZG cyBhcmUgbm90IGludm9sdmVkIGluIHRoZSBpbnRlZ3JpdHkgY2hlY2tzLCBhDQogICBtaXNiZWhh dmluZyBTRkYgd2hpY2ggZGVjcmVtZW50cyBTSSB3aGlsZSB0aGlzIHNob3VsZCBiZSBkb25lIGJ5 IGFuDQogICBTRiAoU0YgYnlwYXNzIGF0dGFjaykgd2lsbCBiZSBkZXRlY3RlZCBieSBhbiB1cHN0 cmVhbSBTRiBiZWNhdXNlIHRoZQ0KICAgaW50ZWdyaXR5IGNoZWNrIHdpbGwgZmFpbC4NCg0KDQoN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCkNPTU1FTlQ6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCioqIFNlY3Rpb24gMS4N CiAgIFRodXMsIHRoZSBOU0gNCiAgIGRvZXMgbm90IGhhdmUgdG8gcmVseSB1cG9uIGFuIHVuZGVy bHlpbmcgdHJhbnNwb3J0IGVuY2Fwc3VsYXRpb24gZm9yDQogICBzZWN1cml0eSBhbmQgY29uZmlk ZW50aWFsaXR5Lg0KDQpJc27igJl0IGNvbmZpZGVudGlhbGl0eSBqdXN0IGEgc3Vic2V0IG9mIHRo ZSBwcm92aWRlZCBzZWN1cml0eSBwcm9wZXJ0aWVzLCBvciBpcw0Kc29tZXRoaW5nIGVsc2UgaW50 ZW5kZWQ/ICBSZWNvbW1lbmQgcy9mb3Igc2VjdXJpdHkgYW5kIGNvbmZpZGVudGlhbGl0eS9mb3IN CnNlY3VyaXR5Lw0KDQpZZXMsIEkgd2lsbCB1cGRhdGUgdGhlIHRleHQuDQoNCg0KKiogU2VjdGlv biAyLiAgUGVyIOKAnEtleSBJZGVudGlmaWVyOiAgSXMgdXNlZCB0byBpZGVudGlmeSBhbmQgZGVs aXZlciBrZXlzIHRvDQphdXRob3JpemVkIGVudGl0aWVzLiAgU2VlLCBmb3IgZXhhbXBsZSwgJ2tp ZCcgdXNhZ2UgaW4gW1JGQzc2MzVd4oCdLiBIb3cgZG9lcyBhDQprZXkgaWRlbnRpZmllciDigJxk ZWxpdmVyeSBrZXlz4oCdPyAgRG9lc27igJl0IGFub3RoZXIgcHJvdG9jb2wgcHJvdmlkZSB0aGUg ZGVsaXZlcnkNCnVzaW5nIHRoZSBraWQgYXMgYW4gaWRlbnRpZmllcj8NCg0KWWVzLCBraWQgaXMg dHlwaWNhbGx5IHVzZWQgYXMgYW4gaWRlbnRpZmllciBieSBhIEtNUyBwcm90b2NvbC4NCg0KDQoq KiBTZWN0aW9uIDcuMi4gIEhvdyBkb2VzIG9uZSBzZXJpYWxpemUgdGhlIHBhY2tldCBkYXRhIHRv IGNvbnN0cnVjdCBBPyAgRmlndXJlDQo3IGlzIHRoZSBjbG9zZXN0IGd1aWRhbmNlIGJ1dCBpdCBp bmNsdWRlcyB0aGUgTUFDIGl0c2VsZi4NCg0KVGhlIE1BQyBmaWVsZCBpcyBzZXQgdG8gemVybyBi ZWZvcmUgY29tcHV0aW5nIHRoZSBtZXNzYWdlIGludGVncml0eSwgd2Ugd2lsbCB1cGRhdGUgdGhl IHRleHQuDQoNCg0KKiogU2VjdGlvbiA3LjQuDQogICDigKYgbGVnaXRpbWF0ZSBkdXBsaWNhdGUg cGFja2V0cyB3aWxsIGJlDQogICB0YWdnZWQgYnkgTlNILWF3YXJlIG5vZGVzIGludm9sdmVkIGlu IHRoYXQgc2VnbWVudCBhcyByZXBsYXkgcGFja2V0cw0KICAgdW5sZXNzIHN1ZmZpY2llbnQgZW50 cm9weSBpcyBhZGRlZCB0byB0aGUgZHVwbGljYXRlIHBhY2tldC4NCg0KV2hhdCBpcyB0aGUgcHJl c2NyaWJlZCBtZWNoYW5pc20gdG8gYWRkIGVudHJvcHk/DQoNClNlcXVlbmNlIG51bWJlcnMgY2Fu IGJlIHVzZWQgYXMgZGlzY3Vzc2VkIGluIHRoZSBub3RlIGluIFNlY3Rpb24gNy40DQpbTWVkXSB0 aGlzIGNhbiBhbHNvIGJlIGhhbmRsZWQgYnkgU0ZzIHRoZW1zZWx2ZXMuIEFkZGVkIHRoaXMgbm90 ZToNCg0KDQrigJxIb3cgc3VjaA0KDQogICBhbiBlbnRyb3B5IGlzIGFkZGVkIGlzIGltcGxlbWVu dGF0aW9uLXNwZWNpZmljLuKAnQ0KDQoNCg0KKiogU2VjdGlvbiA3LjUNCiAgIFdoZW4gYW4gU0ZD IGRhdGEgcGxhbmUgZWxlbWVudCByZWNlaXZlcyBhbiBOU0ggcGFja2V0LCBpdCBNVVNUIGZpcnN0 DQogICBlbnN1cmUgdGhhdCBhICJNQUMgYW5kIEVuY3J5cHRlZCBNZXRhZGF0YSIgQ29udGV4dCBI ZWFkZXIgaXMNCiAgIGluY2x1ZGVkLg0KDQpJIHdhcyB1bmRlciB0aGUgaW1wcmVzc2lvbiB0aGF0 IHRoZSBzZWN1cml0eSBwcm90ZWN0aW9ucyBzcGVjaWZpZWQgaW4gdGhpcw0KZG9jdW1lbnQgd2Vy ZSBvcHRpb25hbCBpbiB0aGUgb3ZlcmFsbCBTRkMgYXJjaGl0ZWN0dXJlLiAgSXMgdGhlcmUgc29t ZSBjYXZlYXQNCnRvIGFkZCB0byB0aGlzIHNlY3Rpb24gdG8gcmVtaW5kZXIgcmVhZGVycz8gIFBl cmhhcHMsICDigJxXaGVuIGFuIFNGQyBkYXRhIHBsYW4NCmVsZW1lbnQgY29uZm9ybXMgdG8gdGhp cyBzcGVjaWZpY2F0aW9uLCBpdCBNVVNUIGZpcnN0IOKApuKAnQ0KDQpZZXMsIHdlIHdpbGwgdXBk YXRlLg0KDQoNCioqIFNlY3Rpb24gNy41IGFuZCA3LjYuICBXaGF0IGlzIHRoZSBlcnJvciBwcm9j ZXNzaW5nIGZvciByZWNlaXZpbmcgYSBwYWNrZXQNCndpdGggYW4gdW5rbm93biBrZXkgaWRlbnRp Zmllcj8NCg0KQW4gZXJyb3Igc2hvdWxkIGJlIGxvZ2dlZCwgd2Ugd2lsbCB1cGRhdGUgdGhlIGRy YWZ0Lg0KW01lZF0gVXBkYXRlZCB0aGUgdGV4dCB0byBjb3ZlciBib3RoIHVua25vd24gYW5kIGlu dmFsaWQga2lkcy4NCg0KDQoqKiBTZWN0aW9uIDkuIFNlY3Rpb24gOS4gIENhbiB5b3UgZnVydGhl ciBjbGFyaWZ5IGhvdyBpcyB0aGUgcmVhZGVyIHN1cHBvc2VkIHRvDQppbnRlcnByZXQgdGhlIGd1 aWRhbmNlIGluIFJGQzQxMDcgd2hpY2ggZnJhbWVzIGl0cyBzY29wZSBhcyBndWlkZWxpbmVzIGFz IHRvIGJlDQrigJwuLi4gdXNlW2RdIGJ5IElFVEYgd29ya2luZyBncm91cHMgYW5kIHByb3RvY29s IGF1dGhvcnMgd2hvIGFyZSBkZXRlcm1pbmluZw0Kd2hldGhlciB0byBtYW5kYXRlIGF1dG9tYXRl ZCBrZXkgICAgbWFuYWdlbWVudCBhbmQgd2hldGhlciBtYW51YWwga2V5DQptYW5hZ2VtZW50IGlz IGFjY2VwdGFibGUuICBJbmZvcm1lZCBqdWRnbWVudCBpcyBuZWVkZWQu4oCdICBEb2VzIHRoaXMg ZG9jdW1lbnQNCnRha2UgYSBwb3NpdGlvbiBvbiBhdXRvbWF0ZWQgdnMuIG1hbnVhbCBrZXkgbWFu YWdlbWVudD8NCg0KKiogU2VjdGlvbiA5LiAgUGVyIOKAnFRoZSBzZWNyZXQga2V5IChLKSBtdXN0 IGhhdmUgYW4gZXhwaXJhdGlvbiB0aW1lIGFzc2lnbmVkIOKApuKAnToNCg0KKEkgc3VzcGVjdCBt YW55IG9mIHRoZXNlIGlzc3VlcyBhcmUgb3V0IG9mIHNjb3BlIOKApikNCg0KLS0gd2hvIGFzc2ln bnMgdGhhdCBleHBpcmF0aW9uIHRpbWUgKHRoZSBrZXkgbWFuYWdlbWVudCBzeXN0ZW0pPw0KDQpZ ZXMuDQpbTWVkXSBBbmQgY29tbXVuaWNhdGVkIGJ5IHRoZSBjb250cm9sIHBsYW5lLiBQbGVhc2Ug cmVmZXIgdG8gdGhpcyBwYXJ0IGluIHRoZSBkcmFmdDoNCg0KVGhlIHNlY3JldCBrZXkgKEspIG11 c3QgaGF2ZSBhbg0KDQogICBleHBpcmF0aW9uIHRpbWUgYXNzaWduZWQgYXMgdGhlIGxhdGVzdCBw b2ludCBpbiB0aW1lIGJlZm9yZSB3aGljaCB0aGUNCg0KICAga2V5IG1heSBiZSB1c2VkIGZvciBp bnRlZ3JpdHkgcHJvdGVjdGlvbiBvZiBOU0ggZGF0YSBhbmQgZW5jcnlwdGlvbg0KDQogICBvZiBD b250ZXh0IEhlYWRlcnMuICBQcmlvciB0byB0aGUgZXhwaXJhdGlvbiBvZiB0aGUgc2VjcmV0IGtl eSwgYWxsDQoNCiAgIHBhcnRpY2lwYXRpbmcgTlNILWF3YXJlIG5vZGVzIFNIT1VMRCBoYXZlIHRo ZSBjb250cm9sIHBsYW5lDQoNCiAgIGRpc3RyaWJ1dGUgYSBuZXcga2V5IGlkZW50aWZpZXIgYW5k IGFzc29jaWF0ZWQga2V5aW5nIG1hdGVyaWFsIHNvDQoNCiAgIHRoYXQgd2hlbiB0aGUgc2VjcmV0 IGtleSBpcyBleHBpcmVkLCB0aG9zZSBub2RlcyBhcmUgcHJlcGFyZWQgd2l0aA0KDQogICB0aGUg bmV3IHNlY3JldCBrZXkuICBUaGlzIGFsbG93cyB0aGUgTlNIIGltcG9zZXIgdG8gc3dpdGNoIHRv IHRoZSBuZXcNCg0KICAga2V5IGlkZW50aWZpZXIgYXMgc29vbiBhcyBuZWNlc3NhcnkuICBJdCBp cyBSRUNPTU1FTkRFRCB0aGF0IHRoZSBuZXh0DQoNCiAgIGtleSBpZGVudGlmaWVyIGFuZCBhc3Nv Y2lhdGVkIGtleWluZyBtYXRlcmlhbCBiZSBkaXN0cmlidXRlZCBieSB0aGUNCg0KICAgY29udHJv bCBwbGFuZSB3ZWxsIHByaW9yIHRvIHRoZSBzZWNyZXQga2V5IGV4cGlyYXRpb24gdGltZS4NCg0K DQoNCi0tIHdobyBrbm93cyBhYm91dCB0aGF0IGV4cGlyYXRpb24gdGltZSwgaXMgaXQgYm90aCB0 aGUga2V5IG1hbmFnZW1lbnQgc3lzdGVtDQphbmQgdGhlIHBhcnRpY2lwYXRpbmcgbm9kZXM/DQpJ ZiB0aGUgbm9kZXMga25vdyB0aGUgZXhwaXJhdGlvbiB0aW1lLCBzaG91bGQNCnRoZXkgcmVmdXNl IHRvIGRlY3J5cHQgYSBtZXNzYWdlIHdpdGggYW4gZXhwaXJlZCBrZXk/ICBUaGlzIGNoZWNrIG9m IGV4cGlyYXRpb24NCmlzIG5vdCB0aGUgU2VjdGlvbiA3LjUgb3IgNy42IHByb2NlZHVyZXMuDQoN ClllcywgYSBLTVMgY2FuIGFzc2lnbiBrZXlzIGZvciBtdWx0aXBsZSBrZXkgaW50ZXJ2YWxzLg0K DQoNCioqIFNlY3Rpb24gOS4gIEluIHRoZSBzcGlyaXQgb2YgaW5jbHVzaXZlIGxhbmd1YWdlLCBw bGVhc2Ugcy9BDQptYW4taW4tdGhlLW1pZGRsZS9BbiBvbi1wYXRoLWF0dGFja2VyLw0KDQpPa2F5 Lg0KDQoNCioqIFNlY3Rpb24gOS4NCiAgIEluIGFuIFNGQy1lbmFibGVkIGRvbWFpbiB3aGVyZSB0 aGUgYWJvdmUgYXR0YWNrcyBhcmUgcG9zc2libGUsICgxKQ0KICAgTlNIIGRhdGEgTVVTVCBiZSBp bnRlZ3JpdHktcHJvdGVjdGVkIGFuZCByZXBsYXktcHJvdGVjdGVkLCBhbmQgKDIpDQogICBwcml2 YWN5LXNlbnNpdGl2ZSBOU0ggbWV0YWRhdGEgTVVTVCBiZSBlbmNyeXB0ZWQgZm9yIGNvbmZpZGVu dGlhbGl0eQ0KICAgcHJlc2VydmF0aW9uIHB1cnBvc2VzLg0KDQpSZWxhdGVkIHRvIHRoZSBDT01N RU5UcyByYWlzZWQgYnkgTGFycyBhbmQgQWx2YXJvLg0KDQpJdOKAmXMgbXkgdW5kZXJzdGFuZGlu ZyB0aGF0IHRoZSBzZWN1cml0eSBwcm90ZWN0aW9ucyBoZXJlIGFyZSBvcHRpb25hbCBmb3IgdGhl DQpTRkMgYXJjaGl0ZWN0dXJlIOKAkyBpcyB0aGlzIGNvcnJlY3Q/ICBJZiBzbywgSSBkb27igJl0 IGZvbGxvdyB0aGUgYWJvdmUgZ3VpZGFuY2UuDQpXaXRoIHRoZSBleGNlcHRpb24gb2Yg4oCcZGF0 YSBjYXJyaWVkIGluIHRoZSBjb250ZXh0IGhlYWRlcnMgaGF2aW5nIHByaXZhY3kNCnNlbnNpdGl2 ZSBpbmZvcm1hdGlvbuKAnSwgYWxsIFNGQy1lbmFibGVkIGRvbWFpbnMgaGF2ZSB0aGUgcG90ZW50 aWFsIGZvciB0aGUNCmFib3ZlIGRlc2NyaWJlZCBhdHRhY2tzLiAgSXQgc2VlbXMgbGlrZSB0aGlz IGRvY3VtZW50IGlzIGhlbHBmdWxseSBtYWtpbmcNCmludGVncml0eSwgcmVwbGF5IGFuZCBlbmNy eXB0ZWQgbWV0YS1kYXRhIGEgcmVxdWlyZW1lbnQgZm9yIHRoZSBlbnRpcmUgU0ZDDQphcmNoaXRl Y3R1cmUgKHdpdGhvdXQgZXhwbGljaXRseSB1cGRhdGluZyBSRkM4MzAwKQ0KDQoqKiBTZWN0aW9u IDkuMQ0KICAgQW4gYWN0aXZlIGF0dGFja2VyIGNhbiBwb3RlbnRpYWxseSBtb2RpZnkgdGhlIEJh c2UgaGVhZGVyIChlLmcuLA0KICAgZGVjcmVtZW50IHRoZSBUVEwgc28gdGhlIG5leHQgU0ZGIGlu IHRoZSBTRlAgZGlzY2FyZHMgdGhlIE5TSA0KICAgcGFja2V0KS4gIEluIHRoZSBtZWFudGltZSwg YW4gYWN0aXZlIGF0dGFja2VyIGNhbiBhbHNvIGRyb3AgTlNIDQogICBwYWNrZXRzLg0KDQpUaGUg cGhyYXNlIOKAnEluIHRoZSBtZWFudGltZSDigKbigJ0gc3VnZ2VzdHMgdGhhdCB0aGVzZSB0d28g YWN0aXZlIGF0dGFja2VycyBhcmUNCmNvb3JkaW5hdGluZy4gIEJvdGggb2YgdGhlc2Ugc2VudGVu Y2VzIHNlZW0gdG8gYmUgZGVzY3JpYmluZyBpbmRlcGVuZGVudA0KYXR0YWNrZXJzLg0KDQpZZXMs IEkgd2lsbCByZW1vdmUgIkluIHRoZSBtZWFudGltZSIuDQoNCg0KPT1bIEVkaXRvcmlhbA0KKiog QWJzdHJhY3QuICBUeXBvLiAgVGhpcyBzZW50ZW5jZSBkb2VzbuKAmXQgcGFyc2UuDQpPTEQNCkFs c28sDQogICB0aGlzIHNwZWNpZmljYXRpb24gYWxsb3dzIHRvIGVuY3J5cHQgc2Vuc2l0aXZlIG1l dGFkYXRhIHRoYXQgaXMNCiAgIGNhcnJpZWQgaW4gdGhlIE5TSC4NCg0KTkVXDQpBbHNvLCB0aGlz IHNwZWNpZmljYXRpb24gYWxsb3dzIGZvciB0aGUgZW5jcnlwdGlvbiBvZiBzZW5zaXRpdmUgbWV0 YWRhdGEgIHRoYXQNCmlzIGNhcnJpZWQgaW4gdGhlIE5TSC4NCg0KKiogU2VjdGlvbiAxLiAgRWRp dG9yaWFsLiBzL3RvIGlzIGFuIGluZm9ybWF0aW9uL3RvIGlzIGluZm9ybWF0aW9uLw0KDQoqKiBT ZWN0aW9uIDEuICBFZGl0b3JpYWwuICBzL1RoaXMgc3BlY2lmaWNhdGlvbiBmaWxscyB0aGF0IGdh cC9UaGlzDQpzcGVjaWZpY2F0aW9uIGZpbGxzIHRoYXQgZ2FwIGZvciBTRkMvDQoNCioqIFNlY3Rp b24gMS4gIEVkaXRvcmlhbC4gIHMvVGhpcyBzcGVjaWZpY2F0aW9uIGxpbWl0cyB0aHVzIGFjY2Vz cy9UaGlzDQpzcGVjaWZpY2F0aW9uIGxpbWl0cyBhY2Nlc3MvDQoNCioqIFNlY3Rpb24gMy4gIEVk aXRvcmlhbC4gIHMvVGhlIE5TSCBhbGxvd3MgdG8gc2hhcmUvVGhlIE5TSCBzaGFyZXMvDQoNCioq IFNlY3Rpb24gNC4xLjIuICBFZGl0b3JpYWwuICBzL1NGRnMgYXJlIG5vdCB0aHVzIHByb3ZpZGVk L1NGRnMgYXJlIG5vdA0KcHJvdmlkZWQvDQoNCioqIFNlY3Rpb24gNC4yLiBFZGl0b3JpYWwuICBS ZWNvbW1lbmQgYmVpbmcgY2xlYXJlciBvbiB0aGUgc2VjdGlvbiDigJMgcy9UaGUNCmF1dGhlbnRp Y2F0ZWQgZW5jcnlwdGlvbiBhbGdvcml0aG0gZGVmaW5lZCBpbiBbUkZDNzUxOF0vIFRoZSBhdXRo ZW50aWNhdGVkDQplbmNyeXB0aW9uIGFsZ29yaXRobSBkZWZpbmVkIGluIFNlY3Rpb24gNS4yIG9m IFtSRkM3NTE4XS87IG9yIHlvdSBjb3VsZCBuYW1lDQp0aGUgYWxnb3JpdGhtIGRpcmVjdGx5IHdp dGggdGhlIHJlZmVyZW5jZS4NCg0KKiogU2VjdGlvbiA0LjQuIEVkaXRvcmlhbC4gcy9Eb2luZyBz byBhbGxvd3MgdG8gYWRkcmVzcyB0aGUgcHJvYmxlbS9Eb2luZyBzbw0KYWRkcmVzc2VzIHRoZSBw cm9ibGVtLw0KDQpUaGFua3MsIHdlIHdpbGwgZml4IGFsbCB0aGUgYWJvdmUgbml0cyBpbiB0aGUg bmV4dCByZXZpc2lvbi4NCg0KQ2hlZXJzLA0KLVRpcnUNCgpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0 IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29u ZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUg ZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMg YXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBs J2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4g TGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlv biwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0 ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBp dHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5m b3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJl IGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFp bHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0 IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== --_000_787AE7BB302AE849A7480A190F8B9330353BF404OPEXCAUBMA2corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1h cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5QcmZvcm1hdEhUTUxDYXINCgl7bXNvLXN0eWxlLW5hbWU6 IlByw6lmb3JtYXTDqSBIVE1MIENhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRNTCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQg NzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPkhpIFJvbWFuLCBhbGwsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkEgdmVyc2lvbiB0aGF0IGFkZHJlc3Nl cyB5b3VyIHJldmlldyBjYW4gYmUgdHJhY2tlZCBhdDoNCjxhIGhyZWY9Imh0dHBzOi8vdGlueXVy bC5jb20vbnNoLWludGVncml0eS1sYXRlc3QiPmh0dHBzOi8vdGlueXVybC5jb20vbnNoLWludGVn cml0eS1sYXRlc3Q8L2E+LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+UGxlYXNlIHNlZSBpbmxpbmUgZm9yIHR3byBtb3JlIGNvbW1lbnRz IGluIGFkZGl0aW9uIHRvIHRoZSBjbGFyaWZpY2F0aW9ucyBwcm92aWRlZCBieSBUaXJ1Lg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5D aGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPk1lZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4g bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+IHRpcnVtYWwgcmVkZHkgW21haWx0bzprb25kdGlyQGdtYWls LmNvbV0NCjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBtZXJjcmVkaSAxNCBqdWlsbGV0IDIw MjEgMTE6Mjg8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IFJvbWFuIERhbnlsaXcgJmx0O3JkZEBjZXJ0 Lm9yZyZndDs8YnI+DQo8Yj5DYyZuYnNwOzo8L2I+IFRoZSBJRVNHICZsdDtpZXNnQGlldGYub3Jn Jmd0OzsgZHJhZnQtaWV0Zi1zZmMtbnNoLWludGVncml0eUBpZXRmLm9yZzsgc2ZjLWNoYWlyc0Bp ZXRmLm9yZzsgc2ZjQGlldGYub3JnOyBncmVnaW1pcnNreUBnbWFpbC5jb208YnI+DQo8Yj5PYmpl dCZuYnNwOzo8L2I+IFJlOiBSb21hbiBEYW55bGl3J3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXNm Yy1uc2gtaW50ZWdyaXR5LTA2OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgUm9t YW4sPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QbGVhc2Ug c2VlIGlubGluZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBXZWQsIDE0IEp1bCAyMDIxIGF0IDAwOjMzLCBSb21hbiBEYW55bGl3IHZpYSBE YXRhdHJhY2tlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmciPm5vcmVwbHlA aWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJvbWFuIERhbnlsaXcgaGFzIGVudGVyZWQgdGhlIGZv bGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yPGJyPg0KZHJhZnQtaWV0Zi1zZmMtbnNoLWludGVn cml0eS0wNjogRGlzY3Vzczxicj4NCjxicj4NCldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAg dGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbDxicj4NCmVtYWlsIGFkZHJl c3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0 aGlzPGJyPg0KaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pPGJyPg0KPGJyPg0KPGJy Pg0KUGxlYXNlIHJlZmVyIHRvIDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3Rh dGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sPC9hPjxicj4N CmZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25z Ljxicj4NCjxicj4NCjxicj4NClRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3Qg cG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZTo8YnI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNmYy1uc2gtaW50ZWdyaXR5LyIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2Zj LW5zaC1pbnRlZ3JpdHkvPC9hPjxicj4NCjxicj4NCjxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08 YnI+DQpESVNDVVNTOjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+DQoqKiBTZWN0aW9uIDQu Ni4mbmJzcDsgVGhpcyBzZWN0aW9uIGV4cGxhaW5zIHRoYXQgYW4gdXBwZXIgTlNIIGNhbiBiZSBl bmNhcHN1bGF0ZWQgaW48YnI+DQphIGxvd2VyIE5TSCwgYW5kIHRoYXQg4oCcdGhlIFVwcGVyLU5T SCBpbmZvcm1hdGlvbiBpcyBjYXJyaWVkIGFsb25nIHRoZTxicj4NCmxvd2VyLWxldmVsIGNoYWlu IHdpdGhvdXQgbW9kaWZpY2F0aW9uLuKAnSZuYnNwOyBJIHJlYWQgdGhpcyB0byBtZWFuIHRoYXQg dGhlIHVwcGVyPGJyPg0KYW5kIGxvd2VyIE5TSCBjYW4gaW5kZXBlbmRlbnRseSBiZSBwcm90ZWN0 ZWQgd2l0aCBkaWZmZXJlbnQga2V5cy4mbmJzcDsgVGhlIHRleHQ8YnI+DQpldmVuIGhlbHBmdWxs eSBwb2ludHMgb3V0IHRoYXQg4oCcS2V5aW5nIG1hdGVyaWFsIHVzZWQgYXQgdGhlIHVwcGVyLWxl dmVsIGRvbWFpbjxicj4NClNIT1VMRCBOT1QgYmUgdGhlIHNhbWUgYXMgdGhlIG9uZSB1c2VkIGJ5 IGEgbG93ZXItbGV2ZWwgZG9tYWluLuKAnSZuYnNwOyBTdWNoIGE8YnI+DQpjb25zdHJ1Y3Qgc3Vn Z2VzdHMgdGhhdCB0aGVyZSBhcmUgbXVsdGlwbGUgTUFDL0VuY3J5cHRlZCBNZXRhZGF0YSBjb250 ZXh0PGJyPg0KaGVhZGVycywgb25lIGZvciB0aGUgdXBwZXIgYW5kIGFub3RoZXIgZm9yIHRoZSBs b3dlci4mbmJzcDsgSG93ZXZlciwgU2VjdGlvbiA3LjE8YnI+DQpsYXRlciBub3RlcyB0aGF0IOKA nE9ubHkgb25lIGluc3RhbmNlIG9mICZxdW90O01BQyBhbmQgRW5jcnlwdGVkIE1ldGFkYXRhJnF1 b3Q7IENvbnRleHQ8YnI+DQpIZWFkZXIgKFNlY3Rpb24gNSkgaXMgYWxsb3dlZC7igJ0mbmJzcDsg VGhpcyBzZWVtcyBsaWtlIGNvbmZsaWN0LiZuYnNwOyBXaGF0IGFtIEkgbWlzc2luZz88bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0 IG1lYW5zIG9ubHkgb25lIGluc3RhbmNlICZxdW90O01BQyBhbmQgRW5jcnlwdGVkIE1ldGFkYXRh JnF1b3Q7IENvbnRleHQgSGVhZGVyIChTZWN0aW9uIDUpIGlzIGFsbG93ZWQgaW4gYW4gTlNILWxl dmVsIChvbmUgaW5zdGFuY2UgaW4gdGhlJm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Y29sb3I6YmxhY2siPlVwcGVyLU5TSCBhbmQgYW5vdGhlciBpbiB0aGUgTG93ZXItTlNIKTwv c3Bhbj4sIHdlIHdpbGwgdXBkYXRlDQogdGV4dCBmb3IgYmV0dGVyIGNsYXJpdHkuJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxicj4NCioqIFNlY3Rpb24gNy4yLiZuYnNwOyBPbiBjb21wdXRpbmcgdGhlIEhNQUMgaW4gYW4g aW50ZWdyaXR5IG9ubHkgc2l0dWF0aW9uOjxicj4NCjxicj4NCi0tIFRoaXMgc2VjdGlvbiBkZWZp bmVzIHRoZSBNQUMgYXMg4oCcVCA9IEhNQUMtU0hBLTI1Ni0xMjgoTUFDX0tFWSwgQSnigJ0uIDxi cj4NClByZXZpb3VzbHksIEEgd2FzIGRlZmluZWQgYXMgdGhlIEFkZGl0aW9uYWwgQXV0aGVudGlj YXRlZCBEYXRhIChwZXIgU2VjdGlvbjxicj4NCjQuMikuJm5ic3A7IFNpbmNlIHRoaXMgaXNu4oCZ dCB0aGUgQUVBRCB1c2UgY2FzZSwgdGhlcmUgaXMgbm8gQS4gSXQgc2VlbXMgdGhhdCB0aGlzPGJy Pg0Kc2hvdWxkIGJlIHNvbWV0aGluZyBjbG9zZXIgdG86IOKAnFQgPSBITUFDLVNIQS0yNTYtMTI4 KE1BQ19LRVksICZsdDtwYXJ0IG9mIHRoZTxicj4NCnBhY2tldCB5b3Ugd2FudCB0byBoYXNoJmd0 OynigJ0uPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5Hb29kIGNhdGNoLCB3aWxsIHVwZGF0ZSB0byAmcXVvdDtUID0gSE1BQy1TSEEt MjU2LTEyOChNQUNfS0VZLCB0YXJnZXQgTlNIIGRhdGEpJnF1b3Q7PGJyPg0KJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQotLSBUaGUgdGV4dCB3b3VsZCBiZW5lZml0IGZyb20gYSBkZXNjcmlwdGlvbiBvbiBob3cgdG8g c2VyaWFsaXplIHRoZSBwYWNrZXQgZm9yPGJyPg0KaGFzaGluZy4mbmJzcDsgRm9yIGV4YW1wbGUs IEZpZ3VyZSA2IGFuZCA3IGFyZSBoZWxwZnVsIGxvZ2ljYWwgZGVzY3JpcHRpb25zIG9mIHRoZTxi cj4NCmludGVncml0eSBzY29wZS4mbmJzcDsgSG93ZXZlciwgdGhlIE1BQyBmaWVsZCBpdHNlbGYg aXMgZGVwaWN0ZWQgYXMgcGFydCBvZiB0aGUgd2hhdDxicj4NCnNob3VsZCBnZXQgaGFzaGVkLiZu YnNwOyBTaG91bGQgdGhhdCBmaWVsZCBiZSB6ZXJvZWQgb3V0PyBSZW1vdmVkID88bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcywg d2Ugd2lsbCB1cGRhdGUgdGV4dCBhcyBmb2xsb3dzOiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtjb2xvcjpibGFjayI+VGhlIE5TSCBpbXBvc2VyIHNldHMgdGhlIE1BQyBmaWVsZCB0 byB6ZXJvIGFuZCB0aGVuIGNvbXB1dGVzIHRoZSBtZXNzYWdlIGludGVncml0eSBmb3IgdGhlIHRh cmdldCBOU0ggZGF0YSAoZGVwZW5kaW5nIG9uIHRoZSBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBzY29w ZSBkaXNjdXNzZWQgaW4mbmJzcDtTZWN0aW9uIDUpIHVzaW5nIE1BQ19LRVkgYW5kDQogSE1BQyBh bGdvcml0aG0uJm5ic3A7SXQgaW5zZXJ0cyB0aGUgY29tcHV0ZWQgZGlnZXN0IGluIHRoZSBNQUMg ZmllbGQgaW4mbmJzcDt0aGUgJnF1b3Q7TUFDIGFuZCBFbmNyeXB0ZWQgTWV0YWRhdGEmcXVvdDsg Q29udGV4dCBIZWFkZXIuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQoqKiBTZWN0aW9uIDkuPGJyPg0K Jm5ic3A7ICZuYnNwO1RoZSBhdHRhY2tzIGRpc2N1c3NlZCBpbiBbSS1ELm5ndXllbi1zZmMtc2Vj dXJpdHktYXJjaGl0ZWN0dXJlXSBhcmU8YnI+DQombmJzcDsgJm5ic3A7aGFuZGxlZCBvd2luZyB0 byB0aGUgc29sdXRpb24gc3BlY2lmaWVkIGluIHRoaXMgZG9jdW1lbnQsIGV4Y2VwdCBmb3I8YnI+ DQombmJzcDsgJm5ic3A7YXR0YWNrcyBkcm9wcGluZyBwYWNrZXRzLjxicj4NCjxicj4NClRoZSBh Ym92ZSByZWZlcmVuY2UgaGlnaGxpZ2h0cyB0aGUgZm9sbG93aW5nIGF0dGFja2VycyDigJMg4oCc VGhlcmUgYXJlIG1hbnkgdHlwZXM8YnI+DQpvZiBjb21wcm9taXNlZCBzd2l0Y2hlcyBhdHRhY2s6 IHBhY2tldCBkcm9wcGluZywgcGFja2V0IGR1cGxpY2F0aW5nLCBwYWNrZXQ8YnI+DQptYW5pcHVs YXRpbmcsIGluY29ycmVjdCBmb3J3YXJkaW5nLCZuYnNwOyBlYXZlc2Ryb3BwaW5nLCB3ZWlnaHQg YWRqdXN0aW5nLDxicj4NCm1hbi1pbi10aGUtbWlkZGxlLCBzdGF0ZS1zcG9vZmluZywgY29udHJv bC1jaGFubmVsIGhpamFja2luZywgZXRjLuKAnSZuYnNwOyBQZXIgdGhlPGJyPg0Kc2VjdXJpdHkg c2VydmljZXMgaW4gdGhpcyBkb2N1bWVudCwgaXQgZG9lc27igJl0IHNlZW0gbGlrZSBhbGwgYXJl IG1pdGlnYXRlZCBieTxicj4NCnRoaXMgZHJhZnQgYXMgZGVzY3JpYmVkIGFib3ZlOjxicj4NCjxi cj4NCi0tIHBhY2tldCBkcm9wcGluZyA9IG5vdGVkIGFzIG5vdCBiZWluZyBoYW5kbGVkPGJyPg0K PGJyPg0KLS0gcGFja2V0IG1hbmlwdWxhdGluZywgZWF2ZXNkcm9wcGluZywgd2VpZ2h0IGFkanVz dGluZywgbWFuLWluIHRoZS1taWRkbGUsPGJyPg0Kc3RhdGUtc3Bvb2ZpbmcsIGFuZCBjb250cm9s LWNoYW5uZWwgaGlqYWNraW5nID0gYXBwZWFyIHRvIGJlIGhhbmRsZWQgaWYgYm90aDxicj4NCnNl Y3VyaXR5IHNlcnZpY2VzIGFyZSBhcHBsaWVkPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCi0tIHBhY2tldCBk dXBsaWNhdGluZyA9IHRoaXMgZHJhZnQgZG9lc27igJl0IG5vdCBwcm92aWRlIGEgc3RhbmRhcmRp emVkIGFwcHJvYWNoPGJyPg0KZm9yIG1pdGlnYXRpbmcgdGhpcyBpc3N1ZTxvOnA+PC9vOnA+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVwbGF5IGF0 dGFjayBpcyBkZXRlY3RlZCB1c2luZyB0aW1lc3RhbXAgYW5kIHJlY29yZGluZyBhIHVuaXF1ZSB2 YWx1ZSZuYnNwO3dpdGhpbiB0aGUgZGVsdGEgd2luZG93IGRlcml2ZWQgZnJvbSB0aGUgTlNIJm5i c3A7ZGF0YSBhbmQgcGFja2V0Jm5ic3A7KHNlZQ0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXNmYy1uc2gtaW50ZWdyaXR5I3NlY3Rpb24t Ny40Ij4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1z ZmMtbnNoLWludGVncml0eSNzZWN0aW9uLTcuNDwvYT4pLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQotLSBpbmNvcnJlY3Qg Zm9yd2FyZGluZyA9IGRvZXNu4oCZdCBhcHBlYXIgdG8gYmUgbWl0aWdhdGVkLjxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgdGhl IGNvbnRleHQgaGVhZGVycyBhcmUgZW5jcnlwdGVkLCBhbiBhdHRhY2tlciByZWNlaXZpbmcgZm9y d2FyZGVkIE5TSCBmcm9tIGFuIGNvbXByb21pc2VkIHN3aXRjaCB3aWxsIG5vdCBiZSBhYmxlIHRv IGRlY3J5cHQgdGhlIGNvbnRleHQgaGVhZGVycy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5bTWVkXSBpbmNvcnJlY3QgZm9yd2FyZGlu ZyBpcyBwcmV2ZW50ZWQgYXMgYW55IG1hbmlwdWxhdGlvbiB0byB0aGUgc2VydmljZSBpbmRleCBp cyBkZXRlY3RlZCBieSBTRnMuIFRoaXMgaXMgYWxyZWFkeSBkaXNjdXNzZWQgaW4gdGhlIHRleHQ6 DQo8L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHByZT4mbmJzcDsmbmJzcDsgQWxzbywgaWYgU0ZGcyBhcmUgbm90IGludm9sdmVk IGluIHRoZSBpbnRlZ3JpdHkgY2hlY2tzLCBhPG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgbWlzYmVoYXZpbmcgU0ZGIHdoaWNoIGRl Y3JlbWVudHMgU0kgd2hpbGUgdGhpcyBzaG91bGQgYmUgZG9uZSBieSBhbjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgU0Yg KFNGIGJ5cGFzcyBhdHRhY2spIHdpbGwgYmUgZGV0ZWN0ZWQgYnkgYW4gdXBzdHJlYW0gU0YgYmVj YXVzZSB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7IGludGVncml0eSBjaGVjayB3aWxsIGZhaWwuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPGJyPg0KQ09NTUVOVDo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KKiog U2VjdGlvbiAxLjxicj4NCiZuYnNwOyAmbmJzcDtUaHVzLCB0aGUgTlNIPGJyPg0KJm5ic3A7ICZu YnNwO2RvZXMgbm90IGhhdmUgdG8gcmVseSB1cG9uIGFuIHVuZGVybHlpbmcgdHJhbnNwb3J0IGVu Y2Fwc3VsYXRpb24gZm9yPGJyPg0KJm5ic3A7ICZuYnNwO3NlY3VyaXR5IGFuZCBjb25maWRlbnRp YWxpdHkuPGJyPg0KPGJyPg0KSXNu4oCZdCBjb25maWRlbnRpYWxpdHkganVzdCBhIHN1YnNldCBv ZiB0aGUgcHJvdmlkZWQgc2VjdXJpdHkgcHJvcGVydGllcywgb3IgaXM8YnI+DQpzb21ldGhpbmcg ZWxzZSBpbnRlbmRlZD8mbmJzcDsgUmVjb21tZW5kIHMvZm9yIHNlY3VyaXR5IGFuZCBjb25maWRl bnRpYWxpdHkvZm9yPGJyPg0Kc2VjdXJpdHkvPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMsIEkgd2lsbCB1cGRhdGUgdGhlIHRl eHQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNt IDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxicj4NCioqIFNlY3Rpb24gMi4mbmJzcDsgUGVyIOKAnEtleSBJZGVudGlm aWVyOiZuYnNwOyBJcyB1c2VkIHRvIGlkZW50aWZ5IGFuZCBkZWxpdmVyIGtleXMgdG88YnI+DQph dXRob3JpemVkIGVudGl0aWVzLiZuYnNwOyBTZWUsIGZvciBleGFtcGxlLCAna2lkJyB1c2FnZSBp biBbUkZDNzYzNV3igJ0uIEhvdyBkb2VzIGE8YnI+DQprZXkgaWRlbnRpZmllciDigJxkZWxpdmVy eSBrZXlz4oCdPyZuYnNwOyBEb2VzbuKAmXQgYW5vdGhlciBwcm90b2NvbCBwcm92aWRlIHRoZSBk ZWxpdmVyeTxicj4NCnVzaW5nIHRoZSBraWQgYXMgYW4gaWRlbnRpZmllcj88bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcywga2lk IGlzIHR5cGljYWxseSB1c2VkIGFzIGFuIGlkZW50aWZpZXImbmJzcDtieSBhIEtNUyBwcm90b2Nv bC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KKiogU2VjdGlvbiA3LjIuJm5ic3A7IEhvdyBkb2VzIG9uZSBzZXJp YWxpemUgdGhlIHBhY2tldCBkYXRhIHRvIGNvbnN0cnVjdCBBPyZuYnNwOyBGaWd1cmU8YnI+DQo3 IGlzIHRoZSBjbG9zZXN0IGd1aWRhbmNlIGJ1dCBpdCBpbmNsdWRlcyB0aGUgTUFDIGl0c2VsZi48 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoZSBNQUMgZmllbGQgaXMgc2V0IHRvIHplcm8gYmVmb3JlIGNvbXB1dGluZyB0aGUgPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPg0KbWVzc2FnZSBpbnRlZ3Jp dHksIHdlIHdpbGwgdXBkYXRlIHRoZSB0ZXh0LiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KKiogU2Vj dGlvbiA3LjQuPGJyPg0KJm5ic3A7ICZuYnNwO+KApiBsZWdpdGltYXRlIGR1cGxpY2F0ZSBwYWNr ZXRzIHdpbGwgYmU8YnI+DQombmJzcDsgJm5ic3A7dGFnZ2VkIGJ5IE5TSC1hd2FyZSBub2RlcyBp bnZvbHZlZCBpbiB0aGF0IHNlZ21lbnQgYXMgcmVwbGF5IHBhY2tldHM8YnI+DQombmJzcDsgJm5i c3A7dW5sZXNzIHN1ZmZpY2llbnQgZW50cm9weSBpcyBhZGRlZCB0byB0aGUgZHVwbGljYXRlIHBh Y2tldC48YnI+DQo8YnI+DQpXaGF0IGlzIHRoZSBwcmVzY3JpYmVkIG1lY2hhbmlzbSB0byBhZGQg ZW50cm9weT8mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlNlcXVlbmNlIG51bWJlcnMgY2FuIGJlIHVzZWQgYXMgZGlzY3Vz c2VkIGluIHRoZSBub3RlIGluIFNlY3Rpb24gNy40Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+W01lZF0gdGhpcyBjYW4gYWxzbyBiZSBo YW5kbGVkIGJ5IFNGcyB0aGVtc2VsdmVzLiBBZGRlZCB0aGlzIG5vdGU6DQo8bzpwPjwvbzpwPjwv c3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwcmU+4oCcSG93IHN1Y2g8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgYW4gZW50cm9weSBpcyBhZGRlZCBpcyBp bXBsZW1lbnRhdGlvbi1zcGVjaWZpYy7igJ08bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KKiogU2VjdGlvbiA3LjU8 YnI+DQombmJzcDsgJm5ic3A7V2hlbiBhbiBTRkMgZGF0YSBwbGFuZSBlbGVtZW50IHJlY2VpdmVz IGFuIE5TSCBwYWNrZXQsIGl0IE1VU1QgZmlyc3Q8YnI+DQombmJzcDsgJm5ic3A7ZW5zdXJlIHRo YXQgYSAmcXVvdDtNQUMgYW5kIEVuY3J5cHRlZCBNZXRhZGF0YSZxdW90OyBDb250ZXh0IEhlYWRl ciBpczxicj4NCiZuYnNwOyAmbmJzcDtpbmNsdWRlZC48YnI+DQo8YnI+DQpJIHdhcyB1bmRlciB0 aGUgaW1wcmVzc2lvbiB0aGF0IHRoZSBzZWN1cml0eSBwcm90ZWN0aW9ucyBzcGVjaWZpZWQgaW4g dGhpczxicj4NCmRvY3VtZW50IHdlcmUgb3B0aW9uYWwgaW4gdGhlIG92ZXJhbGwgU0ZDIGFyY2hp dGVjdHVyZS4mbmJzcDsgSXMgdGhlcmUgc29tZSBjYXZlYXQ8YnI+DQp0byBhZGQgdG8gdGhpcyBz ZWN0aW9uIHRvIHJlbWluZGVyIHJlYWRlcnM/Jm5ic3A7IFBlcmhhcHMsJm5ic3A7IOKAnFdoZW4g YW4gU0ZDIGRhdGEgcGxhbjxicj4NCmVsZW1lbnQgY29uZm9ybXMgdG8gdGhpcyBzcGVjaWZpY2F0 aW9uLCBpdCBNVVNUIGZpcnN0IOKApuKAnTxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzLCB3ZSB3aWxsIHVwZGF0ZS4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGJyPg0KKiogU2VjdGlvbiA3LjUgYW5kIDcuNi4mbmJzcDsgV2hhdCBpcyB0aGUgZXJyb3Ig cHJvY2Vzc2luZyBmb3IgcmVjZWl2aW5nIGEgcGFja2V0PGJyPg0Kd2l0aCBhbiB1bmtub3duIGtl eSBpZGVudGlmaWVyPzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+QW4gZXJyb3Igc2hvdWxkIGJlIGxvZ2dlZCwgd2Ugd2lsbCB1cGRh dGUgdGhlIGRyYWZ0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPltNZWRdIFVwZGF0ZWQgdGhlIHRleHQgdG8gY292ZXIgYm90aCB1bmtub3duIGFu ZCBpbnZhbGlkIGtpZHMuDQo8L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQoqKiBTZWN0aW9uIDkuIFNlY3Rpb24gOS4mbmJzcDsgQ2FuIHlvdSBmdXJ0aGVyIGNsYXJpZnkg aG93IGlzIHRoZSByZWFkZXIgc3VwcG9zZWQgdG88YnI+DQppbnRlcnByZXQgdGhlIGd1aWRhbmNl IGluIFJGQzQxMDcgd2hpY2ggZnJhbWVzIGl0cyBzY29wZSBhcyBndWlkZWxpbmVzIGFzIHRvIGJl PGJyPg0K4oCcLi4uIHVzZVtkXSBieSBJRVRGIHdvcmtpbmcgZ3JvdXBzIGFuZCBwcm90b2NvbCBh dXRob3JzIHdobyBhcmUgZGV0ZXJtaW5pbmc8YnI+DQp3aGV0aGVyIHRvIG1hbmRhdGUgYXV0b21h dGVkIGtleSZuYnNwOyAmbmJzcDsgbWFuYWdlbWVudCBhbmQgd2hldGhlciBtYW51YWwga2V5PGJy Pg0KbWFuYWdlbWVudCBpcyBhY2NlcHRhYmxlLiZuYnNwOyBJbmZvcm1lZCBqdWRnbWVudCBpcyBu ZWVkZWQu4oCdJm5ic3A7IERvZXMgdGhpcyBkb2N1bWVudDxicj4NCnRha2UgYSBwb3NpdGlvbiBv biBhdXRvbWF0ZWQgdnMuIG1hbnVhbCBrZXkgbWFuYWdlbWVudD88YnI+DQo8YnI+DQoqKiBTZWN0 aW9uIDkuJm5ic3A7IFBlciDigJxUaGUgc2VjcmV0IGtleSAoSykgbXVzdCBoYXZlIGFuIGV4cGly YXRpb24gdGltZSBhc3NpZ25lZCDigKbigJ06PGJyPg0KPGJyPg0KKEkgc3VzcGVjdCBtYW55IG9m IHRoZXNlIGlzc3VlcyBhcmUgb3V0IG9mIHNjb3BlIOKApik8YnI+DQo8YnI+DQotLSB3aG8gYXNz aWducyB0aGF0IGV4cGlyYXRpb24gdGltZSAodGhlIGtleSBtYW5hZ2VtZW50IHN5c3RlbSk/PG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5ZZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+W01lZF0gQW5kIGNvbW11bmljYXRlZCBieSB0aGUgY29udHJvbCBwbGFuZS4gUGxlYXNlIHJl ZmVyIHRvIHRoaXMgcGFydCBpbiB0aGUgZHJhZnQ6PG86cD48L286cD48L3NwYW4+PC9pPjwvYj48 L3A+DQo8cHJlPlRoZSBzZWNyZXQga2V5IChLKSBtdXN0IGhhdmUgYW48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsmbmJzcDsgZXhwaXJhdGlvbiB0aW1lIGFzc2lnbmVkIGFzIHRoZSBsYXRl c3QgcG9pbnQgaW4gdGltZSBiZWZvcmUgd2hpY2ggdGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7Jm5ic3A7IGtleSBtYXkgYmUgdXNlZCBmb3IgaW50ZWdyaXR5IHByb3RlY3Rpb24gb2Yg TlNIIGRhdGEgYW5kIGVuY3J5cHRpb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz cDsgb2YgQ29udGV4dCBIZWFkZXJzLiZuYnNwOyBQcmlvciB0byB0aGUgZXhwaXJhdGlvbiBvZiB0 aGUgc2VjcmV0IGtleSwgYWxsPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHBh cnRpY2lwYXRpbmcgTlNILWF3YXJlIG5vZGVzIFNIT1VMRCBoYXZlIHRoZSBjb250cm9sIHBsYW5l PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGRpc3RyaWJ1dGUgYSBuZXcga2V5 IGlkZW50aWZpZXIgYW5kIGFzc29jaWF0ZWQga2V5aW5nIG1hdGVyaWFsIHNvPG86cD48L286cD48 L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHRoYXQgd2hlbiB0aGUgc2VjcmV0IGtleSBpcyBleHBp cmVkLCB0aG9zZSBub2RlcyBhcmUgcHJlcGFyZWQgd2l0aDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyB0aGUgbmV3IHNlY3JldCBrZXkuJm5ic3A7IFRoaXMgYWxsb3dzIHRoZSBO U0ggaW1wb3NlciB0byBzd2l0Y2ggdG8gdGhlIG5ldzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu YnNwOyZuYnNwOyBrZXkgaWRlbnRpZmllciBhcyBzb29uIGFzIG5lY2Vzc2FyeS4mbmJzcDsgSXQg aXMgUkVDT01NRU5ERUQgdGhhdCB0aGUgbmV4dDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OyZuYnNwOyBrZXkgaWRlbnRpZmllciBhbmQgYXNzb2NpYXRlZCBrZXlpbmcgbWF0ZXJpYWwgYmUg ZGlzdHJpYnV0ZWQgYnkgdGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGNv bnRyb2wgcGxhbmUgd2VsbCBwcmlvciB0byB0aGUgc2VjcmV0IGtleSBleHBpcmF0aW9uIHRpbWUu PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBj bSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NCi0tIHdobyBrbm93cyBhYm91dCB0aGF0IGV4cGlyYXRpb24gdGltZSwg aXMgaXQgYm90aCB0aGUga2V5IG1hbmFnZW1lbnQgc3lzdGVtPGJyPg0KYW5kIHRoZSBwYXJ0aWNp cGF0aW5nIG5vZGVzPyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHRoZSBub2RlcyBrbm93IHRoZSBleHBpcmF0 aW9uIHRpbWUsIHNob3VsZDxicj4NCnRoZXkgcmVmdXNlIHRvIGRlY3J5cHQgYSBtZXNzYWdlIHdp dGggYW4gZXhwaXJlZCBrZXk/Jm5ic3A7IFRoaXMgY2hlY2sgb2YgZXhwaXJhdGlvbjxicj4NCmlz IG5vdCB0aGUgU2VjdGlvbiA3LjUgb3IgNy42IHByb2NlZHVyZXMuPG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMsIGEgS01TIGNh biBhc3NpZ24ga2V5cyBmb3IgbXVsdGlwbGUga2V5IGludGVydmFscy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KKiogU2Vj dGlvbiA5LiZuYnNwOyBJbiB0aGUgc3Bpcml0IG9mIGluY2x1c2l2ZSBsYW5ndWFnZSwgcGxlYXNl IHMvQTxicj4NCm1hbi1pbi10aGUtbWlkZGxlL0FuIG9uLXBhdGgtYXR0YWNrZXIvPG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Pa2F5 LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnI+DQoqKiBTZWN0aW9uIDkuPGJyPg0KJm5ic3A7ICZuYnNwO0luIGFuIFNG Qy1lbmFibGVkIGRvbWFpbiB3aGVyZSB0aGUgYWJvdmUgYXR0YWNrcyBhcmUgcG9zc2libGUsICgx KTxicj4NCiZuYnNwOyAmbmJzcDtOU0ggZGF0YSBNVVNUIGJlIGludGVncml0eS1wcm90ZWN0ZWQg YW5kIHJlcGxheS1wcm90ZWN0ZWQsIGFuZCAoMik8YnI+DQombmJzcDsgJm5ic3A7cHJpdmFjeS1z ZW5zaXRpdmUgTlNIIG1ldGFkYXRhIE1VU1QgYmUgZW5jcnlwdGVkIGZvciBjb25maWRlbnRpYWxp dHk8YnI+DQombmJzcDsgJm5ic3A7cHJlc2VydmF0aW9uIHB1cnBvc2VzLjxicj4NCjxicj4NClJl bGF0ZWQgdG8gdGhlIENPTU1FTlRzIHJhaXNlZCBieSBMYXJzIGFuZCBBbHZhcm8uPGJyPg0KPGJy Pg0KSXTigJlzIG15IHVuZGVyc3RhbmRpbmcgdGhhdCB0aGUgc2VjdXJpdHkgcHJvdGVjdGlvbnMg aGVyZSBhcmUgb3B0aW9uYWwgZm9yIHRoZTxicj4NClNGQyBhcmNoaXRlY3R1cmUg4oCTIGlzIHRo aXMgY29ycmVjdD8mbmJzcDsgSWYgc28sIEkgZG9u4oCZdCBmb2xsb3cgdGhlIGFib3ZlIGd1aWRh bmNlLiA8YnI+DQpXaXRoIHRoZSBleGNlcHRpb24gb2Yg4oCcZGF0YSBjYXJyaWVkIGluIHRoZSBj b250ZXh0IGhlYWRlcnMgaGF2aW5nIHByaXZhY3k8YnI+DQpzZW5zaXRpdmUgaW5mb3JtYXRpb27i gJ0sIGFsbCBTRkMtZW5hYmxlZCBkb21haW5zIGhhdmUgdGhlIHBvdGVudGlhbCBmb3IgdGhlPGJy Pg0KYWJvdmUgZGVzY3JpYmVkIGF0dGFja3MuJm5ic3A7IEl0IHNlZW1zIGxpa2UgdGhpcyBkb2N1 bWVudCBpcyBoZWxwZnVsbHkgbWFraW5nPGJyPg0KaW50ZWdyaXR5LCByZXBsYXkgYW5kIGVuY3J5 cHRlZCBtZXRhLWRhdGEgYSByZXF1aXJlbWVudCBmb3IgdGhlIGVudGlyZSBTRkM8YnI+DQphcmNo aXRlY3R1cmUgKHdpdGhvdXQgZXhwbGljaXRseSB1cGRhdGluZyBSRkM4MzAwKTxicj4NCjxicj4N CioqIFNlY3Rpb24gOS4xPGJyPg0KJm5ic3A7ICZuYnNwO0FuIGFjdGl2ZSBhdHRhY2tlciBjYW4g cG90ZW50aWFsbHkgbW9kaWZ5IHRoZSBCYXNlIGhlYWRlciAoZS5nLiw8YnI+DQombmJzcDsgJm5i c3A7ZGVjcmVtZW50IHRoZSBUVEwgc28gdGhlIG5leHQgU0ZGIGluIHRoZSBTRlAgZGlzY2FyZHMg dGhlIE5TSDxicj4NCiZuYnNwOyAmbmJzcDtwYWNrZXQpLiZuYnNwOyBJbiB0aGUgbWVhbnRpbWUs IGFuIGFjdGl2ZSBhdHRhY2tlciBjYW4gYWxzbyBkcm9wIE5TSDxicj4NCiZuYnNwOyAmbmJzcDtw YWNrZXRzLjxicj4NCjxicj4NClRoZSBwaHJhc2Ug4oCcSW4gdGhlIG1lYW50aW1lIOKApuKAnSBz dWdnZXN0cyB0aGF0IHRoZXNlIHR3byBhY3RpdmUgYXR0YWNrZXJzIGFyZTxicj4NCmNvb3JkaW5h dGluZy4mbmJzcDsgQm90aCBvZiB0aGVzZSBzZW50ZW5jZXMgc2VlbSB0byBiZSBkZXNjcmliaW5n IGluZGVwZW5kZW50PGJyPg0KYXR0YWNrZXJzLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzLCBJIHdpbGwgcmVtb3ZlICZxdW90 O0luIHRoZSBtZWFudGltZSZxdW90Oy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPT1bIEVkaXRvcmlhbDxicj4N CioqIEFic3RyYWN0LiZuYnNwOyBUeXBvLiZuYnNwOyBUaGlzIHNlbnRlbmNlIGRvZXNu4oCZdCBw YXJzZS48YnI+DQpPTEQ8YnI+DQpBbHNvLDxicj4NCiZuYnNwOyAmbmJzcDt0aGlzIHNwZWNpZmlj YXRpb24gYWxsb3dzIHRvIGVuY3J5cHQgc2Vuc2l0aXZlIG1ldGFkYXRhIHRoYXQgaXM8YnI+DQom bmJzcDsgJm5ic3A7Y2FycmllZCBpbiB0aGUgTlNILjxicj4NCjxicj4NCk5FVzxicj4NCkFsc28s IHRoaXMgc3BlY2lmaWNhdGlvbiBhbGxvd3MgZm9yIHRoZSBlbmNyeXB0aW9uIG9mIHNlbnNpdGl2 ZSBtZXRhZGF0YSZuYnNwOyB0aGF0PGJyPg0KaXMgY2FycmllZCBpbiB0aGUgTlNILjxicj4NCjxi cj4NCioqIFNlY3Rpb24gMS4mbmJzcDsgRWRpdG9yaWFsLiBzL3RvIGlzIGFuIGluZm9ybWF0aW9u L3RvIGlzIGluZm9ybWF0aW9uLzxicj4NCjxicj4NCioqIFNlY3Rpb24gMS4mbmJzcDsgRWRpdG9y aWFsLiZuYnNwOyBzL1RoaXMgc3BlY2lmaWNhdGlvbiBmaWxscyB0aGF0IGdhcC9UaGlzPGJyPg0K c3BlY2lmaWNhdGlvbiBmaWxscyB0aGF0IGdhcCBmb3IgU0ZDLzxicj4NCjxicj4NCioqIFNlY3Rp b24gMS4mbmJzcDsgRWRpdG9yaWFsLiZuYnNwOyBzL1RoaXMgc3BlY2lmaWNhdGlvbiBsaW1pdHMg dGh1cyBhY2Nlc3MvVGhpczxicj4NCnNwZWNpZmljYXRpb24gbGltaXRzIGFjY2Vzcy88YnI+DQo8 YnI+DQoqKiBTZWN0aW9uIDMuJm5ic3A7IEVkaXRvcmlhbC4mbmJzcDsgcy9UaGUgTlNIIGFsbG93 cyB0byBzaGFyZS9UaGUgTlNIIHNoYXJlcy88YnI+DQo8YnI+DQoqKiBTZWN0aW9uIDQuMS4yLiZu YnNwOyBFZGl0b3JpYWwuJm5ic3A7IHMvU0ZGcyBhcmUgbm90IHRodXMgcHJvdmlkZWQvU0ZGcyBh cmUgbm90PGJyPg0KcHJvdmlkZWQvPGJyPg0KPGJyPg0KKiogU2VjdGlvbiA0LjIuIEVkaXRvcmlh bC4mbmJzcDsgUmVjb21tZW5kIGJlaW5nIGNsZWFyZXIgb24gdGhlIHNlY3Rpb24g4oCTIHMvVGhl PGJyPg0KYXV0aGVudGljYXRlZCBlbmNyeXB0aW9uIGFsZ29yaXRobSBkZWZpbmVkIGluIFtSRkM3 NTE4XS8gVGhlIGF1dGhlbnRpY2F0ZWQ8YnI+DQplbmNyeXB0aW9uIGFsZ29yaXRobSBkZWZpbmVk IGluIFNlY3Rpb24gNS4yIG9mIFtSRkM3NTE4XS87IG9yIHlvdSBjb3VsZCBuYW1lPGJyPg0KdGhl IGFsZ29yaXRobSBkaXJlY3RseSB3aXRoIHRoZSByZWZlcmVuY2UuPGJyPg0KPGJyPg0KKiogU2Vj dGlvbiA0LjQuIEVkaXRvcmlhbC4gcy9Eb2luZyBzbyBhbGxvd3MgdG8gYWRkcmVzcyB0aGUgcHJv YmxlbS9Eb2luZyBzbzxicj4NCmFkZHJlc3NlcyB0aGUgcHJvYmxlbS88bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcywgd2Ug d2lsbCBmaXggYWxsIHRoZSBhYm92ZSBuaXRzIGluIHRoZSBuZXh0IHJldmlzaW9uLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGVlcnMsPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tVGlydTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxQ UkU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250 ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQg bmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNh bnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIs IHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNp IHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50 IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNh YmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBN ZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZp ZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBi eSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0 aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVy cm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5k IGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90 IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3Ig ZmFsc2lmaWVkLgpUaGFuayB5b3UuCjwvUFJFPjwvYm9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B9330353BF404OPEXCAUBMA2corp_-- From nobody Wed Jul 14 21:58:00 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 909663A1BCB; Wed, 14 Jul 2021 21:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.796 X-Spam-Level: X-Spam-Status: No, score=-2.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPRZdKKbcF7M; Wed, 14 Jul 2021 21:57:52 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (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 C2E323A1BCA; Wed, 14 Jul 2021 21:57:51 -0700 (PDT) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfedar24.francetelecom.fr (ESMTP service) with ESMTPS id 4GQMZ41D0gz5w5V; Thu, 15 Jul 2021 06:57:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1626325068; bh=4+ROko9fNNd0fy61k9ieSUsZZ4tpjdZd7ikjLXDg/Uo=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=GRdeUBQH8lSYCTnfoFWzQI3a73TjyLjDgsL+wiFR1g+JfwbYDVtaL8DNMcCk4BtZm q+dxR0gwqD/FNqm6Zzzl515klVr2aAWBdwn00Oze0LEfBT6HmfzsWLT4/fQH/86/O4 5NOjhMEX7iA5OxGV/vQZ5/K7sCKd99WiVjGsGnWTO7HxWMbGDqClXKnQaiEdgIoTXn M4JR/ZzrItMubJCHIufGJHSVvpGGlmD3IMX8DmI/WZK9iTExfBDHHm50i6XmUKIOtD RtDz8WbKa72UlgXcARK3PJDdYGr/sfzorHh/TVPhN6g2ZUbVPLJUR3gNGwswPlJOKA ejs4p+BRA6hTA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfedar06.francetelecom.fr (ESMTP service) with ESMTPS id 4GQMZ36sJQz3wbN; Thu, 15 Jul 2021 06:57:47 +0200 (CEST) From: To: "Eric Vyncke (evyncke)" , The IESG CC: "draft-ietf-sfc-nsh-integrity@ietf.org" , "sfc-chairs@ietf.org" , "sfc@ietf.org" , "gregimirsky@gmail.com" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXNmYy1uc2gt?= =?utf-8?Q?integrity-06:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHXd+EWUzPhovDiy06QVDjdApotHKtBE6GQgAFgQoCAAQWqEA== Date: Thu, 15 Jul 2021 04:57:46 +0000 Message-ID: <30015_1626325068_60EFC04B_30015_200_1_787AE7BB302AE849A7480A190F8B9330353BF421@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162617866082.13596.2398814614966286542@ietfa.amsl.com> <15473_1626195281_60EDC551_15473_51_1_787AE7BB302AE849A7480A190F8B9330353BE8EC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <94FF1F19-7004-42C5-8560-C99A2FEEF71A@cisco.com> In-Reply-To: <94FF1F19-7004-42C5-8560-C99A2FEEF71A@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-sfc-n?= =?utf-8?q?sh-integrity-06=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 04:57:58 -0000 SGkgRXJpYywNCg0KQSB2ZXJzaW9uIHRoYXQgaW50ZWdyYXRlcyB5b3VyIHJldmlldyBjYW4gYmUg dHJhY2tlZCBhdDogaHR0cHM6Ly90aW55dXJsLmNvbS9uc2gtaW50ZWdyaXR5LWxhdGVzdC4gDQoN ClBsZWFzZSBzZWUgaW5saW5lIGZvciBtb3JlIGNvbnRleHQuIA0KDQpDaGVlcnMsDQpNZWQNCg0K PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogRXJpYyBWeW5ja2UgKGV2eW5j a2UpIFttYWlsdG86ZXZ5bmNrZUBjaXNjby5jb21dDQo+IEVudm95w6nCoDogbWVyY3JlZGkgMTQg anVpbGxldCAyMDIxIDEzOjEyDQo+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIElOTk9WL05FVCA8 bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IFRoZQ0KPiBJRVNHIDxpZXNnQGlldGYub3Jn Pg0KPiBDY8KgOiBkcmFmdC1pZXRmLXNmYy1uc2gtaW50ZWdyaXR5QGlldGYub3JnOyBzZmMtY2hh aXJzQGlldGYub3JnOw0KPiBzZmNAaWV0Zi5vcmc7IGdyZWdpbWlyc2t5QGdtYWlsLmNvbQ0KPiBP YmpldMKgOiBSZTogw4lyaWMgVnluY2tlJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXNmYy1uc2gt aW50ZWdyaXR5LQ0KPiAwNjogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gDQo+IEhlbGxv IE1lZCwNCj4gDQo+IFRoYW5rIHlvdSBmb3IgeW91ciBwcm9tcHQgcmVwbHkuDQo+IA0KPiBTZWUg YmVsb3cgZm9yIEVWPiwgc3RpbGwgaG9sZGluZyBteSBESVNDVVNTIG1haW5seSBhcm91bmQgdGhl ICJob3cNCj4gdG8gY29tcHV0ZSB0aGUgTUFDIGFzIGl0IGluY2x1ZGVzIHRoZSBNQUMgZmllbGQg aXRzZWxmIg0KDQpbTWVkXSBVcGRhdGVkIHRoZSB0ZXh0IHRvOg0KDQogICBUaGUgTlNIIGltcG9z ZXIgc2V0cyB0aGUgTUFDIGZpZWxkIHRvIHplcm8gYW5kIHRoZW4gY29tcHV0ZXMgdGhlDQogICBt ZXNzYWdlIGludGVncml0eSBmb3IgdGhlIHRhcmdldCBOU0ggZGF0YSAoZGVwZW5kaW5nIG9uIHRo ZSBpbnRlZ3JpdHkNCiAgIHByb3RlY3Rpb24gc2NvcGUgZGlzY3Vzc2VkIGluIFNlY3Rpb24gNSkg dXNpbmcgTUFDX0tFWSBhbmQgSE1BQw0KICAgYWxnb3JpdGhtLg0KDQo+IA0KPiBSZWdhcmRzDQo+ IA0KPiAtw6lyaWMNCj4gDQo+IO+7vy0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 ICJtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIiA8bW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbT4NCj4gRGF0ZTogVHVlc2RheSwgMTMgSnVseSAyMDIxIGF0IDE4OjU0DQo+IFRvOiBFcmlj IFZ5bmNrZSA8ZXZ5bmNrZUBjaXNjby5jb20+LCBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCj4g Q2M6ICJkcmFmdC1pZXRmLXNmYy1uc2gtaW50ZWdyaXR5QGlldGYub3JnIiA8ZHJhZnQtaWV0Zi1z ZmMtbnNoLQ0KPiBpbnRlZ3JpdHlAaWV0Zi5vcmc+LCAic2ZjLWNoYWlyc0BpZXRmLm9yZyIgPHNm Yy1jaGFpcnNAaWV0Zi5vcmc+LA0KPiAic2ZjQGlldGYub3JnIiA8c2ZjQGlldGYub3JnPiwgImdy ZWdpbWlyc2t5QGdtYWlsLmNvbSINCj4gPGdyZWdpbWlyc2t5QGdtYWlsLmNvbT4NCj4gU3ViamVj dDogUkU6IMOJcmljIFZ5bmNrZSdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1zZmMtbnNoLWludGVn cml0eS0NCj4gMDY6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+IA0KPiAgICAgSGkgRXJp YywNCj4gDQo+ICAgICBUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuDQo+IA0KPiAgICAgUGxlYXNl IHNlZSBpbmxpbmUuDQo+IA0KPiAgICAgQ2hlZXJzLA0KPiAgICAgTWVkDQo+IA0KPiAgICAgPiAt LS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gICAgID4gRGUgOiDDiXJpYyBWeW5ja2Ugdmlh IERhdGF0cmFja2VyIFttYWlsdG86bm9yZXBseUBpZXRmLm9yZ10NCj4gICAgID4gRW52b3nDqSA6 IG1hcmRpIDEzIGp1aWxsZXQgMjAyMSAxNDoxOA0KPiAgICAgPiDDgCA6IFRoZSBJRVNHIDxpZXNn QGlldGYub3JnPg0KPiAgICAgPiBDYyA6IGRyYWZ0LWlldGYtc2ZjLW5zaC1pbnRlZ3JpdHlAaWV0 Zi5vcmc7IHNmYy0NCj4gY2hhaXJzQGlldGYub3JnOw0KPiAgICAgPiBzZmNAaWV0Zi5vcmc7IGdy ZWdpbWlyc2t5QGdtYWlsLmNvbTsgZ3JlZ2ltaXJza3lAZ21haWwuY29tDQo+ICAgICA+IE9iamV0 IDogw4lyaWMgVnluY2tlJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXNmYy1uc2gtaW50ZWdyaXR5 LQ0KPiAwNjoNCj4gICAgID4gKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gICAgID4NCj4g ICAgID4gw4lyaWMgVnluY2tlIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0 aW9uIGZvcg0KPiAgICAgPiBkcmFmdC1pZXRmLXNmYy1uc2gtaW50ZWdyaXR5LTA2OiBEaXNjdXNz DQo+ICAgICA+DQo+ICAgICA+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1Ympl Y3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5DQo+IHRvDQo+ICAgICA+IGFsbCBlbWFpbCBhZGRyZXNz ZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwNCj4gZnJlZSB0bw0KPiAg ICAgPiBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4gICAgID4N Cj4gICAgID4NCj4gICAgID4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2ll c2cvc3RhdGVtZW50L2Rpc2N1c3MtDQo+ICAgICA+IGNyaXRlcmlhLmh0bWwNCj4gICAgID4gZm9y IG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+ ICAgICA+DQo+ICAgICA+DQpbLi5dDQo+ICAgICA+DQo+ICAgICA+ID09IERJU0NVU1MgPT0NCj4g ICAgID4NCj4gICAgID4gSSBmYWlsZWQgdG8gc3BvdCB0aGUgb3JkZXIgb2YgdGhlIG9wZXJhdGlv bnMgZm9yIHRoZSBpbnRlZ3JpdHkNCj4gYW5kDQo+ICAgICA+IGNvbmZpZGVudGlhbGl0eSBvcGVy YXRpb25zLCBlLmcuLCBJIGRpZCBub3QgZmluZCBvbiB3aGF0IHRoZQ0KPiBITUFDIGlzDQo+ICAg ICA+IGNvbXB1dGVkOg0KPiAgICAgPiBpbiB0aGUgdW5lbmNyeXB0ZWQgb3IgZW5jcnlwdGVkIGZp ZWxkID8NCj4gDQo+ICAgICBbTWVkXSBJc24ndCB0aGlzIGNvdmVyZWQgYnkgdGhpcyB0ZXh0Og0K PiANCj4gICAgICAgIFVzaW5nIHRoZSBzZWNyZXQga2V5IChLKSBhbmQgYXV0aGVudGljYXRlZCBl bmNyeXB0aW9uDQo+IGFsZ29yaXRobSwgdGhlDQo+ICAgICAgICBOU0ggaW1wb3NlciBlbmNyeXB0 cyB0aGUgQ29udGV4dCBIZWFkZXJzIChhcyBzZXQsIGZvcg0KPiBleGFtcGxlLCBpbg0KPiAgICAg ICAgU2VjdGlvbiAzKSwgY29tcHV0ZXMgdGhlIG1lc3NhZ2UgaW50ZWdyaXR5IGZvciB0aGUgdGFy Z2V0IE5TSA0KPiBkYXRhLA0KPiAgICAgICAgYW5kIGluc2VydHMgdGhlIHJlc3VsdGluZyBwYXls b2FkIGluIHRoZSAiTUFDIGFuZCBFbmNyeXB0ZWQNCj4gTWV0YWRhdGEiDQo+ICAgICAgICBDb250 ZXh0IEhlYWRlciAoU2VjdGlvbiA1KS4gIFRoZSBlbnRpcmUgQ29udGV4dCBIZWFkZXINCj4gY2Fy cnlpbmcgYQ0KPiAgICAgICAgcHJpdmFjeS1zZW5zaXRpdmUgbWV0YWRhdGEgaXMgZW5jcnlwdGVk ICh0aGF0IGlzLCBpbmNsdWRpbmcNCj4gdGhlIE1EDQo+ICAgICAgICBDbGFzcywgVHlwZSwgTGVu Z3RoLCBhbmQgYXNzb2NpYXRlZCBtZXRhZGF0YSBvZiBlYWNoIENvbnRleHQNCj4gSGVhZGVyKS4N Cj4gDQo+IEVWPiB0aGUgdGV4dCBjb3VsZCBiZSBtYWRlIGNsZWFyZXIgYnkgdXNpbmcgInRoZW4i IHJhdGhlciB0aGFuDQo+IHNpbXBsZSAiLCINCj4gRVY+IGJ1dCBJIFNUUk9OR0xZIHN1Z2dlc3Qg dG8gbW92ZSB0aGlzIGV4cGxhbmF0aW9uIGVhcmxpZXIgYXQgdGhlDQo+IHZlcnkNCj4gRVY+IGJl Z2lubmluZyBvZiBzZWN0aW9uIDcgKG9yIDcuMSkgYW5kIG5vdCBsaWtlIG5vdyBpbiBzZWN0aW9u IDcuMw0KPiBCVFcsDQo+IEVWPiB0aGlzIGlzIGluZGVlZCB0aGUgZXhwZWN0ZWQgb3JkZXIgdG8g YXZvaWQgRG9TDQo+IA0KDQpbTWVkXSBJIHJlYWxseSBzdHJ1Z2dsZWQgdG8gc2VlIGhvdyB0byBt ZW50aW9uIHRoaXMgdGV4dCBlYXJsaWVyLCBidXQgaXQgaXMgY3VycmVudGx5IHdoZXJlIGl0IHNo b3VsZCBiZS4gSXQgY2FuIGJlIGluIDcuMSBpcyB0aGlzIGlzIGFib3V0IGdlbmVyaWMgY29uc2lk ZXJhdGlvbnMuIEl0IGlzIGluIHRoaXMgc2VjdGlvbiBiZWNhdXNlIHRoaXMgaXMgd2hlcmUgd2Ug ZGlzY3Vzc2lvbiBlbmNyeXB0aW9uLiANCg0KPiAgICAgPg0KPiAgICAgPiAtLSBTZWN0aW9uIDUu MSAtLQ0KPiAgICAgPiBXaGF0IGlzIHRoZSB1bml0IG9mICJrZXkgbGVuZ3RoIiwgSSBhc3N1bWUg YSBsZW5ndGggZXhwcmVzc2VkDQo+IGluDQo+ICAgICA+IG9jdGV0cyBidXQgaXQgaXMgbm90IHNw ZWNpZmllZC4NCj4gDQo+ICAgICBbTWVkXSBZZXMuIEZpeGVkLiBUaGFuayB5b3UgZm9yIGNhdGNo aW5nIHRoaXMuDQo+IA0KPiBFVj4gX18NCj4gDQo+ICAgICA+DQo+ICAgICA+IC0tIFNlY3Rpb24g Ny4yIC0tDQo+ICAgICA+IFdoYXQgaXMgdGhlICJBIiB1c2VkIGluIHRoZSBITUFDIGNvbXB1dGF0 aW9uID8NCj4gDQo+ICAgICBbTWVkXSBUaGlzIGlzOiBBZGRpdGlvbmFsIEF1dGhlbnRpY2F0ZWQg RGF0YSAoQSkgKG1lbnRpb25lZCBpbg0KPiA0LjIpLg0KPiANCj4gRVY+IGZhaXIgZW5vdWdoLCBz dWdnZXN0IHRvIHdyaXRlIHRoYXQgdGhlIHRlcm1pbm9sb2d5IG9mIHNlY3Rpb24NCj4gNC4yIGlz IHVzZWQgdGhlcmUuDQoNCltNZWRdIFVwZGF0ZWQgdGhlIHRleHQgZm9yIGJldHRlciBjbGFyaXR5 LiANCg0KPiAgICAgPg0KPiAgICAgPiBUaGUgZm9ybXVsYSBzcGVjaWZpZXMgSE1BQy1TSEEtMjU2 LTEyOCgpIGJ1dCB3aGF0IGlmIGFub3RoZXINCj4gSE1BQyBpcw0KPiAgICAgPiB1c2VkID8NCj4g DQo+ICAgICBbTWVkXSBQbGVhc2Ugbm90ZSB0aGF0IHRoZSB0ZXh0IHNheXM6ICJjYW4gYmUgaWxs dXN0cmF0ZWQgYXMNCj4gZm9sbG93czoiLg0KPiANCj4gICAgIFRoYXQgaXMgZm9yIGlsbHVzdHJh dGlvbiBwdXJwb3Nlcy4NCj4gDQo+IEVWPiBjb3VsZCBhbHNvIGJlIG1hZGUgbW9yZSBvYnZpb3Vz IHdpdGggIiBUaGUgTWVzc2FnZQ0KPiBBdXRoZW50aWNhdGlvbiBDb2RlIChUKSBjb21wdXRhdGlv biBwcm9jZXNzIGZvciBhZGRpdGlvbmFsDQo+IGF1dGhlbnRpY2F0aW9uIHRleHQgKEEpIHdpdGgg SE1BQy1TSEEtMjU2LTEyOCgpIGNhbiBiZSBpbGx1c3RyYXRlZA0KPiBhcyBmb2xsb3dzOiINCg0K W01lZF0gRGVhbC4gDQoNCj4gDQo+ICAgICA+IFNlY3Rpb24gNy4zIHVzZSBNQUMoKSB3aGljaCBp cyBtb3JlIGZsZXhpYmxlLg0KPiAgICAgPg0KPiAgICAgPiBBcyB0aGUgTUFDIGZpZWxkIGlzIGlu Y2x1ZGVkIGluIHRoZSBpbnRlZ3JpdHkgcHJvdGVjdGVkDQo+IGhlYWRlciwNCj4gICAgID4gcGxl YXNlIHNwZWNpZnkgdGhlIHZhbHVlIG9mIHRoaXMgZmllbGQgd2hlbiBjb21wdXRpbmcgdGhlIEhN QUMNCj4gKEkNCj4gICAgID4gYXNzdW1lIDAgYnV0IGxldCdzIGJlIGNsZWFyKQ0KPiANCj4gRVY+ IHN0aWxsIHdhaXRpbmcgZm9yIGFuIGFuc3dlciBvbiB0aGlzIGlzc3VlIChzbyBrZWVwaW5nIG15 IERJU0NVU1MNCj4gRVY+IGJhbGxvdCkNCj4gDQoNCltNZWRdIEFkZGVkIHRoaXMgdGV4dDogDQoN CiAgIFRoZSBOU0ggaW1wb3NlciBzZXRzIHRoZSBNQUMgZmllbGQgdG8gemVybyBhbmQgdGhlbiBj b21wdXRlcyB0aGUNCiAgIG1lc3NhZ2UgaW50ZWdyaXR5IGZvciB0aGUgdGFyZ2V0IE5TSCBkYXRh IChkZXBlbmRpbmcgb24gdGhlIGludGVncml0eQ0KICAgcHJvdGVjdGlvbiBzY29wZSBkaXNjdXNz ZWQgaW4gU2VjdGlvbiA1KSB1c2luZyBNQUNfS0VZIGFuZCBITUFDDQogICBhbGdvcml0aG0uDQoN Cj4gICAgID4NCj4gICAgID4gLS0gU2VjdGlvbiA3LjUgLS0NCj4gICAgID4gV2hhdCBpcyB0aGUg ZXhwZWN0ZWQgYmVoYXZpb3Igd2hlbiBhIE5TSCBkb2VzIG5vdCBjb250YWluIGENCj4gIk1BQyBh bmQNCj4gICAgID4gRW5jcnlwdGVkIE1ldGFkYXRhIiBDb250ZXh0IEhlYWRlciA/IMKnMSBoaW50 cyB0byBwYWNrZXQgZHJvcCA/DQo+ICAgICA+IFNob3VsZCB0aGVyZSBiZSBhIGxvY2FsIHBvbGlj eSBmb3IgdGhpcyBjYXNlID8NCj4gDQo+ICAgICBbTWVkXSBUaGlzIGlzIGNvdmVyZWQgaGVyZToN Cj4gDQo+ICAgICAgICBJdCBNVVNUIGxvZyBhbiBlcnJvciBhdCBsZWFzdCBvbmNlIHBlciB0aGUN Cj4gICAgICAgIFNQSSBmb3Igd2hpY2ggdGhlICJNQUMgYW5kIEVuY3J5cHRlZCBNZXRhZGF0YSIg Q29udGV4dCBIZWFkZXINCj4gaXMNCj4gICAgICAgIG1pc3NpbmcuDQo+IA0KPiBFVj4gaG9uZXN0 bHksIG5vdCBjbGVhciBmcm9tIHRoZSB0ZXh0LiBQbGVhc2UgY29uc2lkZXIgYWRkaW5nICJJbg0K PiB0aGlzIGNhc2UsIGl0IE1VU1QuLi4iDQoNCltNZWRdIFVwZGF0ZWQgdGhlIHRleHQuIEl0IHJl YWRzIG5vdzoNCg0KICAgV2hlbiBhbiBTRkMgZGF0YSBwbGFuIGVsZW1lbnQgY29uZm9ybXMgdG8g dGhpcyBzcGVjaWZpY2F0aW9uLCBpdCBNVVNUDQogICBlbnN1cmUgdGhhdCBhICJNQUMgYW5kIEVu Y3J5cHRlZCBNZXRhZGF0YSIgQ29udGV4dCBIZWFkZXIgaXMgaW5jbHVkZWQNCiAgIGluIGEgcmVj ZWl2ZWQgTlNIIHBhY2tldC4gIFRoZSBpbXBvc2VyIE1VU1Qgc2lsZW50bHkgZGlzY2FyZCB0aGUN CiAgIHBhY2tldCBhbmQgTVVTVCBsb2cgYW4gZXJyb3IgYXQgbGVhc3Qgb25jZSBwZXIgdGhlIFNQ SSBpZiBhdCBsZWFzdA0KICAgb25lIG9mIHRoZSBmb2xsb3dpbmcgaXMgb2JzZXJ2ZWQ6DQoNCiAg IG8gIHRoZSAiTUFDIGFuZCBFbmNyeXB0ZWQgTWV0YWRhdGEiIENvbnRleHQgSGVhZGVyIGlzIG1p c3NpbmcsDQoNCiAgIG8gIHRoZSBlbmNsb3NlZCBrZXkgaWRlbnRpZmllciBpcyB1bmtub3duIG9y IGludmFsaWQgKGUuZy4sIHRoZQ0KICAgICAgY29ycmVzcG9uZGluZyBrZXkgZXhwaXJlZCksDQoN CiAgIG8gIHRoZSB0aW1lc3RhbXAgaXMgaW52YWxpZCAoU2VjdGlvbiA3LjQpLg0KDQo+IA0KPiAg ICAgPg0KPiAgICAgPg0KPiAgICAgPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLS0tLS0NCj4gICAgID4gLS0NCj4gICAg ID4gQ09NTUVOVDoNCj4gICAgID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0tLS0tDQo+ICAgICA+IC0tDQo+ICAgICA+ DQo+ICAgICA+DQo+ICAgICA+IEkgc2Vjb25kIEFsdmFybydzIGFuZCBMYXJzJyBwb2ludCBhYm91 dCBmb3JtYWxseSB1cGRhdGluZyBSRkMNCj4gODMwMC4NCj4gICAgID4NCj4gICAgID4gUXVpdGUg b2Z0ZW4gaW4gdGhlIHRleHQgInByaXZhY3ktc2Vuc2l0aXZlIG1ldGFkYXRhIiBpcyB1c2VkDQo+ IGJ1dA0KPiAgICAgPiBlbmNyeXB0aW9uIGlzIG5vdCBvbmx5IHJlcXVpcmVkIGZvciBwcml2YWN5 IGJ1dCBhbHNvIHRvDQo+IHByb3RlY3QNCj4gICAgID4gb3BlcmF0aW9uYWwgZGF0YSBmcm9tIGF0 dGFja2VycyAoaS5lLiwgbm90IGxpbmtlZCB0byBwcml2YWN5KSwNCj4gaXMNCj4gICAgID4gdGhl cmUgYSByZWFsIG5lZWQgdG8gcXVhbGlmeSAibWV0YWRhdGEiIHdpdGggInByaXZhY3ktDQo+IHNl bnNpdGl2ZSIsDQo+ICAgICA+IGkuZS4sICJjb25maWRlbnRpYWwgbWV0YWRhdGEiIG1heSBiZSBt b3JlIGFwcHJvcHJpYXRlID8NCj4gDQo+ICAgICBbTWVkXSBXZSB1c2UgdGhpcyB0ZXJtIGJlY2F1 c2Ugd2UgY2FuIGVhc2lseSBhcmd1ZSB3aHkgd2UNCj4gaW5jbHVkZWQgc3RhdGVtZW50IHN1Y2gg YXM6DQo+IA0KPiAgICAgICIgSW4gYW4gU0ZDLWVuYWJsZWQgZG9tYWluIHdoZXJlIHRoZSBhYm92 ZSBhdHRhY2tzIGFyZQ0KPiBwb3NzaWJsZSwgKDEpDQo+ICAgICAgICBOU0ggZGF0YSBNVVNUIGJl IGludGVncml0eS1wcm90ZWN0ZWQgYW5kIHJlcGxheS1wcm90ZWN0ZWQsDQo+IGFuZCAoMikNCj4g ICAgICAgIHByaXZhY3ktc2Vuc2l0aXZlIE5TSCBtZXRhZGF0YSBNVVNUIGJlIGVuY3J5cHRlZCBm b3INCj4gY29uZmlkZW50aWFsaXR5DQo+ICAgICAgICBwcmVzZXJ2YXRpb24gcHVycG9zZXMuIg0K PiANCj4gICAgIE90aGVyIHR5cGVzIGNhbiBiZSBlbmNyeXB0ZWQgYXMgcGVyOg0KPiANCj4gICAg ICAgIENsYXNzaWZpZXIocyksIE5TSC1hd2FyZSBTRnMsIGFuZCBTRkMgcHJveGllcyBhcmUgaW5z dHJ1Y3RlZA0KPiB3aXRoIHRoZQ0KPiAgICAgICAgc2V0IG9mIENvbnRleHQgSGVhZGVycyAocHJp dmFjeS1zZW5zaXRpdmUgbWV0YWRhdGEsDQo+IHR5cGljYWxseSkgdGhhdA0KPiAgICAgICAgbXVz dCBiZSBlbmNyeXB0ZWQuDQo+IA0KPiBFVj4gbGV0J3Mgc2F5IHRoYXQgd2UgZGlzYWdyZWUgX18g YnV0IHRoaXMgaXMgbm9uLWJsb2NraW5nIGFueXdheQ0KDQpbTWVkXSBJIGNoYW5nZWQgbWFueSBv Y2N1cnJlbmNlcyBvZiBwcml2YWN5LXNlbnNpdGl2ZSB0byBzZW5zaXRpdmVzIGJ1dCBtYWludGFp bmVkIHRoZW0gd2hlbiB6b29taW5nIG9uIHByaXZhY3kgd2FzIHRoZSBpbnRlbnQuIA0KDQo+IA0K PiAgICAgPg0KPiAgICAgPiAtLSBTZWN0aW9uIDQuMS4xIC0tDQo+ICAgICA+IFRoZSB1c2Ugb2Yg J21ldGFkYXRhJyAobm90YWJseSBpbiB0YWJsZSAxKSBmb3IgJ2NvbnRleHQNCj4gaGVhZGVycycg aXMNCj4gICAgID4gY29uZnVzaW5nIGZvciBhIGZpcnN0LXRpbWUgcmVhZGVyLiBBbnkgY2hhbmNl IHRvIGJlIGNvbnNpc3RlbnQNCj4gYW5kDQo+ICAgICA+IG9ubHkgdXNlICdjb250ZXh0IGhlYWRl cnMnID8NCj4gDQo+ICAgICBbTWVkXSBXaWxsIHNlZSBob3cgdG8gbWFrZSB0aGlzIGJldHRlciwg YnV0IHBsZWFzZSB0aGF0IHdlIGRvDQo+IGhhdmUgdGhlIGZvbGxvd2luZyBiZWZvcmUgdGFibGUg MToNCj4gDQo+ICAgICAiQ29udGV4dCBIZWFkZXIocyk6IENhcnJpZXMgbWV0YWRhdGEuLi4iDQo+ IA0KPiAgICAgPg0KPiAgICAgPiAtLSBTZWN0aW9uIDQuMiAtLQ0KPiAgICAgPiBBdCBmaXJzdCBy ZWFkaW5nLCBJIGFtIGNvbmZ1c2VkIGJ5IHRoZSB1c2Ugb2YgdGhlIHdvcmQgJ3NlY3JldA0KPiBr ZXknDQo+ICAgICA+IGZvciB3aGF0IGFwcGVhcnMgdG8gYmUgYSAnc2hhcmVkIGtleScuIE9yIGlz IHRoaXMgJ3NlY3JldCBrZXknDQo+IG5ldmVyDQo+ICAgICA+IHNoYXJlZCBhbmQgc2ltcGx5IHVz ZWQgdG8gZ2VuZXJhdGUgdGhlIHNlY29uZGFyeSBrZXlzLCB3aGljaA0KPiBhcmUNCj4gICAgID4g dGhlbiBzaGFyZWQgPyBFdmVuIGlmIGRpc2N1c3NlZCBsYXRlciwgc29tZSBlYXJseSBleHBsYW5h dGlvbnMNCj4gd291bGQNCj4gICAgID4gYmUgd2VsY29tZS4NCj4gDQo+ICAgICBbTWVkXSBXZSBh cmUgdXNpbmcgc2ltaWxhciB3b3JkaW5nIGFzIGluIFJGQzc1MTguDQo+IA0KPiBFVj4gSSBmYWls IHRvIHNlZSB0aGlzIHdvcmRpbmcgaW4gUkZDIDc1MTgNCg0KW01lZF0gUkZDIDc1MTggc2F5cyBm b3IgZXhhbXBsZToNCg0KICAgVGhlIGF1dGhlbnRpY2F0ZWQgZW5jcnlwdGlvbiBhbGdvcml0aG0g dGFrZXMgYXMgaW5wdXQgZm91ciBvY3RldA0KICAgc3RyaW5nczogYSBzZWNyZXQga2V5IEssIGEg cGxhaW50ZXh0IFAsIEFkZGl0aW9uYWwgQXV0aGVudGljYXRlZCBEYXRhDQogICAgICAgICAgICBe Xl5eXl5eXl5eXl5eXiANCiAgIEEsIGFuZCBhbiBJbml0aWFsaXphdGlvbiBWZWN0b3IgSVYuICBU aGUgYXV0aGVudGljYXRlZCBjaXBoZXJ0ZXh0DQogICB2YWx1ZSBFIGFuZCB0aGUgQXV0aGVudGlj YXRpb24gVGFnIHZhbHVlIFQgYXJlIHByb3ZpZGVkIGFzIG91dHB1dHMuDQogICBUaGUgZGF0YSBp biB0aGUgcGxhaW50ZXh0IGFyZSBlbmNyeXB0ZWQgYW5kIGF1dGhlbnRpY2F0ZWQsIGFuZCB0aGUN CiAgIEFkZGl0aW9uYWwgQXV0aGVudGljYXRlZCBEYXRhIGFyZSBhdXRoZW50aWNhdGVkLCBidXQg bm90IGVuY3J5cHRlZC4NCg0KPiANCj4gICAgID4NCj4gICAgID4gLS0gU2VjdGlvbiA1LjEgLS0N Cj4gICAgID4gSXMgdGhlcmUgYSBnb29kIHJlYXNvbiB3aHkgdGhlIGZpZWxkIG5hbWUgImtleSBs ZW5ndGgiIGlzIG5vdA0KPiAia2V5DQo+ICAgICA+IElEIGxlbmd0aCIgPw0KPiANCj4gICAgIFtN ZWRdIE9ubHkgZm9yIGVzdGhldGljIG1hdHRlcnMgb2YgdGhlIGZpZ3VyZXMuIENhbiBmaXggdGhh dCBpZg0KPiB5b3UgcHJlZmVyLg0KPiANCj4gICAgIHxLZXkgSUQgTGVuZ3RofCB2cyB8IEtleSBM ZW5ndGggfA0KPiANCj4gRVY+IHRoaXMgd291bGQgYmUgY2xlYXJlciBJTUhPIGJ1dCBlZGl0b3Jp YWwgaGVuY2Ugbm9uLWJsb2NraW5nDQoNCltNZWRdIE1hZGUgdGhlIGNoYW5nZS4gVGhhbmtzLiAN Cg0KPiANCj4gICAgID4NCj4gICAgID4gSSBhbHNvIGZpbmQgdmVyeSBzdHJhbmdlIHRvIGRlZmlu ZSAiTGVuZ3RoOiB2YXJpYWJsZSIgYXMgdGhlDQo+IGhlYWRlcg0KPiAgICAgPiBmaWVsZCBpdHNl bGYgYXMgYSBmaXhlZCBsZW5ndGgsIHNpbXBseSBzdGF0ZSAidW5zaWduZWQNCj4gaW50ZWdlciIu DQo+IA0KPiAgICAgW01lZF0gV2UgYXJlIGVjaG9pbmcgU2VjdGlvbiAyLjUuMSBvZiBSRkM4MzAw Lg0KPiANCj4gRVY+IGxpa2UgYWJvdmUsIEkgZmFpbCB0byBzZWUgdGhpcyBzaW1pbGFyaXR5IGlu IHRoZSBzZWN0aW9uIDIuNS4xDQo+IG9mIFJGQyA4MzAwICJJbmRpY2F0ZXMgdGhlIGxlbmd0aCBv ZiB0aGUgdmFyaWFibGUtbGVuZ3RoIG1ldGFkYXRhLA0KPiBpbiBieXRlcy4iDQoNCltNZWRdIHRo YXQncyBiYXNpY2FsbHkgc2F5cyB2YXJpYWJsZS4gVXBkYXRlZCB0aGUgdGV4dCB0byB1c2UgZXhh Y3Qgd29yZGluZyBpbiA4MzAwLg0KDQo+ICAgICA+DQo+ICAgICA+IEFzIHRpbWVzdGFtcCBjYW4g aW5jbHVkZSBmcmFjdGlvbnMgb2Ygc2Vjb25kLCB3aGljaCBpcyBhIGdvb2QNCj4gdGhpbmcsDQo+ ICAgICA+IHRoZW4gcGxlYXNlIHJld29yZCAiZXhwcmVzc2VkIGluIHNlY29uZHMgcmVsYXRpdmUi IHRvIGluZGljYXRlDQo+IHRoYXQNCj4gICAgID4gZnJhY3Rpb24gb2Ygc2Vjb25kIGlzIGluY2x1 ZGVkLg0KPiANCj4gICAgIFtNZWRdIE9LLg0KPiANCj4gICAgID4NCj4gICAgID4gVGhlIDMyLWJp dCBlcG9jaCB3aWxsIHdyYXAgYXJvdW5kIGluIDIwMzYsIHNob3VsZCB0aGlzIEktRA0KPiBhbHJl YWR5DQo+ICAgICA+IGNvbnNpZGVyIHdoYXQgdG8gZG8gYXQgdGhhdCBtb21lbnQgPw0KPiANCj4g ICAgIFtNZWRdIEhtbS4gV2Ugc2F5IHRoYXQgaXQgd3JhcHMgaW4gMjEwNiA6LSkNCj4gDQo+IEVW PiBJIHNob3VsZCBoYXZlIHNwb3QgdGhlIGRpZmZlcmVudCBlcG9jaCA7LSkNCj4gDQo+ICAgICA+ DQo+ICAgICA+IC0tIFNlY3Rpb24gOCAtLQ0KPiAgICAgPiBJbmRlZWQgTVRVIGlzIGFsd2F5cyBh biBpbnRlcmVzdGluZyAncHJvYmxlbScgYnV0IGhvdyBpcyB0aGlzDQo+ICAgICA+IGV4dGVuc2lv biBkaWZmZXJlbnQgdGhhbiBwbGFpbiBOU0ggPyBUaGUgTlNIIG5laXRoZXIgaW5jcmVhc2VzDQo+ IG5vcg0KPiAgICAgPiBkZWNyZWFzZXMgb24gdGhlIGZseSB3aXRoIHRoaXMgZG9jdW1lbnQuDQo+ IA0KPiAgICAgW01lZF0gSXQgdmFyaWVzIGFzIHdlIGNhbiBhZGQvc3RyaXAgY29udGV4dCBoZWFk ZXJzIGFzIHRoZQ0KPiBwYWNrZXQgcHJvZ3Jlc3MgaW4gdGhlIHNlcnZpY2UgY2hhaW4uDQo+IA0K PiBFVj4gQW1hemluZyB0aGF0IHRoaXMgd2FzIGFjY2VwdGVkIGJ5IHRoZSBJRVNHIGluIFJGQyA4 MzAwIHllYXJzDQo+IGFnby4uLiB3aGVuIG5ldC1wZ20gUkZDIGhhZCB0byByZW1vdmUgdGhlIGhl YWRlciBpbnNlcnRpb24uDQo+IA0KPiAgICAgPg0KPiAgICAgPiA9PSBOSVRTID09DQo+ICAgICA+ DQo+ICAgICA+IC0tIFNlY3Rpb24gMyAtLQ0KPiAgICAgPiBTaG91bGQgJ2ZpZ3VyZSAxJyBiZSAn dGFibGUgMScgcGVyIGNvbnNpc3RlbmN5IHdpdGggc2VjdGlvbg0KPiA0LjEuMSA/DQo+IA0KPiAg ICAgW01lZF0gSXQgc2hvdWxkLiBXaWxsIGJlIGZpeGVkLiBUaGFua3MuDQo+IA0KPiAgICAgPg0K PiAgICAgPg0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiANCj4gICAgIENlIG1lc3NhZ2Ug ZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzDQo+IGluZm9ybWF0aW9u cyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KPiAg ICAgcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRp b24uIFNpDQo+IHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXog bGUgc2lnbmFsZXINCj4gICAgIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1 ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcw0KPiBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50 IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQo+ICAgICBPcmFuZ2UgZGVjbGluZSB0b3V0ZSBy ZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwNCj4gZGVmb3JtZSBvdSBm YWxzaWZpZS4gTWVyY2kuDQo+IA0KPiAgICAgVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yDQo+IHByaXZpbGVnZWQgaW5mb3JtYXRpb24g dGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCj4gICAgIHRoZXkgc2hvdWxkIG5vdCBiZSBk aXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dA0KPiBhdXRob3Jpc2F0aW9uLg0KPiAg ICAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUNCj4gc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMuDQo+ICAgICBBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxl IGZvciBtZXNzYWdlcyB0aGF0DQo+IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxz aWZpZWQuDQo+ICAgICBUaGFuayB5b3UuDQo+IA0KDQoKX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBz ZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZp ZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRp ZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2 ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdl eHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExl cyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24s Ck9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUg YWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9y bWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBk aXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxz IG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBo YXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Wed Jul 14 22:02:20 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4473A1BE8; Wed, 14 Jul 2021 22:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jH3F14lLNAJf; Wed, 14 Jul 2021 22:02:08 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (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 8AD883A1BE6; Wed, 14 Jul 2021 22:02:02 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr24.francetelecom.fr (ESMTP service) with ESMTPS id 4GQMfs25J3z1y7P; Thu, 15 Jul 2021 07:01:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1626325317; bh=ShfCveJcEKObaJGFItLlrYuX8tVA9P2Y+fnsRoUjQFk=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=LGjY8rcHi+Puk8M5Ki0y8YdouaWYfDO7vQDuex/4DZQ1/dEyjDZMV3Ebd3bTrZrR8 ZyMF2cczOjPZtDge9MxkLu7cqC9YzRjISLOqNRJ/BPs0j7s7NGuy2xHCKS+4brAg8C swKP/hMKh1RmFds5Sq2FZUbX9VhmUCzAtWDEKwPSGeZL2wsWvxEZ/oI3o9z9+QxP7c FsyUur8wOpSyVWmIuXC7/qbVSpOC5kM6hZqyAmC633d4l+b74L/ixJ3lPW+dbNNe5X 4kfiZ0qaviS75o354EN7M8FUNzVd7xG2ipq3L8xRsM1Z1z8Afc/FR9s7pAU0wKvLTD AzbyqM2+DTbMA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfednr03.francetelecom.fr (ESMTP service) with ESMTPS id 4GQMfs1HKmzDq82; Thu, 15 Jul 2021 07:01:57 +0200 (CEST) From: To: Warren Kumari , The IESG CC: "draft-ietf-sfc-nsh-integrity@ietf.org" , "sfc-chairs@ietf.org" , "sfc@ietf.org" , "gregimirsky@gmail.com" , "j.schoenwaelder@jacobs-university.de" Thread-Topic: Warren Kumari's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) Thread-Index: AQHXeNl9pqahg1HTVUi989FEVTTQtKtDewuw Date: Thu, 15 Jul 2021 05:01:55 +0000 Message-ID: <28315_1626325317_60EFC145_28315_39_1_787AE7BB302AE849A7480A190F8B9330353BF439@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162628534840.21882.4452533905992394703@ietfa.amsl.com> In-Reply-To: <162628534840.21882.4452533905992394703@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Warren Kumari's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 05:02:13 -0000 SGkgV2FycmVuLA0KDQpUaGFua3MgZm9yIHRoZSBjb21tZW50LiANCg0KV2lsbCBzZWUgaG93IHRv IHR3ZWFrIHRoYXQgc2VudGVuY2UuIElmIHdlIGRvbid0IGhhdmUgYSBiZXR0ZXIgYWx0ZXJuYXRp dmUsIHdlIHdpbGwgbGVhdmUgaXQgdG8gdGhlIFJGQyBlZGl0b3IuIA0KDQpDaGVlcnMsDQpNZWQN Cg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogV2FycmVuIEt1bWFyaSB2 aWEgRGF0YXRyYWNrZXIgW21haWx0bzpub3JlcGx5QGlldGYub3JnXQ0KPiBFbnZvecOpwqA6IG1l cmNyZWRpIDE0IGp1aWxsZXQgMjAyMSAxOTo1Ng0KPiDDgMKgOiBUaGUgSUVTRyA8aWVzZ0BpZXRm Lm9yZz4NCj4gQ2PCoDogZHJhZnQtaWV0Zi1zZmMtbnNoLWludGVncml0eUBpZXRmLm9yZzsgc2Zj LWNoYWlyc0BpZXRmLm9yZzsNCj4gc2ZjQGlldGYub3JnOyBncmVnaW1pcnNreUBnbWFpbC5jb207 IGdyZWdpbWlyc2t5QGdtYWlsLmNvbTsNCj4gai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJz aXR5LmRlDQo+IE9iamV0wqA6IFdhcnJlbiBLdW1hcmkncyBObyBPYmplY3Rpb24gb24gZHJhZnQt aWV0Zi1zZmMtbnNoLQ0KPiBpbnRlZ3JpdHktMDY6ICh3aXRoIENPTU1FTlQpDQo+IA0KPiBXYXJy ZW4gS3VtYXJpIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0K PiBkcmFmdC1pZXRmLXNmYy1uc2gtaW50ZWdyaXR5LTA2OiBObyBPYmplY3Rpb24NCj4gDQo+IFdo ZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJl cGx5IHRvDQo+IGFsbCBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBs aW5lcy4gKEZlZWwgZnJlZSB0bw0KPiBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBo b3dldmVyLikNCj4gDQo+IA0KPiBQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv aWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy0NCj4gY3JpdGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZv cm1hdGlvbiBhYm91dCBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gDQo+IA0KPiBU aGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZv dW5kIGhlcmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt c2ZjLW5zaC1pbnRlZ3JpdHkvDQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tDQo+IENP TU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tDQo+IA0KPiBJIHN1cHBvcnQgUm9tYW4gYW5kIEVy aWMncyBESVNDVVNTIHBvaW50cy4NCj4gDQo+IEkgYWxzbyBmb3VuZDoNCj4gIk5vdGUgdGhhdCBz b21lIHRyYW5zcG9ydCBlbmNhcHN1bGF0aW9ucyAoZS5nLiwgSVBzZWMpIG9ubHkgcHJvdmlkZQ0K PiBob3AtYnktaG9wIHNlY3VyaXR5IGJldHdlZW4gdHdvIFNGQyBkYXRhIHBsYW5lIGVsZW1lbnRz IChlLmcuLCB0d28NCj4gU2VydmljZSBGdW5jdGlvbiBGb3J3YXJkZXJzIChTRkZzKSwgU0ZGIHRv IFNGKSBhbmQgZG8gbm90IHByb3ZpZGUNCj4gU0YtdG8tU0Ygc2VjdXJpdHkgb2YgTlNIIG1ldGFk YXRhLiAgRm9yIGV4YW1wbGUsIGlmIElQc2VjIGlzIHVzZWQsDQo+IFNGRnMgb3IgU0ZzIHdpdGhp biBhIFNlcnZpY2UgRnVuY3Rpb24gUGF0aCAoU0ZQKSB0aGF0IGFyZSBub3QNCj4gYXV0aG9yaXpl ZCB0byBhY2Nlc3MgdGhlIHByaXZhY3ktc2Vuc2l0aXZlIG1ldGFkYXRhIHdpbGwgaGF2ZSBhY2Nl c3MNCj4gdG8gdGhlIG1ldGFkYXRhLiIgdG8gYmUgaW5jcmVkaWJseSBoYXJkIHRvIHJlYWQvcGFy c2UuIEkgdGhpbmsgdGhhdA0KPiBteSBjb25mdXNpb24gY29tZXMgaW4gYXJvdW5kIHRoZSAidGhh dCBhcmUgbm90IGF1dGhvcml6ZWQgdG8gYWNjZXNzDQo+IHRoZSBwcml2YWN5LXNlbnNpdGl2ZSBt ZXRhZGF0YSB3aWxsIGhhdmUgYWNjZXNzIHRvIHRoZSBtZXRhZGF0YS4iDQo+IHRlc3QsIGFuZCB0 aGluZyB0aGF0IHRoZSBsYXN0IHNlbnRlbmNlIHNob3VsZCBiZSByZXdyaXR0ZW4gdG8gc3RhcnQN Cj4gd2l0aCAiQmVjYXVzZSBJUHNlYyBkb2VzIG5vdC4uLiBpdCBleHBvc2VzIHByaXZhY3ktc2Vu c2l0aXZlDQo+IG1ldGFkYXRhIHRvLi4uIg0KPiANCj4gQWxzbywgdGhhbmtzIHRvIErDvHJnZW4g U2Now7Zud8OkbGRlciBmb3IgdGhlIE9wc0RpciByZXZpZXcsIGFuZCB0byB0aGUNCj4gYXV0aG9y cyBmb3IgYWRkcmVzc2luZyB0aGUgY29tbWVudHMuDQo+IA0KPiANCg0KCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1l c3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0 aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpw YXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4g U2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWdu YWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBq b2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdh bHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNz YWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3Nh Z2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmls ZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3Vs ZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlv bi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMu CkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3Nh Z2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsg eW91LgoK From nobody Wed Jul 14 22:13:27 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 986D73A1C37; Wed, 14 Jul 2021 22:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rB143_gqfhxQ; Wed, 14 Jul 2021 22:13:21 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (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 8B0413A138E; Wed, 14 Jul 2021 22:13:20 -0700 (PDT) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfedar25.francetelecom.fr (ESMTP service) with ESMTPS id 4GQMvy6CNbz8tKx; Thu, 15 Jul 2021 07:13:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1626325998; bh=Pnnft0nblghT9uU2U6dYTKOLJQBnuu9K+mLaFSmQmq8=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=IFcfQFmIbbhv4iptyq6joLSLHiB+3athXPao8mTOlpLtXX9CQp/I/744ttUWw9aoG agjlG2DDlHLKsI9vGGOPdwnESk9A9QV1QKFTeAv4V4amHV8LnjsZihsNurZiP+3ggU OPL9j3l5PALH2DxPBG8nJNMrB8gECAMW/WLvhOTxQwN8QYZ9ODHY27LZxf/ul71EQi easoLKtXSoAzEHJfpkTc1EbSMYj8VzCun8HIJL8t15iRzzDqELCvtV4RfPY94DThnx 1P+28be4OUjOZo48ycMnqJX2ngaKRkLsvoByznCou+IcL0tHvg5o1uhy5mQmo5Eojd mgKa1lJQOd4EA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfedar06.francetelecom.fr (ESMTP service) with ESMTPS id 4GQMvt5dZQz3wbN; Thu, 15 Jul 2021 07:13:14 +0200 (CEST) From: To: John Scudder , The IESG CC: "gregimirsky@gmail.com" , "draft-ietf-sfc-nsh-integrity@ietf.org" , "sfc-chairs@ietf.org" , "sfc@ietf.org" Thread-Topic: [sfc] John Scudder's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) Thread-Index: AQHXeQY/zJsvbSZ7CkW+ihtKU84LsatDfEGw Date: Thu, 15 Jul 2021 05:13:14 +0000 Message-ID: <32352_1626325998_60EFC3EE_32352_250_1_787AE7BB302AE849A7480A190F8B9330353BF458@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162630455957.5451.359442420121368370@ietfa.amsl.com> In-Reply-To: <162630455957.5451.359442420121368370@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] John Scudder's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 05:13:26 -0000 SGkgSm9obiwgDQoNClRoYW5rIHlvdSBmb3IgdGhlIHJldmlldy4gDQoNClBsZWFzZSBzZWUgaW5s aW5lLiANCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ IERlwqA6IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIEpv aG4gU2N1ZGRlcg0KPiB2aWEgRGF0YXRyYWNrZXINCj4gRW52b3nDqcKgOiBqZXVkaSAxNSBqdWls bGV0IDIwMjEgMDE6MTYNCj4gw4DCoDogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQo+IENjwqA6 IGdyZWdpbWlyc2t5QGdtYWlsLmNvbTsgZHJhZnQtaWV0Zi1zZmMtbnNoLWludGVncml0eUBpZXRm Lm9yZzsNCj4gc2ZjLWNoYWlyc0BpZXRmLm9yZzsgc2ZjQGlldGYub3JnDQo+IE9iamV0wqA6IFtz ZmNdIEpvaG4gU2N1ZGRlcidzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLXNmYy1uc2gtDQo+ IGludGVncml0eS0wNjogKHdpdGggQ09NTUVOVCkNCj4gDQo+IEpvaG4gU2N1ZGRlciBoYXMgZW50 ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gZHJhZnQtaWV0Zi1zZmMt bnNoLWludGVncml0eS0wNjogTm8gT2JqZWN0aW9uDQo+IA0KPiBXaGVuIHJlc3BvbmRpbmcsIHBs ZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0bw0KPiBhbGwgZW1h aWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUg dG8NCj4gY3V0IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+IA0KPiAN Cj4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rp c2N1c3MtDQo+IGNyaXRlcmlhLmh0bWwNCj4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgRElT Q1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+IA0KPiANCj4gVGhlIGRvY3VtZW50LCBhbG9u ZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNmYy1uc2gtaW50ZWdyaXR5 Lw0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLQ0KPiBDT01NRU5UOg0KPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPiAtLQ0KPiANCj4gMS4gU2VjdGlvbiA0LjINCj4gDQo+ICAgIFRoZSBhdXRoZW50aWNh dGVkIGVuY3J5cHRpb24gcHJvY2VzcyB0YWtlcyBhcyBpbnB1dCBmb3VyLW9jdGV0DQo+ICAgIHN0 cmluZ3M6IGEgc2VjcmV0IGtleSAoSyksIGEgcGxhaW50ZXh0IChQKSwgQWRkaXRpb25hbA0KPiBB dXRoZW50aWNhdGVkDQo+ICAgIERhdGEgKEEpICh3aGljaCBjb250YWlucyB0aGUgZGF0YSB0byBi ZSBhdXRoZW50aWNhdGVkLCBidXQgbm90DQo+ICAgIGVuY3J5cHRlZCksIGFuZCBhbiBJbml0aWFs aXphdGlvbiBWZWN0b3IgKElWKS4gIFRoZSBjaXBoZXJ0ZXh0DQo+IHZhbHVlDQo+ICAgIChFKSBh bmQgdGhlIEF1dGhlbnRpY2F0aW9uIFRhZyB2YWx1ZSAoVCkgYXJlIHByb3ZpZGVkIGFzIG91dHB1 dHMuDQo+IA0KPiBBcyB3cml0dGVuLCB0aGlzIG1lYW5zIHRoYXQgZWFjaCBvZiB0aGVzZSBxdWFu dGl0aWVzIGlzIGEgMzIgYml0DQo+IHN0cmluZywgZXZlbiBQIGFuZCBBLiBJIHRoaW5rIHlvdSBk b27igJl0IG1lYW4gdGhhdC4gSWYgeW91IG1lYW4gZWFjaA0KPiBxdWFudGl0eSBpcyBhIHN0cmlu ZyBvZiBvY3RldHMsIHRoZW4gbW92ZSB0aGUgaHlwaGVuOiDigJx0YWtlcyBhcw0KPiBpbnB1dCBm b3VyIG9jdGV0LXN0cmluZ3PigJwuIChJbiB0aGUgdW5saWtlbHkgZXZlbnQgeW91IHJlYWxseSBk byBtZWFuDQo+IGVhY2ggcXVhbnRpdHkgaXMgYSBzdHJpbmcgb2YgZm91ciBvY3RldHMsIHRoZW4g 4oCc4oCmIHRha2VzIGFzIGlucHV0DQo+IGZvdXIgc3RyaW5ncywgZWFjaCBvZiBmb3VyIG9jdGV0 cy7igJ0pDQo+IA0KDQpbTWVkXSBHb29kIGNhdGNoLiBDaGFuZ2VkIHRvICJhcyBpbnB1dCBmb3Vy IG9jdGV0IHN0cmluZ3M6Ig0KDQo+IDIuIFNlY3Rpb24gOQ0KPiANCj4gUmVnYXJkaW5nIHlvdXIg dXNlIG9mIHRoZSB0ZXJtIOKAnG1hbi1pbi10aGUtbWlkZGxlIGF0dGFja2Vy4oCdLCB5b3UNCj4g bWlnaHQgd2FudCB0byB0YWtlIGludG8gY29uc2lkZXJhdGlvbiB0aGF0IHRoaXMgbGFuZ3VhZ2Ug bWF5IGJlIHNlZW4NCj4gYXMgZXhjbHVzaW9uYXJ5IGJ5IHNvbWUgcmVhZGVycywgc2VlIGFsc28N Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYWJvdXQvZ3JvdXBzL2llc2cvc3RhdGVtZW50cy9vbi1p bmNsdXNpdmUtDQo+IGxhbmd1YWdlLy4gSeKAmXZlIHNlZW4g4oCcb24tcGF0aCBhdHRhY2tlcuKA nCB1c2VkIGFzIGEgcmVwbGFjZW1lbnQgaW4NCj4gc29tZSBjYXNlcywgYnV0IEkgdW5kZXJzdGFu ZCB0aGVyZSBtYXkgYmUgbnVhbmNlcyB0aGF0IG1ha2UgdGhpcw0KPiBpbmFwcHJvcHJpYXRlIGZv ciBzb21lIHVzZXM7IGl0IGFsc28gYXBwZWFycyB5b3UgbWlnaHQganVzdCBiZSBhYmxlDQo+IHRv IHVzZSDigJxhdHRhY2tlcuKAnSBpbiB5b3VyIGNhc2UuIFRoZSBSRkMgRWRpdG9yIG1heSBoYXZl IGZ1cnRoZXINCj4gZ3VpZGFuY2UuDQoNCltNZWRdIEFncmVlLiBBbHJlYWR5IGZpeGVkIGFzIHBh cnQgb2YgTGFycydzIHJldmlldy4gDQoNCj4gDQo+IDMuIFNlY3Rpb24gOS4xDQo+IA0KPiBZb3Ug dXNlIOKAnHNob3VsZOKAnCBpbiBzZXZlcmFsIHBsYWNlcy4gQXMgd3JpdHRlbiwgaXQgaXNu4oCZ dCBjbGVhciBpZg0KPiB5b3XigJlyZSBpbmRpY2F0aW5nIGV4cGVjdGF0aW9uLCBvciByZXF1aXJl bWVudC4gQWZ0ZXIgcmVhZGluZyB0aGUNCj4gd2hvbGUgc2VjdGlvbiwgSSB0aGluayB5b3XigJly ZSBpbmRpY2F0aW5nIHJlcXVpcmVtZW50LiBUaGlzIHNlZW1zDQo+IGxpa2UgYSBnb29kIHBsYWNl IGZvciB1c2Ugb2YgdGhlIFJGQyAyMTE5IHN0eWxlIFNIT1VMRCBrZXl3b3JkLg0KPiANCj4gDQoN CltNZWRdIFRoZSBub3JtYXRpdmUgbGFuZ3VhZ2UgaXMgbm90IHVzZWQgYmVjYXVzZSB0aGVzZSBh cmUgc29tZWhvdyBjb3ZlcmVkIGJ5IG90aGVyIG5vcm1hdGl2ZSB0ZXh0IGluIHRoZSBtYWluIGRv Y3VtZW50LiBTZWUgZm9yIGV4YW1wbGUgdGhlIHN0YXRlbWVudHMgYWJvdXQgcHJvdmlkaW5nIGtl eSBtYXRlcmlhbHMgdG8gYXV0aG9yaXplZCBlbnRpdGllcyBhbmQgc28gb24uIA0KDQo+IA0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzZmMgbWFp bGluZyBsaXN0DQo+IHNmY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NmYw0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVz IHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJp dmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVz IG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2Fn ZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBk ZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ry b25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0 b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBv dSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkg Y29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBi ZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQg b3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhp cyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwg T3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVk LCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Wed Jul 14 23:13:47 2021 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA673A1E3D; Wed, 14 Jul 2021 23:13:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Murray Kucherawy via Datatracker To: "The IESG" Cc: draft-ietf-sfc-nsh-integrity@ietf.org, sfc-chairs@ietf.org, sfc@ietf.org, gregimirsky@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <162632962077.15354.4548212112967523910@ietfa.amsl.com> Date: Wed, 14 Jul 2021 23:13:41 -0700 Archived-At: Subject: [sfc] Murray Kucherawy's Discuss on draft-ietf-sfc-nsh-integrity-06: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 06:13:41 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-sfc-nsh-integrity-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Enough other Area Directors have said, and I agree, that this should officially update RFC 8300, so I'd like to have the discussion. In particular, given that this was identified as a gap in RFC 8300, and since I don't see any explicit statement that this is meant to be an optional extension, shouldn't it be an update? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Only nits to add, given the thorough treatment already given by others: Section 4.1.2: "The first level of assurance where all NSH data ..." -- add "is" before "where"? And the same issue in the next paragraph. Section 5.2: s/Coves/Covers/ From nobody Thu Jul 15 02:54:50 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5313A24E7; Thu, 15 Jul 2021 02:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.796 X-Spam-Level: X-Spam-Status: No, score=-2.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAxYFBtLy3EM; Thu, 15 Jul 2021 02:54:41 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (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 D4FAA3A24EC; Thu, 15 Jul 2021 02:54:32 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr21.francetelecom.fr (ESMTP service) with ESMTPS id 4GQV8Q5HcKz5w02; Thu, 15 Jul 2021 11:54:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1626342870; bh=y9v3XCOypjy58RTjC9fzt1rh7WSZ/9eWb2tcXMkvC8Y=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=f4FNcseXRrM8tW6HjtJIUmmPhZ7yHIkM+KLqalxGGQgRimHGym74h2EXLRPCF3tDd jPXd+ShfXSyP5cnu3EERsMAnz3nFW1L+83K8wRDigUTnqs2/RKGrkXvs4zqJGKm1NX lBly8jc8ihGjARJkqyvKR6ni0T8r6UYO/fP5uA7Zujryx9URrtF+zTiV/LdO42Z8wY OPN+8kL1zzDpxgYDInOqLkhXyGrKCGEohsKNc3TdCE5rM2Ng1+h6c028JEff5CYPnZ YaIUxgyBMyZRaC2CB2NEeaH+cgg1OeihTfCrl34NXnsbL9hjKe5EouGK11vOG1F1m7 UaCcC3HGTsvBA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfednr00.francetelecom.fr (ESMTP service) with ESMTPS id 4GQV8Q4LpvzDq7q; Thu, 15 Jul 2021 11:54:30 +0200 (CEST) From: To: Murray Kucherawy , The IESG CC: "draft-ietf-sfc-nsh-integrity@ietf.org" , "sfc-chairs@ietf.org" , "sfc@ietf.org" , "gregimirsky@gmail.com" Thread-Topic: Murray Kucherawy's Discuss on draft-ietf-sfc-nsh-integrity-06: (with DISCUSS and COMMENT) Thread-Index: AQHXeUCRRoFE1lG5BU+IA6kn2WVtFatDytWg Date: Thu, 15 Jul 2021 09:54:29 +0000 Message-ID: <7171_1626342870_60F005D6_7171_103_3_787AE7BB302AE849A7480A190F8B9330353BF653@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162632962077.15354.4548212112967523910@ietfa.amsl.com> In-Reply-To: <162632962077.15354.4548212112967523910@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Murray Kucherawy's Discuss on draft-ietf-sfc-nsh-integrity-06: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 09:54:46 -0000 SGkgTXVycmF5LCANCg0KVGhhbmtzIGZvciB0aGUgY29tbWVudHMuDQoNCkkgZG9uJ3QgaGF2ZSBt dWNoIHRvIGFkZCB0byB0aGUgRElTQ1VTUyBwb2ludCBpbiBhZGRpdGlvbiB0byB3aGF0IGJvdGgg Sm9lbCBhbmQgbXlzZWxmIHNhaWQgaW4gb3RoZXIgdGhyZWFkcy4gV2UgYWRkZWQgbmV3IHRleHQg YXMgYWdyZWVkIHdpdGggQWx2YXJvIGFuZCBaYWhlZCB0byBtYWtlIHN1cmUgdGhhdCB3ZSBhcmUg cmVmZXJyaW5nIHRvIGFuIG9wdGlvbiB0aGF0IGlzIGRpc2N1c3NlZCBpbiBSRkM4MzAwICsgd2Ug ZG9uJ3QgcmVjb21tZW5kIGFnYWluc3QgdHJhbnNwb3J0IHNlY3VyaXR5LiBXZSB3aWxsIGFkZCB0 aGUgdXBkYXRlIGhlYWRlciBpZiB0aGlzIGlzIHRoZSBjb25jbHVzaW9uIG9mIHRoZSBJRVNHIGRp c2N1c3Npb24uIFdlIHdpbGwgZm9sbG93IE1hcnRpbidzIGd1aWRhbmNlIG9uIHRoaXMuDQoNCkZp eGVkIHRoZSBuaXRzIGFzIHlvdSBjYW4gc2VlIGluOiBodHRwczovL3Rpbnl1cmwuY29tL25zaC1p bnRlZ3JpdHktbGF0ZXN0Lg0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmln aW5lLS0tLS0NCj4gRGXCoDogTXVycmF5IEt1Y2hlcmF3eSB2aWEgRGF0YXRyYWNrZXIgW21haWx0 bzpub3JlcGx5QGlldGYub3JnXQ0KPiBFbnZvecOpwqA6IGpldWRpIDE1IGp1aWxsZXQgMjAyMSAw ODoxNA0KPiDDgMKgOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCj4gQ2PCoDogZHJhZnQtaWV0 Zi1zZmMtbnNoLWludGVncml0eUBpZXRmLm9yZzsgc2ZjLWNoYWlyc0BpZXRmLm9yZzsNCj4gc2Zj QGlldGYub3JnOyBncmVnaW1pcnNreUBnbWFpbC5jb20NCj4gT2JqZXTCoDogTXVycmF5IEt1Y2hl cmF3eSdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1zZmMtbnNoLWludGVncml0eS0NCj4gMDY6ICh3 aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+IA0KPiBNdXJyYXkgS3VjaGVyYXd5IGhhcyBlbnRl cmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiBkcmFmdC1pZXRmLXNmYy1u c2gtaW50ZWdyaXR5LTA2OiBEaXNjdXNzDQo+IA0KPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBr ZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0bw0KPiBhbGwgZW1haWwgYWRk cmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8NCj4g Y3V0IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+IA0KPiANCj4gUGxl YXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3Mt DQo+IGNyaXRlcmlhLmh0bWwNCj4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgRElTQ1VTUyBh bmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+IA0KPiANCj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRo IG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNmYy1uc2gtaW50ZWdyaXR5Lw0KPiAN Cj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLQ0KPiBESVNDVVNTOg0KPiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiAtLQ0KPiANCj4gRW5vdWdoIG90aGVyIEFyZWEgRGlyZWN0b3JzIGhhdmUgc2FpZCwgYW5kIEkg YWdyZWUsIHRoYXQgdGhpcyBzaG91bGQNCj4gb2ZmaWNpYWxseSB1cGRhdGUgUkZDIDgzMDAsIHNv IEknZCBsaWtlIHRvIGhhdmUgdGhlIGRpc2N1c3Npb24uICBJbg0KPiBwYXJ0aWN1bGFyLCBnaXZl biB0aGF0IHRoaXMgd2FzIGlkZW50aWZpZWQgYXMgYSBnYXAgaW4gUkZDIDgzMDAsIGFuZA0KPiBz aW5jZSBJIGRvbid0IHNlZSBhbnkgZXhwbGljaXQgc3RhdGVtZW50IHRoYXQgdGhpcyBpcyBtZWFu dCB0byBiZSBhbg0KPiBvcHRpb25hbCBleHRlbnNpb24sIHNob3VsZG4ndCBpdCBiZSBhbiB1cGRh dGU/DQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4gLS0NCj4gDQo+IE9ubHkgbml0cyB0byBhZGQsIGdpdmVuIHRoZSB0aG9yb3VnaCB0cmVh dG1lbnQgYWxyZWFkeSBnaXZlbiBieQ0KPiBvdGhlcnM6DQo+IA0KPiBTZWN0aW9uIDQuMS4yOiAi VGhlIGZpcnN0IGxldmVsIG9mIGFzc3VyYW5jZSB3aGVyZSBhbGwgTlNIIGRhdGEgLi4uIg0KPiAt LSBhZGQgImlzIiBiZWZvcmUgIndoZXJlIj8gIEFuZCB0aGUgc2FtZSBpc3N1ZSBpbiB0aGUgbmV4 dA0KPiBwYXJhZ3JhcGguDQo+IA0KPiBTZWN0aW9uIDUuMjogcy9Db3Zlcy9Db3ZlcnMvDQo+IA0K PiANCg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQg Y29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVz IGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGll cyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJy ZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBh aW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBl dGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNw b25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZp ZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBj b25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0 ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVk IHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlz IG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2Vk IG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Thu Jul 15 05:52:43 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360573A0E7A; Thu, 15 Jul 2021 05:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 QHjkmYi8sY2s; Thu, 15 Jul 2021 05:52:38 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 DEEC03A0E76; Thu, 15 Jul 2021 05:52:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4GQZ5x2XgBz6G9ds; Thu, 15 Jul 2021 05:52:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1626353557; bh=ooZCR25L1WhC2Wp1quX/i8LsdOVrklCYIlO9sVV2zLg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=muOp7qQQ0qXPVteaxtepk8n9jzmKYK590snoMk0eSpc9hVPLHoCnj6nvWMUMeX/qs 5Ov9RyfOag4mttjtJhL8g9j4F+B5EDGT2eMqL6twqZ1lnbSwQj/vNGNs2M1aFL0LtU 302UKM79zYIJV9AX86KB0CSKEl2wR9CBvfkBfHbc= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4GQZ5w44q6z6G7qD; Thu, 15 Jul 2021 05:52:36 -0700 (PDT) To: Murray Kucherawy , The IESG Cc: gregimirsky@gmail.com, draft-ietf-sfc-nsh-integrity@ietf.org, sfc@ietf.org References: <162632962077.15354.4548212112967523910@ietfa.amsl.com> From: "Joel M. Halpern" Message-ID: Date: Thu, 15 Jul 2021 08:52:34 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <162632962077.15354.4548212112967523910@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] Murray Kucherawy's Discuss on draft-ietf-sfc-nsh-integrity-06: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 12:52:42 -0000 The whole point of the earlier discussion is that this is an optional extension. The fact that if you do it, it is mandatory to do it as described does not make this mandatory for implementations of 8300. None of the words in this document have that effect. if the IESG wants to retroactively change 8300, that may be one of the few things that could actually cause the working group to engage, as folks were strongly against mandating the support for this. Yours, Joel On 7/15/2021 2:13 AM, Murray Kucherawy via Datatracker wrote: > Murray Kucherawy has entered the following ballot position for > draft-ietf-sfc-nsh-integrity-06: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Enough other Area Directors have said, and I agree, that this should officially > update RFC 8300, so I'd like to have the discussion. In particular, given that > this was identified as a gap in RFC 8300, and since I don't see any explicit > statement that this is meant to be an optional extension, shouldn't it be an > update? > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Only nits to add, given the thorough treatment already given by others: > > Section 4.1.2: "The first level of assurance where all NSH data ..." -- add > "is" before "where"? And the same issue in the next paragraph. > > Section 5.2: s/Coves/Covers/ > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Thu Jul 15 06:30:23 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFEE3A00B2; Thu, 15 Jul 2021 06:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrjXToUMUa6e; Thu, 15 Jul 2021 06:30:16 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (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 058283A00AE; Thu, 15 Jul 2021 06:30:15 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr20.francetelecom.fr (ESMTP service) with ESMTPS id 4GQZxK6sr4z1yTJ; Thu, 15 Jul 2021 15:30:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1626355814; bh=tVCRtOaRsqjlLY4nT1CN1orKDplTqLMHzVktL+evd5g=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=X+ZW48LzTLx+eeUv/bRFFZnmEfCf6Jl89llAGfZGMXMF97l9U8BjklQN9j/MU2bvn JiWh06Hhroofb/uv0DPVsqLNShfM+JoOjkXS734p9lOL9/gbVrIqsMNfpArwHdkpzZ H32RJbEiVAmrsQ8FSAaquLOL6MxD/gOrWy0l0tMMjbigjOS9GAJ2yF3OxByTx2GSf/ p4ql1z67Qq51qEVyNOkrdw1a7SVFNc/l8gT9PMSuwAC7fxqUpwtoy0cw/R4ceAxnUg HMSjxz/dx+C47P7IT/3xhjJ05KAdSXXRAnGO9z3t/jK5rZVVjkMUJvysexVQpzwyy7 KJeHH5I5/f+Pg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfednr01.francetelecom.fr (ESMTP service) with ESMTPS id 4GQZxK1kjXzDq7N; Thu, 15 Jul 2021 15:30:13 +0200 (CEST) From: To: Benjamin Kaduk , The IESG CC: "draft-ietf-sfc-nsh-integrity@ietf.org" , "sfc-chairs@ietf.org" , "sfc@ietf.org" , "gregimirsky@gmail.com" Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-sfc-nsh-integrity-06: (with DISCUSS and COMMENT) Thread-Index: AQHXePbUnGtMWTBmlECZ6vxdOGPzS6tD9g8g Date: Thu, 15 Jul 2021 13:30:12 +0000 Message-ID: <31639_1626355813_60F03865_31639_1_1_787AE7BB302AE849A7480A190F8B9330353BF7EE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162629795136.25767.17850752260179612361@ietfa.amsl.com> In-Reply-To: <162629795136.25767.17850752260179612361@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Benjamin Kaduk's Discuss on draft-ietf-sfc-nsh-integrity-06: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 13:30:21 -0000 SGkgQmVuLCANCg0KVGhhbmsgeW91IGZvciB0aGUgcmV2aWV3LiBNdWNoIGFwcHJlY2lhdGVkLiAN Cg0KU3RhcnRpbmcgd2l0aCB0aGUgZWFzeSBwYXJ0IChOSVRTKSBhcyB3ZSBuZWVkIG1vcmUgdGlt ZSB0byB0aGluayBhYm91dCB5b3VyIHBvaW50KDApIGFuZCBpdHMgaW1wYWN0IG9uIG1hbnkgQ09N TUVOVCBwb2ludHMuIA0KDQpGWUksIHdlIHVzZWQgdG8gaGF2ZSBhIGRpc2N1c3Npb24gb24gQUVT LUdDTSBpbiB0aGUgcGFzdCwgYnV0IHdlIHdlbnQgZm9yIHRoZSBjdXJyZW50IGRlc2lnbiBhcyB3 ZSB3YW50ZWQgdG8gaW1wb3NlIGJ5IGRlc2lnbiB0aGUgc2VwYXJhdGlvbiBiZXR3ZWVuIGVudGl0 aWVzIHRoYXQgYWNjZXNzIHRoZSBlbmNyeXB0ZWQgZGF0YSBhbmQgYXZvaWQgdGhlIGV4dHJhIDEy OCBiaXRzIG92ZXJoZWFkLiBUaGVyZSB3YXMgYWxzbyBhIGRpc2N1c3Npb24gYWJvdXQgdGhlIHBh cmFsbGVsaXphdGlvbiBwcm92aWRlZCBieSBzZXBhcmF0aW5nIHRoZSB0d28gb3BlcmF0aW9ucy4g IA0KDQpBbnl3YXksIHdlIHdpbGwgZm9sbG93IFNPT04gb24gdGhlIERJU0NVU1MgYW5kIENPTU1F TlQgcGFydHMgd2l0aCBjb25jcmV0ZSBwcm9wb3NhbHMgdG8gaG9wZWZ1bGx5IGZpeCB0aGVtLiAN Cg0KVGhlIGNoYW5nZXMgY2FuIGJlIHRyYWNrZWQgYXQ6IGh0dHBzOi8vdGlueXVybC5jb20vbnNo LWludGVncml0eS1sYXRlc3QgDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29y aWdpbmUtLS0tLQ0KPiBEZcKgOiBCZW5qYW1pbiBLYWR1ayB2aWEgRGF0YXRyYWNrZXIgW21haWx0 bzpub3JlcGx5QGlldGYub3JnXQ0KPiBFbnZvecOpwqA6IG1lcmNyZWRpIDE0IGp1aWxsZXQgMjAy MSAyMzoyNg0KPiDDgMKgOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCj4gQ2PCoDogZHJhZnQt aWV0Zi1zZmMtbnNoLWludGVncml0eUBpZXRmLm9yZzsgc2ZjLWNoYWlyc0BpZXRmLm9yZzsNCj4g c2ZjQGlldGYub3JnOyBncmVnaW1pcnNreUBnbWFpbC5jb207IGdyZWdpbWlyc2t5QGdtYWlsLmNv bQ0KPiBPYmpldMKgOiBCZW5qYW1pbiBLYWR1aydzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1zZmMt bnNoLWludGVncml0eS0wNjoNCj4gKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gDQo+IEJl bmphbWluIEthZHVrIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZv cg0KPiBkcmFmdC1pZXRmLXNmYy1uc2gtaW50ZWdyaXR5LTA2OiBEaXNjdXNzDQo+IA0KPiBXaGVu IHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBs eSB0bw0KPiBhbGwgZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGlu ZXMuIChGZWVsIGZyZWUgdG8NCj4gY3V0IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93 ZXZlci4pDQo+IA0KPiANCj4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2ll c2cvc3RhdGVtZW50L2Rpc2N1c3MtDQo+IGNyaXRlcmlhLmh0bWwNCj4gZm9yIG1vcmUgaW5mb3Jt YXRpb24gYWJvdXQgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+IA0KPiANCj4gVGhl IGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3Vu ZCBoZXJlOg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNm Yy1uc2gtaW50ZWdyaXR5Lw0KPiANCj4gDQpbLi5dDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLQ0K PiBDT01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLQ0KPiANClsuLl0NCj4gTklUUw0KPiANCj4g U2VjdGlvbiAxDQo+IA0KPiAgICBuZXR3b3JrIGluZnJhc3RydWN0dXJlcyBhZ2FpbnN0IHRoZW0s IG5ldHdvcmsgc2xpY2luZywgZXRjLg0KPiBCZWNhdXNlDQo+ICAgIG9mIHRoZSBwcm9saWZlcmF0 aW9uIG9mIHN1Y2ggYWR2YW5jZWQgU0ZzIHRvZ2V0aGVyIHdpdGggY29tcGxleA0KPiAgICBzZXJ2 aWNlIGRlcGxveW1lbnQgY29uc3RyYWludHMgdGhhdCBkZW1hbmQgbW9yZSBhZ2lsZSBzZXJ2aWNl DQo+ICAgIGRlbGl2ZXJ5IHByb2NlZHVyZXMsIG9wZXJhdG9ycyBuZWVkIHRvIHJhdGlvbmFsaXpl IHRoZWlyIHNlcnZpY2UNCj4gICAgZGVsaXZlcnkgbG9naWNzIGFuZCBtYXN0ZXIgdGhlaXIgY29t cGxleGl0eSB3aGlsZSBvcHRpbWlzaW5nDQo+IHNlcnZpY2UNCj4gICAgYWN0aXZhdGlvbiB0aW1l IGN5Y2xlcy4gIFRoZSBvdmVyYWxsIHByb2JsZW0gc3BhY2UgaXMgZGVzY3JpYmVkDQo+IGluDQo+ ICAgIFtSRkM3NDk4XS4NCj4gDQo+IFRoZSAidGhlaXIiIGluICJtYXN0ZXIgdGhlaXIgY29tcGxl eGl0eSIgaXMgYSBiaXQgYW1iaWd1b3VzIGJldHdlZW4NCj4gIm9wZXJhdG9ycyIgYW5kICJzZXJ2 aWNlIGRlbGl2ZXJ5IGxvZ2ljcyINCg0KW01lZF0gcy90aGVpci9pdHMNCg0KDQogKG5vdGluZyB0 aGF0IHRoZSBwcmV2aW91cw0KPiB1c2Ugb2YgInRoZWlyIiBkaWQgcmVmZXIgdG8gIm9wZXJhdG9y cyIpLiAgKFRoZSBzZW50ZW5jZSBhcyBhIHdob2xlDQo+IHJlYWRzIGEgYml0IGxpa2UgbWFya2V0 aW5nIGxhbmd1YWdlLCBidXQgdGhhdCdzIG5vdCBpbnRlbmRlZCB0byBiZQ0KPiBhbiBhY3Rpb25h YmxlDQo+IGNvbW1lbnQuKQ0KPiANCj4gICAgVGhpcyBzcGVjaWZpY2F0aW9uIGZpbGxzIHRoYXQg Z2FwLiAgQ29uY3JldGVseSwgdGhpcyBkb2N1bWVudA0KPiBhZGRzDQo+ICAgIGludGVncml0eSBw cm90ZWN0aW9uIGFuZCBvcHRpb25hbCBlbmNyeXB0aW9uIG9mIHNlbnNpdGl2ZQ0KPiBtZXRhZGF0 YQ0KPiAgICBkaXJlY3RseSB0byB0aGUgTlNIIChTZWN0aW9uIDQpOyBpbnRlZ3JpdHkgcHJvdGVj dHMgdGhlIHBhY2tldA0KPiAgICBwYXlsb2FkIGFuZCBwcm92aWRlcyByZXBsYXkgcHJvdGVjdGlv biAoU2VjdGlvbiA3LjQpLiAgWy4uLl0NCj4gDQo+IFRoZSBjbGF1c2UgYWZ0ZXIgdGhlIHNlbWlj b2xvbiBuZWVkcyB0byBiZSBhYmxlIHRvIHN0YW5kIGFsb25lIGFzIGENCj4gY29tcGxldGUgc2Vu dGVuY2UgaW4gb3JkZXIgdG8gYmUgZ3JhbW1hdGljYWwsIGJ1dCBpdCBjdXJyZW50bHkgaGFzDQo+ IG5vIHN1YmplY3QuICBNYXliZSBwcmVmaXhpbmcgIml0IGFsc28iIHdvdWxkIGJlIGVub3VnaCB0 byBmaXggaXQuDQoNCltNZWRdIE9LIHRvIHN0YXJ0IGEgbmV3IHNlbnRlbmNlLiANCg0KPiANCj4g U2VjdGlvbiA0LjEuMg0KPiANCj4gICAgVGhlIGludGVncml0eSBwcm90ZWN0aW9uIHNjb3BlIGlz IGV4cGxpY2l0bHkgc2lnbmFsZWQgdG8gTlNILQ0KPiBhd2FyZQ0KPiAgICBTRnMgYW5kIFNGQyBw cm94aWVzIGluIHRoZSBOU0ggYnkgbWVhbnMgb2YgYSBkZWRpY2F0ZWQgTUQgVHlwZQ0KPiAgICAo U2VjdGlvbiA1KS4NCj4gDQo+IFNpZ25hbGVkIHRvIFNGRnMgYXMgd2VsbCwgc2luY2UgaW4gdGhl IHNlY29uZCBMb0EgdGhleSBjYW4gdXNlIGl0Lg0KDQpbTWVkXSBZZXMuIA0KDQo+IA0KPiBTZWN0 aW9uIDQuNg0KPiANCj4gICAgQXMgZGlzY3Vzc2VkIGluIFtSRkM4NDU5XSwgYW4gU0ZDLWVuYWJs ZWQgZG9tYWluIChjYWxsZWQsIHVwcGVyLQ0KPiBsZXZlbA0KPiAgICBkb21haW4pIG1heSBiZSBk ZWNvbXBvc2VkIGludG8gbWFueSBzdWItZG9tYWlucyAoY2FsbGVkLCBsb3dlci0NCj4gbGV2ZWwN Cj4gICAgZG9tYWlucykuICBJbiBvcmRlciB0byBhdm9pZCBtYWludGFpbmluZyBzdGF0ZSB0byBy ZXN0b3JlIGJhY2sNCj4gdXBwZXItDQo+ICAgIGxvd2VyIE5TSCBpbmZvcm1hdGlvbiBhdCB0aGUg Ym91bmRhcmllcyBvZiBsb3dlci1sZXZlbCBkb21haW5zLA0KPiB0d28NCj4gDQo+IEkgdGhpbmsg cy91cHBlci1sb3dlci91cHBlci1sYXllci8gKGFjcm9zcyB0aGUgbGluZSBicmVhayk/DQoNCltN ZWRdIFllcywgY2hhbmdlZCB0byAidXBwZXItbGV2ZWwiLiANCg0KPiANCj4gU2VjdGlvbiA1LjEN Cj4gDQo+ICAgIE1BQyMxIENvbnRleHQgSGVhZGVyIGlzIGEgdmFyaWFibGUtbGVuZ3RoIENvbnRl eHQgSGVhZGVyIHRoYXQNCj4gY2Fycmllcw0KPiAgICB0aGUgTWVzc2FnZSBBdXRoZW50aWNhdGlv biBDb2RlIChNQUMpIGZvciB0aGUgU2VydmljZSBQYXRoDQo+IEhlYWRlciwNCj4gICAgQ29udGV4 dCBIZWFkZXJzLCBhbmQgdGhlIGlubmVyIHBhY2tldCBvbiB3aGljaCBOU0ggaXMgaW1wb3NlZCwN Cj4gICAgY2FsY3VsYXRlZCB1c2luZyBNQUNfS0VZIGFuZCBvcHRpb25hbGx5IENvbnRleHQgSGVh ZGVycyBlbmNyeXB0ZWQNCj4gICAgdXNpbmcgRU5DX0tFWS4gIFsuLi5dDQo+IA0KPiBDb21tYSBh ZnRlciAiY2FsY3VsYXRlZCB1c2luZyBNQUNfS0VZIiwgcGxlYXNlLiANCg0KW01lZF0gRml4ZWQs IGJ1dCB0aGF0IEknbSBhZnJhaWQgdGhhdCB3ZSB3aWxsIHRvdWNoIHRoaXMgb25jZSB3ZSBmaXgg eW91ciBkaXNjdXNzIHBvaW50ICgwKS4NCg0KICgib3B0aW9uYWxseQ0KPiBDb250ZXh0IEhlYWRl cnMgWy4uLl0iIGFyZSBub3QgdXNlZCBhbG9uZyB3aXRoIE1BQ19LRVkgaW4gdGhlDQo+IGNhbGN1 bGF0aW9uKQ0KPiANCj4gU2VjdGlvbiA1LjINCj4gDQo+ICAgIE1lc3NhZ2UgQXV0aGVudGljYXRp b24gQ29kZTogIENvdmVzIHRoZSBlbnRpcmUgTlNIIGRhdGEuICBUaGUNCj4gDQo+IHMvQ292ZXMv Q292ZXJzLw0KPiANCg0KW01lZF0gRml4ZWQuIA0KDQo+IFNlY3Rpb24gNg0KPiANCj4gICAgICAg VGhlIGVwb2NoIGlzIDE5NzAtMDEtMDFUMDA6MDBaIGluIFVUQyB0aW1lLiAgWy4uLl0NCj4gDQo+ IChJSVVDLCB0aGUgImluIFVUQyB0aW1lIiBpcyByZWR1bmRhbnQgd2l0aCB0aGUgdHJhaWxpbmcg J1onLikNCg0KW01lZF0gUmlnaHQuIA0KDQo+IA0KPiBTZWN0aW9uIDcuMQ0KPiANCj4gICAgZWxl bWVudC4gIFRoZSBkZXRhaWxzIG9mIHNlbmRpbmcgbm90aWZpY2F0aW9uIGFsYXJtcyAoaS5lLiwg dGhlDQo+ICAgIHBhcmFtZXRlcnMgYWZmZWN0aW5nIHRoZSB0cmFuc21pc3Npb24gb2YgdGhlIG5v dGlmaWNhdGlvbiBhbGFybXMNCj4gICAgZGVwZW5kIG9uIHRoZSBpbmZvcm1hdGlvbiBpbiB0aGUg Y29udGV4dCBoZWFkZXIgc3VjaCBhcw0KPiBmcmVxdWVuY3ksDQo+ICAgIHRocmVzaG9sZHMsIGFu ZCBjb250ZW50IGluIHRoZSBhbGFybSkgU0hPVUxEIGJlIGNvbmZpZ3VyYWJsZS4NCj4gDQo+IFRo ZSBncmFtbWFyIGluIHRoZSBwYXJlbnRoZXRpY2FsIHNlZW1zIG9mZiB0byBtZS4gIFBvc3NpYmx5 DQo+IHMvZGVwZW5kL2RlcGVuZGluZy8gd291bGQgYmUgYSBmaXgsIGJ1dCBJJ20gbm90IHN1cmUu DQoNCltNZWRdIE1hZGUgdGhlc2UgY2hhbmdlczogDQoNCnMvYWZmZWN0aW5nL3RoYXQgYWZmZWN0 DQpzL2RlcGVuZC9kZXBlbmRpbmcvDQoNCj4gDQo+ICAgIE5TSC1hd2FyZSBTRnMgYW5kIFNGQyBw cm94aWVzIE1VU1QgcmUtYXBwbHkgdGhlIGludGVncml0eQ0KPiBwcm90ZWN0aW9uDQo+ICAgIGlm IGFueSBtb2RpZmljYXRpb24gaXMgbWFkZSB0byB0aGUgQ29udGV4dCBIZWFkZXJzIChzdHJpcCBh DQo+IENvbnRleHQNCj4gICAgSGVhZGVyLCB1cGRhdGUgdGhlIGNvbnRlbnQgb2YgYW4gZXhpc3Rp bmcgQ29udGV4dCBIZWFkZXIsIGluc2VydA0KPiBhDQo+ICAgIG5ldyBDb250ZXh0IEhlYWRlciku DQo+IA0KPiBJIHRoaW5rIG1heWJlIGFuICJlLmcuLCIgaW4gdGhlIHBhcmVudGhldGljYWwgaXMg aW4gb3JkZXIsIHNpbmNlDQo+IHRoaXMgZG9lc24ndCBzZWVtIHRvIGluY2x1ZGUgdGhpbmdzIGxp a2UgImRlY3JlbWVudCB0aGUgVFRMIi4NCg0KW01lZF0gRml4ZWQuIA0KDQo+IA0KPiBTZWN0aW9u IDkNCj4gDQo+ICAgIFRoZSBpbnRlcmFjdGlvbiBiZXR3ZWVuIHRoZSBTRkMgZGF0YSBwbGFuZSBl bGVtZW50cyBhbmQgYSBrZXkNCj4gICAgbWFuYWdlbWVudCBzeXN0ZW0gTVVTVCBOT1QgYmUgdHJh bnNtaXR0ZWQgaW4gY2xlYXIgc2luY2UgdGhpcw0KPiB3b3VsZA0KPiAgICBjb21wbGV0ZWx5IGRl c3Ryb3kgdGhlIHNlY3VyaXR5IGJlbmVmaXRzIG9mIHRoZSBpbnRlZ3JpdHkNCj4gcHJvdGVjdGlv bg0KPiAgICBzb2x1dGlvbiBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQuICBUaGUgc2VjcmV0IGtl eSAoSykgbXVzdCBoYXZlDQo+IGFuDQo+ICAgIGV4cGlyYXRpb24gdGltZSBhc3NpZ25lZCBhcyB0 aGUgbGF0ZXN0IHBvaW50IGluIHRpbWUgYmVmb3JlIHdoaWNoDQo+IHRoZQ0KPiANCj4gVGhpcyBm aXJzdCBzZW50ZW5jZSBzZWVtcyBsaWtlIGl0IGNvdWxkIHByb2JhYmx5IGJlIGEgcGFyYWdyYXBo IG9mDQo+IGl0cyBvd247IHRoZSBzdWJzZXF1ZW50IGRpc2N1c3Npb24gb2YgZXhwaXJhdGlvbiB0 aW1lIHNlZW1zIHRvIGJlDQo+IG1vc3RseSB1bnJlbGF0ZWQuDQoNCltNZWRdIFdvcmtzIGZvciBt ZS4gRml4ZWQuDQoNCj4gDQo+IFdlIG1pZ2h0IGFsc28gYWRkIGFub3RoZXIgc2VudGVuY2UgdG8g cmVpdGVyYXRlIHRoYXQgInRoZSBzZWN1cml0eQ0KPiBhbmQgaW50ZWdyaXR5IG9mIHRoZSBrZXkt ZGlzdHJpYnV0aW9uIG1lY2hhbmlzbSBpcyB2aXRhbCB0byB0aGUNCj4gc2VjdXJpdHkgb2YgdGhl IHN5c3RlbSBhcyBhIHdob2xlIi4NCg0KW01lZF0gQWRkZWQuIA0KDQo+IA0KPiAgICBvICBBdHRh Y2tlciByZXBsYWNpbmcgdGhlIHBhY2tldCBvbiB3aGljaCB0aGUgTlNIIGlzIGltcG9zZWQgd2l0 aA0KPiBhDQo+ICAgICAgIGJvZ3VzIHBhY2tldC4NCj4gDQo+IEknZCBwcm9iYWJseSBzYXkgIm1v ZGlmaWVkIG9yIGJvZ3VzIi4NCg0KW01lZF0gRml4ZWQuIA0KDQo+IA0KPiAgICBJbiBhbiBTRkMt ZW5hYmxlZCBkb21haW4gd2hlcmUgdGhlIGFib3ZlIGF0dGFja3MgYXJlIHBvc3NpYmxlLA0KPiAo MSkNCj4gDQo+IFRoaXMgaXMgcGVyaGFwcyBhbWJpZ3VvdXMgYWJvdXQgd2hldGhlciBhbiAiYW55 IiBvciAiYWxsIiBjcml0ZXJpb24NCj4gc2hvdWxkIGJlIHVzZWQuICBQZXJoYXBzIHRoYXQncyBk ZXNpcmVkIDopDQo+IA0KDQpbTWVkXSBJIHRoaW5rIHlvdSBnb3QgaXQgOi0pDQoNCgpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f CgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBp bmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50 IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlz YXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXog bGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBw aWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGli bGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kg Y2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhp cyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9y IHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhl eSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhv cmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFj aG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZv ciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQu ClRoYW5rIHlvdS4KCg== From nobody Thu Jul 15 07:03:35 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C13C43A0D7A; Thu, 15 Jul 2021 07:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyHtzn4EUifu; Thu, 15 Jul 2021 07:03:23 -0700 (PDT) Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (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 36D303A0D75; Thu, 15 Jul 2021 07:03:23 -0700 (PDT) Received: by mail-ua1-x92f.google.com with SMTP id q20so2145739uaa.3; Thu, 15 Jul 2021 07:03:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jg2yo6dUCv9XzJ+ck3QVRKUr6RUjq+sYjEOGWWGYefY=; b=n0uA4uO4nnM/oefEdNOIpXhU7P2zAfymAqDSwfDgyAqysdyTwR31+/DRxVKF8xBuW8 u4KtCqSRh7ECi7a1Ls88sXgv9TSFff1U/TyHgJGjRThq+MZRGmx3OJoiR5Db47gee54O kCKbQzooKhKeOHNGDDfvL2qyQaFMW8HfHmeSK+26CHX6CntzMu7oGeiBGmUtUelQwLdf R9cVtsiEqCwGoDT7H7630qT05QYki2zGMrVeeq1qnSF3C5JgpOU6qe3V5OP53JqCJvQg OPtprGCjAzAZrTAO+RCPQSsjzZ4Yp/1O7yU/Jz/NtwhP2wm/xWqedZHwUmfDh7yYzZfR OFXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jg2yo6dUCv9XzJ+ck3QVRKUr6RUjq+sYjEOGWWGYefY=; b=KWin5vFC9XosBZbGurG3DhFZwIrATA8IbJRLZ2UIx4SFE8Rf+Y2y9TkUwdbs4+m7UX Y/I7wX4TG9mUYy3WwcgKRCRNUDD06MQNrUzGl0v6mvVVkGRNMBsCKdXpzTJlHCExBWJd 9g2f9Qm9NrzaOraYh3wn/YiIO0XCXRS9T0wAmC+KH2fTtnTBfrFRSW7zGoRN67AFLav8 WbUI7sUiIH3TMoypCJ1UZe5QnPrBdLJEQZNQAIa2LYdbkLQ0lgNR7ok/lrgv9S0YTg4g p2mxnuid10btHWKT+7wmYwsC7XPUPTKc44tIxvDvk5nH34RqsBV214fZmQAFzasjINez Mjyw== X-Gm-Message-State: AOAM532X5/GhrB7lifyS+WoKNV2CY6ymzvMNMm8s0gvFD9SSxl1ntwJE Joht5OaAfT0j4CngJHmdUPa2d9p6W+ROjX03SMA= X-Google-Smtp-Source: ABdhPJzgztghu0arye1DxDuyOpUHS4LvDx/q3QtCEtqqaLnwaEU4qIFmoP1dP5MWaSLbpNn1xlOKKjHO6pJM5++myeg= X-Received: by 2002:ab0:7023:: with SMTP id u3mr7212009ual.76.1626357801819; Thu, 15 Jul 2021 07:03:21 -0700 (PDT) MIME-Version: 1.0 References: <162632962077.15354.4548212112967523910@ietfa.amsl.com> <7171_1626342870_60F005D6_7171_103_3_787AE7BB302AE849A7480A190F8B9330353BF653@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <7171_1626342870_60F005D6_7171_103_3_787AE7BB302AE849A7480A190F8B9330353BF653@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: "Murray S. Kucherawy" Date: Thu, 15 Jul 2021 07:03:10 -0700 Message-ID: To: mohamed.boucadair@orange.com Cc: The IESG , "draft-ietf-sfc-nsh-integrity@ietf.org" , "sfc-chairs@ietf.org" , "sfc@ietf.org" , "gregimirsky@gmail.com" Content-Type: multipart/alternative; boundary="0000000000000e20d905c729efc6" Archived-At: Subject: Re: [sfc] Murray Kucherawy's Discuss on draft-ietf-sfc-nsh-integrity-06: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 14:03:30 -0000 --0000000000000e20d905c729efc6 Content-Type: text/plain; charset="UTF-8" On Thu, Jul 15, 2021 at 2:54 AM wrote: > I don't have much to add to the DISCUSS point in addition to what both > Joel and myself said in other threads. We added new text as agreed with > Alvaro and Zahed to make sure that we are referring to an option that is > discussed in RFC8300 + we don't recommend against transport security. We > will add the update header if this is the conclusion of the IESG > discussion. We will follow Martin's guidance on this. > I honestly did try to find such a thread before posting my position. I apologize for missing it. I'll find and review that, and then get out of your way. -MSK --0000000000000e20d905c729efc6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jul 15, 2021 at 2:54 AM <mohamed.boucadair@orange.com= > wrote:
I don't have much to add to the DISCUSS point in= addition to what both Joel and myself said in other threads. We added new = text as agreed with Alvaro and Zahed to make sure that we are referring to = an option that is discussed in RFC8300 + we don't recommend against tra= nsport security. We will add the update header if this is the conclusion of= the IESG discussion. We will follow Martin's guidance on this.

I honestly did try to find such a thread befor= e posting my position.=C2=A0 I apologize for missing it.=C2=A0 I'll fin= d and review that, and then get out of your way.

-= MSK
--0000000000000e20d905c729efc6-- From nobody Thu Jul 15 07:28:20 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE8D3A12BB; Thu, 15 Jul 2021 07:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMLZFS-S3P3K; Thu, 15 Jul 2021 07:28:10 -0700 (PDT) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (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 E7B153A12B7; Thu, 15 Jul 2021 07:28:09 -0700 (PDT) Received: by mail-vs1-xe30.google.com with SMTP id j8so3153290vsd.0; Thu, 15 Jul 2021 07:28:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3P7Z1EXJJVTN7+kvSeq/jXge8CDRooTDH25BPk+tulY=; b=svtsKDmQh0DPr6+wTkguQnm+Uf1mYAkvU4537rh09I+6dzOPBdemSm/+cZUXg13nkV guk2bcFgWiWLSbISqW8CRuM6DmyYQy5s+9A/+BDsg3FyBeYLP2s7CsXzDL0h1YwdcmXk jPOEE1MzSVX/XJpZ3C5FKN1yc9IjpriVG1qYF+rkdhTrStj1S2rNhONe1T7vZGguO0bz CLy+gmGzkQ6pSWH/i6+rNPISqjcbmczPN9f6hydGB/WG8jzSj5UVn2yUsMT/8zHo79oj kvDeMlm9EaWdNvkh4/NWO/PRcd5dtNzCVgkVLBFV8K39Eiko9tjHZks+mg2Ac4mtGH/F k2+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3P7Z1EXJJVTN7+kvSeq/jXge8CDRooTDH25BPk+tulY=; b=JvaaZuWCg6PKfUhlTYTC8tSCYVMxD3l94CIDH+5tr+0Ead7PGwmmuia0TdChnQp/C8 baztxblMilnHIbT833WQiR0ctNaBeOmVX7CT/yyFlvIdNa1imIS0zAsMuX1ajaQJ+4b4 mDGrVjUDVbnrB158Qx4SlvrzMqnONT41wNT/AGmvI3W4pcvSjS/IJlSoudFJS1hA3XNj Lhbh6OHUVKedppyWxDMTkOspVybfYr075P9Di/G1iu4uOgNTAWOEjAMiPpMauMVoH2gK BomOBsqIfq6fwUgFs9oQ1WKYybOtctMQTHd0aYP9JzziQQUT2NaWKGHl2U7alUKvPNjc LFHw== X-Gm-Message-State: AOAM532nihgAjLk5g/OeKf7o0c8O/98ojiDlwDR5N/eev4HUNcKKbaCO oJplKZu+2/vyvPvC75YoQjTQSlOSmSMR/CFtOEA= X-Google-Smtp-Source: ABdhPJyAISdKNL2vnq2g4iM1uLJiNn8H+uryXI5OSeR5wCfO4utwwiVuVw+BxFd5zP9BlFGAMdTkERozXFWMTwkOOqQ= X-Received: by 2002:a05:6102:30a3:: with SMTP id y3mr6559759vsd.33.1626359288369; Thu, 15 Jul 2021 07:28:08 -0700 (PDT) MIME-Version: 1.0 References: <162611498183.7775.3562397379733537345@ietfa.amsl.com> <23837_1626115941_60EC8F65_23837_478_1_787AE7BB302AE849A7480A190F8B9330353BD8C2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <13781_1626118873_60EC9AD9_13781_9_1_787AE7BB302AE849A7480A190F8B9330353BDA95@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <13781_1626118873_60EC9AD9_13781_9_1_787AE7BB302AE849A7480A190F8B9330353BDA95@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: "Murray S. Kucherawy" Date: Thu, 15 Jul 2021 07:27:57 -0700 Message-ID: To: mohamed.boucadair@orange.com Cc: Alvaro Retana , The IESG , "gregimirsky@gmail.com" , "draft-ietf-sfc-nsh-integrity@ietf.org" , "sfc-chairs@ietf.org" , "sfc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a9163b05c72a475c" Archived-At: Subject: Re: [sfc] Alvaro Retana's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 14:28:15 -0000 --000000000000a9163b05c72a475c Content-Type: text/plain; charset="UTF-8" On Mon, Jul 12, 2021 at 12:41 PM wrote: > [Med] Not sure about this given that RFC8300 says the following: > > NSH itself does not mandate protocol-specific integrity > protection. However, if an operator deems protection is required, > several options are viable: > > 1. SFF/SF NSH verification > ... > 2. Transport Security > ... > 3. NSH Variable Header-Based Integrity > > Lastly, NSH MD Type 2 provides, via variable-length headers, > the ability to append cryptographic integrity protection to > the NSH packet. The implementation of such a scheme is > outside the scope of this document. > > The I-D is basically the third option. > One of the things an "Updates" gives us is a forward pointer from RFC 8300 to this document. I think when presented in the context you have here, the notion of such linkage is better than "useless". -MSK --000000000000a9163b05c72a475c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jul 12, 2021 at 12:41 PM <mohamed.boucadair@orange.com> wrote:
[Med] Not sure about this given that RFC8300 says t= he following:=C2=A0

=C2=A0 =C2=A0 =C2=A0 NSH itself does not mandate protocol-specific integrit= y
=C2=A0 =C2=A0 =C2=A0 protection.=C2=A0 However, if an operator deems protec= tion is required,
=C2=A0 =C2=A0 =C2=A0 several options are viable:

=C2=A0 =C2=A0 =C2=A0 1.=C2=A0 SFF/SF NSH verification
=C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 =C2=A0 2.=C2=A0 Transport Security
=C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 =C2=A0 3.=C2=A0 NSH Variable Header-Based Integrity

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Lastly, NSH MD Type 2 provides, via vari= able-length headers,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the ability to append cryptographic inte= grity protection to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the NSH packet.=C2=A0 The implementation= of such a scheme is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 outside the scope of this document.

The I-D is basically the third option.

One of the things an "Updates" gives us is a forward pointer fro= m RFC 8300 to this document.=C2=A0 I think when presented in the context yo= u have here, the notion of such linkage is better than "useless".=

--000000000000a9163b05c72a475c-- From nobody Thu Jul 15 07:33:04 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256843A1315; Thu, 15 Jul 2021 07:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ymtn7-adRw4; Thu, 15 Jul 2021 07:32:55 -0700 (PDT) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 3100C3A130F; Thu, 15 Jul 2021 07:32:50 -0700 (PDT) Received: by mail-ua1-x934.google.com with SMTP id c20so2177425uar.12; Thu, 15 Jul 2021 07:32:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cwViMiUAqgGHI0mtEkLlg2yXDSLufzN0MEqhlBythok=; b=uL9VV7c3vaWVOcTH2UgN4RnDoT4YSrKluQhX7ZRaRHKAL9vKV16lKVcfQWtZxzSx/w qYKZ6F6lg9dyRuK3FBQa3IgJ07IGt2PuMXKCs2CMTVBrkmqHKQi/FM5aV3Y3lw3dVm7Z FRTCNlesXlLjT34w1QrhRkm1D/FgHUuBSfNNv5TGIifkO3rITkZtgTcShm8CoGbfJ1ZJ sImtnGXmBR2+ivObssafxVjlZM++kBPx5kGgfyDKca9p3y++LflBs1scxmUYSQToYuPH ZvzB1IGV81jKO9Qo6chZMg5zI32AnuZ8J69pfc0yLGrGwhOYa/5S4Do8U7OkF35c2O6R dmog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cwViMiUAqgGHI0mtEkLlg2yXDSLufzN0MEqhlBythok=; b=gMrfC4k9LiT7E/HXO3d0bliga9CYLwSkdxfQ4GcH4zqJ1dj4BBbpHayFxhHVXMcUYq kyywNB4LeL3irpeGMBe10w35r+ozNrTT0UHOtzOY323f6AbwfEUr5qjxJVQdgDAqMejg 5Fkxypn9+HWDdFIwiifZHITOfXGahztEtEM76mKMrLro+rd/HL7rA2bLUUh9TVkL45dz tp5xipvDfpWKILhSXYSgqcFUMtd9nXGoiFs1F5YDPuHFuo6mMNKKBJY5k2oyaHVgYNW4 PduJ69D6nQyWO0tRrE1hLvAkxexH5KgP+kVdBUt+kK4fqutk/lE1MozLp5gLAjSByWpw j8Rg== X-Gm-Message-State: AOAM533OVngKzorVXxHI+v8Uh3f5qgF/7HD+DPRY+EY0Jahok8PLQChz VpjgJJ5RuXTL+eUwK06tQoauqYtFA8OajGMsHK4= X-Google-Smtp-Source: ABdhPJwLPZLprdrhY4RleEFMNSThSq2KnwGhZ58vrA96FvplvrqCfK0vlqzODeTLfvv3Hx4YobHiu1nO6faA9uGtaxQ= X-Received: by 2002:ab0:7e94:: with SMTP id j20mr7441939uax.87.1626359568874; Thu, 15 Jul 2021 07:32:48 -0700 (PDT) MIME-Version: 1.0 References: <162611498183.7775.3562397379733537345@ietfa.amsl.com> <1a5ae768-bf12-6d94-819c-7923e1f816ee@joelhalpern.com> In-Reply-To: <1a5ae768-bf12-6d94-819c-7923e1f816ee@joelhalpern.com> From: "Murray S. Kucherawy" Date: Thu, 15 Jul 2021 07:32:37 -0700 Message-ID: To: "Joel M. Halpern" Cc: Alvaro Retana , The IESG , Greg Mirsky , draft-ietf-sfc-nsh-integrity@ietf.org, Service Function Chaining IETF list Content-Type: multipart/alternative; boundary="00000000000061405705c72a5848" Archived-At: Subject: Re: [sfc] Alvaro Retana's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 14:33:00 -0000 --00000000000061405705c72a5848 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 12, 2021 at 12:38 PM Joel M. Halpern wrote: > 2) The discussion happened when 8300 was being approved. We agreed with > the IESG that we would not define a mandatory-to-implement NSH security > mechanism, but that we would add an optional NSH security mechanism. > Which this draft does. > I think on reading the document, I didn't find it clear that this was an optional thing or an extension. It read to me a lot more like it was filling an important gap left by RFC 8300, which to me leans much more firmly in the direction that it's appropriate to call it an update. -MSK --00000000000061405705c72a5848 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
2) The discussion happened when 8300 was being approv= ed.=C2=A0 We agreed with
the IESG that we would not define a mandatory-to-implement NSH security mechanism, but that we would add an optional NSH security mechanism.
Which this draft does.

I think on readi= ng the document, I didn't find it clear that this was an optional thing= or an extension.=C2=A0 It read to me a lot more like it was filling an imp= ortant gap left by RFC 8300, which to me leans much more firmly in the dire= ction that it's appropriate to call it an update.

-MSK
--00000000000061405705c72a5848-- From nobody Thu Jul 15 07:47:55 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 020D73A0D3D; Thu, 15 Jul 2021 07:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 IICvB1ubMEt5; Thu, 15 Jul 2021 07:47:46 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 67F7D3A0C37; Thu, 15 Jul 2021 07:47:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4GQcfj09w3z1nsdX; Thu, 15 Jul 2021 07:47:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1626360461; bh=l4vKSz1uCAQbolyiTxQLl4IqRoaMTj+9Z2D++Jzxskw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=rAjqAJfc8QR421JZF9/Xw5i82eodnNmjL+/4oRKOjgVlZDz42g4DLDLRXgSmX10MT EP48ZCHY7HLJmjrAtUbXmQrHrvAEFcvanU6kgvTUhyHY5DjN5t1ZhdCh09CrZWxRhQ VdVA6vxhJG0UVOjQzpwRpV8Qm04ji3Uo1lzfuJ+0= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4GQcfg62htz1ntvW; Thu, 15 Jul 2021 07:47:39 -0700 (PDT) To: "Murray S. Kucherawy" Cc: Alvaro Retana , The IESG , Greg Mirsky , draft-ietf-sfc-nsh-integrity@ietf.org, Service Function Chaining IETF list References: <162611498183.7775.3562397379733537345@ietfa.amsl.com> <1a5ae768-bf12-6d94-819c-7923e1f816ee@joelhalpern.com> From: Joel Halpern Direct Message-ID: <758d4dcf-5cdb-e493-a6bc-554024be6b62@joelhalpern.com> Date: Thu, 15 Jul 2021 10:47:39 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] Alvaro Retana's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 14:47:51 -0000 Given that the WG intent was that this be an optional extension, can you please suggest how we clarify that? Thank you, Joel On 7/15/2021 10:32 AM, Murray S. Kucherawy wrote: > On Mon, Jul 12, 2021 at 12:38 PM Joel M. Halpern > wrote: > > 2) The discussion happened when 8300 was being approved.  We agreed > with > the IESG that we would not define a mandatory-to-implement NSH security > mechanism, but that we would add an optional NSH security mechanism. > Which this draft does. > > > I think on reading the document, I didn't find it clear that this was an > optional thing or an extension.  It read to me a lot more like it was > filling an important gap left by RFC 8300, which to me leans much more > firmly in the direction that it's appropriate to call it an update. > > -MSK From nobody Thu Jul 15 08:18:49 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF3D3A0935; Thu, 15 Jul 2021 08:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTXc8S3iPl36; Thu, 15 Jul 2021 08:18:39 -0700 (PDT) Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (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 31BEE3A092E; Thu, 15 Jul 2021 08:18:38 -0700 (PDT) Received: by mail-ua1-x92f.google.com with SMTP id g4so2240797uap.5; Thu, 15 Jul 2021 08:18:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kOXgtEiU7i+oL6eIhjEd9aN7xjwpnfkmIprvNyX5UcI=; b=KEnPl9wHEU5DzcjP9xLPoH5C84xyz83hfwv19xQcJUvW0zA0W+Fpp7FISoDzRc0pjy 3ITziBAh7+qwnXNiApnDPhQGFAlOyMKs89QB3eS2smk+Ty+2QfbKMZvn0q0y5Yd5xoTO /vAga48s1Z/v/nz37aewSlKufd6WVLY5W6u4oKbR5SzrVONoF3TlmE2I1pgDx6Al9fjv 48txqfK1rGR/BG29QTdcRlOOlMya7/ER5kHru6+VqyqYAfrHrwX3c6wOpPNqhVF3vlTI 3gQ5WjpyvYKl/Ti9DA5uQ3kGriOZFVxaPpcIg54ZbfTqkvuNIumihVDcRL8QhdxSZPgg Vn6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kOXgtEiU7i+oL6eIhjEd9aN7xjwpnfkmIprvNyX5UcI=; b=Do/fD+DGUstfEK0DXstft7XGD80hkPnDDhrJrvka+z5kWhWgcWp1JVXXmgxnd0ykHv CvZunzf2H4R3+av7HkWZ7AgethP+0K7orDAGB0Ld64vJx41QNH1NWZEZZgd+6Nw5XM8b 6WgZ1/CJqcm9q1pCyE14K27myZj1ehAYu1ft3aJC90JqMJgkS39k5Sp/IloseDKnwIDi YNQ0SgLAtpSRvGJmcUUyQbYmJ8xUMlnDV/Z7Waeei0uwap29m9G9TzNO5DGl8EoRn6fV bOR1kRnKk7tfT1kIa2K+RC26vxt9T3RA+lvWWrsy2Z60f5e62hBB09g4H8BTx2sqwmw8 VMYg== X-Gm-Message-State: AOAM531XDPxT+xKSdu6+QUKUID/zniEugDgr8vFpGVan4du+GB91n+nH it+KRY1rEct5PBkl7pIMO7nOzWTnf62LToh5aXA= X-Google-Smtp-Source: ABdhPJyx1jeK21vDZjJsqIzofWl0hfDehXwbLSDavZbvEqFFLKRDWYDUoM8fOm0RLSE+Y3pZ3CyUx9cTkVK9Md+h7jE= X-Received: by 2002:ab0:7305:: with SMTP id v5mr7762694uao.47.1626362317479; Thu, 15 Jul 2021 08:18:37 -0700 (PDT) MIME-Version: 1.0 References: <162611498183.7775.3562397379733537345@ietfa.amsl.com> <1a5ae768-bf12-6d94-819c-7923e1f816ee@joelhalpern.com> <758d4dcf-5cdb-e493-a6bc-554024be6b62@joelhalpern.com> In-Reply-To: <758d4dcf-5cdb-e493-a6bc-554024be6b62@joelhalpern.com> From: "Murray S. Kucherawy" Date: Thu, 15 Jul 2021 08:18:25 -0700 Message-ID: To: Joel Halpern Direct Cc: Alvaro Retana , The IESG , Greg Mirsky , draft-ietf-sfc-nsh-integrity@ietf.org, Service Function Chaining IETF list Content-Type: multipart/alternative; boundary="00000000000035a27f05c72afc23" Archived-At: Subject: Re: [sfc] Alvaro Retana's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 15:18:45 -0000 --00000000000035a27f05c72afc23 Content-Type: text/plain; charset="UTF-8" On Thu, Jul 15, 2021 at 7:47 AM Joel Halpern Direct < jmh.direct@joelhalpern.com> wrote: > Given that the WG intent was that this be an optional extension, can you > please suggest how we clarify that? > It's obvious from this discussion that that was the WG intent, but is it also your view that this WG intent was made clear in the document? That was certainly not my impression, and I infer from the number of ballot comments that that's not a singular view, though certainly that might be more obvious to someone directly involved in this space. How about this, or something like it, in your Abstract: CURRENT: This specification adds integrity protection directly to the Network Service Header (NSH) used for Service Function Chaining (SFC). Also, this specification allows to encrypt sensitive metadata that is carried in the NSH. NEW 1: This specification adds optional integrity protection directly to the Network Service Header (NSH) used for Service Function Chaining (SFC). Also, this specification allows to encrypt sensitive metadata that is carried in the NSH. NEW 2: This specification presents an optional method to add integrity protection directly to the Network Service Header (NSH) used for Service Function Chaining (SFC). Also, this specification allows to encrypt sensitive metadata that is carried in the NSH. ...and in Section 1: CURRENT: This specification fills that gap. Concretely, this document adds integrity protection and optional encryption of sensitive metadata directly to the NSH [...] NEW: This specification presents an optional extension that fills that gap. Concretely, this document adds optional integrity protection and encryption of sensitive metadata directly to the NSH [...] -MSK --00000000000035a27f05c72afc23 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jul 15, 2021 at 7:47 AM Joel Halp= ern Direct <jmh.direct@joe= lhalpern.com> wrote:
Given that the WG intent was that th= is be an optional extension, can you
please suggest how we clarify that?

It's obvious from this discussion that= that was the WG intent, but is it also your view that this WG intent was m= ade clear in the document?=C2=A0 That was certainly not my impression, and = I infer from the number of ballot comments that that's not a singular v= iew, though certainly that might be more obvious to someone directly involv= ed in this space.

How about this, or something like= it, in your Abstract:

CURRENT:
= 
   This specification adds integrity protection directly to the Networ=
k
   Service Header (NSH) used for Service Function Chaining (SFC).  Also,
   this specification allows to encrypt sensitive metadata that is
   carried in the NSH.
NEW 1:
   This specification adds o=
ptional integrity protection directly to the Network
   Service Header (NSH) used for Service Function Chaining (SFC).  Also,
   this specification allows to encrypt sensitive metadata that is
   carried in the NSH.

NEW 2:
   This specification pr=
esents an optional method to add
   integrity protection directly to the=
 Network
   Service Header (NSH) used for Service Function Chaining (SFC).  Also,
   this specification allows to encrypt sensitive metadata that is
   carried in the NSH.

...and in Section 1:

CURRENT:
   This specifica=
tion fills that gap.  Concretely, this document adds
   integrity protection and optional encryption of sensitive metadata
   directly to the NSH [...]

NEW:
   This specificatio=
n presents an optional extension that fills that gap.
   Concretely, thi=
s document adds optional
   integrity protection and encryption of sensitive metadata
   directly to the NSH [...]

-MSK
--00000000000035a27f05c72afc23-- From nobody Thu Jul 15 08:32:27 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01BEB3A0D35; Thu, 15 Jul 2021 08:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRztOjvqxn86; Thu, 15 Jul 2021 08:32:15 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (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 2B3153A0D2F; Thu, 15 Jul 2021 08:32:15 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr26.francetelecom.fr (ESMTP service) with ESMTPS id 4GQdf50nYbzywy; Thu, 15 Jul 2021 17:32:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1626363133; bh=2az5uWyGKxgKfWuoz1MK8XUuLKXTP8pfp+bAfeT0PbU=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=OSZZNXuMsOSV8J538NLz7hw+mAXR6N0VJwrkE0yhx0fCidfNHp0kNhNQd+OaDHWTD Ara8B72GzddMsUKgsMc+jhUSq8z+WxufCpKCA2RAP05Kks4mtFpufPYGfDq6DUD4Fr UPnGjnUWv/PziYulOXqsiBRUZyAujaftn/l43vDOJrk/NWjP2AjAxR0w2nl2X8KZ+v mrZyAGKFF24vRNIRpX1vaGNvKLOkqGIQFFZk6W8nj/4byIa7zKYPs6qvzL8bGhAm5k yyAk+QFz3YFhBaFGKuGeagSantN/VCHnSOUY17G54ee3kR5t5xkDSbrVkCBEajuI+A V2d5DVy0ONnfg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfednr03.francetelecom.fr (ESMTP service) with ESMTPS id 4GQdf464pCzDq7V; Thu, 15 Jul 2021 17:32:12 +0200 (CEST) From: To: "Murray S. Kucherawy" , Joel Halpern Direct CC: Alvaro Retana , The IESG , "Greg Mirsky" , "draft-ietf-sfc-nsh-integrity@ietf.org" , Service Function Chaining IETF list Thread-Topic: [sfc] Alvaro Retana's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) Thread-Index: AQHXeYy13mq47xriWUaqlKnv0XS0nqtEKCkg Date: Thu, 15 Jul 2021 15:32:11 +0000 Message-ID: <31750_1626363132_60F054FC_31750_329_1_787AE7BB302AE849A7480A190F8B9330353BF9E9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162611498183.7775.3562397379733537345@ietfa.amsl.com> <1a5ae768-bf12-6d94-819c-7923e1f816ee@joelhalpern.com> <758d4dcf-5cdb-e493-a6bc-554024be6b62@joelhalpern.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330353BF9E9OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Alvaro Retana's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 15:32:21 -0000 --_000_787AE7BB302AE849A7480A190F8B9330353BF9E9OPEXCAUBMA2corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogTXVycmF5 IFMuIEt1Y2hlcmF3eSBbbWFpbHRvOnN1cGVydXNlckBnbWFpbC5jb21dDQpFbnZvecOpIDogamV1 ZGkgMTUganVpbGxldCAyMDIxIDE3OjE4DQrDgCA6IEpvZWwgSGFscGVybiBEaXJlY3QgPGptaC5k aXJlY3RAam9lbGhhbHBlcm4uY29tPg0KQ2MgOiBBbHZhcm8gUmV0YW5hIDxhcmV0YW5hLmlldGZA Z21haWwuY29tPjsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+OyBHcmVnIE1pcnNreSA8Z3JlZ2lt aXJza3lAZ21haWwuY29tPjsgZHJhZnQtaWV0Zi1zZmMtbnNoLWludGVncml0eUBpZXRmLm9yZzsg U2VydmljZSBGdW5jdGlvbiBDaGFpbmluZyBJRVRGIGxpc3QgPHNmY0BpZXRmLm9yZz4NCk9iamV0 IDogUmU6IFtzZmNdIEFsdmFybyBSZXRhbmEncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1z ZmMtbnNoLWludGVncml0eS0wNjogKHdpdGggQ09NTUVOVCkNCg0KT24gVGh1LCBKdWwgMTUsIDIw MjEgYXQgNzo0NyBBTSBKb2VsIEhhbHBlcm4gRGlyZWN0IDxqbWguZGlyZWN0QGpvZWxoYWxwZXJu LmNvbTxtYWlsdG86am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb20+PiB3cm90ZToNCkdpdmVuIHRo YXQgdGhlIFdHIGludGVudCB3YXMgdGhhdCB0aGlzIGJlIGFuIG9wdGlvbmFsIGV4dGVuc2lvbiwg Y2FuIHlvdQ0KcGxlYXNlIHN1Z2dlc3QgaG93IHdlIGNsYXJpZnkgdGhhdD8NCg0KSXQncyBvYnZp b3VzIGZyb20gdGhpcyBkaXNjdXNzaW9uIHRoYXQgdGhhdCB3YXMgdGhlIFdHIGludGVudCwgYnV0 IGlzIGl0IGFsc28geW91ciB2aWV3IHRoYXQgdGhpcyBXRyBpbnRlbnQgd2FzIG1hZGUgY2xlYXIg aW4gdGhlIGRvY3VtZW50PyAgVGhhdCB3YXMgY2VydGFpbmx5IG5vdCBteSBpbXByZXNzaW9uLCBh bmQgSSBpbmZlciBmcm9tIHRoZSBudW1iZXIgb2YgYmFsbG90IGNvbW1lbnRzIHRoYXQgdGhhdCdz IG5vdCBhIHNpbmd1bGFyIHZpZXcsIHRob3VnaCBjZXJ0YWlubHkgdGhhdCBtaWdodCBiZSBtb3Jl IG9idmlvdXMgdG8gc29tZW9uZSBkaXJlY3RseSBpbnZvbHZlZCBpbiB0aGlzIHNwYWNlLg0KDQpI b3cgYWJvdXQgdGhpcywgb3Igc29tZXRoaW5nIGxpa2UgaXQsIGluIHlvdXIgQWJzdHJhY3Q6DQpD VVJSRU5UOg0KDQogICBUaGlzIHNwZWNpZmljYXRpb24gYWRkcyBpbnRlZ3JpdHkgcHJvdGVjdGlv biBkaXJlY3RseSB0byB0aGUgTmV0d29yaw0KDQogICBTZXJ2aWNlIEhlYWRlciAoTlNIKSB1c2Vk IGZvciBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nIChTRkMpLiAgQWxzbywNCg0KICAgdGhpcyBz cGVjaWZpY2F0aW9uIGFsbG93cyB0byBlbmNyeXB0IHNlbnNpdGl2ZSBtZXRhZGF0YSB0aGF0IGlz DQoNCiAgIGNhcnJpZWQgaW4gdGhlIE5TSC4NCg0KTkVXIDE6DQogICBUaGlzIHNwZWNpZmljYXRp b24gYWRkcyBvcHRpb25hbCBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBkaXJlY3RseSB0byB0aGUgTmV0 d29yaw0KDQogICBTZXJ2aWNlIEhlYWRlciAoTlNIKSB1c2VkIGZvciBTZXJ2aWNlIEZ1bmN0aW9u IENoYWluaW5nIChTRkMpLiAgQWxzbywNCg0KICAgdGhpcyBzcGVjaWZpY2F0aW9uIGFsbG93cyB0 byBlbmNyeXB0IHNlbnNpdGl2ZSBtZXRhZGF0YSB0aGF0IGlzDQoNCiAgIGNhcnJpZWQgaW4gdGhl IE5TSC4NCg0KTkVXIDI6DQogICBUaGlzIHNwZWNpZmljYXRpb24gcHJlc2VudHMgYW4gb3B0aW9u YWwgbWV0aG9kIHRvIGFkZA0KICAgaW50ZWdyaXR5IHByb3RlY3Rpb24gZGlyZWN0bHkgdG8gdGhl IE5ldHdvcmsNCg0KICAgU2VydmljZSBIZWFkZXIgKE5TSCkgdXNlZCBmb3IgU2VydmljZSBGdW5j dGlvbiBDaGFpbmluZyAoU0ZDKS4NCg0KDQoNCltNZWRdIEkgbGlrZSB0aGlzIG9uZS4gVGhhbmtz Lg0KDQoNCg0KICBBbHNvLA0KDQogICB0aGlzIHNwZWNpZmljYXRpb24gYWxsb3dzIHRvIGVuY3J5 cHQgc2Vuc2l0aXZlIG1ldGFkYXRhIHRoYXQgaXMNCg0KICAgY2FycmllZCBpbiB0aGUgTlNILg0K DQouLi5hbmQgaW4gU2VjdGlvbiAxOg0KDQpDVVJSRU5UOg0KICAgVGhpcyBzcGVjaWZpY2F0aW9u IGZpbGxzIHRoYXQgZ2FwLiAgQ29uY3JldGVseSwgdGhpcyBkb2N1bWVudCBhZGRzDQoNCiAgIGlu dGVncml0eSBwcm90ZWN0aW9uIGFuZCBvcHRpb25hbCBlbmNyeXB0aW9uIG9mIHNlbnNpdGl2ZSBt ZXRhZGF0YQ0KDQogICBkaXJlY3RseSB0byB0aGUgTlNIIFsuLi5dDQoNCltNZWRdIEZvciB0aGlz IG9uZSwgSSB0aGluayB0aGlzIGlzIGFscmVhZHkgY292ZXJlZCBieSB0aGUgdGV4dCBwcm9wb3Nl ZCB0byBBbHZhcm8uIFRoZSBORVcgdGV4dCBjYW4gYmUgc2VlbiBhdDogaHR0cHM6Ly90aW55dXJs LmNvbS9uc2gtaW50ZWdyaXR5LWxhdGVzdA0KICAgVGhpcyBzcGVjaWZpY2F0aW9uIGZpbGxzIHRo YXQgZ2FwIGZvciBTRkMgKHRoYXQgaXMsIGRlZmluZSB0aGUgIk5TSA0KICAgVmFyaWFibGUgSGVh ZGVyLUJhc2VkIEludGVncml0eSIgb3B0aW9uIG1lbnRpb25lZCBpbiBTZWN0aW9uIDguMi4xIG9m DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeXl5eXl4NCiAgIFtSRkM4MzAw XSkuDQoNCg0KDQpORVc6DQogICBUaGlzIHNwZWNpZmljYXRpb24gcHJlc2VudHMgYW4gb3B0aW9u YWwgZXh0ZW5zaW9uIHRoYXQgZmlsbHMgdGhhdCBnYXAuDQogICBDb25jcmV0ZWx5LCB0aGlzIGRv Y3VtZW50IGFkZHMgb3B0aW9uYWwNCg0KICAgaW50ZWdyaXR5IHByb3RlY3Rpb24gYW5kIGVuY3J5 cHRpb24gb2Ygc2Vuc2l0aXZlIG1ldGFkYXRhDQoNCiAgIGRpcmVjdGx5IHRvIHRoZSBOU0ggWy4u Ll0NCg0KLU1TSw0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBl dXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmls ZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91 IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBw YXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRy dWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25p cXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0 ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBm YWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29u dGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBw cm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3Ig Y29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBl bWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBt ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3Jh bmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBj aGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK --_000_787AE7BB302AE849A7480A190F8B9330353BF9E9OPEXCAUBMA2corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBI VE1MIENhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uUHJmb3JtYXRI VE1MQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOpIEhUTUwiOw0K CWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6 d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlJlLSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlBsZWFzZSBzZWUgaW5saW5lLg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5DaGVl cnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi Pk1lZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+IE11cnJheSBTLiBLdWNoZXJhd3kgW21haWx0bzpzdXBlcnVzZXJA Z21haWwuY29tXQ0KPGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IGpldWRpIDE1IGp1aWxsZXQg MjAyMSAxNzoxODxicj4NCjxiPsOAJm5ic3A7OjwvYj4gSm9lbCBIYWxwZXJuIERpcmVjdCAmbHQ7 am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb20mZ3Q7PGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiBBbHZh cm8gUmV0YW5hICZsdDthcmV0YW5hLmlldGZAZ21haWwuY29tJmd0OzsgVGhlIElFU0cgJmx0O2ll c2dAaWV0Zi5vcmcmZ3Q7OyBHcmVnIE1pcnNreSAmbHQ7Z3JlZ2ltaXJza3lAZ21haWwuY29tJmd0 OzsgZHJhZnQtaWV0Zi1zZmMtbnNoLWludGVncml0eUBpZXRmLm9yZzsgU2VydmljZSBGdW5jdGlv biBDaGFpbmluZyBJRVRGIGxpc3QgJmx0O3NmY0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5PYmpldCZu YnNwOzo8L2I+IFJlOiBbc2ZjXSBBbHZhcm8gUmV0YW5hJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0 LWlldGYtc2ZjLW5zaC1pbnRlZ3JpdHktMDY6ICh3aXRoIENPTU1FTlQpPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEp1 bCAxNSwgMjAyMSBhdCA3OjQ3IEFNIEpvZWwgSGFscGVybiBEaXJlY3QgJmx0OzxhIGhyZWY9Im1h aWx0bzpqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbSI+am1oLmRpcmVjdEBqb2VsaGFscGVybi5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HaXZlbiB0aGF0IHRoZSBXRyBpbnRlbnQgd2FzIHRo YXQgdGhpcyBiZSBhbiBvcHRpb25hbCBleHRlbnNpb24sIGNhbiB5b3UNCjxicj4NCnBsZWFzZSBz dWdnZXN0IGhvdyB3ZSBjbGFyaWZ5IHRoYXQ/PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCdzIG9idmlvdXMgZnJvbSB0aGlzIGRp c2N1c3Npb24gdGhhdCB0aGF0IHdhcyB0aGUgV0cgaW50ZW50LCBidXQgaXMgaXQgYWxzbyB5b3Vy IHZpZXcgdGhhdCB0aGlzIFdHIGludGVudCB3YXMgbWFkZSBjbGVhciBpbiB0aGUgZG9jdW1lbnQ/ Jm5ic3A7IFRoYXQgd2FzIGNlcnRhaW5seSBub3QgbXkgaW1wcmVzc2lvbiwgYW5kIEkgaW5mZXIg ZnJvbSB0aGUgbnVtYmVyIG9mIGJhbGxvdCBjb21tZW50cyB0aGF0IHRoYXQncw0KIG5vdCBhIHNp bmd1bGFyIHZpZXcsIHRob3VnaCBjZXJ0YWlubHkgdGhhdCBtaWdodCBiZSBtb3JlIG9idmlvdXMg dG8gc29tZW9uZSBkaXJlY3RseSBpbnZvbHZlZCBpbiB0aGlzIHNwYWNlLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+SG93IGFib3V0IHRoaXMsIG9yIHNvbWV0aGluZyBsaWtlIGl0LCBpbiB5b3VyIEFic3Ry YWN0OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Q1VSUkVOVDo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+Jm5ic3A7ICZuYnNwO1RoaXMgc3BlY2lmaWNh dGlvbiBhZGRzIGludGVncml0eSBwcm90ZWN0aW9uIGRpcmVjdGx5IHRvIHRoZSBOZXR3b3JrPG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFNlcnZpY2UgSGVhZGVyIChOU0gpIHVz ZWQgZm9yIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgKFNGQykuJm5ic3A7IEFsc28sPG86cD48 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHRoaXMgc3BlY2lmaWNhdGlvbiBhbGxvd3Mg dG8gZW5jcnlwdCBzZW5zaXRpdmUgbWV0YWRhdGEgdGhhdCBpczxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOyZuYnNwOyBjYXJyaWVkIGluIHRoZSBOU0guPG86cD48L286cD48L3ByZT4NCjxw cmU+TkVXIDE6PGJyPiZuYnNwOyZuYnNwOyBUaGlzIHNwZWNpZmljYXRpb24gYWRkcyBvcHRpb25h bCBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBkaXJlY3RseSB0byB0aGUgTmV0d29yazxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBTZXJ2aWNlIEhlYWRlciAoTlNIKSB1c2VkIGZvciBT ZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nIChTRkMpLiZuYnNwOyBBbHNvLDxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyB0aGlzIHNwZWNpZmljYXRpb24gYWxsb3dzIHRvIGVuY3J5 cHQgc2Vuc2l0aXZlIG1ldGFkYXRhIHRoYXQgaXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOyZuYnNwOyBjYXJyaWVkIGluIHRoZSBOU0gu PG86cD48L286cD48L3ByZT4NCjxwcmU+TkVXIDI6PGJyPiZuYnNwOyZuYnNwOyBUaGlzIHNwZWNp ZmljYXRpb24gcHJlc2VudHMgYW4gb3B0aW9uYWwgbWV0aG9kIHRvIGFkZDxicj4mbmJzcDsmbmJz cDsgaW50ZWdyaXR5IHByb3RlY3Rpb24gZGlyZWN0bHkgdG8gdGhlIE5ldHdvcms8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgU2VydmljZSBIZWFkZXIgKE5TSCkgdXNlZCBmb3Ig U2VydmljZSBGdW5jdGlvbiBDaGFpbmluZyAoU0ZDKS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 Yj48aT48bzpwPiZuYnNwOzwvbzpwPjwvaT48L2I+PC9wcmU+DQo8cHJlPjxiPjxpPltNZWRdIEkg bGlrZSB0aGlzIG9uZS4gVGhhbmtzLiA8bzpwPjwvbzpwPjwvaT48L2I+PC9wcmU+DQo8cHJlPjxi PjxpPjxvOnA+Jm5ic3A7PC9vOnA+PC9pPjwvYj48L3ByZT4NCjxwcmU+Jm5ic3A7IEFsc28sPG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHRoaXMgc3BlY2lmaWNhdGlvbiBhbGxv d3MgdG8gZW5jcnlwdCBzZW5zaXRpdmUgbWV0YWRhdGEgdGhhdCBpczxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7IGNhcnJpZWQg aW4gdGhlIE5TSC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Li4uYW5kIGluIFNlY3Rpb24gMTo8L3Nw YW4+PGJyPjxicj5DVVJSRU5UOjxicj4mbmJzcDsmbmJzcDsgVGhpcyBzcGVjaWZpY2F0aW9uIGZp bGxzIHRoYXQgZ2FwLiZuYnNwOyBDb25jcmV0ZWx5LCB0aGlzIGRvY3VtZW50IGFkZHM8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgaW50ZWdyaXR5IHByb3RlY3Rpb24gYW5kIG9w dGlvbmFsIGVuY3J5cHRpb24gb2Ygc2Vuc2l0aXZlIG1ldGFkYXRhPG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDsmbmJzcDsgZGlyZWN0bHkg dG8gdGhlIE5TSCBbLi4uXTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PGI+PGk+W01lZF0gRm9yIHRoaXMgb25lLCBJIHRoaW5rIHRoaXMgaXMgYWxy ZWFkeSBjb3ZlcmVkIGJ5IHRoZSB0ZXh0IHByb3Bvc2VkIHRvIEFsdmFyby4gVGhlIE5FVyB0ZXh0 IGNhbiBiZSBzZWVuIGF0OiA8YSBocmVmPSJodHRwczovL3Rpbnl1cmwuY29tL25zaC1pbnRlZ3Jp dHktbGF0ZXN0Ij5odHRwczovL3Rpbnl1cmwuY29tL25zaC1pbnRlZ3JpdHktbGF0ZXN0PC9hPiA8 bzpwPjwvbzpwPjwvaT48L2I+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhpcyBzcGVjaWZpY2F0aW9uIGZpbGxzIHRoYXQgZ2FwIGZvciBT RkMgKHRoYXQgaXMsIGRlZmluZSB0aGUgJnF1b3Q7TlNIPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBWYXJpYWJsZSBIZWFk ZXItQmFzZWQgSW50ZWdyaXR5JnF1b3Q7IG9wdGlvbiBtZW50aW9uZWQgaW4gU2VjdGlvbiA4LjIu MSBvZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgXl5eXl5eDQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7W1JGQzgzMDBdKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+TkVXOjxi cj4mbmJzcDsmbmJzcDsgVGhpcyBzcGVjaWZpY2F0aW9uIHByZXNlbnRzIGFuIG9wdGlvbmFsIGV4 dGVuc2lvbiB0aGF0IGZpbGxzIHRoYXQgZ2FwLjxicj4mbmJzcDsmbmJzcDsgQ29uY3JldGVseSwg dGhpcyBkb2N1bWVudCBhZGRzIG9wdGlvbmFsPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 Jm5ic3A7IGludGVncml0eSBwcm90ZWN0aW9uIGFuZCBlbmNyeXB0aW9uIG9mIHNlbnNpdGl2ZSBt ZXRhZGF0YTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+Jm5ic3A7Jm5ic3A7IGRpcmVjdGx5IHRvIHRoZSBOU0ggWy4uLl08bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4tTVNLPG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPFBSRT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2 ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVn aWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBj b3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFy IGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVp cmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1 ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUg cmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFs c2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRh aW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJv dGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNv cGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1h aWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVz c2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5n ZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hh bmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KPC9QUkU+PC9ib2R5Pg0KPC9odG1sPg0K --_000_787AE7BB302AE849A7480A190F8B9330353BF9E9OPEXCAUBMA2corp_-- From nobody Thu Jul 15 08:41:17 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B99823A0E17; Thu, 15 Jul 2021 08:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17fFdwggypSv; Thu, 15 Jul 2021 08:41:04 -0700 (PDT) Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 835ED3A0E11; Thu, 15 Jul 2021 08:40:58 -0700 (PDT) Received: by mail-ua1-x936.google.com with SMTP id d2so2288424uan.0; Thu, 15 Jul 2021 08:40:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=a1UMqBpNFSJ+iiOXnTKQ0BGoUAMS9GPI08crD+dcJEs=; b=MOYBwY5yR8EHj/0IT/whAjQ+5q6XVPxGIOi+llokBniubG8BXCsIP38sdQrVonohkw 0KQ3dtXAoFyz4Ku/mpR+t19XbQ8JPbITbH3pQQj9mQipUIOWEdDI/Svt/p3gyzT1sEJE kkG38sboVWi++DpayEXpP+QyUGj5bwXYTWl13BQh1/7m4fmhgy6CaN5eK73b4CisHS7m LI8gHpifV7cfbRIRi2wQpETV/QEOcVTu3aj7+UzLzbRskZ+DBmpC2zstQnVhEp47cPTv 6JnkHloHqjUom4NwhGmJfDk6TAEkO3Cg5EAChaFU3CqpVlWf1XOr3QhF8sQN7FrEbOpE xQQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=a1UMqBpNFSJ+iiOXnTKQ0BGoUAMS9GPI08crD+dcJEs=; b=MX5INlul2ZG8hqNDzUabypeTR3d6RNER/18LtaPKSExOCW7TnD/qRCZgx6CzABlVfb ZDqeMeaP/h0hWVq+cq1sl0YhUvDtfhlkFnu/JeHl75eSUw2XIutNYV+BYieEqnrq8Xez XLRsDSbjyWiQ/cTYZFYeY8qw1dw+MY23taV9gndSytgRqBySkZlK6Vs4+SFLJx1Hj7Jp ne0E26Uu8PUUQubIdVGMO4Fnh0LaA8dEz6ETVDY6kWzngrxOpZpWjQ319P7zDg8WMAi/ Q5O1gnHbxsAzhxlr6eTKXuh7ySvs7+ew+zRs9Wztoha+Qi4yP3TluPyFgpybguKe+xI/ w21Q== X-Gm-Message-State: AOAM533XyX68gIgDvfmBN7mdlVwVcEeBque/Knqr7ssP+P1rRcO9vjRc MTCMrhK8TqnUWLtd5EgV9BiKSvG1GvSFu9Da6zY= X-Google-Smtp-Source: ABdhPJxF38FbUrz14pe+hSO8Chv1eqM+5Q9RjWtw+6/bMB4mNmhiYtQEd4X+1lOWtio67fACsFQUt/jz/fylXDY+HT8= X-Received: by 2002:ab0:7023:: with SMTP id u3mr7931893ual.76.1626363656900; Thu, 15 Jul 2021 08:40:56 -0700 (PDT) MIME-Version: 1.0 References: <162611498183.7775.3562397379733537345@ietfa.amsl.com> <1a5ae768-bf12-6d94-819c-7923e1f816ee@joelhalpern.com> <758d4dcf-5cdb-e493-a6bc-554024be6b62@joelhalpern.com> <31750_1626363132_60F054FC_31750_329_1_787AE7BB302AE849A7480A190F8B9330353BF9E9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <31750_1626363132_60F054FC_31750_329_1_787AE7BB302AE849A7480A190F8B9330353BF9E9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: "Murray S. Kucherawy" Date: Thu, 15 Jul 2021 08:40:45 -0700 Message-ID: To: mohamed.boucadair@orange.com Cc: Joel Halpern Direct , Alvaro Retana , The IESG , Greg Mirsky , "draft-ietf-sfc-nsh-integrity@ietf.org" , Service Function Chaining IETF list Content-Type: multipart/alternative; boundary="0000000000000b94bd05c72b4cad" Archived-At: Subject: Re: [sfc] Alvaro Retana's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 15:41:10 -0000 --0000000000000b94bd05c72b4cad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Mohamed, Thank you, that looks good. -MSK On Thu, Jul 15, 2021 at 8:32 AM wrote: > Re-, > > > > Please see inline. > > > > Cheers, > > Med > > > > *De :* Murray S. Kucherawy [mailto:superuser@gmail.com] > *Envoy=C3=A9 :* jeudi 15 juillet 2021 17:18 > *=C3=80 :* Joel Halpern Direct > *Cc :* Alvaro Retana ; The IESG ; > Greg Mirsky ; draft-ietf-sfc-nsh-integrity@ietf.or= g; > Service Function Chaining IETF list > *Objet :* Re: [sfc] Alvaro Retana's No Objection on > draft-ietf-sfc-nsh-integrity-06: (with COMMENT) > > > > On Thu, Jul 15, 2021 at 7:47 AM Joel Halpern Direct < > jmh.direct@joelhalpern.com> wrote: > > Given that the WG intent was that this be an optional extension, can you > please suggest how we clarify that? > > > > It's obvious from this discussion that that was the WG intent, but is it > also your view that this WG intent was made clear in the document? That > was certainly not my impression, and I infer from the number of ballot > comments that that's not a singular view, though certainly that might be > more obvious to someone directly involved in this space. > > > > How about this, or something like it, in your Abstract: > > CURRENT: > > This specification adds integrity protection directly to the Network > > Service Header (NSH) used for Service Function Chaining (SFC). Also, > > this specification allows to encrypt sensitive metadata that is > > carried in the NSH. > > NEW 1: > This specification adds optional integrity protection directly to the = Network > > Service Header (NSH) used for Service Function Chaining (SFC). Also, > > this specification allows to encrypt sensitive metadata that is > > carried in the NSH. > > NEW 2: > This specification presents an optional method to add > integrity protection directly to the Network > > Service Header (NSH) used for Service Function Chaining (SFC). > > > > *[Med] I like this one. Thanks. * > > > > Also, > > this specification allows to encrypt sensitive metadata that is > > carried in the NSH. > > ...and in Section 1: > > CURRENT: > This specification fills that gap. Concretely, this document adds > > integrity protection and optional encryption of sensitive metadata > > directly to the NSH [...] > > *[Med] For this one, I think this is already covered by the text proposed= to Alvaro. The NEW text can be seen at: https://tinyurl.com/nsh-integrity-= latest * > > This specification fills that gap for SFC (that is, define the "NSH > > Variable Header-Based Integrity" option mentioned in Section 8.2.1 of > > ^^^^^^ > > [RFC8300]). > > > > NEW: > This specification presents an optional extension that fills that gap. > Concretely, this document adds optional > > integrity protection and encryption of sensitive metadata > > directly to the NSH [...] > > -MSK > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > --0000000000000b94bd05c72b4cad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mohamed,

Thank you, that = looks good.

-MSK

On Thu, Jul 15, 2021 at = 8:32 AM <mohamed.boucada= ir@orange.com> wrote:

Re-,

=C2=A0

Please see inline.

=C2=A0

Cheers,

Med

=C2=A0

De=C2=A0: Murray= S. Kucherawy [mailto:superuser@gmail.com]
Envoy=C3=A9=C2=A0: jeudi 15 juillet 2021 17:18
=C3=80=C2=A0: Joel Halpern Direct <jmh.direct@joelhalpern.com>
Cc=C2=A0: Alvaro Retana <aretana.ietf@gmail.com>; The IESG <iesg@ietf.org>; Greg Mirsky= <gregimirsky= @gmail.com>; draft-ietf-sfc-nsh-integrity@ietf.org; Service Func= tion Chaining IETF list <sfc@ietf.org>
Objet=C2=A0: Re: [sfc] Alvaro Retana's No Objection on draft-iet= f-sfc-nsh-integrity-06: (with COMMENT)

=C2=A0

On Thu, Jul 15, 2021 at 7:47 AM Joel Halpern Direct = <jmh.dir= ect@joelhalpern.com> wrote:

Given that the WG intent was that this be an optiona= l extension, can you
please suggest how we clarify that?

=C2=A0

It's obvious from this discussion that that was = the WG intent, but is it also your view that this WG intent was made clear = in the document?=C2=A0 That was certainly not my impression, and I infer fr= om the number of ballot comments that that's not a singular view, though certainly that might be more obvious to someon= e directly involved in this space.

=C2=A0

How about this, or some= thing like it, in your Abstract:

CURRENT:

=C2=A0 =C2=A0This specification adds integrity protection directly to =
the Network
=C2=A0=C2=A0 Service Header (NSH) used for Service Function Chaining (=
SFC).=C2=A0 Also,
=C2=A0=C2=A0 this specification allows to encrypt sensitive metadata t=
hat is
=C2=A0=C2=A0 carried in the NSH.
NEW 1:
=C2=A0=C2=A0 This specification adds optional integrity prot=
ection directly to the Network
=C2=A0=C2=A0 Service Header (NSH) used for Service Function Chaining (=
SFC).=C2=A0 Also,
=C2=A0=C2=A0 this specification allows to encrypt sensitive metadata t=
hat is
=C2=A0=C2=A0 carried in the NSH.
NEW 2:
=C2=A0=C2=A0 This specification presents an optional method =
to add
=C2=A0=C2=A0 integrity protection directly to the Network<=
u>
=C2=A0=C2=A0 Service Header (NSH) used for Service Function Chaining (=
SFC).
=C2=A0
[Med] I like this one. Thanks. 
=C2=A0
=C2=A0 Also,
=C2=A0=C2=A0 this specification allows to encrypt sensitive metadata t=
hat is
=C2=A0=C2=A0 carried in the NSH.
...and in Sec=
tion 1:

CURRENT:
=C2=A0=C2=A0 This specification fills tha=
t gap.=C2=A0 Concretely, this document adds
=C2=A0=C2=A0 integrity protection and optional encryption of sensitive=
 metadata
=C2=A0=C2=A0 directly to the NSH [...]=

[Med] For this one, I think this is=
 already covered by the text proposed to Alvaro. The NEW text can be seen a=
t: h=
ttps://tinyurl.com/nsh-integrity-latest

=C2=A0=C2=A0=C2=A0This specification fills that gap for SFC = (that is, define the "NSH

=C2=A0=C2=A0 Variable Header-Based Integrity" option me= ntioned in Section 8.2.1 of

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= ^^^^^^

=C2=A0=C2=A0=C2=A0[RFC8300]).

=C2=A0
NEW:
=C2=A0=C2=A0 This specification presents an optional extension=
 that fills that gap.
=C2=A0=C2=A0 Concretely, this document adds option=
al
=C2=A0=C2=A0 integrity protection and encryption of sensitive metadata=

=C2=A0=C2=A0 directly to the NSH [...]=

-MSK
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message=
s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--0000000000000b94bd05c72b4cad-- From nobody Thu Jul 15 09:07:10 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21A5D3A095E; Thu, 15 Jul 2021 09:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=pgxKMUG+; dkim=pass (1024-bit key) header.d=juniper.net header.b=DpWRCkOL 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 rXPpQ2gc2ynG; Thu, 15 Jul 2021 09:07:00 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A40FC3A0C4C; Thu, 15 Jul 2021 09:06:59 -0700 (PDT) Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 16FFov53032121; Thu, 15 Jul 2021 09:06:57 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=jkxICD7ZP2J8cxEpSGEgZ7zq4ik22ytCuabRTpAl+eg=; b=pgxKMUG+Xdck0gr9EtNSpSyDMQ03QDazUEz+IDDOFn7TXz75RiQv+nNLNbUhob7CkjV2 PJLnnHPxyHnWebqMnp5sbCF78tY5sGdz3/vGnmjkiRkjBJag7gjygr8CGNSd0ALIbQJE IAKPlzaPAH+HjPtt6XugPQADlhT6rYevHo60A/xNGZzyNPmAFaieXPtNNtfv+bNvKquC ODduC8Bpm6M0c4uhGVJjaaK+JccY1r0TxswO7rLI/WKA3pIMq7QySqFZUIcpqbZ88H3O RFfvfh5UZ3SP/UC9GJgLcuWS0/niNs5Dw4Qnu73f8xfZw6c+qNjhvO3l3EF+XKeQIQAK 2A== Received: from nam11-co1-obe.outbound.protection.outlook.com (mail-co1nam11lp2176.outbound.protection.outlook.com [104.47.56.176]) by mx0b-00273201.pphosted.com with ESMTP id 39tr0w014u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Jul 2021 09:06:57 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CwdcxNDuit3QITRYPq7wHlOP4MtdV7RLsq1RZH/gYqXHWbVpaL/vhqRrAOpaUsauDtPkziH7bymmREdFrpE/ISOlVdO8eHlLBJyyjv6SOL7aJxZPLTVSQpDHdKnW7vub/fh5nVtConoY2zFxsn82pOXCdDu7z7QlI48gOvwEW/XGfI/d4QlfBi3OgL6TAo6RgYjbCfrkP3q1fGJn12ApNk0OBSfbBtqfcPO+EUEdQtx8x9D7FbcBiU3SEwg2FsTH9tLP91A1WyR8Lx5oW/S2fL7aa0CPLo1F193uW7zGTF3r8ojcSmPYTtCHZcUsf2g02JCluWI0DBtYR0uwW4M7Hg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jkxICD7ZP2J8cxEpSGEgZ7zq4ik22ytCuabRTpAl+eg=; b=Q2gOSqNwXSqsP3J8hL1UUTTXL1qC839AMKABptUiTbfONbID6JYcD/0megpLaVtoJzMoBUD4nX6veK+UMqS0uAZp3x5YNUciVljXSInQSCsHE56IS7oB7ecCDMRH5VEx4YdRfmtXVv5iE/u1fKw5myzgISSrVPOxCnTUNWlVL8rm+5ufj3vFoqtmfeesFwf7S5orKWZv0S6PvEHgRmw+8dWuWAlJhy8XGr5kYDEolG2e72F9SyiNtmRNZKUfmy38rlb7gRpvfMpT2RfQGE7Vkd8bzjosvez9JnjfG51NMySFO09CmHp2xs65+eE9kVe2TwjcjluwsU3lyWO4syRWTQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jkxICD7ZP2J8cxEpSGEgZ7zq4ik22ytCuabRTpAl+eg=; b=DpWRCkOLuYHR6WQbT7oP/1ZskC8YYcWaVY87HvCt1Z45PjBsZvP0vhtCRAQdV8+97hRQuHLCmE/piRMNn6XuKU/ViBwdJvfFzgapQ+bI4MJ414iPWyCwBYtAKC2K5KjY6u2BVERu/Xyz20EQZNRnOedaaJYg8ZT1vHtavBjowSM= Received: from MN2PR05MB6109.namprd05.prod.outlook.com (2603:10b6:208:c4::20) by BL0PR05MB7186.namprd05.prod.outlook.com (2603:10b6:208:1ca::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4352.8; Thu, 15 Jul 2021 16:06:55 +0000 Received: from MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::e40e:672f:e689:cd0c]) by MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::e40e:672f:e689:cd0c%7]) with mapi id 15.20.4331.022; Thu, 15 Jul 2021 16:06:55 +0000 From: John Scudder To: "mohamed.boucadair@orange.com" CC: The IESG , "gregimirsky@gmail.com" , "draft-ietf-sfc-nsh-integrity@ietf.org" , "sfc-chairs@ietf.org" , "sfc@ietf.org" Thread-Topic: [sfc] John Scudder's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) Thread-Index: AQHXeQY6zKUu9wrRqk2rKi8P49lscKtDfi0AgAC2ogA= Date: Thu, 15 Jul 2021 16:06:55 +0000 Message-ID: <4646DA07-E18B-49C9-891C-116F05EF71E8@juniper.net> References: <162630455957.5451.359442420121368370@ietfa.amsl.com> <32352_1626325998_60EFC3EE_32352_250_1_787AE7BB302AE849A7480A190F8B9330353BF458@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <32352_1626325998_60EFC3EE_32352_250_1_787AE7BB302AE849A7480A190F8B9330353BF458@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3654.100.0.2.22) authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=juniper.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 05adf82b-8074-4463-c396-08d947aa9125 x-ms-traffictypediagnostic: BL0PR05MB7186: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: RFgk7oEVlcFvwtAW9GyP+Enlu6xg0v8EDThJXF6s0fxUXP+W5JUc97SzCZUXVFCPafOcChp63YBaqk2KknpJoKJA0PlJCJ22uL+R7IjdqX+EdJMPfewE1GJIUwRfFNeEwdGyYVIxFCeg+xQ1z7P9oF+KQFGST6eY4SzJVeVkxBsO1VRchwZSodxmW+it0H04wIq1GckRyj7sqaAHF45+olZ9IWTeRqHbaLbMDTggOSpaSHqXsL+kFDTFAut/O5W7mh8NDQ2/vJ3RkDt/KhfYNO07Dg3puUN1DKY5c0A3xNLtHT2N+tpslB82Xe8cvN7/hprivsIrO7Lji99Nq9maWRahOba3hMNtZ7FyyKKUbznNsFVS5mnj+fQxMUcnrGOF9FRG0V+zK+hvsgsjix29alasiNJl75KOtFLzk7eJuknAXWtxWIN+m3CD7/ogJpyH/hGCqKiQULNcav3JpRIW1YEXobo+7j6Ikx07xBFABn49o3XX1qmQQN/9FLTCIH52V/OwGrI2vn7aEnyIeXWpfJQB0GPq1RDUF26VrFisGJznhOKvxLLtBKfSFHSa5nTbqYcPxGAONgh1Lb8iKuVO7eEo5sQP25mB5nGNxucEFZHElNHZviajPBRNIMoPMGxMjQmcYviledx88TsDbQupDmplEeHSfYK8ZFl3W3HGxl+coeaWraVFhBalQQ0IejcGT8Jc/Hnr99pXaI2NEHRmFvMwaYtf4JTdu+9kxAcyM1enoa1zJH4Gdlrsgj4Y+0muHqUZwTXGB00Jw2qm5Z1tTnnVJFyBzGtPzvbQAQGoBtSBlc6lTLUg8FdoOK9WltMSpxK1hN3uokC1Wpuw1MO352qk6kw0owHrsrIcf6T92hE= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR05MB6109.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(39860400002)(346002)(136003)(396003)(376002)(6486002)(8676002)(8936002)(316002)(4326008)(86362001)(5660300002)(38100700002)(91956017)(966005)(2616005)(6512007)(54906003)(122000001)(6506007)(6916009)(33656002)(66476007)(64756008)(186003)(2906002)(83380400001)(478600001)(71200400001)(36756003)(66946007)(26005)(53546011)(76116006)(66556008)(66446008)(38070700004)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?V0d1dUlBTWVQdjhORGVkUzFxNzd3c1B1clErN0g1TmFTelB4Q2ZqQldoUXRx?= =?utf-8?B?Yk9BbVVGanhHZXd6ZjFMZWpXTFVsZkdMQkZFNENIbzVzdFVnaHBPdVp3cnov?= =?utf-8?B?TWZaOWNIS240Ym5CUXVCRVF3dnU3TjhqRTJvd3VqelZEQ0VyeTRLNjBlYUc2?= =?utf-8?B?dW1hK3l6WWRIdEhOeXhwakxCR1VNcGwxcTUwMmxGZExWR3JiYjQvNVN5ai9z?= =?utf-8?B?WHhLM3VqN0JlTE10eUdGY05HR2xOMENMR2ExRkVqWG9kWUhEenY1Y0QvQmhj?= =?utf-8?B?TDIwL2tUU1IwU0M2Mndoa0lFWGtsaERDdGVXZkNmcmJyRFVodmtRa2gwOWhB?= =?utf-8?B?WGVDU3dJRUc1dTZuVUV3aVh3bHRXK05ySkIwYndGMWFMakRqMGRiMGNrS2xh?= =?utf-8?B?YnlwVWNRbStTdUFTaVgycmkzQzgvQUhZdWtSQmJiNDlTbzRnZmF4KzBhTEl0?= =?utf-8?B?Qjhrd1lxelJpS2wwbzU2VlpORnYvL3JjYk1oVmM4bVMyeWl2a2VrS3h4QXVL?= =?utf-8?B?bm5hU05nUk9RMDdQSm8wSkowOVhHdkxKNmNlV3lNTEpOTUl5bnVpOCtGNmxl?= =?utf-8?B?TFRIS2ZSclZOZU11S2kyd2Y2aGU2cSt6ZW9sOW5Na211OGtiMDN1VUg0QjFn?= =?utf-8?B?ZUZEU29UTVc1RFVlajZ2ZnMzbzN3YmxmWU9UUTZVR010OGdodGJwNW9WNHIx?= =?utf-8?B?WGt2UDlZNlBQazlFVVVIYlYvS1VIZWdvNzRaWDJqWERKMDhYVUd5VlBtQVpw?= =?utf-8?B?OXZFSUQzYkwrWWlxeXFGdnFoc09tQ012Z1BqR2ZNMDF0SDBOY2o2WXJyNFd4?= =?utf-8?B?c0xhWHJDR2h5d0tFdmk1ay9pekdBQzhnZHZDR21HM2FydFhWM3B3aG81eFVO?= =?utf-8?B?SnZRVTBHRnlLZGpJbzVjeDc2NFFvbzEvWXZGQ0FpdDdoZklsY24zU1I4YUM4?= =?utf-8?B?Mmh4TCtlLzdOVzR3K1J5WFUzcGxQdm1BVVNPL0FicUlRQzhaM3hTamlpR2NK?= =?utf-8?B?Z0RyNGNEZlozeXNXWk9sSW8wVUVYMVYydDRONFNkNDNVZnJjWnFzbjVHUkNK?= =?utf-8?B?VEpwUnpaZzV2M2V5UnVZRm9LMXRNa2p0VW96REcrYXlNd3FoWkNDWW5FZnBP?= =?utf-8?B?a3o2aW5jTnZHY3VaTWxVcXh5Z2lyK1pLcVNVRzI3QWNKMWFQdUp4bGdLUU9t?= =?utf-8?B?WWI4STZNWTVSTVRFRnRTR0prWEpKYlFCNE1HZWxqMXlXMlVGNWZ0WGlSQ3dN?= =?utf-8?B?cHcwK3VLMzBLR0ZTOXRCK1ZGYmorY3VONXFyMU41eGIyRllhNndaSXdVbG5Y?= =?utf-8?B?UHVnMXMxMStIb2MvUExyUWkyYlpHVHk2c2ZvcGZKYXNKdUc5bkd0MDl1ckdz?= =?utf-8?B?WktpSzB2UExkOUs0UWxERHhlK1dXK3lwY3BDWm52YzVrcmE5cHE1Q3hEVmZI?= =?utf-8?B?SDRaWnhWWUdnVzh5eDhrTUwwRGEyR0FoYXFQR28vM2hDY0UyMmJWVGxtQlNV?= =?utf-8?B?Z1lNYVdiOXgwSjBuMThKTkFGM2sraTZ5SVdBVk5RV0I2aGFtQ1N5K3R6Tlli?= =?utf-8?B?MU1Fc1FjZnczbEpVSnIzZUdYMU9vRTRwbEdYRGpRL0ZHV2tVaFlWdUN5Y0pz?= =?utf-8?B?ZUhhbnU3Wlo1NEJLOFNxWUsvK0NXRWFMSXNwL1MwNHF6RUZiRG1DZWd4Tjdt?= =?utf-8?B?THVyRGQ2MnB1N2hLVFF2M0lhc1hnK09PaUxOSU1SM3VmbGEwY1BGWUFlRm4w?= =?utf-8?B?djMxNUhDdmhPK08rbmowUXpRTzlEcUR3L2g2aSttKzM1bDBNcThGNnhwQXlF?= =?utf-8?B?R3lzNUNDUkpJV3V1bGQ3dz09?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR05MB6109.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 05adf82b-8074-4463-c396-08d947aa9125 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2021 16:06:55.3330 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: i/E79zVhbCM5X8gyuJYiEi5P5k7gR3hZhRU7qHMoXJteWT6O4wi4Wi4/z7IhfieD X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB7186 X-Proofpoint-GUID: OR_AW7h8s2eo2NW_5Ocddd8WsbxyZs3l X-Proofpoint-ORIG-GUID: OR_AW7h8s2eo2NW_5Ocddd8WsbxyZs3l X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-15_10:2021-07-14, 2021-07-15 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 impostorscore=0 phishscore=0 mlxlogscore=999 spamscore=0 clxscore=1011 malwarescore=0 suspectscore=0 mlxscore=0 lowpriorityscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107150111 Archived-At: Subject: Re: [sfc] John Scudder's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 16:07:05 -0000 SGkgTWVkLA0KDQpBIGNvdXBsZSBtb3JlIGNvbW1lbnRzIGlubGluZSBiZWxvdy4gDQoNCj4gT24g SnVsIDE1LCAyMDIxLCBhdCAxOjEzIEFNLCBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIHdy b3RlOg0KPiANCj4gW0V4dGVybmFsIEVtYWlsLiBCZSBjYXV0aW91cyBvZiBjb250ZW50XQ0KPiAN Cj4gDQo+IEhpIEpvaG4sDQo+IA0KPiBUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuDQo+IA0KPiBQ bGVhc2Ugc2VlIGlubGluZS4NCj4gDQo+IENoZWVycywNCj4gTWVkDQo+IA0KPj4gLS0tLS1NZXNz YWdlIGQnb3JpZ2luZS0tLS0tDQo+PiBEZSA6IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYu b3JnXSBEZSBsYSBwYXJ0IGRlIEpvaG4gU2N1ZGRlcg0KPj4gdmlhIERhdGF0cmFja2VyDQo+PiBF bnZvecOpIDogamV1ZGkgMTUganVpbGxldCAyMDIxIDAxOjE2DQo+PiDDgCA6IFRoZSBJRVNHIDxp ZXNnQGlldGYub3JnPg0KPj4gQ2MgOiBncmVnaW1pcnNreUBnbWFpbC5jb207IGRyYWZ0LWlldGYt c2ZjLW5zaC1pbnRlZ3JpdHlAaWV0Zi5vcmc7DQo+PiBzZmMtY2hhaXJzQGlldGYub3JnOyBzZmNA aWV0Zi5vcmcNCj4+IE9iamV0IDogW3NmY10gSm9obiBTY3VkZGVyJ3MgTm8gT2JqZWN0aW9uIG9u IGRyYWZ0LWlldGYtc2ZjLW5zaC0NCj4+IGludGVncml0eS0wNjogKHdpdGggQ09NTUVOVCkNCj4+ IA0KPj4gSm9obiBTY3VkZGVyIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0 aW9uIGZvcg0KPj4gZHJhZnQtaWV0Zi1zZmMtbnNoLWludGVncml0eS0wNjogTm8gT2JqZWN0aW9u DQo+PiANCj4+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBp bnRhY3QgYW5kIHJlcGx5IHRvDQo+PiBhbGwgZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRo ZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8NCj4+IGN1dCB0aGlzIGludHJvZHVjdG9y eSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPj4gDQo+PiANCj4+IFBsZWFzZSByZWZlciB0byBodHRw czovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1l bnQvZGlzY3Vzcy1fXzshIU5FdDZ5TWFPLWdrIVNoMXdLTGRhMURRR3pubGFuWF94aUxtWmpUSDlp SUF2RjlMclE1c19BV1ZKdDM5TURwVmZDUUt5V0ZPVE1BJA0KPj4gY3JpdGVyaWEuaHRtbA0KPj4g Zm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMu DQo+PiANCj4+IA0KPj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3Np dGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPj4gaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9f X2h0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2ZjLW5zaC1pbnRl Z3JpdHkvX187ISFORXQ2eU1hTy1nayFTaDF3S0xkYTFEUUd6bmxhblhfeGlMbVpqVEg5aUlBdkY5 THJRNXNfQVdWSnQzOU1EcFZmQ1FJNGZhazJYdyQNCj4+IA0KPj4gDQo+PiANCj4+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+PiAtLQ0KPj4gQ09NTUVOVDoNCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiAtLQ0KPj4gDQo+PiAx LiBTZWN0aW9uIDQuMg0KPj4gDQo+PiAgIFRoZSBhdXRoZW50aWNhdGVkIGVuY3J5cHRpb24gcHJv Y2VzcyB0YWtlcyBhcyBpbnB1dCBmb3VyLW9jdGV0DQo+PiAgIHN0cmluZ3M6IGEgc2VjcmV0IGtl eSAoSyksIGEgcGxhaW50ZXh0IChQKSwgQWRkaXRpb25hbA0KPj4gQXV0aGVudGljYXRlZA0KPj4g ICBEYXRhIChBKSAod2hpY2ggY29udGFpbnMgdGhlIGRhdGEgdG8gYmUgYXV0aGVudGljYXRlZCwg YnV0IG5vdA0KPj4gICBlbmNyeXB0ZWQpLCBhbmQgYW4gSW5pdGlhbGl6YXRpb24gVmVjdG9yIChJ VikuICBUaGUgY2lwaGVydGV4dA0KPj4gdmFsdWUNCj4+ICAgKEUpIGFuZCB0aGUgQXV0aGVudGlj YXRpb24gVGFnIHZhbHVlIChUKSBhcmUgcHJvdmlkZWQgYXMgb3V0cHV0cy4NCj4+IA0KPj4gQXMg d3JpdHRlbiwgdGhpcyBtZWFucyB0aGF0IGVhY2ggb2YgdGhlc2UgcXVhbnRpdGllcyBpcyBhIDMy IGJpdA0KPj4gc3RyaW5nLCBldmVuIFAgYW5kIEEuIEkgdGhpbmsgeW91IGRvbuKAmXQgbWVhbiB0 aGF0LiBJZiB5b3UgbWVhbiBlYWNoDQo+PiBxdWFudGl0eSBpcyBhIHN0cmluZyBvZiBvY3RldHMs IHRoZW4gbW92ZSB0aGUgaHlwaGVuOiDigJx0YWtlcyBhcw0KPj4gaW5wdXQgZm91ciBvY3RldC1z dHJpbmdz4oCcLiAoSW4gdGhlIHVubGlrZWx5IGV2ZW50IHlvdSByZWFsbHkgZG8gbWVhbg0KPj4g ZWFjaCBxdWFudGl0eSBpcyBhIHN0cmluZyBvZiBmb3VyIG9jdGV0cywgdGhlbiDigJzigKYgdGFr ZXMgYXMgaW5wdXQNCj4+IGZvdXIgc3RyaW5ncywgZWFjaCBvZiBmb3VyIG9jdGV0cy7igJ0pDQo+ PiANCj4gDQo+IFtNZWRdIEdvb2QgY2F0Y2guIENoYW5nZWQgdG8gImFzIGlucHV0IGZvdXIgb2N0 ZXQgc3RyaW5nczoiDQoNCkkgc3VnZ2VzdCB1c2luZyB0aGUgaHlwaGVuIGFzIGluIHRoZSBlYXJs aWVyIGNvbW1lbnQ6IOKAnGFzIGlucHV0IGZvdXIgb2N0ZXQtc3RyaW5nc+KAnS4gVGhpcyBtYWtl cyBpdCB1bmFtYmlndW91cyB0aGF0IOKAnGZvdXLigJ0gbW9kaWZpZXMg4oCcb2N0ZXQgc3RyaW5n c+KAnSBhbmQgbm90IGp1c3Qg4oCcb2N0ZXTigJ0sIHdoaWNoIGlzIHN0aWxsIHNsaWdodGx5IGFt YmlndW91cyBpbiB0aGUgbm9uLWh5cGhlbmF0ZWQgdmVyc2lvbi4gUG9zc2libHkgdGhlIFJGQyBF ZGl0b3Igd2lsbCBoYXZlIGNvbW1lbnRzIHRvbywgb2YgY291cnNlLiBJZiB5b3UgZGlzdGluY3Rs eSBwcmVmZXIgdGhlIG5vbi1oeXBoZW5hdGVkIHZlcnNpb24sIGl04oCZcyBub3QgYSBiaWcgZGVh bCB0aG91Z2guDQoNCuKApg0KDQo+PiAzLiBTZWN0aW9uIDkuMQ0KPj4gDQo+PiBZb3UgdXNlIOKA nHNob3VsZOKAnCBpbiBzZXZlcmFsIHBsYWNlcy4gQXMgd3JpdHRlbiwgaXQgaXNu4oCZdCBjbGVh ciBpZg0KPj4geW914oCZcmUgaW5kaWNhdGluZyBleHBlY3RhdGlvbiwgb3IgcmVxdWlyZW1lbnQu IEFmdGVyIHJlYWRpbmcgdGhlDQo+PiB3aG9sZSBzZWN0aW9uLCBJIHRoaW5rIHlvdeKAmXJlIGlu ZGljYXRpbmcgcmVxdWlyZW1lbnQuIFRoaXMgc2VlbXMNCj4+IGxpa2UgYSBnb29kIHBsYWNlIGZv ciB1c2Ugb2YgdGhlIFJGQyAyMTE5IHN0eWxlIFNIT1VMRCBrZXl3b3JkLg0KPj4gDQo+PiANCj4g DQo+IFtNZWRdIFRoZSBub3JtYXRpdmUgbGFuZ3VhZ2UgaXMgbm90IHVzZWQgYmVjYXVzZSB0aGVz ZSBhcmUgc29tZWhvdyBjb3ZlcmVkIGJ5IG90aGVyIG5vcm1hdGl2ZSB0ZXh0IGluIHRoZSBtYWlu IGRvY3VtZW50LiBTZWUgZm9yIGV4YW1wbGUgdGhlIHN0YXRlbWVudHMgYWJvdXQgcHJvdmlkaW5n IGtleSBtYXRlcmlhbHMgdG8gYXV0aG9yaXplZCBlbnRpdGllcyBhbmQgc28gb24uDQoNCk9LLiBJ biB0aGF0IGNhc2UgSSB0aGluayBpdCB3b3VsZCBiZSBiZW5lZmljaWFsIHRvIGNob29zZSBzb21l IG90aGVyIHJld3JpdGUsIHRvIG1ha2UgaXQgdW5hbWJpZ3VvdXMgdGhhdCB5b3UgbWVhbiBzb21l dGhpbmcgY2xvc2VyIHRvIOKAnHNoYWxs4oCdIGFuZCBsZXNzIGxpa2Ug4oCcd2lsbOKAnS4gVGhl IHByb2JsZW0gaXMgdGhhdCDigJxzaG91bGTigJ0gY291bGQgbWVhbiBlaXRoZXIuIEZvciBleGFt cGxlLA0KDQpPTEQ6DQogICBObyBkZXZpY2Ugb3RoZXIgdGhhbiB0aGUgTlNILWF3YXJlIFNGcyBp biB0aGUgU0ZDLWVuYWJsZWQgZG9tYWluDQogICBzaG91bGQgYmUgYWJsZSB0byB1cGRhdGUgdGhl IGludGVncml0eSBwcm90ZWN0ZWQgTlNIIGRhdGEuDQogICBTaW1pbGFybHksIG5vIGRldmljZSBv dGhlciB0aGFuIHRoZSBOU0gtYXdhcmUgU0ZzIGFuZCBTRkMgcHJveGllcyBpbg0KICAgdGhlIFNG Qy1lbmFibGVkIGRvbWFpbiBzaG91bGQgYmUgYWJsZSB0byBkZWNyeXB0IGFuZCB1cGRhdGUgdGhl DQogICBDb250ZXh0IEhlYWRlcnMgY2FycnlpbmcgcHJpdmFjeS1zZW5zaXRpdmUgbWV0YWRhdGEu ICBJbiBvdGhlciB3b3JkcywNCiAgIGlmIHRoZSBOU0gtYXdhcmUgU0ZzIGFuZCBTRkMgcHJveGll cyBpbiB0aGUgU0ZDLWVuYWJsZWQgZG9tYWluIGFyZQ0KICAgY29uc2lkZXJlZCBmdWxseSB0cnVz dGVkIHRvIGFjdCBvbiB0aGUgTlNIIGRhdGEsIG9ubHkgdGhlc2UgZWxlbWVudHMNCiAgIGNhbiBo YXZlIGFjY2VzcyB0byBwcml2YWN5LXNlbnNpdGl2ZSBOU0ggbWV0YWRhdGEgYW5kIHRoZSBrZXlp bmcNCiAgIG1hdGVyaWFsIHVzZWQgdG8gaW50ZWdyaXR5IHByb3RlY3QgTlNIIGRhdGEgYW5kIGVu Y3J5cHQgQ29udGV4dA0KICAgSGVhZGVycy4NCg0KTkVXOg0KICAgSXQgaXMgZXhwZWN0ZWQgdGhh dCBkZXZpY2VzIGluIHRoZSBTRkMtZW5hYmxlZCBkb21haW4gd2lsbCBiZSBjb25maWd1cmVkDQog ICBzdWNoIHRoYXQgbm8gZGV2aWNlIG90aGVyIHRoYW4gdGhlIE5TSC1hd2FyZSBTRnMgaW4gdGhl IGRvbWFpbg0KICAgd2lsbCBiZSBhYmxlIHRvIHVwZGF0ZSB0aGUgaW50ZWdyaXR5IHByb3RlY3Rl ZCBOU0ggZGF0YSwgYW5kIGFsc28NCiAgIHN1Y2ggdGhhdCBubyBkZXZpY2Ugb3RoZXIgdGhhbiB0 aGUgTlNILWF3YXJlIFNGcyBhbmQgU0ZDIHByb3hpZXMgaW4NCiAgIHRoZSBTRkMtZW5hYmxlZCBk b21haW4gd2lsbCBiZSBhYmxlIHRvIGRlY3J5cHQgYW5kIHVwZGF0ZSB0aGUNCiAgIENvbnRleHQg SGVhZGVycyBjYXJyeWluZyBwcml2YWN5LXNlbnNpdGl2ZSBtZXRhZGF0YS4gIEluIG90aGVyIHdv cmRzLA0KICAgaWYgdGhlIE5TSC1hd2FyZSBTRnMgYW5kIFNGQyBwcm94aWVzIGluIHRoZSBTRkMt ZW5hYmxlZCBkb21haW4gYXJlDQogICBjb25zaWRlcmVkIGZ1bGx5IHRydXN0ZWQgdG8gYWN0IG9u IHRoZSBOU0ggZGF0YSwgb25seSB0aGVzZSBlbGVtZW50cw0KICAgY2FuIGhhdmUgYWNjZXNzIHRv IHByaXZhY3ktc2Vuc2l0aXZlIE5TSCBtZXRhZGF0YSBhbmQgdGhlIGtleWluZw0KICAgbWF0ZXJp YWwgdXNlZCB0byBpbnRlZ3JpdHkgcHJvdGVjdCBOU0ggZGF0YSBhbmQgZW5jcnlwdCBDb250ZXh0 DQogICBIZWFkZXJzLg0KDQpJIGhhdmVu4oCZdCBwdXQgYSBsb3Qgb2YgdGhvdWdodCBpbnRvIHRo aXMgcHJvcG9zYWwgc28gY29uc2lkZXIgaXQgYW4gZXhhbXBsZSBvZiB3aGF0IEnigJltIHRhbGtp bmcgYWJvdXQgcmF0aGVyIHRoYW4gYSB3ZWxsLWNyYWZ0ZWQgcmVwbGFjZW1lbnQgKGFsdGhvdWdo IGZlZWwgZnJlZSB0byB1c2UgaXQgaWYgeW91IGxpa2UpLiAoSWYgZm9sbG93aW5nIHRoaXMgbW9k ZWwsIG1heWJlIGFmdGVyIOKAnGl0IGlzIGV4cGVjdGVk4oCdIHRoZXJlIHdvdWxkIGJlIG9uZSBv ciBtb3JlIHhyZWZzIHRvIHRoZSBwbGFjZXMgd2hlcmUgdGhlc2UgcmVxdWlyZW1lbnRzIGFyZSBz dGF0ZWQgbm9ybWF0aXZlbHkuKQ0KDQpUaGFua3MsDQoNCuKAlEpvaG4= From nobody Thu Jul 15 10:15:09 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5243A0EC9; Thu, 15 Jul 2021 10:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id az61Xr2RmLCE; Thu, 15 Jul 2021 10:14:55 -0700 (PDT) Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (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 C36FA3A0EBD; Thu, 15 Jul 2021 10:14:49 -0700 (PDT) Received: by mail-yb1-xb2c.google.com with SMTP id g5so10227335ybu.10; Thu, 15 Jul 2021 10:14:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ghnJY+LDcTNJNTbuXJIcf1DAAm/tMaX7x2XkRSxgT8Y=; b=ozr7bgwZbRG6jHs3gns6SRv0UDPOfFOaTzhbydV0bqIHS8KXEMAoTTG2/1lM2b3RBQ jYaz+h33fuACsJByB6PXGYpkCQFsKlx08b18KRez8aTXEitApnjqrG08OF0xGGxahA1B eVdUCwqauWwWu7dFWZkgYwQGRI5IfWGHpl2AdllYfc/JsZJZ1YiwGP9J+C/kn4kk80yc 7YLOtJ/B/Zoct0eJflNjrNdlfgXQXTLLq0fV4QUJqJB6lSobbcQLG8xNv11SmcD4lVb7 s/8D0ok5NLdff5LPPG7uPv3G2uD1WPDzd2mX5CdRIgeOssErB+Hl3+ogf/fH4EM+Wd0L x1uA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ghnJY+LDcTNJNTbuXJIcf1DAAm/tMaX7x2XkRSxgT8Y=; b=a18z7e+OqUD05Vr7fJTC5fEwzuqQOtHJFSu5Xnrl9bBcbz8Bj4BlqybX4x44aKmbLe vZ8wXsNC/DXkk+Yz7BvGhTWkxEhRDIqHESYbkVbqOGpPttXThrpcK9w0BEvixE0qs4Km 3DtDGp9Yo7Ie1Ra6FUKh5D0Rh3JD4MJ6+7MzBJMzYlmBS+LGS4nsVF9CQGa51wHxjoqh jw+A+NH9aAVnQ9uZDp+gTSQ9bX25WE4niJCjKeYvnqeEl2WbCZz9KI6zsgybDx9OK4ie xCgnwQWUNhnaV9ml9RGP4EiYe5kkA2n4yuGr+3kL3sZsjGVoBoUwFYaEMpzZegGTsvSd J40w== X-Gm-Message-State: AOAM5321TERnIr+n1hxigNrbB/hzdSxzsifoOdDmvHMaiupfFtymVWNn G2U8uKtXGSdQ4VDA34hBZ6jAPSfU/O1Yhr6fghWZ7H35vY4= X-Google-Smtp-Source: ABdhPJzCwWyhB1YJ9d35OvCjxk6xDf9/4a8Nj+l2pDQDaJ8FxYYaSHU2T83sMdHmL9dVxPVQDM2aDrcZSyl75Y/raOs= X-Received: by 2002:a25:442:: with SMTP id 63mr6717568ybe.114.1626369288178; Thu, 15 Jul 2021 10:14:48 -0700 (PDT) MIME-Version: 1.0 From: Daniel Migault Date: Thu, 15 Jul 2021 13:14:36 -0400 Message-ID: To: saag , int-area , IPsecME WG , sfc@ietf.org, tls , IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000b20d6d05c72c9ba9" Archived-At: Subject: [sfc] Heads up on Netdev conf 0x15 - not too late to attend! X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 17:15:00 -0000 --000000000000b20d6d05c72c9ba9 Content-Type: text/plain; charset="UTF-8" Hi, For those that have not already attending Netdev, Netdev conf 0x15 has been running since July 7 but it runs for 3 weeks but the talk sessions don't start until Monday. As usual a lot of IETF relevant talks. See: https://netdevconf.info/0x15/accepted-sessions.html The fee is USD $50. Students(proof required) are 50% off. The first 2 weeks was keynote, workshops and tutorials. You can replay all the sessions you missed by entering the conference platform (registration required). The keynote was by Hari Balakrishnan, see: https://netdevconf.info/0x15/session.html?keynote-balakrishnan On Monday as well there will be an industry perspectives panel on smartnics which will involve 6 vendors and an industry veteran moderating the session. For registration go here: https://netdevconf.info/0x15/virtual.html Yours, Daniel -- Daniel Migault Ericsson --000000000000b20d6d05c72c9ba9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

For those that have not= already attending Netdev, Netdev conf 0x15 has been running since July 7 b= ut it runs for 3 weeks but the talk sessions don't start until Monday. = As usual a lot of IETF relevant talks.
See:=C2=A0https://netdevco= nf.info/0x15/accepted-sessions.html

The fee is USD $50. Students= (proof required) are 50% off.

The first 2 weeks was keynote, worksho= ps and tutorials. You can replay all the sessions you missed by entering th= e conference platform (registration required).

The keynote was by Ha= ri Balakrishnan, see:
https://netdevconf.info/0x15/ses= sion.html?keynote-balakrishnan

On Monday as well there will be a= n industry perspectives panel on smartnics which will involve 6 vendors and= an industry veteran moderating the session.

For registration go her= e:
https://netdevconf.info/0x15/virtual.html

Yours,= =C2=A0
Daniel

--
Daniel Migault
Ericsson
=
--000000000000b20d6d05c72c9ba9-- From nobody Thu Jul 15 12:36:34 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EFB33A08C2; Thu, 15 Jul 2021 12:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQFcSyDJ2lQM; Thu, 15 Jul 2021 12:36:24 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2480F3A08AE; Thu, 15 Jul 2021 12:36:23 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 16FJaB1W002338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Jul 2021 15:36:16 -0400 Date: Thu, 15 Jul 2021 12:36:11 -0700 From: Benjamin Kaduk To: tirumal reddy Cc: Roman Danyliw , gregimirsky@gmail.com, draft-ietf-sfc-nsh-integrity@ietf.org, sfc-chairs@ietf.org, The IESG , sfc@ietf.org Message-ID: <20210715193611.GV74365@kduck.mit.edu> References: <162620296297.3569.2501497601980031548@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [sfc] Roman Danyliw's Discuss on draft-ietf-sfc-nsh-integrity-06: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 19:36:29 -0000 On Wed, Jul 14, 2021 at 02:57:42PM +0530, tirumal reddy wrote: > Hi Roman, > > Please see inline > > On Wed, 14 Jul 2021 at 00:33, Roman Danyliw via Datatracker < > noreply@ietf.org> wrote: > [...] > > > > -- The text would benefit from a description on how to serialize the > > packet for > > hashing. For example, Figure 6 and 7 are helpful logical descriptions of > > the > > integrity scope. However, the MAC field itself is depicted as part of the > > what > > should get hashed. Should that field be zeroed out? Removed ? > > > > Yes, we will update text as follows: > > The NSH imposer sets the MAC field to zero and then computes the message > integrity for the target NSH data (depending on the integrity protection > scope discussed in Section 5) using MAC_KEY and HMAC algorithm. It inserts > the computed digest in the MAC field in the "MAC and Encrypted Metadata" > Context Header. It's probably also worth updating the description of the verification procedures to match; we typically see these done in tandem. -Ben From nobody Fri Jul 16 05:01:16 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1CB23A33E0; Fri, 16 Jul 2021 05:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exJY2wLAG9wf; Fri, 16 Jul 2021 05:01:09 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (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 97BD03A33E2; Fri, 16 Jul 2021 05:01:08 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr27.francetelecom.fr (ESMTP service) with ESMTPS id 4GR8w24Lz6z4xJ8; Fri, 16 Jul 2021 14:01:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1626436866; bh=UjQ8RZt9nB00MrTlN3t1nzDkayx9uXf6iSf3jiryXok=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=l9hFUAL/k0J4gSNu6DKt9sj/U0FImHqZ7qp+pHxNJbffp3U56HVqagy00kk0dOhSW RDSCn1c/k2rD6Vg2R8d3RkuACEjYK2nNBLjVWQT8RAcS6v0ypgfybbJODIACPreQyw B/j8SBTPJCytkBsBuJNriE5JIbj6Z3zhwxox736D4WOE1Y5l0Y/+XlpE/GlGcU8QZ/ CphrezDhp1W+GgZoa7D4Vy1Bc7kRpncZRcYv4bBci5yu6GMH8siYHUR9pKQI0QIRBl MzMfNJll+puDMxDFLqkfMxgiNYkfC3GJJAL18m29QFFwAYJzDenwYLYaEnlk1UOj6i zlUgBOjnbvFsA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfednr03.francetelecom.fr (ESMTP service) with ESMTPS id 4GR8w23VpSzDq83; Fri, 16 Jul 2021 14:01:06 +0200 (CEST) From: To: John Scudder CC: The IESG , "gregimirsky@gmail.com" , "draft-ietf-sfc-nsh-integrity@ietf.org" , "sfc-chairs@ietf.org" , "sfc@ietf.org" Thread-Topic: [sfc] John Scudder's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) Thread-Index: AQHXeQY6zKUu9wrRqk2rKi8P49lscKtDfi0AgAC2ogCAAUgnwA== Date: Fri, 16 Jul 2021 12:01:04 +0000 Message-ID: <7006_1626436866_60F17502_7006_40_1_787AE7BB302AE849A7480A190F8B9330353C0103@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162630455957.5451.359442420121368370@ietfa.amsl.com> <32352_1626325998_60EFC3EE_32352_250_1_787AE7BB302AE849A7480A190F8B9330353BF458@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <4646DA07-E18B-49C9-891C-116F05EF71E8@juniper.net> In-Reply-To: <4646DA07-E18B-49C9-891C-116F05EF71E8@juniper.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] John Scudder's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2021 12:01:14 -0000 SGkgSm9obiwNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0t TWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBKb2huIFNjdWRkZXIgW21haWx0bzpqZ3NA anVuaXBlci5uZXRdDQo+IEVudm95w6nCoDogamV1ZGkgMTUganVpbGxldCAyMDIxIDE4OjA3DQo+ IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIElOTk9WL05FVCA8bW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbT4NCj4gQ2PCoDogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+OyBncmVnaW1pcnNreUBn bWFpbC5jb207IGRyYWZ0LWlldGYtDQo+IHNmYy1uc2gtaW50ZWdyaXR5QGlldGYub3JnOyBzZmMt Y2hhaXJzQGlldGYub3JnOyBzZmNAaWV0Zi5vcmcNCj4gT2JqZXTCoDogUmU6IFtzZmNdIEpvaG4g U2N1ZGRlcidzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLXNmYy1uc2gtDQo+IGludGVncml0 eS0wNjogKHdpdGggQ09NTUVOVCkNCj4gDQo+IEhpIE1lZCwNCj4gDQo+IEEgY291cGxlIG1vcmUg Y29tbWVudHMgaW5saW5lIGJlbG93Lg0KPiANClsuLi5dDQo+ID4+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tLQ0K PiA+PiAtLQ0KPiA+PiBDT01NRU5UOg0KPiA+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLS0NCj4gPj4gLS0NCj4g Pj4NCj4gPj4gMS4gU2VjdGlvbiA0LjINCj4gPj4NCj4gPj4gICBUaGUgYXV0aGVudGljYXRlZCBl bmNyeXB0aW9uIHByb2Nlc3MgdGFrZXMgYXMgaW5wdXQgZm91ci1vY3RldA0KPiA+PiAgIHN0cmlu Z3M6IGEgc2VjcmV0IGtleSAoSyksIGEgcGxhaW50ZXh0IChQKSwgQWRkaXRpb25hbA0KPiA+PiBB dXRoZW50aWNhdGVkDQo+ID4+ICAgRGF0YSAoQSkgKHdoaWNoIGNvbnRhaW5zIHRoZSBkYXRhIHRv IGJlIGF1dGhlbnRpY2F0ZWQsIGJ1dCBub3QNCj4gPj4gICBlbmNyeXB0ZWQpLCBhbmQgYW4gSW5p dGlhbGl6YXRpb24gVmVjdG9yIChJVikuICBUaGUgY2lwaGVydGV4dA0KPiA+PiB2YWx1ZQ0KPiA+ PiAgIChFKSBhbmQgdGhlIEF1dGhlbnRpY2F0aW9uIFRhZyB2YWx1ZSAoVCkgYXJlIHByb3ZpZGVk IGFzDQo+IG91dHB1dHMuDQo+ID4+DQo+ID4+IEFzIHdyaXR0ZW4sIHRoaXMgbWVhbnMgdGhhdCBl YWNoIG9mIHRoZXNlIHF1YW50aXRpZXMgaXMgYSAzMiBiaXQNCj4gPj4gc3RyaW5nLCBldmVuIFAg YW5kIEEuIEkgdGhpbmsgeW91IGRvbuKAmXQgbWVhbiB0aGF0LiBJZiB5b3UgbWVhbg0KPiBlYWNo DQo+ID4+IHF1YW50aXR5IGlzIGEgc3RyaW5nIG9mIG9jdGV0cywgdGhlbiBtb3ZlIHRoZSBoeXBo ZW46IOKAnHRha2VzIGFzDQo+IGlucHV0DQo+ID4+IGZvdXIgb2N0ZXQtc3RyaW5nc+KAnC4gKElu IHRoZSB1bmxpa2VseSBldmVudCB5b3UgcmVhbGx5IGRvIG1lYW4NCj4gZWFjaA0KPiA+PiBxdWFu dGl0eSBpcyBhIHN0cmluZyBvZiBmb3VyIG9jdGV0cywgdGhlbiDigJzigKYgdGFrZXMgYXMgaW5w dXQgZm91cg0KPiA+PiBzdHJpbmdzLCBlYWNoIG9mIGZvdXIgb2N0ZXRzLuKAnSkNCj4gPj4NCj4g Pg0KPiA+IFtNZWRdIEdvb2QgY2F0Y2guIENoYW5nZWQgdG8gImFzIGlucHV0IGZvdXIgb2N0ZXQg c3RyaW5nczoiDQo+IA0KPiBJIHN1Z2dlc3QgdXNpbmcgdGhlIGh5cGhlbiBhcyBpbiB0aGUgZWFy bGllciBjb21tZW50OiDigJxhcyBpbnB1dCBmb3VyDQo+IG9jdGV0LXN0cmluZ3PigJ0uIFRoaXMg bWFrZXMgaXQgdW5hbWJpZ3VvdXMgdGhhdCDigJxmb3Vy4oCdIG1vZGlmaWVzDQo+IOKAnG9jdGV0 IHN0cmluZ3PigJ0gYW5kIG5vdCBqdXN0IOKAnG9jdGV04oCdLCB3aGljaCBpcyBzdGlsbCBzbGln aHRseQ0KPiBhbWJpZ3VvdXMgaW4gdGhlIG5vbi1oeXBoZW5hdGVkIHZlcnNpb24uIFBvc3NpYmx5 IHRoZSBSRkMgRWRpdG9yDQo+IHdpbGwgaGF2ZSBjb21tZW50cyB0b28sIG9mIGNvdXJzZS4gSWYg eW91IGRpc3RpbmN0bHkgcHJlZmVyIHRoZSBub24tDQo+IGh5cGhlbmF0ZWQgdmVyc2lvbiwgaXTi gJlzIG5vdCBhIGJpZyBkZWFsIHRob3VnaC4NCj4gDQo+IOKApg0KDQpbTWVkXSBOb3RlZCB5b3Vy IHByZWZlcmVuY2UsIGJ1dCBJJ20gYWZyYWlkIHRoYXQgd2Ugd2lsbCB0b3VjaCB0aGF0IHRleHQg dG8gYWRkcmVzcyBvbmUgb2YgQmVuJ3MgRElTQ1VTUyBwb2ludC4gDQoNCj4gDQo+ID4+IDMuIFNl Y3Rpb24gOS4xDQo+ID4+DQo+ID4+IFlvdSB1c2Ug4oCcc2hvdWxk4oCcIGluIHNldmVyYWwgcGxh Y2VzLiBBcyB3cml0dGVuLCBpdCBpc27igJl0IGNsZWFyIGlmDQo+ID4+IHlvdeKAmXJlIGluZGlj YXRpbmcgZXhwZWN0YXRpb24sIG9yIHJlcXVpcmVtZW50LiBBZnRlciByZWFkaW5nIHRoZQ0KPiA+ PiB3aG9sZSBzZWN0aW9uLCBJIHRoaW5rIHlvdeKAmXJlIGluZGljYXRpbmcgcmVxdWlyZW1lbnQu IFRoaXMgc2VlbXMNCj4gbGlrZQ0KPiA+PiBhIGdvb2QgcGxhY2UgZm9yIHVzZSBvZiB0aGUgUkZD IDIxMTkgc3R5bGUgU0hPVUxEIGtleXdvcmQuDQo+ID4+DQo+ID4+DQo+ID4NCj4gPiBbTWVkXSBU aGUgbm9ybWF0aXZlIGxhbmd1YWdlIGlzIG5vdCB1c2VkIGJlY2F1c2UgdGhlc2UgYXJlIHNvbWVo b3cNCj4gY292ZXJlZCBieSBvdGhlciBub3JtYXRpdmUgdGV4dCBpbiB0aGUgbWFpbiBkb2N1bWVu dC4gU2VlIGZvcg0KPiBleGFtcGxlIHRoZSBzdGF0ZW1lbnRzIGFib3V0IHByb3ZpZGluZyBrZXkg bWF0ZXJpYWxzIHRvIGF1dGhvcml6ZWQNCj4gZW50aXRpZXMgYW5kIHNvIG9uLg0KPiANCj4gT0su IEluIHRoYXQgY2FzZSBJIHRoaW5rIGl0IHdvdWxkIGJlIGJlbmVmaWNpYWwgdG8gY2hvb3NlIHNv bWUgb3RoZXINCj4gcmV3cml0ZSwgdG8gbWFrZSBpdCB1bmFtYmlndW91cyB0aGF0IHlvdSBtZWFu IHNvbWV0aGluZyBjbG9zZXIgdG8NCj4g4oCcc2hhbGzigJ0gYW5kIGxlc3MgbGlrZSDigJx3aWxs 4oCdLiBUaGUgcHJvYmxlbSBpcyB0aGF0IOKAnHNob3VsZOKAnSBjb3VsZA0KPiBtZWFuIGVpdGhl ci4gRm9yIGV4YW1wbGUsDQo+IA0KPiBPTEQ6DQo+ICAgIE5vIGRldmljZSBvdGhlciB0aGFuIHRo ZSBOU0gtYXdhcmUgU0ZzIGluIHRoZSBTRkMtZW5hYmxlZCBkb21haW4NCj4gICAgc2hvdWxkIGJl IGFibGUgdG8gdXBkYXRlIHRoZSBpbnRlZ3JpdHkgcHJvdGVjdGVkIE5TSCBkYXRhLg0KPiAgICBT aW1pbGFybHksIG5vIGRldmljZSBvdGhlciB0aGFuIHRoZSBOU0gtYXdhcmUgU0ZzIGFuZCBTRkMg cHJveGllcw0KPiBpbg0KPiAgICB0aGUgU0ZDLWVuYWJsZWQgZG9tYWluIHNob3VsZCBiZSBhYmxl IHRvIGRlY3J5cHQgYW5kIHVwZGF0ZSB0aGUNCj4gICAgQ29udGV4dCBIZWFkZXJzIGNhcnJ5aW5n IHByaXZhY3ktc2Vuc2l0aXZlIG1ldGFkYXRhLiAgSW4gb3RoZXINCj4gd29yZHMsDQo+ICAgIGlm IHRoZSBOU0gtYXdhcmUgU0ZzIGFuZCBTRkMgcHJveGllcyBpbiB0aGUgU0ZDLWVuYWJsZWQgZG9t YWluDQo+IGFyZQ0KPiAgICBjb25zaWRlcmVkIGZ1bGx5IHRydXN0ZWQgdG8gYWN0IG9uIHRoZSBO U0ggZGF0YSwgb25seSB0aGVzZQ0KPiBlbGVtZW50cw0KPiAgICBjYW4gaGF2ZSBhY2Nlc3MgdG8g cHJpdmFjeS1zZW5zaXRpdmUgTlNIIG1ldGFkYXRhIGFuZCB0aGUga2V5aW5nDQo+ICAgIG1hdGVy aWFsIHVzZWQgdG8gaW50ZWdyaXR5IHByb3RlY3QgTlNIIGRhdGEgYW5kIGVuY3J5cHQgQ29udGV4 dA0KPiAgICBIZWFkZXJzLg0KPiANCj4gTkVXOg0KPiAgICBJdCBpcyBleHBlY3RlZCB0aGF0IGRl dmljZXMgaW4gdGhlIFNGQy1lbmFibGVkIGRvbWFpbiB3aWxsIGJlDQo+IGNvbmZpZ3VyZWQNCj4g ICAgc3VjaCB0aGF0IG5vIGRldmljZSBvdGhlciB0aGFuIHRoZSBOU0gtYXdhcmUgU0ZzIGluIHRo ZSBkb21haW4NCj4gICAgd2lsbCBiZSBhYmxlIHRvIHVwZGF0ZSB0aGUgaW50ZWdyaXR5IHByb3Rl Y3RlZCBOU0ggZGF0YSwgYW5kIGFsc28NCj4gICAgc3VjaCB0aGF0IG5vIGRldmljZSBvdGhlciB0 aGFuIHRoZSBOU0gtYXdhcmUgU0ZzIGFuZCBTRkMgcHJveGllcw0KPiBpbg0KPiAgICB0aGUgU0ZD LWVuYWJsZWQgZG9tYWluIHdpbGwgYmUgYWJsZSB0byBkZWNyeXB0IGFuZCB1cGRhdGUgdGhlDQo+ ICAgIENvbnRleHQgSGVhZGVycyBjYXJyeWluZyBwcml2YWN5LXNlbnNpdGl2ZSBtZXRhZGF0YS4g IA0KPiANCg0KW01lZF0gVGhhbmtzLiBXZW50IHdpdGggdGhlIGZvbGxvd2luZzogDQoNCiAgIEl0 IGlzIGV4cGVjdGVkIHRoYXQgc3BlY2lmaWMgZGV2aWNlcyBpbiB0aGUgU0ZDLWVuYWJsZWQgZG9t YWluIHdpbGwNCiAgIGJlIGNvbmZpZ3VyZWQgc3VjaCB0aGF0IG5vIGRldmljZSBvdGhlciB0aGFu IHRoZSBjbGFzc2lmaWVycyAod2hlbg0KICAgcmVjbGFzc2lmaWNhdGlvbiBpcyBlbmFibGVkKSwg TlNILWF3YXJlIFNGcywgYW5kIFNGQyBwcm94aWVzIHdpbGwgYmUNCiAgIGFibGUgdG8gdXBkYXRl IHRoZSBpbnRlZ3JpdHkgcHJvdGVjdGVkIE5TSCBkYXRhIChTZWN0aW9uIDcuMSksIGFuZA0KICAg YWxzbyBzdWNoIHRoYXQgbm8gZGV2aWNlIG90aGVyIHRoYW4gdGhlIE5TSC1hd2FyZSBTRnMgYW5k IFNGQyBwcm94aWVzDQogICB3aWxsIGJlIGFibGUgdG8gZGVjcnlwdCBhbmQgdXBkYXRlIHRoZSBD b250ZXh0IEhlYWRlcnMgY2FycnlpbmcNCiAgIHNlbnNpdGl2ZSBtZXRhZGF0YSAoU2VjdGlvbiA3 LjEpLg0KDQpBIGZ1bGwgZGlmZiBjYW4gYmUgdHJhY2tlZCBhdDogaHR0cHM6Ly90aW55dXJsLmNv bS9uc2gtaW50ZWdyaXR5LWxhdGVzdCANCg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBp ZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRp ZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNl cywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJl Y3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRp dGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVz c2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFu Z2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVy ZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh Y2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlv biB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJp YnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFu ZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkg YmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBi ZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Fri Jul 16 07:15:55 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9B83A38AA; Fri, 16 Jul 2021 07:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J_LSazbBC6yH; Fri, 16 Jul 2021 07:15:48 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (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 1E7033A38A9; Fri, 16 Jul 2021 07:15:48 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr22.francetelecom.fr (ESMTP service) with ESMTPS id 4GRCvP4dLVz103d; Fri, 16 Jul 2021 16:15:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1626444945; bh=GmL54hOe13TS9AZG/i3lkmBkt50TKtvoOxZi0V2p4Mo=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=deWto+DpOufkXZi4DWcEOiaeCgPtAsQML6XBfsAW9z0UZ5FDtfgNvT+nzVmcEoSEL OdT0rnhOfDShOI79QOWnA6M22tEaMfjSsIzS0EE+8+TtjdKmp6eHTOUIcgZs8PqcIN PDqUY26t1EoKCpQDS7rCWcQoSTadS2NJS9pUHX1o+mmgXy0CT/kzIwGeCFFlnSqwxg QA5okBur9WqjMRZtdGoZBF2ksGuMCbfvT7VCEmvLoHr0bLSDCTVhEMHHNnpZkzj5AR hnrWhRAUVJod5ousXUn1RLgeoyqLlS6amtK7wXb3tG6XUzvTDywutsCllJTXnedKiA fgQqq5Bb0/xIQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfednr04.francetelecom.fr (ESMTP service) with ESMTPS id 4GRCvP3clSz1xpn; Fri, 16 Jul 2021 16:15:45 +0200 (CEST) From: To: Benjamin Kaduk , The IESG CC: "draft-ietf-sfc-nsh-integrity@ietf.org" , "sfc-chairs@ietf.org" , "sfc@ietf.org" , "gregimirsky@gmail.com" Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-sfc-nsh-integrity-06: (with DISCUSS and COMMENT) Thread-Index: AQHXePbUnGtMWTBmlECZ6vxdOGPzS6tFFEmQ Date: Fri, 16 Jul 2021 14:15:44 +0000 Message-ID: <14311_1626444945_60F19491_14311_347_2_787AE7BB302AE849A7480A190F8B9330353C02BD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162629795136.25767.17850752260179612361@ietfa.amsl.com> In-Reply-To: <162629795136.25767.17850752260179612361@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Benjamin Kaduk's Discuss on draft-ietf-sfc-nsh-integrity-06: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2021 14:15:54 -0000 SGkgQmVuLCANCg0KTWFueSB0aGFua3MgYWdhaW4gZm9yIHRoZSBkZXRhaWxlZCByZXZpZXcuIFJl YWxseSBoZWxwZnVsLiANCg0KUGxlYXNlIHNlZSBpbmxpbmUgc29tZSByZXBsaWVzIHRvIHRoZSBD T01NRU5UIHBhcnQgKHdpdGggcmVmZXJlbmNlcyB0byBzb21lIERJU0NVU1MgcG9pbnRzKS4NCg0K Q2hhbmdlcyB0byBhZGRyZXNzIHlvdXIgQ09NTUVOVFMvTklUUyBjYW4gYmUgdHJhY2tlZCBhdDog aHR0cHM6Ly90aW55dXJsLmNvbS9uc2gtaW50ZWdyaXR5LWxhdGVzdC4NCg0KQ2hlZXJzLA0KTWVk DQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IEJlbmphbWluIEthZHVr IHZpYSBEYXRhdHJhY2tlciBbbWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmddDQo+IEVudm95w6nCoDog bWVyY3JlZGkgMTQganVpbGxldCAyMDIxIDIzOjI2DQo+IMOAwqA6IFRoZSBJRVNHIDxpZXNnQGll dGYub3JnPg0KPiBDY8KgOiBkcmFmdC1pZXRmLXNmYy1uc2gtaW50ZWdyaXR5QGlldGYub3JnOyBz ZmMtY2hhaXJzQGlldGYub3JnOw0KPiBzZmNAaWV0Zi5vcmc7IGdyZWdpbWlyc2t5QGdtYWlsLmNv bTsgZ3JlZ2ltaXJza3lAZ21haWwuY29tDQo+IE9iamV0wqA6IEJlbmphbWluIEthZHVrJ3MgRGlz Y3VzcyBvbiBkcmFmdC1pZXRmLXNmYy1uc2gtaW50ZWdyaXR5LTA2Og0KPiAod2l0aCBESVNDVVNT IGFuZCBDT01NRU5UKQ0KPiANCj4gQmVuamFtaW4gS2FkdWsgaGFzIGVudGVyZWQgdGhlIGZvbGxv d2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+IGRyYWZ0LWlldGYtc2ZjLW5zaC1pbnRlZ3JpdHkt MDY6IERpc2N1c3MNCj4gDQo+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1Ympl Y3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvDQo+IGFsbCBlbWFpbCBhZGRyZXNzZXMgaW5jbHVk ZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0bw0KPiBjdXQgdGhpcyBpbnRy b2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4gDQo+IA0KPiBQbGVhc2UgcmVmZXIgdG8g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy0NCj4gY3JpdGVyaWEu aHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBESVNDVVNTIGFuZCBDT01NRU5UIHBv c2l0aW9ucy4NCj4gDQo+IA0KPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90 IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2ZjLW5zaC1pbnRlZ3JpdHkvDQo+IA0KPiANCj4gDQpbLi4u XQ0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tDQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+IC0tDQo+IA0KPiBTZWN0aW9uIDMNCj4gDQo+ICAgIG8gIEJvdGggZW5jcnlwdGVkIGFuZCB1 bmVuY3J5cHRlZCBDb250ZXh0IEhlYWRlcnMgTUFZIGJlIGluY2x1ZGVkDQo+IGluDQo+ICAgICAg IHRoZSBzYW1lIE5TSC4gIFRoYXQgaXMsIHNvbWUgQ29udGV4dCBIZWFkZXJzIG1heSBiZSBwcm90 ZWN0ZWQNCj4gICAgICAgd2hpbGUgb3RoZXJzIGRvIG5vdCBuZWVkIHRvIGJlIHByb3RlY3RlZC4N Cj4gDQo+IEluIHRoZSBzZWN1cml0eSBhcmVhIHdlJ3JlIHByZXR0eSBzdHJvbmdseSBtb3ZlZCB0 b3dhcmRzIGEgc3RhbmNlIG9mDQo+ICJlbmNyeXB0IGV2ZXJ5dGhpbmcgdGhhdCBkb2Vzbid0IGhh dmUgYSBzdHJvbmcgbmVlZCB0byBiZSBwbGFpbnRleHQNCj4gKHNpbmNlIHdlIGRvbid0IHdhbnQg dG8gYXNzdW1lIHRoYXQgd2UgY2FuIHByZWRpY3QgYWxsIHRocmVhdHMgYW5kDQo+IGF0dGFja3Mg aW4gYWR2YW5jZSksIGFuZCBRVUlDIGhhcyBldmVuIHRha2VuIHRoYXQgdG8gbmV3IGxldmVscy4N Cj4gSXQncyBxdWl0ZSBzdXJwcmlzaW5nIHRvIHNlZSAiZG9uJ3QgbmVlZCB0byBiZSBwcm90ZWN0 ZWQiIGFzIGENCj4ganVzdGlmaWNhdGlvbiBmb3IgbGFjayBvZiBlbmNyeXB0aW9uLCByYXRoZXIg dGhhbiAibmVlZCB0byBiZQ0KPiB1bnByb3RlY3RlZCIuICBHaXZlbiB0aGF0IHdlJ3JlIGdvaW5n IHRvIGJlIHNvbHZpbmcga2V5IGRpc3RyaWJ1dGlvbg0KPiBmb3IgaW50ZWdyaXR5IHByb3RlY3Rp b24gYW55d2F5LCBpdCByZW1haW5zIHVuY2xlYXIgdG8gbWUgd2h5IHdlDQo+IHdvdWxkbid0IGp1 c3QgZW5jcnlwdCBldmVyeXRoaW5nLg0KDQpbTWVkXSBUaGlzIGRlcGVuZHMgb24gdGhlIHR5cGUg b2YgdGhlIGNvbnRleHQgaGVhZGVyLCB0aGUgY2FwYWJpbGl0aWVzIG9mIFNGcywgbG9jYWwgcG9s aWNpZXMsIHBlcmZvcm1hbmNlIGltcGxpY2F0aW9ucywgZXRjLiBFbmNyeXB0aW5nIG9ubHkgYSBz dWJzZXQgb2YgY29udGV4dCBoZWFkZXJzIGlzIGEgZmVhdHVyZSB3ZSB3YW50IHRvIHByb3ZpZGUu IA0KDQpQbGVhc2Ugbm90ZSB0aGF0IHRoZSBJLUQgZ2l2ZXMgYSB0cmFuc2l0aW9uIHBhdGggZm9y IFNGQyBmcm9tIHRoZSBjdXJyZW50IHBsYWluIHRleHQgd2l0aG91dCBhbnkgY29uZmlkZW50aWFs aXR5IG9yIGludGVncml0eSBwcm90ZWN0aW9uIHRvIHN0YXJ0IHdpdGggaW50ZWdyaXR5IHByb3Rl Y3Rpb24gYW5kIGV2ZW50dWFsbHkgdHJhbnNpdGlvbiB0byAocGFydGlhbCBhbmQgZnVsbCkgY29u ZmlkZW50aWFsaXR5IGFuZCBpbnRlZ3JpdHkgcHJvdGVjdGlvbi4NCg0KV2UgY2FuIHJlY29tbWVu ZCBkZXBsb3ltZW50cyB0byBjb25zaWRlciB1c2luZyBlbmNyeXB0aW9uIGZvciAqKmFueSoqIGNv bnRleHQgaGVhZGVyIHRvIHByZXZlbnQgcGVydmFzaXZlIG1vbml0b3JpbmcuDQoNCldlIHVuZGVy c3RhbmQgdGhhdCB0aGUgd29yZGluZyAiZG8gbm90IG5lZWQgdG8gYmUgcHJvdGVjdGVkIiBtYXkg bm90IGJlIGFwcHJvcHJpYXRlLiBXZSByZW1vdmVkIHRoZSBzZW50ZW5jZSBzdGFydGluZyB3aXRo ICJUaGF0IGlzLCBzb21lIC4uLiIuDQoNCj4gDQo+IFNlY3Rpb24gNC4xLjENCj4gDQo+IElzIHRo ZSBjb2x1bW4gaGVhZGluZyBmb3IgdGhlIG1pZGRsZSBjb2x1bW4gb2YgVGFibGUgMSByZWZlcnJp bmcgdG8NCj4gdGhlIEJhc2UgSGVhZGVyIGFuZCAiU2VydmljZSBQYXRoIEhlYWRlciI/ICBJJ20g bm90IHN1cmUgaG93IHRvDQo+IGludGVycHJldCBqdXN0ICJTZXJ2aWNlIEhlYWRlciIgb3RoZXIg dGhhbiB0aGUgZW50aXJlIE5TSCwgd2hpY2gNCj4gZG9lc24ndCBzZWVtIHJpZ2h0Li4uDQoNCltN ZWRdIFRoYXQgaXMgaW4gcmVmZXJlbmNlIHRvIHdoYXQgd2Ugc2F5IGluIFNlY3Rpb24gMyB0aGF0 Og0KDQogICBvICBCYXNlIEhlYWRlcjogUHJvdmlkZXMgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHNl cnZpY2UgaGVhZGVyIGFuZCB0aGUNCiAgICAgIHBheWxvYWQgcHJvdG9jb2wuDQoNCj4gDQo+ICAg IFRoZSBTZXJ2aWNlIFBhdGggSGVhZGVyIChTZWN0aW9uIDIgb2YgW1JGQzgzMDBdKSBpcyBub3Qg ZW5jcnlwdGVkDQo+ICAgIGJlY2F1c2UgU0ZGcyB1c2UgU2VydmljZSBJbmRleCAoU0kpIGluIGNv bmp1bmN0aW9uIHdpdGggU2VydmljZQ0KPiBQYXRoDQo+ICAgIElkZW50aWZpZXIgKFNQSSkgZm9y IGRldGVybWluaW5nIHRoZSBuZXh0IFNGIGluIHRoZSBwYXRoLg0KPiANCj4gSXQncyBnb29kIHRv IHNlZSB0aGlzIHNwZWxsZWQgb3V0IGxpa2UgdGhpczsgSSdkIGxvdmUgdG8gaGF2ZSB0aGlzDQo+ IGtpbmQgb2YgZXhwbGFuYXRpb24gZm9yIGV2ZXJ5IHVuLWVuY3J5cHRlZCBwcm90b2NvbCBlbGVt ZW50Lg0KPiANCj4gU2VjdGlvbiA0LjEuMg0KPiANCj4gICAgVGhlIHNvbHV0aW9uIHByb3ZpZGVz IGludGVncml0eSBwcm90ZWN0aW9uIGZvciB0aGUgTlNIIGRhdGEuICBUd28NCj4gICAgbGV2ZWxz IG9mIGFzc3VyYW5jZSAoTG9BcykgYXJlIHN1cHBvcnRlZC4NCj4gDQo+IEkgc2VlIChyZWFkaW5n IG9ud2FyZCkgdGhhdCB0aGUgdHdvIExvQXMganVzdCBkaWZmZXIgaW4gd2hhdCBpcw0KPiBjb3Zl cmVkIGJ5IHRoZSBpbnRlZ3JpdHkgdGFnLCBidXQgZWFjaCBpbnZvbHZlIG9ubHkgYSBzaW5nbGUg TUFDLg0KPiBUaGVyZSdzIGEgcmVhc29uYWJsZSBhcmd1bWVudCB0aGF0IHdoZW4gdGhlcmUgYXJl IG92ZXJsYXBwaW5nIG5lZWRzDQo+IGZvciB3aGF0IGRhdGEgbmVlZHMgcHJvdGVjdGluZyBhbmQg d2hvIG5lZWRzIGFjY2VzcyB0byBpdCwgdGhhdA0KPiBtdWx0aXBsZSBNQUNzIChvciBlbmNyeXB0 aW9uLCBpZiBuZWVkZWQpIGFyZSBtb3N0IGFwcHJvcHJpYXRlLCB3aGljaA0KPiBjYW4gYmUgdGFp bG9yZWQgdG8gdGhlIHJlc3BlY3RpdmUgbmVlZHMuICBUaGlzIGlzIHNvbWV0aGluZyB0aGF0DQo+ IFBoaWxsaXAgSGFsbGFtLUJha2VyIGhhcyBhc2NyaWJlZCBhcyB0aGUgInNob3J0LWJsYW5rZXQg dGhlb3J5IiBvZg0KPiBjcnlwdG9ncmFwaHksIGluIHRoYXQgaXQncyBsaWtlIGEgYmxhbmtldCB0 aGF0J3MgdG9vIHNob3J0IHRvIGNvdmVyDQo+IGV2ZXJ5dGhpbmcgeW91IHdhbnQsIHNvIHlvdSBu ZWVkIHRvIGhhdmUgbW9yZSB0aGFuIG9uZSBhbmQgcHV0IHRoZW0NCj4gaW4gcGFydGlhbGx5IG92 ZXJsYXBwaW5nIGxheWVycy4NCj4gUGVyaGFwcyB0aGlzICJzaG9ydC1ibGFua2V0IHRoZW9yeSIg aXMgbW9yZSBhcHBsaWNhYmxlIHRvIERpc2N1c3MNCj4gcG9pbnQNCj4gKDApIHRoYW4gd2hhdCBp cyBjb3ZlcmVkIGJ5IHRoZSBNQUMsIHRob3VnaC4uLg0KPiANCj4gICAgVGhlIGZpcnN0IGxldmVs IG9mIGFzc3VyYW5jZSB3aGVyZSBhbGwgTlNIIGRhdGEgZXhjZXB0IHRoZSBCYXNlDQo+ICAgIEhl YWRlciBhcmUgaW50ZWdyaXR5IHByb3RlY3RlZCAoRmlndXJlIDIpLiAgSW4gdGhpcyBjYXNlLCB0 aGUgTlNIDQo+ICAgIGltcG9zZXIgbWF5IGJlIGEgQ2xhc3NpZmllciwgYW4gTlNILWF3YXJlIFNG LCBvciBhbiBTRkMgUHJveHkuDQo+IFNGRnMNCj4gICAgYXJlIG5vdCB0aHVzIHByb3ZpZGVkIHdp dGggYXV0aGVudGljYXRpb24gbWF0ZXJpYWwuICBbLi4uXQ0KPiANCj4gVGhlcmUgc2VlbXMgdG8g YmUgYSBnYXAgaW4gdGhlIGNoYWluIG9mIHJlYXNvbmluZyBhcyB0byB3aHkgU0ZGcyBhcmUNCj4g bm90IHByb3ZpZGVkIHdpdGggYXV0aGVudGljYXRpb24gbWF0ZXJpYWwuICBJdCBzZWVtcyB0aGF0 IHRoZSBpbnRlbnQNCj4gaXMgc29tZXRoaW5nIGFsb25nIHRoZSBsaW5lcyBvZiBjb25zaWRlcmlu ZyB3aGljaCBlbnRpdGllcyBuZWVkDQo+IGFjY2VzcyB0byB0aGUga2V5IG1hdGVyaWFsIGluIG9y ZGVyIHRvIHN1Y2Nlc3NmdWxseSBhZGQgYW4gTlNIIG9yDQo+IHVwZGF0ZSBjb250ZXh0IGhlYWRl cnMsIGJ1dCB0aGF0IGFsb25lIGlzIG5vdCBpdHNlbGYgY2F1c2UgdG8gc2F5DQo+IHRoYXQgb3Ro ZXIgZW50aXRpZXMgY2FuIG5ldmVyIGJlIHByb3ZpZGVkIHdpdGggdGhlIGtleXMgKHN1YmplY3Qg dG8NCj4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIG9mIGdyb3VwLXNoYXJlZCBQU0tzLCBv ZiBjb3Vyc2UpLg0KDQpbTWVkXSBUaGUgdHdvIGxldmVscyBhcmUgdGhlcmUgZm9yIHNldmVyYWwg cmVhc29uczoNCiogZWFzZSBkZXBsb3ltZW50OiBoYXZlIGFuIG9wdGlvbiB0aGF0IGRvZXMgbm90 IGludm9sdmUgU0ZGcy4NCiogcGVyZm9ybWFuY2UgY29uc2lkZXJhdGlvbnMgb2YgU0ZGcw0KDQoN Cj4gRnVydGhlcm1vcmUsIGlmIGEgcGFydGljdWxhciBTRkYgaXMgdHJ1c3RlZCwgaXQgbWF5IGhh dmUgZ3JvdW5kcyB0bw0KPiB2ZXJpZnkgdGhlIGludGVncml0eSB0YWcgZXZlbiBpZiBpdCBpcyBh ZG1pbmlzdHJhdGl2ZWx5IHByb2hpYml0ZWQNCj4gZnJvbSB3cml0aW5nIHN1Y2ggYSB0YWcuDQoN CltNZWRdIEFncmVlLCBidXQgd2Ugd2FudGVkIHRvIGtlZXAgb25seSB0d28gY2xlYXIgTG9Bcy4g DQoNCj4gDQo+ICAgIEluIGJvdGggbGV2ZWxzIG9mIGFzc3VyYW5jZSwgdGhlIHVuZW5jcnlwdGVk IENvbnRleHQgSGVhZGVycyBhbmQNCj4gdGhlDQo+ICAgIHBhY2tldCBvbiB3aGljaCB0aGUgTlNI IGlzIGltcG9zZWQgYXJlIHN1YmplY3QgdG8gaW50ZWdyaXR5DQo+ICAgIHByb3RlY3Rpb24uDQo+ IA0KPiBTdXJlbHkgYW55IGVuY3J5cHRlZCBDb250ZXh0IEhlYWRlcnMgYXJlIGFsc28gZ2l2ZW4g aW50ZWdyaXR5DQo+IHByb3RlY3Rpb24sIGFzIGV4Y2x1ZGluZyB0aGVtIGZyb20gdGhlIE1BQyBj b21wdXRhdGlvbiB3b3VsZCBiZQ0KPiBxdWl0ZSBjb21wbGV4LiAgSSBzZWUgdGhhdCB0aGUgZW5j cnlwdGVkIGNvbnRleHQgaGVhZGVycyBhcmUgbm90DQo+IHBhcnQgb2YgdGhlIEFBRCBpbnB1dCwg YnV0IGluIHRoZSBBRUFEIG1vZGVsIHRoZSBjaXBoZXJ0ZXh0IGlzIHN0aWxsDQo+IGdpdmVuIGlu dGVncml0eSBwcm90ZWN0aW9uIQ0KDQpbTWVkXSBUaGUgdGV4dCB5b3UgcXVvdGVkIGlzIGhlcmUg dG8gcmVtaW5kIHRoYXQgdGhlIG9yaWdpbmFsIE5TSCBwYWNrZXQgaXMgaW50ZWdyaXR5IHByb3Rl Y3RlZCBhcyB0aGlzIG1heSBiZSBtaXNzZWQgYnkgdGhlIHJlYWRlci4gTGlrZXdpc2UsIHRoYXQg c2FtZSBwcm90ZWN0aW9uIGlzIHByb3ZpZGVkIHRvIGNvbnRleHQgaGVhZGVycywgZXZlbiB3aGVu IHVuZW5jcnlwdGVkLiANCg0KPiANCj4gU2VjdGlvbiA0LjINCj4gDQo+ICAgIFRoZSBhdXRoZW50 aWNhdGVkIGVuY3J5cHRpb24gYWxnb3JpdGhtIGRlZmluZWQgaW4gW1JGQzc1MThdIGlzDQo+IHVz ZWQNCj4gICAgdG8gcHJvdmlkZSBOU0ggZGF0YSBpbnRlZ3JpdHkgYW5kIHRvIGVuY3J5cHQgdGhl IENvbnRleHQgSGVhZGVycw0KPiB0aGF0DQo+ICAgIGNhcnJ5IHByaXZhY3ktc2Vuc2l0aXZlIG1l dGFkYXRhLg0KPiANCj4gUkZDIDc1MTggKEpTT04gV2ViIEFsZ29yaXRobXMpIGlzIGEgdmVyeSBz dXJwcmlzaW5nIHJlZmVyZW5jZSBmb3INCj4gZ2VuZXJpYyBBRUFEIGVuY3J5cHRpb24uIA0KDQpb TWVkXSBGWUksIHdlIHVzZWQgdG8gaGF2ZSBzdWNoIHJlZmVyZW5jZSBpbiBkcmFmdC1yZWJvLXNm Yy1uc2gtaW50ZWdyaXR5LTAwOg0KDQogICBUaGUgQXV0aGVudGljYXRlZCBFbmNyeXB0aW9uIHdp dGggQXNzb2NpYXRlZCBEYXRhIChBRUFEKSBhbGdvcml0aG0NCiAgIFtSRkM1MTE2XSBpcyB1c2Vk IHRvIHByb3ZpZGUgTlNIIGRhdGEgaW50ZWdyaXR5IGFuZCB0byBlbmNyeXB0DQogICBwcml2YWN5 LXNlbnNpdGl2ZSBtZXRhZGF0YS4NCg0KV2UgY2hhbmdlZCB0aGUgc3BlYyBiZWNhdXNlIHdlIHdh bnRlZCB0byBjb250cm9sIGJ5IGRlc2lnbiB0aGUgbm9kZXMgdGhhdCBhcmUgYWxsb3dlZCB0byBh Y2Nlc3MgZW5jcnlwdGVkIGRhdGEgdnMgaW50ZWdyaXR5LW9ubHkuIEJUVywgd2Ugc2VudCBhIG5v dGUgdG8gdGhlIHNhYWcgbWFpbGluZyBsaXN0IHJpZ2h0IGFmdGVyIHdlIGNoYW5nZWQgb3VyIGRl c2lnbiBpbiB0aGUgaG9wZSB0byBoYXZlIG1vcmUgZXllcyBvbiB3aGF0IHdlIGFyZSBkb2luZywg YnV0IHVuZm9ydHVuYXRlbHkgd2UgZGlkbid0IGdldCBtdWNoIGF0dGVudGlvbi4gDQoNCk91ciB1 bmRlcnN0YW5kaW5nIG9mIHlvdXIgcmV2aWV3IGlzIHRoYXQgeW91IGFyZSBub3QgYWdhaW5zdCB1 c2luZyBFTkNfS0VZIGFuZCBNQUNfS0VZLCBidXQgeW91IHByZWZlciBBRVMtR0NNIG92ZXIgQ0JD LiBXZSBhcmUgY29uc2lkZXJpbmcgdGhlIGZvbGxvd2luZyBjaGFuZ2UgKG5vdCB5ZXQgaW1wbGVt ZW50ZWQpOiAgDQoNCk9MRDoNCg0KICAgQ2xhc3NpZmllcnMsIE5TSC1hd2FyZSBTRnMsIGFuZCBT RkMgcHJveGllcyBNVVNUIGltcGxlbWVudCB0aGUNCiAgIEFFU18xMjhfQ0JDX0hNQUNfU0hBXzI1 NiBhbGdvcml0aG0gYW5kIFNIT1VMRCBpbXBsZW1lbnQgdGhlDQogICBBRVNfMTkyX0NCQ19ITUFD X1NIQV8zODQgYW5kIEFFU18yNTZfQ0JDX0hNQUNfU0hBXzUxMiBhbGdvcml0aG1zLg0KDQogICBD bGFzc2lmaWVycywgTlNILWF3YXJlIFNGcywgYW5kIFNGQyBwcm94aWVzIE1VU1QgaW1wbGVtZW50 IHRoZSBITUFDLQ0KICAgU0hBLTI1Ni0xMjggYWxnb3JpdGhtIGFuZCBTSE9VTEQgaW1wbGVtZW50 IHRoZSBITUFDLVNIQS0zODQtMTkyIGFuZA0KICAgSE1BQy1TSEEtNTEyLTI1NiBhbGdvcml0aG1z Lg0KDQogICBTRkZzIE1BWSBpbXBsZW1lbnQgdGhlIGFmb3JlbWVudGlvbmVkIGNpcGhlciBzdWl0 ZXMgYW5kIEhNQUMNCiAgIGFsZ29yaXRobXMuDQoNCiAgICAgIE5vdGU6IFRoZSB1c2Ugb2YgQWR2 YW5jZWQgRW5jcnlwdGlvbiBTdGFuZGFyZCAoQUVTKSBpbiBHYWxvaXMvDQogICAgICBDb3VudGVy IE1vZGUgKEdDTSkgKyBITUFDIG1heSBoYXZlIENQVSBhbmQgcGFja2V0IHNpemUNCiAgICAgIGlt cGxpY2F0aW9ucyAobmVlZCBmb3IgYSBzZWNvbmQgMTI4LWJpdCBhdXRoZW50aWNhdGlvbiB0YWcp Lg0KDQpORVc6DQoNCiAgIENsYXNzaWZpZXJzLCBOU0gtYXdhcmUgU0ZzLCBhbmQgU0ZDIHByb3hp ZXMgTVVTVCBpbXBsZW1lbnQgdGhlDQogICBBRVNfMTI4X0dDTSBhbGdvcml0aG0gYW5kIFNIT1VM RCBpbXBsZW1lbnQgdGhlDQogICBBRVNfMTkyX0dDTSBhbmQgQUVTXzI1Nl9HQ00gYWxnb3JpdGht cy4NCg0KICAgQ2xhc3NpZmllcnMsIE5TSC1hd2FyZSBTRnMsIGFuZCBTRkMgcHJveGllcyBNVVNU IGltcGxlbWVudCB0aGUgSE1BQy0NCiAgIFNIQS0yNTYtMTI4IGFsZ29yaXRobSBhbmQgU0hPVUxE IGltcGxlbWVudCB0aGUgSE1BQy1TSEEtMzg0LTE5MiBhbmQNCiAgIEhNQUMtU0hBLTUxMi0yNTYg YWxnb3JpdGhtcy4NCg0KICAgU0ZGcyBNQVkgaW1wbGVtZW50IHRoZSBhZm9yZW1lbnRpb25lZCBj aXBoZXIgc3VpdGVzIGFuZCBITUFDDQogICBhbGdvcml0aG1zLg0KDQpXZSB3aWxsIGhhdmUgdG8g cmVmZXIgdG8gUkZDNTExNiBhbmQgW0dDTV0NCg0KICAgW0dDTV0gICAgICAgICBEd29ya2luLCBN LiwgIlJlY29tbWVuZGF0aW9uIGZvciBCbG9jayBDaXBoZXIgTW9kZXMgb2YNCiAgICAgICAgICAg ICAgICAgT3BlcmF0aW9uOiBHYWxvaXMvQ291bnRlciBNb2RlIChHQ00pIGFuZCBHTUFDIiwNCiAg ICAgICAgICAgICAgICAgTmF0aW9uYWwgSW5zdGl0dXRlIG9mIFN0YW5kYXJkcyBhbmQgVGVjaG5v bG9neSBTUCA4MDAtDQogICAgICAgICAgICAgICAgIDM4RCwgTm92ZW1iZXIgMjAwNy4NCg0KV2l0 aCB0aGF0LCB3ZSBkb24ndCBuZWVkIHRvIGNpdGUgUkZDNzUxOC4gDQoNCg0KIENvbnRpbnVpbmcg b24sIGl0IGJlY29tZXMgY2xlYXIgdGhhdCB3ZSBpbg0KPiBmYWN0IGRvIG5vdCB3YW50IGEgZ2Vu ZXJpYyBBRUFEIG9wZXJhdGlvbiBoZXJlLCBidXQgaW5zdGVhZCBoYXZlDQo+IG5lZWQgZm9yIHNl cGFyYXRpb24gb2YgZW5jcnlwdGlvbiBhbmQgaW50ZWdyaXR5IHByb3RlY3Rpb24gZHVlIHRvDQo+ IHRoZSB2YXJpb3VzIHNlcGFyYXRpb25zIG9mIHJvbGVzIHRoYXQgYXJlIHBvc3NpYmxlLiANCg0K W01lZF0gVGhhdCdzIGl0IQ0KDQogQmVjYXVzZSB0aGlzIGlzDQo+IGEgZGl2ZXJnZW5jZSBmcm9t IGN1cnJlbnQgYmVzdCBwcmFjdGljZXMgKHVzZSBvZiBuYXRpdmUgQUVBRCBjaXBoZXINCj4gbW9k ZXMgbGlrZSBHQ00sIFNJViwgZXRjLiksIEkgbWlnaHQgc3VnZ2VzdCBhIHJhdGhlciBkaWZmZXJl bnQNCj4gaW50cm9kdWN0b3J5IG1hdGVyaWFsOg0KPiANCj4gJSBUaGUgQUVBRCBpbnRlcmZhY2Ug c3BlY2lmaWVkIGluIFJGQyA1MTE2IGlzIGEgdmVyeSBwb3dlcmZ1bCB0b29sDQo+IGZvciAlIHBy b3ZpZGluZyBzdHJvbmcgY29uZmlkZW50aWFsaXR5IGFuZCBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBm b3INCj4gcHJvdG9jb2wgJSBtZXNzYWdlcywgYW5kIGhhcyBiZWNvbWUgcXVpdGUgd2lkZWx5IGFk b3B0ZWQgYXMgYQ0KPiByZXN1bHQuICBGb3IgJSBwcm90ZWN0aW5nIE5TSCBkYXRhIHdlIGFkaGVy ZSB0byB0aGUgc3Bpcml0IG9mIHRoZQ0KPiBBRUFEIGludGVyZmFjZSBidXQgJSB1c2UgYSBzbGln aHRseSBtb2RpZmllZCB2ZXJzaW9uIGluIG9yZGVyIHRvDQo+IHJlbWFpbiBjb25zaXN0ZW50IHdp dGggdGhlICUgcHJpdmlsZWdlIHNlcGFyYXRpb24gbmVlZGVkIChlLmcuLCBpbg0KPiB0aGUgc2Vj b25kIGxldmVsIG9mIGFzc3VyYW5jZSwgJSBTRkZzIG5lZWQgdG8gYmUgYWJsZSB0byB1cGRhdGUg dGhlDQo+IG1lc3NhZ2UgaW50ZWdyaXR5IHRhZyBidXQgZG8gbm90ICUgbmVlZCBhY2Nlc3MgdG8g dGhlIGRlY3J5cHRlZA0KPiBwbGFpbnRleHQpLiAgQWNjb3JkaW5nbHksIGEgY29tcG91bmQgQUVB RCAlIG1lY2hhbmlzbSBjb21iaW5pbmcgQ0JDDQo+IGVuY3J5cHRpb24gYW5kIEhNQUMgaW50ZWdy aXR5IHRhZyBpcyB1c2VkLCBzbyAlIHRoYXQgZGlzdHJpYnV0aW9uIG9mDQo+IHRoZSBlbmNyeXB0 aW9uIGtleSBjYW4gYmUgbGltaXRlZC4gIFJhdGhlciB0aGFuICUgZGVmaW5lIGEgbmV3DQo+IHNj aGVtZSBmcm9tIHNjcmF0Y2gsIHRoZSBBRVNfQ0JDX0hNQUNfU0hBMiBzY2hlbWUgZnJvbSAlIFtS RkM3NTE4XQ0KPiBpcyB1c2VkLiAgSW4gb3JkZXIgdG8gc2ltcGxpZnkga2V5IGRpc3RyaWJ1dGlv biwgYSBzaW5nbGUgJSBzZWNyZXQNCj4ga2V5IG1hdGVyaWFsIHNlZWQgSyBpcyB1c2VkLCB3aGlj aCBjYW4gYmUga2VwdCBwcml2YXRlICUgY2VudHJhbGx5DQo+IG9yIGRpc3RyaWJ1dGVkIHRvIGFs bCBwYXJ0aWVzIHRoYXQgd2lsbCBoYXZlIGFjY2VzcyB0byAlIGRlY3J5cHRlZA0KPiBwbGFpbnRl eHQsIGFuZCB0aGUgc2Vjb25kYXJ5IGtleXMgTUFDX0tFWSBhbmQgRU5DX0tFWSBhcmUgJSBkZXJp dmVkDQo+IGZyb20gSyBhcyBkaXNjdXNzZWQgaW4gU2VjdGlvbiA1LjIuMi4xIG9mIFtSRkM3NTE4 XS4gIEVudGl0aWVzICUNCj4gdGhhdCBuZWVkIHRvIHVwZGF0ZSB0aGUgaW50ZWdyaXR5IHRhZyBi dXQgYXJlIG5vdCBhdXRob3JpemVkIHRvIHNlZQ0KPiAlIHRoZSBkZWNyeXB0ZWQgcGxhaW50ZXh0 IHdpbGwgb25seSByZWNlaXZlIE1BQ19LRVkgYW5kIG5vdCBLIG9yICUNCj4gRU5DX0tFWS4NCg0K W01lZF0gSSBndWVzcywgdGhlIGNvbW1lbnQgd2lsbCBub3QgYmUgcmVsZXZhbnQgYWZ0ZXIgbWFu ZGF0aW5nIEFFUy1HQ00uDQoNCj4gDQo+ICAgIG8gIElmIHRoZSBDb250ZXh0IEhlYWRlcnMgYXJl IG5vdCBlbmNyeXB0ZWQsIHRoZSBIYXNoZWQgTWVzc2FnZQ0KPiAgICAgICBBdXRoZW50aWNhdGlv biBNb2RlIChITUFDKSBhbGdvcml0aG0gZGlzY3Vzc2VkIGluIFtSRkM0ODY4XSBpcw0KPiAgICAg ICB1c2VkIHRvIHByb3RlY3QgdGhlIGludGVncml0eSBvZiB0aGUgTlNIIGRhdGEuDQo+IA0KPiBJ dCdzIG5vdCBjbGVhciB0byBtZSB0aGF0IHRoaXMgaXMgYWRkaW5nIG11Y2ggdmFsdWU7IEhNQUMg aXMgdXNlZA0KPiB3aGV0aGVyIG9yIG5vdCB0aGVyZSBhcmUgZW5jcnlwdGVkIGhlYWRlcnMsIGFu ZCB0aGUgUkZDIDQ4NjgNCj4gcmVmZXJlbmNlIGlzIHJhdGhlciBvZGQgKHNlZSBhbHNvIG15IERp c2N1c3MgcG9pbnQgKDIpKS4NCj4gDQo+ICAgIFRoZSBhZHZhbnRhZ2Ugb2YgdXNpbmcgdGhlIGF1 dGhlbnRpY2F0ZWQgZW5jcnlwdGlvbiBhbGdvcml0aG0gaXMNCj4gdGhhdA0KPiAgICBOU0gtYXdh cmUgU0ZzIGFuZCBTRkMgcHJveGllcyBvbmx5IG5lZWQgdG8gcmUtY29tcHV0ZSB0aGUgbWVzc2Fn ZQ0KPiAgICBpbnRlZ3JpdHkgb2YgdGhlIE5TSCBkYXRhIGFmdGVyIGRlY3JlbWVudGluZyB0aGUg U2VydmljZSBJbmRleA0KPiAoU0kpDQo+ICAgIGFuZCBkbyBub3QgaGF2ZSB0byByZS1jb21wdXRl IHRoZSBjaXBoZXJ0ZXh0LiAgVGhlIG90aGVyDQo+IGFkdmFudGFnZSBpcw0KPiAgICB0aGF0IFNG RnMgZG8gbm90IGhhdmUgYWNjZXNzIHRvIHRoZSBFTkNfS0VZIGFuZCBjYW5ub3QgYWN0IG9uIHRo ZQ0KPiAgICBlbmNyeXB0ZWQgQ29udGV4dCBIZWFkZXJzIGFuZCwgb25seSBpbiBjYXNlIG9mIHRo ZSBzZWNvbmQgbGV2ZWwNCj4gb2YNCj4gICAgYXNzdXJhbmNlLCBTRkZzIGRvIGhhdmUgYWNjZXNz IHRvIHRoZSBNQUNfS0VZLiAgU2ltaWxhcmx5LCBhbg0KPiBOU0gtDQo+ICAgIGF3YXJlIFNGIG9y IFNGQyBQcm94eSBub3QgYWxsb3dlZCB0byBkZWNyeXB0IHRoZSBDb250ZXh0IEhlYWRlcnMNCj4g d2lsbA0KPiAgICBub3QgaGF2ZSBhY2Nlc3MgdG8gdGhlIEVOQ19LRVkuDQo+IA0KPiBbSWYgbXkg YWJvdmUgc3VnZ2VzdGlvbiBpcyB1c2VkLCB0aGlzIHRleHQgaGFzIHByb2JhYmx5IGJlY29tZQ0K PiBtb3N0bHkgcmVkdW5kYW50IGFuZCBjb3VsZCBiZSB0cmltbWVkIGRvd24gb3IgcmVtb3ZlZC5d DQo+IA0KPiAgICBUaGUgYXV0aGVudGljYXRlZCBlbmNyeXB0aW9uIHByb2Nlc3MgdGFrZXMgYXMg aW5wdXQgZm91ci1vY3RldA0KPiAgICBzdHJpbmdzOiBhIHNlY3JldCBrZXkgKEspLCBhIHBsYWlu dGV4dCAoUCksIEFkZGl0aW9uYWwNCj4gQXV0aGVudGljYXRlZA0KPiAgICBEYXRhIChBKSAod2hp Y2ggY29udGFpbnMgdGhlIGRhdGEgdG8gYmUgYXV0aGVudGljYXRlZCwgYnV0IG5vdA0KPiAgICBl bmNyeXB0ZWQpLCBhbmQgYW4gSW5pdGlhbGl6YXRpb24gVmVjdG9yIChJVikuICBUaGUgY2lwaGVy dGV4dA0KPiB2YWx1ZQ0KPiAgICAoRSkgYW5kIHRoZSBBdXRoZW50aWNhdGlvbiBUYWcgdmFsdWUg KFQpIGFyZSBwcm92aWRlZCBhcyBvdXRwdXRzLg0KPiANCj4gICAgSW4gb3JkZXIgdG8gZGVjcnlw dCBhbmQgdmVyaWZ5LCB0aGUgY2lwaGVyIHRha2VzIGFzIGlucHV0IEssIElWLA0KPiBBLA0KPiAg ICBULCBhbmQgRS4gIFRoZSBvdXRwdXQgaXMgZWl0aGVyIHRoZSBwbGFpbnRleHQgb3IgYW4gZXJy b3INCj4gaW5kaWNhdGluZw0KPiAgICB0aGF0IHRoZSBkZWNyeXB0aW9uIGZhaWxlZCBhcyBkZXNj cmliZWQgaW4gU2VjdGlvbiA1LjIuMi4yIG9mDQo+ICAgIFtSRkM3NTE4XS4NCj4gDQo+IFRoaXMg c2VlbXMgdHJ1ZSBmb3IgdGhlIGFic3RyYWN0IEFFQUQgaW50ZXJmYWNlLCBidXQgc2luY2Ugd2Un cmUNCj4gcGVlbGluZyBvZmYgdGhlIEhNQUMgaW50ZWdyaXR5IHRhZyBmb3Igc3RhbmRhbG9uZSB1 c2UsIHdlIG1heSBuZWVkDQo+IHRvIHNheSBzb21ldGhpbmcgYWJvdXQgd2hhdCBpbnB1dHMvb3V0 cHV0cyBhcmUgbmVlZGVkIGZvciBqdXN0IHVzaW5nDQo+IHRoZSBpbnRlZ3JpdHkgdGFnIHdpdGhv dXQgZG9pbmcgZGVjcnlwdGlvbi4gIEluIHBhcnRpY3VsYXIsIHdlDQo+IGNhbm5vdCB1c2UgSyBh cyBhbiBpbnB1dCBmb3Igc3RhbmRhbG9uZSBITUFDIHZlcmlmaWNhdGlvbiENCj4gDQo+IEFsc28s IHRoaXMgaXMganVzdCB0aGUgZ2VuZXJpYyBBRUFEIGludGVyZmFjZSwgc28gUkZDIDUxMTYgaXMN Cj4gcHJvYmFibHkgYSBtb3JlIGFwcm9wb3MgcmVmZXJlbmNlIHRoYW4gUkZDIDc1MTguDQoNCltN ZWRdIEFzIHN1Z2dlc3RlZCBhYm92ZSwgd2UgY2FuIHJlZmVyIHRvIFJGQzUxMTYgaW5zdGVhZCBv ZiBSRkM3NTE4Lg0KDQo+IA0KPiBTZWN0aW9uIDQuMw0KPiANCj4gICAgICAgTm90ZTogVGhlIHVz ZSBvZiBBZHZhbmNlZCBFbmNyeXB0aW9uIFN0YW5kYXJkIChBRVMpIGluIEdhbG9pcy8NCj4gICAg ICAgQ291bnRlciBNb2RlIChHQ00pICsgSE1BQyBtYXkgaGF2ZSBDUFUgYW5kIHBhY2tldCBzaXpl DQo+ICAgICAgIGltcGxpY2F0aW9ucyAobmVlZCBmb3IgYSBzZWNvbmQgMTI4LWJpdCBhdXRoZW50 aWNhdGlvbiB0YWcpLg0KPiANCj4gW1RoaXMgbWlnaHQgYWxzbyBiZSByZWR1bmRhbnQgaWYgbXkg ZWFybGllciBwcm9wb3NhbCBpcyBhY2NlcHRlZC5dDQo+IA0KPiBTZWN0aW9uIDQuNA0KPiANCj4g ICAgVGhlIGRvY3VtZW50IGRvZXMgbm90IGFzc3VtZSBub3IgcHJlY2x1ZGUgdGhlIGZvbGxvd2lu ZzoNCj4gDQo+ICAgIG8gIFRoZSBzYW1lIGtleWluZyBtYXRlcmlhbCBpcyB1c2VkIGZvciBhbGwg dGhlIHNlcnZpY2UgZnVuY3Rpb25zDQo+ICAgICAgIHVzZWQgd2l0aGluIGFuIFNGQy1lbmFibGVk IGRvbWFpbi4NCj4gDQo+ICAgIG8gIERpc3RpbmN0IGtleWluZyBtYXRlcmlhbCBpcyB1c2VkIHBl ciBTRlAgYnkgYWxsIGludm9sdmVkIFNGQw0KPiBkYXRhDQo+ICAgICAgIHBhdGggZWxlbWVudHMu DQo+IA0KPiAgICBvICBQZXItdGVuYW50IGtleXMgYXJlIHVzZWQuDQo+IA0KPiBJIHN1Z2dlc3Qg YSBmb3J3YXJkIHJlZmVyZW5jZSB0byB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgd2l0aCBh DQo+IGJyaWVmIG5vdGUgdGhhdCB0aGUgcmlzayBpbnZvbHZlZCBpbiB1c2luZyBhIGdyb3VwLXNo YXJlZCBzeW1tZXRyaWMNCj4ga2V5IGluY3JlYXNlcyB3aXRoIHRoZSBzaXplIG9mIHRoZSBncm91 cCB0byB3aGljaCBpdCBpcyBzaGFyZWQuDQoNCltNZWRdIE9LLiBEb25lLiANCg0KPiANCj4gICAg SW4gb3JkZXIgdG8gYWNjb21tb2RhdGUgZGVwbG95bWVudHMgcmVseWluZyB1cG9uIGtleWluZyBt YXRlcmlhbA0KPiBwZXINCj4gICAgU0ZDL1NGUCBhbmQgYWxzbyB0aGUgbmVlZCB0byB1cGRhdGUg a2V5cyBhZnRlciBlbmNyeXB0aW5nIE5TSA0KPiBkYXRhDQo+ICAgIGZvciBhIGNlcnRhaW4gYW1v dW50IG9mIHRpbWUsIHRoaXMgZG9jdW1lbnQgdXNlcyBrZXkgaWRlbnRpZmllcnMNCj4gdG8NCj4g ICAgdW5hbWJpZ3VvdXNseSBpZGVudGlmeSB0aGUgYXBwcm9wcmlhdGUga2V5aW5nIG1hdGVyaWFs LiAgRG9pbmcgc28NCj4gICAgYWxsb3dzIHRvIGFkZHJlc3MgdGhlIHByb2JsZW0gb2Ygc3luY2hy b25pemF0aW9uIG9mIGtleWluZw0KPiBtYXRlcmlhbC4NCj4gDQo+IEknZCBzdWdnZXN0IG1ha2lu ZyBhIHN0YXRlbWVudCBhYm91dCB0aGUgc2NvcGUgaW4gd2hpY2gga2V5DQo+IGlkZW50aWZpZXJz IG5lZWQgdG8gYmUgdW5pcXVlLg0KDQpbTWVkXSBUaGF0IGRlcGVuZHMgb24gdGhlIGJ1bGxldCBt ZW50aW9uZWQgYWJvdmUgKGV4LiBwZXItdGVuYW50KS4gSSdtIG5vdCBzdXJlIGFkZGluZyB0aGUg c2VudGVuY2UgYWRkcyBtdWNoIHZhbHVlIGFzIHRoZSBzY29wZSB0d2Vha2luZyBzdGlsbCBkZXBs b3ltZW50LXNwZWNpZmljLiAgDQoNCj4gDQo+IFNlY3Rpb24gNC41DQo+IA0KPiAgICBBbiBOU0gt YXdhcmUgU0Ygb3IgU0ZDIFByb3h5IHRoYXQgbmVlZHMgdG8gZGVjcnlwdCBzb21lIENvbnRleHQN Cj4gICAgSGVhZGVycyB1c2VzIEVOQ19LZXkgYW5kIHRoZSBkZWNyeXB0aW9uIGFsZ29yaXRobSBm b3IgdGhlIGtleQ0KPiAgICBpZGVudGlmaWVyIGJlaW5nIGNhcnJpZWQgaW4gdGhlIE5TSC4NCj4g DQo+IEkgdGhpbmsgd2UgbmVlZCB0byBzYXkgdGhhdCBkZWNyeXB0aW9uIE1VU1QgTk9UIHByb2Nl ZWQgdW5sZXNzIHRoZQ0KPiBpbnRlZ3JpdHkgdGFnIGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSB2YWxp ZGF0ZWQuICBUbyBkZWNyeXB0IHdpdGhvdXQNCj4gY2hlY2tpbmcgdGhlIGludGVncml0eSB0YWcg dmlvbGF0ZXMgdGhlIEFFQUQgaW50ZXJmYWNlLg0KPiBBbHRlcm5hdGVseSwgd2UgY291bGQgb25s eSBldmVyIGRlc2NyaWJlIGRlY3J5cHRpb24gYXMgdGhlIEFFQUQNCj4gb3BlcmF0aW9uIHRoYXQg dXNlcyBLIGFzIGlucHV0IChub3QganVzdCBFTkNfS0VZKSAtLSDCpzcuNiBzZWVtcyB0bw0KPiBh dHRlbXB0IHRvIHRha2UgdGhpcyBsYXR0ZXIgYXBwcm9hY2gsIGJ1dCB0aGUgZG9jdW1lbnQgYXMg YSB3aG9sZSBpcw0KPiBub3QgY29uc2lzdGVudCBhYm91dCBpdC4NCg0KW01lZF0gVGhpcyBzZWN0 aW9uIGlzIGFib3V0IGludHJvZHVjaW5nIHRoZSBuZXcgTUFDIGNvbnRleHQgaGVhZGVycy4gSSBk b24ndCB0aGluayB0aGlzIGlzIHRoZSByaWdodCBwbGFjZSB0byBtZW50aW9uIHRoaXMuICANCg0K QlRXLCB0aGUgb3JkZXIgeW91IG1lbnRpb25lZCBpcyB3aGF0IGlzIGltcGxpZWQgYnkgdGhlIHBy b2NlZHVyZTogNy41IChOU0ggRGF0YSBWYWxpZGF0aW9uKSBhbmQgdGhlbiA3LjYgKERlY3J5cHRp b24gb2YgTlNIIE1ldGFkYXRhKS4gSW52YWxpZCBkYXRhIGFyZSBkaXNjYXJkZWQgYXMgcGFydCBv ZiA3LjUuDQoNCk5vIHByb2JsZW0gdG8gYWRkIGEgbm90ZSB0byA3LjYgaWYgeW91IHRoaW5rIHRo aXMgaXMgcmVhbGx5IG5lZWRlZC4NCg0KPiANCj4gU2VjdGlvbiA1LCA1LngNCj4gDQo+IEkgc3Ry b25nbHkgc3VnZ2VzdCBjaGFuZ2luZyAiS2V5IExlbmd0aCIgdG8gImtleWlkIGxlbmd0aCIsIHNp bmNlDQo+IHRoZXJlIGlzIGFscmVhZHkgY29udmVudGlvbiBvbiAia2V5IGxlbmd0aCIgKGUuZy4s IGZvciBBRVMtMTI4IHZzDQo+IEFFUy0xOTIgdnMgQUVTLTI1NikuDQoNCltNZWRdIEZpeGVkIGFz IHBlciBhIGNvbW1lbnQgZnJvbSBFcmljLiANCg0KPiANCj4gU2VjdGlvbiA1LjENCj4gDQo+ICAg IEtleSBJZGVudGlmaWVyOiAgQ2FycmllcyBhIHZhcmlhYmxlLWxlbmd0aCBLZXkgSWRlbnRpZmll ciBvYmplY3QNCj4gdXNlZA0KPiAgICAgICB0byBpZGVudGlmeSBhbmQgZGVsaXZlciBrZXlzIHRv IFNGQyBkYXRhIHBsYW5lIGVsZW1lbnRzLiAgVGhpcw0KPiAgICAgICBpZGVudGlmaWVyIGlzIGhl bHBmdWwgdG8gYWNjb21tb2RhdGUgZGVwbG95bWVudHMgcmVseWluZyB1cG9uDQo+ICAgICAgIGtl eWluZyBtYXRlcmlhbCBwZXIgU0ZDL1NGUC4gIFRoZSBrZXkgaWRlbnRpZmllciBoZWxwcyBpbg0K PiAgICAgICByZXNvbHZpbmcgdGhlIHByb2JsZW0gb2Ygc3luY2hyb25pemF0aW9uIG9mIGtleWlu ZyBtYXRlcmlhbC4NCj4gDQo+IEkgc3VnZ2VzdCBjbGFyaWZ5aW5nIHRoYXQgYSBzaW5nbGUga2V5 IGlkZW50aWZpZXIgaXMgdXNlZCB0byBsb29rdXANCj4gYm90aCB0aGUgYXNzb2NpYXRlZCBFTkNf S0VZIGFuZCB0aGUgYXNzb2NpYXRlZCBNQUNfS0VZIChvciwNCj4gYWx0ZXJuYXRlbHksIHRoYXQg aXQgaXMgbG9naWNhbGx5IGJvdW5kIHRvIEsgYW5kIHJlbWluZCB0aGUgcmVhZGVyDQo+IHRoYXQg RU5DX0tFWSBhbmQgTUFDX0tFWSBhcmUgZXh0cmFjdGVkIGZyb20gSyBhbmQgbWlnaHQgYmUNCj4g c2VwYXJhdGVseSBkaXN0cmlidXRlZCkuDQoNCltNZWRdIEFkZGVkIHRoaXMgTkVXOiANCg0KIkEg c2luZ2xlIGtleSBpZGVudGlmaWVyIGlzIHVzZWQgdG8gbG9va3VwIGJvdGggdGhlIEVOQ19LRVkg YW5kIHRoZSBNQUNfS0VZIGFzc29jaWF0ZWQgd2l0aCBhIGtleS4iIA0KDQo+IA0KPiAgICBLZXkg TGVuZ3RoOiAgVmFyaWFibGUuICBDYXJyaWVzIHRoZSBsZW5ndGggb2YgdGhlIGtleSBpZGVudGlm aWVyLg0KPiAgICBbLi4uXQ0KPiAgICBJViBMZW5ndGg6ICBDYXJyaWVzIHRoZSBsZW5ndGggb2Yg dGhlIElWIChTZWN0aW9uIDUuMiBvZg0KPiBbUkZDNzUxOF0pLg0KPiAgICAgICBJZiBlbmNyeXB0 aW9uIGlzIG5vdCB1c2VkLCBJViBsZW5ndGggaXMgc2V0IHRvIHplcm8gKHRoYXQgaXMsDQo+IG5v DQo+ICAgICAgICJJbml0aWFsaXphdGlvbiBWZWN0b3IiIGlzIGluY2x1ZGVkKS4NCj4gDQo+IFBs ZWFzZSBhbHNvIHNwZWNpZnkgdGhhdCB0aGUgS2V5L0lWIGxlbmd0aHMgYXJlIG1lYXN1cmVkIGlu IGJ5dGVzDQoNCltNZWRdIEZpeGVkIHBlciBhIGNvbW1lbnQgZnJvbSBFcmljLg0KDQo+ICh0aGUg cmVmZXJlbmNlIGZvciBJViBsZW5ndGgsIGF0IGxlYXN0LCB0YWxrcyBhYm91dCBJVnMgaW4gYml0 cykuDQo+IA0KPiBJIHN0cm9uZ2x5IHN1Z2dlc3QgdXNpbmcgYSB2YWx1ZSBvdGhlciB0aGFuIHpl cm8gYXMgdGhlIHNlbnRpbmVsDQo+IHZhbHVlIGZvciAibm8gZW5jcnlwdGlvbiIgLS0gdGhlcmUg YWxyZWFkeSBleGlzdCBtb2RlcyBsaWtlIEFFUy1TSVYNCj4gKFJGQyA1Mjk3KSB0aGF0IGRvIG5v dCByZXF1aXJlIGFuIElWIGlucHV0LCB3aGljaCB3b3VsZCBiZSBhIG5hdHVyYWwNCj4gdXNlIGZv ciB6ZXJvLWxlbmd0aCBJVi4NCg0KW01lZF0gV2hhdCBpcyB0aGUgYWR2YW50YWdlIG9mIHVzaW5n IGEgdmFsdWUgb3RoZXIgdGhhbiB6ZXJvIHdoZW4gZW5jcnlwdGlvbiBpcyBub3QgaW5jbHVkZWQ/ IA0KDQo+IA0KPiBBZGRpdGlvbmFsbHksIG9uZSBtaWdodCBpbWFnaW5lIHVzaW5nIGEgbm9uLXpl cm8tbGVuZ3RoIElWIGFzIGlucHV0DQo+IHRvIGFuIEhNQUMgY2FsY3VsYXRpb24gYXMgYSBwZXIt bWVzc2FnZSBub25jZS4gIE9uIGN1cnNvcnkNCj4gZXhhbWluYXRpb24sIHNpbmNlIHdlIGFyZSBh bHJlYWR5IHVzaW5nIHRpbWVzdGFtcC1iYXNlZCByZXBsYXkNCj4gZGV0ZWN0aW9uLCB0aGUgYWRk aXRpb25hbCBub25jZSBpcyB1bmxpa2VseSB0byBhZGQgbXVjaCB2YWx1ZSwgYnV0DQo+IEknbSBu b3Qgd2lsbGluZyB0byBjb21wbGV0ZWx5IHJ1bGUgaXQgb3V0IG9uIHRoZSBiYXNpcyBvZiB0aGUN Cj4gbWluaW1hbCBhbmFseXNpcyBJIHBlcmZvcm1lZC4NCj4gDQo+IFNlY3Rpb24gNy4xDQo+IA0K PiAgICBPbmx5IG9uZSBpbnN0YW5jZSBvZiAiTUFDIGFuZCBFbmNyeXB0ZWQgTWV0YWRhdGEiIENv bnRleHQgSGVhZGVyDQo+ICAgIChTZWN0aW9uIDUpIGlzIGFsbG93ZWQuICBJZiBtdWx0aXBsZSBp bnN0YW5jZXMgb2YgIk1BQyBhbmQNCj4gRW5jcnlwdGVkDQo+ICAgIE1ldGFkYXRhIiBDb250ZXh0 IEhlYWRlciBhcmUgaW5jbHVkZWQgaW4gYW4gTlNIIHBhY2tldCwgdGhlIFNGQw0KPiBkYXRhDQo+ IA0KPiBJIHRoaW5rIFJvbWFuIG1heSBoYXZlIG1lbnRpb25lZCB0aGlzIGFscmVhZHksIGJ1dCBw bGVhc2UgY2xhcmlmeSBpZg0KPiB0aGlzIGlzIG9uZSBpbnN0YW5jZSBwZXIgTlNIIG9yIHBlciBw YWNrZXQgKGUuZy4sIGluIGhpZXJhcmNoaWNhbA0KPiBTRkMgd2UgbWlnaHQgaGF2ZSBtb3JlIHRo YW4gb25lIE5TSCBpbiBhIHBhY2tldCkuDQoNCltNZWRdIEkgY29uZmlybS4NCg0KPiANCj4gUGxl YXNlIGFsc28gY2xhcmlmeSBpdCBpZiBpcyBwZXJtaXR0ZWQgdG8gaGF2ZSBib3RoIE1BQyMxIGFu ZCBNQUMjMg0KPiBwcmVzZW50IGluIHRoZSBzYW1lIHBhY2tldC4gIChJSVVDIHRoZXJlIGFyZSBu b3Qgb2J2aW91cyBzaXR1YXRpb25zDQo+IHdoZXJlIHN1Y2ggYSBzZXR1cCB3b3VsZCBiZSB1c2Vm dWwsIGJ1dCBpdCdzIHN0aWxsIGdvb2QgdG8gYmUgY2xlYXINCj4gYWJvdXQgZXhwZWN0YXRpb25z LikNCg0KW01lZF0gSXQgaXMgbm90IGFsbG93ZWQgdG8gaGF2ZSBib3RoLiBUaGlzIGlzIHdoeSB3 ZSBhcmUgdXNpbmcgdGhlIGdlbmVyaWMgdGVybTogImluc3RhbmNlIG9mICJNQUMgYW5kIEVuY3J5 cHRlZCBNZXRhZGF0YSIgQ29udGV4dCBIZWFkZXIiLiBUaGF0IHRlcm0gaXMgdXNlZCB0aHJvdWdo IHRoZSBkb2N1bWVudCB3aGVuIHdlIHJlZmVyIGluZGlmZmVyZW50bHkgdG8gTUFDIzEgYW5kIE1B QyMyLg0KICANCj4gDQo+IFNlY3Rpb24gNy4yDQo+IA0KPiAgICBJZiB0aGUgQ29udGV4dCBIZWFk ZXJzIGFyZSBub3QgZW5jcnlwdGVkLCB0aGUgSE1BQyBhbGdvcml0aG0NCj4gICAgZGlzY3Vzc2Vk IGluIFtSRkM0ODY4XSBpcyB1c2VkIHRvIGludGVncml0eSBwcm90ZWN0IHRoZSB0YXJnZXQNCj4g TlNIDQo+ICAgIGRhdGEuICBbLi4uXQ0KPiANCj4gSXQncyBub3QgcmVhbGx5IGNsZWFyIHRvIG1l IHdoeSBSRkMgNDg2OCBpcyB0aGUgcmlnaHQgcmVmZXJlbmNlDQo+IGhlcmUsIGFzIG9wcG9zZWQg dG8gKGUuZy4pIFJGQyAyMTA0LiAgSW4gcGFydGljdWxhciwgc2VlIG15IERpc2N1c3MNCj4gcG9p bnQgKDIpLg0KDQpbTWVkXSBXZSB0aGluayB0aGF0IFJGQyA0ODY4IGlzIHRoZSByaWdodCByZWZl cmVuY2UgYXMgUkZDIDIwMTQgZG9lcyBub3QgZGlzY3VzcyBhbnkgb2YgdGhlIEhNQUMgYWxnb3Jp dGhtcyB1c2VkIGluIHRoaXMgc3BlY2lmaWNhdGlvbi4gDQoNCj4gDQo+ICAgIFRoZSBNZXNzYWdl IEF1dGhlbnRpY2F0aW9uIENvZGUgKFQpIGNvbXB1dGF0aW9uIHByb2Nlc3MgY2FuIGJlDQo+ICAg IGlsbHVzdHJhdGVkIGFzIGZvbGxvd3M6DQo+IA0KPiAgICAgICAgICBUID0gSE1BQy1TSEEtMjU2 LTEyOChNQUNfS0VZLCBBKQ0KPiANCj4gSSBhZ3JlZSB3aXRoIHRoZSBvdGhlciByZXZpZXdlciB0 aGF0IHdvbmRlcmVkIGFib3V0IGp1c3QgdXNpbmcgIk1BQyINCj4gKG9yIG1heWJlICJITUFDIikg cmF0aGVyIHRoYW4gIkhNQUMtU0hBLTI1Ni0xMjgiIGhlcmUgKEkgZG8gc2VlIHRoZQ0KPiAiY2Fu IGJlIGlsbHVzdHJhdGVkIGFzIiBxdWFsaWZpZXIpLg0KPiANCj4gSXQncyBhbHNvIGEgbGl0dGxl IHdlaXJkIHRvIHJldXNlIFQgYW5kIEEgZnJvbSB0aGUgQUVBRCBjb25zdHJ1Y3Rpb24NCj4gKG9y IFJGQyA0ODY4KSBoZXJlIHdpdGhvdXQgYWRkaXRpb25hbCBkaXNjdXNzaW9uIG9uIGhvdyB0aGV5 IGFwcGx5DQo+IGFuZCBob3cgdGhlIHZhbHVlIG9mIEEgaXMgY29uc3RydWN0ZWQuDQoNCltNZWRd IE5vdGVkLiBXZSBtYWRlIGFscmVhZHkgdGhpcyBjaGFuZ2U6IHMvQS90YXJnZXQgTlNIIGRhdGEu IA0KDQo+IA0KPiAgICBBbiBlbnRpdHkgaW4gdGhlIFNGUCB0aGF0IGludGVuZHMgdG8gdXBkYXRl IHRoZSBOU0ggTVVTVCBmb2xsb3cNCj4gdGhlDQo+ICAgIGFib3ZlIGJlaGF2aW9yIHRvIG1haW50 YWluIG1lc3NhZ2UgaW50ZWdyaXR5IG9mIHRoZSBOU0ggZm9yDQo+ICAgIHN1YnNlcXVlbnQgdmFs aWRhdGlvbnMuDQo+IA0KPiBJJ20gbm90IHN1cmUgdGhhdCAiaW50ZW5kcyB0byIgaXMgbmVlZGVk OyB0aGUgcmVxdWlyZW1lbnQgYXBwbGllcyB0bw0KPiBhY3Rpb25zLCBub3QgaW50ZW50Lg0KDQpb TWVkXSBGYWlyLiBGaXhlZCwgdGhhbmtzLg0KDQo+IA0KPiBTZWN0aW9uIDcuMw0KPiANCj4gICAg SW4gYW4gU0ZDLWVuYWJsZWQgZG9tYWluIHdoZXJlIHBlcnZhc2l2ZSBtb25pdG9yaW5nIFtSRkM3 MjU4XSBpcw0KPiAgICBwb3NzaWJsZSwgYWxsIENvbnRleHQgSGVhZGVycyBjYXJyeWluZyBwcml2 YWN5LXNlbnNpdGl2ZSBtZXRhZGF0YQ0KPiAgICBNVVNUIGJlIGVuY3J5cHRlZDsgWy4uLl0NCj4g DQo+IEkgYWdyZWUgd2l0aCB0aGUgb3RoZXIgcmV2aWV3ZXIgdGhhdCBub3RlZCB0aGF0IHRoaXMg c2VlbXMgdG8NCj4gZWZmZWN0aXZlbHkgYmUgYW4gdW5xdWFsaWZpZWQgIk1VU1QiLCBzaW5jZSB0 aGVyZSBpcyBhbHdheXMgc29tZQ0KPiBwb3NzaWJpbGl0eSBvZiBtb25pdG9yaW5nLg0KPiANCj4g ICAgICAgICAgTUFDX0tFWSA9IGluaXRpYWwgTUFDX0tFWV9MRU4gb2N0ZXRzIG9mIEssDQo+ICAg ICAgICAgIEVOQ19LRVkgPSBmaW5hbCBFTkNfS0VZX0xFTiBvY3RldHMgb2YgSywNCj4gICAgICAg ICAgRSA9IENCQy1QS0NTNy1FTkMoRU5DX0tFWSwgUCksDQo+ICAgICAgICAgIE0gPSBNQUMoTUFD X0tFWSwgQSB8fCBJViB8fCBFIHx8IEFMKSwNCj4gICAgICAgICAgVCA9IGluaXRpYWwgVF9MRU4g b2N0ZXRzIG9mIE0uDQo+ICAgICAgICAgIE1BQyBhbmQgRW5jcnlwdGVkIE1ldGFkYXRhID0gRSB8 fCBUDQo+IA0KPiBJIHJlY29nbml6ZSB0aGF0IHRoaXMgaXMganVzdCBjb3B5K3Bhc3RlIGZyb20g UkZDIDc1MTggKHdpdGggdGhlDQo+IGFkZGl0aW9uIG9mIHRoZSBsYXN0IGxpbmUpLCBidXQgaXQg c2VlbXMgYSBnbGFyaW5nIG9taXNzaW9uIHRoYXQgdGhlDQo+IENCQy1QS0NTNy1FTkMoKSBpbnZv Y2F0aW9uIGRvZXMgbm90IGluY2x1ZGUgdGhlIElWIGFzIGFuIGlucHV0IQ0KPiAoSW4gwqc1LjIu Mi4xIG9mIFJGQyA3NTE4IHdlIGRvIHNlZSB0aGF0ICJUaGUgcGxhaW50ZXh0IGlzIENCQw0KPiBl bmNyeXB0ZWQgdXNpbmcgUEtDUyAjNyBwYWRkaW5nIHVzaW5nIEVOQ19LRVkgYXMgdGhlIGtleSBh bmQgdGhlDQo+IElWIiwgc28gaXQncyBqdXN0IHRoZSBmaWd1cmUvZm9ybXVsYSB0aGF0IG9taXRz IHRoZSBJVi4pDQo+IA0KPiBXZSBhbHNvIGRvbid0IGRlZmluZSBvciBtZW50aW9uIFRfTEVOIGlu IHRoaXMgZG9jdW1lbnQgb3RoZXIgdGhhbiBpbg0KPiB0aGlzIGZvcm11bGEgYW5kIHRoZSBhbmFs b2dvdXMgb25lIGZvciBNQUMtd2l0aG91dC1lbmNyeXB0aW9uLCB3aGljaA0KPiBtaWdodCBiZSB3 b3J0aCByZW1lZHlpbmcuDQoNCltNZWRdIElmIHdlIG1hbmRhdGUgQUVTX0dDTSwgYWxsIHRoZSBh Ym92ZSB0ZXh0IHdpbGwgYmUgcmVtb3ZlZC4NCg0KPiANCj4gU2VjdGlvbiA3LjQNCj4gDQo+IEkg c3VnZ2VzdCBhZGRpbmcgYW5vdGhlciB3b3JkIChsaWtlICJQcmV2ZW50aW9uIikgdG8gdGhlIHNl Y3Rpb24NCj4gdGl0bGUuDQo+IA0KDQpbTWVkXSBGaXhlZC4gDQoNCj4gICAgVGhlIHJlY2VpdmVk IE5TSCBpcyBhY2NlcHRlZCBieSBhbiBOU0gtYXdhcmUgbm9kZSBpZiB0aGUNCj4gVGltZXN0YW1w DQo+ICAgIChUUykgaW4gdGhlIE5TSCBpcyByZWNlbnQgZW5vdWdoIHRvIHRoZSByZWNlcHRpb24g dGltZSBvZiB0aGUgTlNIDQo+ICAgIChUU3J0KS4gIFRoZSBmb2xsb3dpbmcgZm9ybXVsYSBpcyB1 c2VkIGZvciB0aGlzIGNoZWNrOg0KPiANCj4gICAgICAgICAgICAgIC1EZWx0YSA8IChUU3J0IC0g VFMpIDwgK0RlbHRhDQo+IA0KPiAoVGhlcmUncyBubyByZWFsIHJlYXNvbiB3aHkgdGhlIGFjY2Vw dGVkIHRpbWVzdGFtcCBza2V3IHBhcmFtZXRlcg0KPiBEZWx0YSBuZWVkcyB0byBiZSBzeW1tZXRy aWMgaW4gdGhlIHBvc2l0aXZlIGFuZCBuZWdhdGl2ZQ0KPiBkaXJlY3Rpb25zLikNCg0KW01lZF0g VGhpcyB3YXMgdG8gYWNjb21tb2RhdGUgYW55IHN5bmMgaXNzdWVzLg0KDQo+IA0KPiAgICBSZXBs YXkgYXR0YWNrcyB3aXRoaW4gdGhlIERlbHRhIHdpbmRvdyBtYXkgYmUgZGV0ZWN0ZWQgYnkgYW4g TlNILQ0KPiAgICBhd2FyZSBub2RlIGJ5IHJlY29yZGluZyBhIHVuaXF1ZSB2YWx1ZSBkZXJpdmVk LCBmb3IgZXhhbXBsZSwgZnJvbQ0KPiB0aGUNCj4gICAgTlNIIGRhdGEgYW5kIE9yaWdpbmFsIHBh Y2tldCAoZS5nLiwgdXNpbmcgU0hBMikuICBbLi4uXQ0KPiANCj4gTm90ZSB0aGF0IHRoZSB1bmlx dWUgdmFsdWUgTVVTVCBOT1QgdXNlIGFzIGlucHV0IGFueSBiaXRzIHRoYXQgYXJlDQo+IG5vdCBj b3ZlcmVkIGJ5IHRoZSBNQUMuIA0KDQpbTWVkXSBBZ3JlZSwgYnV0IHdlIGRvbid0IHNwZWNpZnkg dGhlIGJpdHMgdGhhdCBhcmUgdXNlZC4gDQoNCiBJbmRlZWQsIGp1c3QgdXNpbmcgdGhlIE1BQyBp dHNlbGYgYXMgdGhlDQo+IHVuaXF1ZSB2YWx1ZSB3b3VsZCBiZSBhIGZhaXJseSBzdHJhaWdodGZv cndhcmQgc2NoZW1lLCBJIHRoaW5rLg0KDQpbTWVkXSBUaGFua3MuDQoNCj4gDQo+IFNlY3Rpb24g Ny41DQo+IA0KPiAgICBXaGVuIGFuIFNGQyBkYXRhIHBsYW5lIGVsZW1lbnQgcmVjZWl2ZXMgYW4g TlNIIHBhY2tldCwgaXQgTVVTVA0KPiBmaXJzdA0KPiAgICBlbnN1cmUgdGhhdCBhICJNQUMgYW5k IEVuY3J5cHRlZCBNZXRhZGF0YSIgQ29udGV4dCBIZWFkZXIgaXMNCj4gICAgaW5jbHVkZWQuICBb Li4uXQ0KPiANCj4gVGhpcyBzb3J0IG9mIHJlcXVpcmVtZW50IChhcyB3cml0dGVuKSB3b3VsZCBz ZWVtIHRvIHN1cHBvcnQgdGhlDQo+IHBvc2l0aW9uIG9mIHNvbWUgb3RoZXIgcmV2aWV3ZXJzIHRo YXQgdGhpcyBkb2N1bWVudCB3b3VsZCBuZWVkIHRvDQo+IGZvcm1hbGx5IHVwZGF0ZSBSRkMgODMw MC4NCg0KW01lZF0gQWRkZWQgIldoZW4gYW4gU0ZDIGRhdGEgcGxhbiBlbGVtZW50IGNvbmZvcm1z IHRvIHRoaXMgc3BlY2lmaWNhdGlvbiwiIHRvIGFkZHJlc3Mgb25lIG9mIFJvbWFuJ3MgY29tbWVu dHMuIA0KDQo+IA0KPiBTZWN0aW9uIDkNCj4gDQo+IFdlIG1pZ2h0IGRpc2N1c3MgdGhhdCB0aGlz IG1lY2hhbmlzbSBpcyBvbmx5IGZvciBtZXRhZGF0YSB0eXBlIDIgYW5kDQo+IG5vdCB0eXBlIDEg KGFzIHdlbGwgYXMgdGhhdCB3aXRoIHRoZSByZWxhdGl2ZWx5IHNtYWxsIGZpeGVkIGxlbmd0aA0K PiBvZiB0eXBlIDEgbWV0YWRhdGEsIGl0J3MgcXVpdGUgY2hhbGxlbmdpbmcgdG8gcHJvdmlkZSB1 c2VmdWwNCj4gY3J5cHRvZ3JhcGhpYyBwcm90ZWN0aW9uKSwgc28gdGhhdCB0eXBlLTEgbWV0YWRh dGEgc3RpbGwgaGFzIG5vDQo+IGdlbmVyaWMgcHJvdGVjdGlvbiBtZWNoYW5pc20uICBBIGdpdmVu IG1ldGFkYXRhIGVsZW1lbnQgY291bGQgZGVmaW5lDQo+IGl0cyBvd24gcHJvdGVjdGlvbiBzY2hl bWUsIG9mIGNvdXJzZS4NCg0KW01lZF0gV2UgYWxyZWFkeSBoYXZlIHRoZSBmb2xsb3dpbmcgaW4g dGhlIGludHJvZHVjdGlvbjoNCg0KICAgVGhpcyBzcGVjaWZpY2F0aW9uIGlzIG9ubHkNCiAgIGFw cGxpY2FibGUgdG8gTlNIIE1EIFR5cGUgMHgwMiAoU2VjdGlvbiAyLjUgb2YgW1JGQzgzMDBdKS4N Cg0KPiANCj4gICAgVGhlIGF0dGFja3MgZGlzY3Vzc2VkIGluIFtJLUQubmd1eWVuLXNmYy1zZWN1 cml0eS1hcmNoaXRlY3R1cmVdDQo+IGFyZQ0KPiAgICBoYW5kbGVkIG93aW5nIHRvIHRoZSBzb2x1 dGlvbiBzcGVjaWZpZWQgaW4gdGhpcyBkb2N1bWVudCwgZXhjZXB0DQo+IGZvcg0KPiAgICBhdHRh Y2tzIGRyb3BwaW5nIHBhY2tldHMuICBbLi4uXQ0KPiANCj4gPkZyb20gYSB2ZXJ5IHF1aWNrIHJl YWQsIGRyYWZ0LW5ndXllbi1zZmMtc2VjdXJpdHktYXJjaGl0ZWN0dXJlDQo+IHByb3Bvc2VzDQo+ IGEgcHJvYmUtYmFzZWQgc2NoZW1lIHRoYXQgbW9uaXRvcnMgYWxsIG1pZGRsZWJveGVzIChvciBh dCBsZWFzdA0KPiB0aG9zZSBpbiB0aGUgZXhwZWN0ZWQgcGF0aCkgdG8gZGV0ZWN0IGEgbWlkZGxl Ym94LWJ5cGFzcyBhdHRhY2sgYW5kDQo+IHZlcmlmeSB0aGF0IHRoZSBwcm9iZSB0cmF2ZXJzZWQg dGhlIGV4cGVjdGVkIFNGUC4gIEkgYW0gbm90IHN1cmUNCj4gdGhhdCB0aGlzIGRvY3VtZW50IG9u IGl0cyBvd24gc3VmZmljZXMgdG8gcHJldmVudCB0aGUgbWlkZGxlYm94LQ0KPiBieXBhc3MgYXR0 YWNrIGZvciBhbGwgdHJhZmZpYyAoaS5lLiwgdGhlIHByb2JlLWJhc2VkIHNjaGVtZSBtaWdodA0K PiBzdGlsbCBiZSBuZWVkZWQpLiAgSWYgc29tZSBuZXR3b3JrIGVudGl0aWVzIGtub3cgd2hhdCB0 aGUgZXhwZWN0ZWQNCj4gc2VydmljZSBpbmRleCB3aWxsIGJlIGZvciBhIGdpdmVuIFNQSSBhdCBh IGdpdmVuIG5vZGUsIHRoZW4NCj4gbWlkZGxlYm94LWJ5cGFzcyBhdHRhY2tzIGNvdWxkIGJlIG5h dGl2ZWx5IGRldGVjdGVkLCBidXQgbXkNCj4gdW5kZXJzdGFuZGluZyB3YXMgdGhhdCBzdWNoIGFk dmFuY2Uga25vd2xlZGdlIG9mIGV4cGVjdGVkIHNlcnZpY2UNCj4gaW5kZXggd2FzIG5vdCBnb2lu ZyB0byBiZSBhdmFpbGFibGUuDQoNCltNZWRdIFRoZSBTRiBieXBhc3MgY2FuIGJlIGRldGVjdGVk IGlmIFNJIHdhcyBtYW5pcHVsYXRlZCBvbiBwYXRoIGJlY2F1c2UgaW50ZWdyaXR5IGNoZWNrIHdp bGwgZmFpbC4gDQoNCj4gDQo+ICAgIFRoZSBzb2x1dGlvbiBzcGVjaWZpZWQgaW4gdGhpcyBkb2N1 bWVudCBkb2VzIG5vdCBwcm92aWRlIGRhdGENCj4gb3JpZ2luDQo+ICAgIGF1dGhlbnRpY2F0aW9u Lg0KPiANCj4gSSB3b3VsZCBoYXZlIGV4cGVjdGVkIG1vcmUgaW4tZGVwdGggZGlzY3Vzc2lvbiBv ZiB0aGUgc2VjdXJpdHkNCj4gY29uc2lkZXJhdGlvbnMgZm9yIGEgZ3JvdXAtc2hhcmVkIFBTSyBz Y2hlbWUsIGluY2x1ZGluZyBob3cgdGhlIHJpc2sNCj4gb2Yga2V5IGxvc3MvY29tcHJvbWlzZSBn b2VzIHVwIHdoZW4gdGhlIGtleSBpcyBkaXN0cmlidXRlZCB0byBtb3JlDQo+IGxvY2F0aW9ucy4N Cg0KW01lZF0gVGhhdCdzIHBhcnQgb2YgdGhlIGtleSBtYW5hZ2VtZW50LCBkZWNsYXJlZCBvdXQg b2Ygc2NvcGUuICAgDQoNCj4gDQo+IFNlY3Rpb24gOS4xDQo+IA0KPiAgICBObyBkZXZpY2Ugb3Ro ZXIgdGhhbiB0aGUgTlNILWF3YXJlIFNGcyBpbiB0aGUgU0ZDLWVuYWJsZWQgZG9tYWluDQo+ICAg IHNob3VsZCBiZSBhYmxlIHRvIHVwZGF0ZSB0aGUgaW50ZWdyaXR5IHByb3RlY3RlZCBOU0ggZGF0 YS4NCj4gDQo+IFdoYXQgYWJvdXQgY2xhc3NpZmllcnMgYW5kIFNGQyBwcm94aWVzPw0KDQpbTWVk XSBHb29kIGNhdGNoOiBwcm94aWVzIHNob3VsZCBiZSBtZW50aW9uZWQgYXMgd2VsbCBhcyByZS1j bGFzc2lmaWNhdGlvbi4gV2UgY2FuJ3QganVzdCB0YWxrIGFib3V0IGNsYXNzaWZpY2F0aW9uIGFz IHRoaXMgaXMgYWJvdXQgdXBkYXRpbmcgdGhlIE1BQy4gDQoNClRoZSBORVcgdGV4dCB0aGF0IGFs c28gdGFrZXMgaW50byBhY2NvdW50IGEgY29tbWVudCBmcm9tIEpvaG4gaXMgYXMgZm9sbG93czog DQoNCiAgIEl0IGlzIGV4cGVjdGVkIHRoYXQgc3BlY2lmaWMgZGV2aWNlcyBpbiB0aGUgU0ZDLWVu YWJsZWQgZG9tYWluIHdpbGwNCiAgIGJlIGNvbmZpZ3VyZWQgc3VjaCB0aGF0IG5vIGRldmljZSBv dGhlciB0aGFuIHRoZSBjbGFzc2lmaWVycyAod2hlbg0KICAgcmVjbGFzc2lmaWNhdGlvbiBpcyBl bmFibGVkKSwgTlNILWF3YXJlIFNGcywgYW5kIFNGQyBwcm94aWVzIHdpbGwgYmUNCiAgIGFibGUg dG8gdXBkYXRlIHRoZSBpbnRlZ3JpdHkgcHJvdGVjdGVkIE5TSCBkYXRhIChTZWN0aW9uIDcuMSks IGFuZA0KICAgYWxzbyBzdWNoIHRoYXQgbm8gZGV2aWNlIG90aGVyIHRoYW4gdGhlIE5TSC1hd2Fy ZSBTRnMgYW5kIFNGQyBwcm94aWVzDQogICB3aWxsIGJlIGFibGUgdG8gZGVjcnlwdCBhbmQgdXBk YXRlIHRoZSBDb250ZXh0IEhlYWRlcnMgY2FycnlpbmcNCiAgIHNlbnNpdGl2ZSBtZXRhZGF0YSAo U2VjdGlvbiA3LjEpLg0KDQo+IA0KPiBTZWN0aW9uIDkuMg0KPiANCj4gSSBleHBlY3RlZCB0byBz ZWUgc29tZSByZW1hcmtzIGhlcmUgYW5hbG9nb3VzIHRvIHRoZSBzZWNvbmQNCj4gcGFyYWdyYXBo IG9mDQo+IMKnOS4xIChldmVuIGlmIGp1c3QgYnkgcmVmZXJlbmNlIHRvIHRoYXQgc2VjdGlvbiku DQoNCltNZWRdIEFkZGVkIHRoaXMgTkVXIHNlbnRlbmNlOiANCg0KICAgU2ltaWxhciB0byBTZWN0 aW9uIDkuMSwgbm8gZGV2aWNlIG90aGVyIHRoYW4gdGhlIE5TSC1hd2FyZSBTRnMgYW5kDQogICBT RkMgcHJveGllcyBpbiB0aGUgU0ZDLWVuYWJsZWQgZG9tYWluIHNob3VsZCBiZSBhYmxlIHRvIGRl Y3J5cHQgYW5kDQogICB1cGRhdGUgdGhlIENvbnRleHQgSGVhZGVycyBjYXJyeWluZyBzZW5zaXRp dmUgbWV0YWRhdGEuIA0KDQo+IA0KPiBTZWN0aW9uIDkuMw0KPiANCj4gICAgU2VjdGlvbiA1LjYg b2YgW1JGQzg2MzNdIGRlc2NyaWJlcyBiZXN0IGN1cnJlbnQgcHJhY3RpY2VzIHRvIGJlDQo+ICAg IGNvbnNpZGVyZWQgaW4gZGVwbG95bWVudHMgd2hlcmUgU0ZDIGRhdGEgcGxhbmUgZWxlbWVudHMg dXNlIE5UUA0KPiBmb3INCj4gICAgdGltZSBzeW5jaHJvbml6YXRpb24gcHVycG9zZXMuDQo+IA0K PiBUaGUgcmVmZXJlbmNlZCBzZWN0aW9uIGNvdmVycyBOVFAgc3ltbWV0cmljIG1vZGUgb25seS4N Cg0KW01lZF0gWWVzIGJlY2F1c2Ugd2UgdGhpbmsgdGhhdOKAmXMgdGhlIHN5bW1ldHJpYyBtb2Rl IGlzIGJldHRlciB2cy4gYnJvYWRjYXN0IHdpdGggdHJ1c3RlZCBtb2Rlcy4gDQoNCiAgSXMNCj4g Y2xpZW50L3NlcnZlciBtb2RlIG5vdCBhIEJDUCBmb3IgdHJ1c3RlZCBuZXR3b3JrcyBhbmQNCj4g YnJvYWRjYXN0L3N5bW1ldHJpYyB0aGUgb25seSBvcHRpb25zPyANCg0KW01lZF0gTm90IHN1cmUg dG8gZ2V0IHRoaXMgY29tbWVudC4gDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2Vz IGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxl cyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBl eHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBj ZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVy IGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdl cyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBk ZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBk ZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRo YXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRl ZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRl bGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBh bHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4g bW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Mon Jul 19 00:50:46 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A153A27D2; Mon, 19 Jul 2021 00:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMYgoMAvC3II; Mon, 19 Jul 2021 00:50:31 -0700 (PDT) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 2C86A3A27D1; Mon, 19 Jul 2021 00:50:24 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id g8so22826914lfh.8; Mon, 19 Jul 2021 00:50:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rEf6domIG4OQKOhLuuPHiU4Gkd5XKulZolRGh4zXntM=; b=tn3/VZpnwC+cP17FJL96HCWD76Mo2Q4Ta+n1YPIGaCRE9n6dejlcPuQ3QDtCUQtJqH hTZ5K+acFCBs9E+7wtUZqr08SUvsptdNk/n7cinvt8Urvi8mLnTMtceInMJ8L7ZCKQB6 J1e0FDZ0f14tJgB4J10OfBdBdwxeVS2cUEm8GXKqmyDlNaeKscZ4gY2gs67gIQi9NYvs AK4Jw8ueyUq/xGsKD1plYu1xwJaOkqcdlS8jVBWX+r+pf01spnKQTHSboYfZ4PPi6Nzf GBPI7qBDuPiqp2XzouOsa8FxW7tir0kWdB7q0gHP7nTkFasgyWRD4eeb7axlhThvRCON TapA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rEf6domIG4OQKOhLuuPHiU4Gkd5XKulZolRGh4zXntM=; b=rZMcFfmtLk2dXzFDcbd24tghdC6kvZFCCoZSesgp1g9TS0TbVLepmr1tFCHKmuPcEv QdW2RVu14h/EuXTh4EDFWn0sH4+wyVl1SW8fZzYTVM7u96pmXruph2JSqZ19tjJJtCwY S7VaFkr5vdw9p8E3eWi6NasFATe+lvIZEjoax1eI5AHmEb/a/0uGuAvCy0pfjEt5sFON B8lVLv1cIugqjJoiN0cSQ6PAoK2CG9vvyPR42scOfzZNh1YP3/HotSqnCs3L7hb8IOJT H3nuYa+CdWpRRhy/NGuzQ67t8atqUT5XtTwraBmjKtLYBnm4HuVTCN0zSnbVY2cLy5By eVYg== X-Gm-Message-State: AOAM531mQzX7qn2+g0Kkb5P7+Ls4we2qBfLLKfJuN4JANm6OLolGee+3 Zph/39W7cCNxcvHZnIiwN5K8Lfoxhwp/HQOKAIE= X-Google-Smtp-Source: ABdhPJzZ5znt2DpsUXTyYK32kX96Ok1a5dqqAjdWEIxEq/raiv9M2Ow99Bzxgt5sT0MLpwkZZDXaLaMD9KOotHLjuio= X-Received: by 2002:a19:f00c:: with SMTP id p12mr17658350lfc.647.1626681022481; Mon, 19 Jul 2021 00:50:22 -0700 (PDT) MIME-Version: 1.0 References: <162629795136.25767.17850752260179612361@ietfa.amsl.com> In-Reply-To: <162629795136.25767.17850752260179612361@ietfa.amsl.com> From: tirumal reddy Date: Mon, 19 Jul 2021 13:20:11 +0530 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-sfc-nsh-integrity@ietf.org, sfc-chairs@ietf.org, sfc@ietf.org, gregimirsky@gmail.com Content-Type: multipart/alternative; boundary="000000000000820a0205c77530a4" Archived-At: Subject: Re: [sfc] Benjamin Kaduk's Discuss on draft-ietf-sfc-nsh-integrity-06: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2021 07:50:39 -0000 --000000000000820a0205c77530a4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ben, Please see inline On Thu, 15 Jul 2021 at 02:55, Benjamin Kaduk via Datatracker < noreply@ietf.org> wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-sfc-nsh-integrity-06: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > (0) (I came to this realization rather late in my review process, so > there may be places where the COMMENT and this discuss point are in > disagreement; this DISCUS takes precedence.) > I fear that the construction that separately distributes ENC_KEY and > MAC_KEY in an attempt to achieve privilege separation is fatally flawed. > In particular, the CBC encryption mode is a malleable encryption mode, > in that flipping a bit of ciphertext will filp the corresponding bit of > the next block of recovered plaintext (at the cost of completely > garbling the recovered block containing the bit that was modified). > Subsequent blocks are unaffected. Typically we combine CBC mode with a > MAC such as HMAC in order to prevent such modifications from being > exposed as attack vectors, and while we do use HMAC here for that > purpose, we also introduce a separate class of actors that have access > to the HMAC key but not the encryption key. Accordingly, those actors > can produce a new, valid, integrity tag after making a modification to > the ciphertext, allowing them to engage in attacks that make use of > ciphertext malleability. Ciphertext malleability is particularly useful > as an attack vector when the structure of the plaintext being encrypted > is known, and there are portions of the plaintext that the application > will either ignore if they are garbled or are expected to be near random > in the normal case (and thus for which garbled output does not cause > rejection by the application). In a SFC environment it seems highly > likely that the structure of the plaintext will be known or guessable, > and we don't have any real mechanisms to control what types of metadata > go into encrypted context headers, so it seems that we must act as if we > are exposed to this risk. > > While =C2=A74.3 does have a note that use of GCM with HMAC is undesirable= due > to the additional authentication tag, it may be unavoidable in order to > provide the properties that we need. > Thanks for explaining the attack. We will modify the text in Section 4.3 as follows to address the comment: Classifiers, NSH-aware SFs, and SFC proxies MUST implement the AES_128_GCM [GCM][RFC5116] algorithm and SHOULD implement the AES_192_GCM and AES_256_GCM algorithms. Classifiers, NSH-aware SFs, and SFC proxies MUST implement the HMAC- SHA-256-128 algorithm and SHOULD implement the HMAC-SHA-384-192 and HMAC-SHA-512-256 algorithms. SFFs MAY implement the aforementioned cipher suites and HMAC algorithms. Note: The use of AES_128_CBC_HMAC_SHA_256 algorithm would have avoided the need for a second 128-bit authentication tag but due to the nature of how CBC mode operates, the mode allows for malleability of plaintexts. This malleability allows for attackers to make changes in the ciphertext and, if parts of the plaintext are known, create arbitrary blocks of plaintext. This specification mandates the use of AES-GCM to prevent this type of attack. > > (1) Section 5.1 describes the MAC as: > > Message Authentication Code: Covers the entire NSH data, excluding > the Base header. The Additional Authenticated Data (defined in > [RFC7518]) MUST be the Service Path header, the unencrypted > Context headers, and the inner packet on which the NSH is imposed. > > This description seems to exclude from the MAC most of the MAC context > header itself (if we go by the corresponding figure), which is very bad > for security. We definitely need to include under the MAC the MAC > context header bits from metadata class through and including at least > timestamp, and I think IV length as well. (The IV itself would be > incorporated via the ciphertext, since the IV is an input to encryption, > but since the IV length field indicates whether or not encryption was > performed, we'd need to protect that information.) > No, the MAC context header is also used for generating the digest. > > Similarly, Section 5.2 has the description: > > Message Authentication Code: Coves the entire NSH data. The > Additional Authenticated Data (defined in [RFC7518]) MUST be the > entire NSH data (i.e., including the Base Header) excluding the > Context Headers to be encrypted. > > which on the face of it includes the field that holds the MAC itself > (and is not yet populated), i.e., is self-referential. > The below update will address this comment: The NSH imposer sets the MAC field to zero and then computes the message integrity for the target NSH data (depending on the integrity protection scope discussed in Section 5) using MAC_KEY and HMAC algorithm. It inserts the computed digest in the MAC field in the "MAC and Encrypted Metadata" Context Header. > > I think we need to be much more precise about the construction of the > AAD in both cases. It's possible that the HMAC construction for the > no-encrypted-context-headers case can inherit a definition from the AAD > description, but if not we'll need to have some more precision there as > well. > > (2) In order for the MAC-only construction in =C2=A77.2 to be compatible = with > the AEAD integrity tag construction, we would need to include the 64-bit > AL after A. While HMAC is intrinsically immune to length-extension > attacks, I think that having the explicit AL is useful to avoid any risk > of malleability, since the same MAC_KEY is used for constructing both > types of MACs. > I don't think this comment is applicable after AES_128_CBC_HMAC_SHA_256 is removed. > > (3) Section 5.1 describes the Timestamp field as an "unsigned 64-bit > integer value", which is inconsistent with the actual format given in > Section 6. > Thanks, we will fix it in the next revision. > > (4) Section 7.5 directs the verifier to check if "the value of the newly > generated digest is identical to the one enclosed in the NSH". It is > critical for the security of the system that this comparison be done in > a constant-time manner that does not provide a side channel into whether > the generated digest and the value in the NSH share a common substring. > Agreed, will update text as follows: After storing the value of the MAC field in the "MAC and Encrypted Metadata" Context Header, the SFC data plane element fills the MAC field with zeros. Then, the SFC data plane element generates the message integrity for the target NSH data (depending on the integrity protection scope discussed in Section 5) using MAC_KEY and HMAC algorithm. If the value of the newly generated digest is identical to the stored one, the SFC data plane element is certain that the NSH data has not been tampered and validation is therefore successful. Otherwise, the NSH packet MUST be discarded. The comparison of the computed HMAC value to the store value MUS= T be done in a constant-time manner to thwart timing attacks. > > (5) Do the MAC context headers always have to be the last metadata > entries in the packet (to simplify the cryptographic calculations)? > Yes. Cheers, -Tiru > Certainly the diagrams only show "unencrypted context headers" appearing > prior to the MAC context header, so if we expect unencrypted context > headers to appear after the MAC context header as well, we should be > clear about that both in the figures and in the specification for how to > prepare the AAD. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 3 > > o Both encrypted and unencrypted Context Headers MAY be included in > the same NSH. That is, some Context Headers may be protected > while others do not need to be protected. > > In the security area we're pretty strongly moved towards a stance of > "encrypt everything that doesn't have a strong need to be plaintext > (since we don't want to assume that we can predict all threats and > attacks in advance), and QUIC has even taken that to new levels. It's > quite surprising to see "don't need to be protected" as a justification > for lack of encryption, rather than "need to be unprotected". Given > that we're going to be solving key distribution for integrity protection > anyway, it remains unclear to me why we wouldn't just encrypt > everything. > > Section 4.1.1 > > Is the column heading for the middle column of Table 1 referring to the > Base Header and "Service Path Header"? I'm not sure how to interpret > just "Service Header" other than the entire NSH, which doesn't seem > right... > > The Service Path Header (Section 2 of [RFC8300]) is not encrypted > because SFFs use Service Index (SI) in conjunction with Service Path > Identifier (SPI) for determining the next SF in the path. > > It's good to see this spelled out like this; I'd love to have this kind > of explanation for every un-encrypted protocol element. > > Section 4.1.2 > > The solution provides integrity protection for the NSH data. Two > levels of assurance (LoAs) are supported. > > I see (reading onward) that the two LoAs just differ in what is covered > by the integrity tag, but each involve only a single MAC. There's a > reasonable argument that when there are overlapping needs for what data > needs protecting and who needs access to it, that multiple MACs (or > encryption, if needed) are most appropriate, which can be tailored to > the respective needs. This is something that Phillip Hallam-Baker has > ascribed as the "short-blanket theory" of cryptography, in that it's > like a blanket that's too short to cover everything you want, so you > need to have more than one and put them in partially overlapping layers. > Perhaps this "short-blanket theory" is more applicable to Discuss point > (0) than what is covered by the MAC, though... > > The first level of assurance where all NSH data except the Base > Header are integrity protected (Figure 2). In this case, the NSH > imposer may be a Classifier, an NSH-aware SF, or an SFC Proxy. SFFs > are not thus provided with authentication material. [...] > > There seems to be a gap in the chain of reasoning as to why SFFs are not > provided with authentication material. It seems that the intent is > something along the lines of considering which entities need access to > the key material in order to successfully add an NSH or update context > headers, but that alone is not itself cause to say that other entities > can never be provided with the keys (subject to the security > considerations of group-shared PSKs, of course). Furthermore, if a > particular SFF is trusted, it may have grounds to verify the integrity > tag even if it is administratively prohibited from writing such a tag. > > In both levels of assurance, the unencrypted Context Headers and the > packet on which the NSH is imposed are subject to integrity > protection. > > Surely any encrypted Context Headers are also given integrity > protection, as excluding them from the MAC computation would be quite > complex. I see that the encrypted context headers are not part of the > AAD input, but in the AEAD model the ciphertext is still given integrity > protection! > > Section 4.2 > > The authenticated encryption algorithm defined in [RFC7518] is used > to provide NSH data integrity and to encrypt the Context Headers that > carry privacy-sensitive metadata. > > RFC 7518 (JSON Web Algorithms) is a very surprising reference for > generic AEAD encryption. Continuing on, it becomes clear that we in > fact do not want a generic AEAD operation here, but instead have need > for separation of encryption and integrity protection due to the various > separations of roles that are possible. Because this is a divergence > from current best practices (use of native AEAD cipher modes like GCM, > SIV, etc.), I might suggest a rather different introductory material: > > % The AEAD interface specified in RFC 5116 is a very powerful tool for > % providing strong confidentiality and integrity protection for protocol > % messages, and has become quite widely adopted as a result. For > % protecting NSH data we adhere to the spirit of the AEAD interface but > % use a slightly modified version in order to remain consistent with the > % privilege separation needed (e.g., in the second level of assurance, > % SFFs need to be able to update the message integrity tag but do not > % need access to the decrypted plaintext). Accordingly, a compound AEAD > % mechanism combining CBC encryption and HMAC integrity tag is used, so > % that distribution of the encryption key can be limited. Rather than > % define a new scheme from scratch, the AES_CBC_HMAC_SHA2 scheme from > % [RFC7518] is used. In order to simplify key distribution, a single > % secret key material seed K is used, which can be kept private > % centrally or distributed to all parties that will have access to > % decrypted plaintext, and the secondary keys MAC_KEY and ENC_KEY are > % derived from K as discussed in Section 5.2.2.1 of [RFC7518]. Entities > % that need to update the integrity tag but are not authorized to see > % the decrypted plaintext will only receive MAC_KEY and not K or > % ENC_KEY. > > o If the Context Headers are not encrypted, the Hashed Message > Authentication Mode (HMAC) algorithm discussed in [RFC4868] is > used to protect the integrity of the NSH data. > > It's not clear to me that this is adding much value; HMAC is used > whether or not there are encrypted headers, and the RFC 4868 reference > is rather odd (see also my Discuss point (2)). > > The advantage of using the authenticated encryption algorithm is that > NSH-aware SFs and SFC proxies only need to re-compute the message > integrity of the NSH data after decrementing the Service Index (SI) > and do not have to re-compute the ciphertext. The other advantage is > that SFFs do not have access to the ENC_KEY and cannot act on the > encrypted Context Headers and, only in case of the second level of > assurance, SFFs do have access to the MAC_KEY. Similarly, an NSH- > aware SF or SFC Proxy not allowed to decrypt the Context Headers will > not have access to the ENC_KEY. > > [If my above suggestion is used, this text has probably become mostly > redundant and could be trimmed down or removed.] > > The authenticated encryption process takes as input four-octet > strings: a secret key (K), a plaintext (P), Additional Authenticated > Data (A) (which contains the data to be authenticated, but not > encrypted), and an Initialization Vector (IV). The ciphertext value > (E) and the Authentication Tag value (T) are provided as outputs. > > In order to decrypt and verify, the cipher takes as input K, IV, A, > T, and E. The output is either the plaintext or an error indicating > that the decryption failed as described in Section 5.2.2.2 of > [RFC7518]. > > This seems true for the abstract AEAD interface, but since we're peeling > off the HMAC integrity tag for standalone use, we may need to say > something about what inputs/outputs are needed for just using the > integrity tag without doing decryption. In particular, we cannot use K > as an input for standalone HMAC verification! > > Also, this is just the generic AEAD interface, so RFC 5116 is probably a > more apropos reference than RFC 7518. > > Section 4.3 > > Note: The use of Advanced Encryption Standard (AES) in Galois/ > Counter Mode (GCM) + HMAC may have CPU and packet size > implications (need for a second 128-bit authentication tag). > > [This might also be redundant if my earlier proposal is accepted.] > > Section 4.4 > > The document does not assume nor preclude the following: > > o The same keying material is used for all the service functions > used within an SFC-enabled domain. > > o Distinct keying material is used per SFP by all involved SFC data > path elements. > > o Per-tenant keys are used. > > I suggest a forward reference to the security considerations with a > brief note that the risk involved in using a group-shared symmetric key > increases with the size of the group to which it is shared. > > In order to accommodate deployments relying upon keying material per > SFC/SFP and also the need to update keys after encrypting NSH data > for a certain amount of time, this document uses key identifiers to > unambiguously identify the appropriate keying material. Doing so > allows to address the problem of synchronization of keying material. > > I'd suggest making a statement about the scope in which key identifiers > need to be unique. > > Section 4.5 > > An NSH-aware SF or SFC Proxy that needs to decrypt some Context > Headers uses ENC_Key and the decryption algorithm for the key > identifier being carried in the NSH. > > I think we need to say that decryption MUST NOT proceed unless the > integrity tag has been successfully validated. To decrypt without > checking the integrity tag violates the AEAD interface. Alternately, we > could only ever describe decryption as the AEAD operation that uses K as > input (not just ENC_KEY) -- =C2=A77.6 seems to attempt to take this latte= r > approach, but the document as a whole is not consistent about it. > > Section 5, 5.x > > I strongly suggest changing "Key Length" to "keyid length", since there > is already convention on "key length" (e.g., for AES-128 vs AES-192 vs > AES-256). > > Section 5.1 > > Key Identifier: Carries a variable-length Key Identifier object used > to identify and deliver keys to SFC data plane elements. This > identifier is helpful to accommodate deployments relying upon > keying material per SFC/SFP. The key identifier helps in > resolving the problem of synchronization of keying material. > > I suggest clarifying that a single key identifier is used to lookup both > the associated ENC_KEY and the associated MAC_KEY (or, alternately, that > it is logically bound to K and remind the reader that ENC_KEY and > MAC_KEY are extracted from K and might be separately distributed). > > Key Length: Variable. Carries the length of the key identifier. > [...] > IV Length: Carries the length of the IV (Section 5.2 of [RFC7518]). > If encryption is not used, IV length is set to zero (that is, no > "Initialization Vector" is included). > > Please also specify that the Key/IV lengths are measured in bytes (the > reference for IV length, at least, talks about IVs in bits). > > I strongly suggest using a value other than zero as the sentinel value > for "no encryption" -- there already exist modes like AES-SIV (RFC 5297) > that do not require an IV input, which would be a natural use for > zero-length IV. > > Additionally, one might imagine using a non-zero-length IV as input to > an HMAC calculation as a per-message nonce. On cursory examination, > since we are already using timestamp-based replay detection, the > additional nonce is unlikely to add much value, but I'm not willing to > completely rule it out on the basis of the minimal analysis I performed. > > Section 7.1 > > Only one instance of "MAC and Encrypted Metadata" Context Header > (Section 5) is allowed. If multiple instances of "MAC and Encrypted > Metadata" Context Header are included in an NSH packet, the SFC data > > I think Roman may have mentioned this already, but please clarify if > this is one instance per NSH or per packet (e.g., in hierarchical SFC we > might have more than one NSH in a packet). > > Please also clarify it if is permitted to have both MAC#1 and MAC#2 > present in the same packet. (IIUC there are not obvious situations > where such a setup would be useful, but it's still good to be clear > about expectations.) > > Section 7.2 > > If the Context Headers are not encrypted, the HMAC algorithm > discussed in [RFC4868] is used to integrity protect the target NSH > data. [...] > > It's not really clear to me why RFC 4868 is the right reference here, as > opposed to (e.g.) RFC 2104. In particular, see my Discuss point (2). > > The Message Authentication Code (T) computation process can be > illustrated as follows: > > T =3D HMAC-SHA-256-128(MAC_KEY, A) > > I agree with the other reviewer that wondered about just using "MAC" (or > maybe "HMAC") rather than "HMAC-SHA-256-128" here (I do see the "can be > illustrated as" qualifier). > > It's also a little weird to reuse T and A from the AEAD construction (or > RFC 4868) here without additional discussion on how they apply and how > the value of A is constructed. > > An entity in the SFP that intends to update the NSH MUST follow the > above behavior to maintain message integrity of the NSH for > subsequent validations. > > I'm not sure that "intends to" is needed; the requirement applies to > actions, not intent. > > Section 7.3 > > In an SFC-enabled domain where pervasive monitoring [RFC7258] is > possible, all Context Headers carrying privacy-sensitive metadata > MUST be encrypted; [...] > > I agree with the other reviewer that noted that this seems to > effectively be an unqualified "MUST", since there is always some > possibility of monitoring. > > MAC_KEY =3D initial MAC_KEY_LEN octets of K, > ENC_KEY =3D final ENC_KEY_LEN octets of K, > E =3D CBC-PKCS7-ENC(ENC_KEY, P), > M =3D MAC(MAC_KEY, A || IV || E || AL), > T =3D initial T_LEN octets of M. > MAC and Encrypted Metadata =3D E || T > > I recognize that this is just copy+paste from RFC 7518 (with the > addition of the last line), but it seems a glaring omission that the > CBC-PKCS7-ENC() invocation does not include the IV as an input! > (In =C2=A75.2.2.1 of RFC 7518 we do see that "The plaintext is CBC encryp= ted > using PKCS #7 padding using ENC_KEY as the key and the IV", so it's just > the figure/formula that omits the IV.) > > We also don't define or mention T_LEN in this document other than in > this formula and the analogous one for MAC-without-encryption, which > might be worth remedying. > > Section 7.4 > > I suggest adding another word (like "Prevention") to the section title. > > The received NSH is accepted by an NSH-aware node if the Timestamp > (TS) in the NSH is recent enough to the reception time of the NSH > (TSrt). The following formula is used for this check: > > -Delta < (TSrt - TS) < +Delta > > (There's no real reason why the accepted timestamp skew parameter Delta > needs to be symmetric in the positive and negative directions.) > > Replay attacks within the Delta window may be detected by an NSH- > aware node by recording a unique value derived, for example, from the > NSH data and Original packet (e.g., using SHA2). [...] > > Note that the unique value MUST NOT use as input any bits that are not > covered by the MAC. Indeed, just using the MAC itself as the unique > value would be a fairly straightforward scheme, I think. > > Section 7.5 > > When an SFC data plane element receives an NSH packet, it MUST first > ensure that a "MAC and Encrypted Metadata" Context Header is > included. [...] > > This sort of requirement (as written) would seem to support the position > of some other reviewers that this document would need to formally update > RFC 8300. > > Section 9 > > We might discuss that this mechanism is only for metadata type 2 and not > type 1 (as well as that with the relatively small fixed length of type 1 > metadata, it's quite challenging to provide useful cryptographic > protection), so that type-1 metadata still has no generic protection > mechanism. A given metadata element could define its own protection > scheme, of course. > > The attacks discussed in [I-D.nguyen-sfc-security-architecture] are > handled owing to the solution specified in this document, except for > attacks dropping packets. [...] > > >From a very quick read, draft-nguyen-sfc-security-architecture proposes > a probe-based scheme that monitors all middleboxes (or at least those in > the expected path) to detect a middlebox-bypass attack and verify that > the probe traversed the expected SFP. I am not sure that this document > on its own suffices to prevent the middlebox-bypass attack for all > traffic (i.e., the probe-based scheme might still be needed). If some > network entities know what the expected service index will be for a > given SPI at a given node, then middlebox-bypass attacks could be > natively detected, but my understanding was that such advance knowledge > of expected service index was not going to be available. > > The solution specified in this document does not provide data origin > authentication. > > I would have expected more in-depth discussion of the security > considerations for a group-shared PSK scheme, including how the risk of > key loss/compromise goes up when the key is distributed to more > locations. > > Section 9.1 > > No device other than the NSH-aware SFs in the SFC-enabled domain > should be able to update the integrity protected NSH data. > > What about classifiers and SFC proxies? > > Section 9.2 > > I expected to see some remarks here analogous to the second paragraph of > =C2=A79.1 (even if just by reference to that section). > > Section 9.3 > > Section 5.6 of [RFC8633] describes best current practices to be > considered in deployments where SFC data plane elements use NTP for > time synchronization purposes. > > The referenced section covers NTP symmetric mode only. Is client/server > mode not a BCP for trusted networks and broadcast/symmetric the only > options? > > NITS > > Section 1 > > network infrastructures against them, network slicing, etc. Because > of the proliferation of such advanced SFs together with complex > service deployment constraints that demand more agile service > delivery procedures, operators need to rationalize their service > delivery logics and master their complexity while optimising service > activation time cycles. The overall problem space is described in > [RFC7498]. > > The "their" in "master their complexity" is a bit ambiguous between > "operators" and "service delivery logics" (noting that the previous use > of "their" did refer to "operators"). (The sentence as a whole reads a > bit like marketing language, but that's not intended to be an actionable > comment.) > > This specification fills that gap. Concretely, this document adds > integrity protection and optional encryption of sensitive metadata > directly to the NSH (Section 4); integrity protects the packet > payload and provides replay protection (Section 7.4). [...] > > The clause after the semicolon needs to be able to stand alone as a > complete sentence in order to be grammatical, but it currently has no > subject. Maybe prefixing "it also" would be enough to fix it. > > Section 4.1.2 > > The integrity protection scope is explicitly signaled to NSH-aware > SFs and SFC proxies in the NSH by means of a dedicated MD Type > (Section 5). > > Signaled to SFFs as well, since in the second LoA they can use it. > > Section 4.6 > > As discussed in [RFC8459], an SFC-enabled domain (called, upper-level > domain) may be decomposed into many sub-domains (called, lower-level > domains). In order to avoid maintaining state to restore back upper- > lower NSH information at the boundaries of lower-level domains, two > > I think s/upper-lower/upper-layer/ (across the line break)? > > Section 5.1 > > MAC#1 Context Header is a variable-length Context Header that carries > the Message Authentication Code (MAC) for the Service Path Header, > Context Headers, and the inner packet on which NSH is imposed, > calculated using MAC_KEY and optionally Context Headers encrypted > using ENC_KEY. [...] > > Comma after "calculated using MAC_KEY", please. ("optionally Context > Headers [...]" are not used along with MAC_KEY in the calculation) > > Section 5.2 > > Message Authentication Code: Coves the entire NSH data. The > > s/Coves/Covers/ > > Section 6 > > The epoch is 1970-01-01T00:00Z in UTC time. [...] > > (IIUC, the "in UTC time" is redundant with the trailing 'Z'.) > > Section 7.1 > > element. The details of sending notification alarms (i.e., the > parameters affecting the transmission of the notification alarms > depend on the information in the context header such as frequency, > thresholds, and content in the alarm) SHOULD be configurable. > > The grammar in the parenthetical seems off to me. Possibly > s/depend/depending/ would be a fix, but I'm not sure. > > NSH-aware SFs and SFC proxies MUST re-apply the integrity protection > if any modification is made to the Context Headers (strip a Context > Header, update the content of an existing Context Header, insert a > new Context Header). > > I think maybe an "e.g.," in the parenthetical is in order, since this > doesn't seem to include things like "decrement the TTL". > > Section 9 > > The interaction between the SFC data plane elements and a key > management system MUST NOT be transmitted in clear since this would > completely destroy the security benefits of the integrity protection > solution defined in this document. The secret key (K) must have an > expiration time assigned as the latest point in time before which the > > This first sentence seems like it could probably be a paragraph of its > own; the subsequent discussion of expiration time seems to be mostly > unrelated. > > We might also add another sentence to reiterate that "the security and > integrity of the key-distribution mechanism is vital to the security of > the system as a whole". > > o Attacker replacing the packet on which the NSH is imposed with a > bogus packet. > > I'd probably say "modified or bogus". > > In an SFC-enabled domain where the above attacks are possible, (1) > > This is perhaps ambiguous about whether an "any" or "all" criterion > should be used. Perhaps that's desired :) > > > > --000000000000820a0205c77530a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ben,

Please see inline=C2= =A0

On Thu, 15 Jul 2021 at 02:55, Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote:
Benjamin Kaduk has entered the= following ballot position for
draft-ietf-sfc-nsh-integrity-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft= -ietf-sfc-nsh-integrity/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(0) (I came to this realization rather late in my review process, so
there may be places where the COMMENT and this discuss point are in
disagreement; this DISCUS takes precedence.)
I fear that the construction that separately distributes ENC_KEY and
MAC_KEY in an attempt to achieve privilege separation is fatally flawed. In particular, the CBC encryption mode is a malleable encryption mode,
in that flipping a bit of ciphertext will filp the corresponding bit of
the next block of recovered plaintext (at the cost of completely
garbling the recovered block containing the bit that was modified).
Subsequent blocks are unaffected.=C2=A0 Typically we combine CBC mode with = a
MAC such as HMAC in order to prevent such modifications from being
exposed as attack vectors, and while we do use HMAC here for that
purpose, we also introduce a separate class of actors that have access
to the HMAC key but not the encryption key.=C2=A0 Accordingly, those actors=
can produce a new, valid, integrity tag after making a modification to
the ciphertext, allowing them to engage in attacks that make use of
ciphertext malleability.=C2=A0 Ciphertext malleability is particularly usef= ul
as an attack vector when the structure of the plaintext being encrypted
is known, and there are portions of the plaintext that the application
will either ignore if they are garbled or are expected to be near random in the normal case (and thus for which garbled output does not cause
rejection by the application).=C2=A0 In a SFC environment it seems highly likely that the structure of the plaintext will be known or guessable,
and we don't have any real mechanisms to control what types of metadata=
go into encrypted context headers, so it seems that we must act as if we are exposed to this risk.

While =C2=A74.3 does have a note that use of GCM with HMAC is undesirable d= ue
to the additional authentication tag, it may be unavoidable in order to
provide the properties that we need.

Th= anks for explaining the attack. We will modify the text in Section 4.3 as f= ollows to address the comment:

=C2=A0 =C2=A0Classi= fiers, NSH-aware SFs, and SFC proxies MUST implement the
=C2=A0 =C2=A0AE= S_128_GCM [GCM][RFC5116] algorithm and SHOULD implement the
=C2=A0 =C2= =A0AES_192_GCM and AES_256_GCM algorithms.

=C2=A0 =C2=A0Classifiers,= NSH-aware SFs, and SFC proxies MUST implement the HMAC-
=C2=A0 =C2=A0SH= A-256-128 algorithm and SHOULD implement the HMAC-SHA-384-192 and
=C2=A0= =C2=A0HMAC-SHA-512-256 algorithms.

=C2=A0 =C2=A0SFFs MAY implement = the aforementioned cipher suites and HMAC
=C2=A0 =C2=A0algorithms.
Note:
The use of AES_128_CBC_HMAC_SHA_256 algorithm would have avoided= the need for a second 128-bit authentication tag=C2=A0but due to the natur= e of how CBC mode operates, the mode allows for malleability of plaintexts.= This malleability allows for attackers to make changes in the ciphertext a= nd, if parts of the plaintext=C2=A0are known, create arbitrary blocks of pl= aintext.=C2=A0This specification mandates the use of AES-GCM to prevent thi= s type of attack.
=C2=A0

(1) Section 5.1 describes the MAC as:

=C2=A0 =C2=A0Message Authentication Code:=C2=A0 =C2=A0Covers the entire NSH= data, excluding
=C2=A0 =C2=A0 =C2=A0 the Base header.=C2=A0 The Additional Authenticated Da= ta (defined in
=C2=A0 =C2=A0 =C2=A0 [RFC7518]) MUST be the Service Path header, the unencr= ypted
=C2=A0 =C2=A0 =C2=A0 Context headers, and the inner packet on which the NSH= is imposed.

This description seems to exclude from the MAC most of the MAC context
header itself (if we go by the corresponding figure), which is very bad
for security.=C2=A0 We definitely need to include under the MAC the MAC
context header bits from metadata class through and including at least
timestamp, and I think IV length as well.=C2=A0 (The IV itself would be
incorporated via the ciphertext, since the IV is an input to encryption, but since the IV length field indicates whether or not encryption was
performed, we'd need to protect that information.)

No, the MAC context header is also used for generating the = digest.=C2=A0
=C2=A0

Similarly, Section 5.2 has the description:

=C2=A0 =C2=A0Message Authentication Code:=C2=A0 Coves the entire NSH data.= =C2=A0 The
=C2=A0 =C2=A0 =C2=A0 Additional Authenticated Data (defined in [RFC7518]) M= UST be the
=C2=A0 =C2=A0 =C2=A0 entire NSH data (i.e., including the Base Header) excl= uding the
=C2=A0 =C2=A0 =C2=A0 Context Headers to be encrypted.

which on the face of it includes the field that holds the MAC itself
(and is not yet populated), i.e., is self-referential.

The below update will address this comment:

<= /div>
The NSH imposer sets the MAC field to zero and then computes the = message
integrity for the target NSH data (depending on the integrity pr= otection
scope discussed in Section 5) using MAC_KEY and HMAC algorithm.= It inserts
the computed digest in the MAC field in the "MAC and En= crypted Metadata"
Context Header.

=C2= =A0

I think we need to be much more precise about the construction of the
AAD in both cases.=C2=A0 It's possible that the HMAC construction for t= he
no-encrypted-context-headers case can inherit a definition from the AAD
description, but if not we'll need to have some more precision there as=
well.

(2) In order for the MAC-only construction in =C2=A77.2 to be compatible wi= th
the AEAD integrity tag construction, we would need to include the 64-bit AL after A.=C2=A0 While HMAC is intrinsically immune to length-extension attacks, I think that having the explicit AL is useful to avoid any risk of malleability, since the same MAC_KEY is used for constructing both
types of MACs.

I don't think this c= omment is applicable after=C2=A0AES_128_CBC_HMAC_SHA_256=C2=A0is removed.=C2=A0
<= div>=C2=A0

(3) Section 5.1 describes the Timestamp field as an "unsigned 64-bit integer value", which is inconsistent with the actual format given in<= br> Section 6.

Thanks, we will fix it in th= e next revision.=C2=A0
=C2=A0

(4) Section 7.5 directs the verifier to check if "the value of the new= ly
generated digest is identical to the one enclosed in the NSH".=C2=A0 I= t is
critical for the security of the system that this comparison be done in
a constant-time manner that does not provide a side channel into whether the generated digest and the value in the NSH share a common substring.
=

Agreed, will update text as follows:
=

After storing the value of the MAC field in=C2=A0the &q= uot;MAC and Encrypted Metadata" Context Header, the=C2=A0SFC data plane element=C2= =A0fills the MAC field=C2=A0with zeros.=C2=A0 Then, the=C2=A0SFC data plane element=C2=A0g= enerates the message integrity
for the target NSH data (depending on the= integrity protection=C2=A0scope discussed in Section 5) using MAC_KEY and = HMAC algorithm.=C2=A0=C2=A0If the value of the newly generated digest is id= entical to the=C2=A0stored one, the SFC data plane element is certain that = the NSH data=C2=A0has not been tampered and validation is therefore success= ful.=C2=A0Otherwise, the NSH packet MUST be discarded. The comparison of th= e computed HMAC value to the store value MUST
be done in a constant-time= manner to thwart timing attacks.
=C2=A0

(5) Do the MAC context headers always have to be the last metadata
entries in the packet (to simplify the cryptographic calculations)?

Yes.

Cheers,
-Tiru
=C2=A0
Certainly the diagrams only show "unencrypted context headers" ap= pearing
prior to the MAC context header, so if we expect unencrypted context
headers to appear after the MAC context header as well, we should be
clear about that both in the figures and in the specification for how to prepare the AAD.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 3

=C2=A0 =C2=A0o=C2=A0 Both encrypted and unencrypted Context Headers MAY be = included in
=C2=A0 =C2=A0 =C2=A0 the same NSH.=C2=A0 That is, some Context Headers may = be protected
=C2=A0 =C2=A0 =C2=A0 while others do not need to be protected.

In the security area we're pretty strongly moved towards a stance of "encrypt everything that doesn't have a strong need to be plaintex= t
(since we don't want to assume that we can predict all threats and
attacks in advance), and QUIC has even taken that to new levels.=C2=A0 It&#= 39;s
quite surprising to see "don't need to be protected" as a jus= tification
for lack of encryption, rather than "need to be unprotected".=C2= =A0 Given
that we're going to be solving key distribution for integrity protectio= n
anyway, it remains unclear to me why we wouldn't just encrypt
everything.

Section 4.1.1

Is the column heading for the middle column of Table 1 referring to the
Base Header and "Service Path Header"?=C2=A0 I'm not sure how= to interpret
just "Service Header" other than the entire NSH, which doesn'= t seem
right...

=C2=A0 =C2=A0The Service Path Header (Section 2 of [RFC8300]) is not encryp= ted
=C2=A0 =C2=A0because SFFs use Service Index (SI) in conjunction with Servic= e Path
=C2=A0 =C2=A0Identifier (SPI) for determining the next SF in the path.

It's good to see this spelled out like this; I'd love to have this = kind
of explanation for every un-encrypted protocol element.

Section 4.1.2

=C2=A0 =C2=A0The solution provides integrity protection for the NSH data.= =C2=A0 Two
=C2=A0 =C2=A0levels of assurance (LoAs) are supported.

I see (reading onward) that the two LoAs just differ in what is covered
by the integrity tag, but each involve only a single MAC.=C2=A0 There's= a
reasonable argument that when there are overlapping needs for what data
needs protecting and who needs access to it, that multiple MACs (or
encryption, if needed) are most appropriate, which can be tailored to
the respective needs.=C2=A0 This is something that Phillip Hallam-Baker has=
ascribed as the "short-blanket theory" of cryptography, in that i= t's
like a blanket that's too short to cover everything you want, so you need to have more than one and put them in partially overlapping layers. Perhaps this "short-blanket theory" is more applicable to Discuss= point
(0) than what is covered by the MAC, though...

=C2=A0 =C2=A0The first level of assurance where all NSH data except the Bas= e
=C2=A0 =C2=A0Header are integrity protected (Figure 2).=C2=A0 In this case,= the NSH
=C2=A0 =C2=A0imposer may be a Classifier, an NSH-aware SF, or an SFC Proxy.= =C2=A0 SFFs
=C2=A0 =C2=A0are not thus provided with authentication material.=C2=A0 [...= ]

There seems to be a gap in the chain of reasoning as to why SFFs are not provided with authentication material.=C2=A0 It seems that the intent is something along the lines of considering which entities need access to
the key material in order to successfully add an NSH or update context
headers, but that alone is not itself cause to say that other entities
can never be provided with the keys (subject to the security
considerations of group-shared PSKs, of course).=C2=A0 Furthermore, if a particular SFF is trusted, it may have grounds to verify the integrity
tag even if it is administratively prohibited from writing such a tag.

=C2=A0 =C2=A0In both levels of assurance, the unencrypted Context Headers a= nd the
=C2=A0 =C2=A0packet on which the NSH is imposed are subject to integrity =C2=A0 =C2=A0protection.

Surely any encrypted Context Headers are also given integrity
protection, as excluding them from the MAC computation would be quite
complex.=C2=A0 I see that the encrypted context headers are not part of the=
AAD input, but in the AEAD model the ciphertext is still given integrity protection!

Section 4.2

=C2=A0 =C2=A0The authenticated encryption algorithm defined in [RFC7518] is= used
=C2=A0 =C2=A0to provide NSH data integrity and to encrypt the Context Heade= rs that
=C2=A0 =C2=A0carry privacy-sensitive metadata.

RFC 7518 (JSON Web Algorithms) is a very surprising reference for
generic AEAD encryption.=C2=A0 Continuing on, it becomes clear that we in fact do not want a generic AEAD operation here, but instead have need
for separation of encryption and integrity protection due to the various separations of roles that are possible.=C2=A0 Because this is a divergence<= br> from current best practices (use of native AEAD cipher modes like GCM,
SIV, etc.), I might suggest a rather different introductory material:

% The AEAD interface specified in RFC 5116 is a very powerful tool for
% providing strong confidentiality and integrity protection for protocol % messages, and has become quite widely adopted as a result.=C2=A0 For
% protecting NSH data we adhere to the spirit of the AEAD interface but
% use a slightly modified version in order to remain consistent with the % privilege separation needed (e.g., in the second level of assurance,
% SFFs need to be able to update the message integrity tag but do not
% need access to the decrypted plaintext).=C2=A0 Accordingly, a compound AE= AD
% mechanism combining CBC encryption and HMAC integrity tag is used, so
% that distribution of the encryption key can be limited.=C2=A0 Rather than=
% define a new scheme from scratch, the AES_CBC_HMAC_SHA2 scheme from
% [RFC7518] is used.=C2=A0 In order to simplify key distribution, a single<= br> % secret key material seed K is used, which can be kept private
% centrally or distributed to all parties that will have access to
% decrypted plaintext, and the secondary keys MAC_KEY and ENC_KEY are
% derived from K as discussed in Section 5.2.2.1 of [RFC7518].=C2=A0 Entiti= es
% that need to update the integrity tag but are not authorized to see
% the decrypted plaintext will only receive MAC_KEY and not K or
% ENC_KEY.

=C2=A0 =C2=A0o=C2=A0 If the Context Headers are not encrypted, the Hashed M= essage
=C2=A0 =C2=A0 =C2=A0 Authentication Mode (HMAC) algorithm discussed in [RFC= 4868] is
=C2=A0 =C2=A0 =C2=A0 used to protect the integrity of the NSH data.

It's not clear to me that this is adding much value; HMAC is used
whether or not there are encrypted headers, and the RFC 4868 reference
is rather odd (see also my Discuss point (2)).

=C2=A0 =C2=A0The advantage of using the authenticated encryption algorithm = is that
=C2=A0 =C2=A0NSH-aware SFs and SFC proxies only need to re-compute the mess= age
=C2=A0 =C2=A0integrity of the NSH data after decrementing the Service Index= (SI)
=C2=A0 =C2=A0and do not have to re-compute the ciphertext.=C2=A0 The other = advantage is
=C2=A0 =C2=A0that SFFs do not have access to the ENC_KEY and cannot act on = the
=C2=A0 =C2=A0encrypted Context Headers and, only in case of the second leve= l of
=C2=A0 =C2=A0assurance, SFFs do have access to the MAC_KEY.=C2=A0 Similarly= , an NSH-
=C2=A0 =C2=A0aware SF or SFC Proxy not allowed to decrypt the Context Heade= rs will
=C2=A0 =C2=A0not have access to the ENC_KEY.

[If my above suggestion is used, this text has probably become mostly
redundant and could be trimmed down or removed.]

=C2=A0 =C2=A0The authenticated encryption process takes as input four-octet=
=C2=A0 =C2=A0strings: a secret key (K), a plaintext (P), Additional Authent= icated
=C2=A0 =C2=A0Data (A) (which contains the data to be authenticated, but not=
=C2=A0 =C2=A0encrypted), and an Initialization Vector (IV).=C2=A0 The ciphe= rtext value
=C2=A0 =C2=A0(E) and the Authentication Tag value (T) are provided as outpu= ts.

=C2=A0 =C2=A0In order to decrypt and verify, the cipher takes as input K, I= V, A,
=C2=A0 =C2=A0T, and E.=C2=A0 The output is either the plaintext or an error= indicating
=C2=A0 =C2=A0that the decryption failed as described in Section 5.2.2.2 of<= br> =C2=A0 =C2=A0[RFC7518].

This seems true for the abstract AEAD interface, but since we're peelin= g
off the HMAC integrity tag for standalone use, we may need to say
something about what inputs/outputs are needed for just using the
integrity tag without doing decryption.=C2=A0 In particular, we cannot use = K
as an input for standalone HMAC verification!

Also, this is just the generic AEAD interface, so RFC 5116 is probably a more apropos reference than RFC 7518.

Section 4.3

=C2=A0 =C2=A0 =C2=A0 Note: The use of Advanced Encryption Standard (AES) in= Galois/
=C2=A0 =C2=A0 =C2=A0 Counter Mode (GCM) + HMAC may have CPU and packet size=
=C2=A0 =C2=A0 =C2=A0 implications (need for a second 128-bit authentication= tag).

[This might also be redundant if my earlier proposal is accepted.]

Section 4.4

=C2=A0 =C2=A0The document does not assume nor preclude the following:

=C2=A0 =C2=A0o=C2=A0 The same keying material is used for all the service f= unctions
=C2=A0 =C2=A0 =C2=A0 used within an SFC-enabled domain.

=C2=A0 =C2=A0o=C2=A0 Distinct keying material is used per SFP by all involv= ed SFC data
=C2=A0 =C2=A0 =C2=A0 path elements.

=C2=A0 =C2=A0o=C2=A0 Per-tenant keys are used.

I suggest a forward reference to the security considerations with a
brief note that the risk involved in using a group-shared symmetric key
increases with the size of the group to which it is shared.

=C2=A0 =C2=A0In order to accommodate deployments relying upon keying materi= al per
=C2=A0 =C2=A0SFC/SFP and also the need to update keys after encrypting NSH = data
=C2=A0 =C2=A0for a certain amount of time, this document uses key identifie= rs to
=C2=A0 =C2=A0unambiguously identify the appropriate keying material.=C2=A0 = Doing so
=C2=A0 =C2=A0allows to address the problem of synchronization of keying mat= erial.

I'd suggest making a statement about the scope in which key identifiers=
need to be unique.

Section 4.5

=C2=A0 =C2=A0An NSH-aware SF or SFC Proxy that needs to decrypt some Contex= t
=C2=A0 =C2=A0Headers uses ENC_Key and the decryption algorithm for the key<= br> =C2=A0 =C2=A0identifier being carried in the NSH.

I think we need to say that decryption MUST NOT proceed unless the
integrity tag has been successfully validated.=C2=A0 To decrypt without
checking the integrity tag violates the AEAD interface.=C2=A0 Alternately, = we
could only ever describe decryption as the AEAD operation that uses K as input (not just ENC_KEY) -- =C2=A77.6 seems to attempt to take this latter<= br> approach, but the document as a whole is not consistent about it.

Section 5, 5.x

I strongly suggest changing "Key Length" to "keyid length&qu= ot;, since there
is already convention on "key length" (e.g., for AES-128 vs AES-1= 92 vs
AES-256).

Section 5.1

=C2=A0 =C2=A0Key Identifier:=C2=A0 Carries a variable-length Key Identifier= object used
=C2=A0 =C2=A0 =C2=A0 to identify and deliver keys to SFC data plane element= s.=C2=A0 This
=C2=A0 =C2=A0 =C2=A0 identifier is helpful to accommodate deployments relyi= ng upon
=C2=A0 =C2=A0 =C2=A0 keying material per SFC/SFP.=C2=A0 The key identifier = helps in
=C2=A0 =C2=A0 =C2=A0 resolving the problem of synchronization of keying mat= erial.

I suggest clarifying that a single key identifier is used to lookup both the associated ENC_KEY and the associated MAC_KEY (or, alternately, that it is logically bound to K and remind the reader that ENC_KEY and
MAC_KEY are extracted from K and might be separately distributed).

=C2=A0 =C2=A0Key Length:=C2=A0 Variable.=C2=A0 Carries the length of the ke= y identifier.
=C2=A0 =C2=A0[...]
=C2=A0 =C2=A0IV Length:=C2=A0 Carries the length of the IV (Section 5.2 of = [RFC7518]).
=C2=A0 =C2=A0 =C2=A0 If encryption is not used, IV length is set to zero (t= hat is, no
=C2=A0 =C2=A0 =C2=A0 "Initialization Vector" is included).

Please also specify that the Key/IV lengths are measured in bytes (the
reference for IV length, at least, talks about IVs in bits).

I strongly suggest using a value other than zero as the sentinel value
for "no encryption" -- there already exist modes like AES-SIV (RF= C 5297)
that do not require an IV input, which would be a natural use for
zero-length IV.

Additionally, one might imagine using a non-zero-length IV as input to
an HMAC calculation as a per-message nonce.=C2=A0 On cursory examination, since we are already using timestamp-based replay detection, the
additional nonce is unlikely to add much value, but I'm not willing to<= br> completely rule it out on the basis of the minimal analysis I performed.
Section 7.1

=C2=A0 =C2=A0Only one instance of "MAC and Encrypted Metadata" Co= ntext Header
=C2=A0 =C2=A0(Section 5) is allowed.=C2=A0 If multiple instances of "M= AC and Encrypted
=C2=A0 =C2=A0Metadata" Context Header are included in an NSH packet, t= he SFC data

I think Roman may have mentioned this already, but please clarify if
this is one instance per NSH or per packet (e.g., in hierarchical SFC we might have more than one NSH in a packet).

Please also clarify it if is permitted to have both MAC#1 and MAC#2
present in the same packet.=C2=A0 (IIUC there are not obvious situations where such a setup would be useful, but it's still good to be clear
about expectations.)

Section 7.2

=C2=A0 =C2=A0If the Context Headers are not encrypted, the HMAC algorithm =C2=A0 =C2=A0discussed in [RFC4868] is used to integrity protect the target= NSH
=C2=A0 =C2=A0data.=C2=A0 [...]

It's not really clear to me why RFC 4868 is the right reference here, a= s
opposed to (e.g.) RFC 2104.=C2=A0 In particular, see my Discuss point (2).<= br>
=C2=A0 =C2=A0The Message Authentication Code (T) computation process can be=
=C2=A0 =C2=A0illustrated as follows:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0T =3D HMAC-SHA-256-128(MAC_KEY, A)

I agree with the other reviewer that wondered about just using "MAC&qu= ot; (or
maybe "HMAC") rather than "HMAC-SHA-256-128" here (I do= see the "can be
illustrated as" qualifier).

It's also a little weird to reuse T and A from the AEAD construction (o= r
RFC 4868) here without additional discussion on how they apply and how
the value of A is constructed.

=C2=A0 =C2=A0An entity in the SFP that intends to update the NSH MUST follo= w the
=C2=A0 =C2=A0above behavior to maintain message integrity of the NSH for =C2=A0 =C2=A0subsequent validations.

I'm not sure that "intends to" is needed; the requirement app= lies to
actions, not intent.

Section 7.3

=C2=A0 =C2=A0In an SFC-enabled domain where pervasive monitoring [RFC7258] = is
=C2=A0 =C2=A0possible, all Context Headers carrying privacy-sensitive metad= ata
=C2=A0 =C2=A0MUST be encrypted; [...]

I agree with the other reviewer that noted that this seems to
effectively be an unqualified "MUST", since there is always some<= br> possibility of monitoring.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAC_KEY =3D initial MAC_KEY_LEN octets of= K,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ENC_KEY =3D final ENC_KEY_LEN octets of K= ,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0E =3D CBC-PKCS7-ENC(ENC_KEY, P),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0M =3D MAC(MAC_KEY, A || IV || E || AL), =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0T =3D initial T_LEN octets of M.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAC and Encrypted Metadata =3D E || T

I recognize that this is just copy+paste from RFC 7518 (with the
addition of the last line), but it seems a glaring omission that the
CBC-PKCS7-ENC() invocation does not include the IV as an input!
(In =C2=A75.2.2.1 of RFC 7518 we do see that "The plaintext is CBC enc= rypted
using PKCS #7 padding using ENC_KEY as the key and the IV", so it'= s just
the figure/formula that omits the IV.)

We also don't define or mention T_LEN in this document other than in this formula and the analogous one for MAC-without-encryption, which
might be worth remedying.

Section 7.4

I suggest adding another word (like "Prevention") to the section = title.

=C2=A0 =C2=A0The received NSH is accepted by an NSH-aware node if the Times= tamp
=C2=A0 =C2=A0(TS) in the NSH is recent enough to the reception time of the = NSH
=C2=A0 =C2=A0(TSrt).=C2=A0 The following formula is used for this check:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-Delta < (TSrt - TS) <= ; +Delta

(There's no real reason why the accepted timestamp skew parameter Delta=
needs to be symmetric in the positive and negative directions.)

=C2=A0 =C2=A0Replay attacks within the Delta window may be detected by an N= SH-
=C2=A0 =C2=A0aware node by recording a unique value derived, for example, f= rom the
=C2=A0 =C2=A0NSH data and Original packet (e.g., using SHA2).=C2=A0 [...]
Note that the unique value MUST NOT use as input any bits that are not
covered by the MAC.=C2=A0 Indeed, just using the MAC itself as the unique value would be a fairly straightforward scheme, I think.

Section 7.5

=C2=A0 =C2=A0When an SFC data plane element receives an NSH packet, it MUST= first
=C2=A0 =C2=A0ensure that a "MAC and Encrypted Metadata" Context H= eader is
=C2=A0 =C2=A0included.=C2=A0 [...]

This sort of requirement (as written) would seem to support the position of some other reviewers that this document would need to formally update RFC 8300.

Section 9

We might discuss that this mechanism is only for metadata type 2 and not type 1 (as well as that with the relatively small fixed length of type 1 metadata, it's quite challenging to provide useful cryptographic
protection), so that type-1 metadata still has no generic protection
mechanism.=C2=A0 A given metadata element could define its own protection scheme, of course.

=C2=A0 =C2=A0The attacks discussed in [I-D.nguyen-sfc-security-architecture= ] are
=C2=A0 =C2=A0handled owing to the solution specified in this document, exce= pt for
=C2=A0 =C2=A0attacks dropping packets.=C2=A0 [...]

>From a very quick read, draft-nguyen-sfc-security-architecture proposes=
a probe-based scheme that monitors all middleboxes (or at least those in the expected path) to detect a middlebox-bypass attack and verify that
the probe traversed the expected SFP.=C2=A0 I am not sure that this documen= t
on its own suffices to prevent the middlebox-bypass attack for all
traffic (i.e., the probe-based scheme might still be needed).=C2=A0 If some=
network entities know what the expected service index will be for a
given SPI at a given node, then middlebox-bypass attacks could be
natively detected, but my understanding was that such advance knowledge
of expected service index was not going to be available.

=C2=A0 =C2=A0The solution specified in this document does not provide data = origin
=C2=A0 =C2=A0authentication.

I would have expected more in-depth discussion of the security
considerations for a group-shared PSK scheme, including how the risk of
key loss/compromise goes up when the key is distributed to more
locations.

Section 9.1

=C2=A0 =C2=A0No device other than the NSH-aware SFs in the SFC-enabled doma= in
=C2=A0 =C2=A0should be able to update the integrity protected NSH data.

What about classifiers and SFC proxies?

Section 9.2

I expected to see some remarks here analogous to the second paragraph of =C2=A79.1 (even if just by reference to that section).

Section 9.3

=C2=A0 =C2=A0Section 5.6 of [RFC8633] describes best current practices to b= e
=C2=A0 =C2=A0considered in deployments where SFC data plane elements use NT= P for
=C2=A0 =C2=A0time synchronization purposes.

The referenced section covers NTP symmetric mode only.=C2=A0 Is client/serv= er
mode not a BCP for trusted networks and broadcast/symmetric the only
options?

NITS

Section 1

=C2=A0 =C2=A0network infrastructures against them, network slicing, etc.=C2= =A0 Because
=C2=A0 =C2=A0of the proliferation of such advanced SFs together with comple= x
=C2=A0 =C2=A0service deployment constraints that demand more agile service<= br> =C2=A0 =C2=A0delivery procedures, operators need to rationalize their servi= ce
=C2=A0 =C2=A0delivery logics and master their complexity while optimising s= ervice
=C2=A0 =C2=A0activation time cycles.=C2=A0 The overall problem space is des= cribed in
=C2=A0 =C2=A0[RFC7498].

The "their" in "master their complexity" is a bit ambig= uous between
"operators" and "service delivery logics" (noting that = the previous use
of "their" did refer to "operators").=C2=A0 (The senten= ce as a whole reads a
bit like marketing language, but that's not intended to be an actionabl= e
comment.)

=C2=A0 =C2=A0This specification fills that gap.=C2=A0 Concretely, this docu= ment adds
=C2=A0 =C2=A0integrity protection and optional encryption of sensitive meta= data
=C2=A0 =C2=A0directly to the NSH (Section 4); integrity protects the packet=
=C2=A0 =C2=A0payload and provides replay protection (Section 7.4).=C2=A0 [.= ..]

The clause after the semicolon needs to be able to stand alone as a
complete sentence in order to be grammatical, but it currently has no
subject.=C2=A0 Maybe prefixing "it also" would be enough to fix i= t.

Section 4.1.2

=C2=A0 =C2=A0The integrity protection scope is explicitly signaled to NSH-a= ware
=C2=A0 =C2=A0SFs and SFC proxies in the NSH by means of a dedicated MD Type=
=C2=A0 =C2=A0(Section 5).

Signaled to SFFs as well, since in the second LoA they can use it.

Section 4.6

=C2=A0 =C2=A0As discussed in [RFC8459], an SFC-enabled domain (called, uppe= r-level
=C2=A0 =C2=A0domain) may be decomposed into many sub-domains (called, lower= -level
=C2=A0 =C2=A0domains).=C2=A0 In order to avoid maintaining state to restore= back upper-
=C2=A0 =C2=A0lower NSH information at the boundaries of lower-level domains= , two

I think s/upper-lower/upper-layer/ (across the line break)?

Section 5.1

=C2=A0 =C2=A0MAC#1 Context Header is a variable-length Context Header that = carries
=C2=A0 =C2=A0the Message Authentication Code (MAC) for the Service Path Hea= der,
=C2=A0 =C2=A0Context Headers, and the inner packet on which NSH is imposed,=
=C2=A0 =C2=A0calculated using MAC_KEY and optionally Context Headers encryp= ted
=C2=A0 =C2=A0using ENC_KEY.=C2=A0 [...]

Comma after "calculated using MAC_KEY", please.=C2=A0 ("opti= onally Context
Headers [...]" are not used along with MAC_KEY in the calculation)

Section 5.2

=C2=A0 =C2=A0Message Authentication Code:=C2=A0 Coves the entire NSH data.= =C2=A0 The

s/Coves/Covers/

Section 6

=C2=A0 =C2=A0 =C2=A0 The epoch is 1970-01-01T00:00Z in UTC time.=C2=A0 [...= ]

(IIUC, the "in UTC time" is redundant with the trailing 'Z= 9;.)

Section 7.1

=C2=A0 =C2=A0element.=C2=A0 The details of sending notification alarms (i.e= ., the
=C2=A0 =C2=A0parameters affecting the transmission of the notification alar= ms
=C2=A0 =C2=A0depend on the information in the context header such as freque= ncy,
=C2=A0 =C2=A0thresholds, and content in the alarm) SHOULD be configurable.<= br>
The grammar in the parenthetical seems off to me.=C2=A0 Possibly
s/depend/depending/ would be a fix, but I'm not sure.

=C2=A0 =C2=A0NSH-aware SFs and SFC proxies MUST re-apply the integrity prot= ection
=C2=A0 =C2=A0if any modification is made to the Context Headers (strip a Co= ntext
=C2=A0 =C2=A0Header, update the content of an existing Context Header, inse= rt a
=C2=A0 =C2=A0new Context Header).

I think maybe an "e.g.," in the parenthetical is in order, since = this
doesn't seem to include things like "decrement the TTL".

Section 9

=C2=A0 =C2=A0The interaction between the SFC data plane elements and a key<= br> =C2=A0 =C2=A0management system MUST NOT be transmitted in clear since this = would
=C2=A0 =C2=A0completely destroy the security benefits of the integrity prot= ection
=C2=A0 =C2=A0solution defined in this document.=C2=A0 The secret key (K) mu= st have an
=C2=A0 =C2=A0expiration time assigned as the latest point in time before wh= ich the

This first sentence seems like it could probably be a paragraph of its
own; the subsequent discussion of expiration time seems to be mostly
unrelated.

We might also add another sentence to reiterate that "the security and=
integrity of the key-distribution mechanism is vital to the security of
the system as a whole".

=C2=A0 =C2=A0o=C2=A0 Attacker replacing the packet on which the NSH is impo= sed with a
=C2=A0 =C2=A0 =C2=A0 bogus packet.

I'd probably say "modified or bogus".

=C2=A0 =C2=A0In an SFC-enabled domain where the above attacks are possible,= (1)

This is perhaps ambiguous about whether an "any" or "all&quo= t; criterion
should be used.=C2=A0 Perhaps that's desired :)



--000000000000820a0205c77530a4-- From nobody Mon Jul 19 01:03:26 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E89F3A284D; Mon, 19 Jul 2021 01:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Av_Cc0g1O-ME; Mon, 19 Jul 2021 01:03:15 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 075C93A284B; Mon, 19 Jul 2021 01:03:09 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id f30so22172920lfv.10; Mon, 19 Jul 2021 01:03:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2r79NFYQtzxWgHEIVKYI6cpuCwKjBaUls3MndhSPljw=; b=pF9qRp+nTYpV9MRs4Efkksrfbqt+ICkjt/BKsmttKHXnkuVzKeDQ4fJriVFIUhvFm9 DR8WfTDvxUVrDaYmiI1iQmEpG7UOiUEMBPWoKcBXZd1Ly+58YmSQPrgFtxzgafl30+dE 52gyepxeNYvc0XXYmxC6c/BkTeUPG2fqhHOSB3AsF+uNV4emNuEVNb/LIyAB6UWRLUao l1maIGx5AqVLbMz4ylCWAhJ/nDFNDbesmFdY4udjQPcNpu9OwMPQ5vO2Icx8gsbCfGGZ aRZC9jqn/WkAZCbvO1EkwB1/VvITiXKnkxVpNGjZBLhl4KpNTsRl0xk8hE+qz7ki10yK 9ksA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2r79NFYQtzxWgHEIVKYI6cpuCwKjBaUls3MndhSPljw=; b=s311leiY41yslud6ON6VA3U5qefQobg/xOZKej/ONdVJ4lEQM9nSQhF6MWfoAvWQkC Z3AEKYZNLnWkHsbZoaUZepvr23z6qRkBBT4nwAh0YU9Dlv9fGzD1ytKKRBdEgMG5wFmk OPueEYyY9GHf1FsBOLHTdZc1e4WLoNKNEeULm+FC1GmbsdzrzENNVdcuYmXJ8C0UmN8Z Z7kgwC051rCKTgEbQD9qG9ueFG2IDM+ieCLFqiZgn25dr3l0633lS2G28ncxLsAlemcN 2jBJ/m0ZszEPgolGKCeB6+yZLRzYCDrNIS6BnZjX/VAt2cf1/chFvqUpD3E/a6Cw9HAp 0vRQ== X-Gm-Message-State: AOAM531zrSFyA6d91eI6tOBHib2FvM82KpuRR8qc2Hk4W3yYo5goC0Ju 2I2rkjlp6kk4MzgDdvvJgs7en84Y1qxml9GwGp8= X-Google-Smtp-Source: ABdhPJzS19kVd6MaQMdHQZFkqP3iZWRa4BS+GxW6PMKUos/+RquztHtwAZk7Ts1q1cph3nslpYzILbhDpLkbemgar3k= X-Received: by 2002:a19:f00c:: with SMTP id p12mr17689410lfc.647.1626681786733; Mon, 19 Jul 2021 01:03:06 -0700 (PDT) MIME-Version: 1.0 References: <162620296297.3569.2501497601980031548@ietfa.amsl.com> <20210715193611.GV74365@kduck.mit.edu> In-Reply-To: <20210715193611.GV74365@kduck.mit.edu> From: tirumal reddy Date: Mon, 19 Jul 2021 13:32:56 +0530 Message-ID: To: Benjamin Kaduk Cc: Roman Danyliw , gregimirsky@gmail.com, draft-ietf-sfc-nsh-integrity@ietf.org, sfc-chairs@ietf.org, The IESG , sfc@ietf.org Content-Type: multipart/alternative; boundary="0000000000000f97bc05c7755e87" Archived-At: Subject: Re: [sfc] Roman Danyliw's Discuss on draft-ietf-sfc-nsh-integrity-06: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2021 08:03:20 -0000 --0000000000000f97bc05c7755e87 Content-Type: text/plain; charset="UTF-8" On Fri, 16 Jul 2021 at 01:06, Benjamin Kaduk wrote: > On Wed, Jul 14, 2021 at 02:57:42PM +0530, tirumal reddy wrote: > > Hi Roman, > > > > Please see inline > > > > On Wed, 14 Jul 2021 at 00:33, Roman Danyliw via Datatracker < > > noreply@ietf.org> wrote: > > > [...] > > > > > > -- The text would benefit from a description on how to serialize the > > > packet for > > > hashing. For example, Figure 6 and 7 are helpful logical descriptions > of > > > the > > > integrity scope. However, the MAC field itself is depicted as part of > the > > > what > > > should get hashed. Should that field be zeroed out? Removed ? > > > > > > > Yes, we will update text as follows: > > > > The NSH imposer sets the MAC field to zero and then computes the message > > integrity for the target NSH data (depending on the integrity protection > > scope discussed in Section 5) using MAC_KEY and HMAC algorithm. It > inserts > > the computed digest in the MAC field in the "MAC and Encrypted Metadata" > > Context Header. > > It's probably also worth updating the description of the verification > procedures to match; we typically see these done in tandem. > Yes, we will update Section 7.5 as follows: After storing the value of the MAC field in the "MAC and Encrypted Metadata" Context Header, the SFC data plane element fills the MAC field with zeros. Then, the SFC data plane element generates the message integrity for the target NSH data (depending on the integrity protection scope discussed in Section 5) using MAC_KEY and HMAC algorithm. If the value of the newly generated digest is identical to the stored one, the SFC data plane element is certain that the NSH data has not been tampered and validation is therefore successful. Otherwise, the NSH packet MUST be discarded. The comparison of the computed HMAC value to the store value MUST be done in a constant-time manner to thwart timing attacks. -Tiru > > > -Ben > --0000000000000f97bc05c7755e87 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, 16 Jul 2021 at 01:06, Benjami= n Kaduk <kaduk@mit.edu> wrote:
On Wed, Jul 14, 2= 021 at 02:57:42PM +0530, tirumal reddy wrote:
> Hi Roman,
>
> Please see inline
>
> On Wed, 14 Jul 2021 at 00:33, Roman Danyliw via Datatracker <
> noreply@ietf.org= > wrote:
>
[...]
> >
> > -- The text would benefit from a description on how to serialize = the
> > packet for
> > hashing.=C2=A0 For example, Figure 6 and 7 are helpful logical de= scriptions of
> > the
> > integrity scope.=C2=A0 However, the MAC field itself is depicted = as part of the
> > what
> > should get hashed.=C2=A0 Should that field be zeroed out? Removed= ?
> >
>
> Yes, we will update text as follows:
>
> The NSH imposer sets the MAC field to zero and then computes the messa= ge
> integrity for the target NSH data (depending on the integrity protecti= on
> scope discussed in Section 5) using MAC_KEY and HMAC algorithm. It ins= erts
> the computed digest in the MAC field in the "MAC and Encrypted Me= tadata"
> Context Header.

It's probably also worth updating the description of the verification procedures to match; we typically see these done in tandem.

Yes, we will update Section 7.5 as follows:

A= fter storing the value of the MAC field in the "MAC and Encrypted Meta= data" Context Header, the SFC data plane element fills the MAC field w= ith zeros.=C2=A0 Then, the SFC data plane element generates the message int= egrity
for the target NSH data (depending on the integrity protection sc= ope discussed in Section 5) using MAC_KEY and HMAC algorithm.=C2=A0 If the = value of the newly generated digest is identical to the stored one, the SFC= data plane element is certain that the NSH data has not been tampered and = validation is therefore successful. Otherwise, the NSH packet MUST be disca= rded. The comparison of the computed HMAC value to the store value MUST
= be done in a constant-time manner to thwart timing attacks.

-Tiru
=C2=A0

-Ben
--0000000000000f97bc05c7755e87-- From nobody Wed Jul 21 15:40:24 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 209583A2D37; Wed, 21 Jul 2021 15:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9ayU4MV65Oo; Wed, 21 Jul 2021 15:40:14 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9669D3A2D38; Wed, 21 Jul 2021 15:40:08 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 16LMdwLM027995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 21 Jul 2021 18:40:03 -0400 Date: Wed, 21 Jul 2021 15:39:57 -0700 From: Benjamin Kaduk To: mohamed.boucadair@orange.com Cc: The IESG , "draft-ietf-sfc-nsh-integrity@ietf.org" , "sfc-chairs@ietf.org" , "sfc@ietf.org" , "gregimirsky@gmail.com" Message-ID: <20210721223957.GQ88594@kduck.mit.edu> References: <162629795136.25767.17850752260179612361@ietfa.amsl.com> <14311_1626444945_60F19491_14311_347_2_787AE7BB302AE849A7480A190F8B9330353C02BD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <14311_1626444945_60F19491_14311_347_2_787AE7BB302AE849A7480A190F8B9330353C02BD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Archived-At: Subject: Re: [sfc] Benjamin Kaduk's Discuss on draft-ietf-sfc-nsh-integrity-06: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2021 22:40:20 -0000 Hi Med, I see that Tiru has also replied, but I will respond inline here and then process Tiru's comments. On Fri, Jul 16, 2021 at 02:15:44PM +0000, mohamed.boucadair@orange.com wrote: > Hi Ben, > > Many thanks again for the detailed review. Really helpful. > > Please see inline some replies to the COMMENT part (with references to some DISCUSS points). > > Changes to address your COMMENTS/NITS can be tracked at: https://tinyurl.com/nsh-integrity-latest. > > Cheers, > Med > > > -----Message d'origine----- > > De : Benjamin Kaduk via Datatracker [mailto:noreply@ietf.org] > > Envoyé : mercredi 14 juillet 2021 23:26 > > À : The IESG > > Cc : draft-ietf-sfc-nsh-integrity@ietf.org; sfc-chairs@ietf.org; > > sfc@ietf.org; gregimirsky@gmail.com; gregimirsky@gmail.com > > Objet : Benjamin Kaduk's Discuss on draft-ietf-sfc-nsh-integrity-06: > > (with DISCUSS and COMMENT) > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-sfc-nsh-integrity-06: Discuss > > > > When responding, please keep the subject line intact and reply to > > all email addresses included in the To and CC lines. (Feel free to > > cut this introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss- > > criteria.html > > for more information about DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/ > > > > > > > [...] > > > > > > -------------------------------------------------------------------- > > -- > > COMMENT: > > -------------------------------------------------------------------- > > -- > > > > Section 3 > > > > o Both encrypted and unencrypted Context Headers MAY be included > > in > > the same NSH. That is, some Context Headers may be protected > > while others do not need to be protected. > > > > In the security area we're pretty strongly moved towards a stance of > > "encrypt everything that doesn't have a strong need to be plaintext > > (since we don't want to assume that we can predict all threats and > > attacks in advance), and QUIC has even taken that to new levels. > > It's quite surprising to see "don't need to be protected" as a > > justification for lack of encryption, rather than "need to be > > unprotected". Given that we're going to be solving key distribution > > for integrity protection anyway, it remains unclear to me why we > > wouldn't just encrypt everything. > > [Med] This depends on the type of the context header, the capabilities of SFs, local policies, performance implications, etc. Encrypting only a subset of context headers is a feature we want to provide. > > Please note that the I-D gives a transition path for SFC from the current plain text without any confidentiality or integrity protection to start with integrity protection and eventually transition to (partial and full) confidentiality and integrity protection. > > We can recommend deployments to consider using encryption for **any** context header to prevent pervasive monitoring. That seems reasonable, essentially something analogous to my above note about it being safest to make cleartext the exception rather than the default, in terms of what justification is looked for (and I want to reiterate that this whole remark is a non-blocking comment). > We understand that the wording "do not need to be protected" may not be appropriate. We removed the sentence starting with "That is, some ...". Thank you! > > > > Section 4.1.1 > > > > Is the column heading for the middle column of Table 1 referring to > > the Base Header and "Service Path Header"? I'm not sure how to > > interpret just "Service Header" other than the entire NSH, which > > doesn't seem right... > > [Med] That is in reference to what we say in Section 3 that: > > o Base Header: Provides information about the service header and the > payload protocol. The "base header" part is not what I'm unsure about. To clarify, https://datatracker.ietf.org/doc/html/rfc8300#section-2.1 describes the NSH (Network Service Header) as a single header that's composed of a Base Header, a Service Path Header, and Context Header(s). If we just write "Service Header", I have to pick whether that refers to the (Network) Service Header or the Service (Path) Header. The unqualified "service header" is used a couple times in RFC 8300, but in my (hasty) reading is referring to the entire NSH. My understanding of the contents of table 1 are that this column refers to the Service Path Header, but I would like to see that written out more clearly in the text. > > > > The Service Path Header (Section 2 of [RFC8300]) is not encrypted > > because SFFs use Service Index (SI) in conjunction with Service > > Path > > Identifier (SPI) for determining the next SF in the path. > > > > It's good to see this spelled out like this; I'd love to have this > > kind of explanation for every un-encrypted protocol element. > > > > Section 4.1.2 > > > > The solution provides integrity protection for the NSH data. Two > > levels of assurance (LoAs) are supported. > > > > I see (reading onward) that the two LoAs just differ in what is > > covered by the integrity tag, but each involve only a single MAC. > > There's a reasonable argument that when there are overlapping needs > > for what data needs protecting and who needs access to it, that > > multiple MACs (or encryption, if needed) are most appropriate, which > > can be tailored to the respective needs. This is something that > > Phillip Hallam-Baker has ascribed as the "short-blanket theory" of > > cryptography, in that it's like a blanket that's too short to cover > > everything you want, so you need to have more than one and put them > > in partially overlapping layers. > > Perhaps this "short-blanket theory" is more applicable to Discuss > > point > > (0) than what is covered by the MAC, though... > > > > The first level of assurance where all NSH data except the Base > > Header are integrity protected (Figure 2). In this case, the NSH > > imposer may be a Classifier, an NSH-aware SF, or an SFC Proxy. > > SFFs > > are not thus provided with authentication material. [...] > > > > There seems to be a gap in the chain of reasoning as to why SFFs are > > not provided with authentication material. It seems that the intent > > is something along the lines of considering which entities need > > access to the key material in order to successfully add an NSH or > > update context headers, but that alone is not itself cause to say > > that other entities can never be provided with the keys (subject to > > the security considerations of group-shared PSKs, of course). > > [Med] The two levels are there for several reasons: > * ease deployment: have an option that does not involve SFFs. > * performance considerations of SFFs I am sure there are reasons to have this as an option; my concern here is in some sense editorial in that the text includes a conclusion ("thus") but does not include a chain of logical reasoning that guides the reader to believe that conclusion. I was hoping to have a bit more text in the document that justifies the claim. > > > Furthermore, if a particular SFF is trusted, it may have grounds to > > verify the integrity tag even if it is administratively prohibited > > from writing such a tag. > > [Med] Agree, but we wanted to keep only two clear LoAs. > > > > > In both levels of assurance, the unencrypted Context Headers and > > the > > packet on which the NSH is imposed are subject to integrity > > protection. > > > > Surely any encrypted Context Headers are also given integrity > > protection, as excluding them from the MAC computation would be > > quite complex. I see that the encrypted context headers are not > > part of the AAD input, but in the AEAD model the ciphertext is still > > given integrity protection! > > [Med] The text you quoted is here to remind that the original NSH packet is integrity protected as this may be missed by the reader. Likewise, that same protection is provided to context headers, even when unencrypted. Hmm, maybe the sentiment is along the lines of "the integrity protection provided by the cryptographic mechanism is extended to also provide protection for the unencrypted Context Headers and the packet on which the NSH is imposed". > > > > Section 4.2 > > > > The authenticated encryption algorithm defined in [RFC7518] is > > used > > to provide NSH data integrity and to encrypt the Context Headers > > that > > carry privacy-sensitive metadata. > > > > RFC 7518 (JSON Web Algorithms) is a very surprising reference for > > generic AEAD encryption. > > [Med] FYI, we used to have such reference in draft-rebo-sfc-nsh-integrity-00: > > The Authenticated Encryption with Associated Data (AEAD) algorithm > [RFC5116] is used to provide NSH data integrity and to encrypt > privacy-sensitive metadata. I guess that I'm trying to make a distinction between an AEAD "interface" as an abstraction, and a particular combination of cryptographic primtives used to provide that interface. It can be useful to reference RFC 5116 for "what is an AEAD" even if a specific construction from RFC 5116 is not used. For example, within the boringssl cryptographic library, the TLS ciphersuites that use AES-CBC+HMAC are still treated as providing the AEAD interface, as a simplifying abstraction. The AES-CBC+HMAC instantiation of AEAD is fairly widespread, and it may be reasonable to just present it in its own right without reference to a previous incarnation like RFC 7518. But I don't have particularly strong feelings in this regard. > We changed the spec because we wanted to control by design the nodes that are allowed to access encrypted data vs integrity-only. BTW, we sent a note to the saag mailing list right after we changed our design in the hope to have more eyes on what we are doing, but unfortunately we didn't get much attention. I guess this was https://mailarchive.ietf.org/arch/msg/saag/HOaeRhyJX_RdqLu-XFitNddAd-I/ and it looks like I skimmed the draft for a quick reply but didn't look in depth. I'm not even sure if I even processed Tiru's reply to me at the time that called out the separation of ENC_KEY and MAC_KEY... > Our understanding of your review is that you are not against using ENC_KEY and MAC_KEY, but you prefer AES-GCM over CBC. We are considering the following change (not yet implemented): I'm not entirely sure if the summary you write reflects my sentiment, since there's a bit of a subtlety AES-GCM+HMAC seems like it will provide the properties we need for this mechanism, but AES-CTR+GHASH does not. Since you do mention HMAC still in the NEW text, that is promising. > OLD: > > Classifiers, NSH-aware SFs, and SFC proxies MUST implement the > AES_128_CBC_HMAC_SHA_256 algorithm and SHOULD implement the > AES_192_CBC_HMAC_SHA_384 and AES_256_CBC_HMAC_SHA_512 algorithms. > > Classifiers, NSH-aware SFs, and SFC proxies MUST implement the HMAC- > SHA-256-128 algorithm and SHOULD implement the HMAC-SHA-384-192 and > HMAC-SHA-512-256 algorithms. > > SFFs MAY implement the aforementioned cipher suites and HMAC > algorithms. > > Note: The use of Advanced Encryption Standard (AES) in Galois/ > Counter Mode (GCM) + HMAC may have CPU and packet size > implications (need for a second 128-bit authentication tag). > > NEW: > > Classifiers, NSH-aware SFs, and SFC proxies MUST implement the > AES_128_GCM algorithm and SHOULD implement the > AES_192_GCM and AES_256_GCM algorithms. > > Classifiers, NSH-aware SFs, and SFC proxies MUST implement the HMAC- > SHA-256-128 algorithm and SHOULD implement the HMAC-SHA-384-192 and > HMAC-SHA-512-256 algorithms. > > SFFs MAY implement the aforementioned cipher suites and HMAC > algorithms. > > We will have to refer to RFC5116 and [GCM] > > [GCM] Dworkin, M., "Recommendation for Block Cipher Modes of > Operation: Galois/Counter Mode (GCM) and GMAC", > National Institute of Standards and Technology SP 800- > 38D, November 2007. > > With that, we don't need to cite RFC7518. Ok. > > Continuing on, it becomes clear that we in > > fact do not want a generic AEAD operation here, but instead have > > need for separation of encryption and integrity protection due to > > the various separations of roles that are possible. > > [Med] That's it! > > Because this is > > a divergence from current best practices (use of native AEAD cipher > > modes like GCM, SIV, etc.), I might suggest a rather different > > introductory material: > > > > % The AEAD interface specified in RFC 5116 is a very powerful tool > > for % providing strong confidentiality and integrity protection for > > protocol % messages, and has become quite widely adopted as a > > result. For % protecting NSH data we adhere to the spirit of the > > AEAD interface but % use a slightly modified version in order to > > remain consistent with the % privilege separation needed (e.g., in > > the second level of assurance, % SFFs need to be able to update the > > message integrity tag but do not % need access to the decrypted > > plaintext). Accordingly, a compound AEAD % mechanism combining CBC > > encryption and HMAC integrity tag is used, so % that distribution of > > the encryption key can be limited. Rather than % define a new > > scheme from scratch, the AES_CBC_HMAC_SHA2 scheme from % [RFC7518] > > is used. In order to simplify key distribution, a single % secret > > key material seed K is used, which can be kept private % centrally > > or distributed to all parties that will have access to % decrypted > > plaintext, and the secondary keys MAC_KEY and ENC_KEY are % derived > > from K as discussed in Section 5.2.2.1 of [RFC7518]. Entities % > > that need to update the integrity tag but are not authorized to see > > % the decrypted plaintext will only receive MAC_KEY and not K or % > > ENC_KEY. > > [Med] I guess, the comment will not be relevant after mandating AES-GCM. Not in the same way, no. In some sense we are still using an AEAD interface, but we have two layers of integrity tag because we need to be able to have one tag that is validatable by some parties who are not authorized to be able to read or modify the plaintext data. > > > > o If the Context Headers are not encrypted, the Hashed Message > > Authentication Mode (HMAC) algorithm discussed in [RFC4868] is > > used to protect the integrity of the NSH data. > > > > It's not clear to me that this is adding much value; HMAC is used > > whether or not there are encrypted headers, and the RFC 4868 > > reference is rather odd (see also my Discuss point (2)). > > > > The advantage of using the authenticated encryption algorithm is > > that > > NSH-aware SFs and SFC proxies only need to re-compute the message > > integrity of the NSH data after decrementing the Service Index > > (SI) > > and do not have to re-compute the ciphertext. The other > > advantage is > > that SFFs do not have access to the ENC_KEY and cannot act on the > > encrypted Context Headers and, only in case of the second level > > of > > assurance, SFFs do have access to the MAC_KEY. Similarly, an > > NSH- > > aware SF or SFC Proxy not allowed to decrypt the Context Headers > > will > > not have access to the ENC_KEY. > > > > [If my above suggestion is used, this text has probably become > > mostly redundant and could be trimmed down or removed.] > > > > The authenticated encryption process takes as input four-octet > > strings: a secret key (K), a plaintext (P), Additional > > Authenticated > > Data (A) (which contains the data to be authenticated, but not > > encrypted), and an Initialization Vector (IV). The ciphertext > > value > > (E) and the Authentication Tag value (T) are provided as outputs. > > > > In order to decrypt and verify, the cipher takes as input K, IV, > > A, > > T, and E. The output is either the plaintext or an error > > indicating > > that the decryption failed as described in Section 5.2.2.2 of > > [RFC7518]. > > > > This seems true for the abstract AEAD interface, but since we're > > peeling off the HMAC integrity tag for standalone use, we may need > > to say something about what inputs/outputs are needed for just using > > the integrity tag without doing decryption. In particular, we > > cannot use K as an input for standalone HMAC verification! > > > > Also, this is just the generic AEAD interface, so RFC 5116 is > > probably a more apropos reference than RFC 7518. > > [Med] As suggested above, we can refer to RFC5116 instead of RFC7518. > > > > > Section 4.3 > > > > Note: The use of Advanced Encryption Standard (AES) in Galois/ > > Counter Mode (GCM) + HMAC may have CPU and packet size > > implications (need for a second 128-bit authentication tag). > > > > [This might also be redundant if my earlier proposal is accepted.] > > > > Section 4.4 > > > > The document does not assume nor preclude the following: > > > > o The same keying material is used for all the service functions > > used within an SFC-enabled domain. > > > > o Distinct keying material is used per SFP by all involved SFC > > data > > path elements. > > > > o Per-tenant keys are used. > > > > I suggest a forward reference to the security considerations with a > > brief note that the risk involved in using a group-shared symmetric > > key increases with the size of the group to which it is shared. > > [Med] OK. Done. > > > > > In order to accommodate deployments relying upon keying material > > per > > SFC/SFP and also the need to update keys after encrypting NSH > > data > > for a certain amount of time, this document uses key identifiers > > to > > unambiguously identify the appropriate keying material. Doing so > > allows to address the problem of synchronization of keying > > material. > > > > I'd suggest making a statement about the scope in which key > > identifiers need to be unique. > > [Med] That depends on the bullet mentioned above (ex. per-tenant). I'm not sure adding the sentence adds much value as the scope tweaking still deployment-specific. If it takes a lot of text to describe accurately it may not be worth doing, sure. > > > > Section 4.5 > > > > An NSH-aware SF or SFC Proxy that needs to decrypt some Context > > Headers uses ENC_Key and the decryption algorithm for the key > > identifier being carried in the NSH. > > > > I think we need to say that decryption MUST NOT proceed unless the > > integrity tag has been successfully validated. To decrypt without > > checking the integrity tag violates the AEAD interface. > > Alternately, we could only ever describe decryption as the AEAD > > operation that uses K as input (not just ENC_KEY) -- §7.6 seems to > > attempt to take this latter approach, but the document as a whole is > > not consistent about it. > > [Med] This section is about introducing the new MAC context headers. I don't think this is the right place to mention this. > > BTW, the order you mentioned is what is implied by the procedure: 7.5 (NSH Data Validation) and then 7.6 (Decryption of NSH Metadata). Invalid data are discarded as part of 7.5. > > No problem to add a note to 7.6 if you think this is really needed. It may be best to wait and see what things shape out to be after other changes. > > > > Section 5, 5.x > > > > I strongly suggest changing "Key Length" to "keyid length", since > > there is already convention on "key length" (e.g., for AES-128 vs > > AES-192 vs AES-256). > > [Med] Fixed as per a comment from Eric. > > > > > Section 5.1 > > > > Key Identifier: Carries a variable-length Key Identifier object > > used > > to identify and deliver keys to SFC data plane elements. This > > identifier is helpful to accommodate deployments relying upon > > keying material per SFC/SFP. The key identifier helps in > > resolving the problem of synchronization of keying material. > > > > I suggest clarifying that a single key identifier is used to lookup > > both the associated ENC_KEY and the associated MAC_KEY (or, > > alternately, that it is logically bound to K and remind the reader > > that ENC_KEY and MAC_KEY are extracted from K and might be > > separately distributed). > > [Med] Added this NEW: > > "A single key identifier is used to lookup both the ENC_KEY and the MAC_KEY associated with a key." > > > > > Key Length: Variable. Carries the length of the key identifier. > > [...] > > IV Length: Carries the length of the IV (Section 5.2 of > > [RFC7518]). > > If encryption is not used, IV length is set to zero (that is, > > no > > "Initialization Vector" is included). > > > > Please also specify that the Key/IV lengths are measured in bytes > > [Med] Fixed per a comment from Eric. If he keeps this up, we'll have to nominate him for SEC AD... > > (the reference for IV length, at least, talks about IVs in bits). > > > > I strongly suggest using a value other than zero as the sentinel > > value for "no encryption" -- there already exist modes like AES-SIV > > (RFC 5297) that do not require an IV input, which would be a natural > > use for zero-length IV. > > [Med] What is the advantage of using a value other than zero when encryption is not included? There may arise cases in the future where it's desired to use an encryption scheme that takes a zero-length IV. If the zero-length IV already has the semantics of "encryption not used", then that needlessly precludes such future flexibility. > > > > Additionally, one might imagine using a non-zero-length IV as input > > to an HMAC calculation as a per-message nonce. On cursory > > examination, since we are already using timestamp-based replay > > detection, the additional nonce is unlikely to add much value, but > > I'm not willing to completely rule it out on the basis of the > > minimal analysis I performed. > > > > Section 7.1 > > > > Only one instance of "MAC and Encrypted Metadata" Context Header > > (Section 5) is allowed. If multiple instances of "MAC and > > Encrypted > > Metadata" Context Header are included in an NSH packet, the SFC > > data > > > > I think Roman may have mentioned this already, but please clarify if > > this is one instance per NSH or per packet (e.g., in hierarchical > > SFC we might have more than one NSH in a packet). > > [Med] I confirm. (I trust it will make it into the document, based on Roman's review.) > > > > Please also clarify it if is permitted to have both MAC#1 and MAC#2 > > present in the same packet. (IIUC there are not obvious situations > > where such a setup would be useful, but it's still good to be clear > > about expectations.) > > [Med] It is not allowed to have both. This is why we are using the generic term: "instance of "MAC and Encrypted Metadata" Context Header". That term is used through the document when we refer indifferently to MAC#1 and MAC#2. That is what I suspected, so thank you for confirming. I would propose to have in one location a clear statement that MAC#1 and MAC#2 are not allowed together, but I do not insist on it. > > > > Section 7.2 > > > > If the Context Headers are not encrypted, the HMAC algorithm > > discussed in [RFC4868] is used to integrity protect the target > > NSH > > data. [...] > > > > It's not really clear to me why RFC 4868 is the right reference > > here, as opposed to (e.g.) RFC 2104. In particular, see my Discuss > > point (2). > > [Med] We think that RFC 4868 is the right reference as RFC 2014 does not discuss any of the HMAC algorithms used in this specification. In my experience it's fine to say just that "we use HMAC [RFC 2014] as instantiated with [reference-for-hash]", so whether or not the specific construction (e.g., as from RFC 4868) appears in the reference is not critical. > > > > The Message Authentication Code (T) computation process can be > > illustrated as follows: > > > > T = HMAC-SHA-256-128(MAC_KEY, A) > > > > I agree with the other reviewer that wondered about just using "MAC" > > (or maybe "HMAC") rather than "HMAC-SHA-256-128" here (I do see the > > "can be illustrated as" qualifier). > > > > It's also a little weird to reuse T and A from the AEAD construction > > (or RFC 4868) here without additional discussion on how they apply > > and how the value of A is constructed. > > [Med] Noted. We made already this change: s/A/target NSH data. > > > > > An entity in the SFP that intends to update the NSH MUST follow > > the > > above behavior to maintain message integrity of the NSH for > > subsequent validations. > > > > I'm not sure that "intends to" is needed; the requirement applies to > > actions, not intent. > > [Med] Fair. Fixed, thanks. > > > > > Section 7.3 > > > > In an SFC-enabled domain where pervasive monitoring [RFC7258] is > > possible, all Context Headers carrying privacy-sensitive metadata > > MUST be encrypted; [...] > > > > I agree with the other reviewer that noted that this seems to > > effectively be an unqualified "MUST", since there is always some > > possibility of monitoring. > > > > MAC_KEY = initial MAC_KEY_LEN octets of K, > > ENC_KEY = final ENC_KEY_LEN octets of K, > > E = CBC-PKCS7-ENC(ENC_KEY, P), > > M = MAC(MAC_KEY, A || IV || E || AL), > > T = initial T_LEN octets of M. > > MAC and Encrypted Metadata = E || T > > > > I recognize that this is just copy+paste from RFC 7518 (with the > > addition of the last line), but it seems a glaring omission that the > > CBC-PKCS7-ENC() invocation does not include the IV as an input! > > (In §5.2.2.1 of RFC 7518 we do see that "The plaintext is CBC > > encrypted using PKCS #7 padding using ENC_KEY as the key and the > > IV", so it's just the figure/formula that omits the IV.) > > > > We also don't define or mention T_LEN in this document other than in > > this formula and the analogous one for MAC-without-encryption, which > > might be worth remedying. > > [Med] If we mandate AES_GCM, all the above text will be removed. > > > > > Section 7.4 > > > > I suggest adding another word (like "Prevention") to the section > > title. > > > > [Med] Fixed. > > > The received NSH is accepted by an NSH-aware node if the > > Timestamp > > (TS) in the NSH is recent enough to the reception time of the NSH > > (TSrt). The following formula is used for this check: > > > > -Delta < (TSrt - TS) < +Delta > > > > (There's no real reason why the accepted timestamp skew parameter > > Delta needs to be symmetric in the positive and negative > > directions.) > > [Med] This was to accommodate any sync issues. Having it extend in both directions is clearly useful, to cover all kinds of sync issues. But the range might equally as well be -Epsilon < (TSrt - TS) < +Delta for Delta != Epsilon. Perhaps that's needless complexity, but it seemed worth raising the idea for discussion. > > > > Replay attacks within the Delta window may be detected by an NSH- > > aware node by recording a unique value derived, for example, from > > the > > NSH data and Original packet (e.g., using SHA2). [...] > > > > Note that the unique value MUST NOT use as input any bits that are > > not covered by the MAC. > > [Med] Agree, but we don't specify the bits that are used. This is a very tempting and easy-to-make mistake; I think we should preemptively warn the implementor against it, regardless of whether we also provide a specific suggestion (e.g., the next line of this email). > Indeed, just using the MAC itself as the > > unique value would be a fairly straightforward scheme, I think. > > [Med] Thanks. > > > > > Section 7.5 > > > > When an SFC data plane element receives an NSH packet, it MUST > > first > > ensure that a "MAC and Encrypted Metadata" Context Header is > > included. [...] > > > > This sort of requirement (as written) would seem to support the > > position of some other reviewers that this document would need to > > formally update RFC 8300. > > [Med] Added "When an SFC data plan element conforms to this specification," to address one of Roman's comments. > > > > > Section 9 > > > > We might discuss that this mechanism is only for metadata type 2 and > > not type 1 (as well as that with the relatively small fixed length > > of type 1 metadata, it's quite challenging to provide useful > > cryptographic protection), so that type-1 metadata still has no > > generic protection mechanism. A given metadata element could define > > its own protection scheme, of course. > > [Med] We already have the following in the introduction: > > This specification is only > applicable to NSH MD Type 0x02 (Section 2.5 of [RFC8300]). Yes. There is some security consideration to limiting this mechanism to type 2 only, in that type 1 exists and has no defined method of protection. My proposal is to mention that this mechanism is not fully generic (i.e., does not cover type 1 metadata) and a little bit of explanation of why. > > > > The attacks discussed in [I-D.nguyen-sfc-security-architecture] > > are > > handled owing to the solution specified in this document, except > > for > > attacks dropping packets. [...] > > > > >From a very quick read, draft-nguyen-sfc-security-architecture > > proposes > > a probe-based scheme that monitors all middleboxes (or at least > > those in the expected path) to detect a middlebox-bypass attack and > > verify that the probe traversed the expected SFP. I am not sure > > that this document on its own suffices to prevent the middlebox- > > bypass attack for all traffic (i.e., the probe-based scheme might > > still be needed). If some network entities know what the expected > > service index will be for a given SPI at a given node, then > > middlebox-bypass attacks could be natively detected, but my > > understanding was that such advance knowledge of expected service > > index was not going to be available. > > [Med] The SF bypass can be detected if SI was manipulated on path because integrity check will fail. Does each SF or some other on-path entity know which (SFP, SI) are allowed/expected for traffic it receives? If not, then just moving the packets around differently without changing their contents is my concern. > > > > The solution specified in this document does not provide data > > origin > > authentication. > > > > I would have expected more in-depth discussion of the security > > considerations for a group-shared PSK scheme, including how the risk > > of key loss/compromise goes up when the key is distributed to more > > locations. > > [Med] That's part of the key management, declared out of scope. Even with the details of how keys are shared/distributed being out of scope, I still would have expected discussion of the risks of shared keys. Perhaps my expectations are wrong (it has happened before and will happen again), but that's still what I expect. > > > > Section 9.1 > > > > No device other than the NSH-aware SFs in the SFC-enabled domain > > should be able to update the integrity protected NSH data. > > > > What about classifiers and SFC proxies? > > [Med] Good catch: proxies should be mentioned as well as re-classification. We can't just talk about classification as this is about updating the MAC. > > The NEW text that also takes into account a comment from John is as follows: > > It is expected that specific devices in the SFC-enabled domain will > be configured such that no device other than the classifiers (when > reclassification is enabled), NSH-aware SFs, and SFC proxies will be > able to update the integrity protected NSH data (Section 7.1), and > also such that no device other than the NSH-aware SFs and SFC proxies > will be able to decrypt and update the Context Headers carrying > sensitive metadata (Section 7.1). > > > > > Section 9.2 > > > > I expected to see some remarks here analogous to the second > > paragraph of > > §9.1 (even if just by reference to that section). > > [Med] Added this NEW sentence: > > Similar to Section 9.1, no device other than the NSH-aware SFs and > SFC proxies in the SFC-enabled domain should be able to decrypt and > update the Context Headers carrying sensitive metadata. Thanks! > > > > Section 9.3 > > > > Section 5.6 of [RFC8633] describes best current practices to be > > considered in deployments where SFC data plane elements use NTP > > for > > time synchronization purposes. > > > > The referenced section covers NTP symmetric mode only. > > [Med] Yes because we think that’s the symmetric mode is better vs. broadcast with trusted modes. > > Is > > client/server mode not a BCP for trusted networks and > > broadcast/symmetric the only options? > > [Med] Not sure to get this comment. Sorry, let me try again. "I do not operate an NTP service and have little knowledge of NTP operational best practices. I can easily believe that NTP symmetric mode is a good option ("best current practice") on a trusted network, but I could also easily believe that NTP client/server mode would equally be a useful option on a trusted network. Is there a reason to prefer symmetric over client/server mode?" It seems that you mostly answered this above, though just with a "yes" and not the actual reason (the actual reason would just be for my own curiosity and is not expected to appear in the document, so please feel free to drop the topic). Thanks, Ben From nobody Wed Jul 21 15:47:06 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC17B3A2D58; Wed, 21 Jul 2021 15:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYZNxgVpKDZC; Wed, 21 Jul 2021 15:46:59 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D6CE3A2D54; Wed, 21 Jul 2021 15:46:58 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 16LMkoAw030058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 21 Jul 2021 18:46:54 -0400 Date: Wed, 21 Jul 2021 15:46:49 -0700 From: Benjamin Kaduk To: tirumal reddy Cc: The IESG , draft-ietf-sfc-nsh-integrity@ietf.org, sfc-chairs@ietf.org, sfc@ietf.org, gregimirsky@gmail.com Message-ID: <20210721224649.GR88594@kduck.mit.edu> References: <162629795136.25767.17850752260179612361@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [sfc] Benjamin Kaduk's Discuss on draft-ietf-sfc-nsh-integrity-06: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2021 22:47:04 -0000 Hi Tiru, Also inline... On Mon, Jul 19, 2021 at 01:20:11PM +0530, tirumal reddy wrote: > Hi Ben, > > Please see inline > > On Thu, 15 Jul 2021 at 02:55, Benjamin Kaduk via Datatracker < > noreply@ietf.org> wrote: > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-sfc-nsh-integrity-06: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > (0) (I came to this realization rather late in my review process, so > > there may be places where the COMMENT and this discuss point are in > > disagreement; this DISCUS takes precedence.) > > I fear that the construction that separately distributes ENC_KEY and > > MAC_KEY in an attempt to achieve privilege separation is fatally flawed. > > In particular, the CBC encryption mode is a malleable encryption mode, > > in that flipping a bit of ciphertext will filp the corresponding bit of > > the next block of recovered plaintext (at the cost of completely > > garbling the recovered block containing the bit that was modified). > > Subsequent blocks are unaffected. Typically we combine CBC mode with a > > MAC such as HMAC in order to prevent such modifications from being > > exposed as attack vectors, and while we do use HMAC here for that > > purpose, we also introduce a separate class of actors that have access > > to the HMAC key but not the encryption key. Accordingly, those actors > > can produce a new, valid, integrity tag after making a modification to > > the ciphertext, allowing them to engage in attacks that make use of > > ciphertext malleability. Ciphertext malleability is particularly useful > > as an attack vector when the structure of the plaintext being encrypted > > is known, and there are portions of the plaintext that the application > > will either ignore if they are garbled or are expected to be near random > > in the normal case (and thus for which garbled output does not cause > > rejection by the application). In a SFC environment it seems highly > > likely that the structure of the plaintext will be known or guessable, > > and we don't have any real mechanisms to control what types of metadata > > go into encrypted context headers, so it seems that we must act as if we > > are exposed to this risk. > > > > While §4.3 does have a note that use of GCM with HMAC is undesirable due > > to the additional authentication tag, it may be unavoidable in order to > > provide the properties that we need. > > > > Thanks for explaining the attack. We will modify the text in Section 4.3 as > follows to address the comment: > > Classifiers, NSH-aware SFs, and SFC proxies MUST implement the > AES_128_GCM [GCM][RFC5116] algorithm and SHOULD implement the > AES_192_GCM and AES_256_GCM algorithms. > > Classifiers, NSH-aware SFs, and SFC proxies MUST implement the HMAC- > SHA-256-128 algorithm and SHOULD implement the HMAC-SHA-384-192 and > HMAC-SHA-512-256 algorithms. > > SFFs MAY implement the aforementioned cipher suites and HMAC > algorithms. > > Note: > The use of AES_128_CBC_HMAC_SHA_256 algorithm would have avoided the need > for a second 128-bit authentication tag but due to the nature of how CBC > mode operates, the mode allows for malleability of plaintexts. This > malleability allows for attackers to make changes in the ciphertext and, if > parts of the plaintext are known, create arbitrary blocks of > plaintext. This specification mandates the use of AES-GCM to prevent this > type of attack. This seems okay on first read, thanks. I will probably end up reading it again once the revised I-D is posted, in the full context of the draft. > > > > > (1) Section 5.1 describes the MAC as: > > > > Message Authentication Code: Covers the entire NSH data, excluding > > the Base header. The Additional Authenticated Data (defined in > > [RFC7518]) MUST be the Service Path header, the unencrypted > > Context headers, and the inner packet on which the NSH is imposed. > > > > This description seems to exclude from the MAC most of the MAC context > > header itself (if we go by the corresponding figure), which is very bad > > for security. We definitely need to include under the MAC the MAC > > context header bits from metadata class through and including at least > > timestamp, and I think IV length as well. (The IV itself would be > > incorporated via the ciphertext, since the IV is an input to encryption, > > but since the IV length field indicates whether or not encryption was > > performed, we'd need to protect that information.) > > > > No, the MAC context header is also used for generating the digest. Ok. > > > > > Similarly, Section 5.2 has the description: > > > > Message Authentication Code: Coves the entire NSH data. The > > Additional Authenticated Data (defined in [RFC7518]) MUST be the > > entire NSH data (i.e., including the Base Header) excluding the > > Context Headers to be encrypted. > > > > which on the face of it includes the field that holds the MAC itself > > (and is not yet populated), i.e., is self-referential. > > > > The below update will address this comment: > > The NSH imposer sets the MAC field to zero and then computes the message > integrity for the target NSH data (depending on the integrity protection > scope discussed in Section 5) using MAC_KEY and HMAC algorithm. It inserts > the computed digest in the MAC field in the "MAC and Encrypted Metadata" > Context Header. > Thanks! (I think Roman may have goten this before me, so sorry for the duplication.) > > > > > I think we need to be much more precise about the construction of the > > AAD in both cases. It's possible that the HMAC construction for the > > no-encrypted-context-headers case can inherit a definition from the AAD > > description, but if not we'll need to have some more precision there as > > well. > > > > (2) In order for the MAC-only construction in §7.2 to be compatible with > > the AEAD integrity tag construction, we would need to include the 64-bit > > AL after A. While HMAC is intrinsically immune to length-extension > > attacks, I think that having the explicit AL is useful to avoid any risk > > of malleability, since the same MAC_KEY is used for constructing both > > types of MACs. > > > > I don't think this comment is applicable after AES_128_CBC_HMAC_SHA_256 is > removed. I think so, yes. > > > > > (3) Section 5.1 describes the Timestamp field as an "unsigned 64-bit > > integer value", which is inconsistent with the actual format given in > > Section 6. > > > > Thanks, we will fix it in the next revision. > > > > > > (4) Section 7.5 directs the verifier to check if "the value of the newly > > generated digest is identical to the one enclosed in the NSH". It is > > critical for the security of the system that this comparison be done in > > a constant-time manner that does not provide a side channel into whether > > the generated digest and the value in the NSH share a common substring. > > > > Agreed, will update text as follows: > > After storing the value of the MAC field in the "MAC and Encrypted > Metadata" Context Header, the SFC data plane element fills the MAC > field with zeros. Then, the SFC data plane element generates the message > integrity > for the target NSH data (depending on the integrity protection scope > discussed in Section 5) using MAC_KEY and HMAC algorithm. If the value of > the newly generated digest is identical to the stored one, the SFC data > plane element is certain that the NSH data has not been tampered and > validation is therefore successful. Otherwise, the NSH packet MUST be > discarded. The comparison of the computed HMAC value to the store value MUST > be done in a constant-time manner to thwart timing attacks. Thanks! > > > > > (5) Do the MAC context headers always have to be the last metadata > > entries in the packet (to simplify the cryptographic calculations)? > > > > Yes. > Okay. I suspected that, but it is probably worth a MUST-level requirement in the document to make it clear to everyone. Thanks again, Ben > > > Certainly the diagrams only show "unencrypted context headers" appearing > > prior to the MAC context header, so if we expect unencrypted context > > headers to appear after the MAC context header as well, we should be > > clear about that both in the figures and in the specification for how to > > prepare the AAD. > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Section 3 > > > > o Both encrypted and unencrypted Context Headers MAY be included in > > the same NSH. That is, some Context Headers may be protected > > while others do not need to be protected. > > > > In the security area we're pretty strongly moved towards a stance of > > "encrypt everything that doesn't have a strong need to be plaintext > > (since we don't want to assume that we can predict all threats and > > attacks in advance), and QUIC has even taken that to new levels. It's > > quite surprising to see "don't need to be protected" as a justification > > for lack of encryption, rather than "need to be unprotected". Given > > that we're going to be solving key distribution for integrity protection > > anyway, it remains unclear to me why we wouldn't just encrypt > > everything. > > > > Section 4.1.1 > > > > Is the column heading for the middle column of Table 1 referring to the > > Base Header and "Service Path Header"? I'm not sure how to interpret > > just "Service Header" other than the entire NSH, which doesn't seem > > right... > > > > The Service Path Header (Section 2 of [RFC8300]) is not encrypted > > because SFFs use Service Index (SI) in conjunction with Service Path > > Identifier (SPI) for determining the next SF in the path. > > > > It's good to see this spelled out like this; I'd love to have this kind > > of explanation for every un-encrypted protocol element. > > > > Section 4.1.2 > > > > The solution provides integrity protection for the NSH data. Two > > levels of assurance (LoAs) are supported. > > > > I see (reading onward) that the two LoAs just differ in what is covered > > by the integrity tag, but each involve only a single MAC. There's a > > reasonable argument that when there are overlapping needs for what data > > needs protecting and who needs access to it, that multiple MACs (or > > encryption, if needed) are most appropriate, which can be tailored to > > the respective needs. This is something that Phillip Hallam-Baker has > > ascribed as the "short-blanket theory" of cryptography, in that it's > > like a blanket that's too short to cover everything you want, so you > > need to have more than one and put them in partially overlapping layers. > > Perhaps this "short-blanket theory" is more applicable to Discuss point > > (0) than what is covered by the MAC, though... > > > > The first level of assurance where all NSH data except the Base > > Header are integrity protected (Figure 2). In this case, the NSH > > imposer may be a Classifier, an NSH-aware SF, or an SFC Proxy. SFFs > > are not thus provided with authentication material. [...] > > > > There seems to be a gap in the chain of reasoning as to why SFFs are not > > provided with authentication material. It seems that the intent is > > something along the lines of considering which entities need access to > > the key material in order to successfully add an NSH or update context > > headers, but that alone is not itself cause to say that other entities > > can never be provided with the keys (subject to the security > > considerations of group-shared PSKs, of course). Furthermore, if a > > particular SFF is trusted, it may have grounds to verify the integrity > > tag even if it is administratively prohibited from writing such a tag. > > > > In both levels of assurance, the unencrypted Context Headers and the > > packet on which the NSH is imposed are subject to integrity > > protection. > > > > Surely any encrypted Context Headers are also given integrity > > protection, as excluding them from the MAC computation would be quite > > complex. I see that the encrypted context headers are not part of the > > AAD input, but in the AEAD model the ciphertext is still given integrity > > protection! > > > > Section 4.2 > > > > The authenticated encryption algorithm defined in [RFC7518] is used > > to provide NSH data integrity and to encrypt the Context Headers that > > carry privacy-sensitive metadata. > > > > RFC 7518 (JSON Web Algorithms) is a very surprising reference for > > generic AEAD encryption. Continuing on, it becomes clear that we in > > fact do not want a generic AEAD operation here, but instead have need > > for separation of encryption and integrity protection due to the various > > separations of roles that are possible. Because this is a divergence > > from current best practices (use of native AEAD cipher modes like GCM, > > SIV, etc.), I might suggest a rather different introductory material: > > > > % The AEAD interface specified in RFC 5116 is a very powerful tool for > > % providing strong confidentiality and integrity protection for protocol > > % messages, and has become quite widely adopted as a result. For > > % protecting NSH data we adhere to the spirit of the AEAD interface but > > % use a slightly modified version in order to remain consistent with the > > % privilege separation needed (e.g., in the second level of assurance, > > % SFFs need to be able to update the message integrity tag but do not > > % need access to the decrypted plaintext). Accordingly, a compound AEAD > > % mechanism combining CBC encryption and HMAC integrity tag is used, so > > % that distribution of the encryption key can be limited. Rather than > > % define a new scheme from scratch, the AES_CBC_HMAC_SHA2 scheme from > > % [RFC7518] is used. In order to simplify key distribution, a single > > % secret key material seed K is used, which can be kept private > > % centrally or distributed to all parties that will have access to > > % decrypted plaintext, and the secondary keys MAC_KEY and ENC_KEY are > > % derived from K as discussed in Section 5.2.2.1 of [RFC7518]. Entities > > % that need to update the integrity tag but are not authorized to see > > % the decrypted plaintext will only receive MAC_KEY and not K or > > % ENC_KEY. > > > > o If the Context Headers are not encrypted, the Hashed Message > > Authentication Mode (HMAC) algorithm discussed in [RFC4868] is > > used to protect the integrity of the NSH data. > > > > It's not clear to me that this is adding much value; HMAC is used > > whether or not there are encrypted headers, and the RFC 4868 reference > > is rather odd (see also my Discuss point (2)). > > > > The advantage of using the authenticated encryption algorithm is that > > NSH-aware SFs and SFC proxies only need to re-compute the message > > integrity of the NSH data after decrementing the Service Index (SI) > > and do not have to re-compute the ciphertext. The other advantage is > > that SFFs do not have access to the ENC_KEY and cannot act on the > > encrypted Context Headers and, only in case of the second level of > > assurance, SFFs do have access to the MAC_KEY. Similarly, an NSH- > > aware SF or SFC Proxy not allowed to decrypt the Context Headers will > > not have access to the ENC_KEY. > > > > [If my above suggestion is used, this text has probably become mostly > > redundant and could be trimmed down or removed.] > > > > The authenticated encryption process takes as input four-octet > > strings: a secret key (K), a plaintext (P), Additional Authenticated > > Data (A) (which contains the data to be authenticated, but not > > encrypted), and an Initialization Vector (IV). The ciphertext value > > (E) and the Authentication Tag value (T) are provided as outputs. > > > > In order to decrypt and verify, the cipher takes as input K, IV, A, > > T, and E. The output is either the plaintext or an error indicating > > that the decryption failed as described in Section 5.2.2.2 of > > [RFC7518]. > > > > This seems true for the abstract AEAD interface, but since we're peeling > > off the HMAC integrity tag for standalone use, we may need to say > > something about what inputs/outputs are needed for just using the > > integrity tag without doing decryption. In particular, we cannot use K > > as an input for standalone HMAC verification! > > > > Also, this is just the generic AEAD interface, so RFC 5116 is probably a > > more apropos reference than RFC 7518. > > > > Section 4.3 > > > > Note: The use of Advanced Encryption Standard (AES) in Galois/ > > Counter Mode (GCM) + HMAC may have CPU and packet size > > implications (need for a second 128-bit authentication tag). > > > > [This might also be redundant if my earlier proposal is accepted.] > > > > Section 4.4 > > > > The document does not assume nor preclude the following: > > > > o The same keying material is used for all the service functions > > used within an SFC-enabled domain. > > > > o Distinct keying material is used per SFP by all involved SFC data > > path elements. > > > > o Per-tenant keys are used. > > > > I suggest a forward reference to the security considerations with a > > brief note that the risk involved in using a group-shared symmetric key > > increases with the size of the group to which it is shared. > > > > In order to accommodate deployments relying upon keying material per > > SFC/SFP and also the need to update keys after encrypting NSH data > > for a certain amount of time, this document uses key identifiers to > > unambiguously identify the appropriate keying material. Doing so > > allows to address the problem of synchronization of keying material. > > > > I'd suggest making a statement about the scope in which key identifiers > > need to be unique. > > > > Section 4.5 > > > > An NSH-aware SF or SFC Proxy that needs to decrypt some Context > > Headers uses ENC_Key and the decryption algorithm for the key > > identifier being carried in the NSH. > > > > I think we need to say that decryption MUST NOT proceed unless the > > integrity tag has been successfully validated. To decrypt without > > checking the integrity tag violates the AEAD interface. Alternately, we > > could only ever describe decryption as the AEAD operation that uses K as > > input (not just ENC_KEY) -- §7.6 seems to attempt to take this latter > > approach, but the document as a whole is not consistent about it. > > > > Section 5, 5.x > > > > I strongly suggest changing "Key Length" to "keyid length", since there > > is already convention on "key length" (e.g., for AES-128 vs AES-192 vs > > AES-256). > > > > Section 5.1 > > > > Key Identifier: Carries a variable-length Key Identifier object used > > to identify and deliver keys to SFC data plane elements. This > > identifier is helpful to accommodate deployments relying upon > > keying material per SFC/SFP. The key identifier helps in > > resolving the problem of synchronization of keying material. > > > > I suggest clarifying that a single key identifier is used to lookup both > > the associated ENC_KEY and the associated MAC_KEY (or, alternately, that > > it is logically bound to K and remind the reader that ENC_KEY and > > MAC_KEY are extracted from K and might be separately distributed). > > > > Key Length: Variable. Carries the length of the key identifier. > > [...] > > IV Length: Carries the length of the IV (Section 5.2 of [RFC7518]). > > If encryption is not used, IV length is set to zero (that is, no > > "Initialization Vector" is included). > > > > Please also specify that the Key/IV lengths are measured in bytes (the > > reference for IV length, at least, talks about IVs in bits). > > > > I strongly suggest using a value other than zero as the sentinel value > > for "no encryption" -- there already exist modes like AES-SIV (RFC 5297) > > that do not require an IV input, which would be a natural use for > > zero-length IV. > > > > Additionally, one might imagine using a non-zero-length IV as input to > > an HMAC calculation as a per-message nonce. On cursory examination, > > since we are already using timestamp-based replay detection, the > > additional nonce is unlikely to add much value, but I'm not willing to > > completely rule it out on the basis of the minimal analysis I performed. > > > > Section 7.1 > > > > Only one instance of "MAC and Encrypted Metadata" Context Header > > (Section 5) is allowed. If multiple instances of "MAC and Encrypted > > Metadata" Context Header are included in an NSH packet, the SFC data > > > > I think Roman may have mentioned this already, but please clarify if > > this is one instance per NSH or per packet (e.g., in hierarchical SFC we > > might have more than one NSH in a packet). > > > > Please also clarify it if is permitted to have both MAC#1 and MAC#2 > > present in the same packet. (IIUC there are not obvious situations > > where such a setup would be useful, but it's still good to be clear > > about expectations.) > > > > Section 7.2 > > > > If the Context Headers are not encrypted, the HMAC algorithm > > discussed in [RFC4868] is used to integrity protect the target NSH > > data. [...] > > > > It's not really clear to me why RFC 4868 is the right reference here, as > > opposed to (e.g.) RFC 2104. In particular, see my Discuss point (2). > > > > The Message Authentication Code (T) computation process can be > > illustrated as follows: > > > > T = HMAC-SHA-256-128(MAC_KEY, A) > > > > I agree with the other reviewer that wondered about just using "MAC" (or > > maybe "HMAC") rather than "HMAC-SHA-256-128" here (I do see the "can be > > illustrated as" qualifier). > > > > It's also a little weird to reuse T and A from the AEAD construction (or > > RFC 4868) here without additional discussion on how they apply and how > > the value of A is constructed. > > > > An entity in the SFP that intends to update the NSH MUST follow the > > above behavior to maintain message integrity of the NSH for > > subsequent validations. > > > > I'm not sure that "intends to" is needed; the requirement applies to > > actions, not intent. > > > > Section 7.3 > > > > In an SFC-enabled domain where pervasive monitoring [RFC7258] is > > possible, all Context Headers carrying privacy-sensitive metadata > > MUST be encrypted; [...] > > > > I agree with the other reviewer that noted that this seems to > > effectively be an unqualified "MUST", since there is always some > > possibility of monitoring. > > > > MAC_KEY = initial MAC_KEY_LEN octets of K, > > ENC_KEY = final ENC_KEY_LEN octets of K, > > E = CBC-PKCS7-ENC(ENC_KEY, P), > > M = MAC(MAC_KEY, A || IV || E || AL), > > T = initial T_LEN octets of M. > > MAC and Encrypted Metadata = E || T > > > > I recognize that this is just copy+paste from RFC 7518 (with the > > addition of the last line), but it seems a glaring omission that the > > CBC-PKCS7-ENC() invocation does not include the IV as an input! > > (In §5.2.2.1 of RFC 7518 we do see that "The plaintext is CBC encrypted > > using PKCS #7 padding using ENC_KEY as the key and the IV", so it's just > > the figure/formula that omits the IV.) > > > > We also don't define or mention T_LEN in this document other than in > > this formula and the analogous one for MAC-without-encryption, which > > might be worth remedying. > > > > Section 7.4 > > > > I suggest adding another word (like "Prevention") to the section title. > > > > The received NSH is accepted by an NSH-aware node if the Timestamp > > (TS) in the NSH is recent enough to the reception time of the NSH > > (TSrt). The following formula is used for this check: > > > > -Delta < (TSrt - TS) < +Delta > > > > (There's no real reason why the accepted timestamp skew parameter Delta > > needs to be symmetric in the positive and negative directions.) > > > > Replay attacks within the Delta window may be detected by an NSH- > > aware node by recording a unique value derived, for example, from the > > NSH data and Original packet (e.g., using SHA2). [...] > > > > Note that the unique value MUST NOT use as input any bits that are not > > covered by the MAC. Indeed, just using the MAC itself as the unique > > value would be a fairly straightforward scheme, I think. > > > > Section 7.5 > > > > When an SFC data plane element receives an NSH packet, it MUST first > > ensure that a "MAC and Encrypted Metadata" Context Header is > > included. [...] > > > > This sort of requirement (as written) would seem to support the position > > of some other reviewers that this document would need to formally update > > RFC 8300. > > > > Section 9 > > > > We might discuss that this mechanism is only for metadata type 2 and not > > type 1 (as well as that with the relatively small fixed length of type 1 > > metadata, it's quite challenging to provide useful cryptographic > > protection), so that type-1 metadata still has no generic protection > > mechanism. A given metadata element could define its own protection > > scheme, of course. > > > > The attacks discussed in [I-D.nguyen-sfc-security-architecture] are > > handled owing to the solution specified in this document, except for > > attacks dropping packets. [...] > > > > >From a very quick read, draft-nguyen-sfc-security-architecture proposes > > a probe-based scheme that monitors all middleboxes (or at least those in > > the expected path) to detect a middlebox-bypass attack and verify that > > the probe traversed the expected SFP. I am not sure that this document > > on its own suffices to prevent the middlebox-bypass attack for all > > traffic (i.e., the probe-based scheme might still be needed). If some > > network entities know what the expected service index will be for a > > given SPI at a given node, then middlebox-bypass attacks could be > > natively detected, but my understanding was that such advance knowledge > > of expected service index was not going to be available. > > > > The solution specified in this document does not provide data origin > > authentication. > > > > I would have expected more in-depth discussion of the security > > considerations for a group-shared PSK scheme, including how the risk of > > key loss/compromise goes up when the key is distributed to more > > locations. > > > > Section 9.1 > > > > No device other than the NSH-aware SFs in the SFC-enabled domain > > should be able to update the integrity protected NSH data. > > > > What about classifiers and SFC proxies? > > > > Section 9.2 > > > > I expected to see some remarks here analogous to the second paragraph of > > §9.1 (even if just by reference to that section). > > > > Section 9.3 > > > > Section 5.6 of [RFC8633] describes best current practices to be > > considered in deployments where SFC data plane elements use NTP for > > time synchronization purposes. > > > > The referenced section covers NTP symmetric mode only. Is client/server > > mode not a BCP for trusted networks and broadcast/symmetric the only > > options? > > > > NITS > > > > Section 1 > > > > network infrastructures against them, network slicing, etc. Because > > of the proliferation of such advanced SFs together with complex > > service deployment constraints that demand more agile service > > delivery procedures, operators need to rationalize their service > > delivery logics and master their complexity while optimising service > > activation time cycles. The overall problem space is described in > > [RFC7498]. > > > > The "their" in "master their complexity" is a bit ambiguous between > > "operators" and "service delivery logics" (noting that the previous use > > of "their" did refer to "operators"). (The sentence as a whole reads a > > bit like marketing language, but that's not intended to be an actionable > > comment.) > > > > This specification fills that gap. Concretely, this document adds > > integrity protection and optional encryption of sensitive metadata > > directly to the NSH (Section 4); integrity protects the packet > > payload and provides replay protection (Section 7.4). [...] > > > > The clause after the semicolon needs to be able to stand alone as a > > complete sentence in order to be grammatical, but it currently has no > > subject. Maybe prefixing "it also" would be enough to fix it. > > > > Section 4.1.2 > > > > The integrity protection scope is explicitly signaled to NSH-aware > > SFs and SFC proxies in the NSH by means of a dedicated MD Type > > (Section 5). > > > > Signaled to SFFs as well, since in the second LoA they can use it. > > > > Section 4.6 > > > > As discussed in [RFC8459], an SFC-enabled domain (called, upper-level > > domain) may be decomposed into many sub-domains (called, lower-level > > domains). In order to avoid maintaining state to restore back upper- > > lower NSH information at the boundaries of lower-level domains, two > > > > I think s/upper-lower/upper-layer/ (across the line break)? > > > > Section 5.1 > > > > MAC#1 Context Header is a variable-length Context Header that carries > > the Message Authentication Code (MAC) for the Service Path Header, > > Context Headers, and the inner packet on which NSH is imposed, > > calculated using MAC_KEY and optionally Context Headers encrypted > > using ENC_KEY. [...] > > > > Comma after "calculated using MAC_KEY", please. ("optionally Context > > Headers [...]" are not used along with MAC_KEY in the calculation) > > > > Section 5.2 > > > > Message Authentication Code: Coves the entire NSH data. The > > > > s/Coves/Covers/ > > > > Section 6 > > > > The epoch is 1970-01-01T00:00Z in UTC time. [...] > > > > (IIUC, the "in UTC time" is redundant with the trailing 'Z'.) > > > > Section 7.1 > > > > element. The details of sending notification alarms (i.e., the > > parameters affecting the transmission of the notification alarms > > depend on the information in the context header such as frequency, > > thresholds, and content in the alarm) SHOULD be configurable. > > > > The grammar in the parenthetical seems off to me. Possibly > > s/depend/depending/ would be a fix, but I'm not sure. > > > > NSH-aware SFs and SFC proxies MUST re-apply the integrity protection > > if any modification is made to the Context Headers (strip a Context > > Header, update the content of an existing Context Header, insert a > > new Context Header). > > > > I think maybe an "e.g.," in the parenthetical is in order, since this > > doesn't seem to include things like "decrement the TTL". > > > > Section 9 > > > > The interaction between the SFC data plane elements and a key > > management system MUST NOT be transmitted in clear since this would > > completely destroy the security benefits of the integrity protection > > solution defined in this document. The secret key (K) must have an > > expiration time assigned as the latest point in time before which the > > > > This first sentence seems like it could probably be a paragraph of its > > own; the subsequent discussion of expiration time seems to be mostly > > unrelated. > > > > We might also add another sentence to reiterate that "the security and > > integrity of the key-distribution mechanism is vital to the security of > > the system as a whole". > > > > o Attacker replacing the packet on which the NSH is imposed with a > > bogus packet. > > > > I'd probably say "modified or bogus". > > > > In an SFC-enabled domain where the above attacks are possible, (1) > > > > This is perhaps ambiguous about whether an "any" or "all" criterion > > should be used. Perhaps that's desired :) > > > > > > > > From nobody Thu Jul 22 03:28:35 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079B03A4135; Thu, 22 Jul 2021 03:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvDPhPvKdbsK; Thu, 22 Jul 2021 03:28:26 -0700 (PDT) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 1B5333A4132; Thu, 22 Jul 2021 03:28:23 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id a12so7720725lfb.7; Thu, 22 Jul 2021 03:28:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Neh2/AZxWgolfpgvMaXq7DXnwD2ThrjsmRmMdUPXOUc=; b=ntf+ablrRO7g4Lp3E6tZZH+5bPqMGdadnllCKzOmVQq6s4T/J3iNYuvTzhTRPJDThv R0juK0vP07HHrr3x6dPCdovcSohb1+oNja4ID+e9ae0w+dofJfc041trv9Mx0EZgJko9 6U9jQdMsHLPmT5En8jBGtcvD2gQgMNxMIJYriHK6ELhgCduE+8EAjThPeRU2JrYCfI8L 83DVCQCSQDJfVKPNMbNg/6COYQLOAQlkObWb41dlUdXdiRbLzWUU2WAq2a6rPScCLoIe YKq0rTjEqGWWESOSliFMuZ/hxvV//512V7P3H8syIb/U++I0CnYlIjVqkPzhOGXFum18 ki4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Neh2/AZxWgolfpgvMaXq7DXnwD2ThrjsmRmMdUPXOUc=; b=OMcZsnOLI/83XdDeU1mz3kvJqpJ1EBlxC6GhLlzbkMq2Ak4JlOgcMH2hS4q92D+3rt 9Y2aoo2R4IenTz7Y7ifauiRM4RXK0x00iUtOMSAibzyT080VVhICYsOz8ViFMBnsA1kx qDSaiJkaz7lxaK97KPIGj8G+HrTxkrK5g9kklYie/c9I7lQC/zUGzlb3EQAmdSDjHVZM BFqoXreBh6l4iiyRyVg/8Y+5CamuQnsQ9mifNBM92/NoGafCKiz7AfDct6kIoD+vqSfK G049srHhG8AIOSMbxEvWbydCiOkwWzmk6fXnTzOHuHpLVIj18QOQPt8ReXzCNYDRv7aQ +gqg== X-Gm-Message-State: AOAM532xCGj/QWsNxh+Zocsvb4hqOzYpLAomidfhmu4Icxxm0UygEn3x r+SCCvAU4Dbiq2dl3BP7jgZjcLBQDQHBrjGff+c= X-Google-Smtp-Source: ABdhPJxDOt1oJQUQ/GdEthO7SR86m+ozJDchz5s5xpe9hYfbJ9dAgGggv/Yz/k1fAPJTwtvLxdl55YFwidZ71pastx8= X-Received: by 2002:a05:6512:c15:: with SMTP id z21mr29288124lfu.614.1626949701571; Thu, 22 Jul 2021 03:28:21 -0700 (PDT) MIME-Version: 1.0 References: <162629795136.25767.17850752260179612361@ietfa.amsl.com> <20210721224649.GR88594@kduck.mit.edu> In-Reply-To: <20210721224649.GR88594@kduck.mit.edu> From: tirumal reddy Date: Thu, 22 Jul 2021 15:58:10 +0530 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-sfc-nsh-integrity@ietf.org, sfc-chairs@ietf.org, sfc@ietf.org, gregimirsky@gmail.com Content-Type: multipart/alternative; boundary="00000000000007977405c7b3bf2d" Archived-At: Subject: Re: [sfc] Benjamin Kaduk's Discuss on draft-ietf-sfc-nsh-integrity-06: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2021 10:28:33 -0000 --00000000000007977405c7b3bf2d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ben, Please see inline On Thu, 22 Jul 2021 at 04:16, Benjamin Kaduk wrote: > Hi Tiru, > > Also inline... > > On Mon, Jul 19, 2021 at 01:20:11PM +0530, tirumal reddy wrote: > > Hi Ben, > > > > Please see inline > > > > On Thu, 15 Jul 2021 at 02:55, Benjamin Kaduk via Datatracker < > > noreply@ietf.org> wrote: > > > > > Benjamin Kaduk has entered the following ballot position for > > > draft-ietf-sfc-nsh-integrity-06: Discuss > > > > > > When responding, please keep the subject line intact and reply to all > > > email addresses included in the To and CC lines. (Feel free to cut th= is > > > introductory paragraph, however.) > > > > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > for more information about DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/ > > > > > > > > > > > > ---------------------------------------------------------------------= - > > > DISCUSS: > > > ---------------------------------------------------------------------= - > > > > > > (0) (I came to this realization rather late in my review process, so > > > there may be places where the COMMENT and this discuss point are in > > > disagreement; this DISCUS takes precedence.) > > > I fear that the construction that separately distributes ENC_KEY and > > > MAC_KEY in an attempt to achieve privilege separation is fatally > flawed. > > > In particular, the CBC encryption mode is a malleable encryption mode= , > > > in that flipping a bit of ciphertext will filp the corresponding bit = of > > > the next block of recovered plaintext (at the cost of completely > > > garbling the recovered block containing the bit that was modified). > > > Subsequent blocks are unaffected. Typically we combine CBC mode with= a > > > MAC such as HMAC in order to prevent such modifications from being > > > exposed as attack vectors, and while we do use HMAC here for that > > > purpose, we also introduce a separate class of actors that have acces= s > > > to the HMAC key but not the encryption key. Accordingly, those actor= s > > > can produce a new, valid, integrity tag after making a modification t= o > > > the ciphertext, allowing them to engage in attacks that make use of > > > ciphertext malleability. Ciphertext malleability is particularly > useful > > > as an attack vector when the structure of the plaintext being encrypt= ed > > > is known, and there are portions of the plaintext that the applicatio= n > > > will either ignore if they are garbled or are expected to be near > random > > > in the normal case (and thus for which garbled output does not cause > > > rejection by the application). In a SFC environment it seems highly > > > likely that the structure of the plaintext will be known or guessable= , > > > and we don't have any real mechanisms to control what types of metada= ta > > > go into encrypted context headers, so it seems that we must act as if > we > > > are exposed to this risk. > > > > > > While =C2=A74.3 does have a note that use of GCM with HMAC is undesir= able > due > > > to the additional authentication tag, it may be unavoidable in order = to > > > provide the properties that we need. > > > > > > > Thanks for explaining the attack. We will modify the text in Section 4.= 3 > as > > follows to address the comment: > > > > Classifiers, NSH-aware SFs, and SFC proxies MUST implement the > > AES_128_GCM [GCM][RFC5116] algorithm and SHOULD implement the > > AES_192_GCM and AES_256_GCM algorithms. > > > > Classifiers, NSH-aware SFs, and SFC proxies MUST implement the HMAC- > > SHA-256-128 algorithm and SHOULD implement the HMAC-SHA-384-192 and > > HMAC-SHA-512-256 algorithms. > > > > SFFs MAY implement the aforementioned cipher suites and HMAC > > algorithms. > > > > Note: > > The use of AES_128_CBC_HMAC_SHA_256 algorithm would have avoided the ne= ed > > for a second 128-bit authentication tag but due to the nature of how CB= C > > mode operates, the mode allows for malleability of plaintexts. This > > malleability allows for attackers to make changes in the ciphertext and= , > if > > parts of the plaintext are known, create arbitrary blocks of > > plaintext. This specification mandates the use of AES-GCM to prevent th= is > > type of attack. > > This seems okay on first read, thanks. I will probably end up reading it > again once the revised I-D is posted, in the full context of the draft. > Sure, we will publish the revised draft next week. > > > > > > > > > (1) Section 5.1 describes the MAC as: > > > > > > Message Authentication Code: Covers the entire NSH data, excludi= ng > > > the Base header. The Additional Authenticated Data (defined in > > > [RFC7518]) MUST be the Service Path header, the unencrypted > > > Context headers, and the inner packet on which the NSH is > imposed. > > > > > > This description seems to exclude from the MAC most of the MAC contex= t > > > header itself (if we go by the corresponding figure), which is very b= ad > > > for security. We definitely need to include under the MAC the MAC > > > context header bits from metadata class through and including at leas= t > > > timestamp, and I think IV length as well. (The IV itself would be > > > incorporated via the ciphertext, since the IV is an input to > encryption, > > > but since the IV length field indicates whether or not encryption was > > > performed, we'd need to protect that information.) > > > > > > > No, the MAC context header is also used for generating the digest. > > Ok. > > > > > > > > > Similarly, Section 5.2 has the description: > > > > > > Message Authentication Code: Coves the entire NSH data. The > > > Additional Authenticated Data (defined in [RFC7518]) MUST be th= e > > > entire NSH data (i.e., including the Base Header) excluding the > > > Context Headers to be encrypted. > > > > > > which on the face of it includes the field that holds the MAC itself > > > (and is not yet populated), i.e., is self-referential. > > > > > > > The below update will address this comment: > > > > The NSH imposer sets the MAC field to zero and then computes the messag= e > > integrity for the target NSH data (depending on the integrity protectio= n > > scope discussed in Section 5) using MAC_KEY and HMAC algorithm. It > inserts > > the computed digest in the MAC field in the "MAC and Encrypted Metadata= " > > Context Header. > > > > Thanks! (I think Roman may have goten this before me, so sorry for the > duplication.) > > > > > > > > > I think we need to be much more precise about the construction of the > > > AAD in both cases. It's possible that the HMAC construction for the > > > no-encrypted-context-headers case can inherit a definition from the A= AD > > > description, but if not we'll need to have some more precision there = as > > > well. > > > > > > (2) In order for the MAC-only construction in =C2=A77.2 to be compati= ble > with > > > the AEAD integrity tag construction, we would need to include the > 64-bit > > > AL after A. While HMAC is intrinsically immune to length-extension > > > attacks, I think that having the explicit AL is useful to avoid any > risk > > > of malleability, since the same MAC_KEY is used for constructing both > > > types of MACs. > > > > > > > I don't think this comment is applicable after AES_128_CBC_HMAC_SHA_256 > is > > removed. > > I think so, yes. > > > > > > > > > (3) Section 5.1 describes the Timestamp field as an "unsigned 64-bit > > > integer value", which is inconsistent with the actual format given in > > > Section 6. > > > > > > > Thanks, we will fix it in the next revision. > > > > > > > > > > (4) Section 7.5 directs the verifier to check if "the value of the > newly > > > generated digest is identical to the one enclosed in the NSH". It is > > > critical for the security of the system that this comparison be done = in > > > a constant-time manner that does not provide a side channel into > whether > > > the generated digest and the value in the NSH share a common substrin= g. > > > > > > > Agreed, will update text as follows: > > > > After storing the value of the MAC field in the "MAC and Encrypted > > Metadata" Context Header, the SFC data plane element fills the MAC > > field with zeros. Then, the SFC data plane element generates the messa= ge > > integrity > > for the target NSH data (depending on the integrity protection scope > > discussed in Section 5) using MAC_KEY and HMAC algorithm. If the value > of > > the newly generated digest is identical to the stored one, the SFC data > > plane element is certain that the NSH data has not been tampered and > > validation is therefore successful. Otherwise, the NSH packet MUST be > > discarded. The comparison of the computed HMAC value to the store value > MUST > > be done in a constant-time manner to thwart timing attacks. > > Thanks! > > > > > > > > > (5) Do the MAC context headers always have to be the last metadata > > > entries in the packet (to simplify the cryptographic calculations)? > > > > > > > Yes. > > > > Okay. I suspected that, but it is probably worth a MUST-level requiremen= t > in the document to make it clear to everyone. > Done, will add a line. Cheers, -Tiru > > Thanks again, > > Ben > > > > > > Certainly the diagrams only show "unencrypted context headers" > appearing > > > prior to the MAC context header, so if we expect unencrypted context > > > headers to appear after the MAC context header as well, we should be > > > clear about that both in the figures and in the specification for how > to > > > prepare the AAD. > > > > > > > > > ---------------------------------------------------------------------= - > > > COMMENT: > > > ---------------------------------------------------------------------= - > > > > > > Section 3 > > > > > > o Both encrypted and unencrypted Context Headers MAY be included = in > > > the same NSH. That is, some Context Headers may be protected > > > while others do not need to be protected. > > > > > > In the security area we're pretty strongly moved towards a stance of > > > "encrypt everything that doesn't have a strong need to be plaintext > > > (since we don't want to assume that we can predict all threats and > > > attacks in advance), and QUIC has even taken that to new levels. It'= s > > > quite surprising to see "don't need to be protected" as a justificati= on > > > for lack of encryption, rather than "need to be unprotected". Given > > > that we're going to be solving key distribution for integrity > protection > > > anyway, it remains unclear to me why we wouldn't just encrypt > > > everything. > > > > > > Section 4.1.1 > > > > > > Is the column heading for the middle column of Table 1 referring to t= he > > > Base Header and "Service Path Header"? I'm not sure how to interpret > > > just "Service Header" other than the entire NSH, which doesn't seem > > > right... > > > > > > The Service Path Header (Section 2 of [RFC8300]) is not encrypted > > > because SFFs use Service Index (SI) in conjunction with Service Pa= th > > > Identifier (SPI) for determining the next SF in the path. > > > > > > It's good to see this spelled out like this; I'd love to have this ki= nd > > > of explanation for every un-encrypted protocol element. > > > > > > Section 4.1.2 > > > > > > The solution provides integrity protection for the NSH data. Two > > > levels of assurance (LoAs) are supported. > > > > > > I see (reading onward) that the two LoAs just differ in what is cover= ed > > > by the integrity tag, but each involve only a single MAC. There's a > > > reasonable argument that when there are overlapping needs for what da= ta > > > needs protecting and who needs access to it, that multiple MACs (or > > > encryption, if needed) are most appropriate, which can be tailored to > > > the respective needs. This is something that Phillip Hallam-Baker ha= s > > > ascribed as the "short-blanket theory" of cryptography, in that it's > > > like a blanket that's too short to cover everything you want, so you > > > need to have more than one and put them in partially overlapping > layers. > > > Perhaps this "short-blanket theory" is more applicable to Discuss poi= nt > > > (0) than what is covered by the MAC, though... > > > > > > The first level of assurance where all NSH data except the Base > > > Header are integrity protected (Figure 2). In this case, the NSH > > > imposer may be a Classifier, an NSH-aware SF, or an SFC Proxy. SF= Fs > > > are not thus provided with authentication material. [...] > > > > > > There seems to be a gap in the chain of reasoning as to why SFFs are > not > > > provided with authentication material. It seems that the intent is > > > something along the lines of considering which entities need access t= o > > > the key material in order to successfully add an NSH or update contex= t > > > headers, but that alone is not itself cause to say that other entitie= s > > > can never be provided with the keys (subject to the security > > > considerations of group-shared PSKs, of course). Furthermore, if a > > > particular SFF is trusted, it may have grounds to verify the integrit= y > > > tag even if it is administratively prohibited from writing such a tag= . > > > > > > In both levels of assurance, the unencrypted Context Headers and t= he > > > packet on which the NSH is imposed are subject to integrity > > > protection. > > > > > > Surely any encrypted Context Headers are also given integrity > > > protection, as excluding them from the MAC computation would be quite > > > complex. I see that the encrypted context headers are not part of th= e > > > AAD input, but in the AEAD model the ciphertext is still given > integrity > > > protection! > > > > > > Section 4.2 > > > > > > The authenticated encryption algorithm defined in [RFC7518] is use= d > > > to provide NSH data integrity and to encrypt the Context Headers > that > > > carry privacy-sensitive metadata. > > > > > > RFC 7518 (JSON Web Algorithms) is a very surprising reference for > > > generic AEAD encryption. Continuing on, it becomes clear that we in > > > fact do not want a generic AEAD operation here, but instead have need > > > for separation of encryption and integrity protection due to the > various > > > separations of roles that are possible. Because this is a divergence > > > from current best practices (use of native AEAD cipher modes like GCM= , > > > SIV, etc.), I might suggest a rather different introductory material: > > > > > > % The AEAD interface specified in RFC 5116 is a very powerful tool fo= r > > > % providing strong confidentiality and integrity protection for > protocol > > > % messages, and has become quite widely adopted as a result. For > > > % protecting NSH data we adhere to the spirit of the AEAD interface b= ut > > > % use a slightly modified version in order to remain consistent with > the > > > % privilege separation needed (e.g., in the second level of assurance= , > > > % SFFs need to be able to update the message integrity tag but do not > > > % need access to the decrypted plaintext). Accordingly, a compound > AEAD > > > % mechanism combining CBC encryption and HMAC integrity tag is used, = so > > > % that distribution of the encryption key can be limited. Rather tha= n > > > % define a new scheme from scratch, the AES_CBC_HMAC_SHA2 scheme from > > > % [RFC7518] is used. In order to simplify key distribution, a single > > > % secret key material seed K is used, which can be kept private > > > % centrally or distributed to all parties that will have access to > > > % decrypted plaintext, and the secondary keys MAC_KEY and ENC_KEY are > > > % derived from K as discussed in Section 5.2.2.1 of [RFC7518]. > Entities > > > % that need to update the integrity tag but are not authorized to see > > > % the decrypted plaintext will only receive MAC_KEY and not K or > > > % ENC_KEY. > > > > > > o If the Context Headers are not encrypted, the Hashed Message > > > Authentication Mode (HMAC) algorithm discussed in [RFC4868] is > > > used to protect the integrity of the NSH data. > > > > > > It's not clear to me that this is adding much value; HMAC is used > > > whether or not there are encrypted headers, and the RFC 4868 referenc= e > > > is rather odd (see also my Discuss point (2)). > > > > > > The advantage of using the authenticated encryption algorithm is > that > > > NSH-aware SFs and SFC proxies only need to re-compute the message > > > integrity of the NSH data after decrementing the Service Index (SI= ) > > > and do not have to re-compute the ciphertext. The other advantage > is > > > that SFFs do not have access to the ENC_KEY and cannot act on the > > > encrypted Context Headers and, only in case of the second level of > > > assurance, SFFs do have access to the MAC_KEY. Similarly, an NSH- > > > aware SF or SFC Proxy not allowed to decrypt the Context Headers > will > > > not have access to the ENC_KEY. > > > > > > [If my above suggestion is used, this text has probably become mostly > > > redundant and could be trimmed down or removed.] > > > > > > The authenticated encryption process takes as input four-octet > > > strings: a secret key (K), a plaintext (P), Additional Authenticat= ed > > > Data (A) (which contains the data to be authenticated, but not > > > encrypted), and an Initialization Vector (IV). The ciphertext val= ue > > > (E) and the Authentication Tag value (T) are provided as outputs. > > > > > > In order to decrypt and verify, the cipher takes as input K, IV, A= , > > > T, and E. The output is either the plaintext or an error indicati= ng > > > that the decryption failed as described in Section 5.2.2.2 of > > > [RFC7518]. > > > > > > This seems true for the abstract AEAD interface, but since we're > peeling > > > off the HMAC integrity tag for standalone use, we may need to say > > > something about what inputs/outputs are needed for just using the > > > integrity tag without doing decryption. In particular, we cannot use= K > > > as an input for standalone HMAC verification! > > > > > > Also, this is just the generic AEAD interface, so RFC 5116 is probabl= y > a > > > more apropos reference than RFC 7518. > > > > > > Section 4.3 > > > > > > Note: The use of Advanced Encryption Standard (AES) in Galois/ > > > Counter Mode (GCM) + HMAC may have CPU and packet size > > > implications (need for a second 128-bit authentication tag). > > > > > > [This might also be redundant if my earlier proposal is accepted.] > > > > > > Section 4.4 > > > > > > The document does not assume nor preclude the following: > > > > > > o The same keying material is used for all the service functions > > > used within an SFC-enabled domain. > > > > > > o Distinct keying material is used per SFP by all involved SFC da= ta > > > path elements. > > > > > > o Per-tenant keys are used. > > > > > > I suggest a forward reference to the security considerations with a > > > brief note that the risk involved in using a group-shared symmetric k= ey > > > increases with the size of the group to which it is shared. > > > > > > In order to accommodate deployments relying upon keying material p= er > > > SFC/SFP and also the need to update keys after encrypting NSH data > > > for a certain amount of time, this document uses key identifiers t= o > > > unambiguously identify the appropriate keying material. Doing so > > > allows to address the problem of synchronization of keying materia= l. > > > > > > I'd suggest making a statement about the scope in which key identifie= rs > > > need to be unique. > > > > > > Section 4.5 > > > > > > An NSH-aware SF or SFC Proxy that needs to decrypt some Context > > > Headers uses ENC_Key and the decryption algorithm for the key > > > identifier being carried in the NSH. > > > > > > I think we need to say that decryption MUST NOT proceed unless the > > > integrity tag has been successfully validated. To decrypt without > > > checking the integrity tag violates the AEAD interface. Alternately, > we > > > could only ever describe decryption as the AEAD operation that uses K > as > > > input (not just ENC_KEY) -- =C2=A77.6 seems to attempt to take this l= atter > > > approach, but the document as a whole is not consistent about it. > > > > > > Section 5, 5.x > > > > > > I strongly suggest changing "Key Length" to "keyid length", since the= re > > > is already convention on "key length" (e.g., for AES-128 vs AES-192 v= s > > > AES-256). > > > > > > Section 5.1 > > > > > > Key Identifier: Carries a variable-length Key Identifier object > used > > > to identify and deliver keys to SFC data plane elements. This > > > identifier is helpful to accommodate deployments relying upon > > > keying material per SFC/SFP. The key identifier helps in > > > resolving the problem of synchronization of keying material. > > > > > > I suggest clarifying that a single key identifier is used to lookup > both > > > the associated ENC_KEY and the associated MAC_KEY (or, alternately, > that > > > it is logically bound to K and remind the reader that ENC_KEY and > > > MAC_KEY are extracted from K and might be separately distributed). > > > > > > Key Length: Variable. Carries the length of the key identifier. > > > [...] > > > IV Length: Carries the length of the IV (Section 5.2 of [RFC7518]= ). > > > If encryption is not used, IV length is set to zero (that is, n= o > > > "Initialization Vector" is included). > > > > > > Please also specify that the Key/IV lengths are measured in bytes (th= e > > > reference for IV length, at least, talks about IVs in bits). > > > > > > I strongly suggest using a value other than zero as the sentinel valu= e > > > for "no encryption" -- there already exist modes like AES-SIV (RFC > 5297) > > > that do not require an IV input, which would be a natural use for > > > zero-length IV. > > > > > > Additionally, one might imagine using a non-zero-length IV as input t= o > > > an HMAC calculation as a per-message nonce. On cursory examination, > > > since we are already using timestamp-based replay detection, the > > > additional nonce is unlikely to add much value, but I'm not willing t= o > > > completely rule it out on the basis of the minimal analysis I > performed. > > > > > > Section 7.1 > > > > > > Only one instance of "MAC and Encrypted Metadata" Context Header > > > (Section 5) is allowed. If multiple instances of "MAC and Encrypt= ed > > > Metadata" Context Header are included in an NSH packet, the SFC da= ta > > > > > > I think Roman may have mentioned this already, but please clarify if > > > this is one instance per NSH or per packet (e.g., in hierarchical SFC > we > > > might have more than one NSH in a packet). > > > > > > Please also clarify it if is permitted to have both MAC#1 and MAC#2 > > > present in the same packet. (IIUC there are not obvious situations > > > where such a setup would be useful, but it's still good to be clear > > > about expectations.) > > > > > > Section 7.2 > > > > > > If the Context Headers are not encrypted, the HMAC algorithm > > > discussed in [RFC4868] is used to integrity protect the target NSH > > > data. [...] > > > > > > It's not really clear to me why RFC 4868 is the right reference here, > as > > > opposed to (e.g.) RFC 2104. In particular, see my Discuss point (2). > > > > > > The Message Authentication Code (T) computation process can be > > > illustrated as follows: > > > > > > T =3D HMAC-SHA-256-128(MAC_KEY, A) > > > > > > I agree with the other reviewer that wondered about just using "MAC" > (or > > > maybe "HMAC") rather than "HMAC-SHA-256-128" here (I do see the "can = be > > > illustrated as" qualifier). > > > > > > It's also a little weird to reuse T and A from the AEAD construction > (or > > > RFC 4868) here without additional discussion on how they apply and ho= w > > > the value of A is constructed. > > > > > > An entity in the SFP that intends to update the NSH MUST follow th= e > > > above behavior to maintain message integrity of the NSH for > > > subsequent validations. > > > > > > I'm not sure that "intends to" is needed; the requirement applies to > > > actions, not intent. > > > > > > Section 7.3 > > > > > > In an SFC-enabled domain where pervasive monitoring [RFC7258] is > > > possible, all Context Headers carrying privacy-sensitive metadata > > > MUST be encrypted; [...] > > > > > > I agree with the other reviewer that noted that this seems to > > > effectively be an unqualified "MUST", since there is always some > > > possibility of monitoring. > > > > > > MAC_KEY =3D initial MAC_KEY_LEN octets of K, > > > ENC_KEY =3D final ENC_KEY_LEN octets of K, > > > E =3D CBC-PKCS7-ENC(ENC_KEY, P), > > > M =3D MAC(MAC_KEY, A || IV || E || AL), > > > T =3D initial T_LEN octets of M. > > > MAC and Encrypted Metadata =3D E || T > > > > > > I recognize that this is just copy+paste from RFC 7518 (with the > > > addition of the last line), but it seems a glaring omission that the > > > CBC-PKCS7-ENC() invocation does not include the IV as an input! > > > (In =C2=A75.2.2.1 of RFC 7518 we do see that "The plaintext is CBC en= crypted > > > using PKCS #7 padding using ENC_KEY as the key and the IV", so it's > just > > > the figure/formula that omits the IV.) > > > > > > We also don't define or mention T_LEN in this document other than in > > > this formula and the analogous one for MAC-without-encryption, which > > > might be worth remedying. > > > > > > Section 7.4 > > > > > > I suggest adding another word (like "Prevention") to the section titl= e. > > > > > > The received NSH is accepted by an NSH-aware node if the Timestamp > > > (TS) in the NSH is recent enough to the reception time of the NSH > > > (TSrt). The following formula is used for this check: > > > > > > -Delta < (TSrt - TS) < +Delta > > > > > > (There's no real reason why the accepted timestamp skew parameter Del= ta > > > needs to be symmetric in the positive and negative directions.) > > > > > > Replay attacks within the Delta window may be detected by an NSH- > > > aware node by recording a unique value derived, for example, from > the > > > NSH data and Original packet (e.g., using SHA2). [...] > > > > > > Note that the unique value MUST NOT use as input any bits that are no= t > > > covered by the MAC. Indeed, just using the MAC itself as the unique > > > value would be a fairly straightforward scheme, I think. > > > > > > Section 7.5 > > > > > > When an SFC data plane element receives an NSH packet, it MUST fir= st > > > ensure that a "MAC and Encrypted Metadata" Context Header is > > > included. [...] > > > > > > This sort of requirement (as written) would seem to support the > position > > > of some other reviewers that this document would need to formally > update > > > RFC 8300. > > > > > > Section 9 > > > > > > We might discuss that this mechanism is only for metadata type 2 and > not > > > type 1 (as well as that with the relatively small fixed length of typ= e > 1 > > > metadata, it's quite challenging to provide useful cryptographic > > > protection), so that type-1 metadata still has no generic protection > > > mechanism. A given metadata element could define its own protection > > > scheme, of course. > > > > > > The attacks discussed in [I-D.nguyen-sfc-security-architecture] ar= e > > > handled owing to the solution specified in this document, except f= or > > > attacks dropping packets. [...] > > > > > > >From a very quick read, draft-nguyen-sfc-security-architecture > proposes > > > a probe-based scheme that monitors all middleboxes (or at least those > in > > > the expected path) to detect a middlebox-bypass attack and verify tha= t > > > the probe traversed the expected SFP. I am not sure that this docume= nt > > > on its own suffices to prevent the middlebox-bypass attack for all > > > traffic (i.e., the probe-based scheme might still be needed). If som= e > > > network entities know what the expected service index will be for a > > > given SPI at a given node, then middlebox-bypass attacks could be > > > natively detected, but my understanding was that such advance knowled= ge > > > of expected service index was not going to be available. > > > > > > The solution specified in this document does not provide data orig= in > > > authentication. > > > > > > I would have expected more in-depth discussion of the security > > > considerations for a group-shared PSK scheme, including how the risk = of > > > key loss/compromise goes up when the key is distributed to more > > > locations. > > > > > > Section 9.1 > > > > > > No device other than the NSH-aware SFs in the SFC-enabled domain > > > should be able to update the integrity protected NSH data. > > > > > > What about classifiers and SFC proxies? > > > > > > Section 9.2 > > > > > > I expected to see some remarks here analogous to the second paragraph > of > > > =C2=A79.1 (even if just by reference to that section). > > > > > > Section 9.3 > > > > > > Section 5.6 of [RFC8633] describes best current practices to be > > > considered in deployments where SFC data plane elements use NTP fo= r > > > time synchronization purposes. > > > > > > The referenced section covers NTP symmetric mode only. Is > client/server > > > mode not a BCP for trusted networks and broadcast/symmetric the only > > > options? > > > > > > NITS > > > > > > Section 1 > > > > > > network infrastructures against them, network slicing, etc. Becau= se > > > of the proliferation of such advanced SFs together with complex > > > service deployment constraints that demand more agile service > > > delivery procedures, operators need to rationalize their service > > > delivery logics and master their complexity while optimising servi= ce > > > activation time cycles. The overall problem space is described in > > > [RFC7498]. > > > > > > The "their" in "master their complexity" is a bit ambiguous between > > > "operators" and "service delivery logics" (noting that the previous u= se > > > of "their" did refer to "operators"). (The sentence as a whole reads= a > > > bit like marketing language, but that's not intended to be an > actionable > > > comment.) > > > > > > This specification fills that gap. Concretely, this document adds > > > integrity protection and optional encryption of sensitive metadata > > > directly to the NSH (Section 4); integrity protects the packet > > > payload and provides replay protection (Section 7.4). [...] > > > > > > The clause after the semicolon needs to be able to stand alone as a > > > complete sentence in order to be grammatical, but it currently has no > > > subject. Maybe prefixing "it also" would be enough to fix it. > > > > > > Section 4.1.2 > > > > > > The integrity protection scope is explicitly signaled to NSH-aware > > > SFs and SFC proxies in the NSH by means of a dedicated MD Type > > > (Section 5). > > > > > > Signaled to SFFs as well, since in the second LoA they can use it. > > > > > > Section 4.6 > > > > > > As discussed in [RFC8459], an SFC-enabled domain (called, > upper-level > > > domain) may be decomposed into many sub-domains (called, lower-lev= el > > > domains). In order to avoid maintaining state to restore back > upper- > > > lower NSH information at the boundaries of lower-level domains, tw= o > > > > > > I think s/upper-lower/upper-layer/ (across the line break)? > > > > > > Section 5.1 > > > > > > MAC#1 Context Header is a variable-length Context Header that > carries > > > the Message Authentication Code (MAC) for the Service Path Header, > > > Context Headers, and the inner packet on which NSH is imposed, > > > calculated using MAC_KEY and optionally Context Headers encrypted > > > using ENC_KEY. [...] > > > > > > Comma after "calculated using MAC_KEY", please. ("optionally Context > > > Headers [...]" are not used along with MAC_KEY in the calculation) > > > > > > Section 5.2 > > > > > > Message Authentication Code: Coves the entire NSH data. The > > > > > > s/Coves/Covers/ > > > > > > Section 6 > > > > > > The epoch is 1970-01-01T00:00Z in UTC time. [...] > > > > > > (IIUC, the "in UTC time" is redundant with the trailing 'Z'.) > > > > > > Section 7.1 > > > > > > element. The details of sending notification alarms (i.e., the > > > parameters affecting the transmission of the notification alarms > > > depend on the information in the context header such as frequency, > > > thresholds, and content in the alarm) SHOULD be configurable. > > > > > > The grammar in the parenthetical seems off to me. Possibly > > > s/depend/depending/ would be a fix, but I'm not sure. > > > > > > NSH-aware SFs and SFC proxies MUST re-apply the integrity protecti= on > > > if any modification is made to the Context Headers (strip a Contex= t > > > Header, update the content of an existing Context Header, insert a > > > new Context Header). > > > > > > I think maybe an "e.g.," in the parenthetical is in order, since this > > > doesn't seem to include things like "decrement the TTL". > > > > > > Section 9 > > > > > > The interaction between the SFC data plane elements and a key > > > management system MUST NOT be transmitted in clear since this woul= d > > > completely destroy the security benefits of the integrity protecti= on > > > solution defined in this document. The secret key (K) must have a= n > > > expiration time assigned as the latest point in time before which > the > > > > > > This first sentence seems like it could probably be a paragraph of it= s > > > own; the subsequent discussion of expiration time seems to be mostly > > > unrelated. > > > > > > We might also add another sentence to reiterate that "the security an= d > > > integrity of the key-distribution mechanism is vital to the security = of > > > the system as a whole". > > > > > > o Attacker replacing the packet on which the NSH is imposed with = a > > > bogus packet. > > > > > > I'd probably say "modified or bogus". > > > > > > In an SFC-enabled domain where the above attacks are possible, (1) > > > > > > This is perhaps ambiguous about whether an "any" or "all" criterion > > > should be used. Perhaps that's desired :) > > > > > > > > > > > > > --00000000000007977405c7b3bf2d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ben,

Please see inl= ine=C2=A0

On Thu, 22 Jul 2021 at 04:16, Benjamin Kaduk <kaduk@mit.edu> wrote:
Hi Tiru,

Also inline...

On Mon, Jul 19, 2021 at 01:20:11PM +0530, tirumal reddy wrote:
> Hi Ben,
>
> Please see inline
>
> On Thu, 15 Jul 2021 at 02:55, Benjamin Kaduk via Datatracker <
> noreply@ietf.org= > wrote:
>
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-sfc-nsh-integrity-06: Discuss
> >
> > When responding, please keep the subject line intact and reply to= all
> > email addresses included in the To and CC lines. (Feel free to cu= t this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.= org/iesg/statement/discuss-criteria.html
> > for more information about DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found her= e:
> > https://datatracker.ietf.org= /doc/draft-ietf-sfc-nsh-integrity/
> >
> >
> >
> > -----------------------------------------------------------------= -----
> > DISCUSS:
> > -----------------------------------------------------------------= -----
> >
> > (0) (I came to this realization rather late in my review process,= so
> > there may be places where the COMMENT and this discuss point are = in
> > disagreement; this DISCUS takes precedence.)
> > I fear that the construction that separately distributes ENC_KEY = and
> > MAC_KEY in an attempt to achieve privilege separation is fatally = flawed.
> > In particular, the CBC encryption mode is a malleable encryption = mode,
> > in that flipping a bit of ciphertext will filp the corresponding = bit of
> > the next block of recovered plaintext (at the cost of completely<= br> > > garbling the recovered block containing the bit that was modified= ).
> > Subsequent blocks are unaffected.=C2=A0 Typically we combine CBC = mode with a
> > MAC such as HMAC in order to prevent such modifications from bein= g
> > exposed as attack vectors, and while we do use HMAC here for that=
> > purpose, we also introduce a separate class of actors that have a= ccess
> > to the HMAC key but not the encryption key.=C2=A0 Accordingly, th= ose actors
> > can produce a new, valid, integrity tag after making a modificati= on to
> > the ciphertext, allowing them to engage in attacks that make use = of
> > ciphertext malleability.=C2=A0 Ciphertext malleability is particu= larly useful
> > as an attack vector when the structure of the plaintext being enc= rypted
> > is known, and there are portions of the plaintext that the applic= ation
> > will either ignore if they are garbled or are expected to be near= random
> > in the normal case (and thus for which garbled output does not ca= use
> > rejection by the application).=C2=A0 In a SFC environment it seem= s highly
> > likely that the structure of the plaintext will be known or guess= able,
> > and we don't have any real mechanisms to control what types o= f metadata
> > go into encrypted context headers, so it seems that we must act a= s if we
> > are exposed to this risk.
> >
> > While =C2=A74.3 does have a note that use of GCM with HMAC is und= esirable due
> > to the additional authentication tag, it may be unavoidable in or= der to
> > provide the properties that we need.
> >
>
> Thanks for explaining the attack. We will modify the text in Section 4= .3 as
> follows to address the comment:
>
>=C2=A0 =C2=A0 Classifiers, NSH-aware SFs, and SFC proxies MUST implemen= t the
>=C2=A0 =C2=A0 AES_128_GCM [GCM][RFC5116] algorithm and SHOULD implement= the
>=C2=A0 =C2=A0 AES_192_GCM and AES_256_GCM algorithms.
>
>=C2=A0 =C2=A0 Classifiers, NSH-aware SFs, and SFC proxies MUST implemen= t the HMAC-
>=C2=A0 =C2=A0 SHA-256-128 algorithm and SHOULD implement the HMAC-SHA-3= 84-192 and
>=C2=A0 =C2=A0 HMAC-SHA-512-256 algorithms.
>
>=C2=A0 =C2=A0 SFFs MAY implement the aforementioned cipher suites and H= MAC
>=C2=A0 =C2=A0 algorithms.
>
> Note:
> The use of AES_128_CBC_HMAC_SHA_256 algorithm would have avoided the n= eed
> for a second 128-bit authentication tag but due to the nature of how C= BC
> mode operates, the mode allows for malleability of plaintexts. This > malleability allows for attackers to make changes in the ciphertext an= d, if
> parts of the plaintext are known, create arbitrary blocks of
> plaintext. This specification mandates the use of AES-GCM to prevent t= his
> type of attack.

This seems okay on first read, thanks.=C2=A0 I will probably end up reading= it
again once the revised I-D is posted, in the full context of the draft.
=

Sure, we will publish the revised draft ne= xt week.
=C2=A0

>
> >
> > (1) Section 5.1 describes the MAC as:
> >
> >=C2=A0 =C2=A0 Message Authentication Code:=C2=A0 =C2=A0Covers the = entire NSH data, excluding
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0the Base header.=C2=A0 The Additional A= uthenticated Data (defined in
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC7518]) MUST be the Service Path hea= der, the unencrypted
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Context headers, and the inner packet o= n which the NSH is imposed.
> >
> > This description seems to exclude from the MAC most of the MAC co= ntext
> > header itself (if we go by the corresponding figure), which is ve= ry bad
> > for security.=C2=A0 We definitely need to include under the MAC t= he MAC
> > context header bits from metadata class through and including at = least
> > timestamp, and I think IV length as well.=C2=A0 (The IV itself wo= uld be
> > incorporated via the ciphertext, since the IV is an input to encr= yption,
> > but since the IV length field indicates whether or not encryption= was
> > performed, we'd need to protect that information.)
> >
>
> No, the MAC context header is also used for generating the digest.

Ok.

>
> >
> > Similarly, Section 5.2 has the description:
> >
> >=C2=A0 =C2=A0 Message Authentication Code:=C2=A0 Coves the entire = NSH data.=C2=A0 The
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Additional Authenticated Data (defined = in [RFC7518]) MUST be the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0entire NSH data (i.e., including the Ba= se Header) excluding the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Context Headers to be encrypted.
> >
> > which on the face of it includes the field that holds the MAC its= elf
> > (and is not yet populated), i.e., is self-referential.
> >
>
> The below update will address this comment:
>
> The NSH imposer sets the MAC field to zero and then computes the messa= ge
> integrity for the target NSH data (depending on the integrity protecti= on
> scope discussed in Section 5) using MAC_KEY and HMAC algorithm. It ins= erts
> the computed digest in the MAC field in the "MAC and Encrypted Me= tadata"
> Context Header.
>

Thanks!=C2=A0 (I think Roman may have goten this before me, so sorry for th= e
duplication.)

>
> >
> > I think we need to be much more precise about the construction of= the
> > AAD in both cases.=C2=A0 It's possible that the HMAC construc= tion for the
> > no-encrypted-context-headers case can inherit a definition from t= he AAD
> > description, but if not we'll need to have some more precisio= n there as
> > well.
> >
> > (2) In order for the MAC-only construction in =C2=A77.2 to be com= patible with
> > the AEAD integrity tag construction, we would need to include the= 64-bit
> > AL after A.=C2=A0 While HMAC is intrinsically immune to length-ex= tension
> > attacks, I think that having the explicit AL is useful to avoid a= ny risk
> > of malleability, since the same MAC_KEY is used for constructing = both
> > types of MACs.
> >
>
> I don't think this comment is applicable after AES_128_CBC_HMAC_SH= A_256 is
> removed.

I think so, yes.

>
> >
> > (3) Section 5.1 describes the Timestamp field as an "unsigne= d 64-bit
> > integer value", which is inconsistent with the actual format= given in
> > Section 6.
> >
>
> Thanks, we will fix it in the next revision.
>
>
> >
> > (4) Section 7.5 directs the verifier to check if "the value = of the newly
> > generated digest is identical to the one enclosed in the NSH"= ;.=C2=A0 It is
> > critical for the security of the system that this comparison be d= one in
> > a constant-time manner that does not provide a side channel into = whether
> > the generated digest and the value in the NSH share a common subs= tring.
> >
>
> Agreed, will update text as follows:
>
> After storing the value of the MAC field in the "MAC and Encrypte= d
> Metadata" Context Header, the SFC data plane element fills the MA= C
> field with zeros.=C2=A0 Then, the SFC data plane element generates the= message
> integrity
> for the target NSH data (depending on the integrity protection scope > discussed in Section 5) using MAC_KEY and HMAC algorithm.=C2=A0 If the= value of
> the newly generated digest is identical to the stored one, the SFC dat= a
> plane element is certain that the NSH data has not been tampered and > validation is therefore successful. Otherwise, the NSH packet MUST be<= br> > discarded. The comparison of the computed HMAC value to the store valu= e MUST
> be done in a constant-time manner to thwart timing attacks.

Thanks!

>
> >
> > (5) Do the MAC context headers always have to be the last metadat= a
> > entries in the packet (to simplify the cryptographic calculations= )?
> >
>
> Yes.
>

Okay.=C2=A0 I suspected that, but it is probably worth a MUST-level require= ment
in the document to make it clear to everyone.

Done, will add a line.

Cheers,
-T= iru
=C2=A0

Thanks again,

Ben

>
> > Certainly the diagrams only show "unencrypted context header= s" appearing
> > prior to the MAC context header, so if we expect unencrypted cont= ext
> > headers to appear after the MAC context header as well, we should= be
> > clear about that both in the figures and in the specification for= how to
> > prepare the AAD.
> >
> >
> > -----------------------------------------------------------------= -----
> > COMMENT:
> > -----------------------------------------------------------------= -----
> >
> > Section 3
> >
> >=C2=A0 =C2=A0 o=C2=A0 Both encrypted and unencrypted Context Heade= rs MAY be included in
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0the same NSH.=C2=A0 That is, some Conte= xt Headers may be protected
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0while others do not need to be protecte= d.
> >
> > In the security area we're pretty strongly moved towards a st= ance of
> > "encrypt everything that doesn't have a strong need to b= e plaintext
> > (since we don't want to assume that we can predict all threat= s and
> > attacks in advance), and QUIC has even taken that to new levels.= =C2=A0 It's
> > quite surprising to see "don't need to be protected"= ; as a justification
> > for lack of encryption, rather than "need to be unprotected&= quot;.=C2=A0 Given
> > that we're going to be solving key distribution for integrity= protection
> > anyway, it remains unclear to me why we wouldn't just encrypt=
> > everything.
> >
> > Section 4.1.1
> >
> > Is the column heading for the middle column of Table 1 referring = to the
> > Base Header and "Service Path Header"?=C2=A0 I'm no= t sure how to interpret
> > just "Service Header" other than the entire NSH, which = doesn't seem
> > right...
> >
> >=C2=A0 =C2=A0 The Service Path Header (Section 2 of [RFC8300]) is = not encrypted
> >=C2=A0 =C2=A0 because SFFs use Service Index (SI) in conjunction w= ith Service Path
> >=C2=A0 =C2=A0 Identifier (SPI) for determining the next SF in the = path.
> >
> > It's good to see this spelled out like this; I'd love to = have this kind
> > of explanation for every un-encrypted protocol element.
> >
> > Section 4.1.2
> >
> >=C2=A0 =C2=A0 The solution provides integrity protection for the N= SH data.=C2=A0 Two
> >=C2=A0 =C2=A0 levels of assurance (LoAs) are supported.
> >
> > I see (reading onward) that the two LoAs just differ in what is c= overed
> > by the integrity tag, but each involve only a single MAC.=C2=A0 T= here's a
> > reasonable argument that when there are overlapping needs for wha= t data
> > needs protecting and who needs access to it, that multiple MACs (= or
> > encryption, if needed) are most appropriate, which can be tailore= d to
> > the respective needs.=C2=A0 This is something that Phillip Hallam= -Baker has
> > ascribed as the "short-blanket theory" of cryptography,= in that it's
> > like a blanket that's too short to cover everything you want,= so you
> > need to have more than one and put them in partially overlapping = layers.
> > Perhaps this "short-blanket theory" is more applicable = to Discuss point
> > (0) than what is covered by the MAC, though...
> >
> >=C2=A0 =C2=A0 The first level of assurance where all NSH data exce= pt the Base
> >=C2=A0 =C2=A0 Header are integrity protected (Figure 2).=C2=A0 In = this case, the NSH
> >=C2=A0 =C2=A0 imposer may be a Classifier, an NSH-aware SF, or an = SFC Proxy.=C2=A0 SFFs
> >=C2=A0 =C2=A0 are not thus provided with authentication material.= =C2=A0 [...]
> >
> > There seems to be a gap in the chain of reasoning as to why SFFs = are not
> > provided with authentication material.=C2=A0 It seems that the in= tent is
> > something along the lines of considering which entities need acce= ss to
> > the key material in order to successfully add an NSH or update co= ntext
> > headers, but that alone is not itself cause to say that other ent= ities
> > can never be provided with the keys (subject to the security
> > considerations of group-shared PSKs, of course).=C2=A0 Furthermor= e, if a
> > particular SFF is trusted, it may have grounds to verify the inte= grity
> > tag even if it is administratively prohibited from writing such a= tag.
> >
> >=C2=A0 =C2=A0 In both levels of assurance, the unencrypted Context= Headers and the
> >=C2=A0 =C2=A0 packet on which the NSH is imposed are subject to in= tegrity
> >=C2=A0 =C2=A0 protection.
> >
> > Surely any encrypted Context Headers are also given integrity
> > protection, as excluding them from the MAC computation would be q= uite
> > complex.=C2=A0 I see that the encrypted context headers are not p= art of the
> > AAD input, but in the AEAD model the ciphertext is still given in= tegrity
> > protection!
> >
> > Section 4.2
> >
> >=C2=A0 =C2=A0 The authenticated encryption algorithm defined in [R= FC7518] is used
> >=C2=A0 =C2=A0 to provide NSH data integrity and to encrypt the Con= text Headers that
> >=C2=A0 =C2=A0 carry privacy-sensitive metadata.
> >
> > RFC 7518 (JSON Web Algorithms) is a very surprising reference for=
> > generic AEAD encryption.=C2=A0 Continuing on, it becomes clear th= at we in
> > fact do not want a generic AEAD operation here, but instead have = need
> > for separation of encryption and integrity protection due to the = various
> > separations of roles that are possible.=C2=A0 Because this is a d= ivergence
> > from current best practices (use of native AEAD cipher modes like= GCM,
> > SIV, etc.), I might suggest a rather different introductory mater= ial:
> >
> > % The AEAD interface specified in RFC 5116 is a very powerful too= l for
> > % providing strong confidentiality and integrity protection for p= rotocol
> > % messages, and has become quite widely adopted as a result.=C2= =A0 For
> > % protecting NSH data we adhere to the spirit of the AEAD interfa= ce but
> > % use a slightly modified version in order to remain consistent w= ith the
> > % privilege separation needed (e.g., in the second level of assur= ance,
> > % SFFs need to be able to update the message integrity tag but do= not
> > % need access to the decrypted plaintext).=C2=A0 Accordingly, a c= ompound AEAD
> > % mechanism combining CBC encryption and HMAC integrity tag is us= ed, so
> > % that distribution of the encryption key can be limited.=C2=A0 R= ather than
> > % define a new scheme from scratch, the AES_CBC_HMAC_SHA2 scheme = from
> > % [RFC7518] is used.=C2=A0 In order to simplify key distribution,= a single
> > % secret key material seed K is used, which can be kept private > > % centrally or distributed to all parties that will have access t= o
> > % decrypted plaintext, and the secondary keys MAC_KEY and ENC_KEY= are
> > % derived from K as discussed in Section 5.2.2.1 of [RFC7518].=C2= =A0 Entities
> > % that need to update the integrity tag but are not authorized to= see
> > % the decrypted plaintext will only receive MAC_KEY and not K or<= br> > > % ENC_KEY.
> >
> >=C2=A0 =C2=A0 o=C2=A0 If the Context Headers are not encrypted, th= e Hashed Message
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Authentication Mode (HMAC) algorithm di= scussed in [RFC4868] is
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0used to protect the integrity of the NS= H data.
> >
> > It's not clear to me that this is adding much value; HMAC is = used
> > whether or not there are encrypted headers, and the RFC 4868 refe= rence
> > is rather odd (see also my Discuss point (2)).
> >
> >=C2=A0 =C2=A0 The advantage of using the authenticated encryption = algorithm is that
> >=C2=A0 =C2=A0 NSH-aware SFs and SFC proxies only need to re-comput= e the message
> >=C2=A0 =C2=A0 integrity of the NSH data after decrementing the Ser= vice Index (SI)
> >=C2=A0 =C2=A0 and do not have to re-compute the ciphertext.=C2=A0 = The other advantage is
> >=C2=A0 =C2=A0 that SFFs do not have access to the ENC_KEY and cann= ot act on the
> >=C2=A0 =C2=A0 encrypted Context Headers and, only in case of the s= econd level of
> >=C2=A0 =C2=A0 assurance, SFFs do have access to the MAC_KEY.=C2=A0= Similarly, an NSH-
> >=C2=A0 =C2=A0 aware SF or SFC Proxy not allowed to decrypt the Con= text Headers will
> >=C2=A0 =C2=A0 not have access to the ENC_KEY.
> >
> > [If my above suggestion is used, this text has probably become mo= stly
> > redundant and could be trimmed down or removed.]
> >
> >=C2=A0 =C2=A0 The authenticated encryption process takes as input = four-octet
> >=C2=A0 =C2=A0 strings: a secret key (K), a plaintext (P), Addition= al Authenticated
> >=C2=A0 =C2=A0 Data (A) (which contains the data to be authenticate= d, but not
> >=C2=A0 =C2=A0 encrypted), and an Initialization Vector (IV).=C2=A0= The ciphertext value
> >=C2=A0 =C2=A0 (E) and the Authentication Tag value (T) are provide= d as outputs.
> >
> >=C2=A0 =C2=A0 In order to decrypt and verify, the cipher takes as = input K, IV, A,
> >=C2=A0 =C2=A0 T, and E.=C2=A0 The output is either the plaintext o= r an error indicating
> >=C2=A0 =C2=A0 that the decryption failed as described in Section 5= .2.2.2 of
> >=C2=A0 =C2=A0 [RFC7518].
> >
> > This seems true for the abstract AEAD interface, but since we'= ;re peeling
> > off the HMAC integrity tag for standalone use, we may need to say=
> > something about what inputs/outputs are needed for just using the=
> > integrity tag without doing decryption.=C2=A0 In particular, we c= annot use K
> > as an input for standalone HMAC verification!
> >
> > Also, this is just the generic AEAD interface, so RFC 5116 is pro= bably a
> > more apropos reference than RFC 7518.
> >
> > Section 4.3
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Note: The use of Advanced Encryption St= andard (AES) in Galois/
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Counter Mode (GCM) + HMAC may have CPU = and packet size
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0implications (need for a second 128-bit= authentication tag).
> >
> > [This might also be redundant if my earlier proposal is accepted.= ]
> >
> > Section 4.4
> >
> >=C2=A0 =C2=A0 The document does not assume nor preclude the follow= ing:
> >
> >=C2=A0 =C2=A0 o=C2=A0 The same keying material is used for all the= service functions
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0used within an SFC-enabled domain.
> >
> >=C2=A0 =C2=A0 o=C2=A0 Distinct keying material is used per SFP by = all involved SFC data
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0path elements.
> >
> >=C2=A0 =C2=A0 o=C2=A0 Per-tenant keys are used.
> >
> > I suggest a forward reference to the security considerations with= a
> > brief note that the risk involved in using a group-shared symmetr= ic key
> > increases with the size of the group to which it is shared.
> >
> >=C2=A0 =C2=A0 In order to accommodate deployments relying upon key= ing material per
> >=C2=A0 =C2=A0 SFC/SFP and also the need to update keys after encry= pting NSH data
> >=C2=A0 =C2=A0 for a certain amount of time, this document uses key= identifiers to
> >=C2=A0 =C2=A0 unambiguously identify the appropriate keying materi= al.=C2=A0 Doing so
> >=C2=A0 =C2=A0 allows to address the problem of synchronization of = keying material.
> >
> > I'd suggest making a statement about the scope in which key i= dentifiers
> > need to be unique.
> >
> > Section 4.5
> >
> >=C2=A0 =C2=A0 An NSH-aware SF or SFC Proxy that needs to decrypt s= ome Context
> >=C2=A0 =C2=A0 Headers uses ENC_Key and the decryption algorithm fo= r the key
> >=C2=A0 =C2=A0 identifier being carried in the NSH.
> >
> > I think we need to say that decryption MUST NOT proceed unless th= e
> > integrity tag has been successfully validated.=C2=A0 To decrypt w= ithout
> > checking the integrity tag violates the AEAD interface.=C2=A0 Alt= ernately, we
> > could only ever describe decryption as the AEAD operation that us= es K as
> > input (not just ENC_KEY) -- =C2=A77.6 seems to attempt to take th= is latter
> > approach, but the document as a whole is not consistent about it.=
> >
> > Section 5, 5.x
> >
> > I strongly suggest changing "Key Length" to "keyid= length", since there
> > is already convention on "key length" (e.g., for AES-12= 8 vs AES-192 vs
> > AES-256).
> >
> > Section 5.1
> >
> >=C2=A0 =C2=A0 Key Identifier:=C2=A0 Carries a variable-length Key = Identifier object used
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0to identify and deliver keys to SFC dat= a plane elements.=C2=A0 This
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0identifier is helpful to accommodate de= ployments relying upon
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0keying material per SFC/SFP.=C2=A0 The = key identifier helps in
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0resolving the problem of synchronizatio= n of keying material.
> >
> > I suggest clarifying that a single key identifier is used to look= up both
> > the associated ENC_KEY and the associated MAC_KEY (or, alternatel= y, that
> > it is logically bound to K and remind the reader that ENC_KEY and=
> > MAC_KEY are extracted from K and might be separately distributed)= .
> >
> >=C2=A0 =C2=A0 Key Length:=C2=A0 Variable.=C2=A0 Carries the length= of the key identifier.
> >=C2=A0 =C2=A0 [...]
> >=C2=A0 =C2=A0 IV Length:=C2=A0 Carries the length of the IV (Secti= on 5.2 of [RFC7518]).
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0If encryption is not used, IV length is= set to zero (that is, no
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"Initialization Vector" is in= cluded).
> >
> > Please also specify that the Key/IV lengths are measured in bytes= (the
> > reference for IV length, at least, talks about IVs in bits).
> >
> > I strongly suggest using a value other than zero as the sentinel = value
> > for "no encryption" -- there already exist modes like A= ES-SIV (RFC 5297)
> > that do not require an IV input, which would be a natural use for=
> > zero-length IV.
> >
> > Additionally, one might imagine using a non-zero-length IV as inp= ut to
> > an HMAC calculation as a per-message nonce.=C2=A0 On cursory exam= ination,
> > since we are already using timestamp-based replay detection, the<= br> > > additional nonce is unlikely to add much value, but I'm not w= illing to
> > completely rule it out on the basis of the minimal analysis I per= formed.
> >
> > Section 7.1
> >
> >=C2=A0 =C2=A0 Only one instance of "MAC and Encrypted Metadat= a" Context Header
> >=C2=A0 =C2=A0 (Section 5) is allowed.=C2=A0 If multiple instances = of "MAC and Encrypted
> >=C2=A0 =C2=A0 Metadata" Context Header are included in an NSH= packet, the SFC data
> >
> > I think Roman may have mentioned this already, but please clarify= if
> > this is one instance per NSH or per packet (e.g., in hierarchical= SFC we
> > might have more than one NSH in a packet).
> >
> > Please also clarify it if is permitted to have both MAC#1 and MAC= #2
> > present in the same packet.=C2=A0 (IIUC there are not obvious sit= uations
> > where such a setup would be useful, but it's still good to be= clear
> > about expectations.)
> >
> > Section 7.2
> >
> >=C2=A0 =C2=A0 If the Context Headers are not encrypted, the HMAC a= lgorithm
> >=C2=A0 =C2=A0 discussed in [RFC4868] is used to integrity protect = the target NSH
> >=C2=A0 =C2=A0 data.=C2=A0 [...]
> >
> > It's not really clear to me why RFC 4868 is the right referen= ce here, as
> > opposed to (e.g.) RFC 2104.=C2=A0 In particular, see my Discuss p= oint (2).
> >
> >=C2=A0 =C2=A0 The Message Authentication Code (T) computation proc= ess can be
> >=C2=A0 =C2=A0 illustrated as follows:
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 T =3D HMAC-SHA-256-128(MAC_KEY,= A)
> >
> > I agree with the other reviewer that wondered about just using &q= uot;MAC" (or
> > maybe "HMAC") rather than "HMAC-SHA-256-128" = here (I do see the "can be
> > illustrated as" qualifier).
> >
> > It's also a little weird to reuse T and A from the AEAD const= ruction (or
> > RFC 4868) here without additional discussion on how they apply an= d how
> > the value of A is constructed.
> >
> >=C2=A0 =C2=A0 An entity in the SFP that intends to update the NSH = MUST follow the
> >=C2=A0 =C2=A0 above behavior to maintain message integrity of the = NSH for
> >=C2=A0 =C2=A0 subsequent validations.
> >
> > I'm not sure that "intends to" is needed; the requi= rement applies to
> > actions, not intent.
> >
> > Section 7.3
> >
> >=C2=A0 =C2=A0 In an SFC-enabled domain where pervasive monitoring = [RFC7258] is
> >=C2=A0 =C2=A0 possible, all Context Headers carrying privacy-sensi= tive metadata
> >=C2=A0 =C2=A0 MUST be encrypted; [...]
> >
> > I agree with the other reviewer that noted that this seems to
> > effectively be an unqualified "MUST", since there is al= ways some
> > possibility of monitoring.
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MAC_KEY =3D initial MAC_KEY_LEN= octets of K,
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ENC_KEY =3D final ENC_KEY_LEN o= ctets of K,
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 E =3D CBC-PKCS7-ENC(ENC_KEY, P)= ,
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 M =3D MAC(MAC_KEY, A || IV || E= || AL),
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 T =3D initial T_LEN octets of M= .
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MAC and Encrypted Metadata =3D = E || T
> >
> > I recognize that this is just copy+paste from RFC 7518 (with the<= br> > > addition of the last line), but it seems a glaring omission that = the
> > CBC-PKCS7-ENC() invocation does not include the IV as an input! > > (In =C2=A75.2.2.1 of RFC 7518 we do see that "The plaintext = is CBC encrypted
> > using PKCS #7 padding using ENC_KEY as the key and the IV", = so it's just
> > the figure/formula that omits the IV.)
> >
> > We also don't define or mention T_LEN in this document other = than in
> > this formula and the analogous one for MAC-without-encryption, wh= ich
> > might be worth remedying.
> >
> > Section 7.4
> >
> > I suggest adding another word (like "Prevention") to th= e section title.
> >
> >=C2=A0 =C2=A0 The received NSH is accepted by an NSH-aware node if= the Timestamp
> >=C2=A0 =C2=A0 (TS) in the NSH is recent enough to the reception ti= me of the NSH
> >=C2=A0 =C2=A0 (TSrt).=C2=A0 The following formula is used for this= check:
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -Delta < (TSrt= - TS) < +Delta
> >
> > (There's no real reason why the accepted timestamp skew param= eter Delta
> > needs to be symmetric in the positive and negative directions.) > >
> >=C2=A0 =C2=A0 Replay attacks within the Delta window may be detect= ed by an NSH-
> >=C2=A0 =C2=A0 aware node by recording a unique value derived, for = example, from the
> >=C2=A0 =C2=A0 NSH data and Original packet (e.g., using SHA2).=C2= =A0 [...]
> >
> > Note that the unique value MUST NOT use as input any bits that ar= e not
> > covered by the MAC.=C2=A0 Indeed, just using the MAC itself as th= e unique
> > value would be a fairly straightforward scheme, I think.
> >
> > Section 7.5
> >
> >=C2=A0 =C2=A0 When an SFC data plane element receives an NSH packe= t, it MUST first
> >=C2=A0 =C2=A0 ensure that a "MAC and Encrypted Metadata"= Context Header is
> >=C2=A0 =C2=A0 included.=C2=A0 [...]
> >
> > This sort of requirement (as written) would seem to support the p= osition
> > of some other reviewers that this document would need to formally= update
> > RFC 8300.
> >
> > Section 9
> >
> > We might discuss that this mechanism is only for metadata type 2 = and not
> > type 1 (as well as that with the relatively small fixed length of= type 1
> > metadata, it's quite challenging to provide useful cryptograp= hic
> > protection), so that type-1 metadata still has no generic protect= ion
> > mechanism.=C2=A0 A given metadata element could define its own pr= otection
> > scheme, of course.
> >
> >=C2=A0 =C2=A0 The attacks discussed in [I-D.nguyen-sfc-security-ar= chitecture] are
> >=C2=A0 =C2=A0 handled owing to the solution specified in this docu= ment, except for
> >=C2=A0 =C2=A0 attacks dropping packets.=C2=A0 [...]
> >
> > >From a very quick read, draft-nguyen-sfc-security-architectur= e proposes
> > a probe-based scheme that monitors all middleboxes (or at least t= hose in
> > the expected path) to detect a middlebox-bypass attack and verify= that
> > the probe traversed the expected SFP.=C2=A0 I am not sure that th= is document
> > on its own suffices to prevent the middlebox-bypass attack for al= l
> > traffic (i.e., the probe-based scheme might still be needed).=C2= =A0 If some
> > network entities know what the expected service index will be for= a
> > given SPI at a given node, then middlebox-bypass attacks could be=
> > natively detected, but my understanding was that such advance kno= wledge
> > of expected service index was not going to be available.
> >
> >=C2=A0 =C2=A0 The solution specified in this document does not pro= vide data origin
> >=C2=A0 =C2=A0 authentication.
> >
> > I would have expected more in-depth discussion of the security > > considerations for a group-shared PSK scheme, including how the r= isk of
> > key loss/compromise goes up when the key is distributed to more > > locations.
> >
> > Section 9.1
> >
> >=C2=A0 =C2=A0 No device other than the NSH-aware SFs in the SFC-en= abled domain
> >=C2=A0 =C2=A0 should be able to update the integrity protected NSH= data.
> >
> > What about classifiers and SFC proxies?
> >
> > Section 9.2
> >
> > I expected to see some remarks here analogous to the second parag= raph of
> > =C2=A79.1 (even if just by reference to that section).
> >
> > Section 9.3
> >
> >=C2=A0 =C2=A0 Section 5.6 of [RFC8633] describes best current prac= tices to be
> >=C2=A0 =C2=A0 considered in deployments where SFC data plane eleme= nts use NTP for
> >=C2=A0 =C2=A0 time synchronization purposes.
> >
> > The referenced section covers NTP symmetric mode only.=C2=A0 Is c= lient/server
> > mode not a BCP for trusted networks and broadcast/symmetric the o= nly
> > options?
> >
> > NITS
> >
> > Section 1
> >
> >=C2=A0 =C2=A0 network infrastructures against them, network slicin= g, etc.=C2=A0 Because
> >=C2=A0 =C2=A0 of the proliferation of such advanced SFs together w= ith complex
> >=C2=A0 =C2=A0 service deployment constraints that demand more agil= e service
> >=C2=A0 =C2=A0 delivery procedures, operators need to rationalize t= heir service
> >=C2=A0 =C2=A0 delivery logics and master their complexity while op= timising service
> >=C2=A0 =C2=A0 activation time cycles.=C2=A0 The overall problem sp= ace is described in
> >=C2=A0 =C2=A0 [RFC7498].
> >
> > The "their" in "master their complexity" is a= bit ambiguous between
> > "operators" and "service delivery logics" (no= ting that the previous use
> > of "their" did refer to "operators").=C2=A0 (= The sentence as a whole reads a
> > bit like marketing language, but that's not intended to be an= actionable
> > comment.)
> >
> >=C2=A0 =C2=A0 This specification fills that gap.=C2=A0 Concretely,= this document adds
> >=C2=A0 =C2=A0 integrity protection and optional encryption of sens= itive metadata
> >=C2=A0 =C2=A0 directly to the NSH (Section 4); integrity protects = the packet
> >=C2=A0 =C2=A0 payload and provides replay protection (Section 7.4)= .=C2=A0 [...]
> >
> > The clause after the semicolon needs to be able to stand alone as= a
> > complete sentence in order to be grammatical, but it currently ha= s no
> > subject.=C2=A0 Maybe prefixing "it also" would be enoug= h to fix it.
> >
> > Section 4.1.2
> >
> >=C2=A0 =C2=A0 The integrity protection scope is explicitly signale= d to NSH-aware
> >=C2=A0 =C2=A0 SFs and SFC proxies in the NSH by means of a dedicat= ed MD Type
> >=C2=A0 =C2=A0 (Section 5).
> >
> > Signaled to SFFs as well, since in the second LoA they can use it= .
> >
> > Section 4.6
> >
> >=C2=A0 =C2=A0 As discussed in [RFC8459], an SFC-enabled domain (ca= lled, upper-level
> >=C2=A0 =C2=A0 domain) may be decomposed into many sub-domains (cal= led, lower-level
> >=C2=A0 =C2=A0 domains).=C2=A0 In order to avoid maintaining state = to restore back upper-
> >=C2=A0 =C2=A0 lower NSH information at the boundaries of lower-lev= el domains, two
> >
> > I think s/upper-lower/upper-layer/ (across the line break)?
> >
> > Section 5.1
> >
> >=C2=A0 =C2=A0 MAC#1 Context Header is a variable-length Context He= ader that carries
> >=C2=A0 =C2=A0 the Message Authentication Code (MAC) for the Servic= e Path Header,
> >=C2=A0 =C2=A0 Context Headers, and the inner packet on which NSH i= s imposed,
> >=C2=A0 =C2=A0 calculated using MAC_KEY and optionally Context Head= ers encrypted
> >=C2=A0 =C2=A0 using ENC_KEY.=C2=A0 [...]
> >
> > Comma after "calculated using MAC_KEY", please.=C2=A0 (= "optionally Context
> > Headers [...]" are not used along with MAC_KEY in the calcul= ation)
> >
> > Section 5.2
> >
> >=C2=A0 =C2=A0 Message Authentication Code:=C2=A0 Coves the entire = NSH data.=C2=A0 The
> >
> > s/Coves/Covers/
> >
> > Section 6
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0The epoch is 1970-01-01T00:00Z in UTC t= ime.=C2=A0 [...]
> >
> > (IIUC, the "in UTC time" is redundant with the trailing= 'Z'.)
> >
> > Section 7.1
> >
> >=C2=A0 =C2=A0 element.=C2=A0 The details of sending notification a= larms (i.e., the
> >=C2=A0 =C2=A0 parameters affecting the transmission of the notific= ation alarms
> >=C2=A0 =C2=A0 depend on the information in the context header such= as frequency,
> >=C2=A0 =C2=A0 thresholds, and content in the alarm) SHOULD be conf= igurable.
> >
> > The grammar in the parenthetical seems off to me.=C2=A0 Possibly<= br> > > s/depend/depending/ would be a fix, but I'm not sure.
> >
> >=C2=A0 =C2=A0 NSH-aware SFs and SFC proxies MUST re-apply the inte= grity protection
> >=C2=A0 =C2=A0 if any modification is made to the Context Headers (= strip a Context
> >=C2=A0 =C2=A0 Header, update the content of an existing Context He= ader, insert a
> >=C2=A0 =C2=A0 new Context Header).
> >
> > I think maybe an "e.g.," in the parenthetical is in ord= er, since this
> > doesn't seem to include things like "decrement the TTL&q= uot;.
> >
> > Section 9
> >
> >=C2=A0 =C2=A0 The interaction between the SFC data plane elements = and a key
> >=C2=A0 =C2=A0 management system MUST NOT be transmitted in clear s= ince this would
> >=C2=A0 =C2=A0 completely destroy the security benefits of the inte= grity protection
> >=C2=A0 =C2=A0 solution defined in this document.=C2=A0 The secret = key (K) must have an
> >=C2=A0 =C2=A0 expiration time assigned as the latest point in time= before which the
> >
> > This first sentence seems like it could probably be a paragraph o= f its
> > own; the subsequent discussion of expiration time seems to be mos= tly
> > unrelated.
> >
> > We might also add another sentence to reiterate that "the se= curity and
> > integrity of the key-distribution mechanism is vital to the secur= ity of
> > the system as a whole".
> >
> >=C2=A0 =C2=A0 o=C2=A0 Attacker replacing the packet on which the N= SH is imposed with a
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0bogus packet.
> >
> > I'd probably say "modified or bogus".
> >
> >=C2=A0 =C2=A0 In an SFC-enabled domain where the above attacks are= possible, (1)
> >
> > This is perhaps ambiguous about whether an "any" or &qu= ot;all" criterion
> > should be used.=C2=A0 Perhaps that's desired :)
> >
> >
> >
> >
--00000000000007977405c7b3bf2d-- From nobody Fri Jul 23 00:11:13 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549B23A079F; Fri, 23 Jul 2021 00:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5swwFOSx3n9c; Fri, 23 Jul 2021 00:10:58 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 4FC013A0799; Fri, 23 Jul 2021 00:10:57 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id u3so467071lff.9; Fri, 23 Jul 2021 00:10:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wMwkPLvg+W7cpSI6DzJQ/rINOwA4vanPUwtlyL9h18c=; b=q8LMlK8DqDJCjLVLtbs40mFQHzWGywij9Fv9E3vRK9G00hzltMo5C+Zfw746eTufum zdV6VwNwgbAAPZLJcF+UtbrtcitAot/DOyiA/X3jhreKc7p5OAVLk1PREYCMEQSI31j+ z+PQIwtENSSB9BOhb1Qf7PoRGnhQkFCtE+28xJu7HsWjtPy8TgRrye0W9t6TCRTRkgs2 akqtbJ5t3Puswf25eyZ62tabTnkKQTDBW/uyVV3CtV54GksUD1gh0tHJt3ThsK7bvEZ6 90ufUU/Bzjsrss1xg0PW/aeEdBCgxBw7cytsqDHzgto95TLz/r49PsN1aYhMIxM7JzyS v2mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wMwkPLvg+W7cpSI6DzJQ/rINOwA4vanPUwtlyL9h18c=; b=t39hUp9omSeVjFGKkVea1aoYDdtZRGgU06l9l6fkPNNFeXbc8qJFSyRMW8f8+KPwj5 oMh7l8rSZjoUoU1NYsRn08wBbcHhwm1DXMuTWPHUgcP39BIWxKCToWfr9ROrJpgRC+rF nGppZzQtYC/SzsmDZwCoAgeJpoon3M1EkdCmZ573YvCrf9pO/oICzb0W8pCkH8spi8js L1jnzrSu20bKMv0iHOeH6q29YtNGEfhpVOkYByvJKk4lg5Fb0v8Ne7zXty/d4uxFD0H3 dddcZUZcjfhyQ64ri4hHqX5a4ciTpSnwqxWTzujsoz1J1IF+BiMcI43TGoIlHJ2uA2B5 C21Q== X-Gm-Message-State: AOAM533PROsJHjqZmvJ4t50bn22MWfnh5HkfZrKzaS45Lh0ljw4HSBZ2 KD3WAKykUNrmsqlVzEbFKmdeLQ35QFt6uGokYPQ= X-Google-Smtp-Source: ABdhPJyUYJjhBJRo1dzk7eiLMGhy5ez8DdsHyKe5wKOrkdsJ7v8ETSsUqz2HP0EEKnUAIieT/XNO3ANNwvo4JwEY7sk= X-Received: by 2002:a19:5f53:: with SMTP id a19mr2201052lfj.111.1627024254771; Fri, 23 Jul 2021 00:10:54 -0700 (PDT) MIME-Version: 1.0 References: <162629795136.25767.17850752260179612361@ietfa.amsl.com> <14311_1626444945_60F19491_14311_347_2_787AE7BB302AE849A7480A190F8B9330353C02BD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20210721223957.GQ88594@kduck.mit.edu> In-Reply-To: <20210721223957.GQ88594@kduck.mit.edu> From: tirumal reddy Date: Fri, 23 Jul 2021 12:40:42 +0530 Message-ID: To: Benjamin Kaduk Cc: Mohamed Boucadair , The IESG , "draft-ietf-sfc-nsh-integrity@ietf.org" , "sfc-chairs@ietf.org" , "sfc@ietf.org" , "gregimirsky@gmail.com" Content-Type: multipart/alternative; boundary="000000000000bf25e005c7c51acb" Archived-At: Subject: Re: [sfc] Benjamin Kaduk's Discuss on draft-ietf-sfc-nsh-integrity-06: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2021 07:11:07 -0000 --000000000000bf25e005c7c51acb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ben, Please see inline On Thu, 22 Jul 2021 at 04:10, Benjamin Kaduk wrote: > Hi Med, > > I see that Tiru has also replied, but I will respond inline here and then > process Tiru's comments. > > On Fri, Jul 16, 2021 at 02:15:44PM +0000, mohamed.boucadair@orange.com > wrote: > > Hi Ben, > > > > Many thanks again for the detailed review. Really helpful. > > > > Please see inline some replies to the COMMENT part (with references to > some DISCUSS points). > > > > Changes to address your COMMENTS/NITS can be tracked at: > https://tinyurl.com/nsh-integrity-latest. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De : Benjamin Kaduk via Datatracker [mailto:noreply@ietf.org] > > > Envoy=C3=A9 : mercredi 14 juillet 2021 23:26 > > > =C3=80 : The IESG > > > Cc : draft-ietf-sfc-nsh-integrity@ietf.org; sfc-chairs@ietf.org; > > > sfc@ietf.org; gregimirsky@gmail.com; gregimirsky@gmail.com > > > Objet : Benjamin Kaduk's Discuss on draft-ietf-sfc-nsh-integrity-06: > > > (with DISCUSS and COMMENT) > > > > > > Benjamin Kaduk has entered the following ballot position for > > > draft-ietf-sfc-nsh-integrity-06: Discuss > > > > > > When responding, please keep the subject line intact and reply to > > > all email addresses included in the To and CC lines. (Feel free to > > > cut this introductory paragraph, however.) > > > > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss- > > > criteria.html > > > for more information about DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/ > > > > > > > > > > > [...] > > > > > > > > > -------------------------------------------------------------------- > > > -- > > > COMMENT: > > > -------------------------------------------------------------------- > > > -- > > > > > > Section 3 > > > > > > o Both encrypted and unencrypted Context Headers MAY be included > > > in > > > the same NSH. That is, some Context Headers may be protected > > > while others do not need to be protected. > > > > > > In the security area we're pretty strongly moved towards a stance of > > > "encrypt everything that doesn't have a strong need to be plaintext > > > (since we don't want to assume that we can predict all threats and > > > attacks in advance), and QUIC has even taken that to new levels. > > > It's quite surprising to see "don't need to be protected" as a > > > justification for lack of encryption, rather than "need to be > > > unprotected". Given that we're going to be solving key distribution > > > for integrity protection anyway, it remains unclear to me why we > > > wouldn't just encrypt everything. > > > > [Med] This depends on the type of the context header, the capabilities > of SFs, local policies, performance implications, etc. Encrypting only a > subset of context headers is a feature we want to provide. > > > > Please note that the I-D gives a transition path for SFC from the > current plain text without any confidentiality or integrity protection to > start with integrity protection and eventually transition to (partial and > full) confidentiality and integrity protection. > > > > We can recommend deployments to consider using encryption for **any** > context header to prevent pervasive monitoring. > > That seems reasonable, essentially something analogous to my above note > about it being safest to make cleartext the exception rather than the > default, in terms of what justification is looked for (and I want to > reiterate that this whole remark is a non-blocking comment). > Updated text as follows : In order to prevent pervasive monitoring [RFC7258], it is RECOMMENDED to encrypt all Context Headers. All Context Headers carrying privacy-sensitive metadata MUST be encrypted; doing so, privacy- sensitive metadata is not revealed to attackers. Privacy specific threats are discussed in Section 5.2 of [RFC6973]. > > We understand that the wording "do not need to be protected" may not be > appropriate. We removed the sentence starting with "That is, some ...". > > Thank you! > > > > > > > Section 4.1.1 > > > > > > Is the column heading for the middle column of Table 1 referring to > > > the Base Header and "Service Path Header"? I'm not sure how to > > > interpret just "Service Header" other than the entire NSH, which > > > doesn't seem right... > > > > [Med] That is in reference to what we say in Section 3 that: > > > > o Base Header: Provides information about the service header and th= e > > payload protocol. > > The "base header" part is not what I'm unsure about. > To clarify, https://datatracker.ietf.org/doc/html/rfc8300#section-2.1 > describes the NSH (Network Service Header) as a single header that's > composed of a Base Header, a Service Path Header, and Context Header(s). > If we just write "Service Header", I have to pick whether that refers to > the (Network) Service Header or the Service (Path) Header. The unqualifi= ed > "service header" is used a couple times in RFC 8300, but in my (hasty) > reading is referring to the entire NSH. My understanding of the contents > of table 1 are that this column refers to the Service Path Header, but I > would like to see that written out more clearly in the text. > Thanks, fixed. > > > > > > > The Service Path Header (Section 2 of [RFC8300]) is not encrypted > > > because SFFs use Service Index (SI) in conjunction with Service > > > Path > > > Identifier (SPI) for determining the next SF in the path. > > > > > > It's good to see this spelled out like this; I'd love to have this > > > kind of explanation for every un-encrypted protocol element. > > > > > > Section 4.1.2 > > > > > > The solution provides integrity protection for the NSH data. Two > > > levels of assurance (LoAs) are supported. > > > > > > I see (reading onward) that the two LoAs just differ in what is > > > covered by the integrity tag, but each involve only a single MAC. > > > There's a reasonable argument that when there are overlapping needs > > > for what data needs protecting and who needs access to it, that > > > multiple MACs (or encryption, if needed) are most appropriate, which > > > can be tailored to the respective needs. This is something that > > > Phillip Hallam-Baker has ascribed as the "short-blanket theory" of > > > cryptography, in that it's like a blanket that's too short to cover > > > everything you want, so you need to have more than one and put them > > > in partially overlapping layers. > > > Perhaps this "short-blanket theory" is more applicable to Discuss > > > point > > > (0) than what is covered by the MAC, though... > > > > > > The first level of assurance where all NSH data except the Base > > > Header are integrity protected (Figure 2). In this case, the NSH > > > imposer may be a Classifier, an NSH-aware SF, or an SFC Proxy. > > > SFFs > > > are not thus provided with authentication material. [...] > > > > > > There seems to be a gap in the chain of reasoning as to why SFFs are > > > not provided with authentication material. It seems that the intent > > > is something along the lines of considering which entities need > > > access to the key material in order to successfully add an NSH or > > > update context headers, but that alone is not itself cause to say > > > that other entities can never be provided with the keys (subject to > > > the security considerations of group-shared PSKs, of course). > > > > [Med] The two levels are there for several reasons: > > * ease deployment: have an option that does not involve SFFs. > > * performance considerations of SFFs > > I am sure there are reasons to have this as an option; my concern here is > in some sense editorial in that the text includes a conclusion ("thus") b= ut > does not include a chain of logical reasoning that guides the reader to > believe that conclusion. I was hoping to have a bit more text in the > document that justifies the claim. > The primary job of SFF is to forward traffic to the appropriate SF, it does not need access to the metadata in the context headers. However, if a deployment requires SFF to access the metadata in the context headers, KMS can give access to the keying material to authorized SFF. I will add reference to https://datatracker.ietf.org/doc/html/rfc7665#section-4.3, it discusses the role of SFF in SFC. > > > > > > Furthermore, if a particular SFF is trusted, it may have grounds to > > > verify the integrity tag even if it is administratively prohibited > > > from writing such a tag. > > > > [Med] Agree, but we wanted to keep only two clear LoAs. > > > > > > > > In both levels of assurance, the unencrypted Context Headers and > > > the > > > packet on which the NSH is imposed are subject to integrity > > > protection. > > > > > > Surely any encrypted Context Headers are also given integrity > > > protection, as excluding them from the MAC computation would be > > > quite complex. I see that the encrypted context headers are not > > > part of the AAD input, but in the AEAD model the ciphertext is still > > > given integrity protection! > > > > [Med] The text you quoted is here to remind that the original NSH packe= t > is integrity protected as this may be missed by the reader. Likewise, tha= t > same protection is provided to context headers, even when unencrypted. > > Hmm, maybe the sentiment is along the lines of "the integrity protection > provided by the cryptographic mechanism is extended to also provide > protection for the unencrypted Context Headers and the packet on which th= e > NSH is imposed". > Looks good, I will update the draft. > > > > > > > Section 4.2 > > > > > > The authenticated encryption algorithm defined in [RFC7518] is > > > used > > > to provide NSH data integrity and to encrypt the Context Headers > > > that > > > carry privacy-sensitive metadata. > > > > > > RFC 7518 (JSON Web Algorithms) is a very surprising reference for > > > generic AEAD encryption. > > > > [Med] FYI, we used to have such reference in > draft-rebo-sfc-nsh-integrity-00: > > > > The Authenticated Encryption with Associated Data (AEAD) algorithm > > [RFC5116] is used to provide NSH data integrity and to encrypt > > privacy-sensitive metadata. > > I guess that I'm trying to make a distinction between an AEAD "interface" > as an abstraction, and a particular combination of cryptographic primtive= s > used to provide that interface. It can be useful to reference RFC 5116 f= or > "what is an AEAD" even if a specific construction from RFC 5116 is not > used. For example, within the boringssl cryptographic library, the TLS > ciphersuites that use AES-CBC+HMAC are still treated as providing the AEA= D > interface, as a simplifying abstraction. > > The AES-CBC+HMAC instantiation of AEAD is fairly widespread, and it may b= e > reasonable to just present it in its own right without reference to a > previous incarnation like RFC 7518. But I don't have particularly strong > feelings in this regard. > Removed reference to RFC 7518. > > > We changed the spec because we wanted to control by design the nodes > that are allowed to access encrypted data vs integrity-only. BTW, we sent= a > note to the saag mailing list right after we changed our design in the ho= pe > to have more eyes on what we are doing, but unfortunately we didn't get > much attention. > > I guess this was > https://mailarchive.ietf.org/arch/msg/saag/HOaeRhyJX_RdqLu-XFitNddAd-I/ > and > it looks like I skimmed the draft for a quick reply but didn't look in > depth. I'm not even sure if I even processed Tiru's reply to me at the > time that called out the separation of ENC_KEY and MAC_KEY... > > > Our understanding of your review is that you are not against using > ENC_KEY and MAC_KEY, but you prefer AES-GCM over CBC. We are considering > the following change (not yet implemented): > > I'm not entirely sure if the summary you write reflects my sentiment, sin= ce > there's a bit of a subtlety AES-GCM+HMAC seems like it will provide the > properties we need for this mechanism, but AES-CTR+GHASH does not. Since > you do mention HMAC still in the NEW text, that is promising. > > > OLD: > > > > Classifiers, NSH-aware SFs, and SFC proxies MUST implement the > > AES_128_CBC_HMAC_SHA_256 algorithm and SHOULD implement the > > AES_192_CBC_HMAC_SHA_384 and AES_256_CBC_HMAC_SHA_512 algorithms. > > > > Classifiers, NSH-aware SFs, and SFC proxies MUST implement the HMAC- > > SHA-256-128 algorithm and SHOULD implement the HMAC-SHA-384-192 and > > HMAC-SHA-512-256 algorithms. > > > > SFFs MAY implement the aforementioned cipher suites and HMAC > > algorithms. > > > > Note: The use of Advanced Encryption Standard (AES) in Galois/ > > Counter Mode (GCM) + HMAC may have CPU and packet size > > implications (need for a second 128-bit authentication tag). > > > > NEW: > > > > Classifiers, NSH-aware SFs, and SFC proxies MUST implement the > > AES_128_GCM algorithm and SHOULD implement the > > AES_192_GCM and AES_256_GCM algorithms. > > > > Classifiers, NSH-aware SFs, and SFC proxies MUST implement the HMAC- > > SHA-256-128 algorithm and SHOULD implement the HMAC-SHA-384-192 and > > HMAC-SHA-512-256 algorithms. > > > > SFFs MAY implement the aforementioned cipher suites and HMAC > > algorithms. > > > > We will have to refer to RFC5116 and [GCM] > > > > [GCM] Dworkin, M., "Recommendation for Block Cipher Modes of > > Operation: Galois/Counter Mode (GCM) and GMAC", > > National Institute of Standards and Technology SP 800- > > 38D, November 2007. > > > > With that, we don't need to cite RFC7518. > > Ok. > > > > > Continuing on, it becomes clear that we in > > > fact do not want a generic AEAD operation here, but instead have > > > need for separation of encryption and integrity protection due to > > > the various separations of roles that are possible. > > > > [Med] That's it! > > > > Because this is > > > a divergence from current best practices (use of native AEAD cipher > > > modes like GCM, SIV, etc.), I might suggest a rather different > > > introductory material: > > > > > > % The AEAD interface specified in RFC 5116 is a very powerful tool > > > for % providing strong confidentiality and integrity protection for > > > protocol % messages, and has become quite widely adopted as a > > > result. For % protecting NSH data we adhere to the spirit of the > > > AEAD interface but % use a slightly modified version in order to > > > remain consistent with the % privilege separation needed (e.g., in > > > the second level of assurance, % SFFs need to be able to update the > > > message integrity tag but do not % need access to the decrypted > > > plaintext). Accordingly, a compound AEAD % mechanism combining CBC > > > encryption and HMAC integrity tag is used, so % that distribution of > > > the encryption key can be limited. Rather than % define a new > > > scheme from scratch, the AES_CBC_HMAC_SHA2 scheme from % [RFC7518] > > > is used. In order to simplify key distribution, a single % secret > > > key material seed K is used, which can be kept private % centrally > > > or distributed to all parties that will have access to % decrypted > > > plaintext, and the secondary keys MAC_KEY and ENC_KEY are % derived > > > from K as discussed in Section 5.2.2.1 of [RFC7518]. Entities % > > > that need to update the integrity tag but are not authorized to see > > > % the decrypted plaintext will only receive MAC_KEY and not K or % > > > ENC_KEY. > > > > [Med] I guess, the comment will not be relevant after mandating AES-GCM= . > > Not in the same way, no. > In some sense we are still using an AEAD interface, but we have two layer= s > of integrity tag because we need to be able to have one tag that is > validatable by some parties who are not authorized to be able to read or > modify the plaintext data. > Yes, now we have two layers of message integrity provided by AES_GCM and HMAC. > > > > > > > o If the Context Headers are not encrypted, the Hashed Message > > > Authentication Mode (HMAC) algorithm discussed in [RFC4868] is > > > used to protect the integrity of the NSH data. > > > > > > It's not clear to me that this is adding much value; HMAC is used > > > whether or not there are encrypted headers, and the RFC 4868 > > > reference is rather odd (see also my Discuss point (2)). > > > > > > The advantage of using the authenticated encryption algorithm is > > > that > > > NSH-aware SFs and SFC proxies only need to re-compute the message > > > integrity of the NSH data after decrementing the Service Index > > > (SI) > > > and do not have to re-compute the ciphertext. The other > > > advantage is > > > that SFFs do not have access to the ENC_KEY and cannot act on the > > > encrypted Context Headers and, only in case of the second level > > > of > > > assurance, SFFs do have access to the MAC_KEY. Similarly, an > > > NSH- > > > aware SF or SFC Proxy not allowed to decrypt the Context Headers > > > will > > > not have access to the ENC_KEY. > > > > > > [If my above suggestion is used, this text has probably become > > > mostly redundant and could be trimmed down or removed.] > > > > > > The authenticated encryption process takes as input four-octet > > > strings: a secret key (K), a plaintext (P), Additional > > > Authenticated > > > Data (A) (which contains the data to be authenticated, but not > > > encrypted), and an Initialization Vector (IV). The ciphertext > > > value > > > (E) and the Authentication Tag value (T) are provided as outputs. > > > > > > In order to decrypt and verify, the cipher takes as input K, IV, > > > A, > > > T, and E. The output is either the plaintext or an error > > > indicating > > > that the decryption failed as described in Section 5.2.2.2 of > > > [RFC7518]. > > > > > > This seems true for the abstract AEAD interface, but since we're > > > peeling off the HMAC integrity tag for standalone use, we may need > > > to say something about what inputs/outputs are needed for just using > > > the integrity tag without doing decryption. In particular, we > > > cannot use K as an input for standalone HMAC verification! > > > > > > Also, this is just the generic AEAD interface, so RFC 5116 is > > > probably a more apropos reference than RFC 7518. > > > > [Med] As suggested above, we can refer to RFC5116 instead of RFC7518. > > > > > > > > Section 4.3 > > > > > > Note: The use of Advanced Encryption Standard (AES) in Galois/ > > > Counter Mode (GCM) + HMAC may have CPU and packet size > > > implications (need for a second 128-bit authentication tag). > > > > > > [This might also be redundant if my earlier proposal is accepted.] > > > > > > Section 4.4 > > > > > > The document does not assume nor preclude the following: > > > > > > o The same keying material is used for all the service functions > > > used within an SFC-enabled domain. > > > > > > o Distinct keying material is used per SFP by all involved SFC > > > data > > > path elements. > > > > > > o Per-tenant keys are used. > > > > > > I suggest a forward reference to the security considerations with a > > > brief note that the risk involved in using a group-shared symmetric > > > key increases with the size of the group to which it is shared. > > > > [Med] OK. Done. > > > > > > > > In order to accommodate deployments relying upon keying material > > > per > > > SFC/SFP and also the need to update keys after encrypting NSH > > > data > > > for a certain amount of time, this document uses key identifiers > > > to > > > unambiguously identify the appropriate keying material. Doing so > > > allows to address the problem of synchronization of keying > > > material. > > > > > > I'd suggest making a statement about the scope in which key > > > identifiers need to be unique. > > > > [Med] That depends on the bullet mentioned above (ex. per-tenant). I'm > not sure adding the sentence adds much value as the scope tweaking still > deployment-specific. > > If it takes a lot of text to describe accurately it may not be worth doin= g, > sure. > > > > > > > Section 4.5 > > > > > > An NSH-aware SF or SFC Proxy that needs to decrypt some Context > > > Headers uses ENC_Key and the decryption algorithm for the key > > > identifier being carried in the NSH. > > > > > > I think we need to say that decryption MUST NOT proceed unless the > > > integrity tag has been successfully validated. To decrypt without > > > checking the integrity tag violates the AEAD interface. > > > Alternately, we could only ever describe decryption as the AEAD > > > operation that uses K as input (not just ENC_KEY) -- =C2=A77.6 seems = to > > > attempt to take this latter approach, but the document as a whole is > > > not consistent about it. > > > > [Med] This section is about introducing the new MAC context headers. I > don't think this is the right place to mention this. > > > > BTW, the order you mentioned is what is implied by the procedure: 7.5 > (NSH Data Validation) and then 7.6 (Decryption of NSH Metadata). Invalid > data are discarded as part of 7.5. > > > > No problem to add a note to 7.6 if you think this is really needed. > > It may be best to wait and see what things shape out to be after other > changes. > > > > > > > Section 5, 5.x > > > > > > I strongly suggest changing "Key Length" to "keyid length", since > > > there is already convention on "key length" (e.g., for AES-128 vs > > > AES-192 vs AES-256). > > > > [Med] Fixed as per a comment from Eric. > > > > > > > > Section 5.1 > > > > > > Key Identifier: Carries a variable-length Key Identifier object > > > used > > > to identify and deliver keys to SFC data plane elements. This > > > identifier is helpful to accommodate deployments relying upon > > > keying material per SFC/SFP. The key identifier helps in > > > resolving the problem of synchronization of keying material. > > > > > > I suggest clarifying that a single key identifier is used to lookup > > > both the associated ENC_KEY and the associated MAC_KEY (or, > > > alternately, that it is logically bound to K and remind the reader > > > that ENC_KEY and MAC_KEY are extracted from K and might be > > > separately distributed). > > > > [Med] Added this NEW: > > > > "A single key identifier is used to lookup both the ENC_KEY and the > MAC_KEY associated with a key." > > > > > > > > Key Length: Variable. Carries the length of the key identifier. > > > [...] > > > IV Length: Carries the length of the IV (Section 5.2 of > > > [RFC7518]). > > > If encryption is not used, IV length is set to zero (that is, > > > no > > > "Initialization Vector" is included). > > > > > > Please also specify that the Key/IV lengths are measured in bytes > > > > [Med] Fixed per a comment from Eric. > > If he keeps this up, we'll have to nominate him for SEC AD... > > > > (the reference for IV length, at least, talks about IVs in bits). > > > > > > I strongly suggest using a value other than zero as the sentinel > > > value for "no encryption" -- there already exist modes like AES-SIV > > > (RFC 5297) that do not require an IV input, which would be a natural > > > use for zero-length IV. > > > > [Med] What is the advantage of using a value other than zero when > encryption is not included? > > There may arise cases in the future where it's desired to use an encrypti= on > scheme that takes a zero-length IV. If the zero-length IV already has th= e > semantics of "encryption not used", then that needlessly precludes such > future flexibility. > Good point, added the following line: If the Context Headers are only integrity protected, "Nonce Length" is set to zero (that is, no "Nonce" is included). The "Nonce Length" can be set to zero based on the encryption algorithm used to encrypt the Context Headers. > > > > > > > Additionally, one might imagine using a non-zero-length IV as input > > > to an HMAC calculation as a per-message nonce. On cursory > > > examination, since we are already using timestamp-based replay > > > detection, the additional nonce is unlikely to add much value, but > > > I'm not willing to completely rule it out on the basis of the > > > minimal analysis I performed. > > > > > > Section 7.1 > > > > > > Only one instance of "MAC and Encrypted Metadata" Context Header > > > (Section 5) is allowed. If multiple instances of "MAC and > > > Encrypted > > > Metadata" Context Header are included in an NSH packet, the SFC > > > data > > > > > > I think Roman may have mentioned this already, but please clarify if > > > this is one instance per NSH or per packet (e.g., in hierarchical > > > SFC we might have more than one NSH in a packet). > > > > [Med] I confirm. > > (I trust it will make it into the document, based on Roman's review.) > > > > > > > Please also clarify it if is permitted to have both MAC#1 and MAC#2 > > > present in the same packet. (IIUC there are not obvious situations > > > where such a setup would be useful, but it's still good to be clear > > > about expectations.) > > > > [Med] It is not allowed to have both. This is why we are using the > generic term: "instance of "MAC and Encrypted Metadata" Context Header". > That term is used through the document when we refer indifferently to MAC= #1 > and MAC#2. > > That is what I suspected, so thank you for confirming. I would propose t= o > have in one location a clear statement that MAC#1 and MAC#2 are not allow= ed > together, but I do not insist on it. > > > > > > > Section 7.2 > > > > > > If the Context Headers are not encrypted, the HMAC algorithm > > > discussed in [RFC4868] is used to integrity protect the target > > > NSH > > > data. [...] > > > > > > It's not really clear to me why RFC 4868 is the right reference > > > here, as opposed to (e.g.) RFC 2104. In particular, see my Discuss > > > point (2). > > > > [Med] We think that RFC 4868 is the right reference as RFC 2014 does no= t > discuss any of the HMAC algorithms used in this specification. > > In my experience it's fine to say just that "we use HMAC [RFC 2014] as > instantiated with [reference-for-hash]", so whether or not th= e > specific construction (e.g., as from RFC 4868) appears in the reference i= s > not critical. > Fixed. > > > > > > > The Message Authentication Code (T) computation process can be > > > illustrated as follows: > > > > > > T =3D HMAC-SHA-256-128(MAC_KEY, A) > > > > > > I agree with the other reviewer that wondered about just using "MAC" > > > (or maybe "HMAC") rather than "HMAC-SHA-256-128" here (I do see the > > > "can be illustrated as" qualifier). > > > > > > It's also a little weird to reuse T and A from the AEAD construction > > > (or RFC 4868) here without additional discussion on how they apply > > > and how the value of A is constructed. > > > > [Med] Noted. We made already this change: s/A/target NSH data. > > > > > > > > An entity in the SFP that intends to update the NSH MUST follow > > > the > > > above behavior to maintain message integrity of the NSH for > > > subsequent validations. > > > > > > I'm not sure that "intends to" is needed; the requirement applies to > > > actions, not intent. > > > > [Med] Fair. Fixed, thanks. > > > > > > > > Section 7.3 > > > > > > In an SFC-enabled domain where pervasive monitoring [RFC7258] is > > > possible, all Context Headers carrying privacy-sensitive metadata > > > MUST be encrypted; [...] > > > > > > I agree with the other reviewer that noted that this seems to > > > effectively be an unqualified "MUST", since there is always some > > > possibility of monitoring. > > > > > > MAC_KEY =3D initial MAC_KEY_LEN octets of K, > > > ENC_KEY =3D final ENC_KEY_LEN octets of K, > > > E =3D CBC-PKCS7-ENC(ENC_KEY, P), > > > M =3D MAC(MAC_KEY, A || IV || E || AL), > > > T =3D initial T_LEN octets of M. > > > MAC and Encrypted Metadata =3D E || T > > > > > > I recognize that this is just copy+paste from RFC 7518 (with the > > > addition of the last line), but it seems a glaring omission that the > > > CBC-PKCS7-ENC() invocation does not include the IV as an input! > > > (In =C2=A75.2.2.1 of RFC 7518 we do see that "The plaintext is CBC > > > encrypted using PKCS #7 padding using ENC_KEY as the key and the > > > IV", so it's just the figure/formula that omits the IV.) > > > > > > We also don't define or mention T_LEN in this document other than in > > > this formula and the analogous one for MAC-without-encryption, which > > > might be worth remedying. > > > > [Med] If we mandate AES_GCM, all the above text will be removed. > > > > > > > > Section 7.4 > > > > > > I suggest adding another word (like "Prevention") to the section > > > title. > > > > > > > [Med] Fixed. > > > > > The received NSH is accepted by an NSH-aware node if the > > > Timestamp > > > (TS) in the NSH is recent enough to the reception time of the NSH > > > (TSrt). The following formula is used for this check: > > > > > > -Delta < (TSrt - TS) < +Delta > > > > > > (There's no real reason why the accepted timestamp skew parameter > > > Delta needs to be symmetric in the positive and negative > > > directions.) > > > > [Med] This was to accommodate any sync issues. > > Having it extend in both directions is clearly useful, to cover all kinds > of sync issues. But the range might equally as well be -Epsilon < (TSrt = - > TS) < +Delta for Delta !=3D Epsilon. Perhaps that's needless complexity,= but > it seemed worth raising the idea for discussion. > > > > > > > Replay attacks within the Delta window may be detected by an NSH- > > > aware node by recording a unique value derived, for example, from > > > the > > > NSH data and Original packet (e.g., using SHA2). [...] > > > > > > Note that the unique value MUST NOT use as input any bits that are > > > not covered by the MAC. > > > > [Med] Agree, but we don't specify the bits that are used. > > This is a very tempting and easy-to-make mistake; I think we should > preemptively warn the implementor against it, regardless of whether we al= so > provide a specific suggestion (e.g., the next line of this email). > > Indeed, just using the MAC itself as the > > > unique value would be a fairly straightforward scheme, I think. > Sure, updated text as follows: Replay attacks within the Delta window may be detected by an NSH-aware node by recording a unique value derived, for example, to record a unique value derived from the MAC field value. Such an NSH-aware node will detect and reject duplicates. > > > > [Med] Thanks. > > > > > > > Section 7.5 > > > > > > When an SFC data plane element receives an NSH packet, it MUST > > > first > > > ensure that a "MAC and Encrypted Metadata" Context Header is > > > included. [...] > > > > > > This sort of requirement (as written) would seem to support the > > > position of some other reviewers that this document would need to > > > formally update RFC 8300. > > > > [Med] Added "When an SFC data plan element conforms to this > specification," to address one of Roman's comments. > > > > > > > > Section 9 > > > > > > We might discuss that this mechanism is only for metadata type 2 and > > > not type 1 (as well as that with the relatively small fixed length > > > of type 1 metadata, it's quite challenging to provide useful > > > cryptographic protection), so that type-1 metadata still has no > > > generic protection mechanism. A given metadata element could define > > > its own protection scheme, of course. > > > > [Med] We already have the following in the introduction: > > > > This specification is only > > applicable to NSH MD Type 0x02 (Section 2.5 of [RFC8300]). > > Yes. > There is some security consideration to limiting this mechanism to type 2 > only, in that type 1 exists and has no defined method of protection. > My proposal is to mention that this mechanism is not fully generic (i.e., > does not cover type 1 metadata) and a little bit of explanation of why. > Done, added following text: This specification is not applicable to NSH MD Type 0x01 (Section TBD of RFC8300) because it only allows a Fixed-Length Context Header whose size is 16-bytes and is not sufficient to accommodate both the metadata and message integrity of the NSH data. > > > > > > The attacks discussed in [I-D.nguyen-sfc-security-architecture] > > > are > > > handled owing to the solution specified in this document, except > > > for > > > attacks dropping packets. [...] > > > > > > >From a very quick read, draft-nguyen-sfc-security-architecture > > > proposes > > > a probe-based scheme that monitors all middleboxes (or at least > > > those in the expected path) to detect a middlebox-bypass attack and > > > verify that the probe traversed the expected SFP. I am not sure > > > that this document on its own suffices to prevent the middlebox- > > > bypass attack for all traffic (i.e., the probe-based scheme might > > > still be needed). If some network entities know what the expected > > > service index will be for a given SPI at a given node, then > > > middlebox-bypass attacks could be natively detected, but my > > > understanding was that such advance knowledge of expected service > > > index was not going to be available. > > > > [Med] The SF bypass can be detected if SI was manipulated on path > because integrity check will fail. > > Does each SF or some other on-path entity know which (SFP, SI) are > allowed/expected for traffic it receives? If not, then just moving the > packets around differently without changing their contents is my concern. > This attack can be detected using the proof of transit mechanism discussed in https://datatracker.ietf.org/doc/draft-ietf-sfc-proof-of-transit/ > > > > > > > The solution specified in this document does not provide data > > > origin > > > authentication. > > > > > > I would have expected more in-depth discussion of the security > > > considerations for a group-shared PSK scheme, including how the risk > > > of key loss/compromise goes up when the key is distributed to more > > > locations. > > > > [Med] That's part of the key management, declared out of scope. > > Even with the details of how keys are shared/distributed being out of > scope, I still would have expected discussion of the risks of shared keys= . > Perhaps my expectations are wrong (it has happened before and will happen > again), but that's still what I expect. > Agreed, added following line: The group key management protocol related security considerations discussed in Section 8 of [RFC4046] needs to be taken into consideration. > > > > > > > Section 9.1 > > > > > > No device other than the NSH-aware SFs in the SFC-enabled domain > > > should be able to update the integrity protected NSH data. > > > > > > What about classifiers and SFC proxies? > > > > [Med] Good catch: proxies should be mentioned as well as > re-classification. We can't just talk about classification as this is abo= ut > updating the MAC. > > > > The NEW text that also takes into account a comment from John is as > follows: > > > > It is expected that specific devices in the SFC-enabled domain will > > be configured such that no device other than the classifiers (when > > reclassification is enabled), NSH-aware SFs, and SFC proxies will be > > able to update the integrity protected NSH data (Section 7.1), and > > also such that no device other than the NSH-aware SFs and SFC proxie= s > > will be able to decrypt and update the Context Headers carrying > > sensitive metadata (Section 7.1). > > > > > > > > Section 9.2 > > > > > > I expected to see some remarks here analogous to the second > > > paragraph of > > > =C2=A79.1 (even if just by reference to that section). > > > > [Med] Added this NEW sentence: > > > > Similar to Section 9.1, no device other than the NSH-aware SFs and > > SFC proxies in the SFC-enabled domain should be able to decrypt and > > update the Context Headers carrying sensitive metadata. > > Thanks! > > > > > > > Section 9.3 > > > > > > Section 5.6 of [RFC8633] describes best current practices to be > > > considered in deployments where SFC data plane elements use NTP > > > for > > > time synchronization purposes. > > > > > > The referenced section covers NTP symmetric mode only. > > > > [Med] Yes because we think that=E2=80=99s the symmetric mode is better = vs. > broadcast with trusted modes. > > > > Is > > > client/server mode not a BCP for trusted networks and > > > broadcast/symmetric the only options? > > > > [Med] Not sure to get this comment. > > Sorry, let me try again. "I do not operate an NTP service and have littl= e > knowledge of NTP operational best practices. I can easily believe that N= TP > symmetric mode is a good option ("best current practice") on a trusted > network, but I could also easily believe that NTP client/server mode woul= d > equally be a useful option on a trusted network. Is there a reason to > prefer symmetric over client/server mode?" > It seems that you mostly answered this above, though just with a "yes" an= d > not the actual reason (the actual reason would just be for my own curiosi= ty > and is not expected to appear in the document, so please feel free to dro= p > the topic). > I think by mistake we pointed to Section 5.6, the intention was to point to RFC8333 which discusses various modes including client/server mode with pre-shared keys. Fixed text. Cheers, -Tiru > Thanks, > > Ben > --000000000000bf25e005c7c51acb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ben,

Please see inline
On = Thu, 22 Jul 2021 at 04:10, Benjamin Kaduk <kaduk@mit.edu> wrote:
Hi Med,

I see that Tiru has also replied, but I will respond inline here and then process Tiru's comments.

On Fri, Jul 16, 2021 at 02:15:44PM +0000, mohamed.boucadair@orange.com wrote: > Hi Ben,
>
> Many thanks again for the detailed review. Really helpful.
>
> Please see inline some replies to the COMMENT part (with references to= some DISCUSS points).
>
> Changes to address your COMMENTS/NITS can be tracked at: https://tinyurl.com/nsh-integrity-latest.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De=C2=A0: Benjamin Kaduk via Datatracker [mailto:noreply@ietf.org]
> > Envoy=C3=A9=C2=A0: mercredi 14 juillet 2021 23:26
> > =C3=80=C2=A0: The IESG <iesg@ietf.org>
> > Cc=C2=A0: draft-ietf-sfc-nsh-integrity@ietf.org; sfc-chairs@ietf.org;
> > sfc@ietf.org; gregimirsky@g= mail.com; gr= egimirsky@gmail.com
> > Objet=C2=A0: Benjamin Kaduk's Discuss on draft-ietf-sfc-nsh-i= ntegrity-06:
> > (with DISCUSS and COMMENT)
> >
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-sfc-nsh-integrity-06: Discuss
> >
> > When responding, please keep the subject line intact and reply to=
> > all email addresses included in the To and CC lines. (Feel free t= o
> > cut this introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.org/iesg/stat= ement/discuss-
> > criteria.html
> > for more information about DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found her= e:
> > https://datatracker.ietf.org= /doc/draft-ietf-sfc-nsh-integrity/
> >
> >
> >
> [...]
> >
> >
> > -----------------------------------------------------------------= ---
> > --
> > COMMENT:
> > -----------------------------------------------------------------= ---
> > --
> >
> > Section 3
> >
> >=C2=A0 =C2=A0 o=C2=A0 Both encrypted and unencrypted Context Heade= rs MAY be included
> > in
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0the same NSH.=C2=A0 That is, some Conte= xt Headers may be protected
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0while others do not need to be protecte= d.
> >
> > In the security area we're pretty strongly moved towards a st= ance of
> > "encrypt everything that doesn't have a strong need to b= e plaintext
> > (since we don't want to assume that we can predict all threat= s and
> > attacks in advance), and QUIC has even taken that to new levels.<= br> > > It's quite surprising to see "don't need to be prote= cted" as a
> > justification for lack of encryption, rather than "need to b= e
> > unprotected".=C2=A0 Given that we're going to be solving= key distribution
> > for integrity protection anyway, it remains unclear to me why we<= br> > > wouldn't just encrypt everything.
>
> [Med] This depends on the type of the context header, the capabilities= of SFs, local policies, performance implications, etc. Encrypting only a s= ubset of context headers is a feature we want to provide.
>
> Please note that the I-D gives a transition path for SFC from the curr= ent plain text without any confidentiality or integrity protection to start= with integrity protection and eventually transition to (partial and full) = confidentiality and integrity protection.
>
> We can recommend deployments to consider using encryption for **any** = context header to prevent pervasive monitoring.

That seems reasonable, essentially something analogous to my above note
about it being safest to make cleartext the exception rather than the
default, in terms of what justification is looked for (and I want to
reiterate that this whole remark is a non-blocking comment).

Updated text as follows :
   In order =
to prevent pervasive monitoring [RFC7258], it is RECOMMENDED
   to encrypt all Context Headers.  All Context Headers carrying
   privacy-sensitive metadata MUST be encrypted; doing so, privacy-
   sensitive metadata is not revealed to attackers.  Privacy specific
   threats are discussed in Section 5.2 of [RFC6973].

<= /div>

> We understand that the wording "do not need to be protected"= may not be appropriate. We removed the sentence starting with "That i= s, some ...".

Thank you!

> >
> > Section 4.1.1
> >
> > Is the column heading for the middle column of Table 1 referring = to
> > the Base Header and "Service Path Header"?=C2=A0 I'= m not sure how to
> > interpret just "Service Header" other than the entire N= SH, which
> > doesn't seem right...
>
> [Med] That is in reference to what we say in Section 3 that:
>
>=C2=A0 =C2=A0 o=C2=A0 Base Header: Provides information about the servi= ce header and the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0payload protocol.

The "base header" part is not what I'm unsure about.
To clarify, https://datatracker.ietf.org/do= c/html/rfc8300#section-2.1
describes the NSH (Network Service Header) as a single header that's composed of a Base Header, a Service Path Header, and Context Header(s). If we just write "Service Header", I have to pick whether that re= fers to
the (Network) Service Header or the Service (Path) Header.=C2=A0 The unqual= ified
"service header" is used a couple times in RFC 8300, but in my (h= asty)
reading is referring to the entire NSH.=C2=A0 My understanding of the conte= nts
of table 1 are that this column refers to the Service Path Header, but I would like to see that written out more clearly in the text.

Thanks, fixed.=C2=A0
=C2=A0

> >
> >=C2=A0 =C2=A0 The Service Path Header (Section 2 of [RFC8300]) is = not encrypted
> >=C2=A0 =C2=A0 because SFFs use Service Index (SI) in conjunction w= ith Service
> > Path
> >=C2=A0 =C2=A0 Identifier (SPI) for determining the next SF in the = path.
> >
> > It's good to see this spelled out like this; I'd love to = have this
> > kind of explanation for every un-encrypted protocol element.
> >
> > Section 4.1.2
> >
> >=C2=A0 =C2=A0 The solution provides integrity protection for the N= SH data.=C2=A0 Two
> >=C2=A0 =C2=A0 levels of assurance (LoAs) are supported.
> >
> > I see (reading onward) that the two LoAs just differ in what is > > covered by the integrity tag, but each involve only a single MAC.=
> > There's a reasonable argument that when there are overlapping= needs
> > for what data needs protecting and who needs access to it, that > > multiple MACs (or encryption, if needed) are most appropriate, wh= ich
> > can be tailored to the respective needs.=C2=A0 This is something = that
> > Phillip Hallam-Baker has ascribed as the "short-blanket theo= ry" of
> > cryptography, in that it's like a blanket that's too shor= t to cover
> > everything you want, so you need to have more than one and put th= em
> > in partially overlapping layers.
> > Perhaps this "short-blanket theory" is more applicable = to Discuss
> > point
> > (0) than what is covered by the MAC, though...
> >
> >=C2=A0 =C2=A0 The first level of assurance where all NSH data exce= pt the Base
> >=C2=A0 =C2=A0 Header are integrity protected (Figure 2).=C2=A0 In = this case, the NSH
> >=C2=A0 =C2=A0 imposer may be a Classifier, an NSH-aware SF, or an = SFC Proxy.
> > SFFs
> >=C2=A0 =C2=A0 are not thus provided with authentication material.= =C2=A0 [...]
> >
> > There seems to be a gap in the chain of reasoning as to why SFFs = are
> > not provided with authentication material.=C2=A0 It seems that th= e intent
> > is something along the lines of considering which entities need > > access to the key material in order to successfully add an NSH or=
> > update context headers, but that alone is not itself cause to say=
> > that other entities can never be provided with the keys (subject = to
> > the security considerations of group-shared PSKs, of course).
>
> [Med] The two levels are there for several reasons:
> * ease deployment: have an option that does not involve SFFs.
> * performance considerations of SFFs

I am sure there are reasons to have this as an option; my concern here is in some sense editorial in that the text includes a conclusion ("thus&= quot;) but
does not include a chain of logical reasoning that guides the reader to
believe that conclusion.=C2=A0 I was hoping to have a bit more text in the<= br> document that justifies the claim.

The = primary job of SFF is to forward traffic to the appropriate SF, it does not= need access to the metadata in the context headers. However, if a deployme= nt requires SFF to access the metadata in the context headers, KMS can give= access to the keying material to authorized SFF.=C2=A0

I will add reference to=C2=A0https://datatracker.ietf.org/doc/html/rfc7665= #section-4.3, it discusses the role of SFF in=C2=A0 SFC.=C2=A0
=C2=A0

>
> > Furthermore, if a particular SFF is trusted, it may have grounds = to
> > verify the integrity tag even if it is administratively prohibite= d
> > from writing such a tag.
>
> [Med] Agree, but we wanted to keep only two clear LoAs.
>
> >
> >=C2=A0 =C2=A0 In both levels of assurance, the unencrypted Context= Headers and
> > the
> >=C2=A0 =C2=A0 packet on which the NSH is imposed are subject to in= tegrity
> >=C2=A0 =C2=A0 protection.
> >
> > Surely any encrypted Context Headers are also given integrity
> > protection, as excluding them from the MAC computation would be > > quite complex.=C2=A0 I see that the encrypted context headers are= not
> > part of the AAD input, but in the AEAD model the ciphertext is st= ill
> > given integrity protection!
>
> [Med] The text you quoted is here to remind that the original NSH pack= et is integrity protected as this may be missed by the reader. Likewise, th= at same protection is provided to context headers, even when unencrypted. <= br>
Hmm, maybe the sentiment is along the lines of "the integrity protecti= on
provided by the cryptographic mechanism is extended to also provide
protection for the unencrypted Context Headers and the packet on which the<= br> NSH is imposed".

Looks good, I wil= l update the draft.=C2=A0
=C2=A0

> >
> > Section 4.2
> >
> >=C2=A0 =C2=A0 The authenticated encryption algorithm defined in [R= FC7518] is
> > used
> >=C2=A0 =C2=A0 to provide NSH data integrity and to encrypt the Con= text Headers
> > that
> >=C2=A0 =C2=A0 carry privacy-sensitive metadata.
> >
> > RFC 7518 (JSON Web Algorithms) is a very surprising reference for=
> > generic AEAD encryption.
>
> [Med] FYI, we used to have such reference in draft-rebo-sfc-nsh-integr= ity-00:
>
>=C2=A0 =C2=A0 The Authenticated Encryption with Associated Data (AEAD) = algorithm
>=C2=A0 =C2=A0 [RFC5116] is used to provide NSH data integrity and to en= crypt
>=C2=A0 =C2=A0 privacy-sensitive metadata.

I guess that I'm trying to make a distinction between an AEAD "int= erface"
as an abstraction, and a particular combination of cryptographic primtives<= br> used to provide that interface.=C2=A0 It can be useful to reference RFC 511= 6 for
"what is an AEAD" even if a specific construction from RFC 5116 i= s not
used.=C2=A0 For example, within the boringssl cryptographic library, the TL= S
ciphersuites that use AES-CBC+HMAC are still treated as providing the AEAD<= br> interface, as a simplifying abstraction.

The AES-CBC+HMAC instantiation of AEAD is fairly widespread, and it may be<= br> reasonable to just present it in its own right without reference to a
previous incarnation like RFC 7518.=C2=A0 But I don't have particularly= strong
feelings in this regard.

Removed refere= nce to RFC 7518.
=C2=A0

> We changed the spec because we wanted to control by design the nodes t= hat are allowed to access encrypted data vs integrity-only. BTW, we sent a = note to the saag mailing list right after we changed our design in the hope= to have more eyes on what we are doing, but unfortunately we didn't ge= t much attention.

I guess this was
https://mailarchive.ietf.org/= arch/msg/saag/HOaeRhyJX_RdqLu-XFitNddAd-I/ and
it looks like I skimmed the draft for a quick reply but didn't look in<= br> depth.=C2=A0 I'm not even sure if I even processed Tiru's reply to = me at the
time that called out the separation of ENC_KEY and MAC_KEY...

> Our understanding of your review is that you are not against using ENC= _KEY and MAC_KEY, but you prefer AES-GCM over CBC. We are considering the f= ollowing change (not yet implemented):=C2=A0

I'm not entirely sure if the summary you write reflects my sentiment, s= ince
there's a bit of a subtlety AES-GCM+HMAC seems like it will provide the=
properties we need for this mechanism, but AES-CTR+GHASH does not.=C2=A0 Si= nce
you do mention HMAC still in the NEW text, that is promising.

> OLD:
>
>=C2=A0 =C2=A0 Classifiers, NSH-aware SFs, and SFC proxies MUST implemen= t the
>=C2=A0 =C2=A0 AES_128_CBC_HMAC_SHA_256 algorithm and SHOULD implement t= he
>=C2=A0 =C2=A0 AES_192_CBC_HMAC_SHA_384 and AES_256_CBC_HMAC_SHA_512 alg= orithms.
>
>=C2=A0 =C2=A0 Classifiers, NSH-aware SFs, and SFC proxies MUST implemen= t the HMAC-
>=C2=A0 =C2=A0 SHA-256-128 algorithm and SHOULD implement the HMAC-SHA-3= 84-192 and
>=C2=A0 =C2=A0 HMAC-SHA-512-256 algorithms.
>
>=C2=A0 =C2=A0 SFFs MAY implement the aforementioned cipher suites and H= MAC
>=C2=A0 =C2=A0 algorithms.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Note: The use of Advanced Encryption Standar= d (AES) in Galois/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Counter Mode (GCM) + HMAC may have CPU and p= acket size
>=C2=A0 =C2=A0 =C2=A0 =C2=A0implications (need for a second 128-bit auth= entication tag).
>
> NEW:
>
>=C2=A0 =C2=A0 Classifiers, NSH-aware SFs, and SFC proxies MUST implemen= t the
>=C2=A0 =C2=A0 AES_128_GCM algorithm and SHOULD implement the
>=C2=A0 =C2=A0 AES_192_GCM and AES_256_GCM algorithms.
>
>=C2=A0 =C2=A0 Classifiers, NSH-aware SFs, and SFC proxies MUST implemen= t the HMAC-
>=C2=A0 =C2=A0 SHA-256-128 algorithm and SHOULD implement the HMAC-SHA-3= 84-192 and
>=C2=A0 =C2=A0 HMAC-SHA-512-256 algorithms.
>
>=C2=A0 =C2=A0 SFFs MAY implement the aforementioned cipher suites and H= MAC
>=C2=A0 =C2=A0 algorithms.
>
> We will have to refer to RFC5116 and [GCM]
>
>=C2=A0 =C2=A0 [GCM]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Dworkin, M., "= ;Recommendation for Block Cipher Modes of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Operatio= n: Galois/Counter Mode (GCM) and GMAC",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 National= Institute of Standards and Technology SP 800-
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 38D, Nov= ember 2007.
>
> With that, we don't need to cite RFC7518.

Ok.

>
>=C2=A0 Continuing on, it becomes clear that we in
> > fact do not want a generic AEAD operation here, but instead have<= br> > > need for separation of encryption and integrity protection due to=
> > the various separations of roles that are possible.
>
> [Med] That's it!
>
>=C2=A0 Because this is
> > a divergence from current best practices (use of native AEAD ciph= er
> > modes like GCM, SIV, etc.), I might suggest a rather different > > introductory material:
> >
> > % The AEAD interface specified in RFC 5116 is a very powerful too= l
> > for % providing strong confidentiality and integrity protection f= or
> > protocol % messages, and has become quite widely adopted as a
> > result.=C2=A0 For % protecting NSH data we adhere to the spirit o= f the
> > AEAD interface but % use a slightly modified version in order to<= br> > > remain consistent with the % privilege separation needed (e.g., i= n
> > the second level of assurance, % SFFs need to be able to update t= he
> > message integrity tag but do not % need access to the decrypted > > plaintext).=C2=A0 Accordingly, a compound AEAD % mechanism combin= ing CBC
> > encryption and HMAC integrity tag is used, so % that distribution= of
> > the encryption key can be limited.=C2=A0 Rather than % define a n= ew
> > scheme from scratch, the AES_CBC_HMAC_SHA2 scheme from % [RFC7518= ]
> > is used.=C2=A0 In order to simplify key distribution, a single % = secret
> > key material seed K is used, which can be kept private % centrall= y
> > or distributed to all parties that will have access to % decrypte= d
> > plaintext, and the secondary keys MAC_KEY and ENC_KEY are % deriv= ed
> > from K as discussed in Section 5.2.2.1 of [RFC7518].=C2=A0 Entiti= es %
> > that need to update the integrity tag but are not authorized to s= ee
> > % the decrypted plaintext will only receive MAC_KEY and not K or = %
> > ENC_KEY.
>
> [Med] I guess, the comment will not be relevant after mandating AES-GC= M.

Not in the same way, no.
In some sense we are still using an AEAD interface, but we have two layers<= br> of integrity tag because we need to be able to have one tag that is
validatable by some parties who are not authorized to be able to read or modify the plaintext data.

Yes, now we = have two layers of message integrity provided by AES_GCM and HMAC.=C2=A0
=C2=A0

> >
> >=C2=A0 =C2=A0 o=C2=A0 If the Context Headers are not encrypted, th= e Hashed Message
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Authentication Mode (HMAC) algorithm di= scussed in [RFC4868] is
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0used to protect the integrity of the NS= H data.
> >
> > It's not clear to me that this is adding much value; HMAC is = used
> > whether or not there are encrypted headers, and the RFC 4868
> > reference is rather odd (see also my Discuss point (2)).
> >
> >=C2=A0 =C2=A0 The advantage of using the authenticated encryption = algorithm is
> > that
> >=C2=A0 =C2=A0 NSH-aware SFs and SFC proxies only need to re-comput= e the message
> >=C2=A0 =C2=A0 integrity of the NSH data after decrementing the Ser= vice Index
> > (SI)
> >=C2=A0 =C2=A0 and do not have to re-compute the ciphertext.=C2=A0 = The other
> > advantage is
> >=C2=A0 =C2=A0 that SFFs do not have access to the ENC_KEY and cann= ot act on the
> >=C2=A0 =C2=A0 encrypted Context Headers and, only in case of the s= econd level
> > of
> >=C2=A0 =C2=A0 assurance, SFFs do have access to the MAC_KEY.=C2=A0= Similarly, an
> > NSH-
> >=C2=A0 =C2=A0 aware SF or SFC Proxy not allowed to decrypt the Con= text Headers
> > will
> >=C2=A0 =C2=A0 not have access to the ENC_KEY.
> >
> > [If my above suggestion is used, this text has probably become > > mostly redundant and could be trimmed down or removed.]
> >
> >=C2=A0 =C2=A0 The authenticated encryption process takes as input = four-octet
> >=C2=A0 =C2=A0 strings: a secret key (K), a plaintext (P), Addition= al
> > Authenticated
> >=C2=A0 =C2=A0 Data (A) (which contains the data to be authenticate= d, but not
> >=C2=A0 =C2=A0 encrypted), and an Initialization Vector (IV).=C2=A0= The ciphertext
> > value
> >=C2=A0 =C2=A0 (E) and the Authentication Tag value (T) are provide= d as outputs.
> >
> >=C2=A0 =C2=A0 In order to decrypt and verify, the cipher takes as = input K, IV,
> > A,
> >=C2=A0 =C2=A0 T, and E.=C2=A0 The output is either the plaintext o= r an error
> > indicating
> >=C2=A0 =C2=A0 that the decryption failed as described in Section 5= .2.2.2 of
> >=C2=A0 =C2=A0 [RFC7518].
> >
> > This seems true for the abstract AEAD interface, but since we'= ;re
> > peeling off the HMAC integrity tag for standalone use, we may nee= d
> > to say something about what inputs/outputs are needed for just us= ing
> > the integrity tag without doing decryption.=C2=A0 In particular, = we
> > cannot use K as an input for standalone HMAC verification!
> >
> > Also, this is just the generic AEAD interface, so RFC 5116 is
> > probably a more apropos reference than RFC 7518.
>
> [Med] As suggested above, we can refer to RFC5116 instead of RFC7518.<= br> >
> >
> > Section 4.3
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Note: The use of Advanced Encryption St= andard (AES) in Galois/
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Counter Mode (GCM) + HMAC may have CPU = and packet size
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0implications (need for a second 128-bit= authentication tag).
> >
> > [This might also be redundant if my earlier proposal is accepted.= ]
> >
> > Section 4.4
> >
> >=C2=A0 =C2=A0 The document does not assume nor preclude the follow= ing:
> >
> >=C2=A0 =C2=A0 o=C2=A0 The same keying material is used for all the= service functions
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0used within an SFC-enabled domain.
> >
> >=C2=A0 =C2=A0 o=C2=A0 Distinct keying material is used per SFP by = all involved SFC
> > data
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0path elements.
> >
> >=C2=A0 =C2=A0 o=C2=A0 Per-tenant keys are used.
> >
> > I suggest a forward reference to the security considerations with= a
> > brief note that the risk involved in using a group-shared symmetr= ic
> > key increases with the size of the group to which it is shared. >
> [Med] OK. Done.
>
> >
> >=C2=A0 =C2=A0 In order to accommodate deployments relying upon key= ing material
> > per
> >=C2=A0 =C2=A0 SFC/SFP and also the need to update keys after encry= pting NSH
> > data
> >=C2=A0 =C2=A0 for a certain amount of time, this document uses key= identifiers
> > to
> >=C2=A0 =C2=A0 unambiguously identify the appropriate keying materi= al.=C2=A0 Doing so
> >=C2=A0 =C2=A0 allows to address the problem of synchronization of = keying
> > material.
> >
> > I'd suggest making a statement about the scope in which key > > identifiers need to be unique.
>
> [Med] That depends on the bullet mentioned above (ex. per-tenant). I&#= 39;m not sure adding the sentence adds much value as the scope tweaking sti= ll deployment-specific.=C2=A0

If it takes a lot of text to describe accurately it may not be worth doing,=
sure.

> >
> > Section 4.5
> >
> >=C2=A0 =C2=A0 An NSH-aware SF or SFC Proxy that needs to decrypt s= ome Context
> >=C2=A0 =C2=A0 Headers uses ENC_Key and the decryption algorithm fo= r the key
> >=C2=A0 =C2=A0 identifier being carried in the NSH.
> >
> > I think we need to say that decryption MUST NOT proceed unless th= e
> > integrity tag has been successfully validated.=C2=A0 To decrypt w= ithout
> > checking the integrity tag violates the AEAD interface.
> > Alternately, we could only ever describe decryption as the AEAD > > operation that uses K as input (not just ENC_KEY) -- =C2=A77.6 se= ems to
> > attempt to take this latter approach, but the document as a whole= is
> > not consistent about it.
>
> [Med] This section is about introducing the new MAC context headers. I= don't think this is the right place to mention this.=C2=A0
>
> BTW, the order you mentioned is what is implied by the procedure: 7.5 = (NSH Data Validation) and then 7.6 (Decryption of NSH Metadata). Invalid da= ta are discarded as part of 7.5.
>
> No problem to add a note to 7.6 if you think this is really needed.
It may be best to wait and see what things shape out to be after other
changes.

> >
> > Section 5, 5.x
> >
> > I strongly suggest changing "Key Length" to "keyid= length", since
> > there is already convention on "key length" (e.g., for = AES-128 vs
> > AES-192 vs AES-256).
>
> [Med] Fixed as per a comment from Eric.
>
> >
> > Section 5.1
> >
> >=C2=A0 =C2=A0 Key Identifier:=C2=A0 Carries a variable-length Key = Identifier object
> > used
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0to identify and deliver keys to SFC dat= a plane elements.=C2=A0 This
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0identifier is helpful to accommodate de= ployments relying upon
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0keying material per SFC/SFP.=C2=A0 The = key identifier helps in
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0resolving the problem of synchronizatio= n of keying material.
> >
> > I suggest clarifying that a single key identifier is used to look= up
> > both the associated ENC_KEY and the associated MAC_KEY (or,
> > alternately, that it is logically bound to K and remind the reade= r
> > that ENC_KEY and MAC_KEY are extracted from K and might be
> > separately distributed).
>
> [Med] Added this NEW:
>
> "A single key identifier is used to lookup both the ENC_KEY and t= he MAC_KEY associated with a key."
>
> >
> >=C2=A0 =C2=A0 Key Length:=C2=A0 Variable.=C2=A0 Carries the length= of the key identifier.
> >=C2=A0 =C2=A0 [...]
> >=C2=A0 =C2=A0 IV Length:=C2=A0 Carries the length of the IV (Secti= on 5.2 of
> > [RFC7518]).
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0If encryption is not used, IV length is= set to zero (that is,
> > no
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"Initialization Vector" is in= cluded).
> >
> > Please also specify that the Key/IV lengths are measured in bytes=
>
> [Med] Fixed per a comment from Eric.

If he keeps this up, we'll have to nominate him for SEC AD...

> > (the reference for IV length, at least, talks about IVs in bits).=
> >
> > I strongly suggest using a value other than zero as the sentinel<= br> > > value for "no encryption" -- there already exist modes = like AES-SIV
> > (RFC 5297) that do not require an IV input, which would be a natu= ral
> > use for zero-length IV.
>
> [Med] What is the advantage of using a value other than zero when encr= yption is not included?

There may arise cases in the future where it's desired to use an encryp= tion
scheme that takes a zero-length IV.=C2=A0 If the zero-length IV already has= the
semantics of "encryption not used", then that needlessly preclude= s such
future flexibility.

Good point, added t= he following line:
If the Context Headers are only integrity prot= ected, "Nonce Length" is set to zero (that is, no "Nonce&quo= t; is included). The "Nonce Length" can be set to zero based on t= he encryption algorithm used to encrypt the Context Headers.
= =C2=A0

> >
> > Additionally, one might imagine using a non-zero-length IV as inp= ut
> > to an HMAC calculation as a per-message nonce.=C2=A0 On cursory > > examination, since we are already using timestamp-based replay > > detection, the additional nonce is unlikely to add much value, bu= t
> > I'm not willing to completely rule it out on the basis of the=
> > minimal analysis I performed.
> >
> > Section 7.1
> >
> >=C2=A0 =C2=A0 Only one instance of "MAC and Encrypted Metadat= a" Context Header
> >=C2=A0 =C2=A0 (Section 5) is allowed.=C2=A0 If multiple instances = of "MAC and
> > Encrypted
> >=C2=A0 =C2=A0 Metadata" Context Header are included in an NSH= packet, the SFC
> > data
> >
> > I think Roman may have mentioned this already, but please clarify= if
> > this is one instance per NSH or per packet (e.g., in hierarchical=
> > SFC we might have more than one NSH in a packet).
>
> [Med] I confirm.

(I trust it will make it into the document, based on Roman's review.)
> >
> > Please also clarify it if is permitted to have both MAC#1 and MAC= #2
> > present in the same packet.=C2=A0 (IIUC there are not obvious sit= uations
> > where such a setup would be useful, but it's still good to be= clear
> > about expectations.)
>
> [Med] It is not allowed to have both. This is why we are using the gen= eric term: "instance of "MAC and Encrypted Metadata" Context= Header". That term is used through the document when we refer indiffe= rently to MAC#1 and MAC#2.

That is what I suspected, so thank you for confirming.=C2=A0 I would propos= e to
have in one location a clear statement that MAC#1 and MAC#2 are not allowed=
together, but I do not insist on it.

> >
> > Section 7.2
> >
> >=C2=A0 =C2=A0 If the Context Headers are not encrypted, the HMAC a= lgorithm
> >=C2=A0 =C2=A0 discussed in [RFC4868] is used to integrity protect = the target
> > NSH
> >=C2=A0 =C2=A0 data.=C2=A0 [...]
> >
> > It's not really clear to me why RFC 4868 is the right referen= ce
> > here, as opposed to (e.g.) RFC 2104.=C2=A0 In particular, see my = Discuss
> > point (2).
>
> [Med] We think that RFC 4868 is the right reference as RFC 2014 does n= ot discuss any of the HMAC algorithms used in this specification.

In my experience it's fine to say just that "we use HMAC [RFC 2014= ] as
instantiated with <some hash> [reference-for-hash]", so whether = or not the
specific construction (e.g., as from RFC 4868) appears in the reference is<= br> not critical.

Fixed.=C2=A0
= =C2=A0

> >
> >=C2=A0 =C2=A0 The Message Authentication Code (T) computation proc= ess can be
> >=C2=A0 =C2=A0 illustrated as follows:
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 T =3D HMAC-SHA-256-128(MAC_KEY,= A)
> >
> > I agree with the other reviewer that wondered about just using &q= uot;MAC"
> > (or maybe "HMAC") rather than "HMAC-SHA-256-128&qu= ot; here (I do see the
> > "can be illustrated as" qualifier).
> >
> > It's also a little weird to reuse T and A from the AEAD const= ruction
> > (or RFC 4868) here without additional discussion on how they appl= y
> > and how the value of A is constructed.
>
> [Med] Noted. We made already this change: s/A/target NSH data.
>
> >
> >=C2=A0 =C2=A0 An entity in the SFP that intends to update the NSH = MUST follow
> > the
> >=C2=A0 =C2=A0 above behavior to maintain message integrity of the = NSH for
> >=C2=A0 =C2=A0 subsequent validations.
> >
> > I'm not sure that "intends to" is needed; the requi= rement applies to
> > actions, not intent.
>
> [Med] Fair. Fixed, thanks.
>
> >
> > Section 7.3
> >
> >=C2=A0 =C2=A0 In an SFC-enabled domain where pervasive monitoring = [RFC7258] is
> >=C2=A0 =C2=A0 possible, all Context Headers carrying privacy-sensi= tive metadata
> >=C2=A0 =C2=A0 MUST be encrypted; [...]
> >
> > I agree with the other reviewer that noted that this seems to
> > effectively be an unqualified "MUST", since there is al= ways some
> > possibility of monitoring.
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MAC_KEY =3D initial MAC_KEY_LEN= octets of K,
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ENC_KEY =3D final ENC_KEY_LEN o= ctets of K,
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 E =3D CBC-PKCS7-ENC(ENC_KEY, P)= ,
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 M =3D MAC(MAC_KEY, A || IV || E= || AL),
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 T =3D initial T_LEN octets of M= .
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MAC and Encrypted Metadata =3D = E || T
> >
> > I recognize that this is just copy+paste from RFC 7518 (with the<= br> > > addition of the last line), but it seems a glaring omission that = the
> > CBC-PKCS7-ENC() invocation does not include the IV as an input! > > (In =C2=A75.2.2.1 of RFC 7518 we do see that "The plaintext = is CBC
> > encrypted using PKCS #7 padding using ENC_KEY as the key and the<= br> > > IV", so it's just the figure/formula that omits the IV.)=
> >
> > We also don't define or mention T_LEN in this document other = than in
> > this formula and the analogous one for MAC-without-encryption, wh= ich
> > might be worth remedying.
>
> [Med] If we mandate AES_GCM, all the above text will be removed.
>
> >
> > Section 7.4
> >
> > I suggest adding another word (like "Prevention") to th= e section
> > title.
> >
>
> [Med] Fixed.
>
> >=C2=A0 =C2=A0 The received NSH is accepted by an NSH-aware node if= the
> > Timestamp
> >=C2=A0 =C2=A0 (TS) in the NSH is recent enough to the reception ti= me of the NSH
> >=C2=A0 =C2=A0 (TSrt).=C2=A0 The following formula is used for this= check:
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -Delta < (TSrt= - TS) < +Delta
> >
> > (There's no real reason why the accepted timestamp skew param= eter
> > Delta needs to be symmetric in the positive and negative
> > directions.)
>
> [Med] This was to accommodate any sync issues.

Having it extend in both directions is clearly useful, to cover all kinds of sync issues.=C2=A0 But the range might equally as well be -Epsilon < = (TSrt -
TS) < +Delta for Delta !=3D Epsilon.=C2=A0 Perhaps that's needless c= omplexity, but
it seemed worth raising the idea for discussion.

> >
> >=C2=A0 =C2=A0 Replay attacks within the Delta window may be detect= ed by an NSH-
> >=C2=A0 =C2=A0 aware node by recording a unique value derived, for = example, from
> > the
> >=C2=A0 =C2=A0 NSH data and Original packet (e.g., using SHA2).=C2= =A0 [...]
> >
> > Note that the unique value MUST NOT use as input any bits that ar= e
> > not covered by the MAC.
>
> [Med] Agree, but we don't specify the bits that are used.

This is a very tempting and easy-to-make mistake; I think we should
preemptively warn the implementor against it, regardless of whether we also=
provide a specific suggestion (e.g., the next line of this email).=C2=A0

>=C2=A0 Indeed, just using the MAC itself as the
> > unique value would be a fairly straightforward scheme, I think.

Sure, updated text as follows:
Replay attacks within the Delta window may be detected by an NSH-aware nod= e by recording a unique value derived, for example, to record a unique valu= e derived from the MAC field value. Such an NSH-aware node will detect and = reject duplicates.
=C2=A0
>
> [Med] Thanks.=C2=A0
>
> >
> > Section 7.5
> >
> >=C2=A0 =C2=A0 When an SFC data plane element receives an NSH packe= t, it MUST
> > first
> >=C2=A0 =C2=A0 ensure that a "MAC and Encrypted Metadata"= Context Header is
> >=C2=A0 =C2=A0 included.=C2=A0 [...]
> >
> > This sort of requirement (as written) would seem to support the > > position of some other reviewers that this document would need to=
> > formally update RFC 8300.
>
> [Med] Added "When an SFC data plan element conforms to this speci= fication," to address one of Roman's comments.
>
> >
> > Section 9
> >
> > We might discuss that this mechanism is only for metadata type 2 = and
> > not type 1 (as well as that with the relatively small fixed lengt= h
> > of type 1 metadata, it's quite challenging to provide useful<= br> > > cryptographic protection), so that type-1 metadata still has no > > generic protection mechanism.=C2=A0 A given metadata element coul= d define
> > its own protection scheme, of course.
>
> [Med] We already have the following in the introduction:
>
>=C2=A0 =C2=A0 This specification is only
>=C2=A0 =C2=A0 applicable to NSH MD Type 0x02 (Section 2.5 of [RFC8300])= .

Yes.
There is some security consideration to limiting this mechanism to type 2 only, in that type 1 exists and has no defined method of protection.
My proposal is to mention that this mechanism is not fully generic (i.e., does not cover type 1 metadata) and a little bit of explanation of why.
=

Done, added following text:

=
This specification is not applicable to NSH MD Type 0x01 (Sectio= n TBD of RFC8300) because it only allows a Fixed-Length Context Header whos= e size is 16-bytes and is not sufficient to accommodate both the metadata a= nd message integrity of the NSH data.



> >
> >=C2=A0 =C2=A0 The attacks discussed in [I-D.nguyen-sfc-security-ar= chitecture]
> > are
> >=C2=A0 =C2=A0 handled owing to the solution specified in this docu= ment, except
> > for
> >=C2=A0 =C2=A0 attacks dropping packets.=C2=A0 [...]
> >
> > >From a very quick read, draft-nguyen-sfc-security-architectur= e
> > proposes
> > a probe-based scheme that monitors all middleboxes (or at least > > those in the expected path) to detect a middlebox-bypass attack a= nd
> > verify that the probe traversed the expected SFP.=C2=A0 I am not = sure
> > that this document on its own suffices to prevent the middlebox-<= br> > > bypass attack for all traffic (i.e., the probe-based scheme might=
> > still be needed).=C2=A0 If some network entities know what the ex= pected
> > service index will be for a given SPI at a given node, then
> > middlebox-bypass attacks could be natively detected, but my
> > understanding was that such advance knowledge of expected service=
> > index was not going to be available.
>
> [Med] The SF bypass can be detected if SI was manipulated on path beca= use integrity check will fail.

Does each SF or some other on-path entity know which (SFP, SI) are
allowed/expected for traffic it receives?=C2=A0 If not, then just moving th= e
packets around differently without changing their contents is my concern.

This attack can be detected using the pr= oof of transit mechanism discussed in=C2=A0https://datatracker.ietf.org/= doc/draft-ietf-sfc-proof-of-transit/=C2=A0=C2=A0
=C2=A0
=

> >
> >=C2=A0 =C2=A0 The solution specified in this document does not pro= vide data
> > origin
> >=C2=A0 =C2=A0 authentication.
> >
> > I would have expected more in-depth discussion of the security > > considerations for a group-shared PSK scheme, including how the r= isk
> > of key loss/compromise goes up when the key is distributed to mor= e
> > locations.
>
> [Med] That's part of the key management, declared out of scope.=C2= =A0 =C2=A0

Even with the details of how keys are shared/distributed being out of
scope, I still would have expected discussion of the risks of shared keys.<= br> Perhaps my expectations are wrong (it has happened before and will happen again), but that's still what I expect.

=
Agreed, added following line:
The group key management proto= col related security considerations discussed in Section 8 of [RFC4046] nee= ds to be taken into consideration.
=C2=A0

> >
> > Section 9.1
> >
> >=C2=A0 =C2=A0 No device other than the NSH-aware SFs in the SFC-en= abled domain
> >=C2=A0 =C2=A0 should be able to update the integrity protected NSH= data.
> >
> > What about classifiers and SFC proxies?
>
> [Med] Good catch: proxies should be mentioned as well as re-classifica= tion. We can't just talk about classification as this is about updating= the MAC.
>
> The NEW text that also takes into account a comment from John is as fo= llows:
>
>=C2=A0 =C2=A0 It is expected that specific devices in the SFC-enabled d= omain will
>=C2=A0 =C2=A0 be configured such that no device other than the classifi= ers (when
>=C2=A0 =C2=A0 reclassification is enabled), NSH-aware SFs, and SFC prox= ies will be
>=C2=A0 =C2=A0 able to update the integrity protected NSH data (Section = 7.1), and
>=C2=A0 =C2=A0 also such that no device other than the NSH-aware SFs and= SFC proxies
>=C2=A0 =C2=A0 will be able to decrypt and update the Context Headers ca= rrying
>=C2=A0 =C2=A0 sensitive metadata (Section 7.1).
>
> >
> > Section 9.2
> >
> > I expected to see some remarks here analogous to the second
> > paragraph of
> > =C2=A79.1 (even if just by reference to that section).
>
> [Med] Added this NEW sentence:
>
>=C2=A0 =C2=A0 Similar to Section 9.1, no device other than the NSH-awar= e SFs and
>=C2=A0 =C2=A0 SFC proxies in the SFC-enabled domain should be able to d= ecrypt and
>=C2=A0 =C2=A0 update the Context Headers carrying sensitive metadata. <= br>
Thanks!

> >
> > Section 9.3
> >
> >=C2=A0 =C2=A0 Section 5.6 of [RFC8633] describes best current prac= tices to be
> >=C2=A0 =C2=A0 considered in deployments where SFC data plane eleme= nts use NTP
> > for
> >=C2=A0 =C2=A0 time synchronization purposes.
> >
> > The referenced section covers NTP symmetric mode only.
>
> [Med] Yes because we think that=E2=80=99s the symmetric mode is better= vs. broadcast with trusted modes.
>
>=C2=A0 =C2=A0Is
> > client/server mode not a BCP for trusted networks and
> > broadcast/symmetric the only options?
>
> [Med] Not sure to get this comment.

Sorry, let me try again.=C2=A0 "I do not operate an NTP service and ha= ve little
knowledge of NTP operational best practices.=C2=A0 I can easily believe tha= t NTP
symmetric mode is a good option ("best current practice") on a tr= usted
network, but I could also easily believe that NTP client/server mode would<= br> equally be a useful option on a trusted network.=C2=A0 Is there a reason to=
prefer symmetric over client/server mode?"
It seems that you mostly answered this above, though just with a "yes&= quot; and
not the actual reason (the actual reason would just be for my own curiosity=
and is not expected to appear in the document, so please feel free to drop<= br> the topic).

I think by mistake we point= ed to Section 5.6, the intention was to point to RFC8333 which discusses va= rious modes including client/server mode with pre-shared keys.=C2=A0
<= div>
Fixed text.

Cheers,
-= Tiru


Thanks,

Ben
--000000000000bf25e005c7c51acb-- From nobody Sun Jul 25 22:04:50 2021 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE1A3A1A78; Sun, 25 Jul 2021 22:04:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Joseph Touch via Datatracker To: Cc: draft-ietf-sfc-nsh-integrity.all@ietf.org, last-call@ietf.org, sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.35.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162727588884.5692.17674077604548999432@ietfa.amsl.com> Reply-To: Joseph Touch Date: Sun, 25 Jul 2021 22:04:48 -0700 Archived-At: Subject: [sfc] Tsvart last call review of draft-ietf-sfc-nsh-integrity-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2021 05:04:49 -0000 Reviewer: Joseph Touch Review result: Not Ready This document has been reviewed as part of the transport area review team's 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 and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. It was very difficult to review this document for IETF transport protocol considerations. Although "transport encapsulation" is indicated repeatedly, it is never referred to directly or described either in this document or its citations. It appears to be using this term in the sense of RFC8300, which too never defines it, but uses examples that are more accurately referred to in the IETF as link layer protocols or either network or link tunnel protocols (IP in IP, GRE, VXLAN, Ethernet). Regardless of the fact that this confusion originates in RFC8300, it needs to be addressed here and corrected before this document can be reviewed to determine if there are any IETF transport area issues. The remainder of these notes provide detail of this issue. ----- The document refers back to RFC8300 to define the NSH itself; that document discusses transport issues just as vaguely (never mentioning a particular transport protocol), and when it discusses fragmentation, it refers to section 9 of a document (draft-ietf-rtgwg-dt-encap-02 from 2017) that had expired prior to the publication of RFC8300. Because transport fragmentation is, IMO, a normative issue, this should not have been permitted. Further, Section 9 of that draft incorrectly recommends reliance on ICMP feedback to address MTU failures when not under a single operator’s management. That was widely known even then to be insufficient due to blackholing; this had motivated PLPMTUD in RFC4821 a full decade earlier. RFC8300 compounds this error by simply asserting that the operator should ensure that ICMPs are not blocked, overlooking the need to address when this is not the case. This document cannot ignore that issue and simply refer to RFC8300 on this issue. Note that one of the only places an actual encapsulation protocol is mentioned is RFC8300, in which Section 5 mentions IP and Section 6.1 Table 1 describes VXLAN-GPE, GRE, and Ethernet – all of which are described as “transport encapsulation”. If, in fact, IETF transport protocols are being used, at some point the use of an actual IETF transport protocol should be described (e.g., TCP, UDP, SCTP, DCCP). At that point, the transport issues would be reviewable. As the document currently stands, it completely ignores such transport issues and should not proceed until this is addressed and re-reviewed. If instead, as I suspect, the term “transport encapsulation” actually refers to “network layer encapsulation” or “link layer encapsulation” and really implies some sort of tunnel, there would be no transport area issues to review unless that tunnel were to include a transport protocol as part of the layers of encapsulation. If that is the case, the document should be revised to replace the term “transport” with something that more accurately describes VXLAN-GPE, GRE, Ethernet, and IP encapsulation using IETF terminology. Note that draft-ietf-intarea-tunnels never uses the term “transport” except when referring to the use of IETF transport protocols as a tunnel layer, e.g. (i.e., the last sentence of Sec 8 of this doc is incorrect in implying otherwise). (I would also note that neither this doc nor RFC8300 define “transport encapsulation” in their terminology; even if they would, they should not attempt to define it in a way inconsistent with widespread use in the IETF). From nobody Mon Jul 26 00:28:58 2021 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4983A1EDE; Mon, 26 Jul 2021 00:28:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.35.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sfc@ietf.org Message-ID: <162728452907.21056.3024389978207775673@ietfa.amsl.com> Date: Mon, 26 Jul 2021 00:28:49 -0700 Archived-At: Subject: [sfc] I-D Action: draft-ietf-sfc-nsh-integrity-07.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2021 07:28:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining WG of the IETF. Title : Integrity Protection for the Network Service Header (NSH) and Encryption of Sensitive Context Headers Authors : Mohamed Boucadair Tirumaleswar Reddy Dan Wing Filename : draft-ietf-sfc-nsh-integrity-07.txt Pages : 29 Date : 2021-07-26 Abstract: This specification presents an optional method to add integrity protection directly to the Network Service Header (NSH) used for Service Function Chaining (SFC). Also, this specification allows for the encryption of sensitive metadata that is carried in the NSH. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-sfc-nsh-integrity-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-integrity-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 26 01:05:45 2021 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 381BC3A2015; Mon, 26 Jul 2021 01:05:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.35.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sfc@ietf.org Message-ID: <162728674017.20212.13816942449688133397@ietfa.amsl.com> Date: Mon, 26 Jul 2021 01:05:40 -0700 Archived-At: Subject: [sfc] I-D Action: draft-ietf-sfc-nsh-tlv-07.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2021 08:05:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining WG of the IETF. Title : Network Service Header Metadata Type 2 Variable-Length Context Headers Authors : Yuehua Wei Uri Elzur Sumandra Majee Carlos Pignataro Donald E. Eastlake Filename : draft-ietf-sfc-nsh-tlv-07.txt Pages : 12 Date : 2021-07-26 Abstract: Service Function Chaining (SFC) uses the Network Service Header (NSH) (RFC 8300) to steer and provide context Metadata (MD) with each packet. Such Metadata can be of various Types including MD Type 2 variable length context headers. This document specifies several such context headers that can be used within a service function path. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-tlv/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-sfc-nsh-tlv-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-tlv-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 26 01:18:56 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 885FF3A2080 for ; Mon, 26 Jul 2021 01:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mQUUiQ-Qfhy for ; Mon, 26 Jul 2021 01:18:50 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 3E5E33A2079 for ; Mon, 26 Jul 2021 01:18:27 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id r17so13993121lfe.2 for ; Mon, 26 Jul 2021 01:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=ijAhLuXEcvzTRQ0qrusP0g0Ra+8VhNOUY8PhU2r1Tcc=; b=fDNlpRqBahX8iPtvy/BBzjjD4DJaFs4CCQCPknoaPrhrWhYwKlcsxMx5H76C6rCq7d DXoedjcuQOgOMeVRhNEsBPk/WCPe168hSpdnDzwLTBH3rMxzB47euehLWehS6Q4MOkKK PhcAUbAJQQhBSWShjNEwvfJrN+B7wU2N9+FAxCkI1PSkOOffNLoKrQud5ciNSwT7IGgh TZjGffmu8X0/HUKbPBi9xv+9U/lqkDN5No7OS2YFDP+Djb7tjyA/rQ3w3xcu9R1QptLw RiO1MdLc7UzdZPIl2OduknsbbBt4XR1ZcTpRaglq7oGVUKPeHQI6saGDKHfHMVk9v+gE QBpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ijAhLuXEcvzTRQ0qrusP0g0Ra+8VhNOUY8PhU2r1Tcc=; b=Umsf9yi+oTOzgv5p8j5LILGSD5cHrPXq6ohIrp34p3RUbw6g/ARAZXpBOs5ZSSs1Ps H0+SYfmgSZc49Drh8EDqJUK7OxYP19CZ7BKN1eJJ8KfAHNFvoxYMz3UWG/CcO5zrVNuP dRujZfnENwzD934CJZbMZMfD051gTnAIl/sp1TEst1a/GpGW+Yjofod8iS5VJaUfpSPq HkfRwuBATGp+SnUpFVOLCE14BhuoTBriq+olQzgIMpPQo8sKEPqjsAlnHU9kD/1VR26M IFno6u2p98gD3nq2NFRLG18/rCW5BXWVtZWf7OnVptsMNhFmiC3YMWeoJPyXscgZbyMT /ueA== X-Gm-Message-State: AOAM530XInC3l8fRMbjz0q0/BhLnfFxJy01BpJwjKvrWaVaXDMPOZZvE iPmn86qPgqiR1TkbQN/2qz3qwcRn/NBg0bOth3hdk+msGXwb6g== X-Google-Smtp-Source: ABdhPJzsc3EFr+eJO4lad8R4d5PzEB1VeprsC4M46//uZtzOuiPWdb+6VrUeO/FWnQlkyaXK1Qs1TlfSnl8F7hPCwWk= X-Received: by 2002:a05:6512:238e:: with SMTP id c14mr12011209lfv.499.1627287502429; Mon, 26 Jul 2021 01:18:22 -0700 (PDT) MIME-Version: 1.0 References: <162728452907.21056.3024389978207775673@ietfa.amsl.com> In-Reply-To: <162728452907.21056.3024389978207775673@ietfa.amsl.com> From: tirumal reddy Date: Mon, 26 Jul 2021 13:48:11 +0530 Message-ID: To: sfc@ietf.org, Benjamin Kaduk , Roman Danyliw , =?UTF-8?B?w4lyaWMgVnluY2tl?= , superuser@gmail.com Content-Type: multipart/alternative; boundary="000000000000879f6305c8026529" Archived-At: Subject: Re: [sfc] I-D Action: draft-ietf-sfc-nsh-integrity-07.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2021 08:18:55 -0000 --000000000000879f6305c8026529 Content-Type: text/plain; charset="UTF-8" Hi all, This revision https://datatracker.ietf.org/doc/html/draft-ietf-sfc-nsh-integrity-07 addresses comments and DISCUSS from ISEG review. Cheers, -Tiru On Mon, 26 Jul 2021 at 13:00, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Service Function Chaining WG of the IETF. > > Title : Integrity Protection for the Network Service > Header (NSH) and Encryption of Sensitive Context Headers > Authors : Mohamed Boucadair > Tirumaleswar Reddy > Dan Wing > Filename : draft-ietf-sfc-nsh-integrity-07.txt > Pages : 29 > Date : 2021-07-26 > > Abstract: > This specification presents an optional method to add integrity > protection directly to the Network Service Header (NSH) used for > Service Function Chaining (SFC). Also, this specification allows for > the encryption of sensitive metadata that is carried in the NSH. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-sfc-nsh-integrity-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-integrity-07 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > --000000000000879f6305c8026529 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

This revision=C2=A0<= a href=3D"https://datatracker.ietf.org/doc/html/draft-ietf-sfc-nsh-integrit= y-07" rel=3D"noreferrer" target=3D"_blank">https://datatracker.ietf.org/doc= /html/draft-ietf-sfc-nsh-integrity-07=C2=A0addresses comments and DISCU= SS from ISEG review.

Cheers,
-Tiru
=

On Mon, 26 Jul 2021 at 13:00, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Service Function Chaining WG of the IETF.<= br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Integrity Protection for the Network Service Header (NSH) and Encryption o= f Sensitive Context Headers
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Moha= med Boucadair
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Tirumaleswar Reddy
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Dan Wing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-sfc-nsh-integrity-07.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 29
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2021-07-26

Abstract:
=C2=A0 =C2=A0This specification presents an optional method to add integrit= y
=C2=A0 =C2=A0protection directly to the Network Service Header (NSH) used f= or
=C2=A0 =C2=A0Service Function Chaining (SFC).=C2=A0 Also, this specificatio= n allows for
=C2=A0 =C2=A0the encryption of sensitive metadata that is carried in the NS= H.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft= -ietf-sfc-nsh-integrity/

There is also an htmlized version available at:
https://datatracker.ietf.org/do= c/html/draft-ietf-sfc-nsh-integrity-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-sfc-nsh-integrity-07


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc
--000000000000879f6305c8026529-- From nobody Mon Jul 26 10:25:53 2021 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B0B7D3A1E3B; Mon, 26 Jul 2021 10:25:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Murray Kucherawy via Datatracker To: "The IESG" Cc: draft-ietf-sfc-nsh-integrity@ietf.org, sfc-chairs@ietf.org, sfc@ietf.org, gregimirsky@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.35.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <162732034869.1408.4651101249180266694@ietfa.amsl.com> Date: Mon, 26 Jul 2021 10:25:48 -0700 Archived-At: Subject: [sfc] Murray Kucherawy's No Objection on draft-ietf-sfc-nsh-integrity-07: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2021 17:25:49 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-sfc-nsh-integrity-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the discussion about updating RFC 8300. Only nits to add, given the thorough treatment already given by others: Section 4.1.2: "The first level of assurance where all NSH data ..." -- add "is" before "where"? And the same issue in the next paragraph. Section 5.2: s/Coves/Covers/ From nobody Wed Jul 28 07:08:52 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 198D93A11E5; Wed, 28 Jul 2021 07:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSWG19UYTt4C; Wed, 28 Jul 2021 07:08:39 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAE7A3A11E4; Wed, 28 Jul 2021 07:08:38 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id l17so3273913ljn.2; Wed, 28 Jul 2021 07:08:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=scPFQRZVfSXMxCzFqYdzFgfP/s/bNOXjs1Mf+8hqrYY=; b=PRKX631JrMS9bO39JNfh7WMJTUV+HpcgM2gW2Cvko1Q5NyO7FaaPFRPHvkRR8apP+b i5U44dWQ4kYxjETAxuAOI0XC623WozLCLtygzJlxRg1cK0c4RmcL4KjHERHERO39OrG4 QXIHb5A5cJP4IPcEsXKbI1qkn3S5Kljl69Irp91qPfkCIe1/X3b36WmdLPuXDLK+mIyh ZAxPlMYqCRz/vNw1l1ze+diMmbsjQPTvSQnk3aijelVc55VXaNqXx0r1X0eOAGceL0C0 3EWIJP0PJIU/qWNYAapSLIs5YpzbhV5hnrFm7HeJcgsVAxXSXggXmeAalbGd+nmArtVe yK8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=scPFQRZVfSXMxCzFqYdzFgfP/s/bNOXjs1Mf+8hqrYY=; b=lH1DY3jMaPDWexklMg4wvWi7QkP6Pzs7eixoPTquxwGml9TK8gZGHjlJz78qX4hYkY Xla/OnSrL0R/onCk+ICUf5oNHT0Zh60QLWE8J9SaVYZFXyEKObthneVoUOhF4w4Qrj+K KaXv66MR+gBmzYaPDGQSyunxal4IV+Nb8PTJNKBwFTxn0KAKI/pBZyfDzx+l3Q6MTzf6 RL5Jp6Nt/tawu7oxrEQFI6mHgqQB6QoyJ2oZVDXE4RtUbRYR+UI1dcwttPRxU12GMavM THp8z5SuttqpZr77ATzFRiS0/dwTDGZFEQbv/pJjNNi1NEyViC9c8+6kQtfKyVRg3o4C XOEg== X-Gm-Message-State: AOAM531M/cd8FUvRzhIGjKa+9zn5X7ewq0ZqJAaxcVJ3MKqQYawvmI2F rmnmZrdvUbStbnmVUpPE/xVJmqkHs6EJLwJJ7XXEaPfcoLjJFw== X-Google-Smtp-Source: ABdhPJyV3qFEjw4MYGJgSzGBYREi3QH0c093MsPm40Lpo0dwYqA37vBVsP2pps5Bnb8kdT5hmNZPS14f8jiY4WEztGk= X-Received: by 2002:a2e:9ec1:: with SMTP id h1mr57181ljk.0.1627481316217; Wed, 28 Jul 2021 07:08:36 -0700 (PDT) MIME-Version: 1.0 References: <162727588884.5692.17674077604548999432@ietfa.amsl.com> In-Reply-To: <162727588884.5692.17674077604548999432@ietfa.amsl.com> From: tirumal reddy Date: Wed, 28 Jul 2021 19:38:24 +0530 Message-ID: To: Joseph Touch Cc: tsv-art@ietf.org, draft-ietf-sfc-nsh-integrity.all@ietf.org, last-call@ietf.org, sfc@ietf.org Content-Type: multipart/alternative; boundary="000000000000bb582605c82f85e4" Archived-At: Subject: Re: [sfc] Tsvart last call review of draft-ietf-sfc-nsh-integrity-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2021 14:08:44 -0000 --000000000000bb582605c82f85e4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Joseph for the detailed comment and explanation. We plan to add the following text to address the issue: Note that the term =E2=80=9Ctransport encapsulation=E2=80=9D used in this d= ocument is equivalent to the term =E2=80=9Ctunnel encapsulation=E2=80=9D used In [ietf= -intarea-tunnel]. Cheers, -Tiru On Mon, 26 Jul 2021 at 10:34, Joseph Touch via Datatracker wrote: > Reviewer: Joseph Touch > Review result: Not Ready > > This document has been reviewed as part of the transport area review team= 's > 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 and WG to allow them to address any issues raised and also to the > IETF > discussion list for information. > > When done at the time of IETF Last Call, the authors should consider this > review as part of the last-call comments they receive. Please always CC > tsv-art@ietf.org if you reply to or forward this review. > > It was very difficult to review this document for IETF transport protocol > considerations. > > Although "transport encapsulation" is indicated repeatedly, it is never > referred to directly or described either in this document or its > citations. It > appears to be using this term in the sense of RFC8300, which too never > defines > it, but uses examples that are more accurately referred to in the IETF as > link > layer protocols or either network or link tunnel protocols (IP in IP, GRE= , > VXLAN, Ethernet). > > Regardless of the fact that this confusion originates in RFC8300, it need= s > to > be addressed here and corrected before this document can be reviewed to > determine if there are any IETF transport area issues. > > The remainder of these notes provide detail of this issue. > > ----- > > The document refers back to RFC8300 to define the NSH itself; that docume= nt > discusses transport issues just as vaguely (never mentioning a particular > transport protocol), and when it discusses fragmentation, it refers to > section > 9 of a document (draft-ietf-rtgwg-dt-encap-02 from 2017) that had expired > prior > to the publication of RFC8300. Because transport fragmentation is, IMO, = a > normative issue, this should not have been permitted. > > Further, Section 9 of that draft incorrectly recommends reliance on ICMP > feedback to address MTU failures when not under a single operator=E2=80= =99s > management. > That was widely known even then to be insufficient due to blackholing; > this had > motivated PLPMTUD in RFC4821 a full decade earlier. RFC8300 compounds thi= s > error by simply asserting that the operator should ensure that ICMPs are > not > blocked, overlooking the need to address when this is not the case. > > This document cannot ignore that issue and simply refer to RFC8300 on thi= s > issue. > > Note that one of the only places an actual encapsulation protocol is > mentioned > is RFC8300, in which Section 5 mentions IP and Section 6.1 Table 1 > describes > VXLAN-GPE, GRE, and Ethernet =E2=80=93 all of which are described as =E2= =80=9Ctransport > encapsulation=E2=80=9D. > > If, in fact, IETF transport protocols are being used, at some point the > use of > an actual IETF transport protocol should be described (e.g., TCP, UDP, > SCTP, > DCCP). At that point, the transport issues would be reviewable. As the > document > currently stands, it completely ignores such transport issues and should > not > proceed until this is addressed and re-reviewed. > > If instead, as I suspect, the term =E2=80=9Ctransport encapsulation=E2=80= =9D actually > refers to > =E2=80=9Cnetwork layer encapsulation=E2=80=9D or =E2=80=9Clink layer enca= psulation=E2=80=9D and really > implies > some sort of tunnel, there would be no transport area issues to review > unless > that tunnel were to include a transport protocol as part of the layers of > encapsulation. If that is the case, the document should be revised to > replace > the term =E2=80=9Ctransport=E2=80=9D with something that more accurately = describes > VXLAN-GPE, > GRE, Ethernet, and IP encapsulation using IETF terminology. Note that > draft-ietf-intarea-tunnels never uses the term =E2=80=9Ctransport=E2=80= =9D except when > referring to the use of IETF transport protocols as a tunnel layer, e.g. > (i.e., > the last sentence of Sec 8 of this doc is incorrect in implying otherwise= ). > > (I would also note that neither this doc nor RFC8300 define =E2=80=9Ctran= sport > encapsulation=E2=80=9D in their terminology; even if they would, they sho= uld not > attempt to define it in a way inconsistent with widespread use in the > IETF). > > > > --000000000000bb582605c82f85e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Joseph for the detailed comment and explanatio= n. We plan to add the following text to address the issue:

Note that the term =E2=80=9Ctransport encapsulation=E2=80=9D used in th= is document is equivalent to the term =E2=80=9Ctunnel encapsulation=E2=80= =9D used In [ietf-intarea-tunnel].= =C2=A0


Chee= rs,

-Tiru


On Mon, 26 Jul 2021 at 10:34, J= oseph Touch via Datatracker <noreply= @ietf.org> wrote:
Reviewer: Joseph Touch
Review result: Not Ready

This document has been reviewed as part of the transport area review team&#= 39;s
ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document&= #39;s
authors and WG to allow them to address any issues raised and also to the I= ETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org = if you reply to or forward this review.

It was very difficult to review this document for IETF transport protocol considerations.

Although "transport encapsulation" is indicated repeatedly, it is= never
referred to directly or described either in this document or its citations.= It
appears to be using this term in the sense of RFC8300, which too never defi= nes
it, but uses examples that are more accurately referred to in the IETF as l= ink
layer protocols or either network or link tunnel protocols (IP in IP, GRE,<= br> VXLAN, Ethernet).

Regardless of the fact that this confusion originates in RFC8300, it needs = to
be addressed here and corrected before this document can be reviewed to
determine if there are any IETF transport area issues.

The remainder of these notes provide detail of this issue.

-----

The document refers back to RFC8300 to define the NSH itself; that document=
discusses transport issues just as vaguely (never mentioning a particular transport protocol), and when it discusses fragmentation, it refers to sect= ion
9 of a document (draft-ietf-rtgwg-dt-encap-02 from 2017) that had expired p= rior
to the publication of RFC8300.=C2=A0 Because transport fragmentation is, IM= O, a
normative issue, this should not have been permitted.

Further, Section 9 of that draft incorrectly recommends reliance on ICMP feedback to address MTU failures when not under a single operator=E2=80=99s= management.
That was widely known even then to be insufficient due to blackholing; this= had
motivated PLPMTUD in RFC4821 a full decade earlier. RFC8300 compounds this<= br> error by simply asserting that the operator should ensure that ICMPs are no= t
blocked, overlooking the need to address when this is not the case.

This document cannot ignore that issue and simply refer to RFC8300 on this<= br> issue.

Note that one of the only places an actual encapsulation protocol is mentio= ned
is RFC8300, in which Section 5 mentions IP and=C2=A0 Section 6.1 Table 1 de= scribes
VXLAN-GPE, GRE, and Ethernet =E2=80=93 all of which are described as =E2=80= =9Ctransport
encapsulation=E2=80=9D.

If, in fact, IETF transport protocols are being used, at some point the use= of
an actual IETF transport protocol should be described (e.g., TCP, UDP, SCTP= ,
DCCP). At that point, the transport issues would be reviewable. As the docu= ment
currently stands, it completely ignores such transport issues and should no= t
proceed until this is addressed and re-reviewed.

If instead, as I suspect, the term =E2=80=9Ctransport encapsulation=E2=80= =9D actually refers to
=E2=80=9Cnetwork layer encapsulation=E2=80=9D or =E2=80=9Clink layer encaps= ulation=E2=80=9D and really implies
some sort of tunnel, there would be no transport area issues to review unle= ss
that tunnel were to include a transport protocol as part of the layers of encapsulation. If that is the case, the document should be revised to repla= ce
the term =E2=80=9Ctransport=E2=80=9D with something that more accurately de= scribes VXLAN-GPE,
GRE, Ethernet, and IP encapsulation using IETF terminology. Note that
draft-ietf-intarea-tunnels never uses the term =E2=80=9Ctransport=E2=80=9D = except when
referring to the use of IETF transport protocols as a tunnel layer, e.g. (i= .e.,
the last sentence of Sec 8 of this doc is incorrect in implying otherwise).=

(I would also note that neither this doc nor RFC8300 define =E2=80=9Ctransp= ort
encapsulation=E2=80=9D in their terminology; even if they would, they shoul= d not
attempt to define it in a way inconsistent with widespread use in the IETF)= .



--000000000000bb582605c82f85e4-- From nobody Wed Jul 28 21:41:25 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 753F63A0BB6; Wed, 28 Jul 2021 21:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 CQ6lpeM8_sCD; Wed, 28 Jul 2021 21:41:14 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 2381F3A0BCD; Wed, 28 Jul 2021 21:41:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type:Sender: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=ksqny8F8YK7tfPIQ47rRILUnQhD+SjTxi00jBCCT+5U=; b=UWYfXCjHsWGqv0X8YByOBWqxQg NjGu+djIDuZO4jZ+6umR0wsAph0uDbUQGSLTMGgiepJB3norqFq8BuVzsF+8nAUF+SNSku6xGhJET tHrOzbL3izfYsVx/66rA1jnpds5phPpeLNx4y7Yx+fTNaQzPl9vGLDGoDkpOsgtJBI/0LuQckLmBr 3ENATifnsRtPdDwiV1kzgk/T0q/YF+gCF+uJ9U/dLJm/xPWsDBPmo8oCLIjG3vO2I+b6AaiIA64IJ 8Er+92sBo7NE4ziC/4I430JaUb3npN/zd1UBwgGhgcyfRy0B6eU4v9hSfzEothqX/yucWWJ+LbAGZ yUtN82Nw==; Received: from cpe-172-114-237-88.socal.res.rr.com ([172.114.237.88]:64853 helo=smtpclient.apple) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1m8xr1-001NBr-Ch; Thu, 29 Jul 2021 00:41:12 -0400 Content-Type: multipart/alternative; boundary=Apple-Mail-43B50022-F870-4A03-86D1-6D43CC45DE89 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) From: Joe Touch In-Reply-To: Date: Wed, 28 Jul 2021 21:41:06 -0700 Cc: tsv-art@ietf.org, draft-ietf-sfc-nsh-integrity.all@ietf.org, sfc@ietf.org, last-call@ietf.org Message-Id: References: To: tirumal reddy X-Mailer: iPad Mail (18G82) X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [sfc] [Last-Call] Tsvart last call review of draft-ietf-sfc-nsh-integrity-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2021 04:41:21 -0000 --Apple-Mail-43B50022-F870-4A03-86D1-6D43CC45DE89 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Insufficient. > On Jul 28, 2021, at 7:09 AM, tirumal reddy wrote: >=20 > =EF=BB=BF > Thanks Joseph for the detailed comment and explanation. We plan to add the= following text to address the issue: >=20 > Note that the term =E2=80=9Ctransport encapsulation=E2=80=9D used in this d= ocument is equivalent to the term =E2=80=9Ctunnel encapsulation=E2=80=9D use= d In [ietf-intarea-tunnel].=20 >=20 > Cheers, > -Tiru >=20 >> On Mon, 26 Jul 2021 at 10:34, Joseph Touch via Datatracker wrote: >> Reviewer: Joseph Touch >> Review result: Not Ready >>=20 >> This document has been reviewed as part of the transport area review team= 's >> ongoing effort to review key IETF documents. These comments were written >> primarily for the transport area directors, but are copied to the documen= t's >> authors and WG to allow them to address any issues raised and also to the= IETF >> discussion list for information. >>=20 >> When done at the time of IETF Last Call, the authors should consider this= >> review as part of the last-call comments they receive. Please always CC >> tsv-art@ietf.org if you reply to or forward this review. >>=20 >> It was very difficult to review this document for IETF transport protocol= >> considerations. >>=20 >> Although "transport encapsulation" is indicated repeatedly, it is never >> referred to directly or described either in this document or its citation= s. It >> appears to be using this term in the sense of RFC8300, which too never de= fines >> it, but uses examples that are more accurately referred to in the IETF as= link >> layer protocols or either network or link tunnel protocols (IP in IP, GRE= , >> VXLAN, Ethernet). >>=20 >> Regardless of the fact that this confusion originates in RFC8300, it need= s to >> be addressed here and corrected before this document can be reviewed to >> determine if there are any IETF transport area issues. >>=20 >> The remainder of these notes provide detail of this issue. >>=20 >> ----- >>=20 >> The document refers back to RFC8300 to define the NSH itself; that docume= nt >> discusses transport issues just as vaguely (never mentioning a particular= >> transport protocol), and when it discusses fragmentation, it refers to se= ction >> 9 of a document (draft-ietf-rtgwg-dt-encap-02 from 2017) that had expired= prior >> to the publication of RFC8300. Because transport fragmentation is, IMO, a= >> normative issue, this should not have been permitted. >>=20 >> Further, Section 9 of that draft incorrectly recommends reliance on ICMP >> feedback to address MTU failures when not under a single operator=E2=80=99= s management. >> That was widely known even then to be insufficient due to blackholing; th= is had >> motivated PLPMTUD in RFC4821 a full decade earlier. RFC8300 compounds thi= s >> error by simply asserting that the operator should ensure that ICMPs are n= ot >> blocked, overlooking the need to address when this is not the case. >>=20 >> This document cannot ignore that issue and simply refer to RFC8300 on thi= s >> issue. >>=20 >> Note that one of the only places an actual encapsulation protocol is ment= ioned >> is RFC8300, in which Section 5 mentions IP and Section 6.1 Table 1 descr= ibes >> VXLAN-GPE, GRE, and Ethernet =E2=80=93 all of which are described as =E2=80= =9Ctransport >> encapsulation=E2=80=9D. >>=20 >> If, in fact, IETF transport protocols are being used, at some point the u= se of >> an actual IETF transport protocol should be described (e.g., TCP, UDP, SC= TP, >> DCCP). At that point, the transport issues would be reviewable. As the do= cument >> currently stands, it completely ignores such transport issues and should n= ot >> proceed until this is addressed and re-reviewed. >>=20 >> If instead, as I suspect, the term =E2=80=9Ctransport encapsulation=E2=80= =9D actually refers to >> =E2=80=9Cnetwork layer encapsulation=E2=80=9D or =E2=80=9Clink layer enca= psulation=E2=80=9D and really implies >> some sort of tunnel, there would be no transport area issues to review un= less >> that tunnel were to include a transport protocol as part of the layers of= >> encapsulation. If that is the case, the document should be revised to rep= lace >> the term =E2=80=9Ctransport=E2=80=9D with something that more accurately d= escribes VXLAN-GPE, >> GRE, Ethernet, and IP encapsulation using IETF terminology. Note that >> draft-ietf-intarea-tunnels never uses the term =E2=80=9Ctransport=E2=80=9D= except when >> referring to the use of IETF transport protocols as a tunnel layer, e.g. (= i.e., >> the last sentence of Sec 8 of this doc is incorrect in implying otherwise= ). >>=20 >> (I would also note that neither this doc nor RFC8300 define =E2=80=9Ctran= sport >> encapsulation=E2=80=9D in their terminology; even if they would, they sho= uld not >> attempt to define it in a way inconsistent with widespread use in the IET= F). >>=20 >>=20 >>=20 > --=20 > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call --Apple-Mail-43B50022-F870-4A03-86D1-6D43CC45DE89 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Insufficient.

On Jul 28, 2021, at 7:09 AM, tirumal= reddy <kondtir@gmail.com> wrote:

=EF=BB=BF
Thanks Josep= h for the detailed comment and explanation. We plan to add the following tex= t to address the issue:

Note that the term =E2=80=9Ctrans= port encapsulation=E2=80=9D used in this document is equivalent to the term =E2= =80=9Ctunnel encapsulation=E2=80=9D used In [ietf-intarea-tunnel]. 


Cheers,

-Tiru


On Mon, 26 Jul= 2021 at 10:34, Joseph Touch via Datatracker <noreply@ietf.org> wrote:
Reviewer: Joseph Touch
Review result: Not Ready

This document has been reviewed as part of the transport area review team's<= br> 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 and WG to allow them to address any issues raised and also to the IE= TF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org i= f you reply to or forward this review.

It was very difficult to review this document for IETF transport protocol considerations.

Although "transport encapsulation" is indicated repeatedly, it is never
referred to directly or described either in this document or its citations. I= t
appears to be using this term in the sense of RFC8300, which too never defin= es
it, but uses examples that are more accurately referred to in the IETF as li= nk
layer protocols or either network or link tunnel protocols (IP in IP, GRE, VXLAN, Ethernet).

Regardless of the fact that this confusion originates in RFC8300, it needs t= o
be addressed here and corrected before this document can be reviewed to
determine if there are any IETF transport area issues.

The remainder of these notes provide detail of this issue.

-----

The document refers back to RFC8300 to define the NSH itself; that document<= br> discusses transport issues just as vaguely (never mentioning a particular transport protocol), and when it discusses fragmentation, it refers to secti= on
9 of a document (draft-ietf-rtgwg-dt-encap-02 from 2017) that had expired pr= ior
to the publication of RFC8300.  Because transport fragmentation is, IMO= , a
normative issue, this should not have been permitted.

Further, Section 9 of that draft incorrectly recommends reliance on ICMP
= feedback to address MTU failures when not under a single operator=E2=80=99s m= anagement.
That was widely known even then to be insufficient due to blackholing; this h= ad
motivated PLPMTUD in RFC4821 a full decade earlier. RFC8300 compounds this error by simply asserting that the operator should ensure that ICMPs are not=
blocked, overlooking the need to address when this is not the case.

This document cannot ignore that issue and simply refer to RFC8300 on this issue.

Note that one of the only places an actual encapsulation protocol is mention= ed
is RFC8300, in which Section 5 mentions IP and  Section 6.1 Table 1 des= cribes
VXLAN-GPE, GRE, and Ethernet =E2=80=93 all of which are described as =E2=80=9C= transport
encapsulation=E2=80=9D.

If, in fact, IETF transport protocols are being used, at some point the use o= f
an actual IETF transport protocol should be described (e.g., TCP, UDP, SCTP,=
DCCP). At that point, the transport issues would be reviewable. As the docum= ent
currently stands, it completely ignores such transport issues and should not=
proceed until this is addressed and re-reviewed.

If instead, as I suspect, the term =E2=80=9Ctransport encapsulation=E2=80=9D= actually refers to
=E2=80=9Cnetwork layer encapsulation=E2=80=9D or =E2=80=9Clink layer encapsu= lation=E2=80=9D and really implies
some sort of tunnel, there would be no transport area issues to review unles= s
that tunnel were to include a transport protocol as part of the layers of encapsulation. If that is the case, the document should be revised to replac= e
the term =E2=80=9Ctransport=E2=80=9D with something that more accurately des= cribes VXLAN-GPE,
GRE, Ethernet, and IP encapsulation using IETF terminology. Note that
draft-ietf-intarea-tunnels never uses the term =E2=80=9Ctransport=E2=80=9D e= xcept when
referring to the use of IETF transport protocols as a tunnel layer, e.g. (i.= e.,
the last sentence of Sec 8 of this doc is incorrect in implying otherwise).<= br>
(I would also note that neither this doc nor RFC8300 define =E2=80=9Ctranspo= rt
encapsulation=E2=80=9D in their terminology; even if they would, they should= not
attempt to define it in a way inconsistent with widespread use in the IETF).=



--
last-call mailing list
last-call@i= etf.org
https://www.ietf.org/mailman/listinfo/last-call
= --Apple-Mail-43B50022-F870-4A03-86D1-6D43CC45DE89-- From nobody Thu Jul 29 08:02:06 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF0F73A2558; Thu, 29 Jul 2021 08:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 VnCRVTpMXIJa; Thu, 29 Jul 2021 08:01:43 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 0EE623A2560; Thu, 29 Jul 2021 08:01:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4GbDJQ2BkGz1nwVj; Thu, 29 Jul 2021 08:01:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1627570902; bh=AzQzYFSr0Io0C+79psZEw/eHg/rBDxQGm+lzOXiAIqA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=lkmHcSKavW6g+Q0iYJF55ey8a32fynZbn3wSqCOLQf/xTmN5UeBsl2kDs/ixXPQYv UlcFPlSS4bJjgxlfGcJwlDwGKgE8JJ1TKYt+MuEsZftE+IpKzhHpHezQjcWiaSgBay IxHvgi7OKOVNwO6YLG7Rk+5phvOLO71SQNXAz8Xc= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4GbDJP2NtHz1nwg7; Thu, 29 Jul 2021 08:01:41 -0700 (PDT) To: Joe Touch , tirumal reddy Cc: tsv-art@ietf.org, draft-ietf-sfc-nsh-integrity.all@ietf.org, sfc@ietf.org, last-call@ietf.org References: From: "Joel M. Halpern" Message-ID: <031a8199-7a93-afc7-37e4-7fcdb4733c60@joelhalpern.com> Date: Thu, 29 Jul 2021 11:01:39 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] [Last-Call] Tsvart last call review of draft-ietf-sfc-nsh-integrity-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2021 15:01:48 -0000 If you want the terminology usage clarified, then what they have proposed is sufficient. If you want to change RFC 8300, this is not the place to do that. Yours, Joel On 7/29/2021 12:41 AM, Joe Touch wrote: > Insufficient. > >> On Jul 28, 2021, at 7:09 AM, tirumal reddy wrote: >> >>  >> Thanks Joseph for the detailed comment and explanation. We plan to add >> the following text to address the issue: >> >> Note that the term “transport encapsulation” used in this document is >> equivalent to the term “tunnel encapsulation” used In >> [ietf-intarea-tunnel]. >> >> >> Cheers, >> >> -Tiru >> >> >> On Mon, 26 Jul 2021 at 10:34, Joseph Touch via Datatracker >> > wrote: >> >> Reviewer: Joseph Touch >> Review result: Not Ready >> >> This document has been reviewed as part of the transport area >> review team's >> 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 and WG to allow them to address any issues raised and also >> to the IETF >> discussion list for information. >> >> When done at the time of IETF Last Call, the authors should >> consider this >> review as part of the last-call comments they receive. Please >> always CC >> tsv-art@ietf.org if you reply to or >> forward this review. >> >> It was very difficult to review this document for IETF transport >> protocol >> considerations. >> >> Although "transport encapsulation" is indicated repeatedly, it is >> never >> referred to directly or described either in this document or its >> citations. It >> appears to be using this term in the sense of RFC8300, which too >> never defines >> it, but uses examples that are more accurately referred to in the >> IETF as link >> layer protocols or either network or link tunnel protocols (IP in >> IP, GRE, >> VXLAN, Ethernet). >> >> Regardless of the fact that this confusion originates in RFC8300, >> it needs to >> be addressed here and corrected before this document can be >> reviewed to >> determine if there are any IETF transport area issues. >> >> The remainder of these notes provide detail of this issue. >> >> ----- >> >> The document refers back to RFC8300 to define the NSH itself; that >> document >> discusses transport issues just as vaguely (never mentioning a >> particular >> transport protocol), and when it discusses fragmentation, it >> refers to section >> 9 of a document (draft-ietf-rtgwg-dt-encap-02 from 2017) that had >> expired prior >> to the publication of RFC8300.  Because transport fragmentation >> is, IMO, a >> normative issue, this should not have been permitted. >> >> Further, Section 9 of that draft incorrectly recommends reliance >> on ICMP >> feedback to address MTU failures when not under a single >> operator’s management. >> That was widely known even then to be insufficient due to >> blackholing; this had >> motivated PLPMTUD in RFC4821 a full decade earlier. RFC8300 >> compounds this >> error by simply asserting that the operator should ensure that >> ICMPs are not >> blocked, overlooking the need to address when this is not the case. >> >> This document cannot ignore that issue and simply refer to RFC8300 >> on this >> issue. >> >> Note that one of the only places an actual encapsulation protocol >> is mentioned >> is RFC8300, in which Section 5 mentions IP and  Section 6.1 Table >> 1 describes >> VXLAN-GPE, GRE, and Ethernet – all of which are described as >> “transport >> encapsulation”. >> >> If, in fact, IETF transport protocols are being used, at some >> point the use of >> an actual IETF transport protocol should be described (e.g., TCP, >> UDP, SCTP, >> DCCP). At that point, the transport issues would be reviewable. As >> the document >> currently stands, it completely ignores such transport issues and >> should not >> proceed until this is addressed and re-reviewed. >> >> If instead, as I suspect, the term “transport encapsulation” >> actually refers to >> “network layer encapsulation” or “link layer encapsulation” and >> really implies >> some sort of tunnel, there would be no transport area issues to >> review unless >> that tunnel were to include a transport protocol as part of the >> layers of >> encapsulation. If that is the case, the document should be revised >> to replace >> the term “transport” with something that more accurately describes >> VXLAN-GPE, >> GRE, Ethernet, and IP encapsulation using IETF terminology. Note that >> draft-ietf-intarea-tunnels never uses the term “transport” except when >> referring to the use of IETF transport protocols as a tunnel >> layer, e.g. (i.e., >> the last sentence of Sec 8 of this doc is incorrect in implying >> otherwise). >> >> (I would also note that neither this doc nor RFC8300 define “transport >> encapsulation” in their terminology; even if they would, they >> should not >> attempt to define it in a way inconsistent with widespread use in >> the IETF). >> >> >> >> -- >> last-call mailing list >> last-call@ietf.org >> https://www.ietf.org/mailman/listinfo/last-call From nobody Thu Jul 29 08:21:26 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 185623A25F1; Thu, 29 Jul 2021 08:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.32 X-Spam-Level: X-Spam-Status: No, score=-1.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 n1NeuA9VDGpT; Thu, 29 Jul 2021 08:21:12 -0700 (PDT) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 3B2DB3A2657; Thu, 29 Jul 2021 08:21:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=/JgIbfeXSEMGpttQD7tcS8cQ/qsrhLRy7oErnCBEROI=; b=GhSvC/B8iHvoxFYGAAuh4dZd0f w78bRRSdlhrpzbBXa0T87L48c/6546ikXnNNQbjmz7wVUlHTUf0psfSTIIErY2kKMea97D8Mby1em fp/5i4Qh1/aigYxJ0M7Bnrouc+BHgUfgyVeTz6dIPBZ+Zk5aU5StR150iwdOzd7QkDr8EPy2H7m60 0fLbNCDTca9/7t2kREKp0KWCdrzUPQ5ABP7jMIQZBCUln4bhhKFW08Igbabr5K16G+O7kqRaFFgSJ QgA3CFRvKNBV4CJyjgN6fDQUis89M5IpkpUCsUM+V9RdwG6ZWfkeay1UCd7mGTRUJfz7e1dyq1BlN Y4SKYO3Q==; Received: from cpe-172-114-237-88.socal.res.rr.com ([172.114.237.88]:50286 helo=smtpclient.apple) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1m97qK-000R8T-GZ; Thu, 29 Jul 2021 11:21:09 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Joseph Touch In-Reply-To: <031a8199-7a93-afc7-37e4-7fcdb4733c60@joelhalpern.com> Date: Thu, 29 Jul 2021 08:21:01 -0700 Cc: tirumal reddy , tsv-art , draft-ietf-sfc-nsh-integrity.all@ietf.org, sfc@ietf.org, last-call@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <45937185-139B-4948-8635-DBAAE044F797@strayalpha.com> References: <031a8199-7a93-afc7-37e4-7fcdb4733c60@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3654.120.0.1.13) X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [sfc] [Last-Call] Tsvart last call review of draft-ietf-sfc-nsh-integrity-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2021 15:21:18 -0000 Joel, I performed this review for the transport area. An IETF document should never attempt to redefine the word = =E2=80=9Ctransport=E2=80=9D in a single sentence and refer to an = unpublished draft (even mine) to explain. It takes more than that. > On Jul 29, 2021, at 8:01 AM, Joel M. Halpern = wrote: >=20 > If you want the terminology usage clarified, then what they have = proposed is sufficient. >=20 > If you want to change RFC 8300, this is not the place to do that. Agreed, but we cannot continue to propagate the error. At a minimum, the = sentence should clarify that the term is being used inconsistently with = the rest of IETF as a whole and explain what it means in a stand-alone = way. That either warrants a separate (even if brief) section or at least = a terminology section entry. Additionally, it is not feasible to review how their approach - which = makes packets bigger, necessarily - without understanding how that = tunneling works. Joe > On 7/29/2021 12:41 AM, Joe Touch wrote: >> Insufficient. >>> On Jul 28, 2021, at 7:09 AM, tirumal reddy = wrote: >>>=20 >>> =EF=BB=BF >>> Thanks Joseph for the detailed comment and explanation. We plan to = add the following text to address the issue: >>>=20 >>> Note that the term =E2=80=9Ctransport encapsulation=E2=80=9D used in = this document is equivalent to the term =E2=80=9Ctunnel encapsulation=E2=80= =9D used In [ietf-intarea-tunnel]. >>>=20 >>>=20 >>> Cheers, >>>=20 >>> -Tiru >>>=20 >>>=20 >>> On Mon, 26 Jul 2021 at 10:34, Joseph Touch via Datatracker = > wrote: >>>=20 >>> Reviewer: Joseph Touch >>> Review result: Not Ready >>>=20 >>> This document has been reviewed as part of the transport area >>> review team's >>> 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 and WG to allow them to address any issues raised and = also >>> to the IETF >>> discussion list for information. >>>=20 >>> When done at the time of IETF Last Call, the authors should >>> consider this >>> review as part of the last-call comments they receive. Please >>> always CC >>> tsv-art@ietf.org if you reply to or >>> forward this review. >>>=20 >>> It was very difficult to review this document for IETF transport >>> protocol >>> considerations. >>>=20 >>> Although "transport encapsulation" is indicated repeatedly, it is >>> never >>> referred to directly or described either in this document or its >>> citations. It >>> appears to be using this term in the sense of RFC8300, which too >>> never defines >>> it, but uses examples that are more accurately referred to in the >>> IETF as link >>> layer protocols or either network or link tunnel protocols (IP in >>> IP, GRE, >>> VXLAN, Ethernet). >>>=20 >>> Regardless of the fact that this confusion originates in RFC8300, >>> it needs to >>> be addressed here and corrected before this document can be >>> reviewed to >>> determine if there are any IETF transport area issues. >>>=20 >>> The remainder of these notes provide detail of this issue. >>>=20 >>> ----- >>>=20 >>> The document refers back to RFC8300 to define the NSH itself; = that >>> document >>> discusses transport issues just as vaguely (never mentioning a >>> particular >>> transport protocol), and when it discusses fragmentation, it >>> refers to section >>> 9 of a document (draft-ietf-rtgwg-dt-encap-02 from 2017) that had >>> expired prior >>> to the publication of RFC8300. Because transport fragmentation >>> is, IMO, a >>> normative issue, this should not have been permitted. >>>=20 >>> Further, Section 9 of that draft incorrectly recommends reliance >>> on ICMP >>> feedback to address MTU failures when not under a single >>> operator=E2=80=99s management. >>> That was widely known even then to be insufficient due to >>> blackholing; this had >>> motivated PLPMTUD in RFC4821 a full decade earlier. RFC8300 >>> compounds this >>> error by simply asserting that the operator should ensure that >>> ICMPs are not >>> blocked, overlooking the need to address when this is not the = case. >>>=20 >>> This document cannot ignore that issue and simply refer to = RFC8300 >>> on this >>> issue. >>>=20 >>> Note that one of the only places an actual encapsulation protocol >>> is mentioned >>> is RFC8300, in which Section 5 mentions IP and Section 6.1 Table >>> 1 describes >>> VXLAN-GPE, GRE, and Ethernet =E2=80=93 all of which are described = as >>> =E2=80=9Ctransport >>> encapsulation=E2=80=9D. >>>=20 >>> If, in fact, IETF transport protocols are being used, at some >>> point the use of >>> an actual IETF transport protocol should be described (e.g., TCP, >>> UDP, SCTP, >>> DCCP). At that point, the transport issues would be reviewable. = As >>> the document >>> currently stands, it completely ignores such transport issues and >>> should not >>> proceed until this is addressed and re-reviewed. >>>=20 >>> If instead, as I suspect, the term =E2=80=9Ctransport = encapsulation=E2=80=9D >>> actually refers to >>> =E2=80=9Cnetwork layer encapsulation=E2=80=9D or =E2=80=9Clink = layer encapsulation=E2=80=9D and >>> really implies >>> some sort of tunnel, there would be no transport area issues to >>> review unless >>> that tunnel were to include a transport protocol as part of the >>> layers of >>> encapsulation. If that is the case, the document should be = revised >>> to replace >>> the term =E2=80=9Ctransport=E2=80=9D with something that more = accurately describes >>> VXLAN-GPE, >>> GRE, Ethernet, and IP encapsulation using IETF terminology. Note = that >>> draft-ietf-intarea-tunnels never uses the term =E2=80=9Ctransport=E2= =80=9D except when >>> referring to the use of IETF transport protocols as a tunnel >>> layer, e.g. (i.e., >>> the last sentence of Sec 8 of this doc is incorrect in implying >>> otherwise). >>>=20 >>> (I would also note that neither this doc nor RFC8300 define = =E2=80=9Ctransport >>> encapsulation=E2=80=9D in their terminology; even if they would, = they >>> should not >>> attempt to define it in a way inconsistent with widespread use in >>> the IETF). >>>=20 >>>=20 >>>=20 >>> --=20 >>> last-call mailing list >>> last-call@ietf.org >>> https://www.ietf.org/mailman/listinfo/last-call >=20 > --=20 > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call From nobody Thu Jul 29 08:45:04 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87EA43A0865; Thu, 29 Jul 2021 08:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 yR9Rz-_J8IfL; Thu, 29 Jul 2021 08:44:50 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 2059A3A082E; Thu, 29 Jul 2021 08:44:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4GbFG55drCz1ntsV; Thu, 29 Jul 2021 08:44:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1627573485; bh=t0IMClxLdJkMkljdNjfteoih2rPpl79RQIjvkipW/VI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=pAwxIn9iyWl3gh5yzW0/tAlOIBOs6CzdJZPwaW13y8M5p4ek+S2T+FBLNOj9vMd4o Qenfho+Fhl2sRXMR0lY9ePv+7lANMSOeK9uFG4mlSUcmKsnsUhPzrxfnAVUQzZ8Xo1 ecmm+KbINFhiuFF/38UA1oSc8ALjPR9QVpRGTAX8= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4GbFG4402Gz1nsyQ; Thu, 29 Jul 2021 08:44:44 -0700 (PDT) To: Joseph Touch Cc: tsv-art , draft-ietf-sfc-nsh-integrity.all@ietf.org, last-call@ietf.org, sfc@ietf.org, tirumal reddy References: <031a8199-7a93-afc7-37e4-7fcdb4733c60@joelhalpern.com> <45937185-139B-4948-8635-DBAAE044F797@strayalpha.com> From: "Joel M. Halpern" Message-ID: <9df24c0f-1462-037a-8d86-b55356a0ae67@joelhalpern.com> Date: Thu, 29 Jul 2021 11:44:42 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <45937185-139B-4948-8635-DBAAE044F797@strayalpha.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] [Last-Call] Tsvart last call review of draft-ietf-sfc-nsh-integrity-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2021 15:44:58 -0000 "Insufficient" is not an acceptable answer from a reviewer. it is not even an acceptable answer from an AD. I do understand that your review is on behalf of the TSV Area Directors. If you are not willing to be more clear about what (within the constraints that we are NOT rewriting 8300) is going to be helpful, then we will leave it to the Transport ADs. We will not play "fetch a rock" / "no not that rock" until you are happy. Yours, Joel On 7/29/2021 11:21 AM, Joseph Touch wrote: > Joel, > > I performed this review for the transport area. > > An IETF document should never attempt to redefine the word “transport” in a single sentence and refer to an unpublished draft (even mine) to explain. It takes more than that. > >> On Jul 29, 2021, at 8:01 AM, Joel M. Halpern wrote: >> >> If you want the terminology usage clarified, then what they have proposed is sufficient. >> >> If you want to change RFC 8300, this is not the place to do that. > > Agreed, but we cannot continue to propagate the error. At a minimum, the sentence should clarify that the term is being used inconsistently with the rest of IETF as a whole and explain what it means in a stand-alone way. That either warrants a separate (even if brief) section or at least a terminology section entry. > > Additionally, it is not feasible to review how their approach - which makes packets bigger, necessarily - without understanding how that tunneling works. > > Joe > >> On 7/29/2021 12:41 AM, Joe Touch wrote: >>> Insufficient. >>>> On Jul 28, 2021, at 7:09 AM, tirumal reddy wrote: >>>> >>>>  >>>> Thanks Joseph for the detailed comment and explanation. We plan to add the following text to address the issue: >>>> >>>> Note that the term “transport encapsulation” used in this document is equivalent to the term “tunnel encapsulation” used In [ietf-intarea-tunnel]. >>>> >>>> >>>> Cheers, >>>> >>>> -Tiru >>>> >>>> >>>> On Mon, 26 Jul 2021 at 10:34, Joseph Touch via Datatracker > wrote: >>>> >>>> Reviewer: Joseph Touch >>>> Review result: Not Ready >>>> >>>> This document has been reviewed as part of the transport area >>>> review team's >>>> 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 and WG to allow them to address any issues raised and also >>>> to the IETF >>>> discussion list for information. >>>> >>>> When done at the time of IETF Last Call, the authors should >>>> consider this >>>> review as part of the last-call comments they receive. Please >>>> always CC >>>> tsv-art@ietf.org if you reply to or >>>> forward this review. >>>> >>>> It was very difficult to review this document for IETF transport >>>> protocol >>>> considerations. >>>> >>>> Although "transport encapsulation" is indicated repeatedly, it is >>>> never >>>> referred to directly or described either in this document or its >>>> citations. It >>>> appears to be using this term in the sense of RFC8300, which too >>>> never defines >>>> it, but uses examples that are more accurately referred to in the >>>> IETF as link >>>> layer protocols or either network or link tunnel protocols (IP in >>>> IP, GRE, >>>> VXLAN, Ethernet). >>>> >>>> Regardless of the fact that this confusion originates in RFC8300, >>>> it needs to >>>> be addressed here and corrected before this document can be >>>> reviewed to >>>> determine if there are any IETF transport area issues. >>>> >>>> The remainder of these notes provide detail of this issue. >>>> >>>> ----- >>>> >>>> The document refers back to RFC8300 to define the NSH itself; that >>>> document >>>> discusses transport issues just as vaguely (never mentioning a >>>> particular >>>> transport protocol), and when it discusses fragmentation, it >>>> refers to section >>>> 9 of a document (draft-ietf-rtgwg-dt-encap-02 from 2017) that had >>>> expired prior >>>> to the publication of RFC8300. Because transport fragmentation >>>> is, IMO, a >>>> normative issue, this should not have been permitted. >>>> >>>> Further, Section 9 of that draft incorrectly recommends reliance >>>> on ICMP >>>> feedback to address MTU failures when not under a single >>>> operator’s management. >>>> That was widely known even then to be insufficient due to >>>> blackholing; this had >>>> motivated PLPMTUD in RFC4821 a full decade earlier. RFC8300 >>>> compounds this >>>> error by simply asserting that the operator should ensure that >>>> ICMPs are not >>>> blocked, overlooking the need to address when this is not the case. >>>> >>>> This document cannot ignore that issue and simply refer to RFC8300 >>>> on this >>>> issue. >>>> >>>> Note that one of the only places an actual encapsulation protocol >>>> is mentioned >>>> is RFC8300, in which Section 5 mentions IP and Section 6.1 Table >>>> 1 describes >>>> VXLAN-GPE, GRE, and Ethernet – all of which are described as >>>> “transport >>>> encapsulation”. >>>> >>>> If, in fact, IETF transport protocols are being used, at some >>>> point the use of >>>> an actual IETF transport protocol should be described (e.g., TCP, >>>> UDP, SCTP, >>>> DCCP). At that point, the transport issues would be reviewable. As >>>> the document >>>> currently stands, it completely ignores such transport issues and >>>> should not >>>> proceed until this is addressed and re-reviewed. >>>> >>>> If instead, as I suspect, the term “transport encapsulation” >>>> actually refers to >>>> “network layer encapsulation” or “link layer encapsulation” and >>>> really implies >>>> some sort of tunnel, there would be no transport area issues to >>>> review unless >>>> that tunnel were to include a transport protocol as part of the >>>> layers of >>>> encapsulation. If that is the case, the document should be revised >>>> to replace >>>> the term “transport” with something that more accurately describes >>>> VXLAN-GPE, >>>> GRE, Ethernet, and IP encapsulation using IETF terminology. Note that >>>> draft-ietf-intarea-tunnels never uses the term “transport” except when >>>> referring to the use of IETF transport protocols as a tunnel >>>> layer, e.g. (i.e., >>>> the last sentence of Sec 8 of this doc is incorrect in implying >>>> otherwise). >>>> >>>> (I would also note that neither this doc nor RFC8300 define “transport >>>> encapsulation” in their terminology; even if they would, they >>>> should not >>>> attempt to define it in a way inconsistent with widespread use in >>>> the IETF). >>>> >>>> >>>> >>>> -- >>>> last-call mailing list >>>> last-call@ietf.org >>>> https://www.ietf.org/mailman/listinfo/last-call >> >> -- >> last-call mailing list >> last-call@ietf.org >> https://www.ietf.org/mailman/listinfo/last-call > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Thu Jul 29 09:33:18 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9CA3A0B85; Thu, 29 Jul 2021 09:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.32 X-Spam-Level: X-Spam-Status: No, score=-1.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 qIpcKG9g6i3q; Thu, 29 Jul 2021 09:33:11 -0700 (PDT) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 1B9403A0B80; Thu, 29 Jul 2021 09:33:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=538NubAObvvkIKTnLSi//b1E8woB149pDGvGSIZ0YYw=; b=S+4oc6ZKLO9DLU8Zrwl0WIf8uD /wLQQuO0mVlE4uoNbVD12xKRmUHaeDWmE4T86gTHHXqjq+KRkbBWxId9E8DiU1ecQEA1CjMibwoiV qACkwBemI9/6dLH4221iLMebUyPfZvPah8LIguYocbocaveaCS/gw28Yy/U5BYyrFkD9uq4QovshU Fbb0/hoQi/cj7GEtw3Q5AWoB2mYCfUfSKMLP9jIBoAcpG25bYgPw7xPoIFM9W66R3rBsX/R7SUjbc Q0KoDBsmJq8/TKXMUDzUgsjSnWT3s1s5aVn8YU/4Bo6Otq8aeSfCpL3TaoC2iWZB+mxb50Q4VfHDP str8JO2g==; Received: from cpe-172-114-237-88.socal.res.rr.com ([172.114.237.88]:50728 helo=smtpclient.apple) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1m98y1-001qct-Hi; Thu, 29 Jul 2021 12:33:10 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Joseph Touch In-Reply-To: <9df24c0f-1462-037a-8d86-b55356a0ae67@joelhalpern.com> Date: Thu, 29 Jul 2021 09:33:04 -0700 Cc: tirumal reddy , tsv-art , draft-ietf-sfc-nsh-integrity.all@ietf.org, sfc@ietf.org, last-call@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3B5E8814-522D-4559-AE2D-3B2D8119EE24@strayalpha.com> References: <031a8199-7a93-afc7-37e4-7fcdb4733c60@joelhalpern.com> <45937185-139B-4948-8635-DBAAE044F797@strayalpha.com> <9df24c0f-1462-037a-8d86-b55356a0ae67@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3654.120.0.1.13) X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [sfc] [Last-Call] Tsvart last call review of draft-ietf-sfc-nsh-integrity-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2021 16:33:16 -0000 Joel, > On Jul 29, 2021, at 8:44 AM, Joel M. Halpern = wrote: >=20 > "Insufficient" is not an acceptable answer from a reviewer. it is not = even an acceptable answer from an AD. My review is commensurate with the response. > I do understand that your review is on behalf of the TSV Area = Directors. If you are not willing to be more clear about what (within = the constraints that we are NOT rewriting 8300) is going to be helpful, = then we will leave it to the Transport ADs. I did below, when I received engagement commensurate with the review I = provided. > We will not play "fetch a rock" / "no not that rock" until you are = happy. That is your decision; it is mine as to what constitutes a single = sentence followup on a review that already provided much more detail = than =E2=80=9Cfetch a rock=E2=80=9D.=20 Nor will I play =E2=80=9Cignore the review and redefine the very term = that defines the area providing that review=E2=80=9D. Joe > Yours, > Joel >=20 > On 7/29/2021 11:21 AM, Joseph Touch wrote: >> Joel, >> I performed this review for the transport area. >> An IETF document should never attempt to redefine the word = =E2=80=9Ctransport=E2=80=9D in a single sentence and refer to an = unpublished draft (even mine) to explain. It takes more than that. >>> On Jul 29, 2021, at 8:01 AM, Joel M. Halpern = wrote: >>>=20 >>> If you want the terminology usage clarified, then what they have = proposed is sufficient. >>>=20 >>> If you want to change RFC 8300, this is not the place to do that. >> Agreed, but we cannot continue to propagate the error. At a minimum, = the sentence should clarify that the term is being used inconsistently = with the rest of IETF as a whole and explain what it means in a = stand-alone way. That either warrants a separate (even if brief) section = or at least a terminology section entry. >> Additionally, it is not feasible to review how their approach - which = makes packets bigger, necessarily - without understanding how that = tunneling works. >> Joe >>> On 7/29/2021 12:41 AM, Joe Touch wrote: >>>> Insufficient. >>>>> On Jul 28, 2021, at 7:09 AM, tirumal reddy = wrote: >>>>>=20 >>>>> =EF=BB=BF >>>>> Thanks Joseph for the detailed comment and explanation. We plan to = add the following text to address the issue: >>>>>=20 >>>>> Note that the term =E2=80=9Ctransport encapsulation=E2=80=9D used = in this document is equivalent to the term =E2=80=9Ctunnel = encapsulation=E2=80=9D used In [ietf-intarea-tunnel]. >>>>>=20 >>>>>=20 >>>>> Cheers, >>>>>=20 >>>>> -Tiru >>>>>=20 >>>>>=20 >>>>> On Mon, 26 Jul 2021 at 10:34, Joseph Touch via Datatracker = > wrote: >>>>>=20 >>>>> Reviewer: Joseph Touch >>>>> Review result: Not Ready >>>>>=20 >>>>> This document has been reviewed as part of the transport area >>>>> review team's >>>>> 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 and WG to allow them to address any issues raised and = also >>>>> to the IETF >>>>> discussion list for information. >>>>>=20 >>>>> When done at the time of IETF Last Call, the authors should >>>>> consider this >>>>> review as part of the last-call comments they receive. Please >>>>> always CC >>>>> tsv-art@ietf.org if you reply to or >>>>> forward this review. >>>>>=20 >>>>> It was very difficult to review this document for IETF = transport >>>>> protocol >>>>> considerations. >>>>>=20 >>>>> Although "transport encapsulation" is indicated repeatedly, it = is >>>>> never >>>>> referred to directly or described either in this document or = its >>>>> citations. It >>>>> appears to be using this term in the sense of RFC8300, which = too >>>>> never defines >>>>> it, but uses examples that are more accurately referred to in = the >>>>> IETF as link >>>>> layer protocols or either network or link tunnel protocols (IP = in >>>>> IP, GRE, >>>>> VXLAN, Ethernet). >>>>>=20 >>>>> Regardless of the fact that this confusion originates in = RFC8300, >>>>> it needs to >>>>> be addressed here and corrected before this document can be >>>>> reviewed to >>>>> determine if there are any IETF transport area issues. >>>>>=20 >>>>> The remainder of these notes provide detail of this issue. >>>>>=20 >>>>> ----- >>>>>=20 >>>>> The document refers back to RFC8300 to define the NSH itself; = that >>>>> document >>>>> discusses transport issues just as vaguely (never mentioning a >>>>> particular >>>>> transport protocol), and when it discusses fragmentation, it >>>>> refers to section >>>>> 9 of a document (draft-ietf-rtgwg-dt-encap-02 from 2017) that = had >>>>> expired prior >>>>> to the publication of RFC8300. Because transport fragmentation >>>>> is, IMO, a >>>>> normative issue, this should not have been permitted. >>>>>=20 >>>>> Further, Section 9 of that draft incorrectly recommends = reliance >>>>> on ICMP >>>>> feedback to address MTU failures when not under a single >>>>> operator=E2=80=99s management. >>>>> That was widely known even then to be insufficient due to >>>>> blackholing; this had >>>>> motivated PLPMTUD in RFC4821 a full decade earlier. RFC8300 >>>>> compounds this >>>>> error by simply asserting that the operator should ensure that >>>>> ICMPs are not >>>>> blocked, overlooking the need to address when this is not the = case. >>>>>=20 >>>>> This document cannot ignore that issue and simply refer to = RFC8300 >>>>> on this >>>>> issue. >>>>>=20 >>>>> Note that one of the only places an actual encapsulation = protocol >>>>> is mentioned >>>>> is RFC8300, in which Section 5 mentions IP and Section 6.1 = Table >>>>> 1 describes >>>>> VXLAN-GPE, GRE, and Ethernet =E2=80=93 all of which are = described as >>>>> =E2=80=9Ctransport >>>>> encapsulation=E2=80=9D. >>>>>=20 >>>>> If, in fact, IETF transport protocols are being used, at some >>>>> point the use of >>>>> an actual IETF transport protocol should be described (e.g., = TCP, >>>>> UDP, SCTP, >>>>> DCCP). At that point, the transport issues would be reviewable. = As >>>>> the document >>>>> currently stands, it completely ignores such transport issues = and >>>>> should not >>>>> proceed until this is addressed and re-reviewed. >>>>>=20 >>>>> If instead, as I suspect, the term =E2=80=9Ctransport = encapsulation=E2=80=9D >>>>> actually refers to >>>>> =E2=80=9Cnetwork layer encapsulation=E2=80=9D or =E2=80=9Clink = layer encapsulation=E2=80=9D and >>>>> really implies >>>>> some sort of tunnel, there would be no transport area issues to >>>>> review unless >>>>> that tunnel were to include a transport protocol as part of the >>>>> layers of >>>>> encapsulation. If that is the case, the document should be = revised >>>>> to replace >>>>> the term =E2=80=9Ctransport=E2=80=9D with something that more = accurately describes >>>>> VXLAN-GPE, >>>>> GRE, Ethernet, and IP encapsulation using IETF terminology. = Note that >>>>> draft-ietf-intarea-tunnels never uses the term =E2=80=9Ctransport= =E2=80=9D except when >>>>> referring to the use of IETF transport protocols as a tunnel >>>>> layer, e.g. (i.e., >>>>> the last sentence of Sec 8 of this doc is incorrect in implying >>>>> otherwise). >>>>>=20 >>>>> (I would also note that neither this doc nor RFC8300 define = =E2=80=9Ctransport >>>>> encapsulation=E2=80=9D in their terminology; even if they = would, they >>>>> should not >>>>> attempt to define it in a way inconsistent with widespread use = in >>>>> the IETF). >>>>>=20 >>>>>=20 >>>>>=20 >>>>> --=20 >>>>> last-call mailing list >>>>> last-call@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/last-call >>>=20 >>> --=20 >>> last-call mailing list >>> last-call@ietf.org >>> https://www.ietf.org/mailman/listinfo/last-call >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >=20 > --=20 > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call From nobody Thu Jul 29 09:45:16 2021 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD2C3A0C90; Thu, 29 Jul 2021 09:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 Ck1l9eUTSYzS; Thu, 29 Jul 2021 09:45:09 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 427B93A0C85; Thu, 29 Jul 2021 09:45:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4GbGbj2sFMz1nvff; Thu, 29 Jul 2021 09:45:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1627577105; bh=6HlcclVLAXPcsJN2heUKsHhAuO7/9bEzbAhhpVgSs9o=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=K3cP/AP/Pk9T7QR+ooufdSczO/UlErAMcd3nAoqcOknn5gv0b0zMBUb/oZRH0H7XK A6N1pj7mRv+vufdtQkdznCX4SH0Mzenh+aHW5iSwWbqn3VnqKY9LIw8EdfAIN9n8Mm KTCHv+YF4+TPGXBi2+lCIdStko6eX/vloFp3RNdI= X-Quarantine-ID: <2HQD7aR_xcS2> X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4GbGbh58t8z1ntsV; Thu, 29 Jul 2021 09:45:04 -0700 (PDT) To: draft-ietf-sfc-nsh-integrity.all@ietf.org Cc: sfc@ietf.org, last-call@ietf.org References: <031a8199-7a93-afc7-37e4-7fcdb4733c60@joelhalpern.com> <45937185-139B-4948-8635-DBAAE044F797@strayalpha.com> <9df24c0f-1462-037a-8d86-b55356a0ae67@joelhalpern.com> <3B5E8814-522D-4559-AE2D-3B2D8119EE24@strayalpha.com> From: "Joel M. Halpern" Message-ID: <5a5e84a2-73f5-9ef9-1c4c-40b6580c9f15@joelhalpern.com> Date: Thu, 29 Jul 2021 12:45:02 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <3B5E8814-522D-4559-AE2D-3B2D8119EE24@strayalpha.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] [Last-Call] Tsvart last call review of draft-ietf-sfc-nsh-integrity-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2021 16:45:14 -0000 Authors. If there is something you see as reasonable and consistent with the working groups work that you think would help, please do taht. Otherwise, we will leave this reiew situation for the transport ADs to resolve. Yours, Joel On 7/29/2021 12:33 PM, Joseph Touch wrote: > Joel, > >> On Jul 29, 2021, at 8:44 AM, Joel M. Halpern wrote: >> >> "Insufficient" is not an acceptable answer from a reviewer. it is not even an acceptable answer from an AD. > > My review is commensurate with the response. > >> I do understand that your review is on behalf of the TSV Area Directors. If you are not willing to be more clear about what (within the constraints that we are NOT rewriting 8300) is going to be helpful, then we will leave it to the Transport ADs. > > I did below, when I received engagement commensurate with the review I provided. > >> We will not play "fetch a rock" / "no not that rock" until you are happy. > > That is your decision; it is mine as to what constitutes a single sentence followup on a review that already provided much more detail than “fetch a rock”. > > Nor will I play “ignore the review and redefine the very term that defines the area providing that review”. > > Joe > >> Yours, >> Joel >> >> On 7/29/2021 11:21 AM, Joseph Touch wrote: >>> Joel, >>> I performed this review for the transport area. >>> An IETF document should never attempt to redefine the word “transport” in a single sentence and refer to an unpublished draft (even mine) to explain. It takes more than that. >>>> On Jul 29, 2021, at 8:01 AM, Joel M. Halpern wrote: >>>> >>>> If you want the terminology usage clarified, then what they have proposed is sufficient. >>>> >>>> If you want to change RFC 8300, this is not the place to do that. >>> Agreed, but we cannot continue to propagate the error. At a minimum, the sentence should clarify that the term is being used inconsistently with the rest of IETF as a whole and explain what it means in a stand-alone way. That either warrants a separate (even if brief) section or at least a terminology section entry. >>> Additionally, it is not feasible to review how their approach - which makes packets bigger, necessarily - without understanding how that tunneling works. >>> Joe >>>> On 7/29/2021 12:41 AM, Joe Touch wrote: >>>>> Insufficient. >>>>>> On Jul 28, 2021, at 7:09 AM, tirumal reddy wrote: >>>>>> >>>>>>  >>>>>> Thanks Joseph for the detailed comment and explanation. We plan to add the following text to address the issue: >>>>>> >>>>>> Note that the term “transport encapsulation” used in this document is equivalent to the term “tunnel encapsulation” used In [ietf-intarea-tunnel]. >>>>>> >>>>>> >>>>>> Cheers, >>>>>> >>>>>> -Tiru >>>>>> >>>>>> >>>>>> On Mon, 26 Jul 2021 at 10:34, Joseph Touch via Datatracker > wrote: >>>>>> >>>>>> Reviewer: Joseph Touch >>>>>> Review result: Not Ready >>>>>> >>>>>> This document has been reviewed as part of the transport area >>>>>> review team's >>>>>> 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 and WG to allow them to address any issues raised and also >>>>>> to the IETF >>>>>> discussion list for information. >>>>>> >>>>>> When done at the time of IETF Last Call, the authors should >>>>>> consider this >>>>>> review as part of the last-call comments they receive. Please >>>>>> always CC >>>>>> tsv-art@ietf.org if you reply to or >>>>>> forward this review. >>>>>> >>>>>> It was very difficult to review this document for IETF transport >>>>>> protocol >>>>>> considerations. >>>>>> >>>>>> Although "transport encapsulation" is indicated repeatedly, it is >>>>>> never >>>>>> referred to directly or described either in this document or its >>>>>> citations. It >>>>>> appears to be using this term in the sense of RFC8300, which too >>>>>> never defines >>>>>> it, but uses examples that are more accurately referred to in the >>>>>> IETF as link >>>>>> layer protocols or either network or link tunnel protocols (IP in >>>>>> IP, GRE, >>>>>> VXLAN, Ethernet). >>>>>> >>>>>> Regardless of the fact that this confusion originates in RFC8300, >>>>>> it needs to >>>>>> be addressed here and corrected before this document can be >>>>>> reviewed to >>>>>> determine if there are any IETF transport area issues. >>>>>> >>>>>> The remainder of these notes provide detail of this issue. >>>>>> >>>>>> ----- >>>>>> >>>>>> The document refers back to RFC8300 to define the NSH itself; that >>>>>> document >>>>>> discusses transport issues just as vaguely (never mentioning a >>>>>> particular >>>>>> transport protocol), and when it discusses fragmentation, it >>>>>> refers to section >>>>>> 9 of a document (draft-ietf-rtgwg-dt-encap-02 from 2017) that had >>>>>> expired prior >>>>>> to the publication of RFC8300. Because transport fragmentation >>>>>> is, IMO, a >>>>>> normative issue, this should not have been permitted. >>>>>> >>>>>> Further, Section 9 of that draft incorrectly recommends reliance >>>>>> on ICMP >>>>>> feedback to address MTU failures when not under a single >>>>>> operator’s management. >>>>>> That was widely known even then to be insufficient due to >>>>>> blackholing; this had >>>>>> motivated PLPMTUD in RFC4821 a full decade earlier. RFC8300 >>>>>> compounds this >>>>>> error by simply asserting that the operator should ensure that >>>>>> ICMPs are not >>>>>> blocked, overlooking the need to address when this is not the case. >>>>>> >>>>>> This document cannot ignore that issue and simply refer to RFC8300 >>>>>> on this >>>>>> issue. >>>>>> >>>>>> Note that one of the only places an actual encapsulation protocol >>>>>> is mentioned >>>>>> is RFC8300, in which Section 5 mentions IP and Section 6.1 Table >>>>>> 1 describes >>>>>> VXLAN-GPE, GRE, and Ethernet – all of which are described as >>>>>> “transport >>>>>> encapsulation”. >>>>>> >>>>>> If, in fact, IETF transport protocols are being used, at some >>>>>> point the use of >>>>>> an actual IETF transport protocol should be described (e.g., TCP, >>>>>> UDP, SCTP, >>>>>> DCCP). At that point, the transport issues would be reviewable. As >>>>>> the document >>>>>> currently stands, it completely ignores such transport issues and >>>>>> should not >>>>>> proceed until this is addressed and re-reviewed. >>>>>> >>>>>> If instead, as I suspect, the term “transport encapsulation” >>>>>> actually refers to >>>>>> “network layer encapsulation” or “link layer encapsulation” and >>>>>> really implies >>>>>> some sort of tunnel, there would be no transport area issues to >>>>>> review unless >>>>>> that tunnel were to include a transport protocol as part of the >>>>>> layers of >>>>>> encapsulation. If that is the case, the document should be revised >>>>>> to replace >>>>>> the term “transport” with something that more accurately describes >>>>>> VXLAN-GPE, >>>>>> GRE, Ethernet, and IP encapsulation using IETF terminology. Note that >>>>>> draft-ietf-intarea-tunnels never uses the term “transport” except when >>>>>> referring to the use of IETF transport protocols as a tunnel >>>>>> layer, e.g. (i.e., >>>>>> the last sentence of Sec 8 of this doc is incorrect in implying >>>>>> otherwise). >>>>>> >>>>>> (I would also note that neither this doc nor RFC8300 define “transport >>>>>> encapsulation” in their terminology; even if they would, they >>>>>> should not >>>>>> attempt to define it in a way inconsistent with widespread use in >>>>>> the IETF). >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> last-call mailing list >>>>>> last-call@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/last-call >>>> >>>> -- >>>> last-call mailing list >>>> last-call@ietf.org >>>> https://www.ietf.org/mailman/listinfo/last-call >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >> >> -- >> last-call mailing list >> last-call@ietf.org >> https://www.ietf.org/mailman/listinfo/last-call > From nobody Sat Jul 31 07:18:37 2021 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0F73A27B7; Sat, 31 Jul 2021 07:18:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.35.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sfc@ietf.org Message-ID: <162774111532.12056.3937588159475955228@ietfa.amsl.com> Date: Sat, 31 Jul 2021 07:18:35 -0700 Archived-At: Subject: [sfc] I-D Action: draft-ietf-sfc-ioam-nsh-06.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2021 14:18:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining WG of the IETF. Title : Network Service Header (NSH) Encapsulation for In-situ OAM (IOAM) Data Authors : Frank Brockners Shwetha Bhandari Filename : draft-ietf-sfc-ioam-nsh-06.txt Pages : 9 Date : 2021-07-31 Abstract: In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document outlines how IOAM data fields are encapsulated in the Network Service Header (NSH). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-ioam-nsh-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/