From clystal_star88@yahoo.fr Mon Jul 02 11:44:01 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5O4H-0000UI-OW for pim-archive@lists.ietf.org; Mon, 02 Jul 2007 11:44:01 -0400 Received: from [124.234.75.56] (helo=so-net.ne.jp) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5O4G-0007Wn-Ut for pim-archive@lists.ietf.org; Mon, 02 Jul 2007 11:44:01 -0400 Received: from oGZTQhZ4 (unknown [198.111.163.116]) by so-net.ne.jp (Coremail) with SMTP id XVU41NAC9d1ccYjF.1 for ; Sat, 29 Mar 2008 12:19:13 +0800 (CST) X-Originating-IP: [198.111.163.116] Subject: =?iso-2022-jp?B?GyRCIVYbKEJUaGF0J3MgaXQbJEIhVyRyOiNHLyRiMys6RSQ3GyhC?= From: "michiru hasagawa" To: X-Mailer: Microsoft Outlook Express MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01C7A159.90CACE80" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.9 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C7A159.90CACE80 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit $Bl$G(B100$BL>0L$rM=Dj$7$F$$$^$9(B $B:#G/$bLLGr$/$J$j$=$&$G$9$h(B $B;22CHqMQ$OL5NA$G$9!#(B $BCK@-$NJ}!"=w@-$NJ}!"@'Hs$I$s$I$s;22C$7$F$/$@$5$$!#(B $B3Z$7$$0l;~$r2a$4$7$^$7$g$&!#(B http://pure.final-love.net/?salut $B"(HVAH
=1B$B
=1B$BBg5,LOMp8r%Q!<%F%#!
=1B$B:#2s$O7k9=3DBg5,LO$J2q>l$G=1B(B100=1B$BL>0L$rM=3DDj$7$F$$$^= $9=1B(B
=1B$B:#G/$bLLGr$/$J$j$=3D$&$G$9$h=1B(B
=1B$B;22CHqMQ$OL5NA$G$9!#=1B(B
=1B$BCK@-$NJ}!"=3Dw@-$NJ}!"@'Hs$I$s$I$s;22C$7$F$/$@$5$$!#=1B(B
=1B$B3Z$7$$0l;~$r2a$4$7$^$7$g$&!#=1B(B
http://pure.final-love.net/?sa= lut
=1B$B"(HVAH
 
=1B$B59$7$/$*4j$$$7$^$9=1B(B
 
=1B$B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!:Y@n=1B(B
 
 
 
 
 
 
------=_NextPart_000_0016_01C7A159.90CACE80-- From pim-bounces@ietf.org Mon Jul 02 12:41:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5OyA-0003Tb-QZ; Mon, 02 Jul 2007 12:41:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4hfb-000488-8m for pim@ietf.org; Sat, 30 Jun 2007 14:27:43 -0400 Received: from wa-out-1112.google.com ([209.85.146.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4hfA-0007lx-Ir for pim@ietf.org; Sat, 30 Jun 2007 14:27:43 -0400 Received: by wa-out-1112.google.com with SMTP id k17so1898218waf for ; Sat, 30 Jun 2007 11:27:16 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type; b=c4Zbus0Xg6cuhD9godOneb/2msUH4tTdfx7pTHgL7aIvDS3Z5KEQv9WV2gx7b7zfVG/XhlWoPs0feGSbwJGKGX4Vjay1YUhn1pnVEbWFWMGcZMW3D9DWq1UVCCfeSkG6Nh4tL2BhQo2/p9jeOAnHsOZVBarS+FjNHUHMPs3TD2Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type; b=mrPZ/mTnfGyLMmYtUJwBR6voyyr9YvmHZLl+7MgDJK+XnmV5jXDspZjBBaoYeUIXxb3qI7SlO+jbtQxY5OWW2K9xGHpoK7msEGBjCsHlj46s71BvcSyCTggrOUuJuLhlVWAuhbJy3YzHUbCRKnUqEYRyAMhZ966FpsPltQYEgqo= Received: by 10.115.33.1 with SMTP id l1mr3700748waj.1183228035807; Sat, 30 Jun 2007 11:27:15 -0700 (PDT) Received: by 10.114.103.7 with HTTP; Sat, 30 Jun 2007 11:27:15 -0700 (PDT) Message-ID: <100ba11b0706301127v716d8288w95d2919314121cbd@mail.gmail.com> Date: Sat, 30 Jun 2007 23:57:15 +0530 From: "janardhan kulkarni" To: internet-drafts@ietf.org, pim@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_20290_23349526.1183228035777" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8104b3fcabb4d2dfaed548848b9dc80f X-Mailman-Approved-At: Mon, 02 Jul 2007 12:41:41 -0400 Cc: Archana Patel Subject: [pim] A new draft on PIM to test the convexity of domain and RP consistency X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pim-bounces@ietf.org ------=_Part_20290_23349526.1183228035777 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Please find attached a our new draft on PIM to test the convexity of pim domain and hence the reachability of multicast source. This can also be used to test the RP consistency along a path. Kindly review it and let us know the comments. Thanks. ------=_Part_20290_23349526.1183228035777 Content-Type: text/plain; name=draft-archana-pimwg-pim-ping-00.txt; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: base64 X-Attachment-Id: f_f3kfc9ry Content-Disposition: attachment; filename="draft-archana-pimwg-pim-ping-00.txt" SU5URVJORVQtRFJBRlQgICAgICAgICAgICAgUElNLVBJTkcgICAgICAgICAgICAgIEFyY2hhbmEg UGF0ZWwNCkV4cGlyZXMgMjggRGVjZW1iZXIgMjAwNyAgICAgICAgICAgICAgICAgICAgICAgICBD aXNjbyAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEphbmFyZGhhbiBLdWxrYXJuaQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIENpdHJpeA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDI4IEp1bmUgMjAwNw0KDQoNCg0KDQogICAgICAgICAgICAgICAg ICAgICAgICAgIFBJTS1QSU5HICAgICAgICAgICAgIA0KICAgICAgICAgICAgPGRyYWZ0LWFyY2hh bmEtcGltd2ctcGltLXBpbmctMDA+DQoNCg0KU3RhdHVzIG9mIHRoaXMgTWVtbw0KDQpUaGlzIGRv Y3VtZW50IGlzIGFuIEludGVybmV0LURyYWZ0IGFuZCBpcyBpbiBmdWxsIGNvbmZvcm1hbmNlIHdp dGgNCkFsbCBwcm92aXNpb25zIG9mIFNlY3Rpb24gMTAgb2YgUkZDMjAyNi4NCg0KSW50ZXJuZXQt RHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcg DQpUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAg Tm90ZSB0aGF0IA0Kb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1 bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRv Y3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMNCmFuZCBtYXkgYmUgdXBk YXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55DQp0 aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtIERyYWZ0cyBhcyByZWZl cmVuY2UgDQptYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBw cm9ncmVzcy4iDQoNClRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBh Y2Nlc3NlZCBhdA0KaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0DQoN ClRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNj ZXNzZWQgYXQNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuDQoNCkFic3RyYWN0DQoN CkFzIG11bHRpY2FzdCBuZXR3b3JrcyBzdGFydCB0byBnZXQgZGVwbG95ZWQgaW4gbGFyZ2UgbnVt YmVyLCBpdCANCmJlY29tZXMgdmVyeSBpbXBvcnRhbnQgdGhhdCwgcHJvcGVyIG1lY2hhbmlzbXMg YXJlIGluIHBsYWNlIGZvciANCnRyb3VibGUgc2hvb3RpbmcgZXJyb3IgY29uZGl0aW9ucyBhbmQg aW5mb3JtaW5nIG90aGVyIGZhaWx1cmUgDQpzaXR1YXRpb25zLiBTaW5jZSBtdWx0aWNhc3Rpbmcg aGFzIGxpdHRsZSBzdXBwb3J0IGZyb20gSVAgaW4gdGhpcw0KbWF0dGVyIChzaW5jZSBJQ01QIGRv ZXMgbm90IHN1cHBvcnQgbXVsdGljYXN0aW5nIGFuZCBicm9hZGNhc3RpbmcpIGl0DQpiZWhvb3Zl cyB0aGF0LCBtdWx0aWNhc3Qgcm91dGluZyBwcm90b2NvbHMsIGVtYmVkIHRoZXNlIGZlYXR1cmVz IGluIA0KdGhlbXNlbHZlcy4gVGhpcyBkcmFmdCBwcmVzZW50cyBzb21lIGlkZWFzIGFib3V0IGhv dyB0aGlzIGNhbiBiZSBkb25lDQp1c2luZyBQSU0gcHJvdG9jb2wgc3VpdGUgYXMgZXhhbXBsZSwg c2luY2UgUElNU1NNIGFuZCBQSU1TTSBhcmUgDQpwcm9iYWJseSBtb3N0IHdpZGVseSB1c2VkIG11 bHRpY2FzdCByb3V0aW5nIHByb3RvY29scy4NCg0KDQoNCg0KQXJjaGFuYS9KYW5hcmRoYW4gICAg ICAgICAgICBQSU0tUElORyAgICAgICAgICAgICAgIFtQYWdlIDFdDQpJTlRFUk5FVC1EUkFGVCAg ICAgICAgICAgICAgIEV4cDogRGVjIDIwMDcgICAgICAgICAgMjggSnVuZSAyMDA3DQoNCg0KDQoN Cg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAg IFRhYmxlIG9mIENvbnRlbnRzDQoNCjEuICBJbnRyb2R1Y3Rpb24gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDMNCjIuICBUZXJtaW5vbG9neSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDQNCiAgICAg IDIuMSBEZWZpbml0aW9ucyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDQNCjMuICBQSU0tUElORyBPdmVydmlldyAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDUNCjQuICBQSU0tUElORyBtZXNzYWdlIGZvcm1hdHMgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDYNCiAgICAgIDQuMSBSZXF1ZXN0 IE1lc3NhZ2UgZm9ybWF0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDYNCiAg ICAgIDQuMiBSZXNwb25zZSBNZXNzYWdlIGZvcm1hdCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDkNCjUuICBTcGVjaWZpY2F0aW9uIG9mIFBJTS1QaW5nICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDEwDQogICAgICA1LjEuIENoZWNraW5nIENvbnZleGl0 eSBpbiBQSU0tRG9tYWluICAgICAgICAgICAgICAgICAgICAgICAgICAxMA0KICAgICAgICAgNS4x LjEuIFNlbmRpbmcgdGhlIFBJTS1QSU5HIFJlcXVlc3QgbWVzc2FnZSAgICAgICAgICAgICAgICAg MTANCiAgICAgICAgIDUuMS4yLiBQcm9jZXNzaW5nIG9mIHRoZSBQSU0tUElORyBwYWNrZXRzIGF0 IHRoZSANCiAgICAgICAgICAgICAgICBpbnRlcm1lZGlhdGUgUm91dGVycyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDEwDQogICAgICAgICA1LjEuMyBQcm9jZXNzaW5nIG9mIHRoZSBQ SU0tUElORyByZXF1ZXN0IHBhY2tldCBhdCB0aGUgDQogICAgICAgICAgICAgICBmaXJzdGhvcCBy b3V0ZXIgdG93YXJkcyBkZXN0aW5hdGlvbiBvciANCiAgICAgICAgICAgICAgIGF0IGRlc3RpbmF0 aW9uLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDEwIA0KICAgICAgNS4y LiBDaGVja2luZyBmb3IgdGhlIFJQIGNvbnNpc3RlbmN5IGFsb25nIGEgcGF0aCAgICAgICAgICAg ICAgMTAgIA0KICAgICAgICAgNS4yLjEgU2VuZGluZyB0aGUgUElNLVBJTkcgbWVzc2FnZSB0byB2 ZXJpZnkgUlAgY29uc2lzdGVuY3kgMTENCiAgICAgICAgIDUuMi4yIFByb2Nlc3Npbmcgb2YgdGhl IFBJTS1QSU5HIFJQIGNvbnNpc3RlbmN5IG1lc3NhZ2VzIA0KICAgICAgICAgICAgICAgYXQgdGhl IGludGVybWVkaWF0ZSByb3V0ZXJzLiAgICAgICAgICAgICAgICAgICAgICAgICAgMTENCiAgICAg ICAgIDUuMi4zIFByb2Nlc3Npbmcgb2YgdGhlIFBJTS1QSU5HIFJQIGNvbnNpc3RlbmN5ICBtZXNz YWdlcyANCiAgICAgICAgICAgICAgIGF0IGRlc3RpbmF0aW9uLiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDExDQogICAgICA1LjMuIFJlcXVlc3QgVHlwZXMgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAxMg0KICAgICAgNS40LiBSZXNwb25z ZSBUeXBlcyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMTINCjYu ICBQcm9jZXNzaW5nIHRoZSByZWNlaXZlZCByZXNwb25zZSBtZXNzYWdlICAgICAgICAgICAgICAg ICAgICAgICAgIDEzDQo3LiAgTWVzc2FnZSBWZXJpZmljYXRpb25zICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAxMw0KOC4gIFJlZmVyZW5jZXMgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMTQNCjkuICBBdXRob3KS cyBBZGRyZXNzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDE0DQoxMC4gQ29weXJpZ2h0IChDKSBUaGUgSUVURiBUcnVzdCAoMjAwNykgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAxNQ0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K QXJjaGFuYS9KYW5hcmRoYW4gICAgICAgICAgICBQSU0tUElORyAgICAgICAgICAgICAgIFtQYWdl IDJdDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgIEV4cDogRGVjIDIwMDcgICAgICAgICAg MjggSnVuZSAyMDA3DQoNCg0KDQoNCg0KDQoNCkp1c3RpZmljYXRpb24NCg0KTXVsdGljYXN0IHRl Y2hub2xvZ3kgaGFzIGJlZW4gYXJvdW5kIGZvciBxdWl0ZSBzb21lIHRpbWUgbm93LiBCdXQgDQp3 aWRlc3ByZWFkIGRlcGxveW1lbnQgb2YgbXVsdGljYXN0aW5nIGhhcyBqdXN0IGJlZ3VuLiBBbGwg dGhlc2UgZGF5cywNCm11bHRpY2FzdGluZyB0ZWNobm9sb2d5IHdhcyByZXZvbHZpbmcgYXJvdW5k IGRldmVsb3BpbmcgZWZmaWNpZW50LCANCnNjYWxhYmxlIHJvdXRpbmcgcHJvdG9jb2xzLiBOb3cg dGhhdCwgbXVsdGljYXN0IHJvdXRpbmcgcHJvdG9jb2xzIGFyZQ0KbWF0dXJlZCwgUElNU1NNIGFu ZCBQSU1TTSBoYXZlIGVzdGFibGlzaGVkIHRoZW1zZWx2ZXMgYXMgcHJpbmNpcGFsIA0KbXVsdGlj YXN0IHJvdXRpbmcgcHJvdG9jb2xzLCBzaW5jZSBtYW55IGFwcGxpY2F0aW9ucyBhcmUgdXNpbmcg DQptdWx0aWNhc3RpbmcgYXMgdGhlaXIgYmFzZSB0ZWNobm9sb2d5LCBpdCBpcyB0aGUgdGltZSB0 byBhZGRyZXNzIA0Kb3RoZXIgYXNwZWN0cyBsaWtlIGRlYnVnZ2luZywgdHJvdWJsZSBzaG9vdGlu ZyBhbmQgZXJyb3IgcmVwb3J0aW5nLiANCk1vc3Qgb2YgdGhlIHdvcmsgdGhhdCBoYXMgYmVlbiBk b25lIHNvIGZhciBpbiB0aGVzZSBhcmVhcywgZWl0aGVyDQpkZXBlbmQgb24gbXVsdGljYXN0IHRy ZWUgYmVpbmcgc2V0IHVwIG9yIHN1cHBvcnQgZnJvbSBJUCwgYW5kIE1JQlMuIA0KQnV0IGl0IGlz IG91ciBvcGluaW9uIHRoYXQsIG11bHRpY2FzdCByb3V0aW5nIHByb3RvY29scyBzaG91bGQgaW4g DQp0aGVtc2VsdmVzIGVtYmVkIG5lY2Vzc2FyeSBtZWNoYW5pc21zIHRvIGFkZHJlc3MgdGhlc2Ug aXNzdWVzLCBldmVuIGlmDQppdCBtZWFucyBwcm90b2NvbCBpbXBsZW1lbnRhdGlvbnMgbmVlZHMg dG8gYmUgdHdlYWtlZC4gQWxzbywgd2UgDQpzaG91bGQgbm90ZSB0aGF0LCBtb3N0IG9mIG11bHRp Y2FzdCByb3V0aW5nIHByb3RvY29scyB3aGljaCB1c2UgUFVMTA0KbW9kZWwgbGlrZSBQSU1TTSwg UElNU1NNIHdpbGwgY3JlYXRlIGEgbXVsdGljYXN0IHRyZWUgb25seSBpZiB0aGVyZQ0KYXJlIHNv bWUgcmVjZWl2ZXJzIGpvaW4gdGhlIHRyZWUuIFNvLCB0byBnZXQgaW5mb3JtYXRpb24gYWJvdXQg dGhlIA0KcmVhY2hhYmlsaXR5IG9yIHRvIHRyYWNlIHRoZSBwYXRoIG9mIG11bHRpY2FzdCBkYXRh LCBldmVuIGJlZm9yZSANCmNyZWF0aW5nIHRoZSB0cmVlIGl0IGlzIG5lY2Vzc2FyeSB0byBleHRl bmQgdGhlIHByb3RvY29scy4gSW4gdGhpcyANCmRyYWZ0IHdlIHdhbnQgdG8gcHJlc2VudCBzb21l IGV4dGVuc2lvbnMgdG8gUElNLCB3aGljaCBoZWxwIGluIHRyb3VibGUNCnNob290aW5nIFBJTSBy ZWxhdGVkIGlzc3Vlcy4gDQoNCg0KMS4gSW50cm9kdWN0aW9uDQoNClRoaXMgZHJhZnQgZGVzY3Jp YmVzIHNpbXBsZSBleHRlbnNpb25zIHRvIFBJTSBwcm90b2NvbCBzdWl0ZSB0byB0ZXN0DQp0aGUg Y29udmV4aXR5IG9mIHBpbSBkb21haW4gYW5kIFJQIGNvbnNpc3RlbmN5IGZvciBhIG11bHRpY2Fz dCBncm91cCANCmFsb25nIGEgcGF0aC5BIGNvbnZleCBwaW0gZG9tYWluIGltcGxpZXMgdGhhdCBk YXRhIGZyb20gYSBtdWx0aWNhc3QgDQpzb3VyY2UgY2FuIGJlIHJlY2VpdmVkIGlmIHRoZSBzb3Vy Y2UgbGllcyB3aXRoaW4gdGhlIGRvbWFpbi4gSGVuY2UgDQp0aGlzIGZlYXR1cmUgY2FuIGFsc28g YmUgdXNlZCB0byB0ZXN0IHdoZXRoZXIgYSBtdWx0aWNhc3Qgc291cmNlIGNhbiANCmJlIHJlYWNo ZWQgd2l0aGluIGEgcGltIGRvbWFpbiBhbmQgdG8gdGVzdCB3aGV0aGVyIHNvdXJjZSBpcyBzZW5k aW5nDQptdWx0aWNhc3QgZGF0YS4gRm9yIFBJTVNNIHRvIGZ1bmN0aW9uIHByb3Blcmx5LCBpdCBp cyByZXF1aXJlZCB0aGF0LA0KZ3JvdXAgdG8gUlAgbWFwcGluZyBpcyBjb25zaXN0ZW50IGFjcm9z cyB0aGUgcGltIGRvbWFpbi4gU2luY2UsIGdyb3VwDQp0byBSUCBtYXBwaW5nIGlzIGRvbmUgdXNp bmcgdmFyaW91cyBtZWNoYW5pc21zIGxpa2Ugc3RhdGljIA0KY29uZmlndXJhdGlvbnMsIEJTUi1S UCBhbmQgaW4gY2FzZSBvZiBJUFY2IGVtYmVkZGVkIFJQLCBpdCBpcyANCmN1bWJlcnNvbWUgdG8g dHJhY2sgdGhlIGNvbnNpc3RlbmN5IG9mIHRoZSBtYXBwaW5nIGFjcm9zcyBhbGwgdGhlIA0Kcm91 dGVycy4gSGVuY2UgdGhlc2UgZXh0ZW5zaW9ucyB0byBwaW0gcHJvdG9jb2wgc3VpdGUgY2FuIGJl IGhhbmR5IHRvDQpkZWJ1ZyB0aGVzZSBzY2VuYXJpb3MuV2UgY2FsbCB0aGVzZSBleHRlbnNpb25z IGFzIFBJTS1QSU5HLCBzaW5jZSBpdCANCmRvZXMgdGhlIHNhbWUgZnVuY3Rpb24gZm9yIG11bHRp Y2FzdCBhcyBQSU5HIGRvZXMgZm9yIHVuaWNhc3Qgcm91dGluZy4NCiANClBJTS1QSU5HIGFzIGRl c2NyaWJlZCBpbiB0aGlzIGRyYWZ0IGNhbiBiZSB1c2VkIHRvIHNvbHZlIGZvbGxvd2luZw0KcHJv YmxlbXM6DQpvIFRvIHRlc3QgdGhlIGNvbnZleGl0eSBvZiBwaW0gZG9tYWluLCBhbmQgdG8gdGVz dCB3aGV0aGVyIGEgbXVsdGljYXN0DQogIGRhdGEgIHNvdXJjZSBpcyBhY3RpdmUuDQpvIFRvIHRl c3Qgd2hldGhlciBSUCBtYXBwaW5nIGZvciBhIHBhcnRpY3VsYXIgZ3JvdXAgaXMgY29uc2lzdGVu dCwgYXQNCiAgYWxsIHRoZSByb3V0ZXJzLiANCg0KDQpBcmNoYW5hL0phbmFyZGhhbiAgICAgICAg ICAgIFBJTS1QSU5HICAgICAgICAgICAgICAgW1BhZ2UgM10NCklOVEVSTkVULURSQUZUICAgICAg ICAgICAgICAgRXhwOiBEZWMgMjAwNyAgICAgICAgICAyOCBKdW5lIDIwMDcNCg0KDQoNCg0KDQoN Cm8gVG8gdHJhY2UgdGhlIHJvdXRlIHRocm91Z2ggd2hpY2ggbXVsdGljYXN0IGRhdGEgd2lsbCB0 cmF2ZXJzZSwgDQogIHdpdGhpbiBhIHBpbSBkb21haW4uDQpvIFRvIGNhbGN1bGF0ZSBhcHByb3hp bWF0ZWx5IHRoZSB0aW1lIG5lZWRlZCB0byBjb25zdHJ1Y3QgYSBTUFQgb3IgUlBULiANCiAgDQoN Cg0KMi4gVGVybWlub2xvZ3kNCg0KSW4gdGhpcyBkb2N1bWVudCwgdGhlIGtleSB3b3JkcyAiTVVT VCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsDQoiU0hBTEwiLCAiU0hBTEwgTk9UIiwgIlNIT1VM RCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsDQogYW5kICAiT1BUSU9OQUwi IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gUkZDIDIxMTkgWzFdDQphbmQg aW5kaWNhdGUgcmVxdWlyZW1lbnQgbGV2ZWxzIGZvciBjb21wbGlhbnQgUElNLVBJTkcgDQppbXBs ZW1lbnRhdGlvbnMuDQoNCjIuMS4gRGVmaW5pdGlvbnMNCiAgIFRoZSBmb2xsb3dpbmcgdGVybXMg aGF2ZSBzcGVjaWFsIHNpZ25pZmljYW5jZSBmb3IgUElNLVBJTkc6IA0KDQogICBSUEYgSW50ZXJm YWNlDQogICAgICAgICBSUEYgc3RhbmRzIGZvciAiUmV2ZXJzZSBQYXRoIEZvcndhcmRpbmciLiAg VGhlIFJQRiBJbnRlcmZhY2UgDQogICAgICAgICBvZiBhIHJvdXRlciB3aXRoIHJlc3BlY3QgdG8g YW4gYWRkcmVzcyBpcyB0aGUgaW50ZXJmYWNlIHRoYXQNCiAgICAgICAgIHRoZSB1bmljYXN0LXJv dXRpbmcgdGFibGUgaW5kaWNhdGVzIHNob3VsZCBiZSB1c2VkIHRvIHJlYWNoIA0KICAgICAgICAg dGhhdCBhZGRyZXNzLg0KDQogICBSUEYgTmVpZ2hib3INCiAgICAgICAgIFRoZSBSUEYgTmVpZ2hi b3Igb2YgYSByb3V0ZXIgd2l0aCByZXNwZWN0IHRvIGFuIGFkZHJlc3MgaXMgDQogICAgICAgICB0 aGUgbmVpZ2hib3IgdGhhdCB0aGUgVW5pY2FzdCBSb3V0aW5nIFRhYmxlIGluZGljYXRlcyBzaG91 bGQNCiAgICAgICAgIGJlIHVzZWQgdG8gcmVhY2ggdGhhdCBhZGRyZXNzLiANCg0KICAgUElNIE5l aWdoYm9yDQogICAgICAgICBBbnkgYWRqYWNlbnQgcm91dGVyIGZyb20gd2hpY2ggcGltIGhlbGxv IG1lc3NhZ2VzIGFyZSANCiAgICAgICAgIHJlY2VpdmVkLg0KDQogICBSZW5kZXp2b3VzIFBvaW50 IChSUCk6DQogICAgICAgICBSUCBpcyBhIHJvdXRlciB0aGF0IGhhcyBiZWVuIGNvbmZpZ3VyZWQg dG8gYmUgdXNlZCBhcyB0aGUNCiAgICAgICAgIHJvb3Qgb2YgdGhlIG5vbi1zb3VyY2Utc3BlY2lm aWMgZGlzdHJpYnV0aW9uIHRyZWUgZm9yIGEgDQogICAgICAgICBtdWx0aWNhc3QgZ3JvdXAuICBK b2luIG1lc3NhZ2VzIGZyb20gcmVjZWl2ZXJzIGZvciBhIGdyb3VwIA0KICAgICAgICAgYXJlIHNl bnQgdG93YXJkcyB0aGUgUlAsIGFuZCBkYXRhIGZyb20gc2VuZGVycyBpcyBzZW50IHRvIA0KICAg ICAgICAgdGhlIFJQIHNvIHRoYXQgcmVjZWl2ZXJzIGNhbiBkaXNjb3ZlciB3aG8gdGhlIHNlbmRl cnMgYXJlLCANCiAgICAgICAgIGFuZCBzdGFydCB0byByZWNlaXZlIHRyYWZmaWMgZGVzdGluZWQg Zm9yIHRoZSBncm91cC4NCg0KDQoNCg0KDQoNCg0KDQpBcmNoYW5hL0phbmFyZGhhbiAgICAgICAg ICAgIFBJTS1QSU5HICAgICAgICAgICAgICAgW1BhZ2UgNF0NCklOVEVSTkVULURSQUZUICAgICAg ICAgICAgICAgRXhwOiBEZWMgMjAwNyAgICAgICAgICAyOCBKdW5lIDIwMDcNCg0KDQoNCg0KDQoN Cg0KMy4gUElNLVBJTkcgT3ZlcnZpZXcNCg0KVGhpcyBkb2N1bWVudCBhc3N1bWVzIHNvbWUgZmFt aWxpYXJpdHkgd2l0aCB3b3JraW5nIG9mIFBJTSBwcm90b2NvbCANCnN1aXRlLCBzcGVjaWFsbHkg UElNU00gb3IgUElNU1NNLiBQSU0tUElORyB1c2VzIGEgMiBuZXcgUElNIE1lc3NhZ2UNCnR5cGVz LCByZXF1ZXN0IGFuZCByZXNwb25zZSBtZXNzYWdlIHdoaWNoIGFyZSB2ZXJ5IHNpbWlsYXIgdG8g UElNIA0KSm9pbi9wcnVuZSBtZXNzYWdlcy5UaGVzZSBtZXNzYWdlcyBkbyBub3QgY3JlYXRlIGFu eSBzdGF0ZSBhdCB0aGUgDQppbnRlcm1lZGlhdGUgcm91dGVycywgYnV0IGl0IGRvZXMgaW52b2x2 ZSBwcm9jZXNzaW5nIG9mIHRoZXNlIA0KbWVzc2FnZXMgYnkgYWxsIHRoZSByb3V0ZXJzLg0KDQpQ SU0tUElORyB1c2VzIGEgbWV0aG9kIHZlcnkgc2ltaWxhciB0byBidWlsZGluZyBhIFNQVCBvciBS UFQgaW4gUElNU00gDQoob3IgUElNU1NNKSwgdG8gdGVzdCB0aGUgY29udmV4aXR5IG9mIFBJTSBk b21haW4sIG9yIHRvIGRvIHRoZSBSUCANCmNvbnNpc3RlbmN5LiBBIHJvdXRlciBnZW5lcmF0ZXMg cmVxdWVzdCBtZXNzYWdlIHdoaWNoIHdpbGwgYmUgDQpwcm9wYWdhdGVkIGhvcCBieSBob3AgdG93 YXJkcyB0aGUgZGVzdGluYXRpb24gcm91dGVyLiBJZiB0aGUgYW55IG9mIA0KdGhlIGludGVybWVk aWF0ZSByb3V0ZXJzIGZhaWwgdG8gcHJvcGFnYXRlIHRoZSBtZXNzYWdlLCB0aGV5IHdpbGwgDQpn ZW5lcmF0ZSByZXNwb25zZSBtZXNzYWdlIGJhY2sgdG8gcm91dGVyIHdoaWNoIG9yaWdpbmF0ZWQg dGhlIHJlcXVlc3QuDQpJZiB0aGUgcmVxdWVzdCBtZXNzYWdlIHJlYWNoZXMgdGhlIGRlc3RpbmF0 aW9uIHN1Y2Nlc3NmdWxseSwgYSANCnJlc3BvbnNlIG1lc3NhZ2UgaW5kaWNhdGluZyB0aGUgc3Vj Y2VzcyB3aWxsIGJlIGdlbmVyYXRlZCBhbmQgc2VudCB0bw0KdGhlIG9yaWdpbmF0b3Igb2YgcmVx dWVzdC4NCg0KQWx0aG91Z2ggdGhpcyBmZWF0dXJlIGNhbiBiZSB1c2VkIGZvciBib3RoIElQVjQg YW5kIElQVjYgdmVyc2lvbnMgb2YNClBJTSBwcm90b2NvbHMsIGhlcmUgSVBWNCBpcyB1c2VkIHRv IGRlbW9uc3RyYXRlIHRoZSB3b3JraW5nIG9mIA0KUElNLVBJTkcuDQoNCkNvbnNpZGVyIHRoZSBm b2xsb3dpbmcgdG9wb2xvZ3k6DQoNCiAgICAgICAgICAgICAgIDEwLjAuMC4wICAgICAgICAyMC4w LjAuMCAgICAgIDMwLjAuMC4wICAgNDAuMC4wLjAgDQogICBbU10tLS0tLVIxLS0tLS0tLS0tLS0t UjItLS0tLS0tLS0tLS0tUjMtLS0tLS0tLS0tUjQtLS0tLS0tLS0tW1I1XQ0KICAgICAgICAgICAg LjEgICAgICAgICAgLjIgIC4xICAgICAgICAuMiAgLjEgICAgICAuMiAuMSAgICAgICAgIC4yDQoN Cg0KU3VwcG9zZSBhdCBSNSwgdXNlciB3YW50cyB0byB0ZXN0IHRoZSByZWFjaGFiaWxpdHkgb2Yg bXVsdGljYXN0IHNvdXJjZSBTLA0Kd2hpY2ggaXMgc2VuZGluZyBtdWx0aWNhc3QgZGF0YSBmb3Ig Z3JvdXAgRy4gU28sIHJvdXRlciBSNSANCmdlbmVyYXRlcyByZXF1ZXN0IG1lc3NhZ2UsIHdpdGgg dHlwZSBhcyBQSU1QSU5HX0NPTlZFWElUWV9URVNULCANCihyZXF1ZXN0IG1lc3NhZ2UgdHlwZXMg YXJlIGV4cGxhaW5lZCBpbiBkZXRhaWwgbGF0ZXIpIGFuZCBzZW5kcyBpdCB0bw0KdGhlIFJQRiBu ZWlnaGJvciBvZiBTLCB3aGljaCBpbiB0aGlzIGV4YW1wbGUgaXMgUjQuIA0KUjQgb24gcmVjZXB0 aW9uIG9mIHRoaXMgcGFja2V0LCBpbiB0dXJuIHNlbmRzIHRoaXMgcGFja2V0IHRvIFIzLCANCldo aWNoIGlzIFJQRiBuZWlnaGJvciBvZiBTIGF0IFIzLiBUaGlzIHByb2Nlc3MgY29udGludWVzIHRp bGwgZWl0aGVyDQptZXNzYWdlIHJlYWNoZXMgUjEgb3Igb25lIG9mIHRoZSByb3V0ZXIgZmFpbHMg dG8gcHJvcGFnYXRlIHRoZSANCm1lc3NhZ2UuSW4gdGhlIGZvcm1lciBjYXNlLCBSMSBiZWluZyB0 aGUgbGFzdCBob3Agcm91dGVyIGFuZCBzaW5jZSBpdA0KcmVjb2duaXplcyB0aGF0IFMgaXMgYSBk aXJlY3RseSBjb25uZWN0ZWQgbXVsdGljYXN0IGRhdGEgc291cmNlLCBpdCANCnNlbmRzIGJhY2sg YSB1bmljYXN0IHJlcGx5IHRvIFI1LCBpbmRpY2F0aW5nIHRoZSBzdWNjZXNzLg0KDQpJbiBjYXNl IG9mIGZhaWx1cmUsIHdoZXJlIG1lc3NhZ2UgY2Fubm90IGJlIHByb3BhZ2F0ZWQgYnkgYSByb3V0 ZXIsYW4gDQphcHByb3ByaWF0ZSByZXNwb25zZSBtZXNzYWdlIHdpbGwgYmUgZ2VuZXJhdGVkIGJ5 IHRoZSByb3V0ZXIgYW5kIHdpbGwNCmJlIHNlbnQgYmFjayB0byBSNS4NCg0KDQoNCkFyY2hhbmEv SmFuYXJkaGFuICAgICAgICAgICAgUElNLVBJTkcgICAgICAgICAgICAgICBbUGFnZSA1XQ0KSU5U RVJORVQtRFJBRlQgICAgICAgICAgICAgICBFeHA6IERlYyAyMDA3ICAgICAgICAgIDI4IEp1bmUg MjAwNw0KDQoNCg0KDQoNCg0KDQpBIHNpbWlsYXIgaWRlYSBpcyB1c2VkIHRvIGNoZWNrIHRoZSBS UCBjb25zaXN0ZW5jeSBhbG9uZyBhIHBhdGguIA0KVGFraW5nIHRoZSBhYm92ZSBleGFtcGxlLCBz dXBwb3NlIHVzZXIgd2FudHMgdG8gdGVzdCB3aGV0aGVyIGFsbCB0aGUgDQpyb3V0ZXJzIGZyb20g UjUgdG8gUjIgdXNlIHNhbWUgUlAgZm9yIGEgcGFydGljdWxhciBtdWx0aWNhc3QgZ3JvdXAgRy4N ClRvIHZlcmlmeSB0aGlzLCBSNSB3aWxsIG9yaWdpbmF0ZSBhIHJlcXVlc3QgbWVzc2FnZSB3aXRo IHR5cGUgYXMNClBJTVBJTkdfUlBDT05TSVNURU5DWV9URVNULiBJdCBwdXRzIHRoZSBncm91cCBh ZGRyZXNzIGFuZCBSUCBpdCBpcw0KdXNpbmcgZm9yIHRoYXQgZ3JvdXAgaW4gdGhlIHBhY2tldCBh bmQgc2VuZHMgaXQgdG8gdGhlIFJQRiBuZWlnaGJvciANCm9mIGRlc3RpbmF0aW9uICh3aGljaCBp cyBSMiBub3cpLiBXaGVuIHRoZSBwYWNrZXQgcmVhY2hlcyByb3V0ZXIgUjQsIA0KaXQgdmVyaWZp ZXMgd2hldGhlciBSUCBmb3IgZ3JvdXAgRyBpdCBpcyB1c2luZyBpcyBzYW1lIGFzIG9uZSBpbiB0 aGUgDQpwYWNrZXQgaXQgaGFzIGdvdC4gSWYgdGhlIFJQIGJlaW5nIHVzZWQgbWlzbWF0Y2gsIGEg cmVzcG9uc2UgbWVzc2FnZQ0KaXMgdW5pY2FzdGVkIGJhY2sgdG8gUjUuIElmIFJQIGFkZHJlc3Nl cyBtYXRjaCB0aGVuIGl0IHByb3BhZ2F0ZXOSIA0KdGhlIHBhY2tldCB0byBSUEYgbmVpZ2hib3Ig b2YgZGVzdGluYXRpb24uIFRoaXMgY29udGludWVzIHRpbGwgdGhlIA0KcGFja2V0IHJlYWNoZXMg UjIuIEhlcmUgUjIgYmVpbmcgdGhlIGRlc3RpbmF0aW9uIHdpbGwgc2VuZCBhIHJlc3BvbnNlDQpt ZXNzYWdlIGJhY2sgdG8gUjUsIGluZm9ybWluZyB0aGUgY29uc2lzdGVuY3kgb2YgUlAgYWRkcmVz c2VzIGFsb25nIA0KdGhlIHBhdGguIElmLCBhbnkgcm91dGVyIGZhaWxzIHRvIHByb3BhZ2F0ZSB0 aGUgcGFja2V0LCBlaXRoZXIgZHVlIHRvDQpSUCBpbmNvbnNpc3RlbmN5IG9yLCBkdWUgdG8gb3Ro ZXIgcHJvYmxlbXMgbGlrZSBoYXZpbmcgbm8gUElNIA0KbmVpZ2hib3JzLCBhbiBhcHByb3ByaWF0 ZSByZXNwb25zZSBtZXNzYWdlIHdpbGwgYmUgZ2VuZXJhdGVkIGJhY2sgdG8NClI1Lg0KICANClJv dXRlcnMgYWxzbyBhcHBlbmQgdGhlaXIgSVB2NC9JUFY2IGFkZHJlc3NlcyBpbiB0aGUgcmVxdWVz dCBtZXNzYWdlLCANCndoZW4gdGhleSBwcm9wYWdhdGUgdGhlIG1lc3NhZ2UgdG93YXJkcyBkZXN0 aW5hdGlvbi4gVGhpcyBsaXN0IG9mIA0Kcm91dGVyIGFkZHJlc3NlcyBpcyB1c2VkIHRvIHRyYWNl IHRoZSBwYXRoIHRvd2FyZHMgbXVsdGljYXN0IGRhdGENCnNvdXJjZS4NCg0KNC4gUElNLVBJTkcg UGFja2V0IEZvcm1hdA0KDQpQSU0tUGluZyB1c2VzIDIgdHlwZXMgb2YgbWVzc2FnZXMNCg0KbyBS ZXF1ZXN0IE1lc3NhZ2UgOiBUaGlzIG1lc3NhZ2UgaXMgZ2VuZXJhdGVkIGJ5IHRoZSByb3V0ZXIg d2hpY2ggDQogIHdhbnRzIHRvIHVzZSBQSU0tUElORyBmdW5jdGlvbmFsaXR5IG1lbnRpb25lZCBh Ym92ZS4gUmVxdWVzdCANCiAgcGFja2V0IGZvcm1hdCBhbmQgZmllbGRzIGFyZSBkZXNjcmliZWQg aW4gdGhlIHNlY3Rpb24gNC4xLg0KDQpvIFJlc3BvbnNlIE1lc3NhZ2UgOiBUaGlzIG1lc3NhZ2Ug aXMgIGdlbmVyYXRlZCBieSB0aGUgDQogIGZpcnN0aG9wIHJvdXRlciBmb3IgZGVzdGluYXRpb24g b3IgZGVzdGluYXRpb24gUm91dGVyIG9yIA0KICBpbnRlcm1lZGlhdGUgcm91dGVycyBpbiBjYXNl IG9mIGZhaWx1cmUsIGZvciBhIHBhcnRpY3VsYXIgcmVxdWVzdC4NCiAgVGhlIG1lc3NhZ2UgZm9y bWF0IGlzIGRlc2NyaWJlZCBpbiBkZXRhaWwgaW4gdGhlIHNlY3Rpb24gNC4yLg0KDQoNCjQuMSBS ZXF1ZXN0IE1lc3NhZ2U6DQoNCkFsbCBQSU0gY29udHJvbCBtZXNzYWdlcyBoYXZlIElQIHByb3Rv Y29sIG51bWJlciAxMDMuDQpQSU0tUElORyByZXF1ZXN0IG1lc3NhZ2UgaXMgbXVsdGljYXN0IHdp dGggVFRMIDEgdG8gdGhlIA0KYEFMTC1QSU0tUk9VVEVSUycgR3JvdXAuIFRoZSBJUHY0IGBBTEwt UElNLVJPVVRFUlMnIGdyb3VwIGlzIA0KYDIyNC4wLjAuMTMnLiAgVGhlIElQdjYgYEFMTC1QSU0t Uk9VVEVSUycgZ3JvdXAgaXMgYGZmMDI6OmQnLg0KSW4gY2FzZSBvZiBJUFY2LCB0aGUgc291cmNl IGFkZHJlc3MgdXNlZCBmb3IgcmVxdWVzdCBNZXNzYWdlIGlzIHRoZQ0KbGluay1sb2NhbCBhZGRy ZXNzIG9mIHRoZSBpbnRlcmZhY2Ugb24gd2hpY2ggdGhlIG1lc3NhZ2UgaXMgYmVpbmcgDQpzZW50 Lg0KDQoNCkFyY2hhbmEvSmFuYXJkaGFuICAgICAgICAgICAgUElNLVBJTkcgICAgICAgICAgICAg ICBbUGFnZSA2XQ0KSU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICBFeHA6IERlYyAyMDA3ICAg ICAgICAgIDI4IEp1bmUgMjAwNw0KDQoNCg0KDQoNCg0KDQpGb2xsb3dpbmcgaXMgdGhlIFBJTS1Q aW5nIFJlcXVlc3QgbWVzc2FnZXMgZm9ybWF0Og0KDQogICAgMCAgICAgICAgICAgICAgICAgICAx ICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMw0KICAgIDAgMSAyIDMgNCA1 IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsNCiAgIHxQSU0gVmVyfCBUeXBlICB8ICAgUmVzZXJ2ZWQgICAgfCAgICAgICAgICAg Q2hlY2tzdW0gICAgICAgICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCAgICAgICAgVXBzdHJlYW0g TmVpZ2hib3IgQWRkcmVzcyAoRW5jb2RlZC1VbmljYXN0IGZvcm1hdCkgICAgIHwNCiAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rDQogICB8cmVxdWVzdC9yZXNwb25zZXwgICAgICBOQSAgICAgIHwgICAgICAgICAgU2VxdWVu Y2UgTnVtYmVyICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwgICAgICAgICAgICBEZXN0aW5hdGlv biBhZGRyZXNzLiAgKEVVRikgICAgICAgICAgICAgICAgICAgICAgICB8DQogICB8ICAgICAgICAg IChOb3JtYWxseSBhIE11bHRpY2FzdCBkYXRhIHNvdXJjZSkgICAgICAgICAgICAgICAgICAgfA0K ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsNCiAgIHwgICAgICAgICAgTXVsdGljYXN0IEdyb3VwIGFkZHJlc3MgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8DQogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwg ICAgICAgICAgICBUaGUgUlAgYWRkcmVzcyBVc2VkICAoRVNGKSAgICAgICAgICAgICAgICAgICAg ICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKw0KICAgfCAgIE51bWJlciBvZiBSb3V0ZXJzICAgICAgICAgICB8 ICAgTkEgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8ICAgICAg ICBSb3V0ZXIgQWRkcmVzcyAxIChPcmlnaW5hdG9yIG9mIHJlcXVlc3QpKEVTRikgICAgICAgICAg fA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsNCiAgIHwgICAgICAgIFJvdXRlciBBZGRyZXNzIDIgKEVuY29kZWQtVW5p Y2FzdCBmb3JtYXQpIChFVUYpICAgICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCAgICAgICAgUm91dGVyIEFkZHJlc3MgbiAoRW5j b2RlZC1VbmljYXN0IGZvcm1hdCkgICAgICAgICAgICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoNClBJTSBW ZXINCiAgICAgICAgUElNIFZlcnNpb24gbnVtYmVyIGlzIDIuDQoNClR5cGUNCiAgICAgICAgVHlw ZSBmb3IgUElNLVBpbmcgcGFja2V0IGlzIDE0DQoNClJlc2VydmVkDQogICAgICAgIFNldCB0byB6 ZXJvIG9uIHRyYW5zbWlzc2lvbi4gIElnbm9yZWQgdXBvbiByZWNlaXB0Lg0KDQpDaGVja3N1bQ0K ICAgICAgICBUaGUgY2hlY2tzdW0gaXMgYSBzdGFuZGFyZCBJUCBjaGVja3N1bSwgaS5lLix0aGUg MTYtYml0IG9uZSdzDQogICAgICAgIGNvbXBsZW1lbnQgb2YgdGhlIG9uZSdzIGNvbXBsZW1lbnQg c3VtIG9mIHRoZSBlbnRpcmUgUElNDQogICAgICAgIG1lc3NhZ2UuICBGb3IgY29tcHV0aW5nIHRo ZSBjaGVja3N1bSwgdGhlIGNoZWNrc3VtDQogICAgICAgIGZpZWxkIGlzIHplcm9lZC4gIElmIHRo ZSBwYWNrZXQncyBsZW5ndGggaXMgbm90IGFuIGludGVncmFsDQogICAgICAgIG51bWJlciBvZiAx Ni1iaXQgd29yZHMsIHRoZSBwYWNrZXQgaXMgcGFkZGVkIHdpdGggYSB0cmFpbGluZw0KICAgICAg ICBieXRlIG9mIHplcm8gYmVmb3JlIHBlcmZvcm1pbmcgdGhlIGNoZWNrc3VtLg0KDQpBcmNoYW5h L0phbmFyZGhhbiAgICAgICAgICAgIFBJTS1QSU5HICAgICAgICAgICAgICAgW1BhZ2UgN10NCklO VEVSTkVULURSQUZUICAgICAgICAgICAgICAgRXhwOiBEZWMgMjAwNyAgICAgICAgICAyOCBKdW5l IDIwMDcNCg0KDQoNCg0KDQoNCg0KICAgICAgICBGb3IgSVB2NiwgdGhlIGNoZWNrc3VtIGFsc28g aW5jbHVkZXMgdGhlIElQdjYgDQogICAgICAgICJwc2V1ZG8taGVhZGVyIixhcyBzcGVjaWZpZWQg aW4gUkZDIDI0NjAsIFNlY3Rpb24gOC4xIFs1XS4NCiAgICAgICAgVGhpcyAicHNldWRvLWhlYWRl ciIgaXMgcHJlcGVuZGVkIHRvIHRoZSBQSU0gaGVhZGVyIGZvciANCiAgICAgICAgdGhlIHB1cnBv c2VzIG9mIGNhbGN1bGF0aW5nIHRoZSBjaGVja3N1bS4gIFRoZSAiVXBwZXItTGF5ZXINCiAgICAg ICAgUGFja2V0IExlbmd0aCIgaW4gdGhlIHBzZXVkby1oZWFkZXIgaXMgc2V0IHRvIHRoZSBsZW5n dGggb2YNCiAgICAgICAgdGhlIFBJTSBtZXNzYWdlLiAgVGhlIE5leHQgSGVhZGVyIHZhbHVlIHVz ZWQgaW4gdGhlIA0KICAgICAgICBwc2V1ZG8taGVhZGVyIGlzIDEwMy4NCg0KVXBzdHJlYW0gTmVp Z2hib3IgQWRkcmVzcw0KICAgICAgICBUaGUgdXBzdHJlYW0gbmVpZ2hib3IgYWRkcmVzcyBpcyB0 aGUgUlBGIG5laWdoYm9yIGFkZHJlc3MgZm9yDQogICAgICAgIHRoZSBkZXN0aW5hdGlvbiBhcyBp bmRpY2F0ZWQgYnkgdGhlIHVuaWNhc3QgUklCLiBVbmljYXN0IA0KICAgICAgICBFbmNvZGluZyBG b3JtYXQgdXNlZCBpcyBzYW1lIGFzIG1lbnRpb25lZCBpbiBTZWN0aW9uIDQuOS4xLA0KICAgICAg ICBSRkMgNDYwMS4NCg0KUmVxdWVzdCBUeXBlIA0KICAgICAgICBSZXF1ZXN0IFR5cGVzIGFyZSBt ZW50aW9uZWQgaW4gU2VjdGlvbiA1LjMuDQogICAgICAgICAgICAgIA0KTkENCiAgICAgICAgRmll bGQgd2lsbCBiZSBzZXQgYXMgemVyby4NCg0KU2VxdWVuY2UgTnVtYmVyIA0KICAgICAgICBSYW5k b21seSBnZW5lcmF0ZWQgbnVtYmVyIHRvIGlkZW50aWZ5IHRoZSByZXF1ZXN0IG1lc3NhZ2UuDQoN CkRlc3RpbmF0aW9uIGFkZHJlc3MNCiAgICAgICAgRGVzdGluYXRpb24gYWRkcmVzcyBpcyB0aGUg YWRkcmVzcyBvZiB0aGUgcm91dGVyLCBvciANCiAgICAgICAgbXVsdGljYXN0IHNvdXJjZSwgdGhl IHBhdGggb2Ygd2hpY2ggaXMgYmVpbmcgdGVzdGVkIGZvciANCiAgICAgICAgY29udmV4aXR5IG9y IFJQIGNvbnNpc3RlbmN5LiANCg0KR3JvdXAgQWRkcmVzcyANCiAgICAgICAgVGhpcyBmaWVsZCBj b250YWlucyB0aGUgbXVsdGljYXN0IGdyb3VwIGFkZHJlc3MgaW4gZW5jb2RlZCANCiAgICAgICAg Z3JvdXAgZm9ybWF0LCBmb3Igd2hpY2ggUlAgY29uc2lzdGVuY3kgY2hlY2sgaXMgYmVpbmcgY2Fy cmllZA0KICAgICAgICBvdXQuIElmIHRoZSByZXF1ZXN0IHR5cGUgaXMgUElNUElOR19DT05WRVhJ VFlfVEVTVCx0aGlzIGZpZWxkDQogICAgICAgIHdpbGwgYmUgc2V0IHRvIDAsIGFuZCBzaG91bGQg YmUgaWdub3JlZCBieSB0aGUgcm91dGVycy4NCg0KUlAgQWRkcmVzcw0KICAgICAgICBUaGlzIGZp ZWxkIGNvbnRhaW5zIHRoZSBSUCBiZWluZyB1c2VkIGZvciBhIG11bHRpY2FzdCBncm91cCANCiAg ICAgICAgYWRkcmVzcyBhdCBhIHJvdXRlci4gSWYgdGhlIHJlcXVlc3QgdHlwZSBpcyANCiAgICAg ICAgUElNUElOR19DT05WRVhJVFlfVEVTVCwgdGhpcyBmaWVsZCB3aWxsIGJlIHNldCB0byAwLCBh bmQgDQogICAgICAgIHNob3VsZCBiZSBpZ25vcmVkIGJ5IHRoZSByb3V0ZXJzLg0KDQpOdW1iZXIg b2Ygcm91dGVycyANCiAgICAgICAgVGhpcyBmaWVsZCBnaXZlcyB0aGUgbnVtYmVyIG9mIHJvdXRl ciBhZGRyZXNzZXMgYXBwZW5kZWQgaW4gDQogICAgICAgIHRoZSByb3V0ZXIgYWRkcmVzcyBsaXN0 Lg0KDQoNCg0KDQoNCkFyY2hhbmEvSmFuYXJkaGFuICAgICAgICAgICAgUElNLVBJTkcgICAgICAg ICAgICAgICBbUGFnZSA4XQ0KSU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICBFeHA6IERlYyAy MDA3ICAgICAgICAgIDI4IEp1bmUgMjAwNw0KDQoNCg0KDQoNCg0KDQpSb3V0ZXIgQWRkcmVzcw0K ICAgICAgICBFdmVyeSByb3V0ZXIgd2hlbiBpdCBwcm9wYWdhdGVzIHRoZSByZXF1ZXN0IG1lc3Nh Z2Ugd2lsbCBhbHNvIA0KICAgICAgICBhcHBlbmQgaXRzIG93biBhZGRyZXNzIHRvIHRoZSByZXF1 ZXN0IG1lc3NhZ2UuIFRoZSBmaXJzdCANCiAgICAgICAgYWRkcmVzcyBpbiB0aGlzIGxpc3QgaXMg dGhhdCBvZiB0aGUgcm91dGVyIHdoaWNoIGluaXRpYXRlZCANCiAgICAgICAgdGhpcyByZXF1ZXN0 LCBpcyB1c2VkIGFzIGRlc3RpbmF0aW9uIGFkZHJlc3MgdG8gZ2VuZXJhdGUgdGhlIA0KICAgICAg ICByZXNwb25zZSBtZXNzYWdlLiBUaGUgbGlzdCBvZiByb3V0ZXIgYWRkcmVzc2VzIGhlbHBzIGlu IA0KICAgICAgICB0cmFjaW5nIHRoZSBtdWx0aWNhc3QgcGF0aCB0b3dhcmRzIGEgIHBhcnRpY3Vs YXIgZGVzdGluYXRpb24uDQogICAgICAgIFRoZSBhZGRyZXNzIGFwcGVuZGVkIGlzIGFsd2F5cyBn bG9iYWwgcm91dGFibGUgdW5pY2FzdCANCiAgICAgICAgYWRkcmVzcywgcHJlc2VudCBvbiB0aGUg UlBGIGludGVyZmFjZSBvbiB3aGljaCBtZXNzYWdlIHdpbGwgDQogICAgICAgIGJlIHByb3BhZ2F0 ZWQuDQoNCjQuMiBUaGUgUmVzcG9uc2UgTWVzc2FnZSBGb3JtYXQ6DQoNClRoZSByZXNwb25zZSBt ZXNzYWdlIGlzIHNhbWUgYXMgdGhlIHJlcXVlc3QgbWVzc2FnZSwgZXhjZXB0IHRoZSANCmZvbGxv d2luZyAyIGRpZmZlcmVuY2VzLg0KICAgIG8gUmVxdWVzdCB0eXBlIGZpZWxkIGJlY29tZXMgUmVz cG9uc2UgdHlwZS4NCiAgICBvIFdoZW4gdGhlIHJlc3BvbnNlIGlzIGZvciBSUCBjb25zaXN0ZW5j eSwgdGhlIJNUaGUgUlAgYWRkcmVzcyANCiAgICAgIGZpZWxklCwgd2lsbCBpbmRpY2F0ZSwgaW4g ZmFpbHVyZSBjYXNlcywgdGhlIFJQIGFkZHJlc3MgdXNlZA0KICAgICAgZm9yIGEgcGFydGljdWxh ciBncm91cCwgYXQgdGhlIHJvdXRlciB3aGVyZSBSUJJzIHVzZWQgZm9yIGEgDQogICAgICBwYXJ0 aWN1bGFyIG11bHRpY2FzdCBncm91cCBhZGRyZXNzIG1pc21hdGNoLg0KDQpQSU0tUElORyByZXNw b25zZSBtZXNzYWdlIGhhcyBJUCBwcm90b2NvbCBudW1iZXIgMTAzLg0KDQpUaGUgcmVzcG9uc2Ug bWVzc2FnZSBpcyB1bmljYXN0ZWQgdG8gb3JpZ2luYXRvciBvZiB0aGUgcmVxdWVzdC4gDQpBZGRy ZXNzIG9mIHRoZSBvcmlnaW5hdG9yIG9mIHJlcXVlc3QsIGlzIGdvdCBmcm9tIGZpcnN0IGFkZHJl c3Mgb2YgDQp0aGUgcm91dGVycyBsaXN0IGZyb20gcmVxdWVzdCBtZXNzYWdlLiAgVGhlIHNvdXJj ZSBhZGRyZXNzIHVzZWQgZm9yDQpyZXNwb25zZSBtZXNzYWdlIGlzIGEgZG9tYWluLXdpZGUgcmVh Y2hhYmxlIHVuaWNhc3Qgcm91dGFibGUgYWRkcmVzcy4NCg0KVFRMIHZhbHVlIGZvciByZXNwb25z ZSBtZXNzYWdlIGlzIHNhbWUgYXMgVFRMIHZhbHVlIHVzZWQgYnkgdW5pY2FzdCANCnBhY2tldCBv biB0aGF0IHJvdXRlci4NCg0KVXBzdHJlYW0gTmVpZ2hib3IgQWRkcmVzcw0KICAgICAgVXBzdHJl YW0gTmVpZ2hib3IgYWRkcmVzcyBpcyBzZXQgdG8gMCBieSBzZW5kZXIgYW5kDQogICAgICBpcyBp Z25vcmVkIGJ5IHJlY2VpdmVyLg0KDQpSZXNwb25zZSBUeXBlDQogICAgICBSZXNwb25zZSB0eXBl IHZhbHVlcyBhcmUgbWVudGlvbmVkIGluIFNlY3Rpb24gNS43Lg0KDQpBbGwgb3RoZXIgZmllbGRz IG9mIHRoZSByZXNwb25zZSBtZXNzYWdlIHNoYWxsIHJlbWFpbiBzYW1lIGFzIA0KcmVjZWl2ZWQg cmVxdWVzdCBwYWNrZXQgZm9yIHdoaWNoIHJlc3BvbnNlIGlzIGdlbmVyYXRlZC4gDQogICAgICAg ICAgICAgICAgICAgICAgDQogIA0KDQoNCg0KDQoNCg0KQXJjaGFuYS9KYW5hcmRoYW4gICAgICAg ICAgICBQSU0tUElORyAgICAgICAgICAgICAgIFtQYWdlIDldDQpJTlRFUk5FVC1EUkFGVCAgICAg ICAgICAgICAgIEV4cDogRGVjIDIwMDcgICAgICAgICAgMjggSnVuZSAyMDA3DQoNCg0KDQoNCg0K DQoNCjUuICBTcGVjaWZpY2F0aW9uIG9mIFBJTS1QSU5HIGZ1bmN0aW9uYWxpdHkuDQoNCjUuMSAg Q2hlY2tpbmcgdGhlIGNvbnZleGl0eSBvZiBQSU0tRG9tYWluLiANCiANCjUuMS4xIFNlbmRpbmcg dGhlIFBJTS1QSU5HIHJlcXVlc3QgbWVzc2FnZS4NCg0KV2hlbiBhIHJvdXRlciB3YW50cyB0byB2 ZXJpZnkgdGhlIHJlYWNoYWJpbGl0eSBvZiBhIG11bHRpY2FzdCBzb3VyY2UsIA0Kb3Igd2FudHMg dG8gdmVyaWZ5IHRoZSBjb252ZXhpdHkgb2YgUElNIGRvbWFpbiwgaXQgZ2VuZXJhdGVzIGEgDQpy ZXF1ZXN0IG1lc3NhZ2UgYW5kIHNldHMgdGhlIHJlcXVlc3QgdHlwZSBhcyBQSU1QSU5HX0NPTlZF WElUWV9URVNULg0KRGVzdGluYXRpb24gYWRkcmVzcyBhbmQgdXBzdHJlYW0gbmVpZ2hib3IgYWRk cmVzcyBmaWVsZHMgYXJlIGZpbGxlZC4NCkl0IGFsc28gaW5jbHVkZXMgYSBzZXF1ZW5jZSBudW1i ZXIsIHdoaWNoIGlzIGEgcmFuZG9tbHkgZ2VuZXJhdGVkIA0KbnVtYmVyIHRvIGlkZW50aWZ5IHRo ZSByZXF1ZXN0IG1lc3NhZ2UuIE51bWJlciBvZiByb3V0ZXJzIGZpZWxkIGlzIA0Kc2V0IGFzIDEs IElQIGFkZHJlc3MgcHJlc2VudCBvbiB0aGUgUlBGIGludGVyZmFjZSB0b3dhcmRzIA0KZGVzdGlu YXRpb24gaXMgYXBwZW5kZWQgYW5kIHBhY2tldCBpcyBzZW50IHRvIFBJTS1BTExST1VURVJTLiBB biANCm9wdGlvbmFsIGltcGxlbWVudGF0aW9uIG1heSBzdGFydCBhIHRpbWVyIGFuZCByZXBlYXQg dGhlIHdob2xlIA0KcHJvY2VzcyBmb3IgY2VydGFpbiBudW1iZXIgb2YgdGltZXMsIHRvIG1ha2Ug aXQgcm9idXN0IGFnYWluc3QgDQpwb3NzaWJsZSBsb3NzIG9mIHBhY2tldHMuIA0KDQo1LjEuMiBQ cm9jZXNzaW5nIG9mIHRoZSBQSU0tUElORyBwYWNrZXRzIGF0IHRoZSBpbnRlcm1lZGlhdGUgcm91 dGVycy4NCg0KV2hlbiBhbiBpbnRlcm1lZGlhdGUgcm91dGVyIHJlY2VpdmVzIGEgUElNLVBJTkcg cmVxdWVzdCBtZXNzYWdlLCBpdA0KZG9lcyBtZXNzYWdlIHZlcmlmaWNhdGlvbiBhcyBkZXNjcmli ZWQgaW4gc2VjdGlvbiA3LiBSZXF1ZXN0IA0KbWVzc2FnZSBpcyBkcm9wcGVkLCBpZiBhbnkgb2Yg dGhlIHZlcmlmaWNhdGlvbiBjaGVja3MgZmFpbC4gUm91dGVyIA0KdGhlbiBsb29rcyB1cCBSUEYg bmVpZ2hib3IgZm9yIGRlc3RpbmF0aW9uIGFkZHJlc3MgcHJlc2VudCBpbiB0aGUgDQptZXNzYWdl LiBJZiBSUEYgbmVpZ2hib3IgaXMgZm91bmQsIGl0IGZpbGxzIHRoaXMgYWRkcmVzcyBpbiB1cHN0 cmVhbQ0KbmVpZ2hib3IgZmllbGQgYW5kIGFkZHMgaXRzIG93biBJUCBhZGRyZXNzIHByZXNlbnQg b24gdGhlIFJQRiANCmludGVyZmFjZSB0byB0aGUgbGlzdCBvZiByb3V0ZXKScyBhZGRyZXNzZXMu ICBOdW1iZXIgb2Ygcm91dGVycyBjb3VudA0KaXMgaW5jcmVtZW50ZWQgYW5kIHBhY2tldCBpcyBz ZW50IHRvIFBJTS1BTExST1VURVJTLiAgSWYgdGhlIHJvdXRlciANCmZhaWxzIHRvIHByb3BhZ2F0 ZSByZXF1ZXN0IG1lc3NhZ2UgaXQgZ2VuZXJhdGVzIGEgcmVwbHkgbWVzc2FnZSBhcyANCmRlc2Ny aWJlZCBpbiB0aGUgc2VjdGlvbiA1LjQuIA0KDQo1LjEuMyBQcm9jZXNzaW5nIG9mIHRoZSBQSU0t UElORyByZXF1ZXN0IHBhY2tldCBhdCB0aGUgZmlyc3Rob3AgDQogICAgICByb3V0ZXIgdG93YXJk cyBkZXN0aW5hdGlvbiBvciBhdCBkZXN0aW5hdGlvbi4gDQoNCldoZW4gdGhlIGZpcnN0IGhvcCBy b3V0ZXIgdG93YXJkcyBkZXN0aW5hdGlvbiBvciBkZXN0aW5hdGlvbiByb3V0ZXIgDQpyZWNlaXZl cyB0aGUgUElNLVBJTkcgbWVzc2FnZSwgaXQgZG9lcyB0aGUgbWVzc2FnZSB2ZXJpZmljYXRpb24g YXMgDQpkZXNjcmliZWQgaW4gU2VjdGlvbi4gQSB1bmljYXN0IHJlcGx5IG1lc3NhZ2UgaXMgc2Vu dCBiYWNrIHRvIHRvd2FyZHMNCnRoZSByb3V0ZXIgd2hpY2ggaXNzdWVkIHRoZSByZXF1ZXN0LiBE ZXRhaWxzIGFib3V0IHRoZSB2YXJpb3VzIA0KcmVzcG9uc2VzIGFyZSBnaXZlbiBpbiBzZWN0aW9u IDUuNC4NCg0KDQo1LjIuIENoZWNraW5nIGZvciB0aGUgUlAgY29uc2lzdGVuY3kgYWxvbmcgYSBw YXRoLg0KIA0KDQoNCg0KDQoNCkFyY2hhbmEvSmFuYXJkaGFuICAgICAgICAgICAgUElNLVBJTkcg ICAgICAgICAgICAgICBbUGFnZSAxMF0NCklOVEVSTkVULURSQUZUICAgICAgICAgICAgICAgRXhw OiBEZWMgMjAwNyAgICAgICAgICAyOCBKdW5lIDIwMDcNCg0KDQoNCg0KDQoNCg0KNS4yLjEgU2Vu ZGluZyB0aGUgUElNLVBJTkcgbWVzc2FnZSB0byB2ZXJpZnkgUlAgY29uc2lzdGVuY3kuDQoNCldo ZW4gYSByb3V0ZXIgd2FudHMgdG8gdmVyaWZ5IHRoZSBSUCBjb25zaXN0ZW5jeSBmb3IgZ3JvdXAs IGl0DQpnZW5lcmF0ZXMgYSByZXF1ZXN0IG1lc3NhZ2UgYW5kIHNldHMgdGhlIHJlcXVlc3QgdHlw ZSBhcw0KUElNUElOR19SUENPTlNJU1RFTkNZX1RFU1QuIERlc3RpbmF0aW9uIGFkZHJlc3MgYW5k IHVwc3RyZWFtIG5laWdoYm9yDQphZGRyZXNzIGZpZWxkcyBhcmUgZmlsbGVkLiBUaGUgbXVsdGlj YXN0IGdyb3VwIGFkZHJlc3MgZm9yIHdoaWNoIFJQDQpjb25zaXN0ZW5jeSBuZWVkcyB0byBiZSB2 ZXJpZmllZCBhbmQgUlAgYmVpbmcgdXNlZCBmb3IgdGhhdCBncm91cCBhcmUNCnNldC4gDQoNCkl0 IGFsc28gaW5jbHVkZXMgYSBzZXF1ZW5jZSBudW1iZXIsIHdoaWNoIGlzIGEgcmFuZG9tbHkgZ2Vu ZXJhdGVkIA0KbnVtYmVyIHRvIGlkZW50aWZ5IHRoZSByZXF1ZXN0IG1lc3NhZ2UuICBOdW1iZXIg b2Ygcm91dGVycyBmaWVsZCBpcyANCnNldCB0byAxLCBJUCBhZGRyZXNzIHByZXNlbnQgb24gdGhl IFJQRiBpbnRlcmZhY2UgdG93YXJkcyBkZXN0aW5hdGlvbg0KaXMgYXBwZW5kZWQgYW5kIG1lc3Nh Z2UgaXMgc2VudCB0byBQSU0tQUxMUk9VVEVSUy4gQW4gb3B0aW9uYWwgDQppbXBsZW1lbnRhdGlv biBtYXkgc3RhcnQgYSB0aW1lciBhbmQgcmVwZWF0IHRoZSAgd2hvbGUgcHJvY2VzcyBmb3IgDQpj ZXJ0YWluIG51bWJlciBvZiB0aW1lcywgdG8gbWFrZSBpdCByb2J1c3QgYWdhaW5zdCBwb3NzaWJs ZSBsb3NzIG9mDQpwYWNrZXRzLiANCg0KNS4yLjIgUHJvY2Vzc2luZyBvZiB0aGUgUElNLVBJTkcg UlAgY29uc2lzdGVuY3kgbWVzc2FnZXMgYXQgdGhlIA0KICAgICAgaW50ZXJtZWRpYXRlIHJvdXRl cnMuDQoNCldoZW4gYW4gaW50ZXJtZWRpYXRlIHJvdXRlciByZWNlaXZlcyBhIFBJTS1QSU5HIHJl cXVlc3QgbWVzc2FnZSwgaXQNCmRvZXMgbWVzc2FnZSB0aGUgdmVyaWZpY2F0aW9uIGFzIGRlc2Ny aWJlZCBpbiBzZWN0aW9uIDcuIFJlcXVlc3QgDQptZXNzYWdlIGlzIHNpbGVudGx5IGRyb3BwZWQs IGlmIGFueSBvZiB0aGUgdmVyaWZpY2F0aW9uIGNoZWNrcyBmYWlsLg0KUm91dGVyIHRoZW4gdmVy aWZpZXMgd2hldGhlciBSUCBhZGRyZXNzZXMgYmVpbmcgdXNlZCBmb3IgbXVsdGljYXN0IA0KZ3Jv dXAgYXJlIGNvbnNpc3RlbnQgLklmIHRoZXkgbWF0Y2gsIHJvdXRlciB0aGVuIGxvb2tzIHVwIFJQ RiANCm5laWdoYm9yIGZvciBkZXN0aW5hdGlvbiBhZGRyZXNzIHByZXNlbnQgaW4gdGhlIG1lc3Nh Z2UuIElmIFJQRiANCm5laWdoYm9yIGlzIGZvdW5kLCBpdCBmaWxscyB0aGlzIGFkZHJlc3MgaW4g dXBzdHJlYW0gbmVpZ2hib3IgZmllbGQgDQphbmQgYWRkcyBpdHMgb3duIElQIGFkZHJlc3MgcHJl c2VudCBvbiB0aGUgUlBGIGludGVyZmFjZSB0byB0aGUgbGlzdCANCm9mIHJvdXRlcpJzIGFkZHJl c3Nlcy4gIE51bWJlciBvZiByb3V0ZXJzIGNvdW50IGlzIGluY3JlbWVudGVkIGFuZCANCnBhY2tl dCBpcyBzZW50IHRvIFBJTS1BTExST1VURVJTLiAgSWYgdGhlIFJQIGFkZHJlc3NlcyBtaXNtYXRj aCBvciANCnJvdXRlciBmYWlscyB0byBwcm9wYWdhdGUgcmVxdWVzdCBtZXNzYWdlIGl0IGdlbmVy YXRlcyBhIHJlcGx5IA0KbWVzc2FnZSBhcyBkZXNjcmliZWQgaW4gdGhlIHNlY3Rpb24gNS40LiAN Cg0KNS4yLjMgUHJvY2Vzc2luZyBvZiB0aGUgUElNLVBJTkcgUlAgY29uc2lzdGVuY3kgIG1lc3Nh Z2VzIGF0IA0KICAgICAgZGVzdGluYXRpb24uIA0KDQpXaGVuIHRoZSBkZXN0aW5hdGlvbiByb3V0 ZXIgcmVjZWl2ZXMgdGhlIFBJTS1QSU5HIG1lc3NhZ2UsIGl0IGRvZXMNCnRoZSBtZXNzYWdlIHZl cmlmaWNhdGlvbiBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA3LiBBIHVuaWNhc3QgcmVwbHkgDQpt ZXNzYWdlIGlzIHNlbnQgYmFjayB0byB0b3dhcmRzIHRoZSByb3V0ZXIgd2hpY2ggaXNzdWVkIHRo ZSByZXF1ZXN0Lg0KRGV0YWlscyBhYm91dCB0aGUgdmFyaW91cyByZXNwb25zZXMgaXMgZGVzY3Jp YmVkIGluIGRldGFpbCBpbiBzZWN0aW9uDQo1LjQuDQoNCg0KDQoNCg0KDQoNCkFyY2hhbmEvSmFu YXJkaGFuICAgICAgICAgICAgUElNLVBJTkcgICAgICAgICAgICAgICBbUGFnZSAxMV0NCklOVEVS TkVULURSQUZUICAgICAgICAgICAgICAgRXhwOiBEZWMgMjAwNyAgICAgICAgICAyOCBKdW5lIDIw MDcNCg0KDQoNCg0KDQoNCg0KNS4gMyBUaGUgcmVxdWVzdCB0eXBlczoNCg0KVGhpcyBkcmFmdCBk ZXNjcmliZXMgZm9sbG93aW5nIHR3byByZXF1ZXN0IHR5cGVzDQoNCjEuICBUbyB2ZXJpZnkgY29u dmV4aXR5IG9mIFBJTSBkb21haW4gKFBJTVBJTkdfQ09OVkVYSVRZX1RFU1QpOg0KICAgIFRoaXMg cmVxdWVzdCB0eXBlIGlzIHVzZWQgdG8gY2hlY2sgdGhlIGNvbnZleGl0eSBvZiBwaW0gZG9tYWlu IG9yDQogICAgcmVhY2hhYmlsaXR5IG9mIG11bHRpY2FzdCBkYXRhIHNvdXJjZSB0aHJvdWdoIGEg cGltIGRvbWFpbi4gVGhlIA0KICAgIHZhbHVlIGZvciB0aGlzIGlzIDEuDQoyLiAgVG8gdmVyaWZ5 IFJQIGNvbnNpc3RlbmN5IChQSU1QSU5HX1JQQ09OU0lTVEVOQ1lfVEVTVCk6IA0KICAgIFRoaXMg cmVxdWVzdCB0eXBlIGlzIHVzZWQgdG8gY2hlY2sgdGhlIFJQIGNvbnNpc3RlbmN5LiBUaGUgdmFs dWUNCiAgICBmb3IgdGhpcyBpcyAyLg0KDQoNCjUuNCBUaGUgcmVzcG9uc2UgdHlwZXM6DQoNClRo ZSBmb2xsb3dpbmcgYXJlIHRoZSByZXNwb25zZSB0eXBlcyBhbmQgdGhlIHZhbHVlcyBmb3IgdGhl bSwgYXMgDQpkZXNjcmliZWQgaW4gdGhpcyBkcmFmdC4gDQoNCjEuIFNvdXJjZSBpcyBhY3RpdmUg W1BJTVBJTkdfREVTVElOQVRJT05fQUNUXTogDQogICBUaGlzIHdpbGwgYmUgdGhlIHJlc3BvbnNl IHR5cGUsIHdoZW4gYSByZXNwb25zZSBtZXNzYWdlIGlzIA0KICAgZ2VuZXJhdGVkIGJ5IHRoZSBm aXJzdCBob3Agcm91dGVyIGluIHRoZSBzdWJuZXQgb2YgZGVzdGluYXRpb24gb3INCiAgIGRlc3Rp bmF0aW9uIHJvdXRlciBpdHNlbGYuIFZhbHVlIGlzIDMuDQoNCjIuIFNvdXJjZSBpcyBub3QgYWN0 aXZlIGJ1dCBpcyByZWFjaGFibGUgDQogICBbUElNUElOR18gREVTVElOQVRJT04gX1JFQUNIQUJM RV06IA0KICAgVGhpcyBpcyAgdGhlIHJlc3BvbnNlIHR5cGUsIHdoZW4gYSByZXNwb25zZSBtZXNz YWdlIGlzIGdlbmVyYXRlZCANCiAgIGJ5IHRoZSBmaXJzdCBob3Agcm91dGVyIGluIHRoZSBzdWJu ZXQgb2YgZGVzdGluYXRpb24gb3IgDQogICBkZXN0aW5hdGlvbiByb3V0ZXIgaXRzZWxmLiBEZXN0 aW5hdGlvbiBpcyByZWFjaGFibGUgYnV0IGlzIG5vdCANCiAgIHNlbmRpbmcgdGhlIG11bHRpY2Fz dCBkYXRhLiBWYWx1ZSBpcyA0Lg0KDQozLiBEZXN0aW5hdGlvbiBpcyBub3QgcHJlc2VudCBpbiB0 aGUgc3VibmV0IG9mIGZpcnN0aG9wIHJvdXRlci4NCiAgIFtQSU1QSU5HXyBERVNUSU5BVElPTiBf Tk9UUFJFU0VOVF06DQogICBUaGlzIHdpbGwgYmUgdGhlIHJlc3BvbnNlIHR5cGUsIHdoZW4gYSBy ZXBseSBtZXNzYWdlIGlzIGdlbmVyYXRlZCB0aGUNCiAgIGZpcnN0IGhvcCByb3V0ZXIgaW4gdGhl IHN1Ym5ldCBvZiBkZXN0aW5hdGlvbi4gVGhpcyByZXNwb25zZSB3aWxsDQogICBiZSBnZW5lcmF0 ZWQgb25seSB3aGVuIGZpcnN0IGhvcCByb3V0ZXIgaW4gdGhlIHN1Ym5ldCBvZg0KICAgZGVzdGlu YXRpb24gaGFzIHRoZSBrbm93bGVkZ2UgdGhhdCBkZXN0aW5hdGlvbiBhZGRyZXNzIGJlaW5nIA0K ICAgcGluZ2VkIGlzIG5vdCBwcmVzZW50LiBWYWx1ZSBpcyA1Lg0KDQo0LiBEZXN0aW5hdGlvbiBp cyBub3QgcmVhY2hhYmxlIHNpbmNlIHVuaWNhc3Qgcm91dGUgaXMgbm90IHByZXNlbnQ6IA0KICAg W1BJTVBJTkdfREVTVElOQVRJT05fTk9VTklDQVNUUk9VVEVdOg0KICAgVGhpcyByZXNwb25zZSBp cyBnZW5lcmF0ZWQgYnkgaW50ZXJtZWRpYXRlIHJvdXRlcnMuIFNpbmNlIHVuaWNhc3QNCiAgIHJv dXRlIGlzIG5vdCB0aGVyZSwgKG9yIG5vIHN0YXRpYyBtdWx0aWNhc3QgUlBGIGludGVyZmFjZSBp cyBub3QgDQogICBjb25maWd1cmVkKSBqb2luIGNhbm5vdCBiZSBwcm9wYWdhdGVkIGZ1cnRoZXIu IFZhbHVlIGlzIDYuIA0KDQoNCg0KDQoNCkFyY2hhbmEvSmFuYXJkaGFuICAgICAgICAgICAgUElN LVBJTkcgICAgICAgICAgICAgICBbUGFnZSAxMl0NCklOVEVSTkVULURSQUZUICAgICAgICAgICAg ICAgRXhwOiBEZWMgMjAwNyAgICAgICAgICAyOCBKdW5lIDIwMDcNCg0KDQoNCg0KDQoNCg0KNS4g RGVzdGluYXRpb24gaXMgbm90IHJlYWNoYWJsZSBzaW5jZSB0aGVyZSB0aGVyZSBpcyBubyBwaW0g bmVpZ2hib3INCiAgIG9uIHRoZSBSUEYgaW50ZXJmYWNlIFtQSU1QSU5HX0RFU1RJTkFUSU9OX05P UElNTkJSXToNCiAgIFRoaXMgcmVzcG9uc2UgaXMgZ2VuZXJhdGVkIGJ5IGludGVybWVkaWF0ZSBy b3V0ZXJzLiBTaW5jZSBwaW0gDQogICBuZWlnaGJvciBpcyBub3QgcHJlc2VudCwgdGhlIHJlcXVl c3QgbWVzc2FnZSBjYW5ub3QgYmUgcHJvcGFnYXRlZCANCiAgIGZ1cnRoZXIuIFZhbHVlIGlzIDcu IA0KDQo2LiBEZXN0aW5hdGlvbiBpcyBub3QgcmVhY2hhYmxlIGR1ZSB0byBjb25maWd1cmF0aW9u IGlzc3Vlcw0KICAgW1BJTVBJTkdfREVTVElOQVRJT05fTk9QSU1DRkddOg0KICAgVGhpcyByZXNw b25zZSBpcyBnZW5lcmF0ZWQgYnkgaW50ZXJtZWRpYXRlIHJvdXRlcnMuIA0KICAgRHVlIHRvIGNv bmZpZ3VyYXRpb24gcmVsYXRlZCBwcm9ibGVtcywgdGhlIHJlcXVlc3QgbWVzc2FnZSBjYW5ub3QN CiAgIGJlIGZvcndhcmRlZC4gVmFsdWUgaXMgOC4NCg0KNy4gUlAgYWRkcmVzc2VzIHVzZWQgYXQg Zm9yIGEgcGFydGljdWxhciBncm91cCBtaXNtYXRjaCANCiAgIFtSUF9NSVNNQVRDSF06DQogICBU aGlzIHJlc3BvbnNlIGlzIGdlbmVyYXRlZCBieSB0aGUgcm91dGVyLCB3aGVuIHRoZSBSUCBhZGRy ZXNzIHVzZWQNCiAgIGZvciBhIHBhcnRpY3VsYXIgZ3JvdXAgbWlzbWF0Y2guIFRoZSB2YWx1ZSBp cyA5Lg0KDQo4LiBSUCBhZGRyZXNzZXMgdXNlZCBmb3IgYSBwYXJ0aWN1bGFyIGdyb3VwIGFyZSBj b25zaXN0ZW50IA0KICAgW1JQX0NPTlNJU1RBTlRdOg0KICAgVGhpcyB3aWxsIGJlIGdlbmVyYXRl ZCBieSB0aGUgbGFzdCBob3Agcm91dGVyIG9yIHJvdXRlciB0byB3aGljaCANCiAgIHJlcXVlc3Qg aXMgaXNzdWVkLiBUaGlzIG1lYW5zIHRoYXQsIGFsbCB0aGUgcm91dGVycyBhcmUgdXNpbmcgDQog ICB0aGUgc2FtZSBSUCBhZGRyZXNzIGZvciBhIHBhcnRpY3VsYXIgbXVsdGljYXN0IGdyb3VwIGFk ZHJlc3MsIA0KICAgYWxvbmcgdGhpcyBwYXRoLiBUaGUgdmFsdWUgaXMgMTAuDQoNCg0KNi4gUHJv Y2Vzc2luZyB0aGUgcmVjaWV2ZWQgcmVzcG9uc2UgbWVzc2FnZS4NCg0KVGhlIHJvdXRlciB3aGlj aCByZWNpZXZlcyB0aGUgcmVzcG9uc2UgbWVzc2FnZSBzaG91bGQgZG8gdGhlIHBhY2tldCANCnZl cmlmaWNhdGlvbiBhcyBkZXNyaWJlZCBpbiB0aGUgc2VjdGlvbiA5LiBJdCBzaG91bGQgY2hlY2sg dGhlIHNvdXJjZQ0KYWRkcmVzcyBhbmQgc2VxdWVuY2UgbnVtYmVyIGZpZWxkcyB0byB2ZXJpZnkg dGhhdCByZXNwb25zZSBtZXNzYWdlDQppcyBmb3IgdGhlIHJlcXVlc3QgaXQgc2VudC4gSWYgdGhl IHJlc3BvbnNlIGlzIGludGVuZGVkIHRvIGl0LA0KcmVzcG9uc2UgdHlwZSBpbmRpY2F0ZXMgcmVz dWx0IG9mIGl0cyBxdWVyeS4NCg0KDQo3LiBNZXNzYWdlIFZlcmlmaWNhdGlvbg0KDQpUaGUgZm9s bG93aW5nIGZpZWxkcyBvZiB0aGUgcmVxdWVzdCBhbmQgcmVzcG9uc2UgbWVzc2FnZXMgc2hvdWxk IGJlIA0KdmVyaWZpZWQgZm9yIHRoZSB2YWxpZGl0eSBiZWZvcmUgbWVzc2FnZSBpcyBwcm9jZXNz ZWQgYnkgdGhlIHJvdXRlcnMuDQpJZiBhbnkgb2YgdGhlIGNoZWNrcyBmYWlsLCBtZXNzYWdlIHNo b3VsZCBiZSBkcm9wcGVkLg0KDQoxLiBQSU0gVmVyIGFuZCBUeXBlIG11c3QgaGF2ZSB2YWx1ZSBt ZW50aW9uZWQgaW4gU2VjdGlvbiA0LjEuDQoyLiBVcHN0cmVhbSBhZGRyZXNzIG11c3QgYmUgdmFs aWQgdW5pY2FzdCBpcCBhZGRyZXNzIGZvciBpcHY0IGFuZCANCiAgIHZhbGlkIGxpbmstbG9jYWwg YWRkcmVzcyBmb3IgSVB2Ni4gVGhpcyBmaWVsZCBzaGFsbCBiZSBpZ25vcmVkIGluDQogICByZXNw b25zZSBtZXNzYWdlLg0KMy4gRGVzdGluYXRpb24gYWRkcmVzcyBtdXN0IGJlIHZhbGlkIHVuaWNh c3QgZ2xvYmFsIGlwLWFkZHJlc3MuDQo0LiBSb3V0ZXJzkiBMaXN0IG11c3QgY29udGFpbiB2YWxp ZCB1bmljYXN0IGdsb2JhbCBpcC1hZGRyZXNzZXMuDQoNCg0KQXJjaGFuYS9KYW5hcmRoYW4gICAg ICAgICAgICBQSU0tUElORyAgICAgICAgICAgICAgIFtQYWdlIDEzXQ0KSU5URVJORVQtRFJBRlQg ICAgICAgICAgICAgICBFeHA6IERlYyAyMDA3ICAgICAgICAgIDI4IEp1bmUgMjAwNw0KDQoNCg0K DQoNCg0KDQogICBGb3IgUlAgQ29uc2lzdGVuY3kgbWVzc2FnZXMgOg0KNS4gUlAgYWRkcmVzcyBt dXN0IGJlIHZhbGlkIHVuaWNhc3QgZ2xvYmFsIGlwLWFkZHJlc3MuDQo2LiBHcm91cCBhZGRyZXNz IG11c3QgYmUgdmFsaWQgbXVsdGljYXN0IGFkZHJlc3MuDQogICBBYm92ZSBmaWVsZHMgbXVzdCBi ZSBzZXQgdG8gemVybyBpbiB0aGUgcmVxdWVzdCBhbmQNCiAgIHJlc3BvbnNlIG1lc3NhZ2VzIGZv ciBkb21haW4gY29udmV4aXR5IHRlc3RzLg0KDQoNCjguIFJlZmVyZW5jZXMNCg0KICAgWzFdIFJG QyA0NjAxIJYgUHJvdG9jb2wgSW5kZXBlbmRlbnQgTXVsdGljYXN0IJYgU3BhcnNlIE1vZGU6DQog ICAgICAgUHJvdG9jb2wgU3BlY2lmaWNhdGlvbg0KDQogICBbMl0gUkZDIDM5NzMgliBQcm90b2Nv bCBJbmRlcGVuZGVudCBNdWx0aWNhc3QgliBEZW5zZSBNb2RlDQoNCiAgIFszXSBkcmFmdC1pZXRm LXBpbS1ic3ItMTAudHh0IJYgQm9vdHN0cmFwIFJvdXRlciAoQlNSKSBNZWNoYW5pc20NCiAgICAg ICBmb3IgUElNDQoNCqAgIFs0XSBkcmFmdC1pZXRmLXBpbS1pcHY2LTAzLnR4dCAtIFByb3RvY29s IEluZGVwZW5kZW50IE11bHRpY2FzdA0KICAgICAgIFJvdXRpbmcgaW4gSVB2Ng0KDQoNCjkuIEF1 dGhvcidzIGFkZHJlc3MNCiAgICAgICAgSmFuYXJkaGFuIEt1bGthcm5pLA0KICAgICAgICBDaXRy aXggc3lzdGVtcywgDQogICAgICAgIEJhbmdhbG9yZS4NCiAgICAgICAgZW1haWw6IGphbmFyZGhh bi5rdWxrYXJuaUBjaXRyaXguY29tDQogDQogICAgICAgIEFyY2hhbmEgUGF0ZWwsIA0KICAgICAg ICBDaXNjbyBTeXN0ZW1zLCBJbmMuLA0KICAgICAgICBCYW5nYWxvcmUuDQogICAgICAgIGVtYWls OiBhcmNoYW5hcEBjaXNjby5jb20NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpB cmNoYW5hL0phbmFyZGhhbiAgICAgICAgICAgIFBJTS1QSU5HICAgICAgICAgICAgICAgW1BhZ2Ug MTRdDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgIEV4cDogRGVjIDIwMDcgICAgICAgICAg MjggSnVuZSAyMDA3DQoNCg0KDQoNCg0KDQoNCg0KMTAuIENvcHlyaWdodCAoQykgVGhlIElFVEYg VHJ1c3QgKDIwMDcpDQoNClRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byB0aGUgcmlnaHRzLCBs aWNlbnNlcyBhbmQgcmVzdHJpY3Rpb25zDQpjb250YWluZWQgaW4gQkNQIDc4LCBhbmQgZXhjZXB0 IGFzIHNldCBmb3J0aCB0aGVyZWluLCB0aGUgYXV0aG9ycyANCnJldGFpbiBhbGwgdGhlaXIgcmln aHRzLg0KDQpUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVp biBhcmUgcHJvdmlkZWQgb24NCkFuICJBUyBJUyIgYmFzaXMgYW5kIFRIRSBDT05UUklCVVRPUiwg VEhFIE9SR0FOSVpBVElPTiBIRS9TSEUgDQpSRVBSRVNFTlRTIE9SIElTIFNQT05TT1JFRCBCWSAo SUYgQU5ZKSwgVEhFIElOVEVSTkVUIFNPQ0lFVFksIA0KVEhFIElFVEYgVFJVU1QgQU5EIFRIRSBJ TlRFUk5FVCBFTkdJTkVFUklORyBUQVNLIEZPUkNFIERJU0NMQUlNIEFMTA0KV0FSUkFOVElFUywg RVhQUkVTUyBPUiBJTVBMSUVELCBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSANCldB UlJBTlRZIFRIQVQgVEhFIFVTRSBPRiBUSEUgSU5GT1JNQVRJT04gSEVSRUlOIFdJTEwgTk9UIElO RlJJTkdFIEFOWQ0KUklHSFRTIE9SIEFOWSBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRB QklMSVRZIE9SIEZJVE5FU1MgRk9SIEENClBBUlRJQ1VMQVIgUFVSUE9TRS4NCg0KSW50ZWxsZWN0 dWFsIFByb3BlcnR5DQoNClRoZSBJRVRGIHRha2VzIG5vIHBvc2l0aW9uIHJlZ2FyZGluZyB0aGUg dmFsaWRpdHkgb3Igc2NvcGUgb2YgYW55DQpJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIG9y IG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQgdG8NCnBlcnRhaW4gdG8gdGhlIGlt cGxlbWVudGF0aW9uIG9yIHVzZSBvZiB0aGUgdGVjaG5vbG9neSBkZXNjcmliZWQgaW4gDQp0aGlz IGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vuc2UgdW5kZXIgc3VjaCBy aWdodHMgDQptaWdodCBvciBtaWdodCBub3QgYmUgYXZhaWxhYmxlOyBub3IgZG9lcyBpdCByZXBy ZXNlbnQgdGhhdCBpdCBoYXMgDQptYWRlIGFueSBpbmRlcGVuZGVudCBlZmZvcnQgdG8gaWRlbnRp ZnkgYW55IHN1Y2ggcmlnaHRzLiAgSW5mb3JtYXRpb24NCm9uIHRoZSBwcm9jZWR1cmVzIHdpdGgg cmVzcGVjdCB0byByaWdodHMgaW4gUkZDIGRvY3VtZW50cyBjYW4gYmUNCmZvdW5kIGluIEJDUCA3 OCBhbmQgQkNQIDc5Lg0KDQpDb3BpZXMgb2YgSVBSIGRpc2Nsb3N1cmVzIG1hZGUgdG8gdGhlIElF VEYgU2VjcmV0YXJpYXQgYW5kIGFueQ0KYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0byBiZSBtYWRl IGF2YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbiANCmF0dGVtcHQgbWFkZSB0byBvYnRhaW4g YSBnZW5lcmFsIGxpY2Vuc2Ugb3IgcGVybWlzc2lvbiBmb3IgdGhlIHVzZSBvZg0Kc3VjaCBwcm9w cmlldGFyeSByaWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMgc3BlY2lmaWNh dGlvbg0KY2FuIGJlIG9idGFpbmVkIGZyb20gdGhlIElFVEYgb24tbGluZSBJUFIgcmVwb3NpdG9y eSBhdA0KaHR0cDovL3d3dy5pZXRmLm9yZy9pcHIuDQoNClRoZSBJRVRGIGludml0ZXMgYW55IGlu dGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8gaXRzIGF0dGVudGlvbiBhbnkNCmNvcHlyaWdodHMs IHBhdGVudHMgb3IgcGF0ZW50IGFwcGxpY2F0aW9ucywgb3Igb3RoZXIgcHJvcHJpZXRhcnkgDQpy aWdodHMgdGhhdCBtYXkgY292ZXIgdGVjaG5vbG9neSB0aGF0IG1heSBiZSByZXF1aXJlZCB0byBp bXBsZW1lbnQgDQp0aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJlc3MgdGhlIGluZm9ybWF0aW9u IHRvIHRoZSBJRVRGIGF0IA0KaWV0Zi0gaXByQGlldGYub3JnLg0KDQoNCg0KDQoNCg0KDQoNCg0K QXJjaGFuYS9KYW5hcmRoYW4gICAgICAgICAgICBQSU0tUElORyAgICAgICAgICAgICAgIFtQYWdl IDE1XQ0KSU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICBFeHA6IERlYyAyMDA3ICAgICAgICAg IDI4IEp1bmUgMjAwNw0KDQo= ------=_Part_20290_23349526.1183228035777 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim ------=_Part_20290_23349526.1183228035777-- From pim-bounces@ietf.org Mon Jul 09 01:01:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7lNO-0000E5-9O; Mon, 09 Jul 2007 01:01:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7lNN-0000Dy-0c for pim@ietf.org; Mon, 09 Jul 2007 01:01:33 -0400 Received: from wa-out-1112.google.com ([209.85.146.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7lNI-0003EQ-Lp for pim@ietf.org; Mon, 09 Jul 2007 01:01:32 -0400 Received: by wa-out-1112.google.com with SMTP id k17so1366648waf for ; Sun, 08 Jul 2007 22:01:28 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=GPvuo1rWxSCcVfnKzh9yDck4F+xj49lArjOUFuY+rScJiaHMWTmuG30H3RTFNlI80S5Ea/4xVfSDiWrRhF4VKasagixX9b4dgU/mAml0cRlRLHLmt7RftgNsQW54SRGCVLV0PKPlkdimrXGNPv31/8j4tlR9JnXdq0+K3qa1NrI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=QhUq4W6ewWicUfM0yP8vM1eCRtf/QYPoyYlFlY72im/kfdB8PpMfSOrHe1n8A+naJOWLRKt3imglYV+1yMddYGYxaAZhCh0o5ba1P3BOt6bQEsKpPBZobqeehBAa6HAtUp7ZpwiXXekvo1V6AUAw1yb8A1nu8I4RSJ9KLcXZdIQ= Received: by 10.114.106.1 with SMTP id e1mr2768162wac.1183957287947; Sun, 08 Jul 2007 22:01:27 -0700 (PDT) Received: by 10.114.108.5 with HTTP; Sun, 8 Jul 2007 22:01:27 -0700 (PDT) Message-ID: <100ba11b0707082201w69d002ddo68334716a4efa432@mail.gmail.com> Date: Mon, 9 Jul 2007 10:31:27 +0530 From: "janardhan kulkarni" To: pim@ietf.org, "Stig Venaas" , "=?ISO-8859-1?Q?Beno=EEt_HILT?=" , "Hitoshi Asaeda" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Archana Patel Subject: [pim] Please review our new draft and give us feedback. Thanks. X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pim-bounces@ietf.org Hi, In our new draft we are proposing some extensions to PIM so that, troubleshooting becomes easy. Below is link and extract from our work. Kindly review this and give us feedback about the utility of this. http://www.ietf.org/internet-drafts/draft-archana-pimwg-pim-ping-00.txt Brief Introduction:- ******************** Multicast technology has been around for quite some time now. But widespread deployment of multicasting has just begun. All these days, multicasting technology was revolving around developing efficient, scalable routing protocols. Now that, multicast routing protocols are matured, PIMSSM and PIMSM have established themselves as principal multicast routing protocols, since many applications are using multicasting as their base technology, it is the time to address other aspects like debugging, trouble shooting and error reporting. Most of the work that has been done so far in these areas, either depend on multicast tree being set up or support from IP, and MIBS. But it is our opinion that, multicast routing protocols should in themselves embed necessary mechanisms to address these issues, even if it means protocol implementations needs to be tweaked. Also, we should note that, most of multicast routing protocols which use PULL model like PIMSM, PIMSSM will create a multicast tree only if there are some receivers join the tree. So, to get information about the reachability or to trace the path of multicast data, even before creating the tree it is necessary to extend the protocols. In this draft we want to present some extensions to PIM, which help in trouble shooting PIM related issues. -- Bye, Janardhan. "I have never been hurt by what I have not said." -Calvin Coolidge _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Tue Jul 10 16:15:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8M7E-0006GY-Kw; Tue, 10 Jul 2007 16:15:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8M6w-0005mY-MG; Tue, 10 Jul 2007 16:15:02 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8M6w-0008L7-7b; Tue, 10 Jul 2007 16:15:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 0BF9632A2B; Tue, 10 Jul 2007 20:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I8M6v-0004X2-UT; Tue, 10 Jul 2007 16:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 10 Jul 2007 16:15:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: pim@ietf.org Subject: [pim] I-D ACTION:draft-ietf-pim-sm-linklocal-01.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pim-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol Independent Multicast Working Group of the IETF. Title : Security Issues in PIM-SM Link-local Messages Author(s) : J. Atwood, S. Islam Filename : draft-ietf-pim-sm-linklocal-01.txt Pages : 24 Date : 2007-7-10 RFC 4601 mandates the use of IPsec to ensure authentication of the link-local messages in the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol. This document specifies mechanisms to authenticate the PIM-SM link local messages using the IP security (IPsec) Authentication Header (AH) or Encapsulating Security Payload (ESP). It specifies optional mechanisms to provide confidentiality using the ESP. Manual keying is specified as the mandatory and default group key management solution. To deal with issues of scalability and security that exist with manual keying, an optional automated group key management mechanism is specified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-linklocal-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pim-sm-linklocal-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pim-sm-linklocal-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-10155709.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pim-sm-linklocal-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pim-sm-linklocal-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-10155709.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim --NextPart-- From pim-bounces@ietf.org Wed Jul 11 02:26:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Vej-0004gI-Ke; Wed, 11 Jul 2007 02:26:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Vei-0004g7-CJ for pim@ietf.org; Wed, 11 Jul 2007 02:26:32 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8Ved-0006CK-HD for pim@ietf.org; Wed, 11 Jul 2007 02:26:32 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL0007554IKLH@szxga01-in.huawei.com> for pim@ietf.org; Wed, 11 Jul 2007 14:25:33 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL0000XG4IJSP@szxga01-in.huawei.com> for pim@ietf.org; Wed, 11 Jul 2007 14:25:32 +0800 (CST) Received: from jys4040097 ([10.194.121.126]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JL000ISD4IFGA@szxml04-in.huawei.com> for pim@ietf.org; Wed, 11 Jul 2007 14:25:31 +0800 (CST) Date: Wed, 11 Jul 2007 14:25:27 +0800 From: su haiyang Subject: =?utf-8?Q?=E7=AD=94=E5=A4=8D:_=5Bpim=5D_Please_review_our_new_?= =?utf-8?Q?draft_and_give_us_feedback._Than?= =?utf-8?Q?ks.?= In-reply-to: <100ba11b0707082201w69d002ddo68334716a4efa432@mail.gmail.com> To: 'janardhan kulkarni' Message-id: <000301c7c384$461c07d0$7e79c20a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Thread-index: AcfB5j/HcpY9vkMpQW67AongOzpD3ABnThIg X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: pim@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pim-bounces@ietf.org Dear Janardhan, I can't see any advantages of your drafts over mtrace proposed to a = draft long time ago. Given that mtrace has been long applied at mbone or = carrier's network for fault-locating, Can you make a summary about your = initiative ideas included in the following draft. Su Haiyang -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: janardhan kulkarni = [mailto:janardhan.kulkarni@gmail.com]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2007=E5=B9=B47=E6=9C=889=E6=97=A5 = 13:01 =E6=94=B6=E4=BB=B6=E4=BA=BA: pim@ietf.org; Stig Venaas; Beno=C3=AEt = HILT; Hitoshi Asaeda =E6=8A=84=E9=80=81: Archana Patel =E4=B8=BB=E9=A2=98: [pim] Please review our new draft and give us = feedback. Thanks. Hi, In our new draft we are proposing some extensions to PIM so that, troubleshooting becomes easy. Below is link and extract from our work. Kindly review this and give us feedback about the utility of this. http://www.ietf.org/internet-drafts/draft-archana-pimwg-pim-ping-00.txt Brief Introduction:- ******************** Multicast technology has been around for quite some time now. But widespread deployment of multicasting has just begun. All these days, multicasting technology was revolving around developing efficient, scalable routing protocols. Now that, multicast routing protocols are matured, PIMSSM and PIMSM have established themselves as principal multicast routing protocols, since many applications are using multicasting as their base technology, it is the time to address other aspects like debugging, trouble shooting and error reporting. Most of the work that has been done so far in these areas, either depend on multicast tree being set up or support from IP, and MIBS. But it is our opinion that, multicast routing protocols should in themselves embed necessary mechanisms to address these issues, even if it means protocol implementations needs to be tweaked. Also, we should note that, most of multicast routing protocols which use PULL model like PIMSM, PIMSSM will create a multicast tree only if there are some receivers join the tree. So, to get information about the reachability or to trace the path of multicast data, even before creating the tree it is necessary to extend the protocols. In this draft we want to present some extensions to PIM, which help in trouble shooting PIM related issues. --=20 Bye, Janardhan. "I have never been hurt by what I have not said." -Calvin Coolidge _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Thu Jul 12 12:15:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I91K2-0003Hj-Dd; Thu, 12 Jul 2007 12:15:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I91Jq-00035B-Ip; Thu, 12 Jul 2007 12:15:06 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I91Jq-0005i2-B7; Thu, 12 Jul 2007 12:15:06 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 10857175EE; Thu, 12 Jul 2007 16:15:06 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I91Jo-0003FP-Py; Thu, 12 Jul 2007 12:15:05 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 12 Jul 2007 12:15:04 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: pim@ietf.org Subject: [pim] I-D ACTION:draft-ietf-pim-sm-bsr-11.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pim-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol Independent Multicast Working Group of the IETF. Title : Bootstrap Router (BSR) Mechanism for PIM Author(s) : N. Bhaskar, et al. Filename : draft-ietf-pim-sm-bsr-11.txt,.ps Pages : 45 Date : 2007-7-12 This document specifies the Bootstrap Router (BSR) mechanism for the class of multicast routing protocols in the PIM (Protocol Independent Multicast) family that use the concept of a Rendezvous Point as a means for receivers to discover the sources that send to a particular multicast group. BSR is one way that a multicast router can learn the set of group-to-RP mappings required in order to function. The mechanism is dynamic, largely self-configuring, and robust to router failure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-bsr-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pim-sm-bsr-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pim-sm-bsr-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-12110419.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pim-sm-bsr-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pim-sm-bsr-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-12110419.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim --NextPart-- From pim-bounces@ietf.org Thu Jul 12 12:15:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I91KV-00043R-TP; Thu, 12 Jul 2007 12:15:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I91Jt-00036X-BF; Thu, 12 Jul 2007 12:15:09 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I91Jt-0007KZ-1B; Thu, 12 Jul 2007 12:15:09 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id D666F26EB1; Thu, 12 Jul 2007 16:15:08 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I91Jr-0003Ff-7R; Thu, 12 Jul 2007 12:15:07 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 12 Jul 2007 12:15:07 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: pim@ietf.org Subject: [pim] I-D ACTION:draft-ietf-pim-rpf-vector-04.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pim-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol Independent Multicast Working Group of the IETF. Title : The RPF Vector TLV Author(s) : I. Wijnands, et al. Filename : draft-ietf-pim-rpf-vector-04.txt Pages : 10 Date : 2007-7-12 This document describes a use of the PIM Join Attribute as defined in draft-ietf-pim-join-attributes[I-D.ietf-pim-join-attributes] which enables PIM to build multicast trees through an MPLS-enabled network, even if that network's IGP does not have a route to the source of the tree. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pim-rpf-vector-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pim-rpf-vector-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pim-rpf-vector-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-12110808.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pim-rpf-vector-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pim-rpf-vector-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-12110808.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim --NextPart-- From pim-bounces@ietf.org Sun Jul 15 07:49:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA2av-0003lH-DJ; Sun, 15 Jul 2007 07:48:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA2au-0003lC-Dc for pim@ietf.org; Sun, 15 Jul 2007 07:48:56 -0400 Received: from tyholt.uninett.no ([2001:700:1::eecb]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IA2at-00012A-38 for pim@ietf.org; Sun, 15 Jul 2007 07:48:56 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by tyholt.uninett.no (Postfix) with ESMTP id BC383B5A6D; Sun, 15 Jul 2007 13:48:53 +0200 (CEST) Received: from tyholt.uninett.no ([127.0.0.1]) by localhost (tyholt.uninett.no [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 09859-01-11; Sun, 15 Jul 2007 13:48:53 +0200 (CEST) Received: from [IPv6?2001?700?1?1100?20c9?e28b?8bd0?afdf] (unknown [IPv6:2001:700:1:1100:20c9:e28b:8bd0:afdf]) by tyholt.uninett.no (Postfix) with ESMTP id ECE96B5A6B; Sun, 15 Jul 2007 13:48:52 +0200 (CEST) Message-ID: <469A09A4.5090708@uninett.no> Date: Sun, 15 Jul 2007 13:48:52 +0200 From: Stig Venaas User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: pim@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at uninett.no X-Spam-Score: -2.8 (--) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: Sandy Murphy Subject: [pim] BSR update X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pim-bounces@ietf.org We've revised revision 10 based on feedback from the General Area review (which Alex has posted previously and also presented in the last pim wg meeting), and feedback from the Security Directorate. Below is the secdir review we got and what changes we've made based on that. For a diff of all changes from 10 to 11, please see http://tools.ietf.org/wg/pim/draft-ietf-pim-sm-bsr/draft-ietf-pim-sm-bsr-11-from-10.diff.html Please let me know if you have further comments, disagree or whatever on any of the below. In March Sandy Murphy (cc-ed) wrote: > This draft describes the Bootstrap Router Mechanism for PIM, a > mechanism by which PIM routers can discover which routers are > Rendezvous Points and what multicast group addresses each serves. > > The security considerations section does a good job of identifying > the threats to the BSR Mechanism, including the types of damage that > can be done and mechanisms that could help to protect the domain, > both operational and cryptographic. > > The authors somewhat punt on the problem of Byzantine routers, noting > only that "If a legitimate PIM router is compromised, there is little > any security mechanism can do to prevent that router subverting PIM > traffic in that domain." > > SECURITY RELATED POINTS: > > The non-cryptographic protections suggested are of filtering > on the basis of source, destination, or protocol. They also > recommend access lists: > > "we recommend that implementations have a way of > restricting which IP addresses the BSR accepts C-RP-Adv messages from, > e.g., access lists." > > "we recommend that implementers provide a mechanism > whereby a PIM router using the BSR mechanisms can be configured with > the IP addresses of valid BSR routers, and that any Bootstrap message > from any other BSR should then be dropped and logged as a security > issue." > > First: I believe that they mean "any other host" or "any other PIM > router" rather than "any other BSR" - it does not seem likely that > there are "valid" BSRs and "other" BSRs. This has now been changed to: "we recommend that implementers provide a mechanism whereby a PIM router using the BSR mechanisms can be configured with the IP addresses of valid BSR routers, and that any Bootstrap message with a non-valid BSR address should be dropped and logged as a security issue. Due to the RPF check of the BSR address, it it will not be trivial to inject messages with a spoofed BSR address." > Second: Use of access lists is useful if the data origin can be > authenticated. The draft later suggests the use of IPSEC AH for both > Bootstrap messages and C-RP-Adv messages. It recommends a single > domain wide shared secret for all PIM routers, which means > authentication is to that group, not to any specific sender. That is > in keeping with their statement that nothing can protect against > Byzantine PIM routers. However, with that key management, an access > list of valid BSR routers does not help - any valid PIM router could > spoof the address of a valid BSR router. (It might protect against > accidental misconfiguration of a non-BSR router.) Furthermore, even > if other key management were used, Bootstrap messages, which are > flooded from PIM router to PIM router using the ALL-PIM-ROUTER > multicast address on each link, would be difficult to authenticate > with IPSEC to a specific data origin (the immediate sender of a BSM is > not the source of the BSM). My comment to her was: We recommend a single domain wide shared secret for all PIM routers, assuming that you trust all PIM routers in your management domain. You are right that any of these can spoof the address. It is difficult to restrict this further, since in general, any PIM router should be able to authenticate the message and take part in hop-by-hop forwarding of the messages. No changes made to the draft regarding this. > -------------- > > The draft says: > > The securing of interactions between PIM neighbors is discussed > in more detail in the Security Considerations section of [1], and so > we do not discuss the details further here. > > Ref [1] is RFC 4601, which says that "The anti-replay option for IPsec > SHOULD be enabled on all SAs." However, the BSMs are flooded over the > link-local ALL-PIM-ROUTERs multicast address. RFC4302 says that it > does not specify mechanisms for providing anti-replay for a > multi-sender SA. This is a problem in RFC 4601, but it could be noted > here that anti-replay is not likely to be available for BSMs, and, > depending on the number of (manually) configured SAs, not for C-RP-Adv > messages. Rev 10 says: The securing of interactions between PIM neighbors is discussed in more detail in the Security Considerations section of [1], and so we do not discuss the details further here. The same security mechanisms that can be used to secure PIM Join, Prune and Assert messages should also be used to secure Bootstrap messages. In Rev 11 we have in front of this text added "In order to prevent replay attacks one will need to have one SA per sender using the sender address for SA lookup." and right after the above text we added "How exactly to secure PIM link link-local messages is still being worked on by the PIM working group, see [10]." where reference 10 is to draft-ietf-pim-sm-linklocal-00. > ------------- > > There are multiple uses of phrases like "We recommend", "It might also > be a good idea", "it may also be useful". (Such phrases were not > restricted to the security consideration section.) Would any of these > uses be better written as RFC 2119 key words, i.e., SHOULD, MAY, > RECOMMENDED, etc? For the security consideration section, the use of > key words might be important, such as "For true security, we recommend > that all C-RPs are configured to use IPsec authentication." What does > that "recommend" mean? My response to her was: At least to me it seems more reasonable to use these phrases than the normative language from 2119. I believe we could have used the terms SHOULD/RECOMMENDED instead, but is that really better? > NON SECURITY RELATED: > > In Section 4.1, the discussion of the fields in a single fragment > points out that the Fragment Tag (duh) and the Hash Mask Len are the > same for all fragments belonging to the same Bootstrap message. It > does not make the same comment about any other field. Does that mean > that "No forward bit", "BSR Priority", "BSR Address", etc. could be > different? It seems like the fragment format is divided into a common > area at the beginning that looks like it should remain the same over > all fragments, and an area that would differ from fragment to > fragment. If so, that might be explained. Rev 11 now says in 4.1.1 on semantic fragmentation: All fragments of a given Bootstrap message MUST have identical values for the Type, No-forward bit, Fragment Tag, Hash Mask Len, BSR Priority and BSR Address fields. That is, only the group-to-RP mappings may differ between fragments. She pointed out a few nits, the interesting one is: > There are cases where multiple terms, which seem to be synonymous, are > used. > > Group addresses/ group ranges/ group prefixes/ admin scope range > > admin scope /admin scope zone/ scope zone/ admin-scope region > > Trying to figure out if a different term is just a synonym is an > annoyance to the reader. Some of these terms are used in the same > paragraph. Sure would be nice to be consistent. (OK, I'll grant you > that "admin scope zone" and "scope zone" was easy.) Revision 11 now tries to avoid synonyms. It defines the term "scope zone" and avoids the term "region". Also it uses the term "group ranges" rather than "group addresses" and "group prefixes". Stig _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Mon Jul 16 11:43:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IASjY-00037k-61; Mon, 16 Jul 2007 11:43:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IASjW-000365-ED for pim@ietf.org; Mon, 16 Jul 2007 11:43:34 -0400 Received: from tyholt.uninett.no ([2001:700:1::eecb]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IASjV-00004t-Ba for pim@ietf.org; Mon, 16 Jul 2007 11:43:34 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by tyholt.uninett.no (Postfix) with ESMTP id 1C09AB5A7A; Mon, 16 Jul 2007 17:43:32 +0200 (CEST) Received: from tyholt.uninett.no ([127.0.0.1]) by localhost (tyholt.uninett.no [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 03122-01-77; Mon, 16 Jul 2007 17:43:31 +0200 (CEST) Received: from [IPv6?2001?700?1?7?215?f2ff?fe35?307d] (sverresborg.uninett.no [IPv6:2001:700:1:7:215:f2ff:fe35:307d]) by tyholt.uninett.no (Postfix) with ESMTP id 9C0C7B5A6A; Mon, 16 Jul 2007 17:43:31 +0200 (CEST) Message-ID: <469B9223.2030009@uninett.no> Date: Mon, 16 Jul 2007 17:43:31 +0200 From: Stig Venaas User-Agent: Thunderbird 2.0.0.4 (X11/20070627) MIME-Version: 1.0 To: Sandy Murphy References: <20070716140154.EE1273F47E@pecan.tislabs.com> In-Reply-To: <20070716140154.EE1273F47E@pecan.tislabs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at uninett.no X-Spam-Score: -2.8 (--) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: pim@ietf.org Subject: [pim] Re: BSR update X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pim-bounces@ietf.org Sandy Murphy wrote: >> We recommend a single domain wide shared secret for all PIM routers, >> assuming that you trust all PIM routers in your management domain. >> You are right that any of these can spoof the address. It is difficult >> to restrict this further, since in general, any PIM router should be >> able to authenticate the message and take part in hop-by-hop forwarding >> of the messages. No changes made to the draft regarding this. > > Perhaps I don't understand your intended use of access lists. I > thought the text I quoted meant that you wanted the access lists to > give you a way to tell the valid BSR PIM routers from the PIM routers > that are not valid BSRs. If that is true, then your access list does > protect you against PIM routers that are accidentally mis-configured > as being BSR capable, but not those that are also misconfigured to use a > valid BSR address. A PIM router could assume the address of a valid BSR > router undetectably, because all the PIM routers use the same domain > wide shared secret. > > If the above is correct, I wonder why you go to the trouble of recommending > access lists - is the protection against only-half-mis-configured > PIM routers what you are after? If so, it would be good to state what > protection the access lists give you. OK, maybe we need to be more explicit. First of all, access lists might give some protection against misconfiguration. You would typically have very few Candidate BSR routers and should only get BSMs with one of those specified as the BSR (the originator of the hop-by-hop flooded BSM). They can also be used to block BSMs from PIM neighbors that are outside your core network (say customer/peer/ISP router). Note that the RPF check done on the BSR address protects you from spoofed external BSMs that appear to come from one of your own BSRs. Due to the RPF check someone compromising a non-BSR router (one that is not allowed to be the BSR) will only be able to originate BSMs and get them flooded to parts of the domain (they must pass the RPF check for one of the valid BSD addresses). I admit access lists give limited protection. What I think one should do in general is simply to discard all BSMs from non-trusted neighbors. That is, drop BSMs on interfaces facing customer/peer/ISP routers. We are currently saying: 6.3.1. Rejecting Bootstrap Messages from Invalid Neighbors Most hosts that are likely to attempt to subvert PIM BSR are likely to be located on leaf subnets. We recommend that implementers provide a configuration option that specifies an interface is a leaf subnet, and that no PIM packets are accepted on such interfaces. Here we are however talking about invalid neighbors, not non-trusted neighbors. I think we should modify this text so that it recommends a configuration option for dropping BSMs on interfaces in general. This would then be useful on both leaf subnets and on external links. This text talking about "no PIM packets" is kind of leftover from when BSR was part of the PIM specification. Next the text says: On multi-access subnets with multiple PIM routers and hosts that are not trusted, we recommend that IPsec AH is used to protect communication between PIM routers, and that such routers are configured to drop and log communication attempts from any host that do not pass the authentication check. When all the PIM routers are under the same administrative control, this authentication may use a configured shared secret. We should update this text to talk about both hosts and non-trusted (or external?) PIM routers. That is, IPsec is needed if you want to only receive BSMs from some routers but don't trust everyone on the link. The only real value I see with ACLs is when you don't use IPsec and have these non-trusted multi-access links. It depends on the topology, but it should be possible to choose the location of the candidate BSRs so that any forged BSM coming from a multi-access subnet with one of the valid BSR addresses will fail RPF. E.g. if the multi-access subnets are close to the edge, and the C-BSRs are centrally located, only those routers further towards the edge will accept the forged BSM. I agree this is not all that good. I'm fine with removing the ACL recommendation and instead recommend the config option for dropping all BSMs on external interfaces. I guess it should even be a SHOULD as this is fairly important for most BSR deployments. I'm familiar with implementations that can drop all BSMs, but not with anyone doing the ACLs. What does the rest of you think of dropping the ACL recommendation for BSMs and just recommend configuration option for BSR border interfaces? Thanks Sandy for helping me finally see this. What do you think of this BSR border interface configuration instead of the more vague ACLs? Stig > > --Sandy _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Mon Jul 16 12:52:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAToA-0003kI-Kr; Mon, 16 Jul 2007 12:52:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IATo8-0003k6-U2 for pim@ietf.org; Mon, 16 Jul 2007 12:52:25 -0400 Received: from tyholt.uninett.no ([2001:700:1::eecb]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IATo6-0002tN-QX for pim@ietf.org; Mon, 16 Jul 2007 12:52:24 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by tyholt.uninett.no (Postfix) with ESMTP id 91481B5A77; Mon, 16 Jul 2007 18:52:21 +0200 (CEST) Received: from tyholt.uninett.no ([127.0.0.1]) by localhost (tyholt.uninett.no [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 19851-01-21; Mon, 16 Jul 2007 18:52:21 +0200 (CEST) Received: from [IPv6?2001?700?1?1100?2968?386d?3a84?946c] (unknown [IPv6:2001:700:1:1100:2968:386d:3a84:946c]) by tyholt.uninett.no (Postfix) with ESMTP id C805AB5A6A; Mon, 16 Jul 2007 18:52:20 +0200 (CEST) Message-ID: <469BA240.8000307@uninett.no> Date: Mon, 16 Jul 2007 18:52:16 +0200 From: Stig Venaas User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Sandy Murphy Subject: Re: [pim] Re: BSR update References: <20070716140154.EE1273F47E@pecan.tislabs.com> <469B9223.2030009@uninett.no> In-Reply-To: <469B9223.2030009@uninett.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at uninett.no X-Spam-Score: -2.8 (--) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: pim@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pim-bounces@ietf.org One additional comment below Stig Venaas wrote: > Sandy Murphy wrote: >>> We recommend a single domain wide shared secret for all PIM routers, >>> assuming that you trust all PIM routers in your management domain. >>> You are right that any of these can spoof the address. It is difficult >>> to restrict this further, since in general, any PIM router should be >>> able to authenticate the message and take part in hop-by-hop forwarding >>> of the messages. No changes made to the draft regarding this. >> >> Perhaps I don't understand your intended use of access lists. I >> thought the text I quoted meant that you wanted the access lists to >> give you a way to tell the valid BSR PIM routers from the PIM routers >> that are not valid BSRs. If that is true, then your access list does >> protect you against PIM routers that are accidentally mis-configured >> as being BSR capable, but not those that are also misconfigured to use >> a valid BSR address. A PIM router could assume the address of a valid >> BSR >> router undetectably, because all the PIM routers use the same domain >> wide shared secret. >> >> If the above is correct, I wonder why you go to the trouble of >> recommending >> access lists - is the protection against only-half-mis-configured >> PIM routers what you are after? If so, it would be good to state what >> protection the access lists give you. > > OK, maybe we need to be more explicit. First of all, access lists might > give some protection against misconfiguration. You would typically have > very few Candidate BSR routers and should only get BSMs with one of > those specified as the BSR (the originator of the hop-by-hop flooded > BSM). They can also be used to block BSMs from PIM neighbors that are > outside your core network (say customer/peer/ISP router). Note that > the RPF check donFrom pim-bounces@ietf.org Mon Jul 16 12:52:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAToA-0003kI-Kr; Mon, 16 Jul 2007 12:52:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IATo8-0003k6-U2 for pim@ietf.org; Mon, 16 Jul 2007 12:52:25 -0400 Received: from tyholt.uninett.no ([2001:700:1::eecb]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IATo6-0002tN-QX for pim@ietf.org; Mon, 16 Jul 2007 12:52:24 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by tyholt.uninett.no (Postfix) with ESMTP id 91481B5A77; Mon, 16 Jul 2007 18:52:21 +0200 (CEST) Received: from tyholt.uninett.no ([127.0.0.1]) by localhost (tyholt.uninett.no [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 19851-01-21; Mon, 16 Jul 2007 18:52:21 +0200 (CEST) Received: from [IPv6?2001?700?1?1100?2968?386d?3a84?946c] (unknown [IPv6:2001:700:1:1100:2968:386d:3a84:946c]) by tyholt.uninett.no (Postfix) with ESMTP id C805AB5A6A; Mon, 16 Jul 2007 18:52:20 +0200 (CEST) Message-ID: <469BA240.8000307@uninett.no> Date: Mon, 16 Jul 2007 18:52:16 +0200 From: Stig Venaas User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Sandy Murphy Subject: Re: [pim] Re: BSR update References: <20070716140154.EE1273F47E@pecan.tislabs.com> <469B9223.2030009@uninett.no> In-Reply-To: <469B9223.2030009@uninett.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at uninett.no X-Spam-Score: -2.8 (--) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: pim@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pim-bounces@ietf.org One additional comment below Stig Venaas wrote: > Sandy Murphy wrote: >>> We recommend a single domain wide shared secret for all PIM routers, >>> assuming that you trust all PIM routers in your management domain. >>> You are right that any of these can spoof the address. It is difficult >>> to restrict this further, since in general, any PIM router should be >>> able to authenticate the message and take part in hop-by-hop forwarding >>> of the messages. No changes made to the draft regarding this. >> >> Perhaps I don't understand your intended use of access lists. I >> thought the text I quoted meant that you wanted the access lists to >> give you a way to tell the valid BSR PIM routers from the PIM routers >> that are not valid BSRs. If that is true, then your access list does >> protect you against PIM routers that are accidentally mis-configured >> as being BSR capable, but not those that are also misconfigured to use >> a valid BSR address. A PIM router could assume the address of a valid >> BSR >> router undetectably, because all the PIM routers use the same domain >> wide shared secret. >> >> If the above is correct, I wonder why you go to the trouble of >> recommending >> access lists - is the protection against only-half-mis-configured >> PIM routers what you are after? If so, it would be good to state what >> protection the access lists give you. > > OK, maybe we need to be more explicit. First of all, access lists might > give some protection against misconfiguration. You would typically have > very few Candidate BSR routers and should only get BSMs with one of > those specified as the BSR (the originator of the hop-by-hop flooded > BSM). They can also be used to block BSMs from PIM neighbors that are > outside your core network (say customer/peer/ISP router). Note that > the RPF check done on the BSR address protects you from spoofed external > BSMs that appear to come from one of your own BSRs. > > Due to the RPF check someone compromising a non-BSR router (one that is > not allowed to be the BSR) will only be able to originate BSMs and get > them flooded to parts of the domain (they must pass the RPF check for > one of the valid BSD addresses). > > I admit access lists give limited protection. What I think one should > do in general is simply to discard all BSMs from non-trusted neighbors. > That is, drop BSMs on interfaces facing customer/peer/ISP routers. > > We are currently saying: > > 6.3.1. Rejecting Bootstrap Messages from Invalid Neighbors > > Most hosts that are likely to attempt to subvert PIM BSR are likely to > be located on leaf subnets. We recommend that implementers provide a > configuration option that specifies an interface is a leaf subnet, and > that no PIM packets are accepted on such interfaces. > > Here we are however talking about invalid neighbors, not non-trusted > neighbors. > > I think we should modify this text so that it recommends a configuration > option for dropping BSMs on interfaces in general. This would then be > useful on both leaf subnets and on external links. This text talking > about "no PIM packets" is kind of leftover from when BSR was part of the > PIM specification. > > Next the text says: > > On multi-access subnets with multiple PIM routers and hosts that are > not trusted, we recommend that IPsec AH is used to protect > communication between PIM routers, and that such routers are > configured to drop and log communication attempts from any host that > do not pass the authentication check. When all the PIM routers are > under the same administrative control, this authentication may use a > configured shared secret. > > We should update this text to talk about both hosts and non-trusted > (or external?) PIM routers. That is, IPsec is needed if you want to only > receive BSMs from some routers but don't trust everyone on the link. > > The only real value I see with ACLs is when you don't use IPsec and have > these non-trusted multi-access links. It depends on the topology, but it > should be possible to choose the location of the candidate BSRs so that > any forged BSM coming from a multi-access subnet with one of the valid > BSR addresses will fail RPF. E.g. if the multi-access subnets are close > to the edge, and the C-BSRs are centrally located, only those routers > further towards the edge will accept the forged BSM. I should also have said that ACLs are useful on these multi-access links for blocking benign BSMs from other domains while still using BSM between your own routers. As I say above you would still be vulnerable to attacks though. Stig > > I agree this is not all that good. I'm fine with removing the ACL > recommendation and instead recommend the config option for dropping all > BSMs on external interfaces. I guess it should even be a SHOULD as this > is fairly important for most BSR deployments. > > I'm familiar with implementations that can drop all BSMs, but not with > anyone doing the ACLs. What does the rest of you think of dropping the > ACL recommendation for BSMs and just recommend configuration option for > BSR border interfaces? > > Thanks Sandy for helping me finally see this. What do you think of this > BSR border interface configuration instead of the more vague ACLs? > > Stig > >> >> --Sandy > > > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www1.ietf.org/mailman/listinfo/pim _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Mon Jul 16 12:52:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAToH-00048O-4a; Mon, 16 Jul 2007 12:52:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.e on the BSR address protects you from spoofed external > BSMs that appear to come from one of your own BSRs. > > Due to the RPF check someone compromising a non-BSR router (one that is > not allowed to be the BSR) will only be able to originate BSMs and get > them flooded to parts of the domain (they must pass the RPF check for > one of the valid BSD addresses). > > I admit access lists give limited protection. What I think one should > do in general is simply to discard all BSMs from non-trusted neighbors. > That is, drop BSMs on interfaces facing customer/peer/ISP routers. > > We are currently saying: > > 6.3.1. Rejecting Bootstrap Messages from Invalid Neighbors > > Most hosts that are likely to attempt to subvert PIM BSR are likely to > be located on leaf subnets. We recommend that implementers provide a > configuration option that specifies an interface is a leaf subnet, and > that no PIM packets are accepted on such interfaces. > > Here we are however talking about invalid neighbors, not non-trusted > neighbors. > > I think we should modify this text so that it recommends a configuration > option for dropping BSMs on interfaces in general. This would then be > useful on both leaf subnets and on external links. This text talking > about "no PIM packets" is kind of leftover from when BSR was part of the > PIM specification. > > Next the text says: > > On multi-access subnets with multiple PIM routers and hosts that are > not trusted, we recommend that IPsec AH is used to protect > communication between PIM routers, and that such routers are > configured to drop and log communication attempts from any host that > do not pass the authentication check. When all the PIM routers are > under the same administrative control, this authentication may use a > configured shared secret. > > We should update this text to talk about both hosts and non-trusted > (or external?) PIM routers. That is, IPsec is needed if you want to only > receive BSMs from some routers but don't trust everyone on the link. > > The only real value I see with ACLs is when you don't use IPsec and have > these non-trusted multi-access links. It depends on the topology, but it > should be possible to choose the location of the candidate BSRs so that > any forged BSM coming from a multi-access subnet with one of the valid > BSR addresses will fail RPF. E.g. if the multi-access subnets are close > to the edge, and the C-BSRs are centrally located, only those routers > further towards the edge will accept the forged BSM. I should also have said that ACLs are useful on these multi-access links for blocking benign BSMs from other domains while still using BSM between your own routers. As I say above you would still be vulnerable to attacks though. Stig > > I agree this is not all that good. I'm fine with removing the ACL > recommendation and instead recommend the config option for dropping all > BSMs on external interfaces. I guess it should even be a SHOULD as this > is fairly important for most BSR deployments. > > I'm familiar with implementations that can drop all BSMs, but not with > anyone doing the ACLs. What does the rest of you think of dropping the > ACL recommendation for BSMs and just recommend configuration option for > BSR border interfaces? > > Thanks Sandy for helping me finally see this. What do you think of this > BSR border interface configuration instead of the more vague ACLs? > > Stig > >> >> --Sandy > > > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www1.ietf.org/mailman/listinfo/pim _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Mon Jul 16 12:52:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAToH-00048O-4a; Mon, 16 Jul 2007 12:52:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAToG-00045h-64 for pim@ietf.org; Mon, 16 Jul 2007 12:52:32 -0400 Received: from tyholt.uninett.no ([2001:700:1::eecb]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAToF-0002tr-IV for pim@ietf.org; Mon, 16 Jul 2007 12:52:32 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by tyholt.uninett.no (Postfix) with ESMTP id E927BB5A7A; Mon, 16 Jul 2007 18:52:30 +0200 (CEST) Received: from tyholt.uninett.no ([127.0.0.1]) by localhost (tyholt.uninett.no [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 19852-01; Mon, 16 Jul 2007 18:52:30 +0200 (CEST) Received: from [IPv6?2001?700?1?1100?2968?386d?3a84?946c] (unknown [IPv6:2001:700:1:1100:2968:386d:3a84:946c]) by tyholt.uninett.no (Postfix) with ESMTP id 206C8B5A6A; Mon, 16 Jul 2007 18:52:30 +0200 (CEST) Message-ID: <469BA24D.8090502@uninett.no> Date: Mon, 16 Jul 2007 18:52:29 +0200 From: Stig Venaas User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Sandy Murphy Subject: Re: [pim] Re: BSR update References: <20070716140154.EE1273F47E@pecan.tislabs.com> <469B9223.2030009@uninett.no> In-Reply-To: <469B9223.2030009@uninett.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at uninett.no X-Spam-Score: -2.8 (--) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: pim@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pim-bounces@ietf.org One additional comment below Stig Venaas wrote: > Sandy Murphy wrote: >>> We recommend a single domain wide shared secret for all PIM routers, >>> assuming that you trust all PIM routers in your management domain. >>> You are right that any of these can spoof the address. It is difficult >>> to restrict this further, since in general, any PIM router should be >>> able to authenticate the message and take part in hop-by-hop forwarding >>> of the messages. No changes made to the draft regarding this. >> >> Perhaps I don't understand your intended use of access lists. I >> thought the text I quoted meant that you wanted the access lists to >> give you a way to tell the valid BSR PIM routers from the PIM routers >> that are not valid BSRs. If that is true, then your access list does >> protect you against PIM routers that are accidentally mis-configured >> as being BSR capable, but not those that are also misconfigured to use >> a valid BSR address. A PIM router could assume the address of a valid >> BSR >> router undetectably, because all the PIM routers use the same domain >> wide shared secret. >> >> If the above is correct, I wonder why you go to the trouble of >> recommending >> access lists - is the protection against only-half-mis-configured >> PIM routers what you are after? If so, it would be good to state what >> protection the access lists give you. > > OK, maybe we need to be more explicit. First of all, access lists might > give some protection against misconfiguration. You would typically have > very few Candidate BSR routers and should only get BSMs with one of > those specified as the BSR (the originator of the hop-by-hop flooded > BSM). They can also be used to block BSMs from PIM neighbors that are > outside your core network (say customer/peer/ISP router). Note that > the RPF check done on the BSR address protects you from spoofed external > BSMs that appear to come from one of your own BSRs. > > Due to the RPF check someone compromising a non-BSR router (one that is > not allowed to be the BSR) will only be able to originate BSMs and get > them flooded to parts of the domain (they must pass the RPF check for > one of the 43) id 1IAToG-00045h-64 for pim@ietf.org; Mon, 16 Jul 2007 12:52:32 -0400 Received: from tyholt.uninett.no ([2001:700:1::eecb]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAToF-0002tr-IV for pim@ietf.org; Mon, 16 Jul 2007 12:52:32 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by tyholt.uninett.no (Postfix) with ESMTP id E927BB5A7A; Mon, 16 Jul 2007 18:52:30 +0200 (CEST) Received: from tyholt.uninett.no ([127.0.0.1]) by localhost (tyholt.uninett.no [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 19852-01; Mon, 16 Jul 2007 18:52:30 +0200 (CEST) Received: from [IPv6?2001?700?1?1100?2968?386d?3a84?946c] (unknown [IPv6:2001:700:1:1100:2968:386d:3a84:946c]) by tyholt.uninett.no (Postfix) with ESMTP id 206C8B5A6A; Mon, 16 Jul 2007 18:52:30 +0200 (CEST) Message-ID: <469BA24D.8090502@uninett.no> Date: Mon, 16 Jul 2007 18:52:29 +0200 From: Stig Venaas User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Sandy Murphy Subject: Re: [pim] Re: BSR update References: <20070716140154.EE1273F47E@pecan.tislabs.com> <469B9223.2030009@uninett.no> In-Reply-To: <469B9223.2030009@uninett.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at uninett.no X-Spam-Score: -2.8 (--) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: pim@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pim-bounces@ietf.org One additional comment below Stig Venaas wrote: > Sandy Murphy wrote: >>> We recommend a single domain wide shared secret for all PIM routers, >>> assuming that you trust all PIM routers in your management domain. >>> You are right that any of these can spoof the address. It is difficult >>> to restrict this further, since in general, any PIM router should be >>> able to authenticate the message and take part in hop-by-hop forwarding >>> of the messages. No changes made to the draft regarding this. >> >> Perhaps I don't understand your intended use of access lists. I >> thought the text I quoted meant that you wanted the access lists to >> give you a way to tell the valid BSR PIM routers from the PIM routers >> that are not valid BSRs. If that is true, then your access list does >> protect you against PIM routers that are accidentally mis-configured >> as being BSR capable, but not those that are also misconfigured to use >> a valid BSR address. A PIM router could assume the address of a valid >> BSR >> router undetectably, because all the PIM routers use the same domain >> wide shared secret. >> >> If the above is correct, I wonder why you go to the trouble of >> recommending >> access lists - is the protection against only-half-mis-configured >> PIM routers what you are after? If so, it would be good to state what >> protection the access lists give you. > > OK, maybe we need to be more explicit. First of all, access lists might > give some protection against misconfiguration. You would typically have > very few Candidate BSR routers and should only get BSMs with one of > those specified as the BSR (the originator of the hop-by-hop flooded > BSM). They can also be used to block BSMs from PIM neighbors that are > outside your core network (say customer/peer/ISP router). Note that > the RPF check done on the BSR address protects you from spoofed external > BSMs that appear to come from one of your own BSRs. > > Due to the RPF check someone compromising a non-BSR router (one that is > not allowed to be the BSR) will only be able to originate BSMs and get > them flooded to parts of the domain (they must pass the RPF check for > one of the valid BSD addresses). > > I admit access lists give limited protection. What I think one should > do in general is simply to discard all BSMs from non-trusted neighbors. > That is, drop BSMs on interfaces facing customer/peer/ISP routers. > > We are currently saying: > > 6.3.1. Rejecting Bootstrap Messages from Invalid Neighbors > > Most hosts that are likely to attempt to subvert PIM BSR are likely to > be located on leaf subnets. We recommend that implementers provide a > configuration option that specifies an interface is a leaf subnet, and > that no PIM packets are accepted on such interfaces. > > Here we are however talking about invalid neighbors, not non-trusted > neighbors. > > I think we should modify this text so that it recommends a configuration > option for dropping BSMs on interfaces in general. This would then be > useful on both leaf subnets and on external links. This text talking > about "no PIM packets" is kind of leftover from when BSR was part of the > PIM specification. > > Next the text says: > > On multi-access subnets with multiple PIM routers and hosts that are > not trusted, we recommend that IPsec AH is used to protect > communication between PIM routers, and that such routers are > configured to drop and log communication attempts from any host that > do not pass the authentication check. When all the PIM routers are > under the same administrative control, this authentication may use a > configured shared secret. > > We should update this text to talk about both hosts and non-trusted > (or external?) PIM routers. That is, IPsec is needed if you want to only > receive BSMs from some routers but don't trust everyone on the link. > > The only real value I see with ACLs is when you don't use IPsec and have > these non-trusted multi-access links. It depends on the topology, but it > should be possible to choose the location of the candidate BSRs so that > any forged BSM coming from a multi-access subnet with one of the valid > BSR addresses will fail RPF. E.g. if the multi-access subnets are close > to the edge, and the C-BSRs are centrally located, only those routers > further towards the edge will accept the forged BSM. I should also have said that ACLs are useful on these multi-access links for blocking benign BSMs from other domains while still using BSM between your own routers. As I say above you would still be vulnerable to attacks though. Stig > > I agree this is not all that good. I'm fine with removing the ACL > recommendation and instead recommend the config option for dropping all > BSMs on external interfaces. I guess it should even be a SHOULD as this > is fairly important for most BSR deployments. > > I'm familiar with implementations that can drop all BSMs, but not with > anyone doing the ACLs. What does the rest of you think of dropping the > ACL recommendation for BSMs and just recommend configuration option for > BSR border interfaces? > > Thanks Sandy for helping me finally see this. What do you think of this > BSR border interface configuration instead of the more vague ACLs? > > Stig > >> >> --Sandy > > > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www1.ietf.org/mailman/listinfo/pim _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim valid BSD addresses). > > I admit access lists give limited protection. What I think one should > do in general is simply to discard all BSMs from non-trusted neighbors. > That is, drop BSMs on interfaces facing customer/peer/ISP routers. > > We are currently saying: > > 6.3.1. Rejecting Bootstrap Messages from Invalid Neighbors > > Most hosts that are likely to attempt to subvert PIM BSR are likely to > be located on leaf subnets. We recommend that implementers provide a > configuration option that specifies an interface is a leaf subnet, and > that no PIM packets are accepted on such interfaces. > > Here we are however talking about invalid neighbors, not non-trusted > neighbors. > > I think we should modify this text so that it recommends a configuration > option for dropping BSMs on interfaces in general. This would then be > useful on both leaf subnets and on external links. This text talking > about "no PIM packets" is kind of leftover from when BSR was part of the > PIM specification. > > Next the text says: > > On multi-access subnets with multiple PIM routers and hosts that are > not trusted, we recommend that IPsec AH is used to protect > communication between PIM routers, and that such routers are > configured to drop and log communication attempts from any host that > do not pass the authentication check. When all the PIM routers are > under the same administrative control, this authentication may use a > configured shared secret. > > We should update this text to talk about both hosts and non-trusted > (or external?) PIM routers. That is, IPsec is needed if you want to only > receive BSMs from some routers but don't trust everyone on the link. > > The only real value I see with ACLs is when you don't use IPsec and have > these non-trusted multi-access links. It depends on the topology, but it > should be possible to choose the location of the candidate BSRs so that > any forged BSM coming from a multi-access subnet with one of the valid > BSR addresses will fail RPF. E.g. if the multi-access subnets are close > to the edge, and the C-BSRs are centrally located, only those routers > further towards the edge will accept the forged BSM. I should also have said that ACLs are useful on these multi-access links for blocking benign BSMs from other domains while still using BSM between your own routers. As I say above you would still be vulnerable to attacks though. Stig > > I agree this is not all that good. I'm fine with removing the ACL > recommendation and instead recommend the config option for dropping all > BSMs on external interfaces. I guess it should even be a SHOULD as this > is fairly important for most BSR deployments. > > I'm familiar with implementations that can drop all BSMs, but not with > anyone doing the ACLs. What does the rest of you think of dropping the > ACL recommendation for BSMs and just recommend configuration option for > BSR border interfaces? > > Thanks Sandy for helping me finally see this. What do you think of this > BSR border interface configuration instead of the more vague ACLs? > > Stig > >> >> --Sandy > > > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www1.ietf.org/mailman/listinfo/pim _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Mon Jul 16 13:07:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAU2I-0008Qr-E0; Mon, 16 Jul 2007 13:07:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IARW1-0001Ab-JD for pim@ietf.org; Mon, 16 Jul 2007 10:25:33 -0400 Received: from nutshell.tislabs.com ([192.94.214.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IARVx-0005GL-Aa for pim@ietf.org; Mon, 16 Jul 2007 10:25:33 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id l6GEMwuQ017011; Mon, 16 Jul 2007 10:22:58 -0400 (EDT) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAATcaqdH; Mon, 16 Jul 07 10:22:08 -0400 Received: by pecan.tislabs.com (Postfix, from userid 2005) id EE1273F47E; Mon, 16 Jul 2007 10:01:54 -0400 (EDT) To: pim@ietf.org, stig.venaas@uninett.no In-Reply-To: <469A09A4.5090708@uninett.no> Message-Id: <20070716140154.EE1273F47E@pecan.tislabs.com> Date: Mon, 16 Jul 2007 10:01:54 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-Mailman-Approved-At: Mon, 16 Jul 2007 13:07:00 -0400 Cc: sandy@tislabs.com Subject: [pim] Re: BSR update X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pim-bounces@ietf.org >We recommend a single domain wide shared secret for all PIM routers, >assuming that you trust all PIM routers in your management domain. >You are right that any of these can spoof the address. It is difficult >to restrict this further, since in general, any PIM router should be >able to authenticate the message and take part in hop-by-hop forwarding >of the messages. No changes made to the draft regarding this. Perhaps I don't understand your intended use of access lists. I thought the text I quoted meant that you wanted the access lists to give you a way to tell the valid BSR PIM routers from the PIM routers that are not valid BSRs. If that is true, then your access list does protect you against PIM routers that are accidentally mis-configured as being BSR capable, but not those that are also misconfigured to use a valid BSR address. A PIM router could assume the address of a valid BSR router undetectably, because all the PIM routers use the same domain wide shared secret. If the above is correct, I wonder why you go to the trouble of recommending access lists - is the protection against only-half-mis-configured PIM routers what you are after? If so, it would be good to state what protection the access lists give you. --Sandy _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From sample@mx.broad-tech.net Mon Jul 16 22:23:42 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAciz-0005tU-Vm for pim-archive@lists.ietf.org; Mon, 16 Jul 2007 22:23:41 -0400 Received: from pd5fe76.tokyff01.ap.so-net.ne.jp ([202.213.254.118] helo=mx.broad-tech.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAciu-0002PM-Gm for pim-archive@lists.ietf.org; Mon, 16 Jul 2007 22:23:41 -0400 Received: by mx.broad-tech.net (Postfix, from userid 12359) id 307106437C7; Tue, 17 Jul 2007 10:20:07 +0900 (JST) To: pim-archive@lists.ietf.org Subject: Join the PowerSeller Program Now From: eBay PowerSellers Content-Type: text/html Message-Id: <20070717012007.307106437C7@mx.broad-tech.net> Date: Tue, 17 Jul 2007 10:20:07 +0900 (JST) X-Spam-Score: 4.8 (++++) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 eBay sent this message to an eBay Seller.
eBay sent this message to an eBay Seller.
Your registered name is included to show this message originated from eBay. Learn more.
Dear eBay Seller,

Congratulations! Your recent selling activity entitles you to Bronze status in the eBay PowerSeller Program. Your membership comes with some great benefits and services:
See the PowerSeller icon next to your User ID
Free seller support via Live Chat, Monday-Friday, 6am-2pm PST.
Get exclusive offerings on the PowerSeller portal--check back often for updates!
Network on the exclusive PowerSeller Discussion Board.
Download free business templates for PowerSeller business cards and letterhead.

Be sure to sign up today--it's FREE! Visit www.ebay.com/powerseller and click "Member Sign In." Please note that to activate your membership, you must register today.

Again, congratulations and best wishes for your continued success!

Sincerely,
eBay PowerSeller Team

eBay sent this communication to you because of your outstanding feedback, high sales, and good account standing. If you would not like to be invited to join the PowerSeller program, follow the directions above, click "Member Sign In", and then click "Decline" at the bottom of the page. Please note that it may take up to 10 days to process your request.

Visit our Privacy Policy and User Agreement if you have any questions.

Learn More to protect yourself from Spoof (fake) e-mails.

Copyright © 2007 eBay Inc. All Rights Reserved.
Designated trademarks and brands are the property of their respective owners.
eBay and the eBay logo are trademarks of eBay Inc.
eBay is located at 2145 Hamilton Avenue, San Jose, CA 95125.

 

From pim-bounces@ietf.org Tue Jul 17 12:02:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IApUk-0003Tk-G0; Tue, 17 Jul 2007 12:01:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IApUj-0003Te-Ib for pim@ietf.org; Tue, 17 Jul 2007 12:01:49 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IApUi-0005Xg-59 for pim@ietf.org; Tue, 17 Jul 2007 12:01:49 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 17 Jul 2007 09:01:47 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CANaEnEarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,546,1175497200"; d="scan'208"; a="6835096:sNHT11826522" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l6HG1lSk018258 for ; Tue, 17 Jul 2007 09:01:47 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l6HG1ZT5027230 for ; Tue, 17 Jul 2007 16:01:47 GMT Received: from xmb-sjc-219.amer.cisco.com ([171.70.151.188]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 09:01:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [pim] pimwg agenda in Chicago Date: Tue, 17 Jul 2007 09:01:32 -0700 Message-ID: <47951CBFA6409B4C8916514FCB05BFBE02867116@xmb-sjc-219.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pim] pimwg agenda in Chicago Thread-Index: AcfIi76FqA1G9AKdTMWW5vOEbsTOiQ== From: "Mike McBride \(mmcbride\)" To: X-OriginalArrivalTime: 17 Jul 2007 16:01:29.0859 (UTC) FILETIME=[BCE6A530:01C7C88B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=349; t=1184688107; x=1185552107; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mmcbride@cisco.com; z=From:=20=22Mike=20McBride=20\(mmcbride\)=22=20 |Subject:=20[pim]=20=20pimwg=20agenda=20in=20Chicago |Sender:=20; bh=t6p+XGPPCmzmTi0ouL6nFmbEjIA7GEwzkVIAxnY1Ji4=; b=ej/OpguFkbSj1UXIRtX5qlG32WXKjOmEWhTsXIIfHd1UQdLh7wK8mIq38TA20Wyh0/pPk4d+ XgHJU+gKcboxATq/Y483lan5ymXw4uvca32OZuDNDH98rvKxID1GkD7r; Authentication-Results: sj-dkim-3; header.From=mmcbride@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pim-bounces@ietf.org We will meet Wednesday, July 25th from 1510-1610. Here is the agenda: draft/charter status M. McBride draft-hilt-pim-tree-unreachability-00 B. Hilt draft-ietf-pim-sm-linklocal-01 B. Atwood draft-ietf-pim-sm-bsr S. Venaas Please let me know if you would like additional topics discussed. mike _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Mon Jul 23 13:15:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID1Uz-0005c2-Gy; Mon, 23 Jul 2007 13:15:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID1Us-0005Gt-Hw; Mon, 23 Jul 2007 13:15:02 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID1Us-0002qn-4C; Mon, 23 Jul 2007 13:15:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id E7D3B2AC7E; Mon, 23 Jul 2007 17:15:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ID1Ur-0007JQ-Li; Mon, 23 Jul 2007 13:15:01 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: ietf-announce@ietf.org From: IESG Secretary Message-Id: Date: Mon, 23 Jul 2007 13:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Mike McBride , pim@ietf.org Subject: [pim] WG Action: RECHARTER: Protocol Independent Multicast (pim) X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pim-bounces@ietf.org The charter of the Protocol Independent Multicast (pim) working group in the Routing Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. +++ Protocol Independent Multicast (pim) ===================================== Current Status: Active Working Group Chair(s): Mike McBride Tom Pusateri Routing Area Director(s): Ross Callon David Ward Routing Area Advisor: David Ward Mailing Lists: General Discussion: pim@ietf.org To Subscribe: http://www1.ietf.org/mailman/listinfo/pim/ Archive: http://www.ietf.org/mail-archive/web/pim/index.html Description of Working Group: The Protocol Independent Multicast (PIM) Working Group has completed the standardization of PIM with RFC 4601. The WG has determined there is additional work to be accomplished and is chartered to standardize extensions to RFC 4601 - Protocol Independent Multicast Version 2 - Sparse Mode. These PIM extensions will involve reliability, resiliency, scalability, management, and security. The PIM WG will consider implications of VPN service on PIM when it's a component of that service or when PIM interfaces with that service at a VPN edge. If L2VPN or L3VPN WGs determine that support for multicast in L2VPNs and/or L3VPNs requires extensions to PIM, then such extensions could be developed within the PIM WG. Additional work on the PIM-BIDIR and BSR drafts may also be necessary by the WG as these drafts progress through Standards Track. The working group will continue to specify the MIB modules required for PIM and its enhancements. The PIM WG will further enhance RFC4601 as an even more scalable, efficient and robust multicast routing protocol, which is capable of supporting thousands of groups, different types of multicast applications, and all major underlying layer-2 subnetwork technologies. We will accomplish these enhancements by submitting drafts, to the IESG, involving reliable pim, pim join attributes and pim authentication. The working group will initiate a new re-chartering effort if it is determined that a Version 3 of PIM is required. Goals and Milestones: Jul 2007 Ratify new WG charter and milestones Dec 2007 Submit the BSR spec as a Proposed Standard to the IESG Dec 2007 Submit the BSR MIB as a Proposed Standard to the IESG Mar 2008 Submit a more reliable pim solution (refresh reduction) to the IESG Mar 2008 Submit a generic TLV PIM Join Attribute PS draft to the IESG Mar 2008 Submit RPF Vector (use of PIM Join Attribute) as PS to the IESG Mar 2008 Submit a way to authenticate PIM link local messages as PS to the IESG Mar 2008 Submit an Informational PIM last hop threats document to the IESG _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Wed Jul 25 12:28:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDjih-00053c-Nb; Wed, 25 Jul 2007 12:28:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDjig-00051Z-8v for pim@ietf.org; Wed, 25 Jul 2007 12:28:14 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDjif-0004Ce-B2 for pim@ietf.org; Wed, 25 Jul 2007 12:28:14 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 25 Jul 2007 09:28:13 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAHcWp0arR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,581,1175497200"; d="scan'208"; a="388103721:sNHT32437608" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6PGSCH3006136 for ; Wed, 25 Jul 2007 09:28:12 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l6PGRoU9028447 for ; Wed, 25 Jul 2007 16:28:12 GMT Received: from xmb-sjc-219.amer.cisco.com ([171.70.151.188]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 09:28:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [pim] PIM refresh reduction discussion Date: Wed, 25 Jul 2007 09:28:05 -0700 Message-ID: <47951CBFA6409B4C8916514FCB05BFBE028D59D0@xmb-sjc-219.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pim] PIM refresh reduction discussion Thread-Index: AcetL7MvWKDTszLfQNiyGbt+GpkoaQMoiZpQBUElgjA= From: "Mike McBride \(mmcbride\)" To: X-OriginalArrivalTime: 25 Jul 2007 16:28:02.0712 (UTC) FILETIME=[C59EB980:01C7CED8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4631; t=1185380892; x=1186244892; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mmcbride@cisco.com; z=From:=20=22Mike=20McBride=20\(mmcbride\)=22=20 |Subject:=20[pim]=20PIM=20refresh=20reduction=20discussion |Sender:=20; bh=jT/Jecqs+vEmSRRCYmxl8hfjMjbDJ+2nAIArhL5gIt8=; b=ma00Vs1ycBkmKui0Qsz95wY4FVrunJ0Fy/XjTI5FTPLUD0zpCEDoYuo6TIWGU2466VezNtdn BBsYUdHEaOx6amgJyu1f+xf1ia9Hgm5SeXpOCvG1yboYDSgWLGdxSWEZ2rkIemtYNWrb16/KfL nrt/ELUBgbffhn+q8/rdJWhWo=; Authentication-Results: sj-dkim-1; header.From=mmcbride@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -3.2 (---) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pim-bounces@ietf.org For a complete view of the discussion which occurred on the pim-state list, please go here: http://www3.ietf.org/proceedings/07jul/slides/pim-2.txt =20 Suresh has provided a summary below.=20 Refresh reduction or refresh elimination *The consensus seemed to be to keep refreshes and use holdtime in the JP PDU to eliminate them if someone wants it by setting the hold time to max value. Otherwise, state would be refreshed every 30 minutes (or some such large value). Reliability *Every JP PDU gets acked. A Hello option will help determine if all routers on the LAN support JP ACK or not. If not, we revert back to existing behavior. How to achieve refresh reduction *One of the goals was to make as minimal changes to PIM as possible. Dino's suggestion was to use a new message type, say Join Ack, which would look exactly like the JP Pdu. The upstream router that receives a JP reflects back the same PDU to the downstream router by just changing the PDU type.=20 *To differentiate between successive state changes, we need to have a sequence number. Where we differed:=20 *Dino wanted to overload one of the reserved fields in the source address field to use it as a sequence number per route.=20 *Bob and I prefer that there be a seq num per PDU. The idea here was to have a seq# TLV and just ack that in the JP Ack PDU.=20 I think if we combine the two approaches, we get the following. See if this is agreeable to you guys (I will use an example here): oLet's say there are entries E1, E2, E3, E4 that have Joins scheduled to be sent.=20 oThe JP PDU will contain the entries E1 thru E4 as Joins.=20 oA seq num TLV gets assigned to the PDU. Let's say the seq num is 1. All entries get the seq number of the PDU they go in so that effectively, each entry is associated with a seq num (what Dino wants). =20 oThe JP PDU is sent out. A retransmission timer is started for the PDU that starts off at a low value and backs off exponentially.=20 oThe ACK is just a reflection of the JP PDU by changing the PDU type. When the ACK is received, all entries associated with that PDU are considered ACKed by the router that sent the JP PDU. For any other downstream router, the seq number is meaningless. It processes the ACK just as it processes a "See Join" or "See Prune" event. This gives the other routers one more chance to see the PDU just in case they missed the Join.=20 oBefore the ACK is received, if the state changes for an entry, say E1 changes from a Join to Prune, E1 is added to a new PDU with seq #2. Before PDU 2 gets sent out, if the state changes again, E1 simply gets updated without having to change the seq number. So E1's seq number is now 2. oIf an ACK is received for seq #1, E2 thru E4 are considered ACKed, but not E1, since E1 is not associated with seq #1 anymore. So the router that processes the ACK does not really care about the contents of the JP PDU, except the seq number and its notion of which entries correspond to the seq number. Another way to look at it is to say that it goes through each entry in the PDU and considers those entries acked whose seq number match that of the PDU. Other issues *Both JP and JP Acks are multicast. This preserves Join Suppression. There is still a problem where one downstream router Prunes a state and the Upstream router Acks it back and this exchange (both the JP and the JP ACK) is not seen by another downstream router that wants the state. Now there is no traffic flowing on the LAN until this router refreshes its state after a long period of time, if it decides to do so. The only solution to this is to have explicit tracking.=20 *There was also mention of ensuring bidirectional connectivity for adjacencies. I think this should be addressed as well as part of reliability. Once a JP Exchange occurs, if there is error on the link leaving only one way connectivity where the Hellos sent by the Upstream router are seen by the downstream router, but not vice-versa, data forwarding simply stops, since the upstream router would have cleaned up all downstream state while the downstream router assumes the upstream router has all the state. This can be fixed by having a new 2Way Hello option wherein each router adds its nbr IP in the TLV (OSPF style). This is especially important when we are running PIM on overlay networks like in L3VPN. *Lastly, the need for L2 snooping devices to be able to request states to build snooping state was mentioned. Modifying Hellos with GenId 0 to force routers to refresh their state is a solution. _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Fri Jul 27 11:23:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IERee-00036z-O5; Fri, 27 Jul 2007 11:23:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IERee-00036u-2s for pim@ietf.org; Fri, 27 Jul 2007 11:23:00 -0400 Received: from tyholt.uninett.no ([2001:700:1::eecb]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IERed-0006lC-0C for pim@ietf.org; Fri, 27 Jul 2007 11:23:00 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by tyholt.uninett.no (Postfix) with ESMTP id D22C6B5A8C; Fri, 27 Jul 2007 17:22:53 +0200 (CEST) Received: from tyholt.uninett.no ([127.0.0.1]) by localhost (tyholt.uninett.no [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 03495-01-20; Fri, 27 Jul 2007 17:22:53 +0200 (CEST) Received: from [IPv6?2001?df8?0?80?34a7?81af?8ff5?d7a4] (unknown [IPv6:2001:df8:0:80:34a7:81af:8ff5:d7a4]) by tyholt.uninett.no (Postfix) with ESMTP id DAD8EB5A7A; Fri, 27 Jul 2007 17:22:52 +0200 (CEST) Message-ID: <46AA161B.4040406@uninett.no> Date: Fri, 27 Jul 2007 17:58:19 +0200 From: Stig Venaas User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: pim@ietf.org, Sandy Murphy Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at uninett.no X-Spam-Score: -1.4 (-) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: Subject: [pim] Proposed update of draft-ietf-pim-bsr-11 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pim-bounces@ietf.org As was discussed between Sandy Murphy and me in a previous mail on the list (and in the wg meeting yesterday), there is little value in the ACLs recommended in the security considerations for filtering BSMs by the BSR address. I also realized that the draft did not recommend BSR Border functionality which is common in implementations and quite simple and useful. Below is the new text I propose for 6.3 Bootstrap Message Security. Apart from the change above there should be no changes apart from the text being partly restructured. Unless I get any negative comments I'll submit revision 12 with this change beginning of next week. Stig 6.3. Bootstrap Message Security If a legitimate PIM router in a domain is compromised, there is little any security mechanism can do to prevent that router subverting PIM traffic in that domain. Implementations SHOULD provide a per interface configuration option where one can specify that no Bootstrap messages are to be sent out of or accepted on the interface. This should generally be configured on all PMBRs in order to not receive messages from neighboring domains. This avoids receiving legitimate messages with conflicting BSR information from other domains, and also prevents BSR attacks from neighboring domains. This option is also useful on leaf interfaces where there are only hosts present. However, the Security Considerations section of [1], say that there should be a mechanism for not accepting PIM Hello messages on leaf interfaces and messages are only accepted from valid PIM neighbors. There may however be additional issues with unicast Bootstrap messages, see below. In addition to dropping all multicast Bootstrap messages on PMBRs we also recommend configuring PMBRs (both towards other domains and on leaf interfaces) to drop all unicast PIM messages (Bootstrap message, Candidate RP Advertisement, PIM register and PIM register stop). 6.3.1. Unicast Bootstrap Messages There are some possible security issues with unicast Bootstrap Messages. The Bootstrap Message Processing Checks prevent a router from accepting a Bootstrap message from outside of the PIM Domain, as the source address on Bootstrap messages must be an immediate PIM neighbor. There is however a small window of time after a reboot where a PIM router will accept a bad Bootstrap message unicast from an immediate neighbor, and it might be possible to unicast a Bootstrap message to a router during this interval from outside the domain, using the spoofed source address of a neighbor. This can be prevented if PMBRs perform source-address filtering to prevent packets entering the PIM domain with IP source addresses that are infrastructure addresses in the PIM domain. The best way to protect against this is as mentioned above to configure border and leaf interfaces to drop all bootstrap messages, including unicast messages. The use of unicast BSMs is for backwards compatibility only. Due to the possible security implications, implementations supporting unicast BSMs SHOULD provide a configuration option for whether they are to be used. 6.3.2. Multi-access subnets We recommend that implementers provide a configuration option to drop Bootstrap messages on leaf interfaces and interfaces facing other domains. On multi-access subnets with both PIM routers in the domain and PIM routers outside the domain or non-trusted hosts, we recommend that IPsec AH is used to protect communication between the PIM routers in the domain, and that such routers are configured to drop and log communication attempts from any host that do not pass the authentication check. When all the PIM routers are under the same administrative control, this authentication may use a configured shared secret. In order to prevent replay attacks one will need to have one SA per sender using the sender address for SA lookup. The securing of interactions between PIM neighbors is discussed in more detail in the Security Considerations section of [1], and so we do not discuss the details further here. The same security mechanisms that can be used to secure PIM Join, Prune and Assert messages should also be used to secure Bootstrap messages. How exactly to secure PIM link-local messages is still being worked on by the PIM working group, see [10]. _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Fri Jul 27 12:09:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IESNI-00051B-2O; Fri, 27 Jul 2007 12:09:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IESNH-00050w-FH for pim@ietf.org; Fri, 27 Jul 2007 12:09:07 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IESNG-0007vR-4j for pim@ietf.org; Fri, 27 Jul 2007 12:09:07 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 27 Jul 2007 09:08:58 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAMa0qUarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,589,1175497200"; d="scan'208"; a="168457571:sNHT4381167537" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6RG8wA6015718; Fri, 27 Jul 2007 09:08:58 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6RG8tAG011986; Fri, 27 Jul 2007 16:08:55 GMT Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jul 2007 09:08:53 -0700 Received: from [130.129.18.231] ([10.82.220.83]) by xmb-sjc-22c.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jul 2007 09:08:52 -0700 In-Reply-To: <46AA161B.4040406@uninett.no> References: <46AA161B.4040406@uninett.no> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0F0207FF-CFF1-42D0-BAE9-EDC569318858@cisco.com> Content-Transfer-Encoding: 7bit From: John Zwiebel Subject: Re: [pim] Proposed update of draft-ietf-pim-bsr-11 Date: Fri, 27 Jul 2007 09:08:48 -0700 To: Stig Venaas X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 27 Jul 2007 16:08:53.0582 (UTC) FILETIME=[6D82E6E0:01C7D068] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1110; t=1185552538; x=1186416538; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jzwiebel@cisco.com; z=From:=20John=20Zwiebel=20 |Subject:=20Re=3A=20[pim]=20Proposed=20update=20of=20draft-ietf-pim-bsr-1 1 |Sender:=20; bh=IMiw1BcVdeJY7zO9Lq8nMDMTyALEILcU/RrcX/kmn2E=; b=XZU20E2gLHZsyJlou9bkBDwRTVYbTqlVv/AZfj5IDGmd2DuYaOcfhTUoQnATS0ia6yuzp0EP le19Dn5EFRPrkP5SRyJugLmlG8axaRY+g+rOuu+fTaYrI360tMZ6M5o4; Authentication-Results: sj-dkim-2; header.From=jzwiebel@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: pim@ietf.org, Sandy Murphy X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pim-bounces@ietf.org On Jul 27, 2007, at 8:58 AM, Stig Venaas wrote: > There > is however a small window of time after a reboot where a PIM router > will shouldn't this be "may"? > accept a bad Bootstrap message unicast from an immediate neighbor, and > it might be possible to unicast a Bootstrap message to a router during > this interval from outside the domain, Doesn't this depend on whether or not PIM comes up with the border in place or not? ie, an implementation shouldn't accept any BSR messages so it shouldn't have sent out a hello until it is completely up. > 6.3.2. Multi-access subnets > this section seems to assume that there are two routers for the same domain on the same multi-access link. In this case, shouldn't the interfaces be configured with the "ip pim border" anyway so that no BSMs are accepted or sent on these interfaces. Any RP messages should arrive at these border routers through some internal connections so you shouldn't have to worry about setting up any shared secrets here. (which doesn't mean that administrators might not do this.) _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Fri Jul 27 15:34:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEVa0-00025I-VG; Fri, 27 Jul 2007 15:34:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEVZz-00025C-Le for pim@ietf.org; Fri, 27 Jul 2007 15:34:27 -0400 Received: from tyholt.uninett.no ([2001:700:1::eecb]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEVZz-0004r6-2b for pim@ietf.org; Fri, 27 Jul 2007 15:34:27 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by tyholt.uninett.no (Postfix) with ESMTP id CF203B5A7D; Fri, 27 Jul 2007 21:34:25 +0200 (CEST) Received: from tyholt.uninett.no ([127.0.0.1]) by localhost (tyholt.uninett.no [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 07170-02-30; Fri, 27 Jul 2007 21:34:25 +0200 (CEST) Received: from [IPv6?2001?df8?0?80?34a7?81af?8ff5?d7a4] (unknown [IPv6:2001:df8:0:80:34a7:81af:8ff5:d7a4]) by tyholt.uninett.no (Postfix) with ESMTP id E0DE7B5A7A; Fri, 27 Jul 2007 21:34:24 +0200 (CEST) Message-ID: <46AA4895.9090707@uninett.no> Date: Fri, 27 Jul 2007 21:33:41 +0200 From: Stig Venaas User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: John Zwiebel Subject: Re: [pim] Proposed update of draft-ietf-pim-bsr-11 References: <46AA161B.4040406@uninett.no> <0F0207FF-CFF1-42D0-BAE9-EDC569318858@cisco.com> In-Reply-To: <0F0207FF-CFF1-42D0-BAE9-EDC569318858@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at uninett.no X-Spam-Score: -1.4 (-) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: pim@ietf.org, Sandy Murphy X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pim-bounces@ietf.org John Zwiebel wrote: > > On Jul 27, 2007, at 8:58 AM, Stig Venaas wrote: > >> There >> is however a small window of time after a reboot where a PIM router will > shouldn't this be "may"? >> accept a bad Bootstrap message unicast from an immediate neighbor, and >> it might be possible to unicast a Bootstrap message to a router during >> this interval from outside the domain, > > Doesn't this depend on whether or not PIM comes up with the border > in place or not? ie, an implementation shouldn't accept any BSR > messages so it shouldn't have sent out a hello until it is completely up. Note that at the end of that section I say that this can be avoided using BSR Border. Perhaps I should try to rephrase it so that it says earlier in the section that this applies to when BSR border is not used. > > >> 6.3.2. Multi-access subnets >> > this section seems to assume that there are two routers for the same > domain on the same multi-access link. In this case, shouldn't the > interfaces be configured with the "ip pim border" anyway so that no > BSMs are accepted or sent on these interfaces. Any RP messages > should arrive at these border routers through some internal connections > so you shouldn't have to worry about setting up any shared secrets > here. Agree. It depends on the topology and the location of the e-BSR, but this should generally be fine. I'll try to add some text to clarify that. Thanks, at least someone is reading my posts :) Stig > > (which doesn't mean that administrators might not do this.) > > _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Mon Jul 30 08:19:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFUD8-0000Kl-Ft; Mon, 30 Jul 2007 08:18:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFUD7-0000K9-IX for pim@ietf.org; Mon, 30 Jul 2007 08:18:53 -0400 Received: from tyholt.uninett.no ([2001:700:1::eecb]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFUD6-0004Uj-D2 for pim@ietf.org; Mon, 30 Jul 2007 08:18:53 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by tyholt.uninett.no (Postfix) with ESMTP id 0AD1DB5A8B; Mon, 30 Jul 2007 14:18:51 +0200 (CEST) Received: from tyholt.uninett.no ([127.0.0.1]) by localhost (tyholt.uninett.no [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 30606-01-99; Mon, 30 Jul 2007 14:18:50 +0200 (CEST) Received: from [IPv6?2001?700?1?7?215?f2ff?fe35?307d] (sverresborg.uninett.no [IPv6:2001:700:1:7:215:f2ff:fe35:307d]) by tyholt.uninett.no (Postfix) with ESMTP id 8084CB5A6C; Mon, 30 Jul 2007 14:18:50 +0200 (CEST) Message-ID: <46ADD72A.4070905@uninett.no> Date: Mon, 30 Jul 2007 14:18:50 +0200 From: Stig Venaas User-Agent: Thunderbird 2.0.0.4 (X11/20070627) MIME-Version: 1.0 To: John Zwiebel Subject: Re: [pim] Proposed update of draft-ietf-pim-bsr-11 References: <46AA161B.4040406@uninett.no> <0F0207FF-CFF1-42D0-BAE9-EDC569318858@cisco.com> <46AA4895.9090707@uninett.no> In-Reply-To: <46AA4895.9090707@uninett.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at uninett.no X-Spam-Score: -1.4 (-) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: pim@ietf.org, Sandy Murphy X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pim-bounces@ietf.org Stig Venaas wrote: > John Zwiebel wrote: >> >> On Jul 27, 2007, at 8:58 AM, Stig Venaas wrote: >> >>> There >>> is however a small window of time after a reboot where a PIM router will >> shouldn't this be "may"? >>> accept a bad Bootstrap message unicast from an immediate neighbor, and >>> it might be possible to unicast a Bootstrap message to a router during >>> this interval from outside the domain, >> >> Doesn't this depend on whether or not PIM comes up with the border >> in place or not? ie, an implementation shouldn't accept any BSR >> messages so it shouldn't have sent out a hello until it is completely up. > > Note that at the end of that section I say that this can be avoided > using BSR Border. Perhaps I should try to rephrase it so that it says > earlier in the section that this applies to when BSR border is not used. I've now changed 6.3.1 to the following: There are some possible security issues with unicast Bootstrap Messages. The Bootstrap Message Processing Checks prevent a router from accepting a Bootstrap message from outside of the PIM Domain, as the source address on Bootstrap messages must be an immediate PIM neighbor. There is however a small window of time after a reboot where a PIM router will accept a bad Bootstrap message unicast from an immediate neighbor, and it might be possible to unicast a Bootstrap message to a router during this interval from outside the domain, using the spoofed source address of a neighbor. The best way to protect against this is to use the above mentioned mechanism configuring border and leaf interfaces to drop all bootstrap messages, including unicast messages. This can also be prevented if PMBRs perform source-address filtering to prevent packets entering the PIM domain with IP source addresses that are infrastructure addresses in the PIM domain. The use of unicast BSMs is for backwards compatibility only. Due to the possible security implications, implementations supporting unicast BSMs SHOULD provide a configuration option for whether they are to be used. >> >> >>> 6.3.2. Multi-access subnets >>> >> this section seems to assume that there are two routers for the same >> domain on the same multi-access link. In this case, shouldn't the >> interfaces be configured with the "ip pim border" anyway so that no >> BSMs are accepted or sent on these interfaces. Any RP messages >> should arrive at these border routers through some internal connections >> so you shouldn't have to worry about setting up any shared secrets >> here. > > Agree. It depends on the topology and the location of the e-BSR, but > this should generally be fine. I'll try to add some text to clarify > that. I've now changed the first part of 6.3.2 to the following: As mentioned above, implementations SHOULD provide a per interface configuration option so that leaf interfaces and interfaces facing other domains can be configured to drop all bootstrap messages. In this section we will consider multi-access subnets where there are both multiple PIM routers in a PIM domain and also PIM routers outside the PIM domain or non-trusted hosts. On such links one should if possible configure the PMBRs to drop Bootstrap messages. This is possible provided that the routers in the PIM domain receive Bootstrap messages on other internal links. That is, for each of the routers on the multi-access link that are in our domain, the RPF interface for each of the candidate BSR addresses must be an internal interface (an interface not on a multi-access link). There are however network topologies where this is not possible. With such topologies, we recommend that IPsec AH is used to protect communication between the PIM routers in the domain, and that such routers are configured to drop and log communication attempts from any host that do not pass the authentication check. When all the PIM routers are under the same administrative ... Unless I get any negative feedback I'll submit a new revision with this new text shortly. Stig > > Thanks, at least someone is reading my posts :) > > Stig > >> >> (which doesn't mean that administrators might not do this.) >> >> > > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www1.ietf.org/mailman/listinfo/pim _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim