From rpsec-bounces@ietf.org Tue Mar 8 13:53:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01212 for ; Tue, 8 Mar 2005 13:53:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8jro-0004Ry-G8 for rpsec-web-archive@ietf.org; Tue, 08 Mar 2005 13:55:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8jjd-0005ji-Ex; Tue, 08 Mar 2005 13:47:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8jjb-0005jc-4b for rpsec@megatron.ietf.org; Tue, 08 Mar 2005 13:47:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00602 for ; Tue, 8 Mar 2005 13:47:07 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8jlz-0004IN-QI for rpsec@ietf.org; Tue, 08 Mar 2005 13:49:42 -0500 Received: from [130.129.134.228] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j28IkskJ015991 for ; Tue, 8 Mar 2005 13:46:55 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <00ff01c51365$6a94f9e0$0601a8c0@pc6> Date: Tue, 8 Mar 2005 13:46:54 -0500 To: rpsec@ietf.org From: Stephen Kent Content-Type: multipart/mixed; boundary="============_-1101814878==_============" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.1 (/) X-Scan-Signature: f4bb0a58c699ca9be2d04589e50a8c9a Subject: [RPSEC] comments on rpsec-bgpsecrec-01 X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 5f0fbe4afeb8ebbd90221aadfbfecbeb --============_-1101814878==_============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" sorry for the lateness of the comments. I used MS Word with change tracking to highlight changed text, and to accommodate comments, but saved the result in RTF. Steve --============_-1101814878==_============ Content-Id: Content-Type: application/rtf; name="draft-ietf-rpsec-bgpsecrec-01.txt" ; x-mac-type="52544620" ; x-mac-creator="4D535744" Content-Disposition: attachment; filename="draft-ietf-rpsec-bgpsecrec-01.txt" Content-Transfer-Encoding: base64 e1xydGYxXG1hY1xhbnNpY3BnMTAwMDBcdWMxXGRlZmYwXHN0c2hmZGJjaDBcc3RzaGZs b2NoMFxzdHNoZmhpY2gwXHN0c2hmYmkwXGRlZmxhbmcxMDMzXGRlZmxhbmdmZTEwMzN7 XHVwcntcZm9udHRibHtcZjBcZm5pbFxmY2hhcnNldDI1NlxmcHJxMntcKlxwYW5vc2Ug MDAwMjAyMDYwMzA1MDQwNTAyMDN9VGltZXMgTmV3IFJvbWFuO30Ne1xmMVxmbmlsXGZj aGFyc2V0MjU2XGZwcnEye1wqXHBhbm9zZSAwMDAyMGIwNjA0MDIwMjAyMDIwMn1Bcmlh bDt9e1xmMlxmbmlsXGZjaGFyc2V0MjU2XGZwcnEye1wqXHBhbm9zZSAwMDAyMDcwMzA5 MDIwMjA1MDIwNH1Db3VyaWVyIE5ldzt9e1xmM1xmbmlsXGZjaGFyc2V0MlxmcHJxMntc KlxwYW5vc2UgMDAwMjAwMDUwMDAwMDAwMDAwMDB9U3ltYm9sO30Ne1xmNFxmbmlsXGZj aGFyc2V0MjU2XGZwcnEye1wqXHBhbm9zZSAwMDAyMDAwNTAwMDAwMDAwMDAwMH1UaW1l czt9e1xmNVxmbmlsXGZjaGFyc2V0MjU2XGZwcnEye1wqXHBhbm9zZSAwMDAyMDAwNTAw MDAwMDAwMDAwMH1IZWx2ZXRpY2E7fXtcZjZcZm5pbFxmY2hhcnNldDI1NlxmcHJxMntc KlxwYW5vc2UgMDAwMjAwMDUwMDAwMDAwMDAwMDB9Q291cmllcjt9e1xmN1xmbmlsXGZj aGFyc2V0MjU2XGZwcnEyIEdlbmV2YTt9DXtcZjhcZnJvbWFuXGZjaGFyc2V0NzdcZnBy cTJ7XCpccGFub3NlIDAwMDAwMDAwMDAwMDAwMDAwMDAwfVRtcyBSbW47fXtcZjlcZnN3 aXNzXGZjaGFyc2V0NzdcZnBycTJ7XCpccGFub3NlIDAwMDAwMDAwMDAwMDAwMDAwMDAw fUhlbHY7fXtcZjEwXGZyb21hblxmY2hhcnNldDc3XGZwcnEye1wqXHBhbm9zZSAwMDAw MDAwMDAwMDAwMDAwMDAwMH1NUyBTZXJpZjt9DXtcZjExXGZzd2lzc1xmY2hhcnNldDc3 XGZwcnEye1wqXHBhbm9zZSAwMDAwMDAwMDAwMDAwMDAwMDAwMH1NUyBTYW5zIFNlcmlm O317XGYxMlxmbmlsXGZjaGFyc2V0MjU2XGZwcnEye1wqXHBhbm9zZSAwMDAyMDIwNTAy MDYwMzA1MDYwMn1OZXcgWW9yazt9e1xmMTNcZnN3aXNzXGZjaGFyc2V0NzdcZnBycTJ7 XCpccGFub3NlIDAwMDAwMDAwMDAwMDAwMDAwMDAwfVN5c3RlbTt9DXtcZjE0XGZuaWxc ZmNoYXJzZXQyXGZwcnEye1wqXHBhbm9zZSAwMDA1MDIwMTAyMDEwODA0MDgwN31XaW5n ZGluZ3M7fXtcZjE1XGZyb21hblxmY2hhcnNldDEyOFxmcHJxMXtcKlxwYW5vc2UgMDAw MDAwMDAwMDAwMDAwMDAwMDB9XCc4MmxcJzgyciBcJzk2XCdiZVwnOTJcJ2E5O317XGYx NlxmbmlsXGZjaGFyc2V0MTI5XGZwcnExe1wqXHBhbm9zZSAwMDAwMDAwMDAwMDAwMDAw MDAwMH1cJ2I5XCdkOVwnYzVcJ2MxO30Ne1xmMTdcZm5pbFxmY2hhcnNldDEzNFxmcHJx MntcKlxwYW5vc2UgMDAwMDAwMDAwMDAwMDAwMDAwMDB9XCdjYlwnY2VcJ2NjXCdlNTt9 e1xmMThcZm5pbFxmY2hhcnNldDEzNlxmcHJxMntcKlxwYW5vc2UgMDAwMDAwMDAwMDAw MDAwMDAwMDB9XCdiN3NcJ2IyXCdkM1wnYTlcJ2ZhXCdjNVwnZTk7fQ17XGYxOVxmbW9k ZXJuXGZjaGFyc2V0MTI4XGZwcnExe1wqXHBhbm9zZSAwMDAwMDAwMDAwMDAwMDAwMDAw MH1cJzgybFwnODJyIFwnODNTXCc4M1ZcJzgzYlwnODNOO317XGYyMFxmcm9tYW5cZmNo YXJzZXQ3N1xmcHJxMntcKlxwYW5vc2UgMDAwMjA0MDYwNDA1MDUwNTAyMDN9Q2VudHVy eTt9e1xmMjFcZm5pbFxmY2hhcnNldDI1NlxmcHJxMntcKlxwYW5vc2UgMDAwMjBiMDYw NDAzMDUwNDA0MDJ9VmVyZGFuYTt9DXtcZjIyXGZuaWxcZmNoYXJzZXQyNTZcZnBycTJ7 XCpccGFub3NlIDAwMDIwYjA2MDQwMzA1MDQwNDAyfVRhaG9tYTt9e1xmMjNcZm5pbFxm Y2hhcnNldDJcZnBycTJ7XCpccGFub3NlIDAwMDEwMTA2MDEwMTAxMDEwMTAxfU1vbm90 eXBlIFNvcnRzO317XGYyNFxmbmlsXGZjaGFyc2V0MjU2XGZwcnEye1wqXHBhbm9zZSAw MDAyMGIwNjAwMDQwNTAyMDIwMn1MdWNpZGEgR3JhbmRlO30Ne1xmMjVcZm5pbFxmY2hh cnNldDI1NlxmcHJxMntcKlxwYW5vc2UgMDAwMjBiMDUwOTAwMDAwMDAwMDB9QW5kYWxl IE1vbm87fXtcZjI2XGZuaWxcZmNoYXJzZXQyNTZcZnBycTJ7XCpccGFub3NlIDAwMDMw MjA3MDIwNDA1MDYwNjA1fUFwcGxlIENoYW5jZXJ5O317XGYyN1xmbmlsXGZjaGFyc2V0 MjU2XGZwcnEye1wqXHBhbm9zZSAwMDAyMGIwYTA0MDIwMTAyMDIwMn1BcmlhbCBCbGFj azt9DXtcZjI4XGZuaWxcZmNoYXJzZXQyNTZcZnBycTJ7XCpccGFub3NlIDAwMDIwYjA1 MDYwMjAyMDIwMzAyfUFyaWFsIE5hcnJvdzt9e1xmMjlcZm5pbFxmY2hhcnNldDI1Nlxm cHJxMntcKlxwYW5vc2UgMDAwMjBmMDcwNDAzMDUwNDAzMDJ9QXJpYWwgUm91bmRlZCBN VCBCb2xkO317XGYzMFxmbmlsXGZjaGFyc2V0MjU2XGZwcnEye1wqXHBhbm9zZSAwMDAy MDIwNTAyMDcwNDAxMDIwM31CYXNrZXJ2aWxsZTt9DXtcZjMxXGZuaWxcZmNoYXJzZXQy NTZcZnBycTJ7XCpccGFub3NlIDAwMDIwMjA3MDIwNzA0MDAwMjAyfUJhc2tlcnZpbGxl IFNlbWlib2xkO317XGYzMlxmbmlsXGZjaGFyc2V0MjU2XGZwcnEye1wqXHBhbm9zZSAw MDAyMDAwNjAzMDkwMDAwMDIwMH1CaWcgQ2FzbG9uO317XGYzM1xmbmlsXGZjaGFyc2V0 MjU2XGZwcnEye1wqXHBhbm9zZSAwMDAyMDAwNTAwMDAwMDAwMDAwMH1DYXBpdGFsczt9 DXtcZjM0XGZuaWxcZmNoYXJzZXQyNTZcZnBycTJ7XCpccGFub3NlIDAwMDAwMDAwMDAw MDAwMDAwMDAwfUNoYXJjb2FsO317XGYzNVxmbmlsXGZjaGFyc2V0MjU2XGZwcnEye1wq XHBhbm9zZSAwMDAyMGIwODA2MDgwNjA0MDQwMn1DaGljYWdvO317XGYzNlxmbmlsXGZj aGFyc2V0MjU2XGZwcnEye1wqXHBhbm9zZSAwMDAzMGYwNzAyMDMwMzAyMDIwMn1Db21p YyBTYW5zIE1TO30Ne1xmMzdcZm5pbFxmY2hhcnNldDI1NlxmcHJxMntcKlxwYW5vc2Ug MDAwMjAwMDUwNDAwMDAwMDAyMDB9Q29wcGVycGxhdGU7fXtcZjM4XGZuaWxcZmNoYXJz ZXQyNTZcZnBycTJ7XCpccGFub3NlIDAwMDIwMDA2MDQwMzAwMDAwMjAwfUNvcHBlcnBs YXRlIExpZ2h0O317XGYzOVxmbmlsXGZjaGFyc2V0MjU2XGZwcnEye1wqXHBhbm9zZSAw MDAwMDAwMDAwMDAwMDAwMDAwMH1HYWRnZXQ7fQ17XGY0MFxmbmlsXGZjaGFyc2V0MjU2 XGZwcnEye1wqXHBhbm9zZSAwMDAyMDIwNDA0MDMwMzAxMDEwOH1HYXJhbW9uZDt9e1xm NDFcZm5pbFxmY2hhcnNldDI1NlxmcHJxMntcKlxwYW5vc2UgMDAwMjA0MDUwMjA1MDQw NTAyMDN9R2VvcmdpYTt9e1xmNDJcZm5pbFxmY2hhcnNldDI1NlxmcHJxMntcKlxwYW5v c2UgMDAwMjAzMDYwMjA1MDUwNjAyMDJ9SG9lZmxlciBUZXh0O30Ne1xmNDNcZm5pbFxm Y2hhcnNldDJcZnBycTJ7XCpccGFub3NlIDAwMDAwMDAwMDAwMDAwMDAwMDAwfUhvZWZs ZXIgVGV4dCBPcm5hbWVudHM7fXtcZjQ0XGZuaWxcZmNoYXJzZXQyNTZcZnBycTJ7XCpc cGFub3NlIDAwMDIwYjA4MDYwMzA5MDIwNTAyfUltcGFjdDt9e1xmNDVcZm5pbFxmY2hh cnNldDI1NlxmcHJxMntcKlxwYW5vc2UgMDAwMDAwMDAwMDAwMDAwMDAwMDB9THVjaWRh IEJsYWNrbGV0dGVyO30Ne1xmNDZcZm5pbFxmY2hhcnNldDI1NlxmcHJxMntcKlxwYW5v c2UgMDAwMjA0MDYwMjA1MDUwNTAyMDN9THVjaWRhIEJyaWdodDt9e1xmNDdcZm5pbFxm Y2hhcnNldDI1NlxmcHJxMntcKlxwYW5vc2UgMDAwMzAxMDEwMTAxMDEwMTAxMDF9THVj aWRhIENhbGxpZ3JhcGh5O317XGY0OFxmbmlsXGZjaGFyc2V0MjU2XGZwcnEye1wqXHBh bm9zZSAwMDAzMDEwMTAxMDEwMTAxMDEwMX1MdWNpZGEgSGFuZHdyaXRpbmc7fQ17XGY0 OVxmbmlsXGZjaGFyc2V0MjU2XGZwcnEye1wqXHBhbm9zZSAwMDAyMDAwNTAwMDAwMDAw MDAwMH1Nb25hY287fXtcZjUwXGZuaWxcZmNoYXJzZXQyNTZcZnBycTJ7XCpccGFub3Nl IDAwMDMwMTAxMDEwMTAyMDEwMTAxfU1vbm90eXBlIENvcnNpdmE7fXtcZjUxXGZuaWxc ZmNoYXJzZXQyXGZwcnEye1wqXHBhbm9zZSAwMDAyMDAwNTAwMDAwMDAwMDAwMH1NVCBF eHRyYTt9DXtcZjUyXGZuaWxcZmNoYXJzZXQyNTZcZnBycTJ7XCpccGFub3NlIDAwMDIw MDA1MDMwNjAwMDAwMjAwfU9wdGltYTt9e1xmNTNcZm5pbFxmY2hhcnNldDI1NlxmcHJx MntcKlxwYW5vc2UgMDAwMjAwMGIwMzAwMDAwMDAyMDB9T3B0aW1hIEV4dHJhQmxhY2s7 fXtcZjU0XGZuaWxcZmNoYXJzZXQyNTZcZnBycTJ7XCpccGFub3NlIDAwMDIwMDA1MDAw MDAwMDAwMDAwfVBhbGF0aW5vO30Ne1xmNTVcZm5pbFxmY2hhcnNldDI1NlxmcHJxMntc KlxwYW5vc2UgMDAwMDAwMDAwMDAwMDAwMDAwMDB9U2FuZDt9e1xmNTZcZm5pbFxmY2hh cnNldDI1NlxmcHJxMntcKlxwYW5vc2UgMDAwMjBkMDUwMjAyMDIwNDAyMDJ9U2tpYTt9 e1xmNTdcZm5pbFxmY2hhcnNldDI1NlxmcHJxMntcKlxwYW5vc2UgMDAwMDAwMDAwMDAw MDAwMDAwMDB9VGVjaG5vO30Ne1xmNThcZm5pbFxmY2hhcnNldDI1NlxmcHJxMntcKlxw YW5vc2UgMDAwMjAwMDUwMDAwMDAwMDAwMDB9VGV4dGlsZTt9e1xmNTlcZm5pbFxmY2hh cnNldDI1NlxmcHJxMntcKlxwYW5vc2UgMDAwMjBiMDYwMzAyMDIwMjAyMDJ9VHJlYnVj aGV0IE1TO317XGY2MFxmbmlsXGZjaGFyc2V0MlxmcHJxMntcKlxwYW5vc2UgMDAwNTAz MDEwMjAxMDUwOTA2MDd9V2ViZGluZ3M7fQ17XGY2MVxmbmlsXGZjaGFyc2V0MlxmcHJx MntcKlxwYW5vc2UgMDAwNTAyMDEwMjAxMDUwNzA3MDd9V2luZ2RpbmdzIDI7fXtcZjYy XGZuaWxcZmNoYXJzZXQyXGZwcnEye1wqXHBhbm9zZSAwMDA1MDQwMTAyMDEwODA3MDcw N31XaW5nZGluZ3MgMzt9e1xmNjNcZm5pbFxmY2hhcnNldDJcZnBycTJ7XCpccGFub3Nl IDAwMDUwMjAxMDIwMTA3MDQwMjA2fVphcGYgRGluZ2JhdHM7fQ17XGY2NFxmbmlsXGZj aGFyc2V0ODhcZnBycTJ7XCpccGFub3NlIDAwMDIwMDA1MDAwMDAwMDAwMDAwfUNvdXJp ZXIgQ0U7fXtcZjY1XGZuaWxcZmNoYXJzZXQ4OFxmcHJxMntcKlxwYW5vc2UgMDAwMjBi MDUwMzAzMDQwNDA0MDJ9R2VuZXZhIENFO317XGY2NlxmbmlsXGZjaGFyc2V0ODhcZnBy cTJ7XCpccGFub3NlIDAwMDIwMDA1MDAwMDAwMDAwMDAwfUhlbHZldGljYSBDRTt9DXtc ZjY3XGZuaWxcZmNoYXJzZXQ4OFxmcHJxMntcKlxwYW5vc2UgMDAwMjAwMDUwMDAwMDAw MDAwMDB9TW9uYWNvIENFO317XGY2OFxmbmlsXGZjaGFyc2V0ODhcZnBycTJ7XCpccGFu b3NlIDAwMDIwMDA1MDAwMDAwMDAwMDAwfVRpbWVzIENFO317XGY2OVxmbmlsXGZjaGFy c2V0ODlcZnBycTJ7XCpccGFub3NlIDAwMDIwYjA2MDAwNDA1MDIwMjAyfUx1Y2lkYSBH cmFuZGUgQ1k7fQ17XGY3MFxmbmlsXGZjaGFyc2V0ODFcZnBycTJ7XCpccGFub3NlIDAw MDIwMDA1MDAwMDAwMDAwMDAwfUFwcGxlIExpU3VuZyBMaWdodDt9e1xmNzFcZm5pbFxm Y2hhcnNldDgxXGZwcnEye1wqXHBhbm9zZSAwMDAyMDEwNjAxMDAwMTAxMDEwMX1CaWF1 S2FpO317XGY3MlxmbmlsXGZjaGFyc2V0ODFcZnBycTIgXCdjNFwnZDdcJ2E3XCdiYSBQ cm87fXtcZjczXGZuaWxcZmNoYXJzZXQ4MVxmcHJxMiBcJ2M0XCdkN1wnYjZcJ2MyIFBy bzt9DXtcZjc0XGZuaWxcZmNoYXJzZXQ4MFxmcHJxMntcKlxwYW5vc2UgMDAwMjAwMDUw MDAwMDAwMDAwMDB9RmFuZyBTb25nO317XGY3NVxmbmlsXGZjaGFyc2V0ODBcZnBycTIg R0IxODAzMCBCaXRtYXA7fXtcZjc2XGZuaWxcZmNoYXJzZXQ4MFxmcHJxMntcKlxwYW5v c2UgMDAwMjAwMDUwMDAwMDAwMDAwMDB9S2FpO317XGY3N1xmbmlsXGZjaGFyc2V0ODBc ZnBycTJ7XCpccGFub3NlIDAwMDIwMDA1MDAwMDAwMDAwMDAwfVNvbmc7fQ17XGY3OFxm bmlsXGZjaGFyc2V0ODBcZnBycTIgXCdiYlwnYWFcJ2NlXCdjNFwnYjdcJ2MyXCdjYlwn Y2U7fXtcZjc5XGZuaWxcZmNoYXJzZXQ4MFxmcHJxMiBcJ2JiXCdhYVwnY2VcJ2M0XCdi ZlwnYWNcJ2NjXCdlNTt9e1xmODBcZm5pbFxmY2hhcnNldDgwXGZwcnEyIFwnYmJcJ2Fh XCdjZVwnYzRcJ2NiXCdjZVwnY2NcJ2U1O30Ne1xmODFcZm5pbFxmY2hhcnNldDc4XGZw cnEyIFwnODNxXCc4M1wnODlcJzgzTVwnODNtXCc4YXBcJzgzUyBQcm8gVzM7fXtcZjgy XGZuaWxcZmNoYXJzZXQ3OFxmcHJxMiBcJzgzcVwnODNcJzg5XCc4M01cJzgzbVwnOGFw XCc4M1MgUHJvIFc2O317XGY4M1xmbmlsXGZjaGFyc2V0NzlcZnBycTIgI1BDXCdiOFwn ZWRcJ2MxXCdiNjt9e1xmODRcZm5pbFxmY2hhcnNldDc5XGZwcnEyICNcJ2IxXCdjM1wn YmNcJ2FkXCdjM1wnYmM7fQ17XGY4NVxmbmlsXGZjaGFyc2V0NzlcZnBycTIgI1wnYzdc J2NhXCdiMVwnZTJcJ2MzXCdiYzt9e1xmODZcZm5pbFxmY2hhcnNldDc5XGZwcnEyICNc J2M3XCdlY1wnYjVcJ2U1XCdiNlwnZjNcJ2MwXCdjZUE7fXtcZjg3XGZuaWxcZmNoYXJz ZXQ3OVxmcHJxMntcKlxwYW5vc2UgMDAwMjAwMDUwMDAwMDAwMDAwMDB9QXBwbGVNeXVu Z2pvO317XGY4OFxmbmlsXGZjaGFyc2V0MjU2XGZwcnEyIFZUMTAwO30NfXtcKlx1ZHtc Zm9udHRibHtcZjBcZm5pbFxmY2hhcnNldDI1NlxmcHJxMntcKlxwYW5vc2UgMDAwMjAy MDYwMzA1MDQwNTAyMDN9VGltZXMgTmV3IFJvbWFuO317XGYxXGZuaWxcZmNoYXJzZXQy NTZcZnBycTJ7XCpccGFub3NlIDAwMDIwYjA2MDQwMjAyMDIwMjAyfUFyaWFsO317XGYy XGZuaWxcZmNoYXJzZXQyNTZcZnBycTJ7XCpccGFub3NlIDAwMDIwNzAzMDkwMjAyMDUw MjA0fUNvdXJpZXIgTmV3O30Ne1xmM1xmbmlsXGZjaGFyc2V0MlxmcHJxMntcKlxwYW5v c2UgMDAwMjAwMDUwMDAwMDAwMDAwMDB9U3ltYm9sO317XGY0XGZuaWxcZmNoYXJzZXQy NTZcZnBycTJ7XCpccGFub3NlIDAwMDIwMDA1MDAwMDAwMDAwMDAwfVRpbWVzO317XGY1 XGZuaWxcZmNoYXJzZXQyNTZcZnBycTJ7XCpccGFub3NlIDAwMDIwMDA1MDAwMDAwMDAw MDAwfUhlbHZldGljYTt9DXtcZjZcZm5pbFxmY2hhcnNldDI1NlxmcHJxMntcKlxwYW5v c2UgMDAwMjAwMDUwMDAwMDAwMDAwMDB9Q291cmllcjt9e1xmN1xmbmlsXGZjaGFyc2V0 MjU2XGZwcnEyIEdlbmV2YTt9e1xmOFxmcm9tYW5cZmNoYXJzZXQ3N1xmcHJxMntcKlxw YW5vc2UgMDAwMDAwMDAwMDAwMDAwMDAwMDB9VG1zIFJtbjt9e1xmOVxmc3dpc3NcZmNo YXJzZXQ3N1xmcHJxMntcKlxwYW5vc2UgMDAwMDAwMDAwMDAwMDAwMDAwMDB9SGVsdjt9 DXtcZjEwXGZyb21hblxmY2hhcnNldDc3XGZwcnEye1wqXHBhbm9zZSAwMDAwMDAwMDAw MDAwMDAwMDAwMH1NUyBTZXJpZjt9e1xmMTFcZnN3aXNzXGZjaGFyc2V0NzdcZnBycTJ7 XCpccGFub3NlIDAwMDAwMDAwMDAwMDAwMDAwMDAwfU1TIFNhbnMgU2VyaWY7fXtcZjEy XGZuaWxcZmNoYXJzZXQyNTZcZnBycTJ7XCpccGFub3NlIDAwMDIwMjA1MDIwNjAzMDUw NjAyfU5ldyBZb3JrO30Ne1xmMTNcZnN3aXNzXGZjaGFyc2V0NzdcZnBycTJ7XCpccGFu b3NlIDAwMDAwMDAwMDAwMDAwMDAwMDAwfVN5c3RlbTt9e1xmMTRcZm5pbFxmY2hhcnNl dDJcZnBycTJ7XCpccGFub3NlIDAwMDUwMjAxMDIwMTA4MDQwODA3fVdpbmdkaW5nczt9 e1xmMTVcZnJvbWFuXGZjaGFyc2V0MTI4XGZwcnExe1wqXHBhbm9zZSAwMDAwMDAwMDAw MDAwMDAwMDAwMH1cdS0yMTEgX1x1LTIwNSBfIFx1MjYxMjYgX1x1MjYzOTcgXzt9DXtc ZjE2XGZuaWxcZmNoYXJzZXQxMjlcZnBycTF7XCpccGFub3NlIDAwMDAwMDAwMDAwMDAw MDAwMDAwfVx1LTE3Mzg4IF9cdS0xMjA3NSBfO317XGYxN1xmbmlsXGZjaGFyc2V0MTM0 XGZwcnEye1wqXHBhbm9zZSAwMDAwMDAwMDAwMDAwMDAwMDAwMH1cdTIzNDM1IF9cdTIw MzA3IF87fQ17XGYxOFxmbmlsXGZjaGFyc2V0MTM2XGZwcnEye1wqXHBhbm9zZSAwMDAw MDAwMDAwMDAwMDAwMDAwMH1cdTI2MDMyIF9cdTMyMDQ4IF9cdTI2MTI2IF9cdS0yNTkw MCBfO317XGYxOVxmbW9kZXJuXGZjaGFyc2V0MTI4XGZwcnExe1wqXHBhbm9zZSAwMDAw MDAwMDAwMDAwMDAwMDAwMH1cdS0yMTEgX1x1LTIwNSBfIFx1MTI0NjggX1x1MTI0NzEg X1x1MTI0ODMgX1x1MTI0NjMgXzt9DXtcZjIwXGZyb21hblxmY2hhcnNldDc3XGZwcnEy e1wqXHBhbm9zZSAwMDAyMDQwNjA0MDUwNTA1MDIwM31DZW50dXJ5O317XGYyMVxmbmls XGZjaGFyc2V0MjU2XGZwcnEye1wqXHBhbm9zZSAwMDAyMGIwNjA0MDMwNTA0MDQwMn1W ZXJkYW5hO317XGYyMlxmbmlsXGZjaGFyc2V0MjU2XGZwcnEye1wqXHBhbm9zZSAwMDAy MGIwNjA0MDMwNTA0MDQwMn1UYWhvbWE7fQ17XGYyM1xmbmlsXGZjaGFyc2V0MlxmcHJx MntcKlxwYW5vc2UgMDAwMTAxMDYwMTAxMDEwMTAxMDF9TW9ub3R5cGUgU29ydHM7fXtc ZjI0XGZuaWxcZmNoYXJzZXQyNTZcZnBycTJ7XCpccGFub3NlIDAwMDIwYjA2MDAwNDA1 MDIwMjAyfUx1Y2lkYSBHcmFuZGU7fXtcZjI1XGZuaWxcZmNoYXJzZXQyNTZcZnBycTJ7 XCpccGFub3NlIDAwMDIwYjA1MDkwMDAwMDAwMDAwfUFuZGFsZSBNb25vO30Ne1xmMjZc Zm5pbFxmY2hhcnNldDI1NlxmcHJxMntcKlxwYW5vc2UgMDAwMzAyMDcwMjA0MDUwNjA2 MDV9QXBwbGUgQ2hhbmNlcnk7fXtcZjI3XGZuaWxcZmNoYXJzZXQyNTZcZnBycTJ7XCpc cGFub3NlIDAwMDIwYjBhMDQwMjAxMDIwMjAyfUFyaWFsIEJsYWNrO317XGYyOFxmbmls XGZjaGFyc2V0MjU2XGZwcnEye1wqXHBhbm9zZSAwMDAyMGIwNTA2MDIwMjAyMDMwMn1B cmlhbCBOYXJyb3c7fQ17XGYyOVxmbmlsXGZjaGFyc2V0MjU2XGZwcnEye1wqXHBhbm9z ZSAwMDAyMGYwNzA0MDMwNTA0MDMwMn1BcmlhbCBSb3VuZGVkIE1UIEJvbGQ7fXtcZjMw XGZuaWxcZmNoYXJzZXQyNTZcZnBycTJ7XCpccGFub3NlIDAwMDIwMjA1MDIwNzA0MDEw MjAzfUJhc2tlcnZpbGxlO317XGYzMVxmbmlsXGZjaGFyc2V0MjU2XGZwcnEye1wqXHBh bm9zZSAwMDAyMDIwNzAyMDcwNDAwMDIwMn1CYXNrZXJ2aWxsZSBTZW1pYm9sZDt9DXtc ZjMyXGZuaWxcZmNoYXJzZXQyNTZcZnBycTJ7XCpccGFub3NlIDAwMDIwMDA2MDMwOTAw MDAwMjAwfUJpZyBDYXNsb247fXtcZjMzXGZuaWxcZmNoYXJzZXQyNTZcZnBycTJ7XCpc cGFub3NlIDAwMDIwMDA1MDAwMDAwMDAwMDAwfUNhcGl0YWxzO317XGYzNFxmbmlsXGZj aGFyc2V0MjU2XGZwcnEye1wqXHBhbm9zZSAwMDAwMDAwMDAwMDAwMDAwMDAwMH1DaGFy Y29hbDt9DXtcZjM1XGZuaWxcZmNoYXJzZXQyNTZcZnBycTJ7XCpccGFub3NlIDAwMDIw YjA4MDYwODA2MDQwNDAyfUNoaWNhZ287fXtcZjM2XGZuaWxcZmNoYXJzZXQyNTZcZnBy cTJ7XCpccGFub3NlIDAwMDMwZjA3MDIwMzAzMDIwMjAyfUNvbWljIFNhbnMgTVM7fXtc ZjM3XGZuaWxcZmNoYXJzZXQyNTZcZnBycTJ7XCpccGFub3NlIDAwMDIwMDA1MDQwMDAw MDAwMjAwfUNvcHBlcnBsYXRlO30Ne1xmMzhcZm5pbFxmY2hhcnNldDI1NlxmcHJxMntc KlxwYW5vc2UgMDAwMjAwMDYwNDAzMDAwMDAyMDB9Q29wcGVycGxhdGUgTGlnaHQ7fXtc ZjM5XGZuaWxcZmNoYXJzZXQyNTZcZnBycTJ7XCpccGFub3NlIDAwMDAwMDAwMDAwMDAw MDAwMDAwfUdhZGdldDt9e1xmNDBcZm5pbFxmY2hhcnNldDI1NlxmcHJxMntcKlxwYW5v c2UgMDAwMjAyMDQwNDAzMDMwMTAxMDh9R2FyYW1vbmQ7fQ17XGY0MVxmbmlsXGZjaGFy c2V0MjU2XGZwcnEye1wqXHBhbm9zZSAwMDAyMDQwNTAyMDUwNDA1MDIwM31HZW9yZ2lh O317XGY0MlxmbmlsXGZjaGFyc2V0MjU2XGZwcnEye1wqXHBhbm9zZSAwMDAyMDMwNjAy MDUwNTA2MDIwMn1Ib2VmbGVyIFRleHQ7fXtcZjQzXGZuaWxcZmNoYXJzZXQyXGZwcnEy e1wqXHBhbm9zZSAwMDAwMDAwMDAwMDAwMDAwMDAwMH1Ib2VmbGVyIFRleHQgT3JuYW1l bnRzO30Ne1xmNDRcZm5pbFxmY2hhcnNldDI1NlxmcHJxMntcKlxwYW5vc2UgMDAwMjBi MDgwNjAzMDkwMjA1MDJ9SW1wYWN0O317XGY0NVxmbmlsXGZjaGFyc2V0MjU2XGZwcnEy e1wqXHBhbm9zZSAwMDAwMDAwMDAwMDAwMDAwMDAwMH1MdWNpZGEgQmxhY2tsZXR0ZXI7 fXtcZjQ2XGZuaWxcZmNoYXJzZXQyNTZcZnBycTJ7XCpccGFub3NlIDAwMDIwNDA2MDIw NTA1MDUwMjAzfUx1Y2lkYSBCcmlnaHQ7fQ17XGY0N1xmbmlsXGZjaGFyc2V0MjU2XGZw cnEye1wqXHBhbm9zZSAwMDAzMDEwMTAxMDEwMTAxMDEwMX1MdWNpZGEgQ2FsbGlncmFw aHk7fXtcZjQ4XGZuaWxcZmNoYXJzZXQyNTZcZnBycTJ7XCpccGFub3NlIDAwMDMwMTAx MDEwMTAxMDEwMTAxfUx1Y2lkYSBIYW5kd3JpdGluZzt9e1xmNDlcZm5pbFxmY2hhcnNl dDI1NlxmcHJxMntcKlxwYW5vc2UgMDAwMjAwMDUwMDAwMDAwMDAwMDB9TW9uYWNvO30N e1xmNTBcZm5pbFxmY2hhcnNldDI1NlxmcHJxMntcKlxwYW5vc2UgMDAwMzAxMDEwMTAx MDIwMTAxMDF9TW9ub3R5cGUgQ29yc2l2YTt9e1xmNTFcZm5pbFxmY2hhcnNldDJcZnBy cTJ7XCpccGFub3NlIDAwMDIwMDA1MDAwMDAwMDAwMDAwfU1UIEV4dHJhO317XGY1Mlxm bmlsXGZjaGFyc2V0MjU2XGZwcnEye1wqXHBhbm9zZSAwMDAyMDAwNTAzMDYwMDAwMDIw MH1PcHRpbWE7fQ17XGY1M1xmbmlsXGZjaGFyc2V0MjU2XGZwcnEye1wqXHBhbm9zZSAw MDAyMDAwYjAzMDAwMDAwMDIwMH1PcHRpbWEgRXh0cmFCbGFjazt9e1xmNTRcZm5pbFxm Y2hhcnNldDI1NlxmcHJxMntcKlxwYW5vc2UgMDAwMjAwMDUwMDAwMDAwMDAwMDB9UGFs YXRpbm87fXtcZjU1XGZuaWxcZmNoYXJzZXQyNTZcZnBycTJ7XCpccGFub3NlIDAwMDAw MDAwMDAwMDAwMDAwMDAwfVNhbmQ7fQ17XGY1NlxmbmlsXGZjaGFyc2V0MjU2XGZwcnEy e1wqXHBhbm9zZSAwMDAyMGQwNTAyMDIwMjA0MDIwMn1Ta2lhO317XGY1N1xmbmlsXGZj aGFyc2V0MjU2XGZwcnEye1wqXHBhbm9zZSAwMDAwMDAwMDAwMDAwMDAwMDAwMH1UZWNo bm87fXtcZjU4XGZuaWxcZmNoYXJzZXQyNTZcZnBycTJ7XCpccGFub3NlIDAwMDIwMDA1 MDAwMDAwMDAwMDAwfVRleHRpbGU7fQ17XGY1OVxmbmlsXGZjaGFyc2V0MjU2XGZwcnEy e1wqXHBhbm9zZSAwMDAyMGIwNjAzMDIwMjAyMDIwMn1UcmVidWNoZXQgTVM7fXtcZjYw XGZuaWxcZmNoYXJzZXQyXGZwcnEye1wqXHBhbm9zZSAwMDA1MDMwMTAyMDEwNTA5MDYw N31XZWJkaW5nczt9e1xmNjFcZm5pbFxmY2hhcnNldDJcZnBycTJ7XCpccGFub3NlIDAw MDUwMjAxMDIwMTA1MDcwNzA3fVdpbmdkaW5ncyAyO30Ne1xmNjJcZm5pbFxmY2hhcnNl dDJcZnBycTJ7XCpccGFub3NlIDAwMDUwNDAxMDIwMTA4MDcwNzA3fVdpbmdkaW5ncyAz O317XGY2M1xmbmlsXGZjaGFyc2V0MlxmcHJxMntcKlxwYW5vc2UgMDAwNTAyMDEwMjAx MDcwNDAyMDZ9WmFwZiBEaW5nYmF0czt9e1xmNjRcZm5pbFxmY2hhcnNldDg4XGZwcnEy e1wqXHBhbm9zZSAwMDAyMDAwNTAwMDAwMDAwMDAwMH1Db3VyaWVyIENFO30Ne1xmNjVc Zm5pbFxmY2hhcnNldDg4XGZwcnEye1wqXHBhbm9zZSAwMDAyMGIwNTAzMDMwNDA0MDQw Mn1HZW5ldmEgQ0U7fXtcZjY2XGZuaWxcZmNoYXJzZXQ4OFxmcHJxMntcKlxwYW5vc2Ug MDAwMjAwMDUwMDAwMDAwMDAwMDB9SGVsdmV0aWNhIENFO317XGY2N1xmbmlsXGZjaGFy c2V0ODhcZnBycTJ7XCpccGFub3NlIDAwMDIwMDA1MDAwMDAwMDAwMDAwfU1vbmFjbyBD RTt9DXtcZjY4XGZuaWxcZmNoYXJzZXQ4OFxmcHJxMntcKlxwYW5vc2UgMDAwMjAwMDUw MDAwMDAwMDAwMDB9VGltZXMgQ0U7fXtcZjY5XGZuaWxcZmNoYXJzZXQ4OVxmcHJxMntc KlxwYW5vc2UgMDAwMjBiMDYwMDA0MDUwMjAyMDJ9THVjaWRhIEdyYW5kZSBDWTt9e1xm NzBcZm5pbFxmY2hhcnNldDgxXGZwcnEye1wqXHBhbm9zZSAwMDAyMDAwNTAwMDAwMDAw MDAwMH1BcHBsZSBMaVN1bmcgTGlnaHQ7fQ17XGY3MVxmbmlsXGZjaGFyc2V0ODFcZnBy cTJ7XCpccGFub3NlIDAwMDIwMTA2MDEwMDAxMDEwMTAxfUJpYXVLYWk7fXtcZjcyXGZu aWxcZmNoYXJzZXQ4MVxmcHJxMiBcdTIwNzkxIF9cdTIzNDM1IF8gUHJvO317XGY3M1xm bmlsXGZjaGFyc2V0ODFcZnBycTIgXHUyMDc5MSBfXHUtMjQ4NzkgXyBQcm87fXtcZjc0 XGZuaWxcZmNoYXJzZXQ4MFxmcHJxMntcKlxwYW5vc2UgMDAwMjAwMDUwMDAwMDAwMDAw MDB9RmFuZyBTb25nO30Ne1xmNzVcZm5pbFxmY2hhcnNldDgwXGZwcnEyIEdCMTgwMzAg Qml0bWFwO317XGY3NlxmbmlsXGZjaGFyc2V0ODBcZnBycTJ7XCpccGFub3NlIDAwMDIw MDA1MDAwMDAwMDAwMDAwfUthaTt9e1xmNzdcZm5pbFxmY2hhcnNldDgwXGZwcnEye1wq XHBhbm9zZSAwMDAyMDAwNTAwMDAwMDAwMDAwMH1Tb25nO317XGY3OFxmbmlsXGZjaGFy c2V0ODBcZnBycTIgXHUyMTMyNiBfXHUyNTk5MSBfXHUyMDIyMyBfXHUyMzQzNSBfO30N e1xmNzlcZm5pbFxmY2hhcnNldDgwXGZwcnEyIFx1MjEzMjYgX1x1MjU5OTEgX1x1MjY5 OTkgX1x1MjAzMDcgXzt9e1xmODBcZm5pbFxmY2hhcnNldDgwXGZwcnEyIFx1MjEzMjYg X1x1MjU5OTEgX1x1MjM0MzUgX1x1MjAzMDcgXzt9e1xmODFcZm5pbFxmY2hhcnNldDc4 XGZwcnEyIFx1MTI0OTggX1x1MTI1MjEgX1x1MTI0NjIgX1x1MTI0OTQgX1x1LTMwMjU0 IF9cdTEyNDY4IF8gUHJvIFczO30Ne1xmODJcZm5pbFxmY2hhcnNldDc4XGZwcnEyIFx1 MTI0OTggX1x1MTI1MjEgX1x1MTI0NjIgX1x1MTI0OTQgX1x1LTMwMjU0IF9cdTEyNDY4 IF8gUHJvIFc2O317XGY4M1xmbmlsXGZjaGFyc2V0NzlcZnBycTIgI1BDXHUtMTc3ODcg X1x1LTE0MjI0IF87fXtcZjg0XGZuaWxcZmNoYXJzZXQ3OVxmcHJxMiAjXHUtMjExMTkg X1x1LTE2MTAwIF9cdS0xMzEzMiBfO30Ne1xmODVcZm5pbFxmY2hhcnNldDc5XGZwcnEy ICNcdS0xMDk0MCBfXHUtMjA5NDQgX1x1LTEzMTMyIF87fXtcZjg2XGZuaWxcZmNoYXJz ZXQ3OVxmcHJxMiAjXHUtMTA3ODAgX1x1LTE5MjM2IF9cdS0xODU2NCBfXHUtMTQ0NzIg X0E7fXtcZjg3XGZuaWxcZmNoYXJzZXQ3OVxmcHJxMntcKlxwYW5vc2UgMDAwMjAwMDUw MDAwMDAwMDAwMDB9QXBwbGVNeXVuZ2pvO317XGY4OFxmbmlsXGZjaGFyc2V0MjU2XGZw cnEyIFZUMTAwO319fX0Ne1xjb2xvcnRibDtccmVkMFxncmVlbjBcYmx1ZTA7XHJlZDBc Z3JlZW4wXGJsdWUyNTU7XHJlZDBcZ3JlZW4yNTVcYmx1ZTI1NTtccmVkMFxncmVlbjI1 NVxibHVlMDtccmVkMjU1XGdyZWVuMFxibHVlMjU1O1xyZWQyNTVcZ3JlZW4wXGJsdWUw O1xyZWQyNTVcZ3JlZW4yNTVcYmx1ZTA7XHJlZDI1NVxncmVlbjI1NVxibHVlMjU1O1xy ZWQwXGdyZWVuMFxibHVlMTI4O1xyZWQwXGdyZWVuMTI4XGJsdWUxMjg7XHJlZDBcZ3Jl ZW4xMjhcYmx1ZTA7DVxyZWQxMjhcZ3JlZW4wXGJsdWUxMjg7XHJlZDEyOFxncmVlbjBc Ymx1ZTA7XHJlZDEyOFxncmVlbjEyOFxibHVlMDtccmVkMTI4XGdyZWVuMTI4XGJsdWUx Mjg7XHJlZDE5MlxncmVlbjE5MlxibHVlMTkyO317XHN0eWxlc2hlZXR7XHFsIFxsaTBc cmkwXHdpZGN0bHBhclxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJp bjBcbGluMFxpdGFwMCANXGxhbmcxMDMzXGxhbmdmZTEwMzNcY2dyaWRcbGFuZ25wMTAz M1xsYW5nZmVucDEwMzMgXHNuZXh0MCBOb3JtYWw7fXtcKlxjczEwIFxhZGRpdGl2ZSBE ZWZhdWx0IFBhcmFncmFwaCBGb250O317XCoNXHRzMTFcdHNyb3dkXHRyZnRzV2lkdGhC M1x0cnBhZGRsMTA4XHRycGFkZHIxMDhcdHJwYWRkZmwzXHRycGFkZGZ0M1x0cnBhZGRm YjNcdHJwYWRkZnIzXHRzY2VsbHdpZHRoZnRzMFx0c3ZlcnRhbHRcdHNicmRydFx0c2Jy ZHJsXHRzYnJkcmJcdHNicmRyclx0c2JyZHJkZ2xcdHNicmRyZGdyXHRzYnJkcmhcdHNi cmRydiANXHFsIFxsaTBccmkwXHdpZGN0bHBhclxhc3BhbHBoYVxhc3BudW1cZmFhdXRv XGFkanVzdHJpZ2h0XHJpbjBcbGluMFxpdGFwMCBcZnMyMFxsYW5nMTAyNFxsYW5nZmUx MDI0XGNncmlkXGxhbmducDEwMjRcbGFuZ2ZlbnAxMDI0IFxzbmV4dDExIE5vcm1hbCBU YWJsZTt9e1xzMTVccWwgXGxpMFxyaTBcd2lkY3RscGFyXGFzcGFscGhhXGFzcG51bVxm YWF1dG9cYWRqdXN0cmlnaHRccmluMFxsaW4wXGl0YXAwIA1cZjZcbGFuZzEwMzNcbGFu Z2ZlMTAzM1xjZ3JpZFxsYW5nbnAxMDMzXGxhbmdmZW5wMTAzMyBcc2Jhc2Vkb24wIFxz bmV4dDE1IFBsYWluIFRleHQ7fXtcKlxjczE2IFxhZGRpdGl2ZSBcZnMxOCBcc2Jhc2Vk b24xMCBhbm5vdGF0aW9uIHJlZmVyZW5jZTt9e1xzMTdccWwgXGxpMFxyaTBcd2lkY3Rs cGFyXGFzcGFscGhhXGFzcG51bVxmYWF1dG9cYWRqdXN0cmlnaHRccmluMFxsaW4wXGl0 YXAwIA1cbGFuZzEwMzNcbGFuZ2ZlMTAzM1xjZ3JpZFxsYW5nbnAxMDMzXGxhbmdmZW5w MTAzMyBcc2Jhc2Vkb24wIFxzbmV4dDE3IGFubm90YXRpb24gdGV4dDt9e1xzMThccWwg XGxpMFxyaTBcd2lkY3RscGFyXGFzcGFscGhhXGFzcG51bVxmYWF1dG9cYWRqdXN0cmln aHRccmluMFxsaW4wXGl0YXAwIFxsYW5nMTAzM1xsYW5nZmUxMDMzXGNncmlkXGxhbmdu cDEwMzNcbGFuZ2ZlbnAxMDMzIFxzYmFzZWRvbjE3IFxzbmV4dDE3IA1hbm5vdGF0aW9u IHN1YmplY3Q7fXtcczE5XHFsIFxsaTBccmkwXHdpZGN0bHBhclxhc3BhbHBoYVxhc3Bu dW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJpbjBcbGluMFxpdGFwMCBcZjI0XGZzMThcbGFu ZzEwMzNcbGFuZ2ZlMTAzM1xjZ3JpZFxsYW5nbnAxMDMzXGxhbmdmZW5wMTAzMyBcc2Jh c2Vkb24wIFxzbmV4dDE5IEJhbGxvb24gVGV4dDt9fXtcKlxyZXZ0Ymwge1Vua25vd247 fXtTdGVwaGVuIEtlbnQ7fX17XGluZm8Ne1x0aXRsZSBSb3V0aW5nIFByb3RvY29sIFNl Y3VyaXR5ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQn17XGF1dGhvciBTdGVw aGVuIEtlbnR9e1xvcGVyYXRvciBTdGVwaGVuIEtlbnR9e1xjcmVhdGltXHlyMjAwNVxt bzNcZHk4XGhyMTNcbWluNDV9e1xyZXZ0aW1ceXIyMDA1XG1vM1xkeThcaHIxM1xtaW40 NX17XHZlcnNpb24yfXtcZWRtaW5zMH17XG5vZnBhZ2VzMzF9e1xub2Z3b3JkczQ0MDh9 e1xub2ZjaGFyczI1MTI3fQ17XCpcY29tcGFueSBCQk4gVGVjaG5vbG9naWVzfXtcbm9m Y2hhcnN3czMwODU3fXtcdmVybjI0NzA1fX1ccGFwZXJoMTU4NTRcbWFyZ2wzNTlcbWFy Z3IzNTkgXHdpZG93Y3RybFxmdG5ialxhZW5kZG9jXHJldmlzaW9uc1xub3hsYXR0b3ll blxleHBzaHJ0blxub3VsdHJsc3BjXGRudGJsbnNiZGJcbm9zcGFjZWZvcnVsXGZvcm1z aGFkZVxob3J6ZG9jXGRnaHNwYWNlMTgwXGRndnNwYWNlMTgwXGRnaG9yaWdpbjE3MDFc ZGd2b3JpZ2luMTk4NA1cZGdoc2hvdzBcZGd2c2hvdzBcamV4cGFuZFx2aWV3a2luZDFc dmlld3NjYWxlMTAwXHBnYnJkcmhlYWRccGdicmRyZm9vdFxzcGx5dHduaW5lXGZ0bmx5 dHduaW5lXGh0bWF1dHNwXG5vbG5odGFkanRibFx1c2VsdGJhbG5cYWxudGJsaW5kXGx5 dGNhbGN0Ymx3ZFxseXR0YmxydGdyXGxuYnJrcnVsZVxub2Jya3dycHRibFxyc2lkcm9v dDYwMzM3NDMgXGZldDBcc2VjdGQgDVxsaW5leDBcZW5kbmhlcmVcc2VjdGRlZmF1bHRj bFxzZWN0cnNpZDEzOTc2NDUxXHNmdG5iaiB7XCpccG5zZWNsdmwxXHBudWNybVxwbnN0 YXJ0MVxwbmluZGVudDcyMFxwbmhhbmd7XHBudHh0YSAufX17XCpccG5zZWNsdmwyXHBu dWNsdHJccG5zdGFydDFccG5pbmRlbnQ3MjBccG5oYW5ne1xwbnR4dGEgLn19e1wqXHBu c2VjbHZsM1xwbmRlY1xwbnN0YXJ0MVxwbmluZGVudDcyMFxwbmhhbmd7XHBudHh0YSAu fX17XCpccG5zZWNsdmw0DVxwbmxjbHRyXHBuc3RhcnQxXHBuaW5kZW50NzIwXHBuaGFu Z3tccG50eHRhICl9fXtcKlxwbnNlY2x2bDVccG5kZWNccG5zdGFydDFccG5pbmRlbnQ3 MjBccG5oYW5ne1xwbnR4dGIgKH17XHBudHh0YSApfX17XCpccG5zZWNsdmw2XHBubGNs dHJccG5zdGFydDFccG5pbmRlbnQ3MjBccG5oYW5ne1xwbnR4dGIgKH17XHBudHh0YSAp fX17XCpccG5zZWNsdmw3XHBubGNybVxwbnN0YXJ0MVxwbmluZGVudDcyMFxwbmhhbmd7 XHBudHh0YiAofQ17XHBudHh0YSApfX17XCpccG5zZWNsdmw4XHBubGNsdHJccG5zdGFy dDFccG5pbmRlbnQ3MjBccG5oYW5ne1xwbnR4dGIgKH17XHBudHh0YSApfX17XCpccG5z ZWNsdmw5XHBubGNybVxwbnN0YXJ0MVxwbmluZGVudDcyMFxwbmhhbmd7XHBudHh0YiAo fXtccG50eHRhICl9fVxwYXJkXHBsYWluIA1cczE1XHFsIFxsaTBccmkwXHdpZGN0bHBh clxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJpbjBcbGluMFxpdGFw MFxwYXJhcnNpZDEzOTc2NDUxIFxmNlxsYW5nMTAzM1xsYW5nZmUxMDMzXGNncmlkXGxh bmducDEwMzNcbGFuZ2ZlbnAxMDMzIHtcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNo YXJyc2lkNjAzMzc0MyANXHBhciANXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hc ZjYgUm91dGluZyBQcm90b2NvbCBTZWN1cml0eSAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEIuIENocmlzdGlhbiwgRWQuDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxs b2NoXGY2IFJlcXVpcmVtZW50cyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEtNQyBUZWxlY29tIFNvbHV0aW9ucw1ccGFyIFxoaWNoXGFmNlxkYmNoXGFm MTVcbG9jaFxmNiBJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgRmViIDIwMDQNXHBhciBcaGljaFxhZjZcZGJj aFxhZjE1XGxvY2hcZjYgRXhwaXJlczogQXVndXN0IDEsIDIwMDQNXHBhciANXHBhciAN XHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgICAgICAgXGhpY2hcYWY2 XGRiY2hcYWYxNVxsb2NoXGY2ICAgICAgICAgICAgICAgQkdQIFNlY3VyaXR5IFJlcXVp cmVtZW50cw1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICAgICAgICAg ICAgICAgICAgICBkcmFmdC1pZXRmLXJwc2VjLWJncHNlY3JlYy0wMQ1ccGFyIA1ccGFy IFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiBTdGF0dXMgb2YgdGhpcyBNZW1vDVxw YXIgDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIEJ5IHN1Ym1pdHRp bmcgdGhpcyBJbnRlcm5ldC1EcmFmdCwgZWFjaCBhdXRob3IgcmVwcmVzZW50cyB0aGF0 IGFueQ1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBhcHBsaWNhYmxl IHBhdGVudCBvciBvdGhlciBJUFIgY2xhaW1zIG9mIHdoaWNoIGhlIG9yIHNoZSBpcyBh d2FyZQ1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBoXGhpY2hcYWY2 XGRiY2hcYWYxNVxsb2NoXGY2IGF2ZSBiZWVuIG9yIHdpbGwgYmUgZGlzY2xvc2VkLCBp biBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiA2IG9mIFJGQw1ccGFyIFxoaWNoXGFmNlxk YmNoXGFmMTVcbG9jaFxmNiAgICAzNjY4Lg1ccGFyIA1ccGFyIFxoaWNoXGFmNlxkYmNo XGFmMTVcbG9jaFxmNiAgICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1l bnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZw1ccGFyIFxoaWNoXGFmNlxkYmNo XGFmMTVcbG9jaFxmNiAgICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQg aXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0DVxwYXIgXGhpY2hcYWY2XGRiY2hc YWYxNVxsb2NoXGY2ICAgIG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdv cmtpblxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiBnIGRvY3VtZW50cyBhcw1ccGFy IFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBJbnRlcm5ldC1EcmFmdHMuDVxw YXIgDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIEludGVybmV0LURy YWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4 IG1vbnRocw1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBhbmQgbWF5 IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1l bnRzIGF0IGFueQ1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICB0aW1l LiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJl ZmVyZW5jZQ1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBtYXRlcmlc aGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVy IHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg1ccGFyIA1ccGFyIFxoaWNoXGFmNlxk YmNoXGFmMTVcbG9jaFxmNiAgICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURy YWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQNXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxv Y2hcZjYgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0 Lg1ccGFyIA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBUaGUgbGlz dCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vz c2VkIGF0DVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIGh0dHA6Ly93 d3cuaWV0Zi5vcmcvc2hhZG9caGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgdy5odG1s Lg1ccGFyIA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBUaGlzIElu dGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIEF1Z3VzdCAxLCAyMDA0Lg1ccGFyIA1c cGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiBDb3B5cmlnaHQgTm90aWNlDVxw YXIgDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIENvcHlyaWdodCAo QykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDQpLiAgQWxsIFJpZ2h0cyBSZXNlcnZl ZC4NXHBhciANXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgQWJzdHJhY3QN XHBhciANXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgVGhlIHNlY3Vy aXR5IG9mIEJHUCBpcyBjcml0aWNhbCB0byB0aGUgcHJvcGVyIG9wZXJhdGlvbiBvZg1c cGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBsYXJnZS1zY2FsZSBpbnRl cm5ldHdvcmtzLCBib3RcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgaCBwdWJsaWMg YW5kIHByaXZhdGUuICBXaGlsZSBzZWN1cmluZw1ccGFyIFxoaWNoXGFmNlxkYmNoXGFm MTVcbG9jaFxmNiAgICB0aGUgaW5mb3JtYXRpb24gdHJhbnNtaXR0ZWQgYmV0d2VlbiB0 d28gQkdQIHNwZWFrZXJzIGlzIGEgcmVsYXRpdmVseQ1ccGFyIFxoaWNoXGFmNlxkYmNo XGFmMTVcbG9jaFxmNiAgICBlYXN5IHRlY2huaWNhbCBtYXR0ZXIsIHNlY3VyaW5nIEJH UCwgYXMgYSByb3V0ZWQgc3lzdGVtLCBpcyBtb3JlDVxwYXIgXGhpY2hcYWY2XGRiY2hc YWYxNVxsb2NoXGY2ICAgIGNvbXBsZXguICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBh IHNldCBvZiByZXF1aXJlbWVudHMgZm9yIHNlY3VyaW5nDVxwYXIgXGhpY2hcYWY2XGRi Y2hcYWYxNVxsb2NoXGY2ICAgIEJHUFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAs IGluY2x1ZGluZyBzZWN1cmluZyBwZWVyaW5nIHJlbGF0aW9uc2hpcHMgYmV0d2VlbiBC R1Agc3BlYWtlcnMsDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIGFu ZCBhdXRoZW50aWNhdGluZyB0aGUgcm91dGluZyBpbmZvcm1hdGlvbiBjYXJyaWVkIHdp dGhpbiBCR1AuDVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIgXGhpY2hc YWY2XGRiY2hcYWYxNVxsb2NoXGY2IENocmlzdGlhbiAgICAgICAgICAgICAgICBFeHBp cmVzIEF1Z3VzdCAxLCAyMDA0ICAgICAgICAgICAgICAgICBbUGFnZSAxXQ1ccGFyIFxw YWdlIA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiBJbnRlcm5ldC1EcmFm dCAgICAgICAgIEJHUCBTZWN1cml0eSBSZXF1aXJlbWVcaGljaFxhZjZcZGJjaFxhZjE1 XGxvY2hcZjYgbnRzICAgICAgICAgICAgICAgIEZlYiAyMDA0DVxwYXIgDVxwYXIgDVxw YXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IDEuICBJbnRyb2R1Y3Rpb24NXHBh ciANXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgMS4xICBTeXN0ZW0gRGVz Y3JpcHRpb24NXHBhciANXHBhciB9XHBhcmQgXHMxNVxxbCBcbGkwXHJpMFx3aWRjdGxw YXJcYXNwYWxwaGFcYXNwbnVtXGZhYXV0b1xzMTVccWwgXGxpMFxyaTBcd2lkY3RscGFy XGFzcGFscGhhXGFzcG51bVxmYWF1dG9ccG5yYXV0aDFccG5yZGF0ZTExODQwNTU5MDRc cG5ybm90MVxhZGp1c3RyaWdodFxyaW4wXGxpbjBcaXRhcDBccGFyYXJzaWQxMzk3NjQ1 MSB7XGRiY2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMgDVxoaWNo XGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBCR1AgaXMgZGVzY3JpYmVkIGluIFJGQ317 XGNmMFxyZXZpc2VkXHJldmF1dGgxXHJldmR0dG0xMTg0MDU1OTA1XGRiY2hcZjE1XGlu c3JzaWQxMzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYxNVxs b2NoXGY2ICB9e1xkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQz IFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAxNzcxIFszXSBhcyBhIH17DVxjZjBc cmV2aXNlZFxyZXZhdXRoMVxyZXZkdHRtMTE4NDA1NTkwNFxkYmNoXGYxNVxpbnNyc2lk MTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxm NiBwYXRoIHZlY3RvciB9e1xkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hhcnJzaWQ2 MDMzNzQzIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiByb3V0aW5nIHByb3RvY29s Ln17DVxjZjBccmV2aXNlZFxyZXZhdXRoMVxyZXZkdHRtMTE4NDA1NTkwNFxkYmNoXGYx NVxpbnNyc2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIA1ccGFyIH1ccGFyZCBcczE1 XHFsIFxsaTBccmkwXHdpZGN0bHBhclxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGFkanVz dHJpZ2h0XHJpbjBcbGluMFxpdGFwMFxwYXJhcnNpZDEzOTc2NDUxIHtcZGJjaFxmMTVc aW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyBcaGljaFxhZjZcZGJjaFxhZjE1 XGxvY2hcZjYgICAgQkdQIHNwZWFrZXJzIGV4Y2hhbmdlIGluZm9ybWF0aW9uIGFib3V0 IHJlYWNoYWJsZSBkZXN0aW5hdGlvbnN9ew1cY2YwXHJldmlzZWRccmV2YXV0aDFccmV2 ZHR0bTExODQwNTU5MDVcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAz Mzc0MyBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgIChleHByZXNzZWQgYXMgYWRk cmVzcyBwcmVmaXhlcykgdmlhIH17XGNmMFxyZXZpc2VkXHJldmF1dGgxXHJldmR0dG0x MTg0MDU1OTA2XGRiY2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMg DVxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiBwYWlyd2lzZSB9e1xkYmNoXGYxNVxp bnNyc2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIFxoaWNoXGFmNlxkYmNoXGFmMTVc bG9jaFxmNiBwXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IGVlcmluZyBzZXNzaW9u fXtcY2YwXHJldmlzZWRccmV2YXV0aDFccmV2ZHR0bTExODQwNTU5MDZcZGJjaFxmMTVc aW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyANXGhpY2hcYWY2XGRiY2hcYWYx NVxsb2NoXGY2IHN9e1xkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMz NzQzIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAuICBPbmNlIHRoaXMgaW5mb3Jt YXRpb24gaGFzDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIGJlZW4g ZXhjaGFuZ2VkLCBlYWNoIEJHUCBzcGVha2VyIGxvY2FsbHkgZGV0ZXJtaW5lcyBhIGxv b3AgZnJlZSBwYXRoDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIHRv IGVhY2ggcmVhY2hhYmxlIGRlc3RpbmF0aW9uLCBiYXNlZCBvbiBsb2NhbCBwb2xpY3ks IHBvbGljeQ1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBpbmRpY2F0 b3JzIChvciBwb2xpY2llcykgY2FycmllZCBpbiB0aGUgdXBkYXRlLCBhbmQgdGhlIEFT IFBhdGgNXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgfXtcY2YwXHJl dmlzZWRccmV2YXV0aDFccmV2ZHR0bTExODQwNTU5MDZcZGJjaFxmMTVcaW5zcnNpZDEz OTc2NDUxXGNoYXJyc2lkNjAzMzc0MyBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYg ZGF0YSB9e1xkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIFxo aWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiBjXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2No XGY2IA1hcnJpZWQgaW4gQkdQIH17XGNmMFxyZXZpc2VkXHJldmF1dGgxXHJldmR0dG0x MTg0MDU1OTA2XGRiY2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMg XGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IFVQREFURSBtZXNzYWdlc317XGRiY2hc ZjE1XGluc3JzaWQxMzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRiY2hc YWYxNVxsb2NoXGY2IC59ew1cY2YwXHJldmlzZWRccmV2YXV0aDFccmV2ZHR0bTExODQw NTU5MDdcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyANXHBh ciB9XHBhcmQgXHMxNVxxbCBcbGkwXHJpMFx3aWRjdGxwYXJcYXNwYWxwaGFcYXNwbnVt XGZhYXV0b1xzMTVccWwgXGxpMFxyaTBcd2lkY3RscGFyXGFzcGFscGhhXGFzcG51bVxm YWF1dG9ccG5yYXV0aDFccG5yZGF0ZTExODQwNTU5MDdccG5ybm90MVxhZGp1c3RyaWdo dFxyaW4wXGxpbjBcaXRhcDBccGFyYXJzaWQxMzk3NjQ1MSB7DVxjZjBccmV2aXNlZFxy ZXZhdXRoMVxyZXZkdHRtMTE4NDA1NTkwN1xkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFc Y2hhcnJzaWQ2MDMzNzQzIA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiBF YWNoIEJHUCBzcGVha2VyIHJlcHJlc2VudHMgYW4gQXV0b25vbW91cyBTeXN0ZW0gKEFT KS4gQWxsIG9mIHRoZSBCR1Agc3BlYWtlcnMgd2l0aGluIGFuIEFTIG9wZXJhdGUgdW5k ZXIgYSBjb21tb24gfXtcY2YwXHJldmlzZWRccmV2YXV0aDFccmV2ZHR0bTExODQwNTU5 MDhcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyBcaGljaFxh ZjZcZGJjaFxhZjE1XGxvY2hcZjYgDWFkbWluaXN0cmF0aXZlIH17XGNmMFxyZXZpc2Vk XHJldmF1dGgxXHJldmR0dG0xMTg0MDU1OTA3XGRiY2hcZjE1XGluc3JzaWQxMzk3NjQ1 MVxjaGFycnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IHBvbGlj eX17XGNmMFxyZXZpc2VkXHJldmF1dGgxXHJldmR0dG0xMTg0MDU1OTA5XGRiY2hcZjE1 XGluc3JzaWQxMzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYx NVxsb2NoXGY2IA0uIDxtYXliZSBhZGQgc29tZSBtb3JlIEJHUCBiYWNrZ3JvdW5kIGlu Zm8gaGVyZSwgYXMgbmVlZGVkIHRvIHN1cHBvcnQgbGF0ZXIgcmVxdWlyZW1lbnRzXGhp Y2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICBkZWZpbml0aW9ucz59e1xkYmNoXGYxNVxp bnNyc2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIA1ccGFyIH1ccGFyZCBcczE1XHFs IFxsaTBccmkwXHdpZGN0bHBhclxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGFkanVzdHJp Z2h0XHJpbjBcbGluMFxpdGFwMFxwYXJhcnNpZDEzOTc2NDUxIHtcZGJjaFxmMTVcaW5z cnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyANXHBhciBcaGljaFxhZjZcZGJjaFxh ZjE1XGxvY2hcZjYgMS4yICBUaHJlYXRzDVxwYXIgDVxwYXIgXGhpY2hcYWY2XGRiY2hc YWYxNVxsb2NoXGY2ICAgIH17XGNmMFxyZXZpc2VkXHJldmF1dGgxXHJldmR0dG0xMTg0 MDU1ODg2XGRiY2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMgXGhp Y2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IFZpb2xhdGlvbnMgb2Ygc2VjdXJpdHkgZm9y fXtcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyBcaGljaFxh ZjZcZGJjaFxhZjE1XGxvY2hcZjYgIH17DVxjZjBccmV2aXNlZFxyZXZhdXRoMVxyZXZk dHRtMTE4NDA1NTg4NVxkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcZGVscnNpZDYwMzM3 NDNcY2hhcnJzaWQ2MDMzNzQzIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiBpbmZv cm1hdGlvbiBhbmQgbmV0d29yayBzeXN0ZW1zfXtcZGJjaFxmMTVcaW5zcnNpZDEzOTc2 NDUxXGNoYXJyc2lkNjAzMzc0MyBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgDSBn ZW5lcmFsbHkgZmFsbCB1bmRlciBvbmUgb2YgdGhlIHRocmVlDVxwYXIgXGhpY2hcYWY2 XGRiY2hcYWYxNVxsb2NoXGY2ICAgIGNhdGVnb3JpZXMgYXMgZGVmaW5lZCBpbiBSRkMg MjE5NiBbMV06DVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIG8gIFVu YXV0aG9yaXplZCBhY2Nlc3MgdG8gcmVzb3VyY2VzIGFuZC9vciBpbmZvcm1hdGlvbg1c cGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBvICBVbmludGVuZGVkIGFu ZC9vciB1bmFcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgdXRob3JpemVkIGRpc2Ns b3N1cmUgb2YgaW5mb3JtYXRpb24NXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hc ZjYgICAgbyAgRGVuaWFsIG9mIHNlcnZpY2V9e1xjZjBccmV2aXNlZFxyZXZhdXRoMVxy ZXZkdHRtMTE4NDA1NTg4NlxkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hhcnJzaWQ2 MDMzNzQzIA1ccGFyIH17XGRiY2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxjaGFycnNpZDYw MzM3NDMgDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIEEgbnVtYmVy IG9mIGF0dGFja3MgY2FuIGJlIHJlYWxpemVkIHdoaWNoLCBpZiBleHBsb2l0ZWQsIGNh biBsZWFkIHRvDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIG9uZSBv ZiB0aGUgYWJvdmUgbWVudGlvbmVkIH17XGNmMFxyZXZpc2VkXHJldmF1dGgxXHJldmR0 dG0xMTg0MDU1ODg2XGRiY2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxjaGFycnNpZDYwMzM3 NDMgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IHNlY3VyaXR5IHZpb2xhdGlvbnN9 e1xkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIA1caGljaFxh ZjZcZGJjaFxhZjE1XGxvY2hcZjYgLiAgfXtcY2YwXHJldmlzZWRccmV2YXV0aDFccmV2 ZHR0bTExODQwNTU4ODZcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAz Mzc0MyBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgQXR0YWNrcyBhZ2FpbnN0IGNv bW11bmljYXRpb25zIH17XGRiY2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxjaGFycnNpZDYw MzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IA1hcmUgdHlwaWNhbGx5IGNs YXNzaWZpZWQNXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgYXMgcGFz c2l2ZSB9e1xjZjBccmV2aXNlZFxyZXZhdXRoMVxyZXZkdHRtMTE4NDA1NTg4N1xkYmNo XGYxNVxpbnNyc2lkMTM5NzY0NTFcZGVscnNpZDYwMzM3NDNcY2hhcnJzaWQ2MDMzNzQz IFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiBvXGhpY2hcYWY2XGRiY2hcYWYxNVxs b2NoXGY2IHIgfXtcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0 MyANXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IGFjdGl2ZSB9e1xjZjBccmV2aXNl ZFxyZXZhdXRoMVxyZXZkdHRtMTE4NDA1NTg4N1xkYmNoXGYxNVxpbnNyc2lkMTM5NzY0 NTFcY2hhcnJzaWQ2MDMzNzQzIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiB3aXJl dGFwcGluZyB9e1xkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQz IFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiANYXR0YWNrcy4gIFBhc3NpdmUgYXR0 YWNrcyBhcmUgb25lcw1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICB3 aGVyZSBhbiBhdHRhY2tlciBzaW1wbHkgfXtcY2YwXHJldmlzZWRccmV2YXV0aDFccmV2 ZHR0bTExODQwNTU4ODdcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAz Mzc0MyBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgb2JzZXJ2ZXMgfXtcZGJjaFxm MTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyBcaGljaFxhZjZcZGJjaFxh ZjE1XGxvY2hcZjYgDWluZm9ybWF0aW9uIH17XGNmMFxyZXZpc2VkXHJldmF1dGgxXHJl dmR0dG0xMTg0MDU1ODg3XGRiY2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxjaGFycnNpZDYw MzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IHRyYXZlcnNpbmcgfXtcZGJj aFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyBcaGljaFxhZjZcZGJj aFxhZjE1XGxvY2hcZjYgdGhlIG5ldHdvcmt9ew1cY2YwXHJldmlzZWRccmV2YXV0aDFc cmV2ZHR0bTExODQwNTU4ODdcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lk NjAzMzc0MyBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgLCB2aW9sYXRpbmcgY29u ZmlkZW50aWFsaXR5fXtcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAz Mzc0MyBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgLiAgQWN0aXZlIGF0dGFja3Mg YXJlDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIG9uZXMgd2hlcmUg dGhlIGF0dGFja2VyIH17XGNmMFxyZXZpc2VkXHJldmF1dGgxXHJldmR0dG0xMTg0MDU1 ODg4XGRiY2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMgXGhpY2hc YWY2XGRiY2hcYWYxNVxsb2NoXGY2IG1vZGlmaWVzIH17XGRiY2hcZjE1XGluc3JzaWQx Mzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2 IGRhdGEgfXsNXGNmMFxyZXZpc2VkXHJldmF1dGgxXHJldmR0dG0xMTg0MDU1ODg4XGRi Y2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRi Y2hcYWYxNVxsb2NoXGY2IGluIHRyYW5zaXQuIFN1Y2ggYXR0YWNrc317XGRiY2hcZjE1 XGluc3JzaWQxMzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYx NVxsb2NoXGY2ICBpbmNsdWRlDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2 ICAgIHJlcFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiBsYXkgYXR0YWNrcywgbWVz c2FnZSBpbnNlcnRpb24sIG1lc3NhZ2UgZGVsZXRpb24sIH17XGNmMFxyZXZpc2VkXHJl dmF1dGgxXHJldmR0dG0xMTg0MDU1ODg4XGRiY2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxj aGFycnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IGFuZCB9ew1c ZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyBcaGljaFxhZjZc ZGJjaFxhZjE1XGxvY2hcZjYgbWVzc2FnZQ1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVc bG9jaFxmNiAgICBtb2RpZmljYXRpb24gfXtcY2YwXHJldmlzZWRccmV2YXV0aDFccmV2 ZHR0bTExODQwNTU4ODhcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAz Mzc0MyBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgYXR0YWNrcy4gfXtcY2YwXHJl dmlzZWRccmV2YXV0aDFccmV2ZHR0bTExODQwNTU4ODlcZGJjaFxmMTVcaW5zcnNpZDEz OTc2NDUxXGNoYXJyc2lkNjAzMzc0MyANXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2 IFNvbWUgYWN0aXZlIGF0dGFja3MgbWF5IGJlIGVmZmVjdGVkIGJ5IHNlbmRpbmcgIG1l c3NhZ2VzIHRvIGEgZGVzdGluYXRpb24gZnJvbSBhbnl3aGVyZSBpbiB0aGUgSW50ZXJu ZXQuIE90aGVyIGFjdGl2ZSBhdHRhY2tzIHJlcXVpcmUgYSB9e1xjZjBccmV2aXNlZFxy ZXZhdXRoMVxyZXZkdHRtMTE4NDA1NTg4OFxkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFc Y2hhcnJzaWQ2MDMzNzQzIA1cbGRibHF1b3RlIH17XGRiY2hcZjE1XGluc3JzaWQxMzk3 NjQ1MVxjaGFycnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IG1h bi1pbi10aGUtbWlkZGxlfXtcY2YwXHJldmlzZWRccmV2YXV0aDFccmV2ZHR0bTExODQw NTU4ODhcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyBccmRi bHF1b3RlIH17XGRiY2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMg DVxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgfXtcY2YwXHJldmlzZWRccmV2YXV0 aDFccmV2ZHR0bTExODQwNTU4OTBcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJy c2lkNjAzMzc0MyBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgY2FwYWJpbGl0eSwg aVxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAuZS4sIHRoZSBhdHRhY2tlciBtdXN0 IGJlIGluIGEgcG9zaXRpb24gd2hlcmUgfXsNXGNmMFxyZXZpc2VkXHJldmF1dGgxXHJl dmR0dG0xMTg0MDU1ODkxXGRiY2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxjaGFycnNpZDYw MzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IHRyYWZmaWMgcGFzc2VzIHRo cm91Z2ggYW4gYXR0YWNrZXItY29udHJvbGxlZCBkZXZpY2V9e1xkYmNoXGYxNVxpbnNy c2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9j aFxmNiAufXsNXGNmMFxyZXZpc2VkXHJldmF1dGgxXHJldmR0dG0xMTg0MDU1ODkzXGRi Y2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRi Y2hcYWYxNVxsb2NoXGY2ICBBdHRhY2tzIGFnYWluc3QgQkdQIG1heSBiZSB1c2VkIGJ5 IGF0dGFja2VyIHRvIGZhY2lsaXRhdGUgYSB3aWR9ew1cY2YwXHJldmlzZWRccmV2YXV0 aDFccmV2ZHR0bTExODQwNTU4OTVcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJy c2lkNjAzMzc0MyBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgZX17XGNmMFxyZXZp c2VkXHJldmF1dGgxXHJldmR0dG0xMTg0MDU1ODkzXGRiY2hcZjE1XGluc3JzaWQxMzk3 NjQ1MVxjaGFycnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IA0g dmFyaWV0eSBvZiBhY3RpdmUgb3IgcGFzc2l2ZSB3aXJldGFwcGluZyBhdHRhY2tzLn17 XGRiY2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMgXGhpY2hcYWY2 XGRiY2hcYWYxNVxsb2NoXGY2IC4NXHBhciB9XHBhcmQgXHMxNVxxbCBcbGkwXHJpMFx3 aWRjdGxwYXJcYXNwYWxwaGFcYXNwbnVtXGZhYXV0b1xzMTVccWwgXGxpMFxyaTBcd2lk Y3RscGFyXGFzcGFscGhhXGFzcG51bVxmYWF1dG9ccG5yYXV0aDFccG5yZGF0ZTExODQw NTU4OTJccG5ybm90MVxhZGp1c3RyaWdodFxyaW4wXGxpbjBcaXRhcDBccGFyYXJzaWQx Mzk3NjQ1MSB7DVxjZjBccmV2aXNlZFxyZXZhdXRoMVxyZXZkdHRtMTE4NDA1NTg5Mlxk YmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIA1ccGFyIH17XGNm MFxyZXZpc2VkXHJldmF1dGgxXHJldmR0dG0xMTg0MDU1ODkzXGRiY2hcZjE1XGluc3Jz aWQxMzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2No XGY2ICB9e1xkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIA1c cGFyIH1ccGFyZCBcczE1XHFsIFxsaTBccmkwXHdpZGN0bHBhclxhc3BhbHBoYVxhc3Bu dW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJpbjBcbGluMFxpdGFwMFxwYXJhcnNpZDEzOTc2 NDUxIHtcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyBcaGlj aFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgQXR0YWNrcyB0aGF0IGRvIG5vdCBpbnZv bHZlIGRpcmVjdFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiANIG1hbmlwdWxhdGlv biBvZiBCR1AsIGFuZCB0aGUNXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYg ICAgaW5mb3JtYXRpb24gfXtcY2YwXHJldmlzZWRccmV2YXV0aDFccmV2ZHR0bTExODQw NTU4OTRcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyBcaGlj aFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgY2FycmllZCBpbiBCR1AgbWVzc2FnZXN9ew1c Y2YwXHJldmlzZWRccmV2YXV0aDFccmV2ZHR0bTExODQwNTU4OTVcZGJjaFxmMTVcaW5z cnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyBcaGljaFxhZjZcZGJjaFxhZjE1XGxv Y2hcZjYgIH17XGRiY2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMg XGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IHdpdGhpbiBpdCwgYXJlIG91dHNpZGUg dGhlIHNjb3BlIG9mIHRoaXMNXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYg ICAgZG9jdW1lbnQufXtcY2YwXHJldmlzZWRccmV2YXV0aDFccmV2ZHR0bTExODQwNTU4 OTRcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyBcaGljaFxh ZjZcZGJjaFxhZjE1XGxvY2hcZjYgIH17XGRiY2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxj aGFycnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IFdoZW4gcG9z c2libGUsIHRoZSByZXF1aXJlbWVudHMNfXtcY2YwXHJldmlzZWRccmV2YXV0aDFccmV2 ZHR0bTExODQwNTU4OTRcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAz Mzc0MyBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgIH17XGRiY2hcZjE1XGluc3Jz aWQxMzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2No XGY2IHdpbGwgYXR0ZW1wdCB0byBtaW5pbWl6ZQ1ccGFyIFxoaWNoXGFmNlxkYmNoXGFm MTVcbG9jaFxmNiAgICB0aGUgZXh0ZW50IG9mIHRoZSBkYW1hZ2UgdGhhdCBvY2N1cnMg d2hlbiBlbmQgc3lzdGVtcyBjb21lIHVuZGVyDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYx NVxsb2NoXGY2ICAgIGF0dGFjXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IGsufXtc Y2YwXHJldmlzZWRccmV2YXV0aDFccmV2ZHR0bTExODQwNTU4OTZcZGJjaFxmMTVcaW5z cnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyBcaGljaFxhZjZcZGJjaFxhZjE1XGxv Y2hcZjYgDSBbd2hhdCBpcyB0aGUgaW50ZW50IG9mIHRoaXMgbGFzdCBzZW50ZW5jZT8g SG93IGRvZXMgaXQgcmVsYXRlIHRvIEJHUCBzZWN1cml0eT9dfXtcZGJjaFxmMTVcaW5z cnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyANXHBhciANXHBhciB9XHBhcmQgXHMx NVxxbCBcbGkwXHJpMFx3aWRjdGxwYXJcYXNwYWxwaGFcYXNwbnVtXGZhYXV0b1xzMTVc cWwgXGxpMFxyaTBcd2lkY3RscGFyXGFzcGFscGhhXGFzcG51bVxmYWF1dG9ccG5yYXV0 aDFccG5yZGF0ZTExODQwNTU4OTlccG5ybm90MVxhZGp1c3RyaWdodFxyaW4wXGxpbjBc aXRhcDBccGFyYXJzaWQxMzk3NjQ1MSB7DVxjZjBccmV2aXNlZFxyZXZhdXRoMVxyZXZk dHRtMTE4NDA1NTg5OVxkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMz NzQzIA1ccGFyIH1ccGFyZCBcczE1XHFsIFxsaTBccmkwXHdpZGN0bHBhclxhc3BhbHBo YVxhc3BudW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJpbjBcbGluMFxpdGFwMFxwYXJhcnNp ZDEzOTc2NDUxIHtcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0 MyBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgVGhlIGludGVudCBvZiB0aGlz IHJlcXVpcmVtZW50cyBkb2N1bWVudCBpcyB0byB9ew1cY2YwXHJldmlzZWRccmV2YXV0 aDFccmV2ZHR0bTExODQwNTU4OTZcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJy c2lkNjAzMzc0MyBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgcHJvdmlkZSB9e1xj ZjBccmV2aXNlZFxyZXZhdXRoMVxyZXZkdHRtMTE4NDA1NTg5N1xkYmNoXGYxNVxpbnNy c2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9j aFxmNiANY3JpdGVyaWEgZm9yIGV2YWx1YXRpbmcgcHJvcG9zZWQgbWVjaGFuaXNtcyBm b3IgaW1wcm92aW5nIHRoZSBzZWN1cml0eSBvZiBCR1AuIH17XGNmMFxyZXZpc2VkXHJl dmF1dGgxXHJldmR0dG0xMTg0MDU1OTEwXGRiY2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxj aGFycnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IEJlY2F1c2Ug QVNlcyBhcmUgYXV0b25vbW91cyBpbiB0aGVcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hc ZjYgDWlyIG9wZXJhdGlvbiwgaXQgaXMgbm90IHBvc3NpYmxlIHRvIG1hbmRhdGUgc2Vj dXJlIG9wZXJhdGlvbiBieSBhbGwgQVNlcywgbm9yIHdvdWxkIGl0IGJlIH17XGNmMFxy ZXZpc2VkXHJldmF1dGgxXHJldmR0dG0xMTg0MDU1OTExXGRiY2hcZjE1XGluc3JzaWQx Mzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2 IGFkdmlzYWJsZSB9ew1cY2YwXHJldmlzZWRccmV2YXV0aDFccmV2ZHR0bTExODQwNTU5 MTBcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyBcaGljaFxh ZjZcZGJjaFxhZjE1XGxvY2hcZjYgdG8gYXNzdW1lIHN1Y2ggb3BlcmF0aW9uLn17XGNm MFxyZXZpc2VkXHJldmF1dGgxXHJldmR0dG0xMTg0MDU1OTExXGRiY2hcZjE1XGluc3Jz aWQxMzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2No XGY2IA0gVGh1cyB0aGUgcHJpbWFyeSBnb2FsIG9mIEJHUCBzZWN1cml0eSBtZWFzdXJl cyBpcyB0byBwcm92aWRlIGRhdGEgdG8gQVMgb3BlcmF0b3JzIHRvIGVuYWJsZSB9e1xj ZjBccmV2aXNlZFxyZXZhdXRoMVxyZXZkdHRtMTE4NDA1NTkxMlxkYmNoXGYxNVxpbnNy c2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9j aFxmNiBCR1Agc3BlYWtlcnMgdG8gcmVqZWN0IGFkdmVydGlzZW1lbnRzIA1caGljaFxh ZjZcZGJjaFxhZjE1XGxvY2hcZjYgKFVQREFURSBtZXNzYWdlcykgdGhhdCBhcmUgbm90 IHZhbGlkLn17XGNmMFxyZXZpc2VkXHJldmF1dGgxXHJldmR0dG0xMTg0MDU1OTEzXGRi Y2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRi Y2hcYWYxNVxsb2NoXGY2ICB9ew1cY2YwXHJldmlzZWRccmV2YXV0aDFccmV2ZHR0bTEx ODQwNTU5MTVcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyBc aGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgRm9yIGV4YW1wbGUsIFVQREFURSBtZXNz YWdlc317XGNmMFxyZXZpc2VkXHJldmF1dGgxXHJldmR0dG0xMTg0MDU1OTEzXGRiY2hc ZjE1XGluc3JzaWQxMzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRiY2hc YWYxNVxsb2NoXGY2IA0gdGhhdCByZXByZXNlbnQgfXtcY2YwXHJldmlzZWRccmV2YXV0 aDFccmV2ZHR0bTExODQwNTU5MTRcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJy c2lkNjAzMzc0MyBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgZXJyb25lb3VzIH17 XGNmMFxyZXZpc2VkXHJldmF1dGgxXHJldmR0dG0xMTg0MDU1OTE2XGRiY2hcZjE1XGlu c3JzaWQxMzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYxNVxs b2NoXGY2IA1iaW5kaW5nIH17XGNmMFxyZXZpc2VkXHJldmF1dGgxXHJldmR0dG0xMTg0 MDU1OTE0XGRiY2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMgXGhp Y2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IG9mIH17XGNmMFxyZXZpc2VkXHJldmF1dGgx XHJldmR0dG0xMTg0MDU1OTE2XGRiY2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxjaGFycnNp ZDYwMzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IHByZWZpeGVzIHRvIH17 DVxjZjBccmV2aXNlZFxyZXZhdXRoMVxyZXZkdHRtMTE4NDA1NTkyMFxkYmNoXGYxNVxp bnNyc2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIFxoaWNoXGFmNlxkYmNoXGFmMTVc bG9jaFxmNiBhbiB9e1xjZjBccmV2aXNlZFxyZXZhdXRoMVxyZXZkdHRtMTE4NDA1NTkx NFxkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIFxoaWNoXGFm NlxkYmNoXGFmMTVcbG9jaFxmNiBvcmlnaW4gQVN9ew1cY2YwXHJldmlzZWRccmV2YXV0 aDFccmV2ZHR0bTExODQwNTU5MTlcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJy c2lkNjAzMzc0MyBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgLH17XGNmMFxyZXZp c2VkXHJldmF1dGgxXHJldmR0dG0xMTg0MDU1OTE0XGRiY2hcZjE1XGluc3JzaWQxMzk3 NjQ1MVxjaGFycnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICBv ciB0aGF0IGFkdmVydGlzZSBwYXRocyB9ew1cY2YwXHJldmlzZWRccmV2YXV0aDFccmV2 ZHR0bTExODQwNTU5MTZcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAz Mzc0MyBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgdGhhdCBoYXZlIG5vdCBiZWVu IHByb3BhZ2F0ZWQgfXtcY2YwXHJldmlzZWRccmV2YXV0aDFccmV2ZHR0bTExODQwNTU5 MTdcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyBcaGljaFxh ZjZcZGJjaFxhZjE1XGxvY2hcZjYgDWFjY29yZGluZyB0byB0aGUgYWxnb3JpdGhtcyBz cGVjaWZpZWQgaW4gUkZDIDE3NzEgc2hvdWxkIH17XGNmMFxyZXZpc2VkXHJldmF1dGgx XHJldmR0dG0xMTg0MDU1OTE4XGRiY2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxjaGFycnNp ZDYwMzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IGJlIHJlamVjdGVkLiB9 ew1cY2YwXHJldmlzZWRccmV2YXV0aDFccmV2ZHR0bTExODQwNTU5MjFcZGJjaFxmMTVc aW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyBcaGljaFxhZjZcZGJjaFxhZjE1 XGxvY2hcZjYgQmVjXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IGF1c2UgQkdQIHBl ZXJpbmcgc2Vzc2lvbnMgdGFrZSBwbGFjZSBpbiB0aGUgY29udGV4dCBvZiBUQ1AsfXsN XGNmMFxyZXZpc2VkXHJldmF1dGgxXHJldmR0dG0xMTg0MDU1OTIyXGRiY2hcZjE1XGlu c3JzaWQxMzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYxNVxs b2NoXGY2ICB0aGUgYXV0aGVudGljYXRpb24gYW5kIGludGVncml0eSBndWFyYW50ZWVz IHVzdWFsbHkgYXNzb2NpYXRpb24gd2l0aCBUQ1AgbmVlZCB0byBiZSB9ew1cY2YwXHJl dmlzZWRccmV2YXV0aDFccmV2ZHR0bTExODQwNTU5MjNcZGJjaFxmMTVcaW5zcnNpZDEz OTc2NDUxXGNoYXJyc2lkNjAzMzc0MyBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYg cHJvdmlkZWQgaW4gdGhlIGZhY2Ugb2YgcG9zc2libGUgYWN0aXZlIHdpcmV0YXBwaW5n IGF0dGFja3MuIFVzaW5nIHRoZSB0ZXJtaW5vbG9neSBlc3RhYmxpc2hlZCBpbiBSRkMg MzU1MiBbMl0sIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiANdGhlc2UgcGVlcmlu ZyBzZXNzaW9ucyBzaG91bGQgYmUgYWZmb3JkZWR9e1xjZjBccmV2aXNlZFxyZXZhdXRo MVxyZXZkdHRtMTE4NDA1NTkyMFxkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hhcnJz aWQ2MDMzNzQzIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgZGF0YSBvcmlnaW4g YW5kIHBlZXIgZW50aXR5IH17DVxjZjBccmV2aXNlZFxyZXZhdXRoMVxyZXZkdHRtMTE4 NDA1NTkyMVxkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIFxo aWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiBhdXRoZW50aWNhdGlvbiBhbmQgY29ubmVj dGlvbi1vcmllbnRlZCBpbnRlZ3JpdHkufXtcY2YwXHJldmlzZWRccmV2YXV0aDFccmV2 ZHR0bTExODQwNTU5MTBcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAz Mzc0MyANXHBhciB9XHBhcmQgXHMxNVxxbCBcbGkwXHJpMFx3aWRjdGxwYXJcYXNwYWxw aGFcYXNwbnVtXGZhYXV0b1xzMTVccWwgXGxpMFxyaTBcd2lkY3RscGFyXGFzcGFscGhh XGFzcG51bVxmYWF1dG9ccG5yYXV0aDFccG5yZGF0ZTExODQwNTU5MTBccG5ybm90MVxh ZGp1c3RyaWdodFxyaW4wXGxpbjBcaXRhcDBccGFyYXJzaWQxMzk3NjQ1MSB7DVxjZjBc cmV2aXNlZFxyZXZhdXRoMVxyZXZkdHRtMTE4NDA1NTkxMFxkYmNoXGYxNVxpbnNyc2lk MTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIA1ccGFyIH1ccGFyZCBcczE1XHFsIFxsaTBc cmkwXHdpZGN0bHBhclxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJp bjBcbGluMFxpdGFwMFxwYXJhcnNpZDEzOTc2NDUxIHtcZGJjaFxmMTVcaW5zcnNpZDEz OTc2NDUxXGNoYXJyc2lkNjAzMzc0MyANXHBhciANXHBhciBcaGljaFxhZjZcZGJjaFxh ZjE1XGxvY2hcZjYgICAgfXtcY2YwXHJldmlzZWRccmV2YXV0aDFccmV2ZHR0bTExODQw NTU5MjVcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyBcaGlj aFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgU2VjdXJ9e1xjZjBccmV2aXNlZFxyZXZhdXRo MVxyZXZkdHRtMTE4NDA1NTkyNlxkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hhcnJz aWQ2MDMzNzQzIA1caGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgaX17XGNmMFxyZXZp c2VkXHJldmF1dGgxXHJldmR0dG0xMTg0MDU1OTI1XGRiY2hcZjE1XGluc3JzaWQxMzk3 NjQ1MVxjaGFycnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IHR5 IGZvciBzdWJzY3JpYmVyIHRyYWZmaWMgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhp cyBkb2N1bWVudCwgb2YgQkdQIHNlY3VyaXR5IGluIGdlbmVyYWwuIH17DVxjZjBccmV2 aXNlZFxyZXZhdXRoMVxyZXZkdHRtMTE4NDA1NTkyNlxkYmNoXGYxNVxpbnNyc2lkMTM5 NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiBJ RVRGIHN0YW5kYXJkcyBmb3Igc3Vic2NyaWJlciBkXGhpY2hcYWY2XGRiY2hcYWYxNVxs b2NoXGY2IGF0YSB9e1xjZjBccmV2aXNlZFxyZXZhdXRoMVxyZXZkdHRtMTE4NDA1NTky N1xkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIA1caGljaFxh ZjZcZGJjaFxhZjE1XGxvY2hcZjYgc2VjdXJpdHksIGUuZy4sIH17XGNmMFxyZXZpc2Vk XHJldmF1dGgxXHJldmR0dG0xMTg0MDU1OTI2XGRiY2hcZjE1XGluc3JzaWQxMzk3NjQ1 MVxjaGFycnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IElQc2Vj IFs/XSwgfXtcY2YwXHJldmlzZWRccmV2YXV0aDFccmV2ZHR0bTExODQwNTU5MjdcZGJj aFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyANXGhpY2hcYWY2XGRi Y2hcYWYxNVxsb2NoXGY2IFRMUyBbP10sIGFuZCBTL01JTUUgWz9dIHNob3VsZCBiZSBl bXBsb3llZCBmcm8gc3VjaCBwdXJwb3Nlcy4gV2hpbGUgYWRvcHRpb24gb2YgQkdQIHNl Y3VyaXR5IG1lYXN1cmVzIG1heSBwcmVjbHVkZSBjZXJ0YWluIGNsYXNzZXMgb2YgYXR0 YWNrcyB9e1xjZjBccmV2aXNlZFxyZXZhdXRoMVxyZXZkdHRtMTE4NDA1NTkyOFxkYmNo XGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIA1caGljaFxhZjZcZGJj aFxhZjE1XGxvY2hcZjYgb24gc3Vic2NyaWJlciB0cmFmZmljLCB0aGVzZSBtZWFzdXJl cyBhcmUgbm90IGEgc3Vic3RpdHV0ZSBmb3IgfXtcY2YwXHJldmlzZWRccmV2YXV0aDFc cmV2ZHR0bTExODQwNTU5MjlcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lk NjAzMzc0MyBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgdXNlIG9mIHN1YnNjcmli ZXItYmFcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgDXNlZCBzZWN1cml0eSBtZWNo YW5pc21zIG9mIHRoZSBzb3J0IG5vdGVkIGFib3ZlLiB9e1xkYmNoXGYxNVxpbnNyc2lk MTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIA1ccGFyIA1ccGFyIA1ccGFyIA1ccGFyIFxo aWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiBDaHJpc3RpYW4gICAgICAgICAgICAgICAg RXhwaXJlcyBBdWd1c3QgMSwgMjAwNCAgICAgICAgICAgICAgICAgW1BhZ2UgMl0NXHBh ciBccGFnZSANXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgSW50ZXJuZXQt RHJhZnQgICAgICAgICBCR1AgU2VjdXJpdHkgUmVxdWlyZW1lbnRzICAgICAgICAgICAg ICAgIEZlYiAyMDA0DVxwYXIgDVxwYXIgDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxs b2NoXGY2ICAgIA1ccGFyIA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAx LjMgIEFyZWFzIHRvIHNlY3VyZQ1ccGFyIA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVc bG9jaFxmNiAgICBUaGVyZSBhcmUgdHdvIHByaW1hcnkgcFxoaWNoXGFmNlxkYmNoXGFm MTVcbG9jaFxmNiBvaW50cyB3aGVyZSBCR1AgbWF5IGJlIHNlY3VyZWQuICBJZiB3ZSBl eGFtaW5lDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIHRoZSBzeXN0 ZW0gZGVzY3JpcHRpb24gcHJlc2VudGVkIGFib3ZlIHRob3NlIHBvaW50cyBhcmUgYXMg Zm9sbG93cy4NXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgbyAgVGhl IHNlc3Npb24gYmV0d2VlbiB0d28gQkdQIHNwZWFrZXJzIGNhbiBiZSBzZWN1cmVkIHN1 Y2ggdGhhdCB0aGUNXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgICAg QkdQIGRhdGEgcmVjZWl2ZWQgYnkgdGhlIEJHUCBzcGVha2VycyBjYW4gYnkgY3J5cHRv Z3JhcGhpY2FsXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IGx5DVxwYXIgXGhpY2hc YWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgICAgIHZlcmlmaWVkIHRvIGhhdmUgYmVlbiB0 cmFuc21pdHRlZCBieSB0aGUgb3RoZXIgc3BlYWtlci59e1xjczE2XHZcZjBcZnMxOFxp bnNyc2lkMTM5NzY0NTEge1wqXGF0bmlkIFNLfXtcKlxhdG5hdXRob3IgU3RlcGhlbiBL ZW50fVxjaGF0biB7XCpcYW5ub3RhdGlvbntcKlxhdG5kYXRlIDExODQwNTU5MzZ9XHBh cmRccGxhaW4gDVxzMTdccWwgXGxpMFxyaTBcd2lkY3RscGFyXGFzcGFscGhhXGFzcG51 bVxmYWF1dG9cYWRqdXN0cmlnaHRccmluMFxsaW4wXGl0YXAwIFxsYW5nMTAzM1xsYW5n ZmUxMDMzXGNncmlkXGxhbmducDEwMzNcbGFuZ2ZlbnAxMDMzIHtcY3MxNlxmczE4XGlu c3JzaWQxMzk3NjQ1MSBcY2hhdG4gfXtcaW5zcnNpZDEzOTc2NDUxIA1UaGlzIGlzIGEg cmF0aGVyIGltcHJlY2lzZSBjaGFyYWN0ZXJpemF0aW9uIG9mIHRoZSBzZWN1cml0eSBy ZXF1aXJlbWVudHMgZm9yIHRoZSBUQ1AgcGVlcmluZyBzZXNzaW9uLiBTZWUgbXkgc3Vn Z2VzdGVkIHRleHQgYWJvdmUufX19e1xkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hh cnJzaWQ2MDMzNzQzIA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBv ICBUaGUgb3JpZ2luYXRvciBhbmQgdGhlIHByb3BhZ2F0b3JzIG9mIHByZWZpeCBpbmZv cm1hdGlvbiBtYXkgaGF2ZQ1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAg ICAgICB0aGVpciBwb2xpY3kgaW5mb3JtYXRpb24gdmVyaWZpZWQgc3VjaCB0aGF0IHRo ZSBpbnRlbnQgb2YgdGhlDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAg ICAgIHBvbGljeSB3aXRoIHJlc3BlY3QgdG8gdGhlIHNwZWNpZmljIHByZWZpeCBpXGhp Y2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IHMgcHJlc2VydmVkfXtcY3MxNlx2XGYwXGZz MThcaW5zcnNpZDEzOTc2NDUxIHtcKlxhdG5pZCBTS317XCpcYXRuYXV0aG9yIFN0ZXBo ZW4gS2VudH1cY2hhdG4ge1wqXGFubm90YXRpb257XCpcYXRuZGF0ZSAxMTg0MDU1OTM3 fVxwYXJkXHBsYWluIA1cczE3XHFsIFxsaTBccmkwXHdpZGN0bHBhclxhc3BhbHBoYVxh c3BudW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJpbjBcbGluMFxpdGFwMCBcbGFuZzEwMzNc bGFuZ2ZlMTAzM1xjZ3JpZFxsYW5nbnAxMDMzXGxhbmdmZW5wMTAzMyB7XGNzMTZcZnMx OFxpbnNyc2lkMTM5NzY0NTEgXGNoYXRuIH17XGluc3JzaWQxMzk3NjQ1MSANVGhpcyBz b3VuZHMgbGlrZSBhbiBzb0JHUCBjaGFyYWN0ZXJpemF0aW9uIG9mIHdoYXQgY29uc3Rp dHV0ZXMgc2VjdXJlIG9wZXJhdGlvbiEgfX19e1xkYmNoXGYxNVxpbnNyc2lkMTM5NzY0 NTFcY2hhcnJzaWQ2MDMzNzQzIA1ccGFyIA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVc bG9jaFxmNiAgICBUaGVyZSBhcmUgYWxzbyBzZXZlcmFsIHF1ZXN0aW9ucyB3ZSBjYW4g YXNrIGFib3V0IHRoZSBpbmZvcm1hdGlvbg1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVc bG9jaFxmNiAgICBjb250YWluZWQgd2l0aGluIGEgcmVjZWl2ZWQgdXBkYXRlLg1ccGFy IFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBvICBJcyB0aGUgb3JpZ2luYXRp bmcgQXV0b25vbW91cyBzeXN0ZW0gYXV0aG9yaXplZCB0byBwcm9wYWdhdGUgdGhlDVxw YXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgICAgIHByZWZpeCB3ZSBoYXZl IHJlY2VpdmVkPw1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBvICBJ cyB0aGUgQVMgcGF0aCwgcmVjZWl2ZWQgdlxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxm NiBpYSBhbiBVUERBVEUsIHZhbGlkP317XGNzMTZcdlxmMFxmczE4XGluc3JzaWQxMzk3 NjQ1MSB7XCpcYXRuaWQgU0t9e1wqXGF0bmF1dGhvciBTdGVwaGVuIEtlbnR9XGNoYXRu IHtcKlxhbm5vdGF0aW9ue1wqXGF0bmRhdGUgMTE4NDA1NTkzOH1ccGFyZFxwbGFpbiAN XHMxN1xxbCBcbGkwXHJpMFx3aWRjdGxwYXJcYXNwYWxwaGFcYXNwbnVtXGZhYXV0b1xh ZGp1c3RyaWdodFxyaW4wXGxpbjBcaXRhcDAgXGxhbmcxMDMzXGxhbmdmZTEwMzNcY2dy aWRcbGFuZ25wMTAzM1xsYW5nZmVucDEwMzMge1xjczE2XGZzMThcaW5zcnNpZDEzOTc2 NDUxIFxjaGF0biB9e1xpbnNyc2lkMTM5NzY0NTEgR29vZCBzdGF0ZW1lbnQgaWYgd2Ug Y2FuIGFncmVlIG9uIHdoYXQgXGxkYmxxdW90ZSB2YWxpZFxyZGJscXVvdGUgDSBtZWFu cy4gfX19e1xkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIA1c cGFyIA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBUaGUgdmVyaWZp Y2F0aW9uIG9mIEFTLVBhdGggdmFsaWRpdHkgZmFsbHMgaW50byB0aHJlZSBkaXN0aW5j dA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBjYXRlZ29yaWVzLg1c cGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBvICBEb2VzIHRoZSBBUy1Q YXRoIHNwZWNpZmllZCBhY3R1YWxseSBleGlzdCBhbmQsIGJhc2VkIG9uIHRoZQ1ccGFy IFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICAgICBBUy1QQVRILCBpcyBpdCBw b3NzaWJsZSB0byB0cmF2ZXJzZSB0aGF0IHBhdGggdG8gcmVhY2ggYSBnaXZlbg1ccGFy IFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICAgICBwcmVmaXg/fXtcY3MxNlx2 XGYwXGZzMThcaW5zcnNpZDEzOTc2NDUxIHtcKlxhdG5pZCBTS317XCpcYXRuYXV0aG9y IFN0ZXBoZW4gS2VudH1cY2hhdG4ge1wqXGFubm90YXRpb257XCpcYXRuZGF0ZSAxMTg0 MDU1OTQxfVxwYXJkXHBsYWluIFxzMTdccWwgXGxpMFxyaTBcd2lkY3RscGFyXGFzcGFs cGhhXGFzcG51bVxmYWF1dG9cYWRqdXN0cmlnaHRccmluMFxsaW4wXGl0YXAwIA1cbGFu ZzEwMzNcbGFuZ2ZlMTAzM1xjZ3JpZFxsYW5nbnAxMDMzXGxhbmdmZW5wMTAzMyB7XGNz MTZcZnMxOFxpbnNyc2lkMTM5NzY0NTEgXGNoYXRuIH17XGluc3JzaWQxMzk3NjQ1MSBU aGlzIHNlZW1zIGxpa2UgYSBzb21ld2hhdCBvZGQgY2hhcmFjdGVyaXphdGlvbiBvZiB0 aGUgY29uY2VybiwgZ2l2ZW4gdGhlIG5leHQgYnVsbGV0LCBpLmUuLCBpZiB0aGUgVVBE QVRFDSB0cmF2ZXJzZWQgdGhlIHBhdGgsIHRoZW4gd2Uga25vdyBpdCBleGlzdHMsIHJp Z2h0P319fXtcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyAN XHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICBcaGljaFxhZjZcZGJjaFxh ZjE1XGxvY2hcZjYgIG8gIEhhcyB0aGUgdXBkYXRlIGFjdHVhbGx5IH17XGNmMFxyZXZp c2VkXHJldmF1dGgxXHJldmR0dG0xMTg0MDU1OTM5XGRiY2hcZjE1XGluc3JzaWQxMzk3 NjQ1MVxjaGFycnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IHRy YXZlcnNlZCB9e1xkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQz IA1caGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgdGhlIHBhdGg/DVxwYXIgXGhpY2hc YWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIG8gIFdhcyB0aGUgdXBkYXRlIGF1dGhvcml6 ZWQgdG8gdHJhdmVyc2UgdGhlIGdpdmVuIHBhdGggYnkgdGhlDVxwYXIgXGhpY2hcYWY2 XGRiY2hcYWYxNVxsb2NoXGY2ICAgICAgIG9yaWdpbmF0b3Igb2YgdGhlIHByZWZpeD99 e1xjczE2XHZcZjBcZnMxOFxpbnNyc2lkMTM5NzY0NTEge1wqXGF0bmlkIFNLfXtcKlxh dG5hdXRob3IgU3RlcGhlbiBLZW50fVxjaGF0biB7XCpcYW5ub3RhdGlvbntcKlxhdG5k YXRlIDExODQwNTU5NDJ9XHBhcmRccGxhaW4gDVxzMTdccWwgXGxpMFxyaTBcd2lkY3Rs cGFyXGFzcGFscGhhXGFzcG51bVxmYWF1dG9cYWRqdXN0cmlnaHRccmluMFxsaW4wXGl0 YXAwIFxsYW5nMTAzM1xsYW5nZmUxMDMzXGNncmlkXGxhbmducDEwMzNcbGFuZ2ZlbnAx MDMzIHtcY3MxNlxmczE4XGluc3JzaWQxMzk3NjQ1MSBcY2hhdG4gfXtcaW5zcnNpZDEz OTc2NDUxIA1UaGUgb3JpZ2luYXRvciBjYW5ub3QgZ2VuZXJhbGx5IGtub3cgYWJvdXQg dGhlIHBhdGggdGhhdCB0aGUgVVBEQVRFIHdpbGwgdHJhdmVyc2UsIGJleW9uZCB0aGUg Zmlyc3QgaG9wLiBzbyB0aGVyZSBhcmUgcHJvYmxlbXMgd2l0aCB0aGlzIGNoYXJhY3Rl cml6YXRpb24uIEhvd2V2ZXIsIEkgc3RpbGwgbWFpbnRhaW4gdGhhdCBob3AtYnktaG9w IGF1dGhvcml6YXRpb24gaXMgbWVhbmluZ2Z1bC59fX17DVxkYmNoXGYxNVxpbnNyc2lk MTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIA1ccGFyIA1ccGFyIFxoaWNoXGFmNlxkYmNo XGFmMTVcbG9jaFxmNiAgICBJbiB0aGlzIGRyYWZ0IHdlIGRvIG5vdCBhdHRlbXB0IHRv IHNldCByZXF1aXJlbWVudHMgZGVhbGluZyB3aXRoIHRoZQ1ccGFyIFxoaWNoXGFmNlxk YmNoXGFmMTVcbG9jaFxmNiAgICB0aGlyZCBxdWVzdGlvbiBwcmVzZW50ZWQgYWJvdmUu ICBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgSG93ZXZlciwgdGhlIG5lZWRzIG9m IHRoZSBvcGVyYXRvcnMNXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAg b2YgdGhlIHN5c3RlbXMgdGhhdCB1c2UgQkdQIGFyZSBzdWNoIHRoYXQgdGhlIGZpcnN0 IHR3byBxdWVzdGlvbnMgYXJlDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2 ICAgIG9mIGtleSBpbXBvcnRhbmNlIHRvIGFueSBzZWN1cmVkIGludGVyfXtcY2YwXHJl dmlzZWRccmV2YXV0aDFccmV2ZHR0bTExODQwNTU5NDBcZGJjaFxmMTVcaW5zcnNpZDEz OTc2NDUxXGNoYXJyc2lkNjAzMzc0MyBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYg LX17XGRiY2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMgXGhpY2hc YWY2XGRiY2hcYWYxNVxsb2NoXGY2IA1kb21haW4gcm91dGluZyBzeXN0ZW0uDVxwYXIg DVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIgDVxw YXIgDVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIgXGhpY2hc YWY2XGRiY2hcYWYxNVxsb2NoXGY2IENocmlzdGlhbiAgICAgICAgICAgICAgICBFeHBp cmVzIEF1Z3VzdCAxLCAyMDA0ICAgICAgICAgICAgICAgICBbUFxoaWNoXGFmNlxkYmNo XGFmMTVcbG9jaFxmNiBhZ2UgM10NXHBhciBccGFnZSANXHBhciBcaGljaFxhZjZcZGJj aFxhZjE1XGxvY2hcZjYgSW50ZXJuZXQtRHJhZnQgICAgICAgICBCR1AgU2VjdXJpdHkg UmVxdWlyZW1lbnRzICAgICAgICAgICAgICAgIEZlYiAyMDA0DVxwYXIgDVxwYXIgDVxw YXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IDIuICB9e1xjZjBccmV2aXNlZFxy ZXZhdXRoMVxyZXZkdHRtMTE4NDA1NjAwMlxkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFc Y2hhcnJzaWQ2MDMzNzQzIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiBVbmRlcmx5 aW5nIEFzc3VtcHRpb24gcmUgQkdQfXtcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNo YXJyc2lkNjAzMzc0MyANXHBhciANXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hc ZjYgICAgSW4gb3JkZXIgdG8gcHJvcGVybHkgaWRlbnRpZnkgc2VjdXJpdHkgcmVxdWly ZW1lbnRzIGl0IGlzIGltcG9ydGFudA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9j aFxmNiAgICB0byB9e1xjZjBccmV2aXNlZFxyZXZhdXRoMVxyZXZkdHRtMTE4NDA1NjAw M1xkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcZGVscnNpZDEzOTc2NDUxXGNoYXJyc2lk NjAzMzc0MyBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgYXJ0aWN1bGF0ZX17XGNm MFxyZXZpc2VkXHJldmF1dGgxXHJldmR0dG0xMTg0MDU2MDAzXGRiY2hcZjE1XGluc3Jz aWQxMzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMgDVxoaWNoXGFmNlxkYmNoXGFmMTVcbG9j aFxmNiAgfXtcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyBc aGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgZnVuZGFtZW50YWwgYXNwZWN0cyBvZiBC R1AgYXMgcmVsYXRlZCB0byBzZWN1cml0eQ1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVc bG9jaFxmNiAgICByZXF1aXJlbWVudHMuICBUaGUgZm9sbG93aW5nIGxpc3QgcHJlc2Vu dHMgdGhlIGJhc2ljIHBhcmFtZXRlcnMgYW5kDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYx NVxsb2NoXGY2ICAgIGFwcGxpY2F0aW9uIGNvbmNlcHRzIG9mIEJHUCB0aGF0IH17XGNm MFxyZXZpc2VkXHJldmF1dGgxXHJldmR0dG0xMTg0MDU2MDAzXGRiY2hcZjE1XGluc3Jz aWQxMzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2No XGY2IGFyZX17DVxjZjBccmV2aXNlZFxyZXZhdXRoMVxyZXZkdHRtMTE4NDA1NjAwNFxk YmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIFxoaWNoXGFmNlxk YmNoXGFmMTVcbG9jaFxmNiAgfXtcY2YwXHJldmlzZWRccmV2YXV0aDFccmV2ZHR0bTEx ODQwNTYwMDNcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyBc aGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgYXNzdW1lZH17DVxkYmNoXGYxNVxpbnNy c2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9j aFxmNiAgYnkgdGhpcyBkb2N1bWVudC4NXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxv Y2hcZjYgICAgbyAgUGVlciBDb21tdW5pY2F0aW9uOiBCR1AgdHJhZmZpYyB0cmF2ZWxz IG92ZXIgVENQIGJldHdlZW4gcGVlcnMsIHNvDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYx NVxsb2NoXGY2ICAgICAgIEJHUCBzcGVha2VycyBhc3N1bWUgdGhlIFRDUCBkYXRhIGRl bGl2ZXJcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgeSBndWFyYW50ZWVzIG9mIFRD UCBpbiBhDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgICAgIGJlbmln biBlbnZpcm9ubWVudC4gIFRoaXMgaW5jbHVkZXMgb3JkZXJlZCwgZXJyb3ItZnJlZSBk ZWxpdmVyeSBvZg1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICAgICBh cHBsaWNhdGlvbiB0cmFmZmljIGZyb20gYSBwZWVyIGlkZW50aWZpZWQgYnkgYW4gSVAg YWRkcmVzcywgcGx1cw1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICAg ICBpbnRlZ3JpdHkgb2YgdGhlIGNvbnRyb2wgYXNwZWN0cyBvZiBUQ1AuICBGcm9tIGEg c2VjdXJpdHkNXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgICAgcGVy c3BlY3RpdmUsIHRoZVxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiBzZSBndWFyYW50 ZWVzIG5lZWQgdG8gYmUgZW5mb3JjZWQgaW4gdGhlIGNvbnRleHQNXHBhciBcaGljaFxh ZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgICAgb2YgcG9zc2libGUgYWN0aXZlIHdpcmV0 YXBwaW5nLg1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBvICBSb3V0 aW5nIGFuZCBSZWFjaGFiaWxpdHk6IEJHUCBpcyBhIHByb3RvY29sIHVzZWQgdG8gY29u dmV5IHJvdXRpbmcNXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgICAg YW5kIHJlYWNoYWJpbGl0eSBpbmZvcm1hdGlvbiBib3RoIGludGVybmFsIGFuZCBleHRl cm5hbCB0byBhbg1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICAgICBB dXRvbm9tb3VzIFN5c3RlbS4gIFR5XGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IHBp Y2FsbHksIH17XGRlbGV0ZWRcZGJjaFxmMTVccmV2YXV0aGRlbDFccmV2ZHR0bWRlbDEx ODQwNTU5NDJcaW5zcnNpZDEzOTc2NDUxXGRlbHJzaWQ2MDMzNzQzXGNoYXJyc2lkNjAz Mzc0MyBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgaW50ZXJuYWwgfXsNXGNmMFxy ZXZpc2VkXHJldmF1dGgxXHJldmR0dG0xMTg0MDU1OTQyXGRiY2hcZjE1XGluc3JzaWQx Mzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2 IGludGVyaW9yIH17XGRiY2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxjaGFycnNpZDYwMzM3 NDMgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IEJHUCB9ew1cY2YwXHJldmlzZWRc cmV2YXV0aDFccmV2ZHR0bTExODQwNTU5NDJcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUx XGNoYXJyc2lkNjAzMzc0MyBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgKGktQkdQ KSB9e1xkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIFxoaWNo XGFmNlxkYmNoXGFmMTVcbG9jaFxmNiBpcyB1c2VkIHRvIGRpc3RyaWJ1dGUNXHBhciBc aGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgICAgcHJlZml4IHJlYWNoYWJpbGl0 eSBpbmZvcm1hdGlvbiBpbiBjb25qdW5jdGlvbiB3aXRoIGFuIElHUCBhbmQgaXMNXHBh ciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgICAgdXNlZCBieSBhIGRpc3Rp bmN0IG5ldHdvcmsgYWRtaW5pc3RyYXRpdmUgZW50aXR5IHRvIGNvbnZleQ1ccGFyIFxo aWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICAgICBpbnRlcm5hbCByb3V0aW5nIHBv bGljeSByZWdhcmRpbmcgZXh0ZXJuYWwgYW5kIGludGVyXGhpY2hcYWY2XGRiY2hcYWYx NVxsb2NoXGY2IG5hbA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICAg ICBpbmZvcm1hdGlvbi4gIH17XGRlbGV0ZWRcZGJjaFxmMTVccmV2YXV0aGRlbDFccmV2 ZHR0bWRlbDExODQwNTU5NDNcaW5zcnNpZDEzOTc2NDUxXGRlbHJzaWQ2MDMzNzQzXGNo YXJyc2lkNjAzMzc0MyBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgRXh0ZXJuYWwg fXsNXGNmMFxyZXZpc2VkXHJldmF1dGgxXHJldmR0dG0xMTg0MDU1OTQzXGRiY2hcZjE1 XGluc3JzaWQxMzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYx NVxsb2NoXGY2IEV4dGVyaW9yIH17XGRiY2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxjaGFy cnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IEJHUCB9ew1cY2Yw XHJldmlzZWRccmV2YXV0aDFccmV2ZHR0bTExODQwNTU5NDNcZGJjaFxmMTVcaW5zcnNp ZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hc ZjYgKGUtQkdQKSB9e1xkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMz NzQzIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiBpcyB0eXBpY2FsbHkgdXNlZCB0 byBkaXN0cmlidXRlIHJvdXRlLw1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxm NiAgICAgICBwcmVmaXggcmVhY2hhYmlsaXR5IGluZm9ybWF0aW9uIGJldHdlZW4gdHdv IGRpc3RpbmN0IHJvdXRpbmcNXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYg ICAgICAgZW50aXRpZXMgYW5kIGlzIHVzZWQgdG8gc2lnbmFsIGZvcndhcmRpbmcgcHJl ZmVyZW5jZXMgYW5kIHBvbGljeQ1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxm NiAgICAgICBkZWNpc2lvbnMufXtcY3MxNlx2XGYwXGZzMThcaW5zcnNpZDEzOTc2NDUx IHtcKlxhdG5pZCBTS317XCpcYXRuYXV0aG9yIFN0ZXBoZW4gS2VudH1cY2hhdG4ge1wq XGFubm90YXRpb257XCpcYXRuZGF0ZSAxMTg0MDU2MDA1fVxwYXJkXHBsYWluIFxzMTdc cWwgXGxpMFxyaTBcd2lkY3RscGFyXGFzcGFscGhhXGFzcG51bVxmYWF1dG9cYWRqdXN0 cmlnaHRccmluMFxsaW4wXGl0YXAwIA1cbGFuZzEwMzNcbGFuZ2ZlMTAzM1xjZ3JpZFxs YW5nbnAxMDMzXGxhbmdmZW5wMTAzMyB7XGNzMTZcZnMxOFxpbnNyc2lkMTM5NzY0NTEg XGNoYXRuIH17XGluc3JzaWQxMzk3NjQ1MSBXaGVyZSBpbiB0aGlzIGRvY3VtZW50IGlz IHRoZSBlLUJHUCB2cy4gaS1CR1AgZGlmZmVyZW5jZSByZWZlcmVuY2VkPyBEbyB3ZSBu ZWVkIHRvIHNheSB0aGF0IHRoZSBmb2N1cyAgb2YgdGhlIGRvY3VtZW50IGlzIGUtQkdQ IHNlY3VyaXR5P319fXsNXGRiY2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxjaGFycnNpZDYw MzM3NDMgDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIG8gIElcaGlj aFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgbnRlci1BUyBVUERBVEUgTWVzc2FnZSBhc3N1 bXB0aW9uczogV2hlbiBhbiBBUyBkaXN0cmlidXRlcw1ccGFyIFxoaWNoXGFmNlxkYmNo XGFmMTVcbG9jaFxmNiAgICAgICByZWFjaGFiaWxpdHkgaW5mb3JtYXRpb24gdG8gYSBw ZWVyIGl0IGlzIGRvbmUgd2l0aCB0aGUgaW50ZW50IG9mDVxwYXIgXGhpY2hcYWY2XGRi Y2hcYWYxNVxsb2NoXGY2ICAgICAgIGFmZmVjdGluZyByb3V0aW5nIGRlY2lzaW9ucyBi eSB0aGUgcGVlci59e1xjczE2XHZcZjBcZnMxOFxpbnNyc2lkMTM5NzY0NTEge1wqXGF0 bmlkIFNLfXtcKlxhdG5hdXRob3IgU3RlcGhlbiBLZW50fVxjaGF0biB7XCpcYW5ub3Rh dGlvbntcKlxhdG5kYXRlIDExODQwNTYwMDh9XHBhcmRccGxhaW4gDVxzMTdccWwgXGxp MFxyaTBcd2lkY3RscGFyXGFzcGFscGhhXGFzcG51bVxmYWF1dG9cYWRqdXN0cmlnaHRc cmluMFxsaW4wXGl0YXAwIFxsYW5nMTAzM1xsYW5nZmUxMDMzXGNncmlkXGxhbmducDEw MzNcbGFuZ2ZlbnAxMDMzIHtcY3MxNlxmczE4XGluc3JzaWQxMzk3NjQ1MSBcY2hhdG4g fXtcaW5zcnNpZDEzOTc2NDUxIA1UcnVlLCBidXQgd2UgYWxzbyBzaG91bGQgbm90ZSB0 aGF0IHdoaWxlIEFTIEEgdHJpZXMgdG8gaW5mbHVlbmNlIHRoZSByb3V0aW5nIGRlY2lz aW9ucyBvZiBBUyBCLCAgQVMgQSBpcyBvbmx5IHByb3ZpZGluZyBpbnB1dHMgdG8gYSBs b2NhbCBkZWNpc2lvbiBieSBBUyBCLCBhIGRlY2lzaW9uIHRoYXQgaXMgdmVyeSBtdWNo IGluZmx1ZW5jZWQgYnkgQVMgQlxycXVvdGUgcyBsb2NhbCBwb2xpY3ksIG92ZXIgd2hp Y2ggQSBoYXMgbm8gY29udHJvbC4NfX19e1xkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFc Y2hhcnJzaWQ2MDMzNzQzIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgIEZvciBl eGFtcGxlLCBhbiBBUy1BDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAg ICAgIHNlbmRzIHBlZXIgQVMtQiBhIGxlc3Mgc3BlY2lmaWMgYWR2ZXJ0aXNlbWVudCBh bmQgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IHBlZXIgQVMtQyBhDVxwYXIgXGhp Y2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgICAgICJtb3JlIiBzcGVjaWZpYyBhZHZl cnRpc2VtZW50LiAgVGhpcyBwcmVmaXggZGlzdHJpYnV0aW9uIGRlY2lzaW9uDVxwYXIg XGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgICAgIG1heSBoYXZlIGJlZW4gbWFk ZSB0byBwcm92aWRlIGEgbWVhbnMgZm9yIGZhaWx1cmUgcmVzb2x1dGlvbg1ccGFyIFxo aWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICAgICBiZXR3ZWVuIEFTLUEgYW5kIEFT LUMuICBVcGRhdGUgbWVzc2FnZXMgYXJlIHNlbnQgYmV0d2VlbiBBUyBwZWVycw1ccGFy IFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICAgICB3aXRoIHRoZSBpbXBsaWNp dCBhc3N1bXB0aW9caGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgbiB0aGF0IHRob3Nl IG1lc3NhZ2VzIHdpbGwgYmUgZm9yd2FyZGVkDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYx NVxsb2NoXGY2ICAgICAgIHRvIG90aGVycy4gIEEgbm90YWJsZSBleGNlcHRpb24gdG8g dGhpcyBhc3N1bXB0aW9uIGlzIHRoZSB1c2Ugb2YNXHBhciBcaGljaFxhZjZcZGJjaFxh ZjE1XGxvY2hcZjYgICAgICAgdmFyaW91cyBwb2xpY3kgYmFzZWQgbWVjaGFuaXNtcyBi ZXR3ZWVuIHBlZXJzIHN1Y2ggYXMgdGhlDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxs b2NoXGY2ICAgICAgIE5PLUVYUE9SVCBjb21tdW5pdHkuICBJbiB0aGlzIGRvY3VtZW50 IGFuIGltcG9ydGFudCBhc3BlY3Qgb2YgdGhlDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYx NVxsb2NoXGY2ICAgICAgIFVQRFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiBBVEUg bWVzc2FnZSB0byBub3RlIGlzIHRoYXQgdGhlIHNwZWNpZmljIFVQREFURSBtZXNzYWdl IGl0c2VsZg1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICAgICBpcyB0 eXBpY2FsbHkgbm90IHJlLXRyYW5zbWl0dGVkLiAgSW5zdGVhZCwgdGhlIHNwZWNpZmlj IFVQREFURQ1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICAgICBtZXNz YWdlIGlzIHJlZ2VuZXJhdGVkIGNvbnRpbnVhbGx5IGFzIGl0IHBhc3NlcyBmcm9tIEJH UCBzcGVha2VyDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgICAgIHRv IEJHUCBzcGVha2VyLn17XGNzMTZcdlxmMFxmczE4XGluc3JzaWQxMzk3NjQ1MSB7XCpc YXRuaWQgU0t9e1wqXGF0bmF1dGhvciBTdGVwaGVuIEtlbnR9XGNoYXRuIHtcKlxhbm5v dGF0aW9ue1wqXGF0bmRhdGUgMTE4NDA1NjAwOX1ccGFyZFxwbGFpbiANXHMxN1xxbCBc bGkwXHJpMFx3aWRjdGxwYXJcYXNwYWxwaGFcYXNwbnVtXGZhYXV0b1xhZGp1c3RyaWdo dFxyaW4wXGxpbjBcaXRhcDAgXGxhbmcxMDMzXGxhbmdmZTEwMzNcY2dyaWRcbGFuZ25w MTAzM1xsYW5nZmVucDEwMzMge1xjczE2XGZzMThcaW5zcnNpZDEzOTc2NDUxIFxjaGF0 biB9e1xpbnNyc2lkMTM5NzY0NTEgVHJ1ZSwgYnV0IGlzblxycXVvdGUgDXQgdGhlIEFT IHBhdGggaW50byBzdXBwb3NlZCB0byBiZSBmb3J3YXJkZWQsIGF0IGxlYXN0IHRoZSB0 cmFuc2l0aXZlIGF0dHJpYnV0ZXM/fX19e1xkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFc Y2hhcnJzaWQ2MDMzNzQzIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgIEZ1cnRo ZXJtb3JlLCBVUERBVEUgbWVzc2FnZXMgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2 IGhhdmUgbm8gbWVjaGFuaXNtDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2 ICAgICAgIGZvciBmcmVzaG5lc3MgKGkuZSB0aW1lc3RhbXBzIG9yIHNlcXVlbmNlIG51 bWJlcnMpLiAgVGhpcw1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICAg ICBpbmRpY2F0ZXMgdGhhdCBtZXNzYWdlcyBtYXkgYXBwZWFyIHZhbGlkIGF0IGFueSBw b2ludCBpbiB0aGUgbGlmZQ1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAg ICAgICBvZiBhIEJHUCBwZWVyaW5nIHNlc3Npb24ufXtcY3MxNlx2XGYwXGZzMThcaW5z cnNpZDEzOTc2NDUxIHtcKlxhdG5pZCBTS317XCpcYXRuYXV0aG9yIFN0ZXBoZW4gS2Vu dH1cY2hhdG4ge1wqXGFubm90YXRpb257XCpcYXRuZGF0ZSAxMTg0MDU2MDA5fVxwYXJk XHBsYWluIA1cczE3XHFsIFxsaTBccmkwXHdpZGN0bHBhclxhc3BhbHBoYVxhc3BudW1c ZmFhdXRvXGFkanVzdHJpZ2h0XHJpbjBcbGluMFxpdGFwMCBcbGFuZzEwMzNcbGFuZ2Zl MTAzM1xjZ3JpZFxsYW5nbnAxMDMzXGxhbmdmZW5wMTAzMyB7XGNzMTZcZnMxOFxpbnNy c2lkMTM5NzY0NTEgXGNoYXRuIH17XGluc3JzaWQxMzk3NjQ1MSBJbiANZmFjdCwgdGhl IHByb2JsZW0gaXMgd29yc2UsIHNpbmNlIHRoZSBtZXNzYWdlcyBhcmUgdmFsaWQgYmV5 b25kIHRoZSBsaWZldGltZSBvZiBhIHBlZXJpbmcgc2Vzc2lvbi59fX17XGRiY2hcZjE1 XGluc3JzaWQxMzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMgDVxwYXIgXGhpY2hcYWY2XGRi Y2hcYWYxNVxsb2NoXGY2ICAgIG8gIEludGVyLUFTIHdpdGhkcmF3IG1lc3NhZ2UgYXNz dW1wdGlvbnM6IFRoZSBwcm9jZXNzaW5nIG1vZGVsIG9mIFxoaWNoXGFmNlxkYmNoXGFm MTVcbG9jaFxmNiBCR1ANXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAg ICAgUkZDMTc3MSBbM10gaW5kaWNhdGVzIHRoYXQgb25seSB0aGUgcGVlciBhZHZlcnRp c2luZyBOTFJJDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgICAgIGlu Zm9ybWF0aW9uIG1heSB3aXRoZHJhdyBpdC4gIFRoZXJlIGFyZSBzZXZlcmFsIGluc3Rh bmNlcyB3aGVyZSBhDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgICAg IHdpdGhkcmF3IG1heSBvY2N1ci4gIFR5cGljYWwgcmVhc29ucyBmb3Igd2l0aGRyYXcg aW5jbHVkZSB0aGUNXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgICAg ZGV0ZXJtaW5hdGlvbiBvZiBhIGJldHRlciBwYXRoLCBwZWVyIHNlc3NpXGhpY2hcYWY2 XGRiY2hcYWYxNVxsb2NoXGY2IG9uIGZhaWx1cmUsIG9yIGxvY2FsDVxwYXIgXGhpY2hc YWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgICAgIHBvbGljeSBjaGFuZ2UuICBUaGVyZSBp cyBubyBzcGVjaWZpZWQgbWVjaGFuaXNtIGZvciBpbmRpY2F0aW5nLCB0bw1ccGFyIFxo aWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICAgICBhbiBleHRlcm5hbCBwZWVyLCB0 aGUgcmVhc29uIGZvciBhIHJvdXRlIHdpdGhkcmF3LiAgRWFjaCB3aXRoZHJhdw1ccGFy IA1ccGFyIA1ccGFyIA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiBDaHJp c3RpYW4gICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMSwgMjAwNCAgICAgICAg ICAgICAgICAgW1BhZ2UgNF0NXHBhciBccGFnZSANXHBhciBcaGljaFxhZjZcZGJjaFxh ZjE1XGxvY2hcZjYgSW50ZXJuZXQtRHJhXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2 IGZ0ICAgICAgICAgQkdQIFNlY3VyaXR5IFJlcXVpcmVtZW50cyAgICAgICAgICAgICAg ICBGZWIgMjAwNA1ccGFyIA1ccGFyIA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9j aFxmNiAgICAgICByZWNlaXZlZCBmcm9tIGEgdmFsaWQgcGVlcmluZyBzZXNzaW9uIG11 c3QgYmUgdGFrZW4gYXQgZmFjZSB2YWx1ZS4NXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1 XGxvY2hcZjYgICAgICAgVGhlcmUgaXMgbm8sIGV4aXN0aW5nLCBtZXRob2QgdG8gZW5z dXJlIHRoYXQgYW4gQVMgd2lsbCBwcm9wZXJseQ1ccGFyIFxoaWNoXGFmNlxkYmNoXGFm MTVcbG9jaFxmNiAgICAgICBwcm9wYWdhdGUgd2l0aGRyYXcgbWVzc2FnZXMgcmVjZWl2 ZWQgZnJvbSBpXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IHQncyBleHRlcm5hbCBw ZWVycy59e1xjczE2XHZcZjBcZnMxOFxpbnNyc2lkMTM5NzY0NTEge1wqXGF0bmlkIFNL fXtcKlxhdG5hdXRob3IgU3RlcGhlbiBLZW50fVxjaGF0biB7XCpcYW5ub3RhdGlvbntc KlxhdG5kYXRlIDExODQwNTYwMTB9XHBhcmRccGxhaW4gDVxzMTdccWwgXGxpMFxyaTBc d2lkY3RscGFyXGFzcGFscGhhXGFzcG51bVxmYWF1dG9cYWRqdXN0cmlnaHRccmluMFxs aW4wXGl0YXAwIFxsYW5nMTAzM1xsYW5nZmUxMDMzXGNncmlkXGxhbmducDEwMzNcbGFu Z2ZlbnAxMDMzIHtcY3MxNlxmczE4XGluc3JzaWQxMzk3NjQ1MSBcY2hhdG4gfXtcaW5z cnNpZDEzOTc2NDUxIA1BbHNvIG5vdGUgdGhlIHRpbWVsaW5lc3MgaXNzdWUgaGVyZSwg ZS5nLiwgLCBhbmQgb2xkIGFkdmVydGlzZW1lbnQgY2FuIGJlIHJlaXNzdWVkIGJ5IGEg c3BlYWtlciBhZnRlciBjb3JyZWN0bHkgc2VuZGluZyBhIHdpdGhkcmF3YWwufX19e1xk YmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIA1ccGFyIFxoaWNo XGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBvICBBUy1QYXRoIGFzc3VtcHRpb25zOiBB c2lkZSBmcm9tIHRoZSB1c2Ugb2YgQVMtU2V0LCB0aGUgQVMtUGF0aCBpcw1ccGFyIFxo aWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICAgICB0eXBpY2FsbHkgY29uc2lkZXJl ZCB0byBiZSBhbiBvcmRlcmVkIGxpc3Qgb2YgdGhlIEF1dG9ub21vdXMNXHBhciBcaGlj aFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgICAgU3lzdGVtcyB0aGF0IGFuIHVwZGF0 ZSBoYXMgdHJhdmVyc2VkLiAgSW4gbW9zdCBjYXNlcyB0aGUgZmlyc3QgQVMNXHBhciBc aGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgICAgaW4gdGhlIGxpc3QgaXMgdGhl XGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICBvcmlnaW4gQVN9e1xjczE2XHZcZjBc ZnMxOFxpbnNyc2lkMTM5NzY0NTEge1wqXGF0bmlkIFNLfXtcKlxhdG5hdXRob3IgU3Rl cGhlbiBLZW50fVxjaGF0biB7XCpcYW5ub3RhdGlvbntcKlxhdG5kYXRlIDExODQwNTYw Mjh9XHBhcmRccGxhaW4gDVxzMTdccWwgXGxpMFxyaTBcd2lkY3RscGFyXGFzcGFscGhh XGFzcG51bVxmYWF1dG9cYWRqdXN0cmlnaHRccmluMFxsaW4wXGl0YXAwIFxsYW5nMTAz M1xsYW5nZmUxMDMzXGNncmlkXGxhbmducDEwMzNcbGFuZ2ZlbnAxMDMzIHtcY3MxNlxm czE4XGluc3JzaWQxMzk3NjQ1MSBcY2hhdG4gfXtcaW5zcnNpZDEzOTc2NDUxIEJHUCBk ZWZpbmVzIHRoZSBsYXN0IEFTIGluIHRoZSBwYXRoIGFzIHRoZSBvcmlnaW4gaW4gYWxs IGNhc2VzLCBkb2Vzbg1ccnF1b3RlIHQgaXQ/fX19e1xkYmNoXGYxNVxpbnNyc2lkMTM5 NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAs IG9yIGF0IGxlYXN0IHRoZSBBUyByZXNwb25zaWJsZSBmb3INXHBhciBcaGljaFxhZjZc ZGJjaFxhZjE1XGxvY2hcZjYgICAgICAgdGhlIG1hbmFnZW1lbnQgb2YgdGhlIE5MUkkg aW5mb3JtYXRpb24gYXNzb2NpYXRlZCB3aXRoIHRoZSBmaXJzdA1ccGFyIFxoaWNoXGFm NlxkYmNoXGFmMTVcbG9jaFxmNiAgICAgICBBUy4gIFNwZWNpZmljYXRpb25zIHN0YXRl IHRoYXQgdGhlIEFTIHRvcG9sb2d5IG11c3QgYmUgbG9vcCBmcmVlLg1ccGFyIFxoaWNo XGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICAgICBUaGlzIGluZGljYXRlcyB0aGF0IHRo ZSBhcHBlYXJhbmNlIG9mIHRoZSBsb2NhbCBBUyBpbiBhbiB1cFxoaWNoXGFmNlxkYmNo XGFmMTVcbG9jaFxmNiBkYXRlDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2 ICAgICAgIHJlY2VpdmVkIGZyb20gYW4gZXh0ZXJuYWwgcGVlciBpcyBnZW5lcmFsbHkg bm90IHBlcm1pdHRlZH17XGNzMTZcdlxmMFxmczE4XGluc3JzaWQxMzk3NjQ1MSB7XCpc YXRuaWQgU0t9e1wqXGF0bmF1dGhvciBTdGVwaGVuIEtlbnR9XGNoYXRuIHtcKlxhbm5v dGF0aW9ue1wqXGF0bmRhdGUgMTE4NDA1NjAxMn1ccGFyZFxwbGFpbiANXHMxN1xxbCBc bGkwXHJpMFx3aWRjdGxwYXJcYXNwYWxwaGFcYXNwbnVtXGZhYXV0b1xhZGp1c3RyaWdo dFxyaW4wXGxpbjBcaXRhcDAgXGxhbmcxMDMzXGxhbmdmZTEwMzNcY2dyaWRcbGFuZ25w MTAzM1xsYW5nZmVucDEwMzMge1xjczE2XGZzMThcaW5zcnNpZDEzOTc2NDUxIFxjaGF0 biB9e1xpbnNyc2lkMTM5NzY0NTEgV2hlbiBpcyBpdCBwZXJtaXR0ZWRlP319fXtcZGJj aFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyANXGhpY2hcYWY2XGRi Y2hcYWYxNVxsb2NoXGY2IC4gIFRoZQ1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9j aFxmNiAgICAgICBwcmVwZW5kaW5nIG9mIEFTIGluZm9ybWF0aW9uIGZvciByZWNlaXZl ZCB1cGRhdGVzIGFuZCB0cmFuc21pdHRlZA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVc bG9jaFxmNiAgICAgICB1cGRhdGVzIGlzIGdlbmVyYWxseSBwZXJtaXR0ZWQgYW5kIGlz IGNvbW1vbiBwcmFjdGljZS4gIFByZXBlbmRlZA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFm MTVcbG9jaFxmNiAgICAgICBBUyBpbmZvcm1hdGlvbiBvbiBpbmJvdW5kIGFkdmVcaGlj aFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgcnRpc2VtZW50cyAod2hlcmUgdGhlIGV4dGVy bmFsIHBlZXJzDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgICAgIEFT IGlzIHByZXBlbmRlZCkgYW5kIG91dGJvdW5kIGFkdmVydGlzZW1lbnRzICh3aGVyZSB0 aGUgbG9jYWwgQVMNXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgICAg bnVtYmVyIGlzIHByZXBlbmRlZCkgaXMgYSBjb21tb25seSB1c2VkIG1ldGhvZCB0byBl ZmZlY3QNXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgICAgZm9yd2Fy ZGluZyBjaGFuZ2VzLn17XGNzMTZcdlxmMFxmczE4XGluc3JzaWQxMzk3NjQ1MSB7XCpc YXRuaWQgU0t9e1wqXGF0bmF1dGhvciBTdGVwaGVuIEtlbnR9XGNoYXRuIHtcKlxhbm5v dGF0aW9ue1wqXGF0bmRhdGUgMTE4NDA1NjAxM31ccGFyZFxwbGFpbiANXHMxN1xxbCBc bGkwXHJpMFx3aWRjdGxwYXJcYXNwYWxwaGFcYXNwbnVtXGZhYXV0b1xhZGp1c3RyaWdo dFxyaW4wXGxpbjBcaXRhcDAgXGxhbmcxMDMzXGxhbmdmZTEwMzNcY2dyaWRcbGFuZ25w MTAzM1xsYW5nZmVucDEwMzMge1xjczE2XGZzMThcaW5zcnNpZDEzOTc2NDUxIFxjaGF0 biB9e1xpbnNyc2lkMTM5NzY0NTEgDVRoaXMgc2VlbXMgbGlrZSBhbiBvdmVybHkgY29t cGxleCBzdGF0ZW1lbnQuIFdoeSBub3QganVzdCBzYXkgdGhhdCBCR1AgYWxsb3dzIGFu IEFTIHRvIHByZXBlbmQgaXRzIG93biBBUyBudW1iZXIgbW9yZSB0aGFuICBvbmNlLCBh cyBhIGxlZ2l0aW1hdGUgbWVhbnMgb2YgYmlhc2luZyBvdGhlciBBU2VzIGFnYWluc3Qg c2VsZWN0aW9uIG9mIGEgcm91dGU/fX19e1xkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFc Y2hhcnJzaWQ2MDMzNzQzIA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAg ICBvICBSb3V0ZSBPcmlnaW5hdGlvbjogT3JpZ2luYXRpbmcgYSByb3V0ZSB3aXRob3V0 IHRoZSBhXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IGJpbGl0eSB0bw1ccGFyIFxo aWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICAgICBmb3J3YXJkIHRoZSB0cmFmZmlj IGFzc29jaWF0ZWQgd2l0aCB0aGF0IHJvdXRlIGlzLCBpbiBtb3N0IGNhc2VzLA1ccGFy IFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICAgICBpbiBjb25mbGljdCB3aXRo IHRoZSBpbnRlbnQgb2YgdGhlIEJHUCBzcGVjaWZpY2F0aW9uLn17XGNzMTZcdlxmMFxm czE4XGluc3JzaWQxMzk3NjQ1MSB7XCpcYXRuaWQgU0t9e1wqXGF0bmF1dGhvciBTdGVw aGVuIEtlbnR9XGNoYXRuIHtcKlxhbm5vdGF0aW9ue1wqXGF0bmRhdGUgMTE4NDA1NTk0 NX1ccGFyZFxwbGFpbiANXHMxN1xxbCBcbGkwXHJpMFx3aWRjdGxwYXJcYXNwYWxwaGFc YXNwbnVtXGZhYXV0b1xhZGp1c3RyaWdodFxyaW4wXGxpbjBcaXRhcDAgXGxhbmcxMDMz XGxhbmdmZTEwMzNcY2dyaWRcbGFuZ25wMTAzM1xsYW5nZmVucDEwMzMge1xjczE2XGZz MThcaW5zcnNpZDEzOTc2NDUxIFxjaGF0biB9e1xpbnNyc2lkMTM5NzY0NTEgV2hlbiBp cyBpdCBub3Q/fX19e1xkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMz NzQzIA1caGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICBCR1ANXHBhciBcaGljaFxh ZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgICAgc3BlYWtlcnMgbWF5IG9yaWdpbmF0ZSBy b3V0ZXMgYmFzZWQgb24gdmFyaW91cyBpbnRlcm5hbCBhbmQNXHBhciBcaGljaFxhZjZc ZGJjaFxhZjE1XGxvY2hcZjYgICAgICAgZXh0ZXJuYWwgZGF0YS4gIEFuIEF1dG9ub21v dXMgU3lzdGVtXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICBzaG91bGQgb25seSBv cmlnaW5hdGUgYQ1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICAgICBw cmVmaXggdG8gaXQncyBleHRlcm5hbCBwZWVycyBpZiB0aGF0IHByZWZpeCBoYXMgYmVl biBzb21laG93DVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgICAgIGFs bG9jYXRlZCB0byB0aGUgYWRtaW5pc3RyYXRvcnMgb2YgdGhhdCBzeXN0ZW0sIG9yIGF1 dGhvcml6ZWQgYnkNXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgICAg dGhlIHByZWZpeCBob2xkZXJzLg1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxm NiAgICBvICBBZ2dyZWdhdGlvbjogQWdncmVnYXRpb24sIGFuZCBkZWFnZ3JlZ2F0aW9u LCBvZiBwcmVmaXhlcyBjYW5caGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgIGNhdXNl DVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgICAgIHNpZ25pZmljYW50 IGlzc3VlcyB3aXRoIHByb3Bvc2VkIHNlY3VyaXR5IG1lY2hhbmlzbXN9e1xjczE2XHZc ZjBcZnMxOFxpbnNyc2lkMTM5NzY0NTEge1wqXGF0bmlkIFNLfXtcKlxhdG5hdXRob3Ig U3RlcGhlbiBLZW50fVxjaGF0biB7XCpcYW5ub3RhdGlvbntcKlxhdG5kYXRlIDExODQw NTU5NDV9XHBhcmRccGxhaW4gDVxzMTdccWwgXGxpMFxyaTBcd2lkY3RscGFyXGFzcGFs cGhhXGFzcG51bVxmYWF1dG9cYWRqdXN0cmlnaHRccmluMFxsaW4wXGl0YXAwIFxsYW5n MTAzM1xsYW5nZmUxMDMzXGNncmlkXGxhbmducDEwMzNcbGFuZ2ZlbnAxMDMzIHtcY3Mx NlxmczE4XGluc3JzaWQxMzk3NjQ1MSBcY2hhdG4gfXtcaW5zcnNpZDEzOTc2NDUxIA1U aGlzIGlzIGEgcmVxdWlyZW1lbnRzIGRvY3VtZW50LCBzbyBjb21tZW50cyBhYm91dCB3 aGF0IHByb3Bvc2VkIHNvbHV0aW9ucyBtYXkgb3IgbWF5IG5vdCBiZSBhYmxlIHRvIGRv IGFyZSBvdXQgb2Ygc2NvcGUufX19e1xkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hh cnJzaWQ2MDMzNzQzIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAuICBBY2NvcmRp bmcNXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgICAgdG8gUkZDIDE3 NzEsIGlmIGEgQkdQIHNwZWFrZXIgY2hvb3NlcyB0byBhZ2dyZWdhdGUgYSBzZXQgb2Yg bW9yZQ1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICAgICBzcGVjaWZp YyBwcmVmaXhlcyBpbnRvIGEgbGVzcyBzcGVjaWZpYyBwcmVmaXggdGhlbiB0aGUNXHBh ciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgICAgQVRPTUlDX0FHR1JFR0FU RSBhdHRyaWJ1dGUgU0hPVUxEIGJlIHNlXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2 IHQuICBUaGlzIGNyZWF0ZXMgYQ1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxm NiAgICAgICBzaWduaWZpY2FudCBwb3RlbnRpYWwgbG9vcGhvbGUgaW4gYW4gYXR0ZW1w dCB0byBzZWN1cmUgQkdQIGJhc2VkDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2No XGY2ICAgICAgIG9uIHRoZSBSRkMgc3BlY2lmaWNhdGlvbnMufXtcY3MxNlx2XGYwXGZz MThcaW5zcnNpZDEzOTc2NDUxIHtcKlxhdG5pZCBTS317XCpcYXRuYXV0aG9yIFN0ZXBo ZW4gS2VudH1cY2hhdG4ge1wqXGFubm90YXRpb257XCpcYXRuZGF0ZSAxMTg0MDU1OTQ3 fVxwYXJkXHBsYWluIA1cczE3XHFsIFxsaTBccmkwXHdpZGN0bHBhclxhc3BhbHBoYVxh c3BudW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJpbjBcbGluMFxpdGFwMCBcbGFuZzEwMzNc bGFuZ2ZlMTAzM1xjZ3JpZFxsYW5nbnAxMDMzXGxhbmdmZW5wMTAzMyB7XGNzMTZcZnMx OFxpbnNyc2lkMTM5NzY0NTEgXGNoYXRuIH17XGluc3JzaWQxMzk3NjQ1MSBJXHJxdW90 ZSANbSBhbGwgaW4gZmF2b3Igb2Ygbm90aW5nIHdoYXQgdGhlIFJGQyBzYXlzIGEgcHJv cGVybHkgb3BlcmF0aW5nIHNwZWFrZXIgc2hvdWxkIGRvIHJlIGFnZ3JlZ2F0aW9uLCBh cyB0aGF0IGhlbHBzIGRlZmluZSB3aGF0IGRldmlhdGlvbnMgZnJvbSBjb3JyZWN0IGJl aGF2aW9yIGNhbiBiZSByZWxpYWJseSBkZXRlY3RlZCwgYW5kIHdoYXQgbWF5IGJlIGhh cmQsIGJlY2F1c2UgdGhlIGJlaGF2aW9yIGlzIGEgU0hPVUxEIHZzLiBhIE1VU1QufX19 ew1cZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyANXHBhciAN XHBhciANXHBhciANXHBhciANXHBhciANXHBhciANXHBhciANXHBhciANXHBhciANXHBh ciANXHBhciANXHBhciANXHBhciANXHBhciANXHBhciANXHBhciANXHBhciANXHBhciAN XHBhciANXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgQ2hyaXN0aWFuICAg ICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDEsIDIwMDQgICAgICAgICAgICAgICAg IFtQYWdlIDVdDVxwYXIgXHBhZ2UgDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2No XGY2IEludGVybmV0LURyYWZ0ICAgICAgICAgQkdQIFNlY3VyaXR5IFJlXGhpY2hcYWY2 XGRiY2hcYWYxNVxsb2NoXGY2IHF1aXJlbWVudHMgICAgICAgICAgICAgICAgRmViIDIw MDQNXHBhciANXHBhciANXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgMy4g IH17XGNmMFxyZXZpc2VkXHJldmF1dGgxXHJldmR0dG0xMTg0MDU1OTQ4XGRiY2hcZjE1 XGluc3JzaWQxMzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYx NVxsb2NoXGY2IE9wZXJhdGlvbmFsIH17XGRiY2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxj aGFycnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IFJlcXVpcmVt ZW50cw1ccGFyIA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBXZSBo YXZlIGRldGVybWluZWQsIHRocm91Z2ggZGlzY3Vzc2lvbiB3aXRoIHNldmVyYWwgbGFy Z2UNXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgaW50ZXJuZXR3b3Jr IG9wZXJhdG9ycyBhbmQgZXF1aXBtZW50IHZlbmRvcnMsIHRoYXQgdGhlIGZvbGxvd2lu Zw1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBhdHRyaWJ1dGVzIGFy ZSBpbXBvcnRhbnQgdG8gdGhlIG9uZ29pbmcgcGVyZm9ybWFuY2Ugb2YgaW5caGljaFxh ZjZcZGJjaFxhZjE1XGxvY2hcZjYgdGVyfXtcY2YwXHJldmlzZWRccmV2YXV0aDFccmV2 ZHR0bTExODQwNTU5NDhcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAz Mzc0MyBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgLX17DVxkYmNoXGYxNVxpbnNy c2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9j aFxmNiBkb21haW4NXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgcm91 dGluZyBzeXN0ZW1zIHN1Y2ggYXMgQkdQDVxwYXIgDVxwYXIgXGhpY2hcYWY2XGRiY2hc YWYxNVxsb2NoXGY2IDMuMSAgQ29udmVyZ2VuY2Ugc3BlZWQNXHBhciANXHBhciBcaGlj aFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgQ29udmVyZ2VuY2Ugc3BlZWQgaXMgYSBt YWpvciBjb25jZXJuIHRvIG1hbnkgb3BlcmF0b3JzIG9mIGxhcmdlIHNjYWxlDVxwYXIg XGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIGludGVybmV0d29ya2luZyBzeXN0 ZW1zLiAgTmV0d29ya3MsIGFuZCBpbnRlcm5ldHdvcmtzLCBhcmUgY2FycnlpbmcNXHBh ciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgZXZlciBpbmNyZWFzaW5nIGFt b3VudHMgb2YgaW5mb3JtYXRpb24gdGhhXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2 IHQgaXMgdGltZSBhbmQgZGVsYXkNXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hc ZjYgICAgc2Vuc2l0aXZlOyBpbmNyZWFzaW5nIGNvbnZlcmdlbmNlIHRpbWVzIGNhbiBh ZHZlcnNlbHkgYWZmZWN0IHRoZQ1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxm NiAgICB1c2FiaWxpdHkgb2YgdGhlIG5ldHdvcmssIGFuZCB0aGUgYWJpbGl0eSBvZiBh biBpbnRlcm5ldHdvcmsgdG8gZ3Jvdy4NXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxv Y2hcZjYgICAgQkdQJ3MgY29udmVyZ2VuY2Ugc3BlZWQsIHdpdGggYSBzZWN1cml0eSBz eXN0ZW0gaW4gb3BlcmF0aW9uLCBTSE9VTER9e1xjczE2XHZcZjBcZnMxOFxpbnNyc2lk MTM5NzY0NTEge1wqXGF0bmlkIFNLfXtcKlxhdG5hdXRob3IgU3RlcGhlbiBLZW50fVxj aGF0biB7XCpcYW5ub3RhdGlvbntcKlxhdG5kYXRlIDExODQwNTYwMjd9XHBhcmRccGxh aW4gDVxzMTdccWwgXGxpMFxyaTBcd2lkY3RscGFyXGFzcGFscGhhXGFzcG51bVxmYWF1 dG9cYWRqdXN0cmlnaHRccmluMFxsaW4wXGl0YXAwIFxsYW5nMTAzM1xsYW5nZmUxMDMz XGNncmlkXGxhbmducDEwMzNcbGFuZ2ZlbnAxMDMzIHtcY3MxNlxmczE4XGluc3JzaWQx Mzk3NjQ1MSBcY2hhdG4gfXtcaW5zcnNpZDEzOTc2NDUxIEkgY2hhbGxlbmdlIHdoZXRo ZXIgdGhpcyBpcyBhIHJlYWxpc3RpYyByZXF1aXJlbWVudCwgdnMuIGp1c3QgYXMgDVxs ZGJscXVvdGUgbmljZSB0byBoYXZlXHJkYmxxdW90ZSAgZ2l2ZW4gb3VyIHVzdWFsIGV4 cGVyaWVuY2Ugd2l0aCBkZXBsb3ltZW50IG9mIHNlY3VyaXR5IG1lY2hhbmlzbXMuIEFs c28sIFxsZGJscXVvdGUgZXF1aXZhbGVudFxyZGJscXVvdGUgIGlzIG5vdCB2ZXJ5IHBy ZWNpc2UuIENvbnZlcmdlbmNlIHRpbWVzIHZhcnkgY29uc2lkZXJhYmx5LCBkb25ccnF1 b3RlIA10IHRoZXk/IFNvIGEgYmV0dGVyIHN0YXRlbWVudCBoZXJlIG1pZ2h0IGJlIGV4 cHJlc3NlZCBpbiB0ZXJtcyBvZiBzdGFuZGFyZCBkZXZpYXRpb25zIGZyb20gYSBtZWRp YW4gdmFsdWUsIG9yIHNvbWV0aGluZyBsaWtlIHRoYXQufX19e1xkYmNoXGYxNVxpbnNy c2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFm MTVcbG9jaFxmNiAgICBiZSBlcXVpdmFsZW50IHRvIEJHXGhpY2hcYWY2XGRiY2hcYWYx NVxsb2NoXGY2IFAgcnVubmluZyB3aXRob3V0IHRoZSBzZWN1cml0eSBzeXN0ZW0gaW4N XHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgb3BlcmF0aW9uLiAgVGhp cyBpbmNsdWRlcyB0aGUgcHJlc2VydmF0aW9uIG9mIG9wdGltaXphdGlvbnMgY3VycmVu dGx5DVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIHVzZWQgdG8gcHJv ZHVjZSBhY2NlcHRhYmxlIGNvbnZlcmdlbmNlIHNwZWVkcyBvbiBjdXJyZW50IGhhcmR3 YXJlLA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBpbmNsdWRpbmcg dXBkYXRlIHBhY2tpbmcsIHBlZXIgZ3JvdXBzLCBhbmQgb3RoZXJzLiAgQ3VycmVudCB0 aW1lcnMsDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICBcaGljaFxhZjZc ZGJjaFxhZjE1XGxvY2hcZjYgICBpbmNsdWRpbmcgaG9sZCB0aW1lcnMsIGtlZXBhbGl2 ZSB0aW1lcnMsIGFuZCB0aGUgcGVlcmluZyBwcm9jZXNzLA1ccGFyIFxoaWNoXGFmNlxk YmNoXGFmMTVcbG9jaFxmNiAgICBTSE9VTEQgTk9UIGJlIGltcGFjdGVkIGJ5IHRoZSBz ZWN1cml0eSBzeXN0ZW19e1xjczE2XHZcZjBcZnMxOFxpbnNyc2lkMTM5NzY0NTEge1wq XGF0bmlkIFNLfXtcKlxhdG5hdXRob3IgU3RlcGhlbiBLZW50fVxjaGF0biB7XCpcYW5u b3RhdGlvbntcKlxhdG5kYXRlIDExODQwNTYwMTV9XHBhcmRccGxhaW4gDVxzMTdccWwg XGxpMFxyaTBcd2lkY3RscGFyXGFzcGFscGhhXGFzcG51bVxmYWF1dG9cYWRqdXN0cmln aHRccmluMFxsaW4wXGl0YXAwIFxsYW5nMTAzM1xsYW5nZmUxMDMzXGNncmlkXGxhbmdu cDEwMzNcbGFuZ2ZlbnAxMDMzIHtcY3MxNlxmczE4XGluc3JzaWQxMzk3NjQ1MSBcY2hh dG4gfXtcaW5zcnNpZDEzOTc2NDUxIA1JcyB0aGlzIHJlcXVpcmVtZW50IHN0YXRlZCBi ZWNhdXNlIGV4cGVyaWVuY2Ugc2hvd3MgdGhhdCAgb3BlcmF0b3JzIG5ldmVyIGNoYW5n ZSB0aGVzZSB0aW1lcnMgKGxlYXZlIHRoZW0gYXQgZmFjdG9yeSBkZWZhdWx0cykgb3Ig dGhhdCBjaGFuZ2VzIGFyZSAgZGFuZ2Vyb3VzIGFuZCB0aGVyZWZvcmUgYXJlIHJhcmVs eSBtYWRlIG9yIHdoYXQ/fX19e1xkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hhcnJz aWQ2MDMzNzQzIA1caGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgLiAgVHdvIHR5cGVz IG9mDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIHZlcmlmaWNhdGlv biBNQVkgYmUgb2ZmZXJlZCBmb3IgdGhlIE5MUkkgYW5kIHRoZSBBU19QQVRIIGluIG9y ZGVyIHRvDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIGFsbG93IGZv ciBhIHNlbGVjdGlvbiBvZiBvcHRpbWl6YXRpb25zOg1ccGFyIFxoaWNoXGFmNlxkYmNo XGFmMTVcbG9jaFxmNiAgICBvICBDb1xoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiBu dGVudHMgb2YgdGhlIFVQREFURSBtZXNzYWdlIFNIT1VMRCBiZSBhdXRoZW50aWNhdGVk IGluDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgICAgIHJlYWwtdGlt ZSBhcyB0aGUgVVBEQVRFIG1lc3NhZ2UgaXMgcHJvY2Vzc2VkLg1ccGFyIFxoaWNoXGFm NlxkYmNoXGFmMTVcbG9jaFxmNiAgICBvICBUaGUgcm91dGUgaW5mb3JtYXRpb24gYmFz ZSBNQVkgYmUgYXV0aGVudGljYXRlZCBwZXJpb2RpY2FsbHkgb3IgaW4NXHBhciBcaGlj aFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgICAgYW4gZXZlbnQgZHJpdmVuIG1hbm5l ciBieSBzY2FubmluZyB0aGUgZGF0YX17XGNzMTZcdlxmMFxmczE4XGluc3JzaWQxMzk3 NjQ1MSB7XCpcYXRuaWQgU0t9e1wqXGF0bmF1dGhvciBTdGVwaGVuIEtlbnR9XGNoYXRu IHtcKlxhbm5vdGF0aW9ue1wqXGF0bmRhdGUgMTE4NDA1NTk1Nn1ccGFyZFxwbGFpbiAN XHMxN1xxbCBcbGkwXHJpMFx3aWRjdGxwYXJcYXNwYWxwaGFcYXNwbnVtXGZhYXV0b1xh ZGp1c3RyaWdodFxyaW4wXGxpbjBcaXRhcDAgXGxhbmcxMDMzXGxhbmdmZTEwMzNcY2dy aWRcbGFuZ25wMTAzM1xsYW5nZmVucDEwMzMge1xjczE2XGZzMThcaW5zcnNpZDEzOTc2 NDUxIFxjaGF0biB9e1xpbnNyc2lkMTM5NzY0NTEgV2hpY2ggZGF0YT8gVGhlIExvYy1S SUIsIGVhY2ggQWRqLVJJQi1JbiwgXHVjMVx1ODIzMFwnYzk/fX19ew1cZGJjaFxmMTVc aW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyBcaGljaFxhZjZcZGJjaFxhZjE1 XGxvY2hcZjYgIGFuZCB2ZXJpZnlpbmcgdGhlDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYx NVxsb2NoXGY2ICAgICAgIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiBvcmlnaW5h dGluZyBBUyBhbmQgdGhlIHZlcmlmaWFiaWxpdHkgb2YgdGhlIEFTLVBBVEggbGlzdC59 e1xjczE2XHZcZjBcZnMxOFxpbnNyc2lkMTM5NzY0NTEge1wqXGF0bmlkIFNLfXtcKlxh dG5hdXRob3IgU3RlcGhlbiBLZW50fVxjaGF0biB7XCpcYW5ub3RhdGlvbntcKlxhdG5k YXRlIDExODQwNTU5NTZ9XHBhcmRccGxhaW4gDVxzMTdccWwgXGxpMFxyaTBcd2lkY3Rs cGFyXGFzcGFscGhhXGFzcG51bVxmYWF1dG9cYWRqdXN0cmlnaHRccmluMFxsaW4wXGl0 YXAwIFxsYW5nMTAzM1xsYW5nZmUxMDMzXGNncmlkXGxhbmducDEwMzNcbGFuZ2ZlbnAx MDMzIHtcY3MxNlxmczE4XGluc3JzaWQxMzk3NjQ1MSBcY2hhdG4gfXtcaW5zcnNpZDEz OTc2NDUxIA1UaGlzIG9wdGlvbiBzZWVtcyBtb3RpdmF0ZWQgYnkgYSBwZXJjZXB0aW9u IHRoYXQgdGhlIGZpcnN0IG9wdGlvbiB3aWxsIG5vdCBiZSBhdHRhaW5hYmxlLCByZWxh dGl2ZSB0byB0aGUgY29udmVyZ2VuY2Ugc3BlZWQgY3JpdGVyaWEuIEJ1dCwgdGhlcmUg aXMgbm8gYW5hbHlzaXMgaGVyZSBvZiB0aGUgZXh0ZW50IG9mIGRhbWFnZSB0aGF0IG1h eSByZXN1bHQgZnJvbSAgdGhpcyBkZWZlcnJlZCBjaGVja2luZywgZXNwZWNpYWxseSBz aW5jZSB0aA1lcmUgaXMgbm8gaW5kaWNhdGlvbiB0aGUgcGVyaW9kaWNpdHkgdGhhdCBt aWdodCBiZSBhY2NlcHRhYmxlLiB9fX17XGRiY2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxj aGFycnNpZDYwMzM3NDMgDVxwYXIgDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2No XGY2ICAgIEFsbCBCR1AgaW1wbGVtZW50YXRpb25zIHRoYXQgaW1wbGVtZW50IHNlY3Vy aXR5IE1VU1QgdXRpbGl6ZSBhdCBsZWFzdA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVc bG9jaFxmNiAgICBvbmUgb2YgdGhlIGFib3ZlIG1ldGhvZHMgZm9yIHZhbGlkYXRpbmcg cm91dGluZyBpbmZvcm1hdGlvbi4gIFJlYWwNXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1 XGxvY2hcZjYgICAgdGltZSB2ZXJpZmljYXRpb24gaXMgcHJlZmVycmVkIGluIG9yZGVy IHRvIHByZXZlbnRcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgIHRyYW5zaXRpdmUN XHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgZmFpbHVyZXN9e1xjczE2 XHZcZjBcZnMxOFxpbnNyc2lkMTM5NzY0NTEge1wqXGF0bmlkIFNLfXtcKlxhdG5hdXRo b3IgU3RlcGhlbiBLZW50fVxjaGF0biB7XCpcYW5ub3RhdGlvbntcKlxhdG5kYXRlIDEx ODQwNTYwMTl9XHBhcmRccGxhaW4gXHMxN1xxbCBcbGkwXHJpMFx3aWRjdGxwYXJcYXNw YWxwaGFcYXNwbnVtXGZhYXV0b1xhZGp1c3RyaWdodFxyaW4wXGxpbjBcaXRhcDAgDVxs YW5nMTAzM1xsYW5nZmUxMDMzXGNncmlkXGxhbmducDEwMzNcbGFuZ2ZlbnAxMDMzIHtc Y3MxNlxmczE4XGluc3JzaWQxMzk3NjQ1MSBcY2hhdG4gfXtcaW5zcnNpZDEzOTc2NDUx IFRoaXMgZG9lcyBub3Qgc2VlbSBsaWtlIHRoZSByaWdodCBleHBsYW5hdGlvbiBmb3Ig d2h5IHRoZSByZWFsdGltZSBvcHRpb24gaXMgcHJlZmVycmVkLiBJZiBlYWNoIEFTIGRl Y2lkZXMgd2hpY2ggbWV0aG9kIHRvIA1ccGFyIHVzZSwgdGhlbiB0aGUgb3B0aW9uIGNo b3NlbiBieSBvbmUgbmVpZ2hib3IsIG9yIGFuIEFTIGRvd25zdHJlYW0gb24NIGEgcGF0 aCBvdWdodCBhZmZlY3QgdGhlIGFiaWxpdHkgb2YgIGFub3RoZXIgQVMgdG8gdXNlIGVp dGhlciBvcHRpb24uIFRoZSBhcmd1bWVudCBmb3IgcmVhbHRpbWUgdmVyaWZpY2F0aW9u IHNob3VsZCBiZSB0aGF0IGRlbGF5aW5nIHZlcmlmaWNhdGlvbiBtYWtlcyBhbiBBUyB2 dWxuZXJhYmxlIGZvciBhIGxvbmdlciBwZXJpb2QsIGFuZCB0aGF0IGFmZmVjdHMgaXRc cnF1b3RlIA1zIHN1YnNjcmliZXJzIGFuZCBhbnkgbmVpZ2hib3IgQVNlcyB0aGF0IGRv IG5vdCBtYWtlIHVzZSBvZiBCR1Agc2VjdXJpdHkufX19e1xkYmNoXGYxNVxpbnNyc2lk MTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxm NiAgYmFzZWQgb24gcGVyaW9kaWMgb3IgZXZlbnQgZHJpdmVuIHNjYW4gaW50ZXJ2YWxz Lg1ccGFyIA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAzLjIgIEluY3Jl bWVudGFsIGRlcGxveW1lbnQNXHBhciANXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxv Y2hcZjYgICAgV2Ugd2lsbCBub3QgYmUgYWJsZSB0byBkZXBsb3kgYSBuZXdseSBzZWN1 cmVkIEJHUCBwcm90b2NvbA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAg ICBpbnN0YW50YW5lb3VzbHkgYW5kIHdpbGwgYmUgdW5hYmxlIHRvIGRpY3RhdGUgYSBw YXJ0aXRpb25pbmcgb2YgbGFyZ2UNXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hc ZjYgICAgfXtcY2YwXHJldmlzZWRccmV2YXV0aDFccmV2ZHR0bTExODQwNTU5NTdcZGJj aFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyBcaGljaFxhZjZcZGJj aFxhZjE1XGxvY2hcZjYgQVNlcyB9e1xkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hh cnJzaWQ2MDMzNzQzIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiBieSB9ew1cY2Yw XHJldmlzZWRccmV2YXV0aDFccmV2ZHR0bTExODQwNTU5NTdcZGJjaFxmMTVcaW5zcnNp ZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hc ZjYgbmV0d29caGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgcmsgfXtcZGJjaFxmMTVc aW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyBcaGljaFxhZjZcZGJjaFxhZjE1 XGxvY2hcZjYgDW9wZXJhdG9ycy4gIEJlY2F1c2Ugb2YgdGhpcywgdGhlcmUgYXJlIHNl dmVyYWwNXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgcmVxdWlyZW1l bnRzIHRoYXQgYW55IHByb3Bvc2VkIG1lY2hhbmlzbSB0byBzZWN1cmUgQkdQIG11c3Qg Y29uc2lkZXIuDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIG8gIEJH UCBNVVNUIHN1cHBvcnQgdHJhbnNtaXR0aW5nLCByZWNlaXZpbmcsIGFuZCBhY3Rpbmcg b24gYm90aA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICAgICBzZWN1 cmVkIGFuZCB1bnNlY3VyZWQgcm91dGluZyBpbmZvcm1hdGlvbiB3aXRoIHRoZSBzZWN1 cml0eSBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgc3lzdGVtDVxwYXIgXGhpY2hc YWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgICAgIGluIHBsYWNlLn17XGNzMTZcdlxmMFxm czE4XGluc3JzaWQxMzk3NjQ1MSB7XCpcYXRuaWQgU0t9e1wqXGF0bmF1dGhvciBTdGVw aGVuIEtlbnR9XGNoYXRuIHtcKlxhbm5vdGF0aW9ue1wqXGF0bmRhdGUgMTE4NDA1NTk2 MH1ccGFyZFxwbGFpbiBcczE3XHFsIFxsaTBccmkwXHdpZGN0bHBhclxhc3BhbHBoYVxh c3BudW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJpbjBcbGluMFxpdGFwMCANXGxhbmcxMDMz XGxhbmdmZTEwMzNcY2dyaWRcbGFuZ25wMTAzM1xsYW5nZmVucDEwMzMge1xjczE2XGZz MThcaW5zcnNpZDEzOTc2NDUxIFxjaGF0biB9e1xpbnNyc2lkMTM5NzY0NTEgV291bGQg aXQgYmUgYmV0dGVyIHRvIHNheSB0aGF0IGEgQkdQIHNlY3VyaXR5IG1lY2hhbmlzbSBN VVNUIGVuYWJsZSBlYWNoIEJHUCBzcGVha2VyIHRvIGNvbmZpZ3VyZSB1c2Ugb2YgdGhl IHNlY3VyaXR5IG1lY2hhbmlzbSBvbiBhIHBlci1wZWVyIGJhc2lzP319DX17XGRiY2hc ZjE1XGluc3JzaWQxMzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMgDVxwYXIgXGhpY2hcYWY2 XGRiY2hcYWYxNVxsb2NoXGY2ICAgIG8gIFRoZSBzZWN1cml0eSBzeXN0ZW0gTVVTVCBh bGxvdyB0aGUgZm9ybWluZyBvZiBwZWVyaW5nDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYx NVxsb2NoXGY2ICAgICAgIHJlbGF0aW9uc2hpcHMgYmV0d2VlbiBwZWVycyByZWdhcmRs ZXNzIG9mIHdoZXRoZXIgdGhlIHNlY3VyaXR5DVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYx NVxsb2NoXGY2ICAgICAgIHN5c3RlbSBpcyBpbiBwbGFjZX17XGNzMTZcdlxmMFxmczE4 XGluc3JzaWQxMzk3NjQ1MSB7XCpcYXRuaWQgU0t9e1wqXGF0bmF1dGhvciBTdGVwaGVu IEtlbnR9XGNoYXRuIHtcKlxhbm5vdGF0aW9ue1wqXGF0bmRhdGUgMTE4NDA1NTk2MX1c cGFyZFxwbGFpbiANXHMxN1xxbCBcbGkwXHJpMFx3aWRjdGxwYXJcYXNwYWxwaGFcYXNw bnVtXGZhYXV0b1xhZGp1c3RyaWdodFxyaW4wXGxpbjBcaXRhcDAgXGxhbmcxMDMzXGxh bmdmZTEwMzNcY2dyaWRcbGFuZ25wMTAzM1xsYW5nZmVucDEwMzMge1xjczE2XGZzMThc aW5zcnNpZDEzOTc2NDUxIFxjaGF0biB9e1xpbnNyc2lkMTM5NzY0NTEgV291bGQgdGhp cyAgYmUgY292ZXJlZCBieSBteSBzdWdnZXN0ZWQgdGV4dCBhYm92ZT99fX17DVxkYmNo XGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIA1ccGFyIFxoaWNoXGFm NlxkYmNoXGFmMTVcbG9jaFxmNiAgICBvICBNVVNUIGJlIGJhY2t3YXJkIGNvbXBhdGli bGUgaW4gdGhlIG1lc3NhZ2UgZm9ybWF0dGluZywNXHBhciBcaGljaFxhZjZcZGJjaFxh ZjE1XGxvY2hcZjYgICAgICAgdHJhbnNtaXNzaVxoaWNoXGFmNlxkYmNoXGFmMTVcbG9j aFxmNiBvbiwgYW5kIHByb2Nlc3Npbmcgb2Ygcm91dGluZyBpbmZvcm1hdGlvbiBjYXJy aWVkDVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2No XGY2IENocmlzdGlhbiAgICAgICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAxLCAyMDA0 ICAgICAgICAgICAgICAgICBbUGFnZSA2XQ1ccGFyIFxwYWdlIA1ccGFyIFxoaWNoXGFm NlxkYmNoXGFmMTVcbG9jaFxmNiBJbnRlcm5ldC1EcmFmdCAgICAgICAgIEJHUCBTZWN1 cml0eSBSZXF1aXJlbWVudHMgICAgICAgICAgICAgICAgRmViIDIwMDQNXHBhciANXHBh ciANXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgICAgdGhyb3VnaCBh IG1peGVkIHNlY3VyaXR5IGVudmlyb25tZW50LiAgTWVzc2FnZSBcaGljaFxhZjZcZGJj aFxhZjE1XGxvY2hcZjYgZm9ybWF0dGluZyBpbiBhDVxwYXIgXGhpY2hcYWY2XGRiY2hc YWYxNVxsb2NoXGY2ICAgICAgIGZ1bGx5IHNlY3VyZWQgZW52aXJvbm1lbnQgTUFZIGJl IGhhbmRsZWQgaW4gYSBub24tYmFja3dhcmQNXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1 XGxvY2hcZjYgICAgICAgY29tcGF0aWJsZSBmYXNoaW9uLn17XGNzMTZcdlxmMFxmczE4 XGluc3JzaWQxMzk3NjQ1MSB7XCpcYXRuaWQgU0t9e1wqXGF0bmF1dGhvciBTdGVwaGVu IEtlbnR9XGNoYXRuIHtcKlxhbm5vdGF0aW9ue1wqXGF0bmRhdGUgMTE4NDA1NTk2NX1c cGFyZFxwbGFpbiANXHMxN1xxbCBcbGkwXHJpMFx3aWRjdGxwYXJcYXNwYWxwaGFcYXNw bnVtXGZhYXV0b1xhZGp1c3RyaWdodFxyaW4wXGxpbjBcaXRhcDAgXGxhbmcxMDMzXGxh bmdmZTEwMzNcY2dyaWRcbGFuZ25wMTAzM1xsYW5nZmVucDEwMzMge1xjczE2XGZzMThc aW5zcnNpZDEzOTc2NDUxIFxjaGF0biB9e1xpbnNyc2lkMTM5NzY0NTEgVGhpcyB3b3Jk aW5nIHNlZW1zIHRvIGJlIA1hZGRyZXNzaW5nIGFuIGltcG9ydGFudCBpc3N1ZSBpbiBh IHZlcnkgaW5kaXJlY3Qgd2F5LiBUd28gcGVlcnMgd2hvIGltcGxlbWVudCBhIEJHUCBz ZWN1cml0eSBtZWNoYW5pc20gc2hvdWxkIGJlIGFibGUgdG8gdXNlIGEgDVxwYXIgbmV3 IGZvcm1hdCwgaWYgbmVlZGVkLiBob3dldmVyLCB0aGlzIHNlZW1zIHRvIGJlIGVzdGFi bGlzaGluZyBhIHJlcXVpcmVtZW50IGZvciB0cmFuc2l0aXZpdHkgb2Ygc2VjdXJlZCBV UERBVEVzIHRocm91Z2ggbm9uLXNlY3VyZSBzeXN0ZW1zLiBJIHRoaW5rIHRoaXMgaXMg cXVlc3Rpb25hYmxlLn19fXtcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lk NjAzMzc0MyANXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgbyAgSW4g YW4gZW52aXJvbm1lbnQgd2hlcmUgYm90aCBzZWN1cmVkIGFuZCBub24tc2VjdXJlZCBz eXN0ZW1zIGFyZQ1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICAgICBp bnRlcm9wZXJhdGluZyBhIG1lY2hhbmlzbSBNVVNUIGV4aXN0IGZvciBzZWN1cmVkIHN5 c3RlbXMgdG8NXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgICAgaWRl blxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiB0aWZ5IHdoZXRoZXIgYW4gb3JpZ2lu YXRvciBpbnRlbmRlZCB0aGUgaW5mb3JtYXRpb24gdG8gYmUNXHBhciBcaGljaFxhZjZc ZGJjaFxhZjE1XGxvY2hcZjYgICAgICAgc2VjdXJlZC59e1xjczE2XHZcZjBcZnMxOFxp bnNyc2lkMTM5NzY0NTEge1wqXGF0bmlkIFNLfXtcKlxhdG5hdXRob3IgU3RlcGhlbiBL ZW50fVxjaGF0biB7XCpcYW5ub3RhdGlvbntcKlxhdG5kYXRlIDExODQwNTU5NTh9XHBh cmRccGxhaW4gXHMxN1xxbCBcbGkwXHJpMFx3aWRjdGxwYXJcYXNwYWxwaGFcYXNwbnVt XGZhYXV0b1xhZGp1c3RyaWdodFxyaW4wXGxpbjBcaXRhcDAgDVxsYW5nMTAzM1xsYW5n ZmUxMDMzXGNncmlkXGxhbmducDEwMzNcbGFuZ2ZlbnAxMDMzIHtcY3MxNlxmczE4XGlu c3JzaWQxMzk3NjQ1MSBcY2hhdG4gfXtcaW5zcnNpZDEzOTc2NDUxIFRoZSBvcmlnaW5h dG9yPyBIb3cgYWJvdXQganVzdCB0aGUgcGVlcj99fX17XGRiY2hcZjE1XGluc3JzaWQx Mzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMgDVxwYXIgDVxwYXIgXGhpY2hcYWY2XGRiY2hc YWYxNVxsb2NoXGY2IDMuMyAgQ29uZGl0aW9ucyBmb3IgaW5pdGlhbGl6YXRpb24NXHBh ciANXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgQSBrZXkgZmFjdG9y IGluIHRoZSByb2J1c3QgbmF0dXJlIG9mIHRoZSBleGlzdGluZyBpbnRlcm5hbCBhbmQN XHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgZXh0ZXJuYWwgcmVsYXRp b25zaGlwcyBtYWludGFpbmVkIGluIHRvZGF5fXtcY2YwXHJldmlzZWRccmV2YXV0aDFc cmV2ZHR0bTExODQwNTU5NjVcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lk NjAzMzc0MyBccnF1b3RlIH17XGRiY2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxjaGFycnNp ZDYwMzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IA1zIEludGVybmV0IHBy b3ZpZGVyIHNwYWNlDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIGlz IHRcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgaGUgYWJpbGl0eSB0byBtYWludGFp biBhbmQgcmV0dXJuIHRvIGEgc2lnbmlmaWNhbnRseSBjb252ZXJnZWQNXHBhciBcaGlj aFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgc3RhdGUgd2l0aG91dCB0aGUgbmVlZCB0 byByZWx5IG9uIHN5c3RlbXMgZXh0ZXJuYWwgdG8gdGhlIHJvdXRpbmcNXHBhciBcaGlj aFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgc3lzdGVtICh0aGUgcGh5c2ljYWwgZXF1 aXBtZW50IHRoYXQgaXMgcGVyZm9ybWluZyB0aGUgZm9yd2FyZGluZykuDVxwYXIgXGhp Y2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIEluIG9yZGVyIHRvIGVuc3VyZSB0aGUg cmFwaWQgaW5pdGlhbGl6YXRpb24gYW5kL29yIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9j aFxmNiByZXR1cm4gdG8gc2VydmljZQ1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9j aFxmNiAgICBvZiBmYWlsZWQgbm9kZXMgaXQgaXMgaW1wb3J0YW50IHRvIHJlZHVjZSBy ZWxpYW5jZSBvbiBleHRlcm5hbA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxm NiAgICBzeXN0ZW1zIHRvIHRoZSBncmVhdGVzdCBleHRlbnQgcG9zc2libGUuICBUaGVy ZWZvcmUsIHByb3Bvc2VkIHN5c3RlbXMNXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxv Y2hcZjYgICAgU0hPVUxEIE5PVCByZXF1aXJlIGNvbm5lY3Rpb25zIHRvIGV4dGVybmFs IHN5c3RlbXMsIGJleW9uZCB0aG9zZQ1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9j aFxmNiAgICBkaXJlY3RseSBpbnZvbHZlZCBpbiBwZWVyaW5nXGhpY2hcYWY2XGRiY2hc YWYxNVxsb2NoXGY2ICByZWxhdGlvbnNoaXBzLCBpbiBvcmRlciB0byByZXR1cm4gdG8N XHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgZnVsbCBzZXJ2aWNlLiAg UHJvcG9zZWQgc3lzdGVtcyBNQVkgcmVxdWlyZSBwb3N0IGluaXRpYWxpemF0aW9uDVxw YXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIHN5bmNocm9uaXphdGlvbiB3 aXRoIGV4dGVybmFsIHN5c3RlbXMgaW4gb3JkZXIgdG8gc3luY2hyb25pemUNXHBhciBc aGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgc2VjdXJpdHkgaW5mb3JtYXRpb24u fXtcY3MxNlx2XGYwXGZzMThcaW5zcnNpZDEzOTc2NDUxIHtcKlxhdG5pZCBTS317XCpc YXRuYXV0aG9yIFN0ZXBoZW4gS2VudH1cY2hhdG4ge1wqXGFubm90YXRpb257XCpcYXRu ZGF0ZSAxMTg0MDU2MDIxfVxwYXJkXHBsYWluIA1cczE3XHFsIFxsaTBccmkwXHdpZGN0 bHBhclxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJpbjBcbGluMFxp dGFwMCBcbGFuZzEwMzNcbGFuZ2ZlMTAzM1xjZ3JpZFxsYW5nbnAxMDMzXGxhbmdmZW5w MTAzMyB7XGNzMTZcZnMxOFxpbnNyc2lkMTM5NzY0NTEgXGNoYXRuIH17XGluc3JzaWQx Mzk3NjQ1MSANQWdhaW4sIHRoZSB3b3JkaW5nIHNlZW1zIGF3ZnVsbHkgY29tcGxleC4g SXMgdGhlIGludGVudCB0byBzYXkgdGhhdCBpbnNlY3VyZSBvcGVyYXRpb24gbXVzdCBi ZSBhYmxlIHRvIGJlIHJlc3RvcmVkIGFzIHF1aWNrbHkgYXMgdy9vIEJHUCBzZWN1cml0 eSwgYnV0IHNlY3VyZSBvcGVyYXRpb24gbWF5IHRha2UgbG9uZ2VyIGJlY2F1c2Ugb2Yg dGhlIG5lZWQgdG8gYWNxdWlyZSBzZWN1cml0eSBkYXRhIGZyb20gb3RoZXIgc291cmNl cz99fX17DVxkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIA1c cGFyIA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAzLjQgIH17XGNmMFxy ZXZpc2VkXHJldmF1dGgxXHJldmR0dG0xMTg0MDU1OTcwXGRiY2hcZjE1XGluc3JzaWQx Mzk3NjQ1MVxkZWxyc2lkNjAzMzc0M1xjaGFycnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRi Y2hcYWYxNVxsb2NoXGY2IExvY2FsIENvbnRyb2x9ew1cY2YwXHJldmlzZWRccmV2YXV0 aDFccmV2ZHR0bTExODQwNTU5NzFcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGRlbHJz aWQ2MDMzNzQzXGNoYXJyc2lkNjAzMzc0MyBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hc ZjYgcyBmb3J9e1xjZjBccmV2aXNlZFxyZXZhdXRoMVxyZXZkdHRtMTE4NDA1NTk3MFxk YmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcZGVscnNpZDYwMzM3NDNcY2hhcnJzaWQ2MDMz NzQzIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiANIH17XGNmMFxyZXZpc2VkXHJl dmF1dGgxXHJldmR0dG0xMTg0MDU1OTcxXGRiY2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxk ZWxyc2lkNjAzMzc0M1xjaGFycnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYxNVxs b2NoXGY2IFNlY3VyZSBVUERBVEUgQWNjZXB0YW5jZX17XGRiY2hcZjE1XGluc3JzaWQx Mzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMgDVxwYXIgDVxwYXIgXGhpY2hcYWY2XGRiY2hc YWYxNVxsb2NoXGY2ICAgIEVhY2ggc1xoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiBl Y3VyZWQgZW52aXJvbm1lbnQgbWF5IGhhdmUgZGlmZmVyZW50IGxldmVscyBvZiByZXF1 aXJlbWVudHMgaW4NXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgdGVy bXMgb2Ygd2hhdCBpcyBhY2NlcHRhYmxlIG9yIHVuYWNjZXB0YWJsZS4gIEluIGVudmly b25tZW50cyB0aGF0DVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIHJl cXVpcmUgc3RyaWN0IHNlY3VyaXR5IGl0IG1heSBub3QgYmUgYWNjZXB0YWJsZSB0byB0 ZW1wb3JhcmlseSByb3V0ZQ1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAg ICB0byBhIGRlc3RpbmF0aW9uIHdoaWxlIHdhaXRpbmcgZm9yIHNlY3VyaXR5IHZlXGhp Y2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IHJpZmljYXRpb24gdG8gYmUNXHBhciBcaGlj aFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgcGVyZm9ybWVkLiAgSG93ZXZlciwgaW4g bWFueSBjb21tZXJjaWFsIGVudmlyb25tZW50cyB0aGUgcmFwaWRpdHkgb2YNXHBhciBc aGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgcm91dGUgaW5zdGFsbGF0aW9uIG1h eSBiZSBvZiBwYXJhbW91bnQgaW1wb3J0YW5jZTsgaW4gb3JkZXIgdG8NXHBhciBcaGlj aFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgZmFjaWxpdGF0ZSB0aGUgbW9yZSBjb21t b24gfXtcY2YwXHJldmlzZWRccmV2YXV0aDFccmV2ZHR0bTExODQwNTU5NjZcZGJjaFxm MTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyBcaGljaFxhZjZcZGJjaFxh ZjE1XGxvY2hcZjYgb2NjdXJyZW5jZX17XGRiY2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxj aGFycnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IA0gb2Ygcm91 dGUgfXtcY2YwXHJldmlzZWRccmV2YXV0aDFccmV2ZHR0bTExODQwNTU5NjZcZGJjaFxm MTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyBcaGljaFxhZjZcZGJjaFxh ZjE1XGxvY2hcZjYgd2l0aGRyYXdhbH17XGRiY2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxj aGFycnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICBkdWUgdG8N XHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgbmV0d29yayBmYWlsdXJl LiAgQmFzZWQgb24gdGhlXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICB0d28gZGl2 ZXJnZW50IHJlcXVpcmVtZW50cywgdGhlDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxs b2NoXGY2ICAgIGZvbGxvd2luZyBjcml0ZXJpYSBhcHBseS4NXHBhciBcaGljaFxhZjZc ZGJjaFxhZjE1XGxvY2hcZjYgICAgbyAgVGhlIHNlY3VyaXR5IHN5c3RlbSBNVVNUIHN1 cHBvcnQgYSByYW5nZSBvZiBwb3NzaWJsZSBvdXRwdXRzIGZvcg1ccGFyIFxoaWNoXGFm NlxkYmNoXGFmMTVcbG9jaFxmNiAgICAgICBsb2NhbCBkZXRlcm1pbmF0aW9uIG9mIHRo ZSB0cnVzdCBsZXZlbH17XGNzMTZcdlxmMFxmczE4XGluc3JzaWQxMzk3NjQ1MSB7XCpc YXRuaWQgU0t9e1wqXGF0bmF1dGhvciBTdGVwaGVuIEtlbnR9XGNoYXRuIHtcKlxhbm5v dGF0aW9ue1wqXGF0bmRhdGUgMTE4NDA1NTk2OX1ccGFyZFxwbGFpbiANXHMxN1xxbCBc bGkwXHJpMFx3aWRjdGxwYXJcYXNwYWxwaGFcYXNwbnVtXGZhYXV0b1xhZGp1c3RyaWdo dFxyaW4wXGxpbjBcaXRhcDAgXGxhbmcxMDMzXGxhbmdmZTEwMzNcY2dyaWRcbGFuZ25w MTAzM1xsYW5nZmVucDEwMzMge1xjczE2XGZzMThcaW5zcnNpZDEzOTc2NDUxIFxjaGF0 biB9e1xpbnNyc2lkMTM5NzY0NTEgDVRoaXMgaXMgYSB2ZXJ5IHF1ZXN0aW9uYWJsZSBy ZXF1aXJlbWVudC4gQXMgc3RhdGVkLiBUcnVzdCBpcyBub3QgdHJhbnNpdGl2ZSwgeWV0 IHJvdXRlIHByb3BhZ2F0aW9uIElTIHRyYW5zaXRpdmUuIEkgYXBwcmVjaWF0ZSB0aGUg bm90aW9uIHRoYXQgYW4gQVMgb3BlcmF0b3IgbmVlZHMgdG8gYmUgYWJsZSB0bw0gaGF2 ZSBzb21lIGNvbnRyb2xzIG9uIHdoZXRoZXIgdG8gYWNjZXB0IG9mIHJlamVjdCBhbiBV UERBVEUgd2hlbiB0aGUgVVBEQVRFIGNhbm5vdCBiZSB2ZXJpZmllZC4gQnV0IHRoYXRc cnF1b3RlIA1zIGFsbCBJIHdvdWxkIHNheSBhYm91dCB0aGlzLiAgVGFsa2luZyBhYm91 dCB0cnVzdCBsZXZlbHMgbWF5IGxlYWQgdXMgZG93biBhIHBhdGggb2Ygc2VyaW91cyBj b25maWd1cmF0aW9uIGNvbXBsZXhpdHksIHdoaWNoIHVzdWFsbHkgcmVzdWx0cyBpbiBt YW5hZ2VtZW50LWluZHVjZWQgdnVsbmVyYWJpbGl0aWVzIX19fXtcZGJjaFxmMTVcaW5z cnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyBcaGljaFxhZjZcZGJjaFxhZjE1XGxv Y2hcZjYgDSBmb3IgYSBzcGVjaWZpYyByb3V0ZS4gIEFueQ1ccGFyIFxoaWNoXGFmNlxk YmNoXGFmMTVcbG9jaFxmNiAgICAgICBnaXZlbiByb3V0ZSBzaG91bGQgYmUgdHJ1c3Rh YmxlIHRvIGEgbG9jYWxseVxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgY29uZmln dXJlZCBkZWdyZWUsDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgICAg IGJhc2VkIG9uIHRoZSBjb21wbGV0ZW5lc3Mgb2Ygc2VjdXJpdHkgaW5mb3JtYXRpb24g Zm9yIHRoZSB1cGRhdGUNXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAg ICAgYW5kIG90aGVyIGZhY3RvcnMuDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2No XGY2ICAgIG8gIFRoZSBzZWN1cml0eSBzeXN0ZW0gU0hPVUxEIGFsbG93IHRoZSBvcGVy YXRvciB0byBkZXRlcm1pbmUgd2hldGhlcg1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVc bG9jaFxmNiAgICAgICB0aGUgc3BlZWQgb2YgY29udmVyZ2VuY2UgaXMgbW9yZSBpbXBv cnRhbnQgdGhhbiBzZWN1cml0eQ1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxm NiAgICAgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgb3BlcmF0aW9ucywgb3Ig c2VjdXJpdHkgb3BlcmF0aW9ucyBhcmUgbW9yZSBpbXBvcnRhbnQgdGhhbiB0aGUNXHBh ciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgICAgc3BlZWQgb2YgY29udmVy Z2VuY2UuICBUaGlzIGZhY2lsaXRhdGVzIHRoZSBpbmNyZW1lbnRhbCBkZXBsb3ltZW50 DVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgICAgIG9mIHNlY3VyaXR5 IG9uIHN5c3RlbXMgbm90IGRlc2lnbmVkIHRvIHN1cHBvcnQgaW5jcmVhc2VkDVxwYXIg XGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgICAgIHByb2Nlc3NpbmcgcmVxdWly ZW1lbnRzIGltcG9zZWQgYnkgdGhlIHNlY3VyaXR5IHNcaGljaFxhZjZcZGJjaFxhZjE1 XGxvY2hcZjYgeXN0ZW0ufXtcY3MxNlx2XGYwXGZzMThcaW5zcnNpZDEzOTc2NDUxIHtc KlxhdG5pZCBTS317XCpcYXRuYXV0aG9yIFN0ZXBoZW4gS2VudH1cY2hhdG4ge1wqXGFu bm90YXRpb257XCpcYXRuZGF0ZSAxMTg0MDU1OTczfVxwYXJkXHBsYWluIA1cczE3XHFs IFxsaTBccmkwXHdpZGN0bHBhclxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGFkanVzdHJp Z2h0XHJpbjBcbGluMFxpdGFwMCBcbGFuZzEwMzNcbGFuZ2ZlMTAzM1xjZ3JpZFxsYW5n bnAxMDMzXGxhbmdmZW5wMTAzMyB7XGNzMTZcZnMxOFxpbnNyc2lkMTM5NzY0NTEgXGNo YXRuIH17XGluc3JzaWQxMzk3NjQ1MSANSSB1bmRlcnN0YW5kIHRoZSBpbnRlbnQgaGVy ZSwgYnV0IHdvcnJ5IGFib3V0IHRoZSBpbXBsaWNhdGlvbnMsIGkuZS4sIGEgcG9vcmx5 IGNob3NlbiBzZXR0aW5nIGNvdWxkIGFsbG93IGF0dGFja2VycyB0byBkcml2ZSB0aGUg c3lzdGVtIGludG8gYSBzdGF0ZSB3aGVyZSBpbnZhbGlkIFVQREFURXMgYXJlIGFjY2Vw dGVkLCByZWd1bGFybHkufX19e1xkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hhcnJz aWQ2MDMzNzQzIA1ccGFyIA1ccGFyIA1ccGFyIA1ccGFyIA1ccGFyIA1ccGFyIFxoaWNo XGFmNlxkYmNoXGFmMTVcbG9jaFxmNiBDaHJpc3RpYW4gICAgICAgICAgICAgICAgRXhw aXJlcyBBdWd1c3QgMSwgMjAwNCAgICAgICAgICAgICAgICAgW1BhZ2UgN10NXHBhciBc cGFnZSANXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgSW50ZXJuZXQtRHJh ZnQgICAgICAgICBCR1AgU2VjdXJpdHkgUmVxdWlyZW1lbnRzICAgICAgICAgICAgICAg IEZlYiAyMDA0DVxwYXIgDVxwYXIgDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2No XGY2IDQuICBUaGUgVHJ1c3QgTW9kZWwNXHBhciANXHBhciBcaGljaFxhZjZcZGJjaFxh ZjE1XGxvY2hcZjYgICAgSW4gZXhhbWluaW5nIHRoZSB2YXJpb3VzIGVudmlyb25tZW50 cyBpbiB3aGljaCBCR1AgaXMgZGVwbG95ZWQsIGFuZA1ccGFyIFxoaWNoXGFmNlxkYmNo XGFmMTVcbG9jaFxmNiAgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgdGhyb3Vn aCBkaXNjdXNzaW9ucyB3aXRoIHZhcmlvdXMgb3BlcmF0b3JzfXtcY3MxNlx2XGYwXGZz MThcaW5zcnNpZDEzOTc2NDUxIHtcKlxhdG5pZCBTS317XCpcYXRuYXV0aG9yIFN0ZXBo ZW4gS2VudH1cY2hhdG4ge1wqXGFubm90YXRpb257XCpcYXRuZGF0ZSAxMTg0MDU1OTc2 fVxwYXJkXHBsYWluIA1cczE3XHFsIFxsaTBccmkwXHdpZGN0bHBhclxhc3BhbHBoYVxh c3BudW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJpbjBcbGluMFxpdGFwMCBcbGFuZzEwMzNc bGFuZ2ZlMTAzM1xjZ3JpZFxsYW5nbnAxMDMzXGxhbmdmZW5wMTAzMyB7XGNzMTZcZnMx OFxpbnNyc2lkMTM5NzY0NTEgXGNoYXRuIH17XGluc3JzaWQxMzk3NjQ1MSAuIHRoZSB1 bmRlcmx5aW5nIGJhc2lzIGZvciB0DWhlIG9wZXJhdG9yIGNvbmNlcm5zIG5lZWRzIHRv IGJlIGJldHRlciBleHBsYWluZWQgaGVyZSwgdG8gd2FycmFudCB1c2luZyB0aGlzIGFz IGEgYmFzaXMgZm9yIGFuIElFVEYgc3RhbmRhcmQufX19e1xkYmNoXGYxNVxpbnNyc2lk MTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxm NiAgd29ya2luZyB3aXRoIHRoZSBjb250ZXh0DVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYx NVxsb2NoXGY2ICAgIG9mIHRoZSBwdWJsaWMgSW50ZXJuZXQsIGFuZCBvdGhlciBpbnRl cm5ldHdvcmtzLCBpdCBpcyBhcHBhcmVudCB0aGF0DVxwYXIgXGhpY2hcYWY2XGRiY2hc YWYxNVxsb2NoXGY2ICAgIHRydXN0IG1vZGVscyBhcmUgbGFyZ2VseSBlbnZpcm9ubWVu dCBzcGVjaWZpYy4gIEZvciBpbnN0YW5jZSwgaW4gdGhlDVxwYXIgXGhpY2hcYWY2XGRi Y2hcYWYxNVxsb2NoXGY2ICAgIHB1YmxpYyBJbnRlcm5ldCwgYSBkaXN0cmlidXRlZCB0 cnVzdCBtXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IG9kZWwsIGZvbGxvd2luZyB0 aGUgY3VycmVudA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICB0cmFu c2l0aXZlIHRydXN0IHBhdHRlcm4gb2YgY29udHJhY3R1YWwgYW5kIHBlZXJpbmcgYXJy YW5nZW1lbnRzLA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICB3b3Vs ZCBmaXQgdGhlIGJ1c2luZXNzIG1vZGVscyBvZiB0aGUgcGFydGljaXBhbnRzLn17XGNz MTZcdlxmMFxmczE4XGluc3JzaWQxMzk3NjQ1MSB7XCpcYXRuaWQgU0t9e1wqXGF0bmF1 dGhvciBTdGVwaGVuIEtlbnR9XGNoYXRuIHtcKlxhbm5vdGF0aW9ue1wqXGF0bmRhdGUg MTE4NDA1NTk3OX1ccGFyZFxwbGFpbiANXHMxN1xxbCBcbGkwXHJpMFx3aWRjdGxwYXJc YXNwYWxwaGFcYXNwbnVtXGZhYXV0b1xhZGp1c3RyaWdodFxyaW4wXGxpbjBcaXRhcDAg XGxhbmcxMDMzXGxhbmdmZTEwMzNcY2dyaWRcbGFuZ25wMTAzM1xsYW5nZmVucDEwMzMg e1xjczE2XGZzMThcaW5zcnNpZDEzOTc2NDUxIFxjaGF0biB9e1xpbnNyc2lkMTM5NzY0 NTEgDVRoZXJlIGlzIG5vIGNvbnRleHQgdG8gZXhwbGFpbiBob3cgdHJ1c3QsIGFzIGRl c2NyaWJlZCBoZXJlLCBpcyBzdXBwb3NlZCB0byBiZSByZWZsZWN0ZWQgaW4gYSBCR1Ag c2VjdXJpdHkgbWVjaGFuaXNtLiBCR1Agc2VjdXJpdHkgIG1lY2hhbmlzbXMgcg1lcXVp cmUgc2V2ZXJhbCBmb3JtcyBvZiBpbnB1dHMsIGluY2x1ZGluZyBkYXRhIG9uIHdobyBp cyB0aGUgaG9sZGVyIG9mIHdoaWNoIHByZWZpeCwgd2hvIGlzIGFzc2lnbmVkIHdoaWNo IEFTICMsIHdobyBoYXMgYmVlbiBhdXRob3JpemVkIHRvIG9yaWdpbmF0ZSB3aGljaCA7 cHJlZml4LCBldGMuIHRoaXMgZGlzY3Vzc2lvbiBuZWVkcyB0byBzYXkgd2hpY2ggb2Yg dGhlc2Ugc29ydHMgb2YgZGF0YSBvcGVyYXRvcnMgZmVlbCBuZWVkcyB0byBiZSANdmVy aWZpZWQgYmFzZWQgb24gYSB0cmFuc2l0aXZlIHRydXN0IG1vZGVsIHZzLiBhIGhpZXJh cmNoaWMgdHJ1c3QgbW9kZWx9fX17XGRiY2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxjaGFy cnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgSW4gb3RoZXIN XHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgZW52aXJvbm1lbnRzIGEg aGllcmFyY2hpY2FsIHRydXN0IG1vZGVsIHdvdWxkIHdvcmsgYmV0dGVyLiAgVGh1cywg YW55DVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIHRydXN0IHN5c3Rl bSBzcGVjaVxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiBmaWVkIGluIGEgc2VjdXJp dHkgbWVjaGFuaXNtIGRlc2lnbmVkIGZvciBCR1AgbXVzdA1ccGFyIFxoaWNoXGFmNlxk YmNoXGFmMTVcbG9jaFxmNiAgICBiZSBmbGV4aWJsZSwgYW5kIHN1cHBvcnQgYm90aCBh IHRydWUgZGlzdHJpYnV0ZWQgdHJ1c3QgbW9kZWwgYW5kIGENXHBhciBcaGljaFxhZjZc ZGJjaFxhZjE1XGxvY2hcZjYgICAgZnVsbHkgaGllcmFyY2hpY2FsIHRydXN0IG1vZGVs Ln17XGNzMTZcdlxmMFxmczE4XGluc3JzaWQxMzk3NjQ1MSB7XCpcYXRuaWQgU0t9e1wq XGF0bmF1dGhvciBTdGVwaGVuIEtlbnR9XGNoYXRuIHtcKlxhbm5vdGF0aW9ue1wqXGF0 bmRhdGUgMTE4NDA1NTk3Nn1ccGFyZFxwbGFpbiANXHMxN1xxbCBcbGkwXHJpMFx3aWRj dGxwYXJcYXNwYWxwaGFcYXNwbnVtXGZhYXV0b1xhZGp1c3RyaWdodFxyaW4wXGxpbjBc aXRhcDAgXGxhbmcxMDMzXGxhbmdmZTEwMzNcY2dyaWRcbGFuZ25wMTAzM1xsYW5nZmVu cDEwMzMge1xjczE2XGZzMThcaW5zcnNpZDEzOTc2NDUxIFxjaGF0biB9e1xpbnNyc2lk MTM5NzY0NTEgDSBUcmFuc2l0aXZlIHRydXN0IGNyZWF0ZXMgY2FzY2FkZSBmYWlsdXJl IG9wcG9ydHVuaXRpZXMgYW5kIHRoYXQgaXMgdGhlIGJhc2lzIGZvciBtYW55IEJHUCB2 dWxuZXJhYmlsaXRpZXMgdG9kYXkhfX19e1xkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFc Y2hhcnJzaWQ2MDMzNzQzIA1ccGFyIA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9j aFxmNiAgICBTaW5jZSBoaWVyYXJjaGljYWwgdHJ1c3QgbW9kZWxzIGFyZSBhIHN1YnNl dCAob3IgYSBzcGVjaWFsIGNhc2Ugb2YpIGENXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1 XGxvY2hcZjYgICAgZGlzdHJpYnV0ZWQgdHJ1c3QgbW9kZVxoaWNoXGFmNlxkYmNoXGFm MTVcbG9jaFxmNiBsLCBhbnkgc2VjdXJpdHkgc3lzdGVtIGRlc2lnbmVkIGZvciBCR1Ag TVVTVA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBzdXBwb3J0IGEg ZGlzdHJpYnV0ZWQgdHJ1c3QgbW9kZWwsIGFuZCBNVVNUIGFsc28gc3VwcG9ydCBhDVxw YXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIGhpZXJhcmNoaWNhbCB0cnVz dCBtb2RlbCwgaWYgZGVzaXJlZC4NXHBhciANXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1 XGxvY2hcZjYgICAgSWYgdHdvIGludGVybmV0d29ya3MgdXNpbmcgZGlmZmVyaW5nIHRy dXN0IG1vZGVscyBhcmUgaW50ZXJjb25uZWN0ZWQNXHBhciBcaGljaFxhZjZcZGJjaFxh ZjE1XGxvY2hcZjYgICAgdGhleSBNVVNUIGJlIGFibGUgdG8gaW50ZXJvcGVyYXRcaGlj aFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgZSB1c2luZyBsb2NhbGx5IGRldGVybWluZWQg bGV2ZWxzIG9mDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIHRydXN0 IHRvIGNvbXBlbnNhdGUgZm9yIGRpZmZlcmVuY2VzIGluIHRoZWlyIHRydXN0IG1vZGVs cy59e1xjczE2XHZcZjBcZnMxOFxpbnNyc2lkMTM5NzY0NTEge1wqXGF0bmlkIFNLfXtc KlxhdG5hdXRob3IgU3RlcGhlbiBLZW50fVxjaGF0biB7XCpcYW5ub3RhdGlvbntcKlxh dG5kYXRlIDExODQwNTU5ODF9XHBhcmRccGxhaW4gDVxzMTdccWwgXGxpMFxyaTBcd2lk Y3RscGFyXGFzcGFscGhhXGFzcG51bVxmYWF1dG9cYWRqdXN0cmlnaHRccmluMFxsaW4w XGl0YXAwIFxsYW5nMTAzM1xsYW5nZmUxMDMzXGNncmlkXGxhbmducDEwMzNcbGFuZ2Zl bnAxMDMzIHtcY3MxNlxmczE4XGluc3JzaWQxMzk3NjQ1MSBcY2hhdG4gfXtcaW5zcnNp ZDEzOTc2NDUxIFRoaXMgaXMganVzdCBhc2tpbmcgZm9yIHRyb3VibGUhIFRoZXJlIGFy ZSBubyBnZW5lcmljLCBtYWdpYyB3YXlzIHRvIA1tYWtlIHRoZSBpbnRlcmZhY2UgYmV0 d2VlbiB0d28gdHJ1ZXN0IG1vZGVscyB3b3JrLiBBbHNvLCB0aGlzIHNvdW5kcyBsaWtl IGl0IGlzIGFkZGluZyBhIGxvdCBvZiBsb2NhbGx5IG1hbmFnZWQgY29udHJvbHMgdGhh dCAgd2lsbCBiZSBoYXJkIHRvIG1haW50YWluLCBhbmQgdGh1cyB3aWxsIGNyZWF0ZSBz ZXJpb3VzIHZ1bG5lcmFiaWxpdHkgcHJvYmxlbXMufX19e1xkYmNoXGYxNVxpbnNyc2lk MTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIA0NXHBhciANXHBhciANXHBhciANXHBhciAN XHBhciANXHBhciANXHBhciANXHBhciANXHBhciANXHBhciANXHBhciANXHBhciANXHBh ciANXHBhciANXHBhciANXHBhciANXHBhciANXHBhciANXHBhciANXHBhciANXHBhciAN XHBhciANXHBhciANXHBhciANXHBhciANXHBhciANXHBhciANXHBhciANXHBhciANXHBh ciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgQ2hyaXN0aWFuICAgICAgICAgICAg ICAgIEV4cGlyZXMgQXVndXN0IDEsIDIwMDQgICAgICAgICAgICAgICAgIFtQYWdlIDhd DVxwYXIgXHBhZ2UgDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IEludGVy bmV0LURyYWZ0ICAgICAgICAgQkdQIFNlY3VyaXR5IFJlcXVpcmVtZW50cyAgICBcaGlj aFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgICAgICAgICAgRmViIDIwMDQNXHBhciAN XHBhciANXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgNS4gIFRoZSBBUy1Q YXRoIEF0dHJpYnV0ZSBhbmQgTkxSSSBBdXRoZW50aWNhdGlvbg1ccGFyIA1ccGFyIFxo aWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBCR1AgZGlzdHJpYnV0ZXMgcm91dGlu ZyBpbmZvcm1hdGlvbiBhY3Jvc3MgdGhlIEludGVybmV0IChiZXR3ZWVuIEJHUA1ccGFy IFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBzcGVha2VycykgdXNpbmcgQkdQ IFVQREFURSBtZXNzYWdlcy4gIFRoZSBVUERBVEUgbWVzc2FnZSBjb250YWlucw1ccGFy IFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICB3aXRoZHJhd24gcm91dGVzLCBw YXRoIGF0dHJpYnV0ZXMgYW5kIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiBvbmUg b3IgbW9yZSBOTFJJcyAoTmV0d29yaw1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9j aFxmNiAgICBMYXllciBSZWFjaGFiaWxpdHkgSW5mb3JtYXRpb24gaXMgc3lub255bW91 cyB3aXRoIGFkdmVydGlzZWQgcHJlZml4KS4NXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1 XGxvY2hcZjYgICAgRm9yIHRoZSByZW1haW5kZXIgb2YgdGhpcyBzZWN0aW9uLCB3ZSB3 aWxsIGZvY3VzIG9uIHRoZSBBUy1QYXRoDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxs b2NoXGY2ICAgIEF0dHJpYnV0ZSBhbmQgdGhlIE5MUkkuICBBdHRyaWJ1dGVzIHN1Y2gg YXMgbG9jYWwgcHJlZiBhcmUgbG9jYWxseQ1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVc bG9jaFxmNiAgICBzcGVjaWZpYyBhbmQsIGFzXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2No XGY2ICBzdWNoLCBhcmUgcHJvdGVjdGVkIGJ5IEJHUCBzZXNzaW9uIHNlY3VyaXR5Lg1c cGFyIA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBUaGUgQVNfUEFU SCBmb3Igc3BlY2lmaWMgcHJlZml4ZXMgbXVzdCBiZSBwcm90ZWN0ZWQgaW4gYW55IHBy b3Bvc2VkDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIHNlY3VyaXR5 IHN5c3RlbSBpbiB0aHJlZSB3YXlzOg1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9j aFxmNiAgICBvICBBdXRob3JpemF0aW9uIG9mIE9yaWdpbmF0aW5nIEFTOiBGb3IgYWxs IHByZWZpeGVzIGFubm91bmNlZCBpbg1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9j aFxmNiAgICAgICBCR1AsIHRoZSBvcmlnaW5hdGluZyBBUyBNVVNUIFxoaWNoXGFmNlxk YmNoXGFmMTVcbG9jaFxmNiBiZSB2ZXJpZmlhYmxlIA1ccGFyIFxoaWNoXGFmNlxkYmNo XGFmMTVcbG9jaFxmNiAgICAgICBhcyB0aGUgYXV0aG9yaXplZCBhbm5vdW5jZXIgb2Yg dGhlIHByZWZpeC4gIFRoZSB2ZXJpZmljYXRpb24NXHBhciBcaGljaFxhZjZcZGJjaFxh ZjE1XGxvY2hcZjYgICAgICAgbWVjaGFuaXNtIG11c3QgYWNjb3VudCBmb3IgZXhpc3Rp bmcgQkdQIG1lY2hhbmlzbXMgc3VjaCBhcw1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVc bG9jaFxmNiAgICAgICBzdW1tYXJpemF0aW9ufXtcY3MxNlx2XGYwXGZzMThcaW5zcnNp ZDEzOTc2NDUxIHtcKlxhdG5pZCBTS317XCpcYXRuYXV0aG9yIFN0ZXBoZW4gS2VudH1c Y2hhdG4ge1wqXGFubm90YXRpb257XCpcYXRuZGF0ZSAxMTg0MDU2MDIzfVxwYXJkXHBs YWluIFxzMTdccWwgXGxpMFxyaTBcd2lkY3RscGFyXGFzcGFscGhhXGFzcG51bVxmYWF1 dG9cYWRqdXN0cmlnaHRccmluMFxsaW4wXGl0YXAwIA1cbGFuZzEwMzNcbGFuZ2ZlMTAz M1xjZ3JpZFxsYW5nbnAxMDMzXGxhbmdmZW5wMTAzMyB7XGNzMTZcZnMxOFxpbnNyc2lk MTM5NzY0NTEgXGNoYXRuIH17XGluc3JzaWQxMzk3NjQ1MSBOb3QgZGVmaW5lZCBpbiB0 aGUgQkdQIGFzc3VtcHRpb25zIHNlY3Rpb24uIEFkZCBpdCB0aGVyZSBhbmQgZXhwbGFp biBpdC59fX17XGRiY2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMg XGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IA0uICBGb3IgdGhlIHB1cnBvc2Ugb2Yg dGhpcyBkb2N1bWVudCB0aGUgdGVybQ1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9j aFxmNiAgICAgICB2ZXJpZmlhYmxlIGlzIGRlZmluZWQgYXMgdGhlIHJlc3VsdGFudFxo aWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgb2YgYSBzZWN1cmVkIHJvdXRpbmcNXHBh ciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgICAgc3lzdGVtcyBhcyBkZXNj cmliZWQgaW4gdGhpcyBkb2N1bWVudC4gIFRoZSB0ZXJtIHNwZWNpZmljYWxseQ1ccGFy IFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICAgICBpbmRpY2F0ZXMgdGhlIGFi aWxpdHkgdG8gdmFsaWRhdGUgdGhlIG9yaWdpbmF0b3Igb2YgYSBzcGVjaWZpYw1ccGFy IFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICAgICBwcmVmaXggKG9yIGJsb2Nr IG9mIElQIGFkZHJlc3NlcykgYW5kIHRoZSBhYmlsaXR5IHRvIHZhbGlkYXRlIHRoZQ1c cGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICAgICBzZXNzaW9uIHRocm91 Z2ggd2hpXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IGNoIHRoZSBwcmVmaXggd2Fz IHJlY2VpdmVkfXtcY3MxNlx2XGYwXGZzMThcaW5zcnNpZDEzOTc2NDUxIHtcKlxhdG5p ZCBTS317XCpcYXRuYXV0aG9yIFN0ZXBoZW4gS2VudH1cY2hhdG4ge1wqXGFubm90YXRp b257XCpcYXRuZGF0ZSAxMTg0MDU2MDI3fVxwYXJkXHBsYWluIA1cczE3XHFsIFxsaTBc cmkwXHdpZGN0bHBhclxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJp bjBcbGluMFxpdGFwMCBcbGFuZzEwMzNcbGFuZ2ZlMTAzM1xjZ3JpZFxsYW5nbnAxMDMz XGxhbmdmZW5wMTAzMyB7XGNzMTZcZnMxOFxpbnNyc2lkMTM5NzY0NTEgXGNoYXRuIH17 XGluc3JzaWQxMzk3NjQ1MSANVGhpcyBsYXN0IHNlbnRlbmNlIHNlZW1zIHRvIG1peCB0 d28gZGlzdGluY3QgY29uY2VybnMuICBBIHNwZWFrZXIgd2FudHMgdG8ga25vdyBpZiB0 aGUgb3JpZ2luIEFTIGhhcyBiZWVuIGF1dGhvcml6ZWQgdG8gIG9yaWdpbmF0ZSB0aGUg TkxSSSBieSB0aGUgcHJlZml4IGhvbGRlcnMuICBCdXQsIHRoZSBzZWNvbmQgaXNzdWUg aXMgTk9UIGEgcHJlZml4IG9yaWdpbmF0aW9uIGNvbmNlcm4sIGJ1dCByYXRoDWVyIHRo ZSBnZW5lcmFsIGlzc3VlIG9mIGVuc3VyaW5nIHRoYXQgYW4gVUlQREFURSBpcyByZWNl aXZlZCB2aWEgYSBzZWN1cmUgc2Vzc2lvbiBmcm9tIHRoZSBpbmRpY2F0ZWQgcGVlciwg Y29uc2lzdGVudCB3aXRoIHRoZSBsYXRlc3QsIHByZXBlbmRlZCBBUyBudW1iZXIufX19 e1xkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIA1ccGFyIFxo aWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBvICBUaGUgQVNfUEFUSCBsaXN0IE1V U1QgY29ycmVzcG9uZCB0byBhIHZlcmlmaWFibGUgbGlzdCBvZg1ccGFyIFxoaWNoXGFm NlxkYmNoXGFmMTVcbG9jaFxmNiAgICAgICBhdXRvbm9tb3VzIHN5c3RlbXMgYmFzZWQg b24gdGhlIHBlZXJpbmcgdG9wb2xvZ3kgb2YgdGhlIG5ldHdvcmsufXtcY3MxNlx2XGYw XGZzMThcaW5zcnNpZDEzOTc2NDUxIHtcKlxhdG5pZCBTS317XCpcYXRuYXV0aG9yIFN0 ZXBoZW4gS2VudH1cY2hhdG4ge1wqXGFubm90YXRpb257XCpcYXRuZGF0ZSAxMTg0MDU2 MDI5fVxwYXJkXHBsYWluIA1cczE3XHFsIFxsaTBccmkwXHdpZGN0bHBhclxhc3BhbHBo YVxhc3BudW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJpbjBcbGluMFxpdGFwMCBcbGFuZzEw MzNcbGFuZ2ZlMTAzM1xjZ3JpZFxsYW5nbnAxMDMzXGxhbmdmZW5wMTAzMyB7XGNzMTZc ZnMxOFxpbnNyc2lkMTM5NzY0NTEgXGNoYXRuIH17XGluc3JzaWQxMzk3NjQ1MSANVGhp cyBpcyBub3QgdGhlIHNhbWUgYXMgdGhlIGFzc3VtcHRpb24gY2l0ZWQgYXQgdGhlIGJl Z2lubmluZyBvZiB0aGUgZG9jdW1lbnQsIHdoZXJlIHRoZSBwYXRoIGlzIGdlDW5lcmFs bHkgc3VwcG9zZWQgdG8gYmUgdGhlIG9uZSB0aGF0IHRoZSBhZHZlcnRpc2VtZW50IHRy YXZlcnNlZC4gVGhpcyBpcyBhIG11Y2ggd2Vha2VyIGFzc2VydGlvbi4gV2h5IGlzIHRo aXMgY2hlY2sgYmVpbmcgc3Vic3RpdHV0ZWQgZm9yIHRoZSBhc3N1bXB0aW9uIGNpdGVk IGVhcmxpZXI/fX19e1xkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMz NzQzIA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBvICBBbm5vdW5j aW5nIEFTIENoZWNrOiBGb3IgYWxsIEJHUCBwZWVycywgYSBCR1AgSW1wbGVtZW50YXRp b24gTVVTVA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICAgICBlbnN1 cmUgdGhhdCB0aGVcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgIGZpcnN0IGVsZW1l bnQgb2YgdGhlIEFTX1BBVEggbGlzdCBjb3JyZXNwb25kcyB0bw1ccGFyIFxoaWNoXGFm NlxkYmNoXGFmMTVcbG9jaFxmNiAgICAgICB0aGUgbG9jYWxseSBjb25maWd1cmVkIEFT IG9mIHRoYXQgcGVlci59e1xjczE2XHZcZjBcZnMxOFxpbnNyc2lkMTM5NzY0NTEge1wq XGF0bmlkIFNLfXtcKlxhdG5hdXRob3IgU3RlcGhlbiBLZW50fVxjaGF0biB7XCpcYW5u b3RhdGlvbntcKlxhdG5kYXRlIDExODQwNTYwMzB9XHBhcmRccGxhaW4gDVxzMTdccWwg XGxpMFxyaTBcd2lkY3RscGFyXGFzcGFscGhhXGFzcG51bVxmYWF1dG9cYWRqdXN0cmln aHRccmluMFxsaW4wXGl0YXAwIFxsYW5nMTAzM1xsYW5nZmUxMDMzXGNncmlkXGxhbmdu cDEwMzNcbGFuZ2ZlbnAxMDMzIHtcY3MxNlxmczE4XGluc3JzaWQxMzk3NjQ1MSBcY2hh dG4gfXtcaW5zcnNpZDEzOTc2NDUxIA1TZWUgY29tbWVudCBvbiBob3cgdGhlIGZpcnN0 IGJ1bGxldCBpbiB0aGlzIGxpc3Qgc2VlbXMgdG8gb3ZlcmxhcCB3aXRoIHRoaXMgaXNz dWUufX19e1xkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIA1c cGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBvICBSb3V0aW5nIGluZm9y bWF0aW9uIGNhcnJpZWQgdGhyb3VnaCBCR1AgU0hPVUxEIGluY2x1ZGUgaW5mb3JtYXRp b24NXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgICAgdGhhdCBjYW4g YmUgdXNlZCB0byB2ZXJpZnkgdGhlIHJlYWR2ZXJ0aXNlbWVudCBvciBtb2RpZmljYXRp b24gYnkNXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgICAgZWFjaCBh dXRcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgb25vbW91cyBzeXN0ZW0gdGhyb3Vn aCB3aGljaCB0aGUgVVBEQVRFIGhhcyBwYXNzZWQufXtcY3MxNlx2XGYwXGZzMThcaW5z cnNpZDEzOTc2NDUxIHtcKlxhdG5pZCBTS317XCpcYXRuYXV0aG9yIFN0ZXBoZW4gS2Vu dH1cY2hhdG4ge1wqXGFubm90YXRpb257XCpcYXRuZGF0ZSAxMTg0MDU2MDMxfVxwYXJk XHBsYWluIA1cczE3XHFsIFxsaTBccmkwXHdpZGN0bHBhclxhc3BhbHBoYVxhc3BudW1c ZmFhdXRvXGFkanVzdHJpZ2h0XHJpbjBcbGluMFxpdGFwMCBcbGFuZzEwMzNcbGFuZ2Zl MTAzM1xjZ3JpZFxsYW5nbnAxMDMzXGxhbmdmZW5wMTAzMyB7XGNzMTZcZnMxOFxpbnNy c2lkMTM5NzY0NTEgXGNoYXRuIH17XGluc3JzaWQxMzk3NjQ1MSBXaGF0IGV4YWN0bHkg ZG9lcyB0aGlzIG1lYW4/IEhvdyBkb2VzIGl0IHJlbGF0ZSB0byBidWxsZXQgIzI/fX19 ew1cZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyANXHBhciAN XHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgVGhlcmUgYXJlIG1hbnkg d2F5cyBpbiB3aGljaCBhIGRpZmZlcmVudGlhbCBiZXR3ZWVuIHRoZSBzcGVlZCBvZg1c cGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBwcmVmaXgvQVMgcGF0aCBh dHRyaWJ1dGUgcHJvcGFnYXRpb24gYW5kIHRoZSBpbmZvcm1hdGlvbiB2YWxpZGF0aW5n DVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIHRoZSBwcmVmaXgvQVMg cGF0aCBhdHRyaWJ1dGUgaW5mb3JtYXRpb24gY2FuIGJlIGV4cGxvaXRlZCB0bw1ccGFy IFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBhdHRhY2sgdGhlIHJvdXRpbmcg c3lzdGVtIG9uIGEgdGVtcG9yYXJ5IGJhc2lzLiAgVGhlc2UgdHlwZXMgb2YNXHBhciBc aGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgYXR0YWNrcyBhcmUgZG9taW5hbnRs eSBleHBsb2l0YXRpdmUgb2YgdGhlIG1vbWVudCBpbiB0aW1lIGl0IHRha2VzIHRvDVxw YXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIGZvbGxvdyB0aGUgd2l0aGRy YXd9e1xjZjBccmV2aXNlZFxyZXZhdXRoMVxyZXZkdHRtMTE4NDA1NjAzMVxkYmNoXGYx NVxpbnNyc2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIFxoaWNoXGFmNlxkYmNoXGFm MTVcbG9jaFxmNiBhbH17XGRiY2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxjaGFycnNpZDYw MzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICBvZiBhIH17DVxjZjBccmV2 aXNlZFxyZXZhdXRoMVxyZXZkdHRtMTE4NDA1NjAzMlxkYmNoXGYxNVxpbnNyc2lkMTM5 NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiBy b3V0ZSB2aWF9e1xkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQz IFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgYW4gdXBkYXRlLiAgQXMgYSByZXN1 bHQgb2YgdGhpcw1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBwb3Rl bnRpYWwgZm9yIHRlbXBvcmFyeSBkaXNydXB0aW9uLCBCR1AgXGhpY2hcYWY2XGRiY2hc YWYxNVxsb2NoXGY2IHNlY3VyaXR5IHNvbHV0aW9ucyBNVVNUDVxwYXIgXGhpY2hcYWY2 XGRiY2hcYWYxNVxsb2NoXGY2ICAgIHByb3BhZ2F0ZSBzZWN1cml0eSBpbmZvcm1hdGlv biBhdCB0aGUgc2FtZSByYXRlIGFzIHRoZSBCR1AgdXBkYXRlcw1ccGFyIFxoaWNoXGFm NlxkYmNoXGFmMTVcbG9jaFxmNiAgICBhbmQgd2l0aGRyYXd9e1xjZjBccmV2aXNlZFxy ZXZhdXRoMVxyZXZkdHRtMTE4NDA1NjAzMlxkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFc Y2hhcnJzaWQ2MDMzNzQzIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiBhfXtcZGJj aFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyBcaGljaFxhZjZcZGJj aFxhZjE1XGxvY2hcZjYgbHMufXsNXGNzMTZcdlxmMFxmczE4XGluc3JzaWQxMzk3NjQ1 MSB7XCpcYXRuaWQgU0t9e1wqXGF0bmF1dGhvciBTdGVwaGVuIEtlbnR9XGNoYXRuIHtc Klxhbm5vdGF0aW9ue1wqXGF0bmRhdGUgMTE4NDA1NjAzNH1ccGFyZFxwbGFpbiBcczE3 XHFsIFxsaTBccmkwXHdpZGN0bHBhclxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGFkanVz dHJpZ2h0XHJpbjBcbGluMFxpdGFwMCANXGxhbmcxMDMzXGxhbmdmZTEwMzNcY2dyaWRc bGFuZ25wMTAzM1xsYW5nZmVucDEwMzMge1xjczE2XGZzMThcaW5zcnNpZDEzOTc2NDUx IFxjaGF0biB9e1xpbnNyc2lkMTM5NzY0NTEgSSB0aGluayBJIHVuZGVyc3RhbmQgdGhp cyBwYXJhZ3JhcGgsIGJ1dCBJXHJxdW90ZSBtIG5vdCBzdXJlLiBJdCBuZWVkcyB0byBi ZSByZXdvcmRlZCB0byBiZSBjbGVhcmVyLn19fXtcZGJjaFxmMTVcaW5zcnNpZDEzOTc2 NDUxXGNoYXJyc2lkNjAzMzc0MyANXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAg VGhlIGZvbGxvd2luZyBpdGVtcyBhcmUgcmVxdWlyZWQgdG8gcHJvcGFnYXRlIGF0IHRo ZQ1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBzYW1lIHJhdGU6DVxw YXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIG8gIFRoZSBkaXN0cmlidXRp b24gb2Yga2V5IGluZm9ybWF0aW9uIHVzZWQgYnkgaW5kaXZpZHVhbCBhY3RvcnMNXHBh ciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgICBcaGljaFxhZjZcZGJjaFxh ZjE1XGxvY2hcZjYgIHdpdGhpbiB0aGUgc3lzdGVtLCBpbmNsdWRpbmcgdGhlIGtleXMg dXNlZCBieSBpbmRpdmlkdWFsDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2 ICAgICAgIGF1dG9ub21vdXMgc3lzdGVtcyB0byBzaWduIGNlcnRpZmljYXRlcyBhbmQg b3RoZXIgb2JqZWN0c317XGNzMTZcdlxmMFxmczE4XGluc3JzaWQxMzk3NjQ1MSB7XCpc YXRuaWQgU0t9e1wqXGF0bmF1dGhvciBTdGVwaGVuIEtlbnR9XGNoYXRuIHtcKlxhbm5v dGF0aW9ue1wqXGF0bmRhdGUgMTE4NDA1NjAzMn1ccGFyZFxwbGFpbiANXHMxN1xxbCBc bGkwXHJpMFx3aWRjdGxwYXJcYXNwYWxwaGFcYXNwbnVtXGZhYXV0b1xhZGp1c3RyaWdo dFxyaW4wXGxpbjBcaXRhcDAgXGxhbmcxMDMzXGxhbmdmZTEwMzNcY2dyaWRcbGFuZ25w MTAzM1xsYW5nZmVucDEwMzMge1xjczE2XGZzMThcaW5zcnNpZDEzOTc2NDUxIFxjaGF0 biB9e1xpbnNyc2lkMTM5NzY0NTEgVGhpcyBzZWVtcyB0byBiZSBhd2Z1bGx5IHNvbHV0 aW9uIHNwZWNpZmljLiB9fX17DVxkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hhcnJz aWQ2MDMzNzQzIA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBvICBU aGUgZGlzdHJpYnV0aW9uIG9mIGluZm9ybWF0aW9uIGFib3V0IHRoZSBBU317XGNmMFxy ZXZpc2VkXHJldmF1dGgxXHJldmR0dG0xMTg0MDU2MDM1XGRiY2hcZjE1XGluc3JzaWQx Mzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2 IChlcyl9e1xkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIA1c aGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgIGF1dGhvcml6ZWQgdG8NXHBhciBcaGlj aFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgICAgYWR2ZXJ0aXNlIGEgZ2l2ZW4gYmxv Y2sgb2YgSVAgYWRkcmVzc2VzIChvciBhbiBhZGRyZXNzIHNwYVxoaWNoXGFmNlxkYmNo XGFmMTVcbG9jaFxmNiBjZSl9e1xjczE2XHZcZjBcZnMxOFxpbnNyc2lkMTM5NzY0NTEg e1wqXGF0bmlkIFNLfXtcKlxhdG5hdXRob3IgU3RlcGhlbiBLZW50fVxjaGF0biB7XCpc YW5ub3RhdGlvbntcKlxhdG5kYXRlIDExODQwNTYwMzV9XHBhcmRccGxhaW4gDVxzMTdc cWwgXGxpMFxyaTBcd2lkY3RscGFyXGFzcGFscGhhXGFzcG51bVxmYWF1dG9cYWRqdXN0 cmlnaHRccmluMFxsaW4wXGl0YXAwIFxsYW5nMTAzM1xsYW5nZmUxMDMzXGNncmlkXGxh bmducDEwMzNcbGFuZ2ZlbnAxMDMzIHtcY3MxNlxmczE4XGluc3JzaWQxMzk3NjQ1MSBc Y2hhdG4gfXtcaW5zcnNpZDEzOTc2NDUxIFRoaXMgaXMgc2xvd2x5IGNoYW5naW5nIGRh dGEsIHRoYXQgZG9lcyBub3Qgc2VlbSB0byBiZSANcmVsYXRlZCB0byB3aGF0IHRoZSB0 ZXh0IGluIHRoZSBwYXJhZ3JhcGggYWJvdmUgd2FzIGRpc2N1c3NpbmcuLH19fXtcZGJj aFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyANXHBhciBcaGljaFxh ZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgbyAgVGhlIGRpc3RyaWJ1dGlvbiBvZiBpbmZv cm1hdGlvbiBhYm91dCBjb25uZWN0aXZpdHkgYmV0d2Vlbg1ccGFyIFxoaWNoXGFmNlxk YmNoXGFmMTVcbG9jaFxmNiAgICAgICBhdXRvbm9tb3VzIHN5c3RlbXMgYW5kIGF1dG9u b21vdXMgc3lzdGVtIHBvbGljZXMsIGlmIHN1Y2gNXHBhciANXHBhciANXHBhciANXHBh ciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgQ2hyaXN0aWFuICAgICAgICAgICAg ICAgIEV4cGlyZXMgQXVndXN0IDEsIDIwMDQgICAgICAgICAgICAgICAgIFtQYWdlIDld DVxwYXIgXHBhZ2UgDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IEludGVy bmV0LURyYWZ0ICAgICAgICAgQkdQIFNlY3VyaXR5IFJlcXVpcmVtXGhpY2hcYWY2XGRi Y2hcYWYxNVxsb2NoXGY2IGVudHMgICAgICAgICAgICAgICAgRmViIDIwMDQNXHBhciAN XHBhciANXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgICAgaW5mb3Jt YXRpb24gaXMgdG8gYmUgZGlzdHJpYnV0ZWQgd2l0aGluIHRoZSBzZWN1cml0eSBzeXN0 ZW0ufXtcY3MxNlx2XGYwXGZzMThcaW5zcnNpZDEzOTc2NDUxIHtcKlxhdG5pZCBTS317 XCpcYXRuYXV0aG9yIFN0ZXBoZW4gS2VudH1cY2hhdG4ge1wqXGFubm90YXRpb257XCpc YXRuZGF0ZSAxMTg0MDU2MDM2fVxwYXJkXHBsYWluIA1cczE3XHFsIFxsaTBccmkwXHdp ZGN0bHBhclxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJpbjBcbGlu MFxpdGFwMCBcbGFuZzEwMzNcbGFuZ2ZlMTAzM1xjZ3JpZFxsYW5nbnAxMDMzXGxhbmdm ZW5wMTAzMyB7XGNzMTZcZnMxOFxpbnNyc2lkMTM5NzY0NTEgXGNoYXRuIH17XGluc3Jz aWQxMzk3NjQ1MSANVGhpcyBpcyBhbiBvZGQgc3RhdGVtZW50LiwgaWYgdGhpcyBpbmZv IGlzIGRpc3RyaWJ1dGVkIG91dHNpZGUgb2YgdGhlIHNlY3VyaXR5IHN5c3RlbSwgdGhl biBpdCBkb2VzIG5vdCBoYXZlIHRvIGJlIHRpbWVseT8gV2hhdCBpcyB0aGUgcmVhbCBp bnRlbnQgb2YgdGhpcyBidWxsZXQ/fX19e1xkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFc Y2hhcnJzaWQ2MDMzNzQzIA1ccGFyIA1ccGFyIA1ccGFyIA1ccGFyIA1ccGFyIA1ccGFy IA1ccGFyIA1ccGFyIA1ccGFyIA1ccGFyIA1ccGFyIA1ccGFyIA1ccGFyIA1ccGFyIA1c cGFyIA1ccGFyIA1ccGFyIA1ccGFyIA1ccGFyIA1ccGFyIA1ccGFyIA1ccGFyIA1ccGFy IA1ccGFyIA1ccGFyIA1ccGFyIA1ccGFyIA1ccGFyIA1ccGFyIA1ccGFyIA1ccGFyIA1c cGFyIA1ccGFyIA1ccGFyIA1ccGFyIA1ccGFyIA1ccGFyIA1ccGFyIA1ccGFyIA1ccGFy IA1ccGFyIA1ccGFyIA1ccGFyIA1ccGFyIA1ccGFyIA1ccGFyIA1ccGFyIA1ccGFyIA1c cGFyIA1ccGFyIA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiBDaHJpc3Rp YW4gICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMSwgMjAwNCAgICAgICAgICAg ICAgICBbUGFnZSAxMF0NXHBhciBccGFnZSANXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1 XGxvY2hcZjYgSW50ZXJuZXQtRHJhZnQgICAgICAgICBCR1AgU2VjdXJcaGljaFxhZjZc ZGJjaFxhZjE1XGxvY2hcZjYgaXR5IFJlcXVpcmVtZW50cyAgICAgICAgICAgICAgICBG ZWIgMjAwNA1ccGFyIA1ccGFyIA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxm NiA2LiAgQWRkcmVzcyBBbGxvY2F0aW9uIGFuZCBhZHZlcnRpc2VtZW50DVxwYXIgDVxw YXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIEFzIHBhcnQgb2YgdGhlIHJl Z3VsYXIgb3BlcmF0aW9uIG9mIHRoZSBJbnRlcm5ldCwgYWRkcmVzc2VzIHRoYXQgYXJl DVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIGFsbG9jYXRlZCB0byB9 e1xjZjBccmV2aXNlZFxyZXZhdXRoMVxyZXZkdHRtMTE4NDA1NjAzNlxkYmNoXGYxNVxp bnNyc2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIFxoaWNoXGFmNlxkYmNoXGFmMTVc bG9jaFxmNiBvbmUgfXtcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAz Mzc0MyBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgDW9yZ2FuaXphdGlvbiBtYXkg YmUsIGFuZCBhcmUgcXVpdGUgY29tbW9ubHksDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYx NVxsb2NoXGY2ICAgIGFkdmVydGlzZWQgYnkgYSBkaWZmZXJlbnQgb3JnYW5caGljaFxh ZjZcZGJjaFxhZjE1XGxvY2hcZjYgaXphdGlvbi4gIENvbW1vbiByZWFzb25zIGZvciB0 aGlzDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIHByYWN0aWNlIGlu Y2x1ZGUgbXVsdGktaG9taW5nIGFuZCByb3V0ZSByZWR1Y3Rpb24gZm9yIHRoZSBwdXJw b3NlcyBvZg1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICByZXNvdXJj ZSBjb25zZXJ2YXRpb24uICBUaGVyZSBhcmUgdHdvIG1vZGVzIG9mIGRlbGVnYXRpb246 fXtcY3MxNlx2XGYwXGZzMThcaW5zcnNpZDEzOTc2NDUxIHtcKlxhdG5pZCBTS317XCpc YXRuYXV0aG9yIFN0ZXBoZW4gS2VudH1cY2hhdG4ge1wqXGFubm90YXRpb257XCpcYXRu ZGF0ZSAxMTg0MDU2MDM4fVxwYXJkXHBsYWluIA1cczE3XHFsIFxsaTBccmkwXHdpZGN0 bHBhclxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJpbjBcbGluMFxp dGFwMCBcbGFuZzEwMzNcbGFuZ2ZlMTAzM1xjZ3JpZFxsYW5nbnAxMDMzXGxhbmdmZW5w MTAzMyB7XGNzMTZcZnMxOFxpbnNyc2lkMTM5NzY0NTEgXGNoYXRuIH17XGluc3JzaWQx Mzk3NjQ1MSBJdCBtaWdodCBiZSBiZXR0ZXIgdG8gYnJlYQ1rIHRoaXMgaW50byB0d28g ZGlzY3Vzc2lvbnM6IG9uZSBhYm91dCBkZWxlZ2F0aW9uIG9mIGFsbG9jYXRlZCBwcmVm aXhlcyBhbmQgb25lIGFib3V0IGFkdmVydGlzZW1lbnQgb2Ygc3VjaCBkZWxlZ2F0aW9u cy59fX17XGRiY2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMgDVxw YXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIG8gIEEgQkdQIHNwZWFrZXIg YW5kIGxpc3RlbmVyIGhhdmUgY2hvc2VuIHRvIHJlc3RyaWN0IHRoZSBhbW91bnQgb2YN XHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgICAgcmVjZWl2ZWQgXGhp Y2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IHByZWZpeGVzIGZvciB0aGUgbGlzdGVuZXIu ICBUaGUgbGlzdGVuZXIgaGFzIGNob3NlbiB0bw1ccGFyIFxoaWNoXGFmNlxkYmNoXGFm MTVcbG9jaFxmNiAgICAgICBob25vciByb3V0ZSBhbm5vdW5jZW1lbnRzIHNlbnQgaW4g YSBzdW1tYXJ5IGZhc2hpb24gYnkgdGhlDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxs b2NoXGY2ICAgICAgIHNwZWFrZXIuDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2No XGY2ICAgIG8gIEFkZHJlc3Mgc3BhY2UgdGhhdCBpcyBiZWluZyBkZWxlZ2F0ZWQgaXMg cGFydCBvZiBhIGxhcmdlcg1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAg ICAgICBhbGxvY2F0aW9uIHRoYXQgaXMgb3duZWQgYnkgYW4gYXV0b25vbW91cyBzeXN0 ZW0uICBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgVGhlIG93bmVyIHRoZW4NXHBh ciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgICAgZGVsZWdhdGVzIHRoZSBz bWFsbGVyIGJsb2NrIHRvIGFub3RoZXIgQVMgZm9yIHB1cnBvc2VzIG9mDVxwYXIgXGhp Y2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgICAgIGFkdmVydGlzZW1lbnQuICBUaGlz IG1vZGUgaXMgY29tbW9ubHkgb2JzZXJ2ZWQgaW4gbXVsdGktaG9taW5nLg1ccGFyIA1c cGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBUaGVzZSB0d28gbW9kZXMg bGVhZCB0byBhIHNpbmdsZSBjb21tb24gcmVxdWlyZW1lbnQ6IEFueSBCR1AgU2VjdXJp dHkNXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgc29sdXRpb24gTVVT VCBzdXBwb3J0IGRlbGVnYXRpXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IG9uIG9m IGFuIGFkZHJlc3MgYmxvY2sgb2YgYW55IHNpemUNXHBhciBcaGljaFxhZjZcZGJjaFxh ZjE1XGxvY2hcZjYgICAgcmVnYXJkbGVzcyBvZiBpdHMgcmVsYXRpb25zaGlwIHRvIG90 aGVyIGFkZHJlc3MgYmxvY2tzIHRvIGFub3RoZXINXHBhciBcaGljaFxhZjZcZGJjaFxh ZjE1XGxvY2hcZjYgICAgZW50aXR5IHZpYSB2ZXJpZmlhYmxlIG1lYW5zLn17XGNzMTZc dlxmMFxmczE4XGluc3JzaWQxMzk3NjQ1MSB7XCpcYXRuaWQgU0t9e1wqXGF0bmF1dGhv ciBTdGVwaGVuIEtlbnR9XGNoYXRuIHtcKlxhbm5vdGF0aW9ue1wqXGF0bmRhdGUgMTE4 NDA1NjAzOX1ccGFyZFxwbGFpbiANXHMxN1xxbCBcbGkwXHJpMFx3aWRjdGxwYXJcYXNw YWxwaGFcYXNwbnVtXGZhYXV0b1xhZGp1c3RyaWdodFxyaW4wXGxpbjBcaXRhcDAgXGxh bmcxMDMzXGxhbmdmZTEwMzNcY2dyaWRcbGFuZ25wMTAzM1xsYW5nZmVucDEwMzMge1xj czE2XGZzMThcaW5zcnNpZDEzOTc2NDUxIFxjaGF0biB9e1xpbnNyc2lkMTM5NzY0NTEg SXNuXHJxdW90ZSANdCB0aGUgcmVhbCByZXF1aXJlbWVudCBoZXJlIHRoZSBhYmlsaXR5 IG9mIGEgcHJlZml4IGhvbGRlciB0byBhdXRob3JpemUgb25lIG9yIG1vcmUgQVNlcyB0 byBvcmlnaW5hdGUgcm91dGVzIGZvciB0aGUgcHJlZml4P319fXtcZGJjaFxmMTVcaW5z cnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyANXHBhciANXHBhciBcaGljaFxhZjZc ZGJjaFxhZjE1XGxvY2hcZjYgICAgQW4gYXNzb2NpYXRlZCBkZWxlZ2F0aW9uIGNyaXRl cmlhIGlzIHRoZSByZXF1aXJlbWVudCB0byBhbGxvdyBmb3INXHBhciBcaGljaFxhZjZc ZGJjaFxhZjE1XGxvY2hcZjYgICAgbm9uLUJHUCBJUCBlbmQgdXNlciBpbXBsZW1lbnRh dGlvbnMuICBBcyBhIHJlc1xoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiB1bHQsIGFs bCBzZWN1cmVkIEJHUA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBp bXBsZW1lbnRhdGlvbnMgTVVTVCBhbGxvdyBmb3IgdGhlIHByb3BhZ2F0aW9uIG9mIGEg cHJlZml4IGJ5IG1vcmUNXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAg dGhhbiBvbmUgb3JpZ2luYXRvciBBUyB3aXRoaW4gbm9ybWFsIG5ldHdvcmsgY29udmVy Z2VuY2UgdGltZXMufXtcY3MxNlx2XGYwXGZzMThcaW5zcnNpZDEzOTc2NDUxIHtcKlxh dG5pZCBTS317XCpcYXRuYXV0aG9yIFN0ZXBoZW4gS2VudH1cY2hhdG4ge1wqXGFubm90 YXRpb257XCpcYXRuZGF0ZSAxMTg0MDU2MDQwfVxwYXJkXHBsYWluIA1cczE3XHFsIFxs aTBccmkwXHdpZGN0bHBhclxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGFkanVzdHJpZ2h0 XHJpbjBcbGluMFxpdGFwMCBcbGFuZzEwMzNcbGFuZ2ZlMTAzM1xjZ3JpZFxsYW5nbnAx MDMzXGxhbmdmZW5wMTAzMyB7XGNzMTZcZnMxOFxpbnNyc2lkMTM5NzY0NTEgXGNoYXRu IH17XGluc3JzaWQxMzk3NjQ1MSBXb3VsZCBteSBjb21tZW50IGltbWVkaWF0ZWx5IGFi b3ZlIGNvdmVyIHRoaXMgY2FzZSB0b28/P319fXsNXGRiY2hcZjE1XGluc3JzaWQxMzk3 NjQ1MVxjaGFycnNpZDYwMzM3NDMgDVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIg DVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIgDVxw YXIgDVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIg DVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxs b2NoXGY2IENocmlzdGlhbiAgICAgICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAxLCAy MDA0ICAgICAgICAgICAgICAgIFtQYWdlIDExXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2No XGY2IF0NXHBhciBccGFnZSANXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYg SW50ZXJuZXQtRHJhZnQgICAgICAgICBCR1AgU2VjdXJpdHkgUmVxdWlyZW1lbnRzICAg ICAgICAgICAgICAgIEZlYiAyMDA0DVxwYXIgDVxwYXIgDVxwYXIgXGhpY2hcYWY2XGRi Y2hcYWYxNVxsb2NoXGY2IDcuICBOTFJJIGFuZCBQYXRoIEF0dHJpYnV0ZSBUcmFja2lu Zw1ccGFyIA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBUaGUgYWJp bGl0eSBmb3IgYSByZWNlaXZlciB0byBrbm93IGV4YWN0bHkgd2hvIG9yaWdpbmF0ZWQg YW5kDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIGZvcndhcmRlZCBh IHJvdXRpbmcgdXBkYXRlLCBpcyBhIGRlc2lyYWJsZSB0cmFpdC4gIEluIG9yZGVyIHRv DVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIHJhcGlkXGhpY2hcYWY2 XGRiY2hcYWYxNVxsb2NoXGY2IGx5IGlkZW50aWZ5IH17XGNmMFxyZXZpc2VkXHJldmF1 dGgxXHJldmR0dG0xMTg0MDU2MDQwXGRiY2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxjaGFy cnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IGF0dGFjayBwb2lu dHMgfXtcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyANXGhp Y2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IGFuZCBwYXJ0aWVzIGF0IGZhdWx0IGZvciBy b3V0ZSB0YWJsZQ1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBkaXNy dXB0aW9uIGl0IGlzIGltcG9ydGFudCB0byB9e1xjZjBccmV2aXNlZFxyZXZhdXRoMVxy ZXZkdHRtMTE4NDA1NjA0MFxkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hhcnJzaWQ2 MDMzNzQzIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiBiZSBhYmxlIHRvIH17XGRi Y2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRi Y2hcYWYxNVxsb2NoXGY2IA10cmFjayBhbmQgbG9nIHByZWZpeCBvcmlnaW5hdGlvbg1c cGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBpbmZvcm1hdGlvbiBhbG9u ZyB3aXRoIGFzc29jaWF0ZWQgc2VjdXJpdHkgaW5mb3JtYXRpb24uDVxwYXIgDVxwYXIg XGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIEFueSBzZWN1cml0eSBzeXN0ZW0g U0hPVUxEIHByb3ZpZGUgYSBtZXRob2QgdG8gYWxsb3cgXGhpY2hcYWY2XGRiY2hcYWYx NVxsb2NoXGY2IHRoZSByZWNlaXZlciBvZg1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVc bG9jaFxmNiAgICBhbiB1cGRhdGUgdG8gdmVyaWZ5IHRoYXQgdGhlIG9yaWdpbmF0b3Ig YWN0dWFsbHkgb3JpZ2luYXRlZCB0aGUNXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxv Y2hcZjYgICAgdXBkYXRlLCBhbmQgdGhhdCB0aGUgQVMncyBsaXN0ZWQgaW4gdGhlIEFT X1BBVEggYWN0dWFsbHkgZm9yd2FyZGVkDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxs b2NoXGY2ICAgIHRoZSB1cGRhdGUufXtcY3MxNlx2XGYwXGZzMThcaW5zcnNpZDEzOTc2 NDUxIHtcKlxhdG5pZCBTS317XCpcYXRuYXV0aG9yIFN0ZXBoZW4gS2VudH1cY2hhdG4g e1wqXGFubm90YXRpb257XCpcYXRuZGF0ZSAxMTg0MDU2MDQwfVxwYXJkXHBsYWluIFxz MTdccWwgXGxpMFxyaTBcd2lkY3RscGFyXGFzcGFscGhhXGFzcG51bVxmYWF1dG9cYWRq dXN0cmlnaHRccmluMFxsaW4wXGl0YXAwIA1cbGFuZzEwMzNcbGFuZ2ZlMTAzM1xjZ3Jp ZFxsYW5nbnAxMDMzXGxhbmdmZW5wMTAzMyB7XGNzMTZcZnMxOFxpbnNyc2lkMTM5NzY0 NTEgXGNoYXRuIH17XGluc3JzaWQxMzk3NjQ1MSBUaGlzIHNlZW1zIHRvIG92ZXJsYXAg d2l0aCBwcmV2aW91cyByZXF1aXJlbWVudHMuIFdoYXRccnF1b3RlIHMgbmV3IGhlcmU/ fX19e1xkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMzNzQzIA1ccGFy IA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBUaGUgZGF0YSBnZW5l cmF0ZWQgYnkgbG9nZ2luZyBtYXkgYmUgdmVyeSBsYXJnZSBkZXBlbmRpbmcgb24gdGhl DVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIG51bWJlciBvZiBwZWVy c1xoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAsIHRoZSBudW1iZXIgb2YgcHJlZml4 ZXMgcmVjZWl2ZWQsIHRoZSBhdXRoZW50aWNhdGlvbg1ccGFyIFxoaWNoXGFmNlxkYmNo XGFmMTVcbG9jaFxmNiAgICBtb2RlbCB1c2VkLCBhbmQgcm91dGluZyBwb2xpY2llcy4g IEFzIHN1Y2gsIGVmZmljaWVudCBkYXRhIHN0cnVjdHVyZXMNXHBhciBcaGljaFxhZjZc ZGJjaFxhZjE1XGxvY2hcZjYgICAgYW5kIHN0b3JhZ2UgbWVjaGFuaXNtcyBNVVNUIGJl IGRldmVsb3BlZCB0byBhbGxvdyBmb3IgYW4gZWZmZWN0aXZlDVxwYXIgXGhpY2hcYWY2 XGRiY2hcYWYxNVxsb2NoXGY2ICAgIG1lYW5zIG9mIHJlcHJvZHVjaW5nIGluY2lkZW50 cyBhbmQgb3V0YWdlc317XGNmMFxyZXZpc2VkXHJldmF1dGgxXHJldmR0dG0xMTg0MDU2 MDQxXGRiY2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMgXGhpY2hc YWY2XGRiY2hcYWYxNVxsb2NoXGY2IC59e1xjczE2XHZcZjBcZnMxOFxpbnNyc2lkMTM5 NzY0NTEge1wqXGF0bmlkIFNLfXtcKlxhdG5hdXRob3IgDVN0ZXBoZW4gS2VudH1cY2hh dG4ge1wqXGFubm90YXRpb257XCpcYXRuZGF0ZSAxMTg0MDU2MDQyfVxwYXJkXHBsYWlu IFxzMTdccWwgXGxpMFxyaTBcd2lkY3RscGFyXGFzcGFscGhhXGFzcG51bVxmYWF1dG9c YWRqdXN0cmlnaHRccmluMFxsaW4wXGl0YXAwIFxsYW5nMTAzM1xsYW5nZmUxMDMzXGNn cmlkXGxhbmducDEwMzNcbGFuZ2ZlbnAxMDMzIHtcY3MxNlxmczE4XGluc3JzaWQxMzk3 NjQ1MSBcY2hhdG4gfXtcaW5zcnNpZDEzOTc2NDUxIA1XaG8gZmVlbHMgc3Ryb25nbHkg YWJvdXQgdGhpcz8gQXMgeW91IG5vdGUsIHN1Y2ggbG9nZ2luZyBjb3VsZCBiZSBhIGJp ZyBidXJkZW4ufX19e1xkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hhcnJzaWQ2MDMz NzQzIA1ccGFyIA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBQYXRo IGFuXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IGQgTkxSSSBhdHRyaWJ1dGVzIE1V U1QgYmUgbG9nZ2VkIHVzaW5nIGEgc3RhbmRhcmQgZm9ybWF0LiAgVGhlDVxwYXIgXGhp Y2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIGZvcm1hdCBtdXN0IGJlIHNjYWxhYmxl IHdpdGggdGhlIGFtb3VudCBvZiBkYXRhIGxvZ2dlZCBhbmQgdGhlDVxwYXIgXGhpY2hc YWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIGZyZXF1ZW5jeSBvZiBsb2cgZ2VuZXJhdGlv bi4gIFRoZSBmcmVxdWVuY3kgb2YgbG9nIGdlbmVyYXRpb24gc2hvdWxkDVxwYXIgXGhp Y2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIGJlIGNvbnRyb2xsYWJsZSBieSB0aGUg b3BlcmF0b3IuICBUaGUgbG9nZ2luZyBtZWNoYW5caGljaFxhZjZcZGJjaFxhZjE1XGxv Y2hcZjYgaXNtcyBmb3IgdGhlDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2 ICAgIHRyYWNrZWQgaW5mb3JtYXRpb24gTVVTVCBiZSBzdGFuZGFyZGl6ZWQgYWNyb3Nz IGFsbCBwbGF0Zm9ybXMuDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAg IExvZ2dpbmcgYWJpbGl0eSBib3RoIG9uIGFuZCBvZmYgbGluZSBpcyBjb25zaWRlcmVk IGhpZ2hseSBkZXNpcmFibGUufXtcY3MxNlx2XGYwXGZzMThcaW5zcnNpZDEzOTc2NDUx IHtcKlxhdG5pZCBTS317XCpcYXRuYXV0aG9yIFN0ZXBoZW4gS2VudH1cY2hhdG4ge1wq XGFubm90YXRpb257XCpcYXRuZGF0ZSAxMTg0MDU2MDQyfVxwYXJkXHBsYWluIA1cczE3 XHFsIFxsaTBccmkwXHdpZGN0bHBhclxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGFkanVz dHJpZ2h0XHJpbjBcbGluMFxpdGFwMCBcbGFuZzEwMzNcbGFuZ2ZlMTAzM1xjZ3JpZFxs YW5nbnAxMDMzXGxhbmdmZW5wMTAzMyB7XGNzMTZcZnMxOFxpbnNyc2lkMTM5NzY0NTEg XGNoYXRuIH17XGluc3JzaWQxMzk3NjQ1MSBBZ2Fpbiwgd2hvIGlzIG1hbmRhdGluZyB0 aGlzIGZlYXR1cmU/IH19fXsNXGRiY2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxjaGFycnNp ZDYwMzM3NDMgDVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIg DVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIgDVxw YXIgDVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIg DVxwYXIgDVxwYXIgDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IENocmlz dGlhbiAgICAgICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAxLCAyMDA0ICAgICAgICAg ICAgICAgIFtQYWdlIDEyXQ1ccGFyIFxwYWdlIA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFm MTVcbG9jaFxmNiBJbnRcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgZXJuZXQtRHJh ZnQgICAgICAgICBCR1AgU2VjdXJpdHkgUmVxdWlyZW1lbnRzICAgICAgICAgICAgICAg IEZlYiAyMDA0DVxwYXIgDVxwYXIgDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2No XGY2IDguICBUcmFuc3BvcnQgfXtcY2YwXHJldmlzZWRccmV2YXV0aDFccmV2ZHR0bTEx ODQwNTYwNDNcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyBc aGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgTGF5ZXIgfXtcZGJjaFxmMTVcaW5zcnNp ZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hc ZjYgUHJvdGVjdGlvbg1ccGFyIA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxm NiAgICBUcmFuc3BvcnQgcHJvdGVjdGlvbiBpcyBhbiBpbXBvcnRhbnQgYXNwZWN0IG9m IEJHUCByb3V0aW5nIHByb3RvY29sDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2No XGY2ICAgIHNlY3VyaXR5LiAgVGhlIHBvdGVudGlhbCB0byBjcmVhdGUgYSBsaW5rZWQg dHJhbnNwb3J0L05MUkkvQVMtUEFUSA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9j aFxmNiAgICBhdXRoZW50aVxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiBjYXRpb24g bWVjaGFuaXNtIHNob3VsZCBub3QgYmUgb3Zlcmxvb2tlZCBhbmQgbWF5IHByb3ZpZGUg Zm9yDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIHRoZSBhY2NlbGVy YXRlZCBkZXBsb3ltZW50IG9mIGEgQkdQIHNlY3VyaXR5IHN5c3RlbS4gIEN1cnJlbnQN XHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgc2VjdXJpdHkgbWVjaGFu aXNtcyBmb3IgQkdQIHRyYW5zcG9ydCBhcmUgaW5hZGVxdWF0ZSBhbmQgcmVxdWlyZQ1c cGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBzaWduaWZpY2FudCBvcGVy YXRvciBpbnRlcmFjdGlvbiB0byBtYWludGFpbiBhIHJlc3BlY3RhYmxlXGhpY2hcYWY2 XGRiY2hcYWYxNVxsb2NoXGY2ICBsZXZlbCBvZg1ccGFyIFxoaWNoXGFmNlxkYmNoXGFm MTVcbG9jaFxmNiAgICBzZWN1cml0eS59e1xjczE2XHZcZjBcZnMxOFxpbnNyc2lkMTM5 NzY0NTEge1wqXGF0bmlkIFNLfXtcKlxhdG5hdXRob3IgU3RlcGhlbiBLZW50fVxjaGF0 biB7XCpcYW5ub3RhdGlvbntcKlxhdG5kYXRlIDExODQwNTYwNDN9XHBhcmRccGxhaW4g XHMxN1xxbCBcbGkwXHJpMFx3aWRjdGxwYXJcYXNwYWxwaGFcYXNwbnVtXGZhYXV0b1xh ZGp1c3RyaWdodFxyaW4wXGxpbjBcaXRhcDAgDVxsYW5nMTAzM1xsYW5nZmUxMDMzXGNn cmlkXGxhbmducDEwMzNcbGFuZ2ZlbnAxMDMzIHtcY3MxNlxmczE4XGluc3JzaWQxMzk3 NjQ1MSBcY2hhdG4gfXtcaW5zcnNpZDEzOTc2NDUxIEkgYXNzdW1lIHRiaXMgYSByZWZl cmVuY2UgdG8gdGhlIE1ENSBUQ1AgY2hlY2tzdW0sIGJ1dCB0aGUgdGV4dCBuZWVkcyBi ZSBtdWNoIGNsZWFyZXIufX19e1xkYmNoXGYxNVxpbnNyc2lkMTM5NzY0NTFcY2hhcnJz aWQ2MDMzNzQzIA1ccGFyIA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAg ICBBbnkgcHJvcG9zZWQgc2VjdXJpdHkgbWVjaGFuaXNtIE1VU1QgaW5jbHVkZSBwcm92 aXNpb25zIGZvciBzZWN1cmluZw1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxm NiAgICBib3RoIGludGVybmFsIEJHUCBhbmQgZXh0ZXJuYWwgQkdQIHBlZXJpbmcgc2Vz c2lvbnMufXtcY3MxNlx2XGYwXGZzMThcaW5zcnNpZDEzOTc2NDUxIHtcKlxhdG5pZCBT S317XCpcYXRuYXV0aG9yIFN0ZXBoZW4gS2VudH1cY2hhdG4ge1wqXGFubm90YXRpb257 XCpcYXRuZGF0ZSAxMTg0MDU2MDQ1fVxwYXJkXHBsYWluIA1cczE3XHFsIFxsaTBccmkw XHdpZGN0bHBhclxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJpbjBc bGluMFxpdGFwMCBcbGFuZzEwMzNcbGFuZ2ZlMTAzM1xjZ3JpZFxsYW5nbnAxMDMzXGxh bmdmZW5wMTAzMyB7XGNzMTZcZnMxOFxpbnNyc2lkMTM5NzY0NTEgXGNoYXRuIH17XGlu c3JzaWQxMzk3NjQ1MSANU2luY2UgYm90aCBlLUJHUCBhbmQgaUJHUCB1c2UgVENQLCBp cyB0aGVyZSBhbnkgcmVhc29uIHRvIGJlbGlldmUgdGhhdCBhIHNlY3VyaXR5IHNvbHV0 aW9uIGFwcGxpY2FibGUgdG8gZS1CR1Agd291bGQgbm90IHdvcmsgZm9yIGktQkdQP319 fXtcZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyBcaGljaFxh ZjZcZGJjaFxhZjE1XGxvY2hcZjYgICBLZXkgbWFpbnRlbmFuY2UNXHBhciBcaGljaFxh ZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgY2FuIGJlIGVzcGVjaWFsbHkgb25lcm91cyB0 byB0aGUgb3BlcmF0b3JzLiAgVGhlIG51bWJlciBvZiBrZXlzDVxwYXIgXGhpY2hcYWY2 XGRiY2hcYWYxNVxsb2NoXGY2ICAgIHJlcXVpcmVkIGFuZCB0aFxoaWNoXGFmNlxkYmNo XGFmMTVcbG9jaFxmNiBlIG1haW50ZW5hbmNlIG9mIGtleXMgKHVwZGF0ZS93aXRoZHJh dy9yZW5ldykgbWF5IGhhdmUNXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYg ICAgYW4gYWRkaXRpdmUgYWZmZWN0IHRvIGEgYmFycmllciB0byBkZXBsb3ltZW50LiAg QSBoaWdobHkgc2VjdXJhYmxlDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2 ICAgIEJHUCByb3V0aW5nIHN5c3RlbSBTSE9VTEQgcmVxdWlyZSBubyBtb3JlIHRoYW4g dGhyZWV9e1xjczE2XHZcZjBcZnMxOFxpbnNyc2lkMTM5NzY0NTEge1wqXGF0bmlkIFNL fXtcKlxhdG5hdXRob3IgU3RlcGhlbiBLZW50fVxjaGF0biB7XCpcYW5ub3RhdGlvbntc KlxhdG5kYXRlIDExODQwNTYwNDV9XHBhcmRccGxhaW4gDVxzMTdccWwgXGxpMFxyaTBc d2lkY3RscGFyXGFzcGFscGhhXGFzcG51bVxmYWF1dG9cYWRqdXN0cmlnaHRccmluMFxs aW4wXGl0YXAwIFxsYW5nMTAzM1xsYW5nZmUxMDMzXGNncmlkXGxhbmducDEwMzNcbGFu Z2ZlbnAxMDMzIHtcY3MxNlxmczE4XGluc3JzaWQxMzk3NjQ1MSBcY2hhdG4gfXtcaW5z cnNpZDEzOTc2NDUxIFdoZXJlIGRpZCB0aGUgbnVtYmVyIFxsZGJscXVvdGUgM1xyZGJs cXVvdGUgIGNvbWUgZnJvbT8gVGhpcyBzZQ1lbSBoaWdobHkgYXJiaXRyYXJ5IX19fXtc ZGJjaFxmMTVcaW5zcnNpZDEzOTc2NDUxXGNoYXJyc2lkNjAzMzc0MyBcaGljaFxhZjZc ZGJjaFxhZjE1XGxvY2hcZjYgIGtleXMgYW5kIGVhY2gNXHBhciBcaGljaFxhZjZcZGJj aFxhZjE1XGxvY2hcZjYgICAga2V5IHNob3VsZCBiZSB1cGRhdGVhYmxlIHdpdGhpbiBz aW1pbGFyIHRpbWVmcmFtZXMgYXMgcHJlXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2 IGZpeA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBwcm9wYWdhdGlv bi4gIFRoZSBwcmVmZXJyZWQgbnVtYmVyIG9mIGtleXMgaXMgT05FIHBlciBBU317XGNz MTZcdlxmMFxmczE4XGluc3JzaWQxMzk3NjQ1MSB7XCpcYXRuaWQgU0t9e1wqXGF0bmF1 dGhvciBTdGVwaGVuIEtlbnR9XGNoYXRuIHtcKlxhbm5vdGF0aW9ue1wqXGF0bmRhdGUg MTE4NDA1NjA0N31ccGFyZFxwbGFpbiANXHMxN1xxbCBcbGkwXHJpMFx3aWRjdGxwYXJc YXNwYWxwaGFcYXNwbnVtXGZhYXV0b1xhZGp1c3RyaWdodFxyaW4wXGxpbjBcaXRhcDAg XGxhbmcxMDMzXGxhbmdmZTEwMzNcY2dyaWRcbGFuZ25wMTAzM1xsYW5nZmVucDEwMzMg e1xjczE2XGZzMThcaW5zcnNpZDEzOTc2NDUxIFxjaGF0biB9e1xpbnNyc2lkMTM5NzY0 NTEgDSBPbmUga2V5IHBlciBBUyBtaWdodCBiZSBuaWNlIGZyb20gYSBtYW5hZ2VtZW50 IHBlcnNwZWN0aXZlLCB1bnRpbCB0aGUga2V5IGlzIGNvbXByb21pc2VkIGFuZCBpdCBo YXMgdG8gYmUgcmVwbGFjZWQgaW4gZXZlcnkgQkdQIHNwZWFrZXIuIFRoaXMgaXMgYSB2 ZXJ5IHF1ZXN0aW9uYWJsZSByZXF1aXJlbWVudC59fX17XGRiY2hcZjE1XGluc3JzaWQx Mzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2 IC4NDVxwYXIgDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIFRyYW5z cG9ydCBwcm90ZWN0aW9uIHN5c3RlbXMgU0hPVUxEIGZ1bmN0aW9uIGFzIGEgY29tcG9u ZW50IG9mIHRoZQ1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBCR1Ag cm91dGluZyBwcm90b2NvbCBzZWN1cml0eSBtZWNoYW5pc20uICBUaGlzIGluY2x1ZGVz IHRoZSB1c2Ugb2YNXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgdGhl IHNhbWUga2V5IGdlbmVyYXRpb24vbWFuYWdlbWVudCBzeXN0ZW1zIGFzIFxoaWNoXGFm NlxkYmNoXGFmMTVcbG9jaFxmNiB0aGUgcmVzdCBvZiB0aGUNXHBhciBcaGljaFxhZjZc ZGJjaFxhZjE1XGxvY2hcZjYgICAgc2VjdXJpdHkgc3lzdGVtLn17XGNzMTZcdlxmMFxm czE4XGluc3JzaWQxMzk3NjQ1MSB7XCpcYXRuaWQgU0t9e1wqXGF0bmF1dGhvciBTdGVw aGVuIEtlbnR9XGNoYXRuIHtcKlxhbm5vdGF0aW9ue1wqXGF0bmRhdGUgMTE4NDA1NjA0 OX1ccGFyZFxwbGFpbiBcczE3XHFsIFxsaTBccmkwXHdpZGN0bHBhclxhc3BhbHBoYVxh c3BudW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJpbjBcbGluMFxpdGFwMCANXGxhbmcxMDMz XGxhbmdmZTEwMzNcY2dyaWRcbGFuZ25wMTAzM1xsYW5nZmVucDEwMzMge1xjczE2XGZz MThcaW5zcnNpZDEzOTc2NDUxIFxjaGF0biB9e1xpbnNyc2lkMTM5NzY0NTEgVGhpcyBp cyBhIGJhZCByZXF1aXJlbWVudC4gS2V5cyB1c2VkIGZvciBwcm90ZWN0aW5nIGEgDXBl ZXJpbmcgc2Vzc2lvbiBtYXkgYmUgZ2VuZXJhdGVkIGR5bmFtaWNhbGx5IGZvciBlYWNo IHNlc3Npb24sLCBhbmQgd291bGQgdHlwaWNhbGx5IGJlIHN5bW1ldHJpYy4gVGhlc2Ug cGVlcmluZyBzZXNzaW9uIGtleXMgbWlnaHQgYmUgZGVyaXZlZCBmcm9tIGVwaGVtZXJh bCBEaWZmaWUtSGFsbG1hbiBrZXlzIChhcyBpbiBJS0UpLiBJbiBjb250cmFzdCwgIGtl eXMgZm9yIHNpZ25hdHVyZSBnZW5lcmF0aW9uL3ZlcmlmaWNhdGlvbiBhcmUgbG9uZw0g bGl2ZWQgcHVibGljIGtleSBwYWlycywgZS5nLiwgUlNBLCBEU0EsIGV0Yy59fX17XGRi Y2hcZjE1XGluc3JzaWQxMzk3NjQ1MVxjaGFycnNpZDYwMzM3NDMgDVxwYXIgDVxwYXIg XGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IDkgIFJlZmVyZW5jZXMNXHBhciANXHBh ciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgWzFdICBGcmFzZXIsICJSRkMg MjE5NiAtIFNpdGUgU2VjdXJpdHkgSGFuZGJvb2siLCBTZXB0ZW1iZXIgMTk5Ny4NXHBh ciANXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgWzJdICBSZXNjb3Js YSwgS29ydmVyIGFuZCBJbnRlcm5ldCBBcmNoaXRlY3R1cmUgQm9hcmQsICJSRkMgMzU1 MiAtDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgICAgICAgR3VpZGVs aW5lcyBmb3IgV3JpdGluZyBSRkMgVGV4dCBvbiBTZWN1cml0eSBDb25zaWRlcmF0aVxo aWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiBvbnMiLA1ccGFyIFxoaWNoXGFmNlxkYmNo XGFmMTVcbG9jaFxmNiAgICAgICAgIEp1bHkgMjAwMy4NXHBhciANXHBhciBcaGljaFxh ZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgWzNdICBSZWtodGVyIGFuZCBMaSwgIlJGQyAx NzcxIC0gQSBCb3JkZXIgR2F0ZXdheSBQcm90b2NvbCA0DVxwYXIgXGhpY2hcYWY2XGRi Y2hcYWYxNVxsb2NoXGY2ICAgICAgICAgKEJHUC00KSIsIE1hcmNoIDE5OTUuDVxwYXIg DVxwYXIgDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IEF1dGhvcidzIEFk ZHJlc3MNXHBhciANXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgQmxh aW5lIENocmlzdGlhbiAoZWRpdG9yKQ1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9j aFxmNiAgICBLTUMgVGVsZWNvbSBTb2x1dGlvbnMNXHBhciBcaGljaFxhZjZcZGJjaFxh ZjE1XGxvY2hcZjYgICAgMTU0NSBVLlMuIEhpZ2h3YXkgMjA2DVxwYXIgXGhpY2hcYWY2 XGRiY2hcYWYxNVxsb2NoXGY2ICAgIEJlZG1pbnN0ZXIsIE5KICAwNzkyMQ1ccGFyIFxo aWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBVUw1ccGFyIA1ccGFyIA1ccGFyIA1c cGFyIA1ccGFyIA1ccGFyIA1ccGFyIA1ccGFyIA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFm MTVcbG9jaFxmNiBDaHJpc3RpYW4gICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3Qg MSwgMjAwNCAgICAgICAgICAgICAgICBbUGFnZSAxM10NXHBhciBccGFnZSANXHBhciBc aGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgSW50ZXJuZXQtRHJhZnQgICAgICAgICBC R1AgU2VjdXJpdHkgUmVxdWlyZW1lbnRzICAgICAgICAgICAgICAgIEZlYiAyMDA0DVxw YXIgDVxwYXIgDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IEFwcGVuZGl4 IEEuICBBY2tub3dsZWRnZW1lbnRzDVxwYXIgDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYx NVxsb2NoXGY2ICAgIFRoZSBmb2xsb3dpbmcgaW5kaXZpZHVhbHMgY29udHJpYnV0ZWQg dG8gdGhlIGRldmVsb3BtZW50IGFuZCByZXZpZXcNXHBhciBcaGljaFxhZjZcZGJjaFxh ZjE1XGxvY2hcZjYgICBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgIG9mIHRoaXMg ZHJhZnQuICBTdGV2ZSBLZW50LCBSdXNzIFdoaXRlLCBTYW5keSBNdXJwaHksIEplZmYg SGFhcywgQm9yYQ1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBBa3lv bCwgU3VzYW4gSGFyZXMsIE1pa2UgVGlib2RlYXUsIFRob21hcyBSZW56eSwgS2FhcnRo aWsgU2l2YWt1bWFyLA1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBU YW8gV2FuLCBSYWRpYSBQZXJsbWFuLCBhbmQgTWVyaWtlIEthZW8uDVxwYXIgDVxwYXIg XGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIFRoaXMgZHJhZnQgd2FzIGRldmVs b3BlZCBiYXNlZCBvbiBjb252ZXJzYXRpb25zIHdpdGggdmFyaW91cyBuZXR3XGhpY2hc YWY2XGRiY2hcYWYxNVxsb2NoXGY2IG9yaw1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVc bG9jaFxmNiAgICBvcGVyYXRvcnMgaW5jbHVkaW5nIENocmlzIE1vcnJvdywgSmFyZWQg TWF1Y2gsIFRpbSBCYXR0bGVzLCBhbmQgUnlhbg1ccGFyIFxoaWNoXGFmNlxkYmNoXGFm MTVcbG9jaFxmNiAgICBNY0Rvd2VsbC4NXHBhciANXHBhciANXHBhciANXHBhciANXHBh ciANXHBhciANXHBhciANXHBhciANXHBhciANXHBhciANXHBhciANXHBhciANXHBhciAN XHBhciANXHBhciANXHBhciANXHBhciANXHBhciANXHBhciANXHBhciANXHBhciANXHBh ciANXHBhciANXHBhciANXHBhciANXHBhciANXHBhciANXHBhciANXHBhciANXHBhciAN XHBhciANXHBhciANXHBhciANXHBhciANXHBhciANXHBhciANXHBhciANXHBhciANXHBh ciANXHBhciANXHBhciANXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgQ2hy aXN0aWFuICAgICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDEsIDIwMDQgICAgICAg ICAgICAgICAgW1BhZ2UgMTRdDVxwYXIgXHBhZ2UgDVxwYXIgXGhpY2hcYWY2XGRiY2hc YWYxNVxsb2NoXGY2IEludGVybmV0LURyYWZ0ICAgICAgICAgQkdQIFNlY3VyaXR5IFJl cXVpcmVtZW50cyAgIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICAgICAgICAg ICAgRmViIDIwMDQNXHBhciANXHBhciANXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxv Y2hcZjYgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFN0YXRlbWVudA1ccGFyIA1ccGFyIFxo aWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBUaGUgSUVURiB0YWtlcyBubyBwb3Np dGlvbiByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9yIHNjb3BlIG9mIGFueQ1ccGFyIFxo aWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBJbnRlbGxlY3R1YWwgUHJvcGVydHkg UmlnaHRzIG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQgdG8NXHBh ciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgcGVydGFpbiB0byB0aGUgaW1w bGVtZW50YXRpb24gb3IgdXNlIG9mIHRoZSB0ZWNobm9sb2d5XGhpY2hcYWY2XGRiY2hc YWYxNVxsb2NoXGY2ICBkZXNjcmliZWQgaW4NXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1 XGxvY2hcZjYgICAgdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50IHRvIHdoaWNoIGFu eSBsaWNlbnNlIHVuZGVyIHN1Y2ggcmlnaHRzDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYx NVxsb2NoXGY2ICAgIG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZSBhdmFpbGFibGU7IG5vciBk b2VzIGl0IHJlcHJlc2VudCB0aGF0IGl0IGhhcw1ccGFyIFxoaWNoXGFmNlxkYmNoXGFm MTVcbG9jaFxmNiAgICBtYWRlIGFueSBpbmRlcGVuZGVudCBlZmZvcnQgdG8gaWRlbnRp ZnkgYW55IHN1Y2ggcmlnaHRzLiAgSW5mb3JtYXRpb24NXHBhciBcaGljaFxhZjZcZGJj aFxhZjE1XGxvY2hcZjYgICAgb24gdGhlIHByb2NlZHVyZXMgd2l0aCByZXNcaGljaFxh ZjZcZGJjaFxhZjE1XGxvY2hcZjYgcGVjdCB0byByaWdodHMgaW4gUkZDIGRvY3VtZW50 cyBjYW4gYmUNXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgZm91bmQg aW4gQkNQIDc4IGFuZCBCQ1AgNzkuDVxwYXIgDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYx NVxsb2NoXGY2ICAgIENvcGllcyBvZiBJUFIgZGlzY2xvc3VyZXMgbWFkZSB0byB0aGUg SUVURiBTZWNyZXRhcmlhdCBhbmQgYW55DVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxs b2NoXGY2ICAgIGFzc3VyYW5jZXMgb2YgbGljZW5zZXMgdG8gYmUgbWFkZSBhdmFpbGFi bGUsIG9yIHRoZSByZXN1bHQgb2YgYW4NXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxv Y2hcZjYgICAgYXR0ZW1wdCBtYWRlIHRvIG9idGFpbiBhIGdlbmVyYWwgbGljZW5zZSBv ciBwZXJtXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IGlzc2lvbiBmb3IgdGhlIHVz ZSBvZg1ccGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBzdWNoIHByb3By aWV0YXJ5IHJpZ2h0cyBieSBpbXBsZW1lbnRlcnMgb3IgdXNlcnMgb2YgdGhpcw1ccGFy IFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICBzcGVjaWZpY2F0aW9uIGNhbiBi ZSBvYnRhaW5lZCBmcm9tIHRoZSBJRVRGIG9uLWxpbmUgSVBSIHJlcG9zaXRvcnkgYXQN XHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgaHR0cDovL3d3dy5pZXRm Lm9yZy9pcHIuDVxwYXIgDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAg IFRoZSBJRVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8g aXRzIGF0dGVudGlvbiBhbnkNXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYg IFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgIGNvcHlyaWdodHMsIHBhdGVudHMg b3IgcGF0ZW50IGFwcGxpY2F0aW9ucywgb3Igb3RoZXIgcHJvcHJpZXRhcnkNXHBhciBc aGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgcmlnaHRzIHRoYXQgbWF5IGNvdmVy IHRlY2hub2xvZ3kgdGhhdCBtYXkgYmUgcmVxdWlyZWQgdG8gaW1wbGVtZW50DVxwYXIg XGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIHRoaXMgc3RhbmRhcmQuICBQbGVh c2UgYWRkcmVzcyB0aGUgaW5mb3JtYXRpb24gdG8gdGhlIElFVEYgYXQNXHBhciBcaGlj aFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgaWV0Zi1pcHJAaWV0Zi5vcmcuDVxwYXIg DVxwYXIgDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IERpc2NsYWltZXIg b2YgVmFsaWRpdHkNXHBhciANXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYg ICAgVGhpXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IHMgZG9jdW1lbnQgYW5kIHRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGFyZSBwcm92aWRlZCBvbiBhbg1c cGFyIFxoaWNoXGFmNlxkYmNoXGFmMTVcbG9jaFxmNiAgICAiQVMgSVMiIGJhc2lzIGFu ZCBUSEUgQ09OVFJJQlVUT1IsIFRIRSBPUkdBTklaQVRJT04gSEUvU0hFIFJFUFJFU0VO VFMNXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgT1IgSVMgU1BPTlNP UkVEIEJZIChJRiBBTlkpLCBUSEUgSU5URVJORVQgU09DSUVUWSBBTkQgVEhFIElOVEVS TkVUDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIEVOR0lORUVSSU5H IFRBU0sgRk9SQ0UgRElTQ0xBSU0gQUxMIFdBUlJBTlRcaGljaFxhZjZcZGJjaFxhZjE1 XGxvY2hcZjYgSUVTLCBFWFBSRVNTIE9SIElNUExJRUQsDVxwYXIgXGhpY2hcYWY2XGRi Y2hcYWYxNVxsb2NoXGY2ICAgIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gQU5Z IFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBPRiBUSEUNXHBhciBcaGljaFxhZjZcZGJjaFxh ZjE1XGxvY2hcZjYgICAgSU5GT1JNQVRJT04gSEVSRUlOIFdJTEwgTk9UIElORlJJTkdF IEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJRUQNXHBhciBcaGljaFxhZjZcZGJjaFxhZjE1 XGxvY2hcZjYgICAgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVT UyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuDVxwYXIgDVxwYXIgDVxwYXIgXGhpY2hc YWY2XGRiY2hcYWYxNVxsb2NoXGY2IENvcHlyaWdodCBTdGF0ZW1lbnQNXHBhciANXHBh ciBcaGljaFxhZjZcZGJjaFxhZjE1XGxvY2hcZjYgICAgQ29weVxoaWNoXGFmNlxkYmNo XGFmMTVcbG9jaFxmNiByaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDQp LiAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0DVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYx NVxsb2NoXGY2ICAgIHRvIHRoZSByaWdodHMsIGxpY2Vuc2VzIGFuZCByZXN0cmljdGlv bnMgY29udGFpbmVkIGluIEJDUCA3OCwgYW5kDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYx NVxsb2NoXGY2ICAgIGV4Y2VwdCBhcyBzZXQgZm9ydGggdGhlcmVpbiwgdGhlIGF1dGhv cnMgcmV0YWluIGFsbCB0aGVpciByaWdodHMuDVxwYXIgDVxwYXIgDVxwYXIgXGhpY2hc YWY2XGRiY2hcYWYxNVxsb2NoXGY2IEFja25vd2xlZGdtZW50DVxwYXIgDVxwYXIgXGhp Y2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2ICAgIEZ1bmRpbmcgZm9yIHRoZSBSRkMgRWRp dG9yIGZ1bmN0XGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IGlvbiBpcyBjdXJyZW50 bHkgcHJvdmlkZWQgYnkgdGhlDVxwYXIgXGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2 ICAgIEludGVybmV0IFNvY2lldHkuDVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIgDVxwYXIg XGhpY2hcYWY2XGRiY2hcYWYxNVxsb2NoXGY2IENocmlzdGlhbiAgICAgICAgICAgICAg ICBFeHBpcmVzIEF1Z3VzdCAxLCAyMDA0ICAgICAgICAgICAgICAgIFtQYWdlIDE1XQ1c cGFyIFxwYWdlIA1ccGFyIA1ccGFyIH19 --============_-1101814878==_============ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --============_-1101814878==_============-- From rpsec-bounces@ietf.org Tue Mar 8 13:58:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02038 for ; Tue, 8 Mar 2005 13:58:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8jxA-0004e8-RK for rpsec-web-archive@ietf.org; Tue, 08 Mar 2005 14:01:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8ju4-0006fH-BH; Tue, 08 Mar 2005 13:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8ju2-0006fC-T7 for rpsec@megatron.ietf.org; Tue, 08 Mar 2005 13:57:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01944 for ; Tue, 8 Mar 2005 13:57:56 -0500 (EST) Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8jwT-0004bu-G1 for rpsec@ietf.org; Tue, 08 Mar 2005 14:00:30 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j28IsKHG015827 for ; Tue, 8 Mar 2005 13:54:20 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAalaO5E; Tue, 8 Mar 05 13:54:17 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j28Iu6oH013567; Tue, 8 Mar 2005 13:56:06 -0500 (EST) Date: Tue, 8 Mar 2005 13:56:06 -0500 (EST) From: Sandy Murphy Message-Id: <200503081856.j28Iu6oH013567@tislabs.com> To: rpsec@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: sandy@tislabs.com Subject: [RPSEC] issue: attributes X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb I note that the draft section on the AS_PATH attribute currently says: Attributes such as local pref are locally specific and, as such, are protected by BGP session security. Is this intended to cover all attributes other than AS_PATH? Is it true to say both that all other attributes are locally specific and that the session security is therefore sufficient (my own interpretation of this sentence)? If we are to cover other specs than the base spec, then we need to consider the security requirements of other attributes, which aren't necessarily locally specific. Like considering the communities attribute -- I've seen suggestions in a couple of places that communities can be misused to effect traffic flow (including one old 1999 presentation at the blackhat conference and the Cisco BGPv4 Security Essentials paper, dated 2004). With the NOPEER community attribute, misuse has the potential to effect remote AS's (as RFC3765 notes). But even if we stick to base spec attributes, the session security might not be sufficient. E.g., I have heard discussions that NEXT_HOP can be mis-used to cause harm: A---B---C B is peering with A and C but does not intend to provide transit. A and C establish their own peering session and exchange UPDATES with a B address listed as NEXT_HOP. If this behavior still a problem, is there a requirement that could be incorporated into the security requirements? --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Mar 8 13:59:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02121 for ; Tue, 8 Mar 2005 13:59:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8jyB-0004fV-F7 for rpsec-web-archive@ietf.org; Tue, 08 Mar 2005 14:02:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8jtQ-0006ee-2v; Tue, 08 Mar 2005 13:57:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8jtP-0006eZ-0l for rpsec@megatron.ietf.org; Tue, 08 Mar 2005 13:57:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01931 for ; Tue, 8 Mar 2005 13:57:15 -0500 (EST) Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8jvp-0004ao-LY for rpsec@ietf.org; Tue, 08 Mar 2005 13:59:50 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j28IreqR015769 for ; Tue, 8 Mar 2005 13:53:40 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAVvaaZE; Tue, 8 Mar 05 13:53:37 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j28ItQ9a013547; Tue, 8 Mar 2005 13:55:26 -0500 (EST) Date: Tue, 8 Mar 2005 13:55:26 -0500 (EST) From: Sandy Murphy Message-Id: <200503081855.j28ItQ9a013547@tislabs.com> To: rpsec@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: sandy@tislabs.com Subject: [RPSEC] issue: coverage X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f There have been a few messages from people saying that the draft should indicate what it is going to cover and suggesting that it must cover lots of BGP features that aren't in the base spec. The list included: communities confederations VPN's MPLS flap dampening route reflectors MBGP The draft as written won't cover these. I can see no discussion on the list of coming to consensus of what is to be covered and what not. I see the point of those who say that the other features (which are carried in the protocol) must be covered in the security requirements. If the security requirements should happen to disable one of these features, that would not be a good thing. OTOH, I also heartily endorse Bill's comment about the inclusion of all these features representing a full employment act for BGP security folks. So what's the consensus? Base spec, Base spec with a best-effort eye to avoid preventing use of other extensions, or base spec plus all spec'd extensions? --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Mar 8 14:07:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02678 for ; Tue, 8 Mar 2005 14:07:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8k5H-0004oj-8a for rpsec-web-archive@ietf.org; Tue, 08 Mar 2005 14:09:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8jul-0006jX-LW; Tue, 08 Mar 2005 13:58:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8juk-0006jG-Sv for rpsec@megatron.ietf.org; Tue, 08 Mar 2005 13:58:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02050 for ; Tue, 8 Mar 2005 13:58:41 -0500 (EST) Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8jxB-0004e9-9R for rpsec@ietf.org; Tue, 08 Mar 2005 14:01:14 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j28It3CO015905 for ; Tue, 8 Mar 2005 13:55:03 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAOVaidF; Tue, 8 Mar 05 13:55:01 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j28IunZ8013598; Tue, 8 Mar 2005 13:56:49 -0500 (EST) Date: Tue, 8 Mar 2005 13:56:49 -0500 (EST) From: Sandy Murphy Message-Id: <200503081856.j28IunZ8013598@tislabs.com> To: rpsec@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: sandy@tislabs.com Subject: [RPSEC] issue: operator use X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 There has been discussion of the need to consider common operator uses (that are not part of the BGP spec) in the requirements. There's also been discussion of the impossibility of analyzing unspecified uses. I tried to start a discussion of the common operator uses that would be considered, but no one picked up on that thread. First question: is this an action for the wg? If people think it is not needed, ignore the following. Here's the list again. The idea is to assemble a list of operator uses that should not be prevented by the security requirements draft. The action is to decide whether each use is common enough, valuable enough, and safe enough to be protected from interference from security solutions. prepending your own AS multiple times on the AS_PATH (actually, this is in the base spec, so it's not really an outside the spec behavior, but included in the list to reassure people) prepending/inserting some AS *OTHER THAN YOUR OWN* in the AS_PATH (Blaine said he got back few comments from his query to NANOG about this, so maybe it is OBE) deleting private AS's from the AS_PATH (recognizing that some regard this not as a common operator use but a required operator use - at least before advertising to the general Internet) not deleting private AS's from the AS_PATH (some call this leakage) deleting non-private AS's from the AS_PATH (not talking aggregation and re-origining - this is deleting some AS's from the AS_PATH) proxy aggregation (that is, you haven't been allocated the prefix you advertise, but you have received prefixes that are covered by the advertised prefix) Note also: I do not intend to imply that the fact that someone, somewhere, has used bgp fields in a particular way will guarantee that that usage will be incorporated into the security requirements. Other factors must also be considered, like the potential for harm if the use comes from the wrong hands, the difficulty of designing a security protection that allowed that particular behavior, the existence of other ways to accomplish the same effect, the prevalence of the behavior, etc. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Mar 8 14:09:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02927 for ; Tue, 8 Mar 2005 14:09:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8k7o-0004rk-JB for rpsec-web-archive@ietf.org; Tue, 08 Mar 2005 14:12:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8jvN-0006kv-45; Tue, 08 Mar 2005 13:59:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8jvM-0006kq-2m for rpsec@megatron.ietf.org; Tue, 08 Mar 2005 13:59:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02111 for ; Tue, 8 Mar 2005 13:59:18 -0500 (EST) Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8jxm-0004f9-M9 for rpsec@ietf.org; Tue, 08 Mar 2005 14:01:52 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j28ItfFT015998 for ; Tue, 8 Mar 2005 13:55:41 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAABRaGoF; Tue, 8 Mar 05 13:55:37 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j28IvQv1013627; Tue, 8 Mar 2005 13:57:26 -0500 (EST) Date: Tue, 8 Mar 2005 13:57:26 -0500 (EST) From: Sandy Murphy Message-Id: <200503081857.j28IvQv1013627@tislabs.com> To: rpsec@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: sandy@tislabs.com Subject: [RPSEC] issue: ASPATH X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da The AS_PATH validity test says the ASPATH must match the topology. This eliminates a large set of bogus AS_PATHs. But as we all know, the fact that adjacencies exist does not necessarily imply that the the peers will forward the traffic. AS1 / \ AS2 AS3 / | AS4 | | | ... | | | AS17 | \ / AS18 AS 1 is not currently announcing an prefix to AS3 - that is the backup. So AS3 is not announcing the prefix to AS 18. (Or maybe AS 1 is announcing the prefix to AS3 with NO_EXPORT, so AS3 is not announcing the prefix to AS18.) But AS18 goes wacko one day and starts announcing a path AS18-AS3-AS1 to all comers. This path satisfies the "adjacency" test of the draft. But if AS 18's peers choose that path, that could put traffic over the AS1-AS3 link, which is probably a bad thing. Or it gets traffic to AS3 which doesn't have an entry in its routing table and can't forward the traffic. Do we have a mechanism in mind to inform everyone whether the path will carry traffic? Should we specify one? If not, then I think it should be explicitly noted that this test does not absolutely ensure that the AS_PATH is now or ever has been set up to pass the traffic. Suppose that A1 and A3 have a non-transit agreement, but A3 goes wacko one day and starts advertising the path to A1 to all comers. The path would carry the traffic, but might not be what A1 would like. Is that a problem? I ran across this one, I think on NANOG: major ISP major ISP west coast ----------------------------east coast | | | | \--big national multi-homed customer--/ Major ISP has an outage on the cross continent link and starts routing traffic through the customer's network. (Charging double to boot, according to the message - once on the down-link and once on the up-link.) I do not believe that the validity test would declare this an invalid path. Should it? --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Mar 8 15:15:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12680 for ; Tue, 8 Mar 2005 15:15:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8l9D-0007V0-6t for rpsec-web-archive@ietf.org; Tue, 08 Mar 2005 15:17:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8l4m-0003Ev-25; Tue, 08 Mar 2005 15:13:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8l4l-0003EW-2o for rpsec@megatron.ietf.org; Tue, 08 Mar 2005 15:13:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12443 for ; Tue, 8 Mar 2005 15:13:05 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8l7D-0007Ss-9q for rpsec@ietf.org; Tue, 08 Mar 2005 15:15:39 -0500 Received: from [130.129.134.228] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j28KCqkN021225; Tue, 8 Mar 2005 15:12:57 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <200503081857.j28IvQv1013627@tislabs.com> References: <200503081857.j28IvQv1013627@tislabs.com> Date: Tue, 8 Mar 2005 15:12:50 -0500 To: Sandy Murphy From: Stephen Kent Subject: Re: [RPSEC] issue: ASPATH Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: rpsec@ietf.org, sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc At 1:57 PM -0500 3/8/05, Sandy Murphy wrote: >The AS_PATH validity test says the ASPATH must match the topology. >This eliminates a large set of bogus AS_PATHs. But as we all know, >the fact that adjacencies exist does not necessarily imply that the >the peers will forward the traffic. > > > AS1 > / \ > AS2 AS3 > / | > AS4 | > | | > ... | > | | > AS17 | > \ / > AS18 > > >AS 1 is not currently announcing an prefix to AS3 - that is the >backup. So AS3 is not announcing the prefix to AS 18. (Or maybe AS 1 >is announcing the prefix to AS3 with NO_EXPORT, so AS3 is not >announcing the prefix to AS18.) But AS18 goes wacko one day and >starts announcing a path AS18-AS3-AS1 to all comers. This path >satisfies the "adjacency" test of the draft. But if AS 18's peers >choose that path, that could put traffic over the AS1-AS3 link, which >is probably a bad thing. Or it gets traffic to AS3 which doesn't have >an entry in its routing table and can't forward the traffic. > > >Do we have a mechanism in mind to inform everyone whether the >path will carry traffic? Should we specify one? you raise a very good point, i.e., the current version of the document refers to existence of links but fails to define the reference basis for this, nor does it say why mere existence of a link is the right sort of check to make. BGP sends UPDATEs as the means of advertising, in a directional fashion, precisely what traffic each AS is soliciting via a specific link. >If not, then I think it should be explicitly noted that this >test does not absolutely ensure that the AS_PATH is now or >ever has been set up to pass the traffic. right, which raises questions as to why we consider a crude topology representation of this sort is an appropriate reference for AS_PATH validity checking. >Suppose that A1 and A3 have a non-transit agreement, but A3 goes >wacko one day and starts advertising the path to A1 to all comers. >The path would carry the traffic, but might not be what A1 would >like. Is that a problem? I would think so, as it presumably violates the intent of route advertisements made by A1 to A3. >I ran across this one, I think on NANOG: > > > major ISP major ISP > west coast ----------------------------east coast > | | > | | > \--big national multi-homed customer--/ > >Major ISP has an outage on the cross continent link and starts routing >traffic through the customer's network. (Charging double to boot, >according to the message - once on the down-link and once on the >up-link.) > >I do not believe that the validity test would declare this an invalid >path. Should it? I'd say so, and I'd guess the unnamed customer would agree :-) Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Mar 8 15:18:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13187 for ; Tue, 8 Mar 2005 15:18:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8lCU-0007ap-Sx for rpsec-web-archive@ietf.org; Tue, 08 Mar 2005 15:21:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8l4l-0003Eg-Pz; Tue, 08 Mar 2005 15:13:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8l4k-0003ER-LU for rpsec@megatron.ietf.org; Tue, 08 Mar 2005 15:13:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12440 for ; Tue, 8 Mar 2005 15:13:04 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8l7B-0007Sp-TI for rpsec@ietf.org; Tue, 08 Mar 2005 15:15:39 -0500 Received: from [130.129.134.228] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j28KCqkJ021225; Tue, 8 Mar 2005 15:12:54 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <200503081856.j28Iu6oH013567@tislabs.com> References: <200503081856.j28Iu6oH013567@tislabs.com> Date: Tue, 8 Mar 2005 14:50:21 -0500 To: Sandy Murphy From: Stephen Kent Subject: Re: [RPSEC] issue: attributes Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Sandy, As you note, some attributes should have only local significance, but others are intended to be propagated beyond a neighbor AS. We also need to pay attention to the semantics of local attributes, in that it is desirable to enable an AS to detect if a prior AS did not behave in a way consistent with a local attribute. The obvious case here is the NO-EXPORT community attribute, which should be only locally significant, but it would be nice to know if AS path info was propagated contrary to the express wishes of a speaker. It seems appropriate to identify which attributes fall into which category, as a starting point. Then we should decide whether we want to require or recommend that solutions provide a facility for a speaker to apply protection to attributes in a fashion that supports the underlying semantics. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Mar 8 15:19:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13440 for ; Tue, 8 Mar 2005 15:19:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8lDS-0007dg-T5 for rpsec-web-archive@ietf.org; Tue, 08 Mar 2005 15:22:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8l4l-0003Eb-Fj; Tue, 08 Mar 2005 15:13:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8l4j-0003EH-Rr for rpsec@megatron.ietf.org; Tue, 08 Mar 2005 15:13:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12434 for ; Tue, 8 Mar 2005 15:13:03 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8l7B-0007Sr-TD for rpsec@ietf.org; Tue, 08 Mar 2005 15:15:38 -0500 Received: from [130.129.134.228] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j28KCqkL021225; Tue, 8 Mar 2005 15:12:55 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <200503081856.j28IunZ8013598@tislabs.com> References: <200503081856.j28IunZ8013598@tislabs.com> Date: Tue, 8 Mar 2005 14:58:27 -0500 To: Sandy Murphy From: Stephen Kent Subject: Re: [RPSEC] issue: operator use Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da At 1:56 PM -0500 3/8/05, Sandy Murphy wrote: >There has been discussion of the need to consider common operator uses >(that are not part of the BGP spec) in the requirements. There's also >been discussion of the impossibility of analyzing unspecified uses. I >tried to start a discussion of the common operator uses that would be >considered, but no one picked up on that thread. > >First question: is this an action for the wg? If people think it >is not needed, ignore the following. > >Here's the list again. The idea is to assemble a list of >operator uses that should not be prevented by the security >requirements draft. The action is to decide whether each >use is common enough, valuable enough, and safe enough to be >protected from interference from security solutions. > >prepending your own AS multiple times on the AS_PATH > (actually, this is in the base spec, so it's not really an outside > the spec behavior, but included in the list to reassure people) right, the BGP spec already addresses this, so it should be explicitly OK >prepending/inserting some AS *OTHER THAN YOUR OWN* in the AS_PATH > (Blaine said he got back few comments from his query to NANOG > about this, so maybe it is OBE) hopefully this is something we can say is NOT OK >deleting private AS's from the AS_PATH > (recognizing that some regard this not as a common operator use > but a required operator use - at least before advertising to the > general Internet) what are the assumptions about private ASes, and what document states the assumptions? based on the terminology, I'd expect that these ASes ought not appear in advertisements in the public Internet. >not deleting private AS's from the AS_PATH > (some call this leakage) see comments above. >deleting non-private AS's from the AS_PATH > (not talking aggregation and re-origining - this is deleting some AS's > from the AS_PATH) we need to get an explanation on when this occurs and why it is considered appropriate behavior, since it is not consistent with comments in the BGP RFC. >proxy aggregation > (that is, you haven't been allocated the prefix you advertise, > but you have received prefixes that are covered by the advertised > prefix) If the AS performing proxy aggregation is authorized to do so by the prefix holders, then it would seem to be OK. if not, then it becomes indistinguishable from bogus origination of prefixes, in general. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Mar 8 15:47:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17996 for ; Tue, 8 Mar 2005 15:47:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8lez-0000Nx-4s for rpsec-web-archive@ietf.org; Tue, 08 Mar 2005 15:50:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8lbL-00036D-7Q; Tue, 08 Mar 2005 15:46:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8lbJ-00035T-RT for rpsec@megatron.ietf.org; Tue, 08 Mar 2005 15:46:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17884 for ; Tue, 8 Mar 2005 15:46:43 -0500 (EST) Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8ldl-0000MS-F0 for rpsec@ietf.org; Tue, 08 Mar 2005 15:49:18 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j28Kh7YT025887 for ; Tue, 8 Mar 2005 15:43:07 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAApUaOJY; Tue, 8 Mar 05 15:43:04 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j28KilAs017341; Tue, 8 Mar 2005 15:44:47 -0500 (EST) Date: Tue, 8 Mar 2005 15:44:47 -0500 (EST) From: Sandy Murphy Message-Id: <200503082044.j28KilAs017341@tislabs.com> To: kent@bbn.com, sandy@tislabs.com Subject: Re: [RPSEC] issue: ASPATH X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f >you raise a very good point, i.e., the current version of the >document refers to existence of links but fails to define the >reference basis for this, nor does it say why mere existence of a >link is the right sort of check to make. Well, for one thing, it is a fairly (comparatively) easy check to make that will flag a large number of the potential bogus AS_PATHs - speaking just in terms of the number of sequences that could be formed from the thousands of AS's. And it could be based on info that is realtively static (peering agreements, tho not active peerings of course). --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Mar 8 15:49:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18069 for ; Tue, 8 Mar 2005 15:49:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8lgK-0000Pe-6u for rpsec-web-archive@ietf.org; Tue, 08 Mar 2005 15:51:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8lc3-00039W-Ih; Tue, 08 Mar 2005 15:47:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8lc2-00039R-Mh for rpsec@megatron.ietf.org; Tue, 08 Mar 2005 15:47:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17971 for ; Tue, 8 Mar 2005 15:47:28 -0500 (EST) Received: from blaines.net ([65.79.159.21] helo=tunguy.blaines.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8leT-0000N3-Mm for rpsec@ietf.org; Tue, 08 Mar 2005 15:50:03 -0500 Received: from [208.231.75.210] ([208.231.75.210]) (authenticated bits=0) by tunguy.blaines.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id j28KkCsh012007 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Tue, 8 Mar 2005 15:46:24 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 08 Mar 2005 15:46:06 -0500 Subject: Re: [RPSEC] issue: operator use From: Blaine Christian To: Stephen Kent , Sandy Murphy Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit I am sure I will have much more to say on the recent threads... However, one thought is important to express. Comment inline... On 3/8/05 2:58 PM, "Stephen Kent" wrote: > > >> prepending/inserting some AS *OTHER THAN YOUR OWN* in the AS_PATH >> (Blaine said he got back few comments from his query to NANOG >> about this, so maybe it is OBE) > > hopefully this is something we can say is NOT OK > The one, very notable, exception is the prepending of your external peers AS number on a "received" advertisement. Many operators use this, including me. This is used to depref/pref advertisements from various peers. The one mechanism that does not seem to be much used, but was raised by an operator, was the insertion of a distant AS's AS number in order to ensure that AS does not process a prefix advertisement. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Mar 8 16:49:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23483 for ; Tue, 8 Mar 2005 16:49:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8mcK-00023b-OK for rpsec-web-archive@ietf.org; Tue, 08 Mar 2005 16:51:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8mXC-0002q9-1c; Tue, 08 Mar 2005 16:46:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8mX6-0002np-T9 for rpsec@megatron.ietf.org; Tue, 08 Mar 2005 16:46:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23275 for ; Tue, 8 Mar 2005 16:46:26 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8mZY-0001zH-QT for rpsec@ietf.org; Tue, 08 Mar 2005 16:49:02 -0500 Received: from [130.129.134.228] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j28LjukJ026604; Tue, 8 Mar 2005 16:45:57 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 8 Mar 2005 16:45:57 -0500 To: Blaine Christian From: Stephen Kent Subject: Re: [RPSEC] issue: operator use Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b At 3:46 PM -0500 3/8/05, Blaine Christian wrote: >I am sure I will have much more to say on the recent threads... However, >one thought is important to express. Comment inline... > > >On 3/8/05 2:58 PM, "Stephen Kent" wrote: > >> >> >>> prepending/inserting some AS *OTHER THAN YOUR OWN* in the AS_PATH >>> (Blaine said he got back few comments from his query to NANOG >>> about this, so maybe it is OBE) >> >> hopefully this is something we can say is NOT OK >> > >The one, very notable, exception is the prepending of your external peers AS >number on a "received" advertisement. Many operators use this, including >me. This is used to depref/pref advertisements from various peers. so the notion is that you may or may not add one or more instances of the peer's AS to bias your choice of route. do you send it with these added AS numbers, or just use it internally? if the latter, no problem, but the former is an attack, generically. can't you achieve the same effect, when sending the advertisement to neighbors, by prepending your own AS number several times. >The one mechanism that does not seem to be much used, but was raised by an >operator, was the insertion of a distant AS's AS number in order to ensure >that AS does not process a prefix advertisement. Yes, that works, but to paraphrase a famous line from the Watergate hearings, "we could do it but it would be wrong." Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Mar 8 17:22:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26019 for ; Tue, 8 Mar 2005 17:22:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8n81-0002gb-Fm for rpsec-web-archive@ietf.org; Tue, 08 Mar 2005 17:24:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8n3H-0006kD-Iq; Tue, 08 Mar 2005 17:19:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8n3F-0006k7-JM for rpsec@megatron.ietf.org; Tue, 08 Mar 2005 17:19:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25878 for ; Tue, 8 Mar 2005 17:19:38 -0500 (EST) Received: from blaines.net ([65.79.159.21] helo=tunguy.blaines.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8n5h-0002dz-Mh for rpsec@ietf.org; Tue, 08 Mar 2005 17:22:14 -0500 Received: from [208.231.75.210] ([208.231.75.210]) (authenticated bits=0) by tunguy.blaines.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id j28MIush013226 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Tue, 8 Mar 2005 17:19:09 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 08 Mar 2005 17:18:50 -0500 Subject: Re: [RPSEC] issue: operator use From: Blaine Christian To: Stephen Kent Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit > > so the notion is that you may or may not add one or more instances of > the peer's AS to bias your choice of route. do you send it with these > added AS numbers, or just use it internally? if the latter, no > problem, but the former is an attack, generically. can't you achieve > the same effect, when sending the advertisement to neighbors, by > prepending your own AS number several times. Folks could prepend and then deprepend... I am not sure that is desired though. I can count off a few scenarios that would break folks existing setups. I think we are going to have to allow folks to prepend their peers incoming advertisements. I received significant feedback on this (about a third) of the community that responded to my request for info. It is really not an attack if you think about it. It is just managing my traffic. IMHO each "cluster" of like AS numbers should be considered to be one instance of an AS for the purposes of security. This seems to be a reasonable assumption to make. Regards, Blaine _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Mar 8 18:00:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28620 for ; Tue, 8 Mar 2005 18:00:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8nix-0003PT-Kz for rpsec-web-archive@ietf.org; Tue, 08 Mar 2005 18:02:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8ned-0002w5-Au; Tue, 08 Mar 2005 17:58:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8neb-0002vx-Sq for rpsec@megatron.ietf.org; Tue, 08 Mar 2005 17:58:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28475 for ; Tue, 8 Mar 2005 17:58:15 -0500 (EST) Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8nh4-0003MC-Lt for rpsec@ietf.org; Tue, 08 Mar 2005 18:00:51 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j28Msdgx005750 for ; Tue, 8 Mar 2005 17:54:39 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAdAaGnl; Tue, 8 Mar 05 17:54:36 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j28MuJ7J020566; Tue, 8 Mar 2005 17:56:19 -0500 (EST) Date: Tue, 8 Mar 2005 17:56:19 -0500 (EST) From: Sandy Murphy Message-Id: <200503082256.j28MuJ7J020566@tislabs.com> To: blaine@blaines.net, kent@bbn.com Subject: Re: [RPSEC] issue: operator use X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 >It is really not an attack if you think about it. It is just managing my >traffic. IMHO each "cluster" of like AS numbers should be considered to be >one instance of an AS for the purposes of security. This seems to be a >reasonable assumption to make. This may not be an attack if you do it to manage your traffic - but could someone of unpure motives use the same sort of path manipulation to cause problems? Is there a way to limit the sort of manipulations to those that are non-risky? What do you mean by "like AS numbers"? You were speaking of appending your peer's AS on the AS_PATH you advertise. In what way is your peer's AS a "like AS"? --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Mar 8 18:02:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28762 for ; Tue, 8 Mar 2005 18:02:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8nlF-0003SL-CP for rpsec-web-archive@ietf.org; Tue, 08 Mar 2005 18:05:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8ngD-00033Q-QF; Tue, 08 Mar 2005 17:59:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8ngB-00033I-N0 for rpsec@megatron.ietf.org; Tue, 08 Mar 2005 17:59:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28580 for ; Tue, 8 Mar 2005 17:59:52 -0500 (EST) Received: from sidehack.sat.gweep.net ([204.145.148.154]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D8nif-0003P3-Bt for rpsec@ietf.org; Tue, 08 Mar 2005 18:02:29 -0500 Received: (qmail 25815 invoked by uid 524); 8 Mar 2005 22:59:54 -0000 Date: Tue, 8 Mar 2005 17:59:54 -0500 From: Joe Provo To: rpsec@ietf.org Subject: Re: [RPSEC] issue: operator use Message-ID: <20050308225954.GA25443@gweep.net> References: <200503081856.j28IunZ8013598@tislabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503081856.j28IunZ8013598@tislabs.com> User-Agent: Mutt/1.4.2.1i X-PGP-Key: http://www.gweep.net/~crimson/pgp.txt X-Disclaimer: "I'm the only one foolish enough to claim these opinions." Organization: Russell Street UN*X Consultations - If we don't do it, you don't need it. X-Do-Not-Email-Here: junky@place.rsuc.gweep.net X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jzp-rpsec@rsuc.gweep.net List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe On Tue, Mar 08, 2005 at 01:56:49PM -0500, Sandy Murphy wrote: > There has been discussion of the need to consider common > operator uses (that are not part of the BGP spec) in the > requirements. [snip] It will be of interest to see what level of use or specific applications is considered 'common' or 'abuse of existing ambiguities' vs 'use of available resources', and by what constituencies. > prepending your own AS multiple times on the AS_PATH irrelevant for this purpose as it is part of the spec and manipulating your 'own' data. > prepending/inserting some AS *OTHER THAN YOUR OWN* in the AS_PATH > (Blaine said he got back few comments from his query to NANOG > about this, so maybe it is OBE) this is forgery, generally filtered as part of belts-and-suspenders for customer-leak-prevention, and not 'common' in my experience. It was observed before providers provided customers with remote path manipulation communities (prepend, supress). remote-action communities have overtaken path forgery in the past few years. > deleting private AS's from the AS_PATH > (recognizing that some regard this not as a common operator use > but a required operator use - at least before advertising to the > general Internet) > not deleting private AS's from the AS_PATH > (some call this leakage) Dropping the announcement (or stripping in the case of direct customers and announcing under your own ASN) is BCP and a 'common' interpretation of rfc1930 section 10. Propaagating these ASNs is clearly inappropriate. > deleting non-private AS's from the AS_PATH > (not talking aggregation and re-origining - this is deleting > some AS's from the AS_PATH) Reductive forgery is still forgery. the only corner case is where ones own as is the element being remove, a la transparent acting route servers. The current practice appears to be against this [the self-deleting-entity's neghbor's inability to appropriately handle security events has been cited]. Are there route servers in operation which currently do this? > proxy aggregation > (that is, you haven't been allocated the prefix you > advertise, but you have received prefixes that are covered > by the advertised prefix) as long as the atomic-aggregate flag is set, this is not only within spec but specifically in the design. without atomic-aggregate set, such path manipulation would be a form of forgery, no? Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Mar 8 18:16:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00391 for ; Tue, 8 Mar 2005 18:16:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8nyi-0003fk-48 for rpsec-web-archive@ietf.org; Tue, 08 Mar 2005 18:19:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8nuK-0004eI-Od; Tue, 08 Mar 2005 18:14:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8nuI-0004e7-Kn for rpsec@megatron.ietf.org; Tue, 08 Mar 2005 18:14:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00123 for ; Tue, 8 Mar 2005 18:14:27 -0500 (EST) Received: from sidehack.sat.gweep.net ([204.145.148.154]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D8nwm-0003db-FD for rpsec@ietf.org; Tue, 08 Mar 2005 18:17:04 -0500 Received: (qmail 27869 invoked by uid 524); 8 Mar 2005 23:14:29 -0000 Date: Tue, 8 Mar 2005 18:14:29 -0500 From: Joe Provo To: rpsec@ietf.org Subject: Re: [RPSEC] issue: operator use Message-ID: <20050308231429.GB25443@gweep.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-PGP-Key: http://www.gweep.net/~crimson/pgp.txt X-Disclaimer: "I'm the only one foolish enough to claim these opinions." Organization: Russell Street UN*X Consultations - If we don't do it, you don't need it. X-Do-Not-Email-Here: jzp@suespammers.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jzp-rpsec@rsuc.gweep.net List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 On Tue, Mar 08, 2005 at 05:18:50PM -0500, Blaine Christian wrote: > > kent@bbn.com wrote: > > so the notion is that you may or may not add one or more > > instances of the peer's AS to bias your choice of route. > > do you send it with these added AS numbers, or just use > > it internally? if the latter, no problem, but the former > > is an attack, generically. can't you achieve the same > > effect, when sending the advertisement to neighbors, by > > prepending your own AS number several times. > > Folks could prepend and then deprepend... I am not sure > that is desired though. I can count off a few scenarios > that would break folks existing setups. I think we are > going to have to allow folks to prepend their peers > incoming advertisements. I received significant feedback > on this (about a third) of the community that responded > to my request for info. > > It is really not an attack if you think about it. It is > just managing my traffic. IMHO each "cluster" of like AS > numbers should be considered to be one instance of an AS > for the purposes of security. This seems to be a reasonable > assumption to make. I believe Steve K was driving toward the point that there is a large difference between twddling data for internal purposes and then propagating those twiddles. There's no detail in the path to indicate which side of the relationship adjusted the as-path, and the general assumption is not forgery and that one prepends one's own data rather than manipulating others'. In the instances of which you speak, is the peer aware of propagating the altered paths? I would imagine if it was purely a case of traffic management at a specific point in the decision tree, then it wouldn't be a problem to not propagate those altered paths, no? I too have to rewind and catch up on the previous messages (an effective subject line caught my attention) to see if some more subtle bits of forgery caught in the wild have already been brought up. Cheers! Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Mar 8 18:23:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01128 for ; Tue, 8 Mar 2005 18:23:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8o5G-0003oE-Cf for rpsec-web-archive@ietf.org; Tue, 08 Mar 2005 18:25:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8o1G-0005Z0-Cz; Tue, 08 Mar 2005 18:21:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8o1E-0005Yv-Jo for rpsec@megatron.ietf.org; Tue, 08 Mar 2005 18:21:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00962 for ; Tue, 8 Mar 2005 18:21:37 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8o3h-0003lc-Fc for rpsec@ietf.org; Tue, 08 Mar 2005 18:24:14 -0500 Received: from [130.129.134.228] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j28NLHkN000963; Tue, 8 Mar 2005 18:21:23 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <200503082044.j28KilAs017341@tislabs.com> References: <200503082044.j28KilAs017341@tislabs.com> Date: Tue, 8 Mar 2005 18:21:17 -0500 To: Sandy Murphy From: Stephen Kent Subject: Re: [RPSEC] issue: ASPATH Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a At 3:44 PM -0500 3/8/05, Sandy Murphy wrote: > >you raise a very good point, i.e., the current version of the >>document refers to existence of links but fails to define the >>reference basis for this, nor does it say why mere existence of a >>link is the right sort of check to make. > >Well, for one thing, it is a fairly (comparatively) easy check to >make that will flag a large number of the potential bogus AS_PATHs - >speaking just in terms of the number of sequences that could be >formed from the thousands of AS's. And it could be based on info >that is realtively static (peering agreements, tho not active >peerings of course). I agree that it would rule out many bogus paths, but is also allows many bogus paths, in the general case, including in examples you gave! What we are discussing is how different is the graph one gets from looking at AS connectivity as defined in a prefix-constrained fashion, vs. non-directional, prefix-free graph. I have done this comparison, using RV data, and there is a world of difference. If this data is representative, then the number of paths that would pass the simple connectivity test, vs. reality (as expressed via propagated routes) is enormous. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Mar 8 18:26:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01399 for ; Tue, 8 Mar 2005 18:26:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8o85-0003tA-Km for rpsec-web-archive@ietf.org; Tue, 08 Mar 2005 18:28:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8o1Q-0005bH-6J; Tue, 08 Mar 2005 18:21:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8o1O-0005ZA-Tl for rpsec@megatron.ietf.org; Tue, 08 Mar 2005 18:21:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00970 for ; Tue, 8 Mar 2005 18:21:47 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8o3n-0003m2-3Q for rpsec@ietf.org; Tue, 08 Mar 2005 18:24:25 -0500 Received: from [130.129.134.228] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j28NLHkL000963; Tue, 8 Mar 2005 18:21:22 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 8 Mar 2005 18:15:59 -0500 To: Blaine Christian From: Stephen Kent Subject: Re: [RPSEC] issue: operator use Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 At 5:18 PM -0500 3/8/05, Blaine Christian wrote: > > >> so the notion is that you may or may not add one or more instances of >> the peer's AS to bias your choice of route. do you send it with these >> added AS numbers, or just use it internally? if the latter, no >> problem, but the former is an attack, generically. can't you achieve >> the same effect, when sending the advertisement to neighbors, by >> prepending your own AS number several times. > >Folks could prepend and then deprepend... I am not sure that is desired >though. I can count off a few scenarios that would break folks existing >setups. I think we are going to have to allow folks to prepend their peers >incoming advertisements. I received significant feedback on this (about a >third) of the community that responded to my request for info. > >It is really not an attack if you think about it. It is just managing my >traffic. IMHO each "cluster" of like AS numbers should be considered to be >one instance of an AS for the purposes of security. This seems to be a >reasonable assumption to make. I know that this is used legitimately as a traffic engineering mechanism. However, this represents a modification of the AS path in a fashion that is not consistent with the BGP RFC. Also, since you can achieve the same traffic engineering effect by prepending your own AS number multiple times, it seems undesirable to make provisions to achieve the effect the other way. Moreover, an operator examining the path further along would probably interpret the multiple instances of your neighbor's AS # as an act by that neighbor to bias routing, not an act by you. So, if we were to declare this as an acceptable behavior, we are adding ambiguity to path interpretation, which is not conducive to security. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Mar 8 18:30:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01810 for ; Tue, 8 Mar 2005 18:30:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8oCQ-0003xk-Kx for rpsec-web-archive@ietf.org; Tue, 08 Mar 2005 18:33:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8o8R-0006TB-0m; Tue, 08 Mar 2005 18:29:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8o8O-0006Sz-Ag for rpsec@megatron.ietf.org; Tue, 08 Mar 2005 18:29:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01662 for ; Tue, 8 Mar 2005 18:29:01 -0500 (EST) Received: from rimp1.nist.gov ([129.6.16.226] helo=smtp.nist.gov) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8oAs-0003wc-0P for rpsec@ietf.org; Tue, 08 Mar 2005 18:31:38 -0500 Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j28NSda7019227; Tue, 8 Mar 2005 18:28:39 -0500 Received: from [127.0.0.1] ([129.6.220.22]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j28NRkEY015438; Tue, 8 Mar 2005 18:27:47 -0500 (EST) Message-ID: <422E34F4.8080308@nist.gov> Date: Tue, 08 Mar 2005 18:27:48 -0500 From: Doug Montgomery Organization: http://www.antd.nist.gov/ User-Agent: Mozilla Thunderbird 1.0 (Windows/20050209) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Subject: Re: [RPSEC] issue: ASPATH References: <200503081857.j28IvQv1013627@tislabs.com> In-Reply-To: X-Enigmail-Version: 0.90.1.1 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-MailScanner-From: dougm@nist.gov X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org, Sandy Murphy X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Stephen Kent wrote: >> Do we have a mechanism in mind to inform everyone whether the >> path will carry traffic? Should we specify one? > > > you raise a very good point, i.e., the current version of the document > refers to existence of links but fails to define the reference basis for > this, nor does it say why mere existence of a link is the right sort of > check to make. BGP sends UPDATEs as the means of advertising, in a > directional fashion, precisely what traffic each AS is soliciting via a > specific link. > >> If not, then I think it should be explicitly noted that this >> test does not absolutely ensure that the AS_PATH is now or >> ever has been set up to pass the traffic. > > > right, which raises questions as to why we consider a crude topology > representation of this sort is an appropriate reference for AS_PATH > validity checking. It seems that a few of the documents have insufficient vocabulary in discussing such things. I will note that (in general) what we usually think of as "links" are not visible in the BGP system. One might want to talk about the graph of BGP peering relationships among ASes. Note, that one might be able to check more specific details about your immediate neighbor peer (e.g., specific link/interface/AS bindings), but from afar all these details disappear. One might be tempted to establish some vocabulary along the lines of the following: Taxonomy of BGP PATHS per NLRI as seen by an individual node: Potential Paths: the set of acyclic paths among all configured AS peering relationships. i.e., the set before we apply policy, routing decisions, administrative and operational state. In general, a given BGP node may not be able to infer much of the membership of this set. Feasible Paths: a subset of potential paths that reflect current administrative polices for route distribution and BGP administrative state. i.e., the set before routing decisions and operational state. In general, it is conceivable that a given BGP node could see any of the members of this set, but at any one moment, much of this set may not be inferable from the BGP protocol alone. Viable Paths: a subset of feasible paths that reflect currently propagated BGP routes. i.e., the subset of feasible routes that reflect current network operational states and routing decisions. A given BGP node will be able to see this set of PATHS as the cumulative contents of its Adj-RIB-ins. Optimal Paths: a subset of viable paths that reflect the local node's local routing preferences and decisions processes. While the result of one nodes choice of optimal paths is made visible in its subsequent updates, it is impossible from afar to verify from afar a remote nodes choices among viable paths. Some documents refer to "valid" and "correct" PATHs / routes. In general, I think that is a poor choice of term, but one might wish to think about PATH tests in terms of what information you might have to perform the test and which set from the above taxonomy you are testing membership in. > >> Suppose that A1 and A3 have a non-transit agreement, but A3 goes >> wacko one day and starts advertising the path to A1 to all comers. >> The path would carry the traffic, but might not be what A1 would >> like. Is that a problem? It is. But without global distribution of policy information, one man's wacko is indistinguishable from a shrew business decision. dougm _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Mar 9 08:20:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01090 for ; Wed, 9 Mar 2005 08:20:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D919f-0007Ml-Nj for rpsec-web-archive@ietf.org; Wed, 09 Mar 2005 08:23:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D914v-0006ib-U9; Wed, 09 Mar 2005 08:18:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D914u-0006iW-Up for rpsec@megatron.ietf.org; Wed, 09 Mar 2005 08:18:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00753 for ; Wed, 9 Mar 2005 08:18:19 -0500 (EST) Received: from blaines.net ([65.79.159.21] helo=tunguy.blaines.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D917W-0007ID-3t for rpsec@ietf.org; Wed, 09 Mar 2005 08:21:02 -0500 Received: from [208.231.75.210] ([208.231.75.210]) (authenticated bits=0) by tunguy.blaines.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id j29DHVsh025709 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Wed, 9 Mar 2005 08:17:59 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 09 Mar 2005 08:17:25 -0500 Subject: Re: [RPSEC] issue: operator use From: Blaine Christian To: Stephen Kent Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit >> >> Folks could prepend and then deprepend... I am not sure that is desired >> though. I can count off a few scenarios that would break folks existing >> setups. I think we are going to have to allow folks to prepend their peers >> incoming advertisements. I received significant feedback on this (about a >> third) of the community that responded to my request for info. >> >> It is really not an attack if you think about it. It is just managing my >> traffic. IMHO each "cluster" of like AS numbers should be considered to be >> one instance of an AS for the purposes of security. This seems to be a >> reasonable assumption to make. > > I know that this is used legitimately as a traffic engineering > mechanism. However, this represents a modification of the AS path in > a fashion that is not consistent with the BGP RFC. Also, since you > can achieve the same traffic engineering effect by prepending your > own AS number multiple times, it seems undesirable to make provisions > to achieve the effect the other way. Moreover, an operator examining > the path further along would probably interpret the multiple > instances of your neighbor's AS # as an act by that neighbor to bias > routing, not an act by you. So, if we were to declare this as an > acceptable behavior, we are adding ambiguity to path interpretation, > which is not conducive to security. > This is where we have to cite it as an operational issue. Many folks prepend inbound advertisements with their peers AS and advertise to the world. It is okay to say it is not to be used but we would then have to provide a means for folks to easily substitute another mechanism. Typically, I would tell the vendor that it is their software that is going to break me so they need to come up with a solution that does not. I am not sure I understand you on the BGP RFC part. I could not find a spot in the existing RFC that allows, or disallows, any prepending other than one prepend on advertisement to an external peer. Can you tell me what section refers to this? Funny enough... I did find a section in 1771 that refers to the removal of all duplicate AS' within an AS set. " If as a result of the above procedure a given AS number appears more than once within the aggregated AS_PATH attribute, all, but the last instance (rightmost occurrence) of that AS number should be removed from the aggregated AS_PATH attribute." The above text seems to indicate that the authors had the same idea as me (or I had the same idea as them). That all instances of a single AS (in our case adjacent to each other in the path) can be considered one AS for the purposes of path aggregation (in our case securing the path). I did also find this text (that you may be referring to).... " When a given BGP speaker advertises the route to another BGP speaker located in its own autonomous system, the advertising speaker shall not modify the AS_PATH attribute associated with the route." It may be cutting a fine line but this text does not seem to preclude the modification of advertisements you receive from your external peers. There will probably be a lot of fight on the ability to prepend inbound and outbound. I think we need to have a good story on this otherwise we will spend all our time defending the position that you are not allowed to prepend your peers AS on a received advertisement. Can we approach this from a different angle? What security problems would result in grouping AS's that are adjacent duplicates? It does not seem like it would be a hard problem to solve. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Mar 9 08:52:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03488 for ; Wed, 9 Mar 2005 08:52:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D91eh-0007wt-Vx for rpsec-web-archive@ietf.org; Wed, 09 Mar 2005 08:55:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D91bh-0000z3-2F; Wed, 09 Mar 2005 08:52:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D91bb-0000yq-SN for rpsec@megatron.ietf.org; Wed, 09 Mar 2005 08:52:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03435 for ; Wed, 9 Mar 2005 08:52:05 -0500 (EST) Received: from dns2.nexthop.com ([65.247.36.217] helo=aa-mx2.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D91eA-0007w5-Mf for rpsec@ietf.org; Wed, 09 Mar 2005 08:54:49 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx2.nexthop.com (Postfix) with ESMTP id 6A2D64AC14; Wed, 9 Mar 2005 08:51:55 -0500 (EST) Received: from aa-mx2.nexthop.com ([127.0.0.1]) by localhost (aa-mx2.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 04094-01-4; Wed, 9 Mar 2005 08:51:50 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx2.nexthop.com (Postfix) with ESMTP id 930284AC01; Wed, 9 Mar 2005 08:51:50 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j29DpoV17774; Wed, 9 Mar 2005 08:51:50 -0500 (EST) Date: Wed, 9 Mar 2005 08:51:50 -0500 From: Jeffrey Haas To: Blaine Christian Subject: Re: [RPSEC] issue: operator use Message-ID: <20050309135149.GA17743@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: rpsec@ietf.org, Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 On Wed, Mar 09, 2005 at 08:17:25AM -0500, Blaine Christian wrote: > I am not sure I understand you on the BGP RFC part. I could not find a spot > in the existing RFC that allows, or disallows, any prepending other than one > prepend on advertisement to an external peer. Let's use draft-ietf-idr-bgp4-26.txt as that's the one that's about to RFC. This allows one to prepend multiple instances of one's AS number. It doesn't talk about prepending one's neighbor's AS number. > Can you tell me what section > refers to this? Funny enough... I did find a section in 1771 that refers > to the removal of all duplicate AS' within an AS set. This makes sense in both the RFC 1771 and -26 contexts. A set is a set and duplicate elements add no meaning. (Unfortunately,) common usage lead to the AS_SETs adding one to the calculated length of the AS_PATH. Thus, the entire set counts as one rather than one per each AS in the set. > It may be cutting a fine line but this text does not seem to preclude the > modification of advertisements you receive from your external peers. This is the usual argument over whether or not "that which is not said is prohibited" is what is usually meant. In more cases than not, this is a reasonable way to read a specification. The property you're trying to take advantage of is artificially lengthening the AS_PATH received from a peer in order to bias the preference of the route within your AS using the BGP route selection rules. This technique is very effective and achieves things that aren't easily achieved using other policy. However, it does have negative effects upon the party that sent you the route since if this artificially lengthened route is used and propagated, it'll bias route selection throughout the Internet. As far as the loop prevention properties of the AS_PATH goes, artificially lengthening the AS_PATH doesn't really break anything. As far as the security implications of adjacent ASes in the AS_PATH, it doesn't change anything. However, any mechanism we're likely to propose with regards to preventing modification of the AS_PATH outside of the stated rules of the RFCs would cause the artificial lengthening to generate potentially invalid routes. (I.e. you've modified a bit of the route you shouldn't.) > There will probably be a lot of fight on the ability to prepend inbound and > outbound. Only on inbound, I think. It wouldn't shock me if someone introduced a mechanism that allows for biasing routes at a particular portion of the route selection process. I believe John Scudder had suggested something along these lines, although the mechanism was very broad. > Can we approach this from a different angle? What security problems would > result in grouping AS's that are adjacent duplicates? It does not seem like > it would be a hard problem to solve. As mentioned above, at least one security implication is you are (negatively) biasing downstream route selection using the neighbor AS rather than your own AS. -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Mar 9 10:47:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17733 for ; Wed, 9 Mar 2005 10:47:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D93Rv-0002s7-Gv for rpsec-web-archive@ietf.org; Wed, 09 Mar 2005 10:50:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D93NS-00010T-Ul; Wed, 09 Mar 2005 10:45:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D93NR-0000zA-RB for rpsec@megatron.ietf.org; Wed, 09 Mar 2005 10:45:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17516 for ; Wed, 9 Mar 2005 10:45:35 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D93Q3-0002o9-Uf for rpsec@ietf.org; Wed, 09 Mar 2005 10:48:20 -0500 Received: from [130.129.134.228] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j29Fj1kJ027897; Wed, 9 Mar 2005 10:45:02 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 9 Mar 2005 10:45:02 -0500 To: Blaine Christian From: Stephen Kent Subject: Re: [RPSEC] issue: operator use X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.1 (/) X-Scan-Signature: 918f4bd8440e8de4700bcf6d658bc801 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0630670333==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 1094b1c84fa6e846d476f39271f5074f --===============0630670333== Content-Type: multipart/alternative; boundary="============_-1101739389==_ma============" --============_-1101739389==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 8:17 AM -0500 3/9/05, Blaine Christian wrote: > >> >>> Folks could prepend and then deprepend... I am not sure that is desired >>> though. I can count off a few scenarios that would break folks existing >>> setups. I think we are going to have to allow folks to prepend their peers >>> incoming advertisements. I received significant feedback on this (about a >>> third) of the community that responded to my request for info. >>> >>> It is really not an attack if you think about it. It is just managing my >>> traffic. IMHO each "cluster" of like AS numbers should be considered to be >>> one instance of an AS for the purposes of security. This seems to be a >>> reasonable assumption to make. >> >> I know that this is used legitimately as a traffic engineering >> mechanism. However, this represents a modification of the AS path in >> a fashion that is not consistent with the BGP RFC. Also, since you >> can achieve the same traffic engineering effect by prepending your >> own AS number multiple times, it seems undesirable to make provisions >> to achieve the effect the other way. Moreover, an operator examining >> the path further along would probably interpret the multiple >> instances of your neighbor's AS # as an act by that neighbor to bias >> routing, not an act by you. So, if we were to declare this as an >> acceptable behavior, we are adding ambiguity to path interpretation, >> which is not conducive to security. >> > >This is where we have to cite it as an operational issue. Many folks >prepend inbound advertisements with their peers AS and advertise to the >world. It is okay to say it is not to be used but we would then have to >provide a means for folks to easily substitute another mechanism. >Typically, I would tell the vendor that it is their software that is going >to break me so they need to come up with a solution that does not. from the RV data I have seen, and based on discussions with at least one ISP, prepending your own AS number is supported by routers, and that's why I suggest it is a viable alternative. >I am not sure I understand you on the BGP RFC part. I could not find a spot >in the existing RFC that allows, or disallows, any prepending other than one >prepend on advertisement to an external peer. Can you tell me what section >refers to this? Funny enough... I did find a section in 1771 that refers >to the removal of all duplicate AS' within an AS set. RFC 1771 does not allow prepending of multiple instances of an SA, but the latest BGP draft, which is in the RFC editor's queue, does. Section 5.1.2 of the document says: Whenever the modification of the AS_PATH attribute calls for including or prepending the AS number of the local system, the local system MAY include/prepend more than one instance of its own AS number in the AS_PATH attribute. This is controlled via local configuration. Appendix A, which describes changes from 1771, says: The ability of a BGP speaker to include more than one instance of its own AS in the AS_PATH attribute for the purpose of inter-AS traffic engineering. So, the change allows an AS to append its OWN AS number multiple times, and the rationale is that this is allowed for traffic engineering purposes. > >" If as a result of the above procedure a given AS number appears > more than once within the aggregated AS_PATH attribute, all, but > the last instance (rightmost occurrence) of that AS number should > be removed from the aggregated AS_PATH attribute." > >The above text seems to indicate that the authors had the same idea as me >(or I had the same idea as them). That all instances of a single AS (in our >case adjacent to each other in the path) can be considered one AS for the >purposes of path aggregation (in our case securing the path). this text applies to aggregation, but not to normal, non-aggregation, processing. so, I don't think it conflicts with the text I cited above. > >I did also find this text (that you may be referring to).... > >" When a given BGP speaker advertises the route to another BGP > speaker located in its own autonomous system, the advertising > speaker shall not modify the AS_PATH attribute associated with the > route." > >It may be cutting a fine line but this text does not seem to preclude the >modification of advertisements you receive from your external peers. I would not draw the same conclusion. >There will probably be a lot of fight on the ability to prepend inbound and >outbound. I think we need to have a good story on this otherwise we will >spend all our time defending the position that you are not allowed to >prepend your peers AS on a received advertisement. the latest version of the spec explicitly allows prepending your own AS, and does not say anything about changing the AS path received from a neighbor in the fashion you describe. we seem to be having an argument over whether one should bias a route by adding one's own AS multiple times, (which is explicitly allowed now) vs. adding the preceding peer's AS number multiple times. both approaches achieve the same effect, when advertised to other ASes, and the method approved in the new spec makes it clear which AS is trying to impose the bias. if we allow both, then later ASes can't tell which of two neighboring ASes did the biasing, which seems inappropriate. >Can we approach this from a different angle? What security problems would >result in grouping AS's that are adjacent duplicates? It does not seem like >it would be a hard problem to solve. I see two problems: - this is an example of adding someone else's AS to a path, which is generally something we agree is a no-no, and thus requires a special case exception to allow such "tampering." - as noted above, if we allow both forms of multi-AS prepending, we create ambiguity for other ASes, since they can't know which AS is trying to bias the route. Steve --============_-1101739389==_ma============ Content-Type: text/html; charset="us-ascii" Re: [RPSEC] issue: operator use
At 8:17 AM -0500 3/9/05, Blaine Christian wrote:
>>
>> Folks could prepend and then deprepend...  I am not sure that is desired
>> though.  I can count off a few scenarios that would break folks existing
>> setups.  I think we are going to have to allow folks to prepend their peers
>> incoming advertisements.  I received significant feedback on this (about a
>> third) of the community that responded to my request for info.
>>
>> It is really not an attack if you think about it.  It is just managing my
>> traffic.  IMHO each "cluster" of like AS numbers should be considered to be
>> one instance of an AS for the purposes of security.  This seems to be a
>> reasonable assumption to make.
>
> I know that this is used legitimately as a traffic engineering
> mechanism. However, this represents a modification of the AS path in
> a fashion that is not consistent with the BGP RFC. Also, since you
> can achieve the same traffic engineering effect by prepending your
> own AS number multiple times, it seems undesirable to make provisions
> to achieve the effect the other way. Moreover, an operator examining
> the path further along would probably interpret the multiple
> instances of your neighbor's AS # as an act by that neighbor to bias
> routing, not an act by you. So, if we were to declare this as an
> acceptable behavior, we are adding ambiguity to path interpretation,
> which is not conducive to security.
>

This is where we have to cite it as an operational issue.  Many folks
prepend inbound advertisements with their peers AS and advertise to the
world.  It is okay to say it is not to be used but we would then have to
provide a means for folks to easily substitute another mechanism.
Typically, I would tell the vendor that it is their software that is going
to break me so they need to come up with a solution that does not.

from the RV data I have seen, and based on discussions with at least one ISP, prepending your own AS number is supported by routers, and that's why I suggest it is a viable alternative.

I am not sure I understand you on the BGP RFC part.  I could not find a spot
in the existing RFC that allows, or disallows, any prepending other than one
prepend on advertisement to an external peer.  Can you tell me what section
refers to this?  Funny enough...  I did find a section in 1771 that refers
to the removal of all duplicate AS' within an AS set.

RFC 1771 does not allow prepending of multiple instances of an SA, but the latest BGP draft, which is in the RFC editor's queue, does.  Section 5.1.2 of the document says:

   Whenever the modification of the AS_PATH attribute calls for including or prepending the AS number of the local system, the local system MAY include/prepend more than one instance of its own AS number in the AS_PATH attribute. This is controlled via local configuration.

Appendix A, which describes changes from 1771, says:

The ability of a BGP speaker to include more than one instance of its own AS in the AS_PATH attribute for the purpose of inter-AS
traffic engineering.

So, the change allows an AS to append its OWN AS number multiple times, and the rationale is that this is allowed for traffic engineering purposes.


" If as a result of the above procedure a given AS number appears
      more than once within the aggregated AS_PATH attribute, all, but
      the last instance (rightmost occurrence) of that AS number should
      be removed from the aggregated AS_PATH attribute."

The above text seems to indicate that the authors had the same idea as me
(or I had the same idea as them).  That all instances of a single AS (in our
case adjacent to each other in the path) can be considered one AS for the
purposes of path aggregation (in our case securing the path).

this text applies to aggregation, but not to normal, non-aggregation, processing.  so, I don't think it conflicts with the text I cited above.


I did also find this text (that you may be referring to)....

" When a given BGP speaker advertises the route to another BGP
      speaker located in its own autonomous system, the advertising
      speaker shall not modify the AS_PATH attribute associated with the
      route."

It may be cutting a fine line but this text does not seem to preclude the
modification of advertisements you receive from your external peers.

I would not draw the same conclusion.

There will probably be a lot of fight on the ability to prepend inbound and
outbound.  I think we need to have a good story on this otherwise we will
spend all our time defending the position that you are not allowed to
prepend your peers AS on a received advertisement.

the latest version of the spec explicitly allows prepending your own AS, and does not say anything about changing the AS path received from a neighbor in the fashion you describe. we seem to be having an argument over whether one should bias a route by adding one's own AS multiple times, (which is explicitly allowed now) vs. adding the preceding peer's AS number multiple times. both approaches achieve the same effect, when advertised to other ASes, and the method approved in the new spec makes it clear which AS is trying to impose the bias. if we allow both, then later ASes can't tell which of two neighboring ASes did the biasing, which seems inappropriate.

Can we approach this from a different angle?  What security problems would
result in grouping AS's that are adjacent duplicates?  It does not seem like
it would be a hard problem to solve.

I see two problems:
        - this is an example of adding someone else's AS to a path, which is generally something we agree is a no-no, and thus requires a special case exception to allow such "tampering."
        - as noted above, if we allow both forms of multi-AS prepending, we create ambiguity for other ASes, since they can't know which AS is trying to bias the route.

Steve
--============_-1101739389==_ma============-- --===============0630670333== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --===============0630670333==-- From rpsec-bounces@ietf.org Wed Mar 9 10:52:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18193 for ; Wed, 9 Mar 2005 10:52:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D93Wz-00030b-Re for rpsec-web-archive@ietf.org; Wed, 09 Mar 2005 10:55:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D93Rk-0001L6-LR; Wed, 09 Mar 2005 10:50:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D93Rj-0001KS-4N for rpsec@megatron.ietf.org; Wed, 09 Mar 2005 10:50:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17977 for ; Wed, 9 Mar 2005 10:50:00 -0500 (EST) Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D93UK-0002wH-SB for rpsec@ietf.org; Wed, 09 Mar 2005 10:52:46 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j29FkMb3010392 for ; Wed, 9 Mar 2005 10:46:22 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA_Da4ru; Wed, 9 Mar 05 10:46:19 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j29Flwa8017513; Wed, 9 Mar 2005 10:47:58 -0500 (EST) Date: Wed, 9 Mar 2005 10:47:58 -0500 (EST) From: Sandy Murphy Message-Id: <200503091547.j29Flwa8017513@tislabs.com> To: dougm@nist.gov, kent@bbn.com Subject: Re: [RPSEC] issue: ASPATH X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: rpsec@ietf.org, sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 >It is. But without global distribution of policy information, one >man's wacko is indistinguishable from a shrew business decision. A hidden feature of some of the topics, examples, comments that I made are that policy causes the problem, policy is being violated, policy is not being communicated, etc. Policy gets mentioned in the draft, as part of the "Areas to secure": o The originator and the propagators of prefix information may have their policy information verified such that the intent of the policy with respect to the specific prefix is preserved and gets mentioned again as a "required to propogate at the same rate": o The distribution of information about connectivity between autonomous systems and autonomous system polices, if such information is to be distributed within the security system. But policy does not come in when the requirements are being listed. So should it? I do have some reservations about creating a mechanism to distribute policy - simply because policies now-a-days seems to be so dependent of the business model. When (not if) the business model changes, policy communication mechanisms could get OBE. Not to mention the oft-repeated reluctance of ISP's to expose their policies. I'm more comfortable with communicating "this is indeed the result of my internal policy decision" which leaves unsaid what the policy would be. I recognize that there is a problem with communicating "and here's my authorization of what you can do with my data". That expands the implicit "here's my route, you can use it for traffic" to something that is so complicated that it can no longer be implicit. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Mar 9 11:15:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20338 for ; Wed, 9 Mar 2005 11:15:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D93t6-0003Ws-8s for rpsec-web-archive@ietf.org; Wed, 09 Mar 2005 11:18:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D93oj-0004Ce-9V; Wed, 09 Mar 2005 11:13:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D93oh-0004C4-2d for rpsec@megatron.ietf.org; Wed, 09 Mar 2005 11:13:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20147 for ; Wed, 9 Mar 2005 11:13:44 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D93rG-0003Tw-Hd for rpsec@ietf.org; Wed, 09 Mar 2005 11:16:30 -0500 Received: from [130.129.134.228] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j29GDWkJ029566; Wed, 9 Mar 2005 11:13:32 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <422E34F4.8080308@nist.gov> References: <200503081857.j28IvQv1013627@tislabs.com> <422E34F4.8080308@nist.gov> Date: Wed, 9 Mar 2005 11:13:31 -0500 To: Doug Montgomery From: Stephen Kent Subject: Re: [RPSEC] issue: ASPATH Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Doug, I agree that we need to use more precise terminology, and your example list is a good start. Terms like "valid" are too imprecise when used to refer to these graphs. > >> >>> Suppose that A1 and A3 have a non-transit agreement, but A3 goes >>> wacko one day and starts advertising the path to A1 to all comers. >>> The path would carry the traffic, but might not be what A1 would >>> like. Is that a problem? > >It is. But without global distribution of policy information, one >man's wacko is indistinguishable from a shrew business decision. Not exactly true, as Sandy noted. The routes (legitimately) advertised by ASes are the result of applying local policies and current link status, etc., and, ultimately, this is what we want to secure. Comparing advertisements to a mix of topology and policy data provides a basis for rejecting a set of bad advertisements, but it does not represent a way to verify that a given advertisement is authentic. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Mar 9 11:42:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22864 for ; Wed, 9 Mar 2005 11:42:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D94JI-000476-MG for rpsec-web-archive@ietf.org; Wed, 09 Mar 2005 11:45:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D94Cf-000751-GK; Wed, 09 Mar 2005 11:38:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D94Cd-00074V-3e for rpsec@megatron.ietf.org; Wed, 09 Mar 2005 11:38:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22546 for ; Wed, 9 Mar 2005 11:38:28 -0500 (EST) Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D94FF-00042A-8T for rpsec@ietf.org; Wed, 09 Mar 2005 11:41:14 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j29GYqTN014306 for ; Wed, 9 Mar 2005 11:34:52 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAs_ay7B; Wed, 9 Mar 05 11:34:49 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j29GaWnn018776; Wed, 9 Mar 2005 11:36:32 -0500 (EST) Date: Wed, 9 Mar 2005 11:36:32 -0500 (EST) From: Sandy Murphy Message-Id: <200503091636.j29GaWnn018776@tislabs.com> To: blaine@blaines.net, jhaas@nexthop.com Subject: Re: [RPSEC] issue: operator use X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: rpsec@ietf.org, kent@bbn.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 >This is the usual argument over whether or not "that which is not said >is prohibited" is what is usually meant. In more cases than not, this >is a reasonable way to read a specification. Jeff, you say "whether or not", so I'm not certain which standpoint you are saying is a reasonable way to read the spec. I have heard this stated as "anything not prohibited is permitted". I am responding to that interpretation. I don't agree that it is reasonable. If the spec says "add 1 to the TTL and send" but does not say "do not add 2, do not subtract 1, do not change the TTL to 200", I don't think that anyone could justify adding 2, subtracting 1, etc on that basis of it not being prohibited. The spec says add you own AS (as many times as you like) to the AS_PATH. Other things are done and commonly. I don't think that "the spec doesn't say you can't" as justification when it explicitly says what you are to do. Furthermore. There are an infinite (well, ok, not infinite, but one heckofa big number) of behaviors not mentioned in the spec (for TTL example: don't add 2, don't add 3, ...., don't subtract 1, don't subtract 2, ...., don't multiply by 2, don't multiply by 3,.... don't change to 13, don't change to 14, ....) Trying to define the security for such an interpretation of what the spec means would be impossible. Give up now. Declare failure and announce the end of the world. Etc. I'm pushing here, but the point is important. Reading specs that broadly presents real problems in designing security. The reason such broad interpretations of the spec have not led to uninteroperability is that no one has been checking the AS_PATH for compliance. Even checking the AS_PATH for the peer's AS has not been done (and that has gone back and forth in idr discussions of the vulnerabilities, let me tell you), for example. If we're trying to secure things, we can't necessarily allow any manipulation that people have been performing. (The reason why people are concerned about BGP is that some people have been doing some rather hurtful manipulations.) Is it common, is it uniquely useful, can it be misused, is it secureable - all these have to be answered. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Mar 9 11:53:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24351 for ; Wed, 9 Mar 2005 11:53:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D94TN-0004Vq-OC for rpsec-web-archive@ietf.org; Wed, 09 Mar 2005 11:55:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D94Oh-0000TO-UH; Wed, 09 Mar 2005 11:50:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D94Og-0000Sd-Op for rpsec@megatron.ietf.org; Wed, 09 Mar 2005 11:50:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24078 for ; Wed, 9 Mar 2005 11:50:55 -0500 (EST) Received: from rimp1.nist.gov ([129.6.16.226] helo=smtp.nist.gov) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D94RI-0004PF-0V for rpsec@ietf.org; Wed, 09 Mar 2005 11:53:41 -0500 Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j29GnnaV020176; Wed, 9 Mar 2005 11:49:50 -0500 Received: from [127.0.0.1] ([129.6.220.5]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j29GmiEY023086; Wed, 9 Mar 2005 11:48:48 -0500 (EST) Message-ID: <422F28DC.4070103@nist.gov> Date: Wed, 09 Mar 2005 11:48:28 -0500 From: Doug Montgomery Organization: http://www.antd.nist.gov/ User-Agent: Mozilla Thunderbird 1.0 (Windows/20050209) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sandy Murphy Subject: Re: [RPSEC] issue: ASPATH References: <200503091547.j29Flwa8017513@tislabs.com> In-Reply-To: <200503091547.j29Flwa8017513@tislabs.com> X-Enigmail-Version: 0.90.1.1 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-MailScanner-From: dougm@nist.gov X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org, kent@bbn.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Sandy Murphy wrote: >>It is. But without global distribution of policy information, one >>man's wacko is indistinguishable from a shrew business decision. > > > A hidden feature of some of the topics, examples, comments that I > made are that policy causes the problem, policy is being violated, > policy is not being communicated, etc. > > Policy gets mentioned in the draft, as part of the "Areas to secure": > > o The originator and the propagators of prefix information may have > their policy information verified such that the intent of the > policy with respect to the specific prefix is preserved > > and gets mentioned again as a "required to propogate at the same rate": > > o The distribution of information about connectivity between > autonomous systems and autonomous system polices, if such > information is to be distributed within the security system. > > But policy does not come in when the requirements are being listed. > So should it? > > I do have some reservations about creating a mechanism to distribute > policy - simply because policies now-a-days seems to be so dependent > of the business model. When (not if) the business model changes, > policy communication mechanisms could get OBE. Not to mention the > oft-repeated reluctance of ISP's to expose their policies. I'm > more comfortable with communicating "this is indeed the result of > my internal policy decision" which leaves unsaid what the policy > would be. *Distributing* enough information so that you could infer from a far what policy decision another AS would make seems entirely intractable along numerous dimensions (scale, representation, distribution mechanisms, privacy concerns, etc). This would be hard enough if one was only concerned with the decisions an AS makes up to itself (i.e. the suffix of the PATH from the AS in question to the source). If you are concerned about down stream policy (i.e., what others can do with my announcements), it only seems worse. If you are only concerned about the former, to some extent, the routes that a AS propagates is a statement of the result of its internal policy decision (including local pref). i.e., I show my neighbors my view of the set of optimal PATHS. To some extent, as long as you can verify the origin and integrity of the a given AS's contribution to the PATH, you might infer that at least the suffix of the PATH is indeed the result of my internal policy decisions. If you could verify origin and integrity of PATH suffixes, I see no reason to out of band ask an AS if what your are seeing is in its set of optimal, viable, feasible, or potential paths. If you are unable to verify PATH suffixes, or don't trust them for some reason, then you might want to infer from a far if a given announced PATH suffix is in an AS's set of optimal, viable, feasible and/or possible paths. I will note that even if it is query based, allowing me to "probe" any set either than optimal PATHS, would allow me to discovery information that you may not want public. Of course the more volatile information (e.g., optimal paths) has some temporal/stability concerns if you are verifying it from afar. > > I recognize that there is a problem with communicating "and here's > my authorization of what you can do with my data". That expands > the implicit "here's my route, you can use it for traffic" to > something that is so complicated that it can no longer be implicit. > > --Sandy Yep, verifying PATHS as being consistent with downstream policies is a whole new can of worms. As you suggest, we should really think about what aspects of policy can be protected/verified and at what cost. dougm _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Mar 9 12:11:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26642 for ; Wed, 9 Mar 2005 12:11:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D94l6-00059F-Ug for rpsec-web-archive@ietf.org; Wed, 09 Mar 2005 12:14:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D94fd-0004Oc-AO; Wed, 09 Mar 2005 12:08:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D94fb-0004OU-Oo for rpsec@megatron.ietf.org; Wed, 09 Mar 2005 12:08:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26280 for ; Wed, 9 Mar 2005 12:08:24 -0500 (EST) Received: from smtp1.phx.gblx.net ([64.208.25.103]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D94iD-00052X-Sc for rpsec@ietf.org; Wed, 09 Mar 2005 12:11:11 -0500 Received: (from daemon@localhost) by smtp1.phx.gblx.net (8.11.2/8.11.2) id j29H8OU15424 for ; Wed, 9 Mar 2005 10:08:24 -0700 (MST) Received: from shell1.phx.gblx.net(64.208.25.102) via SMTP by smtp1.phx.gblx.net, id smtpdAAA14aOhE; Wed Mar 9 10:08:24 2005 Received: from localhost (guy@localhost) by shell1.phx.gblx.net (8.9.3+Sun/8.9.3) with ESMTP id KAA10031 for ; Wed, 9 Mar 2005 10:08:24 -0700 (MST) X-Authentication-Warning: shell1.phx.gblx.net: guy owned process doing -bs Date: Wed, 9 Mar 2005 12:08:24 -0500 (EST) From: Guy Tal X-X-Sender: guy@shell1.phx.gblx.net To: rpsec@ietf.org Subject: Re: [RPSEC] issue: operator use In-Reply-To: <200503091636.j29GaWnn018776@tislabs.com> Message-ID: References: <200503091636.j29GaWnn018776@tislabs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 I wanted to chime in on the prepending issue. IMHO, one should *not* be able to prepend any AS other than the network AS one controls. It's called an Autonomous System for a reason. Simply put, If you do not control a router in an AS, you should not be able to add that AS in the AS_PATH. To add another network's AS that you don't control is similar to stealing or slander in my book. There are ways to accomplish route preference other than manipulating AS_PATH. On a similar note, I've talked with two customers of GX's that have built a business model around gathering small customers, aggregating them, then announcing all those routes sans AS to make it appear for the customers that they are direct customers of us or anyone else the middleman AS is connected to. Do these guys need to come up with a new business model? Or will there be provisions for a model like this? Guy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Mar 9 12:30:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29282 for ; Wed, 9 Mar 2005 12:30:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D953t-0005oH-R7 for rpsec-web-archive@ietf.org; Wed, 09 Mar 2005 12:33:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D94ys-0001jo-02; Wed, 09 Mar 2005 12:28:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D94yq-0001jZ-6v for rpsec@megatron.ietf.org; Wed, 09 Mar 2005 12:28:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29088 for ; Wed, 9 Mar 2005 12:28:17 -0500 (EST) Received: from server2.tcw.telecomplete.net ([213.160.116.2] helo=mx-0.telecomplete.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D951S-0005l3-LN for rpsec@ietf.org; Wed, 09 Mar 2005 12:31:03 -0500 Received: from server2.tcw.telecomplete.net ([127.0.0.1]) by mx-0.telecomplete.net with esmtp (Exim 4.22) id 1D94yg-0007BB-QN; Wed, 09 Mar 2005 17:28:10 +0000 Date: Wed, 9 Mar 2005 17:28:10 +0000 (GMT) From: "Stephen J. Wilcox" X-X-Sender: steve@server2.tcw.telecomplete.net To: Guy Tal Subject: Re: [RPSEC] issue: operator use In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Hi Guy, I dont think the spec is the right place to regulate it tho, there are reasons why someone might prepend an asn other than the one the bgp process is running under that is not the asn of another company's network Steve On Wed, 9 Mar 2005, Guy Tal wrote: > I wanted to chime in on the prepending issue. IMHO, one should > *not* be able to prepend any AS other than the network AS one controls. > It's called an Autonomous System for a reason. Simply put, If you do not > control a router in an AS, you should not be able to add that AS in the > AS_PATH. To add another network's AS that you don't control is similar to > stealing or slander in my book. There are ways to accomplish route > preference other than manipulating AS_PATH. > On a similar note, I've talked with two customers of GX's that > have built a business model around gathering small customers, aggregating > them, then announcing all those routes sans AS to make it appear for the > customers that they are direct customers of us or anyone else the > middleman AS is connected to. Do these guys need to come up with a new > business model? Or will there be provisions for a model like this? > > Guy > > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec > _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Mar 10 06:17:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02575 for ; Thu, 10 Mar 2005 06:17:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9LiV-0001ow-Lw for rpsec-web-archive@ietf.org; Thu, 10 Mar 2005 06:20:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Lf3-0008HR-QW; Thu, 10 Mar 2005 06:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Lep-0008Gj-8z for rpsec@megatron.ietf.org; Thu, 10 Mar 2005 06:16:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02554 for ; Thu, 10 Mar 2005 06:16:43 -0500 (EST) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Lha-0001nZ-E3 for rpsec@ietf.org; Thu, 10 Mar 2005 06:19:39 -0500 Received: from pc6 (1Cust217.tnt105.lnd4.gbr.da.uu.net [213.116.58.217]) by galaxy.systems.pipex.net (Postfix) with SMTP id A97A9E00026C; Thu, 10 Mar 2005 11:16:28 +0000 (GMT) Message-ID: <001501c52559$dbfc76c0$0601a8c0@pc6> From: "Tom Petch" To: "Sandy Murphy" , References: <200503081855.j28ItQ9a013547@tislabs.com> Subject: Re: [RPSEC] issue: coverage Date: Thu, 10 Mar 2005 11:11:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit I am responsible for several of the posts on this so I will respond now. Omitting all these extensions is fine by me but: - I would expect protests at the IESG/AD level that we are excluding IPv6; my impresssion is that such behaviour is politically incorrect. - I would expect operator protests at the exclusion of communities (eg RFC 3765, RFC 1997) since I believe they are often used to effect policy of the kind that has been much discussed on this list. I agree about the lack of consensus over this. Tom Petch ----- Original Message ----- From: "Sandy Murphy" To: Cc: Sent: Tuesday, March 08, 2005 7:55 PM Subject: [RPSEC] issue: coverage > There have been a few messages from people saying that the draft > should indicate what it is going to cover and suggesting that it must > cover lots of BGP features that aren't in the base spec. The list > included: > > communities > confederations > VPN's > MPLS > flap dampening > route reflectors > MBGP > > > The draft as written won't cover these. I can see no discussion on > the list of coming to consensus of what is to be covered and what not. > > I see the point of those who say that the other features (which are > carried in the protocol) must be covered in the security requirements. > If the security requirements should happen to disable one of these > features, that would not be a good thing. OTOH, I also heartily > endorse Bill's comment about the inclusion of all these features > representing a full employment act for BGP security folks. > > So what's the consensus? Base spec, Base spec with a best-effort eye > to avoid preventing use of other extensions, or base spec plus all > spec'd extensions? > > --Sandy > > > > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Mar 10 07:57:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10235 for ; Thu, 10 Mar 2005 07:57:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9NGh-0006KQ-OV for rpsec-web-archive@ietf.org; Thu, 10 Mar 2005 07:59:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9NCB-00012v-UQ; Thu, 10 Mar 2005 07:55:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9NCA-00012q-J0 for rpsec@megatron.ietf.org; Thu, 10 Mar 2005 07:55:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10015 for ; Thu, 10 Mar 2005 07:55:17 -0500 (EST) Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9NEx-0006HY-IW for rpsec@ietf.org; Thu, 10 Mar 2005 07:58:12 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j2ACpeUq025581 for ; Thu, 10 Mar 2005 07:51:40 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAArfaG9X; Thu, 10 Mar 05 07:51:37 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j2ACrMVK017890; Thu, 10 Mar 2005 07:53:22 -0500 (EST) Date: Thu, 10 Mar 2005 07:53:22 -0500 (EST) From: Sandy Murphy Message-Id: <200503101253.j2ACrMVK017890@tislabs.com> To: nwnetworks@dial.pipex.com, rpsec@ietf.org, sandy@tislabs.com Subject: Re: [RPSEC] issue: coverage X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab >- I would expect protests at the IESG/AD level that we are excluding IPv6; my >impresssion is that such behaviour is politically incorrect. Hm. You know, I don't know that the requirements as written would not apply to IPv6 as well. So we may be covered there, anyway. >- I would expect operator protests at the exclusion of communities (eg RFC 3765,>RFC 1997) since I believe they are often used to effect policy of the kind that >has been much discussed on this list. Yep. I believe that the requirements as written do not address protection of communities, as it says that all other (than AS_PATH) are of local concern only. As I noted in the "issue: attributes" thread, this may not be true. And frankly, I don't quite know what to do about communities. Some are transitive, some are mutable, those that are transitive AND mutable would be tough to secure, etc. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Mar 10 08:23:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12957 for ; Thu, 10 Mar 2005 08:23:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Nfy-0007nw-RP for rpsec-web-archive@ietf.org; Thu, 10 Mar 2005 08:26:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Nch-0004Sv-Oi; Thu, 10 Mar 2005 08:22:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Ncg-0004Sm-QG for rpsec@megatron.ietf.org; Thu, 10 Mar 2005 08:22:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12918 for ; Thu, 10 Mar 2005 08:22:41 -0500 (EST) Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9NfU-0007nF-V6 for rpsec@ietf.org; Thu, 10 Mar 2005 08:25:37 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j2ADJ5BP028157 for ; Thu, 10 Mar 2005 08:19:05 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAG0a4_2; Thu, 10 Mar 05 08:19:02 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j2ADKmpb018633; Thu, 10 Mar 2005 08:20:48 -0500 (EST) Date: Thu, 10 Mar 2005 08:20:48 -0500 (EST) From: Sandy Murphy Message-Id: <200503101320.j2ADKmpb018633@tislabs.com> To: guy@gblx.net, steve@telecomplete.co.uk Subject: Re: [RPSEC] issue: operator use X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c > I dont think the spec is the right place to regulate it tho, there are reasons >why someone might prepend an asn other than the one the bgp process is running >under that is not the asn of another company's network I can't tell if you are saying that you might prepend an ASN that no other company is using or that you might prepend an ASN that belongs to your company but just doesn't happen to be the ASN under which the BGP process is running (i.e., you have more than one). --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Mar 10 09:10:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17639 for ; Thu, 10 Mar 2005 09:10:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9OPZ-0001pA-U3 for rpsec-web-archive@ietf.org; Thu, 10 Mar 2005 09:13:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9OL2-0000zi-5N; Thu, 10 Mar 2005 09:08:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9OKz-0000zd-N7 for rpsec@megatron.ietf.org; Thu, 10 Mar 2005 09:08:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17474 for ; Thu, 10 Mar 2005 09:08:27 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9ONo-0001hu-75 for rpsec@ietf.org; Thu, 10 Mar 2005 09:11:24 -0500 Received: from [128.33.244.251] (col-dhcp33-244-251.bbn.com [128.33.244.251]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j2AE8AkJ015568; Thu, 10 Mar 2005 09:08:11 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200503091636.j29GaWnn018776@tislabs.com> Date: Thu, 10 Mar 2005 09:08:13 -0500 To: Guy Tal From: Stephen Kent Subject: Re: [RPSEC] issue: operator use Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 At 12:08 PM -0500 3/9/05, Guy Tal wrote: > I wanted to chime in on the prepending issue. IMHO, one should >*not* be able to prepend any AS other than the network AS one controls. >It's called an Autonomous System for a reason. Simply put, If you do not >control a router in an AS, you should not be able to add that AS in the >AS_PATH. To add another network's AS that you don't control is similar to >stealing or slander in my book. There are ways to accomplish route >preference other than manipulating AS_PATH. > On a similar note, I've talked with two customers of GX's that >have built a business model around gathering small customers, aggregating >them, then announcing all those routes sans AS to make it appear for the >customers that they are direct customers of us or anyone else the >middleman AS is connected to. Do these guys need to come up with a new >business model? Or will there be provisions for a model like this? > >Guy Guy, I think an essential part of any BGP security solution will be a facility that enables each prefix holder to authorize one or more ASes to originate the prefixes of that holder. With such a facility in place, it would be OK for your customers to authorize you to originate their prefixes. This accommodates the business model you described, yet it prevents any AS that the prefix holders did not authorized from being able to originate the prefixes, without detection. I think this is a reasonable candidate for inclusion in the list of requirements. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Mar 10 11:01:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28647 for ; Thu, 10 Mar 2005 11:01:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Q9F-0007AP-68 for rpsec-web-archive@ietf.org; Thu, 10 Mar 2005 11:04:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Q5J-0006ed-Og; Thu, 10 Mar 2005 11:00:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Q5I-0006eX-Pe for rpsec@megatron.ietf.org; Thu, 10 Mar 2005 11:00:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28550 for ; Thu, 10 Mar 2005 11:00:22 -0500 (EST) Received: from smtp1.phx.gblx.net ([64.208.25.103]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Q88-00074Z-3p for rpsec@ietf.org; Thu, 10 Mar 2005 11:03:20 -0500 Received: (from daemon@localhost) by smtp1.phx.gblx.net (8.11.2/8.11.2) id j2AG0M423489; Thu, 10 Mar 2005 09:00:22 -0700 (MST) Received: from shell1.phx.gblx.net(64.208.25.102) via SMTP by smtp1.phx.gblx.net, id smtpdAAAwJa42T; Thu Mar 10 09:00:20 2005 Received: from localhost (guy@localhost) by shell1.phx.gblx.net (8.9.3+Sun/8.9.3) with ESMTP id JAA05186; Thu, 10 Mar 2005 09:00:16 -0700 (MST) X-Authentication-Warning: shell1.phx.gblx.net: guy owned process doing -bs Date: Thu, 10 Mar 2005 11:00:16 -0500 (EST) From: Guy Tal X-X-Sender: guy@shell1.phx.gblx.net To: Stephen Kent Subject: Re: [RPSEC] issue: operator use In-Reply-To: Message-ID: References: <200503091636.j29GaWnn018776@tislabs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 On Thu, 10 Mar 2005, Stephen Kent wrote: > >have built a business model around gathering small customers, aggregating > >them, then announcing all those routes sans AS to make it appear for the > >customers that they are direct customers of us or anyone else the > >middleman AS is connected to. Do these guys need to come up with a new > >business model? Or will there be provisions for a model like this? > > > >Guy > > Guy, > > I think an essential part of any BGP security solution will be a > facility that enables each prefix holder to authorize one or more > ASes to originate the prefixes of that holder. With such a facility > in place, it would be OK for your customers to authorize you to > originate their prefixes. This accommodates the business model you > described, yet it prevents any AS that the prefix holders did not > authorized from being able to originate the prefixes, without > detection. I think this is a reasonable candidate for inclusion in > the list of requirements. > > Steve Well, the business model I'm describing is a little different than what you had made a provision for. Let me give a little more detail... ASN X has a route-server that gets a feed of NLRIs from multiple tier1s. They allow smaller networks that are colocated in the same building in which they have facilities to purchase transit to one, two, or all of those tier1s on a monthly basis. They announce to the smaller networks the tier1 routes without prepending their AS. (This is not as big of a concern because this is essentially going to stub networks). They also announce to the tier1s the routes from the smaller networks, also without prepending their AS. This is where I had my concern. The rest of the internet sees these smaller customers as direct customers of whatever tier1 they purchase transit from. The origin AS is still there, the tier1 is not originating the route for them. The middleman ASN is the only one that is not in the path. I feel that this will not jive with as_path security that is being discussed here. And because this is a service provided for short amount of times, I'm not sure what kind of administrative hassle it will be to have to register and unregister routes and ASNs, etc. I actually am not a fan of this model, but since it's out there, if what we're working on here will break it, I'd like to let those networks know that its coming down the pipe when something more concrete comes out. Guy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Mar 10 11:43:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04015 for ; Thu, 10 Mar 2005 11:43:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Qo3-00015S-D3 for rpsec-web-archive@ietf.org; Thu, 10 Mar 2005 11:46:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9QjZ-0005UQ-St; Thu, 10 Mar 2005 11:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9QjY-0005UI-Ev for rpsec@megatron.ietf.org; Thu, 10 Mar 2005 11:42:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03662 for ; Thu, 10 Mar 2005 11:41:57 -0500 (EST) Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9QmN-0000un-80 for rpsec@ietf.org; Thu, 10 Mar 2005 11:44:56 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j2AGcKwn015156 for ; Thu, 10 Mar 2005 11:38:20 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAVHa4LD; Thu, 10 Mar 05 11:38:18 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j2AGe1Ko024560; Thu, 10 Mar 2005 11:40:01 -0500 (EST) Date: Thu, 10 Mar 2005 11:40:01 -0500 (EST) From: Sandy Murphy Message-Id: <200503101640.j2AGe1Ko024560@tislabs.com> To: guy@gblx.net, kent@bbn.com Subject: Re: [RPSEC] issue: operator use X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 >>have built a business model around gathering small customers, aggregating >>them, then announcing all those routes sans AS to make it appear for the >>customers that they are direct customers of us or anyone else the >>middleman AS is connected to. Do these guys need to come up with a new >>business model? Or will there be provisions for a model like this? >> >>Guy > >Guy, > >I think an essential part of any BGP security solution will be a >facility that enables each prefix holder to authorize one or more >ASes to originate the prefixes of that holder. With such a facility >in place, it would be OK for your customers to authorize you to >originate their prefixes. This accommodates the business model you >described, yet it prevents any AS that the prefix holders did not >authorized from being able to originate the prefixes, without >detection. This presumes that GX's aggregating customer is telling their clients who they might be served through. The client has to sign an authorization for "anyone else the middleman AS is connected to". On another point - one of the requirements in the draft says that your peer's AS has to be on the end of the AS_PATH you receive. That check would fail on the updates GS receives from its aggregating customer because the customer is explicitly leaving off its AS. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Mar 10 12:13:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07416 for ; Thu, 10 Mar 2005 12:13:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9RHA-0002pk-Oy for rpsec-web-archive@ietf.org; Thu, 10 Mar 2005 12:16:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9RDj-0004Kb-QR; Thu, 10 Mar 2005 12:13:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9RDi-0004KJ-Ml for rpsec@megatron.ietf.org; Thu, 10 Mar 2005 12:13:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07232 for ; Thu, 10 Mar 2005 12:13:07 -0500 (EST) Received: from rimp1.nist.gov ([129.6.16.226] helo=smtp.nist.gov) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9RGX-0002nB-Lj for rpsec@ietf.org; Thu, 10 Mar 2005 12:16:07 -0500 Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j2AHC3aP028388; Thu, 10 Mar 2005 12:12:05 -0500 Received: from [127.0.0.1] ([129.6.220.22]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j2AHBMEY018261; Thu, 10 Mar 2005 12:11:23 -0500 (EST) Message-ID: <42307FB9.4070202@nist.gov> Date: Thu, 10 Mar 2005 12:11:21 -0500 From: Doug Montgomery Organization: http://www.antd.nist.gov/ User-Agent: Mozilla Thunderbird 1.0 (Windows/20050209) X-Accept-Language: en-us, en MIME-Version: 1.0 To: rpsec@ietf.org Subject: Re: [RPSEC] issue: operator use References: <200503101640.j2AGe1Ko024560@tislabs.com> In-Reply-To: <200503101640.j2AGe1Ko024560@tislabs.com> X-Enigmail-Version: 0.90.1.1 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-MailScanner-From: dougm@nist.gov X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit In a GROW discussion (on another topic) it sounds as if prepending other ASes for the purpose of effecting downstream distribution policy (i.e., poisoning) is a common "technique". While one may want to detect malicious uses of this technique (maybe all uses are malicious is some AS's view ;^) it would seem that any technique that would allow one to verify who added what to the PATH, would also potentially invalidate this technique. Not clear if this is good or bad ... but just something to keep in mind in this discussion. dougm _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Mar 10 12:49:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11104 for ; Thu, 10 Mar 2005 12:49:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Rpm-0004hg-Nr for rpsec-web-archive@ietf.org; Thu, 10 Mar 2005 12:52:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Rl9-00057w-IG; Thu, 10 Mar 2005 12:47:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Rl8-00057r-GI for rpsec@megatron.ietf.org; Thu, 10 Mar 2005 12:47:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10856 for ; Thu, 10 Mar 2005 12:47:39 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Rny-0004aM-Vv for rpsec@ietf.org; Thu, 10 Mar 2005 12:50:39 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 10 Mar 2005 13:04:03 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,154,1107752400"; d="scan'208"; a="40010834:sNHT20613820" Received: from russpc.Whitehouse.intra (rtp-vpn3-467.cisco.com [10.82.217.213]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2AHlUjJ018747; Thu, 10 Mar 2005 12:47:31 -0500 (EST) Date: Thu, 10 Mar 2005 12:46:49 -0500 (Eastern Standard Time) From: Russ White To: Stephen Kent Subject: Re: [RPSEC] issue: ASPATH In-Reply-To: Message-ID: References: <200503081857.j28IvQv1013627@tislabs.com> X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: rpsec@ietf.org, Sandy Murphy X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d >> Do we have a mechanism in mind to inform everyone whether the path will >> carry traffic? Should we specify one? > > you raise a very good point, i.e., the current version of the document > refers to existence of links but fails to define the reference basis for > this, nor does it say why mere existence of a link is the right sort of > check to make. BGP sends UPDATEs as the means of advertising, in a > directional fashion, precisely what traffic each AS is soliciting via a > specific link. Policy is separate from existence. Although the _intent_ of advertising information, with an attached AS Path, is to draw traffic, you _cannot_ infer from that information that every possible address or set of addresses listed in the information is actually reachable, through policy or in fact, through the AS Path listed. Some parts may be, other parts may not be, there's no way to gather this information from the update itself. The _only_ way to infer this information is to attach a policy outside the information in the update (or to ban aggregation from the Internet as a whole). >> If not, then I think it should be explicitly noted that this >> test does not absolutely ensure that the AS_PATH is now or >> ever has been set up to pass the traffic. > > right, which raises questions as to why we consider a crude topology > representation of this sort is an appropriate reference for AS_PATH > validity checking. See above.... >> I ran across this one, I think on NANOG: >> >> major ISP major ISP >> west coast ----------------------------east coast >> | | >> | | >> \--big national multi-homed customer--/ >> >> Major ISP has an outage on the cross continent link and starts routing >> traffic through the customer's network. (Charging double to boot, >> according to the message - once on the down-link and once on the >> up-link.) >> >> I do not believe that the validity test would declare this an invalid >> path. Should it? It is a _valid_ path, in that traffic could flow across the path in question. It is out of policy for traffic to flow across this link, which is another problem altogether. The problem is we forget to separate the concept of the logical graph across which traffic could flow from that of the actual path someone is "authorized" to use to pass that traffic. We face this problem all the time in routing--traffic engineering and multitopology routing are possible examples among many. Further, what do you do about finer granularity policies? For instance, perhaps the customer has, beforehand, stated they will allow some types of traffic across their network, but not others. Would the mere precesnce of an update stating "this path exists" be able to express these sorts of policies? :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Mar 10 12:51:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11278 for ; Thu, 10 Mar 2005 12:51:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9RrI-0004jt-Vu for rpsec-web-archive@ietf.org; Thu, 10 Mar 2005 12:54:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Rim-00052Q-Um; Thu, 10 Mar 2005 12:45:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Rik-00052J-UL for rpsec@megatron.ietf.org; Thu, 10 Mar 2005 12:45:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10640 for ; Thu, 10 Mar 2005 12:45:11 -0500 (EST) Received: from smtp1.phx.gblx.net ([64.208.25.103]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Rla-0004XL-39 for rpsec@ietf.org; Thu, 10 Mar 2005 12:48:11 -0500 Received: (from daemon@localhost) by smtp1.phx.gblx.net (8.11.2/8.11.2) id j2AHjBq09984; Thu, 10 Mar 2005 10:45:11 -0700 (MST) Received: from shell1.phx.gblx.net(64.208.25.102) via SMTP by smtp1.phx.gblx.net, id smtpdAAAQjaWEt; Thu Mar 10 10:45:10 2005 Received: from localhost (guy@localhost) by shell1.phx.gblx.net (8.9.3+Sun/8.9.3) with ESMTP id KAA07416; Thu, 10 Mar 2005 10:45:05 -0700 (MST) X-Authentication-Warning: shell1.phx.gblx.net: guy owned process doing -bs Date: Thu, 10 Mar 2005 12:45:05 -0500 (EST) From: Guy Tal X-X-Sender: guy@shell1.phx.gblx.net To: Sandy Murphy Subject: Re: [RPSEC] issue: operator use In-Reply-To: <200503101640.j2AGe1Ko024560@tislabs.com> Message-ID: References: <200503101640.j2AGe1Ko024560@tislabs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: rpsec@ietf.org, kent@bbn.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 On Thu, 10 Mar 2005, Sandy Murphy wrote: > >>have built a business model around gathering small customers, aggregating > >>them, then announcing all those routes sans AS to make it appear for the > >>customers that they are direct customers of us or anyone else the > >>middleman AS is connected to. Do these guys need to come up with a new > >>business model? Or will there be provisions for a model like this? > >> > >>Guy > > > >Guy, > > > >I think an essential part of any BGP security solution will be a > >facility that enables each prefix holder to authorize one or more > >ASes to originate the prefixes of that holder. With such a facility > >in place, it would be OK for your customers to authorize you to > >originate their prefixes. This accommodates the business model you > >described, yet it prevents any AS that the prefix holders did not > >authorized from being able to originate the prefixes, without > >detection. > > This presumes that GX's aggregating customer is telling their clients > who they might be served through. The client has to sign an authorization > for "anyone else the middleman AS is connected to". Correct, the end customer can sign up to receive just GX routes, just UU routes, whatever they want. > On another point - one of the requirements in the draft says that > your peer's AS has to be on the end of the AS_PATH you receive. > That check would fail on the updates GS receives from its > aggregating customer because the customer is explicitly > leaving off its AS. Right. So just to be clear, this draft is basically requiring, among other things, that enforce-first-AS be actually enforced, correct? Guy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Mar 10 12:53:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11542 for ; Thu, 10 Mar 2005 12:53:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Rtg-0004sP-Ol for rpsec-web-archive@ietf.org; Thu, 10 Mar 2005 12:56:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Rqj-00069p-C7; Thu, 10 Mar 2005 12:53:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Rqh-00069k-Ro for rpsec@megatron.ietf.org; Thu, 10 Mar 2005 12:53:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11510 for ; Thu, 10 Mar 2005 12:53:24 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9RtX-0004rz-60 for rpsec@ietf.org; Thu, 10 Mar 2005 12:56:24 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 10 Mar 2005 12:53:18 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn3-467.cisco.com [10.82.217.213]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2AHrE1k027469; Thu, 10 Mar 2005 12:53:15 -0500 (EST) Date: Thu, 10 Mar 2005 12:52:33 -0500 (Eastern Standard Time) From: Russ White To: Stephen Kent Subject: Re: [RPSEC] issue: ASPATH In-Reply-To: Message-ID: References: <200503082044.j28KilAs017341@tislabs.com> X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: rpsec@ietf.org, Sandy Murphy X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 > What we are discussing is how different is the graph one gets from > looking at AS connectivity as defined in a prefix-constrained fashion, > vs. non-directional, prefix-free graph. I have done this comparison, > using RV data, and there is a world of difference. If this data is > representative, then the number of paths that would pass the simple > connectivity test, vs. reality (as expressed via propagated routes) is > enormous. Can you provide an example of this? Such an example would have to: -- Be permanent (not transient). -- Not disobey the other requirements already given (that each router on an eBGP edge rejects all routes without the configured peer's AS in the most recent spot of the AS Path). -- Direct traffic that doesn't already (in theory, at least), flow through the attacking AS? I don't know of any such situations. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Mar 10 13:30:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15385 for ; Thu, 10 Mar 2005 13:30:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9STZ-0006oF-6E for rpsec-web-archive@ietf.org; Thu, 10 Mar 2005 13:33:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9SOT-0002ri-Q9; Thu, 10 Mar 2005 13:28:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9SOS-0002rd-DO for rpsec@megatron.ietf.org; Thu, 10 Mar 2005 13:28:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15258 for ; Thu, 10 Mar 2005 13:28:17 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9SRH-0006dW-Tw for rpsec@ietf.org; Thu, 10 Mar 2005 13:31:17 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 10 Mar 2005 13:44:32 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,154,1107752400"; d="scan'208"; a="40017661:sNHT1308448572" Received: from russpc.Whitehouse.intra (rtp-vpn3-467.cisco.com [10.82.217.213]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2AIRwjJ000081; Thu, 10 Mar 2005 13:27:59 -0500 (EST) Date: Thu, 10 Mar 2005 13:27:17 -0500 (Eastern Standard Time) From: Russ White To: Sandy Murphy Subject: Re: [RPSEC] issue: coverage In-Reply-To: <200503101253.j2ACrMVK017890@tislabs.com> Message-ID: References: <200503101253.j2ACrMVK017890@tislabs.com> X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: rpsec@ietf.org, nwnetworks@dial.pipex.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 > Hm. You know, I don't know that the requirements as written would not > apply to IPv6 as well. So we may be covered there, anyway. > >> - I would expect operator protests at the exclusion of communities (eg >> RFC 3765,>RFC 1997) since I believe they are often used to effect policy >> of the kind that has been much discussed on this list. > > Yep. I believe that the requirements as written do not address > protection of communities, as it says that all other (than AS_PATH) are > of local concern only. As I noted in the "issue: attributes" thread, > this may not be true. And frankly, I don't quite know what to do about > communities. Some are transitive, some are mutable, those that are > transitive AND mutable would be tough to secure, etc. It's actually worse than this, I'm afraid.... :-( So, I was thinking about the problems you raised in Minneapolis, and specifically communities and the next hop. I don't actually how you could go about protecting either of these. I'll try and deal with the next hop problem in another email, since this one is too long already for most people to read! :-) Suppose you take the simple case: NO_EXPORT, in this little network: B---C---D | | A---A' Now, suppose: -- A advertises some route to B. -- B and C are under contract to A to transit traffic from A to A', but A doesn't even want D to know about this relationship, for whatever reason. Now, suppose A marks the route it advertises to B with a community so B marks the route NO_EXPORT towards C. But, through some problem, or malicious intent, C actually advertises the route to D. Now, suppose we postulate some way to "secure" communities so C actually can't strip the NO_EXPORT community off. What should D take from receiving an update on which B has marked NO_EXPORT? That it shouldn't have received the update, and should therefore discard it? Isn't that a bit like the useless signatures on emails saying: "If you don't think you should have received this information, please discard it without receiving it," which happens to be conveniently placed at the end of the email?? Essentially, all of A's trust is in B and C to do the right thing. The actual routing information isn't encrypted (and couldn't be, in order to be useful), so there's no way to prevent someone from gaining knowledge of the actual available routes through just about any means. BGP isn't designed to provide secrecy of routing information, just to provide a set of loop free paths through the network, of which one is chosen for local policy reasons.... The enforcement falls to A, through it's contract with B and C, if it even discovers the problem existed in the first place. Another, even simpler, problem. RFC1998 provides a way for an AS to modify a peer's local preference through the use of communities. Now, suppose A and B are peers that have agreed, by contract, to honor these sorts of communities. A sends B some route with a community modifying B's local preference. B now needs to not only know A actually injected this information, but also it must be able to strip this information off the route, so those communities aren't passed on to its peers.... This is a very big tangle.... RFC3765, concepts of AS Path hop counts, and other things, all add to this, making it even more complicated to sort out what should be done here. Another part of the big tangle with policy is that we are diving into the traffic flow problem, again. A routing system provides loop free paths, and doesn't gaurentee traffic sent to the next hop advertising a given loop free path will actually follow the loop free path advertised. Once you dive into policy, you open up entire vistas of traffic flow problems I'm not certain we want to get in to (?). The simplest thing here might be to consider adding a bit more on policy, but severely limiting the discussion to some very basic considerations. For instance, it might be useful to state: -- Any proposed solution should allow an operator to express a specific autonomous system is not to be transited when forwarding traffic to a specific destination. This requirement is made with the assumption that there is no viable way to prove traffic will, or will not, flow along a specific path in an internetwork, but rather is an expression of common policy mechanisms in use today. There are a number of ways you could provide for this requirement, if the system designer chose to do so. And, it would avoid all the pitfalls of actually trying to "secure" communities, by stating what the communities tend to try and get at in terms of policy. Thoughts? :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Mar 10 13:42:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16213 for ; Thu, 10 Mar 2005 13:42:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9SfG-0007Ld-41 for rpsec-web-archive@ietf.org; Thu, 10 Mar 2005 13:45:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9ScC-0004fc-R5; Thu, 10 Mar 2005 13:42:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9ScB-0004fX-0L for rpsec@megatron.ietf.org; Thu, 10 Mar 2005 13:42:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16190 for ; Thu, 10 Mar 2005 13:42:27 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Sey-0007L5-TX for rpsec@ietf.org; Thu, 10 Mar 2005 13:45:28 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 10 Mar 2005 13:58:48 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,154,1107752400"; d="scan'208"; a="40019930:sNHT20421264" Received: from russpc.Whitehouse.intra (rtp-vpn3-467.cisco.com [10.82.217.213]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2AIgEjJ004085; Thu, 10 Mar 2005 13:42:15 -0500 (EST) Date: Thu, 10 Mar 2005 13:41:33 -0500 (Eastern Standard Time) From: Russ White To: Jeffrey Haas Subject: Re: [RPSEC] issue: operator use In-Reply-To: <20050309135149.GA17743@nexthop.com> Message-ID: References: <20050309135149.GA17743@nexthop.com> X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: rpsec@ietf.org, Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 >> There will probably be a lot of fight on the ability to prepend inbound >> and outbound. > > Only on inbound, I think. It wouldn't shock me if someone introduced a > mechanism that allows for biasing routes at a particular portion of the > route selection process. I believe John Scudder had suggested something > along these lines, although the mechanism was very broad. I don't think I know of anyone prepending inbound and then propagating the routes thus prepended.... (?) I know it might exist someplace, but I just don't know of any given case. The problem is, you don't know, from outside the AS, if the prepend was inbound or outbound, I think. For instance, Cisco now allows the prepending of your peer's as onto the path on the outbound side of your AS. For instance: A---B---C B can actually prepend A at it's border with C. There's a simple customer demand for this--A doesn't want to impact B's selection, or B's customers, but wants to impact the selection process beyond B. This is a slight variant of advertising your more specifics to B with NO_EXPORT, and your aggregate to B with no communities at all.... Anyway C can't tell if A or B actually did the prepending, and I don't know that C should or wants to care (?). >> Can we approach this from a different angle? What security problems would >> result in grouping AS's that are adjacent duplicates? It does not seem like >> it would be a hard problem to solve. > > As mentioned above, at least one security implication is you are > (negatively) biasing downstream route selection using the neighbor > AS rather than your own AS. But, that's the point Blaine's making--AS' that prepend are engineering the traffic flows on their inbound links. The problem we're running in to here is that we have to decide is engineering traffic is actually an attack or not. I suppose it could be in some circumstances, but it's not going to be in others, and it's going to be hard to tell the difference between the two, when all the players involved are legitimate. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Mar 10 13:50:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16696 for ; Thu, 10 Mar 2005 13:50:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Smh-0007dp-Sn for rpsec-web-archive@ietf.org; Thu, 10 Mar 2005 13:53:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9ShC-0005JD-UY; Thu, 10 Mar 2005 13:47:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Sh9-0005Iz-L8 for rpsec@megatron.ietf.org; Thu, 10 Mar 2005 13:47:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16575 for ; Thu, 10 Mar 2005 13:47:36 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Sk0-0007Vy-J6 for rpsec@ietf.org; Thu, 10 Mar 2005 13:50:36 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 10 Mar 2005 14:03:45 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,154,1107752400"; d="scan'208"; a="40020708:sNHT43947222064" Received: from russpc.Whitehouse.intra (rtp-vpn3-467.cisco.com [10.82.217.213]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2AIl9jJ005241; Thu, 10 Mar 2005 13:47:10 -0500 (EST) Date: Thu, 10 Mar 2005 13:46:28 -0500 (Eastern Standard Time) From: Russ White To: Guy Tal Subject: Re: [RPSEC] issue: operator use In-Reply-To: Message-ID: References: <200503101640.j2AGe1Ko024560@tislabs.com> X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: rpsec@ietf.org, kent@bbn.com, Sandy Murphy X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 >> On another point - one of the requirements in the draft says that your >> peer's AS has to be on the end of the AS_PATH you receive. That check >> would fail on the updates GS receives from its aggregating customer >> because the customer is explicitly leaving off its AS. > > Right. So just to be clear, this draft is basically requiring, among > other things, that enforce-first-AS be actually enforced, correct? Yes.... No security mechanism thus far proposed (S-BGP, soBGP, IRV, SPV, etc) will actually work without it.... It seems logically impossible to actually enforce any security at all if the AS of your peer isn't the AS they place in the path when they send an update to you. BTW, we do need exceptions to this rule for AS Transition situations, but I'm not certain how to actually word such exceptions, or if we could leave them as a "local matter," and thus, not worth worrying about (?).... We probably need some operator input on this. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Mar 10 13:51:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16887 for ; Thu, 10 Mar 2005 13:51:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Snx-0007lR-5l for rpsec-web-archive@ietf.org; Thu, 10 Mar 2005 13:54:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Sjp-0005ah-KE; Thu, 10 Mar 2005 13:50:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Sjn-0005aW-Me for rpsec@megatron.ietf.org; Thu, 10 Mar 2005 13:50:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16690 for ; Thu, 10 Mar 2005 13:50:20 -0500 (EST) Received: from dns2.nexthop.com ([65.247.36.217] helo=aa-mx2.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Smd-0007dc-H9 for rpsec@ietf.org; Thu, 10 Mar 2005 13:53:20 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx2.nexthop.com (Postfix) with ESMTP id BAEF84AC10; Thu, 10 Mar 2005 13:50:08 -0500 (EST) Received: from aa-mx2.nexthop.com ([127.0.0.1]) by localhost (aa-mx2.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 46741-02-72; Thu, 10 Mar 2005 13:50:05 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx2.nexthop.com (Postfix) with ESMTP id 936134AC01; Thu, 10 Mar 2005 13:50:05 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j2AIo5c22927; Thu, 10 Mar 2005 13:50:05 -0500 (EST) Date: Thu, 10 Mar 2005 13:50:05 -0500 From: Jeffrey Haas To: Russ White Subject: Re: [RPSEC] issue: operator use Message-ID: <20050310185004.GC22174@nexthop.com> References: <20050309135149.GA17743@nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: rpsec@ietf.org, Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 On Thu, Mar 10, 2005 at 01:41:33PM -0500, Russ White wrote: > I don't think I know of anyone prepending inbound and then propagating the > routes thus prepended.... (?) I know it might exist someplace, but I just > don't know of any given case. Ask around. If I'm getting asked to support it, someone else is already doing it. :-) > The problem is, you don't know, from outside the AS, if the prepend was > inbound or outbound, I think. 100% agreed. It's also not a problem from either a loop prevention basis nor a problem with checking AS adjacencies when no cryptographic mechanisms are using on the actual AS_PATH path attribute. If the actual AS_PATH is cryptographically signed in a stacked fashion, then we have a possible issue. Then again, giving it 10 seconds of thought, it's only a *possible* issue. Consider a theoretical signing mechanism where we have AS adjacencies A B C. If A advertises A A and B prepends on ingress A A but only advertises B, then you'll get A A A A B at C. The signature stack would look something roughly like: (A A (A A B)) So long as one can distinguish that B added the other A's, we could certainly permit this sort of thing when it doesn't break the adjacencies. (I.e. this doesn't break routing, and there's a way we could make this work if we wanted to.) > But, that's the point Blaine's making--AS' that prepend are engineering the > traffic flows on their inbound links. That's 1/2 of it. Prepending on egress engineers on incoming traffic. Prepending on ingress engineers on route selection within the AS and will further bias incoming traffic. > The problem we're running in to here > is that we have to decide is engineering traffic is actually an attack or > not. I suppose it could be in some circumstances, but it's not going to be > in others, and it's going to be hard to tell the difference between the > two, when all the players involved are legitimate. I'd agree. -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Mar 10 13:55:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17672 for ; Thu, 10 Mar 2005 13:55:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Srb-0007x5-L4 for rpsec-web-archive@ietf.org; Thu, 10 Mar 2005 13:58:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Smy-0006IS-2e; Thu, 10 Mar 2005 13:53:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Smw-0006HI-5k for rpsec@megatron.ietf.org; Thu, 10 Mar 2005 13:53:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17438 for ; Thu, 10 Mar 2005 13:53:35 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Spn-0007ph-9O for rpsec@ietf.org; Thu, 10 Mar 2005 13:56:35 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 10 Mar 2005 14:09:59 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,154,1107752400"; d="scan'208"; a="40021657:sNHT19953352" Received: from russpc.Whitehouse.intra (rtp-vpn3-467.cisco.com [10.82.217.213]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2AIrQjJ006711; Thu, 10 Mar 2005 13:53:26 -0500 (EST) Date: Thu, 10 Mar 2005 13:52:44 -0500 (Eastern Standard Time) From: Russ White To: Sandy Murphy Subject: Re: [RPSEC] issue: coverage In-Reply-To: <200503081855.j28ItQ9a013547@tislabs.com> Message-ID: References: <200503081855.j28ItQ9a013547@tislabs.com> X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 > confederations I don't see much we can do here, actually.... > VPN's > MPLS Well, MPLS is one specific case of a VPN. As long as VPNs stay within a single provider, we are fine here, because they essentially don't matter from the perspective of the work we're doing. However, when we get into multiprovider VPNs, we run against a brick wall.... :-( In most of these cases, we will find the customer's IGP cost carried as a community, which leads to the first case you mention, and the case I attempted to address in another email, basically as: "I don't have a clue how we can address this case." Further, there is a legitimate need to change some of the attributes associated with a VPNv4 route, either in the 2547 model, or the "biscuit" model (the current work with L2TP, GRE, and others, which, though I've not looked at it a lot, seems to be a generalization of 2547). For a specific instance, the customer might _want_ you to modify the IGP metrics they've dumped into BGP at the AS boundary. Another specific instance is that you need to be able to change the route target and identifier at the AS boundary, since you and the other AS may not have the same actual numbering systems, and such (?). > flap dampening This is local to a router, so is not an attribute. > route reflectors Again, local, and thus not an attribute. > MBGP MBGP attributes, policies, and etc, are similar to unicast and other AFI/SAFI's, so I don't think we need to worry much, here (?). I would think it's best to get some basic work done, and worry about this one later, if possible. I would say base spec + best effort, based on what the concensus is of what's important. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Mar 10 16:51:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11167 for ; Thu, 10 Mar 2005 16:51:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Vbe-0001Qz-Oh for rpsec-web-archive@ietf.org; Thu, 10 Mar 2005 16:54:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9VXF-0004Dz-IO; Thu, 10 Mar 2005 16:49:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9VXD-0004Cs-MU for rpsec@megatron.ietf.org; Thu, 10 Mar 2005 16:49:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11051 for ; Thu, 10 Mar 2005 16:49:32 -0500 (EST) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Va4-0001P4-EZ for rpsec@ietf.org; Thu, 10 Mar 2005 16:52:33 -0500 Received: from pc6 (1Cust151.tnt107.lnd4.gbr.da.uu.net [213.116.62.151]) by blaster.systems.pipex.net (Postfix) with SMTP id 0A723E000065; Thu, 10 Mar 2005 21:49:20 +0000 (GMT) Message-ID: <000401c525b2$4523aee0$0601a8c0@pc6> From: "Tom Petch" To: "Sandy Murphy" , References: <200503101253.j2ACrMVK017890@tislabs.com> Subject: Re: [RPSEC] issue: coverage IPv6 Date: Thu, 10 Mar 2005 21:40:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit What I am skirting around is that while BGP for IPv6 is similar in principle to that for IPv4, it is not the same. Perforce, it brings in Multi-Protocol and Capabilities, it brings in different packet formats, extra attributes, some new (still being discussed) concepts (address architecture). So including it (but not some of the other BGP options) means on the one hand, being precise about just which pieces of eg Multi-Protocol are included and on the other, making sure that all the wording covers two different sets of technical details. (As yet, I have put off reading the document with an IPv6 mindset to see if changes would be needed - there may be no changes but I think we would have to keep on remembering IPv6 is different in detail)). Can be done, but more easily done if we agree to do it from the start rather than try to retrofit it later. Tom Petch ----- Original Message ----- From: "Sandy Murphy" To: ; ; Sent: Thursday, March 10, 2005 1:53 PM Subject: Re: [RPSEC] issue: coverage > >- I would expect protests at the IESG/AD level that we are excluding IPv6; my > >impresssion is that such behaviour is politically incorrect. > > Hm. You know, I don't know that the requirements as written would > not apply to IPv6 as well. So we may be covered there, anyway. > > >- I would expect operator protests at the exclusion of communities (eg RFC 3765,>RFC 1997) since I believe they are often used to effect policy of the kind that > >has been much discussed on this list. > > Yep. I believe that the requirements as written do not address protection > of communities, as it says that all other (than AS_PATH) are of local > concern only. As I noted in the "issue: attributes" thread, this may not > be true. And frankly, I don't quite know what to do about communities. > Some are transitive, some are mutable, those that are transitive AND > mutable would be tough to secure, etc. > > --Sandy > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Mar 10 17:53:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16608 for ; Thu, 10 Mar 2005 17:53:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9WaA-0004R0-C4 for rpsec-web-archive@ietf.org; Thu, 10 Mar 2005 17:56:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9WX4-00050Y-8H; Thu, 10 Mar 2005 17:53:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9WX2-00050P-PR for rpsec@megatron.ietf.org; Thu, 10 Mar 2005 17:53:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16595 for ; Thu, 10 Mar 2005 17:53:25 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9WZu-0004Qg-Q9 for rpsec@ietf.org; Thu, 10 Mar 2005 17:56:28 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 10 Mar 2005 17:53:19 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn3-467.cisco.com [10.82.217.213]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2AMrEjJ012488; Thu, 10 Mar 2005 17:53:16 -0500 (EST) Date: Thu, 10 Mar 2005 17:52:33 -0500 (Eastern Standard Time) From: Russ White To: Tom Petch Subject: Re: [RPSEC] issue: coverage IPv6 In-Reply-To: <000401c525b2$4523aee0$0601a8c0@pc6> Message-ID: References: <200503101253.j2ACrMVK017890@tislabs.com> <000401c525b2$4523aee0$0601a8c0@pc6> X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: rpsec@ietf.org, Sandy Murphy X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 > What I am skirting around is that while BGP for IPv6 is similar in > principle to that for IPv4, it is not the same. Perforce, it brings in > Multi-Protocol That would be AFI/SAFI stuff, and should already be covered under what we're doing.... (?) > and Capabilities, Capabilities are between peers, and would be covered under any given system designed to protect peering sessions, I think. > it brings in different packet formats, Packet formats are probably outside our scope.... > extra attributes, Attributes are already under discussion. Can you tell us what new ones would be added? I've not seen any of the drafts, etc. > some new (still being discussed) concepts (address architecture). I'm not certain address architecture is relevant here, either.... (?) > So including it (but not some of the other BGP options) means on the one > hand, being precise about just which pieces of eg Multi-Protocol are > included and on the other, making sure that all the wording covers two > different sets of technical details. (As yet, I have put off reading the > document with an IPv6 mindset to see if changes would be needed - there > may be no changes but I think we would have to keep on remembering IPv6 > is different in detail)). It would be useful to know what changes you think would be required... :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Mar 10 22:19:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09109 for ; Thu, 10 Mar 2005 22:19:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9ajF-0000Cw-Nj for rpsec-web-archive@ietf.org; Thu, 10 Mar 2005 22:22:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9af5-0001zz-TR; Thu, 10 Mar 2005 22:18:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9af5-0001yo-21 for rpsec@megatron.ietf.org; Thu, 10 Mar 2005 22:18:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08977 for ; Thu, 10 Mar 2005 22:18:00 -0500 (EST) Received: from [128.33.0.62] (helo=aragorn.bbn.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9ai0-0008W1-J3 for rpsec@ietf.org; Thu, 10 Mar 2005 22:21:04 -0500 Received: from [10.84.130.185] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j2B3FXkL023318; Thu, 10 Mar 2005 22:15:35 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200503101253.j2ACrMVK017890@tislabs.com> Date: Thu, 10 Mar 2005 22:15:13 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] issue: coverage Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b At 1:27 PM -0500 3/10/05, Russ White wrote: >>Hm. You know, I don't know that the requirements as written would >>not apply to IPv6 as well. So we may be covered there, anyway. >> >>>- I would expect operator protests at the exclusion of communities >>>(eg RFC 3765,>RFC 1997) since I believe they are often used to >>>effect policy of the kind that has been much discussed on this >>>list. >> >>Yep. I believe that the requirements as written do not address >>protection of communities, as it says that all other (than AS_PATH) >>are of local concern only. As I noted in the "issue: attributes" >>thread, this may not be true. And frankly, I don't quite know what >>to do about communities. Some are transitive, some are mutable, >>those that are transitive AND mutable would be tough to secure, etc. > >It's actually worse than this, I'm afraid.... :-( > >So, I was thinking about the problems you raised in Minneapolis, and >specifically communities and the next hop. I don't actually how you >could go about protecting either of these. I'll try and deal with >the next hop problem in another email, since this one is too long >already for most people to read! :-) > >Suppose you take the simple case: NO_EXPORT, in this little network: > >B---C---D >| | >A---A' > >Now, suppose: > >-- A advertises some route to B. > >-- B and C are under contract to A to transit traffic from A to A', >but A doesn't even want D to know about this relationship, for >whatever reason. > >Now, suppose A marks the route it advertises to B with a community >so B marks the route NO_EXPORT towards C. But, through some problem, >or malicious intent, C actually advertises the route to D. > >Now, suppose we postulate some way to "secure" communities so C >actually can't strip the NO_EXPORT community off. What should D take >from receiving an update on which B has marked NO_EXPORT? That it >shouldn't have received the update, and should therefore discard it? >Isn't that a bit like the useless signatures on emails saying: "If >you don't think you should have received this information, please >discard it without receiving it," which happens to be conveniently >placed at the end of the email?? No, it isn't analogous. if one believes the goal of securing BGP is to provide each AS with info to enable the AS to determine if a received advertisement is legitimate, then the facility to which you allude does that. If D chooses to ignore the fact that it received an advertisement that was not destined for it, then what's the downside for anyone but D? It could always try to forward traffic that it was not solicited to forward, whether it receives an advertisement or not. The fact that it received an advertisement that it knows it was not supposed to receive allows D to make the right choice, i.e., ignore the advertisement, but does not compel D to do so. We can't compel any AS to do anything, > >Essentially, all of A's trust is in B and C to do the right thing. >The actual routing information isn't encrypted (and couldn't be, in >order to be useful), so there's no way to prevent someone from >gaining knowledge of the actual available routes through just about >any means. BGP isn't designed to provide secrecy of routing >information, just to provide a set of loop free paths through the >network, of which one is chosen for local policy reasons.... The >enforcement falls to A, through it's contract with B and C, if it >even discovers the problem existed in the first place. as noted above, this is not about preventing D from knowing anything. It is about giving D authentic info to enable it to make the right decision. Giving D the right info allows it to avoid making a mistake, as a result of an error or malicious intent by B. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Mar 10 22:19:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09127 for ; Thu, 10 Mar 2005 22:19:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9ajJ-0000D5-20 for rpsec-web-archive@ietf.org; Thu, 10 Mar 2005 22:22:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9aeq-0001xM-Jg; Thu, 10 Mar 2005 22:17:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9aep-0001xH-S6 for rpsec@megatron.ietf.org; Thu, 10 Mar 2005 22:17:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08901 for ; Thu, 10 Mar 2005 22:17:45 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9ahi-00005B-BN for rpsec@ietf.org; Thu, 10 Mar 2005 22:20:49 -0500 Received: from [10.84.130.185] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j2B3FXkN023318; Thu, 10 Mar 2005 22:15:37 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200503082044.j28KilAs017341@tislabs.com> Date: Thu, 10 Mar 2005 22:15:13 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] issue: ASPATH Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: rpsec@ietf.org, Sandy Murphy X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 At 12:52 PM -0500 3/10/05, Russ White wrote: >>What we are discussing is how different is the graph one gets from >>looking at AS connectivity as defined in a prefix-constrained >>fashion, vs. non-directional, prefix-free graph. I have done this >>comparison, using RV data, and there is a world of difference. If >>this data is representative, then the number of paths that would >>pass the simple connectivity test, vs. reality (as expressed via >>propagated routes) is enormous. > >Can you provide an example of this? Such an example would have to: > >-- Be permanent (not transient). > >-- Not disobey the other requirements already given (that each >router on an eBGP edge rejects all routes without the configured >peer's AS in the most recent spot of the AS Path). > >-- Direct traffic that doesn't already (in theory, at least), flow >through the attacking AS? > >I don't know of any such situations. There may be some confusion about what I said above, based on your questions, so I'll give some more details and you can see whether the questions still seem relevant. We examined RV data over various intervals, typically 30 days at a time. We constructed graphs based on different assumptions one can infer from the data, So, for example, if you see a route advertised by AS 1, for prefix A, and that path goes through AS 3, 17 and 9, then you can feel fairly confident that traffic destined to A and starting in AS 1 will traverse AS 3 and 17 en route to AS 9. (Whether AS 9 is the real origin AS is debatable, as we have seen.) However, the graph one gets from this data is pretty sparse relative to total Internet connectivity, because it reflects a tiny fraction of all ASes as origins. One has to extrapolate from that data considerably to try to fill in the blanks. Assuming that each AS along the path would route traffic for the same prefix the same ways helps a little, but still leaves lots of gaps. Ignoring the prefix specificity, e.g., assuming that all traffic destined to all prefixes advertised by the origin AS will follow the same path, also helps expand coverage. Finally, though, to get fairly broad coverage, one needs to ignore directionality, as well as prefix specificity. At that point you have a graph that largely ignores all of the policies that affect BGP route propagation. And, that graph does not show any private peering links. One can detect these links via analysis of skitter data, and comparing it to RV data, Siuch comparison suggests that a substantial fraction of all links are not advertised in BGP, to a broad set of ASes. What this suggests is that a graph that shows all links between ASes is very different from the much more constrained graph that reflects actual advertisements which, in turn, reflects policies, when ASes behave. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Mar 10 22:33:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10155 for ; Thu, 10 Mar 2005 22:33:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9awh-0000qp-Ss for rpsec-web-archive@ietf.org; Thu, 10 Mar 2005 22:36:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9arl-00054e-MZ; Thu, 10 Mar 2005 22:31:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9arl-00054Y-69 for rpsec@megatron.ietf.org; Thu, 10 Mar 2005 22:31:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09939 for ; Thu, 10 Mar 2005 22:31:06 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9auf-0000iu-ST for rpsec@ietf.org; Thu, 10 Mar 2005 22:34:11 -0500 Received: from [10.84.130.185] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j2B3UrkJ023628; Thu, 10 Mar 2005 22:30:55 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200503091636.j29GaWnn018776@tislabs.com> Date: Thu, 10 Mar 2005 22:30:56 -0500 To: Guy Tal From: Stephen Kent Subject: Re: [RPSEC] issue: operator use Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Guy, Thanks for the clarification. As you note, the advertisements sent to the subscribers are not an issue. any stub subscriber in this example has but one path to everywhere, through X, so BGP security is irrelevant to their routing decision. In the other direction, as Sandy noted, one could create a capability to nominate any AS, vs. a specified set of ASes, to originate one's prefix, if needed. But, if X fails to add it's AS # to the path when it originates an advertisement, then it seems to fail the basic, BGP test for verifying that X is the peer, a more serious problem.I If each subscriber authorized each tier 1 AS who they are paying to advertise its prefixes, then the model would work, and X would only have to act as an intermediary to collect the fees :-). After all, you said each subscriber chooses which tier 1's X will advertise the prefixes of the subscriber, so the subscribers know who to authorize. One also might try to create a secure, transitive, authorization to originate capability if one needs to mimic this operational model very closely. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Mar 11 05:25:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04447 for ; Fri, 11 Mar 2005 05:25:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9hNo-0002vw-9t for rpsec-web-archive@ietf.org; Fri, 11 Mar 2005 05:28:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9hIh-0000k0-27; Fri, 11 Mar 2005 05:23:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9hIU-0000iT-0W for rpsec@megatron.ietf.org; Fri, 11 Mar 2005 05:23:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04212 for ; Fri, 11 Mar 2005 05:23:07 -0500 (EST) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9hLQ-0002oe-SS for rpsec@ietf.org; Fri, 11 Mar 2005 05:26:15 -0500 Received: from pc6 (1Cust132.tnt105.lnd4.gbr.da.uu.net [213.116.58.132]) by astro.systems.pipex.net (Postfix) with SMTP id 729D7E000276; Fri, 11 Mar 2005 10:22:49 +0000 (GMT) Message-ID: <013101c5261b$88124b80$0601a8c0@pc6> From: "Tom Petch" To: "Russ White" References: <200503101253.j2ACrMVK017890@tislabs.com><000401c525b2$4523aee0$0601a8c0@pc6> Subject: Re: [RPSEC] issue: coverage IPv6 Date: Fri, 11 Mar 2005 10:18:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org, Sandy Murphy X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit I am nervous about being too specific about IPv6 because it is an area where I lurk rather than work:-) but as I see it:- RFC2858 defines Multiprotocol; from 2000, I see no activity to update it nor any need (unless IPv6 want to add anycast). It defines attributes 14 and 15 for other protocols NLRI, reachable and unreachable respectively RFC2545 defines IPv6 use thereof; from 1999, again I see no activity to update it but IPv6 has changed a lot since then (address architecture, role of routers) so it will need an update but only when IPv6 settles down again. As it stands, it preserves a 32 bit router id, allows IPv4 or IPv6 transport (think transport level security and that the TCP IP address can be IPv6 while router id is IPv4), uses attributes 14 and 15 and allows multiple next hops (link local, global unicast). As I said, different in technical detail. I know of no I-Ds in this area (I am on ipv6 and idr lists). So any reference to attributes or next hops sets my IPv6 antenna twitching. Tom Petch ----- Original Message ----- From: "Russ White" To: "Tom Petch" Cc: ; "Sandy Murphy" Sent: Thursday, March 10, 2005 11:52 PM Subject: Re: [RPSEC] issue: coverage IPv6 > > > What I am skirting around is that while BGP for IPv6 is similar in > > principle to that for IPv4, it is not the same. Perforce, it brings in > > Multi-Protocol > > That would be AFI/SAFI stuff, and should already be covered under what > we're doing.... (?) > > > and Capabilities, > > Capabilities are between peers, and would be covered under any given system > designed to protect peering sessions, I think. > > > it brings in different packet formats, > > Packet formats are probably outside our scope.... > > > extra attributes, > > Attributes are already under discussion. Can you tell us what new ones > would be added? I've not seen any of the drafts, etc. > > > some new (still being discussed) concepts (address architecture). > > I'm not certain address architecture is relevant here, either.... (?) > > > So including it (but not some of the other BGP options) means on the one > > hand, being precise about just which pieces of eg Multi-Protocol are > > included and on the other, making sure that all the wording covers two > > different sets of technical details. (As yet, I have put off reading the > > document with an IPv6 mindset to see if changes would be needed - there > > may be no changes but I think we would have to keep on remembering IPv6 > > is different in detail)). > > It would be useful to know what changes you think would be required... > > :-) > > Russ > _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Mar 11 10:46:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06139 for ; Fri, 11 Mar 2005 10:46:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9mOD-0001rX-6j for rpsec-web-archive@ietf.org; Fri, 11 Mar 2005 10:49:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9mKV-0000zF-DB; Fri, 11 Mar 2005 10:45:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9mKU-0000zA-4D for rpsec@megatron.ietf.org; Fri, 11 Mar 2005 10:45:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06081 for ; Fri, 11 Mar 2005 10:45:32 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9mNU-0001pX-Cg for rpsec@ietf.org; Fri, 11 Mar 2005 10:48:41 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j2BFj0N06844; Fri, 11 Mar 2005 16:45:00 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j2BFj0FA027883; Fri, 11 Mar 2005 16:45:00 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200503111545.j2BFj0FA027883@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tom Petch Subject: Re: [RPSEC] issue: coverage IPv6 In-reply-to: Your message of Fri, 11 Mar 2005 10:18:14 +0100. <013101c5261b$88124b80$0601a8c0@pc6> Date: Fri, 11 Mar 2005 16:45:00 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: rpsec@ietf.org, Sandy Murphy , Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 In your previous mail you wrote: RFC2858 defines Multiprotocol => note this is heavily used and in general not for IPv6 (:-). RFC2545 defines IPv6 use thereof => there were some proposals for link-local addresses only in special cases but IMHO in the context of RPSEC global addresses are required... So this IPv6 feature (narrow scope addresses) can be ignored and general considerations for IPv4 apply to IPv6 directly. I know of no I-Ds in this area (I am on ipv6 and idr lists). => I believe the proposals were phased out some years ago and as interconnection points (GIXs) can get dedicated global prefixes the main reason of these proposals no more exists too... So any reference to attributes or next hops sets my IPv6 antenna twitching. => as far as I know (and as one of the RFC 2545 authors I should be informed) there is no planned change to RFC 2545 for its progress to DS. Regards Francis.Dupont@enst-bretagne.fr PS: BTW to make specifications applicable to IPv4 and IPv6 is a good idea and in this case I can't see a reason to drop/forget IPv6... _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Mar 11 18:02:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15875 for ; Fri, 11 Mar 2005 18:02:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9tCn-0007TR-0y for rpsec-web-archive@ietf.org; Fri, 11 Mar 2005 18:06:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9t8s-0002Sq-8d; Fri, 11 Mar 2005 18:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9t8r-0002Si-B1 for rpsec@megatron.ietf.org; Fri, 11 Mar 2005 18:02:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15853 for ; Fri, 11 Mar 2005 18:01:59 -0500 (EST) Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9tBw-0007Sn-BO for rpsec@ietf.org; Fri, 11 Mar 2005 18:05:13 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j2BMwM48002933 for ; Fri, 11 Mar 2005 17:58:22 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAUoa4Tf; Fri, 11 Mar 05 17:58:20 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j2BN08tp014575 for rpsec@ietf.org; Fri, 11 Mar 2005 18:00:08 -0500 (EST) Date: Fri, 11 Mar 2005 18:00:08 -0500 (EST) From: Sandy Murphy Message-Id: <200503112300.j2BN08tp014575@tislabs.com> To: rpsec@ietf.org Subject: Re: [RPSEC] issue: coverage X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 >Policy is separate from existence. Although the _intent_ of advertising >information, with an attached AS Path, is to draw traffic, you _cannot_ >infer from that information that every possible address or set of addresses >listed in the information is actually reachable, through policy or in fact, >through the AS Path listed. Some parts may be, other parts may not be, >there's no way to gather this information from the update itself. I certainly know of specific cases where the traffic won't follow the same path: out-of-protocol: the routers don't forward along the path they advertised in-protocol: a router announces an aggregate with an AS_SET or re-originating private AS's are invisible in the path, so traffic goes places other than the places visible in the AS_PATH confederations are invisible in the path, so traffic goes places other than the places visible in the AS_PATH Are there other cases? I don't believe that the out-of-protocol case is a protocol security concern. {First, the protocol is not being used to make this happen. Second, there is nothing you can do in the protocol to prevent other changes being made to the forwarding table. Third, a router that mis-forwards can effect only that traffic that comes to it, where a router that mis-advertises can effect a lot of other routers' traffic.} If there are really only three in-protocol cases, then I don't think it is insurmountable to provide for those three cases in the protection of the AS_PATH. >A routing system provides loop free paths, and >doesn't gaurentee traffic sent to the next hop advertising a given loop >free path will actually follow the loop free path advertised. This is a broad statement and my questions above are pointed at seeing if this is an unnecessarily broad generalization of the specific cases noted above. And: I'm not sure that ensuring that traffic follows the advertised path is the way to state I'm hoping for. I want to ensure that each AS has indicated that it is willing to accept that traffic, so traffic can't be forced to go places that would be harmful. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Mar 11 18:07:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16629 for ; Fri, 11 Mar 2005 18:07:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9tHR-0007lE-Hh for rpsec-web-archive@ietf.org; Fri, 11 Mar 2005 18:10:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9tCH-0003Aa-PC; Fri, 11 Mar 2005 18:05:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9tCF-0003AN-VT for rpsec@megatron.ietf.org; Fri, 11 Mar 2005 18:05:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16291 for ; Fri, 11 Mar 2005 18:05:29 -0500 (EST) Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9tFL-0007cT-Sb for rpsec@ietf.org; Fri, 11 Mar 2005 18:08:44 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j2BN1sEb003213 for ; Fri, 11 Mar 2005 18:01:54 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAZOayrg; Fri, 11 Mar 05 18:01:50 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j2BN3dXs014683 for rpsec@ietf.org; Fri, 11 Mar 2005 18:03:39 -0500 (EST) Date: Fri, 11 Mar 2005 18:03:39 -0500 (EST) From: Sandy Murphy Message-Id: <200503112303.j2BN3dXs014683@tislabs.com> To: rpsec@ietf.org Subject: Re: [RPSEC] issue: coverage X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 I'm having trouble understanding your example, as the argument seems to contradict itself: You say: >-- B and C are under contract to A to transit traffic from A to A', but A >doesn't even want D to know about this relationship, for whatever reason. > >Now, suppose A marks the route it advertises to B with a community so B >marks the route NO_EXPORT towards C. But, through some problem, or >malicious intent, C actually advertises the route to D. > >... >What should D take from receiving >an update on which B has marked NO_EXPORT? That it shouldn't have received >the update, and should therefore discard it? then later you say: >BGP isn't designed to >provide secrecy of routing information So your example is showing our inability to provide a feature that we know BGP is designed to exclude. I'd say the answer is to gently inform A that it asked for the impossible. Then there's no *security* problem in D's seeing the update. OTOH If you changed your example to say that A didn't want D sending traffic it's way through B/C, then we could discuss whether the security requirements should say that AS's could state such a policy and expect a secure system to make it so. BGP is supposed to be able to represent an AS's desires of where traffic goes - such a requirement would not violate the BGP paradigm. But I'm not confident that we could fulfill such a requirement: >Essentially, all of A's trust is in B and C to do the right thing. Indeed, indeed, indeed. (Is three times enough?) It is a very hard thing to ensure that some other entity does the right thing. There are few cases I can think of where that is possible. There's a lot of work going on to try to prevent people who are allowed to see a document to forward it to someone who can't. Byzantine protocols try to ensure that a group comes to a right answer. And so forth. The solutions generally make assumptions about trusted computing bases or multiple parties that must agree to perform an action. In general, not easy solutions. One thing that we can ensure is that C can not deny that it leaked the route it wasn't supposed to. Non-repudiation can help. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Mar 11 18:26:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18633 for ; Fri, 11 Mar 2005 18:26:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9tZr-00005v-Np for rpsec-web-archive@ietf.org; Fri, 11 Mar 2005 18:29:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9tWS-0007Kt-TQ; Fri, 11 Mar 2005 18:26:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9tWR-0007Ko-2h for rpsec@megatron.ietf.org; Fri, 11 Mar 2005 18:26:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18607 for ; Fri, 11 Mar 2005 18:26:20 -0500 (EST) Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9tZX-000051-Au for rpsec@ietf.org; Fri, 11 Mar 2005 18:29:35 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j2BNMj6B005317 for ; Fri, 11 Mar 2005 18:22:45 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAYyayyk; Fri, 11 Mar 05 18:22:43 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j2BNOVZu015309 for rpsec@ietf.org; Fri, 11 Mar 2005 18:24:32 -0500 (EST) Date: Fri, 11 Mar 2005 18:24:32 -0500 (EST) From: Sandy Murphy Message-Id: <200503112324.j2BNOVZu015309@tislabs.com> To: rpsec@ietf.org Subject: Re: [RPSEC] issue: coverage X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 >The _only_ way to infer this information is to attach a policy outside the >information in the update (or to ban aggregation from the Internet as a >whole). So - should we be considering adding requirements about communicating policy to our list? (Wasn't there a suggestion once of a mechanism that did communicate policy around?) --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Mar 11 18:40:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19642 for ; Fri, 11 Mar 2005 18:40:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9tnB-0000jr-ND for rpsec-web-archive@ietf.org; Fri, 11 Mar 2005 18:43:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9tj1-0001uu-N2; Fri, 11 Mar 2005 18:39:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9tiz-0001up-J6 for rpsec@megatron.ietf.org; Fri, 11 Mar 2005 18:39:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19597 for ; Fri, 11 Mar 2005 18:39:19 -0500 (EST) Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9tm5-0000jP-Vy for rpsec@ietf.org; Fri, 11 Mar 2005 18:42:34 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j2BNZiol006388 for ; Fri, 11 Mar 2005 18:35:44 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAUGayEm; Fri, 11 Mar 05 18:35:41 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j2BNbUIU015629; Fri, 11 Mar 2005 18:37:30 -0500 (EST) Date: Fri, 11 Mar 2005 18:37:30 -0500 (EST) From: Sandy Murphy Message-Id: <200503112337.j2BNbUIU015629@tislabs.com> To: rpsec@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: sandy@tislabs.com Subject: [RPSEC] another example of peering topology check not catching X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Another example which the peering topology check doesn't catch (I think): B / \ / \ A C B is multi-homed and has been allocated a /24 address block. B advertises more specifics for part of that address block to A and more specifics for the rest to C. (Maybe it is load balancing, maybe there are performance advantages to C's connection for the specific application running on the addresses it sends to C, etc.) A advertises the more specifics it got from B *and* the rest of the more specifics as well, so it is advertising the entire /24 address space. This isn't really a case of needing to know B's policy in order to decide what A should have done. A is making an advertisement without having received an advertisement that would justify it or any indication that B is willing to accept the traffic that way. Note that the traffic will get there. And the traffic is following the announced AS_PATH. And the AS_PATH advertised will "correspond to a verifiable list of autonomous systems based on the peering topology of the network." But B is bound to be displeased, no? --Sandy P.S. On the other hand, if there was a way to check: > o Routing information carried through BGP SHOULD include information > that can be used to verify the readvertisement or modification by > each autonomous system through which the UPDATE has passed. Then A's mis-advertisement would be caught. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Mar 11 22:38:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09390 for ; Fri, 11 Mar 2005 22:38:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9xVp-0003KC-Ll for rpsec-web-archive@ietf.org; Fri, 11 Mar 2005 22:42:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9xRV-0003Jl-RR; Fri, 11 Mar 2005 22:37:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9xRV-0003Jg-61 for rpsec@megatron.ietf.org; Fri, 11 Mar 2005 22:37:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09305 for ; Fri, 11 Mar 2005 22:37:31 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9xUd-0003J4-IK for rpsec@ietf.org; Fri, 11 Mar 2005 22:40:47 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 11 Mar 2005 19:39:18 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,158,1107763200"; d="scan'208"; a="167002830:sNHT20626092" Received: from russpc.Whitehouse.intra (sjc-vpn6-568.cisco.com [10.21.122.56]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j2C3bATN014211; Fri, 11 Mar 2005 19:37:11 -0800 (PST) Date: Fri, 11 Mar 2005 22:36:28 -0500 (Eastern Standard Time) From: Russ White To: Sandy Murphy Subject: Re: [RPSEC] another example of peering topology check not catching In-Reply-To: <200503112337.j2BNbUIU015629@tislabs.com> Message-ID: References: <200503112337.j2BNbUIU015629@tislabs.com> X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 > Another example which the peering topology check doesn't catch (I think): > > > B > / \ > / \ > A C > > B is multi-homed and has been allocated a /24 address block. > B advertises more specifics for part of that address block to A and more > specifics for the rest to C. (Maybe it is load balancing, maybe there > are performance advantages to C's connection for the specific application > running on the addresses it sends to C, etc.) Let's make it more specific, say B advertises 10.1.1.0/25 to A, and 10.1.1.128/25 to C. > A advertises the more specifics it got from B *and* the rest of the more > specifics as well, so it is advertising the entire /24 address space. Yes, but, from a routing perspective, this is perfectly valid. The path exists, and is loop free. > This isn't really a case of needing to know B's policy in order to decide > what A should have done. A is making an advertisement without having > received an advertisement that would justify it or any indication that B > is willing to accept the traffic that way. Actually, it is policy. Routing finds loop free paths. Policy determines which of those loop free paths should, or should not, be used. If we delve into the policy arena in some places (like here), then we need a good reason not to delve into it in all the other places. In fact, I'll turn your example around a bit, and show how this is specifically a policy issue. Suppose B also advertises the /24 to both A and C. This is common enough, and smart, if you actually want your traffic to continue flowing when one of your two SP's fails. Now, for whatever reason, C decides not to readvertise the /25, but only the /24. What path is the traffic coming from beyond A and C going to take? Possibly A, correct? Isn't this also against B's policy? Yet, how would you address this? Now, _if_ I were going to address this as a requirement, I would do so with wording something like this: -- Any proposed security system SHOULD be able to express policies indicating a specific autonomous system should not be transited for any given destination. Note there is no way to gaurentee such a policy would be followed. Or something like that. We then need to justify why, exactly, we don't want to cover other policies that may come up when discussing other possible cases. > Note that the traffic will get there. And the traffic is following the > announced AS_PATH. And the AS_PATH advertised will "correspond to a > verifiable list of autonomous systems based on the peering topology of > the network." Precisely. Routing finds loop free paths. BGP also happens to allow the local application of policy, and possibly allows an AS to influence the policy of adjacent AS'. Those influences are not gaurenteed to "work." Sometimes they will, sometimes they won't. Once you have the route, it's your policy that counts, though you might be nice, and allow your neighbor's policy to influence you. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sat Mar 12 07:42:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02437 for ; Sat, 12 Mar 2005 07:42:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DA60G-0004TM-7p for rpsec-web-archive@ietf.org; Sat, 12 Mar 2005 07:46:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DA5un-0004C9-NI; Sat, 12 Mar 2005 07:40:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DA5um-0004C1-AC for rpsec@megatron.ietf.org; Sat, 12 Mar 2005 07:40:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02314 for ; Sat, 12 Mar 2005 07:40:19 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DA5xy-0004Pj-JV for rpsec@ietf.org; Sat, 12 Mar 2005 07:43:39 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 12 Mar 2005 07:56:59 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,158,1107752400"; d="scan'208"; a="40254086:sNHT19894604" Received: from russpc.Whitehouse.intra (rtp-vpn3-313.cisco.com [10.82.217.59]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2CCe71k011259; Sat, 12 Mar 2005 07:40:08 -0500 (EST) Date: Sat, 12 Mar 2005 07:39:29 -0500 (Eastern Standard Time) From: Russ White To: Sandy Murphy Subject: Re: [RPSEC] issue: coverage In-Reply-To: <200503112303.j2BN3dXs014683@tislabs.com> Message-ID: References: <200503112303.j2BN3dXs014683@tislabs.com> X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 > If you changed your example to say that A didn't want D sending traffic > it's way through B/C, then we could discuss whether the security > requirements should say that AS's could state such a policy and expect a > secure system to make it so. BGP is supposed to be able to represent an > AS's desires of where traffic goes - such a requirement would not violate > the BGP paradigm. Yes, we could.... I would suggest such language could be injected (I've suggested possible language below), but I'm not certain how to say: "This is the line over which we won't go when discussing policy." Perhaps it's valid to say we will put in requirements involving policy relating to the acceptability of a specific AS in terms of transit, but leave it at that (?). It seems like a logical place to draw the line, and I don't see how it could get us into trouble.... > But I'm not confident that we could fulfill such a requirement: Which is why I suggested the "but if" type statement in my wording: -- Any proposed security system SHOULD be able to express policies indicating a specific autonomous system should not be transited for any given destination. Note there is no way to gaurantee such a policy would be followed. Of course, I'm also not certain it should be a MUST or a SHOULD, if we placed this in the draft--I'm fine with it either way, I'll leave it to others to speak their minds... :-) I'm also certain the wording could use a little help.... > One thing that we can ensure is that C can not deny that it leaked the > route it wasn't supposed to. Non-repudiation can help. Non-repudiation is already in as a "SHOULD," so I think we've already covered that (though not using that specific term, since it's a term with a lot of baggage). I wouldn't want to make it a "MUST," for two reasons: -- I don't know that it can be proven in relation to the AS Path, specifically. -- I don't know what the total set of tradeoffs are in providing non-repudiation, and believe the users of any given system should be allowed to determine the actual tradeoffs based on deployment considerations. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Mar 14 08:10:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25583 for ; Mon, 14 Mar 2005 08:10:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DApP5-0000TK-VL for rpsec-web-archive@ietf.org; Mon, 14 Mar 2005 08:14:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DApAI-00067c-0P; Mon, 14 Mar 2005 07:59:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DApAG-00067S-2E for rpsec@megatron.ietf.org; Mon, 14 Mar 2005 07:59:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24218 for ; Mon, 14 Mar 2005 07:59:18 -0500 (EST) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DApDs-0008Il-Dd for rpsec@ietf.org; Mon, 14 Mar 2005 08:03:04 -0500 Received: from pc6 (1Cust30.tnt102.lnd4.gbr.da.uu.net [213.116.52.30]) by galaxy.systems.pipex.net (Postfix) with SMTP id EDD8AE00032E; Mon, 14 Mar 2005 12:59:05 +0000 (GMT) Message-ID: <013c01c5288c$d732f2a0$0601a8c0@pc6> From: "Tom Petch" To: "Russ White" References: <200503112337.j2BNbUIU015629@tislabs.com> Subject: Re: [RPSEC] another example of peering topology check not catching Date: Mon, 14 Mar 2005 12:54:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit > Now, _if_ I were going to address this as a requirement, I would do so with > wording something like this: > > -- Any proposed security system SHOULD be able to express policies > indicating a specific autonomous system should not be transited for any > given destination. Note there is no way to gaurentee such a policy would be > followed. > I don't see this as anything to do with security. If you said -- Any proposed routing system SHOULD be able to express policies ... I would agree with you but the problem here seems to me that BGP (as in I-D bgp4-26) cannot express the policies that operators want, so operators break that specification and stretch it beyond what seems reasonable. And now, you want a security system to sanction that:-) Sandy's Operator post listed some dubious practices with the question should security not stop them. The discussion has exposed more dubious practices but the question remains for me, should we not stop them, not should we enforce them. They remain dubious practices. Tom Petch _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Mar 14 08:53:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01562 for ; Mon, 14 Mar 2005 08:53:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAq4C-0002bO-OR for rpsec-web-archive@ietf.org; Mon, 14 Mar 2005 08:57:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DApzH-0000Eh-T8; Mon, 14 Mar 2005 08:52:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DApzC-0000Ea-FV for rpsec@megatron.ietf.org; Mon, 14 Mar 2005 08:51:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01447 for ; Mon, 14 Mar 2005 08:51:56 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAq2o-0002YR-SQ for rpsec@ietf.org; Mon, 14 Mar 2005 08:55:44 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 14 Mar 2005 08:51:49 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn3-535.cisco.com [10.82.218.26]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2EDpj1k018249; Mon, 14 Mar 2005 08:51:46 -0500 (EST) Date: Mon, 14 Mar 2005 08:51:03 -0500 (Eastern Standard Time) From: Russ White To: Tom Petch Subject: Re: [RPSEC] another example of peering topology check not catching In-Reply-To: <013c01c5288c$d732f2a0$0601a8c0@pc6> Message-ID: References: <200503112337.j2BNbUIU015629@tislabs.com> <013c01c5288c$d732f2a0$0601a8c0@pc6> X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 >> Now, _if_ I were going to address this as a requirement, I would do so with >> wording something like this: >> >> -- Any proposed security system SHOULD be able to express policies >> indicating a specific autonomous system should not be transited for any >> given destination. Note there is no way to gaurentee such a policy would be >> followed. >> > > I don't see this as anything to do with security. If you said > > -- Any proposed routing system SHOULD be able to express policies ... > > I would agree with you but the problem here seems to me that BGP (as in > I-D bgp4-26) cannot express the policies that operators want, so > operators break that specification and stretch it beyond what seems > reasonable. And now, you want a security system to sanction that:-) > > Sandy's Operator post listed some dubious practices with the question > should security not stop them. The discussion has exposed more dubious > practices but the question remains for me, should we not stop them, not > should we enforce them. They remain dubious practices. Well, we could argue about/discuss every possible policy all day, but I tend to think this specific one, the ability to indicate if an AS should or should not be used as transit, tends to be common, and one that people expect BGP to be able to do (though it can't gaurentee it in the way many people seem to think it can). I can't think of many others that I would try to get into securing--it's a huge black hole.... :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Mar 14 10:04:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09717 for ; Mon, 14 Mar 2005 10:04:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DArBI-0005y8-HG for rpsec-web-archive@ietf.org; Mon, 14 Mar 2005 10:08:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAr5o-0007tZ-Ke; Mon, 14 Mar 2005 10:02:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAr5m-0007tR-E3 for rpsec@megatron.ietf.org; Mon, 14 Mar 2005 10:02:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09427 for ; Mon, 14 Mar 2005 10:02:48 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAr9P-0005t5-2L for rpsec@ietf.org; Mon, 14 Mar 2005 10:06:36 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j2EF2TkT000855; Mon, 14 Mar 2005 10:02:35 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200503112337.j2BNbUIU015629@tislabs.com> Date: Mon, 14 Mar 2005 09:59:31 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] another example of peering topology check not catching Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: rpsec@ietf.org, Sandy Murphy X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe At 10:36 PM -0500 3/11/05, Russ White wrote: >>Another example which the peering topology check doesn't catch (I think): >> >> >> B >> / \ >> / \ >> A C >> >>B is multi-homed and has been allocated a /24 address block. > >>B advertises more specifics for part of that address block to A and >>more specifics for the rest to C. (Maybe it is load balancing, >>maybe there are performance advantages to C's connection for the >>specific application running on the addresses it sends to C, etc.) > >Let's make it more specific, say B advertises 10.1.1.0/25 to A, and >10.1.1.128/25 to C. > >>A advertises the more specifics it got from B *and* the rest of the >>more specifics as well, so it is advertising the entire /24 address >>space. > >Yes, but, from a routing perspective, this is perfectly valid. The >path exists, and is loop free. Russ, Being a physically extant path and loop free does not necessarily make the path "valid." If we agree that BGP is used by ASes to communicate what traffic they want to flow to/through them, then for a path to be called "valid" it should accurately reflect what as AS has advertised. > >>This isn't really a case of needing to know B's policy in order to >>decide what A should have done. A is making an advertisement >>without having received an advertisement that would justify it or >>any indication that B is willing to accept the traffic that way. > >Actually, it is policy. Routing finds loop free paths. Policy >determines which of those loop free paths should, or should not, be >used. If we delve into the policy arena in some places (like here), >then we need a good reason not to delve into it in all the other >places. BGP, as characterized in the RFC, is about more than just the propagation of loop free paths, so this seems to be an unduly narrow characterization. BGP specifically communicates policy, through route advertisements. The issue you seem to be raising in you message is whether we should adopt new protocols and infrastructure to communicate additional policy data in an out of band fashion. that's a fair question to ask, but it essentially says that BGP does not do an adequate job relative to its own, stated goals, and needs to be augmented. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Mar 14 10:16:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11273 for ; Mon, 14 Mar 2005 10:16:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DArMe-0006Xn-LU for rpsec-web-archive@ietf.org; Mon, 14 Mar 2005 10:20:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DArGk-0002EI-QO; Mon, 14 Mar 2005 10:14:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DArGj-0002E8-I3 for rpsec@megatron.ietf.org; Mon, 14 Mar 2005 10:14:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11063 for ; Mon, 14 Mar 2005 10:14:07 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DArKN-0006R6-Iu for rpsec@ietf.org; Mon, 14 Mar 2005 10:17:55 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 14 Mar 2005 10:14:00 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn3-535.cisco.com [10.82.218.26]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2EFDvjJ015568; Mon, 14 Mar 2005 10:13:58 -0500 (EST) Date: Mon, 14 Mar 2005 10:13:15 -0500 (Eastern Standard Time) From: Russ White To: Stephen Kent Subject: Re: [RPSEC] another example of peering topology check not catching In-Reply-To: Message-ID: References: <200503112337.j2BNbUIU015629@tislabs.com> X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: rpsec@ietf.org, Sandy Murphy X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 > Being a physically extant path and loop free does not necessarily make > the path "valid." If we agree that BGP is used by ASes to communicate > what traffic they want to flow to/through them, then for a path to be > called "valid" it should accurately reflect what as AS has advertised. > >> >>> This isn't really a case of needing to know B's policy in order to >>> decide what A should have done. A is making an advertisement without >>> having received an advertisement that would justify it or any >>> indication that B is willing to accept the traffic that way. >> >> Actually, it is policy. Routing finds loop free paths. Policy determines >> which of those loop free paths should, or should not, be used. If we >> delve into the policy arena in some places (like here), then we need a >> good reason not to delve into it in all the other places. > > BGP, as characterized in the RFC, is about more than just the propagation > of loop free paths, so this seems to be an unduly narrow > characterization. BGP specifically communicates policy, through route > advertisements. > > The issue you seem to be raising in you message is whether we should > adopt new protocols and infrastructure to communicate additional policy > data in an out of band fashion. that's a fair question to ask, but it > essentially says that BGP does not do an adequate job relative to its > own, stated goals, and needs to be augmented. Most of the policy you are discussing isn't implemented in the AS Path, however, it's in communities, local pref, and med--which are all the things we _aren't_ looking at. Policy based on as path is normally either a "hack," or perhaps something done with your immediate peer. I actually think the wording I've suggested doesn't imply any sort of external system, and also covers the AS Path based concepts nicely.... :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Mar 14 10:23:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12098 for ; Mon, 14 Mar 2005 10:23:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DArTe-0006r3-FO for rpsec-web-archive@ietf.org; Mon, 14 Mar 2005 10:27:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DArPQ-0003sC-TE; Mon, 14 Mar 2005 10:23:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DArPP-0003s7-B7 for rpsec@megatron.ietf.org; Mon, 14 Mar 2005 10:23:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12033 for ; Mon, 14 Mar 2005 10:23:05 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DArT3-0006mE-AZ for rpsec@ietf.org; Mon, 14 Mar 2005 10:26:53 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j2EFJskJ001862; Mon, 14 Mar 2005 10:19:54 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200503081857.j28IvQv1013627@tislabs.com> Date: Mon, 14 Mar 2005 10:19:52 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] issue: ASPATH Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: rpsec@ietf.org, Sandy Murphy X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 At 12:46 PM -0500 3/10/05, Russ White wrote: >>>Do we have a mechanism in mind to inform everyone whether the path >>>will carry traffic? Should we specify one? >> >>you raise a very good point, i.e., the current version of the >>document refers to existence of links but fails to define the >>reference basis for this, nor does it say why mere existence of a >>link is the right sort of check to make. BGP sends UPDATEs as the >>means of advertising, in a directional fashion, precisely what >>traffic each AS is soliciting via a specific link. > >Policy is separate from existence. Although the _intent_ of >advertising information, with an attached AS Path, is to draw >traffic, you _cannot_ infer from that information that every >possible address or set of addresses listed in the information is >actually reachable, through policy or in fact, through the AS Path >listed. Some parts may be, other parts may not be, there's no way to >gather this information from the update itself. The BGP spec says that an advertisement is precisely a claim by the advertiser that the NLRI is reachable via the advertiser. Let's not argue again about examples where a portion of a prefix associated with an AS has been delegated to another AS and is no longer reachable via the first AS. We've discussed this before. There is an underlying assumption in BGP that, in this case, if an AS fails to learn of the longer prefix being advertised by another AS, then the traffic will flow inappropriately to the first AS. That's the way the system works, it's consistent with the spec, and so it is not appropriate to argue that securing advertisements is inadequate because of this intrinsic characteristic of BGP. >The _only_ way to infer this information is to attach a policy >outside the information in the update (or to ban aggregation from >the Internet as a whole). This is an approach, but not the only approach. > >>>If not, then I think it should be explicitly noted that this >>>test does not absolutely ensure that the AS_PATH is now or >>>ever has been set up to pass the traffic. >> >>right, which raises questions as to why we consider a crude >>topology representation of this sort is an appropriate reference >>for AS_PATH validity checking. > >See above.... and see my comments above. > >>>I ran across this one, I think on NANOG: >>> >>> major ISP major ISP >>> west coast ----------------------------east coast >>> | | >>> | | >>> \--big national multi-homed customer--/ >>> >>>Major ISP has an outage on the cross continent link and starts routing >>>traffic through the customer's network. (Charging double to boot, >>>according to the message - once on the down-link and once on the >>>up-link.) >>> >>>I do not believe that the validity test would declare this an invalid >>>path. Should it? > >It is a _valid_ path, in that traffic could flow across the path in >question. It is out of policy for traffic to flow across this link, >which is another problem altogether. it was not a valid path for transit traffic, as we all agree. however the failure here seems to be a result of both the ISP and the multi-homed subscriber not causing forwarding tables in their border routers match their local policies. If EITHER of them did that correctly, the misdirected traffic flow would not happen. One does not need to publish the local policies each each As to avert this problem; the ASes merely need to ensure that their own policies are correctly reflected in the forwarding tables of routers that they locally control. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Mar 14 10:43:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14325 for ; Mon, 14 Mar 2005 10:43:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DArn8-0007aJ-AZ for rpsec-web-archive@ietf.org; Mon, 14 Mar 2005 10:47:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DArhX-0006RH-Pc; Mon, 14 Mar 2005 10:41:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DArhU-0006PF-La for rpsec@megatron.ietf.org; Mon, 14 Mar 2005 10:41:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14176 for ; Mon, 14 Mar 2005 10:41:46 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DArl8-0007Xg-PG for rpsec@ietf.org; Mon, 14 Mar 2005 10:45:35 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 14 Mar 2005 10:41:40 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn3-535.cisco.com [10.82.218.26]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2EFfa1k018390; Mon, 14 Mar 2005 10:41:36 -0500 (EST) Date: Mon, 14 Mar 2005 10:40:54 -0500 (Eastern Standard Time) From: Russ White To: Stephen Kent Subject: Re: [RPSEC] issue: ASPATH In-Reply-To: Message-ID: References: <200503081857.j28IvQv1013627@tislabs.com> X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: rpsec@ietf.org, Sandy Murphy X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 > The BGP spec says that an advertisement is precisely a claim by the > advertiser that the NLRI is reachable via the advertiser. But, it says nothing about the policies of the receiver to actually _use_ the path described, not does it garauntee the path described in the AS Path is the path the traffic fowarded through the transmitter of the update will actually be used to forward the traffic. Thus, reachability is not the same as policy--I may be able to do something, but shouldn't do it. I may not be able to do something, but should be able to. They are different concepts. If you want to include "authorized to use this path" in the concept of "a valid path," we will be a long time coming to concensus on a set of requirements, because you simply can't prove "authorization to use a path" from a piece of routing information. You can ascertain your immediate peer intends for you to send traffic to them, across the link through which you've learned this routing information, but you can't ever know that someone more than one AS hop away from you ever intends for you, two AS hops away, to transit traffic through them. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Mar 14 10:59:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16790 for ; Mon, 14 Mar 2005 10:59:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAs2F-0008Mv-44 for rpsec-web-archive@ietf.org; Mon, 14 Mar 2005 11:03:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DArxR-0001On-6L; Mon, 14 Mar 2005 10:58:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DArxP-0001Oi-DN for rpsec@megatron.ietf.org; Mon, 14 Mar 2005 10:58:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16696 for ; Mon, 14 Mar 2005 10:58:13 -0500 (EST) Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAs12-0008HR-Tx for rpsec@ietf.org; Mon, 14 Mar 2005 11:02:02 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j2EFsY1O012657 for ; Mon, 14 Mar 2005 10:54:34 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA2EaaUy; Mon, 14 Mar 05 10:54:32 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j2EFuED7011272; Mon, 14 Mar 2005 10:56:14 -0500 (EST) Date: Mon, 14 Mar 2005 10:56:14 -0500 (EST) From: Sandy Murphy Message-Id: <200503141556.j2EFuED7011272@tislabs.com> To: riw@cisco.com, sandy@tislabs.com Subject: Re: [RPSEC] another example of peering topology check not catching X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f >Suppose B also advertises the /24 to both A >and C. >... >Now, for whatever reason, C decides not to readvertise the /25, but only >the /24. What path is the traffic coming from beyond A and C going to take? >Possibly A, correct? Isn't this also against B's policy? No, I would say not, since B was advertising the /24 to both A and C. Why would you say this was against B's policy? Sure looks like B intended this to happen. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Mar 14 11:11:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18633 for ; Mon, 14 Mar 2005 11:11:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAsDc-0000Uk-L3 for rpsec-web-archive@ietf.org; Mon, 14 Mar 2005 11:15:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAs47-0002JF-EA; Mon, 14 Mar 2005 11:05:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAs45-0002J8-10 for rpsec@megatron.ietf.org; Mon, 14 Mar 2005 11:05:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17483 for ; Mon, 14 Mar 2005 11:05:06 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAs7h-00007X-Hv for rpsec@ietf.org; Mon, 14 Mar 2005 11:08:55 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 14 Mar 2005 11:22:10 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,162,1107752400"; d="scan'208"; a="40396989:sNHT19307552" Received: from russpc.Whitehouse.intra (rtp-vpn3-535.cisco.com [10.82.218.26]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2EG4tjJ001230; Mon, 14 Mar 2005 11:04:55 -0500 (EST) Date: Mon, 14 Mar 2005 11:04:13 -0500 (Eastern Standard Time) From: Russ White To: Sandy Murphy Subject: Re: [RPSEC] another example of peering topology check not catching In-Reply-To: <200503141556.j2EFuED7011272@tislabs.com> Message-ID: References: <200503141556.j2EFuED7011272@tislabs.com> X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 >> Suppose B also advertises the /24 to both A >> and C. >> ... >> Now, for whatever reason, C decides not to readvertise the /25, but only >> the /24. What path is the traffic coming from beyond A and C going to take? >> Possibly A, correct? Isn't this also against B's policy? > > No, I would say not, since B was advertising the /24 to both A and C. > > Why would you say this was against B's policy? Sure looks like B > intended this to happen. It's B's policy not to accept traffic on that link unless it's link to A is down. This is part of the problem with policy, it's hard to define what you mean when you say "policy," and it's also hard to express every possible meaning in routing itself. If we could express all the policies we wanted to in routing, then why do we have communities, and MED, and other such things? Why don't people just advertise what they mean, and not worry about all this other stuff? Because the routing information carried in BGP updates, by themselves, don't carry enough "policy" to sufficiently express what people mean. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Mar 14 11:13:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18933 for ; Mon, 14 Mar 2005 11:13:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAsG3-0000YP-Bn for rpsec-web-archive@ietf.org; Mon, 14 Mar 2005 11:17:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAs7g-0002Xy-86; Mon, 14 Mar 2005 11:08:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAs7e-0002Xt-3W for rpsec@megatron.ietf.org; Mon, 14 Mar 2005 11:08:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18330 for ; Mon, 14 Mar 2005 11:08:47 -0500 (EST) Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAsBI-0000QS-Kn for rpsec@ietf.org; Mon, 14 Mar 2005 11:12:36 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j2EG5A2H013905 for ; Mon, 14 Mar 2005 11:05:11 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAv1aWgB; Mon, 14 Mar 05 11:05:04 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j2EG6aei011602; Mon, 14 Mar 2005 11:06:36 -0500 (EST) Date: Mon, 14 Mar 2005 11:06:36 -0500 (EST) From: Sandy Murphy Message-Id: <200503141606.j2EG6aei011602@tislabs.com> To: nwnetworks@dial.pipex.com, riw@cisco.com Subject: Re: [RPSEC] another example of peering topology check not catching X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 >I can't think of many others that I would try to get into securing--it's a >huge black hole.... Note that the problem is not only "should we make this behavior secure". The problem is also "can the security protections make the behavior impossible". Or even "*should* the security protections make this behavior impossible". --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Mar 14 11:22:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19779 for ; Mon, 14 Mar 2005 11:22:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAsOj-0000yL-CO for rpsec-web-archive@ietf.org; Mon, 14 Mar 2005 11:26:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAsKR-0004ov-Q8; Mon, 14 Mar 2005 11:22:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAsKP-0004kk-Ey for rpsec@megatron.ietf.org; Mon, 14 Mar 2005 11:22:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19713 for ; Mon, 14 Mar 2005 11:21:58 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAsO1-0000x3-QW for rpsec@ietf.org; Mon, 14 Mar 2005 11:25:48 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 14 Mar 2005 11:21:50 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn3-535.cisco.com [10.82.218.26]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2EGLkjJ006397; Mon, 14 Mar 2005 11:21:47 -0500 (EST) Date: Mon, 14 Mar 2005 11:21:04 -0500 (Eastern Standard Time) From: Russ White To: Sandy Murphy Subject: Re: [RPSEC] another example of peering topology check not catching In-Reply-To: <200503141606.j2EG6aei011602@tislabs.com> Message-ID: References: <200503141606.j2EG6aei011602@tislabs.com> X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: rpsec@ietf.org, nwnetworks@dial.pipex.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d >> I can't think of many others that I would try to get into securing--it's >> a huge black hole.... > > Note that the problem is not only "should we make this behavior secure". > The problem is also "can the security protections make the behavior > impossible". Or even "*should* the security protections make this > behavior impossible". >From a traffic flow point of view, no, the security mechanism can't make this impossible. Making it impossible from a routing point of view would really require not doing aggregation, I think. I also think we might need to be able to justify why we're worried about this sort of behaviour, and not a host of other types of behaviours.... I think we can justify this to some degree, but it gets harder and harder to "draw the line" with every step over... :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Mar 14 11:39:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20916 for ; Mon, 14 Mar 2005 11:39:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAseo-0001eT-NT for rpsec-web-archive@ietf.org; Mon, 14 Mar 2005 11:43:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAsaC-0007FB-Pz; Mon, 14 Mar 2005 11:38:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAsaB-0007F3-G5 for rpsec@megatron.ietf.org; Mon, 14 Mar 2005 11:38:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20847 for ; Mon, 14 Mar 2005 11:38:16 -0500 (EST) Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAsdo-0001Z2-U2 for rpsec@ietf.org; Mon, 14 Mar 2005 11:42:06 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j2EGYdCr016638 for ; Mon, 14 Mar 2005 11:34:39 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAvHaOFG; Mon, 14 Mar 05 11:34:36 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j2EGa9KD012611; Mon, 14 Mar 2005 11:36:09 -0500 (EST) Date: Mon, 14 Mar 2005 11:36:09 -0500 (EST) From: Sandy Murphy Message-Id: <200503141636.j2EGa9KD012611@tislabs.com> To: kent@bbn.com, riw@cisco.com Subject: Re: [RPSEC] issue: ASPATH X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: rpsec@ietf.org, sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 >>>>I ran across this one, I think on NANOG: >>>> >>>> major ISP major ISP >>>> west coast ----------------------------east coast >>>> | | >>>> | | >>>> \--big national multi-homed customer--/ >>>> >>>>Major ISP has an outage on the cross continent link and starts routing >>>>traffic through the customer's network > >it was not a valid path for transit traffic, as we all agree. however >the failure here seems to be a result of both the ISP and the >multi-homed subscriber not causing forwarding tables in their border >routers match their local policies. If EITHER of them did that >correctly, the misdirected traffic flow would not happen. Well, I disagree. The "major ISP" did not violate the local policy - it *changed* its local policy and its forwarding. And the customer did not have a forwarding table that violated local policy - if you are presuming that the customer's policy was "I don't carry transit". There's no way for the forwarding table to represent that - forwading tables don't look at source. Now, you could make the filter on the incoming router reject traffic not intended for a customer address. (And, come to think of it, I don't know why that was not done). But it isn't a forwarding vs policy problem. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Mar 14 12:04:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23310 for ; Mon, 14 Mar 2005 12:04:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAt3K-0002dk-Re for rpsec-web-archive@ietf.org; Mon, 14 Mar 2005 12:08:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAsz8-0002Dn-VF; Mon, 14 Mar 2005 12:04:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAsz7-0002Di-SB for rpsec@megatron.ietf.org; Mon, 14 Mar 2005 12:04:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23272 for ; Mon, 14 Mar 2005 12:04:03 -0500 (EST) Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAt2l-0002dC-Sq for rpsec@ietf.org; Mon, 14 Mar 2005 12:07:53 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j2EH0RxO018896 for ; Mon, 14 Mar 2005 12:00:27 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAIIaq5K; Mon, 14 Mar 05 12:00:25 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j2EH1shD013475; Mon, 14 Mar 2005 12:01:54 -0500 (EST) Date: Mon, 14 Mar 2005 12:01:54 -0500 (EST) From: Sandy Murphy Message-Id: <200503141701.j2EH1shD013475@tislabs.com> To: riw@cisco.com, sandy@tislabs.com Subject: Re: [RPSEC] another example of peering topology check not catching X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 >> Another example which the peering topology check doesn't catch (I think): >> >> >> A C >> > >Let's make it more specific, say B advertises 10.1.1.0/25 to A, and >10.1.1.128/25 to C. > >> A advertises the more specifics it got from B *and* the rest of the more >> specifics as well, so it is advertising the entire /24 address space. > >Yes, but, from a routing perspective, this is perfectly valid. The path >exists, and is loop free. That is where we don't agree. I do not consider this to be a path that exists. Certainly the peering adjacencies exist, but as we all know, the existence of a peering does not ensure that the traffic will pass. The BGP advertisements, according to the spec, are supposed to indicate that the speaker has a route to the prefix advertised. Not just a peering relationship with the other AS. If that were all that BGP promised, then the messages could carry a whole lot less information. To better indicate the point, expand the graph a bit: B / \ / \ A1 C / A2 Suppose that A1 advertises 10.1.1.0/25 to A2, but A2 is the one that messes up and announces both 10.1.1.0/25 and 10.1.1.128/25. A2 may have forwarding set up to forward 10.1.1.128/25 to A1, but A1 surely doesn't have a forwarding set up for 10.1.1.128/25. A2's advertisement passes the origination test and the peering topology test and the "advertising the route it uses" test. But the prefix isn't "reachable" because the advertised route doesn't can't and won't forward traffic. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Mar 14 12:23:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25281 for ; Mon, 14 Mar 2005 12:23:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAtLF-0003UM-7Y for rpsec-web-archive@ietf.org; Mon, 14 Mar 2005 12:26:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAtEp-0006D6-FC; Mon, 14 Mar 2005 12:20:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAtEn-0006D1-PT for rpsec@megatron.ietf.org; Mon, 14 Mar 2005 12:20:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25052 for ; Mon, 14 Mar 2005 12:20:14 -0500 (EST) Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAtIS-0003RE-VF for rpsec@ietf.org; Mon, 14 Mar 2005 12:24:05 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j2EHGe9J020233 for ; Mon, 14 Mar 2005 12:16:40 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAf7aiGN; Mon, 14 Mar 05 12:16:37 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j2EHIIe2013919; Mon, 14 Mar 2005 12:18:18 -0500 (EST) Date: Mon, 14 Mar 2005 12:18:18 -0500 (EST) From: Sandy Murphy Message-Id: <200503141718.j2EHIIe2013919@tislabs.com> To: riw@cisco.com, sandy@tislabs.com Subject: Re: [RPSEC] issue: coverage X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 >-- Any proposed security system SHOULD be able to express policies >indicating a specific autonomous system should not be transited for any >given destination. Note there is no way to gaurantee such a policy would be >followed. I'm not sure what you mean by "a specific autonomous system should not be transited". Are you saying AS G sends to AS H an announcement that AS H should *not* transit prefix P? (I'm presuming that this announcement would get propogated so other people could tell whether H was living up to G's policy.) Note that this changes the meaning of announcements of "here's my route to a prefix, you may send me traffic for that prefix" from "... and that prefix only" to "and anything else you want as long as I haven't told you otherwise". (This is called "fail closed" vs "fail open"). I think that trying to express a policy of what H is NOT allowed to transit could mean some pretty big announcements. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Mar 14 12:29:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25964 for ; Mon, 14 Mar 2005 12:29:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAtRX-0003tB-J7 for rpsec-web-archive@ietf.org; Mon, 14 Mar 2005 12:33:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAtLG-0007Q0-Eh; Mon, 14 Mar 2005 12:26:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAtLF-0007Pv-Hw for rpsec@megatron.ietf.org; Mon, 14 Mar 2005 12:26:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25790 for ; Mon, 14 Mar 2005 12:26:54 -0500 (EST) Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAtOt-0003jE-At for rpsec@ietf.org; Mon, 14 Mar 2005 12:30:44 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j2EHNIsd021106 for ; Mon, 14 Mar 2005 12:23:19 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAttaWnP; Mon, 14 Mar 05 12:23:16 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j2EHOue6014194; Mon, 14 Mar 2005 12:24:56 -0500 (EST) Date: Mon, 14 Mar 2005 12:24:56 -0500 (EST) From: Sandy Murphy Message-Id: <200503141724.j2EHOue6014194@tislabs.com> To: riw@cisco.com, sandy@tislabs.com Subject: Re: [RPSEC] another example of peering topology check not catching X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 >It's B's policy not to accept traffic on that link unless it's link to A is >down. This is part of the problem with policy, it's hard to define what you >mean when you say "policy," and it's also hard to express every possible >meaning in routing itself. But we should at least be able to ensure that policy that *IS* expressed in the routing information is adhered to. That, at least, would be an assurance people would like to have, I would say. >If we could express all the policies we wanted to in routing, then why do >we have communities, and MED, and other such things? Why don't people just >advertise what they mean, and not worry about all this other stuff? Because >the routing information carried in BGP updates, by themselves, don't carry >enough "policy" to sufficiently express what people mean. Maybe, then, we are forced to decide on a set of the expressible meanings that we want to be able to secure. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Mar 14 13:48:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06879 for ; Mon, 14 Mar 2005 13:48:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAufs-0007g6-9M for rpsec-web-archive@ietf.org; Mon, 14 Mar 2005 13:52:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAubb-0005kQ-KQ; Mon, 14 Mar 2005 13:47:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAuba-0005kL-Su for rpsec@megatron.ietf.org; Mon, 14 Mar 2005 13:47:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06822 for ; Mon, 14 Mar 2005 13:47:51 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAufG-0007fA-Lr for rpsec@ietf.org; Mon, 14 Mar 2005 13:51:42 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j2EIlbkN014308; Mon, 14 Mar 2005 13:47:39 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <200503141636.j2EGa9KD012611@tislabs.com> References: <200503141636.j2EGa9KD012611@tislabs.com> Date: Mon, 14 Mar 2005 13:13:20 -0500 To: Sandy Murphy From: Stephen Kent Subject: Re: [RPSEC] issue: ASPATH Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 At 11:36 AM -0500 3/14/05, Sandy Murphy wrote: > >>>>I ran across this one, I think on NANOG: >>>>> >>>>> major ISP major ISP >>>>> west coast ----------------------------east coast >>>>> | | >>>>> | | >>>>> \--big national multi-homed customer--/ >>>>> >>>>>Major ISP has an outage on the cross continent link and starts routing >>>>>traffic through the customer's network >> >>it was not a valid path for transit traffic, as we all agree. however >>the failure here seems to be a result of both the ISP and the >>multi-homed subscriber not causing forwarding tables in their border >>routers match their local policies. If EITHER of them did that >>correctly, the misdirected traffic flow would not happen. > >Well, I disagree. The "major ISP" did not violate the local policy >- it *changed* its local policy and its forwarding. And the >customer did not have a forwarding table that violated local >policy - if you are presuming that the customer's policy was >"I don't carry transit". There's no way for the forwarding table >to represent that - forwading tables don't look at source. Now, >you could make the filter on the incoming router reject traffic >not intended for a customer address. (And, come to think of it, >I don't know why that was not done). But it isn't a forwarding >vs policy problem. > >--Sandy Sandy, I think I may have lost the context. Sorry for my confusion. Let me try to reestablish what happened, and why. Are you saying that the ISP erroneously accepted an advertisement from the multi-homed subscriber that advertised some portion of the ISP's address space, or some address space NOT associated with the subscriber, and as a result changed it's forwarding tables? if so, then path security measures would prevent such acceptance, if properly, locally, maintained. If not, then what triggered the forwarding table change? Secondly, with regard to the subscriber's forwarding tables in the BGP speakers that connect to the ISP, why would they have entries to forward INBOUND traffic for any but their own prefixes? Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Mar 14 13:52:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07241 for ; Mon, 14 Mar 2005 13:52:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAuk8-0007qo-9V for rpsec-web-archive@ietf.org; Mon, 14 Mar 2005 13:56:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAudX-0005yz-Md; Mon, 14 Mar 2005 13:49:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAudW-0005yu-16 for rpsec@megatron.ietf.org; Mon, 14 Mar 2005 13:49:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06972 for ; Mon, 14 Mar 2005 13:49:50 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAuhB-0007hW-LC for rpsec@ietf.org; Mon, 14 Mar 2005 13:53:42 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j2EIlbkL014308; Mon, 14 Mar 2005 13:47:38 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200503081857.j28IvQv1013627@tislabs.com> Date: Mon, 14 Mar 2005 13:06:38 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] issue: ASPATH X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0096525312==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 --===============0096525312== Content-Type: multipart/alternative; boundary="============_-1101296438==_ma============" --============_-1101296438==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 10:40 AM -0500 3/14/05, Russ White wrote: >>The BGP spec says that an advertisement is precisely a claim by the >>advertiser that the NLRI is reachable via the advertiser. > >But, it says nothing about the policies of the receiver to actually >_use_ the path described, not does it garauntee the path described >in the AS Path is the path the traffic fowarded through the >transmitter of the update will actually be used to forward the >traffic. You are right that the RFC does not explicitly say that a received path is usable by the AS that receives it. But I believe that a reasonable reading of the RFC makes it pretty clear that this is the primary intent of route advertisement. Moreover, in several places that I cited in previous messages, the RFC does say that the path described in the advertisement is the path via which traffic will be forwarded, at least nominally. >Thus, reachability is not the same as policy--I may be able to do >something, but shouldn't do it. I may not be able to do something, >but should be able to. They are different concepts. Why would AS A send an advertisement to AS B if AS A has no intent to accept traffic from that AS for the indicated NLRI, and forward the traffic to the indicated origin? >If you want to include "authorized to use this path" in the concept >of "a valid path," we will be a long time coming to concensus on a >set of requirements, because you simply can't prove "authorization >to use a path" from a piece of routing information. You can >ascertain your immediate peer intends for you to send traffic to >them, across the link through which you've learned this routing >information, but you can't ever know that someone more than one AS >hop away from you ever intends for you, two AS hops away, to transit >traffic through them. We've had this argument before. Lte's not bore the list by repeating it. Steve --============_-1101296438==_ma============ Content-Type: text/html; charset="us-ascii" Re: [RPSEC] issue: ASPATH
At 10:40 AM -0500 3/14/05, Russ White wrote:
The BGP spec says that an advertisement is precisely a claim by the advertiser that the NLRI is reachable via the advertiser.

But, it says nothing about the policies of the receiver to actually _use_ the path described, not does it garauntee the path described in the AS Path is the path the traffic fowarded through the transmitter of the update will actually be used to forward the traffic.

You are right that the RFC does not explicitly say that a received path is usable by the AS that receives it. But I believe that a reasonable reading of the RFC makes it pretty clear that this is the primary intent of route advertisement. Moreover, in several places that I cited in previous messages, the RFC does say that the path described in the advertisement is the path via which traffic will be forwarded, at least nominally.

Thus, reachability is not the same as policy--I may be able to do something, but shouldn't do it. I may not be able to do something, but should be able to. They are different concepts.

Why would AS A send an advertisement to AS B if AS A has no intent to accept traffic from that AS for the indicated NLRI, and forward the traffic to the indicated origin?

If you want to include "authorized to use this path" in the concept of "a valid path," we will be a long time coming to concensus on a set of requirements, because you simply can't prove "authorization to use a path" from a piece of routing information. You can ascertain your immediate peer intends for you to send traffic to them, across the link through which you've learned this routing information, but you can't ever know that someone more than one AS hop away from you ever intends for you, two AS hops away, to transit traffic through them.

We've had this argument before. Lte's not bore the list by repeating it.

Steve
--============_-1101296438==_ma============-- --===============0096525312== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --===============0096525312==-- From rpsec-bounces@ietf.org Mon Mar 14 15:26:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17835 for ; Mon, 14 Mar 2005 15:26:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAwCs-0003M5-Ok for rpsec-web-archive@ietf.org; Mon, 14 Mar 2005 15:30:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAw79-0001N3-3W; Mon, 14 Mar 2005 15:24:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAw76-0001Mk-Rn for rpsec@megatron.ietf.org; Mon, 14 Mar 2005 15:24:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17380 for ; Mon, 14 Mar 2005 15:24:30 -0500 (EST) Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAwAm-0003Dg-KM for rpsec@ietf.org; Mon, 14 Mar 2005 15:28:21 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j2EKKs7T008534 for ; Mon, 14 Mar 2005 15:20:54 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA6VaOPq; Mon, 14 Mar 05 15:20:51 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j2EKMXLX020161; Mon, 14 Mar 2005 15:22:33 -0500 (EST) Date: Mon, 14 Mar 2005 15:22:33 -0500 (EST) From: Sandy Murphy Message-Id: <200503142022.j2EKMXLX020161@tislabs.com> To: kent@bbn.com, sandy@tislabs.com Subject: Re: [RPSEC] issue: ASPATH X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 >Are you saying that the ISP erroneously accepted an advertisement >from the multi-homed subscriber that advertised some portion of the >ISP's address space, or some address space NOT associated with the >subscriber, and as a result changed it's forwarding tables? The NANOG note said only that the major ISP started routing traffic through the customer. The suggestion was that this was to ease the ISP's crosscountry backbone failure. There was a suggestion that this was deliberate on the part of the ISP - a configuration made this happen. Whether this configuration was just poorly thought out to begin with or a change instituted for the occasion was not discussed. So there was not a suggestion that routing was involved in the forwarding change. >Secondly, with regard to the subscriber's forwarding tables in the >BGP speakers that connect to the ISP, why would they have entries to >forward INBOUND traffic for any but their own prefixes? We're reaching the limit of my knowledge of router practices here. But I think the customer's edge routers forwarding tables have to have entries to the rest of the Internet for the customer user to reach the rest of the Internet. But that the customer's edge routers would/could generally have filters to prevent the entry of traffic destined for non-customer addresses. Protection is in the filter not in the forwarding table. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Mar 14 15:30:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18391 for ; Mon, 14 Mar 2005 15:30:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAwGW-0003YG-Pb for rpsec-web-archive@ietf.org; Mon, 14 Mar 2005 15:34:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAwBd-0001zJ-Ok; Mon, 14 Mar 2005 15:29:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAwBc-0001zE-Ce for rpsec@megatron.ietf.org; Mon, 14 Mar 2005 15:29:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18068 for ; Mon, 14 Mar 2005 15:29:10 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAwFI-0003Q8-9z for rpsec@ietf.org; Mon, 14 Mar 2005 15:33:01 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 14 Mar 2005 15:46:16 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,162,1107752400"; d="scan'208"; a="40442343:sNHT20653480" Received: from russpc.Whitehouse.intra (rtp-vpn3-535.cisco.com [10.82.218.26]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2EKSx1k011117; Mon, 14 Mar 2005 15:29:00 -0500 (EST) Date: Mon, 14 Mar 2005 15:28:17 -0500 (Eastern Standard Time) From: Russ White To: Sandy Murphy Subject: Re: [RPSEC] issue: ASPATH In-Reply-To: <200503141636.j2EGa9KD012611@tislabs.com> Message-ID: References: <200503141636.j2EGa9KD012611@tislabs.com> X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: rpsec@ietf.org, kent@bbn.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa >>>>> major ISP major ISP >>>>> west coast ----------------------------east coast >>>>> | | >>>>> | | >>>>> \--big national multi-homed customer--/ >>>>> >>>>> Major ISP has an outage on the cross continent link and starts routing >>>>> traffic through the customer's network >> >> it was not a valid path for transit traffic, as we all agree. however >> the failure here seems to be a result of both the ISP and the >> multi-homed subscriber not causing forwarding tables in their border >> routers match their local policies. If EITHER of them did that >> correctly, the misdirected traffic flow would not happen. > > Well, I disagree. The "major ISP" did not violate the local policy - it > *changed* its local policy and its forwarding. And the customer did not > have a forwarding table that violated local policy - if you are presuming > that the customer's policy was "I don't carry transit". There's no way > for the forwarding table to represent that - forwading tables don't look > at source. Neither do routing tables.... Or routing protocols. There are some mechanisms for carrying policy information, but they are secondary to finding loop free paths. > Now, you could make the filter on the incoming router reject traffic not > intended for a customer address. (And, come to think of it, I don't know > why that was not done). But it isn't a forwarding vs policy problem. Exactly. It's a forwarding plane problem, fix it at the forwarding plane. You're never going to be able to fix this with routing. You can indicate the policy, but you can't enforce it. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Mar 14 15:34:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18841 for ; Mon, 14 Mar 2005 15:34:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAwKR-0003id-Pd for rpsec-web-archive@ietf.org; Mon, 14 Mar 2005 15:38:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAwFH-0002VI-Dc; Mon, 14 Mar 2005 15:32:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAwFF-0002VD-Od for rpsec@megatron.ietf.org; Mon, 14 Mar 2005 15:32:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18766 for ; Mon, 14 Mar 2005 15:32:55 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAwIv-0003gp-MD for rpsec@ietf.org; Mon, 14 Mar 2005 15:36:46 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 14 Mar 2005 15:32:48 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn3-535.cisco.com [10.82.218.26]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2EKWjjJ020254; Mon, 14 Mar 2005 15:32:45 -0500 (EST) Date: Mon, 14 Mar 2005 15:32:03 -0500 (Eastern Standard Time) From: Russ White To: Stephen Kent Subject: Re: [RPSEC] issue: ASPATH In-Reply-To: Message-ID: References: <200503081857.j28IvQv1013627@tislabs.com> X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 >>> The BGP spec says that an advertisement is precisely a claim by the >>> advertiser that the NLRI is reachable via the advertiser. >> >> But, it says nothing about the policies of the receiver to actually _use_ >> the path described, not does it garauntee the path described in the AS Path >> is the path the traffic fowarded through the transmitter of the update will >> actually be used to forward the traffic. > > You are right that the RFC does not explicitly say that a received path > is usable by the AS that receives it. But I believe that a reasonable > reading of the RFC makes it pretty clear that this is the primary intent > of route advertisement. Moreover, in several places that I cited in > previous messages, the RFC does say that the path described in the > advertisement is the path via which traffic will be forwarded, at least > nominally. >From this, you're taking as a truism that if I receive an advertisement for some destination, it should always be "in policy" to transit traffic along the path described. If the traffic actually took that path. Of course, neither of these are provable, so there's point in arguing this. You can't gaurantee the traffic will take the path described in the routing information, and you can't gaurantee every transit AS listed agrees with this specific traffic stream transiting, nor the final hop AS agrees this is the correct entry point. Routing is hop by hop by design. It's not a circuit, it wasn't designed to be, and it won't ever be. If you want packet stream security, then you need to design and solve that problem at the packet stream level (IPsec, etc). You're not going to get it at the routing level. >> Thus, reachability is not the same as policy--I may be able to do >> something, but shouldn't do it. I may not be able to do something, but >> should be able to. They are different concepts. > > Why would AS A send an advertisement to AS B if AS A has no intent to > accept traffic from that AS for the indicated NLRI, and forward the > traffic to the indicated origin? I've given plenty of examples where this happens, so it's not a matter of intent, it's a matter of fact. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Mar 14 15:36:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18964 for ; Mon, 14 Mar 2005 15:36:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAwM3-0003nu-MH for rpsec-web-archive@ietf.org; Mon, 14 Mar 2005 15:39:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAwIJ-0002rD-Jv; Mon, 14 Mar 2005 15:36:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAwII-0002r3-T5 for rpsec@megatron.ietf.org; Mon, 14 Mar 2005 15:36:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18961 for ; Mon, 14 Mar 2005 15:36:05 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAwLy-0003ng-Ts for rpsec@ietf.org; Mon, 14 Mar 2005 15:39:56 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 14 Mar 2005 15:35:57 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn3-535.cisco.com [10.82.218.26]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2EKZs1k013007; Mon, 14 Mar 2005 15:35:55 -0500 (EST) Date: Mon, 14 Mar 2005 15:35:12 -0500 (Eastern Standard Time) From: Russ White To: Sandy Murphy Subject: Re: [RPSEC] another example of peering topology check not catching In-Reply-To: <200503141724.j2EHOue6014194@tislabs.com> Message-ID: References: <200503141724.j2EHOue6014194@tislabs.com> X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d >> It's B's policy not to accept traffic on that link unless it's link to A >> is down. This is part of the problem with policy, it's hard to define >> what you mean when you say "policy," and it's also hard to express every >> possible meaning in routing itself. > > But we should at least be able to ensure that policy that *IS* expressed > in the routing information is adhered to. That, at least, would be an > assurance people would like to have, I would say. Which policy? Not to transit a specific AS? I've already provided wording I think would cover that case, if we want to include it. If you want to consider that a part of "path validation," that's fine.... More below.... >> If we could express all the policies we wanted to in routing, then why do >> we have communities, and MED, and other such things? Why don't people just >> advertise what they mean, and not worry about all this other stuff? Because >> the routing information carried in BGP updates, by themselves, don't carry >> enough "policy" to sufficiently express what people mean. > > Maybe, then, we are forced to decide on a set of the expressible meanings > that we want to be able to secure. Yes. Is transiting a specific AS a policy we want to say should be expressable in any given system proposed? If so, then let's put the wording in to the draft. I don't (and won't) agree that it changes what we already have, it just adds to it. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Mar 14 15:45:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19627 for ; Mon, 14 Mar 2005 15:45:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAwVM-0004AU-QV for rpsec-web-archive@ietf.org; Mon, 14 Mar 2005 15:49:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAwNn-0003Yz-Gy; Mon, 14 Mar 2005 15:41:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAwNl-0003Yu-QD for rpsec@megatron.ietf.org; Mon, 14 Mar 2005 15:41:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19326 for ; Mon, 14 Mar 2005 15:41:43 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAwRS-00041N-Rn for rpsec@ietf.org; Mon, 14 Mar 2005 15:45:35 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 14 Mar 2005 15:41:37 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn3-535.cisco.com [10.82.218.26]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2EKfYjJ022589; Mon, 14 Mar 2005 15:41:35 -0500 (EST) Date: Mon, 14 Mar 2005 15:40:52 -0500 (Eastern Standard Time) From: Russ White To: Sandy Murphy Subject: Re: [RPSEC] issue: coverage In-Reply-To: <200503141718.j2EHIIe2013919@tislabs.com> Message-ID: References: <200503141718.j2EHIIe2013919@tislabs.com> X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 >> -- Any proposed security system SHOULD be able to express policies >> indicating a specific autonomous system should not be transited for any >> given destination. Note there is no way to gaurantee such a policy would be >> followed. > > I'm not sure what you mean by "a specific autonomous system should not be > transited". Are you saying AS G sends to AS H an announcement that AS H > should *not* transit prefix P? (I'm presuming that this announcement > would get propogated so other people could tell whether H was living up > to G's policy.) Suppose we have this: A---B---C---D A should be able to say: "I don't want C transiting traffic to me." Whether or not another path exists is actually orthogonal to the issue at hand. Whether or not C actually enforces this policy is out of bounds--it's a forwarding question, not a routing question, as I've stated elsewhere. That's the reason for the second part of the statement. > Note that this changes the meaning of announcements of "here's my > route to a prefix, you may send me traffic for that prefix" from > "... and that prefix only" to "and anything else you want as long > as I haven't told you otherwise". (This is called "fail closed" vs > "fail open"). Actually, the general operation of the Internet is not always "fail open," as a lot of people seem to think. For the failure mode to always be "fail open," we need to abolish the default route and aggregation. It might, today, be fail close or fail open, depending on the specific situation. We can try to close this hole, somewhat, but, see below on the tradeoffs involved.... > I think that trying to express a policy of what H is NOT allowed to > transit could mean some pretty big announcements. Perhaps, or perhaps not. That's a design issue, not a requirements one, to be balanced against other requirements.... :-) Second, I think making it a should is appropriate, since it allows designers to take into account just such factors--is being able to express this actually worth the tradeoff in increased processing/etc? To what level of granularity? There are a lot of issues here we've not yet addressed, and it seems to me it's a bit much to make this a must.... :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Mar 14 15:56:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20629 for ; Mon, 14 Mar 2005 15:56:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAwg9-0004fo-Jr for rpsec-web-archive@ietf.org; Mon, 14 Mar 2005 16:00:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAwcN-0005lb-Cw; Mon, 14 Mar 2005 15:56:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAwcM-0005ki-6Z for rpsec@megatron.ietf.org; Mon, 14 Mar 2005 15:56:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20619 for ; Mon, 14 Mar 2005 15:56:47 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAwg3-0004fN-0T for rpsec@ietf.org; Mon, 14 Mar 2005 16:00:39 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 14 Mar 2005 16:13:55 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,162,1107752400"; d="scan'208"; a="40446474:sNHT20111996" Received: from russpc.Whitehouse.intra (rtp-vpn3-535.cisco.com [10.82.218.26]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2EKucjJ026480; Mon, 14 Mar 2005 15:56:38 -0500 (EST) Date: Mon, 14 Mar 2005 15:55:56 -0500 (Eastern Standard Time) From: Russ White To: Sandy Murphy Subject: Re: [RPSEC] another example of peering topology check not catching In-Reply-To: <200503141701.j2EH1shD013475@tislabs.com> Message-ID: References: <200503141701.j2EH1shD013475@tislabs.com> X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 >>> Another example which the peering topology check doesn't catch (I think): >>> >>> >>> A C >>> >> >> Let's make it more specific, say B advertises 10.1.1.0/25 to A, and >> 10.1.1.128/25 to C. >> >>> A advertises the more specifics it got from B *and* the rest of the more >>> specifics as well, so it is advertising the entire /24 address space. >> >> Yes, but, from a routing perspective, this is perfectly valid. The path >> exists, and is loop free. > > > That is where we don't agree. I do not consider this to be a path > that exists. Certainly the peering adjacencies exist, but as we > all know, the existence of a peering does not ensure that the traffic > will pass. You can't gaurantee this, under any circumstances. You have to separate routing from forwarding in your mind.... One builds a graph, the other actually sends the traffic. If packet networks always sent information only across the path listed in the routing database, packet networks would never have been invented in the first place. That's the _point_ of a hop-by-hop packet network. To route around problems on the fly (and notice I've not once discussed failure modes in anything we've discussed so far, just normal operation). The point is to get the packet one hop closer to the destination, and let the next hop, with presumably more knowledge than I have, choose the next best hop, and so on, until the packet reaches its destination. No matter what happens to the network, and no matter what I think about the path the packet should take, the packet gets there. That's the point. Many years ago, we had pure circuit switched networks with the property of always sending traffic along a predetermined path. We've abandoned those for packet switched networks, and for a lot of good reasons. Now, we either have to try and convert packet switched networks into circuit switched networks, in order to "secure" them in some abstract sense, or we have to live within what's possible in a packet switched network--including that we can't know, for certain, when we forward a packet, which way it's going to take to get to the destination. We can try to _influence_ this path, but we can't gaurantee it, hence it's policy, not circuit setup. > The BGP advertisements, according to the spec, are supposed to indicate > that the speaker has a route to the prefix advertised. Yes, exactly. Not what the path is, only that a path exists. That's it, nothing more. I think we're hanging way too much on the AS Path here. Don't hang too much on the path, it's just not that strong of a peg, IMHO. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Mar 14 16:59:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26529 for ; Mon, 14 Mar 2005 16:59:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAxfC-0007bo-JU for rpsec-web-archive@ietf.org; Mon, 14 Mar 2005 17:03:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAxao-0006Zs-FV; Mon, 14 Mar 2005 16:59:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAxan-0006Zn-KN for rpsec@megatron.ietf.org; Mon, 14 Mar 2005 16:59:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26461 for ; Mon, 14 Mar 2005 16:59:15 -0500 (EST) Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAxeU-0007Ww-Dj for rpsec@ietf.org; Mon, 14 Mar 2005 17:03:07 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j2ELtdjN018193 for ; Mon, 14 Mar 2005 16:55:39 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAgTaaIJ; Mon, 14 Mar 05 16:55:36 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j2ELvI6J022809; Mon, 14 Mar 2005 16:57:18 -0500 (EST) Date: Mon, 14 Mar 2005 16:57:18 -0500 (EST) From: Sandy Murphy Message-Id: <200503142157.j2ELvI6J022809@tislabs.com> To: kent@bbn.com, riw@cisco.com Subject: Re: [RPSEC] issue: ASPATH X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 >You can't gaurantee the traffic will take the path described in the routing >information Yep. >you can't gaurantee every transit AS listed agrees with >this specific traffic stream transiting, nor the final hop AS agrees this >is the correct entry point. Why not? If something is propogated along the same path as the update that comes from the AS saying "I agree with this transiting", I would say that would gaurantee that the AS says that. I thought that the PC (Policy Certificates) carried in SoBGP were intended to capture exactly this - a statement that the AS agrees with the transiting. Did I misunderstand? --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Mar 14 17:10:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27033 for ; Mon, 14 Mar 2005 17:10:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAxp4-0007xP-C3 for rpsec-web-archive@ietf.org; Mon, 14 Mar 2005 17:14:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAxka-0007tq-S2; Mon, 14 Mar 2005 17:09:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAxkY-0007tl-S9 for rpsec@megatron.ietf.org; Mon, 14 Mar 2005 17:09:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27000 for ; Mon, 14 Mar 2005 17:09:20 -0500 (EST) Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAxoG-0007wZ-MG for rpsec@ietf.org; Mon, 14 Mar 2005 17:13:12 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j2EM5hsf018913 for ; Mon, 14 Mar 2005 17:05:43 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAACdaG7K; Mon, 14 Mar 05 17:05:40 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j2EM7UPf023132; Mon, 14 Mar 2005 17:07:30 -0500 (EST) Date: Mon, 14 Mar 2005 17:07:30 -0500 (EST) From: Sandy Murphy Message-Id: <200503142207.j2EM7UPf023132@tislabs.com> To: rpsec@ietf.org Subject: Re: [RPSEC] issue: coverage X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 >> Note that this changes the meaning of announcements of "here's my >> route to a prefix, you may send me traffic for that prefix" from >> "... and that prefix only" to "and anything else you want as long >> as I haven't told you otherwise". (This is called "fail closed" vs >> "fail open"). > >Actually, the general operation of the Internet is not always "fail open," >as a lot of people seem to think. For the failure mode to always be "fail >open," we need to abolish the default route and aggregation. It might, >today, be fail close or fail open, depending on the specific situation. We >can try to close this hole, somewhat, but, see below on the tradeoffs >involved.... I'm not certain I'm following, so I'm going to define terms here. Fail closed: if you can not provide explicit authorization to do something, you are forbidden to do it Fail open: if you are not explicitly forbidden to do something, then you are allowed to do it. So "here's my route to a prefix, you may send me traffic for that prefix ... and that prefix only" is a "fail closed". And "here's my route to a prefix, you may send me traffic for that prefix and anything else you want as long as I haven't told you otherwise" is a "fail open". I'm advocating for the "fail close", not the "fail open". Does that match the way you were using the terms? --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Mar 14 17:25:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27955 for ; Mon, 14 Mar 2005 17:25:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAy3m-0008VU-IJ for rpsec-web-archive@ietf.org; Mon, 14 Mar 2005 17:29:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAxxU-0001E0-Rb; Mon, 14 Mar 2005 17:22:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAxxS-0001Ds-MF for rpsec@megatron.ietf.org; Mon, 14 Mar 2005 17:22:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27851 for ; Mon, 14 Mar 2005 17:22:40 -0500 (EST) Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAy19-0008SE-Jb for rpsec@ietf.org; Mon, 14 Mar 2005 17:26:32 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j2EMJ2NC019868 for ; Mon, 14 Mar 2005 17:19:02 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAmdaaYM; Mon, 14 Mar 05 17:18:59 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j2EMKnch023473; Mon, 14 Mar 2005 17:20:49 -0500 (EST) Date: Mon, 14 Mar 2005 17:20:49 -0500 (EST) From: Sandy Murphy Message-Id: <200503142220.j2EMKnch023473@tislabs.com> To: rpsec@ietf.org Subject: Re: [RPSEC] another example of peering topology check not catching X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 >No matter >what happens to the network, and no matter what I think about the path the >packet should take, the packet gets there. But in some of my recent examples, the router advertises paths that do *NOT* get the packet there, period. The router has advertised that it has a route, but there's nothing behind that advertisement - no peer has provided a route that could work. Surely that is not a good thing? --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Mar 14 17:55:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00205 for ; Mon, 14 Mar 2005 17:55:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAyX3-0001Op-Ef for rpsec-web-archive@ietf.org; Mon, 14 Mar 2005 17:59:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAyRT-0005Vq-6K; Mon, 14 Mar 2005 17:53:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAyRR-0005Vl-Tc for rpsec@megatron.ietf.org; Mon, 14 Mar 2005 17:53:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00089 for ; Mon, 14 Mar 2005 17:53:39 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAyV8-0001MT-3b for rpsec@ietf.org; Mon, 14 Mar 2005 17:57:32 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 14 Mar 2005 14:54:07 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn1-388.cisco.com [10.82.225.132]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j2EMrRYP027377; Mon, 14 Mar 2005 14:53:28 -0800 (PST) Date: Mon, 14 Mar 2005 17:52:43 -0500 (Eastern Standard Time) From: Russ White To: Sandy Murphy Subject: Re: [RPSEC] issue: ASPATH In-Reply-To: <200503142157.j2ELvI6J022809@tislabs.com> Message-ID: References: <200503142157.j2ELvI6J022809@tislabs.com> X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: rpsec@ietf.org, kent@bbn.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a >> You can't gaurantee the traffic will take the path described in the >> routing information > > Yep. > >> you can't gaurantee every transit AS listed agrees with this specific >> traffic stream transiting, nor the final hop AS agrees this is the >> correct entry point. > > Why not? If something is propogated along the same path as the update > that comes from the AS saying "I agree with this transiting", I would say > that would gaurantee that the AS says that. Doesn't this contradict what we just agreed on above? :-) :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Mar 14 18:24:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04530 for ; Mon, 14 Mar 2005 18:24:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAyz5-0002vL-SJ for rpsec-web-archive@ietf.org; Mon, 14 Mar 2005 18:28:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAytE-0000ld-1z; Mon, 14 Mar 2005 18:22:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAytC-0000lY-Hb for rpsec@megatron.ietf.org; Mon, 14 Mar 2005 18:22:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04111 for ; Mon, 14 Mar 2005 18:22:19 -0500 (EST) Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAywt-0002iQ-Vg for rpsec@ietf.org; Mon, 14 Mar 2005 18:26:13 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j2ENIgOP024135 for ; Mon, 14 Mar 2005 18:18:42 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAARqaOiV; Mon, 14 Mar 05 18:18:39 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j2ENKLDV024734; Mon, 14 Mar 2005 18:20:21 -0500 (EST) Date: Mon, 14 Mar 2005 18:20:21 -0500 (EST) From: Sandy Murphy Message-Id: <200503142320.j2ENKLDV024734@tislabs.com> To: riw@cisco.com, sandy@tislabs.com Subject: Re: [RPSEC] issue: ASPATH X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: rpsec@ietf.org, kent@bbn.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 >>> You can't gaurantee the traffic will take the path described in the >>> routing information >> >> Yep. >> >>> you can't gaurantee every transit AS listed agrees with this specific >>> traffic stream transiting, nor the final hop AS agrees this is the >>> correct entry point. >> >> Why not? If something is propogated along the same path as the update >> that comes from the AS saying "I agree with this transiting", I would say >> that would gaurantee that the AS says that. > >Doesn't this contradict what we just agreed on above? :-) Not what I thought we said. I thought: you said we couldn't gaurantee that the AS would agree. I said "sure we can - have the AS sign something that says it agrees" Now, if you are looking for a gaurantee that the AS would fulfill its agreement and do what it agreed to do, well, that's a different matter. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Mar 15 12:36:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26621 for ; Tue, 15 Mar 2005 12:35:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBFmz-00047A-Ku for rpsec-web-archive@ietf.org; Tue, 15 Mar 2005 12:25:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBFRj-0003m6-Qx; Tue, 15 Mar 2005 12:03:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBFRh-0003lX-WF for rpsec@megatron.ietf.org; Tue, 15 Mar 2005 12:03:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21283 for ; Tue, 15 Mar 2005 12:00:03 -0500 (EST) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBFLD-0005EW-VD for rpsec@ietf.org; Tue, 15 Mar 2005 11:56:25 -0500 Received: from pc6 (1Cust242.tnt101.lnd4.gbr.da.uu.net [213.116.50.242]) by blaster.systems.pipex.net (Postfix) with SMTP id 7E297E0000E8 for ; Tue, 15 Mar 2005 16:52:12 +0000 (GMT) Message-ID: <040e01c52976$920c8160$0601a8c0@pc6> From: "Tom Petch" Cc: References: Date: Tue, 15 Mar 2005 16:40:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Subject: [RPSEC] Making progress X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit I am concerned that we are not progressing as we might, especially when I look back at the archive and at the significant contributions many people have made. What I see is a recurring debate about an important, but not especially large, element of IDR, about some aspects of policy, ones that cannot be effected with the facilities of bgp4-26, some of which cannot be effected with the facilities of any RFC. To move forward, I want a declaration of rough consensus on things we can agree on, leaving out the few, if important, issues we cannot and then taking a view on what we do about the latter. This needs chairmanship and that is what I think we are not getting; if any, it is coming from the likes of Sandy Murphy and not the designated chairs of rpsec. Russ, I like to hear the views you express, especially when they challenge my convictions, but my sense is that they are getting in the way and they stop us reaching consensus where we could. I think you should step aside as chair of rpsec pro tem (while continuing to argue your case technically) and should ask the ADs to appoint another chair. Tom Petch _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Mar 15 13:33:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01301 for ; Tue, 15 Mar 2005 13:23:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBGX2-0000oe-GN for rpsec-web-archive@ietf.org; Tue, 15 Mar 2005 13:12:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBGRl-0004AW-M5; Tue, 15 Mar 2005 13:07:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBGRj-00049u-Ne for rpsec@megatron.ietf.org; Tue, 15 Mar 2005 13:07:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29306 for ; Tue, 15 Mar 2005 13:07:06 -0500 (EST) Received: from blaines.net ([65.79.159.21] helo=tunguy.blaines.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBGRf-00007k-W5 for rpsec@ietf.org; Tue, 15 Mar 2005 13:07:09 -0500 Received: from [192.168.199.133] ([192.5.93.62]) (authenticated bits=0) by tunguy.blaines.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id j2FI2jsh018752 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Tue, 15 Mar 2005 13:02:48 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 15 Mar 2005 13:02:38 -0500 Subject: Re: [RPSEC] Making progress From: Blaine Christian To: Tom Petch Message-ID: In-Reply-To: <040e01c52976$920c8160$0601a8c0@pc6> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Hey Tom, I think Russ has been a pretty good agitator for this group. While he may have his moments I think his work to involve as many people as possible in the process, and drive consensus, has been instrumental is creating this conversation that we are all having. Personally, I believe in hearing all arguments (and doing my own fair share of arguing myself). I know Russ has been an opinionated, and occasionally abrasive, person but the occasional hand grenade seems to have pushed the requirements forward quite a bit. Without vigorous conversation and detailed debate we might just approach hubris in thinking certain individual opinions (from anyone) are the "correct" ones. Can I suggest to the group that we keep Russ, and Tony, as our cheerleader co-chairs? If they seems to be tearing the group apart and communication decreases we should re-evaluate. I would say that if the thread just "dies" for a couple months due to "lack of interest" we should start discussing potential means of revitalizing things (such as kicking out chairs). If folks feel otherwise can you please contact me off-list? I don't want to drag this discussion too far down politics. Regards, Blaine On 3/15/05 10:40 AM, "Tom Petch" wote: > I am concerned that we are not progressing as we might, especially when I look > back at the archive and at the significant contributions many people have > made. > > What I see is a recurring debate about an important, but not especially large, > element of IDR, about some aspects of policy, ones that cannot be effected > with > the > facilities of bgp4-26, some of which cannot be effected with the facilities of > any RFC. > > To move forward, I want a declaration of rough consensus on things we can > agree > on, leaving out the few, if important, issues we cannot and then taking a view > on what we do about the latter. > > This needs chairmanship and that is what I think we are not getting; if any, > it > is coming from the likes of Sandy Murphy and not the designated chairs of > rpsec. > > Russ, I like to hear the views you express, especially when they challenge my > convictions, but my sense is that they are getting in the way and they stop us > reaching consensus where we could. I think you should step aside as chair of > rpsec pro tem (while continuing to argue your case technically) and should ask > the ADs to appoint another chair. > > Tom Petch > > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Mar 15 15:19:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14604 for ; Tue, 15 Mar 2005 15:19:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBIZx-0004gc-FU for rpsec-web-archive@ietf.org; Tue, 15 Mar 2005 15:23:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBISk-0001L5-PH; Tue, 15 Mar 2005 15:16:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBISh-0001KA-Cq for rpsec@megatron.ietf.org; Tue, 15 Mar 2005 15:16:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13785 for ; Tue, 15 Mar 2005 15:16:15 -0500 (EST) Received: from llmail.ll.mit.edu ([129.55.12.40] helo=ll.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBIMT-0003b8-HV for rpsec@ietf.org; Tue, 15 Mar 2005 15:09:56 -0500 Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id j2FK5ifB004881; Tue, 15 Mar 2005 15:05:44 -0500 (EST) Received: from tauberpc.llan.ll.mit.edu( ), claiming to be "LEN-Overlook.llan.ll.mit.edu" via SMTP by llpost, id smtpdAAAZBaWvj; Tue Mar 15 15:05:38 2005 Date: Tue, 15 Mar 2005 15:05:37 -0500 From: Tony Tauber To: Tom Petch Subject: Re: [RPSEC] Making progress In-Reply-To: <040e01c52976$920c8160$0601a8c0@pc6> Message-ID: References: <040e01c52976$920c8160$0601a8c0@pc6> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Hi Tom, I'll take the whack. In this most recent go-round since Minneapolis, (which, due to a death in the family, I had to leave early), I think the discussion has mostly been taking an orderly path. I'd like to shelve the "you can prove" "you can't prove" stuff and much of the wangling about operational pathologies and policies. I think there's a good consensual intuition about what BGP is (and has been intended to be) used for and much of that has been clarified through this discussion. Either Blaine or I will take the most recent threads and indicate what changes to the document that might be made or try to clarify the point being debated for consensus or deferral if inclusion in this document (vs. some successor) is not necessary. Does that make sense? Thanks for your prodding, Tony On Tue, 15 Mar 2005, Tom Petch wrote: > I am concerned that we are not progressing as we might, especially > when I look back at the archive and at the significant contributions > many people have made. > > What I see is a recurring debate about an important, but not > especially large, element of IDR, about some aspects of policy, ones > that cannot be effected with the facilities of bgp4-26, some of > which cannot be effected with the facilities of any RFC. > > To move forward, I want a declaration of rough consensus on things > we can agree on, leaving out the few, if important, issues we cannot > and then taking a view on what we do about the latter. > > This needs chairmanship and that is what I think we are not getting; > if any, it is coming from the likes of Sandy Murphy and not the > designated chairs of rpsec. > > Russ, I like to hear the views you express, especially when they > challenge my convictions, but my sense is that they are getting in > the way and they stop us reaching consensus where we could. I think > you should step aside as chair of rpsec pro tem (while continuing to > argue your case technically) and should ask the ADs to appoint > another chair. > > Tom Petch _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Mar 15 17:40:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28265 for ; Tue, 15 Mar 2005 17:40:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBKli-0005if-W6 for rpsec-web-archive@ietf.org; Tue, 15 Mar 2005 17:44:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBKgv-0000jx-As; Tue, 15 Mar 2005 17:39:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBKgt-0000h6-R1 for rpsec@megatron.ietf.org; Tue, 15 Mar 2005 17:39:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28196 for ; Tue, 15 Mar 2005 17:39:05 -0500 (EST) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBKko-0005hT-Fx for rpsec@ietf.org; Tue, 15 Mar 2005 17:43:10 -0500 Received: from pc6 (1Cust4.tnt30.lnd3.gbr.da.uu.net [62.188.122.4]) by blaster.systems.pipex.net (Postfix) with SMTP id A61DEE000180; Tue, 15 Mar 2005 22:38:55 +0000 (GMT) Message-ID: <089401c529a7$0246d180$0601a8c0@pc6> From: "Tom Petch" To: "Tony Tauber" References: <040e01c52976$920c8160$0601a8c0@pc6> Subject: Re: [RPSEC] Making progress Date: Tue, 15 Mar 2005 22:36:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit I'll sleep on it while waiting to see what anyone else says; after all, I do believe in consensus:-) (and I am aware of a certain level of off-list activity). Tom Petch ----- Original Message ----- From: "Tony Tauber" To: "Tom Petch" Cc: Sent: Tuesday, March 15, 2005 9:05 PM Subject: Re: [RPSEC] Making progress > Hi Tom, > > I'll take the whack. In this most recent go-round since Minneapolis, > (which, due to a death in the family, I had to leave early), I think > the discussion has mostly been taking an orderly path. > > I'd like to shelve the "you can prove" "you can't prove" stuff and > much of the wangling about operational pathologies and policies. > > I think there's a good consensual intuition about what BGP is (and has > been intended to be) used for and much of that has been clarified > through this discussion. > > Either Blaine or I will take the most recent threads and indicate what > changes to the document that might be made or try to clarify the point > being debated for consensus or deferral if inclusion in this document > (vs. some successor) is not necessary. > > Does that make sense? > > Thanks for your prodding, > > Tony > > > On Tue, 15 Mar 2005, Tom Petch wrote: > > > I am concerned that we are not progressing as we might, especially > > when I look back at the archive and at the significant contributions > > many people have made. > > > > What I see is a recurring debate about an important, but not > > especially large, element of IDR, about some aspects of policy, ones > > that cannot be effected with the facilities of bgp4-26, some of > > which cannot be effected with the facilities of any RFC. > > > > To move forward, I want a declaration of rough consensus on things > > we can agree on, leaving out the few, if important, issues we cannot > > and then taking a view on what we do about the latter. > > > > This needs chairmanship and that is what I think we are not getting; > > if any, it is coming from the likes of Sandy Murphy and not the > > designated chairs of rpsec. > > > > Russ, I like to hear the views you express, especially when they > > challenge my convictions, but my sense is that they are getting in > > the way and they stop us reaching consensus where we could. I think > > you should step aside as chair of rpsec pro tem (while continuing to > > argue your case technically) and should ask the ADs to appoint > > another chair. > > > > Tom Petch _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Mar 16 17:18:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04574 for ; Wed, 16 Mar 2005 17:18:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBguW-0007bi-C7 for rpsec-web-archive@ietf.org; Wed, 16 Mar 2005 17:22:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBgoT-0006LA-9U; Wed, 16 Mar 2005 17:16:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBgoR-0006CQ-1N for rpsec@megatron.ietf.org; Wed, 16 Mar 2005 17:16:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04447 for ; Wed, 16 Mar 2005 17:16:19 -0500 (EST) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBgsX-0007Wv-Ei for rpsec@ietf.org; Wed, 16 Mar 2005 17:20:37 -0500 Received: from pc6 (1Cust217.tnt15.lnd4.gbr.da.uu.net [62.188.144.217]) by astro.systems.pipex.net (Postfix) with SMTP id DAD91E000142; Wed, 16 Mar 2005 22:16:09 +0000 (GMT) Message-ID: <021d01c52a6c$fcdb6b40$0601a8c0@pc6> From: "Tom Petch" To: "Tony Tauber" References: <040e01c52976$920c8160$0601a8c0@pc6> Subject: Re: [RPSEC] Making progress Date: Wed, 16 Mar 2005 22:10:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit Ok, no other comments on the list so over to you. The issue I raised I see as a question of process, of management, of how to make the most of the technical resources available - us! - seeing a need right now for more chairing, for nailing down what we can agree on when we can. I hope you will be able to provide that but do wish you had someone else explicitly supporting you. Tom Petch ----- Original Message ----- From: "Tony Tauber" To: "Tom Petch" Cc: Sent: Tuesday, March 15, 2005 9:05 PM Subject: Re: [RPSEC] Making progress > Hi Tom, > > I'll take the whack. In this most recent go-round since Minneapolis, > (which, due to a death in the family, I had to leave early), I think > the discussion has mostly been taking an orderly path. > > I'd like to shelve the "you can prove" "you can't prove" stuff and > much of the wangling about operational pathologies and policies. > > I think there's a good consensual intuition about what BGP is (and has > been intended to be) used for and much of that has been clarified > through this discussion. > > Either Blaine or I will take the most recent threads and indicate what > changes to the document that might be made or try to clarify the point > being debated for consensus or deferral if inclusion in this document > (vs. some successor) is not necessary. > > Does that make sense? > > Thanks for your prodding, > > Tony > > > On Tue, 15 Mar 2005, Tom Petch wrote: > > > I am concerned that we are not progressing as we might, especially > > when I look back at the archive and at the significant contributions > > many people have made. > > > > What I see is a recurring debate about an important, but not > > especially large, element of IDR, about some aspects of policy, ones > > that cannot be effected with the facilities of bgp4-26, some of > > which cannot be effected with the facilities of any RFC. > > > > To move forward, I want a declaration of rough consensus on things > > we can agree on, leaving out the few, if important, issues we cannot > > and then taking a view on what we do about the latter. > > > > This needs chairmanship and that is what I think we are not getting; > > if any, it is coming from the likes of Sandy Murphy and not the > > designated chairs of rpsec. > > > > Russ, I like to hear the views you express, especially when they > > challenge my convictions, but my sense is that they are getting in > > the way and they stop us reaching consensus where we could. I think > > you should step aside as chair of rpsec pro tem (while continuing to > > argue your case technically) and should ask the ADs to appoint > > another chair. > > > > Tom Petch _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Mar 16 17:34:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06525 for ; Wed, 16 Mar 2005 17:34:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBhAT-0008Rn-JF for rpsec-web-archive@ietf.org; Wed, 16 Mar 2005 17:39:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBh5X-0004DQ-90; Wed, 16 Mar 2005 17:34:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBh5U-00046n-Eo for rpsec@megatron.ietf.org; Wed, 16 Mar 2005 17:34:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06220 for ; Wed, 16 Mar 2005 17:33:57 -0500 (EST) Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBh9b-0008O7-Ew for rpsec@ietf.org; Wed, 16 Mar 2005 17:38:15 -0500 Received: from [192.168.1.101] (lsanca1-ar44-4-33-110-166.lsanca1.dsl-verizon.net [4.33.110.166]) (authenticated bits=0) by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j2GMXV6g030930 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 16 Mar 2005 14:33:32 -0800 In-Reply-To: <021d01c52a6c$fcdb6b40$0601a8c0@pc6> References: <040e01c52976$920c8160$0601a8c0@pc6> <021d01c52a6c$fcdb6b40$0601a8c0@pc6> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Merike Kaeo Subject: Re: [RPSEC] Making progress Date: Wed, 16 Mar 2005 14:34:13 -0800 To: Tom Petch X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org, Tony Tauber X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit As a previous co-chair for another wg, when there was a document which had lots of input from one of us, the 'chair-type' decisions were left to the one not involved with the document. I don't see a problem so far.......as long as decisions are made to reach concensus on discussions and not have them re-hashed numerous times. I was surprised to see a comment to replace a chair who in my opinion has not exerted any chair influence over his technical contribution. [I'm guilty of not keeping up with mailing list in past 2 months but glance at emails to see where things are at. Have 245 emails to sift through to come up with my own conclusions and maybe contribute some opinions - perhaps I'd better get to them in next day or so] - merike On Mar 16, 2005, at 1:10 PM, Tom Petch wrote: > Ok, no other comments on the list so over to you. > > The issue I raised I see as a question of process, of management, of > how to make > the most of the technical resources available - us! - seeing a need > right now > for more chairing, for nailing down what we can agree on when we can. > > I hope you will be able to provide that but do wish you had someone > else > explicitly supporting you. > > Tom Petch > > ----- Original Message ----- > From: "Tony Tauber" > To: "Tom Petch" > Cc: > Sent: Tuesday, March 15, 2005 9:05 PM > Subject: Re: [RPSEC] Making progress > > >> Hi Tom, >> >> I'll take the whack. In this most recent go-round since Minneapolis, >> (which, due to a death in the family, I had to leave early), I think >> the discussion has mostly been taking an orderly path. >> >> I'd like to shelve the "you can prove" "you can't prove" stuff and >> much of the wangling about operational pathologies and policies. >> >> I think there's a good consensual intuition about what BGP is (and has >> been intended to be) used for and much of that has been clarified >> through this discussion. >> >> Either Blaine or I will take the most recent threads and indicate what >> changes to the document that might be made or try to clarify the point >> being debated for consensus or deferral if inclusion in this document >> (vs. some successor) is not necessary. >> >> Does that make sense? >> >> Thanks for your prodding, >> >> Tony >> >> >> On Tue, 15 Mar 2005, Tom Petch wrote: >> >>> I am concerned that we are not progressing as we might, especially >>> when I look back at the archive and at the significant contributions >>> many people have made. >>> >>> What I see is a recurring debate about an important, but not >>> especially large, element of IDR, about some aspects of policy, ones >>> that cannot be effected with the facilities of bgp4-26, some of >>> which cannot be effected with the facilities of any RFC. >>> >>> To move forward, I want a declaration of rough consensus on things >>> we can agree on, leaving out the few, if important, issues we cannot >>> and then taking a view on what we do about the latter. >>> >>> This needs chairmanship and that is what I think we are not getting; >>> if any, it is coming from the likes of Sandy Murphy and not the >>> designated chairs of rpsec. >>> >>> Russ, I like to hear the views you express, especially when they >>> challenge my convictions, but my sense is that they are getting in >>> the way and they stop us reaching consensus where we could. I think >>> you should step aside as chair of rpsec pro tem (while continuing to >>> argue your case technically) and should ask the ADs to appoint >>> another chair. >>> >>> Tom Petch > > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec > _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Mar 17 10:52:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15765 for ; Thu, 17 Mar 2005 10:52:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBxN2-0005Yq-WE for rpsec-web-archive@ietf.org; Thu, 17 Mar 2005 10:57:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBxEz-0003Ol-Br; Thu, 17 Mar 2005 10:48:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBxEu-0003O6-Ra for rpsec@megatron.ietf.org; Thu, 17 Mar 2005 10:48:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15001 for ; Thu, 17 Mar 2005 10:48:45 -0500 (EST) Received: from dsl081-098-224.den1.dsl.speakeasy.net ([64.81.98.224] helo=mail.castlepoint.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBxJ9-0005MM-5L for rpsec@ietf.org; Thu, 17 Mar 2005 10:53:13 -0500 Received: from [127.0.0.1] (ns1.castlepoint.net [172.16.15.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.castlepoint.net (Postfix) with ESMTP id 2B31E426B5; Thu, 17 Mar 2005 08:48:37 -0700 (MST) Message-ID: <4239A6D4.9010400@castlepoint.net> Date: Thu, 17 Mar 2005 08:48:36 -0700 From: Shane Amante User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Petch Subject: Re: [RPSEC] Making progress References: <040e01c52976$920c8160$0601a8c0@pc6> <089401c529a7$0246d180$0601a8c0@pc6> In-Reply-To: <089401c529a7$0246d180$0601a8c0@pc6> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org, Tony Tauber X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit Tom, All, First, I think Russ has done a good job, particularly with his technical contribution, in moving the work in RPSEC forward. As Merike noted in a later e-mail, due to Russ' (and others!) outstanding efforts it's been difficult to stay on top of the "avalanche" of e-mail threads and weigh in on the issues in a timely manner. (Most often by the time I get caught up, Russ or someone else has already brought up the issues or points I would've responded with). Second, I think Russ has adequately maintained a neutral stance between his duties as co-chair and technical contributor to work in the WG. Also, (as Merike already noted), it's not unusual in other IETF WG's for co-chairs to be active contributors to work products of their own WG's, (provided they recuse themselves and ask the other co-chair to seek consensus of WG participants on said work products). Finally, I agree with Tony that what we really need is a list of outstanding issues. Those should each be circulated in their own, individual thread, so we can focus on them individually and hopefully come to some type of agreement and move forward. -shane Tom Petch wrote: > I'll sleep on it while waiting to see what anyone else says; after all, I do > believe in consensus:-) (and I am aware of a certain level of off-list > activity). > > Tom Petch > > ----- Original Message ----- > From: "Tony Tauber" > To: "Tom Petch" > Cc: > Sent: Tuesday, March 15, 2005 9:05 PM > Subject: Re: [RPSEC] Making progress > > > >>Hi Tom, >> >>I'll take the whack. In this most recent go-round since Minneapolis, >>(which, due to a death in the family, I had to leave early), I think >>the discussion has mostly been taking an orderly path. >> >>I'd like to shelve the "you can prove" "you can't prove" stuff and >>much of the wangling about operational pathologies and policies. >> >>I think there's a good consensual intuition about what BGP is (and has >>been intended to be) used for and much of that has been clarified >>through this discussion. >> >>Either Blaine or I will take the most recent threads and indicate what >>changes to the document that might be made or try to clarify the point >>being debated for consensus or deferral if inclusion in this document >>(vs. some successor) is not necessary. >> >>Does that make sense? >> >>Thanks for your prodding, >> >>Tony >> >> >>On Tue, 15 Mar 2005, Tom Petch wrote: >> >> >>>I am concerned that we are not progressing as we might, especially >>>when I look back at the archive and at the significant contributions >>>many people have made. >>> >>>What I see is a recurring debate about an important, but not >>>especially large, element of IDR, about some aspects of policy, ones >>>that cannot be effected with the facilities of bgp4-26, some of >>>which cannot be effected with the facilities of any RFC. >>> >>>To move forward, I want a declaration of rough consensus on things >>>we can agree on, leaving out the few, if important, issues we cannot >>>and then taking a view on what we do about the latter. >>> >>>This needs chairmanship and that is what I think we are not getting; >>>if any, it is coming from the likes of Sandy Murphy and not the >>>designated chairs of rpsec. >>> >>>Russ, I like to hear the views you express, especially when they >>>challenge my convictions, but my sense is that they are getting in >>>the way and they stop us reaching consensus where we could. I think >>>you should step aside as chair of rpsec pro tem (while continuing to >>>argue your case technically) and should ask the ADs to appoint >>>another chair. >>> >>>Tom Petch > > > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Mar 17 17:35:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28905 for ; Thu, 17 Mar 2005 17:35:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC3fE-0000TK-Tv for rpsec-web-archive@ietf.org; Thu, 17 Mar 2005 17:40:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC3Yc-00023n-Nv; Thu, 17 Mar 2005 17:33:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC3YZ-00023i-Mx for rpsec@megatron.ietf.org; Thu, 17 Mar 2005 17:33:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28630 for ; Thu, 17 Mar 2005 17:33:27 -0500 (EST) Received: from mxintern.kundenserver.de ([212.227.126.201] helo=mxintern.schlund.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC3cn-0000Nt-HQ for rpsec@ietf.org; Thu, 17 Mar 2005 17:37:59 -0500 Received: from [82.82.76.152] (helo=[192.168.0.100]) by mxintern.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1DC3YM-000347-I3; Thu, 17 Mar 2005 23:33:19 +0100 Message-ID: <423A05A3.9050604@schlund.net> Date: Thu, 17 Mar 2005 23:33:07 +0100 From: Stefan Mink User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Subject: Re: [RPSEC] issue: operator use References: In-Reply-To: X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Warning: 82.82.76.152 is listed at dialup.bl.kundenserver.de X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1412965703==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1412965703== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig16916DE0A08AFD04FE51458D" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig16916DE0A08AFD04FE51458D Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Steve, Stephen Kent wrote: > I know that this is used legitimately as a traffic engineering > mechanism. However, this represents a modification of the AS path in a > fashion that is not consistent with the BGP RFC. Also, since you can > achieve the same traffic engineering effect by prepending your own AS > number multiple times, it seems undesirable to make provisions to > achieve the effect the other way. that's not true although it might be a vendor specific issue: if you prepend a received route with your own AS and advertise it over an IBGP session, at least juniper routers discard the route because the detect the local as in the path. This is not the case with cisco routers which happily accept such routes on IBGP sessions. I never bothered to check who's right and who's wrong but in any case this is the reason why I - running a dual vendor network - HAVE to prepend with the AS of the peer and not with my own AS. tschuess Stefan PS: I know there is a knob on JUNOS so you can permit the local AS in received routes but this is AFAIK a global option and by thus would also concern EBGP sessions. This would mean you would accept your own routes also over EBGP links. -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA --------------enig16916DE0A08AFD04FE51458D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCOgWnehvPYvDU0roRAs0cAJ4ywg3W86wGtIA4MLKuvMwnCSKGaQCbBOBq IWj7x/EMzlivxprFt1Gll/s= =2Sp4 -----END PGP SIGNATURE----- --------------enig16916DE0A08AFD04FE51458D-- --===============1412965703== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --===============1412965703==-- From rpsec-bounces@ietf.org Thu Mar 17 17:45:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29546 for ; Thu, 17 Mar 2005 17:45:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC3oY-0000gh-QC for rpsec-web-archive@ietf.org; Thu, 17 Mar 2005 17:50:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC3jk-00044V-Py; Thu, 17 Mar 2005 17:45:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC3ji-00042r-So for rpsec@megatron.ietf.org; Thu, 17 Mar 2005 17:45:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29515 for ; Thu, 17 Mar 2005 17:44:59 -0500 (EST) Received: from mxintern.kundenserver.de ([212.227.126.201] helo=mxintern.schlund.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC3o3-0000fr-1r for rpsec@ietf.org; Thu, 17 Mar 2005 17:49:31 -0500 Received: from [82.82.76.152] (helo=[192.168.0.100]) by mxintern.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1DC3ja-0006aP-M5; Thu, 17 Mar 2005 23:44:55 +0100 Message-ID: <423A085B.1000308@schlund.net> Date: Thu, 17 Mar 2005 23:44:43 +0100 From: Stefan Mink User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Russ White Subject: Re: [RPSEC] issue: operator use References: <20050309135149.GA17743@nexthop.com> In-Reply-To: X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Warning: 82.82.76.152 is listed at dialup.bl.kundenserver.de X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: rpsec@ietf.org, Jeffrey Haas , Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0724676651==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0724676651== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig35869555775B8286441A1986" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig35869555775B8286441A1986 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Russ, Russ White wrote: > But, that's the point Blaine's making--AS' that prepend are engineering > the traffic flows on their inbound links. it also concerns local traffic flows and how they leave your network. This is especially important if you run a content heavy network. So it's not necessarily inbound TE but definitely outbound TE > The problem we're running in > to here is that we have to decide is engineering traffic is actually an > attack or not. I suppose it could be in some circumstances, but it's not > going to be in others, and it's going to be hard to tell the difference > between the two, when all the players involved are legitimate. the main problem is, that the knob "local pref", which is meant to be used for local TE, is just to brutal in the route decision process, because if you assign a lower locpref to a route, it wont be used at all as long as there is an alternative with a regular or higher localpref value. MED on the other hand is just meant to be used for routes received from the same AS. So AS-path prepending is sometimes indeed a resonable way to do TE. People who don't like AS path prependings tend to use MED independently of the nexthop AS, but this is also not the way MED is being meant to be used, but it's at least a local thing and invisible to the rest of the internet. tschuess Stefan -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA --------------enig35869555775B8286441A1986 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCOgheehvPYvDU0roRAkhPAKCLi+gIScIUp8mtlX7eFFl2Gn9IiwCcDOov k0baURwnQtaANbk7VIyPs+U= =LYxl -----END PGP SIGNATURE----- --------------enig35869555775B8286441A1986-- --===============0724676651== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --===============0724676651==-- From rpsec-bounces@ietf.org Thu Mar 17 18:13:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02054 for ; Thu, 17 Mar 2005 18:13:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC4FL-0001FI-Hr for rpsec-web-archive@ietf.org; Thu, 17 Mar 2005 18:17:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC49f-0000Z1-Cr; Thu, 17 Mar 2005 18:11:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC49d-0000Xu-OW for rpsec@megatron.ietf.org; Thu, 17 Mar 2005 18:11:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01896 for ; Thu, 17 Mar 2005 18:11:46 -0500 (EST) Received: from mxintern.kundenserver.de ([212.227.126.201] helo=mxintern.schlund.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC4Dy-0001E4-3J for rpsec@ietf.org; Thu, 17 Mar 2005 18:16:18 -0500 Received: from [82.82.76.152] (helo=[192.168.0.100]) by mxintern.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1DC49b-0004PJ-SA; Fri, 18 Mar 2005 00:11:48 +0100 Message-ID: <423A0EAA.9050603@schlund.net> Date: Fri, 18 Mar 2005 00:11:38 +0100 From: Stefan Mink User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Doug Montgomery Subject: Re: [RPSEC] issue: operator use References: <200503101640.j2AGe1Ko024560@tislabs.com> <42307FB9.4070202@nist.gov> In-Reply-To: <42307FB9.4070202@nist.gov> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Warning: 82.82.76.152 is listed at dialup.bl.kundenserver.de X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1914756367==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1914756367== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAA492C304BF0D2ABCFCB5044" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAA492C304BF0D2ABCFCB5044 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Doug, Doug Montgomery wrote: > In a GROW discussion (on another topic) it sounds as if prepending other > ASes for the purpose of effecting downstream distribution policy (i.e., > poisoning) is a common "technique". > > While one may want to detect malicious uses of this technique (maybe all > uses are malicious is some AS's view ;^) it would seem that any technique > that would allow one to verify who added what to the PATH, would also > potentially invalidate this technique. > > Not clear if this is good or bad ... but just something to keep in mind > in this discussion. this is again a sign of how the AS-Path currently gets (mis)used due to missing alternatives: * AS-path prependings: missing other equivalent TE features of BGP * AS-path poisoning: missing authorization schemes It is similar with communities: every missing feature of BGP somehow gets implemented via communities these days. It just seems BGP is not powerful enough but can be tweaked in so many ways that it can do what you want. An interesting example who you can mess up things equally is demonstrated on http://www.tm.uka.de/idrws/2004/contributions/IDRWS2004--22--Griffin_Tim--BGP_Wegdies_Bad_Policy_Interactions_that_cannot_be_debugged.pdf Exactly that tweaking is what makes BGP a pain to secure. I wonder if this would be any different if there would be "regular" routing protocol elements to replace the tweakings... tschuess Stefan PS: IDRWS will take place in May in Stockholm and aims at filling one day with security relevant talks: http://www.tm.uka.de/idrws/cfc.php -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA --------------enigAA492C304BF0D2ABCFCB5044 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCOg6tehvPYvDU0roRAgnPAKC1U45AyaZbeWwEPsfq/omVTqnPFQCgnhRV 9fFG1R6de0l4SHaPnzUfmoo= =xaLv -----END PGP SIGNATURE----- --------------enigAA492C304BF0D2ABCFCB5044-- --===============1914756367== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --===============1914756367==-- From rpsec-bounces@ietf.org Thu Mar 17 18:44:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04797 for ; Thu, 17 Mar 2005 18:44:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC4jS-0001uD-DV for rpsec-web-archive@ietf.org; Thu, 17 Mar 2005 18:48:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC4cp-0006g1-T9; Thu, 17 Mar 2005 18:41:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC4co-0006fw-7a for rpsec@megatron.ietf.org; Thu, 17 Mar 2005 18:41:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04691 for ; Thu, 17 Mar 2005 18:41:54 -0500 (EST) Received: from mxintern.kundenserver.de ([212.227.126.201] helo=mxintern.schlund.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC4h8-0001rl-0k for rpsec@ietf.org; Thu, 17 Mar 2005 18:46:27 -0500 Received: from [82.82.76.152] (helo=[192.168.0.100]) by mxintern.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1DC4cf-0000p2-5R; Fri, 18 Mar 2005 00:41:49 +0100 Message-ID: <423A15B2.9090204@schlund.net> Date: Fri, 18 Mar 2005 00:41:38 +0100 From: Stefan Mink User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Russ White Subject: Re: [RPSEC] issue: ASPATH References: <200503141636.j2EGa9KD012611@tislabs.com> In-Reply-To: X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Warning: 82.82.76.152 is listed at dialup.bl.kundenserver.de X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: rpsec@ietf.org, kent@bbn.com, Sandy Murphy X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1486612407==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1486612407== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1C78095B8903389F83FDCD95" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1C78095B8903389F83FDCD95 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Russ White wrote: > Exactly. It's a forwarding plane problem, fix it at the forwarding > plane. You're never going to be able to fix this with routing. You can > indicate the policy, but you can't enforce it. one would need "forward path filtering" instead of RPF ;) At the moment you're stuck with manual firewalling entries to enforce your policy on forwarding plane :( tschuess Stefan -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA --------------enig1C78095B8903389F83FDCD95 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCOhW2ehvPYvDU0roRAmWvAJ9LOqHBqy3SyNAUVJJZZg9u0Q2pAQCfZ/zi b5yG0p9I6Er3S54gy+jxVxo= =1C44 -----END PGP SIGNATURE----- --------------enig1C78095B8903389F83FDCD95-- --===============1486612407== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --===============1486612407==-- From rpsec-bounces@ietf.org Fri Mar 18 12:26:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00564 for ; Fri, 18 Mar 2005 12:26:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCLJZ-0006hp-9B for rpsec-web-archive@ietf.org; Fri, 18 Mar 2005 12:31:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCLCx-0006V0-D1; Fri, 18 Mar 2005 12:24:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCLCv-0006Tx-0C for rpsec@megatron.ietf.org; Fri, 18 Mar 2005 12:24:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00256 for ; Fri, 18 Mar 2005 12:24:17 -0500 (EST) Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCLHO-0006aC-8k for rpsec@ietf.org; Fri, 18 Mar 2005 12:28:59 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j2IHKeFK002694 for ; Fri, 18 Mar 2005 12:20:40 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA9VaGqf; Fri, 18 Mar 05 12:20:38 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j2IHMJbb007094; Fri, 18 Mar 2005 12:22:19 -0500 (EST) Date: Fri, 18 Mar 2005 12:22:19 -0500 (EST) From: Sandy Murphy Message-Id: <200503181722.j2IHMJbb007094@tislabs.com> To: mink@schlund.net, riw@cisco.com Subject: Re: [RPSEC] issue: operator use X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: rpsec@ietf.org, jhaas@nexthop.com, kent@bbn.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f > The problem we're running in > to here is that we have to decide is engineering traffic is actually an > attack or not. I see it a bit differently. The problem to me is that allowing this behavior as legitimate makes it real darn difficult to prevent people from adding AS's other than their own to an AS_PATH for evil purposes. Not impossible but much more complicated. Engineering your own traffic is reasonable - engineering someone else's traffic can be a problem. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Mar 18 12:39:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02487 for ; Fri, 18 Mar 2005 12:39:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCLWJ-0007GB-1U for rpsec-web-archive@ietf.org; Fri, 18 Mar 2005 12:44:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCLQO-0001RQ-Ti; Fri, 18 Mar 2005 12:38:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCLQM-0001RH-Lf for rpsec@megatron.ietf.org; Fri, 18 Mar 2005 12:38:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02363 for ; Fri, 18 Mar 2005 12:38:11 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCLUq-0007Ec-1q for rpsec@ietf.org; Fri, 18 Mar 2005 12:42:53 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 18 Mar 2005 12:38:05 -0500 Received: from russpc.Whitehouse.intra (rtp-vpn1-297.cisco.com [10.82.225.41]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2IHc11k016988; Fri, 18 Mar 2005 12:38:02 -0500 (EST) Date: Fri, 18 Mar 2005 12:37:56 -0500 (Eastern Standard Time) From: Russ White To: Sandy Murphy Subject: Re: [RPSEC] issue: operator use In-Reply-To: <200503181722.j2IHMJbb007094@tislabs.com> Message-ID: References: <200503181722.j2IHMJbb007094@tislabs.com> X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: mink@schlund.net, jhaas@nexthop.com, kent@bbn.com, rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a >> The problem we're running in to here is that we have to decide is >> engineering traffic is actually an attack or not. > > I see it a bit differently. The problem to me is that allowing this > behavior as legitimate makes it real darn difficult to prevent people > from adding AS's other than their own to an AS_PATH for evil purposes. > Not impossible but much more complicated. > > Engineering your own traffic is reasonable - engineering someone else's > traffic can be a problem. Of course, your inbound traffic is someone else's outbound traffic, and your outbound traffic is someone else's inbound traffic, so it's not even that simple... :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Mar 18 14:19:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12903 for ; Fri, 18 Mar 2005 14:19:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCN4s-0002vz-1g for rpsec-web-archive@ietf.org; Fri, 18 Mar 2005 14:24:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCMyU-0003YP-Iy; Fri, 18 Mar 2005 14:17:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCMyT-0003YH-0L for rpsec@megatron.ietf.org; Fri, 18 Mar 2005 14:17:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12741 for ; Fri, 18 Mar 2005 14:17:31 -0500 (EST) Received: from rimp1.nist.gov ([129.6.16.226] helo=smtp.nist.gov) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCN2v-0002ts-2j for rpsec@ietf.org; Fri, 18 Mar 2005 14:22:12 -0500 Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j2IJFxDJ015872; Fri, 18 Mar 2005 14:16:00 -0500 Received: from [127.0.0.1] (dhcp-9.antd.nist.gov [129.6.51.138]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j2IJFLEY006365; Fri, 18 Mar 2005 14:15:23 -0500 (EST) Message-ID: <423B28C9.8050306@nist.gov> Date: Fri, 18 Mar 2005 14:15:21 -0500 From: Doug Montgomery Organization: http://www.antd.nist.gov/ User-Agent: Mozilla Thunderbird 1.0 (Windows/20050209) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sandy Murphy Subject: Re: [RPSEC] issue: operator use References: <200503181722.j2IHMJbb007094@tislabs.com> In-Reply-To: <200503181722.j2IHMJbb007094@tislabs.com> X-Enigmail-Version: 0.90.1.1 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-MailScanner-From: dougm@nist.gov X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: mink@schlund.net, kent@bbn.com, jhaas@nexthop.com, rpsec@ietf.org, riw@cisco.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit I think soon we will need to partition existing BGP mechanisms *and* common practices into those that we think are necessary / desirable to secure and those that can secured in a reasonable way. I can envision a long period of partial / incremental deployment (possibly forever) in which one might still use things that don't make the second cut. Seems like it might become a local pref kind of thing, reflecting how concerned you are about various attributes being verifiable vs not. Depending upon your local policy you might weight completely verifiable but otherwise lower pref, higher than some other path that can't be completely verified. Anyway, the meta thought was not everything that is common practice today has to be secured. Those that don't make the cut won't necessarily die, they will just be less assured. How they continue to be used will probably evolve over time. dougm Sandy Murphy wrote: >>The problem we're running in >>to here is that we have to decide is engineering traffic is actually an >>attack or not. > > > I see it a bit differently. The problem to me is that allowing this > behavior as legitimate makes it real darn difficult to prevent people > from adding AS's other than their own to an AS_PATH for evil > purposes. Not impossible but much more complicated. > > Engineering your own traffic is reasonable - engineering someone > else's traffic can be a problem. > > --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Mar 18 17:49:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18040 for ; Fri, 18 Mar 2005 17:49:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCQLs-0007Rn-3h for rpsec-web-archive@ietf.org; Fri, 18 Mar 2005 17:54:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCQFA-0006GC-RV; Fri, 18 Mar 2005 17:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCQF9-0006Ft-7p for rpsec@megatron.ietf.org; Fri, 18 Mar 2005 17:46:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17907 for ; Fri, 18 Mar 2005 17:46:55 -0500 (EST) Received: from dns2.nexthop.com ([65.247.36.217] helo=aa-mx2.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCQJe-0007PF-Km for rpsec@ietf.org; Fri, 18 Mar 2005 17:51:39 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx2.nexthop.com (Postfix) with ESMTP id 0134D4AC01; Fri, 18 Mar 2005 17:46:42 -0500 (EST) Received: from aa-mx2.nexthop.com ([127.0.0.1]) by localhost (aa-mx2.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 31379-02-10; Fri, 18 Mar 2005 17:46:36 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx2.nexthop.com (Postfix) with ESMTP id 731534AC29; Fri, 18 Mar 2005 17:46:36 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j2IMka323122; Fri, 18 Mar 2005 17:46:36 -0500 (EST) Date: Fri, 18 Mar 2005 17:46:36 -0500 From: Jeffrey Haas To: Sandy Murphy Subject: Re: [RPSEC] issue: coverage Message-ID: <20050318224636.GU26060@nexthop.com> References: <200503112324.j2BNOVZu015309@tislabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503112324.j2BNOVZu015309@tislabs.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab I'm a bit behind, so I apologize if this was discussed in more detail already. On Fri, Mar 11, 2005 at 06:24:32PM -0500, Sandy Murphy wrote: > So - should we be considering adding requirements about communicating > policy to our list? (Wasn't there a suggestion once of a mechanism that > did communicate policy around?) While such things are in the realm of possibility, I don't believe they're in the realm of practicality. I suggest that we shouldn't be putting a policy communications mechanism in at the moment. > --Sandy -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec