From nobody Tue Sep 4 00:53:13 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C90130DEF for ; Tue, 4 Sep 2018 00:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.33 X-Spam-Level: X-Spam-Status: No, score=-3.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 C-JgEuAGE211 for ; Tue, 4 Sep 2018 00:52:59 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (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 4B861128B14 for ; Tue, 4 Sep 2018 00:52:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1536047578; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=FKCNv2jT3Q0N908+vknsCtGBEau0rLH3Ve/izA8owZQ=; b=ZlaNKoaw2/0+/om1DxhJm6nMVMvjWvTVUOIEZeLU9+2iKYSlczi/FHvHdkuQZoiV 6GLbms+yiIVbj6CuMCbg3vm8bYR9cVlBvXosvULzwM3TszAmS1gom4W8OhRvf0eb 10nHNQjdADgzziZdJaYjz48AT/Gq3LBbkr7R1XpeLyg=; X-AuditID: c6180641-49dff70000002b50-a5-5b8e39da548a Received: from EUSASMB502.ericsson.se (Unknown_Domain [147.117.188.220]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 54.16.11088.AD93E8B5; Tue, 4 Sep 2018 09:52:58 +0200 (CEST) Received: from ESESSMB504.ericsson.se (153.88.183.122) by EUSASMB502.ericsson.se (147.117.188.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 4 Sep 2018 03:52:56 -0400 Received: from ESESSMB504.ericsson.se ([153.88.183.192]) by ESESSMB504.ericsson.se ([153.88.183.192]) with mapi id 15.01.1466.003; Tue, 4 Sep 2018 09:52:55 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Daniel Migault , "secdir@ietf.org" CC: "draft-ietf-core-object-security.all@ietf.org" , "ietf@ietf.org" , "core@ietf.org" Thread-Topic: [secdir] Secdir last call review of draft-ietf-core-object-security-14 Thread-Index: AQHURCRKq+z0Y7hnFkaX71ieBzLbRw== Date: Tue, 4 Sep 2018 07:52:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [153.88.183.157] Content-Type: multipart/alternative; boundary="_000_D7B3CF16AD334goranselanderericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyuXTPHd1bln3RBieeKFrse7ue2eJbzzxW i2cb57NYfFj4kMWBxWPJkp9MAYxRXDYpqTmZZalF+nYJXBkzpz5jLHh7kqVi/8OTzA2MV3ax dDFyckgImEis/PaLuYuRi0NI4BijxJQ5txghnG+MEktn72CDcJYySjz+uJsZpIVNwEXiQcMj JhBbRCBc4tGOs2AdzALLGSVONH4HSnBwCAuESvy94gFREyZxc+M6NghbT6Lj8hR2EJtFQEXi 8ZU5bCDlvAIWEqt3iYKEGQXEJL6fWgM2nllAXOLWk/lMEJcKSCzZc54ZwhaVePn4HyuILQo0 cm9POxtEXEliS+8WsAuYBWIlmmdpgYR5BQQlTs58wjKBUWQWkqmzEKpmIamCCGtKrN+lD1Gt KDGl+yE7hK0h0TpnLpRtLXH8/2tGZDULGDlWMXKUFhfk5KYbGW5iBMbXMQk2xx2Me3s9DzEK cDAq8fDaGfdFC7EmlhVX5h5ilOBgVhLh9eMHCvGmJFZWpRblxxeV5qQWH2KU5mBREuc958kb JSSQnliSmp2aWpBaBJNl4uCUamD0sLSZ3eIqoblh86vvyUn7fq9+/lSnaeKqFf17b8/7dkd3 ha330yL3Qh+Br1LSF09l/HHYHrdHYs+mY7uPn/2euSvVrqb1XMjUdYZGnteWdWzc8M1dr995 x8NEfoH6kA83XIvCJ5b6y+Q4i1rZLBTyvLhzxxcFxjb3wGvr+k6rsJ2MLNlTLM+vxFKckWio xVxUnAgAzBsTuKsCAAA= Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-core-object-security-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 07:53:04 -0000 --_000_D7B3CF16AD334goranselanderericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGFuaWVsLA0KDQpUaGFua3MgZm9yIHlvdXIgcmVzcG9uc2VzLiBEZXRhaWxlZCBjb21tZW50 cyBpbmxpbmUuDQoNCldpdGggdGhhdCBJIGJlbGlldmUgYWxsIG91dHN0YW5kaW5nIGNvbW1lbnRz IGFyZSByZXNvbHZlZCBpbiB2ZXJzaW9uIC0xNS4gTGV0IHVzIGtub3cgaWYgdGhlcmUgYXJlIGFu eSBmdXJ0aGVyIGNvbW1lbnRzLg0KDQpCZXN0IHJlZ2FyZHMNCkfDtnJhbg0KDQoNCkZyb206IERh bmllbCBNaWdhdWx0IDxkYW5pZWwubWlnYXVsdEBlcmljc3Nvbi5jb208bWFpbHRvOmRhbmllbC5t aWdhdWx0QGVyaWNzc29uLmNvbT4+DQpEYXRlOiBGcmlkYXksIDMxIEF1Z3VzdCAyMDE4IGF0IDIw OjI0DQpUbzogInNlY2RpckBpZXRmLm9yZzxtYWlsdG86c2VjZGlyQGlldGYub3JnPiIgPHNlY2Rp ckBpZXRmLm9yZzxtYWlsdG86c2VjZGlyQGlldGYub3JnPj4sIEfDtnJhbiBTZWxhbmRlciA8Z29y YW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tPG1haWx0bzpnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5j b20+Pg0KQ2M6ICJkcmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5LmFsbEBpZXRmLm9yZzxt YWlsdG86ZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eS5hbGxAaWV0Zi5vcmc+IiA8ZHJh ZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eS5hbGxAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWll dGYtY29yZS1vYmplY3Qtc2VjdXJpdHkuYWxsQGlldGYub3JnPj4sICJpZXRmQGlldGYub3JnPG1h aWx0bzppZXRmQGlldGYub3JnPiIgPGlldGZAaWV0Zi5vcmc8bWFpbHRvOmlldGZAaWV0Zi5vcmc+ PiwgImNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+IiA8Y29yZUBpZXRmLm9yZzxt YWlsdG86Y29yZUBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3NlY2Rpcl0gU2VjZGlyIGxhc3Qg Y2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eS0xNA0KDQoNCkhp IEdvcmFuLA0KDQoNCg0KVGhhbmsgeW91IGZvciB5b3VyIGZlZWQgYmFja3MuIEkgYmVsaWV2ZSBh bGwgbXkgY29uY2VybnMgaGF2ZSBiZWVuIGFkZHJlc3NlZC4gWW91IGNhbiBzZWUgaW5saW5lIHRo ZSBzcGVjaWZpYyByZXNwb25zZS4gPG1nbHQyPjwvbWdsdDI+DQoNCg0KDQotIC0gLQ0KDQoNCj4+ DQoNCj4+ICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSBPYmplY3QgU2VjdXJpdHkgZm9yIENv bnN0cmFpbmVkIFJFU1RmdWwNCg0KPj4gICBFbnZpcm9ubWVudHMgKE9TQ09SRSkgc2VjdXJpdHkg cHJvdG9jb2wsIHByb3RlY3RpbmcgQ29BUCBhbmQgQ29BUC0NCg0KPj4gICBtYXBwYWJsZSBIVFRQ IHJlcXVlc3RzIGFuZCByZXNwb25zZXMgZW5kLXRvLWVuZCBhY3Jvc3MgaW50ZXJtZWRpYXJ5DQoN Cj4+ICAgbm9kZXMgc3VjaCBhcyBDb0FQIGZvcndhcmQgcHJveGllcyBhbmQgY3Jvc3MtcHJvdG9j b2wgdHJhbnNsYXRvcnMNCg0KPj4gICBpbmN1ZGluZyBIVFRQLXRvLUNvQVAgcHJveGllcyBbUkZD ODA3NV0uICBJbiBhZGRpdGlvbiB0byB0aGUgY29yZQ0KDQo+PiAgIENvQVAgZmVhdHVyZXMgZGVm aW5lZCBpbiBbUkZDNzI1Ml0sIE9TQ09SRSBzdXBwb3J0cyBPYnNlcnZlDQoNCj4+ICAgW1JGQzc2 NDFdLCBCbG9jay13aXNlIFtSRkM3OTU5XSwgTm8tUmVzcG9uc2UgW1JGQzc5NjddLCBhbmQgUEFU Q0ggYW5kDQoNCj4+ICAgRkVUQ0ggW1JGQzgxMzJdLg0KDQo+PjxtZ2x0Pg0KDQo+Pk1heWJlIHRv byBtYW55ICJhbmQiLg0KDQo+PjwvbWdsdD4NCg0KPg0KDQo+W0dTOl0gSSBzZWUgd2hhdCB5b3Ug bWVhbi4gVGhlIHRpdGxlIG9mIFJGQyA4MTMyIGlzICJQQVRDSCBhbmQgRkVUQ0gNCg0KPm1ldGhv ZHMgZm9yIENvQVDigJ0uIFBlcmhhcHMgd2UganVzdCBjaGFuZ2UgdGhlIG9yZGVyIG9mIHRoZSBl eGFtcGxlcyBpbiB0aGUNCg0KPmxhc3Qgc2VudGVuY2U6DQoNCiBORVcNCg0KPiJJbiBhZGRpdGlv biB0byB0aGUgY29yZSBDb0FQIGZlYXR1cmVzIGRlZmluZWQgaW4NCg0KPltSRkM3MjUyXSwgT1ND T1JFIHN1cHBvcnRzIE9ic2VydmUgW1JGQzc2NDFdLCBCbG9jay13aXNlIFtSRkM3OTU5XSwgUEFU Q0gNCg0KPmFuZCBGRVRDSCBbUkZDODEzMl0sIGFuZCBOby1SZXNwb25zZSBbUkZDNzk2N10u4oCd Pw0KDQo+DQoNCj4NCg0KPG1nbHQyPg0KDQpJIGFtIGZpbmUgZWl0aGVyIHdheXMuIEkgdGhpbmsg dGhlIHByb2JsZW0gaXMgdGhhdCB3ZSBhIGhhdmUgYSBsaXN0IG9mIGRpZmZlcmVudCBuYXR1cmUs IHVubGVzcyB3ZSBhcmUgY29uc2lkZXJpbmcgdGhlIGRvY3VtZW50cyB0aGVtc2VsdmVzLiBJIHdv dWxkIHByb3Bvc2U6DQoNCk9TQ09SRSBzdXBwb3J0cyB0aGUgQmxvY2tXaXNlIFRyYW5zZmVydCBT aWduYWxpbmcgIE9wdGlvbiBbUkZDNzk1OV0sIHRoZSBPYnNlcnZlZCBbUkZDNzY0MV0gYW5kIE5v LVJlc3BvbnNlIE9wdGlvbiwgW1JGQzc5NjddLCBhcyB3ZWxsIGFzIHRoZSBQQVRDSCBhbmQgRkVU Q0ggTWV0aG9kcyBbUkZDODEzMl0uDQoNCjwvbWdsdDI+DQoNCkdTOiBSZXBocmFzZWQgaW4g4oCT MTUuDQoNCg0KLSAtIC0NCg0KDQoNCj4+DQoNCj4+SSBiZWxpZXZlIHRoYXQgU2VuZGVyIFNlcXVl bmNlIE51bWJlciBhbHNvIG5lZWRzIHRvIGJlIHByZXNlbnQgaW4gdGhlDQoNCj4+UmVjaXBpZW50 DQoNCj4+Q29udGV4dCBpbiBvcmRlciB0byBpbXBsZW1lbnQgYW50aSByZXBsYXkgbWVjaGFuaXNt Lg0KDQo+DQoNCj5bR1M6XSBUaGUgcmVwbGF5IHdpbmRvdyBpcyBhbHJlYWR5IHBhcnQgb2YgdGhl IFJlY2lwaWVudCBDb250ZXh0LiBQZXJoYXBzDQoNCj5hIHJlZmVyZW5jZSB0byBTZWN0aW9uIDcu NCB3b3VsZCBiZSBzdWZmaWNpZW50IHRvIG1ha2UgdGhlIGNvbm5lY3Rpb24NCg0KPmJldHdlZW4g cmVwbGF5IHdpbmRvdyBhbmQgc2VxdWVuY2UgbnVtYmVyPw0KDQo+DQoNCjxtZ2x0Mj4NCg0KR29v ZCwgdGhlbiB5ZXMgYSByZWZlcmVuY2Ugd291bGQgYmUgdXNlZnVsbA0KDQo8L21nbHQyPg0KDQpH UzogSW5jbHVkZWQgaW4g4oCTMTUuDQoNCi0gLSAtDQoNCg0KPj4NCg0KPj5TZXF1ZW5jZSBOdW1i ZXIgTWF5IGJlIGludGVycHJldGVkIGRpZmZlcmVudGx5LiBJIGJlbGlldmUgdGhhdA0KDQo+Pmlu dGVycHJldGF0aW9uDQoNCj4+c2hvdWxkIGFsc28gYmUgcGFydCBvZiB0aGUgQ29tbW9uIFNlY3Vy aXR5IENvbnRleHQuDQoNCj4NCg0KPltHUzpdIEkgZGlkbuKAmXQgdW5kZXJzdGFuZCB0aGlzIGNv bW1lbnQuDQoNCg0KDQo8bWdsdDI+DQoNClNlcXVlbmNlIE51bWJlciBhcmUgbm90IGFsd2F5cyBp bmNyZW1lbnRlZC4gVGhpcyBpbnRlcnByZXRhdGlvbiBtYXkgaW1wYWN0IHRoZSBzZXNzaW9uLCBz byB0aGF0IG1heSBuZWVkIHRvIGJlIHNwZWNpZnkgaW4gdGhlIGZ1dHVyZSB3aGVuIGNvbnNpZGVy aW5nIG90aGVyIGludGVycHJldGF0aW9uIG9mIHRoZSBTU04uDQoNCjwvbWdsdDI+DQoNCkdTOiBU aGlzIHNwZWNpZmljYXRpb24gYXNzdW1lcyB0aGF0IFNTTiBpcyBpbmNyZW1lbnRlZCBhcyBzaG91 bGQgYmUgY2xlYXIgZnJvbSB0aGUgcHJvY2Vzc2luZyAoc2VjdGlvbiA4KS4gSW4g4oCTMTUgd2Ug YWRkZWQgYSByZWZlcmVuY2UgdG8gSS1ELm1jZ3Jldy1pdi1nZW48aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHktMTUjcmVmLUktRC5tY2dy ZXctaXYtZ2VuPi4NCg0KLSAtIC0NCg0KDQo+Pg0KDQo+PiAgIFRoZSBmb2xsb3dpbmcgaW5wdXQg cGFyYW1ldGVycyBNQVkgYmUgcHJlLWVzdGFibGlzaGVkLiAgSW4gY2FzZSBhbnkNCg0KPj4gICBv ZiB0aGVzZSBwYXJhbWV0ZXJzIGlzIG5vdCBwcmUtZXN0YWJsaXNoZWQsIHRoZSBkZWZhdWx0IHZh bHVlDQoNCj4+ICAgaW5kaWNhdGVkIGJlbG93IGlzIHVzZWQ6DQoNCj4+DQoNCj4+ICAgbyAgQUVB RCBBbGdvcml0aG0NCg0KPj4NCg0KPj4gICAgICAqICBEZWZhdWx0IGlzIEFFUy1DQ00tMTYtNjQt MTI4IChDT1NFIGFsZ29yaXRobSBlbmNvZGluZzogMTApDQoNCj4+DQoNCj4+ICAgbyAgTWFzdGVy IFNhbHQNCg0KPj4NCg0KPj4gICAgICAqICBEZWZhdWx0IGlzIHRoZSBlbXB0eSBieXRlIHN0cmlu Zw0KDQo+PjxtZ2x0Pg0KDQo+PkkgYmVsaWV2ZSBleHBsaWNpdGx5IHByb3ZpZGluZyB0aGUgc3Ry aW5nIGNvdWxkIGhlbHAuIFRoZXJlIGlzIGFsd2F5cyB0aGUNCg0KPj5jb25mdXNpb24gd2l0aCAi XDAiIHZlcnN1cyAiIi4gPC9tZ2x0Pg0KDQo+DQoNCj5bR1M6XSBOb3RlIHRoYXQgdGhlIE1hc3Rl ciBTYWx0IGlzIG5ldmVyIHNlbnQgYW5kIG9ubHkgdXNlZCBhcyBzYWx0IGluDQoNCj5IS0RGIChz ZWN0aW9uIDIuMiBvZiBSRkMgNTg2OSkuIFNlY3Rpb24gMy4yLjEgZGVzY3JpYmVzIGhvdyB0aGUg ZW1wdHkNCg0KPnN0cmluZyBzaG91bGQgYmUgaW50ZXJwcmV0ZWQ6DQoNCj4iTm90ZSB0aGF0IFtS RkM1ODY5XSBzcGVjaWZpZXMgdGhhdCBpZiB0aGUgc2FsdCBpcyBub3QgcHJvdmlkZWQsIGl0IGlz IHNldA0KDQo+dG8gYSBzdHJpbmcgb2YNCg0KPnplcm9zLiBGb3IgaW1wbGVtZW50YXRpb24gcHVy cG9zZXMsIG5vdCBwcm92aWRpbmcgdGhlIHNhbHQgaXMgdGhlIHNhbWUNCg0KPmFzIHNldHRpbmcg dGhlIHNhbHQgdG8gdGhlIGVtcHR5IGJ5dGUgc3RyaW5nLiBPU0NPUkUgc2V0cyB0aGUgc2FsdA0K DQo+ZGVmYXVsdCB2YWx1ZSB0byBlbXB0eSBieXRlIHN0cmluZywgd2hpY2ggaW4gW1JGQzU4Njld IGlzIGNvbnZlcnRlZCB0byBhDQoNCj5zdHJpbmcgb2YgemVyb2VzIChzZWUgU2VjdGlvbiAyLjIg b2YgW1JGQzU4NjldKS4iDQoNCj5JcyB0aGF0IHN1ZmZpY2llbnRseSBjbGVhcj8NCg0KPg0KDQo+ DQoNCjxtZ2x0Mj4NCg0KVGhpcyBpcyBmaW5lLiBJdCBzZWVtcyB0byBtZSB0aGF0IGVtcHR5IHN0 cmluZyBpcyDigJzigJ0gaGVyZS4gSSB1c3VhbGx5IGxpa2UgdG8gY2l0ZSBleHBsaWNpdGx5IHRo ZSBzdHJpbmcgdG8gYXZvaWQgY29uZnVzaW9uIGJldHdlZW4g4oCc4oCdIG9yIOKAnFww4oCdLiBJ IGFncmVlIHRoYXQgc2F5aW5nIHplcm8gbGVuZ3RoIGRvZXMgbm90IGhlbHAgbXVjaA0KDQpUaGUg bGF0ZXN0IHNlbnRlbmNlIGhhcyB0d28gcmVmZXJlbmNlIHRvIFJGQzU4NjksIG1heWJlIG9uZSB3 b3VsZCBiZSBzdWZmaWNpZW50LiBJZiBwb3NzaWJsZSwgaXQgbWlnaHQgYmUgYmV0dGVyIHRvIHNw ZWNpZnkgdGhlIGxlbmd0aCBvZiB0aGUgc3RyaW5ncyBvZiB6ZXJvcyAoSGFzaExlbiBpbiBvdXIg Y2FzZSkNCg0KPC9tZ2x0Mj4NCg0KR1M6IE9uZSBvZiB0aGUgcmVmZXJlbmNlcyB0byBSRkM1ODY5 IHJlbW92ZWQgaW4g4oCTMTUuIFRoZSBwcm9jZWR1cmUgZm9yIGhhbmRsaW5nIHRoZSBjYXNlIG9m IG5vIHNhbHQgcHJvdmlkZWQgaXMgY2xlYXJseSBzcGVjaWZpZWQgaW4gc2VjdGlvbiAyLjIgb2Yg UkZDNTg2OSwgd2hpY2ggd2UgcmVmZXJlbmNlLiBJIHdvdWxkIHJhdGhlciBub3QgaW5jbHVkZSB0 aGUgZGV0YWlscyBpbiB0aGlzIHNwZWNpZmljYXRpb24uDQoNCi0gLSAtDQoNCg0KPg0KDQo+DQoN Cj4gd2hpY2ggZGVmaW5lcyBob3cgdG8NCg0KPg0KDQo+Pg0KDQo+PiAgIG8gIEtleSBEZXJpdmF0 aW9uIEZ1bmN0aW9uIChLREYpDQoNCj4+DQoNCj4+ICAgICAgKiAgRGVmYXVsdCBpcyBIS0RGIFNI QS0yNTYNCg0KPj4NCg0KPj4gICBvICBSZXBsYXkgV2luZG93IFR5cGUgYW5kIFNpemUNCg0KPj4N Cg0KPj4gICAgICAqICBEZWZhdWx0IGlzIERUTFMtdHlwZSByZXBsYXkgcHJvdGVjdGlvbiB3aXRo IGEgd2luZG93IHNpemUgb2YgMzINCg0KPj4gICAgICAgICBbUkZDNjM0N10NCg0KPj48bWdsdD4N Cg0KPj5UaGlzIHNlY3Rpb24gc3BlY2lmaWVzIFR5cGUgYW5kIHdpbmRvd3MgZm9yIHRoZSBhbnRp IHJlcGxheSBtZWNoYW5pc20uDQoNCj4+VGhpcyB3YXMNCg0KPj5kZXNjcmliZWQgYXMgUmVwbGF5 IFdpbmRvd3MgaW4gdGhlIGNvbnRleHQgZGVzY3JpcHRpb24uIDwvbWdsdD4NCg0KPg0KDQo+W0dT Ol0gSSBkaWRu4oCZdCB1bmRlcnN0YW5kIHRoaXMgY29tbWVudC4gRG8geW91IG1lYW46DQoNCj5P TEQNCg0KPlJlcGxheSBXaW5kb3cgVHlwZSBhbmQgU2l6ZQ0KDQo+TkVXDQoNCj5SZXBsYXkgV2lu ZG93DQoNCj4NCg0KPg0KDQo8bWdsdDI+DQoNCklmIGRpZmZlcmVudCBtZWNoYW5pc20gY291bGQg YmUgdXNlZCwgSSBtZWFudDoNCg0KKiBSZXBsYXkgV2luZG93IFR5cGUgOiBkZWZhdWx0IHRvIERU TFMgMS4yDQoNCiogUmVwbGF5IFdpbmRvdyBTaXplIChQYXJhbWV0ZXJzKToNCg0KPC9tZ2x0Pg0K DQoNCkdTOiBUaGUgZGVmYXVsdCB2YWx1ZXMgbGlzdGVkIGluIHNlY3Rpb24gMy4yIHdlcmUgaW50 ZW5kZWQgdG8gcmVwZWF0IHRoZSBwYXJhbWV0ZXJzIGxpc3RlZCBpbiBzZWN0aW9uIDMuMS4gSSBy ZWFsaXNlZCBmcm9tIHlvdXIgY29tbWVudCB0aGF0ICB0aGF0ICJSZXBsYXkgV2luZG93IiBkZXZp YXRlZCBmcm9tIHRoaXMgY29udmVudGlvbi4gV2UgcmVzb2x2ZWQgdGhhdCBpbiDigJMxNSBieSBj aGFuZ2luZyB0aGUgdGVybSBpbiBzZWN0aW9uIDMuMi4gWW91ciBwcm9wb3NhbCB3b3VsZCBhbHNv IHJlcXVpcmUgYSBjaGFuZ2UgdG8gc2VjdGlvbiAzLjEuIE5vdGUgdGhhdCB3ZSBkbyBub3QgcmVz dHJpY3QgdG8gRFRMUyB0eXBlIHJlcGxheSBwcm90ZWN0aW9uLCBzbyB3ZSB3b3VsZCByYXRoZXIg bm90IGl0ZW1pc2UgdGhlIHN1Yi1wYXJhbWV0ZXJzIG9mIHRoZSByZXBsYXkgcHJvdGVjdGlvbiBt ZWNoYW5pc20uDQoNCi0gLSAtDQoNCg0KPg0KDQo+W0dTOl0gTm8sIHRoZSByZXN0cmljdGlvbiBj b21lcyBmcm9tIHRoZSBub25jZSBjb25zdHJ1Y3Rpb24sIEkgd2lsbCBhZGQgYQ0KDQo+cmVmZXJl bmNlIHRvIFNlY3Rpb24gNS4yLg0KDQo8bWdsdDI+DQoNClRoYW5rcywgSSBiZWxpZXZlIHRoYXQg d291bGQgYmUgdXNlZnVsLg0KDQo8L21nbHQyPg0KDQpHUzogRG9uZSBpbiAtMTUNCg0KLSAtIC0N Cg0KDQo+DQoNCj4+NC4xLjMuNS4yLiAgTm90aWZpY2F0aW9ucw0KDQo+Pg0KDQo+PiAgIElmIHRo ZSBzZXJ2ZXIgYWNjZXB0cyBhbiBPYnNlcnZlIHJlZ2lzdHJhdGlvbiwgYSBQYXJ0aWFsIElWIE1V U1QgYmUNCg0KPj4gICBpbmNsdWRlZCBpbiBhbGwgbm90aWZpY2F0aW9ucyAoYm90aCBzdWNjZXNz ZnVsIGFuZCBlcnJvciksIGV4Y2VwdCBmb3INCg0KPj4gICB0aGUgZmlyc3Qgb25lIHdoZXJlIFBh cnRpYWwgSVYgTUFZIGJlIG9taXR0ZWQuICBUbyBwcm90ZWN0IGFnYWluc3QNCg0KPj4gICByZXBs YXksIHRoZSBjbGllbnQgU0hBTEwgbWFpbnRhaW4gYSBOb3RpZmljYXRpb24gTnVtYmVyIGZvciBl YWNoDQoNCj4+ICAgT2JzZXJ2YXRpb24gaXQgcmVnaXN0ZXJzLiAgVGhlIE5vdGlmaWNhdGlvbiBO dW1iZXIgaXMgYSBub24tbmVnYXRpdmUNCg0KPj4gICBpbnRlZ2VyIGNvbnRhaW5pbmcgdGhlIGxh cmdlc3QgUGFydGlhbCBJViBvZiB0aGUgcmVjZWl2ZWQNCg0KPj4gICBub3RpZmljYXRpb25zIGZv ciB0aGUgYXNzb2NpYXRlZCBPYnNlcnZlIHJlZ2lzdHJhdGlvbi4gIEZ1cnRoZXINCg0KPj4gICBk ZXRhaWxzIG9mIHJlcGxheSBwcm90ZWN0aW9uIG9mIG5vdGlmaWNhdGlvbnMgYXJlIHNwZWNpZmll ZCBpbg0KDQo+PiAgIFNlY3Rpb24gNy40LjEuDQoNCj4+DQoNCj4+ICAgRm9yIG5vdGlmaWNhdGlv bnMsIHRoZSBJbm5lciBPYnNlcnZlIHZhbHVlIE1VU1QgYmUgZW1wdHkgKHNlZQ0KDQo+PiAgIFNl Y3Rpb24gMy4yIG9mIFtSRkM3MjUyXSkuICBUaGUgT3V0ZXIgT2JzZXJ2ZSBpbiBhIG5vdGlmaWNh dGlvbiBpcw0KDQo+Pg0KDQo+PlNlbGFuZGVyLCBldCBhbC4gICAgICAgIEV4cGlyZXMgSmFudWFy eSAyNywgMjAxOSAgICAgICAgICAgICAgIFtQYWdlIDIwXQ0KDQo+Pg0KDQo+PkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICAgICAgIE9TQ09SRSAgICAgICAgICAgICAgICAgICAgICAgIEp1bHkg MjAxOA0KDQo+Pg0KDQo+PiAgIG5lZWRlZCBmb3IgaW50ZXJtZWRpYXJ5IG5vZGVzIHRvIGFsbG93 IG11bHRpcGxlIHJlc3BvbnNlcyB0byBvbmUNCg0KPj4gICByZXF1ZXN0LCBhbmQgbWF5IGJlIHNl dCB0byB0aGUgdmFsdWUgb2YgT2JzZXJ2ZSBpbiB0aGUgb3JpZ2luYWwgQ29BUA0KDQo+PiAgIG1l c3NhZ2UuICBUaGUgY2xpZW50IHBlcmZvcm1zIG9yZGVyaW5nIG9mIG5vdGlmaWNhdGlvbnMgYW5k IHJlcGxheQ0KDQo+PiAgIHByb3RlY3Rpb24gYnkgY29tcGFyaW5nIHRoZWlyIFBhcnRpYWwgSVZz IGFuZCBTSEFMTCBpZ25vcmUgdGhlIG91dGVyDQoNCj4+ICAgT2JzZXJ2ZSB2YWx1ZS4NCg0KPj4N Cg0KPj4gICBJZiB0aGUgY2xpZW50IHJlY2VpdmVzIGEgcmVzcG9uc2UgdG8gYW4gT2JzZXJ2ZSBy ZXF1ZXN0IHdpdGhvdXQgYW4NCg0KPj4gICBJbm5lciBPYnNlcnZlIG9wdGlvbiwgdGhlbiBpdCB2 ZXJpZmllcyB0aGUgcmVzcG9uc2UgYXMgYSBub24tT2JzZXJ2ZQ0KDQo+PiAgIHJlc3BvbnNlLCBh cyBzcGVjaWZpZWQgaW4gU2VjdGlvbiA4LjQuICBJZiB0aGUgY2xpZW50IHJlY2VpdmVzIGENCg0K Pj4gICByZXNwb25zZSB0byBhIG5vbi1PYnNlcnZlIHJlcXVlc3Qgd2l0aCBhbiBJbm5lciBPYnNl cnZlIG9wdGlvbiwgdGhlbg0KDQo+PiAgIGl0IHN0b3BzIHByb2Nlc3NpbmcgdGhlIG1lc3NhZ2Us IGFzIHNwZWNpZmllZCBpbiBTZWN0aW9uIDguNC4NCg0KPj4NCg0KPj4gICBBIGNsaWVudCBNVVNU IGNvbnNpZGVyIHRoZSBub3RpZmljYXRpb24gd2l0aCB0aGUgaGlnaGVzdCBQYXJ0aWFsIElWDQoN Cj4+ICAgYXMgdGhlIGZyZXNoZXN0LCByZWdhcmRsZXNzIG9mIHRoZSBvcmRlciBvZiBhcnJpdmFs LiAgSW4gb3JkZXIgdG8NCg0KPj4gICBzdXBwb3J0IGV4aXN0aW5nIE9ic2VydmUgaW1wbGVtZW50 YXRpb25zIHRoZSBPU0NPUkUgY2xpZW50DQoNCj4+ICAgaW1wbGVtZW50YXRpb24gTUFZIHNldCB0 aGUgT2JzZXJ2ZSB2YWx1ZSB0byB0aGUgdGhyZWUgbGVhc3QNCg0KPj4gICBzaWduaWZpY2FudCBi eXRlcyBvZiB0aGUgUGFydGlhbCBJVjsgc3VjaCBhbiBpbXBsZW1lbnRhdGlvbiBuZWVkcyB0bw0K DQo+PiAgIG1ha2Ugc3VyZSB0aGF0IHRoZSBPYnNlcnZlIHZhbHVlIGZvciBhbiBvYnNlcnZlIG5v dGlmaWNhdGlvbiB3aXRob3V0DQoNCj4+ICAgUGFydGlhbCBJViBpcyBzbWFsbGVyIHRoYW4gYSBu b3RpZmljYXRpb24gd2l0aCBQYXJ0aWFsIElWLg0KDQo+Pg0KDQo+PjxtZ2x0Pg0KDQo+PlRoaXMg c2VjdGlvbiBkaXNjdXNzIHRoZSBiZWhhdmlvciByZWdhcmRpbmcgdGhlIHNlcXVlbmNlIG51bWJl ci4gV2hpbGUNCg0KPj50aGUNCg0KPj5zZXF1ZW5jZSBudW1iZXIgYW5kIHRoZSBwYXJ0aWFsIElW IGhhdmUgdGhlIHNhbWUgdmFsdWUsIEkgYW0gd29uZGVyaW5nDQoNCj4+aWYNCg0KPj5pdA0KDQo+ PndvdWxkIG5vdCBiZSBtb3JlIGFwcHJvcHJpYXRlZCB0byBtZW50aW9uIHRoZSBzZXF1ZW5jZSBu dW1iZXIgdmFsdWUgaXMNCg0KPj5wcm92aWRlZA0KDQo+PmJ5IHRoZSBwYXJ0aWFsIElWLCBhbmQg dGhlbiB1c2UgdGhlIHNlcXVlbmNlIG51bWJlciB2YXJpYWJsZSB0byBkZXNjcmliZQ0KDQo+PmFu dGkNCg0KPj5yZXBsYXkuIDwvbWdsdD4NCg0KPg0KDQo+DQoNCj5bR1M6XSBXZSBpbnRlbmRlZCB0 byB1c2UgdGhlIHRlcm0g4oCccGFydGlhbCBJVuKAnSB3aGVuIHJlZmVycmluZyB0byB0aGUNCg0K Pm51bWJlciBiZWluZyB0cmFuc3BvcnRlZCBhbmQg4oCcU1NOIiB3aGVuIHJlZmVycmluZyB0byB0 aGUgbnVtYmVyIHN0b3JlZCBpbg0KDQo+dGhlIGVuZHBvaW50LiBJIHdpbGwgZ28gdGhyb3VnaCB0 aGUgZG9jdW1lbnQgYW5kIHNlZSB0aGF0IHRoaXMgY29udmVudGlvbg0KDQo+aXMga2VwdC4NCg0K Pj4NCg0KPG1nbHQyPg0KDQpNYXliZSB0aGF0IHdvdWxkIGJlIHVzZWZ1bCB0byBtZW50aW9uIHRo aXMgY29udmVudGlvbg0KDQo8L21nbHQyPg0KDQoNCg0KR1M6IEnigJltIG5vdCBzdXJlIGdvaW5n IGludG8gdGhpcyBkaXN0aW5jdGlvbiBpcyBuZWNlc3NhcnkuIFdlIGFscmVhZHkgZGVzY3JpYmUg dGhlIHJlbGF0aW9uc2hpcCBpbiBzZXZlcmFsIHBsYWNlczoNCg0KU2VjdGlvbiAzLjE6DQoNCiJT ZW5kZXIgU2VxdWVuY2UgTnVtYmVyLiAgTm9uLW5lZ2F0aXZlIGludGVnZXIgdXNlZCBieSB0aGUg c2VuZGVyDQogICAgICB0byBlbnVtZXJhdGUgcmVxdWVzdHMgYW5kIGNlcnRhaW4gcmVzcG9uc2Vz LCBlLmcuICBPYnNlcnZlDQogICAgICBub3RpZmljYXRpb25zLiAgVXNlZCBhcyAnUGFydGlhbCBJ VicgW1JGQzgxNTI8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzgxNTI+XSB0byBnZW5l cmF0ZSB1bmlxdWUNCiAgICAgIEFFQUQgbm9uY2VzLiINCg0KU2VjdGlvbiA1Og0KDQoiIFRoZSAn UGFydGlhbCBJVicgcGFyYW1ldGVyLiAgVGhlIHZhbHVlIGlzIHNldCB0byB0aGUgU2VuZGVyIFNl cXVlbmNlIE51bWJlci4iDQoNClNlY3Rpb24gNy4yOg0KDQoiUGFydGlhbCBJVnMgKHdoaWNoIGVu Y29kZSB0aGUgU2VuZGVyIFNlcXVlbmNlIE51bWJlcnMsIHNlZSBTZWN0aW9uIDU8aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHktMTUjc2Vj dGlvbi01PikiDQoNCg0KU2VjdGlvbiA3LjQgKGFkZHJlc3NpbmcgYW5vdGhlciBjb21tZW50IG9m IHlvdXJzKToNCg0KIlBhcnRpYWwgSVYgPSBTZW5kZXIgU2VxdWVuY2UgTnVtYmVyIg0KDQphbmQg YWxzbyBzZXZlcmFsIHRpbWVzIGluIHRoZSBwcm9jZXNzaW5nLCBTZWN0aW9uIDguDQoNCg0KLSAt IC0NCg0KDQoNCj5ELjQuMS4gIENvQVAgSGVhZGVyIEZpZWxkcw0KDQo+DQoNCj4gICBvICBWZXJz aW9uLiAgVGhlIENvQVAgdmVyc2lvbiBbUkZDNzI1Ml0gaXMgbm90IGV4cGVjdGVkIHRvIGJlDQoN Cj4gICAgICBzZW5zaXRpdmUgdG8gZGlzY2xvc2UuICBDdXJyZW50bHkgdGhlcmUgaXMgb25seSBv bmUgQ29BUCB2ZXJzaW9uDQoNCj4gICAgICBkZWZpbmVkLiAgQSBjaGFuZ2Ugb2YgdGhpcyBwYXJh bWV0ZXIgaXMgcG90ZW50aWFsbHkgYSBkZW5pYWwtb2YtDQoNCj4gICAgICBzZXJ2aWNlIGF0dGFj ay4gIEZ1dHVyZSB2ZXJzaW9ucyBvZiBDb0FQIG5lZWQgdG8gYW5hbHl6ZSBhdHRhY2tzDQoNCj4g ICAgICB0byBPU0NPUkUgcHJvdGVjdGVkIG1lc3NhZ2VzIGR1ZSB0byBhbiBhZHZlcnNhcnkgY2hh bmdpbmcgdGhlIENvQVANCg0KPiAgICAgIHZlcnNpb24uDQoNCj4NCg0KPiAgIG8gIFRva2VuL1Rv a2VuIExlbmd0aC4gIFRoZSBUb2tlbiBmaWVsZCBpcyBhIGNsaWVudC1sb2NhbCBpZGVudGlmaWVy DQoNCj4gICAgICBmb3IgZGlmZmVyZW50aWF0aW5nIGJldHdlZW4gY29uY3VycmVudCByZXF1ZXN0 cyBbUkZDNzI1Ml0uICBBbg0KDQo+ICAgICAgZWF2ZXNkcm9wcGVyIHJlYWRpbmcgdGhlIHRva2Vu IGNhbiBtYXRjaCByZXF1ZXN0cyB0byByZXNwb25zZXMNCg0KPiAgICAgIHdoaWNoIGNhbiBiZSB1 c2VkIGluIHRyYWZmaWMgYW5hbHlzaXMuICBJbiBwYXJ0aWN1bGFyIHRoaXMgaXMgdHJ1ZQ0KDQo+ ICAgICAgZm9yIG5vdGlmaWNhdGlvbnMsIHdoZXJlIG11bHRpcGxlIHJlc3BvbnNlcyBhcmUgbWF0 Y2hlZCB3aXRoIG9uZQ0KDQo+ICAgICAgcmVxdWVzdC4gIENvQVAgcHJveGllcyBhcmUgYWxsb3dl ZCB0byBjaGFuZ2UgVG9rZW4gYW5kIFRva2VuDQoNCj4gICAgICBMZW5ndGggYmV0d2VlbiBVRFAg aG9wcy4gIEhvd2V2ZXIsIG1vZGlmaWNhdGlvbnMgb2YgVG9rZW4gYW5kDQoNCj4gICAgICBUb2tl biBMZW5ndGggZHVyaW5nIGEgVURQIGhvcCBtYXkgYmVjb21lIGEgZGVuaWFsLW9mLXNlcnZpY2UN Cg0KPg0KDQo+U2VsYW5kZXIsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDI3LCAyMDE5 ICAgICAgICAgICAgICAgW1BhZ2UgNzZdDQoNCj4NCg0KPkludGVybmV0LURyYWZ0ICAgICAgICAg ICAgICAgICAgIE9TQ09SRSAgICAgICAgICAgICAgICAgICAgICAgIEp1bHkgMjAxOA0KDQo+DQoN Cj4gICAgICBhdHRhY2ssIHNpbmNlIGl0IG1heSBwcmV2ZW50IHRoZSBjbGllbnQgdG8gaWRlbnRp ZnkgdG8gd2hpY2gNCg0KPiAgICAgIHJlcXVlc3QgdGhlIHJlc3BvbnNlIGJlbG9uZ3Mgb3IgdG8g ZmluZCB0aGUgY29ycmVjdCBpbmZvcm1hdGlvbiB0bw0KDQo+ICAgICAgdmVyaWZ5IGludGVncml0 eSBvZiB0aGUgcmVzcG9uc2UuDQoNCj48bWdsdD4NCg0KPkkgYW0gcmVhZGluZyB0aGUgdGV4dCBh cy4gV2hlbiB0aGUgYXR0YWNrZXIgaXMgb24tcGF0aCwgYSBsb25nIFRva2VuIGRvZXMNCg0KPm5v dA0KDQo+cHJldmVudHMgdGhlIGF0dGFjayBiYXNlZCBvbiBhIHNwb29mZWQgcmVzcG9uc2UuIEhv d2V2ZXIsIGZvciBhbiBhdHRhY2tlcg0KDQo+dGhhdA0KDQo+aXMgbm90IG9uIHBhdGgsIHRoZSBh dHRhY2tlciBuZWVkcyB0byBndWVzcyB0aGUgVG9rZW4sIGFuZCB0aGlzIGNhbiBiZQ0KDQo+bWl0 aWdhdGVkIChwYXJ0aWFsbHkpIGJ5IGluY3JlYXNpbmcgdGhlIFRva2VuIHNpemUuICBOb3RlIHRo YXQgaW4gdGhlDQoNCj5sYXRlc3QNCg0KPmNhc2UsIGEgbG9uZyBUb2tlbiBzaG91bGQgbm90IGJl IHNlZW4gYXMgYSByZXBsYWNlbWVudCBmb3IgY3J5cHRvZ3JhcGhpYw0KDQo+cHJvdGVjdGlvbiBv ZiB0aGUgbWVzc2FnZS4gPC9tZ2x0Pg0KDQo+DQoNCj5bR1M6XSBUaGVyZSBzZWVtcyB0byBiZSBh IG1pc3VuZGVyc3RhbmRpbmcgc29tZXdoZXJlLiBUaGVyZSBpcyBubyBuZWVkDQoNCj5mb3IgYW55 b25lIHRvIOKAnGd1ZXNzIHRoZSBUb2tlbuKAnSBzaW5jZSBpdCBpcyBub3QgZW5jcnlwdGVkLiBU aGVyZSBpcw0KDQo+bm90aGluZyBoaW50ZWQgYWJvdXQgVG9rZW4gYmVpbmcgYSDigJxyZXBsYWNl bWVudCBmb3IgY3J5cHRv4oCdLCBzbyBJIGRvbuKAmXQNCg0KPnVuZGVyc3RhbmQgd2h5IGFueW9u ZSB3b3VsZCBiZSBsZWFkIHRvIHRoaW5rIHRoYXQuIFRva2VuIGxlbmd0aCBpcw0KDQo+bWVudGlv bmVkIHR3aWNlOyBpbiB0aGUgbmV4dCB0byBsYXN0IHNlbnRlbmNlIC0gbWVudGlvbmluZyB0aGF0 IENvQVANCg0KPnByb3hpZXMgKGxlZ2l0aW1hdGVseSkgbWF5IGNoYW5nZSBUb2tlbiBsZW5ndGg7 IGFuZCBpbiB0aGUgbGFzdCBzZW50ZW5jZQ0KDQo+LSBkZXNjcmliaW5nIHRoYXQgYW4gb24tcGF0 aCBhdHRhY2tlciBtYXkgbW9kaWZ5IHRoZSBUb2tlbiBMZW5ndGggd2hpY2gNCg0KPmVpdGhlciBj cmVhdGVkIG1pc21hdGNoIGJldHdlZW4gcmVxdWVzdCBhbmQgcmVzcG9uc2Ugb3Igbm8gbWF0Y2gg YXQgYWxsLA0KDQo+d2hpY2ggYXJlIGJvdGggZGVuaWFsIG9mIHNlcnZpY2UuIElzIGl0IGNsZWFy ZXIgaW4gdGhlIGZvbGxvd2luZyB3YXk/DQoNCk5FVw0KDQo+byBUb2tlbi9Ub2tlbiBMZW5ndGgu IFRoZSBUb2tlbiBmaWVsZCBpcyBhIGNsaWVudC1sb2NhbCBpZGVudGlmaWVyDQoNCj5mb3IgZGlm ZmVyZW50aWF0aW5nIGJldHdlZW4gY29uY3VycmVudCByZXF1ZXN0cyBbUkZDNzI1Ml0uDQoNCj4N Cg0KPg0KDQo8bWdsdDI+DQoNCldoYXQgSSB3YXMgdHJ5aW5nIHRvIHNheSBpcyB0aGF0IGlmIHlv dSB3YW50IHRvIHNwb29mIGEgcmVzcG9uc2UgKCBsaWtlIGluIEROUykgYW5kIHlvdSBhcmUgbm90 IG9uIHBhdGgsIHlvdSBuZWVkIHRvIGd1ZXNzIHRoZSBUb2tlbi4gSW4gdGhhdCBzZW5zZSwgdGhl IGxvbmdlciB0aGUgc2FmZXIuIEhvd2V2ZXIsIGFzIGZvciBETlMsIHdlIHNob3VsZCBub3QgcmVs eSBvbiB0aGlzLg0KDQo8L21nbHQyPg0KDQpHUzogUmlnaHQsIHdlIGRvbuKAmXQgcmVseSBvbiB0 aGUgbGVuZ3RoIG9mIHRva2VuIGZvciBzZWN1cml0eS4NCg0KDQo= --_000_D7B3CF16AD334goranselanderericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTogMTRweDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxkaXY+SGkgRGFuaWVsLDwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmtzIGZvciB5b3VyIHJlc3BvbnNlcy4gRGV0YWls ZWQgY29tbWVudHMgaW5saW5lLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V2l0aCB0 aGF0IEkgYmVsaWV2ZSBhbGwgb3V0c3RhbmRpbmcgY29tbWVudHMgYXJlIHJlc29sdmVkIGluIHZl cnNpb24gLTE1LiBMZXQgdXMga25vdyBpZiB0aGVyZSBhcmUgYW55IGZ1cnRoZXIgY29tbWVudHMu PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5CZXN0IHJlZ2FyZHM8L2Rpdj4NCjxkaXY+ R8O2cmFuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFu IGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxp YnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVS LUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1C T1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVS LVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJ TkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bh bj5EYW5pZWwgTWlnYXVsdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRhbmllbC5taWdhdWx0QGVyaWNz c29uLmNvbSI+ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nzb24uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBz dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPkZyaWRheSwgMzEgQXVndXN0IDIw MTggYXQgMjA6MjQ8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bh bj4mcXVvdDs8YSBocmVmPSJtYWlsdG86c2VjZGlyQGlldGYub3JnIj5zZWNkaXJAaWV0Zi5vcmc8 L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2VjZGlyQGlldGYub3JnIj5zZWNkaXJAaWV0 Zi5vcmc8L2E+Jmd0OywgR8O2cmFuIFNlbGFuZGVyICZsdDs8YSBocmVmPSJtYWlsdG86Z29yYW4u c2VsYW5kZXJAZXJpY3Nzb24uY29tIj5nb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb208L2E+Jmd0 Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPiZxdW90Ozxh IGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5LmFsbEBpZXRmLm9y ZyI+ZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eS5hbGxAaWV0Zi5vcmc8L2E+JnF1b3Q7 ICZsdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eS5hbGxA aWV0Zi5vcmciPmRyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHkuYWxsQGlldGYub3JnPC9h PiZndDssDQogJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmlldGZAaWV0Zi5vcmciPmlldGZAaWV0Zi5v cmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZkBpZXRmLm9yZyI+aWV0ZkBpZXRm Lm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9yZyI+Y29yZUBp ZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpjb3JlQGlldGYub3JnIj5jb3Jl QGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3Vi amVjdDogPC9zcGFuPlJlOiBbc2VjZGlyXSBTZWNkaXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFm dC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5LTE0PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUi IHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1B UkdJTjowIDAgMCA1OyI+DQo8ZGl2IHhtbG5zOnY9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 dm1sIiB4bWxuczpvPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHht bG5zOnc9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOndvcmQiIHhtbG5zOm09Imh0 dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0 dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5n ZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAy IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlNlZ29lIFVJIEVtb2pp Ijt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwg ZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5 NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGku TXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6d2luZG93dGV4dDt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3Jt YWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxh aW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4u RW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28t bGlzdC1pZDoxMjUzOTIzODM7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMDEzODI3NzQ0O30N CkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTk2MzcyNjk1MDsNCgltc28tbGlzdC10 eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTgyNzAzMTAxNCAtNTMyOTYwOTQg Njc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2 OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDow Ow0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7DQoJbXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIjt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwx OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDkN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0K CXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8ZGl2 IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SGkgR29yYW4sIDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGFuayB5b3UgZm9yIHlvdXIgZmVlZCBiYWNrcy4g SSBiZWxpZXZlIGFsbCBteSBjb25jZXJucyBoYXZlIGJlZW4gYWRkcmVzc2VkLiBZb3UgY2FuIHNl ZSBpbmxpbmUgdGhlIHNwZWNpZmljIHJlc3BvbnNlLiAmbHQ7bWdsdDImZ3Q7Jmx0Oy9tZ2x0MiZn dDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LSAtIC08L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNw YW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9P S19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBz b2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdiB4bWxuczp2PSJ1 cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOnZtbCIgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29t Om9mZmljZTp3b3JkIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmlj ZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4N CjxkaXYgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0Ozxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmbmJz cDsmbmJzcDsgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSBPYmplY3QgU2VjdXJpdHkgZm9yIENv bnN0cmFpbmVkIFJFU1RmdWw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7IEVudmlyb25tZW50cyAoT1NDT1JFKSBzZWN1cml0eSBwcm90 b2NvbCwgcHJvdGVjdGluZyBDb0FQIGFuZCBDb0FQLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmbmJzcDsmbmJzcDsgbWFwcGFibGUgSFRUUCByZXF1ZXN0 cyBhbmQgcmVzcG9uc2VzIGVuZC10by1lbmQgYWNyb3NzIGludGVybWVkaWFyeTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmbmJzcDsmbmJzcDsgbm9kZXMg c3VjaCBhcyBDb0FQIGZvcndhcmQgcHJveGllcyBhbmQgY3Jvc3MtcHJvdG9jb2wgdHJhbnNsYXRv cnM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7IGluY3VkaW5nIEhUVFAtdG8tQ29BUCBwcm94aWVzIFtSRkM4MDc1XS4mbmJzcDsgSW4g YWRkaXRpb24gdG8gdGhlIGNvcmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7IENvQVAgZmVhdHVyZXMgZGVmaW5lZCBpbiBbUkZDNzI1 Ml0sIE9TQ09SRSBzdXBwb3J0cyBPYnNlcnZlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyBbUkZDNzY0MV0sIEJsb2NrLXdpc2UgW1JG Qzc5NTldLCBOby1SZXNwb25zZSBbUkZDNzk2N10sIGFuZCBQQVRDSCBhbmQ8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7IEZFVENIIFtS RkM4MTMyXS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7 Jmx0O21nbHQmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 Jmd0O01heWJlIHRvbyBtYW55ICZxdW90O2FuZCZxdW90Oy48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmx0Oy9tZ2x0Jmd0OzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0O1tHUzpdIEkgc2VlIHdoYXQgeW91IG1lYW4uIFRoZSB0aXRs ZSBvZiBSRkMgODEzMiBpcyAmcXVvdDtQQVRDSCBhbmQgRkVUQ0g8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDttZXRob2RzIGZvciBDb0FQ4oCdLiBQZXJoYXBzIHdl IGp1c3QgY2hhbmdlIHRoZSBvcmRlciBvZiB0aGUgZXhhbXBsZXMgaW4gdGhlPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7bGFzdCBzZW50ZW5jZTogPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDtORVc8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmcXVvdDtJbiBhZGRpdGlvbiB0byB0aGUgY29y ZSBDb0FQIGZlYXR1cmVzIGRlZmluZWQgaW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDtbUkZDNzI1Ml0sIE9TQ09SRSBzdXBwb3J0cyBPYnNlcnZlIFtSRkM3NjQx XSwgQmxvY2std2lzZSBbUkZDNzk1OV0sIFBBVENIPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7YW5kIEZFVENIIFtSRkM4MTMyXSwgYW5kIE5vLVJlc3BvbnNlIFtS RkM3OTY3XS7igJ0/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29s b3I6cmVkIj4mbHQ7bWdsdDImZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+SSBhbSBmaW5lIGVpdGhlciB3YXlz LiBJIHRoaW5rIHRoZSBwcm9ibGVtIGlzIHRoYXQgd2UgYSBoYXZlIGEgbGlzdCBvZiBkaWZmZXJl bnQgbmF0dXJlLCB1bmxlc3Mgd2UgYXJlIGNvbnNpZGVyaW5nIHRoZSBkb2N1bWVudHMgdGhlbXNl bHZlcy4gSSB3b3VsZCBwcm9wb3NlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPk9TQ09SRSBzdXBwb3J0cyB0aGUg QmxvY2tXaXNlIFRyYW5zZmVydCBTaWduYWxpbmcmbmJzcDsgT3B0aW9uIFtSRkM3OTU5XSwgdGhl IE9ic2VydmVkIFtSRkM3NjQxXSBhbmQgTm8tUmVzcG9uc2UgT3B0aW9uLCBbUkZDNzk2N10sIGFz IHdlbGwgYXMgdGhlIFBBVENIIGFuZCBGRVRDSCBNZXRob2RzIFtSRkM4MTMyXS4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xv cjpyZWQiPiZsdDsvbWdsdDImZ3Q7PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkdTOiBSZXBo cmFzZWQgaW4g4oCTMTUuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19T UkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNv bTp2bWwiIHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIg eG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0i aHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8ZGl2IGxhbmc9IkVOLVVTIiBsaW5r PSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LSAtIC08L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L3NwYW4+PHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxibG9ja3F1b3RlIGlk PSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6 ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRp diB4bWxuczp2PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOnZtbCIgeG1sbnM6bz0idXJuOnNj aGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4bWxuczp3PSJ1cm46c2NoZW1hcy1t aWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxkaXYgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0 RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7 PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0O0kg YmVsaWV2ZSB0aGF0IFNlbmRlciBTZXF1ZW5jZSBOdW1iZXIgYWxzbyBuZWVkcyB0byBiZSBwcmVz ZW50IGluIHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZn dDtSZWNpcGllbnQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsm Z3Q7Q29udGV4dCBpbiBvcmRlciB0byBpbXBsZW1lbnQgYW50aSByZXBsYXkgbWVjaGFuaXNtLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0O1tHUzpdIFRoZSByZXBsYXkgd2lu ZG93IGlzIGFscmVhZHkgcGFydCBvZiB0aGUgUmVjaXBpZW50IENvbnRleHQuIFBlcmhhcHM8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDthIHJlZmVyZW5jZSB0byBT ZWN0aW9uIDcuNCB3b3VsZCBiZSBzdWZmaWNpZW50IHRvIG1ha2UgdGhlIGNvbm5lY3Rpb248bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDtiZXR3ZWVuIHJlcGxheSB3 aW5kb3cgYW5kIHNlcXVlbmNlIG51bWJlcj88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPiZsdDttZ2x0MiZndDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5H b29kLCB0aGVuIHllcyBhIHJlZmVyZW5jZSB3b3VsZCBiZSB1c2VmdWxsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+ Jmx0Oy9tZ2x0MiZndDs8L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+R1M6IEluY2x1ZGVkIGlu IOKAkzE1LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+LSAtIC08L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGJsb2NrcXVv dGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVIt TEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+ DQo8ZGl2IHhtbG5zOnY9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206dm1sIiB4bWxuczpvPSJ1 cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOnc9InVybjpzY2hl bWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOndvcmQiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1p Y3Jvc29mdC5jb20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3Jn L1RSL1JFQy1odG1sNDAiPg0KPGRpdiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9 IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0O1NlcXVlbmNlIE51bWJlciBNYXkgYmUgaW50ZXJw cmV0ZWQgZGlmZmVyZW50bHkuIEkgYmVsaWV2ZSB0aGF0PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0O2ludGVycHJldGF0aW9uPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0O3Nob3VsZCBhbHNvIGJlIHBhcnQgb2YgdGhl IENvbW1vbiBTZWN1cml0eSBDb250ZXh0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0O1tHUzpdIEkgZGlkbuKAmXQgdW5kZXJzdGFuZCB0aGlzIGNvbW1lbnQuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPiZsdDttZ2x0MiZn dDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iY29sb3I6cmVkIj5TZXF1ZW5jZSBOdW1iZXIgYXJlIG5vdCBhbHdheXMgaW5jcmVtZW50 ZWQuIFRoaXMgaW50ZXJwcmV0YXRpb24gbWF5IGltcGFjdCB0aGUgc2Vzc2lvbiwgc28gdGhhdCBt YXkgbmVlZCB0byBiZSBzcGVjaWZ5IGluIHRoZSBmdXR1cmUgd2hlbiBjb25zaWRlcmluZyBvdGhl ciBpbnRlcnByZXRhdGlvbiBvZiB0aGUgU1NOLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPiZsdDsvbWdsdDImZ3Q7 PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bh bj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkdTOiBUaGlzIHNwZWNpZmljYXRpb24gYXNzdW1l cyB0aGF0IFNTTiBpcyBpbmNyZW1lbnRlZCBhcyBzaG91bGQgYmUgY2xlYXIgZnJvbSB0aGUgcHJv Y2Vzc2luZyAoc2VjdGlvbiA4KS4gSW4g4oCTMTUgd2UgYWRkZWQgYSByZWZlcmVuY2UgdG8mbmJz cDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLW9i amVjdC1zZWN1cml0eS0xNSNyZWYtSS1ELm1jZ3Jldy1pdi1nZW4iIHRpdGxlPSImcXVvdDtHZW5l cmF0aW9uIG9mIERldGVybWluaXN0aWMgSW5pdGlhbGl6YXRpb24gVmVjdG9ycyAoSVZzKSBhbmQg Tm9uY2VzJnF1b3Q7Ij5JLUQubWNncmV3LWl2LWdlbjwvYT4uPC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj4tIC0gLTwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4N CjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHls ZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46 MCAwIDAgNTsiPg0KPGRpdiB4bWxuczp2PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOnZtbCIg eG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4bWxuczp3 PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJodHRwOi8v c2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8v d3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxkaXYgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYz QzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48YnI+DQo8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyZndDsmbmJzcDsmbmJzcDsgVGhlIGZvbGxvd2luZyBpbnB1dCBwYXJhbWV0 ZXJzIE1BWSBiZSBwcmUtZXN0YWJsaXNoZWQuJm5ic3A7IEluIGNhc2UgYW55PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyBvZiB0aGVz ZSBwYXJhbWV0ZXJzIGlzIG5vdCBwcmUtZXN0YWJsaXNoZWQsIHRoZSBkZWZhdWx0IHZhbHVlPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZuYnNwOyZuYnNw OyBpbmRpY2F0ZWQgYmVsb3cgaXMgdXNlZDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyBvJm5ic3A7IEFFQUQgQWxnb3JpdGhtPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgKiZuYnNwOyBEZWZhdWx0IGlzIEFFUy1DQ00tMTYtNjQtMTI4IChDT1NF IGFsZ29yaXRobSBlbmNvZGluZzogMTApPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyZndDsmbmJzcDsmbmJzcDsgbyZuYnNwOyBNYXN0ZXIgU2FsdDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICombmJzcDsgRGVmYXVsdCBpcyB0aGUgZW1wdHkgYnl0ZSBzdHJpbmc8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmx0O21nbHQmZ3Q7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0O0kgYmVsaWV2ZSBl eHBsaWNpdGx5IHByb3ZpZGluZyB0aGUgc3RyaW5nIGNvdWxkIGhlbHAuIFRoZXJlIGlzIGFsd2F5 cyB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Y29u ZnVzaW9uIHdpdGggJnF1b3Q7XDAmcXVvdDsgdmVyc3VzICZxdW90OyZxdW90Oy4gJmx0Oy9tZ2x0 Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0O1tHUzpdIE5vdGUgdGhh dCB0aGUgTWFzdGVyIFNhbHQgaXMgbmV2ZXIgc2VudCBhbmQgb25seSB1c2VkIGFzIHNhbHQgaW48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDtIS0RGIChzZWN0aW9u IDIuMiBvZiBSRkMgNTg2OSkuIFNlY3Rpb24gMy4yLjEgZGVzY3JpYmVzIGhvdyB0aGUgZW1wdHk8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDtzdHJpbmcgc2hvdWxk IGJlIGludGVycHJldGVkOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyZxdW90O05vdGUgdGhhdCBbUkZDNTg2OV0gc3BlY2lmaWVzIHRoYXQgaWYgdGhlIHNhbHQg aXMgbm90IHByb3ZpZGVkLCBpdCBpcyBzZXQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDt0byBhIHN0cmluZyBvZjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0O3plcm9zLiBGb3IgaW1wbGVtZW50YXRpb24gcHVycG9zZXMsIG5vdCBw cm92aWRpbmcgdGhlIHNhbHQgaXMgdGhlIHNhbWU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDthcyBzZXR0aW5nIHRoZSBzYWx0IHRvIHRoZSBlbXB0eSBieXRlIHN0 cmluZy4gT1NDT1JFIHNldHMgdGhlIHNhbHQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDtkZWZhdWx0IHZhbHVlIHRvIGVtcHR5IGJ5dGUgc3RyaW5nLCB3aGljaCBp biBbUkZDNTg2OV0gaXMgY29udmVydGVkIHRvIGE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDtzdHJpbmcgb2YgemVyb2VzIChzZWUgU2VjdGlvbiAyLjIgb2YgW1JG QzU4NjldKS4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDtJcyB0aGF0IHN1ZmZpY2llbnRseSBjbGVhcj88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPiZsdDttZ2x0MiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5UaGlz IGlzIGZpbmUuIEl0IHNlZW1zIHRvIG1lIHRoYXQgZW1wdHkgc3RyaW5nIGlzIOKAnOKAnSBoZXJl LiBJIHVzdWFsbHkgbGlrZSB0byBjaXRlIGV4cGxpY2l0bHkgdGhlIHN0cmluZyB0byBhdm9pZCBj b25mdXNpb24gYmV0d2VlbiDigJzigJ0gb3Ig4oCcXDDigJ0uIEkgYWdyZWUgdGhhdCBzYXlpbmcg emVybyBsZW5ndGggZG9lcyBub3QgaGVscCBtdWNoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+VGhlIGxhdGVzdCBz ZW50ZW5jZSBoYXMgdHdvIHJlZmVyZW5jZSB0byBSRkM1ODY5LCBtYXliZSBvbmUgd291bGQgYmUg c3VmZmljaWVudC4gSWYgcG9zc2libGUsIGl0IG1pZ2h0IGJlIGJldHRlciB0byBzcGVjaWZ5IHRo ZSBsZW5ndGggb2YgdGhlIHN0cmluZ3Mgb2YgemVyb3MgKEhhc2hMZW4gaW4gb3VyIGNhc2UpDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls ZT0iY29sb3I6cmVkIj4mbHQ7L21nbHQyJmd0Ozwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5H UzogT25lIG9mIHRoZSByZWZlcmVuY2VzIHRvIFJGQzU4NjkgcmVtb3ZlZCBpbiDigJMxNS4gVGhl IHByb2NlZHVyZSBmb3IgaGFuZGxpbmcgdGhlIGNhc2Ugb2Ygbm8gc2FsdCBwcm92aWRlZCBpcyBj bGVhcmx5IHNwZWNpZmllZCBpbiBzZWN0aW9uIDIuMiBvZiBSRkM1ODY5LCB3aGljaCB3ZSByZWZl cmVuY2UuIEkgd291bGQgcmF0aGVyIG5vdCBpbmNsdWRlIHRoZSBkZXRhaWxzIGluIHRoaXMgc3Bl Y2lmaWNhdGlvbi48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pi0gLSAtPC9kaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxibG9j a3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9S REVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAg NTsiPg0KPGRpdiB4bWxuczp2PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOnZtbCIgeG1sbnM6 bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4bWxuczp3PSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJodHRwOi8vc2NoZW1h cy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3Lncz Lm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxkaXYgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZs aW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgd2hpY2ggZGVmaW5l cyBob3cgdG88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZuYnNwOyZu YnNwOyBvJm5ic3A7IEtleSBEZXJpdmF0aW9uIEZ1bmN0aW9uIChLREYpPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgKiZuYnNwOyBEZWZhdWx0IGlzIEhLREYgU0hBLTI1NjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgUmVwbGF5IFdp bmRvdyBUeXBlIGFuZCBTaXplPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKiZuYnNwOyBEZWZhdWx0IGlz IERUTFMtdHlwZSByZXBsYXkgcHJvdGVjdGlvbiB3aXRoIGEgd2luZG93IHNpemUgb2YgMzI8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtSRkM2MzQ3XTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmbHQ7bWdsdCZndDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7VGhpcyBzZWN0aW9uIHNw ZWNpZmllcyBUeXBlIGFuZCB3aW5kb3dzIGZvciB0aGUgYW50aSByZXBsYXkgbWVjaGFuaXNtLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDtUaGlzIHdhczxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDtkZXNjcmliZWQg YXMgUmVwbGF5IFdpbmRvd3MgaW4gdGhlIGNvbnRleHQgZGVzY3JpcHRpb24uICZsdDsvbWdsdCZn dDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDtbR1M6XSBJIGRpZG7igJl0 IHVuZGVyc3RhbmQgdGhpcyBjb21tZW50LiBEbyB5b3UgbWVhbjo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDtPTEQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDtSZXBsYXkgV2luZG93IFR5cGUgYW5kIFNpemU8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDtORVc8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDtSZXBsYXkgV2luZG93PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj4mbHQ7bWdsdDImZ3Q7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJl ZCI+SWYgZGlmZmVyZW50IG1lY2hhbmlzbSBjb3VsZCBiZSB1c2VkLCBJIG1lYW50OjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xv cjpyZWQiPiogUmVwbGF5IFdpbmRvdyBUeXBlIDogZGVmYXVsdCB0byBEVExTIDEuMjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xv cjpyZWQiPiogUmVwbGF5IFdpbmRvdyBTaXplIChQYXJhbWV0ZXJzKToNCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQi PiZsdDsvbWdsdCZndDs8L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2PkdTOiBUaGUgZGVmYXVsdCB2YWx1ZXMgbGlzdGVkIGluIHNlY3Rpb24gMy4yIHdlcmUgaW50 ZW5kZWQgdG8gcmVwZWF0IHRoZSBwYXJhbWV0ZXJzIGxpc3RlZCBpbiBzZWN0aW9uIDMuMS4gSSBy ZWFsaXNlZCBmcm9tIHlvdXIgY29tbWVudCB0aGF0ICZuYnNwO3RoYXQgJnF1b3Q7UmVwbGF5IFdp bmRvdyZxdW90OyBkZXZpYXRlZCBmcm9tIHRoaXMgY29udmVudGlvbi4gV2UgcmVzb2x2ZWQgdGhh dCBpbiDigJMxNSBieSBjaGFuZ2luZyB0aGUgdGVybSBpbiBzZWN0aW9uIDMuMi4NCiBZb3VyIHBy b3Bvc2FsIHdvdWxkIGFsc28gcmVxdWlyZSBhIGNoYW5nZSB0byBzZWN0aW9uIDMuMS4gTm90ZSB0 aGF0IHdlIGRvIG5vdCByZXN0cmljdCB0byBEVExTIHR5cGUgcmVwbGF5IHByb3RlY3Rpb24sIHNv IHdlIHdvdWxkIHJhdGhlciBub3QgaXRlbWlzZSB0aGUgc3ViLXBhcmFtZXRlcnMgb2YgdGhlIHJl cGxheSBwcm90ZWN0aW9uIG1lY2hhbmlzbS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 Pi0gLSAtPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9T RUNUSU9OIj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FV T1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1 OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdiB4bWxuczp2PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQt Y29tOnZtbCIgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNl IiB4bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczpt PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5z PSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxkaXYgbGFuZz0iRU4tVVMiIGxp bms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7W0dTOl0gTm8sIHRoZSByZXN0cmljdGlvbiBjb21lcyBm cm9tIHRoZSBub25jZSBjb25zdHJ1Y3Rpb24sIEkgd2lsbCBhZGQgYQ0KPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7cmVmZXJlbmNlIHRvIFNlY3Rpb24gNS4yLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9y OnJlZCI+Jmx0O21nbHQyJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPlRoYW5rcywgSSBiZWxpZXZlIHRoYXQg d291bGQgYmUgdXNlZnVsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPiZsdDsvbWdsdDImZ3Q7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFu Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+R1M6IERvbmUgaW4gLTE1PC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj4tIC0gLTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlk PSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRU UklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7 IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXYgeG1sbnM6dj0idXJuOnNj aGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1j b206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZp Y2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAw NC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8ZGl2 IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDs0LjEuMy41LjIuJm5i c3A7IE5vdGlmaWNhdGlvbnM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7Jmd0OyZuYnNwOyZuYnNwOyBJZiB0aGUgc2VydmVyIGFjY2VwdHMgYW4gT2JzZXJ2ZSByZWdp c3RyYXRpb24sIGEgUGFydGlhbCBJViBNVVNUIGJlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyBpbmNsdWRlZCBpbiBhbGwgbm90aWZp Y2F0aW9ucyAoYm90aCBzdWNjZXNzZnVsIGFuZCBlcnJvciksIGV4Y2VwdCBmb3I8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7IHRoZSBm aXJzdCBvbmUgd2hlcmUgUGFydGlhbCBJViBNQVkgYmUgb21pdHRlZC4mbmJzcDsgVG8gcHJvdGVj dCBhZ2FpbnN0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyByZXBsYXksIHRoZSBjbGllbnQgU0hBTEwgbWFpbnRhaW4gYSBOb3RpZmlj YXRpb24gTnVtYmVyIGZvciBlYWNoPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyBPYnNlcnZhdGlvbiBpdCByZWdpc3RlcnMuJm5ic3A7 IFRoZSBOb3RpZmljYXRpb24gTnVtYmVyIGlzIGEgbm9uLW5lZ2F0aXZlPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyBpbnRlZ2VyIGNv bnRhaW5pbmcgdGhlIGxhcmdlc3QgUGFydGlhbCBJViBvZiB0aGUgcmVjZWl2ZWQ8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7IG5vdGlm aWNhdGlvbnMgZm9yIHRoZSBhc3NvY2lhdGVkIE9ic2VydmUgcmVnaXN0cmF0aW9uLiZuYnNwOyBG dXJ0aGVyPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZu YnNwOyZuYnNwOyBkZXRhaWxzIG9mIHJlcGxheSBwcm90ZWN0aW9uIG9mIG5vdGlmaWNhdGlvbnMg YXJlIHNwZWNpZmllZCBpbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyZndDsmbmJzcDsmbmJzcDsgU2VjdGlvbiA3LjQuMS48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyBGb3Igbm90aWZpY2F0aW9ucywg dGhlIElubmVyIE9ic2VydmUgdmFsdWUgTVVTVCBiZSBlbXB0eSAoc2VlPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyBTZWN0aW9uIDMu MiBvZiBbUkZDNzI1Ml0pLiZuYnNwOyBUaGUgT3V0ZXIgT2JzZXJ2ZSBpbiBhIG5vdGlmaWNhdGlv biBpczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDs8bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7U2VsYW5k ZXIsIGV0IGFsLiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBFeHBp cmVzIEphbnVhcnkgMjcsIDIwMTkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7W1BhZ2UgMjBd PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OzxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDtJbnRlcm5ldC1E cmFmdCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBP U0NPUkUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSnVseSAyMDE4PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmbmJzcDsmbmJzcDsgbmVlZGVkIGZvciBpbnRl cm1lZGlhcnkgbm9kZXMgdG8gYWxsb3cgbXVsdGlwbGUgcmVzcG9uc2VzIHRvIG9uZTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmbmJzcDsmbmJzcDsgcmVx dWVzdCwgYW5kIG1heSBiZSBzZXQgdG8gdGhlIHZhbHVlIG9mIE9ic2VydmUgaW4gdGhlIG9yaWdp bmFsIENvQVA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7IG1lc3NhZ2UuJm5ic3A7IFRoZSBjbGllbnQgcGVyZm9ybXMgb3JkZXJpbmcg b2Ygbm90aWZpY2F0aW9ucyBhbmQgcmVwbGF5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyBwcm90ZWN0aW9uIGJ5IGNvbXBhcmluZyB0 aGVpciBQYXJ0aWFsIElWcyBhbmQgU0hBTEwgaWdub3JlIHRoZSBvdXRlcjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmbmJzcDsmbmJzcDsgT2JzZXJ2ZSB2 YWx1ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZuYnNw OyZuYnNwOyBJZiB0aGUgY2xpZW50IHJlY2VpdmVzIGEgcmVzcG9uc2UgdG8gYW4gT2JzZXJ2ZSBy ZXF1ZXN0IHdpdGhvdXQgYW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7IElubmVyIE9ic2VydmUgb3B0aW9uLCB0aGVuIGl0IHZlcmlm aWVzIHRoZSByZXNwb25zZSBhcyBhIG5vbi1PYnNlcnZlPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyByZXNwb25zZSwgYXMgc3BlY2lm aWVkIGluIFNlY3Rpb24gOC40LiZuYnNwOyBJZiB0aGUgY2xpZW50IHJlY2VpdmVzIGE8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7IHJl c3BvbnNlIHRvIGEgbm9uLU9ic2VydmUgcmVxdWVzdCB3aXRoIGFuIElubmVyIE9ic2VydmUgb3B0 aW9uLCB0aGVuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyBpdCBzdG9wcyBwcm9jZXNzaW5nIHRoZSBtZXNzYWdlLCBhcyBzcGVjaWZp ZWQgaW4gU2VjdGlvbiA4LjQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyZndDsmbmJzcDsmbmJzcDsgQSBjbGllbnQgTVVTVCBjb25zaWRlciB0aGUgbm90aWZpY2F0 aW9uIHdpdGggdGhlIGhpZ2hlc3QgUGFydGlhbCBJVjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmbmJzcDsmbmJzcDsgYXMgdGhlIGZyZXNoZXN0LCByZWdh cmRsZXNzIG9mIHRoZSBvcmRlciBvZiBhcnJpdmFsLiZuYnNwOyBJbiBvcmRlciB0bzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmbmJzcDsmbmJzcDsgc3Vw cG9ydCBleGlzdGluZyBPYnNlcnZlIGltcGxlbWVudGF0aW9ucyB0aGUgT1NDT1JFIGNsaWVudDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmbmJzcDsmbmJz cDsgaW1wbGVtZW50YXRpb24gTUFZIHNldCB0aGUgT2JzZXJ2ZSB2YWx1ZSB0byB0aGUgdGhyZWUg bGVhc3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jm5i c3A7Jm5ic3A7IHNpZ25pZmljYW50IGJ5dGVzIG9mIHRoZSBQYXJ0aWFsIElWOyBzdWNoIGFuIGlt cGxlbWVudGF0aW9uIG5lZWRzIHRvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyBtYWtlIHN1cmUgdGhhdCB0aGUgT2JzZXJ2ZSB2YWx1 ZSBmb3IgYW4gb2JzZXJ2ZSBub3RpZmljYXRpb24gd2l0aG91dDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmbmJzcDsmbmJzcDsgUGFydGlhbCBJViBpcyBz bWFsbGVyIHRoYW4gYSBub3RpZmljYXRpb24gd2l0aCBQYXJ0aWFsIElWLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmx0O21nbHQmZ3Q7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0O1RoaXMgc2VjdGlvbiBkaXNjdXNz IHRoZSBiZWhhdmlvciByZWdhcmRpbmcgdGhlIHNlcXVlbmNlIG51bWJlci4gV2hpbGUNCjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDt0aGU8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7c2VxdWVuY2UgbnVtYmVyIGFu ZCB0aGUgcGFydGlhbCBJViBoYXZlIHRoZSBzYW1lIHZhbHVlLCBJIGFtIHdvbmRlcmluZw0KPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0O2lmIDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDtpdDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDt3b3VsZCBub3QgYmUgbW9yZSBhcHBy b3ByaWF0ZWQgdG8gbWVudGlvbiB0aGUgc2VxdWVuY2UgbnVtYmVyIHZhbHVlIGlzDQo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7cHJvdmlkZWQ8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7YnkgdGhlIHBhcnRpYWwg SVYsIGFuZCB0aGVuIHVzZSB0aGUgc2VxdWVuY2UgbnVtYmVyIHZhcmlhYmxlIHRvIGRlc2NyaWJl DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7YW50aTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDtyZXBsYXkuICZs dDsvbWdsdCZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDtbR1M6XSBXZSBpbnRl bmRlZCB0byB1c2UgdGhlIHRlcm0g4oCccGFydGlhbCBJVuKAnSB3aGVuIHJlZmVycmluZyB0byB0 aGUNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0O251bWJlciBi ZWluZyB0cmFuc3BvcnRlZCBhbmQg4oCcU1NOJnF1b3Q7IHdoZW4gcmVmZXJyaW5nIHRvIHRoZSBu dW1iZXIgc3RvcmVkIGluDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDt0aGUgZW5kcG9pbnQuIEkgd2lsbCBnbyB0aHJvdWdoIHRoZSBkb2N1bWVudCBhbmQgc2Vl IHRoYXQgdGhpcyBjb252ZW50aW9uDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDtpcyBrZXB0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPiZsdDttZ2x0MiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5NYXli ZSB0aGF0IHdvdWxkIGJlIHVzZWZ1bCB0byBtZW50aW9uIHRoaXMgY29udmVudGlvbjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xv cjpyZWQiPiZsdDsvbWdsdDImZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5HUzogSeKA mW0gbm90IHN1cmUgZ29pbmcgaW50byB0aGlzIGRpc3RpbmN0aW9uIGlzIG5lY2Vzc2FyeS4gV2Ug YWxyZWFkeSBkZXNjcmliZSB0aGUgcmVsYXRpb25zaGlwIGluIHNldmVyYWwgcGxhY2VzOjwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+U2VjdGlvbiAzLjE6PC9kaXY+DQo8ZGl2Pg0KPHBy ZSBjbGFzcz0ibmV3cGFnZSI+JnF1b3Q7U2VuZGVyIFNlcXVlbmNlIE51bWJlci4gIE5vbi1uZWdh dGl2ZSBpbnRlZ2VyIHVzZWQgYnkgdGhlIHNlbmRlcg0KICAgICAgdG8gZW51bWVyYXRlIHJlcXVl c3RzIGFuZCBjZXJ0YWluIHJlc3BvbnNlcywgZS5nLiAgT2JzZXJ2ZQ0KICAgICAgbm90aWZpY2F0 aW9ucy4gIFVzZWQgYXMgJ1BhcnRpYWwgSVYnIFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjODE1MiIgdGl0bGU9IiZxdW90O0NCT1IgT2JqZWN0IFNpZ25pbmcgYW5kIEVu Y3J5cHRpb24gKENPU0UpJnF1b3Q7Ij5SRkM4MTUyPC9hPl0gdG8gZ2VuZXJhdGUgdW5pcXVlDQog ICAgICBBRUFEIG5vbmNlcy4mcXVvdDs8L3ByZT4NCjxwcmUgY2xhc3M9Im5ld3BhZ2UiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgd2hpdGUtc3BhY2U6IG5v cm1hbDsiPlNlY3Rpb24gNTo8L3NwYW4+PC9wcmU+DQo8cHJlIGNsYXNzPSJuZXdwYWdlIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4mcXVvdDsgVGhlICdQ YXJ0aWFsIElWJyBwYXJhbWV0ZXIuICBUaGUgdmFsdWUgaXMgc2V0IHRvIHRoZSBTZW5kZXIgU2Vx dWVuY2UgTnVtYmVyLiZxdW90Ozwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+U2VjdGlvbiA3LjI6PC9kaXY+DQo8ZGl2Pg0KPHByZSBjbGFzcz0ibmV3cGFnZSI+ JnF1b3Q7UGFydGlhbCBJVnMgKHdoaWNoIGVuY29kZSB0aGUgU2VuZGVyIFNlcXVlbmNlIE51bWJl cnMsIHNlZSA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1j b3JlLW9iamVjdC1zZWN1cml0eS0xNSNzZWN0aW9uLTUiPlNlY3Rpb24gNTwvYT4pJnF1b3Q7PC9w cmU+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlIGNsYXNzPSJuZXdwYWdlIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IHdoaXRlLXNwYWNlOiBub3JtYWw7Ij48YnI+ PC9zcGFuPjwvcHJlPg0KPHByZSBjbGFzcz0ibmV3cGFnZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyI+U2VjdGlvbiA3 LjQgKGFkZHJlc3NpbmcgYW5vdGhlciBjb21tZW50IG9mIHlvdXJzKTo8L3NwYW4+PC9wcmU+DQo8 cHJlIGNsYXNzPSJuZXdwYWdlIj4mcXVvdDtQYXJ0aWFsIElWID0gU2VuZGVyIFNlcXVlbmNlIE51 bWJlciZxdW90OzwvcHJlPg0KPC9kaXY+DQo8ZGl2PmFuZCBhbHNvIHNldmVyYWwgdGltZXMgaW4g dGhlIHByb2Nlc3NpbmcsIFNlY3Rpb24gOC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj4tIC0gLTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGJsb2NrcXVv dGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVIt TEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+ DQo8ZGl2IHhtbG5zOnY9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206dm1sIiB4bWxuczpvPSJ1 cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOnc9InVybjpzY2hl bWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOndvcmQiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1p Y3Jvc29mdC5jb20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3Jn L1RSL1JFQy1odG1sNDAiPg0KPGRpdiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9 IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDtELjQuMS4mbmJzcDsgQ29BUCBIZWFkZXIgRmllbGRzPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgVmVyc2lvbi4mbmJz cDsgVGhlIENvQVAgdmVyc2lvbiBbUkZDNzI1Ml0gaXMgbm90IGV4cGVjdGVkIHRvIGJlPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHNlbnNpdGl2ZSB0byBkaXNjbG9zZS4mbmJzcDsgQ3VycmVudGx5IHRoZXJl IGlzIG9ubHkgb25lIENvQVAgdmVyc2lvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZWZpbmVkLiZuYnNw OyBBIGNoYW5nZSBvZiB0aGlzIHBhcmFtZXRlciBpcyBwb3RlbnRpYWxseSBhIGRlbmlhbC1vZi08 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgc2VydmljZSBhdHRhY2suJm5ic3A7IEZ1dHVyZSB2ZXJzaW9ucyBv ZiBDb0FQIG5lZWQgdG8gYW5hbHl6ZSBhdHRhY2tzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRvIE9TQ09S RSBwcm90ZWN0ZWQgbWVzc2FnZXMgZHVlIHRvIGFuIGFkdmVyc2FyeSBjaGFuZ2luZyB0aGUgQ29B UDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB2ZXJzaW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyZuYnNwOyZuYnNwOyBvJm5ic3A7IFRva2VuL1Rva2VuIExlbmd0aC4mbmJzcDsg VGhlIFRva2VuIGZpZWxkIGlzIGEgY2xpZW50LWxvY2FsIGlkZW50aWZpZXI8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgZm9yIGRpZmZlcmVudGlhdGluZyBiZXR3ZWVuIGNvbmN1cnJlbnQgcmVxdWVzdHMgW1JG QzcyNTJdLiZuYnNwOyBBbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlYXZlc2Ryb3BwZXIgcmVhZGluZyB0 aGUgdG9rZW4gY2FuIG1hdGNoIHJlcXVlc3RzIHRvIHJlc3BvbnNlczxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB3aGljaCBjYW4gYmUgdXNlZCBpbiB0cmFmZmljIGFuYWx5c2lzLiZuYnNwOyBJbiBwYXJ0aWN1 bGFyIHRoaXMgaXMgdHJ1ZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBmb3Igbm90aWZpY2F0aW9ucywgd2hl cmUgbXVsdGlwbGUgcmVzcG9uc2VzIGFyZSBtYXRjaGVkIHdpdGggb25lPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHJlcXVlc3QuJm5ic3A7IENvQVAgcHJveGllcyBhcmUgYWxsb3dlZCB0byBjaGFuZ2UgVG9r ZW4gYW5kIFRva2VuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IExlbmd0aCBiZXR3ZWVuIFVEUCBob3BzLiZu YnNwOyBIb3dldmVyLCBtb2RpZmljYXRpb25zIG9mIFRva2VuIGFuZDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBUb2tlbiBMZW5ndGggZHVyaW5nIGEgVURQIGhvcCBtYXkgYmVjb21lIGEgZGVuaWFsLW9mLXNl cnZpY2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDtTZWxhbmRlciwgZXQg YWwuJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEV4cGlyZXMgSmFu dWFyeSAyNywgMjAxOSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbUGFnZSA3Nl08bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDtJbnRlcm5ldC1EcmFmdCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPU0NPUkUmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgSnVseSAyMDE4PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwO2F0dGFjaywgc2luY2UgaXQgbWF5 IHByZXZlbnQgdGhlIGNsaWVudCB0byBpZGVudGlmeSB0byB3aGljaDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyByZXF1ZXN0IHRoZSByZXNwb25zZSBiZWxvbmdzIG9yIHRvIGZpbmQgdGhlIGNvcnJlY3QgaW5m b3JtYXRpb24gdG88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdmVyaWZ5IGludGVncml0eSBvZiB0aGUgcmVz cG9uc2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmx0O21n bHQmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7SSBhbSBy ZWFkaW5nIHRoZSB0ZXh0IGFzLiBXaGVuIHRoZSBhdHRhY2tlciBpcyBvbi1wYXRoLCBhIGxvbmcg VG9rZW4gZG9lcw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 bm90PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7cHJldmVudHMg dGhlIGF0dGFjayBiYXNlZCBvbiBhIHNwb29mZWQgcmVzcG9uc2UuIEhvd2V2ZXIsIGZvciBhbiBh dHRhY2tlcg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7dGhh dDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0O2lzIG5vdCBvbiBw YXRoLCB0aGUgYXR0YWNrZXIgbmVlZHMgdG8gZ3Vlc3MgdGhlIFRva2VuLCBhbmQgdGhpcyBjYW4g YmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDttaXRpZ2F0ZWQg KHBhcnRpYWxseSkgYnkgaW5jcmVhc2luZyB0aGUgVG9rZW4gc2l6ZS4mbmJzcDsgTm90ZSB0aGF0 IGluIHRoZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7bGF0 ZXN0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Y2FzZSwgYSBs b25nIFRva2VuIHNob3VsZCBub3QgYmUgc2VlbiBhcyBhIHJlcGxhY2VtZW50IGZvciBjcnlwdG9n cmFwaGljPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7cHJvdGVj dGlvbiBvZiB0aGUgbWVzc2FnZS4gJmx0Oy9tZ2x0Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0O1tHUzpdIFRoZXJlIHNlZW1zIHRvIGJlIGEgbWlzdW5kZXJzdGFuZGlu ZyBzb21ld2hlcmUuIFRoZXJlIGlzIG5vIG5lZWQNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0O2ZvciBhbnlvbmUgdG8g4oCcZ3Vlc3MgdGhlIFRva2Vu4oCdIHNp bmNlIGl0IGlzIG5vdCBlbmNyeXB0ZWQuIFRoZXJlIGlzDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDtub3RoaW5nIGhpbnRlZCBhYm91dCBUb2tlbiBiZWluZyBh IOKAnHJlcGxhY2VtZW50IGZvciBjcnlwdG/igJ0sIHNvIEkgZG9u4oCZdA0KPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7dW5kZXJzdGFuZCB3aHkgYW55b25lIHdv dWxkIGJlIGxlYWQgdG8gdGhpbmsgdGhhdC4gVG9rZW4gbGVuZ3RoIGlzDQo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDttZW50aW9uZWQgdHdpY2U7IGluIHRoZSBu ZXh0IHRvIGxhc3Qgc2VudGVuY2UgLSBtZW50aW9uaW5nIHRoYXQgQ29BUA0KPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7cHJveGllcyAobGVnaXRpbWF0ZWx5KSBt YXkgY2hhbmdlIFRva2VuIGxlbmd0aDsgYW5kIGluIHRoZSBsYXN0IHNlbnRlbmNlDQo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDstIGRlc2NyaWJpbmcgdGhhdCBh biBvbi1wYXRoIGF0dGFja2VyIG1heSBtb2RpZnkgdGhlIFRva2VuIExlbmd0aCB3aGljaA0KPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ZWl0aGVyIGNyZWF0ZWQg bWlzbWF0Y2ggYmV0d2VlbiByZXF1ZXN0IGFuZCByZXNwb25zZSBvciBubyBtYXRjaCBhdCBhbGws DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDt3aGljaCBhcmUg Ym90aCBkZW5pYWwgb2Ygc2VydmljZS4gSXMgaXQgY2xlYXJlciBpbiB0aGUgZm9sbG93aW5nIHdh eT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk5FVzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0O28gVG9rZW4vVG9rZW4gTGVuZ3RoLiBU aGUgVG9rZW4gZmllbGQgaXMgYSBjbGllbnQtbG9jYWwgaWRlbnRpZmllcjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0O2ZvciBkaWZmZXJlbnRpYXRpbmcgYmV0d2Vl biBjb25jdXJyZW50IHJlcXVlc3RzIFtSRkM3MjUyXS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPiZsdDttZ2x0MiZndDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5X aGF0IEkgd2FzIHRyeWluZyB0byBzYXkgaXMgdGhhdCBpZiB5b3Ugd2FudCB0byBzcG9vZiBhIHJl c3BvbnNlICggbGlrZSBpbiBETlMpIGFuZCB5b3UgYXJlIG5vdCBvbiBwYXRoLCB5b3UgbmVlZCB0 byBndWVzcyB0aGUgVG9rZW4uIEluIHRoYXQgc2Vuc2UsIHRoZSBsb25nZXIgdGhlIHNhZmVyLiBI b3dldmVyLCBhcyBmb3IgRE5TLCB3ZSBzaG91bGQgbm90IHJlbHkNCiBvbiB0aGlzLiAmbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls ZT0iY29sb3I6cmVkIj4mbHQ7L21nbHQyJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2PkdTOiBSaWdodCwgd2UgZG9u4oCZdCByZWx5IG9uIHRoZSBsZW5ndGggb2YgdG9r ZW4gZm9yIHNlY3VyaXR5LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtf U1JDX0JPRFlfU0VDVElPTiI+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJ T05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJ Tkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXYgeG1sbnM6dj0idXJuOnNjaGVtYXMt bWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29y ZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9v bW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8ZGl2IGxhbmc9 IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGJyPg0KPC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D7B3CF16AD334goranselanderericssoncom_-- From nobody Tue Sep 4 04:42:24 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE3A130EC4 for ; Tue, 4 Sep 2018 04:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 FbfF_xSuKyL5 for ; Tue, 4 Sep 2018 04:42:11 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 3DF84130EC8 for ; Tue, 4 Sep 2018 04:42:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1536061328; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=9Fuor0ab7BXT1KViV+tCVib3G5w9yTyXdZHt3xX5kTY=; b=D3rW48biUGYBPCiJWzxHfsQ+lkq//dHo6NLtZfmAQKKMwMwdGFHX4HGsuGOmBh2V HIqzqPsA6tG3wajS5BtTVLetvrP57dIW6qhM12zAPd9En2gJVfTVTFszqUEx5bFd zZnRX/J1fLYTXmEYqN+nSCOkzHHDOdZQ76nRvywXSyk=; X-AuditID: c1b4fb25-8e7ff700000013ad-83-5b8e6f90295e Received: from ESESBMB501.ericsson.se (Unknown_Domain [153.88.183.114]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 94.A4.05037.09F6E8B5; Tue, 4 Sep 2018 13:42:08 +0200 (CEST) Received: from EUSASMB503.ericsson.se (147.117.188.221) by ESESBMB501.ericsson.se (153.88.183.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 4 Sep 2018 13:42:07 +0200 Received: from EUSASMB503.ericsson.se ([147.117.188.239]) by EUSASMB503.ericsson.se ([147.117.188.239]) with mapi id 15.01.1466.003; Tue, 4 Sep 2018 07:42:05 -0400 From: Daniel Migault To: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= , "secdir@ietf.org" CC: "draft-ietf-core-object-security.all@ietf.org" , "ietf@ietf.org" , "core@ietf.org" Thread-Topic: [secdir] Secdir last call review of draft-ietf-core-object-security-14 Thread-Index: AQHURCRKq+z0Y7hnFkaX71ieBzLbR6Tf/8HA Date: Tue, 4 Sep 2018 11:42:05 +0000 Message-ID: <6029df3f46e647c38a38b8be969c072b@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.8] Content-Type: multipart/alternative; boundary="_000_6029df3f46e647c38a38b8be969c072bericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyM2J7ke6E/L5og+8rJS32vV3PbPGtZx6r xbON81ksPix8yOLA4rFkyU+mAMYoLpuU1JzMstQifbsEroyF+36zFRyazlpxqnEVUwPjmjbW LkZODgkBE4k/3x+ydTFycQgJHGWUuH7iHwuE841RYv3DDnYIZzmjxLeLLcwgLWwCRhJth/qB EhwcIgKZEu++K4LUMIPUnGj8zgQSFxYIlZh3ug6kXEQgTOLmxnVsELaRxMnZy1hAbBYBFYlJ H9vB4rwC1hL9s+6AjRcSsJC4dX0G2HWcApYSy2c+YQSxGQXEJL6fWsMEYjMLiEvcejKfCeID AYkle84zQ9iiEi8f/4P6TFHi8+kb7BD1yRIHX85lhNglKHFy5hOWCYyis5CMmoWkbBaSsllA 3zALaEqs36UPUaIoMaX7ITuErSHROmcuO7L4Akb2VYyixanFSbnpRsZ6qUWZycXF+Xl6eakl mxiB0Xdwy2/VHYyX3zgeYhTgYFTi4Z2b1BctxJpYVlyZe4hRgoNZSYTXjx8oxJuSWFmVWpQf X1Sak1p8iFGag0VJnPeh+eYoIYH0xJLU7NTUgtQimCwTB6dUA6PhpH/S+jM3H5y3fYFfmln3 58aGN/elLW/uzkvVupvzWXHWF/YlqgEK03ReH111niVB1Ft8gu72nQpbeXW6H/Uffvo+4+6l JxMPylZd8M2t4TXZ5Rp6XuAA70Kj+d6flhmeyd0QMumO7UTheQa/ZcuT9zorGN2SEF1YFlsp eW+H0aPPp7cUT/RVYinOSDTUYi4qTgQAG3WgjboCAAA= Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-core-object-security-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 11:42:16 -0000 --_000_6029df3f46e647c38a38b8be969c072bericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR29yYW4sDQoNCk15IGNvbmNlcm5zIGhhdmUgYmVlbiBhZGRyZXNzZWQuIFRoYW5rcyBmb3Ig dGhlIGV4cGxhbmF0aW9ucy4NCg0KWW91cnMsDQpEYW5pZWwNCg0KRnJvbTogR8O2cmFuIFNlbGFu ZGVyDQpTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMDQsIDIwMTggMzo1MyBBTQ0KVG86IERhbmll bCBNaWdhdWx0IDxkYW5pZWwubWlnYXVsdEBlcmljc3Nvbi5jb20+OyBzZWNkaXJAaWV0Zi5vcmcN CkNjOiBkcmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5LmFsbEBpZXRmLm9yZzsgaWV0ZkBp ZXRmLm9yZzsgY29yZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzZWNkaXJdIFNlY2RpciBsYXN0 IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHktMTQNCg0KSGkg RGFuaWVsLA0KDQpUaGFua3MgZm9yIHlvdXIgcmVzcG9uc2VzLiBEZXRhaWxlZCBjb21tZW50cyBp bmxpbmUuDQoNCldpdGggdGhhdCBJIGJlbGlldmUgYWxsIG91dHN0YW5kaW5nIGNvbW1lbnRzIGFy ZSByZXNvbHZlZCBpbiB2ZXJzaW9uIC0xNS4gTGV0IHVzIGtub3cgaWYgdGhlcmUgYXJlIGFueSBm dXJ0aGVyIGNvbW1lbnRzLg0KDQpCZXN0IHJlZ2FyZHMNCkfDtnJhbg0KDQoNCkZyb206IERhbmll bCBNaWdhdWx0IDxkYW5pZWwubWlnYXVsdEBlcmljc3Nvbi5jb208bWFpbHRvOmRhbmllbC5taWdh dWx0QGVyaWNzc29uLmNvbT4+DQpEYXRlOiBGcmlkYXksIDMxIEF1Z3VzdCAyMDE4IGF0IDIwOjI0 DQpUbzogInNlY2RpckBpZXRmLm9yZzxtYWlsdG86c2VjZGlyQGlldGYub3JnPiIgPHNlY2RpckBp ZXRmLm9yZzxtYWlsdG86c2VjZGlyQGlldGYub3JnPj4sIEfDtnJhbiBTZWxhbmRlciA8Z29yYW4u c2VsYW5kZXJAZXJpY3Nzb24uY29tPG1haWx0bzpnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20+ Pg0KQ2M6ICJkcmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5LmFsbEBpZXRmLm9yZzxtYWls dG86ZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eS5hbGxAaWV0Zi5vcmc+IiA8ZHJhZnQt aWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eS5hbGxAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYt Y29yZS1vYmplY3Qtc2VjdXJpdHkuYWxsQGlldGYub3JnPj4sICJpZXRmQGlldGYub3JnPG1haWx0 bzppZXRmQGlldGYub3JnPiIgPGlldGZAaWV0Zi5vcmc8bWFpbHRvOmlldGZAaWV0Zi5vcmc+Piwg ImNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+IiA8Y29yZUBpZXRmLm9yZzxtYWls dG86Y29yZUBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3NlY2Rpcl0gU2VjZGlyIGxhc3QgY2Fs bCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eS0xNA0KDQoNCkhpIEdv cmFuLA0KDQoNCg0KVGhhbmsgeW91IGZvciB5b3VyIGZlZWQgYmFja3MuIEkgYmVsaWV2ZSBhbGwg bXkgY29uY2VybnMgaGF2ZSBiZWVuIGFkZHJlc3NlZC4gWW91IGNhbiBzZWUgaW5saW5lIHRoZSBz cGVjaWZpYyByZXNwb25zZS4gPG1nbHQyPjwvbWdsdDI+DQoNCg0KDQotIC0gLQ0KDQoNCj4+DQoN Cj4+ICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSBPYmplY3QgU2VjdXJpdHkgZm9yIENvbnN0 cmFpbmVkIFJFU1RmdWwNCg0KPj4gICBFbnZpcm9ubWVudHMgKE9TQ09SRSkgc2VjdXJpdHkgcHJv dG9jb2wsIHByb3RlY3RpbmcgQ29BUCBhbmQgQ29BUC0NCg0KPj4gICBtYXBwYWJsZSBIVFRQIHJl cXVlc3RzIGFuZCByZXNwb25zZXMgZW5kLXRvLWVuZCBhY3Jvc3MgaW50ZXJtZWRpYXJ5DQoNCj4+ ICAgbm9kZXMgc3VjaCBhcyBDb0FQIGZvcndhcmQgcHJveGllcyBhbmQgY3Jvc3MtcHJvdG9jb2wg dHJhbnNsYXRvcnMNCg0KPj4gICBpbmN1ZGluZyBIVFRQLXRvLUNvQVAgcHJveGllcyBbUkZDODA3 NV0uICBJbiBhZGRpdGlvbiB0byB0aGUgY29yZQ0KDQo+PiAgIENvQVAgZmVhdHVyZXMgZGVmaW5l ZCBpbiBbUkZDNzI1Ml0sIE9TQ09SRSBzdXBwb3J0cyBPYnNlcnZlDQoNCj4+ICAgW1JGQzc2NDFd LCBCbG9jay13aXNlIFtSRkM3OTU5XSwgTm8tUmVzcG9uc2UgW1JGQzc5NjddLCBhbmQgUEFUQ0gg YW5kDQoNCj4+ICAgRkVUQ0ggW1JGQzgxMzJdLg0KDQo+PjxtZ2x0Pg0KDQo+Pk1heWJlIHRvbyBt YW55ICJhbmQiLg0KDQo+PjwvbWdsdD4NCg0KPg0KDQo+W0dTOl0gSSBzZWUgd2hhdCB5b3UgbWVh bi4gVGhlIHRpdGxlIG9mIFJGQyA4MTMyIGlzICJQQVRDSCBhbmQgRkVUQ0gNCg0KPm1ldGhvZHMg Zm9yIENvQVDigJ0uIFBlcmhhcHMgd2UganVzdCBjaGFuZ2UgdGhlIG9yZGVyIG9mIHRoZSBleGFt cGxlcyBpbiB0aGUNCg0KPmxhc3Qgc2VudGVuY2U6DQoNCiBORVcNCg0KPiJJbiBhZGRpdGlvbiB0 byB0aGUgY29yZSBDb0FQIGZlYXR1cmVzIGRlZmluZWQgaW4NCg0KPltSRkM3MjUyXSwgT1NDT1JF IHN1cHBvcnRzIE9ic2VydmUgW1JGQzc2NDFdLCBCbG9jay13aXNlIFtSRkM3OTU5XSwgUEFUQ0gN Cg0KPmFuZCBGRVRDSCBbUkZDODEzMl0sIGFuZCBOby1SZXNwb25zZSBbUkZDNzk2N10u4oCdPw0K DQo+DQoNCj4NCg0KPG1nbHQyPg0KDQpJIGFtIGZpbmUgZWl0aGVyIHdheXMuIEkgdGhpbmsgdGhl IHByb2JsZW0gaXMgdGhhdCB3ZSBhIGhhdmUgYSBsaXN0IG9mIGRpZmZlcmVudCBuYXR1cmUsIHVu bGVzcyB3ZSBhcmUgY29uc2lkZXJpbmcgdGhlIGRvY3VtZW50cyB0aGVtc2VsdmVzLiBJIHdvdWxk IHByb3Bvc2U6DQoNCk9TQ09SRSBzdXBwb3J0cyB0aGUgQmxvY2tXaXNlIFRyYW5zZmVydCBTaWdu YWxpbmcgIE9wdGlvbiBbUkZDNzk1OV0sIHRoZSBPYnNlcnZlZCBbUkZDNzY0MV0gYW5kIE5vLVJl c3BvbnNlIE9wdGlvbiwgW1JGQzc5NjddLCBhcyB3ZWxsIGFzIHRoZSBQQVRDSCBhbmQgRkVUQ0gg TWV0aG9kcyBbUkZDODEzMl0uDQoNCjwvbWdsdDI+DQoNCkdTOiBSZXBocmFzZWQgaW4g4oCTMTUu DQoNCg0KLSAtIC0NCg0KDQoNCj4+DQoNCj4+SSBiZWxpZXZlIHRoYXQgU2VuZGVyIFNlcXVlbmNl IE51bWJlciBhbHNvIG5lZWRzIHRvIGJlIHByZXNlbnQgaW4gdGhlDQoNCj4+UmVjaXBpZW50DQoN Cj4+Q29udGV4dCBpbiBvcmRlciB0byBpbXBsZW1lbnQgYW50aSByZXBsYXkgbWVjaGFuaXNtLg0K DQo+DQoNCj5bR1M6XSBUaGUgcmVwbGF5IHdpbmRvdyBpcyBhbHJlYWR5IHBhcnQgb2YgdGhlIFJl Y2lwaWVudCBDb250ZXh0LiBQZXJoYXBzDQoNCj5hIHJlZmVyZW5jZSB0byBTZWN0aW9uIDcuNCB3 b3VsZCBiZSBzdWZmaWNpZW50IHRvIG1ha2UgdGhlIGNvbm5lY3Rpb24NCg0KPmJldHdlZW4gcmVw bGF5IHdpbmRvdyBhbmQgc2VxdWVuY2UgbnVtYmVyPw0KDQo+DQoNCjxtZ2x0Mj4NCg0KR29vZCwg dGhlbiB5ZXMgYSByZWZlcmVuY2Ugd291bGQgYmUgdXNlZnVsbA0KDQo8L21nbHQyPg0KDQpHUzog SW5jbHVkZWQgaW4g4oCTMTUuDQoNCi0gLSAtDQoNCg0KPj4NCg0KPj5TZXF1ZW5jZSBOdW1iZXIg TWF5IGJlIGludGVycHJldGVkIGRpZmZlcmVudGx5LiBJIGJlbGlldmUgdGhhdA0KDQo+PmludGVy cHJldGF0aW9uDQoNCj4+c2hvdWxkIGFsc28gYmUgcGFydCBvZiB0aGUgQ29tbW9uIFNlY3VyaXR5 IENvbnRleHQuDQoNCj4NCg0KPltHUzpdIEkgZGlkbuKAmXQgdW5kZXJzdGFuZCB0aGlzIGNvbW1l bnQuDQoNCg0KDQo8bWdsdDI+DQoNClNlcXVlbmNlIE51bWJlciBhcmUgbm90IGFsd2F5cyBpbmNy ZW1lbnRlZC4gVGhpcyBpbnRlcnByZXRhdGlvbiBtYXkgaW1wYWN0IHRoZSBzZXNzaW9uLCBzbyB0 aGF0IG1heSBuZWVkIHRvIGJlIHNwZWNpZnkgaW4gdGhlIGZ1dHVyZSB3aGVuIGNvbnNpZGVyaW5n IG90aGVyIGludGVycHJldGF0aW9uIG9mIHRoZSBTU04uDQoNCjwvbWdsdDI+DQoNCkdTOiBUaGlz IHNwZWNpZmljYXRpb24gYXNzdW1lcyB0aGF0IFNTTiBpcyBpbmNyZW1lbnRlZCBhcyBzaG91bGQg YmUgY2xlYXIgZnJvbSB0aGUgcHJvY2Vzc2luZyAoc2VjdGlvbiA4KS4gSW4g4oCTMTUgd2UgYWRk ZWQgYSByZWZlcmVuY2UgdG8gSS1ELm1jZ3Jldy1pdi1nZW48aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHktMTUjcmVmLUktRC5tY2dyZXct aXYtZ2VuPi4NCg0KLSAtIC0NCg0KDQoNCj4+DQoNCj4+ICAgVGhlIGZvbGxvd2luZyBpbnB1dCBw YXJhbWV0ZXJzIE1BWSBiZSBwcmUtZXN0YWJsaXNoZWQuICBJbiBjYXNlIGFueQ0KDQo+PiAgIG9m IHRoZXNlIHBhcmFtZXRlcnMgaXMgbm90IHByZS1lc3RhYmxpc2hlZCwgdGhlIGRlZmF1bHQgdmFs dWUNCg0KPj4gICBpbmRpY2F0ZWQgYmVsb3cgaXMgdXNlZDoNCg0KPj4NCg0KPj4gICBvICBBRUFE IEFsZ29yaXRobQ0KDQo+Pg0KDQo+PiAgICAgICogIERlZmF1bHQgaXMgQUVTLUNDTS0xNi02NC0x MjggKENPU0UgYWxnb3JpdGhtIGVuY29kaW5nOiAxMCkNCg0KPj4NCg0KPj4gICBvICBNYXN0ZXIg U2FsdA0KDQo+Pg0KDQo+PiAgICAgICogIERlZmF1bHQgaXMgdGhlIGVtcHR5IGJ5dGUgc3RyaW5n DQoNCj4+PG1nbHQ+DQoNCj4+SSBiZWxpZXZlIGV4cGxpY2l0bHkgcHJvdmlkaW5nIHRoZSBzdHJp bmcgY291bGQgaGVscC4gVGhlcmUgaXMgYWx3YXlzIHRoZQ0KDQo+PmNvbmZ1c2lvbiB3aXRoICJc MCIgdmVyc3VzICIiLiA8L21nbHQ+DQoNCj4NCg0KPltHUzpdIE5vdGUgdGhhdCB0aGUgTWFzdGVy IFNhbHQgaXMgbmV2ZXIgc2VudCBhbmQgb25seSB1c2VkIGFzIHNhbHQgaW4NCg0KPkhLREYgKHNl Y3Rpb24gMi4yIG9mIFJGQyA1ODY5KS4gU2VjdGlvbiAzLjIuMSBkZXNjcmliZXMgaG93IHRoZSBl bXB0eQ0KDQo+c3RyaW5nIHNob3VsZCBiZSBpbnRlcnByZXRlZDoNCg0KPiJOb3RlIHRoYXQgW1JG QzU4NjldIHNwZWNpZmllcyB0aGF0IGlmIHRoZSBzYWx0IGlzIG5vdCBwcm92aWRlZCwgaXQgaXMg c2V0DQoNCj50byBhIHN0cmluZyBvZg0KDQo+emVyb3MuIEZvciBpbXBsZW1lbnRhdGlvbiBwdXJw b3Nlcywgbm90IHByb3ZpZGluZyB0aGUgc2FsdCBpcyB0aGUgc2FtZQ0KDQo+YXMgc2V0dGluZyB0 aGUgc2FsdCB0byB0aGUgZW1wdHkgYnl0ZSBzdHJpbmcuIE9TQ09SRSBzZXRzIHRoZSBzYWx0DQoN Cj5kZWZhdWx0IHZhbHVlIHRvIGVtcHR5IGJ5dGUgc3RyaW5nLCB3aGljaCBpbiBbUkZDNTg2OV0g aXMgY29udmVydGVkIHRvIGENCg0KPnN0cmluZyBvZiB6ZXJvZXMgKHNlZSBTZWN0aW9uIDIuMiBv ZiBbUkZDNTg2OV0pLiINCg0KPklzIHRoYXQgc3VmZmljaWVudGx5IGNsZWFyPw0KDQo+DQoNCj4N Cg0KPG1nbHQyPg0KDQpUaGlzIGlzIGZpbmUuIEl0IHNlZW1zIHRvIG1lIHRoYXQgZW1wdHkgc3Ry aW5nIGlzIOKAnOKAnSBoZXJlLiBJIHVzdWFsbHkgbGlrZSB0byBjaXRlIGV4cGxpY2l0bHkgdGhl IHN0cmluZyB0byBhdm9pZCBjb25mdXNpb24gYmV0d2VlbiDigJzigJ0gb3Ig4oCcXDDigJ0uIEkg YWdyZWUgdGhhdCBzYXlpbmcgemVybyBsZW5ndGggZG9lcyBub3QgaGVscCBtdWNoDQoNClRoZSBs YXRlc3Qgc2VudGVuY2UgaGFzIHR3byByZWZlcmVuY2UgdG8gUkZDNTg2OSwgbWF5YmUgb25lIHdv dWxkIGJlIHN1ZmZpY2llbnQuIElmIHBvc3NpYmxlLCBpdCBtaWdodCBiZSBiZXR0ZXIgdG8gc3Bl Y2lmeSB0aGUgbGVuZ3RoIG9mIHRoZSBzdHJpbmdzIG9mIHplcm9zIChIYXNoTGVuIGluIG91ciBj YXNlKQ0KDQo8L21nbHQyPg0KDQpHUzogT25lIG9mIHRoZSByZWZlcmVuY2VzIHRvIFJGQzU4Njkg cmVtb3ZlZCBpbiDigJMxNS4gVGhlIHByb2NlZHVyZSBmb3IgaGFuZGxpbmcgdGhlIGNhc2Ugb2Yg bm8gc2FsdCBwcm92aWRlZCBpcyBjbGVhcmx5IHNwZWNpZmllZCBpbiBzZWN0aW9uIDIuMiBvZiBS RkM1ODY5LCB3aGljaCB3ZSByZWZlcmVuY2UuIEkgd291bGQgcmF0aGVyIG5vdCBpbmNsdWRlIHRo ZSBkZXRhaWxzIGluIHRoaXMgc3BlY2lmaWNhdGlvbi4NCg0KLSAtIC0NCg0KDQo+DQoNCj4NCg0K PiB3aGljaCBkZWZpbmVzIGhvdyB0bw0KDQo+DQoNCj4+DQoNCj4+ICAgbyAgS2V5IERlcml2YXRp b24gRnVuY3Rpb24gKEtERikNCg0KPj4NCg0KPj4gICAgICAqICBEZWZhdWx0IGlzIEhLREYgU0hB LTI1Ng0KDQo+Pg0KDQo+PiAgIG8gIFJlcGxheSBXaW5kb3cgVHlwZSBhbmQgU2l6ZQ0KDQo+Pg0K DQo+PiAgICAgICogIERlZmF1bHQgaXMgRFRMUy10eXBlIHJlcGxheSBwcm90ZWN0aW9uIHdpdGgg YSB3aW5kb3cgc2l6ZSBvZiAzMg0KDQo+PiAgICAgICAgIFtSRkM2MzQ3XQ0KDQo+PjxtZ2x0Pg0K DQo+PlRoaXMgc2VjdGlvbiBzcGVjaWZpZXMgVHlwZSBhbmQgd2luZG93cyBmb3IgdGhlIGFudGkg cmVwbGF5IG1lY2hhbmlzbS4NCg0KPj5UaGlzIHdhcw0KDQo+PmRlc2NyaWJlZCBhcyBSZXBsYXkg V2luZG93cyBpbiB0aGUgY29udGV4dCBkZXNjcmlwdGlvbi4gPC9tZ2x0Pg0KDQo+DQoNCj5bR1M6 XSBJIGRpZG7igJl0IHVuZGVyc3RhbmQgdGhpcyBjb21tZW50LiBEbyB5b3UgbWVhbjoNCg0KPk9M RA0KDQo+UmVwbGF5IFdpbmRvdyBUeXBlIGFuZCBTaXplDQoNCj5ORVcNCg0KPlJlcGxheSBXaW5k b3cNCg0KPg0KDQo+DQoNCjxtZ2x0Mj4NCg0KSWYgZGlmZmVyZW50IG1lY2hhbmlzbSBjb3VsZCBi ZSB1c2VkLCBJIG1lYW50Og0KDQoqIFJlcGxheSBXaW5kb3cgVHlwZSA6IGRlZmF1bHQgdG8gRFRM UyAxLjINCg0KKiBSZXBsYXkgV2luZG93IFNpemUgKFBhcmFtZXRlcnMpOg0KDQo8L21nbHQ+DQoN Cg0KR1M6IFRoZSBkZWZhdWx0IHZhbHVlcyBsaXN0ZWQgaW4gc2VjdGlvbiAzLjIgd2VyZSBpbnRl bmRlZCB0byByZXBlYXQgdGhlIHBhcmFtZXRlcnMgbGlzdGVkIGluIHNlY3Rpb24gMy4xLiBJIHJl YWxpc2VkIGZyb20geW91ciBjb21tZW50IHRoYXQgIHRoYXQgIlJlcGxheSBXaW5kb3ciIGRldmlh dGVkIGZyb20gdGhpcyBjb252ZW50aW9uLiBXZSByZXNvbHZlZCB0aGF0IGluIOKAkzE1IGJ5IGNo YW5naW5nIHRoZSB0ZXJtIGluIHNlY3Rpb24gMy4yLiBZb3VyIHByb3Bvc2FsIHdvdWxkIGFsc28g cmVxdWlyZSBhIGNoYW5nZSB0byBzZWN0aW9uIDMuMS4gTm90ZSB0aGF0IHdlIGRvIG5vdCByZXN0 cmljdCB0byBEVExTIHR5cGUgcmVwbGF5IHByb3RlY3Rpb24sIHNvIHdlIHdvdWxkIHJhdGhlciBu b3QgaXRlbWlzZSB0aGUgc3ViLXBhcmFtZXRlcnMgb2YgdGhlIHJlcGxheSBwcm90ZWN0aW9uIG1l Y2hhbmlzbS4NCg0KLSAtIC0NCg0KDQo+DQoNCj5bR1M6XSBObywgdGhlIHJlc3RyaWN0aW9uIGNv bWVzIGZyb20gdGhlIG5vbmNlIGNvbnN0cnVjdGlvbiwgSSB3aWxsIGFkZCBhDQoNCj5yZWZlcmVu Y2UgdG8gU2VjdGlvbiA1LjIuDQoNCjxtZ2x0Mj4NCg0KVGhhbmtzLCBJIGJlbGlldmUgdGhhdCB3 b3VsZCBiZSB1c2VmdWwuDQoNCjwvbWdsdDI+DQoNCkdTOiBEb25lIGluIC0xNQ0KDQotIC0gLQ0K DQoNCj4NCg0KPj40LjEuMy41LjIuICBOb3RpZmljYXRpb25zDQoNCj4+DQoNCj4+ICAgSWYgdGhl IHNlcnZlciBhY2NlcHRzIGFuIE9ic2VydmUgcmVnaXN0cmF0aW9uLCBhIFBhcnRpYWwgSVYgTVVT VCBiZQ0KDQo+PiAgIGluY2x1ZGVkIGluIGFsbCBub3RpZmljYXRpb25zIChib3RoIHN1Y2Nlc3Nm dWwgYW5kIGVycm9yKSwgZXhjZXB0IGZvcg0KDQo+PiAgIHRoZSBmaXJzdCBvbmUgd2hlcmUgUGFy dGlhbCBJViBNQVkgYmUgb21pdHRlZC4gIFRvIHByb3RlY3QgYWdhaW5zdA0KDQo+PiAgIHJlcGxh eSwgdGhlIGNsaWVudCBTSEFMTCBtYWludGFpbiBhIE5vdGlmaWNhdGlvbiBOdW1iZXIgZm9yIGVh Y2gNCg0KPj4gICBPYnNlcnZhdGlvbiBpdCByZWdpc3RlcnMuICBUaGUgTm90aWZpY2F0aW9uIE51 bWJlciBpcyBhIG5vbi1uZWdhdGl2ZQ0KDQo+PiAgIGludGVnZXIgY29udGFpbmluZyB0aGUgbGFy Z2VzdCBQYXJ0aWFsIElWIG9mIHRoZSByZWNlaXZlZA0KDQo+PiAgIG5vdGlmaWNhdGlvbnMgZm9y IHRoZSBhc3NvY2lhdGVkIE9ic2VydmUgcmVnaXN0cmF0aW9uLiAgRnVydGhlcg0KDQo+PiAgIGRl dGFpbHMgb2YgcmVwbGF5IHByb3RlY3Rpb24gb2Ygbm90aWZpY2F0aW9ucyBhcmUgc3BlY2lmaWVk IGluDQoNCj4+ICAgU2VjdGlvbiA3LjQuMS4NCg0KPj4NCg0KPj4gICBGb3Igbm90aWZpY2F0aW9u cywgdGhlIElubmVyIE9ic2VydmUgdmFsdWUgTVVTVCBiZSBlbXB0eSAoc2VlDQoNCj4+ICAgU2Vj dGlvbiAzLjIgb2YgW1JGQzcyNTJdKS4gIFRoZSBPdXRlciBPYnNlcnZlIGluIGEgbm90aWZpY2F0 aW9uIGlzDQoNCj4+DQoNCj4+U2VsYW5kZXIsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBKYW51YXJ5 IDI3LCAyMDE5ICAgICAgICAgICAgICAgW1BhZ2UgMjBdDQoNCj4+DQoNCj4+SW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgICAgT1NDT1JFICAgICAgICAgICAgICAgICAgICAgICAgSnVseSAy MDE4DQoNCj4+DQoNCj4+ICAgbmVlZGVkIGZvciBpbnRlcm1lZGlhcnkgbm9kZXMgdG8gYWxsb3cg bXVsdGlwbGUgcmVzcG9uc2VzIHRvIG9uZQ0KDQo+PiAgIHJlcXVlc3QsIGFuZCBtYXkgYmUgc2V0 IHRvIHRoZSB2YWx1ZSBvZiBPYnNlcnZlIGluIHRoZSBvcmlnaW5hbCBDb0FQDQoNCj4+ICAgbWVz c2FnZS4gIFRoZSBjbGllbnQgcGVyZm9ybXMgb3JkZXJpbmcgb2Ygbm90aWZpY2F0aW9ucyBhbmQg cmVwbGF5DQoNCj4+ICAgcHJvdGVjdGlvbiBieSBjb21wYXJpbmcgdGhlaXIgUGFydGlhbCBJVnMg YW5kIFNIQUxMIGlnbm9yZSB0aGUgb3V0ZXINCg0KPj4gICBPYnNlcnZlIHZhbHVlLg0KDQo+Pg0K DQo+PiAgIElmIHRoZSBjbGllbnQgcmVjZWl2ZXMgYSByZXNwb25zZSB0byBhbiBPYnNlcnZlIHJl cXVlc3Qgd2l0aG91dCBhbg0KDQo+PiAgIElubmVyIE9ic2VydmUgb3B0aW9uLCB0aGVuIGl0IHZl cmlmaWVzIHRoZSByZXNwb25zZSBhcyBhIG5vbi1PYnNlcnZlDQoNCj4+ICAgcmVzcG9uc2UsIGFz IHNwZWNpZmllZCBpbiBTZWN0aW9uIDguNC4gIElmIHRoZSBjbGllbnQgcmVjZWl2ZXMgYQ0KDQo+ PiAgIHJlc3BvbnNlIHRvIGEgbm9uLU9ic2VydmUgcmVxdWVzdCB3aXRoIGFuIElubmVyIE9ic2Vy dmUgb3B0aW9uLCB0aGVuDQoNCj4+ICAgaXQgc3RvcHMgcHJvY2Vzc2luZyB0aGUgbWVzc2FnZSwg YXMgc3BlY2lmaWVkIGluIFNlY3Rpb24gOC40Lg0KDQo+Pg0KDQo+PiAgIEEgY2xpZW50IE1VU1Qg Y29uc2lkZXIgdGhlIG5vdGlmaWNhdGlvbiB3aXRoIHRoZSBoaWdoZXN0IFBhcnRpYWwgSVYNCg0K Pj4gICBhcyB0aGUgZnJlc2hlc3QsIHJlZ2FyZGxlc3Mgb2YgdGhlIG9yZGVyIG9mIGFycml2YWwu ICBJbiBvcmRlciB0bw0KDQo+PiAgIHN1cHBvcnQgZXhpc3RpbmcgT2JzZXJ2ZSBpbXBsZW1lbnRh dGlvbnMgdGhlIE9TQ09SRSBjbGllbnQNCg0KPj4gICBpbXBsZW1lbnRhdGlvbiBNQVkgc2V0IHRo ZSBPYnNlcnZlIHZhbHVlIHRvIHRoZSB0aHJlZSBsZWFzdA0KDQo+PiAgIHNpZ25pZmljYW50IGJ5 dGVzIG9mIHRoZSBQYXJ0aWFsIElWOyBzdWNoIGFuIGltcGxlbWVudGF0aW9uIG5lZWRzIHRvDQoN Cj4+ICAgbWFrZSBzdXJlIHRoYXQgdGhlIE9ic2VydmUgdmFsdWUgZm9yIGFuIG9ic2VydmUgbm90 aWZpY2F0aW9uIHdpdGhvdXQNCg0KPj4gICBQYXJ0aWFsIElWIGlzIHNtYWxsZXIgdGhhbiBhIG5v dGlmaWNhdGlvbiB3aXRoIFBhcnRpYWwgSVYuDQoNCj4+DQoNCj4+PG1nbHQ+DQoNCj4+VGhpcyBz ZWN0aW9uIGRpc2N1c3MgdGhlIGJlaGF2aW9yIHJlZ2FyZGluZyB0aGUgc2VxdWVuY2UgbnVtYmVy LiBXaGlsZQ0KDQo+PnRoZQ0KDQo+PnNlcXVlbmNlIG51bWJlciBhbmQgdGhlIHBhcnRpYWwgSVYg aGF2ZSB0aGUgc2FtZSB2YWx1ZSwgSSBhbSB3b25kZXJpbmcNCg0KPj5pZg0KDQo+Pml0DQoNCj4+ d291bGQgbm90IGJlIG1vcmUgYXBwcm9wcmlhdGVkIHRvIG1lbnRpb24gdGhlIHNlcXVlbmNlIG51 bWJlciB2YWx1ZSBpcw0KDQo+PnByb3ZpZGVkDQoNCj4+YnkgdGhlIHBhcnRpYWwgSVYsIGFuZCB0 aGVuIHVzZSB0aGUgc2VxdWVuY2UgbnVtYmVyIHZhcmlhYmxlIHRvIGRlc2NyaWJlDQoNCj4+YW50 aQ0KDQo+PnJlcGxheS4gPC9tZ2x0Pg0KDQo+DQoNCj4NCg0KPltHUzpdIFdlIGludGVuZGVkIHRv IHVzZSB0aGUgdGVybSDigJxwYXJ0aWFsIElW4oCdIHdoZW4gcmVmZXJyaW5nIHRvIHRoZQ0KDQo+ bnVtYmVyIGJlaW5nIHRyYW5zcG9ydGVkIGFuZCDigJxTU04iIHdoZW4gcmVmZXJyaW5nIHRvIHRo ZSBudW1iZXIgc3RvcmVkIGluDQoNCj50aGUgZW5kcG9pbnQuIEkgd2lsbCBnbyB0aHJvdWdoIHRo ZSBkb2N1bWVudCBhbmQgc2VlIHRoYXQgdGhpcyBjb252ZW50aW9uDQoNCj5pcyBrZXB0Lg0KDQo+ Pg0KDQo8bWdsdDI+DQoNCk1heWJlIHRoYXQgd291bGQgYmUgdXNlZnVsIHRvIG1lbnRpb24gdGhp cyBjb252ZW50aW9uDQoNCjwvbWdsdDI+DQoNCg0KDQpHUzogSeKAmW0gbm90IHN1cmUgZ29pbmcg aW50byB0aGlzIGRpc3RpbmN0aW9uIGlzIG5lY2Vzc2FyeS4gV2UgYWxyZWFkeSBkZXNjcmliZSB0 aGUgcmVsYXRpb25zaGlwIGluIHNldmVyYWwgcGxhY2VzOg0KDQpTZWN0aW9uIDMuMToNCg0KIlNl bmRlciBTZXF1ZW5jZSBOdW1iZXIuICBOb24tbmVnYXRpdmUgaW50ZWdlciB1c2VkIGJ5IHRoZSBz ZW5kZXINCg0KICAgICAgdG8gZW51bWVyYXRlIHJlcXVlc3RzIGFuZCBjZXJ0YWluIHJlc3BvbnNl cywgZS5nLiAgT2JzZXJ2ZQ0KDQogICAgICBub3RpZmljYXRpb25zLiAgVXNlZCBhcyAnUGFydGlh bCBJVicgW1JGQzgxNTI8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzgxNTI+XSB0byBn ZW5lcmF0ZSB1bmlxdWUNCg0KICAgICAgQUVBRCBub25jZXMuIg0KDQpTZWN0aW9uIDU6DQoNCiIg VGhlICdQYXJ0aWFsIElWJyBwYXJhbWV0ZXIuICBUaGUgdmFsdWUgaXMgc2V0IHRvIHRoZSBTZW5k ZXIgU2VxdWVuY2UgTnVtYmVyLiINCg0KU2VjdGlvbiA3LjI6DQoNCiJQYXJ0aWFsIElWcyAod2hp Y2ggZW5jb2RlIHRoZSBTZW5kZXIgU2VxdWVuY2UgTnVtYmVycywgc2VlIFNlY3Rpb24gNTxodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eS0x NSNzZWN0aW9uLTU+KSINCg0KDQoNClNlY3Rpb24gNy40IChhZGRyZXNzaW5nIGFub3RoZXIgY29t bWVudCBvZiB5b3Vycyk6DQoNCiJQYXJ0aWFsIElWID0gU2VuZGVyIFNlcXVlbmNlIE51bWJlciIN CmFuZCBhbHNvIHNldmVyYWwgdGltZXMgaW4gdGhlIHByb2Nlc3NpbmcsIFNlY3Rpb24gOC4NCg0K DQotIC0gLQ0KDQoNCg0KPkQuNC4xLiAgQ29BUCBIZWFkZXIgRmllbGRzDQoNCj4NCg0KPiAgIG8g IFZlcnNpb24uICBUaGUgQ29BUCB2ZXJzaW9uIFtSRkM3MjUyXSBpcyBub3QgZXhwZWN0ZWQgdG8g YmUNCg0KPiAgICAgIHNlbnNpdGl2ZSB0byBkaXNjbG9zZS4gIEN1cnJlbnRseSB0aGVyZSBpcyBv bmx5IG9uZSBDb0FQIHZlcnNpb24NCg0KPiAgICAgIGRlZmluZWQuICBBIGNoYW5nZSBvZiB0aGlz IHBhcmFtZXRlciBpcyBwb3RlbnRpYWxseSBhIGRlbmlhbC1vZi0NCg0KPiAgICAgIHNlcnZpY2Ug YXR0YWNrLiAgRnV0dXJlIHZlcnNpb25zIG9mIENvQVAgbmVlZCB0byBhbmFseXplIGF0dGFja3MN Cg0KPiAgICAgIHRvIE9TQ09SRSBwcm90ZWN0ZWQgbWVzc2FnZXMgZHVlIHRvIGFuIGFkdmVyc2Fy eSBjaGFuZ2luZyB0aGUgQ29BUA0KDQo+ICAgICAgdmVyc2lvbi4NCg0KPg0KDQo+ICAgbyAgVG9r ZW4vVG9rZW4gTGVuZ3RoLiAgVGhlIFRva2VuIGZpZWxkIGlzIGEgY2xpZW50LWxvY2FsIGlkZW50 aWZpZXINCg0KPiAgICAgIGZvciBkaWZmZXJlbnRpYXRpbmcgYmV0d2VlbiBjb25jdXJyZW50IHJl cXVlc3RzIFtSRkM3MjUyXS4gIEFuDQoNCj4gICAgICBlYXZlc2Ryb3BwZXIgcmVhZGluZyB0aGUg dG9rZW4gY2FuIG1hdGNoIHJlcXVlc3RzIHRvIHJlc3BvbnNlcw0KDQo+ICAgICAgd2hpY2ggY2Fu IGJlIHVzZWQgaW4gdHJhZmZpYyBhbmFseXNpcy4gIEluIHBhcnRpY3VsYXIgdGhpcyBpcyB0cnVl DQoNCj4gICAgICBmb3Igbm90aWZpY2F0aW9ucywgd2hlcmUgbXVsdGlwbGUgcmVzcG9uc2VzIGFy ZSBtYXRjaGVkIHdpdGggb25lDQoNCj4gICAgICByZXF1ZXN0LiAgQ29BUCBwcm94aWVzIGFyZSBh bGxvd2VkIHRvIGNoYW5nZSBUb2tlbiBhbmQgVG9rZW4NCg0KPiAgICAgIExlbmd0aCBiZXR3ZWVu IFVEUCBob3BzLiAgSG93ZXZlciwgbW9kaWZpY2F0aW9ucyBvZiBUb2tlbiBhbmQNCg0KPiAgICAg IFRva2VuIExlbmd0aCBkdXJpbmcgYSBVRFAgaG9wIG1heSBiZWNvbWUgYSBkZW5pYWwtb2Ytc2Vy dmljZQ0KDQo+DQoNCj5TZWxhbmRlciwgZXQgYWwuICAgICAgICBFeHBpcmVzIEphbnVhcnkgMjcs IDIwMTkgICAgICAgICAgICAgICBbUGFnZSA3Nl0NCg0KPg0KDQo+SW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgICAgICAgT1NDT1JFICAgICAgICAgICAgICAgICAgICAgICAgSnVseSAyMDE4DQoN Cj4NCg0KPiAgICAgIGF0dGFjaywgc2luY2UgaXQgbWF5IHByZXZlbnQgdGhlIGNsaWVudCB0byBp ZGVudGlmeSB0byB3aGljaA0KDQo+ICAgICAgcmVxdWVzdCB0aGUgcmVzcG9uc2UgYmVsb25ncyBv ciB0byBmaW5kIHRoZSBjb3JyZWN0IGluZm9ybWF0aW9uIHRvDQoNCj4gICAgICB2ZXJpZnkgaW50 ZWdyaXR5IG9mIHRoZSByZXNwb25zZS4NCg0KPjxtZ2x0Pg0KDQo+SSBhbSByZWFkaW5nIHRoZSB0 ZXh0IGFzLiBXaGVuIHRoZSBhdHRhY2tlciBpcyBvbi1wYXRoLCBhIGxvbmcgVG9rZW4gZG9lcw0K DQo+bm90DQoNCj5wcmV2ZW50cyB0aGUgYXR0YWNrIGJhc2VkIG9uIGEgc3Bvb2ZlZCByZXNwb25z ZS4gSG93ZXZlciwgZm9yIGFuIGF0dGFja2VyDQoNCj50aGF0DQoNCj5pcyBub3Qgb24gcGF0aCwg dGhlIGF0dGFja2VyIG5lZWRzIHRvIGd1ZXNzIHRoZSBUb2tlbiwgYW5kIHRoaXMgY2FuIGJlDQoN Cj5taXRpZ2F0ZWQgKHBhcnRpYWxseSkgYnkgaW5jcmVhc2luZyB0aGUgVG9rZW4gc2l6ZS4gIE5v dGUgdGhhdCBpbiB0aGUNCg0KPmxhdGVzdA0KDQo+Y2FzZSwgYSBsb25nIFRva2VuIHNob3VsZCBu b3QgYmUgc2VlbiBhcyBhIHJlcGxhY2VtZW50IGZvciBjcnlwdG9ncmFwaGljDQoNCj5wcm90ZWN0 aW9uIG9mIHRoZSBtZXNzYWdlLiA8L21nbHQ+DQoNCj4NCg0KPltHUzpdIFRoZXJlIHNlZW1zIHRv IGJlIGEgbWlzdW5kZXJzdGFuZGluZyBzb21ld2hlcmUuIFRoZXJlIGlzIG5vIG5lZWQNCg0KPmZv ciBhbnlvbmUgdG8g4oCcZ3Vlc3MgdGhlIFRva2Vu4oCdIHNpbmNlIGl0IGlzIG5vdCBlbmNyeXB0 ZWQuIFRoZXJlIGlzDQoNCj5ub3RoaW5nIGhpbnRlZCBhYm91dCBUb2tlbiBiZWluZyBhIOKAnHJl cGxhY2VtZW50IGZvciBjcnlwdG/igJ0sIHNvIEkgZG9u4oCZdA0KDQo+dW5kZXJzdGFuZCB3aHkg YW55b25lIHdvdWxkIGJlIGxlYWQgdG8gdGhpbmsgdGhhdC4gVG9rZW4gbGVuZ3RoIGlzDQoNCj5t ZW50aW9uZWQgdHdpY2U7IGluIHRoZSBuZXh0IHRvIGxhc3Qgc2VudGVuY2UgLSBtZW50aW9uaW5n IHRoYXQgQ29BUA0KDQo+cHJveGllcyAobGVnaXRpbWF0ZWx5KSBtYXkgY2hhbmdlIFRva2VuIGxl bmd0aDsgYW5kIGluIHRoZSBsYXN0IHNlbnRlbmNlDQoNCj4tIGRlc2NyaWJpbmcgdGhhdCBhbiBv bi1wYXRoIGF0dGFja2VyIG1heSBtb2RpZnkgdGhlIFRva2VuIExlbmd0aCB3aGljaA0KDQo+ZWl0 aGVyIGNyZWF0ZWQgbWlzbWF0Y2ggYmV0d2VlbiByZXF1ZXN0IGFuZCByZXNwb25zZSBvciBubyBt YXRjaCBhdCBhbGwsDQoNCj53aGljaCBhcmUgYm90aCBkZW5pYWwgb2Ygc2VydmljZS4gSXMgaXQg Y2xlYXJlciBpbiB0aGUgZm9sbG93aW5nIHdheT8NCg0KTkVXDQoNCj5vIFRva2VuL1Rva2VuIExl bmd0aC4gVGhlIFRva2VuIGZpZWxkIGlzIGEgY2xpZW50LWxvY2FsIGlkZW50aWZpZXINCg0KPmZv ciBkaWZmZXJlbnRpYXRpbmcgYmV0d2VlbiBjb25jdXJyZW50IHJlcXVlc3RzIFtSRkM3MjUyXS4N Cg0KPg0KDQo+DQoNCjxtZ2x0Mj4NCg0KV2hhdCBJIHdhcyB0cnlpbmcgdG8gc2F5IGlzIHRoYXQg aWYgeW91IHdhbnQgdG8gc3Bvb2YgYSByZXNwb25zZSAoIGxpa2UgaW4gRE5TKSBhbmQgeW91IGFy ZSBub3Qgb24gcGF0aCwgeW91IG5lZWQgdG8gZ3Vlc3MgdGhlIFRva2VuLiBJbiB0aGF0IHNlbnNl LCB0aGUgbG9uZ2VyIHRoZSBzYWZlci4gSG93ZXZlciwgYXMgZm9yIEROUywgd2Ugc2hvdWxkIG5v dCByZWx5IG9uIHRoaXMuDQoNCjwvbWdsdDI+DQoNCkdTOiBSaWdodCwgd2UgZG9u4oCZdCByZWx5 IG9uIHRoZSBsZW5ndGggb2YgdG9rZW4gZm9yIHNlY3VyaXR5Lg0KDQoNCg0K --_000_6029df3f46e647c38a38b8be969c072bericssoncom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRp di5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUt bmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7fQ0Kc3Bhbi5IVE1MUHJlZm9y bWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRl ZCI7DQoJZm9udC1mYW1pbHk6IkNvbnNvbGFzIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyNA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgR29yYW4s IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSBjb25jZXJucyBoYXZlIGJlZW4gYWRkcmVzc2Vk LiBUaGFua3MgZm9yIHRoZSBleHBsYW5hdGlvbnMuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ WW91cnMsIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGFuaWVsPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5G cm9tOjwvYj4gR8O2cmFuIFNlbGFuZGVyIDxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBTZXB0 ZW1iZXIgMDQsIDIwMTggMzo1MyBBTTxicj4NCjxiPlRvOjwvYj4gRGFuaWVsIE1pZ2F1bHQgJmx0 O2RhbmllbC5taWdhdWx0QGVyaWNzc29uLmNvbSZndDs7IHNlY2RpckBpZXRmLm9yZzxicj4NCjxi PkNjOjwvYj4gZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eS5hbGxAaWV0Zi5vcmc7IGll dGZAaWV0Zi5vcmc7IGNvcmVAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzZWNk aXJdIFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2Vj dXJpdHktMTQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+SGkgRGFuaWVsLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+VGhhbmtzIGZvciB5b3VyIHJlc3Bv bnNlcy4gRGV0YWlsZWQgY29tbWVudHMgaW5saW5lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtjb2xvcjpibGFjayI+V2l0aCB0aGF0IEkgYmVsaWV2ZSBhbGwgb3V0c3RhbmRpbmcgY29tbWVu dHMgYXJlIHJlc29sdmVkIGluIHZlcnNpb24gLTE1LiBMZXQgdXMga25vdyBpZiB0aGVyZSBhcmUg YW55IGZ1cnRoZXIgY29tbWVudHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJs YWNrIj5CZXN0IHJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpi bGFjayI+R8O2cmFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RnJv bTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkRhbmllbCBNaWdhdWx0ICZs dDs8YSBocmVmPSJtYWlsdG86ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nzb24uY29tIj5kYW5pZWwubWln YXVsdEBlcmljc3Nvbi5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXksIDMxIEF1 Z3VzdCAyMDE4IGF0IDIwOjI0PGJyPg0KPGI+VG86IDwvYj4mcXVvdDs8YSBocmVmPSJtYWlsdG86 c2VjZGlyQGlldGYub3JnIj5zZWNkaXJAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86c2VjZGlyQGlldGYub3JnIj5zZWNkaXJAaWV0Zi5vcmc8L2E+Jmd0OywgR8O2cmFuIFNl bGFuZGVyICZsdDs8YSBocmVmPSJtYWlsdG86Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tIj5n b3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7 PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHkuYWxsQGlldGYu b3JnIj5kcmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5LmFsbEBpZXRmLm9yZzwvYT4mcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5LmFs bEBpZXRmLm9yZyI+ZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eS5hbGxAaWV0Zi5vcmc8 L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmlldGZAaWV0Zi5vcmciPmlldGZAaWV0Zi5v cmc8L2E+JnF1b3Q7DQogJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmQGlldGYub3JnIj5pZXRmQGll dGYub3JnPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpjb3JlQGlldGYub3JnIj5jb3Jl QGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmciPmNv cmVAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW3NlY2Rpcl0gU2Vj ZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eS0x NDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4w cHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi1yaWdodDowaW4iIGlkPSJNQUNfT1VUTE9PS19B VFRSSUJVVElPTl9CTE9DS1FVT1RFIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5IaSBHb3JhbiwgPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoYW5rIHlvdSBmb3IgeW91ciBmZWVkIGJhY2tzLiBJ IGJlbGlldmUgYWxsIG15IGNvbmNlcm5zIGhhdmUgYmVlbiBhZGRyZXNzZWQuIFlvdSBjYW4gc2Vl IGlubGluZSB0aGUgc3BlY2lmaWMgcmVzcG9uc2UuICZsdDttZ2x0MiZndDsmbHQ7L21nbHQyJmd0 OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4tIC0gLTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzowaW4g MGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXJpZ2h0OjBpbiIgaWQ9Ik1B Q19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyBUaGlzIGRvY3VtZW50IGRlZmlu ZXMgdGhlIE9iamVjdCBTZWN1cml0eSBmb3IgQ29uc3RyYWluZWQgUkVTVGZ1bDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jmd0OyZndDsmbmJzcDsmbmJzcDsgRW52aXJvbm1lbnRzIChPU0NPUkUpIHNlY3VyaXR5 IHByb3RvY29sLCBwcm90ZWN0aW5nIENvQVAgYW5kIENvQVAtPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyBtYXBwYWJsZSBIVFRQIHJlcXVlc3RzIGFuZCByZXNwb25zZXMgZW5k LXRvLWVuZCBhY3Jvc3MgaW50ZXJtZWRpYXJ5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZuYnNw OyZuYnNwOyBub2RlcyBzdWNoIGFzIENvQVAgZm9yd2FyZCBwcm94aWVzIGFuZCBjcm9zcy1wcm90 b2NvbCB0cmFuc2xhdG9yczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDsmbmJzcDsmbmJzcDsgaW5j dWRpbmcgSFRUUC10by1Db0FQIHByb3hpZXMgW1JGQzgwNzVdLiZuYnNwOyBJbiBhZGRpdGlvbiB0 byB0aGUgY29yZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDsmbmJzcDsmbmJzcDsgQ29BUCBmZWF0 dXJlcyBkZWZpbmVkIGluIFtSRkM3MjUyXSwgT1NDT1JFIHN1cHBvcnRzIE9ic2VydmU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7IFtSRkM3NjQxXSwgQmxvY2std2lzZSBbUkZD Nzk1OV0sIE5vLVJlc3BvbnNlIFtSRkM3OTY3XSwgYW5kIFBBVENIIGFuZDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jmd0OyZndDsmbmJzcDsmbmJzcDsgRkVUQ0ggW1JGQzgxMzJdLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jmd0OyZndDsmbHQ7bWdsdCZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7TWF5YmUgdG9vIG1h bnkgJnF1b3Q7YW5kJnF1b3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDsmbHQ7L21nbHQmZ3Q7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7W0dTOl0gSSBz ZWUgd2hhdCB5b3UgbWVhbi4gVGhlIHRpdGxlIG9mIFJGQyA4MTMyIGlzICZxdW90O1BBVENIIGFu ZCBGRVRDSDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0O21ldGhvZHMgZm9yIENvQVDigJ0uIFBlcmhhcHMg d2UganVzdCBjaGFuZ2UgdGhlIG9yZGVyIG9mIHRoZSBleGFtcGxlcyBpbiB0aGU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZndDtsYXN0IHNlbnRlbmNlOiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwO05FVzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jmd0OyZxdW90O0luIGFkZGl0aW9uIHRvIHRoZSBjb3JlIENvQVAgZmVhdHVy ZXMgZGVmaW5lZCBpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0O1tSRkM3MjUyXSwgT1NDT1JFIHN1cHBv cnRzIE9ic2VydmUgW1JGQzc2NDFdLCBCbG9jay13aXNlIFtSRkM3OTU5XSwgUEFUQ0g8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZndDthbmQgRkVUQ0ggW1JGQzgxMzJdLCBhbmQgTm8tUmVzcG9uc2UgW1JGQzc5 NjddLuKAnT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsm bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBzdHlsZT0iY29sb3I6cmVkIj4mbHQ7bWdsdDImZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+SSBhbSBmaW5lIGVpdGhlciB3YXlzLiBJIHRoaW5rIHRo ZSBwcm9ibGVtIGlzIHRoYXQgd2UgYSBoYXZlIGEgbGlzdCBvZiBkaWZmZXJlbnQgbmF0dXJlLCB1 bmxlc3Mgd2UgYXJlIGNvbnNpZGVyaW5nIHRoZSBkb2N1bWVudHMgdGhlbXNlbHZlcy4gSSB3b3Vs ZCBwcm9wb3NlOjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQi Pk9TQ09SRSBzdXBwb3J0cyB0aGUgQmxvY2tXaXNlIFRyYW5zZmVydCBTaWduYWxpbmcmbmJzcDsg T3B0aW9uIFtSRkM3OTU5XSwgdGhlIE9ic2VydmVkIFtSRkM3NjQxXSBhbmQgTm8tUmVzcG9uc2Ug T3B0aW9uLCBbUkZDNzk2N10sIGFzIHdlbGwgYXMgdGhlIFBBVENIIGFuZCBGRVRDSCBNZXRob2Rz IFtSRkM4MTMyXS4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpy ZWQiPiZsdDsvbWdsdDImZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2si PkdTOiBSZXBocmFzZWQgaW4g4oCTMTUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si Pi0gLSAtPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi1yaWdodDowaW4i IGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0O0kg YmVsaWV2ZSB0aGF0IFNlbmRlciBTZXF1ZW5jZSBOdW1iZXIgYWxzbyBuZWVkcyB0byBiZSBwcmVz ZW50IGluIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDtSZWNpcGllbnQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZndDsmZ3Q7Q29udGV4dCBpbiBvcmRlciB0byBpbXBsZW1lbnQgYW50aSByZXBsYXkgbWVj aGFuaXNtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0O1tH UzpdIFRoZSByZXBsYXkgd2luZG93IGlzIGFscmVhZHkgcGFydCBvZiB0aGUgUmVjaXBpZW50IENv bnRleHQuIFBlcmhhcHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDthIHJlZmVyZW5jZSB0byBTZWN0aW9u IDcuNCB3b3VsZCBiZSBzdWZmaWNpZW50IHRvIG1ha2UgdGhlIGNvbm5lY3Rpb248bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZndDtiZXR3ZWVuIHJlcGxheSB3aW5kb3cgYW5kIHNlcXVlbmNlIG51bWJlcj88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj4mbHQ7bWdsdDImZ3Q7PC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+R29vZCwgdGhlbiB5ZXMg YSByZWZlcmVuY2Ugd291bGQgYmUgdXNlZnVsbDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IHN0eWxlPSJjb2xvcjpyZWQiPiZsdDsvbWdsdDImZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Y29sb3I6YmxhY2siPkdTOiBJbmNsdWRlZCBpbiDigJMxNS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Y29sb3I6YmxhY2siPi0gLSAtPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41 cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXJp Z2h0OjBpbiIgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZndDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0O1NlcXVlbmNlIE51bWJlciBN YXkgYmUgaW50ZXJwcmV0ZWQgZGlmZmVyZW50bHkuIEkgYmVsaWV2ZSB0aGF0PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mZ3Q7Jmd0O2ludGVycHJldGF0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0O3Nob3Vs ZCBhbHNvIGJlIHBhcnQgb2YgdGhlIENvbW1vbiBTZWN1cml0eSBDb250ZXh0LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0O1tHUzpdIEkgZGlkbuKAmXQgdW5k ZXJzdGFuZCB0aGlzIGNvbW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVk Ij4mbHQ7bWdsdDImZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9y OnJlZCI+U2VxdWVuY2UgTnVtYmVyIGFyZSBub3QgYWx3YXlzIGluY3JlbWVudGVkLiBUaGlzIGlu dGVycHJldGF0aW9uIG1heSBpbXBhY3QgdGhlIHNlc3Npb24sIHNvIHRoYXQgbWF5IG5lZWQgdG8g YmUgc3BlY2lmeSBpbiB0aGUgZnV0dXJlIHdoZW4gY29uc2lkZXJpbmcgb3RoZXIgaW50ZXJwcmV0 YXRpb24gb2YgdGhlIFNTTi48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29s b3I6cmVkIj4mbHQ7L21nbHQyJmd0Ozwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJs YWNrIj5HUzogVGhpcyBzcGVjaWZpY2F0aW9uIGFzc3VtZXMgdGhhdCBTU04gaXMgaW5jcmVtZW50 ZWQgYXMgc2hvdWxkIGJlIGNsZWFyIGZyb20gdGhlIHByb2Nlc3NpbmcgKHNlY3Rpb24gOCkuIElu IOKAkzE1IHdlIGFkZGVkIGEgcmVmZXJlbmNlIHRvJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHktMTUjcmVmLUkt RC5tY2dyZXctaXYtZ2VuIiB0aXRsZT0iJnF1b3Q7R2VuZXJhdGlvbiBvZiBEZXRlcm1pbmlzdGlj IEluaXRpYWxpemF0aW9uIFZlY3RvcnMgKElWcykgYW5kIE5vbmNlcyZxdW90OyI+SS1ELm1jZ3Jl dy1pdi1nZW48L2E+LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+LSAt IC08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi1yaWdodDowaW4iIGlkPSJNQUNfT1VU TE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZndDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyBU aGUgZm9sbG93aW5nIGlucHV0IHBhcmFtZXRlcnMgTUFZIGJlIHByZS1lc3RhYmxpc2hlZC4mbmJz cDsgSW4gY2FzZSBhbnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7IG9mIHRo ZXNlIHBhcmFtZXRlcnMgaXMgbm90IHByZS1lc3RhYmxpc2hlZCwgdGhlIGRlZmF1bHQgdmFsdWU8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7IGluZGljYXRlZCBiZWxvdyBpcyB1 c2VkOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsm Z3Q7Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgQUVBRCBBbGdvcml0aG08bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZn dDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAqJm5ic3A7IERlZmF1bHQgaXMgQUVTLUNDTS0xNi02NC0xMjggKENPU0UgYWxn b3JpdGhtIGVuY29kaW5nOiAxMCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyBvJm5ic3A7IE1hc3RlciBTYWx0PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4mZ3Q7Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKiZuYnNwOyBEZWZhdWx0IGlzIHRoZSBlbXB0eSBieXRl IHN0cmluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDsmbHQ7bWdsdCZndDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZndDsmZ3Q7SSBiZWxpZXZlIGV4cGxpY2l0bHkgcHJvdmlkaW5nIHRoZSBzdHJpbmcgY291 bGQgaGVscC4gVGhlcmUgaXMgYWx3YXlzIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDtjb25m dXNpb24gd2l0aCAmcXVvdDtcMCZxdW90OyB2ZXJzdXMgJnF1b3Q7JnF1b3Q7LiAmbHQ7L21nbHQm Z3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7W0dTOl0g Tm90ZSB0aGF0IHRoZSBNYXN0ZXIgU2FsdCBpcyBuZXZlciBzZW50IGFuZCBvbmx5IHVzZWQgYXMg c2FsdCBpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0O0hLREYgKHNlY3Rpb24gMi4yIG9mIFJGQyA1ODY5 KS4gU2VjdGlvbiAzLjIuMSBkZXNjcmliZXMgaG93IHRoZSBlbXB0eTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jmd0O3N0cmluZyBzaG91bGQgYmUgaW50ZXJwcmV0ZWQ6PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7JnF1 b3Q7Tm90ZSB0aGF0IFtSRkM1ODY5XSBzcGVjaWZpZXMgdGhhdCBpZiB0aGUgc2FsdCBpcyBub3Qg cHJvdmlkZWQsIGl0IGlzIHNldDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0O3RvIGEgc3RyaW5nIG9mPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mZ3Q7emVyb3MuIEZvciBpbXBsZW1lbnRhdGlvbiBwdXJwb3Nlcywgbm90 IHByb3ZpZGluZyB0aGUgc2FsdCBpcyB0aGUgc2FtZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0O2FzIHNl dHRpbmcgdGhlIHNhbHQgdG8gdGhlIGVtcHR5IGJ5dGUgc3RyaW5nLiBPU0NPUkUgc2V0cyB0aGUg c2FsdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0O2RlZmF1bHQgdmFsdWUgdG8gZW1wdHkgYnl0ZSBzdHJp bmcsIHdoaWNoIGluIFtSRkM1ODY5XSBpcyBjb252ZXJ0ZWQgdG8gYTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jmd0O3N0cmluZyBvZiB6ZXJvZXMgKHNlZSBTZWN0aW9uIDIuMiBvZiBbUkZDNTg2OV0pLiZxdW90 OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jmd0O0lzIHRoYXQgc3VmZmljaWVudGx5IGNsZWFyPzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpy ZWQiPiZsdDttZ2x0MiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29s b3I6cmVkIj5UaGlzIGlzIGZpbmUuIEl0IHNlZW1zIHRvIG1lIHRoYXQgZW1wdHkgc3RyaW5nIGlz IOKAnOKAnSBoZXJlLiBJIHVzdWFsbHkgbGlrZSB0byBjaXRlIGV4cGxpY2l0bHkgdGhlIHN0cmlu ZyB0byBhdm9pZCBjb25mdXNpb24gYmV0d2VlbiDigJzigJ0gb3Ig4oCcXDDigJ0uIEkgYWdyZWUg dGhhdCBzYXlpbmcgemVybyBsZW5ndGggZG9lcyBub3QgaGVscCBtdWNoPC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+VGhlIGxhdGVzdCBzZW50ZW5jZSBoYXMg dHdvIHJlZmVyZW5jZSB0byBSRkM1ODY5LCBtYXliZSBvbmUgd291bGQgYmUgc3VmZmljaWVudC4g SWYgcG9zc2libGUsIGl0IG1pZ2h0IGJlIGJldHRlciB0byBzcGVjaWZ5IHRoZSBsZW5ndGggb2Yg dGhlIHN0cmluZ3Mgb2YgemVyb3MgKEhhc2hMZW4gaW4gb3VyIGNhc2UpDQo8L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj4mbHQ7L21nbHQyJmd0Ozwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5HUzogT25lIG9mIHRoZSByZWZlcmVuY2Vz IHRvIFJGQzU4NjkgcmVtb3ZlZCBpbiDigJMxNS4gVGhlIHByb2NlZHVyZSBmb3IgaGFuZGxpbmcg dGhlIGNhc2Ugb2Ygbm8gc2FsdCBwcm92aWRlZCBpcyBjbGVhcmx5IHNwZWNpZmllZCBpbiBzZWN0 aW9uIDIuMiBvZiBSRkM1ODY5LCB3aGljaCB3ZSByZWZlcmVuY2UuIEkgd291bGQgcmF0aGVyIG5v dA0KIGluY2x1ZGUgdGhlIGRldGFpbHMgaW4gdGhpcyBzcGVjaWZpY2F0aW9uLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+LSAtIC08bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1 QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDtt YXJnaW4tcmlnaHQ6MGluIiBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jmd0OyB3aGljaCBkZWZpbmVzIGhvdyB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgS2V5IERlcml2YXRpb24gRnVuY3Rpb24gKEtERik8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZndDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqJm5ic3A7IERlZmF1bHQgaXMgSEtERiBTSEEtMjU2PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDsmbmJz cDsmbmJzcDsgbyZuYnNwOyBSZXBsYXkgV2luZG93IFR5cGUgYW5kIFNpemU8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZndDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAqJm5ic3A7IERlZmF1bHQgaXMgRFRMUy10eXBlIHJlcGxheSBwcm90 ZWN0aW9uIHdpdGggYSB3aW5kb3cgc2l6ZSBvZiAzMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgW1JGQzYzNDdd PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZsdDttZ2x0Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0 OyZndDtUaGlzIHNlY3Rpb24gc3BlY2lmaWVzIFR5cGUgYW5kIHdpbmRvd3MgZm9yIHRoZSBhbnRp IHJlcGxheSBtZWNoYW5pc20uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0O1RoaXMgd2FzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4mZ3Q7Jmd0O2Rlc2NyaWJlZCBhcyBSZXBsYXkgV2luZG93cyBpbiB0aGUgY29u dGV4dCBkZXNjcmlwdGlvbi4gJmx0Oy9tZ2x0Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jmd0O1tHUzpdIEkgZGlkbuKAmXQgdW5kZXJzdGFuZCB0aGlzIGNv bW1lbnQuIERvIHlvdSBtZWFuOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0O09MRDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jmd0O1JlcGxheSBXaW5kb3cgVHlwZSBhbmQgU2l6ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0O05F VzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jmd0O1JlcGxheSBXaW5kb3c8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsm bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj4mbHQ7bWdsdDIm Z3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+SWYgZGlm ZmVyZW50IG1lY2hhbmlzbSBjb3VsZCBiZSB1c2VkLCBJIG1lYW50Ojwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPiogUmVwbGF5IFdpbmRvdyBUeXBlIDogZGVm YXVsdCB0byBEVExTIDEuMjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xv cjpyZWQiPiogUmVwbGF5IFdpbmRvdyBTaXplIChQYXJhbWV0ZXJzKToNCjwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPiZsdDsvbWdsdCZndDs8L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPkdTOiBUaGUgZGVmYXVsdCB2YWx1ZXMgbGlzdGVkIGlu IHNlY3Rpb24gMy4yIHdlcmUgaW50ZW5kZWQgdG8gcmVwZWF0IHRoZSBwYXJhbWV0ZXJzIGxpc3Rl ZCBpbiBzZWN0aW9uIDMuMS4gSSByZWFsaXNlZCBmcm9tIHlvdXIgY29tbWVudCB0aGF0ICZuYnNw O3RoYXQgJnF1b3Q7UmVwbGF5IFdpbmRvdyZxdW90OyBkZXZpYXRlZCBmcm9tIHRoaXMgY29udmVu dGlvbi4NCiBXZSByZXNvbHZlZCB0aGF0IGluIOKAkzE1IGJ5IGNoYW5naW5nIHRoZSB0ZXJtIGlu IHNlY3Rpb24gMy4yLiBZb3VyIHByb3Bvc2FsIHdvdWxkIGFsc28gcmVxdWlyZSBhIGNoYW5nZSB0 byBzZWN0aW9uIDMuMS4gTm90ZSB0aGF0IHdlIGRvIG5vdCByZXN0cmljdCB0byBEVExTIHR5cGUg cmVwbGF5IHByb3RlY3Rpb24sIHNvIHdlIHdvdWxkIHJhdGhlciBub3QgaXRlbWlzZSB0aGUgc3Vi LXBhcmFtZXRlcnMgb2YgdGhlIHJlcGxheSBwcm90ZWN0aW9uIG1lY2hhbmlzbS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPi0gLSAtPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNC NUM0REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7 bWFyZ2luLXJpZ2h0OjBpbiIgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUi Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDtbR1M6XSBObywgdGhlIHJl c3RyaWN0aW9uIGNvbWVzIGZyb20gdGhlIG5vbmNlIGNvbnN0cnVjdGlvbiwgSSB3aWxsIGFkZCBh DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZndDtyZWZlcmVuY2UgdG8gU2VjdGlvbiA1LjIuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9y OnJlZCI+Jmx0O21nbHQyJmd0Ozwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJj b2xvcjpyZWQiPlRoYW5rcywgSSBiZWxpZXZlIHRoYXQgd291bGQgYmUgdXNlZnVsLjwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPiZsdDsvbWdsdDImZ3Q7PC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPkdTOiBEb25lIGluIC0xNTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+LSAtIC08bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMu NzVwdDttYXJnaW4tcmlnaHQ6MGluIiBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tR VU9URSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDs0LjEuMy41 LjIuJm5ic3A7IE5vdGlmaWNhdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyBJZiB0aGUgc2VydmVyIGFjY2VwdHMg YW4gT2JzZXJ2ZSByZWdpc3RyYXRpb24sIGEgUGFydGlhbCBJViBNVVNUIGJlPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyBpbmNsdWRlZCBpbiBhbGwgbm90aWZpY2F0aW9ucyAo Ym90aCBzdWNjZXNzZnVsIGFuZCBlcnJvciksIGV4Y2VwdCBmb3I8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7IHRoZSBmaXJzdCBvbmUgd2hlcmUgUGFydGlhbCBJViBNQVkgYmUg b21pdHRlZC4mbmJzcDsgVG8gcHJvdGVjdCBhZ2FpbnN0PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyByZXBsYXksIHRoZSBjbGllbnQgU0hBTEwgbWFpbnRhaW4gYSBOb3RpZmlj YXRpb24gTnVtYmVyIGZvciBlYWNoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZuYnNwOyZuYnNw OyBPYnNlcnZhdGlvbiBpdCByZWdpc3RlcnMuJm5ic3A7IFRoZSBOb3RpZmljYXRpb24gTnVtYmVy IGlzIGEgbm9uLW5lZ2F0aXZlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyBp bnRlZ2VyIGNvbnRhaW5pbmcgdGhlIGxhcmdlc3QgUGFydGlhbCBJViBvZiB0aGUgcmVjZWl2ZWQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7IG5vdGlmaWNhdGlvbnMgZm9yIHRo ZSBhc3NvY2lhdGVkIE9ic2VydmUgcmVnaXN0cmF0aW9uLiZuYnNwOyBGdXJ0aGVyPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyBkZXRhaWxzIG9mIHJlcGxheSBwcm90ZWN0aW9u IG9mIG5vdGlmaWNhdGlvbnMgYXJlIHNwZWNpZmllZCBpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZn dDsmbmJzcDsmbmJzcDsgU2VjdGlvbiA3LjQuMS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyBGb3Igbm90aWZpY2F0aW9u cywgdGhlIElubmVyIE9ic2VydmUgdmFsdWUgTVVTVCBiZSBlbXB0eSAoc2VlPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyBTZWN0aW9uIDMuMiBvZiBbUkZDNzI1Ml0pLiZuYnNw OyBUaGUgT3V0ZXIgT2JzZXJ2ZSBpbiBhIG5vdGlmaWNhdGlvbiBpczxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7U2VsYW5kZXIsIGV0IGFsLiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBFeHBpcmVzIEphbnVhcnkg MjcsIDIwMTkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7W1BhZ2UgMjBdPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mZ3Q7Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDtJbnRlcm5ldC1EcmFm dCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPU0NP UkUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSnVseSAyMDE4PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7 Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDsmbmJzcDsmbmJzcDsgbmVlZGVkIGZv ciBpbnRlcm1lZGlhcnkgbm9kZXMgdG8gYWxsb3cgbXVsdGlwbGUgcmVzcG9uc2VzIHRvIG9uZTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jmd0OyZndDsmbmJzcDsmbmJzcDsgcmVxdWVzdCwgYW5kIG1heSBiZSBz ZXQgdG8gdGhlIHZhbHVlIG9mIE9ic2VydmUgaW4gdGhlIG9yaWdpbmFsIENvQVA8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7IG1lc3NhZ2UuJm5ic3A7IFRoZSBjbGllbnQgcGVy Zm9ybXMgb3JkZXJpbmcgb2Ygbm90aWZpY2F0aW9ucyBhbmQgcmVwbGF5PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyBwcm90ZWN0aW9uIGJ5IGNvbXBhcmluZyB0aGVpciBQYXJ0 aWFsIElWcyBhbmQgU0hBTEwgaWdub3JlIHRoZSBvdXRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZn dDsmbmJzcDsmbmJzcDsgT2JzZXJ2ZSB2YWx1ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyBJZiB0aGUgY2xpZW50IHJl Y2VpdmVzIGEgcmVzcG9uc2UgdG8gYW4gT2JzZXJ2ZSByZXF1ZXN0IHdpdGhvdXQgYW48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7IElubmVyIE9ic2VydmUgb3B0aW9uLCB0aGVu IGl0IHZlcmlmaWVzIHRoZSByZXNwb25zZSBhcyBhIG5vbi1PYnNlcnZlPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyByZXNwb25zZSwgYXMgc3BlY2lmaWVkIGluIFNlY3Rpb24g OC40LiZuYnNwOyBJZiB0aGUgY2xpZW50IHJlY2VpdmVzIGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsm Z3Q7Jm5ic3A7Jm5ic3A7IHJlc3BvbnNlIHRvIGEgbm9uLU9ic2VydmUgcmVxdWVzdCB3aXRoIGFu IElubmVyIE9ic2VydmUgb3B0aW9uLCB0aGVuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZuYnNw OyZuYnNwOyBpdCBzdG9wcyBwcm9jZXNzaW5nIHRoZSBtZXNzYWdlLCBhcyBzcGVjaWZpZWQgaW4g U2VjdGlvbiA4LjQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jmd0OyZndDsmbmJzcDsmbmJzcDsgQSBjbGllbnQgTVVTVCBjb25zaWRlciB0aGUgbm90aWZp Y2F0aW9uIHdpdGggdGhlIGhpZ2hlc3QgUGFydGlhbCBJVjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZn dDsmbmJzcDsmbmJzcDsgYXMgdGhlIGZyZXNoZXN0LCByZWdhcmRsZXNzIG9mIHRoZSBvcmRlciBv ZiBhcnJpdmFsLiZuYnNwOyBJbiBvcmRlciB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDsmbmJz cDsmbmJzcDsgc3VwcG9ydCBleGlzdGluZyBPYnNlcnZlIGltcGxlbWVudGF0aW9ucyB0aGUgT1ND T1JFIGNsaWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDsmbmJzcDsmbmJzcDsgaW1wbGVtZW50 YXRpb24gTUFZIHNldCB0aGUgT2JzZXJ2ZSB2YWx1ZSB0byB0aGUgdGhyZWUgbGVhc3Q8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7IHNpZ25pZmljYW50IGJ5dGVzIG9mIHRoZSBQ YXJ0aWFsIElWOyBzdWNoIGFuIGltcGxlbWVudGF0aW9uIG5lZWRzIHRvPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyBtYWtlIHN1cmUgdGhhdCB0aGUgT2JzZXJ2ZSB2YWx1ZSBm b3IgYW4gb2JzZXJ2ZSBub3RpZmljYXRpb24gd2l0aG91dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZn dDsmbmJzcDsmbmJzcDsgUGFydGlhbCBJViBpcyBzbWFsbGVyIHRoYW4gYSBub3RpZmljYXRpb24g d2l0aCBQYXJ0aWFsIElWLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZndDsmZ3Q7Jmx0O21nbHQmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0O1RoaXMg c2VjdGlvbiBkaXNjdXNzIHRoZSBiZWhhdmlvciByZWdhcmRpbmcgdGhlIHNlcXVlbmNlIG51bWJl ci4gV2hpbGUNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDt0aGU8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZn dDsmZ3Q7c2VxdWVuY2UgbnVtYmVyIGFuZCB0aGUgcGFydGlhbCBJViBoYXZlIHRoZSBzYW1lIHZh bHVlLCBJIGFtIHdvbmRlcmluZw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0O2lmIDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jmd0OyZndDtpdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDt3b3VsZCBub3QgYmUg bW9yZSBhcHByb3ByaWF0ZWQgdG8gbWVudGlvbiB0aGUgc2VxdWVuY2UgbnVtYmVyIHZhbHVlIGlz DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7cHJvdmlkZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsm Z3Q7YnkgdGhlIHBhcnRpYWwgSVYsIGFuZCB0aGVuIHVzZSB0aGUgc2VxdWVuY2UgbnVtYmVyIHZh cmlhYmxlIHRvIGRlc2NyaWJlDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7YW50aTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jmd0OyZndDtyZXBsYXkuICZsdDsvbWdsdCZndDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZn dDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDtb R1M6XSBXZSBpbnRlbmRlZCB0byB1c2UgdGhlIHRlcm0g4oCccGFydGlhbCBJVuKAnSB3aGVuIHJl ZmVycmluZyB0byB0aGUNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0O251bWJlciBiZWluZyB0cmFuc3Bv cnRlZCBhbmQg4oCcU1NOJnF1b3Q7IHdoZW4gcmVmZXJyaW5nIHRvIHRoZSBudW1iZXIgc3RvcmVk IGluDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPiZndDt0aGUgZW5kcG9pbnQuIEkgd2lsbCBnbyB0aHJvdWdo IHRoZSBkb2N1bWVudCBhbmQgc2VlIHRoYXQgdGhpcyBjb252ZW50aW9uDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZndDtpcyBrZXB0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6 cmVkIj4mbHQ7bWdsdDImZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNv bG9yOnJlZCI+TWF5YmUgdGhhdCB3b3VsZCBiZSB1c2VmdWwgdG8gbWVudGlvbiB0aGlzIGNvbnZl bnRpb248L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj4mbHQ7 L21nbHQyJmd0Ozwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Y29sb3I6YmxhY2siPkdTOiBJ4oCZbSBub3Qgc3VyZSBnb2luZyBpbnRvIHRoaXMgZGlzdGlu Y3Rpb24gaXMgbmVjZXNzYXJ5LiBXZSBhbHJlYWR5IGRlc2NyaWJlIHRoZSByZWxhdGlvbnNoaXAg aW4gc2V2ZXJhbCBwbGFjZXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNr Ij5TZWN0aW9uIDMuMTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJl PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+JnF1b3Q7U2VuZGVyIFNlcXVlbmNlIE51bWJlci4m bmJzcDsgTm9uLW5lZ2F0aXZlIGludGVnZXIgdXNlZCBieSB0aGUgc2VuZGVyPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRvIGVudW1lcmF0ZSByZXF1ZXN0cyBhbmQgY2VydGFpbiByZXNw b25zZXMsIGUuZy4mbmJzcDsgT2JzZXJ2ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBu b3RpZmljYXRpb25zLiZuYnNwOyBVc2VkIGFzICdQYXJ0aWFsIElWJyBbPGEgaHJlZj0iaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzgxNTIiIHRpdGxlPSImcXVvdDtDQk9SIE9iamVjdCBT aWduaW5nIGFuZCBFbmNyeXB0aW9uIChDT1NFKSZxdW90OyI+UkZDODE1MjwvYT5dIHRvIGdlbmVy YXRlIHVuaXF1ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBRUFEIG5vbmNlcy4mcXVv dDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+U2VjdGlvbiA1Ojwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj4mcXVvdDsgVGhlICdQYXJ0aWFsIElWJyBwYXJhbWV0ZXIuJm5ic3A7 IFRoZSB2YWx1ZSBpcyBzZXQgdG8gdGhlIFNlbmRlciBTZXF1ZW5jZSBOdW1iZXIuJnF1b3Q7PC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Y29sb3I6YmxhY2siPlNlY3Rpb24gNy4yOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mcXVvdDtQYXJ0aWFsIElW cyAod2hpY2ggZW5jb2RlIHRoZSBTZW5kZXIgU2VxdWVuY2UgTnVtYmVycywgc2VlIDxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3Vy aXR5LTE1I3NlY3Rpb24tNSI+U2VjdGlvbiA1PC9hPikmcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+U2VjdGlvbiA3LjQg KGFkZHJlc3NpbmcgYW5vdGhlciBjb21tZW50IG9mIHlvdXJzKTo8L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mcXVvdDtQYXJ0aWFsIElWID0gU2VuZGVyIFNlcXVlbmNlIE51bWJlciZx dW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPmFuZCBh bHNvIHNldmVyYWwgdGltZXMgaW4gdGhlIHByb2Nlc3NpbmcsIFNlY3Rpb24gOC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4tIC0gLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tcmln aHQ6MGluIiBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jmd0O0QuNC4xLiZuYnNwOyBDb0FQIEhlYWRlciBGaWVsZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsm bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsgbyZuYnNwOyBWZXJzaW9uLiZu YnNwOyBUaGUgQ29BUCB2ZXJzaW9uIFtSRkM3MjUyXSBpcyBub3QgZXhwZWN0ZWQgdG8gYmU8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2Vuc2l0aXZl IHRvIGRpc2Nsb3NlLiZuYnNwOyBDdXJyZW50bHkgdGhlcmUgaXMgb25seSBvbmUgQ29BUCB2ZXJz aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRl ZmluZWQuJm5ic3A7IEEgY2hhbmdlIG9mIHRoaXMgcGFyYW1ldGVyIGlzIHBvdGVudGlhbGx5IGEg ZGVuaWFsLW9mLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBzZXJ2aWNlIGF0dGFjay4mbmJzcDsgRnV0dXJlIHZlcnNpb25zIG9mIENvQVAgbmVlZCB0 byBhbmFseXplIGF0dGFja3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgdG8gT1NDT1JFIHByb3RlY3RlZCBtZXNzYWdlcyBkdWUgdG8gYW4gYWR2ZXJz YXJ5IGNoYW5naW5nIHRoZSBDb0FQPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHZlcnNpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgVG9rZW4vVG9rZW4gTGVuZ3RoLiZu YnNwOyBUaGUgVG9rZW4gZmllbGQgaXMgYSBjbGllbnQtbG9jYWwgaWRlbnRpZmllcjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBmb3IgZGlmZmVyZW50 aWF0aW5nIGJldHdlZW4gY29uY3VycmVudCByZXF1ZXN0cyBbUkZDNzI1Ml0uJm5ic3A7IEFuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVhdmVzZHJv cHBlciByZWFkaW5nIHRoZSB0b2tlbiBjYW4gbWF0Y2ggcmVxdWVzdHMgdG8gcmVzcG9uc2VzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdoaWNoIGNh biBiZSB1c2VkIGluIHRyYWZmaWMgYW5hbHlzaXMuJm5ic3A7IEluIHBhcnRpY3VsYXIgdGhpcyBp cyB0cnVlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGZvciBub3RpZmljYXRpb25zLCB3aGVyZSBtdWx0aXBsZSByZXNwb25zZXMgYXJlIG1hdGNoZWQg d2l0aCBvbmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgcmVxdWVzdC4mbmJzcDsgQ29BUCBwcm94aWVzIGFyZSBhbGxvd2VkIHRvIGNoYW5nZSBUb2tl biBhbmQgVG9rZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgTGVuZ3RoIGJldHdlZW4gVURQIGhvcHMuJm5ic3A7IEhvd2V2ZXIsIG1vZGlmaWNhdGlv bnMgb2YgVG9rZW4gYW5kPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFRva2VuIExlbmd0aCBkdXJpbmcgYSBVRFAgaG9wIG1heSBiZWNvbWUgYSBkZW5p YWwtb2Ytc2VydmljZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jmd0O1NlbGFuZGVyLCBldCBhbC4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgRXhwaXJlcyBKYW51YXJ5IDI3LCAyMDE5Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFtQYWdlIDc2XTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0 O0ludGVybmV0LURyYWZ0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IE9TQ09SRSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBKdWx5IDIwMTg8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJz cDsgJm5ic3A7Jm5ic3A7YXR0YWNrLCBzaW5jZSBpdCBtYXkgcHJldmVudCB0aGUgY2xpZW50IHRv IGlkZW50aWZ5IHRvIHdoaWNoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHJlcXVlc3QgdGhlIHJlc3BvbnNlIGJlbG9uZ3Mgb3IgdG8gZmluZCB0aGUg Y29ycmVjdCBpbmZvcm1hdGlvbiB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB2ZXJpZnkgaW50ZWdyaXR5IG9mIHRoZSByZXNwb25zZS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZndDsmbHQ7bWdsdCZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDtJIGFtIHJlYWRp bmcgdGhlIHRleHQgYXMuIFdoZW4gdGhlIGF0dGFja2VyIGlzIG9uLXBhdGgsIGEgbG9uZyBUb2tl biBkb2VzDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDtub3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDtwcmV2 ZW50cyB0aGUgYXR0YWNrIGJhc2VkIG9uIGEgc3Bvb2ZlZCByZXNwb25zZS4gSG93ZXZlciwgZm9y IGFuIGF0dGFja2VyDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDt0aGF0PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m Z3Q7aXMgbm90IG9uIHBhdGgsIHRoZSBhdHRhY2tlciBuZWVkcyB0byBndWVzcyB0aGUgVG9rZW4s IGFuZCB0aGlzIGNhbiBiZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0O21pdGlnYXRlZCAocGFydGlhbGx5 KSBieSBpbmNyZWFzaW5nIHRoZSBUb2tlbiBzaXplLiZuYnNwOyBOb3RlIHRoYXQgaW4gdGhlDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZndDtsYXRlc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDtjYXNlLCBhIGxv bmcgVG9rZW4gc2hvdWxkIG5vdCBiZSBzZWVuIGFzIGEgcmVwbGFjZW1lbnQgZm9yIGNyeXB0b2dy YXBoaWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPiZndDtwcm90ZWN0aW9uIG9mIHRoZSBtZXNzYWdlLiAmbHQ7 L21nbHQmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7 W0dTOl0gVGhlcmUgc2VlbXMgdG8gYmUgYSBtaXN1bmRlcnN0YW5kaW5nIHNvbWV3aGVyZS4gVGhl cmUgaXMgbm8gbmVlZA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Zm9yIGFueW9uZSB0byDigJxndWVz cyB0aGUgVG9rZW7igJ0gc2luY2UgaXQgaXMgbm90IGVuY3J5cHRlZC4gVGhlcmUgaXMNCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jmd0O25vdGhpbmcgaGludGVkIGFib3V0IFRva2VuIGJlaW5nIGEg4oCccmVw bGFjZW1lbnQgZm9yIGNyeXB0b+KAnSwgc28gSSBkb27igJl0DQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZn dDt1bmRlcnN0YW5kIHdoeSBhbnlvbmUgd291bGQgYmUgbGVhZCB0byB0aGluayB0aGF0LiBUb2tl biBsZW5ndGggaXMNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0O21lbnRpb25lZCB0d2ljZTsgaW4gdGhl IG5leHQgdG8gbGFzdCBzZW50ZW5jZSAtIG1lbnRpb25pbmcgdGhhdCBDb0FQDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZndDtwcm94aWVzIChsZWdpdGltYXRlbHkpIG1heSBjaGFuZ2UgVG9rZW4gbGVuZ3Ro OyBhbmQgaW4gdGhlIGxhc3Qgc2VudGVuY2UNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0Oy0gZGVzY3Jp YmluZyB0aGF0IGFuIG9uLXBhdGggYXR0YWNrZXIgbWF5IG1vZGlmeSB0aGUgVG9rZW4gTGVuZ3Ro IHdoaWNoDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDtlaXRoZXIgY3JlYXRlZCBtaXNtYXRjaCBiZXR3 ZWVuIHJlcXVlc3QgYW5kIHJlc3BvbnNlIG9yIG5vIG1hdGNoIGF0IGFsbCwNCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jmd0O3doaWNoIGFyZSBib3RoIGRlbmlhbCBvZiBzZXJ2aWNlLiBJcyBpdCBjbGVhcmVy IGluIHRoZSBmb2xsb3dpbmcgd2F5PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+TkVXPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mZ3Q7byBUb2tlbi9Ub2tlbiBMZW5ndGguIFRoZSBUb2tlbiBmaWVsZCBpcyBhIGNsaWVudC1s b2NhbCBpZGVudGlmaWVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Zm9yIGRpZmZlcmVudGlhdGluZyBi ZXR3ZWVuIGNvbmN1cnJlbnQgcmVxdWVzdHMgW1JGQzcyNTJdLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0 OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPiZsdDttZ2x0 MiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5XaGF0 IEkgd2FzIHRyeWluZyB0byBzYXkgaXMgdGhhdCBpZiB5b3Ugd2FudCB0byBzcG9vZiBhIHJlc3Bv bnNlICggbGlrZSBpbiBETlMpIGFuZCB5b3UgYXJlIG5vdCBvbiBwYXRoLCB5b3UgbmVlZCB0byBn dWVzcyB0aGUgVG9rZW4uIEluIHRoYXQgc2Vuc2UsIHRoZSBsb25nZXIgdGhlIHNhZmVyLiBIb3dl dmVyLCBhcyBmb3IgRE5TLCB3ZSBzaG91bGQgbm90IHJlbHkNCiBvbiB0aGlzLiAmbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj4mbHQ7L21nbHQyJmd0 Ozwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5HUzogUmlnaHQsIHdlIGRv buKAmXQgcmVseSBvbiB0aGUgbGVuZ3RoIG9mIHRva2VuIGZvciBzZWN1cml0eS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1s ZWZ0OjMuNzVwdDttYXJnaW4tcmlnaHQ6MGluIiBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05f QkxPQ0tRVU9URSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_6029df3f46e647c38a38b8be969c072bericssoncom_-- From nobody Thu Sep 6 05:08:03 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA99128CF3 for ; Thu, 6 Sep 2018 05:08:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu Message-ID: <153623568173.11674.11901155569724580212.idtracker@ietfa.amsl.com> Date: Thu, 06 Sep 2018 05:08:01 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 12:08:02 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2018-09-13 Reviewer LC end Draft Melinda Shore 2018-09-04 draft-ietf-dnsop-refuse-any-07 Last calls: Reviewer LC end Draft John Bradley 2018-06-18 draft-ietf-bfd-multipoint-active-tail-09 Daniel Franke 2018-06-28 draft-ietf-netconf-rfc7895bis-06 Daniel Gillmor 2018-06-25 draft-ietf-dnsop-session-signal-14 Daniel Gillmor 2018-03-19 draft-gutmann-scep-10 Russ Mundy 2018-08-13 draft-ietf-dnsop-terminology-bis-13 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Sandra Murphy 2018-08-10 draft-ietf-sidrops-rpki-tree-validation-02 Carl Wallace 2018-09-12 draft-ietf-tram-stun-pmtud-09 David Waltermire 2018-09-12 draft-ietf-isis-segment-routing-msd-15 Samuel Weiler 2018-09-07 draft-ietf-tictoc-1588v2-yang-09 Samuel Weiler 2018-05-21 draft-ietf-bfd-multipoint-18 Brian Weis 2018-09-07 draft-ietf-dhc-dhcp4o6-saddr-opt-04 Klaas Wierenga 2018-09-06 draft-ietf-softwire-mesh-multicast-22 Christopher Wood 2018-09-06 draft-ietf-lisp-gpe-05 Paul Wouters 2018-09-06 draft-ietf-dnsop-kskroll-sentinel-15 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Next in the reviewer rotation: Liang Xia Taylor Yu Dacheng Zhang Derek Atkins John Bradley Shaun Cooley Roman Danyliw Alan DeKok Donald Eastlake Shawn Emery From nobody Sun Sep 9 11:26:43 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 305FA130DCD; Sun, 9 Sep 2018 11:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9jc5wavLaz5; Sun, 9 Sep 2018 11:26:30 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABE0F1200D7; Sun, 9 Sep 2018 11:26:30 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id p79-v6so26788831itp.3; Sun, 09 Sep 2018 11:26:30 -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 :content-transfer-encoding; bh=u9961goe8+nxsMpyzOrvVAXFMKLZndG7kiWtwzwx2d8=; b=ng6oMK4NheyruwrW0z2LR1CQU07BoSZ+s4PySpsejvKz6NIbdhymJcUi3Y6pUBhQjj 2pBSNcFXQoDsvdR2xqaAKOXrqKJdM8SSQq0q+Ve0Kc/wYMmdiCfTbBjQqWnmQhSRPw6k FR086pl+ynQSSpQJBMUkv2XUmqMacBWKPMg8rRClJWXff6+EBzMuX/k1XtN6uX1wHClV 9i3Ymz+IhQi3bO4u2Ykwr5BS8cvmqTXojmgafRGvCA4JIV2xfsxfjV0MbcmLsxxO0ScL e8UCeEcOuKppjF+GFc2gpO4nRCE3SMTmgtl6suj7beiYtL4xUXSP/Irbzuw5Lil8Fiho DX7g== 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 :content-transfer-encoding; bh=u9961goe8+nxsMpyzOrvVAXFMKLZndG7kiWtwzwx2d8=; b=EbFKjf4b9UucQdF8cqPpg0lVQ8gU2CminbmyVvu/VofkTX2dMmmNINZkuG+2CA2uj3 pvhyx58eB4z4m8dkD50jqJ/eSHG7ldD7aRNlpZnbv/cSz2h3uOFT4dQ4IHDnHyZjcz9O /Uleaznff3qZZUGBx4n5/8K/T5jLrFe1F1lQcAhylpyoz+GCV9oU61ZTkJxrfcTzgI1F Kr7hYMD7VK6IPUSF+a/T9W9YdUA9/ARmZZZXg112Dvkdg+kglX9MuYYb4LtjVxPMNIUK Njs8T86+cO8WxQHGPyoeA0uQ4cbk27to0XkIFb11/fz2lE0PHf42M0ZADr4sF8f6XAZC N5XA== X-Gm-Message-State: APzg51AdNXhsMpwPVX/rVEDy2gGVOsj8UaMkxQIhdOaR2nRYkiUzo58i FPiuy9XYTwPItdPPCiMXafJV5rSsPlozOU/VyF8XMjrV X-Google-Smtp-Source: ANB0VdbmAHU/uhgO2BdknhB7oKXkpvXfTGcIgbmwk5iwGmBjfD9+6XiRXxBH0dqdhE5Yv+KgUO19w1++1TV488YYV1Y= X-Received: by 2002:a24:98d6:: with SMTP id n205-v6mr15961712itd.44.1536517589529; Sun, 09 Sep 2018 11:26:29 -0700 (PDT) MIME-Version: 1.0 From: Christopher Wood Date: Sun, 9 Sep 2018 11:26:18 -0700 Message-ID: To: The IESG , secdir@ietf.org, draft-ietf-lisp-gpe.all@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [secdir] secdir review of draft-ietf-lisp-gpe X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2018 18:26:32 -0000 Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of my review is: Ready with issues. The proposed extension mechanism is simple to understand. However, my main concern is regarding the nonce size reduction and implications on LISP. While the threat models (on-path and off-path) do not change with this extension, the probability of some off-path attacks might change. Specifically, the probability of correctly guessing a 16 bit nonce is not negligible. This might make attacks in which an adversary tries to convince an ITR of reachability to an otherwise unreachable ETR more likely. From [1], an ITR that sees the nonce echoed correctly =E2=80=9Cknows that the path to and from the ETR is up.=E2=80=9D Thus, I th= ink some discussion of this is necessary in the security considerations. Beyond that, I have the following minor comments and nits: - UDP checksums seem to be the only mechanism in place that give ITRs and ETRs a means of checking datagram integrity. Of course, this means an on-path adversary can muck with the g-Bit from Section 4.1 so as to prevent use of the GPE mechanism. This is not new with this extension, though a comment on the issue might be useful, e.g., in the security considerations. - It would be helpful to include packet diagrams similar to Figure 2 wherein (1) P and V are set and (2) only P is set. While I don=E2=80=99t fi= nd the text misleading or confusing, a figure might help other readers. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|1|I|1|K|K| Source MV | Dest MV | Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID/Locator-Status-Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|L|0|0|I|1|K|K| ... 0 ... | Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID/Locator-Status-Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - In Section 4, where it states, "A LISP-GPE router MUST NOT encapsulate non-IP packets to a non LISP-GPE capable router," I might replace "to a non LIST-GPE capable router" with "when the P-bit is set to 0." [1] https://tools.ietf.org/html/draft-ietf-lisp-rfc6830bis-16#section-10.1 From nobody Mon Sep 10 14:45:02 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E14130EF7 for ; Mon, 10 Sep 2018 14:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 ZNGhy2s0DTBz for ; Mon, 10 Sep 2018 14:44:49 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BD40130DE1 for ; Mon, 10 Sep 2018 14:44:49 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id p79-v6so31619229itp.3 for ; Mon, 10 Sep 2018 14:44:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fOcQTZCX87Q7YFTdrOBrMwkd/5uUoIGQV84RF6Jhjq8=; b=kNP7r66Xh/izm2FcM81TPeCN0SO5HiXD7andH4h9heOcVTLJpMK3QI4ZR+2HGjeWg5 xfJ615sCOw+nF67HRFPiiYWVpMbZULbRFkYsbRYC9FXZ+ymmZYquBvu8WelachrI0dbV LClGI6OnU9LcSyVhxAZHUaikzX40YltFzGKG4= 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=fOcQTZCX87Q7YFTdrOBrMwkd/5uUoIGQV84RF6Jhjq8=; b=Nx0vrKRaQzGdI9hYM615883blP6AORlflY607gGE0ABsJ998OSj7+z8G0ZsdYGiKty KMF0/Clvq9aPKI21hjLLyQ/ehUMVBTICi+CfeAzbP0zdU4z6eV789NMBElZiSdRGvYwG 2X6P3Wtfez84zgUzJ6jamXa6PI/PYuZbAPJz1n7HEgH/TUYLa7HqMuPX5aaJ1+w3Dul7 w3UrYfdfkkB0W32zQRho4iiqHVJGbvbolRSdKViPIHUndGFmP4CalQOpFDEIME/BUdhD 2bBoU71YeFZAkxhualEC6NPSickFpywx3vJ86XXcAjoYdMZW2YTbSCdwTQl2Bv792c0r AjEw== X-Gm-Message-State: APzg51AnQSXXq9gSh2bDRD2LuJLRGZM4ZvESKsvfSBDImz693ukqTkAM uG39o3tWNBVzkg8cAVqNek8QVti0TJIq0gKIrCeSZ6pblQcZ47vxWcDkc2MaMQnDH8p8YZYAPOu u4RvOy1FI3ktvLPw= X-Google-Smtp-Source: ANB0Vdby3zrmIcUyjV5ZbcLbjnzk2OXaaAhlQnC40A1KAjhSkcWz9ngc3VCuxtNGvXKVDqKXORBU5ITN3WZ062OfC+k= X-Received: by 2002:a24:6fd3:: with SMTP id x202-v6mr19399611itb.71.1536615888601; Mon, 10 Sep 2018 14:44:48 -0700 (PDT) MIME-Version: 1.0 References: <201808080746.w787kd74021069@rumpleteazer.rhmr.com> <20180810212645.GU40887@kduck.kaduk.org> In-Reply-To: From: Brian Campbell Date: Mon, 10 Sep 2018 15:44:22 -0600 Message-ID: To: Benjamin Kaduk Cc: hilarie@purplestreak.com, The IESG , secdir@ietf.org, draft-ietf-oauth-token-exchange.all@ietf.org Content-Type: multipart/alternative; boundary="00000000000032653405758b4492" Archived-At: Subject: Re: [secdir] Security review of draft-ietf-oauth-token-exchange-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2018 21:44:52 -0000 --00000000000032653405758b4492 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Hilarie, I've published a new draft -15 of OAuth Token Exchange , which I hope/believe addresses the comments you raised. Thanks again for the review, Brian On Mon, Aug 13, 2018 at 11:36 AM Brian Campbell wrote: > > On Fri, Aug 10, 2018 at 3:26 PM Benjamin Kaduk wrote: > >> ... >> With the disclaimer that I haven't read token-exchange recently and am >> mostly going off my memory of the mailing list discussions, it seems lik= e >> the key consideration here is that token exchange allows you to convert = a >> token that may be opaque to you into one that has inspectable fields, an= d >> those fields can be privacy sensitive. So a JWT response should only be >> given to a requestor that trusted to know such information; a lot of the >> time, that has large overlap with being trusted to have the token in the >> first place, but potentially there is some amount of non-overlap. >> >> The considerations from 7523 of course also apply, and sensitive >> information should not be sent over unencrypted channels, but isn't the >> above paragraph an aspect inherently new to token exchange? > > > I don't think it's unique to token exchange. RFC 7523, for example, > defines the use of a JWT as an authorization grant used to obtain an acce= ss > token from a authorization server. Unless encrypted as a JWE, the JWT in > that scenario has fields that are inspectable to the client. And an OAuth > access token is considered opaque to the client but whether or not > information in the token is actually accessible to a client is an > implementation detail of the authorization server. The latter is true for > OAuth in general and not just these more specialized exchanges. > > The idea behind maybe incorporating some text similar to (but adapted to > the context) what's in the privacy considerations of RFC 7523 > is that the > considerations are pretty much the same - use TLS in transit, minimize th= e > amount of information in the token, encrypt the token if disclosure of it= s > information to the client is a concern. > > > > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --00000000000032653405758b4492 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Hilarie,

I&#= 39;ve published a new draf= t -15 of OAuth Token Exchange, which I hope/believe addresses the comme= nts you raised.=C2=A0

=
Thanks again for the review,
Brian


On Mon, Aug 13, 2018 at 11:36 AM Brian Campbell <bcampbell@ping= identity.com> wrote:

On Fri, Aug 10, 2018 at 3:26 PM Benjamin Kaduk <kaduk@mit.edu> wrote:<= br>
...
With the disclaimer that I haven't read token-exchange recently and am<= br> mostly going off my memory of the mailing list discussions, it seems like the key consideration here is that token exchange allows you to convert a token that may be opaque to you into one that has inspectable fields, and those fields can be privacy sensitive.=C2=A0 So a JWT response should only = be
given to a requestor that trusted to know such information; a lot of the time, that has large overlap with being trusted to have the token in the first place, but potentially there is some amount of non-overlap.

The considerations from 7523 of course also apply, and sensitive
information should not be sent over unencrypted channels, but isn't the=
above paragraph an aspect inherently new to token exchange?

I don't think it's unique to token exchange. RFC 7= 523, for example, defines the use of a JWT as an authorization grant used t= o obtain an access token from a authorization server. Unless encrypted as a= JWE, the JWT in that scenario has fields that are inspectable to the clien= t. And an OAuth access token is considered opaque to the client but whether= or not information in the token is actually accessible to a client is an i= mplementation detail of the authorization server. The latter is true for OA= uth in general and not just these more specialized exchanges.

The idea behind maybe incorpora= ting some text similar to (but adapted to the context) what's in the p= rivacy considerations of RFC 7523 is that the considerations are pretty= much the same - use TLS in transit, minimize the amount of information in = the token, encrypt the token if disclosure of its information to the client= is a concern.

<= /div>



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --00000000000032653405758b4492-- From nobody Mon Sep 10 16:03:07 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 881E0130EEC; Mon, 10 Sep 2018 09:25:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1536596735; bh=rW+MueFV4P6kbAOMgXFzpfKlwjAQvzni6R9cSWQBh+E=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=L0lQwLbO+H3HfxNDcqH/pHYhYNhf7302k/Z6Gv499MVZhsFnP9qLbvrbKnGvROLVn 7LBf0wHXZ0StIfbgTC4u/Fsg377M3I5fIoW8bqw8xTwgDUoKUoWBa7AEv7erYdi/6+ SJLCMhn0DAN6FJfP9YvjON9f4Z5aObyxg3ntZ7/w= X-Mailbox-Line: From new-work-bounces@ietf.org Mon Sep 10 09:25:26 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A859130F47; Mon, 10 Sep 2018 09:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1536596719; bh=rW+MueFV4P6kbAOMgXFzpfKlwjAQvzni6R9cSWQBh+E=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=km03FSdJBlg4eZjvsz/rFtLXErEWi/svKDKkt89ybp6W2uam6cnP9n8axGMu1hRiR xj7ceShF125LyfTeo4jzEIuZ+Ig/fM/FIwkrBl4qzMK0o9DcH56NDV/qZ5N2TNsj9L wnnPZab7GSPxETroztuvOKTvSTw3lVHAZHklvXCc= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 35408130EEB for ; Mon, 10 Sep 2018 09:25:00 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk MIME-Version: 1.0 Reply_to: Message-ID: <153659670021.26517.6954565480220917879.idtracker@ietfa.amsl.com> Date: Mon, 10 Sep 2018 09:25:00 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Mon, 10 Sep 2018 16:03:06 -0700 Subject: [secdir] [new-work] WG Review: Source Packet Routing in Networking (spring) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2018 16:25:45 -0000 The Source Packet Routing in Networking (spring) WG in the Routing Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2018-09-20 Source Packet Routing in Networking (spring) ----------------------------------------------------------------------- Current status: Active WG Chairs: Rob Shakir Bruno Decraene Assigned Area Director: Martin Vigoureux Routing Area Directors: Alvaro Retana Deborah Brungard Martin Vigoureux Mailing list: Address: spring@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/spring Archive: https://mailarchive.ietf.org/arch/browse/spring/ Group page: https://datatracker.ietf.org/group/spring/ Charter: https://datatracker.ietf.org/doc/charter-ietf-spring/ The Source Packet Routing in NetworkinG (SPRING) Working Group is the home of Segment Routing (SR) using MPLS (SR-MPLS) and IPv6 (SRv6). SPRING WG serves as a forum to discuss SPRING networks operations, define new applications of, and specify extensions of Segment Routing technologies. SPRING WG should avoid modification to existing data planes that would make them incompatible with existing deployments. Where possible, existing control and management plane protocols must be used within existing architectures to implement the SPRING function. Any modification of -or extension to- existing architectures, data planes, or control or management plane protocols should be carried out in the WGs responsible for the architecture, data plane, or control or management plane protocol being modified and in coordination with the SPRING WG, but may be done in SPRING WG after agreement with all the relevant WG chairs and responsible Area Directors. The SPRING WG defines procedures that allow a node to steer a packet through an SR Policy instantiated as an ordered list of instructions called segments and without the need for per-path state information to be held at transit nodes. Full explicit control (through loose or strict path specification) can be achieved in a network comprising only SPRING nodes, however SPRING nodes must inter-operate through loose routing in existing networks and may find it advantageous to use loose routing for other network applications. The scope of the SPRING WG work includes both single Autonomous System (AS) and multi-AS environments. Segment Routing typically operates within a single trust domain which requires the enforcement of a strict boundary and preventing Segment Routing packets from entering the trusted domain from the untrusted exterior. Certain deployments may however involve multiple trust domains which in turn may imply the use of cross/inter domain segments. Risk models associated with these various scenarios may necessitate the use of a cryptographic integrity checks to validate that the segment list is provided by an authorised entity. As is customary in the Routing Area, the SPRING WG will also identify and address any other security considerations introduced by the technologies it defines; addressing such considerations may require the introduction of new functionality in protocols leveraged for Source Routing, in which case the SPRING WG will formulate requirements to be considered by the appropriate WG for that work. SPRING technologies may be deployed in environments spanning a range of risk and threat models, which may impact both the security considerations and the requirements place on other protocols in order to support Source Routing protocols. The technologies SPRING WG defines may be applicable to both centralised and distributed path computation. The SPRING WG will manage its specific work items by milestones agreed with the responsible Area Director. The work-items of the SPRING WG include functional specifications for: o Segment Routing policies and the associated steering, signalling and traffic engineering mechanisms. o Source-routed stateless service chaining using SR-MPLS and SRv6 dataplanes. o SRv6 network programming for the underlay networks and overlay services, and including data plane behavior and functions associated with SIDs o Operation, Administration and Management (OAM), and traffic accounting in networks with SR-MPLS and SRv6 data planes in the case where SR introduces specificities compared to MPLS or IPv6 technologies. o Performance Management (PM) and monitoring in networks with SR-MPLS and SRv6 data planes in the case where SR introduces specificities compared to MPLS or IPv6 technologies. o Inter-working between SRv6 and SR-MPLS and between SR and existing routing solutions to allow for seamless deployment and co-existence. o New types of segments mapping to forwarding behaviour (e.g., local ingress replication, local forwarding resources, a pre-existing replication structure) if needed for new usages. Any of the above may require architectural extensions. The work-items of SPRING WG also include: o Specification of management models (YANG) for Segment Routing applications, services and networks with SR-MPLS and SRv6 dataplanes. The SPRING WG will coordinate and collaborate with other WGs as needed. Specific expected interactions include (but may not be limited to): * mpls on the MPLS dataplane and OAM extensions, * 6man on the IPv6 dataplane for SR and associated OAM extensions * lsr on OSPF and IS-IS extensions to flood SPRING-related information * idr for BGP extensions * bess for VPN control plane * pce on extensions to communicate with an external entity to compute and program SPRING paths * teas on generic traffic engineering architecture * sfc on service chaining applications * rtgwg on fast-reroute technologies ----------------------------------------------------------------------- Milestones: SR-MPLS sent to IESG by October 2018 SR-MPLS configuration YANG model sent to IESG by December 2018 MPLS anycast sent to IESG by October 2018 SR-TE policy sent to IESG by SR policies YANG model sent to IESG by December 2019 SR-MPLS OAM sent to IESG by SR-MPLS Performance Measurement to IESG by SR-IPv6 OAM sent to IESG by Stateless service chaining with SR sent to IESG by SRv6 Network Programming to IESG by _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Mon Sep 10 19:13:25 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07462130E17 for ; Mon, 10 Sep 2018 19:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.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 jL_MbmYQsutA for ; Mon, 10 Sep 2018 19:13:15 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 C9D19130DCF for ; Mon, 10 Sep 2018 19:13:14 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id o15-v6so26614809qtk.6 for ; Mon, 10 Sep 2018 19:13:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CcUbFUOnFScAud2LqiElwYRrYmvv9Kdx4fbBFUmNBBg=; b=Cuzny2xKtZ27xXlleN0+c5ioZbNTlMiW9Z5CvYI5z+2DcKj8ZUTtvF7+yowIuA8PYj 8G+e8Y5CWhk2rAZmLDgUePNEu7z3ICSWPkY3XNmDjV02pNQh88/IC7japQjrvWjFKDNa UuR2yTzJWirM8UarLFVRDinqg8FBMD7se66/E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CcUbFUOnFScAud2LqiElwYRrYmvv9Kdx4fbBFUmNBBg=; b=d3dxfs7CljjmtA6e7Al8W7F5CFIcUjsNcP+tI37a+AvmtXd2K6GJ1HXNRB1LlClI6h ndh2bfUwU0LoRx9/vfF07FmNDcinchW2RsZI00r965BtdU43bqyKv2UwuOOoyct2R0K6 1DMaUseiQN/CwgL7PRmtve55RqtizwIDomw5x0g7uMoifSQfsIt/Y+QFqKrOW7m/7pH/ 9YmgV8nebaoW7Ba8wMDEC2Xp6TtH/KgZ/pkSO68H9+hszKa4rb76eJxZMtg3SBR/uct1 wu/w812JvO1ONCHFr2AN5lBkGjxq0sumEs/Lp21wKthMbehdpfVbhnUlF27ji9lzobH0 wvKQ== X-Gm-Message-State: APzg51AisgrNhMowApMzLicEb7vEY6FAv/WywJnVnlQEczbJlDMU5W60 gKNWNz0rblfDe3dMJrMFo0J3GICI2erTfYzaSEKl6Q== X-Google-Smtp-Source: ANB0Vda+RtUvaujke2BlAy5qajZTQc2Ej1HKc0PKjqK5/Ddvln0TZDq/bcGG3rMgmPilZbZQBWO4F7+F8B/SNEd0Plk= X-Received: by 2002:a0c:d842:: with SMTP id i2-v6mr16355801qvj.145.1536631993621; Mon, 10 Sep 2018 19:13:13 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a0c:86ea:0:0:0:0:0 with HTTP; Mon, 10 Sep 2018 19:13:12 -0700 (PDT) X-Originating-IP: [2001:470:1f07:121:922b:34ff:fe5d:efa3] In-Reply-To: References: <153513922907.22939.10542350679349996082@ietfa.amsl.com> From: Kyle Rose Date: Mon, 10 Sep 2018 22:13:12 -0400 Message-ID: To: Dino Farinacci Cc: IETF SecDir , draft-ietf-lisp-rfc6830bis.all@ietf.org, IETF Discussion Mailing List , "lisp@ietf.org list" , Benjamin Kaduk Content-Type: multipart/alternative; boundary="00000000000021742005758f0470" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-lisp-rfc6830bis-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 02:13:18 -0000 --00000000000021742005758f0470 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Apologies for the two-week absence: I've been on vacation (especially from email) for most of that period. On Tue, Aug 28, 2018 at 6:17 PM, Dino Farinacci wrote= : > > The whole point of LISP is to create a routing overlay for the EID > address space, the RIB of which is managed by a global mapping system, no= t > BGP sessions. If control plane traffic managed by BGP (or static routes, = or > whatever networks use once the DFZ RIB is limited to entities in the core= ) > continues to flow, that is of small comfort to end users trying to get da= ta > over the data plane. From the perspective of end users, BGP is being > replaced routing of the traffic that matters to them. > > That really is not true. You need both the overlay and underlay to get > user traffic to flow. > Sure, just like you need link layer connectivity and closed circuits. User traffic is directly handled by the overlay, which is an added layer of novel complexity. When you add complexity, you inevitably add room for bugs and mysterious behavior. Anyway, I'm happy to drop this point for secdir because this is more of a general architectural observation than something specifically related to security. > > * It does not resolve the trust anchor problem. Instead of proposing a > PKI, you seem to be proposing a trusted third party authoritative for the > Hash-EID namespace. (Q.v. section 2, the Hash-EID definition: "Another > entity=E2=80=9D) > > The trust anchor is the mapping system. And that is the PKI. And the > mapping system is distributed. > What PKI? That's part of what I'm trying to establish. How do entities decide to trust each other? E.g., if entity A has pairwise trust with peer B, but needs an EID mapping for peer C, it needs some way to establish that the replies it's supposedly receiving from C are genuine. One popular model enabling you to do that without employing transitive trust is end-to-end signing chained to a trust anchor. With TLS as deployed on the web today, the trust anchors are a set of mostly mutually agreed-upon CA certificates that serve as roots for the certificates presented by every public web server. There are of course issues with this model (q.v., certificate transparency, Symantec), but its behavior is well-established and its properties are understood. What is the equivalent here? It sounds like the answer here is mapping system-specific. E.g., from a quick perusal of the DDT draft, it sounds very DNSSEC-like (which might suggest a course of action to eliminate the need to develop, deploy, and maintain a custom security protocol, but that is a different discussion). Where an interface is described without reference to a specific implementation, a set of assumptions (e.g., "correct routing relies on the authenticity of mapping system responses") and associated security requirements for any conforming mapping system (e.g., "entities making use of mapping system responses must have some way to authenticate them that does not rely on transitive trust") need to be stated for the document to be a complete description of a system component. That is, without first clearly defining the required properties of any valid implementation of described interfaces, there's no way to evaluate whether the component under review will do what it's supposed to. A good place to put these assumptions and requirements is in the security considerations section: those statements are not normative for the system component described by the draft in which they appear, but are effectively requirements for whatever system component is to implement that interface in a conforming way. Enumerating them as such (in the document describing the interface in detail) allows the reader to evaluate the requirements in light of the system using the interface, while also providing a convenient checklist for those designing conforming systems. A set of well-crafted security considerations sections also makes it much easier for a reviewer to understand the security of the system as a whole without having to understand the details of every implementation, and to verify that individual system components under review will have the appropriate behavior. I'm going to skip the comments related to draft-farinacci-lisp-ecdsa-auth, just to limit scope here. We can get back to it once that document has been adopted and more fully fleshed-out. > "TLS" does not appear anywhere in the draft of LISP-SEC I reviewed: > > Right as I explained DTLS does. > Check again. Just to be sure, I've tried several tools and the letters "T", "L", and "S" do not appear consecutively anywhere in this document. Neither do "SSL" nor "transport-level security". > > I would like to see a discussion of whether and how the nature and scal= e > of this problem differs from that of the status quo. BGP sessions and RIB > push have properties that are well-established from decades of experience= : > surely LISP does not have exactly the same properties. The security > considerations should make clear, for instance, how a loss of control pla= ne > connectivity differs from the loss of a BGP session, and how this impacts > visibility and behavior of the data plane. > > Please look at the deployment drafts. Please note, you are reviewing a > document that is focusing on encapsulating packets on an overlay. All the > other support pieces are broken out, in what the WG felt was logical, in > sepreate documents. > I think this gets back to the point I made at the end of my original review, which is that this system is difficult to evaluate from a security perspective in a piecewise manner given the dependencies between the different layers and the lack of explicitly-enumerated security requirements for each system component implementing a given interface. Kyle --00000000000021742005758f0470 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Apologies for the two-week absence: = I've been on vacation (especially from email) for most of that period.<= br>

On Tue, Aug 28, 2018 at 6:17 PM, Dino Farinacc= i <farinacci@gmail.com> wrote:
> The whole point of LISP is to create a r= outing overlay for the EID address space, the RIB of which is managed by a = global mapping system, not BGP sessions. If control plane traffic managed b= y BGP (or static routes, or whatever networks use once the DFZ RIB is limit= ed to entities in the core) continues to flow, that is of small comfort to = end users trying to get data over the data plane. From the perspective of e= nd users, BGP is being replaced routing of the traffic that matters to them= .

That really is not true. You need both the overlay and underlay to g= et user traffic to flow.

Sure, just lik= e you need link layer connectivity and closed circuits. User traffic is dir= ectly handled by the overlay, which is an added layer of novel complexity. = When you add complexity, you inevitably add room for bugs and mysterious be= havior. Anyway, I'm happy to drop this point for secdir because this is= more of a general architectural observation than something specifically re= lated to security.
=C2=A0
>=C2=A0 * It does not resolve the trust anchor pr= oblem. Instead of proposing a PKI, you seem to be proposing a trusted third= party authoritative for the Hash-EID namespace. (Q.v. section 2, the Hash-= EID definition: "Another entity=E2=80=9D)

The trust anchor is the mapping system. And that is the PKI. And the= mapping system is distributed.

What PK= I? That's part of what I'm trying to establish. How do entities dec= ide to trust each other?

E.g., if entity A has pai= rwise trust with peer B, but needs an EID mapping for peer C, it needs some= way to establish that the replies it's supposedly receiving from C are= genuine. One popular model enabling you to do that without employing trans= itive trust is end-to-end signing chained to a trust anchor. With TLS as de= ployed on the web today, the trust anchors are a set of mostly mutually agr= eed-upon CA certificates that serve as roots for the certificates presented= by every public web server. There are of course issues with this model (q.= v., certificate transparency, Symantec), but its behavior is well-establish= ed and its properties are understood. What is the equivalent here?

It sounds like the answer here is mapping system-specific.= E.g., from a quick perusal of the DDT draft, it sounds very DNSSEC-like (w= hich might suggest a course of action to eliminate the need to develop, dep= loy, and maintain a custom security protocol, but that is a different discu= ssion).

Where an interface is described without re= ference to a specific implementation, a set of assumptions (e.g., "cor= rect routing relies on the authenticity of mapping system responses") = and associated security requirements for any conforming mapping system (e.g= ., "entities making use of mapping system responses must have some way= to authenticate them that does not rely on transitive trust") need to= be stated for the document to be a complete description of a system compon= ent. That is, without first clearly defining the required properties of any= valid implementation of described interfaces, there's no way to evalua= te whether the component under review will do what it's supposed to.

A good place to put these assumptions and requiremen= ts is in the security considerations section: those statements are not norm= ative for the system component described by the draft in which they appear,= but are effectively requirements for whatever system component is to imple= ment that interface in a conforming way. Enumerating them as such (in the = document describing the interface in detail) allows the reader to evaluate = the requirements in light of the system using the interface, while also pro= viding a convenient checklist for those designing conforming systems.
=

A set of well-crafted security considerations sections = also makes it much easier for a reviewer to understand the security of the = system as a whole without having to understand the details of every impleme= ntation, and to verify that individual system components under review will = have the appropriate behavior.

I'm going t= o skip the comments related to draft-farinacci-lisp-ecdsa-auth, just to lim= it scope here. We can get back to it once that document has been adopted an= d more fully fleshed-out.

<= span class=3D"gmail-">> "TLS" does not appear anywhere in the = draft of LISP-SEC I reviewed:

Right as I explained DTLS does.

= Check again. Just to be sure, I've tried several tools and the letters = "T", "L", and "S" do not appear consecutively= anywhere in this document. Neither do "SSL" nor "transport-= level security".
=C2=A0
> I would like to see a discussion of whether and how the nature and sca= le of this problem differs from that of the status quo. BGP sessions and RI= B push have properties that are well-established from decades of experience= : surely LISP does not have exactly the same properties. The security consi= derations should make clear, for instance, how a loss of control plane conn= ectivity differs from the loss of a BGP session, and how this impacts visib= ility and behavior of the data plane.

Please look at the deployment drafts. Please note, you are reviewing= a document that is focusing on encapsulating packets on an overlay. All th= e other support pieces are broken out, in what the WG felt was logical, in = sepreate documents.

I think this gets b= ack to the point I made at the end of my original review, which is that thi= s system is difficult to evaluate from a security perspective in a piecewis= e manner given the dependencies between the different layers and the lack o= f explicitly-enumerated security requirements for each system component imp= lementing a given interface.

Kyle
--00000000000021742005758f0470-- From nobody Tue Sep 11 02:18:07 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A433130E8F for ; Tue, 11 Sep 2018 02:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-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=gigix-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEgUV5wE568d for ; Tue, 11 Sep 2018 02:18:03 -0700 (PDT) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 9E3A8130E55 for ; Tue, 11 Sep 2018 02:18:02 -0700 (PDT) Received: by mail-wr1-x433.google.com with SMTP id j26-v6so24960323wre.2 for ; Tue, 11 Sep 2018 02:18:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=n5Y724u5OXBBefCq76QbkwEaAJCmLwZc4l8kZizCLmE=; b=FI5W/HF1NtjizkgUludyYFXWdBlUaP7lmljM7chywyn0F4Hnpu8YQ6+gLNkgAy6+P4 gXE851T9k9L7Q/ucfKbksZ6MAgpoJQ1+0VwtrNDKOXSEUwfYe0NQSjxU6ug3wHKuTCDy 75LsVFhqvMAYGJC1BTF7sitXDf2MTLb45l0RmsYoDJAIykm5WbQPBbJmvspr6fB3tBan 3bwYYZ3SiqpKxBoLK/Yiz+KXp7JcD6O7mc6YhtPUaAXcBG1o8j3uUxVF661MLXJ8Puzm Kjv0Ij5PycGfDSaSvFoUS/y9h0Sz9SxNWc5ujV/L++uhxEBeZJk0jSEtxH0StEWzAwY8 PyxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=n5Y724u5OXBBefCq76QbkwEaAJCmLwZc4l8kZizCLmE=; b=f93gPGzM3LwF50UfHkbwKruxnctabxuLhNK8/05sO5uVGI9UfpZwMFnuTplfEvrhUx v/YKqddU2+DgclsxTqL1540CWteE2ryoewTj54LG3hJmJTAvEPCjZctpSof8wY5u+VE7 bNqHm7zk9mCqDeF/B5ujNZkN3OW6uyOwffK7zrm6amh99LOU7ONTW0w9JCMDrp2nEGIu 8WH4T8ZOEhxmj9lx042N9FJ2z31VXY5wqUEvW6GqlU25gIhWY+X4SnV7SEfhWKz5boBR HykoBRZFs1OB+qgejME+etz1e+tcN6SXgwkBSSVolzhhNOcbMxKUrN/6LSE238+ujiwM sCAw== X-Gm-Message-State: APzg51B9pFwURsTYg2BDWjPGkFIke/GcYwPeEqThNOUAGpg740/AFk4u pvYfTW+F7gcVZ3Id8GEa/xCTgg== X-Google-Smtp-Source: ANB0VdZ2TE703+Co0QLym0A3pHRe2gHn4oJxyxOcpxp0AiHk1ZabCOSsF8QSmcc9Jwmk4jo+0y43XA== X-Received: by 2002:a1c:b441:: with SMTP id d62-v6mr693199wmf.17.1536657481045; Tue, 11 Sep 2018 02:18:01 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:b493:b5af:65cf:aebf? ([2001:660:330f:a4:b493:b5af:65cf:aebf]) by smtp.gmail.com with ESMTPSA id y205-v6sm9837464wmc.3.2018.09.11.02.17.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 02:17:58 -0700 (PDT) From: Luigi Iannone Message-Id: <77109099-A756-4563-968C-5AC17FF38291@gigix.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_722DBC36-275B-4B0C-80DA-04799B4F7825" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 11 Sep 2018 11:17:57 +0200 In-Reply-To: Cc: Dino Farinacci , IETF SecDir , draft-ietf-lisp-rfc6830bis.all@ietf.org, IETF Discussion Mailing List , "lisp@ietf.org list" , Benjamin Kaduk To: Kyle Rose References: <153513922907.22939.10542350679349996082@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-lisp-rfc6830bis-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 09:18:05 -0000 --Apple-Mail=_722DBC36-275B-4B0C-80DA-04799B4F7825 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Kyle, good for you having a break, hope you enjoyed your vacation. Any thoughts about my last email on the subject? Ciao L. > On 11 Sep 2018, at 04:13, Kyle Rose wrote: >=20 > Apologies for the two-week absence: I've been on vacation (especially = from email) for most of that period. >=20 > On Tue, Aug 28, 2018 at 6:17 PM, Dino Farinacci > wrote: > > The whole point of LISP is to create a routing overlay for the EID = address space, the RIB of which is managed by a global mapping system, = not BGP sessions. If control plane traffic managed by BGP (or static = routes, or whatever networks use once the DFZ RIB is limited to entities = in the core) continues to flow, that is of small comfort to end users = trying to get data over the data plane. =46rom the perspective of end = users, BGP is being replaced routing of the traffic that matters to = them. >=20 > That really is not true. You need both the overlay and underlay to get = user traffic to flow. >=20 > Sure, just like you need link layer connectivity and closed circuits. = User traffic is directly handled by the overlay, which is an added layer = of novel complexity. When you add complexity, you inevitably add room = for bugs and mysterious behavior. Anyway, I'm happy to drop this point = for secdir because this is more of a general architectural observation = than something specifically related to security. > =20 > > * It does not resolve the trust anchor problem. Instead of = proposing a PKI, you seem to be proposing a trusted third party = authoritative for the Hash-EID namespace. (Q.v. section 2, the Hash-EID = definition: "Another entity=E2=80=9D) >=20 > The trust anchor is the mapping system. And that is the PKI. And the = mapping system is distributed. >=20 > What PKI? That's part of what I'm trying to establish. How do entities = decide to trust each other? >=20 > E.g., if entity A has pairwise trust with peer B, but needs an EID = mapping for peer C, it needs some way to establish that the replies it's = supposedly receiving from C are genuine. One popular model enabling you = to do that without employing transitive trust is end-to-end signing = chained to a trust anchor. With TLS as deployed on the web today, the = trust anchors are a set of mostly mutually agreed-upon CA certificates = that serve as roots for the certificates presented by every public web = server. There are of course issues with this model (q.v., certificate = transparency, Symantec), but its behavior is well-established and its = properties are understood. What is the equivalent here? >=20 > It sounds like the answer here is mapping system-specific. E.g., from = a quick perusal of the DDT draft, it sounds very DNSSEC-like (which = might suggest a course of action to eliminate the need to develop, = deploy, and maintain a custom security protocol, but that is a different = discussion). >=20 > Where an interface is described without reference to a specific = implementation, a set of assumptions (e.g., "correct routing relies on = the authenticity of mapping system responses") and associated security = requirements for any conforming mapping system (e.g., "entities making = use of mapping system responses must have some way to authenticate them = that does not rely on transitive trust") need to be stated for the = document to be a complete description of a system component. That is, = without first clearly defining the required properties of any valid = implementation of described interfaces, there's no way to evaluate = whether the component under review will do what it's supposed to. >=20 > A good place to put these assumptions and requirements is in the = security considerations section: those statements are not normative for = the system component described by the draft in which they appear, but = are effectively requirements for whatever system component is to = implement that interface in a conforming way. Enumerating them as such = (in the document describing the interface in detail) allows the reader = to evaluate the requirements in light of the system using the interface, = while also providing a convenient checklist for those designing = conforming systems. >=20 > A set of well-crafted security considerations sections also makes it = much easier for a reviewer to understand the security of the system as a = whole without having to understand the details of every implementation, = and to verify that individual system components under review will have = the appropriate behavior. >=20 > I'm going to skip the comments related to = draft-farinacci-lisp-ecdsa-auth, just to limit scope here. We can get = back to it once that document has been adopted and more fully = fleshed-out. >=20 > > "TLS" does not appear anywhere in the draft of LISP-SEC I reviewed: >=20 > Right as I explained DTLS does. >=20 > Check again. Just to be sure, I've tried several tools and the letters = "T", "L", and "S" do not appear consecutively anywhere in this document. = Neither do "SSL" nor "transport-level security". > =20 > > I would like to see a discussion of whether and how the nature and = scale of this problem differs from that of the status quo. BGP sessions = and RIB push have properties that are well-established from decades of = experience: surely LISP does not have exactly the same properties. The = security considerations should make clear, for instance, how a loss of = control plane connectivity differs from the loss of a BGP session, and = how this impacts visibility and behavior of the data plane. >=20 > Please look at the deployment drafts. Please note, you are reviewing a = document that is focusing on encapsulating packets on an overlay. All = the other support pieces are broken out, in what the WG felt was = logical, in sepreate documents. >=20 > I think this gets back to the point I made at the end of my original = review, which is that this system is difficult to evaluate from a = security perspective in a piecewise manner given the dependencies = between the different layers and the lack of explicitly-enumerated = security requirements for each system component implementing a given = interface. >=20 > Kyle --Apple-Mail=_722DBC36-275B-4B0C-80DA-04799B4F7825 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Kyle,

good for you = having a break, hope you enjoyed your vacation.

Any thoughts about my last email on the = subject?

Ciao

L.


On 11 = Sep 2018, at 04:13, Kyle Rose <krose@krose.org> wrote:

Apologies for the = two-week absence: I've been on vacation (especially from email) for most = of that period.

On Tue, Aug 28, 2018 at 6:17 PM, Dino = Farinacci <farinacci@gmail.com> wrote:
> The = whole point of LISP is to create a routing overlay for the EID address = space, the RIB of which is managed by a global mapping system, not BGP = sessions. If control plane traffic managed by BGP (or static routes, or = whatever networks use once the DFZ RIB is limited to entities in the = core) continues to flow, that is of small comfort to end users trying to = get data over the data plane. =46rom the perspective of end users, BGP = is being replaced routing of the traffic that matters to them.

That really is not true. You need both the overlay and underlay = to get user traffic to flow.

Sure, just like you need = link layer connectivity and closed circuits. User traffic is directly = handled by the overlay, which is an added layer of novel complexity. = When you add complexity, you inevitably add room for bugs and mysterious = behavior. Anyway, I'm happy to drop this point for secdir because this = is more of a general architectural observation than something = specifically related to security.
 
>  * It does not resolve the trust anchor = problem. Instead of proposing a PKI, you seem to be proposing a trusted = third party authoritative for the Hash-EID namespace. (Q.v. section 2, = the Hash-EID definition: "Another entity=E2=80=9D)

The trust anchor is the mapping system. And that is the PKI. And = the mapping system is distributed.

What PKI? That's part of = what I'm trying to establish. How do entities decide to trust each = other?

E.g., = if entity A has pairwise trust with peer B, but needs an EID mapping for = peer C, it needs some way to establish that the replies it's supposedly = receiving from C are genuine. One popular model enabling you to do that = without employing transitive trust is end-to-end signing chained to a = trust anchor. With TLS as deployed on the web today, the trust anchors = are a set of mostly mutually agreed-upon CA certificates that serve as = roots for the certificates presented by every public web server. There = are of course issues with this model (q.v., certificate transparency, = Symantec), but its behavior is well-established and its properties are = understood. What is the equivalent here?

It sounds like the answer here is = mapping system-specific. E.g., from a quick perusal of the DDT draft, it = sounds very DNSSEC-like (which might suggest a course of action to = eliminate the need to develop, deploy, and maintain a custom security = protocol, but that is a different discussion).

Where an interface is described without = reference to a specific implementation, a set of assumptions (e.g., = "correct routing relies on the authenticity of mapping system = responses") and associated security requirements for any conforming = mapping system (e.g., "entities making use of mapping system responses = must have some way to authenticate them that does not rely on transitive = trust") need to be stated for the document to be a complete description = of a system component. That is, without first clearly defining the = required properties of any valid implementation of described interfaces, = there's no way to evaluate whether the component under review will do = what it's supposed to.

A good place to put these assumptions and requirements is in = the security considerations section: those statements are not normative = for the system component described by the draft in which they appear, = but are effectively requirements for whatever system component is to = implement that interface in a conforming way. Enumerating them as such = (in the document describing the interface in detail) allows the reader = to evaluate the requirements in light of the system using the interface, = while also providing a convenient checklist for those designing = conforming systems.

A set of well-crafted security considerations sections also = makes it much easier for a reviewer to understand the security of the = system as a whole without having to understand the details of every = implementation, and to verify that individual system components under = review will have the appropriate behavior.

I'm going to skip the = comments related to draft-farinacci-lisp-ecdsa-auth, just to limit scope = here. We can get back to it once that document has been adopted and more = fully fleshed-out.

> "TLS" = does not appear anywhere in the draft of LISP-SEC I reviewed:

Right as I explained DTLS does.

Check again. Just to be = sure, I've tried several tools and the letters "T", "L", and "S" do not = appear consecutively anywhere in this document. Neither do "SSL" nor = "transport-level security".
 
> I would like to see a discussion of whether and how the nature and = scale of this problem differs from that of the status quo. BGP sessions = and RIB push have properties that are well-established from decades of = experience: surely LISP does not have exactly the same properties. The = security considerations should make clear, for instance, how a loss of = control plane connectivity differs from the loss of a BGP session, and = how this impacts visibility and behavior of the data plane.
=
Please look at the deployment drafts. Please note, you are = reviewing a document that is focusing on encapsulating packets on an = overlay. All the other support pieces are broken out, in what the WG = felt was logical, in sepreate documents.

I think this gets back = to the point I made at the end of my original review, which is that this = system is difficult to evaluate from a security perspective in a = piecewise manner given the dependencies between the different layers and = the lack of explicitly-enumerated security requirements for each system = component implementing a given interface.

Kyle

= --Apple-Mail=_722DBC36-275B-4B0C-80DA-04799B4F7825-- From nobody Tue Sep 11 05:43:42 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 987BE130E7E for ; Tue, 11 Sep 2018 05:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.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 YBfcuCq9koOe for ; Tue, 11 Sep 2018 05:43:33 -0700 (PDT) Received: from mail-qt0-x244.google.com (mail-qt0-x244.google.com [IPv6:2607:f8b0:400d:c0d::244]) (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 A483C130E80 for ; Tue, 11 Sep 2018 05:43:33 -0700 (PDT) Received: by mail-qt0-x244.google.com with SMTP id t39-v6so27953700qtc.8 for ; Tue, 11 Sep 2018 05:43:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-transfer-encoding; bh=g3w3pfMS+kStqWG8yp2FmV9inHD9LQoOE3hWP6lE7X8=; b=0aAhAallZLMHZHHmXZOJgTT3zR9/gLlcZ+i8o8fXkJbXVorkecK4WHt5kXmW/d/k+k 1h236ht0pgVr5yMjIid8VC5BGHUvz+vRn9UgsRBLfR+B2SxnXoyT4DKQXwWQcf71fBo3 RD+a0tVddkli7g74JJNZKu1r26jJ1SToPvaso= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version:content-transfer-encoding; bh=g3w3pfMS+kStqWG8yp2FmV9inHD9LQoOE3hWP6lE7X8=; b=pwXBLehmbHbYAE7wDWR8hsELPw95/nO8GHzrnkGerm6SWJj35l0W0gABnLSc1li5Dw X4gk0knIAb3MM8C44SvYL6YbCkEBwy3ba+C7loopkf61d7y/7wDsDk3wQth9Rl8HAhb/ CscFGgLFMHr2CFBZnRKnOL1edQsvd8i52JmV4wO9JgROucdM5Q23VuIKLhlW2fmTvEJC p8PrIcAB9ReoeI4Md/1pMA0fa2Y6RIvf2yA32jUjn9XeHSwWpL7DIa57vVYh88seljCb JkqdbmzEqo/Wnh9/NJBM1tWYhefCKi0LwTPPCnxI8eBvMQqPB4rJlrRO9GFSUb8TFcAm kiYg== X-Gm-Message-State: APzg51DFyqW0GVrk60nPahwEHG5JHaqYARQDVbYf36Jl7SJHi/GKFRp9 dwbfmRY5p6VJbh478O3If++Rc5ugRH27XA== X-Google-Smtp-Source: ANB0Vda7loCNu4QMRpNPSQWa7jkRbRjHDMSUNg/bLxB34c9pe450+u/9A7gH2W6rwI4z6+eE5h1D3w== X-Received: by 2002:ac8:7a98:: with SMTP id x24-v6mr19688902qtr.298.1536669810219; Tue, 11 Sep 2018 05:43:30 -0700 (PDT) Received: from [192.168.2.27] (pool-108-28-91-61.washdc.fios.verizon.net. [108.28.91.61]) by smtp.googlemail.com with ESMTPSA id i85-v6sm14394330qkh.3.2018.09.11.05.43.15 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 11 Sep 2018 05:43:20 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.7.6.170621 Date: Tue, 11 Sep 2018 08:43:11 -0400 From: Carl Wallace To: , The IESG , Message-ID: Thread-Topic: secdir review of draft-ietf-tram-stun-pmtud Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: [secdir] secdir review of draft-ietf-tram-stun-pmtud X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 12:43:36 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes a Session Traversal Utilities for NAT (STUN) usage for Path MTU Discovery (PMTUD) between a client and a server. A few comments (bearing in mind I am not versed in STUN specs): - It may be worth highlighting the requirement for authentication when providing an overview of the Complete Probing mechanism in section 2. - In section 4, replace "Simple Probing mechanism does not require authentication" with "Simple Probing mechanism does not require authentication except where used as an implicit signaling mechanism". - Complete Probing and some uses of Simple Probing require authentication. Are there any authentication mechanisms that must be supported? - The second paragraph of the introduction and first paragraph of section 5 open the use of the spec to non-STUN-based protocols may not square with all of the MUSTs in the document, some of which require STUN (like section 4.1.x). - Why is 5780 marked as informative? Attributes from it are required. From nobody Tue Sep 11 08:30:00 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF4E130EA4; Tue, 11 Sep 2018 08:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svvOyvUcLcj8; Tue, 11 Sep 2018 08:29:56 -0700 (PDT) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 1D686130EA1; Tue, 11 Sep 2018 08:29:56 -0700 (PDT) Received: by mail-pl1-x62e.google.com with SMTP id g2-v6so10542824plo.2; Tue, 11 Sep 2018 08:29:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jF+8TQINnxPKjifCU3kT3vw3vissMNt7qkMzv0fUuFA=; b=b2lGTiX4u3yD62pZXqOzcZjeeIn2ZvCeenvaPjqdAg+ovHZqeJd5FpehdKvTO1zxzG toquadjCLSZ77xdZSuLf1gU7RD0IAYUB6v+cs7MveMBT2lEuZmvziDmigK4SR4GCUcIj pFl7RP3u0uAKpUP10GL9uFwFPEF8zTw44gMXoaV+8EtLBJYbDBwTaTItdbB0rDkH6jnd gYDFHAQ1vy5OlUgRu5vaaVEnTp1Y+wKnRYLd7Js/xK1WBiTW2iFwCjAn4D05+FxHhWc3 XmFK530Jno2WWl6dcboc1eqcr6+NwKCsUKIBkHv46soXw12en0kLPU5G5B8yhQ4w/8rl tJ0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jF+8TQINnxPKjifCU3kT3vw3vissMNt7qkMzv0fUuFA=; b=duzOobK/TT7A1lqmCyWrhKG3c0IIryY4pIZi+7Ya6Mnau8kXDg2GAM4H/he8tvhhXc TGEbj6d5q1Z0SPX52ECvEJjLZLSw7Loln7wbVExSrDC39xCkIUpZo4hX6sMyLKrtJwsC dBxD+OLcIzmHS3EQfMz3es9Yc3n59GGeNZ3JVgFY8WdS4Vi5JY/rMTrkf/OYtGZgxpO3 3l8oOobH79Hhvp/yCou859Zl8Cc1s/npAk1tcGSpKkoNBY+eHYvfe9Cq029/0GftmoB9 r8WMspjX/I05Rl0FmMN2DOGl9bd2hU8blL1mTVFEpWSeqQGZ4SEiqqKvVpJhMuZ5bilP WyLA== X-Gm-Message-State: APzg51AfyMpvodYd0OaAIZe/CFyWAP6dsp/mrDTb2ZgYYUJirQ4cQBdt YI4wNuFhc4Ob4NqAzLnZNdUrbuSA X-Google-Smtp-Source: ANB0VdYO30ybDhXU8bKuUb7aM6tT5efPYpTj0x4E8ihBYwYPFQvg3LVXOG0kGoGrvTl7PB3PlC9RZw== X-Received: by 2002:a17:902:6b0b:: with SMTP id o11-v6mr27751810plk.214.1536679795621; Tue, 11 Sep 2018 08:29:55 -0700 (PDT) Received: from [10.31.79.252] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id f184-v6sm40166076pfc.88.2018.09.11.08.29.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 08:29:54 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: Date: Tue, 11 Sep 2018 08:29:53 -0700 Cc: IETF SecDir , draft-ietf-lisp-rfc6830bis.all@ietf.org, IETF Discussion Mailing List , "lisp@ietf.org list" , Benjamin Kaduk Content-Transfer-Encoding: quoted-printable Message-Id: <430EA55E-6D40-45A1-99D3-0978F1B20038@gmail.com> References: <153513922907.22939.10542350679349996082@ietfa.amsl.com> To: Kyle Rose X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-lisp-rfc6830bis-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 15:29:59 -0000 Responding. The draft-ietf-lisp-sec authors need to respond to one of = your points below about DTLS. > On Sep 10, 2018, at 7:13 PM, Kyle Rose wrote: >=20 > What PKI? That's part of what I'm trying to establish. How do entities = decide to trust each other? The xTRs has a trust association with the mapping system because they = have (1) a business relationship with them and (2) a shared-key that is = used to verify Map-Register messages. =46rom that, Map-Registers and = Map-Requests are can be signed where public-keys are stored by that = trusted mapping system. That is what is documented in = draft-farinacci-lisp-ecdsa-auth-03, and soon to be = draft-ietf-lisp-ecdsa-auth-00 (hopefully). > E.g., if entity A has pairwise trust with peer B, but needs an EID = mapping for peer C, it needs some way to establish that the replies it's = supposedly receiving from C are genuine. One popular model enabling The mapping system allows all of A-C to trust each other. > you to do that without employing transitive trust is end-to-end = signing chained to a trust anchor. With TLS as deployed on the web = today, the trust anchors are a set of mostly mutually agreed-upon CA = certificates that serve as roots for the certificates presented by every = public web server. There are of course issues with this model (q.v., = certificate transparency, Symantec), but its behavior is = well-established and its properties are understood. What is the = equivalent here? >=20 > It sounds like the answer here is mapping system-specific. E.g., from = a quick perusal of the DDT draft, it sounds very DNSSEC-like (which = might suggest a course of action to eliminate the need to develop, = deploy, and maintain a custom security protocol, but that is a different = discussion). >=20 > Where an interface is described without reference to a specific = implementation, a set of assumptions (e.g., "correct routing relies on = the authenticity of mapping system responses") and associated security = requirements for any conforming mapping system (e.g., "entities making = use of mapping system responses must have some way to authenticate them = that does not rely on transitive trust") need to be stated for the = document to be a complete description of a system component. That is, = without first clearly defining the required properties of any valid = implementation of described interfaces, there's no way to evaluate = whether the component under review will do what it's supposed to. >=20 > A good place to put these assumptions and requirements is in the = security considerations section: those statements are not normative for = the system component described by the draft in which they appear, but = are effectively requirements for whatever system component is to = implement that interface in a conforming way. Enumerating them as such = (in the document describing the interface in detail) allows the reader = to evaluate the requirements in light of the system using the interface, = while also providing a convenient checklist for those designing = conforming systems. The designs are done, the references in the various specs are modest = because of the state of the documents. We are sorry for it being hard to = navigate. But for me, I am for less documents versus more, but the = working group wants more modularity in the documentation so hence why = all the pieces don=E2=80=99t seem to be connected (but they are by the = security design of LISP). > A set of well-crafted security considerations sections also makes it = much easier for a reviewer to understand the security of the system as a = whole without having to understand the details of every implementation, = and to verify that individual system components under review will have = the appropriate behavior. >=20 > I'm going to skip the comments related to = draft-farinacci-lisp-ecdsa-auth, just to limit scope here. We can get = back to it once that document has been adopted and more fully = fleshed-out. >=20 > > "TLS" does not appear anywhere in the draft of LISP-SEC I reviewed: >=20 > Right as I explained DTLS does. >=20 > Check again. Just to be sure, I've tried several tools and the letters = "T", "L", and "S" do not appear consecutively anywhere in this document. = Neither do "SSL" nor "transport-level security=E2=80=9D. The draft-ietf-lisp-sec authors need to comment. > > I would like to see a discussion of whether and how the nature and = scale of this problem differs from that of the status quo. BGP sessions = and RIB push have properties that are well-established from decades of = experience: surely LISP does not have exactly the same properties. The = security considerations should make clear, for instance, how a loss of = control plane connectivity differs from the loss of a BGP session, and = how this impacts visibility and behavior of the data plane. >=20 > Please look at the deployment drafts. Please note, you are reviewing a = document that is focusing on encapsulating packets on an overlay. All = the other support pieces are broken out, in what the WG felt was = logical, in sepreate documents. >=20 > I think this gets back to the point I made at the end of my original = review, which is that this system is difficult to evaluate from a = security perspective in a piecewise manner given the dependencies = between the different layers and the lack of explicitly-enumerated = security requirements for each system component implementing a given = interface. >=20 > Kyle I don=E2=80=99t know how to move forward from here. I think we need help = from the lisp-chairs and Deborah. Dino From nobody Tue Sep 11 09:41:04 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A34128CF2 for ; Tue, 11 Sep 2018 09:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.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 QwrrjfK5GYiV for ; Tue, 11 Sep 2018 09:40:52 -0700 (PDT) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 96D7C1293FB for ; Tue, 11 Sep 2018 09:40:52 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id c126-v6so17164495qkd.7 for ; Tue, 11 Sep 2018 09:40:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/bpDNXkFidMPnjzTu4buW2A9tvBBViqCUENYjpd+OGk=; b=IcxdOu9RnireLun38gdIlCHIHBEwBeLqLpyVuRY1bPhRvrKAGpSQqToMbIG6QakA+t R3eyVXnc7HwAIUgjieCatDXK7rN/sqBXvYZ5e8dNGyz+tOJosB9F2ZtvqK/ScoW9biWn 9S3h11G7jaPvXCkHGqb+u49hnHpYiHPFquklk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/bpDNXkFidMPnjzTu4buW2A9tvBBViqCUENYjpd+OGk=; b=fNwmbL7TTiE+z6UwBQ/1E/Kog+3bMLFhs7TBcYxelwIiWtfY8t3MR8XiFGVa2eitf+ oYqPop7vtayxqLUU50g8qCNGuikb6eRqxNq5vhI/rGTEr2JQhFV9PXBNTmCcCEGoIMdE YiOVgsYGTWheRUQWyIGt84rdesKqLVaMQlKeQPQdNy4WBr+aPsvo6HxrB6yJvYCf3+x0 C7aZW//E0XPA3IWbHUPNOHCAAsReXfu4MBlBARb8UnBxcYhkH0NDV0UTHDJ0+kHVWOlm EagTHEKj6qa+lj09WVPuon116H6s5jKnLExCbOS1U1CswEgpijv16ZntWGkiftOFfDf+ UUrQ== X-Gm-Message-State: APzg51Cj6+EhxUvUZpH5+dDOMifWxXncj5wmRRJLAVnn1bQ01si8tmml gIEqc7mQ2W6/AfclTl9Rx1sv31AxKXJIAYhtZfwI9w== X-Google-Smtp-Source: ANB0VdZJTTV7/fT4BuuinqLkoEJJv4A65jrWrsFpVjdBAk+wFlnC9zsiepzUlSiM44b4QsK0W89aM8+oJfP8yKnXEdU= X-Received: by 2002:a37:2381:: with SMTP id j123-v6mr19155128qkj.259.1536684051442; Tue, 11 Sep 2018 09:40:51 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a0c:86ea:0:0:0:0:0 with HTTP; Tue, 11 Sep 2018 09:40:50 -0700 (PDT) X-Originating-IP: [2001:4878:a000:3000:b804:b2b6:546:6e10] In-Reply-To: <430EA55E-6D40-45A1-99D3-0978F1B20038@gmail.com> References: <153513922907.22939.10542350679349996082@ietfa.amsl.com> <430EA55E-6D40-45A1-99D3-0978F1B20038@gmail.com> From: Kyle Rose Date: Tue, 11 Sep 2018 12:40:50 -0400 Message-ID: To: Dino Farinacci Cc: IETF SecDir , draft-ietf-lisp-rfc6830bis.all@ietf.org, IETF Discussion Mailing List , "lisp@ietf.org list" , Benjamin Kaduk Content-Type: multipart/alternative; boundary="00000000000004c5aa05759b23ed" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-lisp-rfc6830bis-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 16:40:56 -0000 --00000000000004c5aa05759b23ed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Sep 11, 2018 at 11:29 AM, Dino Farinacci wrote: > > E.g., if entity A has pairwise trust with peer B, but needs an EID > mapping for peer C, it needs some way to establish that the replies it's > supposedly receiving from C are genuine. One popular model enabling > > The mapping system allows all of A-C to trust each other. > Explain how with a detailed example, or point me to a detailed explanation in a specific document. The mechanism is still not entirely clear to me. If A and C don't have an established business relationship, how does A know that the responses it's getting for EID mappings owned by C are genuine and not modified by B? This is a critical property of the system, and so it needs to be made obvious to the reader. > The designs are done, the references in the various specs are modest > because of the state of the documents. We are sorry for it being hard to > navigate. But for me, I am for less documents versus more, but the workin= g > group wants more modularity in the documentation so hence why all the > pieces don=E2=80=99t seem to be connected (but they are by the security d= esign of > LISP). > I agree with, and am not taking issue with, modularity: no one wants a monolithic design for something this complex. But the interfaces between the documents, by which I mean the requirements they impose on each other, must be made explicit. When a system achieves complexity warranting design modularity, it's simply not sufficient to describe individual system components without providing a framework for analyzing how they fit together without having to read and fully understand all of it. All the information *might* in fact be there, but as an outsider not implementing LISP, and with finite time to review, asking me to understand the minutiae of the entire LISP ecosystem in order to understand the security properties of the overall system is simply not reasonable. I should be able to consume a high-level architectural overview, containing sufficient detail to understand the security properties of the overall system, and then use that to drill into areas of concern more deeply. This is why I want the high-level security requirements documented somewhere, along with a set of high-level explanations of how the proposed system components combine to satisfy them. Put another way: as someone whose day job it is to read and review design documents and to offer architectural consulting on everything from from network architecture and hardware design to build automation and SDLC tools to dynamic job orchestration and application security, being able to achieve a high-level mental picture of the critical properties of a design is an important first step in evaluating a system's fitness for a particular task. Document authors have a responsibility to make their work consumable by people who don't already have the full context. Kyle --00000000000004c5aa05759b23ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Sep 11, 2018 at 11:29 AM, Dino Farinacci <farinacci@gmail.com&g= t; wrote:
> E.= g., if entity A has pairwise trust with peer B, but needs an EID mapping fo= r peer C, it needs some way to establish that the replies it's supposed= ly receiving from C are genuine. One popular model enabling

The mapping system allows all of A-C to trust each other.

Explain how with a detailed example, or point me = to a detailed explanation in a specific document. The mechanism is still no= t entirely clear to me. If A and C don't have an established business r= elationship, how does A know that the responses it's getting for EID ma= ppings owned by C are genuine and not modified by B? This is a critical pro= perty of the system, and so it needs to be made obvious to the reader.
<= /div>
=C2=A0
The designs are done, the references in the various specs are modest becaus= e of the state of the documents. We are sorry for it being hard to navigate= . But for me, I am for less documents versus more, but the working group wa= nts more modularity in the documentation so hence why all the pieces don=E2= =80=99t seem to be connected (but they are by the security design of LISP).=

I agree with, and am not taking issue = with, modularity: no one wants a monolithic design for something this compl= ex. But the interfaces between the documents, by which I mean the requireme= nts they impose on each other, must be made explicit. When a system achieve= s complexity warranting design modularity, it's simply not sufficient t= o describe individual system components without providing a framework for a= nalyzing how they fit together without having to read and fully understand = all of it. All the information *might* in fact be there, but as an outsider= not implementing LISP, and with finite time to review, asking me to unders= tand the minutiae of the entire LISP ecosystem in order to understand the s= ecurity properties of the overall system is simply not reasonable. I should= be able to consume a high-level architectural overview, containing suffici= ent detail to understand the security properties of the overall system, and= then use that to drill into areas of concern more deeply. This is why I wa= nt the high-level security requirements documented somewhere, along with a = set of high-level explanations of how the proposed system components combin= e to satisfy them.

Put another way: as someone= whose day job it is to read and review design documents and to offer archi= tectural consulting on everything from from network architecture and hardwa= re design to build automation and SDLC tools to dynamic job orchestration a= nd application security, being able to achieve a high-level mental picture = of the critical properties of a design is an important first step in evalua= ting a system's fitness for a particular task. Document authors have a= responsibility to make their work consumable by people who don't alrea= dy have the full context.
=C2=A0
Kyle
--00000000000004c5aa05759b23ed-- From nobody Tue Sep 11 09:48:46 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C99130FC2 for ; Tue, 11 Sep 2018 09:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.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 mpKB4XN2BvTh for ; Tue, 11 Sep 2018 09:48:31 -0700 (PDT) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 A9746131176 for ; Tue, 11 Sep 2018 09:48:27 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id 93-v6so17166359qks.3 for ; Tue, 11 Sep 2018 09:48:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=X2fhHEN+ZyCDFM3jVfcRm0t4+SP+/VD37ofszG8PoIQ=; b=YqxbVYgVGtA8kgLeDad2fNIMYHLG9KdrLEqIEDOjKSZi2ktZAutSJ3M41D9WbieiJY NPn3MhWT5QRhPHLCk8I/uMBrpg7ANSZJnN1kkV6d28/+B+tZL7WcB/xjuqVVlvr9YTm3 jZ+ygM/vfIZ5qCeidT8Awe9RG+bBAIfmLz4Hc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=X2fhHEN+ZyCDFM3jVfcRm0t4+SP+/VD37ofszG8PoIQ=; b=T7gs5i00lkFwcrYGEkjF/OmdjpDyl6QhHuIozQkmA4Gar3c0dJm3PgRWsgF/QD9aet Ww1Kl35GBN1xPYlxA48tCLK73DnWkB10qjB98SMzB/X1BVZOM7UBpEBPPQEZ+O4bKC2t fT2UwB3GSvaCeHhFhwkmNocKgy/iEsme3OOMmffa6QF19yyhkMUIKJfZsi2HGTXhf/8u 8YYSmMWr2SXwVNHnbxUcxF6fQ5iPUoI6gMlxpHn9ayCUIXK4tjBBjMMkVqZNWYlmjh2J p6RKVXSVzVd0QTeBtYTlpc23Zbk7QE8WtsMK2/IpvlE626dSWfFvKO26H9cvRGExm/uU PrAw== X-Gm-Message-State: APzg51ALfhe9x6iUqk89/gkZT27RDrr7m6TAhsss2EOD0rgXDv7NGKdA OniP6MNd6hQVB1DGyiop2QUPEDY/bYeFb2ls8Lpd2A== X-Google-Smtp-Source: ANB0VdZMmNcAFB01I++cNiK22cTaKGOVmu/jyc6u6v0xrl4FAhl81RwXLUK1cvKTD4Fya0ivPUhJIxuZlfTAthvFH/U= X-Received: by 2002:ae9:e8d8:: with SMTP id a207-v6mr20018909qkg.235.1536684506663; Tue, 11 Sep 2018 09:48:26 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a0c:86ea:0:0:0:0:0 with HTTP; Tue, 11 Sep 2018 09:48:26 -0700 (PDT) X-Originating-IP: [2001:4878:a000:3000:b804:b2b6:546:6e10] In-Reply-To: <77109099-A756-4563-968C-5AC17FF38291@gigix.net> References: <153513922907.22939.10542350679349996082@ietfa.amsl.com> <77109099-A756-4563-968C-5AC17FF38291@gigix.net> From: Kyle Rose Date: Tue, 11 Sep 2018 12:48:26 -0400 Message-ID: To: Luigi Iannone Cc: Dino Farinacci , IETF SecDir , draft-ietf-lisp-rfc6830bis.all@ietf.org, IETF Discussion Mailing List , "lisp@ietf.org list" , Benjamin Kaduk Content-Type: multipart/alternative; boundary="00000000000026e15b05759b3ef0" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-lisp-rfc6830bis-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 16:48:40 -0000 --00000000000026e15b05759b3ef0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree that the first point is probably not secdir-related, but it is still something that should be addressed. To the second point re: RFC 7835 and resource attacks on control vs. data plane, what I want to see is an analysis for operators of novel attack vectors that are created by LISP. For instance, the threat mitigation section says: q( The control plane is the most critical part of LISP from a security viewpoint, and it is worth noticing that the LISP specifications already offer an authentication mechanism for mappings registration [RFC6833]. This mechanism, combined with LISP-SEC [LISP-SEC], strongly mitigates threats in non-trustable environments such as the Internet. Moreover, an authentication data field for Map-Request messages and Encapsulated Control messages was allocated [RFC6830]. This field provides a general authentication mechanism technique for the LISP control plane that future specifications may use while staying backward compatible. The exact technique still has to be designed and defined. To maximally mitigate the threats on the mapping system, authentication must be used, whenever possible, for both Map-Request and Map-Reply messages and for messages exchanged internally among elements of the mapping system, such as specified in [LISP-SEC] and [LISP-DDT]. Systematically applying filters and rate limitation, as proposed in [RFC6830], will mitigate most of the threats presented in this document. In order to minimize the risk of overloading the control plane with actions triggered from data-plane events, such actions should be rate limited. ) but this doesn't specifically address the fact that a pull-based control plane will fail in a different way, and one that is potentially harder to diagnose, from a push-based one. One area in which it differs is that a loss of a BGP session followed by a network partition is obvious to all users trying to move traffic between those two networks, while choking off control plane traffic in LISP may only affect some endpoints in a mysterious way. Kyle On Tue, Sep 11, 2018 at 5:17 AM, Luigi Iannone wrote: > Hi Kyle, > > good for you having a break, hope you enjoyed your vacation. > > Any thoughts about my last email on the subject? > > Ciao > > L. > > > On 11 Sep 2018, at 04:13, Kyle Rose wrote: > > Apologies for the two-week absence: I've been on vacation (especially fro= m > email) for most of that period. > > On Tue, Aug 28, 2018 at 6:17 PM, Dino Farinacci > wrote: > >> > The whole point of LISP is to create a routing overlay for the EID >> address space, the RIB of which is managed by a global mapping system, n= ot >> BGP sessions. If control plane traffic managed by BGP (or static routes,= or >> whatever networks use once the DFZ RIB is limited to entities in the cor= e) >> continues to flow, that is of small comfort to end users trying to get d= ata >> over the data plane. From the perspective of end users, BGP is being >> replaced routing of the traffic that matters to them. >> >> That really is not true. You need both the overlay and underlay to get >> user traffic to flow. >> > > Sure, just like you need link layer connectivity and closed circuits. Use= r > traffic is directly handled by the overlay, which is an added layer of > novel complexity. When you add complexity, you inevitably add room for bu= gs > and mysterious behavior. Anyway, I'm happy to drop this point for secdir > because this is more of a general architectural observation than somethin= g > specifically related to security. > > >> > * It does not resolve the trust anchor problem. Instead of proposing = a >> PKI, you seem to be proposing a trusted third party authoritative for th= e >> Hash-EID namespace. (Q.v. section 2, the Hash-EID definition: "Another >> entity=E2=80=9D) >> >> The trust anchor is the mapping system. And that is the PKI. And the >> mapping system is distributed. >> > > What PKI? That's part of what I'm trying to establish. How do entities > decide to trust each other? > > E.g., if entity A has pairwise trust with peer B, but needs an EID mappin= g > for peer C, it needs some way to establish that the replies it's supposed= ly > receiving from C are genuine. One popular model enabling you to do that > without employing transitive trust is end-to-end signing chained to a tru= st > anchor. With TLS as deployed on the web today, the trust anchors are a se= t > of mostly mutually agreed-upon CA certificates that serve as roots for th= e > certificates presented by every public web server. There are of course > issues with this model (q.v., certificate transparency, Symantec), but it= s > behavior is well-established and its properties are understood. What is t= he > equivalent here? > > It sounds like the answer here is mapping system-specific. E.g., from a > quick perusal of the DDT draft, it sounds very DNSSEC-like (which might > suggest a course of action to eliminate the need to develop, deploy, and > maintain a custom security protocol, but that is a different discussion). > > Where an interface is described without reference to a specific > implementation, a set of assumptions (e.g., "correct routing relies on th= e > authenticity of mapping system responses") and associated security > requirements for any conforming mapping system (e.g., "entities making us= e > of mapping system responses must have some way to authenticate them that > does not rely on transitive trust") need to be stated for the document to > be a complete description of a system component. That is, without first > clearly defining the required properties of any valid implementation of > described interfaces, there's no way to evaluate whether the component > under review will do what it's supposed to. > > A good place to put these assumptions and requirements is in the security > considerations section: those statements are not normative for the system > component described by the draft in which they appear, but are effectivel= y > requirements for whatever system component is to implement that interface > in a conforming way. Enumerating them as such (in the document describing > the interface in detail) allows the reader to evaluate the requirements i= n > light of the system using the interface, while also providing a convenien= t > checklist for those designing conforming systems. > > A set of well-crafted security considerations sections also makes it much > easier for a reviewer to understand the security of the system as a whole > without having to understand the details of every implementation, and to > verify that individual system components under review will have the > appropriate behavior. > > I'm going to skip the comments related to draft-farinacci-lisp-ecdsa-auth= , > just to limit scope here. We can get back to it once that document has be= en > adopted and more fully fleshed-out. > > > "TLS" does not appear anywhere in the draft of LISP-SEC I reviewed: >> >> Right as I explained DTLS does. >> > > Check again. Just to be sure, I've tried several tools and the letters > "T", "L", and "S" do not appear consecutively anywhere in this document. > Neither do "SSL" nor "transport-level security". > > >> > I would like to see a discussion of whether and how the nature and >> scale of this problem differs from that of the status quo. BGP sessions = and >> RIB push have properties that are well-established from decades of >> experience: surely LISP does not have exactly the same properties. The >> security considerations should make clear, for instance, how a loss of >> control plane connectivity differs from the loss of a BGP session, and h= ow >> this impacts visibility and behavior of the data plane. >> >> Please look at the deployment drafts. Please note, you are reviewing a >> document that is focusing on encapsulating packets on an overlay. All th= e >> other support pieces are broken out, in what the WG felt was logical, in >> sepreate documents. >> > > I think this gets back to the point I made at the end of my original > review, which is that this system is difficult to evaluate from a securit= y > perspective in a piecewise manner given the dependencies between the > different layers and the lack of explicitly-enumerated security > requirements for each system component implementing a given interface. > > Kyle > > > --00000000000026e15b05759b3ef0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree that the fi= rst point is probably not secdir-related, but it is still something that sh= ould be addressed.

To the second point re: RFC 783= 5 and resource attacks on control vs. data plane, what I want to see is an = analysis for operators of novel attack vectors that are created by LISP. Fo= r instance, the threat mitigation section says:

q(= The control plane is the most critical part of LISP from a security
=C2= =A0=C2=A0 viewpoint, and it is worth noticing that the LISP specifications<= br>=C2=A0=C2=A0 already offer an authentication mechanism for mappings regi= stration
=C2=A0=C2=A0 [RFC6833].=C2=A0 This mechanism, combined with LIS= P-SEC [LISP-SEC],
=C2=A0=C2=A0 strongly mitigates threats in non-trustab= le environments such as the
=C2=A0=C2=A0 Internet.=C2=A0 Moreover, an au= thentication data field for Map-Request
=C2=A0=C2=A0 messages and Encaps= ulated Control messages was allocated [RFC6830].
=C2=A0=C2=A0 This field= provides a general authentication mechanism technique for
=C2=A0=C2=A0 = the LISP control plane that future specifications may use while
=C2=A0= =C2=A0 staying backward compatible.=C2=A0 The exact technique still has to = be
=C2=A0=C2=A0 designed and defined.=C2=A0 To maximally mitigate the th= reats on the
=C2=A0=C2=A0 mapping system, authentication must be used, w= henever possible, for
=C2=A0=C2=A0 both Map-Request and Map-Reply messag= es and for messages exchanged
=C2=A0=C2=A0 internally among elements of = the mapping system, such as specified in
=C2=A0=C2=A0 [LISP-SEC] and [LI= SP-DDT].

=C2=A0=C2=A0 Systematically applying filters and rate limit= ation, as proposed in
=C2=A0=C2=A0 [RFC6830], will mitigate most of the = threats presented in this
=C2=A0=C2=A0 document.=C2=A0 In order to minim= ize the risk of overloading the control
=C2=A0=C2=A0 plane with actions = triggered from data-plane events, such actions
=C2=A0=C2=A0 should be ra= te limited. )

but this doesn't specifically ad= dress the fact that a pull-based control plane will fail in a different way= , and one that is potentially harder to diagnose, from a push-based one. On= e area in which it differs is that a loss of a BGP session followed by a ne= twork partition is obvious to all users trying to move traffic between thos= e two networks, while choking off control plane traffic in LISP may only af= fect some endpoints in a mysterious way.

Kyle
<= /div>

On Tue, Sep 11, 2018 at 5:17 AM, Luigi Iannone <= ggx@gigix.net> wrote:
Hi Kyle,

good for yo= u having a break, hope you enjoyed your vacation.

= Any thoughts about my last email on the subject?

C= iao

L.


On 11 Sep 2018, at 04:13, Kyle Rose <krose@krose.org> wrote:
<= br class=3D"m_-8526680949437643856Apple-interchange-newline">
Apologies for the two-week absence: I've= been on vacation (especially from email) for most of that period.

On Tue, Aug 28, 2018 at 6:17 PM, Dino Farinacci <fa= rinacci@gmail.com> wrote:
<= span class=3D"m_-8526680949437643856gmail-">> The whole point of LISP is= to create a routing overlay for the EID address space, the RIB of which is= managed by a global mapping system, not BGP sessions. If control plane tra= ffic managed by BGP (or static routes, or whatever networks use once the DF= Z RIB is limited to entities in the core) continues to flow, that is of sma= ll comfort to end users trying to get data over the data plane. From the pe= rspective of end users, BGP is being replaced routing of the traffic that m= atters to them.

That really is not true. You need both the overlay and underlay to g= et user traffic to flow.

Sure, just lik= e you need link layer connectivity and closed circuits. User traffic is dir= ectly handled by the overlay, which is an added layer of novel complexity. = When you add complexity, you inevitably add room for bugs and mysterious be= havior. Anyway, I'm happy to drop this point for secdir because this is= more of a general architectural observation than something specifically re= lated to security.
=C2=A0
>=C2=A0 * It does not resol= ve the trust anchor problem. Instead of proposing a PKI, you seem to be pro= posing a trusted third party authoritative for the Hash-EID namespace. (Q.v= . section 2, the Hash-EID definition: "Another entity=E2=80=9D)

The trust anchor is the mapping system. And that is the PKI. And the= mapping system is distributed.

What PK= I? That's part of what I'm trying to establish. How do entities dec= ide to trust each other?

E.g., if entity A has pai= rwise trust with peer B, but needs an EID mapping for peer C, it needs some= way to establish that the replies it's supposedly receiving from C are= genuine. One popular model enabling you to do that without employing trans= itive trust is end-to-end signing chained to a trust anchor. With TLS as de= ployed on the web today, the trust anchors are a set of mostly mutually agr= eed-upon CA certificates that serve as roots for the certificates presented= by every public web server. There are of course issues with this model (q.= v., certificate transparency, Symantec), but its behavior is well-establish= ed and its properties are understood. What is the equivalent here?

It sounds like the answer here is mapping system-specific.= E.g., from a quick perusal of the DDT draft, it sounds very DNSSEC-like (w= hich might suggest a course of action to eliminate the need to develop, dep= loy, and maintain a custom security protocol, but that is a different discu= ssion).

Where an interface is described without re= ference to a specific implementation, a set of assumptions (e.g., "cor= rect routing relies on the authenticity of mapping system responses") = and associated security requirements for any conforming mapping system (e.g= ., "entities making use of mapping system responses must have some way= to authenticate them that does not rely on transitive trust") need to= be stated for the document to be a complete description of a system compon= ent. That is, without first clearly defining the required properties of any= valid implementation of described interfaces, there's no way to evalua= te whether the component under review will do what it's supposed to.

A good place to put these assumptions and requiremen= ts is in the security considerations section: those statements are not norm= ative for the system component described by the draft in which they appear,= but are effectively requirements for whatever system component is to imple= ment that interface in a conforming way. Enumerating them as such (in the = document describing the interface in detail) allows the reader to evaluate = the requirements in light of the system using the interface, while also pro= viding a convenient checklist for those designing conforming systems.
=

A set of well-crafted security considerations sections = also makes it much easier for a reviewer to understand the security of the = system as a whole without having to understand the details of every impleme= ntation, and to verify that individual system components under review will = have the appropriate behavior.

I'm going t= o skip the comments related to draft-farinacci-lisp-ecdsa-auth, just t= o limit scope here. We can get back to it once that document has been adopt= ed and more fully fleshed-out.

> "TLS" does not appear anywhere in the draf= t of LISP-SEC I reviewed:

Right as I explained DTLS does.

= Check again. Just to be sure, I've tried several tools and the letters = "T", "L", and "S" do not appear consecutively= anywhere in this document. Neither do "SSL" nor "transport-= level security".
=C2=A0
=
> I would like to see a discussion of whether and how the nature and sca= le of this problem differs from that of the status quo. BGP sessions and RI= B push have properties that are well-established from decades of experience= : surely LISP does not have exactly the same properties. The security consi= derations should make clear, for instance, how a loss of control plane conn= ectivity differs from the loss of a BGP session, and how this impacts visib= ility and behavior of the data plane.

Please look at the deployment drafts. Please note, you are reviewing= a document that is focusing on encapsulating packets on an overlay. All th= e other support pieces are broken out, in what the WG felt was logical, in = sepreate documents.

I think this gets b= ack to the point I made at the end of my original review, which is that thi= s system is difficult to evaluate from a security perspective in a piecewis= e manner given the dependencies between the different layers and the lack o= f explicitly-enumerated security requirements for each system component imp= lementing a given interface.

Kyle

--00000000000026e15b05759b3ef0-- From nobody Tue Sep 11 09:57:12 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31771124BE5; Tue, 11 Sep 2018 09:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJHpRKdXDy6L; Tue, 11 Sep 2018 09:56:52 -0700 (PDT) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (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 2EFF4130F0F; Tue, 11 Sep 2018 09:56:52 -0700 (PDT) Received: by mail-pf1-x429.google.com with SMTP id b11-v6so12537958pfo.3; Tue, 11 Sep 2018 09:56:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vb2pwHTPakpIw9AeIdXU3iHbXJjZgAedb3A6VO4p3tI=; b=BonI908U8DqsV4EKB+sBQN8QYEcnBEznAbt6uKC89E3jna8KUxVhyccB2mHHmJmtQD EhwXpgTUH+qI0NJamdamfLiEs8UQokFElP0ATSxVhOjyRnGVT4RFwOn1mjA5Iy8BhFCG +KaeUG7ijmHIap4jIvSt8OkVeqp2cUgX1+03UY/gsmvBonSIXUkgHJdCLNQKUMbCed5V beBPg0jZGCy0nrs6E/iGd0ebfdRCqvH37CuZ4/abXPCRF6rDfPVzoDwo4MxePtPm+dfs bACjVllRu3PFhnPXl340jkrU6qrEpIiiRYk6abVubCFuYSKB0bNFNRFn4wzlQzc7YVsm eBZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vb2pwHTPakpIw9AeIdXU3iHbXJjZgAedb3A6VO4p3tI=; b=UaLhyXgsN+UJOZZ7Ga/ta9m4b7h0bD3nRkmjPYxC07w83Qy3fssQukTMlWWY2PbFAC +DqK2wZaR2u+RLMqLPYrvMTff0XQk0CXuvYTgDJQIKoHvZMAh6uPLjfXkQRqSlUUhR84 qp4yxKYmUmuE8GUW9IdCoQ/6hDzOvi9/fxeC5nOqV7IYLvDlDPeVmhtOAs7IdNaiKuRb 0P8BlN4Yg43S+AwtHwJN1xwJFIxo9ETJGMSXR6V4Cc7sWQkF8I7u2bI9OG63bUwFBKtH rMyc5F8rIgqzuuW35jXMf7Ypk9I+bgYMfj6ntB8bGVNAXUMYRhINcwfmV0g5fvfs3IC8 9rRQ== X-Gm-Message-State: APzg51ARLRpcLkYiTpUgX5se/BVPIe4zLXkVmwaWCrSkAVy5QoaXUtnS nbNQEHkNW14b589ugXlWIqs= X-Google-Smtp-Source: ANB0VdYsJZ7wEBHUQBxSuoPbmVKvt8zSTb3WXmIl38BEhKoj9D2AIA5k0sWHtsK7GtUR5a/i6UZm2A== X-Received: by 2002:a65:5304:: with SMTP id m4-v6mr29746960pgq.250.1536685011575; Tue, 11 Sep 2018 09:56:51 -0700 (PDT) Received: from [10.31.79.252] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id r87-v6sm44078833pfb.1.2018.09.11.09.56.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 09:56:50 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: Date: Tue, 11 Sep 2018 09:56:49 -0700 Cc: IETF SecDir , draft-ietf-lisp-rfc6830bis.all@ietf.org, IETF Discussion Mailing List , "lisp@ietf.org list" , Benjamin Kaduk , =?utf-8?Q?Mirja_K=C3=BChlewind?= Content-Transfer-Encoding: quoted-printable Message-Id: <8025C400-D41F-4A6D-BC14-6A50E80F854D@gmail.com> References: <153513922907.22939.10542350679349996082@ietfa.amsl.com> <430EA55E-6D40-45A1-99D3-0978F1B20038@gmail.com> To: Kyle Rose X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-lisp-rfc6830bis-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 16:56:55 -0000 On Tue, Sep 11, 2018 at 11:29 AM, Dino Farinacci = wrote: > > E.g., if entity A has pairwise trust with peer B, but needs an EID = mapping for peer C, it needs some way to establish that the replies it's = supposedly receiving from C are genuine. One popular model enabling >=20 > The mapping system allows all of A-C to trust each other. >=20 > Explain how with a detailed example, or point me to a detailed = explanation in a specific document. The mechanism is still not entirely = clear to me. If A and C don't have an established business relationship, = how does A know that the responses it's getting for EID mappings owned = by C are genuine and not modified by B? This is a critical property of = the system, and so it needs to be made obvious to the reader. (1) A, B, and C register their mappings to the mapping system. They have = a trust relationship with each of their respective map-servers. (2) Those map-servers, who participate in the same mapping system and = know about each other via LISP-DDT delegations, can sign referrals to = tell map-resolvers that A uses to look up mappings for B and C can trust = the map-servers of B and C. (3) The map-servers can proxy-reply with the mappings for B and C to A. = Or B and C can Map-Reply specifically with signed Map-Replies according = to draft-ietf-lisp-sec. Do I need to say more? > I agree with, and am not taking issue with, modularity: no one wants a = monolithic design for something I was talking about the docments being modular (but the design is = obviously so as well). > this complex. But the interfaces between the documents, by which I = mean the requirements they impose on each other, must be made explicit. = When a system achieves complexity warranting design modularity, it=E2=80=99= s And they should be by how the reference each other. If you think there = is text that makes assumpiton without a reference to the particular = draft, then we can add it.=20 > simply not sufficient to describe individual system components without = providing a framework for analyzing how they fit together without having = to read and fully understand all of it. All the information *might* in = fact be there, but as an outsider not implementing LISP, and with finite = time to review, asking me to understand the minutiae of the entire LISP = ecosystem in order to understand the security properties of the overall = system is simply not reasonable. I should be able to consume a = high-level architectural overview, containing sufficient detail to = understand the security properties of the overall system, and then use = that to drill into areas of concern more deeply. This is why I want the = high-level security requirements documented somewhere, along with a set = of high-level explanations of how the proposed system components combine = to satisfy them. Yes, understand. The LISP design, especially the security design, as = evolved over 10 years. So having continuity over that long period of = time with work items as well as people has been challenging. And with = the IETF process to boot, it was more difficult. I=E2=80=99m sure you = understand this. The best I can offer is, that you tell us where you are confused at a = point in the text and we add text to clarify it. But the problem we have = is that the IETF process will not allow us to reference documents that = are more inmmature than the document referencing it. > Put another way: as someone whose day job it is to read and review = design documents and to offer architectural consulting on everything = from from network architecture and hardware design to build automation = and SDLC tools to dynamic job orchestration and application security, = being able to achieve a high-level mental picture of the critical = properties of a design is an important first step in evaluating a = system's fitness for a particular task. Document authors have a = responsibility to make their work consumable by people who don't already = have the full context. Well, we have, and each generation of people that come along want more = changes and more consumability We are doing the best we can given the = existing parameters, for a decade. ;-) So I suggest, you look at something and say =E2=80=9CI think this is a = bug=E2=80=9D, or =E2=80=9CI see something missing here, is there a = design and does it need a reference=E2=80=9D. I don=E2=80=99t know, = that=E2=80=99s the most practical way I can see moving forward. I think we are going to have the same issues/recommendations for = Mirja=E2=80=99s comments as well. Dino From nobody Tue Sep 11 10:11:42 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC396130EDF; Tue, 11 Sep 2018 10:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYmEMbGr89OW; Tue, 11 Sep 2018 10:11:28 -0700 (PDT) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 D8D98130EDB; Tue, 11 Sep 2018 10:11:27 -0700 (PDT) Received: by mail-pl1-x632.google.com with SMTP id f6-v6so11641146plo.1; Tue, 11 Sep 2018 10:11:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sKCjNHSLw2CR962a/4A9846/i1bDAFle5yAzogvd+8A=; b=P1l/QAWyiqydtxbbMes8QzIRkUJa8HJhrFXAmMPV+DEBHr1JtoNQzHUxoaKKQsUkX9 a82ZU/7R2Piy9XZUlnXJ34aBswT9k3VZso+9soki6aDDt7WDxJ4xw1BeKY+hUCBusGgw xiDSc3HYi6nO05fWFoIjgQhqH/Cy3DiezNTdpRq8to5SoEpVcDzuLNMz8ciUbfVrMSS+ YtUxHz2XJ1dh6cxXpWbFCQVGAcTbNXOgh0cXwxQxjiK21C5tRTThugsN+jOoAKt1gQ9j yQ5q34cpSUTcvZYMk/EXfDoxv6Ymll5cN9R5SaMOrGT9T6v87PZvuDO4nxRuEUmSWEIN pcfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sKCjNHSLw2CR962a/4A9846/i1bDAFle5yAzogvd+8A=; b=XRohv2pikEcq2R7WmaVV7I98nKpj4gY3wn9zO4aMjpS2teXdbO93SaRrsvvDCuJIkB fTctegXvHkPhiIwP6ZV26s0cAiFM7GCJXVDPIHoc7nQWnEnfsNJBmsYWqkKDlMHJ5PlJ 8N/xCsTYi1lHUzT+B0ClmLFEHhkt6v0JHq1xttFCjidQ7lusb1R8yVcjHGKqxszz3BVD z+8aNA5z81qmjc1EiyI2h0sj2fJxYOntqfXkI358768eBrA65e42QT8+KGd5Y9vrkPrA MLc6+Z7xuBfV6AuZ7xBW/G6NyD5QWVa9o7xJ96M/Ex8GUjIro3hfqQUqAKG43+gM8d1p gYnw== X-Gm-Message-State: APzg51DC+yumWZSRdTjMACLoRf/Eo5vnIZhT1KcoPDfoXb8QLPBg6Vk5 xTAW9p66JU6v13rfS/xU+G8= X-Google-Smtp-Source: ANB0VdaK8B/50WVjFAnJv1uLA1Qa5q1cnmh/06FujepCHoB2vBDQw7/tmBB+f8cF+OS2Z5dQHLnxhw== X-Received: by 2002:a17:902:2e83:: with SMTP id r3-v6mr28326760plb.80.1536685887443; Tue, 11 Sep 2018 10:11:27 -0700 (PDT) Received: from [10.31.79.252] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id j27-v6sm34749919pfj.91.2018.09.11.10.11.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 10:11:26 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: Date: Tue, 11 Sep 2018 10:11:25 -0700 Cc: Luigi Iannone , IETF SecDir , draft-ietf-lisp-rfc6830bis.all@ietf.org, IETF Discussion Mailing List , "lisp@ietf.org list" , Benjamin Kaduk Content-Transfer-Encoding: quoted-printable Message-Id: <6546936B-3AFD-47C4-8A27-8298DDDBBA09@gmail.com> References: <153513922907.22939.10542350679349996082@ietfa.amsl.com> <77109099-A756-4563-968C-5AC17FF38291@gigix.net> To: Kyle Rose X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-lisp-rfc6830bis-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 17:11:30 -0000 > but this doesn't specifically address the fact that a pull-based = control plane will fail in a different way, and one that is potentially = harder to diagnose, from a push-based one. One area in which it differs = is that a loss of a BGP session followed by a network partition is = obvious to all users trying to move traffic between those two networks, = while choking off control plane traffic in LISP may only affect some = endpoints in a mysterious way. IMO, a feature and not a bug. And arguably harder to diagnose makes it = more secure. Dino From nobody Tue Sep 11 10:30:51 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0260B124D68 for ; Tue, 11 Sep 2018 10:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.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 26l-5nxGyNOf for ; Tue, 11 Sep 2018 10:30:42 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33FEA130E4F for ; Tue, 11 Sep 2018 10:30:42 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id h4-v6so29089133qtj.7 for ; Tue, 11 Sep 2018 10:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0Ykstjgvjv+xWHoVjK9RkGrKiHMyLapiP8v8g/vu6ec=; b=Cja/sRXzP1h9yIC3h5a64K2zqkqeSHIbPP7zlmsL/CH6StWQE39JpGQsibru6lTs2c lIFUreGZvSjQFMi6HwplKvvavpMrkW+J2J/crMKWcdUPf/MHJwzPmBxqGqhmJZLLihZg aMWpe63Sc0+5NWm8U4opWtrPF65SpBqgnO5Qw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0Ykstjgvjv+xWHoVjK9RkGrKiHMyLapiP8v8g/vu6ec=; b=cpvWwA7Hen/2bCOjOai9ciEtEBtZJ0vME6kvyECTt5Ot8Z7o9fW++5qSndWUJS88hz SVgFzA13c4w8tp9ExBzNVI8BktfaxDY6rzDlOv/vmjcdEhidhPBPa50QHOjxtxDj/Exo iA8Jn2+zH9dupyKojJsK0vfsS+qJJoCWWUloQd/aR7fjDfxQFqLxkN5lI3kC1YR7JaLo bXvuD/xzRO5EiHuZgGSr+dHCSmAEFUpBsize8jfP3F7agt6q6K8t2mfVpwl6ZnkYzZAc xuAluvdXoAaXrnbXSgqUw3lmAu4MX7rCpGCfkuDd0FoDGErKJRH7lZIJ0239x3iFfmMy 2T3Q== X-Gm-Message-State: APzg51B/Rg5FjKSW47JQ01oMkqzn+gbBtfm1DWe+nOXO8H70uxTRGVWb nGcWI8jOUJq0xjatq4LxFYA8kKnKC08IGOawnWB1BA== X-Google-Smtp-Source: ANB0VdZkRVHMw+sQKPsENXMwAV66RfzDbVWKAAEWnJKt6GSpKtgjWsiL0nztcWAawlbwRPBmvbxCR6+o8jmlirj0qnM= X-Received: by 2002:a0c:d5d3:: with SMTP id h19-v6mr19625084qvi.218.1536687041167; Tue, 11 Sep 2018 10:30:41 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a0c:86ea:0:0:0:0:0 with HTTP; Tue, 11 Sep 2018 10:30:40 -0700 (PDT) X-Originating-IP: [2001:4878:a000:3000:7163:4dac:f91f:e5b5] In-Reply-To: <6546936B-3AFD-47C4-8A27-8298DDDBBA09@gmail.com> References: <153513922907.22939.10542350679349996082@ietfa.amsl.com> <77109099-A756-4563-968C-5AC17FF38291@gigix.net> <6546936B-3AFD-47C4-8A27-8298DDDBBA09@gmail.com> From: Kyle Rose Date: Tue, 11 Sep 2018 13:30:40 -0400 Message-ID: To: Dino Farinacci Cc: Luigi Iannone , IETF SecDir , draft-ietf-lisp-rfc6830bis.all@ietf.org, IETF Discussion Mailing List , "lisp@ietf.org list" , Benjamin Kaduk Content-Type: multipart/alternative; boundary="00000000000038574e05759bd51d" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-lisp-rfc6830bis-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 17:30:44 -0000 --00000000000038574e05759bd51d Content-Type: text/plain; charset="UTF-8" On Tue, Sep 11, 2018 at 1:11 PM, Dino Farinacci wrote: > > but this doesn't specifically address the fact that a pull-based control > plane will fail in a different way, and one that is potentially harder to > diagnose, from a push-based one. One area in which it differs is that a > loss of a BGP session followed by a network partition is obvious to all > users trying to move traffic between those two networks, while choking off > control plane traffic in LISP may only affect some endpoints in a > mysterious way. > > IMO, a feature and not a bug. And arguably harder to diagnose makes it > more secure. > Possibly. But being better or worse isn't my point, so much that it's *different* in a material way from a security perspective. Those deltas are where something proposing to supplant the prevailing mechanism for DFZ routing needs to be clear to operators. Kyle --00000000000038574e05759bd51d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Sep 11, 2018 at 1:11 PM, Dino Farinacci <farin= acci@gmail.com> wrote:
> but= this doesn't specifically address the fact that a pull-based control p= lane will fail in a different way, and one that is potentially harder to di= agnose, from a push-based one. One area in which it differs is that a loss = of a BGP session followed by a network partition is obvious to all users tr= ying to move traffic between those two networks, while choking off control = plane traffic in LISP may only affect some endpoints in a mysterious way.
IMO, a feature and not a bug. And arguably harder to diagnose makes = it more secure.

Possibly. But being better or worse i= sn't my point, so much that it's *different* in a material way from= a security perspective. Those deltas are where something proposing to supp= lant the prevailing mechanism for DFZ routing needs to be clear to operator= s.

Kyle

--00000000000038574e05759bd51d-- From nobody Tue Sep 11 10:36:50 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AACB2130DC3; Tue, 11 Sep 2018 10:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3pJ_K6G2kWR; Tue, 11 Sep 2018 10:36:41 -0700 (PDT) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 E0977124D68; Tue, 11 Sep 2018 10:36:40 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id h79-v6so12566185pfk.8; Tue, 11 Sep 2018 10:36:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gNB3TgKAhyftnsk4CoZ0lWF+70fokZUoV4lIvfqII+E=; b=CVd2R0LCK/B0Mu4Slixif87C63y5jvrb1HYler8BCf0JguuR3MXrtY19aFp3c4WfGH VlBO0vO6VRuwXVd5pidRsQ55/eY0gcngD8iWEbBm5NMg9AwliN1nvnO2atd7kIUMANx7 pLsocImceBxD3VZiaDe6S6tVNBOOjneIYPaXuztu79MRSLFsNmk5IchiC6T9GXqXBkDb Lqs2Pik/YFsYRB9/2dZGgTLJq0biSRS3HOGZUipewrjOKfyQWx7tyKOOVYM9GneCAasU OOckYlMixWjAG4OBJn0fp7Pi4NoSjHTLcvTLFSNXbL5JQAXxjtWLFXk/7zRDWl3KXLGH dGFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gNB3TgKAhyftnsk4CoZ0lWF+70fokZUoV4lIvfqII+E=; b=D2gXT9Ko6B2mms9SRCEO72lkhChcNJGWwRHJE8hFrdesfHDsIktiycMMeZkpX32d5N ldqFk3TJBsNQuKIB+vfNdhyhfZX8J9LvOGVNqflo8GJbdhgR5aBDYoQdvKRo0005J0hY feBFmGYHuAhbaMlZ3eRqVa9yhjUt1myHaXDiVk3BvVMCLN2srJJPKaQUPq82gzarDb1v xU2iEaeITtDVteAKo/dEqij2bV4R/DrIJw1MsiFyg1kIxMZfPlhw3T7VoS7zQPy7UfKr Vba3QkYN4/WV21+MjnHhTUNm98+bPxKjmrP78IiTAvdDugUsuj+B+ZN/RqwV00R4poPF dOxQ== X-Gm-Message-State: APzg51AuERgsX0wz2C8AtWUO/7AD0BLS4ZgI1gTzHdypFCG0PRA5RZxf BNhhxOwVYu7RMAAfGX/AE54= X-Google-Smtp-Source: ANB0VdY8tO3aSc7RjJzd7yaBS+X5rZC3z5eUZ0Qedz2dOhss3x4APkTlK58pIzmClgOJLrjVXw2AWA== X-Received: by 2002:a65:50c9:: with SMTP id s9-v6mr29729037pgp.417.1536687390407; Tue, 11 Sep 2018 10:36:30 -0700 (PDT) Received: from [10.31.79.252] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id y18-v6sm23145446pfl.90.2018.09.11.10.36.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 10:36:29 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: Date: Tue, 11 Sep 2018 10:36:28 -0700 Cc: Luigi Iannone , IETF SecDir , draft-ietf-lisp-rfc6830bis.all@ietf.org, IETF Discussion Mailing List , "lisp@ietf.org list" , Benjamin Kaduk Content-Transfer-Encoding: quoted-printable Message-Id: References: <153513922907.22939.10542350679349996082@ietfa.amsl.com> <77109099-A756-4563-968C-5AC17FF38291@gigix.net> <6546936B-3AFD-47C4-8A27-8298DDDBBA09@gmail.com> To: Kyle Rose X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-lisp-rfc6830bis-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 17:36:43 -0000 We are not supplanting the mechanism for routing. There is a layer above = routing that can (1) pull like DNS, and/or (2) push like BGP to realize = an overlay. Dino > On Sep 11, 2018, at 10:30 AM, Kyle Rose wrote: >=20 > On Tue, Sep 11, 2018 at 1:11 PM, Dino Farinacci = wrote: > > but this doesn't specifically address the fact that a pull-based = control plane will fail in a different way, and one that is potentially = harder to diagnose, from a push-based one. One area in which it differs = is that a loss of a BGP session followed by a network partition is = obvious to all users trying to move traffic between those two networks, = while choking off control plane traffic in LISP may only affect some = endpoints in a mysterious way. >=20 > IMO, a feature and not a bug. And arguably harder to diagnose makes it = more secure. >=20 > Possibly. But being better or worse isn't my point, so much that it's = *different* in a material way from a security perspective. Those deltas = are where something proposing to supplant the prevailing mechanism for = DFZ routing needs to be clear to operators.=20 >=20 > Kyle >=20 From nobody Tue Sep 11 11:29:17 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E43A130F17 for ; Tue, 11 Sep 2018 11:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.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 8PIn_efDgd3v for ; Tue, 11 Sep 2018 11:29:03 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 E3766130EEF for ; Tue, 11 Sep 2018 11:28:59 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id m13-v6so29396659qth.1 for ; Tue, 11 Sep 2018 11:28:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uqfGIHyqdRJg9C/LgAfTR+iwx8At3KN+RnIb+avIy3U=; b=GuZZK0L2CmE8LYrs74YbN/rvqd/rRQgw8YwvKWKRZUm4/SjDgLfYG3Uu5eG3Vi98Sa hEuYitNEQmbv/T15CHhTkzE+5IPVRHnR7RkKM3Ao08i+amhnGtJ2JWDiydI0sAdbJyES AV75EOaw5zRL+j2XHBtvWwNyXzk0rq+YAfQ7w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uqfGIHyqdRJg9C/LgAfTR+iwx8At3KN+RnIb+avIy3U=; b=jy1uwLRP7nekdJnsBm1JypAC3nmOlCqdHvIhE1yv4YLfg+CUYw2Cg4I4bem8ZGIdXI wn8r+OT+VbyOZe754eTQ0NIPxfzVBRXUlPTk+1EMXT5dAIRlCQfeI8Fe/M3u8EbIVwwm C4O/hHODkmV0MedJnD6RL1I9xJf7OfQnLmoxA0RpHCraXsIERWe9BW9PK06XTSAjKaMH salDjjtV4WgtKPBoPI64aZ0yFmeh7fgTtPrs1CALvLXP5Nvrr+fXq/WLE8MepKu2poZ+ FRSnq7cUstz8i0E5eeJrbhAtBm3WqebdnH0CPcvJtusLI8N6SpVKNHsUa7hHmKHNOTti pvOw== X-Gm-Message-State: APzg51AHCgkUlYt1N4Ztelp0o/6AMxzMMRR/ZTHUb1gToFjY7zrJgagi jSdBEgVIYbck45f/YXsrjPT7BqQ6ZTFY/BfDYAPmYw== X-Google-Smtp-Source: ANB0VdZ36Pkhzwphir62bgtPqW5Pdwy2aKcS6V3Yv0MjDRjhWS2WVoVu7dTEUjVlB+qp9wXw9zeaFDhjH2si8HgDPyw= X-Received: by 2002:aed:3d48:: with SMTP id h8-v6mr20758589qtf.222.1536690538778; Tue, 11 Sep 2018 11:28:58 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a0c:86ea:0:0:0:0:0 with HTTP; Tue, 11 Sep 2018 11:28:57 -0700 (PDT) X-Originating-IP: [2001:4878:a000:3000:65c5:5df1:11df:7dca] In-Reply-To: <8025C400-D41F-4A6D-BC14-6A50E80F854D@gmail.com> References: <153513922907.22939.10542350679349996082@ietfa.amsl.com> <430EA55E-6D40-45A1-99D3-0978F1B20038@gmail.com> <8025C400-D41F-4A6D-BC14-6A50E80F854D@gmail.com> From: Kyle Rose Date: Tue, 11 Sep 2018 14:28:57 -0400 Message-ID: To: Dino Farinacci Cc: IETF SecDir , draft-ietf-lisp-rfc6830bis.all@ietf.org, IETF Discussion Mailing List , "lisp@ietf.org list" , Benjamin Kaduk , =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: multipart/alternative; boundary="000000000000b1a6ab05759ca579" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-lisp-rfc6830bis-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 18:29:07 -0000 --000000000000b1a6ab05759ca579 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Sep 11, 2018 at 12:56 PM, Dino Farinacci wrote: > On Tue, Sep 11, 2018 at 11:29 AM, Dino Farinacci > wrote: > > > E.g., if entity A has pairwise trust with peer B, but needs an EID > mapping for peer C, it needs some way to establish that the replies it's > supposedly receiving from C are genuine. One popular model enabling > > > > The mapping system allows all of A-C to trust each other. > > > > Explain how with a detailed example, or point me to a detailed > explanation in a specific document. The mechanism is still not entirely > clear to me. If A and C don't have an established business relationship, > how does A know that the responses it's getting for EID mappings owned by= C > are genuine and not modified by B? This is a critical property of the > system, and so it needs to be made obvious to the reader. > > (1) A, B, and C register their mappings to the mapping system. They have = a > trust relationship with each of their respective map-servers. > (2) Those map-servers, who participate in the same mapping system and kno= w > about each other via LISP-DDT delegations, can sign referrals to tell > map-resolvers that A uses to look up mappings for B and C can trust the > map-servers of B and C. > (3) The map-servers can proxy-reply with the mappings for B and C to A. O= r > B and C can Map-Reply specifically with signed Map-Replies according to > draft-ietf-lisp-sec. > > Do I need to say more? > This is definitely clearer. The trust relationships appear to be: * A network trusts a particular map server to be authoritative for the entire EID/RLOC mapping. * The map servers trust the LISP-DDT root: they use LISP-DDT to publish and resolve EID/RLOC mappings, and can directly authenticate those mappings because they are signed in a hierarchical fashion (like DNSSEC). The first is a transitive trust relationship, but this is probably acceptable because it's only one hop (I'm trusting someone else to verify a piece of data that has been authenticated end-to-end) and there is a direct business relationship between the two entities. The second, if I have the general idea correct, is very much like DNSSEC or the web CA system in that a compromise of a node in the signature tree/forest leads to a loss of authenticity for that entire subtree. This is not disqualifying: clearly, many standardized systems have this property. But it's important to state it explicitly so we can at the very least make the properties clear to operators, and potentially recommend and/or develop mitigations. > > this complex. But the interfaces between the documents, by which I mean > the requirements they impose on each other, must be made explicit. When a > system achieves complexity warranting design modularity, it=E2=80=99s > > And they should be by how the reference each other. If you think there is > text that makes assumpiton without a reference to the particular draft, > then we can add it. > What I might recommend is either an augmentation of, or a new document analogous to (and informationally referencing), draft-ietf-lisp-introduction that covers the expected security properties of the overall design and the requirements for each of the subcomponents in a way that someone can understand without referring to any document other than the high-level architecture itself. draft-ietf-lisp-introduction is actually quite good at getting the general point of LISP across to someone new; I want to see something similar for LISP's security model. I think that's going to be better than inserting clarifying text here or there. I've actually read enough of this stuff at this point that I'm not sure I can enumerate exactly what's missing where. The threat model document could potentially be folded into that, but it has to start by painting a picture of the security that someone new to LISP can quickly understand. Kyle --000000000000b1a6ab05759ca579 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Sep 11, 2018 at 12:56 PM, Dino Farina= cci <farinacci@gmail.com> wrote:
On Tue, Sep 11, 2018 at = 11:29 AM, Dino Farinacci <farinac= ci@gmail.com> wrote:
> > E.g., if entity A has pairwise trust with peer B, but needs an EI= D mapping for peer C, it needs some way to establish that the replies it= 9;s supposedly receiving from C are genuine. One popular model enabling
>
> The mapping system allows all of A-C to trust each other.
>
> Explain how with a detailed example, or point me to a detailed explana= tion in a specific document. The mechanism is still not entirely clear to m= e. If A and C don't have an established business relationship, how does= A know that the responses it's getting for EID mappings owned by C are= genuine and not modified by B? This is a critical property of the system, = and so it needs to be made obvious to the reader.

(1) A, B, and C register their mappings to the mapping system. They = have a trust relationship with each of their respective map-servers.
(2) Those map-servers, who participate in the same mapping system and know = about each other via LISP-DDT delegations, can sign referrals to tell map-r= esolvers that A uses to look up mappings for B and C can trust the map-serv= ers of B and C.
(3) The map-servers can proxy-reply with the mappings for B and C to A. Or = B and C can Map-Reply specifically with signed Map-Replies according to dra= ft-ietf-lisp-sec.

Do I need to say more?

This is definite= ly clearer. The trust relationships appear to be:

= =C2=A0* A network trusts a particular map server to be authoritative for th= e entire EID/RLOC mapping.
=C2=A0* The map servers trust the = LISP-DDT root: they use LISP-DDT to publish and resolve EID/RLOC mappings, = and can directly authenticate those mappings because they are signed in a h= ierarchical fashion (like DNSSEC).

The first i= s a transitive trust relationship, but this is probably acceptable because = it's only one hop (I'm trusting someone else to verify a piece of d= ata that has been authenticated end-to-end) and there is a direct business = relationship between the two entities.

The sec= ond, if I have the general idea correct, is very much like DNSSEC or the we= b CA system in that a compromise of a node in the signature tree/forest lea= ds to a loss of authenticity for that entire subtree. This is not disqualif= ying: clearly, many standardized systems have this property. But it's i= mportant to state it explicitly so we can at the very least make the proper= ties clear to operators, and potentially recommend and/or develop mitigatio= ns.
=C2=A0
> this complex. But the interfaces between the documents, by which I mea= n the requirements they impose on each other, must be made explicit. When a= system achieves complexity warranting design modularity, it=E2=80=99s

And they should be by how the reference each other. If you think the= re is text that makes assumpiton without a reference to the particular draf= t, then we can add it.
=
What I might recommend is either an augmentation of, or a ne= w document analogous to (and informationally referencing), draft-ietf-lisp-= introduction that covers the expected security properties of the overall de= sign and the requirements for each of the subcomponents in a way that someo= ne can understand without referring to any document other than the high-lev= el architecture itself. draft-ietf-lisp-introduction is actually quite good= at getting the general point of LISP across to someone new; I want to see = something similar for LISP's security model. I think that's going t= o be better than inserting clarifying text here or there. I've actually= read enough of this stuff at this point that I'm not sure I can enumer= ate exactly what's missing where. The threat model document could poten= tially be folded into that, but it has to start by painting a picture of th= e security that someone new to LISP can quickly understand.

Kyle
--000000000000b1a6ab05759ca579-- From nobody Tue Sep 11 11:39:48 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E3B130F3F; Tue, 11 Sep 2018 11:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-PtNdBgFJfJ; Tue, 11 Sep 2018 11:39:37 -0700 (PDT) Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0: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 9CF881310F3; Tue, 11 Sep 2018 11:39:37 -0700 (PDT) Received: by mail-pg1-x536.google.com with SMTP id v66-v6so12673163pgb.10; Tue, 11 Sep 2018 11:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AztiOreLFTVnp8qlmYs7d77Zo4hb46ypdV01KoBYNVM=; b=niJpgLRQAiLjfMqM5FCdsZwkhDG/SE3VUFbgENQM47PgCbFi2oQPrUs7TqEI6CWinC rJD7d7rsDsYa6VhthY3Vj6COPRrppc2JpxMh/ckWQB0foFVMz9zVTKMBrv3Oi6BepELC n8EDI3B01mLOUl09d56jDLv4Dc2ixX1e/hm+9VRb5OXfwADTCYO97okeqk0gUILIvTRY XSe7swH7rOU9jqsWyxXKy3IAb+rOW6w1VNSgyYnluWptvy5qJUqTiCcjLxE8ZBRBb43w tZpoTonYpCKclho7Pu8xDyoJbtmlsJe+ZLJ/MdiFCtOc0QzcvewpSRPPnBOHCXVKFQNC KwoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AztiOreLFTVnp8qlmYs7d77Zo4hb46ypdV01KoBYNVM=; b=ZFS6wRsUSGB1IE2QoBZesvi/WSJdve4xyyMxUV9qYg2dXJ5H+heHrzVRuhOdyG1U7L ygeslVeojp6lNN/ik19BoUP4txvb8tbrGxOPdmJVcyPpvasSbBv3Lu5y7IH/5LNzNLUI YMne3m95hEzO/1/swA4dnLHGYyT8ct3NV829xLJ69VZ5alk6ZD2TRLF19shT+9a/QbdW X/wjW021vgEGRw2Xt0SusXOSw2u9VL5TgzkrjNg0otD+cQCYUhCNR1FZLgbmA/YKku1k kgsk0+SEjz07HV11MMT6At2I22Lndl4cMGSZcOkOIzN37sxXmGDHQqofz0ZfSeDhjbGy 85kQ== X-Gm-Message-State: APzg51CFBmxYueS6Bz9/gve1hqziFI/zVNkAGNuC4IqfyIgj+x+nYbE5 gx0cQHDlYiIJ5h0h1U8WaV8= X-Google-Smtp-Source: ANB0Vdbz48U5j4hJzURxSoCc9bhaz5HViBv0nbqq84RFBq8MQ4UnssLN0IcIfDxlXtXX+LPFnXRCHw== X-Received: by 2002:a63:fa0c:: with SMTP id y12-v6mr30153378pgh.177.1536691177176; Tue, 11 Sep 2018 11:39:37 -0700 (PDT) Received: from [10.31.79.252] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id n83-v6sm36696042pfk.19.2018.09.11.11.39.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 11:39:36 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: Date: Tue, 11 Sep 2018 11:39:35 -0700 Cc: IETF SecDir , draft-ietf-lisp-rfc6830bis.all@ietf.org, IETF Discussion Mailing List , "lisp@ietf.org list" , Benjamin Kaduk , =?utf-8?Q?Mirja_K=C3=BChlewind?= Content-Transfer-Encoding: quoted-printable Message-Id: <5655CB57-721B-4F9C-8F7F-0E38FBA60E0C@gmail.com> References: <153513922907.22939.10542350679349996082@ietfa.amsl.com> <430EA55E-6D40-45A1-99D3-0978F1B20038@gmail.com> <8025C400-D41F-4A6D-BC14-6A50E80F854D@gmail.com> To: Kyle Rose X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-lisp-rfc6830bis-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 18:39:47 -0000 > This is definitely clearer. The trust relationships appear to be: >=20 > * A network trusts a particular map server to be authoritative for = the entire EID/RLOC mapping. Yes, a map-server is delegated part of the EID-prefix space for any more = specifics prefixes registered to it. That is what the parent of the = LISP-DDT sends referrals for. > * The map servers trust the LISP-DDT root: they use LISP-DDT to = publish and resolve EID/RLOC mappings, and can directly authenticate = those mappings because they are signed in a hierarchical fashion (like = DNSSEC). Yes. A delegated hierarchy where the parent provides the public-key in = referrals so when the child signs its referrals, it can be verified (by = the map-resolver). > The first is a transitive trust relationship, but this is probably = acceptable because it's only one hop (I'm trusting someone else to = verify a piece of data that has been authenticated end-to-end) and there = is a direct business relationship between the two entities. Right. > The second, if I have the general idea correct, is very much like = DNSSEC or the web CA system in that a compromise of a node in the = signature tree/forest leads to a loss of authenticity for that entire Yep, correct. > subtree. This is not disqualifying: clearly, many standardized systems = have this property. But it's important to state it explicitly so we can = at the very least make the properties clear to operators, and = potentially recommend and/or develop mitigations. Right, that is in the LISP-DDT spec on how map-servers should behave = when they run LISP-DDT. Remember that 6833bis is how the xTRs use the = mapping system to talk to map-resolvers and map-servers (as well as xTR = to xTR for probing and map-replying, etc). > > this complex. But the interfaces between the documents, by which I = mean the requirements they impose on each other, must be made explicit. = When a system achieves complexity warranting design modularity, it=E2=80=99= s >=20 > And they should be by how the reference each other. If you think there = is text that makes assumpiton without a reference to the particular = draft, then we can add it.=20 Do you think (need opinions from the chair), that if we put a document = tree in draft-ietf-lisp-introduction, would that be helpful? The only = drawback is that we may get a circular dependency. But could avoid it by = having: (1) Have lisp-intro point to 6830bis and 6833bis. (2) Have 6830bis and 6833bis point to 6830/6833 (3) And none of the 4 documents point to lisp-intro (obviously RFC6830 = and RFC6833 do not) but the new bis shoud not. But that is not good for the reader, because if someone picks up 6830bis = and realizes they do not want that level of detail, they don=E2=80=99t = know by reading it to go to draft-ietf-lisp-introduction. > What I might recommend is either an augmentation of, or a new document = analogous to (and informationally referencing), = draft-ietf-lisp-introduction that covers the expected security = properties of the overall design and the requirements for each of the = subcomponents in a way that someone can understand without referring to = any document other than the high-level architecture itself. = draft-ietf-lisp-introduction is actually quite good at getting the = general point of LISP across to someone new; I want to see something = similar for LISP's security model. I think that's going to be better = than inserting clarifying text here or there. I've actually read enough = of this stuff at this point that I'm not sure I can enumerate exactly = what's missing where. The threat model document could potentially be = folded into that, but it has to start by painting a picture of the = security that someone new to LISP can quickly understand. I=E2=80=99ll yield to the WG to respond to this. Dino From nobody Tue Sep 11 14:56:21 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCDB5130F39; Tue, 11 Sep 2018 14:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EaRWa5dsPOMN; Tue, 11 Sep 2018 14:56:04 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 BD0B9130F1F; Tue, 11 Sep 2018 14:56:04 -0700 (PDT) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w8BLkKar031045; Tue, 11 Sep 2018 17:56:03 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049297.ppops.net-00191d01. with ESMTP id 2memkgb9gp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 11 Sep 2018 17:56:02 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w8BLu1ft015276; Tue, 11 Sep 2018 17:56:01 -0400 Received: from zlp27127.vci.att.com (zlp27127.vci.att.com [135.66.87.31]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w8BLtstJ015182; Tue, 11 Sep 2018 17:55:54 -0400 Received: from zlp27127.vci.att.com (zlp27127.vci.att.com [127.0.0.1]) by zlp27127.vci.att.com (Service) with ESMTP id C982640F6CEA; Tue, 11 Sep 2018 21:55:54 +0000 (GMT) Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (unknown [130.9.129.145]) by zlp27127.vci.att.com (Service) with ESMTPS id B5A2840F6CE9; Tue, 11 Sep 2018 21:55:54 +0000 (GMT) Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.139]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0415.000; Tue, 11 Sep 2018 17:55:53 -0400 From: "BRUNGARD, DEBORAH A" To: Dino Farinacci , Kyle Rose CC: IETF SecDir , "draft-ietf-lisp-rfc6830bis.all@ietf.org" , IETF Discussion Mailing List , "lisp@ietf.org list" , Benjamin Kaduk , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Thread-Topic: Secdir last call review of draft-ietf-lisp-rfc6830bis-15 Thread-Index: AQHUO+Fnc6omHwFs2E2jTDlX3tDS/6TRQ7aAgAS5MACAAAgsgIAUsDQAgADel4CAABPTAIAABHeAgAAZvoCAAAL5gP//zXPg Date: Tue, 11 Sep 2018 21:55:53 +0000 Message-ID: References: <153513922907.22939.10542350679349996082@ietfa.amsl.com> <430EA55E-6D40-45A1-99D3-0978F1B20038@gmail.com> <8025C400-D41F-4A6D-BC14-6A50E80F854D@gmail.com> <5655CB57-721B-4F9C-8F7F-0E38FBA60E0C@gmail.com> In-Reply-To: <5655CB57-721B-4F9C-8F7F-0E38FBA60E0C@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.164.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-11_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809110214 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-lisp-rfc6830bis-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 21:56:07 -0000 VGhhbmtzIG11Y2ggS3lsZSBmb3IgeW91ciBjb21tZW50cyBhbmQgRGlubyBmb3IgcmVzb2x2aW5n IQ0KDQpDdXR0aW5nIHRvIHRoZSBlbmQgd2hlcmUgRGlubyBhc2tlZCBmb3IgaGVscC0NCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IERpbm8gRmFyaW5hY2NpIDxmYXJpbmFjY2lA Z21haWwuY29tPiANClNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAxMSwgMjAxOCAyOjQwIFBNDQpU bzogS3lsZSBSb3NlIDxrcm9zZUBrcm9zZS5vcmc+DQpDYzogSUVURiBTZWNEaXIgPHNlY2RpckBp ZXRmLm9yZz47IGRyYWZ0LWlldGYtbGlzcC1yZmM2ODMwYmlzLmFsbEBpZXRmLm9yZzsgSUVURiBE aXNjdXNzaW9uIE1haWxpbmcgTGlzdCA8aWV0ZkBpZXRmLm9yZz47IGxpc3BAaWV0Zi5vcmcgbGlz dCA8bGlzcEBpZXRmLm9yZz47IEJlbmphbWluIEthZHVrIDxrYWR1a0BtaXQuZWR1PjsgTWlyamEg S8O8aGxld2luZCA8aWV0ZkBrdWVobGV3aW5kLm5ldD4NClN1YmplY3Q6IFJlOiBTZWNkaXIgbGFz dCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWxpc3AtcmZjNjgzMGJpcy0xNQ0KDQoNCj4gV2hh dCBJIG1pZ2h0IHJlY29tbWVuZCBpcyBlaXRoZXIgYW4gYXVnbWVudGF0aW9uIG9mLCBvciBhIG5l dyBkb2N1bWVudCBhbmFsb2dvdXMgdG8gKGFuZCBpbmZvcm1hdGlvbmFsbHkgcmVmZXJlbmNpbmcp LCBkcmFmdC1pZXRmLWxpc3AtaW50cm9kdWN0aW9uIHRoYXQgY292ZXJzIHRoZSBleHBlY3RlZCBz ZWN1cml0eSBwcm9wZXJ0aWVzIG9mIHRoZSBvdmVyYWxsIGRlc2lnbiBhbmQgdGhlIHJlcXVpcmVt ZW50cyBmb3IgZWFjaCBvZiB0aGUgc3ViY29tcG9uZW50cyBpbiBhIHdheSB0aGF0IHNvbWVvbmUg Y2FuIHVuZGVyc3RhbmQgd2l0aG91dCByZWZlcnJpbmcgdG8gYW55IGRvY3VtZW50IG90aGVyIHRo YW4gdGhlIGhpZ2gtbGV2ZWwgYXJjaGl0ZWN0dXJlIGl0c2VsZi4gZHJhZnQtaWV0Zi1saXNwLWlu dHJvZHVjdGlvbiBpcyBhY3R1YWxseSBxdWl0ZSBnb29kIGF0IGdldHRpbmcgdGhlIGdlbmVyYWwg cG9pbnQgb2YgTElTUCBhY3Jvc3MgdG8gc29tZW9uZSBuZXc7IEkgd2FudCB0byBzZWUgc29tZXRo aW5nIHNpbWlsYXIgZm9yIExJU1AncyBzZWN1cml0eSBtb2RlbC4gSSB0aGluayB0aGF0J3MgZ29p bmcgdG8gYmUgYmV0dGVyIHRoYW4gaW5zZXJ0aW5nIGNsYXJpZnlpbmcgdGV4dCBoZXJlIG9yIHRo ZXJlLiBJJ3ZlIGFjdHVhbGx5IHJlYWQgZW5vdWdoIG9mIHRoaXMgc3R1ZmYgYXQgdGhpcyBwb2lu dCB0aGF0IEknbSBub3Qgc3VyZSBJIGNhbiBlbnVtZXJhdGUgZXhhY3RseSB3aGF0J3MgbWlzc2lu ZyB3aGVyZS4gVGhlIHRocmVhdCBtb2RlbCBkb2N1bWVudCBjb3VsZCBwb3RlbnRpYWxseSBiZSBm b2xkZWQgaW50byB0aGF0LCBidXQgaXQgaGFzIHRvIHN0YXJ0IGJ5IHBhaW50aW5nIGEgcGljdHVy ZSBvZiB0aGUgc2VjdXJpdHkgdGhhdCBzb21lb25lIG5ldyB0byBMSVNQIGNhbiBxdWlja2x5IHVu ZGVyc3RhbmQuDQoNCknigJlsbCB5aWVsZCB0byB0aGUgV0cgdG8gcmVzcG9uZCB0byB0aGlzLg0K DQpEaW5vDQoNCltkZWJvcmFoXSANCg0KSXQncyBkaWZmaWN1bHQgdG8gZG8gKm9uZSogb3ZlcnZp ZXcgZG9jdW1lbnQgb24gYW4gZXZvbHZpbmcgdGVjaG5vbG9neSwgZXNwZWNpYWxseSBpZiB0aGUg aW50ZW50aW9uIGlzIHRvIHByb3ZpZGUgcmVmZXJlbmNlIHRvIG90aGVyIGRvY3VtZW50cyB3aGlj aCBhcmUgYWxzbyBldm9sdmluZy4gTGlzcC1pbnRybyBpcyBhbHJlYWR5IGhhdmluZyBpdHMgcHJv YmxlbXMgYW5kIGl0IGlzIG5vdCBwdWJsaXNoZWQgeWV0Lg0KDQpBcyBNYXJrIE5vdHRpbmdoYW0g bm90ZWQgaW4gaGlzICJIb3cgdG8gUmVhZCBhbiBSRkMiIGJsb2csIHdoZW4gcmVhZGluZyBSRkNz LCBmb3IgYmV0dGVyIG9yIHdvcnNlIGFuZCB0aGUgcmVzdWx0aW5nIGZydXN0cmF0aW9uLCBpdCBp cyAibmVjZXNzYXJ5IHRvIHJlYWQgbm90IG9ubHkgdGhlIHJlbGV2YW50IHRleHQgYnV0IGFsc28g YW55dGhpbmcgdGhhdCBpdCByZWZlcmVuY2VzIjoNCmh0dHBzOi8vd3d3LmlldGYub3JnL2Jsb2cv aG93LXJlYWQtcmZjLw0KDQpJJ2Qgc3VnZ2VzdCBhIHdpa2kgd291bGQgYmUgYSBiZXR0ZXIgdG9v bCB0byBjYXB0dXJlIHRoaXMgIm92ZXJ2aWV3IiBpbmZvcm1hdGlvbmFsIG1hdGVyaWFsLiBOb3Qg b25seSBjYW4gdGhlIGZvcm1hdCBiZSBlYXNpZXIgb24gdGhlIGV5ZSwgaXQgY2FuIGJlIGEgc2hh cmVkIGVmZm9ydCBhbmQgdGltZWx5IHVwZGF0ZWQuIFNpbWlsYXIgdG8gQmVub2l0J3Mgd29yayBv biBoaXMgWUFORyB0cmVlIGRlcGVuZGVuY2llcywgaXQgd291bGQgYmUgaGVscGZ1bCBpZiBhIHdv cmtpbmcgZ3JvdXAgcHJvdmlkZWQgYSB3b3JraW5nIGdyb3VwIHRyZWUgb2YgZG9jdW1lbnRzIGFu ZCBpdCBjb3VsZCBldmVuIHJlZmVyZW5jZSBvdGhlciB3b3JraW5nIGdyb3VwIGRvY3VtZW50cy4N Cg0K From nobody Wed Sep 12 17:12:36 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29BFD130ED7; Wed, 12 Sep 2018 17:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6MB6jaKGxCGU; Wed, 12 Sep 2018 17:12:31 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41BB3130ED4; Wed, 12 Sep 2018 17:12:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4726; q=dns/txt; s=iport; t=1536797551; x=1538007151; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=j70G41yBHmlbM+1AjIKEL8s0zTIcRZGFwnXLLxe4oBY=; b=QFRKcliI0q8/gn/YIUFUy1eOI5hZE3pKq31lYNDNIhiNDIF4sLS5iCU+ U37Z38OI0CeT4V4rSVBY9FU227w6sInLk4N0Wl6a8fl5DgpqcujmDFhS8 Z2t+/vNE5NrLEFw7hLEAFo9f218I8gXHB6d/outKb2fEzM/H3ZV8VSvnP g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C0AABPqplb/4MNJK1bGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYFQgVcvZX8og3KWES2WPYF6CyOBMwGDFQKDTSE2FgECAQECAQE?= =?us-ascii?q?CbRwMhTgBAQEBAgEjDwEFUQsYAgImAgJXBgEMCAEBgx0BgXkID6VtgS6EcoU?= =?us-ascii?q?YBYELhxSCSBeBQT+BEieCa4MbAQECAYRfglcCjjuNGUwJhjuJSQYXgUGEQ4J?= =?us-ascii?q?bhhyLRYhbgUkFLIFVMxoIGxU7gm2LFIVeHzABjnsBAQ?= X-IronPort-AV: E=Sophos;i="5.53,366,1531785600"; d="scan'208";a="170951050" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Sep 2018 00:12:30 +0000 Received: from [10.24.77.250] ([10.24.77.250]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id w8D0CTXR011837; Thu, 13 Sep 2018 00:12:30 GMT To: Christopher Wood , The IESG , secdir@ietf.org, draft-ietf-lisp-gpe.all@ietf.org References: From: Fabio Maino Message-ID: <7aedf62f-780b-6ebd-16eb-d7c2031be91d@cisco.com> Date: Wed, 12 Sep 2018 17:12:29 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Outbound-SMTP-Client: 10.24.77.250, [10.24.77.250] X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-lisp-gpe X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2018 00:12:34 -0000 Hi Christopher, thanks for your review. Please see below how I would like to address your comment. On 9/9/18 11:26 AM, Christopher Wood wrote: > Hello, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > The summary of my review is: Ready with issues. > > The proposed extension mechanism is simple to understand. However, my > main concern is regarding the nonce size reduction and implications on > LISP. While the threat models (on-path and off-path) do not change > with this extension, the probability of some off-path attacks might > change. Specifically, the probability of correctly guessing a 16 bit > nonce is not negligible. This might make attacks in which an adversary > tries to convince an ITR of reachability to an otherwise unreachable > ETR more likely. From [1], an ITR that sees the nonce echoed correctly > “knows that the path to and from the ETR is up.” Thus, I think some > discussion of this is necessary in the security considerations. Good point. I'll add the following text to the Security Section, after the very first paragraph: "The Echo Nonce Algorithm described in [I-D.ietf-lisp-rfc6830bis] relies on the nonce to detect reachability from ITR to ETR. In LISP-GPE the use of a 16-bit nonce, compared with the 24-bit nonce used in LISP, increases the probability of an off-path attacker to correctly guess the nonce and force the ITR to believe that a non-reachable RLOC is reachable. However, the use of common anti-spoofing mechanisms such as uRPF prevents this form of attack." > > Beyond that, I have the following minor comments and nits: > > - UDP checksums seem to be the only mechanism in place that give ITRs > and ETRs a means of checking datagram integrity. Of course, this means > an on-path adversary can muck with the g-Bit from Section 4.1 so as to > prevent use of the GPE mechanism. This is not new with this extension, > though a comment on the issue might be useful, e.g., in the security > considerations. I will add this paragraph to the security section: "LISP-GPE, as many encapsulations that use optional extensions, is subject to on-path adversaries that by manipulating the g-Bit and the packet itself can remove part of the payload. Typical integrity protection mechanisms (such as IPsec) SHOULD be used in combination with LISP-GPE by those protocol extensions that want to protect from on-path attackers." > - It would be helpful to include packet diagrams similar to Figure 2 > wherein (1) P and V are set and (2) only P is set. While I don’t find > the text misleading or confusing, a figure might help other readers. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |N|L|E|1|I|1|K|K| Source MV | Dest MV | Next Protocol | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Instance ID/Locator-Status-Bits | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0|L|0|0|I|1|K|K| ... 0 ... | Next Protocol | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Instance ID/Locator-Status-Bits | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I'd prefer to use diagrams that are congruent with those used in RFC6830bis. I'll defer this comment to the authors of RFC6830bis, and follow whatever convention they will decide to follow. > > - In Section 4, where it states, "A LISP-GPE router MUST NOT > encapsulate non-IP packets to a non LISP-GPE capable router," I might > replace "to a non LIST-GPE capable router" with "when the P-bit is set > to 0." I will use the following text: "A LISP-GPE router MUST NOT encapsulate non-IP packets (that have the P-bit set to 1) to a non-LISP-GPE capable router." Thanks, Fabio > > [1] https://tools.ietf.org/html/draft-ietf-lisp-rfc6830bis-16#section-10.1 From nobody Wed Sep 12 23:47:15 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E28F12D7F8 for ; Wed, 12 Sep 2018 23:47:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu Message-ID: <153682123338.9541.1502673377586537307.idtracker@ietfa.amsl.com> Date: Wed, 12 Sep 2018 23:47:13 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2018 06:47:14 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2018-09-13 Reviewer LC end Draft Melinda Shore 2018-09-04 draft-ietf-dnsop-refuse-any-07 For telechat 2018-09-27 Reviewer LC end Draft Derek Atkins 2018-09-25 draft-ietf-dnsop-isp-ip6rdns-06 David Waltermire 2018-09-12 draft-ietf-isis-segment-routing-msd-15 Klaas Wierenga 2018-09-06 draft-ietf-softwire-mesh-multicast-22 Paul Wouters 2018-09-06 draft-ietf-dnsop-kskroll-sentinel-15 For telechat 2018-10-11 Reviewer LC end Draft Dacheng Zhang None draft-ietf-iasa2-trust-update-00 Last calls: Reviewer LC end Draft John Bradley 2018-09-25 draft-ietf-dnsop-attrleaf-fix-04 John Bradley 2018-06-18 draft-ietf-bfd-multipoint-active-tail-09 Roman Danyliw 2018-09-25 draft-ietf-dnsop-attrleaf-13 Alan DeKok 2018-09-24 draft-ietf-tsvwg-rlc-fec-scheme-07 Donald Eastlake 2018-09-24 draft-ietf-tsvwg-fecframe-ext-04 Shawn Emery 2018-09-24 draft-ietf-opsawg-ipfix-bgp-community-07 Stephen Farrell 2018-09-20 draft-ietf-teas-assoc-corouted-bidir-frr-06 Daniel Franke 2018-06-28 draft-ietf-netconf-rfc7895bis-06 Daniel Gillmor 2018-06-25 draft-ietf-dnsop-session-signal-15 Daniel Gillmor 2018-03-19 draft-gutmann-scep-10 Russ Mundy 2018-08-13 draft-ietf-dnsop-terminology-bis-13 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Sandra Murphy 2018-08-10 draft-ietf-sidrops-rpki-tree-validation-02 Samuel Weiler 2018-09-07 draft-ietf-tictoc-1588v2-yang-10 Samuel Weiler 2018-05-21 draft-ietf-bfd-multipoint-18 Brian Weis 2018-09-07 draft-ietf-dhc-dhcp4o6-saddr-opt-04 Liang Xia 2018-10-10 draft-campbell-sip-messaging-smime-03 Taylor Yu 2018-10-09 draft-murchison-tzdist-tzif-14 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Next in the reviewer rotation: Daniel Franke Daniel Gillmor Tobias Gondrom Ólafur Guðmundsson Phillip Hallam-Baker Steve Hanna Dan Harkins Russ Housley Christian Huitema Leif Johansson From nobody Thu Sep 13 05:23:57 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1F7129C6A; Thu, 13 Sep 2018 05:23:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stephen Farrell To: Cc: draft-ietf-teas-assoc-corouted-bidir-frr.all@ietf.org, ietf@ietf.org, teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153684143617.8370.11801680378187520570@ietfa.amsl.com> Date: Thu, 13 Sep 2018 05:23:56 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-teas-assoc-corouted-bidir-frr-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2018 12:23:56 -0000 Reviewer: Stephen Farrell Review result: Ready I agree with the authors that this document doesn't add new security considerations over and above the referenced RFCs. From nobody Fri Sep 14 05:21:24 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D79130E37 for ; Fri, 14 Sep 2018 05:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.971 X-Spam-Level: X-Spam-Status: No, score=-2.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_24_48=1.34, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=NhOrZpBd; dkim=pass (1024-bit key) header.d=ericsson.com header.b=HvP+3Oe+ 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 YtgC52PxM6OH for ; Fri, 14 Sep 2018 05:21:21 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AE21130E26 for ; Fri, 14 Sep 2018 05:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1536927679; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=gwJinw1S3Uky/9/AhwsTDGpn70dzywm3FZZuGJ9e53M=; b=NhOrZpBdMdKxbtM4DjetkpsHckIvCKIp2eYyU2bmTtSOIIxNk1ZX9CQnsHQwA/Kk veUVvKCRpEepWByzvZvixo1cBPi76fSH2s5GiaLKDae1CSnBrNax4n1vlH9mH/wd PYVyyCXVSBq4741xre00ctjLfTRZsfEIhsFky6O+d2o=; X-AuditID: c1b4fb3a-75d969c000003197-a4-5b9ba7be7c73 Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 85.2F.12695.EB7AB9B5; Fri, 14 Sep 2018 14:21:18 +0200 (CEST) Received: from ESESSMR506.ericsson.se (153.88.183.128) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 14 Sep 2018 14:21:18 +0200 Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESSMR506.ericsson.se (153.88.183.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 14 Sep 2018 14:21:18 +0200 Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 14 Sep 2018 14:21:18 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TLNtN317snclstHjJ7YuT9rdC/2fggMLh53au/SxjKQ=; b=HvP+3Oe+6vDYX70ZkyrHfHNcGM8PRqNOFxMKZ4jRbtN1CCy/zt0iaTMHAw+A68DEkJihts32m5XCrPe8Ylrks4dm9d0uR9KvZaUjJZ059yk6eXxPweKQovfICQyy3uIymgeraP6nMYpFSvEGBVV0jeUND7BTGMYJQJnuGErivms= Received: from [192.168.1.163] (190.64.86.59) by DB6PR0701MB2104.eurprd07.prod.outlook.com (2603:10a6:4:50::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1143.12; Fri, 14 Sep 2018 12:21:09 +0000 To: Carl Wallace , , The IESG , References: From: Gonzalo Camarillo Message-ID: Date: Wed, 12 Sep 2018 17:30:01 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [190.64.86.59] X-ClientProxiedBy: RO1PR80CA0072.lamprd80.prod.outlook.com (2603:10d6:0:5::12) To DB6PR0701MB2104.eurprd07.prod.outlook.com (2603:10a6:4:50::7) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 27f92f2d-46de-4280-7db9-08d61a3c90ec X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:DB6PR0701MB2104; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2104; 3:kipBN8/hRikQvSMORBwaFigPD2jvTvCvPpFG5XZHavb5BFtYqpqSMSxQ971Hh5dDzT3n8TTizjYGiq9f9gcCmQP2Zt3ZuxqRYHSp4c5qlWpH0qr6sgkH33exiRb7KeNR1b1h+RqbtU2zTLHmaL2GD9Wgwp4f9MhfDRprqp1HKDjJx40qAABIIxslxZ6Rkx0DxYtBqi5FDSa6+jUoR0R1tcJGXSzj8JYWxBCQsq7fObRbwoMw2op4Egx4fm8z9KLi; 25:ubJhxs6HUDj7mzzAatKB/BfA+OrdoJbMTjJ5t8q9GiicXMOUaqS41+ZA3Fr8FT0i/0sZs8uNJneqVUQIscXcNRS3nxslnWogye0WfnqCoxzTrmsf6lGlNeskXgvxov1QowgvoZGrN0tvGx4P+gcCcERwQpt4Bq0+l5v7UGXJCdUpfADot9d+evRgiAhtOcwwgwP7NNZ2LWLGI6rb/73qQvsnTOv51VKEsO2DW5qfy93wBRVgZps5c+OzvK9K1XCZpQg1AF66dp1drnzV1+LMdzI/6Nfy7PowIMgnzHlVAbPHOXspqQUWc1FFe5FyBcW2UBvJDRU7kJLeox7w5Wf6Bw==; 31:BhQ8TTX9544bmJAqMMi1mQO2rEENcPAMtUV0AMLcj8Cu0GTAuG6MLGsILkfEvrU3iQO8/0FPU0gjf76H2VbsVosXDKW7TUVsjSvRUMh3T26vS4Yvx4jec1hM+x2aEkgQaV3zrnXwcQvvyNHDugNIgswe9SFnMih5Dtt53wUF/yGR3pVlAHyQFXRmVC4G4Vb0ZSo3tsW+n4sCJlX5wX/GS8rEfQsVCE4C8aG4huB+y1w= X-MS-TrafficTypeDiagnostic: DB6PR0701MB2104: X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2104; 20:fJTlorDVrP3havQ8LEaMR3BAjslV7W8lJP00BbrKO06MGqmb/GB8cKDnvgshDJNDYaZaJaIKig+HKENG50wG2MH2lGrEC/z4t2jCQ6LOX+NqaYqsvcs18pHCLh08IjgGVBIgIvg4LVROkOq+pJULQvT3q8JdsDTeubpnuGUuovm3srIfqYxIKAJR+GZDA8HnNPEtzefSNbKzaJd3RPjnhoUbzZuRp+zKdgIZPWXD6TRrCMe4ry1Plgf1ecoidBpO0BWgZLpuawVg+Ncy08N42aPUNJ7tVECnvV9r708AzINA2LGQoMGI31GJsk5cUrrK7+nuqVEJ5QemHlpkvpBXw6O2OU5H9TG7LLyMmFXu7LYnEgmrm3A4b9RMjoI8O3bfSm+XqVh1Qbu9U+ZgsnyKQlh804b9M1PsN0hM1+JUuAHqnO7+9rn4A90OhUVRqCfH5S9z8R0PA54yiwIrdaU4dEkar82kOjhS9fGpntBjAC2UnbVzR2iHDZfgCtdrYtoA; 4:acTXApRSEaAGF8tKPJpOMkrVXGVX5u/byu1uk6wZ/20StBB6BQlzMZWTl6HHFJ3oRxwLsEjWWfNZ8BIi3FYtVCP04jkAQL1wHYHqgtGydqm4MuaEk+GImWejien6LQZWLPWqSpMeCkpOJMyLUPRkV50er2+oGVsWMHuF37JPCrdhkSL5zWUrdtz22ltmibDEaC29yA4wfFiU0EeGOXwIosYEtkAQrRPdhYRTfTpzebLpqkYISbyR5Ap2otyxjlG2eW5KHnUJvp8+xfo7Q3PlrTzOY7nf3GwTUGXg8NCplb1tjM8gOakvsQZVkGypylPj4b+sK3evV+1MBC2uFW36nCEf6l6QPTwd0sQ2CViwNA4= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705)(788757137089); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231344)(944501410)(52105095)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201708071742011)(7699050)(76991041); SRVR:DB6PR0701MB2104; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0701MB2104; X-Forefront-PRVS: 07954CC105 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(979002)(6049001)(376002)(366004)(39860400002)(136003)(346002)(396003)(199004)(189003)(52116002)(77096007)(11346002)(386003)(36756003)(68736007)(31696002)(8936002)(8676002)(81156014)(50466002)(86362001)(81166006)(53936002)(64126003)(186003)(66066001)(65806001)(16526019)(2906002)(486006)(6346003)(65956001)(26005)(97736004)(476003)(117156002)(47776003)(65826007)(106356001)(58126008)(25786009)(956004)(316002)(6246003)(2486003)(76176011)(53546011)(52146003)(31686004)(14444005)(110136005)(16576012)(105586002)(6666003)(305945005)(3846002)(7736002)(5660300001)(2616005)(230700001)(229853002)(6486002)(23676004)(478600001)(6116002)(446003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR0701MB2104; H:[192.168.1.163]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=gonzalo.camarillo@ericsson.com; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjZQUjA3MDFNQjIxMDQ7MjM6Ly9RamF6a0NLNGRRdUpleFNONEtHdVBq?= =?utf-8?B?eGxoeGMxeHJkNUtMV0wvek5JbjVJaGNyQmszQnJoUGdvd3VEWkpQbmkvRjVF?= =?utf-8?B?NHkydjJ5MHRCQWV3SHpJSjRRVHdzTEVqdUpQb043ZDhNQUVDRlRjMUNKN2oz?= =?utf-8?B?cFd5QldWbnljZzNwNTNGTTNvcUpRd2U5T3VRbFdaVEpydWVJRngxbUZvQnp5?= =?utf-8?B?cmREV3czTWRVM3Z5MEtmWmU0dEhvbkxVQlBIbFpEem1qeDJLRnpMWU1NTXN3?= =?utf-8?B?QXJSeWZQNEVBbjBhSndKZEVvTkZBTDVacE1WbHV6OXZWZ1VPTVJITnJkWlBY?= =?utf-8?B?a0dYRFRTUi9pdkI2bnpjeUx1VDdEdGFJb2FYaHpiTlFvWm9jVkdKTzBMUytU?= =?utf-8?B?SnhhV295dStKKzNhUEZabzNUNXR1SG5ZUXI3MFNjMElWM0pybWJVSS8zbFVH?= =?utf-8?B?ZlU0WHBQT2pHZXgzeUJiSTRBZjlSQUltSjE5YWpxY093MkpKMHVRUG14Q2J6?= =?utf-8?B?RE4vT3RBRno4dnFGSS94OHdjbnBvcm8zNTNHSDBPRlVISnlZbVd3UlFVa3Nt?= =?utf-8?B?cVVKMzZhZVBWQkM3UkluU1RRQ0plUjlKTEVVN3VpL3QwNEFvL1VzU3hqZTRa?= =?utf-8?B?Z2Z5UVhWejNaL1lFUmNaUng2TDhHTVRKbW1pbUVsaUZoS0tHblFUZnJKaERC?= =?utf-8?B?YXdiMHd4Z2UvTVBuSWJZbU52ZmdoOTN5WlNaM2FPRVJrMVlXdXAyWFlVVzZx?= =?utf-8?B?enJhR1BPWFF4RjlyM0FTUXppeXk5VlZuQ1h4NnJ1YTNVaGhCV2hucFRsSVNQ?= =?utf-8?B?Vm8vOTcyakNseEZuWEFPNGQ1aTgrbTNIL3hmL25NNjJMS24xY01tS040NmNs?= =?utf-8?B?ckUwcnVESFZYd2FyT1FncU5CZnJOV0hoa2Z3eFFQK2VhTG1nRFRMQ1lrNHVh?= =?utf-8?B?NU9vRkZXM0gxRUttdEZDK3ZWZ3NlbjBZMTZobDlYQVBVaXRwRDB6OExkSVR4?= =?utf-8?B?TDB1eWRzcjJHWnk4RUpCYVZSNU16dGlCWWtvQzBUWkhZYUZjK0oxTHM5ZTFi?= =?utf-8?B?VEtQSFJIRjBpTUE5ckw2Sk93NFlLN3BsWVltdlZ2SWMrYzFGV2NVNGVQelhM?= =?utf-8?B?bkovWHZucWZmbUd0NW9CTTl6bUxzQ0R0MHlJTnhLZ2lEd1JkbEptK2ZCTk9V?= =?utf-8?B?cHdQN3ZFSHZ5UUF1S0kvME8xNWM4c2V3ZCs3dE1LUzFoZW5GcEZ0VGtOd1lu?= =?utf-8?B?NGF1SVJ5R0tCd0N6eEp5TkZQZGMwMVBOOHRHR3hKakdhRzRHZjdvRGpRNWlB?= =?utf-8?B?SWxaNGt3TlpSV2UvcU1FVjVxdzNwRFBtd0pMaEpvSi9aREw1ajVOeFROVnpE?= =?utf-8?B?Uzd4ZlBRdnd4Z295NWpsTW1ZYnlKaDhYQ081eWNEbXkwcm9ubEQzN01VQSsx?= =?utf-8?B?VmluN2RWdmEzbVhLdWQ3cnZicGo2d1Bwb1BQUjNNKzk2Qi9kOW5CeVBaaTVo?= =?utf-8?B?bEdLTGtpT25Ha1p4NlBvUE1Zb2VSOExjK1cwMXRUazZDQ2MrNzJGYU9tbGpz?= =?utf-8?B?SHMvMEp3UDBoY05PMnppM0pOSjcxVEFzQys0Wk8wNGFtTHMydXU3bnVBVEJl?= =?utf-8?B?ZkR1T3NMZENqZTN2Y0JQV3RCQjcraGhUREUydnFRaFRyZU80QSs0TUFmOFFF?= =?utf-8?B?blMvWlBKbTJ2SHkxdXBRQ3JEYmNJQUJDVDdIRVJISG5PZHB4VDdZUFpPREIr?= =?utf-8?B?YmI5UEY0bzNmb0JSUVpaa1J5RVBPWGRHVnVaWHRHaU5Cc0QyR3ZJdkhLU2h5?= =?utf-8?B?MUxrMk0vQmkyMXdhRDFmZjJsUWF0ZVMzQTVNVWtFTXF5djVVcGh1QXMxOU9N?= =?utf-8?B?QnpUSmJPWEd1U1dlWXhhbjJKblBkVXZtbUF5Q2hrR1JIVFNDOVc5Q3RsWG1t?= =?utf-8?B?Mzc2N09FRDNESFl6ZmVjVWdJRFFydHJHbnRTRGlmR2MrZGlDdDZQb3AwMmhV?= =?utf-8?B?LzBITWRXNXVCY3FCVkdlY2VwWUxzV2JsZTdvRlo5RlU5VjZqZThmblVreWd4?= =?utf-8?B?SWF5N0xrTUQxaGJDellIQnFLRWEyM29LdXlCT2dlU3FyS2RncWpUT2FaYjdH?= =?utf-8?B?WDhVdz09?= X-Microsoft-Antispam-Message-Info: BjV4z8kBBRQbvG6thrpsAJP+Ec1eRkyy2VdHAD1DNDgxM/xdTs59ch+s0W3O4dHe26Qfo7d7TgoiMZrn+yOVtJOwYkyJmBAXf30JWhkic8UlmH2xJCl/sUqbvG4mCu1QgKWKKcMoD5t2ePsMF3EffRDHHTRFoISMnbx6rQWlChgEf4jp7AhxBas/GYxDlXLUidloYPgI2a/nNReUjajIpKS+x2GXfsUcJQp2WUQHsdqC2HWIlHjB40ZxuPmrELcNexWnKRHtKYIXfm0paIo51MTzsonfxtTuBWMEFmBe+xg1Q+e4zo1Nl8C2UbaFpUGRJEorfa9bGjJaYQtsvAJ+6IYOR+2omvsKhmRVx+WIf0A= X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2104; 6:Hi58vDprYKBzFr7EgdACmo2/6GdxqvSJwWJq0aEa8WqRT7eGVyG1PWB/6mgX4xsjPeHm5gwb0XJ2hI5VI9k9Cd68r+eqCL/LQhd0BpEZClyZyHZztn365SxffpfyZMaVNH+C6b8fQysMWazbTnG3SdhWx07NIfZOC16/hWy15bAjP33g8hfhZj6JQPnBaVKNXdosjhV+fx2GEOHooBl96l5hOx0bNl0w2ZYc5xYoYPPf+I24U91KzetKXVtKMsAVaswljffnG3AIPNBvRFxGtTEIfhmdWPS/NAaikZ/buW5lXKaRi6tQIsuKfzdwBUJvLXYo27UMpkVwOGtc6wSbIg0ji0pvxP8+QRUAF2Z5GHlT/oAHuYXAXbg6h+Pi+8DCTTOXgIIAnEB8EHQ/sSHiQZdLgxpJA9EaNubx4d0et0ShnwWOJ4mEkZn15f69yXe8omeMB0jBoJYre592SoFPEw==; 5:zRtInh6ZkrXm9UM51saaXzZulaeN+uk3f40SxnTclmZe+BsBX1vZ3QKprV5dbU6gyImJEg8hoWgryuz+NNfArU6yPpMK4y1fv60PWig2X+YHM0U3LH7OovlN1pqS41Z+H6az3qK45bJiV/YITwByQTHB+Gx1IlmWPDKrbPWJuHw=; 7:VwxpAhd1FTyKNszndvTmznXM4GhbE7W0Xo5qogQwvmua/OvKJmb0zCanKCVcV5tpPB5LGdjlcbMlgX8l6PzEkzE7yebLNBNJmaWygzabcjTaRyHsRG5yHCjZAcdTdB8oCyBjd4D1M30vlRi4tpqpoIq+TNsASqbJ5t+KpYlUB5aTH+Fve0pKOPScHQ/H0PHJ6AJgGJkb5PwoKYGdTKCARkQgtxR8XPGGTkbbz/mEssb6k89nIYete8GJvNBFsRua SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Sep 2018 12:21:09.2374 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 27f92f2d-46de-4280-7db9-08d61a3c90ec X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2104 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCKsWRmVeSWpSXmKPExsUyM2J7se6+5bOjDU4esrZYvXgTk8WfldsY LWb8mchs8WHhQxYHFo8lS34yeeybsZs9gCmKyyYlNSezLLVI3y6BK+PEha+MBX+4K77uucXS wHiRs4uRk0NCwESicd9C1i5GLg4hgaOMEl8/9zBDON8YJfbO28EG5/Q9PMMO4Sxhkjjx9ygL iMMiMIFZYsGWVVCZBiaJ3oUvmUEmCwtYSEz8MRmsSkSgjVFiy6XFjCAJIQEziXOtx8CK2ICK tty6zwJi8wrYS7Rdew20kANorKrEzH9eIGFRgRiJo5Nb2CBKBCVOznwCVs4pYC7RdPYHK4jN LKAu8WfeJWYIW1zi1pP5TBC2vMT2t3OYIT5VkHj36BnYcxICExklehsnMUHcoy2xec0pRogi WYmjZ+ewQNi+Ept/3YJqOMko0fD8LSuE08Qu8efQcjaIKh2Jrat72CESy9glvj06xw6RyJfY 1NLFCmF7Smxe+AVqhZzEqd5zTBANh5kl/vRcYJnAqD8LyX+zkPw0C8lPs5D8tICRZRWjaHFq cXFuupGRXmpRZnJxcX6eXl5qySZGYFo5uOW31Q7Gg88dDzEKcDAq8fDenzU7Wog1say4MvcQ owQHs5II7/rQWdFCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeZ3SLKKEBNITS1KzU1MLUotgskwc nFINjFM3nc7g2DXzWKtX50Pm2Y6XemN72u90cTrPePxM8eHBANeZF37mxNsXV91Oyln81nEr k12Uwq+ANM7JS2cXnQs5uc9lIVvNwa1H5qVofYjy09NgXivJt/X1qWOOC8vnaE9XWu9wKf37 tdXrFb7YeYesfs5rk/+mVmbml9ZEqQP7rCauY13kuVuJpTgj0VCLuag4EQAr089NJwMAAA== Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tram-stun-pmtud X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2018 12:21:23 -0000 Authors, could you please respond to Carl's comments below? Thanks! Cheers, Gonzalo On 11/09/2018 3:43 PM, Carl Wallace wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments > just like any other last call comments. > > This document describes a Session Traversal Utilities for NAT (STUN) usage > for Path MTU Discovery (PMTUD) between a client and a server. > > A few comments (bearing in mind I am not versed in STUN specs): > > - It may be worth highlighting the requirement for authentication when > providing an overview of the Complete Probing mechanism in section 2. > - In section 4, replace "Simple Probing mechanism does not require > authentication" with "Simple Probing mechanism does not require > authentication except where used as an implicit signaling mechanism". > - Complete Probing and some uses of Simple Probing require authentication. > Are there any authentication mechanisms that must be supported? > - The second paragraph of the introduction and first paragraph of section > 5 open the use of the spec to non-STUN-based protocols may not square with > all of the MUSTs in the document, some of which require STUN (like section > 4.1.x). > - Why is 5780 marked as informative? Attributes from it are required. > > From nobody Fri Sep 14 06:30:28 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A204130E5B; Fri, 14 Sep 2018 06:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mC-0nLYdx3vn; Fri, 14 Sep 2018 06:30:14 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 0D074130EC4; Fri, 14 Sep 2018 06:30:14 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id w11-v6so6043013iob.2; Fri, 14 Sep 2018 06:30:14 -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:content-transfer-encoding; bh=1fAL8SoWNK+ETWlHUyCD6E8oPCMnIvauSUpHL43HjxA=; b=uP/Vh3Psy5l7ITIz8y03AerkdUs7uTzDEx89dzgCH5goBIaYiUXeJk+4NYuf2R2OUw YjGktRAN++6IM4JU/4LLkJhMsFusrcLPpjUdm4fmDnPEnoXf+TB+vBOSie+mINtOLGk1 VDUQthxduDl3w5onTDUczURTM1kHK16nVTbDNA78dPZj8Ra3DRfOpEhviL1ZGeuLV8G8 E2Y8f12qTHUoGkCYvrbr7T7bu3yTTKIM4kYjEvn+7xwkhn489223nvuiyxKwGgdr8bZW 9vfaT7/mf/jDtzIz1iJLNh6s/Df6AdNcWBESNzK0rkOgLlv173C0t1OQfpRo5uMDwuSL +iGA== 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:content-transfer-encoding; bh=1fAL8SoWNK+ETWlHUyCD6E8oPCMnIvauSUpHL43HjxA=; b=lrzo+cyyGt7CL4lRi4FDlqAh4+oMls3iA3Tqfg8CN9tmdDxvTCkeb5yIhzz/uh0AxO IxJsqYx5H1bfwDJt9oJcJwaa9/Gx4mM49lan5Y5Aekivul3mMM/hlB7mgvTCaaaxHHbx 5T5/mi8+oyHo0zs+LqmajD1DaTi8XJHVbem46zIeXW9wW1W0qghw7VIB76vMz4jAae+J iRelUq9rSazF6qG0Y0rfaupqO43mFYT8H7sBBLBGMvWXPwD9xJxtE2TD5ZZQyvvnOorN /5vBNlh5aATkCUeC00c7yvHroZ0R50mAIT5xe2SjkQCgx7WX8VuREuxmB1gnq0qTf1fH w48Q== X-Gm-Message-State: APzg51C1Loap5DhGCeQt6GLBTQxo2ciSi5u+lcVxTuY85rtHBnjmGaLc uRnpd72fL7MeRmeHFgbtuY2PRbqc9tBM2ma1G0zFym6m X-Google-Smtp-Source: ANB0VdZm/JKmvRBHXuRAuEeNPJ0/E74ZBXMXFgmji+8qdNZ+Tr4nFn3Hr/mR49BfHFrAkSwD2nzDKFE866kqCp7nAyU= X-Received: by 2002:a6b:7846:: with SMTP id h6-v6mr7911588iop.204.1536931813134; Fri, 14 Sep 2018 06:30:13 -0700 (PDT) MIME-Version: 1.0 References: <7aedf62f-780b-6ebd-16eb-d7c2031be91d@cisco.com> In-Reply-To: <7aedf62f-780b-6ebd-16eb-d7c2031be91d@cisco.com> From: Christopher Wood Date: Fri, 14 Sep 2018 06:29:59 -0700 Message-ID: To: fmaino@cisco.com Cc: The IESG , secdir@ietf.org, draft-ietf-lisp-gpe.all@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-lisp-gpe X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2018 13:30:26 -0000 Hi Fabio, Thanks for the quick response! Your proposed additions address my concerns. I assume you all will work out what is best for the diagrams. Best, Chris On Wed, Sep 12, 2018 at 5:12 PM Fabio Maino wrote: > > On 9/9/18 11:26 AM, Christopher Wood wrote: > > Hello, > > > > I have reviewed this document as part of the security directorate's > > ongoing effort to review all IETF documents being processed by the > > IESG. These comments were written primarily for the benefit of the > > security area directors. Document editors and WG chairs should treat > > these comments just like any other last call comments. > > > > The summary of my review is: Ready with issues. > > > > The proposed extension mechanism is simple to understand. However, my > > main concern is regarding the nonce size reduction and implications on > > LISP. While the threat models (on-path and off-path) do not change > > with this extension, the probability of some off-path attacks might > > change. Specifically, the probability of correctly guessing a 16 bit > > nonce is not negligible. This might make attacks in which an adversary > > tries to convince an ITR of reachability to an otherwise unreachable > > ETR more likely. From [1], an ITR that sees the nonce echoed correctly > > =E2=80=9Cknows that the path to and from the ETR is up.=E2=80=9D Thus, = I think some > > discussion of this is necessary in the security considerations. > > Good point. I'll add the following text to the Security Section, after > the very first paragraph: > > "The Echo Nonce Algorithm described in [I-D.ietf-lisp-rfc6830bis] relies > on the nonce to detect reachability from ITR to ETR. In LISP-GPE the use > of a 16-bit nonce, compared with the 24-bit nonce used in LISP, > increases the probability of an off-path attacker to correctly guess the > nonce and force the ITR to believe that a non-reachable RLOC is > reachable. However, the use of common anti-spoofing mechanisms such as > uRPF prevents this form of attack." > > > > Beyond that, I have the following minor comments and nits: > > > > - UDP checksums seem to be the only mechanism in place that give ITRs > > and ETRs a means of checking datagram integrity. Of course, this means > > an on-path adversary can muck with the g-Bit from Section 4.1 so as to > > prevent use of the GPE mechanism. This is not new with this extension, > > though a comment on the issue might be useful, e.g., in the security > > considerations. > > I will add this paragraph to the security section: > > "LISP-GPE, as many encapsulations that use optional extensions, is > subject to on-path adversaries that by manipulating the g-Bit and the > packet itself can remove part of the payload. Typical integrity > protection mechanisms (such as IPsec) SHOULD be used in combination with > LISP-GPE by those protocol extensions that want to protect from on-path > attackers." > > > > - It would be helpful to include packet diagrams similar to Figure 2 > > wherein (1) P and V are set and (2) only P is set. While I don=E2=80=99= t find > > the text misleading or confusing, a figure might help other readers. > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+ > > |N|L|E|1|I|1|K|K| Source MV | Dest MV | Next Protocol= | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+ > > | Instance ID/Locator-Status-Bits = | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+ > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+ > > |0|L|0|0|I|1|K|K| ... 0 ... | Next Protocol= | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+ > > | Instance ID/Locator-Status-Bits = | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+ > > I'd prefer to use diagrams that are congruent with those used in > RFC6830bis. I'll defer this comment to the authors of RFC6830bis, and > follow whatever convention they will decide to follow. > > > > > - In Section 4, where it states, "A LISP-GPE router MUST NOT > > encapsulate non-IP packets to a non LISP-GPE capable router," I might > > replace "to a non LIST-GPE capable router" with "when the P-bit is set > > to 0." > > I will use the following text: > > "A LISP-GPE router MUST NOT encapsulate non-IP packets (that have the > P-bit set to 1) to a non-LISP-GPE capable router." > > > Thanks, > Fabio > > > > > > [1] https://tools.ietf.org/html/draft-ietf-lisp-rfc6830bis-16#section-1= 0.1 > > From nobody Fri Sep 14 09:29:45 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F3C12F1A2 for ; Fri, 14 Sep 2018 09:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.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 xbmSpT4HjY1t for ; Fri, 14 Sep 2018 09:29:40 -0700 (PDT) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 603A1130E82 for ; Fri, 14 Sep 2018 09:29:40 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id d15-v6so5501538qkc.1 for ; Fri, 14 Sep 2018 09:29:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=b5c7FPOJ6pJCRorfhF09I7Tks+dLbalRHND+IhlYpbg=; b=GohL8Nm0NPVR1kazJCDKRby0T3wFwQa8rqSu+hiDzm/EB+1osiMl6VbA1YHmqMSkIh EZCI1KTBLXUpxpKRJpOPwymyayX8gGdx+dFkNnHMAP5tKGOwCz25fPg1w2O1DDMot2zv MQh7YnhJWMXoPYsiJlyCggYXbzItTbtjLYAYg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=b5c7FPOJ6pJCRorfhF09I7Tks+dLbalRHND+IhlYpbg=; b=N+l8F4KFIOcUtpZBYig929tJ6eyXN+3agjdoUQxoBrPaF3v7H5RxDuoIAOwsNVfQVM z108fmEjuFfc7RrOKn0QPqLuF+l2sDH9ew4ZCxKxrilzDt7bP+h5WI1KWIGY56+MwFcN qsbJ46/N/GEyGHohdFQVRdyGFMqjcfFu4ZUyRxJZ5Nl5Pk9m80iAId79yWpiiWysVLkG aErTc0VbMzajnsv/6p/ENqAnp5JJwB6lrI8gYeJf914h0Zm0TKpV2U2VhOeImfn20Jea 5pOzXbKnIyl5H0iR9aaUh+XhNAf0eXrX4CZ7EuZRWWe45JmKBOkhuvxzZkkkSrVSx9SB m2jg== X-Gm-Message-State: APzg51AM5Dc2cQXW5AXQBJ1B6SL66ld3EiylDuh/yqgTLqkk84qc4ucH eMvdzfejLrDjVFbCBQMvq1W0PtBaAOFpTi5J3vvIcg== X-Google-Smtp-Source: ANB0VdbZUkrdrYgIX4cbJ2qOOxm0EgMFTr3hDa8XG87ig3lcvVK4eEk9VSP/NLHsybd8++ZK9R5QscSCvce03cqBo5A= X-Received: by 2002:a37:3492:: with SMTP id b140-v6mr8602943qka.355.1536942579133; Fri, 14 Sep 2018 09:29:39 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a0c:86ea:0:0:0:0:0 with HTTP; Fri, 14 Sep 2018 09:29:38 -0700 (PDT) X-Originating-IP: [2604:6000:8a42:6905:1d06:646e:3613:148c] In-Reply-To: References: <153513922907.22939.10542350679349996082@ietfa.amsl.com> <430EA55E-6D40-45A1-99D3-0978F1B20038@gmail.com> <8025C400-D41F-4A6D-BC14-6A50E80F854D@gmail.com> <5655CB57-721B-4F9C-8F7F-0E38FBA60E0C@gmail.com> From: Kyle Rose Date: Fri, 14 Sep 2018 12:29:38 -0400 Message-ID: To: "BRUNGARD, DEBORAH A" Cc: Dino Farinacci , IETF SecDir , "draft-ietf-lisp-rfc6830bis.all@ietf.org" , IETF Discussion Mailing List , "lisp@ietf.org list" , Benjamin Kaduk , =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: multipart/alternative; boundary="0000000000007841a40575d75408" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-lisp-rfc6830bis-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2018 16:29:44 -0000 --0000000000007841a40575d75408 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable My response is that while I suspect based on the conversation between myself and Dino that LISP's security model probably adequately protects mapping system integrity, my confidence in that judgment is low because the information I need for a security review I can't find in the drafts without reading every LISP-related document in detail, a time commitment I simply can't justify. It's possible there's someone else in the security directorate who knows more about the details of LISP and so would be able to much more easily answer some of these questions with confidence; if so, I would recommend that you ask them to take a look. I'm unwilling to say "LGTM" simply because I can't find a problem in the time I've allocated. Kyle On Tue, Sep 11, 2018 at 5:55 PM, BRUNGARD, DEBORAH A wrote= : > Thanks much Kyle for your comments and Dino for resolving! > > Cutting to the end where Dino asked for help- > > -----Original Message----- > From: Dino Farinacci > Sent: Tuesday, September 11, 2018 2:40 PM > To: Kyle Rose > Cc: IETF SecDir ; draft-ietf-lisp-rfc6830bis.all@ietf.or= g; > IETF Discussion Mailing List ; lisp@ietf.org list < > lisp@ietf.org>; Benjamin Kaduk ; Mirja K=C3=BChlewind < > ietf@kuehlewind.net> > Subject: Re: Secdir last call review of draft-ietf-lisp-rfc6830bis-15 > > > > What I might recommend is either an augmentation of, or a new document > analogous to (and informationally referencing), > draft-ietf-lisp-introduction that covers the expected security properties > of the overall design and the requirements for each of the subcomponents = in > a way that someone can understand without referring to any document other > than the high-level architecture itself. draft-ietf-lisp-introduction is > actually quite good at getting the general point of LISP across to someon= e > new; I want to see something similar for LISP's security model. I think > that's going to be better than inserting clarifying text here or there. > I've actually read enough of this stuff at this point that I'm not sure I > can enumerate exactly what's missing where. The threat model document cou= ld > potentially be folded into that, but it has to start by painting a pictur= e > of the security that someone new to LISP can quickly understand. > > I=E2=80=99ll yield to the WG to respond to this. > > Dino > > [deborah] > > It's difficult to do *one* overview document on an evolving technology, > especially if the intention is to provide reference to other documents > which are also evolving. Lisp-intro is already having its problems and it > is not published yet. > > As Mark Nottingham noted in his "How to Read an RFC" blog, when reading > RFCs, for better or worse and the resulting frustration, it is "necessary > to read not only the relevant text but also anything that it references": > https://www.ietf.org/blog/how-read-rfc/ > > I'd suggest a wiki would be a better tool to capture this "overview" > informational material. Not only can the format be easier on the eye, it > can be a shared effort and timely updated. Similar to Benoit's work on hi= s > YANG tree dependencies, it would be helpful if a working group provided a > working group tree of documents and it could even reference other working > group documents. > > --0000000000007841a40575d75408 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My response is that while I suspect based on the conversat= ion between=20 myself and Dino that LISP's security model probably adequately protects= =20 mapping system integrity, my confidence in that judgment is low because=20 the information I need for a security review I can't find in the drafts= =20 without reading every LISP-related document in detail, a time commitment I = simply=20 can't justify. It's possible there's someone else in the securi= ty=20 directorate who knows more about the details of LISP and so would be=20 able to much more easily answer some of these questions with confidence; if so, I would recommend that you ask them to take a look. I'm=20 unwilling to say "LGTM" simply because I can't find a problem= in the=20 time I've allocated.

Kyle


On Tue, Sep 1= 1, 2018 at 5:55 PM, BRUNGARD, DEBORAH A <db3546@att.com> wrote:=
Thanks much Kyle for your comments and D= ino for resolving!

Cutting to the end where Dino asked for help-

-----Original Message-----
From: Dino Farinacci <farinacci@g= mail.com>
Sent: Tuesday, September 11, 2018 2:40 PM
To: Kyle Rose <krose@krose.org>= ;
Cc: IETF SecDir <secdir@ietf.org&= gt;; draft-ietf-= lisp-rfc6830bis.all@ietf.org; IETF Discussion Mailing List <ietf@ietf.org>; lisp@ietf.org list <lisp= @ietf.org>; Benjamin Kaduk <kadu= k@mit.edu>; Mirja K=C3=BChlewind <ietf@kuehlewind.net>
Subject: Re: Secdir last call review of draft-ietf-lisp-rfc6830bis-15


> What I might recommend is either an augmentation of, or a new document= analogous to (and informationally referencing), draft-ietf-lisp-introducti= on that covers the expected security properties of the overall design and t= he requirements for each of the subcomponents in a way that someone can und= erstand without referring to any document other than the high-level archite= cture itself. draft-ietf-lisp-introduction is actually quite good at gettin= g the general point of LISP across to someone new; I want to see something = similar for LISP's security model. I think that's going to be bette= r than inserting clarifying text here or there. I've actually read enou= gh of this stuff at this point that I'm not sure I can enumerate exactl= y what's missing where. The threat model document could potentially be = folded into that, but it has to start by painting a picture of the security= that someone new to LISP can quickly understand.

I=E2=80=99ll yield to the WG to respond to this.

Dino

[deborah]

It's difficult to do *one* overview document on an evolving technology,= especially if the intention is to provide reference to other documents whi= ch are also evolving. Lisp-intro is already having its problems and it is n= ot published yet.

As Mark Nottingham noted in his "How to Read an RFC" blog, when r= eading RFCs, for better or worse and the resulting frustration, it is "= ;necessary to read not only the relevant text but also anything that it ref= erences":
https://www.ietf.org/blog/how-read-rfc/

I'd suggest a wiki would be a better tool to capture this "overvie= w" informational material. Not only can the format be easier on the ey= e, it can be a shared effort and timely updated. Similar to Benoit's wo= rk on his YANG tree dependencies, it would be helpful if a working group pr= ovided a working group tree of documents and it could even reference other = working group documents.


--0000000000007841a40575d75408-- From nobody Fri Sep 14 10:00:11 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA3C412F1A5; Fri, 14 Sep 2018 09:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwhzw4Aj2nWv; Fri, 14 Sep 2018 09:59:53 -0700 (PDT) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 101C412F1A2; Fri, 14 Sep 2018 09:59:53 -0700 (PDT) Received: by mail-pl1-x630.google.com with SMTP id ba4-v6so4469006plb.11; Fri, 14 Sep 2018 09:59:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mo54qbWH0tRtE4JAYcaR98ceC89lF8vUl+TanjlalTs=; b=A8k6A832onnetWSS3kBKVwFnsWOo6mPVNwYedkz9o/wBn6SVSeoime3CwQUDSiOnss XmDoUkH28ZfKIHsWaNL9+urZXEf1GEj1iB/VsA5tcjpwE79XRDAsx3wuE/d//9zEM3A/ f2l3VBOluiiA3TtNV4DyLYMEvJz8qsYkTepeavcl56RLL/XE6ZSNeLbFjW9i2/HPio4P AhQAB4350AAPi/JQlbGG0dqxoGbkchZIQwpbNzOOAeDHBVZ7yU77VUgm7rK57BUZrkMF +HAHgbo7B3GRtRGXJKstjh0Wew6uiaH+uP5KWkxAr8cZ3UU2FTcEGX107FnUrbnK9A/Q Azjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mo54qbWH0tRtE4JAYcaR98ceC89lF8vUl+TanjlalTs=; b=OKnQl51BF+Lc1xAB6SdOUn66tHmVSbYCYDFxYzKzfH/UcXBUv07HO4XZHmO0SGR/TF Jyur3IcwqYcFs14ZuE5CVmTf9/W/zM0cdnaDRPOZiY3vZVDA2hnoKMybsr7pgn4/9A1n qbjqcAKaEGEv+ze+vTTf4u/RxPaKQHxu7zWxLsUqyFCNJN9wiegIH09oJpNV6E9M6lNp FgTqA1sVC8GIRLvQSOmrfQOA+Ivk7U3X3UIQfYdZRg7/aaIqnc6ZP/44TNFrPJbhAvFU XQG9hdFyRBNpuP4a/z97irnqMq6UiD5CAm4PpPB0nG6is/8XcqqiTOjVvlwGGKWTgKUF g/YA== X-Gm-Message-State: APzg51CiLNg4ru2JBJtlWCsUuePkJg+f3eJgZCx9SecnrMruWMFCKVPT 8V/p3d5FViPm2vp7yWBZ79E= X-Google-Smtp-Source: ANB0VdajRObVIN//dyk8GgKn2rqzjZ2ApTf+Zw52gxy3P8IWvrOyHtA6W8hWtn5nh7oabGGyYJ9rXQ== X-Received: by 2002:a17:902:543:: with SMTP id 61-v6mr13335471plf.126.1536944392529; Fri, 14 Sep 2018 09:59:52 -0700 (PDT) Received: from [10.31.79.252] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id y124-v6sm10886408pfg.63.2018.09.14.09.59.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Sep 2018 09:59:50 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: Date: Fri, 14 Sep 2018 09:59:49 -0700 Cc: "BRUNGARD, DEBORAH A" , IETF SecDir , "draft-ietf-lisp-rfc6830bis.all@ietf.org" , IETF Discussion Mailing List , "lisp@ietf.org list" , Benjamin Kaduk , =?utf-8?Q?Mirja_K=C3=BChlewind?= Content-Transfer-Encoding: quoted-printable Message-Id: <022C3FE7-B146-44BE-9625-EC9FF3637C49@gmail.com> References: <153513922907.22939.10542350679349996082@ietfa.amsl.com> <430EA55E-6D40-45A1-99D3-0978F1B20038@gmail.com> <8025C400-D41F-4A6D-BC14-6A50E80F854D@gmail.com> <5655CB57-721B-4F9C-8F7F-0E38FBA60E0C@gmail.com> To: Kyle Rose X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-lisp-rfc6830bis-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2018 16:59:56 -0000 The SAAG has helped the LISP WG with RFC8061 (data-plane). And Brian = Weiss and Dan Harkins were authors/reviewers. As for the control-plane, draft-ietf-lisp-sec has been around and = implmented by cisco (in 3 implementations). RFC8111 (LISP-DDT) has been = around as well for a while, a pilot network deployed using it, and cisco = has an implementation of LISP-DDT-SEC. Draft draft-farinacci-lisp-ecdsa = is relatively new, necessary for IoT deployments. I have done an = implementation of it. I don=E2=80=99t know if that helps but focusing on = those 3 documents can clearly explain (in detail) the security = mechanisms in place. Your comment is noted about not seeing TLS or DTLS in = draft-ietf-lisp-sec but we had always intended it to be in there. I=E2=80=99= m not sure (I thought it was in) if it was removed for some reason. The = authors can comment about that. Dino > On Sep 14, 2018, at 9:29 AM, Kyle Rose wrote: >=20 > My response is that while I suspect based on the conversation between = myself and Dino that LISP's security model probably adequately protects = mapping system integrity, my confidence in that judgment is low because = the information I need for a security review I can't find in the drafts = without reading every LISP-related document in detail, a time commitment = I simply can't justify. It's possible there's someone else in the = security directorate who knows more about the details of LISP and so = would be able to much more easily answer some of these questions with = confidence; if so, I would recommend that you ask them to take a look. = I'm unwilling to say "LGTM" simply because I can't find a problem in the = time I've allocated. >=20 > Kyle >=20 >=20 > On Tue, Sep 11, 2018 at 5:55 PM, BRUNGARD, DEBORAH A = wrote: > Thanks much Kyle for your comments and Dino for resolving! >=20 > Cutting to the end where Dino asked for help- >=20 > -----Original Message----- > From: Dino Farinacci =20 > Sent: Tuesday, September 11, 2018 2:40 PM > To: Kyle Rose > Cc: IETF SecDir ; = draft-ietf-lisp-rfc6830bis.all@ietf.org; IETF Discussion Mailing List = ; lisp@ietf.org list ; Benjamin Kaduk = ; Mirja K=C3=BChlewind > Subject: Re: Secdir last call review of draft-ietf-lisp-rfc6830bis-15 >=20 >=20 > > What I might recommend is either an augmentation of, or a new = document analogous to (and informationally referencing), = draft-ietf-lisp-introduction that covers the expected security = properties of the overall design and the requirements for each of the = subcomponents in a way that someone can understand without referring to = any document other than the high-level architecture itself. = draft-ietf-lisp-introduction is actually quite good at getting the = general point of LISP across to someone new; I want to see something = similar for LISP's security model. I think that's going to be better = than inserting clarifying text here or there. I've actually read enough = of this stuff at this point that I'm not sure I can enumerate exactly = what's missing where. The threat model document could potentially be = folded into that, but it has to start by painting a picture of the = security that someone new to LISP can quickly understand. >=20 > I=E2=80=99ll yield to the WG to respond to this. >=20 > Dino >=20 > [deborah]=20 >=20 > It's difficult to do *one* overview document on an evolving = technology, especially if the intention is to provide reference to other = documents which are also evolving. Lisp-intro is already having its = problems and it is not published yet. >=20 > As Mark Nottingham noted in his "How to Read an RFC" blog, when = reading RFCs, for better or worse and the resulting frustration, it is = "necessary to read not only the relevant text but also anything that it = references": > https://www.ietf.org/blog/how-read-rfc/ >=20 > I'd suggest a wiki would be a better tool to capture this "overview" = informational material. Not only can the format be easier on the eye, it = can be a shared effort and timely updated. Similar to Benoit's work on = his YANG tree dependencies, it would be helpful if a working group = provided a working group tree of documents and it could even reference = other working group documents. >=20 >=20 From nobody Mon Sep 17 05:14:42 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF4EA130E46; Mon, 17 Sep 2018 05:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-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 NVcntw1GQ6mi; Mon, 17 Sep 2018 05:14:39 -0700 (PDT) Received: from implementers.org (unknown [IPv6:2001:4b98:dc0:45:216:3eff:fe7f:7abd]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F8B1130E50; Mon, 17 Sep 2018 05:14:35 -0700 (PDT) Received: from [IPv6:2601:648:8400:8e7d:a4fc:48ab:dcca:4300] (unknown [IPv6:2601:648:8400:8e7d:a4fc:48ab:dcca:4300]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id D79D3AE009; Mon, 17 Sep 2018 14:14:31 +0200 (CEST) From: Marc Petit-Huguenin To: Carl Wallace , secdir@ietf.org, The IESG , draft-ietf-tram-stun-pmtud.all@ietf.org References: Openpgp: preference=signencrypt Autocrypt: addr=marc@petit-huguenin.org; prefer-encrypt=mutual; keydata= mQINBE6Mh9wBEADrUEDZChteJbQtsHwZITZExr7TAqT7pniNwhBX3nFgd+FrV3lsLKJ1rym2 52MAYpubXEJZGzMp6uCCAnROWbtmQbOm8z/jHnjxHhPqfuYCYPpAQqu8K/Sc194Rp37krMwB jz32yr7+gvWLzRgQGKIh9d2mzy8QLMETVWWQWGb6fEfpOxXo0wumN1rc/275kZwOu44JIPGg zbgwZdnEqYOUUa18K9MXeRDoWbwDISP30CvKuZDwD14lbBE3o7tBQrU9uoMhE7eFlTjbsCox qoubI2tZSuOTF8mRXjPmNrRGtf9mYkQnOB7y6qy/QxmOVMq4IRtHzOYIm/EZ6NTodcpZQHOM 2v6B6YK9uKrYrapSpJzn4f9oU7alT31Y3o2hOlxAWDQ16+Dd1MOPYsKQXOwY1/ihm4PTjiJ8 ud8yPzy7c+BSVs5wkBU6QuLNIgZHrrxdn+KxM+F/oAVtfzO7XzVoeOcXyWi3/CHL5pgoBruY enIF/RrRuplpy09pvZjmFPNfqKBYJGnqpQuqsQwO7LsFqDqfY2EuHg+KsGN1XuN+jxXc48/1 gCnKw7ALSPWEb7g25wD6KfiZTAcyRTG8LePNFQKhw61LbIWmkw9EaVLyXvwPTc1iCSc0dDT/ pcT/z+8xrWOyWGZNZAjR584NlDpKollbItcxYtFcYZkvTCmOVwARAQABtC1NYXJjIFBldGl0 LUh1Z3VlbmluIDxtYXJjQHBldGl0LWh1Z3VlbmluLm9yZz6JAjsEEwEIACUCGyMGCwkIBwMC BhUIAgkKCwQWAgMBAh4BAheAAhkBBQJX8tdbAAoJECnERZXWan7EiNkQAIbS72cyalFjxQ1l vEW9S8NjjwIMbb5+NC2XqDakAmZq+Aav/Yfk8aEc+eAWBboVC3NBBjYojMRXK1XEnD7xPQ1X rWd23TDibKajy/2fo/MS9/s6uPFOAINi1ykOMq8ShxMHcIPC/dvVt59a7DV1KPGlnUheNR7N 4rIbkL5KndatD38yTGkyKsFvVKTHJn3y5zqHTGP0BjE1rxsGEBn4h+EzxVCIMVFQUeMVPKPV dlQY9fxdicSGPK2WKo1KL3CVpnYTuNCAVIGA9DPTXPPKvEte+/+xv10I03pj4w87iMUZt7Ca FTO55Gsf8hZvmpuB224yzrAbquA450EUVcQ7KAPcHrph5KAu0d3nwrjrUDn/RWWbyRiVrPtf hmnAAhkSv7oOxzyMdLvqt7XKGKbABhrl1ZRF8QbquOkyu8n3Bz2Osgw7JyFn9N6svlFPmpML UTEi64NewvN6zszKs/zBS6bn7na75gxHNvjSZpSF6uSLYgmKbyG8vkY/i0s0e0njjOHcpNx1 0mNZ+wOoCgHtSCZFyv14ncioJTiSjtZCs+srW9PFlbOg73C1Op42xV5Y+dh/mCC+rweKtB3t yTAy52v8vPG0VjsLS52x6yUsoDjYV33AmTEaWmGzN5t8BX/qh7pgNIEd9TEwrR3B4LjqMmUk XXWSJG5IM8Zr2OE/t2vyuQINBE6Mh9wBEAC/i4Lh4XEgwi/yHr3XLx/+f38ztn5rrk8XRsK2 WUpu5evxw9iK2oelqWtS71XkW57EavJOjvP4t8FWqRKED5jWN741n12iW/EeLx3KoHMcPTfY 4WWvprxiZPfnCIpQ8j8x0QQSA+Hf96BSkAkOGNkiJDuus5z4XwTktn9gFOwLVx4VRMo+lrCy um6BDHI+4/sOWnrNp2WptI4YKM/uA0HpuLpPKLra0ZW6Bp2TewNpAjbst/VHjqewab0PeSCn CQiHkqIibdgOATT0K6KoVtMxp/WPRSfVImfWCHjT2G7HFMcb6w/jlPSb+u4VtL9yn76CCg8F SqTtzFuqPtbXkhrdSgks/grxiQryMXwpO0uSuUgZ3u2TSs+65Bl2CM5cq+2aBIER5qhpnCv7 B00uHuoNqUEK0VEpLKcqi2ZeVM5oO8iOaBgS9Gh082HQ5JDijEV2J5e4rwXjbRnJ4hqpTjSy caW8HnPI+4S0aqVxbnqW7T6l/xnn7ivK3aPqaRKqUSedHCU3oHIU31n0o5+f5htQeDs/Tpzn ARHkyzu9vZ9CvQXk8daZorA+j/38q6mWU6Mw8FRIu1qPQDmqljobk3vC9BZRSJOn3P8jNMM7 w1j+7Da3rxGBylfa3fmHPyY7dvdyeLmsq7egzTJkpAMN55Qat7iuXeeCdBQLAFHLBP1tvwAR AQABiQIfBBgBCAAJAhsMBQJX8tdcAAoJECnERZXWan7EkMgP/isd3lrSsm/8t+U44LY0/x67 cPmiKa9biveywJZ9Y+Zu/pUP44dP670mY7PmEDGC6lRiPKGmhf7vqq6JJFOqX64VWePQ9QZp kkzAUmIJwQ2Kmcmfrs0J5w2Lf5qaNji25fQYbon0eUFy6eN3BNRSIcg0+OsH7HubTWfpZeJu B7V7k8OFt2+HDx7aNdNutDJIu4V25AzGfonARQzJK62cmB0pwYXpcyDO152OwP12XbpXxXA1 xHGYQBRL98pSbMU5xsMw8j9VQHQRS94aT9Qqnz9SrYuISnMV2WGyIE0rAY3GGz3IcN5LVE1N vSP51ih+YJg/qsBYs8obbfEIZelOuznWf120RgV7P+7ZWCSBohmchuyELQzl9D7FXfulkXA3 RapKQcGJMVPIHYgnlvmE0OXfJl1z09nYRQHitoQhWtviHWl7x/KL42aUzHirLR61iVA2kqkO BhU+u+g2w8qrZj+lJfXIxlbVyLOuBVqkfcK28AR9RriB4Q5hvbDeQJMgfZsV2hBt7huBOqkH nnbSCguqfnmwLGkxoM7RVjCQwvC1M57uwdKMlsTVaBP0RreZnrDngLamK+ibXYe7p8pPAWD9 cuHvkkjML7cIfuvbScDYRmGzia3V9+LVzQCm+q/6xUY1SZvrDz7OaJOy3Xb1d+aPhYaNC0TQ 7IqA1dx8rZYQ Message-ID: Date: Mon, 17 Sep 2018 05:14:29 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="S8IOhq3suyycdzqyGH8l1UJJjBwawiGS5" Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tram-stun-pmtud X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2018 12:14:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --S8IOhq3suyycdzqyGH8l1UJJjBwawiGS5 Content-Type: multipart/mixed; boundary="NHdBsud8KsmFzg4WFeeGArpr9mAQEcsSo"; protected-headers="v1" From: Marc Petit-Huguenin To: Carl Wallace , secdir@ietf.org, The IESG , draft-ietf-tram-stun-pmtud.all@ietf.org Message-ID: Subject: Re: secdir review of draft-ietf-tram-stun-pmtud References: In-Reply-To: --NHdBsud8KsmFzg4WFeeGArpr9mAQEcsSo Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Carl, Thank you for the review. See my comments inline. On 09/11/2018 05:43 AM, Carl Wallace wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG= =2E > These comments were written primarily for the benefit of the security a= rea > directors. Document editors and WG chairs should treat these comments > just like any other last call comments. >=20 > This document describes a Session Traversal Utilities for NAT (STUN) us= age > for Path MTU Discovery (PMTUD) between a client and a server. >=20 > A few comments (bearing in mind I am not versed in STUN specs): >=20 > - It may be worth highlighting the requirement for authentication when > providing an overview of the Complete Probing mechanism in section 2. I added the following paragraph at the end of the section: "Because of the possibility of amplification attack, the Complete Probing mechanism must be authenticated. Particular care must be taken to prevent amplification when an external mechanism is used to trigger the Complete Probing mechanism." > - In section 4, replace "Simple Probing mechanism does not require > authentication" with "Simple Probing mechanism does not require > authentication except where used as an implicit signaling mechanism". Applied. > - Complete Probing and some uses of Simple Probing require authenticati= on. > Are there any authentication mechanisms that must be supported? Any authentication mechanism defined for STUN can be used, there is no sp= ecific constraint to be added. > - The second paragraph of the introduction and first paragraph of secti= on > 5 open the use of the spec to non-STUN-based protocols may not square w= ith > all of the MUSTs in the document, some of which require STUN (like sect= ion > 4.1.x).=20 I do not understand the problem here. There is two protocols involved in= this specification, the first one is any UDP based protocol that does no= t already have a PMTUD mechanism (and that includes STUN based protocols,= as long as they use UDP as transport and they do not have a PMTUD mechan= ism baked-in). The second protocol is one of the two STUN based protocol= s that are described in this document and used on top of the first protoc= ol for the purpose of providing PMTUD. The MUSTs are for these two proto= cols, not for the first protocol. Let me give an example. TFTP is a UDP protocol that does not have a PMTU= D mechanism defined. One can design an extension that is using this spec= ification to add PMTUD and increase the size of the packets without trigg= ered fragmentation. None of the MUST applies to TFTP itself, only to the= PMTUD mechanism. Now lets imagine that someone designed a protocol similar to TFTP using S= TUN instead of an adhoc encoding for the packets, but still without a PMT= UD mechanism. Similarly to the previous example a PMTUD mechanism can be= added on top of that protocol, but the MUSTs in this document still appl= y only to the STUN packets of the PMTUD mechanism, not to the STUN packet= s of the underlying protocol. > - Why is 5780 marked as informative? Attributes from it are required. Moved to the normative section. --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --NHdBsud8KsmFzg4WFeeGArpr9mAQEcsSo-- --S8IOhq3suyycdzqyGH8l1UJJjBwawiGS5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlufmqUACgkQKcRFldZq fsTfRA/+Ji9GnZTTQ4a3iAr38sWYpPCtfrsIKkVbwcZ0GGT02+8L1/G57nXBdT7d bcQ+977dYSh4+7Or0OHWgiLJSN6YWxaUqXwAegSn7HPgoEeK0oW46zGdj4M0SVBX RW2fb6nlGHPlpfFrLjBiib5z80ZRnF6EE5uV43n7nRHSByGg0mYNNYM4mA5AsL9Y FdCLt5kH8+bPWI3Zk9qU9VSYLz/UiyarHjNwwNNTiKULJ3I36o6ANuca3V3mUx9n EkoujR+Kq4Owtdt2LK/8kfqiNll9TfC1iPBxbPs0+dnUTqkAxw0b32KPT0o7Iahb tj4Y81V6ScJ+fGMK0MnmfSVXqizRx6H+D1iJVSt1hB7aR08qSJU25+/7yaScMMXi sNGiwePLjrm32h8QC/t9f43Q504mCRzZae4VVIj4uOq8rRVL6jVZenSmc7bC5zMe AOs4Y1fbPIZ1pZMAjqdJjIVFjYCNQ+VBUTSsjcpkZrC8tstZCnnMe1WqnBTjtIbO Qb9RA7NEFRqE3/+AQ0EClHwHy/LTsy7tT6/UpTroq2RanMjPUrX+yY+hK93kQkSw e0AcVoctfsIC583ssEp9GkETq+aZjF5QOzlYTgkMbYx+71YWJrskrD2o6oifAV2a 9G5/g63tgHhHV8weZwOIDh3EnepWdJzVv9fNVZ2IKEd89pGxSAU= =FQYm -----END PGP SIGNATURE----- --S8IOhq3suyycdzqyGH8l1UJJjBwawiGS5-- From nobody Mon Sep 17 13:14:50 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979AB130E59; Mon, 17 Sep 2018 13:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.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 SCWmx5NKugAa; Mon, 17 Sep 2018 13:14:48 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 0C61A130E2A; Mon, 17 Sep 2018 13:14:44 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w8HKEfhg028071; Mon, 17 Sep 2018 16:14:41 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu w8HKEfhg028071 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1537215281; bh=nwRVJ+xm4UrsypRVflSHGbx+CBp7y25NC/IMx7GjydU=; h=From:To:Subject:Date:From; b=L0/IOQXTx2QY2O0qeKYCQgN6FHfeJbENgq+24PhcngZSsi3Qz17uBeHAIjyW7aAH0 cf2hqW/+UJah8YG/fnPKEAvRDZmkYtzDVrOrdUfSFQNNn0XWdzlOUd487I642QDZLe y9bZB/s4pkZeC2aB8I12y6tRuqFK/yt6g3SHmDng= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w8HKEb3U018390; Mon, 17 Sep 2018 16:14:37 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0399.000; Mon, 17 Sep 2018 16:14:37 -0400 From: Roman Danyliw To: "secdir@ietf.org" , "draft-ietf-dnsop-attrleaf@ietf.org" , "draft-ietf-dnsop-attrleaf.shepherd@ietf.org" Thread-Topic: secdir review of draft-ietf-dnsop-attrleaf-13 Thread-Index: AdROwqzPlID4s//XS/+AXUurM823KA== Date: Mon, 17 Sep 2018 20:14:37 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC014C449262@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [secdir] secdir review of draft-ietf-dnsop-attrleaf-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2018 20:14:50 -0000 Reviewer: Roman Danyliw Review result: Ready with nits Draft: draft-ietf-dnsop-attrleaf-13 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. The summary of the review is "Ready" No new security issues are introduced with this draft. Roman From nobody Mon Sep 17 17:08:52 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED54C128CF2; Mon, 17 Sep 2018 17:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.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 czFO2bRHSXGT; Mon, 17 Sep 2018 17:08:49 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17D36126BED; Mon, 17 Sep 2018 17:08:48 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w8I08lja017465; Mon, 17 Sep 2018 20:08:47 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu w8I08lja017465 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1537229327; bh=2Dkea5VPzqrYEuk8ymCsZZMn1eA5Crz91FK94c2+cZI=; h=From:To:Subject:Date:References:In-Reply-To:From; b=QJ2+diZRbSgcPWQYpLkFdRI5HNemHoUpKqufij2be9dvGrUWPE/++HBcUpQuQWIsi Z9w/Ql1X+hKlbxXW6i/tGNks/AIQESDgPQdxrchXOfF8SqXbIyv0JxuTSxwi+7XyB3 fpMwu8re6dEnS4+CXfVPta/fi3zq1rWhZ5JOf4ao= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w8I08lJ8007123; Mon, 17 Sep 2018 20:08:47 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0399.000; Mon, 17 Sep 2018 20:08:46 -0400 From: Roman Danyliw To: "secdir@ietf.org" , "draft-ietf-dnsop-attrleaf@ietf.org" , "draft-ietf-dnsop-attrleaf.shepherd@ietf.org" Thread-Topic: [secdir] secdir review of draft-ietf-dnsop-attrleaf-13 Thread-Index: AQHUTuPEhe9TIZsyvEO0NvXwVFmxWA== Date: Tue, 18 Sep 2018 00:08:46 +0000 Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC014C449262@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC014C449262@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-dnsop-attrleaf-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2018 00:08:51 -0000 Oops. There was conflicting status in this write-up. It should be =91ready= =92. Roman > On Sep 17, 2018, at 16:15, Roman Danyliw wrote: >=20 > Reviewer: Roman Danyliw > Review result: Ready with nits > Draft: draft-ietf-dnsop-attrleaf-13 >=20 > I have reviewed this document as part of the security directorate's ongoi= ng effort to review all IETF documents being processed by the IESG. These = comments were written primarily for the benefit of the security area direct= ors. Document editors and WG chairs should treat these comments just like = any other last call comments. >=20 > The summary of the review is "Ready" >=20 > No new security issues are introduced with this draft. >=20 > Roman >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Tue Sep 18 07:08:29 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6625D130EED; Tue, 18 Sep 2018 07:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oQNO8ySRLxF; Tue, 18 Sep 2018 07:08:08 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC76130E3C; Tue, 18 Sep 2018 07:08:04 -0700 (PDT) Received: from [192.168.20.160] (CPEf4cc55220745-CM64777ddff610.cpe.net.cable.rogers.com [173.32.191.82]) by mail.networkradius.com (Postfix) with ESMTPSA id 893061CB; Tue, 18 Sep 2018 14:08:03 +0000 (UTC) From: Alan DeKok Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: Date: Tue, 18 Sep 2018 10:08:02 -0400 Cc: draft-ietf-tsvwg-rlc-fec-scheme.all@ietf.org To: secdir@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [secdir] Secdir review of draft-ietf-tsvwg-rlc-fec-scheme X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2018 14:08:14 -0000 I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. The summary of the review is read with nits The document seems to clearly describe what it's doing and why.=20 One nit I have is the formulae in the document, e.g.: dw_max_size =3D (max_lat * br_out * cr) / (8 * E) My concern here is about numerical overflow, which could lead to = improper calculations and security problems. Experience has shown that naive implementations will just do the = calculations no matter what the inputs. Garbage inputs then lead to = garbage outputs, and we have problems. It would be good to: * state the limits on each of the variables, so that implementations can = know that values *outside* of these limits are erroneous, and should be = ignored * state the minimum size of each of the above variables. e.g. = "dw_max_size" is likely not going to be an 8-bit integer. So what data = types are sufficient to perform the calculations correctly? This information may be in another document, but it wasn't clear on = cursory inspection. 3.1.2: Another approach consists in using ADU timing information (e.g., using the timestamp field of an RTP packet header What happens if the timestamp is outside of reasonable bounds? There = could be a recommendation that only timestamps within a certain window = are used. e.g. an adversary sends timestamps which are unreasonable, and a naive = implementation could use those, and engage in integer overflow, etc. Section 8 describes protections against many adversarial attacks, = which is good. I would suggest adding a sub-section of Section 8, discussion = computation / numerical issues, as discussed above. =20 Other than that, the document looks fine.= From nobody Wed Sep 19 00:03:52 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB06130F7E for ; Wed, 19 Sep 2018 00:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOpxwPIwUQns for ; Wed, 19 Sep 2018 00:03:49 -0700 (PDT) Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) (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 A0D30126CC7 for ; Wed, 19 Sep 2018 00:03:48 -0700 (PDT) Received: by mail-lj1-x244.google.com with SMTP id p10-v6so4031767ljg.2 for ; Wed, 19 Sep 2018 00:03:48 -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:cc; bh=r8vTREydff/DtTKEur2mbvNEmTM35HK22fBBvipa5Ac=; b=X1s/MPfVWxSnBUDDiD16DUwV7Gd/FbpUSNHltIDhwJvuV1NxQxplHxzFRwEndyf6KT I6CqhTm/ImBXryvIwMFQbed5zR9nZuaZIwPzeV2Hy8I3BZo4Y3u0taRxZYhsEiLllm+C yUEGTHllyU1z9pMngHiZT3RtXiwUgateJ7rDj7KCjsAHENmSl+byiFogSWlun4pZiI/n rrB97lXo0j72lTpuAEQxnckax9lzIWQxy26GiIU/ETXJKtqibrn6HAxQS5w7UhhHC1x3 yKufBVgvFpQ/tloqHYejnXGOMfvObWrW/XPeT9rpBVhNLxAqacVPqhdZf1g5f0Rvo9fr WKKA== 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:cc; bh=r8vTREydff/DtTKEur2mbvNEmTM35HK22fBBvipa5Ac=; b=MNt8z08apaK1921W8elRnAiQYoOs0q6FcA1Tx/EpwLKxQAYPuthsQlnLKwQ6ucQhJB 1NGCH8XTQT+G5fEwXn33T1U95WLPJKBiMTAzKpfBvrPNtONQyJkDxnzD+1PVX+z/w8zr Ruv7zLtioHtVYuvHvU9elyl3lWVs3LsyjaDhBAIVHq7RlsNzc0I09TdDAmHVR30NTi4S 2grcCQBWmTjhuUdMX3jZn3qzsGWbux8VORUibKqMd35MioOweIoij5JmZ0ZmQl5MM62C B606D2XUiJT48V1Y0ie6QebTHD+X6dc3sWeU8FDMIpTvZO4mP4D6FJ3tfuRl6GdVw2CQ 3dbw== X-Gm-Message-State: APzg51Bjt8Zah/rGpHGvT0sXo7wC3yClX143k+cq7gWczzD8hd7emtf9 sqJBaPjXe0sZjafYNX21HdmkZIQSfcK1xCoPZ4/MwSM7 X-Google-Smtp-Source: ANB0VdZSGWWw1Zha05osRA6W1gz4N5jM++dPmaTOrhsZlNoP39loBGTZ4mPs7+4/XkqqcCOo6jT4zy20CAgoR5Lxoes= X-Received: by 2002:a2e:9791:: with SMTP id y17-v6mr20689888lji.41.1537340626486; Wed, 19 Sep 2018 00:03:46 -0700 (PDT) MIME-Version: 1.0 From: Shawn Emery Date: Wed, 19 Sep 2018 01:03:35 -0600 Message-ID: To: secdir@ietf.org, draft-ietf-opsawg-ipfix-bgp-community.all@tools.ietf.org Content-Type: multipart/alternative; boundary="000000000000f0ca7805763401db" Archived-At: Subject: [secdir] Review of draft-ietf-opsawg-ipfix-bgp-community-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2018 07:03:52 -0000 --000000000000f0ca7805763401db Content-Type: text/plain; charset="UTF-8" Reviewer: Shawn M. Emery Review result: Ready with numerous nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft specifies new Information Elements (IEs) in order to support BGP community information for the IP Flow Information eXport (IPFIX) protocol. The security considerations section does exist and states that the draft just defines new IEs and does not introduce any new security considerations. The section then goes on to state that the same security issues that apply to the IPFIX protocol and the corresponding Information Model applies to this specification. I agree with these assertions. General comments: None. Editorial comments: s/differnt/different/g s/Netwok/Network/ s/statistic/statistics/ s/mediator needs/the mediator needs/ s/Mediator is/The mediator is/ s/figure up/determine/g s/mechanisum/mechanism/ s/generted/generated/ s/Please refer/Please refer to/g s/originated from AS A and destinated/originating from AS A and destined/ s/becuse it will cause the congestion/because it will cause congestion/ s/togecher/together/ s/source IP and destination IP/source and destination IP address/g s/both the source IP and the destination IP related/relating to both the source and destination IP addresses/ s/length one IPFIX/length of one IPFIX/ s/to the information about the networks in the field/to information about networks in the field/ OLD: configure export policy of BGP communities on the exporter to limit the BGP communities to be exported, so as to only export some specific communities,or not to export some specific communities. NEW: configure the export policy of BGP communities to limit the BGP communities by including or excluding specific communities. s/The detailed mechanism is out of the scope of this document./The details of increasing IPFIX message length is out of scope for this document./ s/refer Appendix A/refer to Appendix A/ s/source or destination IP/source or destination IP address/ Shawn. -- --000000000000f0ca7805763401db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Reviewer: Shawn M. EmeryReview result: Ready with numerous nits

<= /div>I have reviewed this document as part of the securit= y directorate's
ongoing effort = to review all=C2=A0IETF=C2=A0documents be= ing processed by the IESG.
These co= mments were written primarily for the benefit of the security
area directors. Document editors and WG chairs s= hould treat these
comments just lik= e any other last call comments.

This draft specifies new Information Elements (IEs) = in order to support BGP community
information for the IP Flow Information eXport (IPFIX) prot= ocol.

The security consideratio= ns section does exist and states that the draft just defines
new IEs and does not introduce a= ny new security considerations.=C2=A0 The section then
goes on to state that the same securit= y issues that apply to the IPFIX protocol and
the corresponding Information Model applies=C2= =A0to this specification.=C2=A0 I agree wi= th these
assertions.

General comments:

None.

Editorial comments:=

s/differnt/d= ifferent/g
s/Netwok/N=
etwork/
s/statistic/statistics=
/
s/mediator needs/the mediato=
r needs/
s/Mediator is/The med=
iator is/
s/f=
igure up/determine/g
s/mechanisum/mechanism/
s/generted/generated/=

s/Please refer/Please refer to/g
s/originated from AS A a=
nd destinated/originating from AS A and destined/
s/becuse it will =
cause the congestion/because it will cause congestion/
s/togech= er/together/
s/source IP and destination IP/source and destination =
IP address/g
s/both the source IP and the destination IP related/re=
lating to both the source and destination IP addresses/
s/lengt= h one IPFIX/length of one IPFIX/
s/to the information about the net=
works in the field/to information about networks in the field/
= 

=

OLD:
configure export policy of BGP communities on the ex=
porter to limit the BGP communities to be exported, so as to only export so=
me specific communities,or not to export some specific communities.<=
/pre>
NEW:
configure the export policy of BGP communities to limit the B=
GP communities by including or excluding specific communities.
=


=

s/The detailed mechanism is out of the scope of this document./Th=
e details of increasing IPFIX message length is out of scope for this docum=
ent./
s/refer =
Appendix A/refer to Appendix A/
s/source or destination IP/source o=
r destination IP address/

Shawn.
--
<= /div>
--000000000000f0ca7805763401db-- From nobody Wed Sep 19 02:37:32 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32BCF130DC7; Wed, 19 Sep 2018 02:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlejB2Q6m_tN; Wed, 19 Sep 2018 02:37:16 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 6A5E112F1A2; Wed, 19 Sep 2018 02:37:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.53,393,1531778400"; d="scan'208,217";a="279372264" Received: from demeter.inrialpes.fr ([194.199.28.3]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Sep 2018 11:37:13 +0200 From: Vincent Roca Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_94B6AE9A-7444-411A-A7DC-BBFE2F118097" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 19 Sep 2018 11:37:12 +0200 In-Reply-To: Cc: secdir@ietf.org, draft-ietf-tsvwg-rlc-fec-scheme.all@ietf.org, tsvwg@ietf.org, The IESG To: aland@deployingradius.com References: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-tsvwg-rlc-fec-scheme X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2018 09:37:19 -0000 --Apple-Mail=_94B6AE9A-7444-411A-A7DC-BBFE2F118097 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Alan, Thanks a lot for your SECDIR review. NB: I have added IESG (you forgot to do so) and TSVWG (to let everybody = know) to the CC list of this answer. > Le 18 sept. 2018 =C3=A0 16:08, Alan DeKok = a =C3=A9crit : >=20 > I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. >=20 > The summary of the review is read with nits >=20 > The document seems to clearly describe what it's doing and why.=20 >=20 > One nit I have is the formulae in the document, e.g.: >=20 > dw_max_size =3D (max_lat * br_out * cr) / (8 * E) >=20 > My concern here is about numerical overflow, which could lead to = improper calculations and security problems. >=20 > Experience has shown that naive implementations will just do the = calculations no matter what the inputs. Garbage inputs then lead to = garbage outputs, and we have problems. >=20 > It would be good to: >=20 > * state the limits on each of the variables, so that implementations = can know that values *outside* of these limits are erroneous, and should = be ignored >=20 > * state the minimum size of each of the above variables. e.g. = "dw_max_size" is likely not going to be an 8-bit integer. So what data = types are sufficient to perform the calculations correctly? >=20 > This information may be in another document, but it wasn't clear on = cursory inspection. This is a very good point.=20 NEW in section 3.1.1: The ew_max_size is the main parameter at a FECFRAME sender. It is RECOMMENDED to check that the ew_max_size value stays within reasonnable bounds in order to avoid hazardous behaviours. and later (same section): It is RECOMMENDED to check that the ls_max_size value stays within reasonnable bounds in order to avoid hazardous behaviours. NEW section: 8.5. Additional Security Considerations for Numerical Computations In addition to the above security considerations, inherited from [RFC6363], the present document introduces several formulae, in particular in Section 3.1.1. It is RECOMMENDED to check that the computed values stay within reasonnable bounds since numerical overflows, caused by an erroneous implementation or an erroneous input value, may lead to hazardous behaviours. However what "reasonnable bounds" means is use-case and implementation dependent and is not detailed in this document. Section 3.1.2 also mentions the possibility of "using the timestamp field of an RTP packet header" when applicable. A malicious attacker may deliberately corrupt this header field in order to trigger hazardous behaviours at a FECFRAME receiver. Protection against this type of content corruption can be addressed with the above recommendations on a baseline secure operation. In addition, it is also RECOMMENDED to check that the timestamp value be within reasonnable bounds. > 3.1.2: >=20 > Another approach consists in using ADU timing information (e.g., > using the timestamp field of an RTP packet header >=20 > What happens if the timestamp is outside of reasonable bounds? There = could be a recommendation that only timestamps within a certain window = are used. >=20 > e.g. an adversary sends timestamps which are unreasonable, and a = naive implementation could use those, and engage in integer overflow, = etc. >=20 > Section 8 describes protections against many adversarial attacks, = which is good. >=20 > I would suggest adding a sub-section of Section 8, discussion = computation / numerical issues, as discussed above. =20 Good point. In our implementation we do not rely on NTP timestamp but on the 2nd = possibility mentioned in the I-D: "Another approach consists in using ADU timing information (e.g., = using the timestamp=20 field of an RTP packet header, or registering the time upon = receiving a new ADU)." Using the gettimeofday() (or a similar system call) relieves from this = problem and avoids to dig into packet headers to get the RTP timestamp. However we have added = a sentence to warn an implementer about this risk (see the 2nd paragraph on new = section 8.5 above) > Other than that, the document looks fine. Thanks a lot for these suggestions. We=E2=80=99re preparing a new version that will also answer the Genart = review from Russ H. Cheers, Vincent and Belkacem --Apple-Mail=_94B6AE9A-7444-411A-A7DC-BBFE2F118097 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello= Alan,

Thanks a lot = for your SECDIR review.

NB: I have added IESG (you forgot to do so) and TSVWG (to let = everybody know) to the CC list of this answer.

Le 18 sept. 2018 =C3=A0 16:08, Alan DeKok = <aland@deployingradius.com> a =C3=A9crit :

I = have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments.

The summary of the review is read with nits

 The document seems to clearly describe what it's doing = and why.

 One nit I have is the = formulae in the document, e.g.:

=   dw_max_size =3D (max_lat * br_out * cr) / (8 * E)

 My concern here is about numerical = overflow, which could lead to improper calculations and security = problems.

 Experience has shown that = naive implementations will just do the calculations no matter what the = inputs.  Garbage inputs then lead to garbage outputs, and we have = problems.

 It would be good to:

* state the limits on each of the variables, = so that implementations can know that values *outside* of these limits = are erroneous, and should be ignored

* = state the minimum size of each of the above variables.  e.g. = "dw_max_size" is likely not going to be an 8-bit integer.  So what = data types are sufficient to perform the calculations correctly?

 This information may be in another = document, but it wasn't clear on cursory inspection.

This = is a very good point. 

NEW in = section 3.1.1:
   The ew_max_size is the = main parameter at a FECFRAME sender.  It is
  =  RECOMMENDED to check that the ew_max_size value stays = within
   reasonnable bounds in order to avoid = hazardous behaviours.

and = later (same section):
   It is RECOMMENDED to check = that the ls_max_size value
   stays within = reasonnable bounds in order to avoid hazardous
  =  behaviours.

NEW = section:

8.5.  Additional = Security Considerations for Numerical Computations

   In addition to the above security = considerations, inherited from
   [RFC6363], the = present document introduces several formulae, in
  =  particular in Section 3.1.1.  It is RECOMMENDED to check that = the
   computed values stay within reasonnable = bounds since numerical
   overflows, caused by an = erroneous implementation or an erroneous
   input = value, may lead to hazardous behaviours.  However = what
   "reasonnable bounds" means is use-case and = implementation dependent
   and is not detailed in = this document.

   Section = 3.1.2 also mentions the possibility of "using the = timestamp
   field of an RTP packet header" when = applicable.  A malicious attacker
   may = deliberately corrupt this header field in order to = trigger
   hazardous behaviours at a FECFRAME = receiver.  Protection against this
   type of = content corruption can be addressed with the above
  =  recommendations on a baseline secure operation.  In addition, = it is
   also RECOMMENDED to check that the = timestamp value be within
   reasonnable = bounds.

3.1.2:

  Another approach consists in using ADU timing = information (e.g.,
  using the timestamp field = of an RTP packet header

 What happens = if the timestamp is outside of reasonable bounds?  There could be a = recommendation that only timestamps within a certain window are used.

 e.g. an adversary sends timestamps = which are unreasonable, and a naive implementation could use those, and = engage in integer overflow, etc.

=  Section 8 describes protections against many adversarial attacks, = which is good.

 I would suggest = adding a sub-section of Section 8, discussion computation / numerical = issues, as discussed above.  

Good = point.
In our implementation we do not rely on NTP timestamp = but on the 2nd possibility mentioned
in the = I-D:
   "Another approach consists in using ADU = timing information (e.g., using the timestamp 
  =    field of an RTP packet header, or registering the time upon = receiving a new ADU)."
Using the gettimeofday() (or a similar = system call) relieves from this problem and avoids to
dig into = packet headers to get the RTP timestamp. However we have added a = sentence to
warn an implementer about this risk (see the 2nd = paragraph on new section 8.5 above)


 Other than that, the document looks = fine.

Thanks a lot for = these suggestions.
We=E2=80=99re preparing a new version that = will also answer the Genart review from Russ H.

Cheers,

  = Vincent and Belkacem

= --Apple-Mail=_94B6AE9A-7444-411A-A7DC-BBFE2F118097-- From nobody Wed Sep 19 16:57:34 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 98BC1130DFF; Wed, 19 Sep 2018 16:57:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Brian Weis To: Cc: draft-ietf-dhc-dhcp4o6-saddr-opt.all@ietf.org, dhcwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153740144458.21482.13412260727597192650@ietfa.amsl.com> Date: Wed, 19 Sep 2018 16:57:24 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-dhc-dhcp4o6-saddr-opt-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2018 23:57:25 -0000 Reviewer: Brian Weis Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document provides a new DHCPv4 option to enables a DHCP 4o6 client to request binding of its DHCPv4 and DHCPv6 addresses in a Softwire. The security considerations section states that the security considerations of DHCP 4o6 are applicable to this draft, and I agree. I do not see any need for text beyond what is already written. I believe it is Ready to publish. From nobody Thu Sep 20 00:44:11 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5821E130DD1 for ; Thu, 20 Sep 2018 00:44:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu Message-ID: <153742944935.19744.11217306908317492321.idtracker@ietfa.amsl.com> Date: Thu, 20 Sep 2018 00:44:09 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2018 07:44:10 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2018-09-27 Reviewer LC end Draft Derek Atkins 2018-09-25 draft-ietf-dnsop-isp-ip6rdns-06 Kyle Rose R2018-08-29 draft-ietf-lisp-rfc6830bis-18 David Waltermire 2018-09-12 draft-ietf-isis-segment-routing-msd-15 Klaas Wierenga 2018-09-06 draft-ietf-softwire-mesh-multicast-23 Paul Wouters 2018-09-06 draft-ietf-dnsop-kskroll-sentinel-15 For telechat 2018-10-11 Reviewer LC end Draft Dacheng Zhang None draft-ietf-iasa2-trust-update-00 Last calls: Reviewer LC end Draft John Bradley 2018-09-25 draft-ietf-dnsop-attrleaf-fix-04 John Bradley 2018-06-18 draft-ietf-bfd-multipoint-active-tail-09 Donald Eastlake 2018-09-24 draft-ietf-tsvwg-fecframe-ext-06 Daniel Franke 2018-06-28 draft-ietf-netconf-rfc7895bis-06 Daniel Gillmor 2018-06-25 draft-ietf-dnsop-session-signal-15 Daniel Gillmor 2018-03-19 draft-gutmann-scep-10 Phillip Hallam-Baker 2018-10-03 draft-ietf-detnet-use-cases-18 Steve Hanna 2018-10-03 draft-ietf-detnet-problem-statement-06 Dan Harkins 2018-10-03 draft-ietf-detnet-architecture-08 Russ Housley 2018-10-02 draft-ietf-ccamp-mw-yang-09 Christian Huitema 2018-10-02 draft-ietf-anima-bootstrapping-keyinfra-16 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Samuel Weiler 2018-09-07 draft-ietf-tictoc-1588v2-yang-10 Samuel Weiler 2018-05-21 draft-ietf-bfd-multipoint-18 Liang Xia 2018-10-10 draft-campbell-sip-messaging-smime-03 Taylor Yu 2018-10-09 draft-murchison-tzdist-tzif-14 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Next in the reviewer rotation: Phillip Hallam-Baker Steve Hanna Dan Harkins Russ Housley Christian Huitema Leif Johansson Benjamin Kaduk Charlie Kaufman Scott Kelly Stephen Kent From nobody Thu Sep 20 03:31:42 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925B3130E50; Thu, 20 Sep 2018 03:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.125 X-Spam-Level: X-Spam-Status: No, score=-1.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 7halI1ETkgI7; Thu, 20 Sep 2018 03:31:32 -0700 (PDT) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-pu1apc01olkn080f.outbound.protection.outlook.com [IPv6:2a01:111:f400:febe::80f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BC3F130E3B; Thu, 20 Sep 2018 03:31:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GsRGVQWyfSgBQ3jfY7hv08QGNwVWQi8S3fspi9WFAoc=; b=I3MlGG+lv5v0AG3B52ATBf9lIHpDrxhjlxs0o8B2mmkdByotVyZxKo4QsyBw4RFLvfYGAltkJJI4npJAsSf476Ujf0RcmNzcN1JNPfpYR2AN1buBtFPTJAMPkbAeVzJMgY3VkgabEavDj6ekIOtSQjCfqIPme0113I+0M4qNHVHu/64icUgFYQSY+pMcOb7Gr1D0jWJLUggxNjj40IFQ+nSaz8COk/xe9AjOAbhM0/KIm1EHBD5vJTrA9LJjqcTnTqZLFOl1wJa8uDoaYDyFCE2qKU+E2f+0apRuJlio7BsEIGHOo/3fRyJ01OOXrzY24yjoRZZ5mjWqe/b6s+PyZQ== Received: from PU1APC01FT020.eop-APC01.prod.protection.outlook.com (10.152.252.58) by PU1APC01HT097.eop-APC01.prod.protection.outlook.com (10.152.253.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.1164.13; Thu, 20 Sep 2018 10:31:28 +0000 Received: from SG2PR06MB2170.apcprd06.prod.outlook.com (10.152.252.52) by PU1APC01FT020.mail.protection.outlook.com (10.152.252.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.1164.13 via Frontend Transport; Thu, 20 Sep 2018 10:31:28 +0000 Received: from SG2PR06MB2170.apcprd06.prod.outlook.com ([fe80::ac4e:9355:9d60:3ef8]) by SG2PR06MB2170.apcprd06.prod.outlook.com ([fe80::ac4e:9355:9d60:3ef8%6]) with mapi id 15.20.1143.014; Thu, 20 Sep 2018 10:31:28 +0000 From: li zhenqiang To: Shawn Emery , secdir , draft-ietf-opsawg-ipfix-bgp-community.all , opsawg Thread-Topic: Review of draft-ietf-opsawg-ipfix-bgp-community-07 Thread-Index: AQHUUM0WcC149jzhrUONRg77T/T5qA== Date: Thu, 20 Sep 2018 10:31:28 +0000 Message-ID: References: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: SG2PR06CA0172.apcprd06.prod.outlook.com (2603:1096:1:1e::26) To SG2PR06MB2170.apcprd06.prod.outlook.com (2603:1096:4:f::22) x-incomingtopheadermarker: OriginalChecksum:655C93B4C8EFD641E3BE0A777F7903D2EA547449F5F3AA2987D3B88014AECE60; UpperCasedChecksum:CA4DE835C783D80E1D90437771A4CEF1BB5D169712631F183950A4171AC9E89E; SizeAsReceived:7569; Count:49 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [k5GxVxFNjMyKWIi9SclDeqEM3qVQUXMldtA7RYRGa+8=] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; PU1APC01HT097; 6:vM25aS5BIFFuS9nxxuP3yzSCFpV5uWVTY6bTrmssr+bZPHNYlhddOjgBtahLdyijLIj8qDX92i2qZv+kqN7REAaYfZsmSDotAsmAH4fWqX93uHV1cFgXQKe3Ba4bVtLmp/y/7cGcCT40s104u9PRswzM+avVJ2tipzJafXUPvts28tScpyVssRu9SJ+B12vv3fWAfNWq62wMmKRCgfN/9zBcJcGz206spx/YTJlb/0bsVssyYirsI/aXajekmaY61GNbBuql8k2FV6bmHk7DYS4vlM7QELKahdIxlPqKsVrzhcuppnKtn5OzmFFRSwt0IhgBCP4NoOSd4tRECcqtD1Pdi7vyrxdK1mpaZfTDnMkesaiRzLRkHe8wchVlQmsQ1lYtQgncJxQ9d8b/Jf0T2rnPTeanTSoSSNyubIbaJW7cO21PrMFz7hSZ/jG1Hf+WXXEV2F41WtZkW3Mp4MhKTw==; 5:Eqv/g3aqW7LJ4b52d9u9CHqB5Qof3iWs9rsqWq+zANK0uhFa1MIzhMlFb+YixWpH1YkMMPslWcuiSB/XA/iQ01zlFoVYWB9+SDp7WMoSvjh9iXC4v1/Ref1uPsdcc1chkmhSOkSkZTKBxvfspyjnT6T6/5F1mKtfpm9XE3+/cEo=; 7:TQsHHKn4HkMkSPnxlD+FUz7ukpyv5rRXAL8XcQ+OJI0bEywdDv+bgbCuLQHIDeImnkOSk4kZFIQ+rA8sCveKt7Iw5VWN4nOqGOkcvplPAJqHPcMeCUInNK+SbR/ZgQmkjOr/mdZ58+lhxu/BsGVGooPIx6idKf9Woads9P1aLfdP2zN5LB45ipknSFpH4ZNP6Mh8d6KErb5vHcz6h/HTSNz5L/OQVV3zwF0NEMs0ux+tt+38n+voz3DIqPuif2WN x-incomingheadercount: 49 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101475)(1601125500)(1701031045); SRVR:PU1APC01HT097; x-ms-traffictypediagnostic: PU1APC01HT097: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(4566010)(82015058); SRVR:PU1APC01HT097; BCL:0; PCL:0; RULEID:; SRVR:PU1APC01HT097; x-forefront-prvs: 0801F2E62B x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(189003)(199004)(345774005)(5070765005)(5660300001)(86152003)(55016002)(7696005)(53546011)(45080400002)(236005)(9686003)(102836004)(71200400001)(86362001)(71190400001)(54896002)(99286004)(6436002)(8676002)(14444005)(14454004)(82202002)(6346003)(446003)(256004)(2900100001)(4326008)(26005)(25786009)(56003)(74316002)(105586002)(39060400002)(106356001)(486006)(33656002)(73972006)(20460500001)(6246003)(110136005)(5250100002)(81156014)(104016004)(229853002)(97736004)(87572001)(6506007)(386003)(8936002)(76176011)(476003)(83332001)(68736007)(15852004); DIR:OUT; SFP:1901; SCL:1; SRVR:PU1APC01HT097; H:SG2PR06MB2170.apcprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: hotmail.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=li_zhenqiang@hotmail.com; x-microsoft-antispam-message-info: dLVGFpd42ukmngxutm/XMstpdwdRglZC3Itgw+hXzZXwuowU00VikoMPn43cMzZy5mHnSjw8r8QzHO8GVaeDB1xliLJ7yghheXKKACEf1eGQ88GjtjAONpp4S/EambJ4i7rVCRLok3Cwxax8SqQAGZH4FGqfAQlYEmpeTAB0VjEDYz71WUNWQBA3IoI3GVrozmDi/k56R6Np933lz8mr5p9r+Exk8UCyfTGMm/dPAxk= Content-Type: multipart/alternative; boundary="_000_SG2PR06MB217016BC102E505BFA30DC97FC130SG2PR06MB2170apcp_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 24fd1209-d934-423e-a578-ee886993c07f X-MS-Exchange-CrossTenant-Network-Message-Id: 93b97761-8287-4c74-299c-08d61ee438b2 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 24fd1209-d934-423e-a578-ee886993c07f X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Sep 2018 10:31:28.0586 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT097 Archived-At: Subject: Re: [secdir] Review of draft-ietf-opsawg-ipfix-bgp-community-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2018 10:31:35 -0000 --_000_SG2PR06MB217016BC102E505BFA30DC97FC130SG2PR06MB2170apcp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBTaGF3biBNLiBFbWVyeSwNCg0KVGhhbmsgeW91IGZvciB5b3VyIHJldmlldyBhbmQgbml0 cy4gSSBoYXZlIGNvcnJlY3RlZCBhbGwgdGhlIG5pdHMgYW5kIHVwbG9hZGVkIGEgbmV3IHZlcnNp b24gLTA4LiBQbGVhc2UgY2hlY2sgYW5kIHRoYW5rcyBhZ2Fpbi4NCg0KWmhlbnFpYW5nIExpDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbGlfemhlbnFpYW5nQGhvdG1haWwuY29t DQoNCkZyb206IFNoYXduIEVtZXJ5PG1haWx0bzpzaGF3bi5lbWVyeUBnbWFpbC5jb20+DQpEYXRl OiAyMDE4LTA5LTE5IDE1OjAzDQpUbzogc2VjZGlyPG1haWx0bzpzZWNkaXJAaWV0Zi5vcmc+OyBk cmFmdC1pZXRmLW9wc2F3Zy1pcGZpeC1iZ3AtY29tbXVuaXR5LmFsbDxtYWlsdG86ZHJhZnQtaWV0 Zi1vcHNhd2ctaXBmaXgtYmdwLWNvbW11bml0eS5hbGxAdG9vbHMuaWV0Zi5vcmc+DQpDQzogU2hh d24gRW1lcnk8bWFpbHRvOnNoYXduLmVtZXJ5QGdtYWlsLmNvbT4NClN1YmplY3Q6IFJldmlldyBv ZiBkcmFmdC1pZXRmLW9wc2F3Zy1pcGZpeC1iZ3AtY29tbXVuaXR5LTA3DQoNClJldmlld2VyOiBT aGF3biBNLiBFbWVyeQ0KUmV2aWV3IHJlc3VsdDogUmVhZHkgd2l0aCBudW1lcm91cyBuaXRzDQoN CkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRp cmVjdG9yYXRlJ3MNCm9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMg YmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLg0KVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVu IHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5DQphcmVhIGRpcmVjdG9y cy4gRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZQ0KY29t bWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQoNClRoaXMgZHJh ZnQgc3BlY2lmaWVzIG5ldyBJbmZvcm1hdGlvbiBFbGVtZW50cyAoSUVzKSBpbiBvcmRlciB0byBz dXBwb3J0IEJHUCBjb21tdW5pdHkNCmluZm9ybWF0aW9uIGZvciB0aGUgSVAgRmxvdyBJbmZvcm1h dGlvbiBlWHBvcnQgKElQRklYKSBwcm90b2NvbC4NCg0KVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRp b25zIHNlY3Rpb24gZG9lcyBleGlzdCBhbmQgc3RhdGVzIHRoYXQgdGhlIGRyYWZ0IGp1c3QgZGVm aW5lcw0KbmV3IElFcyBhbmQgZG9lcyBub3QgaW50cm9kdWNlIGFueSBuZXcgc2VjdXJpdHkgY29u c2lkZXJhdGlvbnMuICBUaGUgc2VjdGlvbiB0aGVuDQpnb2VzIG9uIHRvIHN0YXRlIHRoYXQgdGhl IHNhbWUgc2VjdXJpdHkgaXNzdWVzIHRoYXQgYXBwbHkgdG8gdGhlIElQRklYIHByb3RvY29sIGFu ZA0KdGhlIGNvcnJlc3BvbmRpbmcgSW5mb3JtYXRpb24gTW9kZWwgYXBwbGllcyB0byB0aGlzIHNw ZWNpZmljYXRpb24uICBJIGFncmVlIHdpdGggdGhlc2UNCmFzc2VydGlvbnMuDQoNCkdlbmVyYWwg Y29tbWVudHM6DQoNCk5vbmUuDQoNCkVkaXRvcmlhbCBjb21tZW50czoNCg0Kcy9kaWZmZXJudC9k aWZmZXJlbnQvZw0KDQpzL05ldHdvay9OZXR3b3JrLw0KDQpzL3N0YXRpc3RpYy9zdGF0aXN0aWNz Lw0KDQpzL21lZGlhdG9yIG5lZWRzL3RoZSBtZWRpYXRvciBuZWVkcy8NCg0Kcy9NZWRpYXRvciBp cy9UaGUgbWVkaWF0b3IgaXMvDQoNCnMvZmlndXJlIHVwL2RldGVybWluZS9nDQoNCnMvbWVjaGFu aXN1bS9tZWNoYW5pc20vDQoNCnMvZ2VuZXJ0ZWQvZ2VuZXJhdGVkLw0KDQpzL1BsZWFzZSByZWZl ci9QbGVhc2UgcmVmZXIgdG8vZw0KDQpzL29yaWdpbmF0ZWQgZnJvbSBBUyBBIGFuZCBkZXN0aW5h dGVkL29yaWdpbmF0aW5nIGZyb20gQVMgQSBhbmQgZGVzdGluZWQvDQoNCnMvYmVjdXNlIGl0IHdp bGwgY2F1c2UgdGhlIGNvbmdlc3Rpb24vYmVjYXVzZSBpdCB3aWxsIGNhdXNlIGNvbmdlc3Rpb24v DQoNCnMvdG9nZWNoZXIvdG9nZXRoZXIvDQoNCnMvc291cmNlIElQIGFuZCBkZXN0aW5hdGlvbiBJ UC9zb3VyY2UgYW5kIGRlc3RpbmF0aW9uIElQIGFkZHJlc3MvZw0KDQpzL2JvdGggdGhlIHNvdXJj ZSBJUCBhbmQgdGhlIGRlc3RpbmF0aW9uIElQIHJlbGF0ZWQvcmVsYXRpbmcgdG8gYm90aCB0aGUg c291cmNlIGFuZCBkZXN0aW5hdGlvbiBJUCBhZGRyZXNzZXMvDQoNCnMvbGVuZ3RoIG9uZSBJUEZJ WC9sZW5ndGggb2Ygb25lIElQRklYLw0KDQpzL3RvIHRoZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUg bmV0d29ya3MgaW4gdGhlIGZpZWxkL3RvIGluZm9ybWF0aW9uIGFib3V0IG5ldHdvcmtzIGluIHRo ZSBmaWVsZC8NCg0KDQpPTEQ6DQoNCmNvbmZpZ3VyZSBleHBvcnQgcG9saWN5IG9mIEJHUCBjb21t dW5pdGllcyBvbiB0aGUgZXhwb3J0ZXIgdG8gbGltaXQgdGhlIEJHUCBjb21tdW5pdGllcyB0byBi ZSBleHBvcnRlZCwgc28gYXMgdG8gb25seSBleHBvcnQgc29tZSBzcGVjaWZpYyBjb21tdW5pdGll cyxvciBub3QgdG8gZXhwb3J0IHNvbWUgc3BlY2lmaWMgY29tbXVuaXRpZXMuDQoNCk5FVzoNCg0K Y29uZmlndXJlIHRoZSBleHBvcnQgcG9saWN5IG9mIEJHUCBjb21tdW5pdGllcyB0byBsaW1pdCB0 aGUgQkdQIGNvbW11bml0aWVzIGJ5IGluY2x1ZGluZyBvciBleGNsdWRpbmcgc3BlY2lmaWMgY29t bXVuaXRpZXMuDQoNCg0Kcy9UaGUgZGV0YWlsZWQgbWVjaGFuaXNtIGlzIG91dCBvZiB0aGUgc2Nv cGUgb2YgdGhpcyBkb2N1bWVudC4vVGhlIGRldGFpbHMgb2YgaW5jcmVhc2luZyBJUEZJWCBtZXNz YWdlIGxlbmd0aCBpcyBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMgZG9jdW1lbnQuLw0KDQpzL3JlZmVy IEFwcGVuZGl4IEEvcmVmZXIgdG8gQXBwZW5kaXggQS8NCg0Kcy9zb3VyY2Ugb3IgZGVzdGluYXRp b24gSVAvc291cmNlIG9yIGRlc3RpbmF0aW9uIElQIGFkZHJlc3MvDQoNCg0KU2hhd24uDQoNCi0t DQo= --_000_SG2PR06MB217016BC102E505BFA30DC97FC130SG2PR06MB2170apcp_ Content-Type: text/html; charset="utf-8" Content-ID: <018CDB5481B68D4B9C2EECA286A74F8C@apcprd06.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5ib2R5IHsgbGluZS1oZWlnaHQ6IDEu NTsgfWJsb2NrcXVvdGUgeyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFy Z2luLWxlZnQ6IDAuNWVtOyB9ZGl2LkZveERpdjIwMTgwOTIwMTgzMTAzNTIzNDc3IHsgfWJvZHkg eyBmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IOW+rui9r+mbhem7kTsgY29sb3I6IHJn YigwLCAwLCAwKTsgbGluZS1oZWlnaHQ6IDEuNTsgfTwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keT4N CjxkaXY+PHNwYW4+PC9zcGFuPkRlYXIgU2hhd24gTS4gRW1lcnksPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj5UaGFuayB5b3UgZm9yIHlvdXIgcmV2aWV3IGFuZCBuaXRzLiBJIGhhdmUg Y29ycmVjdGVkIGFsbCB0aGUgbml0cyBhbmQgdXBsb2FkZWQgYSBuZXcgdmVyc2lvbiAtMDguIFBs ZWFzZSBjaGVjayBhbmQgdGhhbmtzIGFnYWluLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+WmhlbnFpYW5nIExpPC9kaXY+DQo8aHIgc3R5bGU9IndpZHRoOiAyMTBweDsgaGVp Z2h0OiAxcHg7IiBjb2xvcj0iI2I1YzRkZiIgc2l6ZT0iMSIgYWxpZ249ImxlZnQiPg0KPGRpdj48 c3Bhbj4NCjxkaXYgc3R5bGU9Ik1BUkdJTjogMTBweDsgRk9OVC1GQU1JTFk6IHZlcmRhbmE7IEZP TlQtU0laRTogMTBwdCI+DQo8ZGl2PmxpX3poZW5xaWFuZ0Bob3RtYWlsLmNvbTwvZGl2Pg0KPC9k aXY+DQo8L3NwYW4+PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLVRvcDogMHB4OyBt YXJnaW4tQm90dG9tOiAwcHg7IG1hcmdpbi1MZWZ0OiAwLjVlbSI+DQo8ZGl2PiZuYnNwOzwvZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPGRpdiBzdHlsZT0iUEFERElORy1SSUdIVDog OHB4OyBQQURESU5HLUxFRlQ6IDhweDsgRk9OVC1TSVpFOiAxMnB4O0ZPTlQtRkFNSUxZOnRhaG9t YTtDT0xPUjojMDAwMDAwOyBCQUNLR1JPVU5EOiAjZWZlZmVmOyBQQURESU5HLUJPVFRPTTogOHB4 OyBQQURESU5HLVRPUDogOHB4Ij4NCjxkaXY+PGI+RnJvbTo8L2I+Jm5ic3A7PGEgaHJlZj0ibWFp bHRvOnNoYXduLmVtZXJ5QGdtYWlsLmNvbSI+U2hhd24gRW1lcnk8L2E+PC9kaXY+DQo8ZGl2Pjxi PkRhdGU6PC9iPiZuYnNwOzIwMTgtMDktMTkmbmJzcDsxNTowMzwvZGl2Pg0KPGRpdj48Yj5Ubzo8 L2I+Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOnNlY2RpckBpZXRmLm9yZyI+c2VjZGlyPC9hPjsgPGEg aHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtb3BzYXdnLWlwZml4LWJncC1jb21tdW5pdHkuYWxsQHRv b2xzLmlldGYub3JnIj4NCmRyYWZ0LWlldGYtb3BzYXdnLWlwZml4LWJncC1jb21tdW5pdHkuYWxs PC9hPjwvZGl2Pg0KPGRpdj48Yj5DQzo8L2I+Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOnNoYXduLmVt ZXJ5QGdtYWlsLmNvbSI+U2hhd24gRW1lcnk8L2E+PC9kaXY+DQo8ZGl2PjxiPlN1YmplY3Q6PC9i PiZuYnNwO1JldmlldyBvZiBkcmFmdC1pZXRmLW9wc2F3Zy1pcGZpeC1iZ3AtY29tbXVuaXR5LTA3 PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9IkZveERpdjIwMTgwOTIw MTgzMTAzNTIzNDc3Ij4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGRp cj0ibHRyIj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGRpcj0ibHRy Ij4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGRpcj0ibHRyIj4NCjxk aXYgZGlyPSJsdHIiPg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYgZGly PSJsdHIiPg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYgZGlyPSJsdHIi Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRp diBjbGFzcz0iZ21haWxfcXVvdGUiPjxicj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBzdHlsZT0i Zm9udC1zaXplOjEyLjhweDt0ZXh0LWRlY29yYXRpb24tc3R5bGU6aW5pdGlhbDt0ZXh0LWRlY29y YXRpb24tY29sb3I6aW5pdGlhbCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6cmdiKDM0LDM0LDM0KTtm b250LWZhbWlseTphcmlhbCxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxMi44cHg7Zm9udC1zdHlsZTpu b3JtYWw7Zm9udC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9y bWFsO2ZvbnQtd2VpZ2h0OjQwMDtsZXR0ZXItc3BhY2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFy dDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7 d29yZC1zcGFjaW5nOjBweDtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSk7dGV4dC1k ZWNvcmF0aW9uLXN0eWxlOmluaXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNvbG9yOmluaXRpYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjpyZ2IoMzQsMzQsMzQpO2ZvbnQtZmFtaWx5OmFyaWFsLHNhbnMtc2Vy aWY7Zm9udC1zaXplOjEyLjhweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQtbGlnYXR1 cmVzOm5vcm1hbDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7Zm9udC13ZWlnaHQ6NDAwO2xldHRl ci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50OjBweDt0ZXh0LXRy YW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4O2JhY2tncm91 bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KTt0ZXh0LWRlY29yYXRpb24tc3R5bGU6aW5pdGlhbDt0 ZXh0LWRlY29yYXRpb24tY29sb3I6aW5pdGlhbDtmbG9hdDpub25lO2Rpc3BsYXk6aW5saW5lIj5S ZXZpZXdlcjoNCiBTaGF3biBNLiBFbWVyeTwvc3Bhbj48YnIgc3R5bGU9ImNvbG9yOnJnYigzNCwz NCwzNCk7Zm9udC1mYW1pbHk6YXJpYWwsc2Fucy1zZXJpZjtmb250LXNpemU6MTIuOHB4O2ZvbnQt c3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudC1saWdhdHVyZXM6bm9ybWFsO2ZvbnQtdmFyaWFudC1j YXBzOm5vcm1hbDtmb250LXdlaWdodDo0MDA7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxp Z246c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6 bm9ybWFsO3dvcmQtc3BhY2luZzowcHg7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUp O3RleHQtZGVjb3JhdGlvbi1zdHlsZTppbml0aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xvcjppbml0 aWFsIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpyZ2IoMzQsMzQsMzQpO2ZvbnQtZmFtaWx5OmFyaWFs LHNhbnMtc2VyaWY7Zm9udC1zaXplOjEyLjhweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlh bnQtbGlnYXR1cmVzOm5vcm1hbDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7Zm9udC13ZWlnaHQ6 NDAwO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50OjBw eDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4 O2JhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KTt0ZXh0LWRlY29yYXRpb24tc3R5bGU6 aW5pdGlhbDt0ZXh0LWRlY29yYXRpb24tY29sb3I6aW5pdGlhbDtmbG9hdDpub25lO2Rpc3BsYXk6 aW5saW5lIj5SZXZpZXcNCiByZXN1bHQ6IFJlYWR5IHdpdGggbnVtZXJvdXMgbml0czwvc3Bhbj48 YnI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6MTIuOHB4O3RleHQtZGVj b3JhdGlvbi1zdHlsZTppbml0aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xvcjppbml0aWFsIj4NCjxz cGFuIHN0eWxlPSJjb2xvcjpyZ2IoMzQsMzQsMzQpO2ZvbnQtZmFtaWx5OmFyaWFsLHNhbnMtc2Vy aWY7Zm9udC1zaXplOjEyLjhweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQtbGlnYXR1 cmVzOm5vcm1hbDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7Zm9udC13ZWlnaHQ6NDAwO2xldHRl ci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50OjBweDt0ZXh0LXRy YW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4O2JhY2tncm91 bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KTt0ZXh0LWRlY29yYXRpb24tc3R5bGU6aW5pdGlhbDt0 ZXh0LWRlY29yYXRpb24tY29sb3I6aW5pdGlhbCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJnYigzNCwz NCwzNCk7Zm9udC1mYW1pbHk6YXJpYWwsc2Fucy1zZXJpZjtmb250LXNpemU6MTIuOHB4O2ZvbnQt c3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudC1saWdhdHVyZXM6bm9ybWFsO2ZvbnQtdmFyaWFudC1j YXBzOm5vcm1hbDtmb250LXdlaWdodDo0MDA7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxp Z246c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6 bm9ybWFsO3dvcmQtc3BhY2luZzowcHg7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUp O3RleHQtZGVjb3JhdGlvbi1zdHlsZTppbml0aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xvcjppbml0 aWFsO2Zsb2F0Om5vbmU7ZGlzcGxheTppbmxpbmUiPjxicj4NCjwvc3Bhbj48L3NwYW4+PC9kaXY+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjhweDt0ZXh0LWRlY29yYXRpb24tc3R5bGU6aW5p dGlhbDt0ZXh0LWRlY29yYXRpb24tY29sb3I6aW5pdGlhbCI+SSBoYXZlIHJldmlld2VkIHRoaXMg ZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUnczwvc3Bhbj48YnIg c3R5bGU9ImZvbnQtc2l6ZToxMi44cHg7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOmluaXRpYWw7dGV4 dC1kZWNvcmF0aW9uLWNvbG9yOmluaXRpYWwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi44 cHg7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOmluaXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNvbG9yOmlu aXRpYWwiPm9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwmbmJzcDs8c3BhbiBjbGFzcz0iZ21h aWwtbV8xMTM4OTk2NDU2ODYwNzI5MzEzbV81MDY5MzM1Mzc4MDYyODM3MzMzZ21haWwtbV82NjY3 NDIzODQ0ODgwOTkyMTIwZ21haWwtbV84MzQ2NzUyMzMzMzk2MDgxNzc4bV8zNjY4MDI5Nzg4Njk4 NTQ5ODQwZ21haWwtbV8tNjA3MDU3ODg3NzI5NTE3MzQ1M2dtYWlsLW1fNzczMzk4NTYzODc4NDgx MTM5bV8tNjk1OTQ4MDg1MjI1OTc0NDEwZ21haWwtbV8xNjIzNzQ2NDcyMDg5NjI1MDU3Z21haWwt bV8tODYxODQyODYwMDk1NDA2MTE0NmdtYWlsLW1fNzcwODc0MDA1NzM3NzU4ODIwN21fLTU1NDYy NDI5ODM3NjA5NTQxMzVnbWFpbC1tXzQ0NTcwODYyMzM4MjA0MDkxMDFnbWFpbC1tXzQ3Mjg1Mzc0 NjA1Njk3MTc5NDltXzEzNjczMTUyOTQzOTg0ODEyNDJnbWFpbC1pbCI+SUVURjwvc3Bhbj4mbmJz cDtkb2N1bWVudHMNCiBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuPC9zcGFuPjxiciBzdHls ZT0iZm9udC1zaXplOjEyLjhweDt0ZXh0LWRlY29yYXRpb24tc3R5bGU6aW5pdGlhbDt0ZXh0LWRl Y29yYXRpb24tY29sb3I6aW5pdGlhbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjhweDt0 ZXh0LWRlY29yYXRpb24tc3R5bGU6aW5pdGlhbDt0ZXh0LWRlY29yYXRpb24tY29sb3I6aW5pdGlh bCI+VGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQg b2YgdGhlIHNlY3VyaXR5PC9zcGFuPjxiciBzdHlsZT0iZm9udC1zaXplOjEyLjhweDt0ZXh0LWRl Y29yYXRpb24tc3R5bGU6aW5pdGlhbDt0ZXh0LWRlY29yYXRpb24tY29sb3I6aW5pdGlhbCI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjhweDt0ZXh0LWRlY29yYXRpb24tc3R5bGU6aW5pdGlh bDt0ZXh0LWRlY29yYXRpb24tY29sb3I6aW5pdGlhbCI+YXJlYSBkaXJlY3RvcnMuIERvY3VtZW50 IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2U8L3NwYW4+PGJyIHN0eWxl PSJmb250LXNpemU6MTIuOHB4O3RleHQtZGVjb3JhdGlvbi1zdHlsZTppbml0aWFsO3RleHQtZGVj b3JhdGlvbi1jb2xvcjppbml0aWFsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuOHB4O3Rl eHQtZGVjb3JhdGlvbi1zdHlsZTppbml0aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xvcjppbml0aWFs Ij5jb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy48L3NwYW4+ PGJyIHN0eWxlPSJmb250LXNpemU6MTIuOHB4O3RleHQtZGVjb3JhdGlvbi1zdHlsZTppbml0aWFs O3RleHQtZGVjb3JhdGlvbi1jb2xvcjppbml0aWFsIj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTox Mi44cHg7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOmluaXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNvbG9y OmluaXRpYWwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi44cHgiPjxicj4NCjwvc3Bhbj48 L2Rpdj4NCjxkaXYgc3R5bGU9InRleHQtZGVjb3JhdGlvbi1zdHlsZTppbml0aWFsO3RleHQtZGVj b3JhdGlvbi1jb2xvcjppbml0aWFsIj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZToxMi44cHg7Y29s b3I6cmdiKDM0LDM0LDM0KSI+VGhpcyBkcmFmdCBzcGVjaWZpZXMgbmV3IEluZm9ybWF0aW9uIEVs ZW1lbnRzIChJRXMpIGluIG9yZGVyIHRvIHN1cHBvcnQgQkdQIGNvbW11bml0eTwvZGl2Pg0KPGRp diBzdHlsZT0iZm9udC1zaXplOjEyLjhweDtjb2xvcjpyZ2IoMzQsMzQsMzQpIj5pbmZvcm1hdGlv biBmb3IgdGhlIElQIEZsb3cgSW5mb3JtYXRpb24gZVhwb3J0IChJUEZJWCkgcHJvdG9jb2wuPC9k aXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6MTIuOHB4O2NvbG9yOnJnYigzNCwzNCwzNCkiPjxi cj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOjEyLjhweDtjb2xvcjpyZ2IoMzQsMzQs MzQpIj5UaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBkb2VzIGV4aXN0IGFuZCBz dGF0ZXMgdGhhdCB0aGUgZHJhZnQganVzdCBkZWZpbmVzPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250 LXNpemU6MTIuOHB4O2NvbG9yOnJnYigzNCwzNCwzNCkiPm5ldyBJRXMgYW5kIGRvZXMgbm90IGlu dHJvZHVjZSBhbnkgbmV3IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLiZuYnNwOyBUaGUgc2VjdGlv biB0aGVuPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6MTIuOHB4O2NvbG9yOnJnYigzNCwz NCwzNCkiPmdvZXMgb24gdG8gc3RhdGUgdGhhdCB0aGUgc2FtZSBzZWN1cml0eSBpc3N1ZXMgdGhh dCBhcHBseSB0byB0aGUgSVBGSVggcHJvdG9jb2wgYW5kPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250 LXNpemU6MTIuOHB4O2NvbG9yOnJnYigzNCwzNCwzNCkiPnRoZSBjb3JyZXNwb25kaW5nIEluZm9y bWF0aW9uIE1vZGVsIGFwcGxpZXMmbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjhweCI+ dG8gdGhpcyBzcGVjaWZpY2F0aW9uLiZuYnNwOyBJIGFncmVlIHdpdGggdGhlc2U8L3NwYW4+PC9k aXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6MTIuOHB4O2NvbG9yOnJnYigzNCwzNCwzNCkiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuOHB4Ij5hc3NlcnRpb25zLjwvc3Bhbj48L2Rpdj4NCjxk aXYgc3R5bGU9ImZvbnQtc2l6ZToxMi44cHg7Y29sb3I6cmdiKDM0LDM0LDM0KSI+PGJyPg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6MTIuOHB4O2NvbG9yOnJnYigzNCwzNCwzNCkiPkdl bmVyYWwgY29tbWVudHM6PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6MTIuOHB4O2NvbG9y OnJnYigzNCwzNCwzNCkiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOjEyLjhw eDtjb2xvcjpyZ2IoMzQsMzQsMzQpIj5Ob25lLjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXpl OjEyLjhweDtjb2xvcjpyZ2IoMzQsMzQsMzQpIj48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZv bnQtc2l6ZToxMi44cHg7Y29sb3I6cmdiKDM0LDM0LDM0KSI+RWRpdG9yaWFsIGNvbW1lbnRzOjwv ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOjEyLjhweDtjb2xvcjpyZ2IoMzQsMzQsMzQpIj48 YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZToxMi44cHg7Y29sb3I6cmdiKDM0LDM0 LDM0KSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi44cHgiPnMvPC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpyZ2IoMCwwLDApO2ZvbnQtc2l6ZToxMy4zMzMzcHgiPmRpZmZlcm50L2RpZmZlcmVu dC9nPC9zcGFuPjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgY2xhc3M9ImdtYWlsLW1fMTEzODk5 NjQ1Njg2MDcyOTMxM2dtYWlsLW5ld3BhZ2UiIHN0eWxlPSJjb2xvcjpyZ2IoMCwwLDApO2ZvbnQt c2l6ZToxMy4zMzMzcHg7bWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHg7YnJlYWstYmVm b3JlOnBhZ2U7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOmluaXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNv bG9yOmluaXRpYWwiPjxmb250IGZhY2U9ImFyaWFsLCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPnMv TmV0d29rL05ldHdvcmsvPC9mb250PjwvcHJlPg0KPHByZSBjbGFzcz0iZ21haWwtbV8xMTM4OTk2 NDU2ODYwNzI5MzEzZ21haWwtbmV3cGFnZSIgc3R5bGU9ImNvbG9yOnJnYigwLDAsMCk7Zm9udC1z aXplOjEzLjMzMzNweDttYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweDticmVhay1iZWZv cmU6cGFnZTt0ZXh0LWRlY29yYXRpb24tc3R5bGU6aW5pdGlhbDt0ZXh0LWRlY29yYXRpb24tY29s b3I6aW5pdGlhbCI+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZiI+cy9z dGF0aXN0aWMvc3RhdGlzdGljcy88L2ZvbnQ+PC9wcmU+DQo8cHJlIGNsYXNzPSJnbWFpbC1tXzEx Mzg5OTY0NTY4NjA3MjkzMTNnbWFpbC1uZXdwYWdlIiBzdHlsZT0iY29sb3I6cmdiKDAsMCwwKTtm b250LXNpemU6MTMuMzMzM3B4O21hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4O2JyZWFr LWJlZm9yZTpwYWdlO3RleHQtZGVjb3JhdGlvbi1zdHlsZTppbml0aWFsO3RleHQtZGVjb3JhdGlv bi1jb2xvcjppbml0aWFsIj48Zm9udCBmYWNlPSJhcmlhbCwgaGVsdmV0aWNhLCBzYW5zLXNlcmlm Ij5zL21lZGlhdG9yIG5lZWRzL3RoZSBtZWRpYXRvciBuZWVkcy88L2ZvbnQ+PC9wcmU+DQo8cHJl IGNsYXNzPSJnbWFpbC1tXzExMzg5OTY0NTY4NjA3MjkzMTNnbWFpbC1uZXdwYWdlIiBzdHlsZT0i Y29sb3I6cmdiKDAsMCwwKTtmb250LXNpemU6MTMuMzMzM3B4O21hcmdpbi10b3A6MHB4O21hcmdp bi1ib3R0b206MHB4O2JyZWFrLWJlZm9yZTpwYWdlO3RleHQtZGVjb3JhdGlvbi1zdHlsZTppbml0 aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xvcjppbml0aWFsIj48Zm9udCBmYWNlPSJhcmlhbCwgaGVs dmV0aWNhLCBzYW5zLXNlcmlmIj5zL01lZGlhdG9yIGlzL1RoZSBtZWRpYXRvciBpcy88L2ZvbnQ+ PC9wcmU+DQo8cHJlIGNsYXNzPSJnbWFpbC1tXzExMzg5OTY0NTY4NjA3MjkzMTNnbWFpbC1uZXdw YWdlIiBzdHlsZT0ibWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHg7YnJlYWstYmVmb3Jl OnBhZ2U7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOmluaXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNvbG9y OmluaXRpYWwiPjxmb250IGNvbG9yPSIjMDAwMDAwIiBmYWNlPSJhcmlhbCwgaGVsdmV0aWNhLCBz YW5zLXNlcmlmIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjMzMzNweCI+cy9maWd1cmUgdXAv ZGV0ZXJtaW5lL2c8L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZSBjbGFzcz0iZ21haWwtbV8xMTM4 OTk2NDU2ODYwNzI5MzEzZ21haWwtbmV3cGFnZSIgc3R5bGU9Im1hcmdpbi10b3A6MHB4O21hcmdp bi1ib3R0b206MHB4O2JyZWFrLWJlZm9yZTpwYWdlO3RleHQtZGVjb3JhdGlvbi1zdHlsZTppbml0 aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xvcjppbml0aWFsIj48Zm9udCBjb2xvcj0iIzAwMDAwMCIg ZmFjZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMy4zMzMzcHgiPnMvbWVjaGFuaXN1bS9tZWNoYW5pc20vPC9zcGFuPjwvZm9udD48L3ByZT4N CjxwcmUgY2xhc3M9ImdtYWlsLW1fMTEzODk5NjQ1Njg2MDcyOTMxM2dtYWlsLW5ld3BhZ2UiIHN0 eWxlPSJtYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweDticmVhay1iZWZvcmU6cGFnZTt0 ZXh0LWRlY29yYXRpb24tc3R5bGU6aW5pdGlhbDt0ZXh0LWRlY29yYXRpb24tY29sb3I6aW5pdGlh bCI+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZiI+cy9nZW5lcnRlZC9n ZW5lcmF0ZWQvPC9mb250PjwvcHJlPg0KPHByZSBjbGFzcz0iZ21haWwtbV8xMTM4OTk2NDU2ODYw NzI5MzEzZ21haWwtbmV3cGFnZSIgc3R5bGU9Im1hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206 MHB4O2JyZWFrLWJlZm9yZTpwYWdlO3RleHQtZGVjb3JhdGlvbi1zdHlsZTppbml0aWFsO3RleHQt ZGVjb3JhdGlvbi1jb2xvcjppbml0aWFsIj48Zm9udCBmYWNlPSJhcmlhbCwgaGVsdmV0aWNhLCBz YW5zLXNlcmlmIj5zL1BsZWFzZSByZWZlci9QbGVhc2UgcmVmZXIgdG8vZzwvZm9udD48L3ByZT4N CjxwcmUgY2xhc3M9ImdtYWlsLW1fMTEzODk5NjQ1Njg2MDcyOTMxM2dtYWlsLW5ld3BhZ2UiIHN0 eWxlPSJtYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweDticmVhay1iZWZvcmU6cGFnZTt0 ZXh0LWRlY29yYXRpb24tc3R5bGU6aW5pdGlhbDt0ZXh0LWRlY29yYXRpb24tY29sb3I6aW5pdGlh bCI+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZiI+cy9vcmlnaW5hdGVk IGZyb20gQVMgQSBhbmQgZGVzdGluYXRlZC9vcmlnaW5hdGluZyBmcm9tIEFTIEEgYW5kIGRlc3Rp bmVkLzwvZm9udD48L3ByZT4NCjxwcmUgY2xhc3M9ImdtYWlsLW1fMTEzODk5NjQ1Njg2MDcyOTMx M2dtYWlsLW5ld3BhZ2UiIHN0eWxlPSJtYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweDti cmVhay1iZWZvcmU6cGFnZTt0ZXh0LWRlY29yYXRpb24tc3R5bGU6aW5pdGlhbDt0ZXh0LWRlY29y YXRpb24tY29sb3I6aW5pdGlhbCI+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1z ZXJpZiI+cy9iZWN1c2UgaXQgd2lsbCBjYXVzZSB0aGUgY29uZ2VzdGlvbi9iZWNhdXNlIGl0IHdp bGwgY2F1c2UgY29uZ2VzdGlvbi88YnI+PC9mb250PjwvcHJlPg0KPHByZSBjbGFzcz0iZ21haWwt bV8xMTM4OTk2NDU2ODYwNzI5MzEzZ21haWwtbmV3cGFnZSIgc3R5bGU9Im1hcmdpbi10b3A6MHB4 O21hcmdpbi1ib3R0b206MHB4O2JyZWFrLWJlZm9yZTpwYWdlO3RleHQtZGVjb3JhdGlvbi1zdHls ZTppbml0aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xvcjppbml0aWFsIj48Zm9udCBmYWNlPSJhcmlh bCwgaGVsdmV0aWNhLCBzYW5zLXNlcmlmIj5zL3RvZ2VjaGVyL3RvZ2V0aGVyLzwvZm9udD48L3By ZT4NCjxwcmUgY2xhc3M9ImdtYWlsLW1fMTEzODk5NjQ1Njg2MDcyOTMxM2dtYWlsLW5ld3BhZ2Ui IHN0eWxlPSJtYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweDticmVhay1iZWZvcmU6cGFn ZTt0ZXh0LWRlY29yYXRpb24tc3R5bGU6aW5pdGlhbDt0ZXh0LWRlY29yYXRpb24tY29sb3I6aW5p dGlhbCI+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZiI+cy9zb3VyY2Ug SVAgYW5kIGRlc3RpbmF0aW9uIElQL3NvdXJjZSBhbmQgZGVzdGluYXRpb24gSVAgYWRkcmVzcy9n PC9mb250PjwvcHJlPg0KPHByZSBjbGFzcz0iZ21haWwtbV8xMTM4OTk2NDU2ODYwNzI5MzEzZ21h aWwtbmV3cGFnZSIgc3R5bGU9Im1hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4O2JyZWFr LWJlZm9yZTpwYWdlO3RleHQtZGVjb3JhdGlvbi1zdHlsZTppbml0aWFsO3RleHQtZGVjb3JhdGlv bi1jb2xvcjppbml0aWFsIj48Zm9udCBmYWNlPSJhcmlhbCwgaGVsdmV0aWNhLCBzYW5zLXNlcmlm Ij5zL2JvdGggdGhlIHNvdXJjZSBJUCBhbmQgdGhlIGRlc3RpbmF0aW9uIElQIHJlbGF0ZWQvcmVs YXRpbmcgdG8gYm90aCB0aGUgc291cmNlIGFuZCBkZXN0aW5hdGlvbiBJUCBhZGRyZXNzZXMvPC9m b250Pjxicj48L3ByZT4NCjxwcmUgY2xhc3M9ImdtYWlsLW1fMTEzODk5NjQ1Njg2MDcyOTMxM2dt YWlsLW5ld3BhZ2UiIHN0eWxlPSJtYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweDticmVh ay1iZWZvcmU6cGFnZTt0ZXh0LWRlY29yYXRpb24tc3R5bGU6aW5pdGlhbDt0ZXh0LWRlY29yYXRp b24tY29sb3I6aW5pdGlhbCI+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJp ZiI+cy9sZW5ndGggb25lIElQRklYL2xlbmd0aCBvZiBvbmUgSVBGSVgvPC9mb250PjwvcHJlPg0K PHByZSBjbGFzcz0iZ21haWwtbV8xMTM4OTk2NDU2ODYwNzI5MzEzZ21haWwtbmV3cGFnZSIgc3R5 bGU9Im1hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4O2JyZWFrLWJlZm9yZTpwYWdlO3Rl eHQtZGVjb3JhdGlvbi1zdHlsZTppbml0aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xvcjppbml0aWFs Ij48Zm9udCBmYWNlPSJhcmlhbCwgaGVsdmV0aWNhLCBzYW5zLXNlcmlmIj5zL3RvIHRoZSBpbmZv cm1hdGlvbiBhYm91dCB0aGUgbmV0d29ya3MgaW4gdGhlIGZpZWxkL3RvIGluZm9ybWF0aW9uIGFi b3V0IG5ldHdvcmtzIGluIHRoZSBmaWVsZC88L2ZvbnQ+PC9wcmU+DQo8cHJlIGNsYXNzPSJnbWFp bC1tXzExMzg5OTY0NTY4NjA3MjkzMTNnbWFpbC1uZXdwYWdlIiBzdHlsZT0ibWFyZ2luLXRvcDow cHg7bWFyZ2luLWJvdHRvbTowcHg7YnJlYWstYmVmb3JlOnBhZ2U7dGV4dC1kZWNvcmF0aW9uLXN0 eWxlOmluaXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNvbG9yOmluaXRpYWwiPjxmb250IGZhY2U9ImFy aWFsLCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPjxicj48L2ZvbnQ+PC9wcmU+DQo8cHJlIGNsYXNz PSJnbWFpbC1tXzExMzg5OTY0NTY4NjA3MjkzMTNnbWFpbC1uZXdwYWdlIiBzdHlsZT0ibWFyZ2lu LXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHg7YnJlYWstYmVmb3JlOnBhZ2U7dGV4dC1kZWNvcmF0 aW9uLXN0eWxlOmluaXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNvbG9yOmluaXRpYWwiPjxmb250IGZh Y2U9ImFyaWFsLCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPk9MRDo8L2ZvbnQ+PC9wcmU+DQo8cHJl IGNsYXNzPSJnbWFpbC1tXzExMzg5OTY0NTY4NjA3MjkzMTNnbWFpbC1uZXdwYWdlIiBzdHlsZT0i bWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHg7YnJlYWstYmVmb3JlOnBhZ2U7dGV4dC1k ZWNvcmF0aW9uLXN0eWxlOmluaXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNvbG9yOmluaXRpYWwiPjxm b250IGZhY2U9ImFyaWFsLCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPmNvbmZpZ3VyZSBleHBvcnQg cG9saWN5IG9mIEJHUCBjb21tdW5pdGllcyBvbiB0aGUgZXhwb3J0ZXIgdG8gbGltaXQgdGhlIEJH UCBjb21tdW5pdGllcyB0byBiZSBleHBvcnRlZCwgc28gYXMgdG8gb25seSBleHBvcnQgc29tZSBz cGVjaWZpYyBjb21tdW5pdGllcyxvciBub3QgdG8gZXhwb3J0IHNvbWUgc3BlY2lmaWMgY29tbXVu aXRpZXMuPC9mb250PjwvcHJlPg0KPHByZSBjbGFzcz0iZ21haWwtbV8xMTM4OTk2NDU2ODYwNzI5 MzEzZ21haWwtbmV3cGFnZSIgc3R5bGU9Im1hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4 O2JyZWFrLWJlZm9yZTpwYWdlO3RleHQtZGVjb3JhdGlvbi1zdHlsZTppbml0aWFsO3RleHQtZGVj b3JhdGlvbi1jb2xvcjppbml0aWFsIj48Zm9udCBmYWNlPSJhcmlhbCwgaGVsdmV0aWNhLCBzYW5z LXNlcmlmIj5ORVc6PC9mb250PjwvcHJlPg0KPHByZSBjbGFzcz0iZ21haWwtbV8xMTM4OTk2NDU2 ODYwNzI5MzEzZ21haWwtbmV3cGFnZSIgc3R5bGU9Im1hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0 b206MHB4O2JyZWFrLWJlZm9yZTpwYWdlO3RleHQtZGVjb3JhdGlvbi1zdHlsZTppbml0aWFsO3Rl eHQtZGVjb3JhdGlvbi1jb2xvcjppbml0aWFsIj48Zm9udCBmYWNlPSJhcmlhbCwgaGVsdmV0aWNh LCBzYW5zLXNlcmlmIj5jb25maWd1cmUgdGhlIGV4cG9ydCBwb2xpY3kgb2YgQkdQIGNvbW11bml0 aWVzIHRvIGxpbWl0IHRoZSBCR1AgY29tbXVuaXRpZXMgYnkgaW5jbHVkaW5nIG9yIGV4Y2x1ZGlu ZyBzcGVjaWZpYyBjb21tdW5pdGllcy48L2ZvbnQ+PC9wcmU+DQo8cHJlIGNsYXNzPSJnbWFpbC1t XzExMzg5OTY0NTY4NjA3MjkzMTNnbWFpbC1uZXdwYWdlIiBzdHlsZT0ibWFyZ2luLXRvcDowcHg7 bWFyZ2luLWJvdHRvbTowcHg7YnJlYWstYmVmb3JlOnBhZ2U7dGV4dC1kZWNvcmF0aW9uLXN0eWxl OmluaXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNvbG9yOmluaXRpYWwiPjxmb250IGZhY2U9ImFyaWFs LCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPjxicj48L2ZvbnQ+PC9wcmU+DQo8cHJlIGNsYXNzPSJn bWFpbC1tXzExMzg5OTY0NTY4NjA3MjkzMTNnbWFpbC1uZXdwYWdlIiBzdHlsZT0ibWFyZ2luLXRv cDowcHg7bWFyZ2luLWJvdHRvbTowcHg7YnJlYWstYmVmb3JlOnBhZ2U7dGV4dC1kZWNvcmF0aW9u LXN0eWxlOmluaXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNvbG9yOmluaXRpYWwiPjxmb250IGZhY2U9 ImFyaWFsLCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPnMvVGhlIGRldGFpbGVkIG1lY2hhbmlzbSBp cyBvdXQgb2YgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuL1RoZSBkZXRhaWxzIG9mIGluY3Jl YXNpbmcgSVBGSVggbWVzc2FnZSBsZW5ndGggaXMgb3V0IG9mIHNjb3BlIGZvciB0aGlzIGRvY3Vt ZW50Li88L2ZvbnQ+PC9wcmU+DQo8ZGl2Pjxmb250IGZhY2U9ImFyaWFsLCBoZWx2ZXRpY2EsIHNh bnMtc2VyaWYiPnMvcmVmZXIgQXBwZW5kaXggQS9yZWZlciB0byBBcHBlbmRpeCBBLzwvZm9udD48 L2Rpdj4NCjxwcmUgY2xhc3M9ImdtYWlsLW1fMTEzODk5NjQ1Njg2MDcyOTMxM2dtYWlsLW5ld3Bh Z2UiIHN0eWxlPSJtYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweDticmVhay1iZWZvcmU6 cGFnZTt0ZXh0LWRlY29yYXRpb24tc3R5bGU6aW5pdGlhbDt0ZXh0LWRlY29yYXRpb24tY29sb3I6 aW5pdGlhbCI+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZiI+cy9zb3Vy Y2Ugb3IgZGVzdGluYXRpb24gSVAvc291cmNlIG9yIGRlc3RpbmF0aW9uIElQIGFkZHJlc3MvPC9m b250PjwvcHJlPg0KPHByZSBjbGFzcz0iZ21haWwtbV8xMTM4OTk2NDU2ODYwNzI5MzEzZ21haWwt bmV3cGFnZSIgc3R5bGU9Im1hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4O2JyZWFrLWJl Zm9yZTpwYWdlO3RleHQtZGVjb3JhdGlvbi1zdHlsZTppbml0aWFsO3RleHQtZGVjb3JhdGlvbi1j b2xvcjppbml0aWFsIj48Zm9udCBmYWNlPSJhcmlhbCwgaGVsdmV0aWNhLCBzYW5zLXNlcmlmIj48 YnI+PC9mb250PjwvcHJlPg0KPHByZSBjbGFzcz0iZ21haWwtbV8xMTM4OTk2NDU2ODYwNzI5MzEz Z21haWwtbmV3cGFnZSIgc3R5bGU9Im1hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4O2Jy ZWFrLWJlZm9yZTpwYWdlO3RleHQtZGVjb3JhdGlvbi1zdHlsZTppbml0aWFsO3RleHQtZGVjb3Jh dGlvbi1jb2xvcjppbml0aWFsIj48Zm9udCBmYWNlPSJhcmlhbCwgaGVsdmV0aWNhLCBzYW5zLXNl cmlmIj5TaGF3bi48L2ZvbnQ+PC9wcmU+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTox Mi44cHgiPjxmb250IGNvbG9yPSIjMDAwMDAwIiBmYWNlPSJhcmlhbCwgaGVsdmV0aWNhLCBzYW5z LXNlcmlmIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjMzMzNweCI+LS08L3NwYW4+PC9mb250 PjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_SG2PR06MB217016BC102E505BFA30DC97FC130SG2PR06MB2170apcp_-- From nobody Thu Sep 20 11:24:06 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F2F130E67; Thu, 20 Sep 2018 11:23:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kyle Rose To: Cc: draft-ietf-lisp-rfc6830bis.all@ietf.org, ietf@ietf.org, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153746783815.5331.10419091174803926555@ietfa.amsl.com> Date: Thu, 20 Sep 2018 11:23:58 -0700 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-lisp-rfc6830bis-18 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2018 18:23:58 -0000 Reviewer: Kyle Rose Review result: Has Issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I have reviewed the -15/-18 diff and found no changes relevant to the points I raised in the first review and its subsequent discussion. I maintain that some reorganization is warranted to clarify the intended security properties of the system, especially given the complexity of the overall LISP ecosystem and the choice to move documents separately, complicating the realistic need to review them as a block. Otherwise, I have nothing further to add. From nobody Thu Sep 20 22:49:05 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0EC1292F1; Thu, 20 Sep 2018 22:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yS4TP_XJ9o41; Thu, 20 Sep 2018 22:49:00 -0700 (PDT) Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [IPv6:2a00:1450:4864:20::143]) (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 30B32128CF2; Thu, 20 Sep 2018 22:49:00 -0700 (PDT) Received: by mail-lf1-x143.google.com with SMTP id t22-v6so667015lfb.7; Thu, 20 Sep 2018 22:49:00 -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=CLgdnYYHIvD/jK+cu6WdcNn7dd4RVPc3yq1SGmUuPMY=; b=N1T+nM7l/t0mYkKR+142Mep9zlb035qHmjpWIxDlic4OvwGGqESAh1Kx4fEk1ry6CH fey2dXZXFPuCgBV79oQeNrCs8qGcKcmHjB347BicYBOkWhpaDrWfIyw/AtAgI+uEx8+s +B+M51UhQFPfPHnylWw1uM63uBCroCT9+W7uJVSkPPsNE1cvevahWgP8EOOQkkaLeyjf 3L+Yh8TgtjSzZ+dv+ooKAYIyND6JTAcsUBPgUk4zdpCo1fx2Y8hfA6DKC3wJD+B5Tgan 2lqkOryE0fT2pXROlo9qw+l3IDjNYYcmMKTar7EWVvPbr/TUeGyTr4BuiOipyYgMdEGt Uk/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=CLgdnYYHIvD/jK+cu6WdcNn7dd4RVPc3yq1SGmUuPMY=; b=eZeWQsJrKmhGld0CMl5OrEbRqJv6cOQgWlmkHd/FPqcSvXF1FF3V8q0HgmtSu8fIz5 umRzgpMBF8HKBpe3bsIwc/wJQh5cdyGFxN5y4ODWDpxo+k6nMEeYEjOr5PW9cOxQTuwA XhYcz1kkMxkvZg2GaoihBnOGZQ0BTy1WPAUL+6LRIxV9n0RfZhc4C1DCqm5JL90vHQgN DDJEP5M6lgNxyM2exe1g9Q+JWBQvjehvCuezEDYCA/k64X9weda3TeHq9VePDH70pYUc Z247WxOYZFhmSylaeeTEmwGRdAOfwhgBaZObiCv3Z6JmJjTyiTxRy4GLg1ker+GPe89u G3Gw== X-Gm-Message-State: APzg51BlcS60TD4imBi48KXgup1O20djTsGjb5Iqv1QXMbmFzKk8uoy7 AkokFKqbD/KEZT3uOOOgGhyFMiIXsx3Q6IxxmKQ= X-Google-Smtp-Source: ANB0VdZz7snXJSdFnCJdEbzrxOzRxFQ5hyyhzyFisazZv0xcGuVFpmSi/jW5CjsJADOeT08vP9aOwrVKyOY+iNFquFw= X-Received: by 2002:a19:7112:: with SMTP id m18-v6mr19132186lfc.64.1537508938058; Thu, 20 Sep 2018 22:48:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Shawn Emery Date: Thu, 20 Sep 2018 23:48:47 -0600 Message-ID: To: li_zhenqiang@hotmail.com Cc: secdir@ietf.org, draft-ietf-opsawg-ipfix-bgp-community.all@tools.ietf.org, opsawg@ietf.org Content-Type: multipart/alternative; boundary="00000000000017992a05765b32a5" Archived-At: Subject: Re: [secdir] Review of draft-ietf-opsawg-ipfix-bgp-community-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2018 05:49:03 -0000 --00000000000017992a05765b32a5 Content-Type: text/plain; charset="UTF-8" On Thu, Sep 20, 2018 at 4:31 AM li zhenqiang wrote: > Dear Shawn M. Emery, > > Thank you for your review and nits. I have corrected all the nits and > uploaded a new version -08. Please check and thanks again. > The updates look fine to me. Thanks for your quick response. Shawn. -- > ------------------------------ > li_zhenqiang@hotmail.com > > > *From:* Shawn Emery > *Date:* 2018-09-19 15:03 > *To:* secdir ; draft-ietf-opsawg-ipfix-bgp-community.all > > *CC:* Shawn Emery > *Subject:* Review of draft-ietf-opsawg-ipfix-bgp-community-07 > > Reviewer: Shawn M. Emery > Review result: Ready with numerous nits > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. > > This draft specifies new Information Elements (IEs) in order to support > BGP community > information for the IP Flow Information eXport (IPFIX) protocol. > > The security considerations section does exist and states that the draft > just defines > new IEs and does not introduce any new security considerations. The > section then > goes on to state that the same security issues that apply to the IPFIX > protocol and > the corresponding Information Model applies to this specification. I > agree with these > assertions. > > General comments: > > None. > > Editorial comments: > > s/differnt/different/g > > s/Netwok/Network/ > > s/statistic/statistics/ > > s/mediator needs/the mediator needs/ > > s/Mediator is/The mediator is/ > > s/figure up/determine/g > > s/mechanisum/mechanism/ > > s/generted/generated/ > > s/Please refer/Please refer to/g > > s/originated from AS A and destinated/originating from AS A and destined/ > > s/becuse it will cause the congestion/because it will cause congestion/ > > s/togecher/together/ > > s/source IP and destination IP/source and destination IP address/g > > s/both the source IP and the destination IP related/relating to both the source and destination IP addresses/ > > s/length one IPFIX/length of one IPFIX/ > > s/to the information about the networks in the field/to information about networks in the field/ > > > OLD: > > configure export policy of BGP communities on the exporter to limit the BGP communities to be exported, so as to only export some specific communities,or not to export some specific communities. > > NEW: > > configure the export policy of BGP communities to limit the BGP communities by including or excluding specific communities. > > > s/The detailed mechanism is out of the scope of this document./The details of increasing IPFIX message length is out of scope for this document./ > > s/refer Appendix A/refer to Appendix A/ > > s/source or destination IP/source or destination IP address/ > > > Shawn. > > -- > > --00000000000017992a05765b32a5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Sep 20, 2018 at 4:31 AM li zhenqiang <li_zhenqiang@hotmail.com> wr= ote:
Dear Shawn M. Emery,

Thank you for your review and nits. I have corrected all the nits and = uploaded a new version -08. Please check and thanks again.=C2=A0

The updates look fine to me.=C2=A0 Thanks for = your quick response.

=
Shawn.
--=C2=A0
=C2=A0
Shawn Emery
Date:=C2=A02018-09-19=C2=A015:03
CC:=C2=A0Shawn Emery
Subject:=C2=A0Review of draft-ietf-opsawg-ipfix-bgp-community-0= 7

Reviewer: Shawn M. Emery
Review result: Ready with numerous nits

I have reviewed this document as part of the security dir= ectorate's
ongoing effort to review all=C2=A0IETF=C2=A0documents being processed by the IESG.
These comments were written primarily for the benefit of = the security
area directors. Document editors and WG chairs should tre= at these
comments just like any other last call comments.

This draft specifies ne= w Information Elements (IEs) in order to support BGP community
information for the IP = Flow Information eXport (IPFIX) protocol.

The security considerat= ions section does exist and states that the draft just defines
new IEs and does not in= troduce any new security considerations.=C2=A0 The section then
goes on to state that t= he same security issues that apply to the IPFIX protocol and
the corresponding Infor= mation Model applies=C2=A0to this specific= ation.=C2=A0 I agree with these
assertions.

General comments:

None.

Editorial comments:

s/dif= fernt/different/g
s/Netwok/Network/
s/statistic/statisti=
cs/
s/mediator needs/the=
 mediator needs/
s/Mediator is/The me=
diator is/
s/f=
igure up/determine/g
s/m=
echanisum/mechanism/
s/generted/generated/
s/Please refer/Please refer to/g
s/originated from AS A and destinated/originating from AS=
 A and destined/
s/becuse it will cause the congestion/because it will cau=
se congestion/
s/togecher/together/
s/source IP and destination IP/source and destination IP =
address/g
s/both the source IP and the destination IP related/relat=
ing to both the source and destination IP addresses/
s/length one IPFIX/length of one IPFIX/
s/to the information about the networks in the field/to i=
nformation about networks in the field/

OLD:
configure export policy of BGP communities on the exporte=
r to limit the BGP communities to be exported, so as to only export some sp=
ecific communities,or not to export some specific communities.
NEW:
configure the export policy of BGP communities to limit t=
he BGP communities by including or excluding specific communities.




s/The detailed mechanism is out of the scope of this docu=
ment./The details of increasing IPFIX message length is out of scope for th=
is document./


s/refer Appendix A/refer t=
o Appendix A/


s/source or destination IP/source or destination IP addre=
ss/





Shawn.
--
--00000000000017992a05765b32a5-- From nobody Fri Sep 21 12:13:12 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D83130E4C; Fri, 21 Sep 2018 12:12:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Russ Housley To: Cc: ccamp@ietf.org, draft-ietf-ccamp-mw-yang.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153755717789.7274.18097070925148175847@ietfa.amsl.com> Date: Fri, 21 Sep 2018 12:12:57 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-ccamp-mw-yang-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2018 19:12:58 -0000 Reviewer: Russ Housley Review result: Ready I reviewed this document as part of the Security Directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Security Area Directors. Document authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments. Document: review-draft-mwdt-ccamp-mw-yang-09 Reviewer: Russ Housley Review Date: 2018-09-21 IETF LC End Date: 2018-10-02 IESG Telechat date: unknown Summary: Ready Major Concerns: None Minor Concerns: None From nobody Sun Sep 23 23:50:14 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61BB3130E51; Sun, 23 Sep 2018 23:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5C9BXfmct9sj; Sun, 23 Sep 2018 23:50:05 -0700 (PDT) Received: from mail-it1-x129.google.com (mail-it1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 1F632130DE7; Sun, 23 Sep 2018 23:50:05 -0700 (PDT) Received: by mail-it1-x129.google.com with SMTP id j81-v6so9120555ite.0; Sun, 23 Sep 2018 23:50:04 -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:cc; bh=4JbWCuVYtwRkJ87aSL138mMyNakB0Cjgv/Db0nx0AwU=; b=lU42Dmd4Ree+DmTHyPxEHYGVvyzj029sDvlWAJnD5JW7hjNDopx5+Crm1KZSe5WM+z 6WHuXbYvEZ37I99Iz6mIT99bglz4/ow/VKjdAfhzDsi7vFjNb1HsPNfCIQJSA1qAq7lP s1biNOe2RN4aB94ZQolCT+7J+kL91CAfv8FzkJFxftmxBLotvV/DIrfDOjekrQvTTUwx Di/bwRAT03hUPnW2xJHrrtJ5h5J06BCSwL3X7CRL3ENdeRXlYTHJmh8qUwHujZIEAtkA x7NZhDFGkaqx9at0SPeCluxJbgodJMY5tyzHkCutH2mLuda77pu3ungHUjHvDBGowdel rBXw== 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:cc; bh=4JbWCuVYtwRkJ87aSL138mMyNakB0Cjgv/Db0nx0AwU=; b=swy15dWxl55EFXxT9V9EpWNE0oxGimju+1OKHCerM22OkdEe5zc0lO47BvhlrfL9JH gXp/HxftpF/1ZNsO3+okdaqbdzOk/aNrEW2u2HKiMlctGZvE9A9dxtxaid+QyUXMyhxx Nax6tN5By/c8d+e0WnDJzukZE6kuqYuIPstKdIAQIndmVIWXqruMvIEBPvI705VAMtwn dTkAolP9HdWS0SoWfR+XcQmIYXIazaQ4cy0vO7EnSc5riyy4Z9t7MpiL76ntOrFLROyV eIvFH4kpLSAjr+g6Wne3216DVJW37rfOLr6TAwoArTzmpOE793+MaS8TAfkjMst2djZF Q0rQ== X-Gm-Message-State: APzg51B7Qj3HsuYsNkOpxhaOBWNdq0hCxiM+YZyWSkCYIQAaP1WP4kan tJYH7S4xLrpIrm4bdZc+YjMNNb+/zGqZyWu4GtQiDQLw58w= X-Google-Smtp-Source: ANB0VdYefEL2Tl/TjiGk3mNe96qN+WPa92lsfg4o39AshtnZcfnJ2W11JQs43uEY8Csza1J6NKUMJ5vSRGNB+2FVMJA= X-Received: by 2002:a02:4502:: with SMTP id y2-v6mr8423587jaa.11.1537771803862; Sun, 23 Sep 2018 23:50:03 -0700 (PDT) MIME-Version: 1.0 From: Donald Eastlake Date: Mon, 24 Sep 2018 02:49:51 -0400 Message-ID: To: "iesg@ietf.org" , draft-ietf-tsvwg-fecframe-ext.all@ietf.org Cc: secdir@ietf.org, tsvwg@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [secdir] SECDIR review of draft-ietf-tsvwg-fecframe-ext-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2018 06:50:07 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready. This draft extends FEC as per RFC 6363 to cover sliding encoding window based schemes as well as the original block based schemes. The reasonably thorough Security Considerations of RFC 6363, which are referenced, seem adequate. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com From nobody Mon Sep 24 14:18:52 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0303D1310F6; Mon, 24 Sep 2018 14:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.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 2oZBqjy9Hibf; Mon, 24 Sep 2018 14:18:42 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42329130F33; Mon, 24 Sep 2018 14:18:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 18DD7E2048; Mon, 24 Sep 2018 17:18:39 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 21998-10; Mon, 24 Sep 2018 17:18:37 -0400 (EDT) Received: from securerf.ihtfp.org (IHTFP-DHCP-158.IHTFP.ORG [192.168.248.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id AD721E2047; Mon, 24 Sep 2018 17:18:37 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1537823917; bh=/i0W4HcBWFbG2G0LIkxxg3Pxmc/VttvjefRU4OOoYHA=; h=From:To:Cc:Subject:Date; b=RwJSr91MoHCNqAvw9rml8NUNRCABfbL8zMHW19Hy160UjmPCcXGQ7pT79jloghioE a+Xt8/iU9OFnNp+yarW5t6RUo6xn0SfBcUM0DnD8Oe2kMnPi1EqYhmZSNmQHPL98Kh qj23DWy2Zu/JaD4jgDCY8Q4sbeaCh5BzArZKFTCE= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.15.2/Submit) id w8OLIPnr007014; Mon, 24 Sep 2018 17:18:25 -0400 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org Cc: dnsop-chairs@ietf.org, lee.howard@retevia.net Date: Mon, 24 Sep 2018 17:18:25 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: [secdir] sec-dir review of draft-ietf-dnsop-isp-ip6rdns-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2018 21:18:44 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: * Ready to Publish Details: * There is an extra (spurious) reference to RFC1912 at the end of section 1.2, where it says: [RFC1912] This document considers. I suspect this extra reference should be removed. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon Sep 24 17:58:14 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A41EA13115B; Mon, 24 Sep 2018 17:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rm1cxrOILv1Z; Mon, 24 Sep 2018 17:58:09 -0700 (PDT) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (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 6579D1311C8; Mon, 24 Sep 2018 17:58:09 -0700 (PDT) Received: from trixy.bergandi.net ([76.93.146.89]) by wwwlocal.goatley.com (PMDF V6.7-x02 #1001) with ESMTP id <0PFL00NBA6OWQ0@wwwlocal.goatley.com>; Mon, 24 Sep 2018 19:58:08 -0500 (CDT) Received: from thinny.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #1001) with ESMTPSA id <0PFL00D6P6M100@trixy.bergandi.net>; Mon, 24 Sep 2018 17:56:26 -0700 (PDT) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO thinny.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Mon, 24 Sep 2018 17:56:26 -0700 Date: Mon, 24 Sep 2018 17:58:06 -0700 From: Daniel Harkins To: "iesg@ietf.org" , "secdir@ietf.org" Cc: draft-ietf-detnet-architecture.all@ietf.org Message-id: <72b6e1cf-3a41-7845-863e-7958a09d36fc@lounge.org> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_lwuImKJGlKANg5eaSkuukg)" Content-language: en-US User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO thinny.local) X-PMAS-Software: PreciseMail V3.3 [180924a] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: [secdir] secdir review of draft-ietf-detnet-architecture-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2018 00:58:12 -0000 This is a multi-part message in MIME format. --Boundary_(ID_lwuImKJGlKANg5eaSkuukg) Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 8BIT   Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is ready with issues. This draft describes an architecture for deterministic networking that provides for delivery of packet flows with low packet loss and with a maximum amount of latency. A nit first. The terminology seems a bit overblown. We have DetNet Intermediate nodes that could be relay nodes or transit nodes; and a DetNet system that is a DetNet aware system or transit node or relay node; and DetNet edge nodes that are relay nodes; and DetNet relay nodes that can be bridges, firewalls, or anything else that participates in DetNet. Finally, to translate between 802.1 TSN and DetNet we have a "relay system" that is an 802.1 term for a DetNet intermediate node which, as we have seen, is a DetNet relay node. This can be simplified considerably. The Security Considerations is thin, especially for an architecture draft that is going to be referred to by subsequent drafts which will just say something along the lines of, "as an instance of the DetNet FooBar, these Security Considerations are those from [ARCH]", where ARCH is the RFC that comes out of this I-D. I think there needs to be a description of the various points in the architecture that an attacker could exploit, and if a point is not exploitable it should say so. For instance: - is it possible for an attacker to launch a DoS attack by manipulating member flows of a DetNet flow in order to force DetNet nodes to consume buffers they allocated to deal with the DetNet flow? - If an end system is not DetNet aware there needs to be a DetNet edge node to handle the encaps of the flow into the DetNet system. Can an attacker in that case introduce packets that shouldn't be part of the DetNet flow into the flow by getting the edge node to encaps them as such? If there are any assumptions being made-- e.g. "insider attacks are not being considered"-- they should be mentioned. regards, Dan. --Boundary_(ID_lwuImKJGlKANg5eaSkuukg) Content-type: text/html; charset=utf-8 Content-transfer-encoding: 8BIT  
  Hello,
  I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

  The summary of the review is ready with issues.

  This draft describes an architecture for deterministic networking
that provides for delivery of packet flows with low packet loss and
with a maximum amount of latency. 

  A nit first. The terminology seems a bit overblown. We have DetNet
Intermediate nodes that could be relay nodes or transit nodes; and a
DetNet system that is a DetNet aware system or transit node or
relay node; and DetNet edge nodes that are relay nodes; and DetNet
relay nodes that can be bridges, firewalls, or anything else that
participates in DetNet. Finally, to translate between 802.1 TSN and
DetNet we have a "relay system" that is an 802.1 term for a DetNet
intermediate node which, as we have seen, is a DetNet relay node. This
can be simplified considerably.

  The Security Considerations is thin, especially for an architecture
draft that is going to be referred to by subsequent drafts which will
just say something along the lines of, "as an instance of the DetNet
FooBar, these Security Considerations are those from [ARCH]", where
ARCH is the RFC that comes out of this I-D. I think there needs to be
a description of the various points in the architecture that an attacker
could exploit, and if a point is not exploitable it should say so. For
instance:

  - is it possible for an attacker to launch a DoS attack by manipulating
    member flows of a DetNet flow in order to force DetNet nodes to
    consume buffers they allocated to deal with the DetNet flow?

  - If an end system is not DetNet aware there needs to be a DetNet edge
    node to handle the encaps of the flow into the DetNet system. Can an
    attacker in that case introduce packets that shouldn't be part of the
    DetNet flow into the flow by getting the edge node to encaps them as
    such?

If there are any assumptions being made-- e.g. "insider attacks are not
being considered"-- they should be mentioned. 

  regards,

  Dan.

--Boundary_(ID_lwuImKJGlKANg5eaSkuukg)-- From nobody Tue Sep 25 12:14:14 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8140E128CF3; Tue, 25 Sep 2018 12:13:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: David Waltermire To: Cc: lsr@ietf.org, ietf@ietf.org, draft-ietf-isis-segment-routing-msd.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153790283647.5258.15634056350853857580@ietfa.amsl.com> Date: Tue, 25 Sep 2018 12:13:56 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-isis-segment-routing-msd-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2018 19:13:57 -0000 Reviewer: David Waltermire Review result: Has Issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready with (minor) issues My apologies for the late review on this draft. Overall I found this document to be well-written, and concise. General Comments: This document uses a mix of case around RFC2119 language (e.g., MAY may). You should use text from RFC8174 to indicate that lowercase versions of the keywords are not normative, or adjust the case of the lowercase words to ensure there is no confusion. Minor nit: There is some inconsistency in the use of "MSD-Type" (the value) and "MSD type" (the concept). Suggest cleaning this up. Specific comments: Section 1: Para 1: s/to insure/to ensure/ Section 4: The last paragraph establishes a requirement on the registration of an MSD Type to define what the absence of a given MSD Type means. This is an important requirement that must be addressed during registration of new MSD Types. IMHO, this requirement should be echoed in the registration information in section 6 to make sure it is not overlooked. Section 6: The "Base MPLS Imposition MSD" should reference section 5 of this document. The registration for "Experimental" should be marked as "Reserved for Experimental Use" or just "Experimental Use" to align with RFC8126. RFC8126 states that "it is not appropriate for documents to select explicit values from registries or ranges with this policy". It might be good to add a note alongside the one on "Designated Experts" indicating that values from this range are not assignable. The "Interior Gateway Protocol (IGP) Parameters" registry has the "Standards Action" policy assigned. The new "IGP MSD Types" sub-registry does not have the "Standards Action" policy. Was this intentional? If so, this should be explained. This is also confusing since the guidance for expert reviewers in RFC7370 implies that registrations are based on the "RFC Required" or "Standards Action" policies. Section 7: The security considerations in RFC7981 ask that security considerations around the disclosure and modification of this type of information is described in extensions. This has been done, but RFC7981 also asks that an integrity mechanism be provided if there is a high risk resulting from modification of capability information. There is no discussion in the document's security consideration about the nature of risk in this case and why an integrity mechanism is not needed. It seems like false information can be used to cause a denial of service regarding computed paths. This sounds like having this happen could be bad. I am not an expert on routing protocols, so I am not sure if this is an issue. How bad and likely is such a risk? From nobody Wed Sep 26 12:39:36 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 643F8126CC7; Wed, 26 Sep 2018 12:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dolby.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 RrYrtH_gwavY; Wed, 26 Sep 2018 12:39:23 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0129.outbound.protection.outlook.com [104.47.33.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4A81128CB7; Wed, 26 Sep 2018 12:39:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dolby.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vlUe4rqPWgh6M/7gCuNdveLKNqNvsBXm1a4DWhVW6j4=; b=l+WILUWSyOyQx3oQ3SVP4X57Y6qMnw3JVnX/cIlX4/0pW59M5F9JjZ5R1enOmek+ao77zKQz6HefWYTKbBxMM7x9jW9nYolcsG9Gb/Joc+4dhkhC3S5afbcko1JmCL5yCujoqtGnamJ9Hxjr9fQ3zEQ75hep3hgXoMoLOU3Eyt8= Received: from BL0PR06MB4548.namprd06.prod.outlook.com (20.177.145.145) by BL0PR06MB4274.namprd06.prod.outlook.com (10.167.179.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1143.18; Wed, 26 Sep 2018 19:39:20 +0000 Received: from BL0PR06MB4548.namprd06.prod.outlook.com ([fe80::2821:1ebf:40eb:7174]) by BL0PR06MB4548.namprd06.prod.outlook.com ([fe80::2821:1ebf:40eb:7174%2]) with mapi id 15.20.1143.022; Wed, 26 Sep 2018 19:39:20 +0000 From: "Grossman, Ethan A." To: Daniel Harkins , "iesg@ietf.org" , "secdir@ietf.org" CC: "draft-ietf-detnet-architecture.all@ietf.org" Thread-Topic: secdir review of draft-ietf-detnet-architecture-08 Thread-Index: AQHUVGrXrs+5hv7zUEm0nOgDPUhzg6UC96dA Date: Wed, 26 Sep 2018 19:39:19 +0000 Message-ID: References: <72b6e1cf-3a41-7845-863e-7958a09d36fc@lounge.org> In-Reply-To: <72b6e1cf-3a41-7845-863e-7958a09d36fc@lounge.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=eagros@dolby.com; x-originating-ip: [8.39.141.5] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR06MB4274; 6:vQHN8pYtje8mGC3akKxiRonFGpT3rxDazMxVKItYZ6vU/teVAgJwUbH0DYJ5ayQuAoPMVTGqYaMOjKhpoRvgi5Rk3RfvYmIiUxGFGIp0Ta0YRzVJcxXM6JyyI70AwM0QhIVoWcqWrWse++8wk0KC1p8JJPETaDDerXpWlPLMhKxbylKLto3999pMHieTkfuyIokORqTrA3neZRGHB5yhPXdnME8lf4o/IeJQLHeb4Z7M0baylaaWxLYjc8d4TlNnlzHJk/pM/AtUAvEorV3wD7/uMPdqJZ3mqA33K80XF6WQzXqrh6BBToISoaFSfdzmRfiO7l1MoMDMuXBCWGrf2HJVvtLAvEwcDnRVAjI9banJqOjsP1ryY4IHeU1Y1ovHMWcb/Mp00lNowJzDEEhMtVQ2+7Hwl1315fUfhqNdukTDsTIhs8/ykyt+5tY2HXLig1e21JoKrcZBvmzuszdSSQ==; 5:EoWOjSz1fyJ918CGucifcmFODcHLssvqFrzY9Kss+jwqXUNN2N75ZCYEIfsMffNYIXg+MqvSmh3OEcZcuU/Ppd6bGmGnl6DADmU9gAZv+eUlsCC27CgkKRdQttfEv4zzFc1iU1tEPzvbwBeeoLGiC4YTkn49JG1nkQs41YSFWtM=; 7:loTFWjbIFgyPWNRu7cRYzjhjJQuooKzok2y1kAfNn0BNo8W5O7OIN9+MTXMO89nX9bKzSQe/f8u8yep6Gtgd/dWcpB4W00mxY7dHBV2G/f2gMlD+ro+/OMs3TwE/H9W7CjQeGuE209ajPb2ozM4uE9G55Md3QMVU9eB99/AFsxQFyTy2hK5BJxqQSFtbjV/0NffE6+xByiiA2lDmYa2RuiU28wHuUiXTKMN6kvF9apNnRfR9b5GQwYhyDrxXPftX x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: ab5516db-e948-4598-595c-08d623e7c0f3 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534165)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:BL0PR06MB4274; x-ms-traffictypediagnostic: BL0PR06MB4274: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705)(21748063052155)(28532068793085)(190501279198761)(227612066756510); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(3231355)(944501410)(52105095)(10201501046)(149066)(150057)(6041310)(20161123562045)(20161123564045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051); SRVR:BL0PR06MB4274; BCL:0; PCL:0; RULEID:; SRVR:BL0PR06MB4274; x-forefront-prvs: 08076ABC99 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(396003)(346002)(136003)(39860400002)(189003)(199004)(81166006)(81156014)(6116002)(9686003)(3846002)(74316002)(7736002)(2906002)(790700001)(110136005)(33656002)(106356001)(316002)(236005)(55016002)(54896002)(53546011)(4326008)(2900100001)(105586002)(5660300001)(229853002)(102836004)(66066001)(53936002)(6436002)(6306002)(6506007)(99286004)(6246003)(26005)(476003)(486006)(186003)(446003)(76176011)(11346002)(7696005)(9326002)(606006)(25786009)(14444005)(256004)(68736007)(8676002)(966005)(5250100002)(2501003)(8936002)(478600001)(2201001)(86362001)(14454004)(97736004)(71190400001)(71200400001)(34290500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR06MB4274; H:BL0PR06MB4548.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: dolby.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: RoW5wL+nDj6sH/qCrmV4nPca50jwlIa/sthTqzaSRAxjNSKdBC2GJNZw62Ma5vSpTkGYOTQq4bCMrlB8kqxpca+kbfiTXPE6ICiagAMr33Exad/priVMhoxeEcaowR7eYuyWRMIlJI/5ysqc+lj7hpEBxnIQASu58q/vnUrFKHQO5gHjp8yA3FnyShYWZJFxx8T2yah51djuR5tTOf48O1UhDyEawD5aPScD0WffgoHcB0quz7Y/U8P54rP+To2gGpbiFvH8xuwKgd9YKyYZn3O49unDM+TSSrKiyjLD0lzOrLqn+qaPRMYykP610FgTU5VWz1Eui4LP1yjgcA4lHfd7rjRg/r7DstSn6lHyGQE= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BL0PR06MB45480C63A3C83CFAC7C5B686C4150BL0PR06MB4548namp_" MIME-Version: 1.0 X-OriginatorOrg: dolby.com X-MS-Exchange-CrossTenant-Network-Message-Id: ab5516db-e948-4598-595c-08d623e7c0f3 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2018 19:39:19.9219 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 05408d25-cd0d-40c8-8962-5462de64a318 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4274 Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-detnet-architecture-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2018 19:39:28 -0000 --_000_BL0PR06MB45480C63A3C83CFAC7C5B686C4150BL0PR06MB4548namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGFuaWVsLA0KSSBqdXN0IHdhbnQgdG8gbWFrZSBzdXJlIHlvdSBhcmUgYXdhcmUgb2YNCmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZGV0bmV0LXNlY3VyaXR5 Lw0KDQpCZXN0LA0KRXRoYW4gKGFzIEVkaXRvciBvZiB0aGUgRGV0TmV0IFNlY3VyaXR5IENvbnNp ZGVyYXRpb25zIGRyYWZ0KQ0KDQpGcm9tOiBEYW5pZWwgSGFya2lucyA8ZGhhcmtpbnNAbG91bmdl Lm9yZz4NClNlbnQ6IE1vbmRheSwgU2VwdGVtYmVyIDI0LCAyMDE4IDU6NTggUE0NClRvOiBpZXNn QGlldGYub3JnOyBzZWNkaXJAaWV0Zi5vcmcNCkNjOiBkcmFmdC1pZXRmLWRldG5ldC1hcmNoaXRl Y3R1cmUuYWxsQGlldGYub3JnDQpTdWJqZWN0OiBzZWNkaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYt ZGV0bmV0LWFyY2hpdGVjdHVyZS0wOA0KDQoNCiAgSGVsbG8sDQoNCiAgSSBoYXZlIHJldmlld2Vk IHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncw0KDQpv bmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3Nl ZCBieSB0aGUNCg0KSUVTRy4gIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkg Zm9yIHRoZSBiZW5lZml0IG9mIHRoZQ0KDQpzZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4gIERvY3Vt ZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQNCg0KdGhlc2UgY29tbWVudHMg anVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQoNCg0KDQogIFRoZSBzdW1t YXJ5IG9mIHRoZSByZXZpZXcgaXMgcmVhZHkgd2l0aCBpc3N1ZXMuDQoNCg0KDQogIFRoaXMgZHJh ZnQgZGVzY3JpYmVzIGFuIGFyY2hpdGVjdHVyZSBmb3IgZGV0ZXJtaW5pc3RpYyBuZXR3b3JraW5n DQoNCnRoYXQgcHJvdmlkZXMgZm9yIGRlbGl2ZXJ5IG9mIHBhY2tldCBmbG93cyB3aXRoIGxvdyBw YWNrZXQgbG9zcyBhbmQNCg0Kd2l0aCBhIG1heGltdW0gYW1vdW50IG9mIGxhdGVuY3kuDQoNCg0K DQogIEEgbml0IGZpcnN0LiBUaGUgdGVybWlub2xvZ3kgc2VlbXMgYSBiaXQgb3ZlcmJsb3duLiBX ZSBoYXZlIERldE5ldA0KDQpJbnRlcm1lZGlhdGUgbm9kZXMgdGhhdCBjb3VsZCBiZSByZWxheSBu b2RlcyBvciB0cmFuc2l0IG5vZGVzOyBhbmQgYQ0KDQpEZXROZXQgc3lzdGVtIHRoYXQgaXMgYSBE ZXROZXQgYXdhcmUgc3lzdGVtIG9yIHRyYW5zaXQgbm9kZSBvcg0KDQpyZWxheSBub2RlOyBhbmQg RGV0TmV0IGVkZ2Ugbm9kZXMgdGhhdCBhcmUgcmVsYXkgbm9kZXM7IGFuZCBEZXROZXQNCg0KcmVs YXkgbm9kZXMgdGhhdCBjYW4gYmUgYnJpZGdlcywgZmlyZXdhbGxzLCBvciBhbnl0aGluZyBlbHNl IHRoYXQNCg0KcGFydGljaXBhdGVzIGluIERldE5ldC4gRmluYWxseSwgdG8gdHJhbnNsYXRlIGJl dHdlZW4gODAyLjEgVFNOIGFuZA0KDQpEZXROZXQgd2UgaGF2ZSBhICJyZWxheSBzeXN0ZW0iIHRo YXQgaXMgYW4gODAyLjEgdGVybSBmb3IgYSBEZXROZXQNCg0KaW50ZXJtZWRpYXRlIG5vZGUgd2hp Y2gsIGFzIHdlIGhhdmUgc2VlbiwgaXMgYSBEZXROZXQgcmVsYXkgbm9kZS4gVGhpcw0KDQpjYW4g YmUgc2ltcGxpZmllZCBjb25zaWRlcmFibHkuDQoNCg0KDQogIFRoZSBTZWN1cml0eSBDb25zaWRl cmF0aW9ucyBpcyB0aGluLCBlc3BlY2lhbGx5IGZvciBhbiBhcmNoaXRlY3R1cmUNCg0KZHJhZnQg dGhhdCBpcyBnb2luZyB0byBiZSByZWZlcnJlZCB0byBieSBzdWJzZXF1ZW50IGRyYWZ0cyB3aGlj aCB3aWxsDQoNCmp1c3Qgc2F5IHNvbWV0aGluZyBhbG9uZyB0aGUgbGluZXMgb2YsICJhcyBhbiBp bnN0YW5jZSBvZiB0aGUgRGV0TmV0DQoNCkZvb0JhciwgdGhlc2UgU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnMgYXJlIHRob3NlIGZyb20gW0FSQ0hdIiwgd2hlcmUNCg0KQVJDSCBpcyB0aGUgUkZDIHRo YXQgY29tZXMgb3V0IG9mIHRoaXMgSS1ELiBJIHRoaW5rIHRoZXJlIG5lZWRzIHRvIGJlDQoNCmEg ZGVzY3JpcHRpb24gb2YgdGhlIHZhcmlvdXMgcG9pbnRzIGluIHRoZSBhcmNoaXRlY3R1cmUgdGhh dCBhbiBhdHRhY2tlcg0KDQpjb3VsZCBleHBsb2l0LCBhbmQgaWYgYSBwb2ludCBpcyBub3QgZXhw bG9pdGFibGUgaXQgc2hvdWxkIHNheSBzby4gRm9yDQoNCmluc3RhbmNlOg0KDQoNCg0KICAtIGlz IGl0IHBvc3NpYmxlIGZvciBhbiBhdHRhY2tlciB0byBsYXVuY2ggYSBEb1MgYXR0YWNrIGJ5IG1h bmlwdWxhdGluZw0KDQogICAgbWVtYmVyIGZsb3dzIG9mIGEgRGV0TmV0IGZsb3cgaW4gb3JkZXIg dG8gZm9yY2UgRGV0TmV0IG5vZGVzIHRvDQoNCiAgICBjb25zdW1lIGJ1ZmZlcnMgdGhleSBhbGxv Y2F0ZWQgdG8gZGVhbCB3aXRoIHRoZSBEZXROZXQgZmxvdz8NCg0KDQoNCiAgLSBJZiBhbiBlbmQg c3lzdGVtIGlzIG5vdCBEZXROZXQgYXdhcmUgdGhlcmUgbmVlZHMgdG8gYmUgYSBEZXROZXQgZWRn ZQ0KDQogICAgbm9kZSB0byBoYW5kbGUgdGhlIGVuY2FwcyBvZiB0aGUgZmxvdyBpbnRvIHRoZSBE ZXROZXQgc3lzdGVtLiBDYW4gYW4NCg0KICAgIGF0dGFja2VyIGluIHRoYXQgY2FzZSBpbnRyb2R1 Y2UgcGFja2V0cyB0aGF0IHNob3VsZG4ndCBiZSBwYXJ0IG9mIHRoZQ0KDQogICAgRGV0TmV0IGZs b3cgaW50byB0aGUgZmxvdyBieSBnZXR0aW5nIHRoZSBlZGdlIG5vZGUgdG8gZW5jYXBzIHRoZW0g YXMNCg0KICAgIHN1Y2g/DQoNCg0KDQpJZiB0aGVyZSBhcmUgYW55IGFzc3VtcHRpb25zIGJlaW5n IG1hZGUtLSBlLmcuICJpbnNpZGVyIGF0dGFja3MgYXJlIG5vdA0KDQpiZWluZyBjb25zaWRlcmVk Ii0tIHRoZXkgc2hvdWxkIGJlIG1lbnRpb25lZC4NCg0KDQoNCiAgcmVnYXJkcywNCg0KDQoNCiAg RGFuLg0KDQoNCg0K --_000_BL0PR06MB45480C63A3C83CFAC7C5B686C4150BL0PR06MB4548namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglj b2xvcjpibGFjazt9DQp0dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3Jt YWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXIN Cgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQt ZmFtaWx5OiJDb25zb2xhcyIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5IaSBEYW5pZWwsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndp bmRvd3RleHQiPkkganVzdCB3YW50IHRvIG1ha2Ugc3VyZSB5b3UgYXJlIGF3YXJlIG9mDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6d2luZG93dGV4dCI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi1kZXRuZXQtc2VjdXJpdHkvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLWRldG5ldC1zZWN1cml0eS88L2E+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5CZXN0LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5FdGhhbiAoYXMg RWRpdG9yIG9mIHRoZSBEZXROZXQgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgZHJhZnQpPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5k b3d0ZXh0Ij4gRGFuaWVsIEhhcmtpbnMgJmx0O2RoYXJraW5zQGxvdW5nZS5vcmcmZ3Q7DQo8YnI+ DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBTZXB0ZW1iZXIgMjQsIDIwMTggNTo1OCBQTTxicj4NCjxi PlRvOjwvYj4gaWVzZ0BpZXRmLm9yZzsgc2VjZGlyQGlldGYub3JnPGJyPg0KPGI+Q2M6PC9iPiBk cmFmdC1pZXRmLWRldG5ldC1hcmNoaXRlY3R1cmUuYWxsQGlldGYub3JnPGJyPg0KPGI+U3ViamVj dDo8L2I+IHNlY2RpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1kZXRuZXQtYXJjaGl0ZWN0dXJlLTA4 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHR0PjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDs8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJy Pg0KPHR0PiZuYnNwOyBIZWxsbyw8L3R0Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwcmU+Jm5i c3A7IEkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5 IGRpcmVjdG9yYXRlJ3MgPG86cD48L286cD48L3ByZT4NCjxwcmU+b25nb2luZyBlZmZvcnQgdG8g cmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPklFU0cuJm5ic3A7IFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBw cmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5z ZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4mbmJzcDsgRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hh aXJzIHNob3VsZCB0cmVhdCA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGVzZSBjb21tZW50cyBq dXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy48bzpwPjwvbzpwPjwvcHJlPg0K PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsgVGhlIHN1bW1hcnkgb2Yg dGhlIHJldmlldyBpcyByZWFkeSB3aXRoIGlzc3Vlcy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsgVGhpcyBkcmFmdCBkZXNjcmliZXMg YW4gYXJjaGl0ZWN0dXJlIGZvciBkZXRlcm1pbmlzdGljIG5ldHdvcmtpbmc8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT50aGF0IHByb3ZpZGVzIGZvciBkZWxpdmVyeSBvZiBwYWNrZXQgZmxvd3Mgd2l0 aCBsb3cgcGFja2V0IGxvc3MgYW5kPG86cD48L286cD48L3ByZT4NCjxwcmU+d2l0aCBhIG1heGlt dW0gYW1vdW50IG9mIGxhdGVuY3kuIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyBBIG5pdCBmaXJzdC4gVGhlIHRlcm1pbm9sb2d5IHNl ZW1zIGEgYml0IG92ZXJibG93bi4gV2UgaGF2ZSBEZXROZXQ8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT5JbnRlcm1lZGlhdGUgbm9kZXMgdGhhdCBjb3VsZCBiZSByZWxheSBub2RlcyBvciB0cmFuc2l0 IG5vZGVzOyBhbmQgYTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkRldE5ldCBzeXN0ZW0gdGhhdCBp cyBhIERldE5ldCBhd2FyZSBzeXN0ZW0gb3IgdHJhbnNpdCBub2RlIG9yPG86cD48L286cD48L3By ZT4NCjxwcmU+cmVsYXkgbm9kZTsgYW5kIERldE5ldCBlZGdlIG5vZGVzIHRoYXQgYXJlIHJlbGF5 IG5vZGVzOyBhbmQgRGV0TmV0PG86cD48L286cD48L3ByZT4NCjxwcmU+cmVsYXkgbm9kZXMgdGhh dCBjYW4gYmUgYnJpZGdlcywgZmlyZXdhbGxzLCBvciBhbnl0aGluZyBlbHNlIHRoYXQ8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT5wYXJ0aWNpcGF0ZXMgaW4gRGV0TmV0LiBGaW5hbGx5LCB0byB0cmFu c2xhdGUgYmV0d2VlbiA4MDIuMSBUU04gYW5kPG86cD48L286cD48L3ByZT4NCjxwcmU+RGV0TmV0 IHdlIGhhdmUgYSAmcXVvdDtyZWxheSBzeXN0ZW0mcXVvdDsgdGhhdCBpcyBhbiA4MDIuMSB0ZXJt IGZvciBhIERldE5ldDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmludGVybWVkaWF0ZSBub2RlIHdo aWNoLCBhcyB3ZSBoYXZlIHNlZW4sIGlzIGEgRGV0TmV0IHJlbGF5IG5vZGUuIFRoaXM8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT5jYW4gYmUgc2ltcGxpZmllZCBjb25zaWRlcmFibHkuPG86cD48L286 cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7IFRoZSBT ZWN1cml0eSBDb25zaWRlcmF0aW9ucyBpcyB0aGluLCBlc3BlY2lhbGx5IGZvciBhbiBhcmNoaXRl Y3R1cmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5kcmFmdCB0aGF0IGlzIGdvaW5nIHRvIGJlIHJl ZmVycmVkIHRvIGJ5IHN1YnNlcXVlbnQgZHJhZnRzIHdoaWNoIHdpbGw8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT5qdXN0IHNheSBzb21ldGhpbmcgYWxvbmcgdGhlIGxpbmVzIG9mLCAmcXVvdDthcyBh biBpbnN0YW5jZSBvZiB0aGUgRGV0TmV0PG86cD48L286cD48L3ByZT4NCjxwcmU+Rm9vQmFyLCB0 aGVzZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBhcmUgdGhvc2UgZnJvbSBbQVJDSF0mcXVvdDss IHdoZXJlPG86cD48L286cD48L3ByZT4NCjxwcmU+QVJDSCBpcyB0aGUgUkZDIHRoYXQgY29tZXMg b3V0IG9mIHRoaXMgSS1ELiBJIHRoaW5rIHRoZXJlIG5lZWRzIHRvIGJlPG86cD48L286cD48L3By ZT4NCjxwcmU+YSBkZXNjcmlwdGlvbiBvZiB0aGUgdmFyaW91cyBwb2ludHMgaW4gdGhlIGFyY2hp dGVjdHVyZSB0aGF0IGFuIGF0dGFja2VyPG86cD48L286cD48L3ByZT4NCjxwcmU+Y291bGQgZXhw bG9pdCwgYW5kIGlmIGEgcG9pbnQgaXMgbm90IGV4cGxvaXRhYmxlIGl0IHNob3VsZCBzYXkgc28u IEZvcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmluc3RhbmNlOjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyAtIGlzIGl0IHBvc3NpYmxl IGZvciBhbiBhdHRhY2tlciB0byBsYXVuY2ggYSBEb1MgYXR0YWNrIGJ5IG1hbmlwdWxhdGluZzxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyBtZW1iZXIgZmxvd3Mgb2Yg YSBEZXROZXQgZmxvdyBpbiBvcmRlciB0byBmb3JjZSBEZXROZXQgbm9kZXMgdG88bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsgY29uc3VtZSBidWZmZXJzIHRoZXkgYWxs b2NhdGVkIHRvIGRlYWwgd2l0aCB0aGUgRGV0TmV0IGZsb3c/PG86cD48L286cD48L3ByZT4NCjxw cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7IC0gSWYgYW4gZW5kIHN5c3Rl bSBpcyBub3QgRGV0TmV0IGF3YXJlIHRoZXJlIG5lZWRzIHRvIGJlIGEgRGV0TmV0IGVkZ2U8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsgbm9kZSB0byBoYW5kbGUgdGhl IGVuY2FwcyBvZiB0aGUgZmxvdyBpbnRvIHRoZSBEZXROZXQgc3lzdGVtLiBDYW4gYW48bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsgYXR0YWNrZXIgaW4gdGhhdCBjYXNl IGludHJvZHVjZSBwYWNrZXRzIHRoYXQgc2hvdWxkbid0IGJlIHBhcnQgb2YgdGhlPG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7IERldE5ldCBmbG93IGludG8gdGhlIGZs b3cgYnkgZ2V0dGluZyB0aGUgZWRnZSBub2RlIHRvIGVuY2FwcyB0aGVtIGFzPG86cD48L286cD48 L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN1Y2g/PG86cD48L286cD48L3ByZT4NCjxw cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+SWYgdGhlcmUgYXJlIGFueSBhc3N1bXB0 aW9ucyBiZWluZyBtYWRlLS0gZS5nLiAmcXVvdDtpbnNpZGVyIGF0dGFja3MgYXJlIG5vdDxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPmJlaW5nIGNvbnNpZGVyZWQmcXVvdDstLSB0aGV5IHNob3VsZCBi ZSBtZW50aW9uZWQuIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyByZWdhcmRzLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyBEYW4uPG86cD48L286cD48L3ByZT4NCjxwcmU+ PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BL0PR06MB45480C63A3C83CFAC7C5B686C4150BL0PR06MB4548namp_-- From nobody Wed Sep 26 13:45:31 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4161292F1; Wed, 26 Sep 2018 13:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.957 X-Spam-Level: X-Spam-Status: No, score=-14.957 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKYiFdDvcNEv; Wed, 26 Sep 2018 13:45:09 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53A8B128C65; Wed, 26 Sep 2018 13:45:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7214; q=dns/txt; s=iport; t=1537994709; x=1539204309; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=pZ2DltMmkJONo6yWjkGh/5gcLpBbYcnd7/tKYStkPLE=; b=OzEIsVwy2CTizniIPG2QC8qi/+EEZHEz0Hl+dBw8XqyFHk7W2LFQX43r 9FrvJddwwwXK9r/7YrbieC5AWztNL9bpR1evN5XzOxk1mZuLw7pBS9pEF WQ7RgBM0OF24PI56taLe0BgZ35Np4Dlg/7ZcaVQreFMdk6K+q+wk1hoaK E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AMAADh7qtb/4cNJK1aGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUYFkKoFkKAqDaogVjj6DPZMSgXoLhGwCF4NmITQYAQM?= =?us-ascii?q?BAQIBAQJtKIU4AQEBAQIBIxE3DgUHBAIBCBEEAQEDAiYCAgIwFQgIAgQBDQU?= =?us-ascii?q?Ig0IBgVAIpCSBLooYgQuJcBeBQT+BEQGDEoUVD4JbglcCnQcJApAjH4FGhFK?= =?us-ascii?q?JHJRqAhEUgSUdOIFVcBWDJ5BUb4wpgR4BAQ?= X-IronPort-AV: E=Sophos;i="5.54,307,1534809600"; d="scan'208";a="457766425" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Sep 2018 20:45:07 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id w8QKj485020455 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Sep 2018 20:45:08 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 26 Sep 2018 15:45:04 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1395.000; Wed, 26 Sep 2018 15:45:04 -0500 From: "Les Ginsberg (ginsberg)" To: David Waltermire , "secdir@ietf.org" CC: "lsr@ietf.org" , "ietf@ietf.org" , "draft-ietf-isis-segment-routing-msd.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-isis-segment-routing-msd-16 Thread-Index: AQHUVQPqnQ0QGOOP8EOqsf/gazaoC6UC9FjA Date: Wed, 26 Sep 2018 20:45:03 +0000 Message-ID: References: <153790283647.5258.15634056350853857580@ietfa.amsl.com> In-Reply-To: <153790283647.5258.15634056350853857580@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.8.175] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-isis-segment-routing-msd-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2018 20:45:13 -0000 RGF2aWQgLQ0KDQpUaGFueCBmb3IgdGhlIHJldmlldy4NCkEgbmV3IHZlcnNpb24gb2YgdGhlIGRy YWZ0ICgxNykgaGFzIGJlZW4gcHVibGlzaGVkIHRvIGFkZHJlc3MgeW91ciBjb21tZW50cyAtIHN1 YmplY3QgdG8gbXkgcmVzcG9uc2VzIGJlbG93Lg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IERhdmlkIFdhbHRlcm1pcmUgPGRhdmlkLndhbHRlcm1pcmVAbmlzdC5nb3Y+ DQo+IFNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAyNSwgMjAxOCAxMjoxNCBQTQ0KPiBUbzogc2Vj ZGlyQGlldGYub3JnDQo+IENjOiBsc3JAaWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmc7IGRyYWZ0LWll dGYtaXNpcy1zZWdtZW50LXJvdXRpbmctDQo+IG1zZC5hbGxAaWV0Zi5vcmcNCj4gU3ViamVjdDog U2VjZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1pc2lzLXNlZ21lbnQtcm91dGlu Zy1tc2QtMTYNCj4gDQo+IFJldmlld2VyOiBEYXZpZCBXYWx0ZXJtaXJlDQo+IFJldmlldyByZXN1 bHQ6IEhhcyBJc3N1ZXMNCj4gDQo+IEkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBh cnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZw0KPiBlZmZvcnQgdG8gcmV2 aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuICBUaGVz ZQ0KPiBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0 aGUgc2VjdXJpdHkgYXJlYQ0KPiBkaXJlY3RvcnMuDQo+ICBEb2N1bWVudCBlZGl0b3JzIGFuZCBX RyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkNCj4gb3Ro ZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KPiANCj4gVGhlIHN1bW1hcnkgb2YgdGhlIHJldmlldyBp cyBSZWFkeSB3aXRoIChtaW5vcikgaXNzdWVzDQo+IA0KPiBNeSBhcG9sb2dpZXMgZm9yIHRoZSBs YXRlIHJldmlldyBvbiB0aGlzIGRyYWZ0LiBPdmVyYWxsIEkgZm91bmQgdGhpcyBkb2N1bWVudA0K PiB0byBiZSB3ZWxsLXdyaXR0ZW4sIGFuZCBjb25jaXNlLg0KPiANCj4gR2VuZXJhbCBDb21tZW50 czoNCj4gDQo+IFRoaXMgZG9jdW1lbnQgdXNlcyBhIG1peCBvZiBjYXNlIGFyb3VuZCBSRkMyMTE5 IGxhbmd1YWdlIChlLmcuLCBNQVkgbWF5KS4NCj4gWW91IHNob3VsZCB1c2UgdGV4dCBmcm9tIFJG QzgxNzQgdG8gaW5kaWNhdGUgdGhhdCBsb3dlcmNhc2UgdmVyc2lvbnMgb2YgdGhlDQo+IGtleXdv cmRzIGFyZSBub3Qgbm9ybWF0aXZlLCBvciBhZGp1c3QgdGhlIGNhc2Ugb2YgdGhlIGxvd2VyY2Fz ZSB3b3JkcyB0bw0KPiBlbnN1cmUgdGhlcmUgaXMgbm8gY29uZnVzaW9uLg0KPiANCltMZXM6XSBT ZWN0aW9uIDEuMiBkb2VzIGluY2x1ZGUgdGhlIHN0YW5kYXJkIGJvaWxlcnBsYXRlIGZvciBSRkMg MjExOS9SRkM4MTc0Lg0KDQpJIGNoZWNrZWQgYWxsIHRoZSBsb3dlciBjYXNlIHVzZXMgb2YgIm1h eSIgYW5kIHRoZXkgYXJlIGludGVudGlvbmFsLg0KVGhlcmUgd2FzIG9uZSBpbnN0YW5jZSBvZiAi c2hvdWxkIiB0aGF0IEkgY2hhbmdlZCB0byB1cHBlcmNhc2UuDQoNCj4gTWlub3Igbml0OiBUaGVy ZSBpcyBzb21lIGluY29uc2lzdGVuY3kgaW4gdGhlIHVzZSBvZiAiTVNELVR5cGUiICh0aGUgdmFs dWUpDQo+IGFuZCAiTVNEIHR5cGUiICh0aGUgY29uY2VwdCkuIFN1Z2dlc3QgY2xlYW5pbmcgdGhp cyB1cC4NCj4gDQpbTGVzOl0gRG9uZQ0KDQo+IFNwZWNpZmljIGNvbW1lbnRzOg0KPiANCj4gU2Vj dGlvbiAxOg0KPiANCj4gUGFyYSAxOiBzL3RvIGluc3VyZS90byBlbnN1cmUvDQoNCltMZXM6XSBE b25lLg0KDQo+IA0KPiBTZWN0aW9uIDQ6DQo+IA0KPiBUaGUgbGFzdCBwYXJhZ3JhcGggZXN0YWJs aXNoZXMgYSByZXF1aXJlbWVudCBvbiB0aGUgcmVnaXN0cmF0aW9uIG9mIGFuIE1TRA0KPiBUeXBl IHRvIGRlZmluZSB3aGF0IHRoZSBhYnNlbmNlIG9mIGEgZ2l2ZW4gTVNEIFR5cGUgbWVhbnMuIFRo aXMgaXMgYW4NCj4gaW1wb3J0YW50IHJlcXVpcmVtZW50IHRoYXQgbXVzdCBiZSBhZGRyZXNzZWQg ZHVyaW5nIHJlZ2lzdHJhdGlvbiBvZiBuZXcNCj4gTVNEIFR5cGVzLiBJTUhPLCB0aGlzIHJlcXVp cmVtZW50IHNob3VsZCBiZSBlY2hvZWQgaW4gdGhlIHJlZ2lzdHJhdGlvbg0KPiBpbmZvcm1hdGlv biBpbiBzZWN0aW9uIDYgdG8gbWFrZSBzdXJlIGl0IGlzIG5vdCBvdmVybG9va2VkLg0KPg0KW0xl czpdIEkgZGlzYWdyZWUuIFNlY3Rpb24gNiBpcyBkZWZpbmluZyBleGFjdGx5IHdoYXQgc2hvdWxk IGdvIGludG8gdGhlIG5ldyBJQU5BIHJlZ2lzdHJ5Lg0KVGhlIGRlZmluaXRpb24gb2YgImFic2Vu Y2UiIGlzIHNvbWV0aGluZyB0aGF0IHdpbGwgaGF2ZSB0byBiZSBwcm92aWRlZCBpbiB0aGUgZG9j dW1lbnRzIHdoaWNoIGRlZmluZSBuZXcgTVNELXR5cGVzLCBidXQgdGhhdCB3aWxsIE5PVCBiZSBj YXB0dXJlZCBpbiB0aGUgcmVnaXN0cnkgc28gaW5jbHVkaW5nIHRoaXMgaW4gU2VjdGlvbiA2IGlz buKAmXQgYXBwcm9wcmlhdGUuDQoNCiANCj4gU2VjdGlvbiA2Og0KPiANCj4gVGhlICJCYXNlIE1Q TFMgSW1wb3NpdGlvbiBNU0QiIHNob3VsZCByZWZlcmVuY2Ugc2VjdGlvbiA1IG9mIHRoaXMNCj4g ZG9jdW1lbnQuDQoNCltMZXM6XSBBZ2FpbiAtIFNlY3Rpb24gNiBpcyBkZWZpbmluZyB3aGF0IHdp bGwgZ28gaW50byB0aGUgcmVnaXN0cnkuIFRoZSByZWdpc3RyeSB3aWxsIHJlZmVyZW5jZSB0aGUg ZG9jdW1lbnQgLSBub3QgYSBzcGVjaWZpYyBzZWN0aW9uIG9mIHRoZSBkb2N1bWVudC4NCg0KPiAN Cj4gVGhlIHJlZ2lzdHJhdGlvbiBmb3IgIkV4cGVyaW1lbnRhbCIgc2hvdWxkIGJlIG1hcmtlZCBh cyAiUmVzZXJ2ZWQgZm9yDQo+IEV4cGVyaW1lbnRhbCBVc2UiIG9yIGp1c3QgIkV4cGVyaW1lbnRh bCBVc2UiIHRvIGFsaWduIHdpdGggUkZDODEyNi4gUkZDODEyNg0KPiBzdGF0ZXMgdGhhdCAiaXQg aXMgbm90IGFwcHJvcHJpYXRlIGZvciBkb2N1bWVudHMgdG8gc2VsZWN0IGV4cGxpY2l0IHZhbHVl cyBmcm9tDQo+IHJlZ2lzdHJpZXMgb3IgcmFuZ2VzIHdpdGggdGhpcyBwb2xpY3kiLiBJdCBtaWdo dCBiZSBnb29kIHRvIGFkZCBhIG5vdGUgYWxvbmdzaWRlDQo+IHRoZSBvbmUgb24gIkRlc2lnbmF0 ZWQgRXhwZXJ0cyIgaW5kaWNhdGluZyB0aGF0IHZhbHVlcyBmcm9tIHRoaXMgcmFuZ2UgYXJlDQo+ IG5vdCBhc3NpZ25hYmxlLg0KPiANCltMZXM6XSBJIGhhdmUgY2hhbmdlZCB0aGUgdGV4dCB0byAi RXhwZXJpbWVudGFsIFVzZSIuDQpJIHRoaW5rIHRoZSByZXN0IG9mIHlvdXIgY29tbWVudCBpcyBh ZGRyZXNzZWQgYnkgUkZDIDgxMjYgLSB3aGljaCBpcyByZWZlcmVuY2VkLg0KDQo+IFRoZSAiSW50 ZXJpb3IgR2F0ZXdheSBQcm90b2NvbCAoSUdQKSBQYXJhbWV0ZXJzIiByZWdpc3RyeSBoYXMgdGhl DQo+ICJTdGFuZGFyZHMgQWN0aW9uIiBwb2xpY3kgYXNzaWduZWQuIFRoZSBuZXcgIklHUCBNU0Qg VHlwZXMiIHN1Yi1yZWdpc3RyeQ0KPiBkb2VzIG5vdCBoYXZlIHRoZSAiU3RhbmRhcmRzIEFjdGlv biIgcG9saWN5LiBXYXMgdGhpcyBpbnRlbnRpb25hbD8gSWYgc28sIHRoaXMNCj4gc2hvdWxkIGJl IGV4cGxhaW5lZC4gVGhpcyBpcyBhbHNvIGNvbmZ1c2luZyBzaW5jZSB0aGUgZ3VpZGFuY2UgZm9y IGV4cGVydA0KPiByZXZpZXdlcnMgaW4NCj4gUkZDNzM3MCBpbXBsaWVzIHRoYXQgcmVnaXN0cmF0 aW9ucyBhcmUgYmFzZWQgb24gdGhlICJSRkMgUmVxdWlyZWQiIG9yDQo+ICJTdGFuZGFyZHMgQWN0 aW9uIiBwb2xpY2llcy4NCj4NCltMZXM6XSBJUy1JUyByZWdpc3RyaWVzIGFyZSB0eXBpY2FsbHkg RXhwZXJ0IFJldmlldy4gVGhpcyBkZXJpdmVzIGZyb20gY29uc2lkZXJhdGlvbnMgcmVsYXRlZCB0 byB0aGUgbGlhc29uIHdpdGggSVNPIEpUQyAxL1NDNiAoUkZDIDM1NjMpLg0KT1NQRiByZWdpc3Ry aWVzIGFyZSB0eXBpY2FsbHkgU3RhbmRhcmRzIEFjdGlvbi4NCg0KQXMgSUdQIFBhcmFtZXRlcnMg d2FzIGRlZmluZWQgYnkgZHJhZnQtaWV0Zi1vc3BmLXNlZ21lbnQtcm91dGluZy1leHRlbnNpb25z LCBpdCBpcyBTdGFuZGFyZHMgQWN0aW9uLg0KQnV0IGFzIE1TRC1UeXBlcyBpcyBiZWluZyBkZWZp bmVkIGluIGFuIElTLUlTIGRyYWZ0Li4uDQoNClBsZWFzZSBsZWFybiB0byBsaXZlIHdpdGggdGhp cy4NCkl0IGlzbuKAmXQgYSBzaWduaWZpY2FudCBpc3N1ZSBpbiBteSB2aWV3Lg0KDQoNCiANCj4g U2VjdGlvbiA3Og0KPiANCj4gVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGluIFJGQzc5ODEg YXNrIHRoYXQgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMNCj4gYXJvdW5kIHRoZSBkaXNjbG9zdXJl IGFuZCBtb2RpZmljYXRpb24gb2YgdGhpcyB0eXBlIG9mIGluZm9ybWF0aW9uIGlzDQo+IGRlc2Ny aWJlZCBpbiBleHRlbnNpb25zLiBUaGlzIGhhcyBiZWVuIGRvbmUsIGJ1dCBSRkM3OTgxIGFsc28g YXNrcyB0aGF0IGFuDQo+IGludGVncml0eSBtZWNoYW5pc20gYmUgcHJvdmlkZWQgaWYgdGhlcmUg aXMgYSBoaWdoIHJpc2sgcmVzdWx0aW5nIGZyb20NCj4gbW9kaWZpY2F0aW9uIG9mIGNhcGFiaWxp dHkgaW5mb3JtYXRpb24uIFRoZXJlIGlzIG5vIGRpc2N1c3Npb24gaW4gdGhlDQo+IGRvY3VtZW50 J3Mgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBhYm91dCB0aGUgbmF0dXJlIG9mIHJpc2sgaW4gdGhp cyBjYXNlIGFuZA0KPiB3aHkgYW4gaW50ZWdyaXR5IG1lY2hhbmlzbSBpcyBub3QgbmVlZGVkLiBJ dCBzZWVtcyBsaWtlIGZhbHNlIGluZm9ybWF0aW9uDQo+IGNhbiBiZSB1c2VkIHRvIGNhdXNlIGEg ZGVuaWFsIG9mIHNlcnZpY2UgcmVnYXJkaW5nIGNvbXB1dGVkIHBhdGhzLiBUaGlzDQo+IHNvdW5k cyBsaWtlIGhhdmluZyB0aGlzIGhhcHBlbiBjb3VsZCBiZSBiYWQuIEkgYW0gbm90IGFuIGV4cGVy dCBvbiByb3V0aW5nDQo+IHByb3RvY29scywgc28gSSBhbSBub3Qgc3VyZSBpZiB0aGlzIGlzIGFu IGlzc3VlLiBIb3cgYmFkIGFuZCBsaWtlbHkgaXMgc3VjaCBhIHJpc2s/DQo+IA0KDQpbTGVzOl0g VGhlIGludGVncml0eSBtZWNoYW5pc20gaXMgKGFzIHlvdSBwb2ludCBvdXQpIGRpc2N1c3NlZCBp biB0aGUgU2VjdXJpdHkgc2VjdGlvbiBvZiBSRkMgNzk4MSAtIHdoaWNoIGlzIHJlZmVyZW5jZWQg aW4gdGhlIFNlY3VyaXR5IFNlY3Rpb24gb2YgdGhpcyBkb2N1bWVudC4NClRoZSBpbnRyb2R1Y3Rp b24gb2YgYSBuZXcgVExWIGRvZXMgbm90IGFsdGVyIHRoZSBpbnRlZ3JpdHkgbWVjaGFuaXNtIHJl cXVpcmVtZW50cy4NCg0KICAgIExlcw0KDQo= From nobody Wed Sep 26 14:11:20 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B03EA12F1A2; Wed, 26 Sep 2018 14:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AM20XSbfzCWz; Wed, 26 Sep 2018 14:11:16 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 1BF591294D7; Wed, 26 Sep 2018 14:11:12 -0700 (PDT) X-AuditID: 1209190f-079ff7000000662b-35-5babf5ef0678 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id B6.50.26155.FE5FBAB5; Wed, 26 Sep 2018 17:11:11 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w8QLB90J018021; Wed, 26 Sep 2018 17:11:10 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w8QLB4NX017333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 26 Sep 2018 17:11:07 -0400 Date: Wed, 26 Sep 2018 16:11:04 -0500 From: Benjamin Kaduk To: "Les Ginsberg (ginsberg)" Cc: David Waltermire , "secdir@ietf.org" , "lsr@ietf.org" , "ietf@ietf.org" , "draft-ietf-isis-segment-routing-msd.all@ietf.org" Message-ID: <20180926211104.GQ24695@kduck.kaduk.org> References: <153790283647.5258.15634056350853857580@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFKsWRmVeSWpSXmKPExsUixCmqrfv+6+pog66LihYbe/6xWXxfr2ix 4c9GdotnG+ezWJx4soLV4sPChywObB5Tfm9k9Viy5CeTx7WTf1kDmKO4bFJSczLLUov07RK4 Mra9O8BesMmoom/GJ/YGxv/qXYycHBICJhKH3mxg6mLk4hASWMwkcXreNlYIZyOjxLnntxlB qoQErjJJPOsPBbFZBFQlzp+Yww5iswmoSDR0X2buYuTgEBEwklj8XBukl1lgOpPEh4PT2EHi wgJ+ElPOiIGYvEDLdjeWQ0ysk/hychcTiM0rIChxcuYTFhCbWUBd4s+8S2ATmQWkJZb/44AI y0s0b53NDGJzCrhKvP+3BqxVVEBZYm/fIfYJjIKzkEyahWTSLIRJs5BMWsDIsopRNiW3Sjc3 MTOnODVZtzg5MS8vtUjXRC83s0QvNaV0EyM4AiT5dzDOafA+xCjAwajEw7th4+poIdbEsuLK 3EOMkhxMSqK8CnuBQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4120HyvGmJFZWpRblw6SkOViU xHkntCyOFhJITyxJzU5NLUgtgsnKcHAoSfCe+wLUKFiUmp5akZaZU4KQZuLgBBnOAzT8AkgN b3FBYm5xZjpE/hSjMceLGR0zmDm2nemcwSzEkpeflyolzhsDUioAUppRmgc3DZTEJLL317xi FAd6TphXG5jShHiACRBu3iugVUxAqyb0rABZVZKIkJJqYJzC4LdeLpKxx3Or4JQn/pvKPLcs uXx19Z5Dol4y1nv66hfe9rz26Qlv843wtZsYymvkd2n/Mxfsa30XoTG3X4SRP27uig3L017O OOfqUXxf4BVTbZ9P8vn8rWI7XKe8W2HTVvtdMuiobmaS5qJvVp98xVjE6nZvvpe+pfBg4Yfn X2P9/BY8YVRiKc5INNRiLipOBADGFi5IPQMAAA== Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-isis-segment-routing-msd-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2018 21:11:19 -0000 On Wed, Sep 26, 2018 at 08:45:03PM +0000, Les Ginsberg (ginsberg) wrote: > David - > > Thanx for the review. > A new version of the draft (17) has been published to address your comments - subject to my responses below. Just in time for me to see the updated version for my IESG review; thanks. > > -----Original Message----- > > From: David Waltermire > > Sent: Tuesday, September 25, 2018 12:14 PM > > To: secdir@ietf.org > > Cc: lsr@ietf.org; ietf@ietf.org; draft-ietf-isis-segment-routing- > > msd.all@ietf.org > > Subject: Secdir last call review of draft-ietf-isis-segment-routing-msd-16 > > > > Reviewer: David Waltermire > > Review result: Has Issues > > > > I have reviewed this document as part of the security directorate's ongoing > > effort to review all IETF documents being processed by the IESG. These > > comments were written primarily for the benefit of the security area > > directors. > > Document editors and WG chairs should treat these comments just like any > > other last call comments. > > > > The summary of the review is Ready with (minor) issues > > > > My apologies for the late review on this draft. Overall I found this document > > to be well-written, and concise. > > > > General Comments: > > > > This document uses a mix of case around RFC2119 language (e.g., MAY may). > > You should use text from RFC8174 to indicate that lowercase versions of the > > keywords are not normative, or adjust the case of the lowercase words to > > ensure there is no confusion. > > > [Les:] Section 1.2 does include the standard boilerplate for RFC 2119/RFC8174. > > I checked all the lower case uses of "may" and they are intentional. > There was one instance of "should" that I changed to uppercase. > > > Minor nit: There is some inconsistency in the use of "MSD-Type" (the value) > > and "MSD type" (the concept). Suggest cleaning this up. > > > [Les:] Done > > > Specific comments: > > > > Section 1: > > > > Para 1: s/to insure/to ensure/ > > [Les:] Done. > > > > > Section 4: > > > > The last paragraph establishes a requirement on the registration of an MSD > > Type to define what the absence of a given MSD Type means. This is an > > important requirement that must be addressed during registration of new > > MSD Types. IMHO, this requirement should be echoed in the registration > > information in section 6 to make sure it is not overlooked. > > > [Les:] I disagree. Section 6 is defining exactly what should go into the new IANA registry. > The definition of "absence" is something that will have to be provided in the documents which define new MSD-types, but that will NOT be captured in the registry so including this in Section 6 isn’t appropriate. I think a good way to think about this is as giving guidance to the Experts, that they should not approve registration requests that fail to provide this information along with the request. Guidance for the Experts is appropriate in the IANA Considerations section. (Also, my understanding is that IANA prefers to have a more explicit template for new registrations to follow, though I should not try to speak for them.) > > > Section 6: > > > > The "Base MPLS Imposition MSD" should reference section 5 of this > > document. > > [Les:] Again - Section 6 is defining what will go into the registry. The registry will reference the document - not a specific section of the document. The contents of the "Reference" column for Value 1 can refer to a specific section of a document, surely? > > > > The registration for "Experimental" should be marked as "Reserved for > > Experimental Use" or just "Experimental Use" to align with RFC8126. RFC8126 > > states that "it is not appropriate for documents to select explicit values from > > registries or ranges with this policy". It might be good to add a note alongside > > the one on "Designated Experts" indicating that values from this range are > > not assignable. > > > [Les:] I have changed the text to "Experimental Use". > I think the rest of your comment is addressed by RFC 8126 - which is referenced. > > > The "Interior Gateway Protocol (IGP) Parameters" registry has the > > "Standards Action" policy assigned. The new "IGP MSD Types" sub-registry > > does not have the "Standards Action" policy. Was this intentional? If so, this > > should be explained. This is also confusing since the guidance for expert > > reviewers in > > RFC7370 implies that registrations are based on the "RFC Required" or > > "Standards Action" policies. > > > [Les:] IS-IS registries are typically Expert Review. This derives from considerations related to the liason with ISO JTC 1/SC6 (RFC 3563). > OSPF registries are typically Standards Action. > > As IGP Parameters was defined by draft-ietf-ospf-segment-routing-extensions, it is Standards Action. > But as MSD-Types is being defined in an IS-IS draft... > > Please learn to live with this. > It isn’t a significant issue in my view. > > > > > Section 7: > > > > The security considerations in RFC7981 ask that security considerations > > around the disclosure and modification of this type of information is > > described in extensions. This has been done, but RFC7981 also asks that an > > integrity mechanism be provided if there is a high risk resulting from > > modification of capability information. There is no discussion in the > > document's security consideration about the nature of risk in this case and > > why an integrity mechanism is not needed. It seems like false information > > can be used to cause a denial of service regarding computed paths. This > > sounds like having this happen could be bad. I am not an expert on routing > > protocols, so I am not sure if this is an issue. How bad and likely is such a risk? > > > > [Les:] The integrity mechanism is (as you point out) discussed in the Security section of RFC 7981 - which is referenced in the Security Section of this document. > The introduction of a new TLV does not alter the integrity mechanism requirements. My read of 7981 is that "there are these existing integrity protection mechanisms; when the consequences of modification are bad, use them". So there is not necessarily a need for each TLV to provide its own internal integrity scheme, as Les notes. -Benjamin From nobody Wed Sep 26 16:00:13 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D61AB128CB7; Wed, 26 Sep 2018 15:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxau0CLWGkUs; Wed, 26 Sep 2018 15:59:53 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B0F9128A6E; Wed, 26 Sep 2018 15:59:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10374; q=dns/txt; s=iport; t=1538002793; x=1539212393; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Cv+WucbAkB5/cgkhE1OneRZGFea6HfPT84JVK128uPc=; b=jN/dbvVR8oCoPx7vTiV8NXXkSMjpzwWRhp+ZqrV9ygDLcrZDj1TaU6dz 8rxcQeiV7f7kGZGiLPgLiE/gIpOAznvAkC9UkPJ3YTvaKLCIYeNfCuZRo dSEUg1VD4b6mZyF64LsF0QKY68n78aUmQq0lihG25UqjjxSqnu+1noaF2 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AMAABnDqxb/49dJa1aDgsBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVGCDoFkKAqDaogVjDCCDYM9kxKBeguEbAIXg2YhNBg?= =?us-ascii?q?BAwEBAgEBAm0ohTgBAQEBAyMRNw4MBAIBCBEEAQEBAgImAgICMBUICAIEDgU?= =?us-ascii?q?IhRukCYEuiheBC4lwF4FBP4ERAYMShRUPgluCVwKTY4kkCQKQIx+BRoRSgwe?= =?us-ascii?q?GFZRqAhEUgSUdOIFVcBWDJ4IlF41eOm+MMYEeAQE?= X-IronPort-AV: E=Sophos;i="5.54,308,1534809600"; d="scan'208";a="177229998" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Sep 2018 22:59:52 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id w8QMxpbw022748 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Sep 2018 22:59:52 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 26 Sep 2018 17:59:51 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1395.000; Wed, 26 Sep 2018 17:59:50 -0500 From: "Les Ginsberg (ginsberg)" To: Benjamin Kaduk CC: David Waltermire , "secdir@ietf.org" , "lsr@ietf.org" , "ietf@ietf.org" , "draft-ietf-isis-segment-routing-msd.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-isis-segment-routing-msd-16 Thread-Index: AQHUVQPqnQ0QGOOP8EOqsf/gazaoC6UC9FjAgABwTwD//8fJ0A== Date: Wed, 26 Sep 2018 22:59:50 +0000 Message-ID: <149d5d345afc462f9c5e5770079aaf0e@XCH-ALN-001.cisco.com> References: <153790283647.5258.15634056350853857580@ietfa.amsl.com> <20180926211104.GQ24695@kduck.kaduk.org> In-Reply-To: <20180926211104.GQ24695@kduck.kaduk.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.8.175] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-isis-segment-routing-msd-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2018 22:59:56 -0000 QmVuamFtaW4gLQ0KDQpSZXNwb25zZXMgbmxpbmUuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogQmVuamFtaW4gS2FkdWsgPGthZHVrQG1pdC5lZHU+DQo+IFNlbnQ6IFdl ZG5lc2RheSwgU2VwdGVtYmVyIDI2LCAyMDE4IDI6MTEgUE0NCj4gVG86IExlcyBHaW5zYmVyZyAo Z2luc2JlcmcpIDxnaW5zYmVyZ0BjaXNjby5jb20+DQo+IENjOiBEYXZpZCBXYWx0ZXJtaXJlIDxk YXZpZC53YWx0ZXJtaXJlQG5pc3QuZ292Pjsgc2VjZGlyQGlldGYub3JnOw0KPiBsc3JAaWV0Zi5v cmc7IGlldGZAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtaXNpcy1zZWdtZW50LXJvdXRpbmctbXNkLmFs bEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogU2VjZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJh ZnQtaWV0Zi1pc2lzLXNlZ21lbnQtcm91dGluZy1tc2QtMTYNCj4gDQo+IE9uIFdlZCwgU2VwIDI2 LCAyMDE4IGF0IDA4OjQ1OjAzUE0gKzAwMDAsIExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpIHdyb3Rl Og0KPiA+IERhdmlkIC0NCj4gPg0KPiA+IFRoYW54IGZvciB0aGUgcmV2aWV3Lg0KPiA+IEEgbmV3 IHZlcnNpb24gb2YgdGhlIGRyYWZ0ICgxNykgaGFzIGJlZW4gcHVibGlzaGVkIHRvIGFkZHJlc3Mg eW91cg0KPiBjb21tZW50cyAtIHN1YmplY3QgdG8gbXkgcmVzcG9uc2VzIGJlbG93Lg0KPiANCj4g SnVzdCBpbiB0aW1lIGZvciBtZSB0byBzZWUgdGhlIHVwZGF0ZWQgdmVyc2lvbiBmb3IgbXkgSUVT RyByZXZpZXc7IHRoYW5rcy4NCj4gDQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiA+ID4gRnJvbTogRGF2aWQgV2FsdGVybWlyZSA8ZGF2aWQud2FsdGVybWlyZUBuaXN0Lmdvdj4N Cj4gPiA+IFNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAyNSwgMjAxOCAxMjoxNCBQTQ0KPiA+ID4g VG86IHNlY2RpckBpZXRmLm9yZw0KPiA+ID4gQ2M6IGxzckBpZXRmLm9yZzsgaWV0ZkBpZXRmLm9y ZzsgZHJhZnQtaWV0Zi1pc2lzLXNlZ21lbnQtcm91dGluZy0NCj4gPiA+IG1zZC5hbGxAaWV0Zi5v cmcNCj4gPiA+IFN1YmplY3Q6IFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mDQo+ID4gPiBkcmFm dC1pZXRmLWlzaXMtc2VnbWVudC1yb3V0aW5nLW1zZC0xNg0KPiA+ID4NCj4gPiA+IFJldmlld2Vy OiBEYXZpZCBXYWx0ZXJtaXJlDQo+ID4gPiBSZXZpZXcgcmVzdWx0OiBIYXMgSXNzdWVzDQo+ID4g Pg0KPiA+ID4gSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2Vj dXJpdHkgZGlyZWN0b3JhdGUncw0KPiA+ID4gb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJ RVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlDQo+ID4gPiBJRVNHLiAgVGhlc2Ug Y29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlDQo+ ID4gPiBzZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4NCj4gPiA+ICBEb2N1bWVudCBlZGl0b3JzIGFu ZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QNCj4gPiA+IGxpa2Ug YW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCj4gPiA+DQo+ID4gPiBUaGUgc3VtbWFyeSBv ZiB0aGUgcmV2aWV3IGlzIFJlYWR5IHdpdGggKG1pbm9yKSBpc3N1ZXMNCj4gPiA+DQo+ID4gPiBN eSBhcG9sb2dpZXMgZm9yIHRoZSBsYXRlIHJldmlldyBvbiB0aGlzIGRyYWZ0LiBPdmVyYWxsIEkg Zm91bmQgdGhpcw0KPiA+ID4gZG9jdW1lbnQgdG8gYmUgd2VsbC13cml0dGVuLCBhbmQgY29uY2lz ZS4NCj4gPiA+DQo+ID4gPiBHZW5lcmFsIENvbW1lbnRzOg0KPiA+ID4NCj4gPiA+IFRoaXMgZG9j dW1lbnQgdXNlcyBhIG1peCBvZiBjYXNlIGFyb3VuZCBSRkMyMTE5IGxhbmd1YWdlIChlLmcuLCBN QVkNCj4gbWF5KS4NCj4gPiA+IFlvdSBzaG91bGQgdXNlIHRleHQgZnJvbSBSRkM4MTc0IHRvIGlu ZGljYXRlIHRoYXQgbG93ZXJjYXNlIHZlcnNpb25zDQo+ID4gPiBvZiB0aGUga2V5d29yZHMgYXJl IG5vdCBub3JtYXRpdmUsIG9yIGFkanVzdCB0aGUgY2FzZSBvZiB0aGUNCj4gPiA+IGxvd2VyY2Fz ZSB3b3JkcyB0byBlbnN1cmUgdGhlcmUgaXMgbm8gY29uZnVzaW9uLg0KPiA+ID4NCj4gPiBbTGVz Ol0gU2VjdGlvbiAxLjIgZG9lcyBpbmNsdWRlIHRoZSBzdGFuZGFyZCBib2lsZXJwbGF0ZSBmb3Ig UkZDDQo+IDIxMTkvUkZDODE3NC4NCj4gPg0KPiA+IEkgY2hlY2tlZCBhbGwgdGhlIGxvd2VyIGNh c2UgdXNlcyBvZiAibWF5IiBhbmQgdGhleSBhcmUgaW50ZW50aW9uYWwuDQo+ID4gVGhlcmUgd2Fz IG9uZSBpbnN0YW5jZSBvZiAic2hvdWxkIiB0aGF0IEkgY2hhbmdlZCB0byB1cHBlcmNhc2UuDQo+ ID4NCj4gPiA+IE1pbm9yIG5pdDogVGhlcmUgaXMgc29tZSBpbmNvbnNpc3RlbmN5IGluIHRoZSB1 c2Ugb2YgIk1TRC1UeXBlIiAodGhlDQo+ID4gPiB2YWx1ZSkgYW5kICJNU0QgdHlwZSIgKHRoZSBj b25jZXB0KS4gU3VnZ2VzdCBjbGVhbmluZyB0aGlzIHVwLg0KPiA+ID4NCj4gPiBbTGVzOl0gRG9u ZQ0KPiA+DQo+ID4gPiBTcGVjaWZpYyBjb21tZW50czoNCj4gPiA+DQo+ID4gPiBTZWN0aW9uIDE6 DQo+ID4gPg0KPiA+ID4gUGFyYSAxOiBzL3RvIGluc3VyZS90byBlbnN1cmUvDQo+ID4NCj4gPiBb TGVzOl0gRG9uZS4NCj4gPg0KPiA+ID4NCj4gPiA+IFNlY3Rpb24gNDoNCj4gPiA+DQo+ID4gPiBU aGUgbGFzdCBwYXJhZ3JhcGggZXN0YWJsaXNoZXMgYSByZXF1aXJlbWVudCBvbiB0aGUgcmVnaXN0 cmF0aW9uIG9mDQo+ID4gPiBhbiBNU0QgVHlwZSB0byBkZWZpbmUgd2hhdCB0aGUgYWJzZW5jZSBv ZiBhIGdpdmVuIE1TRCBUeXBlIG1lYW5zLg0KPiA+ID4gVGhpcyBpcyBhbiBpbXBvcnRhbnQgcmVx dWlyZW1lbnQgdGhhdCBtdXN0IGJlIGFkZHJlc3NlZCBkdXJpbmcNCj4gPiA+IHJlZ2lzdHJhdGlv biBvZiBuZXcgTVNEIFR5cGVzLiBJTUhPLCB0aGlzIHJlcXVpcmVtZW50IHNob3VsZCBiZQ0KPiA+ ID4gZWNob2VkIGluIHRoZSByZWdpc3RyYXRpb24gaW5mb3JtYXRpb24gaW4gc2VjdGlvbiA2IHRv IG1ha2Ugc3VyZSBpdCBpcyBub3QNCj4gb3Zlcmxvb2tlZC4NCj4gPiA+DQo+ID4gW0xlczpdIEkg ZGlzYWdyZWUuIFNlY3Rpb24gNiBpcyBkZWZpbmluZyBleGFjdGx5IHdoYXQgc2hvdWxkIGdvIGlu dG8gdGhlIG5ldw0KPiBJQU5BIHJlZ2lzdHJ5Lg0KPiA+IFRoZSBkZWZpbml0aW9uIG9mICJhYnNl bmNlIiBpcyBzb21ldGhpbmcgdGhhdCB3aWxsIGhhdmUgdG8gYmUgcHJvdmlkZWQgaW4NCj4gdGhl IGRvY3VtZW50cyB3aGljaCBkZWZpbmUgbmV3IE1TRC10eXBlcywgYnV0IHRoYXQgd2lsbCBOT1Qg YmUgY2FwdHVyZWQNCj4gaW4gdGhlIHJlZ2lzdHJ5IHNvIGluY2x1ZGluZyB0aGlzIGluIFNlY3Rp b24gNiBpc27igJl0IGFwcHJvcHJpYXRlLg0KPiANCj4gSSB0aGluayBhIGdvb2Qgd2F5IHRvIHRo aW5rIGFib3V0IHRoaXMgaXMgYXMgZ2l2aW5nIGd1aWRhbmNlIHRvIHRoZSBFeHBlcnRzLCB0aGF0 DQo+IHRoZXkgc2hvdWxkIG5vdCBhcHByb3ZlIHJlZ2lzdHJhdGlvbiByZXF1ZXN0cyB0aGF0IGZh aWwgdG8gcHJvdmlkZSB0aGlzDQo+IGluZm9ybWF0aW9uIGFsb25nIHdpdGggdGhlIHJlcXVlc3Qu ICBHdWlkYW5jZSBmb3IgdGhlIEV4cGVydHMgaXMgYXBwcm9wcmlhdGUNCj4gaW4gdGhlIElBTkEg Q29uc2lkZXJhdGlvbnMgc2VjdGlvbi4NCj4gKEFsc28sIG15IHVuZGVyc3RhbmRpbmcgaXMgdGhh dCBJQU5BIHByZWZlcnMgdG8gaGF2ZSBhIG1vcmUgZXhwbGljaXQNCj4gdGVtcGxhdGUgZm9yIG5l dyByZWdpc3RyYXRpb25zIHRvIGZvbGxvdywgdGhvdWdoIEkgc2hvdWxkIG5vdCB0cnkgdG8gc3Bl YWsgZm9yDQo+IHRoZW0uKQ0KPiANCg0KW0xlczpdIFRoZSByZWFzb24gd2UgdXNlICJleHBlcnRz IiBpcyBiZWNhdXNlIHdlIGtub3cvZXhwZWN0IHRoZW0gdG8gYmUgZmFtaWxpYXIgd2l0aCB0aGUg ZG9jdW1lbnRzIHdoaWNoIGRlZmluZSB0aGUgVExWcyAodW5saWtlIGEgImdlbmVyYWwgSUVURiBy ZWFkZXIiIHdob3NlIGZhbWlsaWFyaXR5IHdpdGggdGhlIHN1YmplY3QgbWF0dGVyIG1heSB2YXJ5 KS4NClJlcGVhdGluZyB3aGF0IGlzIHNhaWQgaW4gU2VjdGlvbiA0IGluIFNlY3Rpb24gNiBvbmx5 IG1ha2VzIHNlbnNlIGlmIHlvdSB0aGluayB0aGUgImV4cGVydCIgb25seSByZWFkcyBJQU5BIHNl Y3Rpb25zLiBTdWNoIGEgcGVyc29uIHdvdWxkIG5vdCBiZSBhbiBleHBlcnQgSU1PLiA6LSkNCg0K ICAgTGVzDQoNCj4gPg0KPiA+ID4gU2VjdGlvbiA2Og0KPiA+ID4NCj4gPiA+IFRoZSAiQmFzZSBN UExTIEltcG9zaXRpb24gTVNEIiBzaG91bGQgcmVmZXJlbmNlIHNlY3Rpb24gNSBvZiB0aGlzDQo+ ID4gPiBkb2N1bWVudC4NCj4gPg0KPiA+IFtMZXM6XSBBZ2FpbiAtIFNlY3Rpb24gNiBpcyBkZWZp bmluZyB3aGF0IHdpbGwgZ28gaW50byB0aGUgcmVnaXN0cnkuIFRoZSByZWdpc3RyeQ0KPiB3aWxs IHJlZmVyZW5jZSB0aGUgZG9jdW1lbnQgLSBub3QgYSBzcGVjaWZpYyBzZWN0aW9uIG9mIHRoZSBk b2N1bWVudC4NCj4gDQo+IFRoZSBjb250ZW50cyBvZiB0aGUgIlJlZmVyZW5jZSIgY29sdW1uIGZv ciBWYWx1ZSAxIGNhbiByZWZlciB0byBhIHNwZWNpZmljDQo+IHNlY3Rpb24gb2YgYSBkb2N1bWVu dCwgc3VyZWx5Pw0KPiANCj4gPiA+DQo+ID4gPiBUaGUgcmVnaXN0cmF0aW9uIGZvciAiRXhwZXJp bWVudGFsIiBzaG91bGQgYmUgbWFya2VkIGFzICJSZXNlcnZlZA0KPiA+ID4gZm9yIEV4cGVyaW1l bnRhbCBVc2UiIG9yIGp1c3QgIkV4cGVyaW1lbnRhbCBVc2UiIHRvIGFsaWduIHdpdGgNCj4gPiA+ IFJGQzgxMjYuIFJGQzgxMjYgc3RhdGVzIHRoYXQgIml0IGlzIG5vdCBhcHByb3ByaWF0ZSBmb3Ig ZG9jdW1lbnRzIHRvDQo+ID4gPiBzZWxlY3QgZXhwbGljaXQgdmFsdWVzIGZyb20gcmVnaXN0cmll cyBvciByYW5nZXMgd2l0aCB0aGlzIHBvbGljeSIuDQo+ID4gPiBJdCBtaWdodCBiZSBnb29kIHRv IGFkZCBhIG5vdGUgYWxvbmdzaWRlIHRoZSBvbmUgb24gIkRlc2lnbmF0ZWQNCj4gPiA+IEV4cGVy dHMiIGluZGljYXRpbmcgdGhhdCB2YWx1ZXMgZnJvbSB0aGlzIHJhbmdlIGFyZSBub3QgYXNzaWdu YWJsZS4NCj4gPiA+DQo+ID4gW0xlczpdIEkgaGF2ZSBjaGFuZ2VkIHRoZSB0ZXh0IHRvICJFeHBl cmltZW50YWwgVXNlIi4NCj4gPiBJIHRoaW5rIHRoZSByZXN0IG9mIHlvdXIgY29tbWVudCBpcyBh ZGRyZXNzZWQgYnkgUkZDIDgxMjYgLSB3aGljaCBpcw0KPiByZWZlcmVuY2VkLg0KPiA+DQo+ID4g PiBUaGUgIkludGVyaW9yIEdhdGV3YXkgUHJvdG9jb2wgKElHUCkgUGFyYW1ldGVycyIgcmVnaXN0 cnkgaGFzIHRoZQ0KPiA+ID4gIlN0YW5kYXJkcyBBY3Rpb24iIHBvbGljeSBhc3NpZ25lZC4gVGhl IG5ldyAiSUdQIE1TRCBUeXBlcyINCj4gPiA+IHN1Yi1yZWdpc3RyeSBkb2VzIG5vdCBoYXZlIHRo ZSAiU3RhbmRhcmRzIEFjdGlvbiIgcG9saWN5LiBXYXMgdGhpcw0KPiA+ID4gaW50ZW50aW9uYWw/ IElmIHNvLCB0aGlzIHNob3VsZCBiZSBleHBsYWluZWQuIFRoaXMgaXMgYWxzbyBjb25mdXNpbmcN Cj4gPiA+IHNpbmNlIHRoZSBndWlkYW5jZSBmb3IgZXhwZXJ0IHJldmlld2VycyBpbg0KPiA+ID4g UkZDNzM3MCBpbXBsaWVzIHRoYXQgcmVnaXN0cmF0aW9ucyBhcmUgYmFzZWQgb24gdGhlICJSRkMg UmVxdWlyZWQiDQo+ID4gPiBvciAiU3RhbmRhcmRzIEFjdGlvbiIgcG9saWNpZXMuDQo+ID4gPg0K PiA+IFtMZXM6XSBJUy1JUyByZWdpc3RyaWVzIGFyZSB0eXBpY2FsbHkgRXhwZXJ0IFJldmlldy4g VGhpcyBkZXJpdmVzIGZyb20NCj4gY29uc2lkZXJhdGlvbnMgcmVsYXRlZCB0byB0aGUgbGlhc29u IHdpdGggSVNPIEpUQyAxL1NDNiAoUkZDIDM1NjMpLg0KPiA+IE9TUEYgcmVnaXN0cmllcyBhcmUg dHlwaWNhbGx5IFN0YW5kYXJkcyBBY3Rpb24uDQo+ID4NCj4gPiBBcyBJR1AgUGFyYW1ldGVycyB3 YXMgZGVmaW5lZCBieSBkcmFmdC1pZXRmLW9zcGYtc2VnbWVudC1yb3V0aW5nLQ0KPiBleHRlbnNp b25zLCBpdCBpcyBTdGFuZGFyZHMgQWN0aW9uLg0KPiA+IEJ1dCBhcyBNU0QtVHlwZXMgaXMgYmVp bmcgZGVmaW5lZCBpbiBhbiBJUy1JUyBkcmFmdC4uLg0KPiA+DQo+ID4gUGxlYXNlIGxlYXJuIHRv IGxpdmUgd2l0aCB0aGlzLg0KPiA+IEl0IGlzbuKAmXQgYSBzaWduaWZpY2FudCBpc3N1ZSBpbiBt eSB2aWV3Lg0KPiA+DQo+ID4NCj4gPg0KPiA+ID4gU2VjdGlvbiA3Og0KPiA+ID4NCj4gPiA+IFRo ZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBpbiBSRkM3OTgxIGFzayB0aGF0IHNlY3VyaXR5DQo+ ID4gPiBjb25zaWRlcmF0aW9ucyBhcm91bmQgdGhlIGRpc2Nsb3N1cmUgYW5kIG1vZGlmaWNhdGlv biBvZiB0aGlzIHR5cGUNCj4gPiA+IG9mIGluZm9ybWF0aW9uIGlzIGRlc2NyaWJlZCBpbiBleHRl bnNpb25zLiBUaGlzIGhhcyBiZWVuIGRvbmUsIGJ1dA0KPiA+ID4gUkZDNzk4MSBhbHNvIGFza3Mg dGhhdCBhbiBpbnRlZ3JpdHkgbWVjaGFuaXNtIGJlIHByb3ZpZGVkIGlmIHRoZXJlDQo+ID4gPiBp cyBhIGhpZ2ggcmlzayByZXN1bHRpbmcgZnJvbSBtb2RpZmljYXRpb24gb2YgY2FwYWJpbGl0eQ0K PiA+ID4gaW5mb3JtYXRpb24uIFRoZXJlIGlzIG5vIGRpc2N1c3Npb24gaW4gdGhlIGRvY3VtZW50 J3Mgc2VjdXJpdHkNCj4gPiA+IGNvbnNpZGVyYXRpb24gYWJvdXQgdGhlIG5hdHVyZSBvZiByaXNr IGluIHRoaXMgY2FzZSBhbmQgd2h5IGFuDQo+ID4gPiBpbnRlZ3JpdHkgbWVjaGFuaXNtIGlzIG5v dCBuZWVkZWQuIEl0IHNlZW1zIGxpa2UgZmFsc2UgaW5mb3JtYXRpb24NCj4gPiA+IGNhbiBiZSB1 c2VkIHRvIGNhdXNlIGEgZGVuaWFsIG9mIHNlcnZpY2UgcmVnYXJkaW5nIGNvbXB1dGVkIHBhdGhz Lg0KPiA+ID4gVGhpcyBzb3VuZHMgbGlrZSBoYXZpbmcgdGhpcyBoYXBwZW4gY291bGQgYmUgYmFk LiBJIGFtIG5vdCBhbiBleHBlcnQgb24NCj4gcm91dGluZyBwcm90b2NvbHMsIHNvIEkgYW0gbm90 IHN1cmUgaWYgdGhpcyBpcyBhbiBpc3N1ZS4gSG93IGJhZCBhbmQgbGlrZWx5IGlzDQo+IHN1Y2gg YSByaXNrPw0KPiA+ID4NCj4gPg0KPiA+IFtMZXM6XSBUaGUgaW50ZWdyaXR5IG1lY2hhbmlzbSBp cyAoYXMgeW91IHBvaW50IG91dCkgZGlzY3Vzc2VkIGluIHRoZQ0KPiBTZWN1cml0eSBzZWN0aW9u IG9mIFJGQyA3OTgxIC0gd2hpY2ggaXMgcmVmZXJlbmNlZCBpbiB0aGUgU2VjdXJpdHkgU2VjdGlv biBvZg0KPiB0aGlzIGRvY3VtZW50Lg0KPiA+IFRoZSBpbnRyb2R1Y3Rpb24gb2YgYSBuZXcgVExW IGRvZXMgbm90IGFsdGVyIHRoZSBpbnRlZ3JpdHkgbWVjaGFuaXNtDQo+IHJlcXVpcmVtZW50cy4N Cj4gDQo+IE15IHJlYWQgb2YgNzk4MSBpcyB0aGF0ICJ0aGVyZSBhcmUgdGhlc2UgZXhpc3Rpbmcg aW50ZWdyaXR5IHByb3RlY3Rpb24NCj4gbWVjaGFuaXNtczsgd2hlbiB0aGUgY29uc2VxdWVuY2Vz IG9mIG1vZGlmaWNhdGlvbiBhcmUgYmFkLCB1c2UgdGhlbSIuDQo+IFNvIHRoZXJlIGlzIG5vdCBu ZWNlc3NhcmlseSBhIG5lZWQgZm9yIGVhY2ggVExWIHRvIHByb3ZpZGUgaXRzIG93biBpbnRlcm5h bA0KPiBpbnRlZ3JpdHkgc2NoZW1lLCBhcyBMZXMgbm90ZXMuDQo+IA0KPiAtQmVuamFtaW4NCg== From nobody Wed Sep 26 16:06:47 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC02130DCE; Wed, 26 Sep 2018 16:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-3hamkBRr8m; Wed, 26 Sep 2018 16:06:31 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 C5E84128CFD; Wed, 26 Sep 2018 16:06:30 -0700 (PDT) X-AuditID: 12074425-e29ff700000028dd-33-5bac10f4baef Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 89.18.10461.4F01CAB5; Wed, 26 Sep 2018 19:06:29 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w8QN6Pck019013; Wed, 26 Sep 2018 19:06:26 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w8QN6LKE019089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 26 Sep 2018 19:06:24 -0400 Date: Wed, 26 Sep 2018 18:06:21 -0500 From: Benjamin Kaduk To: "Les Ginsberg (ginsberg)" Cc: David Waltermire , "secdir@ietf.org" , "lsr@ietf.org" , "ietf@ietf.org" , "draft-ietf-isis-segment-routing-msd.all@ietf.org" Message-ID: <20180926230621.GW24695@kduck.kaduk.org> References: <153790283647.5258.15634056350853857580@ietfa.amsl.com> <20180926211104.GQ24695@kduck.kaduk.org> <149d5d345afc462f9c5e5770079aaf0e@XCH-ALN-001.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <149d5d345afc462f9c5e5770079aaf0e@XCH-ALN-001.cisco.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFKsWRmVeSWpSXmKPExsUixCmqrPtVYE20wdJ7rBYbe/6xWXxfr2ix 4c9GdotnG+ezWJx4soLV4sPChywObB5Tfm9k9Viy5CeTx7WTf1kDmKO4bFJSczLLUov07RK4 MhbMncFUcFG14s+5RqYGxlWyXYwcHBICJhKH//B2MXJyCAksZpL4toGri5ELyN7IKPF8eSMr hHOVSeLYi/1MIFUsAqoSJ5ZvZgOx2QRUJBq6LzODDBIRMJJY/FwbpJ5ZYDqTxIeD09hB4sIC fhJTzoiBlPMC7Vp8uZcJYtkTRon+8yEQcUGJkzOfsIDYzALqEn/mXQIbySwgLbH8HwdEWF6i eetsZhCbU8BV4uiZFlYQW1RAWWJv3yH2CYyCs5BMmoVk0iyESbOQTFrAyLKKUTYlt0o3NzEz pzg1Wbc4OTEvL7VI10IvN7NELzWldBMjKALYXVR3MM7563WIUYCDUYmHN2L96mgh1sSy4src Q4ySHExKorwKe4FCfEn5KZUZicUZ8UWlOanFhxglOJiVRHjXbQfK8aYkVlalFuXDpKQ5WJTE eSe1LI4WEkhPLEnNTk0tSC2CycpwcChJ8B7jXxMtJFiUmp5akZaZU4KQZuLgBBnOAzScC5gw hHiLCxJzizPTIfKnGI05XszomMHMse1M5wxmIZa8/LxUKXFeNZBSAZDSjNI8uGmgJCaRvb/m FaM40HPCvEwgVTzABAg37xXQKiagVRN6VoCsKklESEk1MIZkaNREFvZx7oiWSf0RnugePeke +1mpy5tDz5S+S8kJiOTiOx1kqvr8a3TJnCRN/xOWoYumK3CbeT8tEeqVnL98Qfy5brfdG7Jy xY7qbNj+5ZhQ0oTf89mnP1dqfDplz8yTAsxnt1pmW1i7zjrdeTxpXbbZwxNxj05cnMAs+XI+ 1+XNCY/O7FBiKc5INNRiLipOBACJRRUzPQMAAA== Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-isis-segment-routing-msd-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2018 23:06:33 -0000 On Wed, Sep 26, 2018 at 10:59:50PM +0000, Les Ginsberg (ginsberg) wrote: > Benjamin - > > Responses nline. > > > -----Original Message----- > > From: Benjamin Kaduk > > Sent: Wednesday, September 26, 2018 2:11 PM > > To: Les Ginsberg (ginsberg) > > Cc: David Waltermire ; secdir@ietf.org; > > lsr@ietf.org; ietf@ietf.org; draft-ietf-isis-segment-routing-msd.all@ietf.org > > Subject: Re: Secdir last call review of draft-ietf-isis-segment-routing-msd-16 > > > > On Wed, Sep 26, 2018 at 08:45:03PM +0000, Les Ginsberg (ginsberg) wrote: > > > David - > > > > > > Thanx for the review. > > > A new version of the draft (17) has been published to address your > > comments - subject to my responses below. > > > > Just in time for me to see the updated version for my IESG review; thanks. > > > > > > -----Original Message----- > > > > From: David Waltermire > > > > Sent: Tuesday, September 25, 2018 12:14 PM > > > > To: secdir@ietf.org > > > > Cc: lsr@ietf.org; ietf@ietf.org; draft-ietf-isis-segment-routing- > > > > msd.all@ietf.org > > > > Subject: Secdir last call review of > > > > draft-ietf-isis-segment-routing-msd-16 > > > > > > > > Reviewer: David Waltermire > > > > Review result: Has Issues > > > > > > > > I have reviewed this document as part of the security directorate's > > > > ongoing effort to review all IETF documents being processed by the > > > > IESG. These comments were written primarily for the benefit of the > > > > security area directors. > > > > Document editors and WG chairs should treat these comments just > > > > like any other last call comments. > > > > > > > > The summary of the review is Ready with (minor) issues > > > > > > > > My apologies for the late review on this draft. Overall I found this > > > > document to be well-written, and concise. > > > > > > > > General Comments: > > > > > > > > This document uses a mix of case around RFC2119 language (e.g., MAY > > may). > > > > You should use text from RFC8174 to indicate that lowercase versions > > > > of the keywords are not normative, or adjust the case of the > > > > lowercase words to ensure there is no confusion. > > > > > > > [Les:] Section 1.2 does include the standard boilerplate for RFC > > 2119/RFC8174. > > > > > > I checked all the lower case uses of "may" and they are intentional. > > > There was one instance of "should" that I changed to uppercase. > > > > > > > Minor nit: There is some inconsistency in the use of "MSD-Type" (the > > > > value) and "MSD type" (the concept). Suggest cleaning this up. > > > > > > > [Les:] Done > > > > > > > Specific comments: > > > > > > > > Section 1: > > > > > > > > Para 1: s/to insure/to ensure/ > > > > > > [Les:] Done. > > > > > > > > > > > Section 4: > > > > > > > > The last paragraph establishes a requirement on the registration of > > > > an MSD Type to define what the absence of a given MSD Type means. > > > > This is an important requirement that must be addressed during > > > > registration of new MSD Types. IMHO, this requirement should be > > > > echoed in the registration information in section 6 to make sure it is not > > overlooked. > > > > > > > [Les:] I disagree. Section 6 is defining exactly what should go into the new > > IANA registry. > > > The definition of "absence" is something that will have to be provided in > > the documents which define new MSD-types, but that will NOT be captured > > in the registry so including this in Section 6 isn’t appropriate. > > > > I think a good way to think about this is as giving guidance to the Experts, that > > they should not approve registration requests that fail to provide this > > information along with the request. Guidance for the Experts is appropriate > > in the IANA Considerations section. > > (Also, my understanding is that IANA prefers to have a more explicit > > template for new registrations to follow, though I should not try to speak for > > them.) > > > > [Les:] The reason we use "experts" is because we know/expect them to be familiar with the documents which define the TLVs (unlike a "general IETF reader" whose familiarity with the subject matter may vary). > Repeating what is said in Section 4 in Section 6 only makes sense if you think the "expert" only reads IANA sections. Such a person would not be an expert IMO. :-) I suspect that the experts would prefer to receive a high proportion of requests that meet the criteria the experts are going to apply, rather than constantly telling people they need to go fix the same thing and come back. It's best practice to be clear about what is required for a successful registration. -Benjamin From nobody Wed Sep 26 16:24:55 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A3C130DC4; Wed, 26 Sep 2018 16:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.49 X-Spam-Level: X-Spam-Status: No, score=-14.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXLLEnp3ic_0; Wed, 26 Sep 2018 16:24:37 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 499AC130DCE; Wed, 26 Sep 2018 16:24:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30136; q=dns/txt; s=iport; t=1538004277; x=1539213877; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dS5eyhCWRTLDalgX2R8URlBBE6JpQ49EaHUynXOdJkE=; b=Fov/5zZuayAiwnEtkCNPohgC8nbSheuApbxbjusDrfEMmU8Bd1o5MG7a BN9kQnHCF2x9fTlU7e3+Ys5THU8zwRMrdAgaif0un39wBT/0V2XZfSU2J 5nxLnBd77XgmsBYvE7yy7qPIoTxkuGBYvzWpJU0GxJsdT5Hfdc8cVEkVc w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAADHFKxb/4UNJK1aDgsBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVGBF3dlfygKg2qIFYwwgg2WT4F6CyOESQIXg2YhNBg?= =?us-ascii?q?BAwEBAgEBAm0cDIU4AQEBAQIBIwo+DgUHBAIBBgIRBAEBKAMCAgIwFAkIAgQ?= =?us-ascii?q?OBQiDGoEdXAgPiCqbTYEuihEFinsXgUE/gRKDEoMbAQECAYF1H4JLglcCjWy?= =?us-ascii?q?Fd4kkCQKGQYliH4FGhFKHfoEei3uIbwIRFIElHTiBVXAVgyeCJReIWoUEOm8?= =?us-ascii?q?BjDCBHgEB?= X-IronPort-AV: E=Sophos;i="5.54,308,1534809600"; d="scan'208,217";a="457926589" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Sep 2018 23:24:33 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id w8QNOXXd001246 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Sep 2018 23:24:33 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 26 Sep 2018 18:24:32 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1395.000; Wed, 26 Sep 2018 18:24:32 -0500 From: "Les Ginsberg (ginsberg)" To: Benjamin Kaduk CC: David Waltermire , "secdir@ietf.org" , "lsr@ietf.org" , "ietf@ietf.org" , "draft-ietf-isis-segment-routing-msd.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-isis-segment-routing-msd-16 Thread-Index: AQHUVQPqnQ0QGOOP8EOqsf/gazaoC6UC9FjAgABwTwD//8fJ0IAAWG2A//+wjNA= Date: Wed, 26 Sep 2018 23:24:31 +0000 Message-ID: <31f78bd59e874b18b7ab5d91a7db4aa8@XCH-ALN-001.cisco.com> References: <153790283647.5258.15634056350853857580@ietfa.amsl.com> <20180926211104.GQ24695@kduck.kaduk.org> <149d5d345afc462f9c5e5770079aaf0e@XCH-ALN-001.cisco.com> <20180926230621.GW24695@kduck.kaduk.org> In-Reply-To: <20180926230621.GW24695@kduck.kaduk.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.8.175] Content-Type: multipart/alternative; boundary="_000_31f78bd59e874b18b7ab5d91a7db4aa8XCHALN001ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-isis-segment-routing-msd-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2018 23:24:40 -0000 --_000_31f78bd59e874b18b7ab5d91a7db4aa8XCHALN001ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QmVuamFtaW4gLQ0KDQoNCg0KUGxlYXNlIHJldmlldyBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjODEyNiNzZWN0aW9uLTEuMQ0KDQoNCg0KSW4gcGFydGljdWxhciAoZW1waGFzaXMgYWRk ZWQpOg0KDQoNCg0KIiBUaGUgcHVycG9zZSBvZiBoYXZpbmcgYSBkZWRpY2F0ZWQgSUFOQSBDb25z aWRlcmF0aW9ucyBzZWN0aW9uIGlzIHRvDQoNCiAgIHByb3ZpZGUgYSBzaW5nbGUgcGxhY2UgdG8g Y29sbGVjdCBjbGVhciBhbmQgY29uY2lzZSBpbmZvcm1hdGlvbiBhbmQNCg0KICAgaW5zdHJ1Y3Rp b25zIGZvciBJQU5BLiAgVGVjaG5pY2FsIGRvY3VtZW50YXRpb24gc2hvdWxkIHJlc2lkZSBpbg0K DQogICBvdGhlciBwYXJ0cyBvZiB0aGUgZG9jdW1lbnTigKbigJ0NCg0KDQoNCkkgdGhpbmsgd2hh dCB5b3UgcHJvcG9zZSBpcyBub3QgY29uc2lzdGVudCB3aXRoIHRoZSBpbnRlbnQgb2YgdGhlIElB TkEgc2VjdGlvbi4NCg0KDQoNClRoYW54Lg0KDQoNCg0KICAgIExlcw0KDQoNCg0KDQoNCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KPiBGcm9tOiBCZW5qYW1pbiBLYWR1ayA8a2FkdWtA bWl0LmVkdT4NCg0KPiBTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAyNiwgMjAxOCA0OjA2IFBN DQoNCj4gVG86IExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpIDxnaW5zYmVyZ0BjaXNjby5jb20+DQoN Cj4gQ2M6IERhdmlkIFdhbHRlcm1pcmUgPGRhdmlkLndhbHRlcm1pcmVAbmlzdC5nb3Y+OyBzZWNk aXJAaWV0Zi5vcmc7DQoNCj4gbHNyQGlldGYub3JnOyBpZXRmQGlldGYub3JnOyBkcmFmdC1pZXRm LWlzaXMtc2VnbWVudC1yb3V0aW5nLW1zZC5hbGxAaWV0Zi5vcmcNCg0KPiBTdWJqZWN0OiBSZTog U2VjZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1pc2lzLXNlZ21lbnQtcm91dGlu Zy1tc2QtMTYNCg0KPg0KDQo+IE9uIFdlZCwgU2VwIDI2LCAyMDE4IGF0IDEwOjU5OjUwUE0gKzAw MDAsIExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpIHdyb3RlOg0KDQo+ID4gQmVuamFtaW4gLQ0KDQo+ ID4NCg0KPiA+IFJlc3BvbnNlcyBubGluZS4NCg0KPiA+DQoNCj4gPiA+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQoNCj4gPiA+IEZyb206IEJlbmphbWluIEthZHVrIDxrYWR1a0BtaXQuZWR1 PG1haWx0bzprYWR1a0BtaXQuZWR1Pj4NCg0KPiA+ID4gU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1i ZXIgMjYsIDIwMTggMjoxMSBQTQ0KDQo+ID4gPiBUbzogTGVzIEdpbnNiZXJnIChnaW5zYmVyZykg PGdpbnNiZXJnQGNpc2NvLmNvbTxtYWlsdG86Z2luc2JlcmdAY2lzY28uY29tPj4NCg0KPiA+ID4g Q2M6IERhdmlkIFdhbHRlcm1pcmUgPGRhdmlkLndhbHRlcm1pcmVAbmlzdC5nb3Y8bWFpbHRvOmRh dmlkLndhbHRlcm1pcmVAbmlzdC5nb3Y+Pjsgc2VjZGlyQGlldGYub3JnPG1haWx0bzpzZWNkaXJA aWV0Zi5vcmc+Ow0KDQo+ID4gPiBsc3JAaWV0Zi5vcmc8bWFpbHRvOmxzckBpZXRmLm9yZz47IGll dGZAaWV0Zi5vcmc8bWFpbHRvOmlldGZAaWV0Zi5vcmc+Ow0KDQo+ID4gPiBkcmFmdC1pZXRmLWlz aXMtc2VnbWVudC1yb3V0aW5nLW1zZC5hbGxAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtaXNp cy1zZWdtZW50LXJvdXRpbmctbXNkLmFsbEBpZXRmLm9yZz4NCg0KPiA+ID4gU3ViamVjdDogUmU6 IFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mDQoNCj4gPiA+IGRyYWZ0LWlldGYtaXNpcy1zZWdt ZW50LXJvdXRpbmctbXNkLTE2DQoNCj4gPiA+DQoNCj4gPiA+IE9uIFdlZCwgU2VwIDI2LCAyMDE4 IGF0IDA4OjQ1OjAzUE0gKzAwMDAsIExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpDQoNCj4gd3JvdGU6 DQoNCj4gPiA+ID4gRGF2aWQgLQ0KDQo+ID4gPiA+DQoNCj4gPiA+ID4gVGhhbnggZm9yIHRoZSBy ZXZpZXcuDQoNCj4gPiA+ID4gQSBuZXcgdmVyc2lvbiBvZiB0aGUgZHJhZnQgKDE3KSBoYXMgYmVl biBwdWJsaXNoZWQgdG8gYWRkcmVzcyB5b3VyDQoNCj4gPiA+IGNvbW1lbnRzIC0gc3ViamVjdCB0 byBteSByZXNwb25zZXMgYmVsb3cuDQoNCj4gPiA+DQoNCj4gPiA+IEp1c3QgaW4gdGltZSBmb3Ig bWUgdG8gc2VlIHRoZSB1cGRhdGVkIHZlcnNpb24gZm9yIG15IElFU0cgcmV2aWV3Ow0KDQo+IHRo YW5rcy4NCg0KPiA+ID4NCg0KPiA+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoN Cj4gPiA+ID4gPiBGcm9tOiBEYXZpZCBXYWx0ZXJtaXJlIDxkYXZpZC53YWx0ZXJtaXJlQG5pc3Qu Z292PG1haWx0bzpkYXZpZC53YWx0ZXJtaXJlQG5pc3QuZ292Pj4NCg0KPiA+ID4gPiA+IFNlbnQ6 IFR1ZXNkYXksIFNlcHRlbWJlciAyNSwgMjAxOCAxMjoxNCBQTQ0KDQo+ID4gPiA+ID4gVG86IHNl Y2RpckBpZXRmLm9yZzxtYWlsdG86c2VjZGlyQGlldGYub3JnPg0KDQo+ID4gPiA+ID4gQ2M6IGxz ckBpZXRmLm9yZzxtYWlsdG86bHNyQGlldGYub3JnPjsgaWV0ZkBpZXRmLm9yZzxtYWlsdG86aWV0 ZkBpZXRmLm9yZz47DQoNCj4gPiA+ID4gPiBkcmFmdC1pZXRmLWlzaXMtc2VnbWVudC1yb3V0aW5n LSBtc2QuYWxsQGlldGYub3JnPG1haWx0bzptc2QuYWxsQGlldGYub3JnPg0KDQo+ID4gPiA+ID4g U3ViamVjdDogU2VjZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YNCg0KPiA+ID4gPiA+IGRyYWZ0LWll dGYtaXNpcy1zZWdtZW50LXJvdXRpbmctbXNkLTE2DQoNCj4gPiA+ID4gPg0KDQo+ID4gPiA+ID4g UmV2aWV3ZXI6IERhdmlkIFdhbHRlcm1pcmUNCg0KPiA+ID4gPiA+IFJldmlldyByZXN1bHQ6IEhh cyBJc3N1ZXMNCg0KPiA+ID4gPiA+DQoNCj4gPiA+ID4gPiBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBk b2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eQ0KDQo+ID4gPiA+ID4gZGlyZWN0b3JhdGUn cyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nDQoNCj4g PiA+ID4gPiBwcm9jZXNzZWQgYnkgdGhlIElFU0cuICBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0 ZW4gcHJpbWFyaWx5DQoNCj4gPiA+ID4gPiBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5 IGFyZWEgZGlyZWN0b3JzLg0KDQo+ID4gPiA+ID4gIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNo YWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdA0KDQo+ID4gPiA+ID4gbGlrZSBh bnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQo+ID4gPiA+ID4NCg0KPiA+ID4gPiA+IFRo ZSBzdW1tYXJ5IG9mIHRoZSByZXZpZXcgaXMgUmVhZHkgd2l0aCAobWlub3IpIGlzc3Vlcw0KDQo+ ID4gPiA+ID4NCg0KPiA+ID4gPiA+IE15IGFwb2xvZ2llcyBmb3IgdGhlIGxhdGUgcmV2aWV3IG9u IHRoaXMgZHJhZnQuIE92ZXJhbGwgSSBmb3VuZA0KDQo+ID4gPiA+ID4gdGhpcyBkb2N1bWVudCB0 byBiZSB3ZWxsLXdyaXR0ZW4sIGFuZCBjb25jaXNlLg0KDQo+ID4gPiA+ID4NCg0KPiA+ID4gPiA+ IEdlbmVyYWwgQ29tbWVudHM6DQoNCj4gPiA+ID4gPg0KDQo+ID4gPiA+ID4gVGhpcyBkb2N1bWVu dCB1c2VzIGEgbWl4IG9mIGNhc2UgYXJvdW5kIFJGQzIxMTkgbGFuZ3VhZ2UgKGUuZy4sDQoNCj4g PiA+ID4gPiBNQVkNCg0KPiA+ID4gbWF5KS4NCg0KPiA+ID4gPiA+IFlvdSBzaG91bGQgdXNlIHRl eHQgZnJvbSBSRkM4MTc0IHRvIGluZGljYXRlIHRoYXQgbG93ZXJjYXNlDQoNCj4gPiA+ID4gPiB2 ZXJzaW9ucyBvZiB0aGUga2V5d29yZHMgYXJlIG5vdCBub3JtYXRpdmUsIG9yIGFkanVzdCB0aGUg Y2FzZQ0KDQo+ID4gPiA+ID4gb2YgdGhlIGxvd2VyY2FzZSB3b3JkcyB0byBlbnN1cmUgdGhlcmUg aXMgbm8gY29uZnVzaW9uLg0KDQo+ID4gPiA+ID4NCg0KPiA+ID4gPiBbTGVzOl0gU2VjdGlvbiAx LjIgZG9lcyBpbmNsdWRlIHRoZSBzdGFuZGFyZCBib2lsZXJwbGF0ZSBmb3IgUkZDDQoNCj4gPiA+ IDIxMTkvUkZDODE3NC4NCg0KPiA+ID4gPg0KDQo+ID4gPiA+IEkgY2hlY2tlZCBhbGwgdGhlIGxv d2VyIGNhc2UgdXNlcyBvZiAibWF5IiBhbmQgdGhleSBhcmUgaW50ZW50aW9uYWwuDQoNCj4gPiA+ ID4gVGhlcmUgd2FzIG9uZSBpbnN0YW5jZSBvZiAic2hvdWxkIiB0aGF0IEkgY2hhbmdlZCB0byB1 cHBlcmNhc2UuDQoNCj4gPiA+ID4NCg0KPiA+ID4gPiA+IE1pbm9yIG5pdDogVGhlcmUgaXMgc29t ZSBpbmNvbnNpc3RlbmN5IGluIHRoZSB1c2Ugb2YgIk1TRC1UeXBlIg0KDQo+ID4gPiA+ID4gKHRo ZQ0KDQo+ID4gPiA+ID4gdmFsdWUpIGFuZCAiTVNEIHR5cGUiICh0aGUgY29uY2VwdCkuIFN1Z2dl c3QgY2xlYW5pbmcgdGhpcyB1cC4NCg0KPiA+ID4gPiA+DQoNCj4gPiA+ID4gW0xlczpdIERvbmUN Cg0KPiA+ID4gPg0KDQo+ID4gPiA+ID4gU3BlY2lmaWMgY29tbWVudHM6DQoNCj4gPiA+ID4gPg0K DQo+ID4gPiA+ID4gU2VjdGlvbiAxOg0KDQo+ID4gPiA+ID4NCg0KPiA+ID4gPiA+IFBhcmEgMTog cy90byBpbnN1cmUvdG8gZW5zdXJlLw0KDQo+ID4gPiA+DQoNCj4gPiA+ID4gW0xlczpdIERvbmUu DQoNCj4gPiA+ID4NCg0KPiA+ID4gPiA+DQoNCj4gPiA+ID4gPiBTZWN0aW9uIDQ6DQoNCj4gPiA+ ID4gPg0KDQo+ID4gPiA+ID4gVGhlIGxhc3QgcGFyYWdyYXBoIGVzdGFibGlzaGVzIGEgcmVxdWly ZW1lbnQgb24gdGhlIHJlZ2lzdHJhdGlvbg0KDQo+ID4gPiA+ID4gb2YgYW4gTVNEIFR5cGUgdG8g ZGVmaW5lIHdoYXQgdGhlIGFic2VuY2Ugb2YgYSBnaXZlbiBNU0QgVHlwZQ0KDQo+IG1lYW5zLg0K DQo+ID4gPiA+ID4gVGhpcyBpcyBhbiBpbXBvcnRhbnQgcmVxdWlyZW1lbnQgdGhhdCBtdXN0IGJl IGFkZHJlc3NlZCBkdXJpbmcNCg0KPiA+ID4gPiA+IHJlZ2lzdHJhdGlvbiBvZiBuZXcgTVNEIFR5 cGVzLiBJTUhPLCB0aGlzIHJlcXVpcmVtZW50IHNob3VsZCBiZQ0KDQo+ID4gPiA+ID4gZWNob2Vk IGluIHRoZSByZWdpc3RyYXRpb24gaW5mb3JtYXRpb24gaW4gc2VjdGlvbiA2IHRvIG1ha2Ugc3Vy ZQ0KDQo+ID4gPiA+ID4gaXQgaXMgbm90DQoNCj4gPiA+IG92ZXJsb29rZWQuDQoNCj4gPiA+ID4g Pg0KDQo+ID4gPiA+IFtMZXM6XSBJIGRpc2FncmVlLiBTZWN0aW9uIDYgaXMgZGVmaW5pbmcgZXhh Y3RseSB3aGF0IHNob3VsZCBnbw0KDQo+ID4gPiA+IGludG8gdGhlIG5ldw0KDQo+ID4gPiBJQU5B IHJlZ2lzdHJ5Lg0KDQo+ID4gPiA+IFRoZSBkZWZpbml0aW9uIG9mICJhYnNlbmNlIiBpcyBzb21l dGhpbmcgdGhhdCB3aWxsIGhhdmUgdG8gYmUNCg0KPiA+ID4gPiBwcm92aWRlZCBpbg0KDQo+ID4g PiB0aGUgZG9jdW1lbnRzIHdoaWNoIGRlZmluZSBuZXcgTVNELXR5cGVzLCBidXQgdGhhdCB3aWxs IE5PVCBiZQ0KDQo+ID4gPiBjYXB0dXJlZCBpbiB0aGUgcmVnaXN0cnkgc28gaW5jbHVkaW5nIHRo aXMgaW4gU2VjdGlvbiA2IGlzbuKAmXQgYXBwcm9wcmlhdGUuDQoNCj4gPiA+DQoNCj4gPiA+IEkg dGhpbmsgYSBnb29kIHdheSB0byB0aGluayBhYm91dCB0aGlzIGlzIGFzIGdpdmluZyBndWlkYW5j ZSB0byB0aGUNCg0KPiA+ID4gRXhwZXJ0cywgdGhhdCB0aGV5IHNob3VsZCBub3QgYXBwcm92ZSBy ZWdpc3RyYXRpb24gcmVxdWVzdHMgdGhhdA0KDQo+ID4gPiBmYWlsIHRvIHByb3ZpZGUgdGhpcyBp bmZvcm1hdGlvbiBhbG9uZyB3aXRoIHRoZSByZXF1ZXN0LiAgR3VpZGFuY2UNCg0KPiA+ID4gZm9y IHRoZSBFeHBlcnRzIGlzIGFwcHJvcHJpYXRlIGluIHRoZSBJQU5BIENvbnNpZGVyYXRpb25zIHNl Y3Rpb24uDQoNCj4gPiA+IChBbHNvLCBteSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgSUFOQSBwcmVm ZXJzIHRvIGhhdmUgYSBtb3JlIGV4cGxpY2l0DQoNCj4gPiA+IHRlbXBsYXRlIGZvciBuZXcgcmVn aXN0cmF0aW9ucyB0byBmb2xsb3csIHRob3VnaCBJIHNob3VsZCBub3QgdHJ5IHRvDQoNCj4gPiA+ IHNwZWFrIGZvcg0KDQo+ID4gPiB0aGVtLikNCg0KPiA+ID4NCg0KPiA+DQoNCj4gPiBbTGVzOl0g VGhlIHJlYXNvbiB3ZSB1c2UgImV4cGVydHMiIGlzIGJlY2F1c2Ugd2Uga25vdy9leHBlY3QgdGhl bSB0byBiZQ0KDQo+IGZhbWlsaWFyIHdpdGggdGhlIGRvY3VtZW50cyB3aGljaCBkZWZpbmUgdGhl IFRMVnMgKHVubGlrZSBhICJnZW5lcmFsIElFVEYNCg0KPiByZWFkZXIiIHdob3NlIGZhbWlsaWFy aXR5IHdpdGggdGhlIHN1YmplY3QgbWF0dGVyIG1heSB2YXJ5KS4NCg0KPiA+IFJlcGVhdGluZyB3 aGF0IGlzIHNhaWQgaW4gU2VjdGlvbiA0IGluIFNlY3Rpb24gNiBvbmx5IG1ha2VzIHNlbnNlIGlm DQoNCj4gPiB5b3UgdGhpbmsgdGhlICJleHBlcnQiIG9ubHkgcmVhZHMgSUFOQSBzZWN0aW9ucy4g U3VjaCBhIHBlcnNvbiB3b3VsZA0KDQo+ID4gbm90IGJlIGFuIGV4cGVydCBJTU8uIDotKQ0KDQo+ DQoNCj4gSSBzdXNwZWN0IHRoYXQgdGhlIGV4cGVydHMgd291bGQgcHJlZmVyIHRvIHJlY2VpdmUg YSBoaWdoIHByb3BvcnRpb24gb2YNCg0KPiByZXF1ZXN0cyB0aGF0IG1lZXQgdGhlIGNyaXRlcmlh IHRoZSBleHBlcnRzIGFyZSBnb2luZyB0byBhcHBseSwgcmF0aGVyIHRoYW4NCg0KPiBjb25zdGFu dGx5IHRlbGxpbmcgcGVvcGxlIHRoZXkgbmVlZCB0byBnbyBmaXggdGhlIHNhbWUgdGhpbmcgYW5k IGNvbWUgYmFjay4NCg0KPiBJdCdzIGJlc3QgcHJhY3RpY2UgdG8gYmUgY2xlYXIgYWJvdXQgd2hh dCBpcyByZXF1aXJlZCBmb3IgYSBzdWNjZXNzZnVsDQoNCj4gcmVnaXN0cmF0aW9uLg0KDQo+DQoN Cj4gLUJlbmphbWluDQo= --_000_31f78bd59e874b18b7ab5d91a7db4aa8XCHALN001ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNv UGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxh aW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMTI5Ljc1cHQgMS4waW4gMTI5LjdwdDt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5CZW5qYW1pbiAtPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPlBsZWFzZSByZXZpZXcgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzgxMjYjc2VjdGlvbi0xLjEiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzgxMjYjc2VjdGlvbi0xLjE8L2E+IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5J biBwYXJ0aWN1bGFyIChlbXBoYXNpcyBhZGRlZCk6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZxdW90OyBUaGUgcHVycG9zZSBvZiBoYXZpbmcgYSBkZWRpY2F0ZWQgSUFOQSBDb25zaWRl cmF0aW9ucyBzZWN0aW9uIGlzIHRvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDsmbmJzcDsgcHJvdmlkZSBhIHNpbmdsZSBwbGFjZSB0byBjb2xsZWN0IGNsZWFy IGFuZCBjb25jaXNlIGluZm9ybWF0aW9uIGFuZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IGluc3RydWN0aW9ucyBmb3IgSUFOQS4mbmJzcDsgPGI+ VGVjaG5pY2FsIGRvY3VtZW50YXRpb24gc2hvdWxkIHJlc2lkZSBpbjxvOnA+PC9vOnA+PC9iPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxiPiZuYnNwOyZuYnNwOyBvdGhlciBwYXJ0cyBv ZiB0aGUgZG9jdW1lbnTigKbigJ08bzpwPjwvbzpwPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48Yj48bzpwPiZuYnNwOzwvbzpwPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij5JIHRoaW5rIHdoYXQgeW91IHByb3Bvc2UgaXMgbm90IGNvbnNpc3RlbnQgd2l0aCB0aGUg aW50ZW50IG9mIHRoZSBJQU5BIHNlY3Rpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PlRoYW54LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsg TGVzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgRnJvbTogQmVuamFtaW4gS2FkdWsgJmx0 O2thZHVrQG1pdC5lZHUmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBTZW50 OiBXZWRuZXNkYXksIFNlcHRlbWJlciAyNiwgMjAxOCA0OjA2IFBNPC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyBUbzogTGVzIEdpbnNiZXJnIChnaW5zYmVyZykgJmx0O2dpbnNiZXJn QGNpc2NvLmNvbSZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IENjOiBEYXZp ZCBXYWx0ZXJtaXJlICZsdDtkYXZpZC53YWx0ZXJtaXJlQG5pc3QuZ292Jmd0Ozsgc2VjZGlyQGll dGYub3JnOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgbHNyQGlldGYub3JnOyBp ZXRmQGlldGYub3JnOyBkcmFmdC1pZXRmLWlzaXMtc2VnbWVudC1yb3V0aW5nLW1zZC5hbGxAaWV0 Zi5vcmc8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFN1YmplY3Q6IFJlOiBTZWNk aXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWlzaXMtc2VnbWVudC1yb3V0aW5nLW1z ZC0xNjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyBPbiBXZWQsIFNlcCAyNiwgMjAxOCBhdCAxMDo1OTo1MFBNICYjNDM7 MDAwMCwgTGVzIEdpbnNiZXJnIChnaW5zYmVyZykgd3JvdGU6PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAmZ3Q7IEJlbmphbWluIC08L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgUmVzcG9u c2VzIG5saW5lLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsgRnJvbTog QmVuamFtaW4gS2FkdWsgJmx0OzxhIGhyZWY9Im1haWx0bzprYWR1a0BtaXQuZWR1Ij48c3BhbiBz dHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+a2FkdWtAbWl0LmVk dTwvc3Bhbj48L2E+Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAm Z3Q7IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDI2LCAyMDE4IDI6MTEgUE08L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyBUbzogTGVzIEdpbnNiZXJnIChnaW5z YmVyZykgJmx0OzxhIGhyZWY9Im1haWx0bzpnaW5zYmVyZ0BjaXNjby5jb20iPjxzcGFuIHN0eWxl PSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5naW5zYmVyZ0BjaXNjby5j b208L3NwYW4+PC9hPiZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsg Jmd0OyBDYzogRGF2aWQgV2FsdGVybWlyZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRhdmlkLndhbHRl cm1pcmVAbmlzdC5nb3YiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3Jh dGlvbjpub25lIj5kYXZpZC53YWx0ZXJtaXJlQG5pc3QuZ292PC9zcGFuPjwvYT4mZ3Q7Ow0KPGEg aHJlZj0ibWFpbHRvOnNlY2RpckBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3Rl eHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPnNlY2RpckBpZXRmLm9yZzwvc3Bhbj48L2E+OzwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzps c3JAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlv bjpub25lIj5sc3JAaWV0Zi5vcmc8L3NwYW4+PC9hPjsNCjxhIGhyZWY9Im1haWx0bzppZXRmQGll dGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9u ZSI+aWV0ZkBpZXRmLm9yZzwvc3Bhbj48L2E+OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWlzaXMtc2VnbWVudC1y b3V0aW5nLW1zZC5hbGxAaWV0Zi5vcmciPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7 dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmRyYWZ0LWlldGYtaXNpcy1zZWdtZW50LXJvdXRpbmctbXNk LmFsbEBpZXRmLm9yZzwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmZ3Q7ICZndDsgU3ViamVjdDogUmU6IFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mPC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsgZHJhZnQtaWV0Zi1pc2lzLXNl Z21lbnQtcm91dGluZy1tc2QtMTY8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn dDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7IE9uIFdl ZCwgU2VwIDI2LCAyMDE4IGF0IDA4OjQ1OjAzUE0gJiM0MzswMDAwLCBMZXMgR2luc2JlcmcgKGdp bnNiZXJnKTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgd3JvdGU6PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBEYXZpZCAtPC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7ICZndDsgVGhhbnggZm9yIHRoZSByZXZpZXcuPC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBBIG5ldyB2ZXJz aW9uIG9mIHRoZSBkcmFmdCAoMTcpIGhhcyBiZWVuIHB1Ymxpc2hlZCB0byBhZGRyZXNzIHlvdXI8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyBjb21tZW50cyAtIHN1 YmplY3QgdG8gbXkgcmVzcG9uc2VzIGJlbG93LjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OyAmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZn dDsgSnVzdCBpbiB0aW1lIGZvciBtZSB0byBzZWUgdGhlIHVwZGF0ZWQgdmVyc2lvbiBmb3IgbXkg SUVTRyByZXZpZXc7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB0aGFua3MuPC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS08L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZndDsgRnJvbTogRGF2aWQgV2FsdGVybWlyZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRhdmlkLndh bHRlcm1pcmVAbmlzdC5nb3YiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVj b3JhdGlvbjpub25lIj5kYXZpZC53YWx0ZXJtaXJlQG5pc3QuZ292PC9zcGFuPjwvYT4mZ3Q7PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IFNlbnQ6 IFR1ZXNkYXksIFNlcHRlbWJlciAyNSwgMjAxOCAxMjoxNCBQTTwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBUbzogPGEgaHJlZj0ibWFpbHRvOnNl Y2RpckBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0 aW9uOm5vbmUiPnNlY2RpckBpZXRmLm9yZzwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IENjOiA8YSBocmVmPSJtYWlsdG86bHNy QGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246 bm9uZSI+bHNyQGlldGYub3JnPC9zcGFuPjwvYT47DQo8YSBocmVmPSJtYWlsdG86aWV0ZkBpZXRm Lm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUi PmlldGZAaWV0Zi5vcmc8L3NwYW4+PC9hPjs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgZHJhZnQtaWV0Zi1pc2lzLXNlZ21lbnQtcm91dGluZy0g PGEgaHJlZj0ibWFpbHRvOm1zZC5hbGxAaWV0Zi5vcmciPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndp bmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPm1zZC5hbGxAaWV0Zi5vcmc8L3NwYW4+PC9h PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBT dWJqZWN0OiBTZWNkaXIgbGFzdCBjYWxsIHJldmlldyBvZjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBkcmFmdC1pZXRmLWlzaXMtc2VnbWVudC1y b3V0aW5nLW1zZC0xNjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7 ICZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyBSZXZpZXdlcjogRGF2aWQgV2FsdGVybWlyZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBSZXZpZXcgcmVzdWx0OiBIYXMgSXNzdWVz PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IEkgaGF2 ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGRpcmVjdG9yYXRl J3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZzwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBwcm9jZXNz ZWQgYnkgdGhlIElFU0cuJm5ic3A7IFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJp bHk8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg Zm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBhcmVhIGRpcmVjdG9ycy48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgRG9jdW1l bnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0 PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGxp a2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgVGhlIHN1bW1hcnkgb2YgdGhlIHJldmlldyBpcyBS ZWFkeSB3aXRoIChtaW5vcikgaXNzdWVzPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAm Z3Q7ICZndDsgJmd0OyAmZ3Q7IE15IGFwb2xvZ2llcyBmb3IgdGhlIGxhdGUgcmV2aWV3IG9uIHRo aXMgZHJhZnQuIE92ZXJhbGwgSSBmb3VuZDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGlzIGRvY3VtZW50IHRvIGJlIHdlbGwtd3JpdHRlbiwg YW5kIGNvbmNpc2UuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7IEdlbmVyYWwgQ29tbWVudHM6PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAm Z3Q7ICZndDsgJmd0OyAmZ3Q7IFRoaXMgZG9jdW1lbnQgdXNlcyBhIG1peCBvZiBjYXNlIGFyb3Vu ZCBSRkMyMTE5IGxhbmd1YWdlIChlLmcuLDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBNQVk8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsgJmd0OyBtYXkpLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0 OyAmZ3Q7ICZndDsgJmd0OyBZb3Ugc2hvdWxkIHVzZSB0ZXh0IGZyb20gUkZDODE3NCB0byBpbmRp Y2F0ZSB0aGF0IGxvd2VyY2FzZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0 OyAmZ3Q7ICZndDsgJmd0OyB2ZXJzaW9ucyBvZiB0aGUga2V5d29yZHMgYXJlIG5vdCBub3JtYXRp dmUsIG9yIGFkanVzdCB0aGUgY2FzZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OyAmZ3Q7ICZndDsgJmd0OyBvZiB0aGUgbG93ZXJjYXNlIHdvcmRzIHRvIGVuc3VyZSB0aGVy ZSBpcyBubyBjb25mdXNpb24uPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7 ICZndDsgJmd0OyAmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZn dDsgJmd0OyBbTGVzOl0gU2VjdGlvbiAxLjIgZG9lcyBpbmNsdWRlIHRoZSBzdGFuZGFyZCBib2ls ZXJwbGF0ZSBmb3IgUkZDPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZn dDsgMjExOS9SRkM4MTc0LjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAm Z3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 IEkgY2hlY2tlZCBhbGwgdGhlIGxvd2VyIGNhc2UgdXNlcyBvZiAmcXVvdDttYXkmcXVvdDsgYW5k IHRoZXkgYXJlIGludGVudGlvbmFsLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OyAmZ3Q7ICZndDsgVGhlcmUgd2FzIG9uZSBpbnN0YW5jZSBvZiAmcXVvdDtzaG91bGQmcXVv dDsgdGhhdCBJIGNoYW5nZWQgdG8gdXBwZXJjYXNlLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJmd0OyAmZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDsgTWlub3Igbml0OiBUaGVyZSBpcyBzb21lIGluY29uc2lzdGVu Y3kgaW4gdGhlIHVzZSBvZiAmcXVvdDtNU0QtVHlwZSZxdW90OzwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAodGhlPC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHZhbHVlKSBhbmQgJnF1b3Q7TVNE IHR5cGUmcXVvdDsgKHRoZSBjb25jZXB0KS4gU3VnZ2VzdCBjbGVhbmluZyB0aGlzIHVwLjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OzwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7ICZndDsgW0xlczpdIERvbmU8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IFNwZWNpZmljIGNvbW1l bnRzOjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0 OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBT ZWN0aW9uIDE6PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAm Z3Q7IFBhcmEgMTogcy90byBpbnN1cmUvdG8gZW5zdXJlLzwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyAmZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsgJmd0OyAmZ3Q7IFtMZXM6XSBEb25lLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJmd0OyAmZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZndDsgU2VjdGlvbiA0OjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGUgbGFzdCBwYXJhZ3JhcGggZXN0YWJsaXNoZXMgYSBy ZXF1aXJlbWVudCBvbiB0aGUgcmVnaXN0cmF0aW9uPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IG9mIGFuIE1TRCBUeXBlIHRvIGRlZmluZSB3aGF0 IHRoZSBhYnNlbmNlIG9mIGEgZ2l2ZW4gTVNEIFR5cGU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7IG1lYW5zLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAm Z3Q7ICZndDsgJmd0OyBUaGlzIGlzIGFuIGltcG9ydGFudCByZXF1aXJlbWVudCB0aGF0IG11c3Qg YmUgYWRkcmVzc2VkIGR1cmluZzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0 OyAmZ3Q7ICZndDsgJmd0OyByZWdpc3RyYXRpb24gb2YgbmV3IE1TRCBUeXBlcy4gSU1ITywgdGhp cyByZXF1aXJlbWVudCBzaG91bGQgYmU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDsgZWNob2VkIGluIHRoZSByZWdpc3RyYXRpb24gaW5mb3JtYXRp b24gaW4gc2VjdGlvbiA2IHRvIG1ha2Ugc3VyZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBpdCBpcyBub3Q8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyBvdmVybG9va2VkLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJmd0OyAmZ3Q7ICZndDsgW0xlczpdIEkgZGlzYWdyZWUuIFNlY3Rpb24gNiBpcyBk ZWZpbmluZyBleGFjdGx5IHdoYXQgc2hvdWxkIGdvPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBpbnRvIHRoZSBuZXc8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyBJQU5BIHJlZ2lzdHJ5LjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7ICZndDsgVGhlIGRlZmluaXRpb24gb2YgJnF1b3Q7YWJz ZW5jZSZxdW90OyBpcyBzb21ldGhpbmcgdGhhdCB3aWxsIGhhdmUgdG8gYmU8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IHByb3ZpZGVkIGluPC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsgdGhlIGRvY3VtZW50cyB3aGljaCBk ZWZpbmUgbmV3IE1TRC10eXBlcywgYnV0IHRoYXQgd2lsbCBOT1QgYmU8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyBjYXB0dXJlZCBpbiB0aGUgcmVnaXN0cnkgc28g aW5jbHVkaW5nIHRoaXMgaW4gU2VjdGlvbiA2IGlzbuKAmXQgYXBwcm9wcmlhdGUuPC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyBJIHRoaW5rIGEgZ29vZCB3YXkgdG8gdGhpbmsgYWJvdXQg dGhpcyBpcyBhcyBnaXZpbmcgZ3VpZGFuY2UgdG8gdGhlPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmZ3Q7ICZndDsgRXhwZXJ0cywgdGhhdCB0aGV5IHNob3VsZCBub3QgYXBwcm92 ZSByZWdpc3RyYXRpb24gcmVxdWVzdHMgdGhhdDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OyAmZ3Q7IGZhaWwgdG8gcHJvdmlkZSB0aGlzIGluZm9ybWF0aW9uIGFsb25nIHdp dGggdGhlIHJlcXVlc3QuJm5ic3A7IEd1aWRhbmNlPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7ICZndDsgZm9yIHRoZSBFeHBlcnRzIGlzIGFwcHJvcHJpYXRlIGluIHRoZSBJ QU5BIENvbnNpZGVyYXRpb25zIHNlY3Rpb24uPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyAmZ3Q7ICZndDsgKEFsc28sIG15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBJQU5BIHByZWZl cnMgdG8gaGF2ZSBhIG1vcmUgZXhwbGljaXQ8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsgJmd0OyB0ZW1wbGF0ZSBmb3IgbmV3IHJlZ2lzdHJhdGlvbnMgdG8gZm9sbG93LCB0 aG91Z2ggSSBzaG91bGQgbm90IHRyeSB0bzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJmd0OyAmZ3Q7IHNwZWFrIGZvcjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OyAmZ3Q7IHRoZW0uKTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAm Z3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IFtMZXM6XSBUaGUgcmVhc29uIHdlIHVzZSAmcXVvdDtl eHBlcnRzJnF1b3Q7IGlzIGJlY2F1c2Ugd2Uga25vdy9leHBlY3QgdGhlbSB0byBiZTwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgZmFtaWxpYXIgd2l0aCB0aGUgZG9jdW1lbnRzIHdo aWNoIGRlZmluZSB0aGUgVExWcyAodW5saWtlIGEgJnF1b3Q7Z2VuZXJhbCBJRVRGPC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyByZWFkZXImcXVvdDsgd2hvc2UgZmFtaWxpYXJpdHkg d2l0aCB0aGUgc3ViamVjdCBtYXR0ZXIgbWF5IHZhcnkpLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyBSZXBlYXRpbmcgd2hhdCBpcyBzYWlkIGluIFNlY3Rpb24gNCBpbiBT ZWN0aW9uIDYgb25seSBtYWtlcyBzZW5zZSBpZjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OyB5b3UgdGhpbmsgdGhlICZxdW90O2V4cGVydCZxdW90OyBvbmx5IHJlYWRzIElB TkEgc2VjdGlvbnMuIFN1Y2ggYSBwZXJzb24gd291bGQ8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7ICZndDsgbm90IGJlIGFuIGV4cGVydCBJTU8uIDotKTwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBJIHN1 c3BlY3QgdGhhdCB0aGUgZXhwZXJ0cyB3b3VsZCBwcmVmZXIgdG8gcmVjZWl2ZSBhIGhpZ2ggcHJv cG9ydGlvbiBvZjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgcmVxdWVzdHMgdGhh dCBtZWV0IHRoZSBjcml0ZXJpYSB0aGUgZXhwZXJ0cyBhcmUgZ29pbmcgdG8gYXBwbHksIHJhdGhl ciB0aGFuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBjb25zdGFudGx5IHRlbGxp bmcgcGVvcGxlIHRoZXkgbmVlZCB0byBnbyBmaXggdGhlIHNhbWUgdGhpbmcgYW5kIGNvbWUgYmFj ay48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IEl0J3MgYmVzdCBwcmFjdGljZSB0 byBiZSBjbGVhciBhYm91dCB3aGF0IGlzIHJlcXVpcmVkIGZvciBhIHN1Y2Nlc3NmdWw8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHJlZ2lzdHJhdGlvbi48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7IDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgLUJl bmphbWluPC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_31f78bd59e874b18b7ab5d91a7db4aa8XCHALN001ciscocom_-- From nobody Wed Sep 26 18:21:17 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739CB12777C; Wed, 26 Sep 2018 18:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o_i-MWVSv6rG; Wed, 26 Sep 2018 18:21:02 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 CA03A130D7A; Wed, 26 Sep 2018 18:21:01 -0700 (PDT) X-AuditID: 12074423-40dff70000005232-61-5bac307bd9b9 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id A4.60.21042.B703CAB5; Wed, 26 Sep 2018 21:21:00 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w8R1KvvF020482; Wed, 26 Sep 2018 21:20:57 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w8R1Kq3X022058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 26 Sep 2018 21:20:54 -0400 Date: Wed, 26 Sep 2018 20:20:52 -0500 From: Benjamin Kaduk To: "Les Ginsberg (ginsberg)" Cc: David Waltermire , "secdir@ietf.org" , "lsr@ietf.org" , "ietf@ietf.org" , "draft-ietf-isis-segment-routing-msd.all@ietf.org" Message-ID: <20180927012051.GX24695@kduck.kaduk.org> References: <153790283647.5258.15634056350853857580@ietfa.amsl.com> <20180926211104.GQ24695@kduck.kaduk.org> <149d5d345afc462f9c5e5770079aaf0e@XCH-ALN-001.cisco.com> <20180926230621.GW24695@kduck.kaduk.org> <31f78bd59e874b18b7ab5d91a7db4aa8@XCH-ALN-001.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <31f78bd59e874b18b7ab5d91a7db4aa8@XCH-ALN-001.cisco.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCKsWRmVeSWpSXmKPExsUixCmqrVtjsCbaYN4nNouNPf/YLL6vV7TY 8Gcju8WzjfNZLE48WcFq8WHhQxYHNo8pvzeyeixZ8pPJ49rJv6wBzFFcNimpOZllqUX6dglc GWdObmct2MhRseb1H5YGxi1sXYwcHBICJhK/P3t2MXJxCAksZpKYMu8xC4SzkVHi1PIt7BDO VSaJxfefsYB0sAioSixaVdXFyMnBJqAi0dB9mRkkLCJgJLH4uTZIObPAdCaJDwensYPEhQX8 JKacEQMp5wXa1XZ3NjPEyFNMEi+vTGCESAhKnJz5hAXEZhZQl/gz7xLYTGYBaYnl/zggwvIS zVtng4U5BVwlnp2xAwmLCihL7O07xD6BUXAWkkGzkAyahTBoFpJBCxhZVjHKpuRW6eYmZuYU pybrFicn5uWlFuma6eVmluilppRuYgRFALuL8g7Gl33ehxgFOBiVeHgj1q+OFmJNLCuuzD3E KMnBpCTKq7AXKMSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmEN1dxTbQQb0piZVVqUT5MSpqDRUmc d2LL4mghgfTEktTs1NSC1CKYrAwHh5IEb7A+UKNgUWp6akVaZk4JQpqJgxNkOA/Q8H0gNbzF BYm5xZnpEPlTjLocL2Z0zGAWYsnLz0uVEufNBykSACnKKM2DmwNKXBLZ+2teMYoDvSXMKwhM Y0I8wKQHN+kV0BImoCUTelaALClJREhJNTD6x/5nXnFJ5l3Oig/+zgsfaC97E+P0iDthmZGK 6MXzB9JudoT7qz9s03xVfe1DW+KmV++Kf2bF+lr9T3mWK3DFs/zJf5udj7I219em/pG4m7kw 3op1z++UVR2BHw3jVrCKFaXenn/xn9vUcDmnogVBDN98zu94XzWr9WjgmW+hoS7KPkyrtFYr sRRnJBpqMRcVJwIA8ONQRDcDAAA= Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-isis-segment-routing-msd-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2018 01:21:05 -0000 On Wed, Sep 26, 2018 at 11:24:31PM +0000, Les Ginsberg (ginsberg) wrote: > Benjamin - > > > > Please review https://tools.ietf.org/html/rfc8126#section-1.1 > > > > In particular (emphasis added): > > > > " The purpose of having a dedicated IANA Considerations section is to > > provide a single place to collect clear and concise information and > > instructions for IANA. Technical documentation should reside in > > other parts of the document…” > > > > I think what you propose is not consistent with the intent of the IANA section. What about Section 1.1, "guidance describing the conditions under which new values should be assigned [...] is needed", or section 1.3's checklist: 7. If you're using a policy that requires a designated expert (Expert Review or Specification Required), understand Section 5 and provide review guidance to the designated expert (see Section 5.3). Section 4.5 (Expert Review) even goes into more detail, though I'll stop quoting now. -Benjamin From nobody Wed Sep 26 22:26:40 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 933DC130DF2; Wed, 26 Sep 2018 22:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.956 X-Spam-Level: X-Spam-Status: No, score=-14.956 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 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 Of31hzJrkFiV; Wed, 26 Sep 2018 22:26:23 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87AD6130DEE; Wed, 26 Sep 2018 22:26:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2978; q=dns/txt; s=iport; t=1538025982; x=1539235582; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NTXAMnSjWP4kt7yi0+9lnWR1x+30hqzvoZ70OThiW4U=; b=a1Co/edRSylA6oG1+VOZ8eyrtyKxRseCFQ+Gcqw0wARWYPjOR1+mQrnP fGne8dJu+KR2wX2OOcbsN4H5TY83hdNmvw36y3+pn5yfAQ1k9GgZgvXV/ 2WlgM7/z+fl/PHDESP8i1XubHwHHRj+H0uM1ar6sFBirYjvle4Nt9mzER k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AaAACEaKxb/4ENJK1bDgsBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVGCDmV/KAqDaogVjDCCDYM9kxKBegsjhEkCF4NmITQ?= =?us-ascii?q?YAQMBAQIBAQJtHAyFOAEBAQEDIxE3DgwEAgEGAhEEAQEBAgImAgICMBUICAI?= =?us-ascii?q?EDgUIgxqCAQ+HVZtNgS6KCwWBC4lzF4FBP4ERAYMSgxsBAQIBggSCW4JXAp0?= =?us-ascii?q?KCQKGQYliH4FHhFKHfoEei3yIcAIRFIElHTiBVXAVgyeLFoUEOm8BjE6BHgE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.54,309,1534809600"; d="scan'208";a="176784642" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Sep 2018 05:26:20 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id w8R5QK8b003219 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Sep 2018 05:26:20 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 27 Sep 2018 00:26:19 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1395.000; Thu, 27 Sep 2018 00:26:19 -0500 From: "Les Ginsberg (ginsberg)" To: Benjamin Kaduk CC: David Waltermire , "secdir@ietf.org" , "lsr@ietf.org" , "ietf@ietf.org" , "draft-ietf-isis-segment-routing-msd.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-isis-segment-routing-msd-16 Thread-Index: AQHUVQPqnQ0QGOOP8EOqsf/gazaoC6UC9FjAgABwTwD//8fJ0IAAWG2A//+wjNCAAHUKAP//7rRg Date: Thu, 27 Sep 2018 05:26:19 +0000 Message-ID: <0491b66f637344eb9ecb20c1a9d651a6@XCH-ALN-001.cisco.com> References: <153790283647.5258.15634056350853857580@ietfa.amsl.com> <20180926211104.GQ24695@kduck.kaduk.org> <149d5d345afc462f9c5e5770079aaf0e@XCH-ALN-001.cisco.com> <20180926230621.GW24695@kduck.kaduk.org> <31f78bd59e874b18b7ab5d91a7db4aa8@XCH-ALN-001.cisco.com> <20180927012051.GX24695@kduck.kaduk.org> In-Reply-To: <20180927012051.GX24695@kduck.kaduk.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.8.175] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-isis-segment-routing-msd-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2018 05:26:25 -0000 QmVuamFtaW4gLQ0KDQpJdCBpcyBub3QgbXkgaW50ZW50IHRvIGVuZ2FnZSBpbiBhIGRlYmF0ZSB3 aXRoIHlvdS4NCg0KSSBzZXJ2ZSBhcyBEZXNpZ25hdGVkIEV4cGVydCBmb3IgYSBudW1iZXIgb2Yg SVMtSVMgcmVnaXN0cmllcy4gSSBjb25zaWRlciBpdCBteSByZXNwb25zaWJpbGl0eSB0byB1bmRl cnN0YW5kIHRoZSB0ZWNobmljYWwgY29udGVudCBvZiB0aGUgZHJhZnRzIHdoaWNoIG1ha2UgY2hh bmdlcyB0byB0aGUgcmVnaXN0cmllcyBmb3Igd2hpY2ggSSBzZXJ2ZSBpbiB0aGlzIHJvbGUuIEkg ZG8gbm90IGxvb2sgZm9yIG9yIGV4cGVjdCB0ZWNobmljYWwgY29udGVudCBpbiB0aGUgSUFOQSBz ZWN0aW9ucyAtIEkgb25seSBleHBlY3QgdGhlbSB0byBiZSBhY2N1cmF0ZSBpbiB0ZXJtcyBvZiB0 aGUgY2hhbmdlcyByZXF1ZXN0ZWQvY29tcGxldGVkIHRvIHRoZSByZWdpc3RyaWVzLg0KDQpJIGhh dmUgbm8gZG91YnQgdGhhdCB3ZSBzdGlsbCBkaXNhZ3JlZS4gSWYgdGhlcmUgaXMgc29tZSBjb25z ZW5zdXMgdG8gbWFrZSBjaGFuZ2VzIEkgd2lsbCBjZXJ0YWlubHkgbGlzdGVuIC0gYnV0IGlmIGxl ZnQgdXAgdG8gbWUgSSB3b3VsZCBsZWF2ZSB0aGUgSUFOQSBzZWN0aW9uIGFzIGlzLg0KDQogICBM ZXMNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCZW5qYW1pbiBLYWR1 ayA8a2FkdWtAbWl0LmVkdT4NCj4gU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMjYsIDIwMTgg NjoyMSBQTQ0KPiBUbzogTGVzIEdpbnNiZXJnIChnaW5zYmVyZykgPGdpbnNiZXJnQGNpc2NvLmNv bT4NCj4gQ2M6IERhdmlkIFdhbHRlcm1pcmUgPGRhdmlkLndhbHRlcm1pcmVAbmlzdC5nb3Y+OyBz ZWNkaXJAaWV0Zi5vcmc7DQo+IGxzckBpZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZzsgZHJhZnQtaWV0 Zi1pc2lzLXNlZ21lbnQtcm91dGluZy1tc2QuYWxsQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBT ZWNkaXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWlzaXMtc2VnbWVudC1yb3V0aW5n LW1zZC0xNg0KPiANCj4gT24gV2VkLCBTZXAgMjYsIDIwMTggYXQgMTE6MjQ6MzFQTSArMDAwMCwg TGVzIEdpbnNiZXJnIChnaW5zYmVyZykgd3JvdGU6DQo+ID4gQmVuamFtaW4gLQ0KPiA+DQo+ID4N Cj4gPg0KPiA+IFBsZWFzZSByZXZpZXcgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzgx MjYjc2VjdGlvbi0xLjENCj4gPg0KPiA+DQo+ID4NCj4gPiBJbiBwYXJ0aWN1bGFyIChlbXBoYXNp cyBhZGRlZCk6DQo+ID4NCj4gPg0KPiA+DQo+ID4gIiBUaGUgcHVycG9zZSBvZiBoYXZpbmcgYSBk ZWRpY2F0ZWQgSUFOQSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIGlzIHRvDQo+ID4NCj4gPiAgICBw cm92aWRlIGEgc2luZ2xlIHBsYWNlIHRvIGNvbGxlY3QgY2xlYXIgYW5kIGNvbmNpc2UgaW5mb3Jt YXRpb24gYW5kDQo+ID4NCj4gPiAgICBpbnN0cnVjdGlvbnMgZm9yIElBTkEuICBUZWNobmljYWwg ZG9jdW1lbnRhdGlvbiBzaG91bGQgcmVzaWRlIGluDQo+ID4NCj4gPiAgICBvdGhlciBwYXJ0cyBv ZiB0aGUgZG9jdW1lbnTigKbigJ0NCj4gPg0KPiA+DQo+ID4NCj4gPiBJIHRoaW5rIHdoYXQgeW91 IHByb3Bvc2UgaXMgbm90IGNvbnNpc3RlbnQgd2l0aCB0aGUgaW50ZW50IG9mIHRoZSBJQU5BDQo+ IHNlY3Rpb24uDQo+IA0KPiBXaGF0IGFib3V0IFNlY3Rpb24gMS4xLCAiZ3VpZGFuY2UgZGVzY3Jp YmluZyB0aGUgY29uZGl0aW9ucyB1bmRlciB3aGljaA0KPiBuZXcgdmFsdWVzIHNob3VsZCBiZSBh c3NpZ25lZCBbLi4uXSBpcyBuZWVkZWQiLCBvciBzZWN0aW9uIDEuMydzIGNoZWNrbGlzdDoNCj4g DQo+ICAgIDcuICBJZiB5b3UncmUgdXNpbmcgYSBwb2xpY3kgdGhhdCByZXF1aXJlcyBhIGRlc2ln bmF0ZWQgZXhwZXJ0DQo+ICAgICAgICAoRXhwZXJ0IFJldmlldyBvciBTcGVjaWZpY2F0aW9uIFJl cXVpcmVkKSwgdW5kZXJzdGFuZCBTZWN0aW9uIDUNCj4gICAgICAgIGFuZCBwcm92aWRlIHJldmll dyBndWlkYW5jZSB0byB0aGUgZGVzaWduYXRlZCBleHBlcnQgKHNlZQ0KPiAgICAgICAgU2VjdGlv biA1LjMpLg0KPiANCj4gU2VjdGlvbiA0LjUgKEV4cGVydCBSZXZpZXcpIGV2ZW4gZ29lcyBpbnRv IG1vcmUgZGV0YWlsLCB0aG91Z2ggSSdsbCBzdG9wDQo+IHF1b3Rpbmcgbm93Lg0KPiANCj4gLUJl bmphbWluDQo= From nobody Thu Sep 27 04:41:31 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1847130E61; Thu, 27 Sep 2018 04:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoESOE5DzoUh; Thu, 27 Sep 2018 04:41:27 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 44AC5130E64; Thu, 27 Sep 2018 04:41:27 -0700 (PDT) X-AuditID: 1209190d-935ff70000003e84-20-5bacc1e421d1 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 29.E6.16004.5E1CCAB5; Thu, 27 Sep 2018 07:41:25 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w8RBfMpU000782; Thu, 27 Sep 2018 07:41:23 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w8RBfI1X020872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 27 Sep 2018 07:41:20 -0400 Date: Thu, 27 Sep 2018 06:41:18 -0500 From: Benjamin Kaduk To: "Les Ginsberg (ginsberg)" Cc: David Waltermire , "secdir@ietf.org" , "lsr@ietf.org" , "ietf@ietf.org" , "draft-ietf-isis-segment-routing-msd.all@ietf.org" Message-ID: <20180927114117.GZ24695@kduck.kaduk.org> References: <153790283647.5258.15634056350853857580@ietfa.amsl.com> <20180926211104.GQ24695@kduck.kaduk.org> <149d5d345afc462f9c5e5770079aaf0e@XCH-ALN-001.cisco.com> <20180926230621.GW24695@kduck.kaduk.org> <31f78bd59e874b18b7ab5d91a7db4aa8@XCH-ALN-001.cisco.com> <20180927012051.GX24695@kduck.kaduk.org> <0491b66f637344eb9ecb20c1a9d651a6@XCH-ALN-001.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0491b66f637344eb9ecb20c1a9d651a6@XCH-ALN-001.cisco.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOKsWRmVeSWpSXmKPExsUixCmqrfv04Jpog/bdXBYbe/6xWXxfr2ix 4c9GdotnG+ezWJx4soLV4sPChywObB5Tfm9k9Viy5CeTx7WTf1kDmKO4bFJSczLLUov07RK4 Mlbu3sZYcEOk4vyBEywNjI0CXYycHBICJhInJl9m6WLk4hASWMwk8ffULmYIZyOjxJ3rT9kg nKtMEgsutLKDtLAIqErsvvwezGYTUJFo6L4M1MHBISJgJLH4uTZIPbPAdCaJDwensYPEhQX8 JKacEQMp5wXatulzMyPEzA3MEhu7JjBDJAQlTs58wgJiMwuoS/yZdwlsJrOAtMTyfxwQYXmJ 5q2zwco5BVwlfrwEuY2TQ1RAWWJv3yH2CYyCs5BMmoVk0iyESbOQTFrAyLKKUTYlt0o3NzEz pzg1Wbc4OTEvL7VI10gvN7NELzWldBMjOA4keXcw/rvrdYhRgINRiYc3Yv3qaCHWxLLiytxD jJIcTEqivAp7gUJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeEvWrYkW4k1JrKxKLcqHSUlzsCiJ 805oWRwtJJCeWJKanZpakFoEk5Xh4FCS4H13AKhRsCg1PbUiLTOnBCHNxMEJMpwHaDjrQZDh xQWJucWZ6RD5U4y6HC9mdMxgFmLJy89LlRLnlQEZJABSlFGaBzcHlL4ksvfXvGIUB3pLmHc6 SBUPMPXBTXoFtIQJaInIAbAlJYkIKakGRrdlC7tVT5V0nmy+Gu5ioym0W8qW84uMydfZj7is tRQ+hP6Ib75YlSdu0OI9Tbnq/dO5JTev9h+4Lq3zoEucbX9295elPxtFth/wWNZmv3ZJtMCU nMnaIVLWXJ5cX05wL5edkdYspeh+/b/O1cyTgkc+Nh/+1W7+nV3TJcL3pt369XWcuYuuKrEU ZyQaajEXFScCAFBFSaY6AwAA Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-isis-segment-routing-msd-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2018 11:41:30 -0000 Hi Les, I'm happy to leave this question to Alvaro's judgment; as you know, I included it in the non-blocking portion of my ballot position. I appreciated the dedication and rigor you put into your service as a DE, and hope that all DEs can do the same. Thanks, Benjamin On Thu, Sep 27, 2018 at 05:26:19AM +0000, Les Ginsberg (ginsberg) wrote: > Benjamin - > > It is not my intent to engage in a debate with you. > > I serve as Designated Expert for a number of IS-IS registries. I consider it my responsibility to understand the technical content of the drafts which make changes to the registries for which I serve in this role. I do not look for or expect technical content in the IANA sections - I only expect them to be accurate in terms of the changes requested/completed to the registries. > > I have no doubt that we still disagree. If there is some consensus to make changes I will certainly listen - but if left up to me I would leave the IANA section as is. > > Les > > > -----Original Message----- > > From: Benjamin Kaduk > > Sent: Wednesday, September 26, 2018 6:21 PM > > To: Les Ginsberg (ginsberg) > > Cc: David Waltermire ; secdir@ietf.org; > > lsr@ietf.org; ietf@ietf.org; draft-ietf-isis-segment-routing-msd.all@ietf.org > > Subject: Re: Secdir last call review of draft-ietf-isis-segment-routing-msd-16 > > > > On Wed, Sep 26, 2018 at 11:24:31PM +0000, Les Ginsberg (ginsberg) wrote: > > > Benjamin - > > > > > > > > > > > > Please review https://tools.ietf.org/html/rfc8126#section-1.1 > > > > > > > > > > > > In particular (emphasis added): > > > > > > > > > > > > " The purpose of having a dedicated IANA Considerations section is to > > > > > > provide a single place to collect clear and concise information and > > > > > > instructions for IANA. Technical documentation should reside in > > > > > > other parts of the document…” > > > > > > > > > > > > I think what you propose is not consistent with the intent of the IANA > > section. > > > > What about Section 1.1, "guidance describing the conditions under which > > new values should be assigned [...] is needed", or section 1.3's checklist: > > > > 7. If you're using a policy that requires a designated expert > > (Expert Review or Specification Required), understand Section 5 > > and provide review guidance to the designated expert (see > > Section 5.3). > > > > Section 4.5 (Expert Review) even goes into more detail, though I'll stop > > quoting now. > > > > -Benjamin From nobody Thu Sep 27 05:23:19 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 619DB130E25 for ; Thu, 27 Sep 2018 05:23:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu Message-ID: <153805099838.26446.14138783372489501463.idtracker@ietfa.amsl.com> Date: Thu, 27 Sep 2018 05:23:18 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2018 12:23:19 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2018-09-27 Reviewer LC end Draft Klaas Wierenga 2018-09-06 draft-ietf-softwire-mesh-multicast-23 Paul Wouters 2018-09-06 draft-ietf-dnsop-kskroll-sentinel-15 For telechat 2018-10-11 Reviewer LC end Draft Tero Kivinen 2018-10-05 draft-ietf-iasa2-trust-rationale-00 Samuel Weiler 2018-09-07 draft-ietf-tictoc-1588v2-yang-10 Dacheng Zhang 2018-10-05 draft-ietf-iasa2-trust-update-00 Last calls: Reviewer LC end Draft John Bradley 2018-09-25 draft-ietf-dnsop-attrleaf-fix-04 John Bradley 2018-06-18 draft-ietf-bfd-multipoint-active-tail-09 Daniel Franke 2018-06-28 draft-ietf-netconf-rfc7895bis-06 Daniel Gillmor 2018-06-25 draft-ietf-dnsop-session-signal-16 Daniel Gillmor 2018-03-19 draft-gutmann-scep-10 Phillip Hallam-Baker 2018-10-11 draft-ietf-softwire-yang-06 Phillip Hallam-Baker 2018-10-03 draft-ietf-detnet-use-cases-18 Steve Hanna 2018-10-10 draft-ietf-ospf-lls-interface-id-06 Steve Hanna 2018-10-03 draft-ietf-detnet-problem-statement-06 Dan Harkins 2018-10-09 draft-ietf-rtgwg-multihomed-prefix-lfa-07 Christian Huitema 2018-10-09 draft-ietf-bess-mvpn-expl-track-10 Christian Huitema 2018-10-02 draft-ietf-anima-bootstrapping-keyinfra-16 Leif Johansson 2018-10-08 draft-ietf-regext-org-ext-09 Charlie Kaufman 2018-10-08 draft-ietf-regext-org-10 Scott Kelly 2018-10-08 draft-ietf-ntp-bcp-07 Chris Lonvick 2018-10-04 draft-ietf-cbor-cddl-05 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Samuel Weiler 2018-05-21 draft-ietf-bfd-multipoint-18 Liang Xia 2018-10-10 draft-campbell-sip-messaging-smime-03 Taylor Yu 2018-10-09 draft-murchison-tzdist-tzif-14 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Next in the reviewer rotation: Barry Leiba Chris Lonvick Aanchal Malhotra David Mandelberg Catherine Meadows Alexey Melnikov Daniel Migault Matthew Miller Adam Montville Kathleen Moriarty From nobody Fri Sep 28 09:19:39 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C72CF130E6C; Fri, 28 Sep 2018 09:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AmZcgAVKJM0; Fri, 28 Sep 2018 09:19:27 -0700 (PDT) Received: from mail-yb1-xb44.google.com (mail-yb1-xb44.google.com [IPv6:2607:f8b0:4864:20::b44]) (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 6FD17130E6B; Fri, 28 Sep 2018 09:19:27 -0700 (PDT) Received: by mail-yb1-xb44.google.com with SMTP id o8-v6so2853459ybk.13; Fri, 28 Sep 2018 09:19:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version; bh=pyyO6rULtq1J23OPJXR/zuPTFwuoQISXBQ8tRGSXs5E=; b=J4F7j/MMZ2HY3bRyvoibnr23LQgx956LmPW3BxbyO6WQTOduXjPNcOePNz8B4x09j7 QZ1TYaeH8mCYnP90CbJ6W0xL1BJw/i/M1BvNmoVR+t48GJm1fse7RIB7v9aV413chFCg bDeo8o/zmnz1ViNmuB2uELaywwlBKQK2GImey/WH91CMEUJutMyiXPbLiqfw/rXkN6YZ FIo950PTr0Dcz3yU9C2nBjJL0qr0BgXmdtsP0pCCl7jz9+39FJ8IKD9LtF4wq6oJHWd1 DDtRVHSQnTvmVr3J77NIYwH48rEa+ejYvOueV0OOPFg20i7hSoMkz/x2ClRvsHF+c+eD L7Ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=pyyO6rULtq1J23OPJXR/zuPTFwuoQISXBQ8tRGSXs5E=; b=I/dygLx5slV9suDSp9AzeTVVi0hCFAjUteFcXjC8Z3ylT3Heu0sZlhc6kyernb6NMf ZEOV+gDO5sjYS/ikrshR0iZGRsJQVb0dTGIY6kTNM4btCwPOsRWiTgCzwl+OWeAR4s// XSlC+gfISl76RGfk/7mf6e1bqMXvO/2V0esz1n4XAHP0durkVcxY7wlVNGWeAyeQI8WB 8Jss7fAxv6j/mCWOlst2YBu0f3HQFjAA9pRXcRsfKvY1X5wnuUlEX3CJMzyxG7eyjQHf 7wUwDQemRQrNZ0un9F7HWFcdbak9MfVZnV6FAm63o34qUk7Bgal1GSUzZZ46wXWda6YQ za2A== X-Gm-Message-State: ABuFfogtROLdQ0spUCe4NDPOEjwhRnWc0CoJQwxfDR3ZcRxr9CySqhde HbkaOWEe2g41YAIc2H8ZYX8lVrgd X-Google-Smtp-Source: ACcGV60Ykag1fN6crUZyDYHNk++85Yh5R+QUhZ6Kr8nwzycdlJCstl2H0iPueUbhHtX/myyXyXtGTQ== X-Received: by 2002:a25:1f54:: with SMTP id f81-v6mr8627075ybf.164.1538151111034; Fri, 28 Sep 2018 09:11:51 -0700 (PDT) Received: from Chriss-MacBook-Air.local (c-73-19-199-54.hsd1.tn.comcast.net. [73.19.199.54]) by smtp.googlemail.com with ESMTPSA id n186-v6sm2500809ywn.16.2018.09.28.09.11.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Sep 2018 09:11:50 -0700 (PDT) To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-cbor-cddl.all@ietf.org From: Chris Lonvick Message-ID: <5BAE5278.9060005@gmail.com> Date: Fri, 28 Sep 2018 12:10:32 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------000306090908010609020009" Archived-At: Subject: [secdir] SECDIR review of draft-ietf-cbor-cddl-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2018 16:19:30 -0000 This is a multi-part message in MIME format. --------------000306090908010609020009 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is READY with nits. I skimmed through the draft and agree with the author's statement in the first paragraph of the Security Considerations section: This document presents a content rules language for expressing CBOR data structures. As such, it does not bring any security issues on itself, although specification of protocols that use CBOR naturally need security analysis when defined. (As a very minor nit, I'd suggest using "analyses" rather than "analysis".) Nit 1: The authors have made a good effort at identifying some of the topics that may be considered in a security considerations section of specifications that use protocols using CDDL to define CBOR structures. However, I would recommend that those bullet points be used to supplement a normative reference to RFC 3552 "Security Considerations Guidelines". Perhaps adding the following between the first and second paragraphs: Guidelines for writing security considerations are defined in Security Considerations Guidelines [RFC 3552] (BCP 72). Implementers using CDDL to define CBOR structures in protocols must follow those guidelines. Then change the start of the second paragraph from "Topics that may be..." to "Additional topics that may be..." Nit 2: I am not very familiar with all of this, but it seems to me that RFC 8152, "CBOR Object Signing and Encryption (COSE)" should be a normative reference rather than an informative reference, and some mention should be made of it in the Security Considerations section. Reference is made in RFC 8152 to CDDL (4th paragraph in Section 1.3): As well as the prose description, a version of a CBOR grammar is presented in CDDL. Since CDDL has not been published in an RFC, this grammar may not work with the final version of CDDL. The CDDL grammar is informational; the prose description is normative. I may be off base here, but it just seems that since 8152 has been published as a Standards Track document, then this draft should normatively reference it and any subsequent updates to 8152 should normatively reference the Standards Track RFC issuing from this draft. Best regards, Chris --------------000306090908010609020009 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hello,

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

The summary of the review is READY with nits.

I skimmed through the draft and agree with the author's statement in the first paragraph of the Security Considerations section:
   This document presents a content rules language for expressing CBOR
   data structures.  As such, it does not bring any security issues on
   itself, although specification of protocols that use CBOR naturally
   need security analysis when defined.
(As a very minor nit, I'd suggest using "analyses" rather than "analysis".)

Nit 1: The authors have made a good effort at identifying some of the topics that may be considered in a security considerations section of specifications that use protocols using CDDL to define CBOR structures. However, I would recommend that those bullet points be used to supplement a normative reference to RFC 3552 "Security Considerations Guidelines".

Perhaps adding the following between the first and second paragraphs:
   Guidelines for writing security considerations are defined in Security Considerations Guidelines [RFC 3552]
   (BCP 72).  Implementers using CDDL to define CBOR structures in protocols must follow those guidelines.

Then change the start of the second paragraph from "Topics that may be..." to "Additional topics that may be..."

Nit 2: I am not very familiar with all of this, but it seems to me that RFC 8152, "CBOR Object Signing and Encryption (COSE)" should be a normative reference rather than an informative reference, and some mention should be made of it in the Security Considerations section. Reference is made in RFC 8152 to CDDL (4th paragraph in Section 1.3):
   As well as the prose description, a version of a CBOR grammar is
   presented in CDDL.  Since CDDL has not been published in an RFC, this
   grammar may not work with the final version of CDDL.  The CDDL
   grammar is informational; the prose description is normative.
I may be off base here, but it just seems that since 8152 has been published as a Standards Track document, then this draft should normatively reference it and any subsequent updates to 8152 should normatively reference the Standards Track RFC issuing from this draft.

Best regards,
Chris
--------------000306090908010609020009-- From nobody Sat Sep 29 16:09:06 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D721130E76; Sat, 29 Sep 2018 16:08:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christian Huitema To: Cc: draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, ietf@ietf.org, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153826253306.18743.9250084704876465818@ietfa.amsl.com> Date: Sat, 29 Sep 2018 16:08:53 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2018 23:08:53 -0000 Reviewer: Christian Huitema Review result: Has Issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I reviewed version 16 of draft-ietf-anima-bootstrapping-keyinfra, specifying Bootstrapping Remote Secure Key Infrastructures (BRSKI). It is part of the "autonomic networking" specifications developed in the Anima WG. It describes processes for enrolling devices in an "Autonomic Network", with the assistance of a voucher service provided by the vendor of the device. This review will start with a summary of the BRSKI processes, as I understood them from the document, before focusing on security considerations. The whole system appears well engineered, but it is quite complex, requiring interactions between three parties. My main problem is that neither the document in general nor the security section in particular delineates the threats that the protocol is protecting against, and that the protocol as it stands gives a lot of control to manufacturers on the deployment of devices in their customers' networks. BRSKI uses Enrollment over Secure Transport (EST, RFC 7030) to enroll new devices into a domain. Doing that requires solving a set of issues, such as whether the device should accept to be enrolled in the domain, whether the domain should accept the device, and whether all of that can be achieved safely. The constraint is that devices come out of the manufacturing chain with only generic configuration, such as device identifiers or manufacturer certificates, but without any destination specific configuration information. In BRSKI, this is described as a "drop ship" model, in which devices are shipped with their "factory default". The EST enrollment process assumes mutual authentication of the device and the registrar using TLS. The registrar can verify the "initial device identifier" per 802.1AR, but the device itself has no knowledge of the domain that it will join. For the initial TLS connection, the device cannot verify the registrar certificate and will simply accept it. This is similar to the "resurecting duckling" methaphor, inspired from Karl Lorentz' observation that a new born ducking accepts the first duck that its sees as its mother. The duckling thus gets "imprinted" to allways follow its "mother". In BRSKI, the equivalent is that the device will be "imprinted" to trust the first qualified "registrar" that it discovers. There is always a risk that the duckling sees a wolf before seeing its actual mother, with bad consequences for the duckling. In BRSKI, the equivalent would be a device captured by a different registrar than the intended owner. In BRSKI devices mitigate that risk by requesting a voucher (RFC 8366) from the registrar before proceeding with enrollment per RFC 7030. The voucher are provided by the Manufacturer Authorized Signing Authority (MASA) service and thus can be verified by the device. They effectively authorize the registrar to take ownership of a device. BRSKI supports several types of voucher: either vouchers including a nonce specified by the device, or vouchers specifying an expiration date. Nonced vouchers must be provided in real time by the manufacturer or vendor of the device. Nonceless vouchers may be provisioned in advenced, possibly as part of a procurement application. BRSKI specifies a rather complex three-parties process between device, domain registrar and proxy, and vendor or manufacturer provided voucher service. The security section mentions some potential issues with non cooperating vendors, but it does not feel comprehensive. It lacks an actual security analysis, looking at the list of threats. On the top of my head, I could think of a few issues: 1) Denial of service against the vendor MASA service. Adversaries could mount an attack against the service at a critical time, preventing real-time issuance of nonced vouchers. This could for example prevent the deployment of autonomic networks during emergencies. 2) Compromise of the vendor's public key. This would allow attackers to get "ugly ducklings" imprinted in the domain. 3) Rotation of the vendor's public key. This could prevent old devices from joining the domain, or from verifying the new vouchers. 4) Abuse of long duration timeless vouchers by a previous owner. This is discussed in the security section. 5) Device tampering during the drop ship process, maybe by some kind of Tailored Access Operation group. I think that BRSKI does nothing against that attack, but maybe we should just say so. 6) No "ship and forget" operation. BRSKI supposes continuous involment of the manufacturer during the deployment process. This means that a whole class of inexpensive devices are out of scope. This is a tradeoff between usability and some security properties, and the tradeoff should be explained. 7) The closest to ship and forget is a MASA service configured to always issue vouchers, regardless of the device ID and the registrar domain. I would expect that to be popular with some manufacturers. It is mentioned in section 6.4, which recommend that manufacturers should not do that. What are the consequences if they still do? 8) Attacks by the device. What happens if a device refuses to be imprinted? I suppose someone will have to "resurrect the duckling". How costly is that? 9) Attacks by the device, pretending to be an infinity of virtual devices. This is listed in the security considerations. 11) Attacks by the MASA. What happens if the MASA refuses to provide a voucher, or provides a wrong voucher? Can the MASA be used to restrain commerce with specific countries? Is that a feature or a bug? 12) Device implementation of random numbers. The draft discusses management of time in a drop ship device, but what about the management of random numbers? For example, what if poorly manufactured devices always generated the same nonce, or a predictable nonce? 13) Device individualization. The drop ship model assumes that devices are shipped with factory default, but BRSKI also assumes that devices come with individuals ID and certificate. This requires a specific per device step in the manufacturing process. Some makers of inexpensive devices don't do that, and ship devices that are all strictly identical. How does that affect the BRSKI process? 14) Privacy considerations. Third parties will be able to observe traffic between domain registrar and service provider MASA. They will at a minimum be able to learn that domain X is a customer of provider Y. Can they do more? The communication is protected by TLS. How much is revealed by clear text components like the SNI? How much can be obtained by traffic analysis? Several of the issues listed above can be construed as potential operation problems, not just security issues. They can be the result of honest mistakes or implementation errors. -- Christian Huitema From nobody Sun Sep 30 11:53:15 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7250F130DED; Sun, 30 Sep 2018 11:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3k9YEkTrhll; Sun, 30 Sep 2018 11:52:57 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 D5033128D0C; Sun, 30 Sep 2018 11:52:53 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1g6gpn-0007xd-9s; Sun, 30 Sep 2018 18:52:51 +0000 Date: Sun, 30 Sep 2018 11:52:49 -0700 Message-ID: From: Randy Bush To: Christian Huitema Cc: Security Directorate , draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, IETF Rinse Repeat , anima@ietf.org In-Reply-To: <153826253306.18743.9250084704876465818@ietfa.amsl.com> References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Sep 2018 18:52:59 -0000 christian, a stunning review as usual. but i have two questions which you kind of finessed. they are simple binary, i.e. yes/no, questions that the end user, to whom the IETF is ultimately responsible, really cares about. if the manufacturer's servers go down, either permanently or even for a day, does the device i have purchased still work? i.e. is it fail soft? [0] if the manufacturer's servers go down, either permanently or even for a day, can i give/sell the device i have purchased to a third, well fourth i guess, party, at my whim and seamlessly unencumbered? fwiw, i asked these same questions at the 2005 paris side meeting at l'ecole whatever hosted by mark. the blank stares i received alarmed me. the ietf is ultimately responsible to the users. thanks. randy -- 0 - yes, i understand i may not be able to access it through the manufacturer's cloud. so you want to help look at tcpdumps of the manufacturer installed thermostat that does not talk to that mfgr on net that i am debugging this weekend? :( From nobody Sun Sep 30 12:58:34 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39204130E13; Sun, 30 Sep 2018 12:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCN5gIajtCQU; Sun, 30 Sep 2018 12:58:15 -0700 (PDT) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 025E3130DE9; Sun, 30 Sep 2018 12:58:15 -0700 (PDT) Received: by mail-pf1-x430.google.com with SMTP id j8-v6so7657107pff.6; Sun, 30 Sep 2018 12:58:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=6D4MkRE/yYanFgjDt6hmibY4RutoZdUMp7hPkL92DKY=; b=ko6C6/YQDO2AmjMGJz9PSYtl4+yyPWIhYvMO859uKgfPCXRXrhZWiJHkhbCCOm2UuI RMHNAKczafhsk7xFiSdRS3ELAKH9kiDtURujzH46LberXJT8B3LTemkcW+64f5u+lH2/ mMluWim6rGc4JyZhhNbk5DAis1OrMJ26ZFFJYcZkdltkc/rYoZkS4GTMzhbaqTFp20Xe KXpAe/SPnR32Ckzb9Fmxp32V8mE0HeTfCyQxwLkIc/LEt9x2d9/EvtcAo24xWz9JFKMR RLVg50yC/NCXGJ2DCNA6cO7DYSp6dzBZIML4ANA8UOri4mHjlsYhw+squZWJVShxCSbu 7Miw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=6D4MkRE/yYanFgjDt6hmibY4RutoZdUMp7hPkL92DKY=; b=ZqyIoTraR5LkyLfFRNOaCcBF9hlOILqJa57DppYgEoD2wNk9CdAShynAAKU9PGpzxP jaFC2mMmoZdXF9Z+LY6/3YKulj1PVvE3FQrVyW3AaY+HXKmDG8M3G2ezLR6dE9RkeHHY S80hd4QvFOk4KjkB3P2dapubAZmCAKauVFCSVaUFxsIJiY04ZyEy6Mp0GnClLbki7fJC pa3M/aR64FgWyJjuZGuIkkWM24e+L4+bVFYywQP+3c1NR/SRHcp1nWeTvb0jGBdazl5Q 0cvScK2zY6j5hy8Vg3dVKOh3TGX5Ks8VlHxJdBd8CT/OKEt4SGOQPhxDQ9rLLXD2fIDA nMrA== X-Gm-Message-State: ABuFfoh6TDYO62Qis0KU8VIyfacZkzKBK7OtiMfgHlVQKOGHKd2/R4PF RyWR8EYLfKKZQ8pKSq0la321raxD X-Google-Smtp-Source: ACcGV62aEt7vP3eRwLWjFfhzmolthbKynj5WlmR0T0AfDY11R8oFETPm9afC1jZB7G0QTCKW33EA+Q== X-Received: by 2002:a62:4704:: with SMTP id u4-v6mr8349428pfa.76.1538337494154; Sun, 30 Sep 2018 12:58:14 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id s16-v6sm14866756pfm.114.2018.09.30.12.58.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 30 Sep 2018 12:58:12 -0700 (PDT) To: Randy Bush , Christian Huitema Cc: draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, IETF Rinse Repeat , anima@ietf.org, Security Directorate References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> From: Brian E Carpenter Message-ID: <0cbdf93d-c432-57f5-5000-8595b006d6d0@gmail.com> Date: Mon, 1 Oct 2018 08:58:06 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Sep 2018 19:58:18 -0000 On 2018-10-01 07:52, Randy Bush wrote: > christian, > > a stunning review as usual. but i have two questions which you kind of > finessed. they are simple binary, i.e. yes/no, questions that the end > user, to whom the IETF is ultimately responsible, really cares about. > > if the manufacturer's servers go down, either permanently or even for > a day, does the device i have purchased still work? i.e. is it fail > soft? [0] It still works if and only if the registrar already holds its voucher. There's a related question, which is: if the autonomic network is air-gapped from the Internet, as is very likely in many sensitive applications, does the whole mechanism work at all? The answer is, as I understand it, yes, but with a variant. See option 3 in section 6.3. "Registrar security reductions", which explicitly covers the case of obtaining vouchers in advance from the MASA. The BRSKI authors regard this as less secure than relying on the MASA in real time. You might have a different opinion, if you were operating the air-gapped network. My personal opinion is that this will be a widely used solution, whatever its security issues, because it avoids MASA dependency. > if the manufacturer's servers go down, either permanently or even for > a day, can i give/sell the device i have purchased to a third, well > fourth i guess, party, at my whim and seamlessly unencumbered? There are two conditions for it to work as I understand: 1) The device ID is added to the list of devices acceptable to the registrar in its new network. AND 2) That registrar is able to contact the MASA. Alternatively - see the previous point. If you had previously obtained a voucher in advance, you could include it with the device. Just as you might write the hard disk password on a yellow sticky when selling a laptop in a garage sale. Brian > > fwiw, i asked these same questions at the 2005 paris side meeting at > l'ecole whatever hosted by mark. the blank stares i received alarmed > me. the ietf is ultimately responsible to the users. > > thanks. > > randy > > -- > > 0 - yes, i understand i may not be able to access it through the > manufacturer's cloud. so you want to help look at tcpdumps of > the manufacturer installed thermostat that does not talk to that > mfgr on net that i am debugging this weekend? :( > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Sun Sep 30 13:06:31 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C586130E13; Sun, 30 Sep 2018 13:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 7lIt-ykYHk1h; Sun, 30 Sep 2018 13:06:06 -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 117AB130E0F; Sun, 30 Sep 2018 13:06:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id CE3F924041B; Sun, 30 Sep 2018 13:06:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1538337965; bh=XgxdunT5Br5jGpQYpqb7rCc7t1yP6PXH/vssApnsY74=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=WLDaQGHii6vjkLfYQqiAM1+HHAaps+OwIGZIAb8JMoU1cZc6QP8PbSxqHTEfaF4Dt hptjf7Ny8u+XbegdhPa/9O8lJcuWMZo5vEqipiEY3N1w3kzGSTm+hI1yTxWW9uHCXI r21e6BePo8cNzC4lBW55bSvZj5avLRzzpb/qTmTk= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id BF922A80092; Sun, 30 Sep 2018 13:06:04 -0700 (PDT) To: Brian E Carpenter , Randy Bush , Christian Huitema Cc: draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, IETF Rinse Repeat , anima@ietf.org, Security Directorate References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <0cbdf93d-c432-57f5-5000-8595b006d6d0@gmail.com> From: "Joel M. Halpern" Message-ID: Date: Sun, 30 Sep 2018 16:06:03 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <0cbdf93d-c432-57f5-5000-8595b006d6d0@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Sep 2018 20:06:07 -0000 That answer seems to imply that if the MASA is down before I try to transfer my device, and if the MASA is still down when the recipient tries to get my device working, it won't work. Which seems to mean that once a MASA goes down permanently, any new can not get a device reliant on that MASA to work. Seems a pretty severe limitation. Yours, Joel On 9/30/18 3:58 PM, Brian E Carpenter wrote: > On 2018-10-01 07:52, Randy Bush wrote: >> christian, >> >> a stunning review as usual. but i have two questions which you kind of >> finessed. they are simple binary, i.e. yes/no, questions that the end >> user, to whom the IETF is ultimately responsible, really cares about. >> ... >> if the manufacturer's servers go down, either permanently or even for >> a day, can i give/sell the device i have purchased to a third, well >> fourth i guess, party, at my whim and seamlessly unencumbered? > > There are two conditions for it to work as I understand: > 1) The device ID is added to the list of devices acceptable to the > registrar in its new network. > AND > 2) That registrar is able to contact the MASA. > > Alternatively - see the previous point. If you had previously obtained > a voucher in advance, you could include it with the device. Just as > you might write the hard disk password on a yellow sticky when > selling a laptop in a garage sale. > > Brian From nobody Sun Sep 30 14:29:50 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0935E130E18; Sun, 30 Sep 2018 14:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPWpiJP9Zbqm; Sun, 30 Sep 2018 14:29:31 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F9E1130E14; Sun, 30 Sep 2018 14:29:31 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 5BBBE20090; Sun, 30 Sep 2018 17:29:27 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id E7D49AE0; Sun, 30 Sep 2018 17:29:27 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E4287ACB; Sun, 30 Sep 2018 17:29:27 -0400 (EDT) From: Michael Richardson To: "Joel M. Halpern" , Randy Bush cc: Brian E Carpenter , Christian Huitema , draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, IETF Rinse Repeat , anima@ietf.org, Security Directorate In-Reply-To: References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <0cbdf93d-c432-57f5-5000-8595b006d6d0@gmail.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [secdir] [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Sep 2018 21:29:34 -0000 --=-=-= Content-Type: text/plain Randy Bush wrote: > a stunning review as usual. but i have two questions which you kind of > finessed. they are simple binary, i.e. yes/no, questions that the end > user, to whom the IETF is ultimately responsible, really cares about. > if the manufacturer's servers go down, either permanently or even for > a day, does the device i have purchased still work? i.e. is it fail > soft? [0] First, BRSKI as used by ANIMA is specifically not targetted at Things. (We are developing profiles of BRSKI that are about Things, but I think that this internet-draft should not be be evaluated on that basis). It's targetted at routers and other devices found at ISPs or Enterprises. Whether or not the device continues to work after you take onwership is not about this protocol. Second, the only time the manufacturer's servers need to be alive is when device ownership is claimed. Once the device is claimed, it joins *YOUR* network, and trusts your infrastructure, not the manufacturer. Whether or not the device will *operate* without the manufacturer's servers is really outside of BRSKI. However, if anything, we feel that as BRSKI creates a strong connection between the device (the "pledge"), and the owner, that it is much easier for the device to operate under the control of the owner rather than exclusively the manufacturer's servers. Joel M. Halpern wrote: > That answer seems to imply that if the MASA is down before I try to transfer > my device, and if the MASA is still down when the recipient tries to get my > device working, it won't work. > Which seems to mean that once a MASA goes down permanently, any new can not > get a device reliant on that MASA to work. > Seems a pretty severe limitation. You are answering a different question than Randy asked, I think. You are answer the question about whether the device can be resold. This is a pretty important question and we have discussed it at length. I remain concerned, but as far as I can see, we have this problem already. It fundamentally depends upon a number of things which unfortunately, the manufacturer has ultimate decision making about. I hope that the market will express itself, and the answers will result in environmentally sustainable solutions rather than landfills. Those things are: 1) trivially, is the manufacturer alive, and willing to issue a new voucher to a new owner. This is the easiest situation. 2) if the manufacturer's software allows the domain owner to replace the MASA trust anchor with another one, then a different MASA could authorize the resale. 3) if the manufacturer allows the entire software stack to be replaced, then in effect, a new manufacturer can be selected. (Think OpenWRT here) In essence, all of these questions are about the degree to which the manufacturer lets the owner control the software. This is a tussle between manufacturers that want to control it all, and owners who feel they should control what the system does. We think that BRSKI does not force either situation, but does deal with some situations where a third party has inserted software between the point of manufacturer and the owner. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAluxQDcACgkQgItw+93Q 3WVBtQgAhLpmOdCaTHgVIONWtvspoVoigJEj+UiivtNfp8EddD/7Il/OaWKSeQQx TavQbvRI7mt2geA8Xv9M3WQGUrb47o1npbaSozLm892/IHN5QyOadYk5XAtDVjYN gE0eUzGHGAvoYsN3JEBvTQZJeWKyU1OfyuzigJHjaRJFolc64oZvw4GEgb7DHjC7 T6JV2NCS+Cg7GNV3DBJKcuOY7yOFHJg34+wmv5anCOSjQy6fatb3dVOxRef1AIPG NUD+beH+ZvD/C5hthzBYrMgIiZBL7xuPNYWo7KKxRQBbdLpvNV2CM56jBR2sSEiA fHpIMGM7AaRG20msbQlsqUdUKKOznw== =Jcny -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Sep 30 16:10:02 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 002E312872C; Sun, 30 Sep 2018 16:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xeQCfeON3DHh; Sun, 30 Sep 2018 16:09:50 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE06D126CB6; Sun, 30 Sep 2018 16:09:49 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 39E6820090; Sun, 30 Sep 2018 19:09:47 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id CABBBAE0; Sun, 30 Sep 2018 19:09:47 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id C757A3D6; Sun, 30 Sep 2018 19:09:47 -0400 (EDT) From: Michael Richardson To: Christian Huitema cc: secdir@ietf.org, draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, ietf@ietf.org, anima@ietf.org In-Reply-To: <153826253306.18743.9250084704876465818@ietfa.amsl.com> References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Sep 2018 23:09:52 -0000 --=-=-= Content-Type: text/plain Christian, thank you for the review. I have opened issues for each of the points you raise so that we can better keep track of your comments. Please see: https://github.com/anima-wg/anima-bootstrap/issues I think that we authors will consider if we need to clarify any text to deal with your comments, and if so, we'll post those changes/diffs. Otherwise, we'll start a sub-thread of this email for the various cases. Should we continue to CC ietf@ietf.org, or will secdir + anima do? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAluxV7sACgkQgItw+93Q 3WUO3AgAr3SAKcKsVFKwHHZDZoVUAGV+cz2bSJfIai4Eh/60OrfVKBAKusMf/2lB 9oMXB7VQXXIyXOQlwEGqlJAfIrBu44jliAc5HX3zguKpmZXtWYPohlaVO3QQTZKJ Txgwb0qrN/UEh0qWOQ/sPP2nU8MaOFUKcSUuZmTfAY8fiGGHvm73GpPcoVkCLfkR 4BnPwrp0V7jGRoY738cSgCyK5rahTwm4wEDljWrb4lQ0niFlFmzJc2RXznpglhIJ 9rW2QFtlCRY6x1kuYgIxEZHGAu/llRhwxjBF3ZARjxFXwvqreHdbw9SEp6fM5J4E e7pAg3vFNBFkh7UGRNcnqvPhab982Q== =OlmZ -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Sep 30 22:43:11 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C711286E3 for ; Sun, 30 Sep 2018 22:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZsTeuftMZbX for ; Sun, 30 Sep 2018 22:43:07 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 795E1126F72 for ; Sun, 30 Sep 2018 22:43:07 -0700 (PDT) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx105.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1g6qz1-0001gD-Ih for secdir@ietf.org; Mon, 01 Oct 2018 07:43:04 +0200 Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1g6qyz-0005EZ-Hp for secdir@ietf.org; Mon, 01 Oct 2018 01:43:02 -0400 Received: (qmail 2373 invoked from network); 1 Oct 2018 05:42:59 -0000 Received: from unknown (HELO [192.168.1.105]) (Authenticated-user:_huitema@huitema.net@[172.56.42.134]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 1 Oct 2018 05:42:58 -0000 To: Randy Bush Cc: draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, IETF Rinse Repeat , anima@ietf.org, Security Directorate References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <057bd957-06b4-824e-a7c8-214383819621@huitema.net> Date: Sun, 30 Sep 2018 22:42:55 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 168.144.250.230 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.44) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5qfirOTVaLBQGbvtAYDwnqF602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOzniiMFxnOFMHTZqw+apvQzTV/3OdXD2Xdo8CfrY5CQSexc6rQWlPuhmVv85H/HTKIyz NJVaeAWax4WOe4pTBX2DwIE7VKe+bqpcdCns72R1/fRcQ8DPjRRdBSJfnAogVbUJ8oN+d2/1YClf NOnZIS+k7MxK87c44TynDTcugpM/kRBtrTRM/4TRHmTy40yDhnXc9h1jP0GCLUBD5fsSyyeBaQIi fdaGzMoXcgXnOXfsRAwX31WVY5lWjWxuGSRuxURW8UvT0kUDO7BO02wlaiMJNrZqjoiSWdcjcZLv /Am2ptBB9icD2fnZzw/HNF6wGm/P3Q658NtotfOVlwP9Y9difvX7GxYM34o1TppnqMQvRsaiauSV ohXqcOBLfm7uY6BmNlijRSWQzbBZx5Si4hrQHolQlVdf0A32Xtl5FAWD8PcNYjhf2jycpxDLnRQv ahqZR3KVQgqF/fPYYAfEfsjRCeh3Vga/K+tTXg3EW+ZCQyYzoTs9p0wBCDqWWHnNC0XDy76XUbBI c8kzcy5u9YnFVfV8YwbQTud2ndj194c9/49qryIYbFFBOkVCXXzvNoACQcwXnrT9jVUoMBm9/34R FZ4oobg8BBg3Jq+ntzj0/EZUYLcD59sOzzNgwf0NQS6m92U/Rr2NiuKWX4lMKSlFQJWvCSfS5UB2 KOwdnKnPUcrFDkA/NjAbu3DqdC3lyMStknsMa5xMcOok/WzPHhmu7ALr9GwxDinRa92sptNCgXQb 9W4Kqgrdo/qlHQwR1/JNukDO91giXRCq1+m63CgzzZ1TJCc1Jsz93JxBBgxpJBPvPDjBPaowofdk fHH45mUVrBsPGnNiJ83AD/4JscB0VTS+bY/ezHW1Vxxj2dVmDKpXV/g3aWnksZpz4kAf+OlNC4wc 2LkM7XQE4YLVklOegMwrtwdodggrHZMuX9HK X-Report-Abuse-To: spam@quarantine6.antispamcloud.com Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 05:43:10 -0000 On 9/30/2018 11:52 AM, Randy Bush wrote: > christian, > > a stunning review as usual. but i have two questions which you kind of= > finessed. they are simple binary, i.e. yes/no, questions that the end > user, to whom the IETF is ultimately responsible, really cares about. > > if the manufacturer's servers go down, either permanently or even for > a day, does the device i have purchased still work? i.e. is it fail > soft? [0] My understanding is that, yes, the device that you have purchased and installed still works. BRSKI is a bootstrap service, and as Michael Richardson says, the dependency is only there during the bootstrap, i.e. between the time you unwrap the device and the time initialization on your network is complete. The "soft fail" happens if devices need to be reset to factory settings for some reason, then you will have to wait for the manufacturer's servers to bring them back up. That may be mitigated if the manufacturer provided you with nonceless vouchers, valid until "time=3DX", and in particular if the manufacturer gave you vouchers "good until infinity". In that case, your old devices could still be reset to factory condition and restarted, without even "soft fail". > > if the manufacturer's servers go down, either permanently or even for > a day, can i give/sell the device i have purchased to a third, well > fourth i guess, party, at my whim and seamlessly unencumbered? It depends somewhat on the type of voucher that the manufacturer is willing to give you, but the short answer is No, you can't. If the manufacturer only wants to provide real time vouchers that incorporate the random nonce issued by the device, then the answer is very clearly no, you cannot resell the device without approval from the manufacturer. The voucher in that case acts as a kind of DRM. If the manufacturer is willing to issue "good until time=3DX" vouchers, then in theory you could provide the voucher to your buyer, provided the time limit of the voucher has not elapsed. If the manufacturer signs a voucher "good until infinity", then the device can in theory be sold and resold forever. But that's probably not true in practice, because the voucher is written for a specific domain, and includes the certificate of the domain for which the voucher is good. You may be able to play games with some kind of certificate chain and make it work, but I will believe that when I see it. > fwiw, i asked these same questions at the 2005 paris side meeting at > l'ecole whatever hosted by mark. the blank stares i received alarmed > me. the ietf is ultimately responsible to the users. The BRSKI specification is a tradeoff and that's why I would really like to see the tradeoff explained in clear terms in the spec. It is designed to prevent hijacking of the device during its registration in the buyer's network. If BRSKI implemented a pure RFC 7030 process, the device=C2=A0 might have= to accept to be imprinted by the registrar without having verified to whom it is talking. In practice that would mean relying on some kind of physical security, or maybe relying on the kind of trust anchors commonly used for web services. =46rom the registrar point of view, the failure mode is that some kind of= man-in-the-middle inserts itself during the registration process, and maintains control of the device after it is connected to the network. The voucher system mitigates that risk, but at the cost of strong dependency on the manufacturer. As I say, that's a trade-off, and I could see different buyers having different opinions on that dependency. In fact, I could see buyers willing to buy devices only if they permitted "voucher-less" initialization. If the standard allowed that option, then market forces would quickly define how valuable the voucher system is. -- Christian Huitema