From Sandra.Murphy@sparta.com Wed Aug 1 06:09:43 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB72711E8601 for ; Wed, 1 Aug 2012 06:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcdYpCniE0GY for ; Wed, 1 Aug 2012 06:09:43 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id CB7AB11E861E for ; Wed, 1 Aug 2012 06:09:42 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q71D9fmO025110 for ; Wed, 1 Aug 2012 08:09:41 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q71D9fRE032223 for ; Wed, 1 Aug 2012 08:09:41 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0355.002; Wed, 1 Aug 2012 09:09:49 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: all slides uploaded Thread-Index: Ac1v4vopmDBBeYBsRiCXjuH2DcfLcw== Date: Wed, 1 Aug 2012 13:09:48 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F364BB@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] all slides uploaded X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 13:09:44 -0000 All slides for today's session are uploaded.=0A= =0A= Presenters should check the uploaded version to be sure the upload got the = right version and appears correct. Alert the chairs sidr-chairs@ietf.org i= f there is anything wrong.=0A= =0A= --Sandy, speaking as co-chair= From jgs@juniper.net Wed Aug 1 17:21:12 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7022111E80EC for ; Wed, 1 Aug 2012 17:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yF-zkxWx3gX4 for ; Wed, 1 Aug 2012 17:21:11 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 7E85111E809A for ; Wed, 1 Aug 2012 17:21:11 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKUBnH9y1IbuW2q5Pm/riWiIDHZu5EaS6K@postini.com; Wed, 01 Aug 2012 17:21:11 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 1 Aug 2012 17:18:03 -0700 Received: from jgs-sslvpn-nc.jnpr.net (jgs-sslvpn-nc.jnpr.net [172.23.2.14]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q720I3h65776 for ; Wed, 1 Aug 2012 17:18:03 -0700 (PDT) (envelope-from jgs@juniper.net) From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Aug 2012 17:18:02 -0700 Message-ID: To: sidr wg list MIME-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [sidr] bgpsec confeds bug, with fix X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 00:21:12 -0000 Randy, Sandy and I realized there is a problem with confeds. As written = right now, the entering-the-confed marker is applied by the first router = sending the route across an internal-to-the-confed boundary (let's call = this router R). It can't be applied by the external peer router sending = it to the confed in EBGP, since it has no clue (that's the nature of a = confed), and it can't be applied by the border router within the confed = (called router B) that's receiving it from that external peer, since it = doesn't apply a signature (we only do that when sending routes across = EBGP, or confed-EBGP).=20 So, how does router R figure out it should apply the marker? In short, = it can't. After discussing a few possible solutions, we came up with two = alternatives: Have router B do the AS aliasing hack, i.e. sign to itself with = pcount=3D0, and apply the mark on that signature. Equivalently, we could invent some new thing to go into the signatures = that has the semantics of "this is a confed entry marker".=20 --John= From Sandra.Murphy@sparta.com Wed Aug 1 20:24:52 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E92011E809C for ; Wed, 1 Aug 2012 20:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAcGROtMkw0n for ; Wed, 1 Aug 2012 20:24:48 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 671BB21F8BC2 for ; Wed, 1 Aug 2012 20:24:48 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q723Om7H032342 for ; Wed, 1 Aug 2012 22:24:48 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q723OlmX020842 for ; Wed, 1 Aug 2012 22:24:47 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0355.002; Wed, 1 Aug 2012 23:24:54 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: minutes from 27 Jul 2012 Thread-Index: Ac1wXlYHBaPhz7z/SM23fY+UYeJCAA== Date: Thu, 2 Aug 2012 03:24:53 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F368B4@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: multipart/mixed; boundary="_002_24B20D14B2CD29478C8D5D6E9CBB29F625F368B4Hermescolumbiaa_" MIME-Version: 1.0 Subject: [sidr] minutes from 27 Jul 2012 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 03:24:52 -0000 --_002_24B20D14B2CD29478C8D5D6E9CBB29F625F368B4Hermescolumbiaa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Attached find the raw notes from the interim meeting.=0A= =0A= Please report any errors or omissions to the list.=0A= =0A= --Sandy= --_002_24B20D14B2CD29478C8D5D6E9CBB29F625F368B4Hermescolumbiaa_ Content-Type: text/plain; name="2012-07-27-interim.minutesfromWes.txt" Content-Description: 2012-07-27-interim.minutesfromWes.txt Content-Disposition: attachment; filename="2012-07-27-interim.minutesfromWes.txt"; size=29125; creation-date="Thu, 02 Aug 2012 03:24:33 GMT"; modification-date="Thu, 02 Aug 2012 03:24:33 GMT" Content-Transfer-Encoding: base64 ICAgICAgICAgICAgICAgICAgIDIwMTItMDctMjcgU0lEUiBJbnRlcmltIE1lZXRpbmcNCiAgICAg ICAgICAgICAgICAgICA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCkRhdGU6IDIw MTItMDctMjcgRnJpDQoNCg0KVGFibGUgb2YgQ29udGVudHMNCj09PT09PT09PT09PT09PT09DQox IExpbmtzIHRvIHRoZXNlIG5vdGVzIGluIHZhcmlvdXMgZm9ybXM6DQoyIEludHJvZHVjdGlvbnMN CjMgRGVwbG95bWVudCBjb25zaWRlcmF0aW9ucyAtIFRpbWUgQnJ1aWpuemVlbHMNCiAgICAzLjEg UXVlc3Rpb25zDQogICAgMy4yIERpYWdyYW0gZnJvbSBjaGFsayBib2FyZCBkdXJpbmcgZGlzY3Vz c2lvbg0KNCBNZWFzdXJpbmcgUlBLSSBSZXBvc2l0b3JpZXMgLSBSYW5keSBCdXNoDQogICAgNC4x IFF1ZXN0aW9ucw0KNSBSUEtJIHByb3BhZ2F0aW9uIGVtdWxhdGlvbiBNZWFzdXJlbWVudCBhbiBl YXJseSByZXBvcnQNCiAgICA1LjEgUXVlc3Rpb25zDQo2IFJQS0kgUmVwb3NpdG9yeSBGZXRjaCBQ cm90b2NvbHMgLSBSb2IgQXVzdGluZQ0KICAgIDYuMSBRdWVzdGlvbnM/DQo3IERlcGxveW1lbnQg Q29uc2lkZXJhdGlvbnMgaW4gUlBLSSAtIFRpbSBCcnVpam56ZWVscw0KICAgIDcuMSBRdWVzdGlv bnM/DQogICAgNy4yIENvbmNsdXNpb25zDQogICAgNy4zIERpc2N1c3Npb25zDQogICAgNy40IE1v cmUgY29uY2x1c2lvbnMNCjggRG9jdW1lbnQgYWR2YW5jZW1lbnQNCjkgQkdQU0VDIHByb3RvY29s IGRvY3VtZW50DQoxMCBNdWx0aVBhdGggRHJhZnRzDQoxMSBTdGFibGUgU2lnbmF0dXJlDQoxMiBS b3V0ZSBMZWFrcyBhbmQgQnJpYW4gRGlja2Vyc29uDQoxMyBSZXBvc2l0b3J5IHN5c3RlbSByZXF1 aXJlbWVudHMNCg0KDQoxIExpbmtzIHRvIHRoZXNlIG5vdGVzIGluIHZhcmlvdXMgZm9ybXM6IA0K PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KICAgIG9yZyBtb2Rl OiAgIFtodHRwOi8vaGFyZGFrZXJzLm5ldC90ZW1wLzIwMTItMDctMjctaW50ZXJpbS5vcmddICAg DQogICAgdHh0OiAgICAgICAgW2h0dHA6Ly9oYXJkYWtlcnMubmV0L3RlbXAvMjAxMi0wNy0yNy1p bnRlcmltLnR4dF0gICANCiAgICBodG1sOiAgICAgICBbaHR0cDovL2hhcmRha2Vycy5uZXQvdGVt cC8yMDEyLTA3LTI3LWludGVyaW0uaHRtbF0gIA0KDQoyIEludHJvZHVjdGlvbnMgDQo9PT09PT09 PT09PT09PT09DQogIC0gbG9jYWwgcmVzb3VyY2VzIGFuZCBhZ2VuZGEgb3ZlcnZpZXcNCg0KMyBE ZXBsb3ltZW50IGNvbnNpZGVyYXRpb25zIC0gVGltZSBCcnVpam56ZWVscyANCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQogIC0gcnN5bmMgaXMgdXNlZnVs DQogIC0gY3VycmVudCByZXBvc2l0b3J5IGlzbid0IHJvYnVzdCBlbm91Z2ggeWV0DQogIC0gcmVw b3NpdG9yaWVzIGFyZSBmbGF0LCBubyBwcm94eWluZywgbm8gQ0ROcyB5ZXQNCiAgLSBTdGV2ZSBL ZW50IGFza2VkIGEgcXVlc3Rpb24gYWJvdXQgY2hhbmdpbmcgd2hpbGUgc3luY2luZywgYW5zd2Vy DQogICAgdGFibGVkIGZvciBsYXRlci4NCiAgLSByc3luYyBsaWJyYXJpZXMgZG9uJ3QgcmVhbGx5 IGV4aXN0LiAgTmVlZCBtb3JlIGRvY3VtZW50YXRpb24gb3INCiAgICBzdGFuZGFyZGl6YXRpb24g b2YgdGhlIHJzeW5jLg0KICAtIEluIHBhcnRpY3VsYXIsIHlvdSBlbmQgdXAgbmVlZGluZyB0byBy ZS1hdXRoIHRoZSBlbnRpcmUgY3J5cHRvIHNldA0KICAgIHdoaWNoIGlzIGluZWZmaWNpZW50IHdo ZW4geW91IHJlYWxseSBqdXN0IG5lZWQgYSBsaXN0IG9mIHRoaW5ncw0KICAgIHRoYXQgaGF2ZSBj aGFuZ2VkIHRvIG9ubHkgcmUtdmFsaWRhdGUgd2hhdCBpcyBuZWVkZWQuDQogIC0gbWVhc3VyaW5n IHJlc3VsdHMgaW4gdGhlIHdpbGQgdXNpbmcgcnBraS12YWxpZGF0b3INCiAgICAtIG9uIGF2ZXJh Z2UgMTUgZGlmZmVyZW50IGluc3RhbmNlcw0KICAgIC0gcHJlY29uZmlndXJlZCB3aXRoIHRydXN0 IGFuY2hvcnMgYW5kIHByZWZldGNoaW5nIGVuYWJsZWQNCiAgICAtIFJvYiBhbmQgUmFuZHkgZGlz YWdyZWUgYWJvdXQgd2hldGhlciBwcmVmZXRjaGluZyBpcyBhIHdpc2UNCiAgICAgIGNob2ljZSAo U3RldmUgSy4gYXNrZWQgd2hhdCBwcmVmZXRjaGluZyBpcywgYW5kIGl0IHdhcyB0YWJsZWQNCiAg ICAgIHVudGlsIGEgbGF0ZXIgc2xpZGUpDQogICAgLSByZXRyaWV2YWwgZmFpbHVyZXMgbm90ZWQg b3ZlciBJUHY2IChzbGlkZSAxMCkNCiAgICAgIC0gU2FuZHk6IHdoeSBpcyBhcG5pYyBJUHY2IG1h cmtlZCBhcyBOL0ENCiAgICAgIC0gSW5zZXJ0IGpva2VzIGFib3V0IHY2IGRlcGxveW1lbnQgaGVy ZQ0KICAgICAgLSBSYW5keSBwcm94aWVzIGZvciBzb21lb25lIHRoYXQgcXVlc3Rpb25zIHdoZXRo ZXIgdGhlIHY2IGlzc3VlDQogICAgICAgIGlzbid0IG9uIHRoZSBjbGllbnQgc2lkZSBhbmQgdGhl IGNsaWVudCBtYXkgbm90IGJlIGFibGUgdG8gcmVhY2gNCiAgICAgICAgYW55IG9mIHRoZSByZXBv cw0KICAgIC0gUHJlZmV0Y2hpbmc6IChzbGlkZSAxMSkNCiAgICAgIC0gdGFrZXMgdGhlIFVSSSwg Y2hvcHMgb2ZmIHRoZSBlbmQgYW5kIHRoZW4gcHJlZmV0Y2hlcyBhIGxhcmdlcg0KICAgICAgICBu dW1iZXIgb2YgdGhpbmdzLg0KICAgICAgLSBUaW0gZ2l2ZXMgYSBiaXQgb2YgZGVzY3JpcHRpb24g b2YgaGlzIGFyY2hpdGVjdHVyZQ0KICAgICAgICAtIFR3byBDQXMsIG9uZSBpcyBmb3IgdGhlIG9m ZmxpbmUgVEFzIGFuZCB0aGUgb3RoZXIgaXMgZm9yDQogICAgICAgICAgb25saW5lIHdvcmsuDQog ICAgICAgIC0gcHJvZHVjdGlvbiBDQSBhbmQgbWVtYmVyIENBIGFyZSBhdCB0aGUgc2FtZSBsZXZl bCBpbiB0aGUgcmVwbw0KICAgICAgICAtIFNvIHRoZSBjb2RlIGZpZ3VyZXMgb3V0IHdoYXQgdGhl IGJhc2UgZGlyZWN0b3J5IGlzIG9mIHRoZQ0KICAgICAgICAgIHByb2R1Y3Rpb24gQ0EgaXMgc28g eW91IGNhbiBnZXQgdGhlIHByb2R1Y3Rpb24gQ0EgYW5kIG1lbWJlciBDQXMuDQogICAgICAgIC0g Um9iIEEgbm90ZXMgdGhhdCBpZiAoYW5kIG9ubHkgaWYpIHlvdSB1bmRlcnN0YW5kIHRoYXQgdGhl DQogICAgICAgICAgcmVwbyB5b3UncmUgdXNpbmcgaXMgc3RydWN0dXJlZCB0aGlzIHdheSwgaXQg bWF5IG1ha2Ugc2Vuc2UuDQogICAgICAgIC0gVGh1cyBpdCBsZXRzIHlvdSBoYXZlIGEgbG9jYWwg Y29weSBvZiBldmVyeXRoaW5nIGZpcnN0LCBhbmQNCiAgICAgICAgICB0aGVuIHNwZWVkcyB1cCB0 aGUgdmVyaWZpY2F0aW9uIHByb2Nlc3MuDQogICAgICAgIC0gUm9iOiBvbmUgdGhpbmcgdG8gbm90 ZSBpcyB0aGF0IHRoZSBjdXJyZW50IGhhY2sgdGltIGlzDQogICAgICAgICAgZGVzY3JpYmluZyBv bmx5IHdvcmtzIHdpdGggYW4gUklSIHdpdGggeW91ciBvd24gVEEuICBJdCBvbmx5DQogICAgICAg ICAgd29ya3Mgd2hlbiB5b3UncmUgdGhlIHJvb3QuICBJZiBJQU5BIHdhcyB0aGUgVEEsIHRoZW4g eW91J2QNCiAgICAgICAgICBzdGlsbCBuZWVkIHRvIGRvIHRoZSB0b25zIG9mIGZldGNoaW5nLg0K ICAgICAgICAtIFJhbmR5OiB0aGUgcXVlc3Rpb24gaXM6IGhvdyBkb2VzIHRoaXMgZWZmZWN0IG1l YXN1cmVtZW50DQogICAgICAgICAgcmVzdWx0cz8/Pw0KICAgICAgICAtIFRpbTogd2UgZG8gYSBw cmVmZXRjaCBvZiBhIGtub3duIHJzeW5jLCBhbmQgd2UgdGhpbmsgdGhhdA0KICAgICAgICAgIHRo ZSB0aW1lIHdvdWxkIGJlIHNpbWlsYXIgKmlmKiB0aGUgcmVwb3NpdG9yaWVzIGFyZQ0KICAgICAg ICAgIGhpZXJhcmNoaWNhbCBpbiB0aGUgZnV0dXJlLg0KICAgICAgICAtIFJvYjogdGhlIGltcG9y dGFudCBwb2ludCBpcyB0aGF0IG91ciBtZWFzdXJlbWVudHMgYXJlIGluDQogICAgICAgICAgZGlz YWdyZWVtZW50IGJlY2F1c2UgaGUncyBwcmVmZXRjaGluZyBhbmQgW1JvYidzIHRvb2xdIGlzDQog ICAgICAgICAgbm90Lg0KICAgICAgICAtIFRpbTogUm9iIG5lZWRzIHRvIGRvIDEwMDArIGZldGNo ZXMgdG8gY29tcGxldGUgdmFsaWRhdGlvbg0KICAgICAgICAtIFJvYjogYW5kIGlmIFRpbSBuZWVk ZWQgdG8gdXNlIElBTkEgYXMgdGhlIFRBIHRoZSBwcmVmZXRjaGluZw0KICAgICAgICAgIHdpbGwg bm8gbG9uZ2VyIHdvcmsuICBJdCBvbmx5IHdvcmtzIGZvciBUQXMuICBBUG5pYyBhbmQNCiAgICAg ICAgICBSaXBlTkNDIGFyZSB0aGUgYmlnIG9uZXMuDQogICAgICAgIC0gVGltOiBhZ3JlZXMgaXQn cyBhIGhhY2ssIGJ1dCB5b3UgY291bGQgc3RpbGwgcHJlZmV0Y2ggdGhlDQogICAgICAgICAgYmln IG9uZXMgKFJvYjogaWYgeW91IGhhdmUgbWFnaWMga25vd2xlZGdlIG9mIHRob3NlOyBUaW06DQog ICAgICAgICAgeWVzLCBidXQgdGhhdCdzIG9rKS4NCiAgICAgICAgLSBTdGV2ZTogcnN5bmMgb25s eSBmZXRjaGVzIHRoaW5ncyB0aGF0IGhhdmUgY2hhbmdlZA0KICAgICAgICAtIFdhcnJlbjogd2hh dCBtYWdpYyBpcyBuZWVkZWQ/DQogICAgICAgIC0gUm9iOiAidGhlIGZvbGxvd2luZyByZXBvc2l0 b3JpZXMgYXJlIGJhZGx5IG9yZ2FuaXplZCwgcGxlYXNlDQogICAgICAgICAgdXNlIHRoaXMgbWFn aWMgVVJJIGluc3RlYWQgdG8gaGVscCIuDQogICAgICAgIC0gV2VzOiBpdCdzIGFuIGltcGxlbWVu dGF0aW9uIGhhY2ssIGFuZCBoZSBjb3VsZCBkbyB0aGF0IGZvcg0KICAgICAgICAgIGhpcyBpbXBs ZW1lbnRhdGlvbg0KICAgICAgICAtIFJhbmR5OiB5ZXMsIGJ1dCBpdCBzdGlsbCBhZmZlY3RzIGRl cGxveW1lbnQgbWVhc3VyZW1lbnRzDQogICAgICAtIGJpZyBkaWZmZXJlbmNlcyBiZXR3ZWVuIGNs aWVudHMgYW5kIGJldHdlZW4gcnVucyByZXN1bHRzIGZyb20NCiAgICAgICAgZGlmZmVyZW50IG1h Y2hpbmUgdHlwZXMgcnVubmluZyB0aGUgdG9vbA0KICAgICAgLSBzbGlkZSAxMisgc2hvd3MgdGlt aW5nIHNlZW4gaW4gZ3JhcGhzDQogICAgICAgIC0gbW9zdCBncmFwaHMgaGF2ZSBhIGhpZ2gtc2hv cnQtdGltZSBzcGlrZSBmb2xsb3dlZCBieSBhIGxvbmcNCiAgICAgICAgICB0YWlsIG91dCBpbiB0 aGUgMTAwKyBzZWNvbmQgcmFuZ2UNCiAgICAgICAgLSB0aGUgcHJlLWZldGNoIGhhY2sgaGVscHMg aXQgdmFsaWRhdGUgd2l0aGluIGEgcmVhc29uYWJsZQ0KICAgICAgICAgIGFtb3VudCBvZiB0aW1l DQogICAgICAtIHByb2JsZW1zIHNlZW4gd2l0aCBhIENSTCBmb3IgdGhlIG5ldyBNRlQgd2Fzbid0 IHB1Ymxpc2hlZA0KICAgICAgICB1bnRpbCBsYXRlci4NCiAgICAtIENvbmNsdXNpb25zDQogICAg ICAtIGJpZyBkaWZmZXJlbmNlcyBiZXR3ZWVuIGNsaWVudHMgKENQVXMsIGV0YykNCiAgICAgIC0g cHJlZmV0Y2hpbmcgaXMgZG9uZSBvdXRzaWRlIG9mIHRoZSBzdGFuZGFyZA0KICAgIC0gaGFyZHdh cmUgZGVzY3JpcHRpb24NCiAgICAtIHJzeW5jZCBwZXJmb3JtYW5jZSB0ZXN0aW5nDQogICAgICAt IGZ1bGwgcmVjdXJzaXZlIGZldGNoIG9mIGp1c3QgZGF0YSAobm8gdmFsaWRhdGlvbikNCiAgICAg IC0gY2xpZW50IGhhZCBhbGwgdGhlIGRhdGEsIG9uIGEgbG9jYWwgbmV0d29yazoganVzdCByc3lu YyBvdmVyaGVhZA0KICAgICAgLSBUaGVyZSBpcyBhIGJvdW5kYXJ5IGZvciBjbGllbnRzL3NlYyB0 aGF0IGNhbiBiZSBoYW5kbGVkIHRoYXQNCiAgICAgICAgaXMgY29uc3RyYWluZWQgYnkgdGhlIENQ VS4NCiAgICAgIC0gVGhlcmUgaXMgYSBib3VuZGFyeSBmb3IgdGhlIG51bWJlciBvZiBjb25jdXJy ZW50IGNsaWVudHMgdGhhdA0KICAgICAgICBpcyBjb25zdHJhaW5lZCBieSB0aGUgbWVtb3J5IGF2 YWlsYWJsZQ0KICAgICAgLSBzbWFsbGVzdCB0ZXN0IGlzIDcwayBvYmplY3RzLCBhbmQgdGhlIHJl YWwgd29ybGQgaXNuJ3QgbmVhcg0KICAgICAgICB0aGF0IHlldC4gIHlldC4gIEluIHRoZSBsb25n IHRlcm0gd2hlbiB3ZSBoYXZlIDEwMGstNDAwayBST0FzDQogICAgICAgIHRoZW4gdGhlc2UgbnVt YmVycyB3aWxsIGJlY29tZSBpbXBvcnRhbnQuDQogICAgICAtIFN0ZXZlIEs6IHNlcnZlciB3YXMg bWFjIG1pbmksIGhvdyBtdWNoIG1lbW9yeT8NCiAgICAgICAgLSBUaW06IDJHYg0KICAgICAgICAt IFN0ZXZlOiB3ZSBzaG91bGQgdHJ5IHRoaXMgYWdhaW4gd2l0aCBhIHJlYWwgc2VydmVyDQogICAg ICAgIC0gVGltOiBJIHRoaW5rIHRoZSBiaWdnZXIgaXNzdWUgaXMgdGhlIENQVSBzaXplLCBhbmQg dGhlcmUgYXJlDQogICAgICAgICAgbXVjaCBiaWdnZXIgQ1BVIHNpemVzIG91dCB0aGVyZSBvZiBj b3Vyc2UNCiAgICAgIC0gUm9iOiBjcmFuayBkb3duIHRoZSBudW1iZXIgb2Ygc2ltdWx0YW5lb3Vz IGNvbm5lY3Rpb25zIG1heSBoZWxwDQogICAgICAtIFN0ZXZlIEs6IHdlIG9yaWdpbmFsbHkgdGhv dWdodCBvZiB1c2luZyBUTFMgd2l0aCBhIGNlcnRpZmljYXRlDQogICAgICAgIHRoYXQgd2FzIG9u bHkgYXZhaWxhYmxlIHZpYSBSUEtJIHNvIHRoYXQgeW91IGNvdWxkIGxpbWl0IHdobw0KICAgICAg ICBjb3VsZCBhY3R1YWxseSBjb25uZWN0DQogICAgICAtIFRpbTogTXkgYm90dG9tIGxpbmUgaXMg dGhhdCBJIHRoaW5rIHRoZSBzeXN0ZW0gd291bGQgYmUgYmV0dGVyDQogICAgICAgIGlmIGl0IGNv dWxkIHRha2UgbXVjaCBoaWdoZXIgbG9hZHMuDQogICAgLSBzbGlkZSAyNjogbGF0ZW5jeSBoYXMg YSBodWdlIGltcGFjdA0KICAgICAgLSBSYW5keTogc28gd2hhdCB5b3UndmUgdHJhZGVkIGlzIHRo ZSBDUFUvbWVtb3J5IGNvc3QgZm9yDQogICAgICAgIG5ldHdvcmsgY29zdD8NCiAgICAgIC0gVGlt OiBZZXMNCiAgICAgIC0gd2UncmUgcHVzaGluZyB3b3JrIGZyb20gdGhlIHJlcG8gc2VydmVyIHRv IHRoZSBjbGllbnRzIGJlY2F1c2UNCiAgICAgICAgSSB0aGluayBpdCB3aWxsIHNjYWxlIGJldHRl cg0KICAgIC0gc2xpZGUgMjc6DQogICAgICAtIEl0J3MgZmFpcmx5IGVhc3kgZm9yIGEgbGFyZ2Ug cmVwb3NpdG9yeSB0byBnZXQgRE9TIGl0IHdpdGgNCiAgICAgICAgcnN5bmMuICBodHRwIHJpc2sg aXMgbG93ZXIuICAoYnV0IHRoZSBpbXBhY3QgaXMgdGhlIHNhbWUpDQogICAgICAtIFRoZXJlIGFy ZSBhIGxvdCBtb3JlIGF2YWlsYWJsZSBtaXRpZ2F0aW9ucyBvdmVyIGh0dHAsIGhvd2V2ZXINCiAg ICAgICAgYmVjYXVzZSB0aGUgaW5kdXN0cnkgYWxyZWFkeSBoYXMgc29tZSBhdmFpbGFibGUuDQog ICAgICAtIHBvc3NpYmxlIGZpeGVzIHdpdGggcnN5bmMgYXJlIGxpbWl0ZWQNCiAgICAtIHNsaWRl IDI4OiByc3luYyB2cyBodHRwDQogICAgICAtIG1ham9yIHJzeW5jIGJlbmVmaXQ6IGhhcyBzdXBw b3J0IGZvciBidWlsdCBpbiBkZWx0YQ0KICAgICAgLSBtYWpvciBodHRwIGJlbmVmaXQ6IHdpZGVs eSBkZXBsb3llZCBhbmQgbWFueSBpbXBsZW1lbnRhdGlvbnMNCiAgICAgIC0gbmVnYXRpdmUgcnN5 bmNzOiBidWlsZGluZyBkZWx0YXMgY2FuIGJlIGV4cGVuc2l2ZSBvbiB0aGUgc2VydmVyDQogICAg ICAgIC0gYnV5aW5nIG1vcmUgQ1BVcyBoZWxwIGJ1dCBJIGRvbid0IGtub3cgaWYgaXQncyBhIGJh dHRsZSB5b3UNCiAgICAgICAgICBjYW4gd2luDQogICAgICAtIG5lZ2F0aXZlIGh0dHA6IHdpdGhv dXQgZGVsdGFzIGl0J2xsIGJlIHNsb3cNCiAgICAtIG5leHQgc3RlcHM6DQogICAgICAtIG1heSBu ZWVkIHRvIHR1cm4gb2ZmIHJlY3Vyc2l2ZSBmZXRjaGVzIHdoZW4gcmVwb3NpdG9yeSBnZXRzIGxh cmdlDQogICAgICAtIGRlbHRhczogbmVlZCB0byBtYWtlIGh0dHAgd29yaywgb3IgcnN5bmMgd2l0 aCByZWN1cnNpb24gZGlzYWJsZWQNCiAgICAgIC0gdXBkYXRlcyB0byBSUCBpbiBtaW51dGVzIG5v dCBob3Vycw0KDQozLjEgUXVlc3Rpb25zIA0KLS0tLS0tLS0tLS0tLS0NCiAgICAtIFN0ZXZlIEs6 IGlmIHlvdSB1c2UgaHR0cCB3aXRoIG1hbmlmZXN0LCB0aGVuIHlvdSdsbCBuZWVkIHRvIHJlZG8g dGhlDQogICAgICBtYW5pZmVzdCBSRkMgYmVjYXVzZSB0aGUgUkZDIHJlYWxseSBpcyBkZXNpZ25l ZCBhcm91bmQgcnN5bmMgbm90DQogICAgICBodHRwIGFuZCB5b3UnZCB3YW50IHRvIHJldXNlIGl0 Lg0KICAgICAgLSBUcnVlLCBidXQgd2Ugc2hvdWxkbid0IGRpdmUgaW50byB0aGF0IG5vdw0KICAg IC0gU2FuZHkgTTogb24gc2xpZGUgMjcsIHlvdSBkb24ndCBpbmNsdWRlIGJhbmR3aWR0aCByZXF1 aXJlZA0KICAgICAgLSBldmVyeSByZWx5aW5nIHBhcnR5IG5lZWRzIHRvIHB1bGwgZG93biBldmVy eXRoaW5nDQogICAgICAtIHRoZSBpbXBhY3Qgb24gdGhlbSB3aWxsIGJlIHRoZSBzYW1lLCBzaW5j ZSBldmVyeSBSUCBuZWVkcyB0bw0KICAgICAgICBwdWxsIGRvd24gZXZlcnl0aGluZyBubyBtYXR0 ZXIgd2hhdCB0aGVpciBzaXplIGlzDQogICAgLSBSb2IgQTogY3VycmVudCB2YWxpZGF0aW9uIGZv ciBtZSBpcyBzbWFsbCAoNTAgc2Vjb25kcy1pc2gpLCBidXQNCiAgICAgIHRoZSB1bml2ZXJzZSBp cyBzbWFsbA0KDQozLjIgRGlhZ3JhbSBmcm9tIGNoYWxrIGJvYXJkIGR1cmluZyBkaXNjdXNzaW9u IA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICAg IFtodHRwOi8vd3d3LmhhcmRha2Vycy5uZXQvdGVtcC8xMjA3MDA0Ni5zbS5qcGddDQoNCjQgTWVh c3VyaW5nIFJQS0kgUmVwb3NpdG9yaWVzIC0gUmFuZHkgQnVzaCANCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiAgLSBmbGF0IGZldGNoZXMgYXJlIHRoZSBzYW1l IGZhbWlseSBhbmQgd2lsbCBhY3QgYWJvdXQgdGhlIHNhbWUNCiAgLSB3aGVyZSBhcmUgd2UgdG9k YXk/DQogIC0gdGhpcyB0YWxrIGlzIGFib3V0IHRoZSBwcm9ibGVtcywgbm90IHRoZSB0aGluZ3Mg Z29pbmcgd2VsbA0KICAtIEkgY2FyZSBhIGxvdCBhYm91dCB0aGUgcGVyZm9ybWFuY2UgYW5kIGF2 YWlsYWJpbGl0eSBhcyBhbiBSUA0KICAtIFRoZSBtYWpvcml0eSBvZiB3aGF0IHdlIGdldCBub3cg aXMgZmFpbHVyZXMNCiAgLSBVc2luZyBSb2IncyBSUCBzb2Z0d2FyZQ0KICAtIDk6IHN5bmMgdGlt ZSBvbiBSSVIgKGxhY25pYykgdmFyaWVzIGEgbG90LCBub3Qgc3VyZSB3aHkNCiAgICAtIGJsYWNr IGxpbmUgaXMgb2JqZWN0DQogIC0gYXBuaWM6IG5vIG1vbml0b3JpbmcsIG5vIE5PQywgLi4uDQog IC0gcmlwZSBkaWQgZmFpcmx5IHdlbGwsIGJ1dCBoYWQgc29tZSBzZXJpb3VzIHByb2JsZW1zIHdp dGggcnN5bmMgYXQNCiAgICBwb2ludHMNCiAgICAtIGNhdXNlOiBORlMNCiAgLSBJc3N1ZXMvQ29u Y2x1c2lvbnM6DQogICAgLSBjdXJyZW50IHB1Ymxpc2hlcnMgKFJJUnMpIGFyZW4ndCBnb29kDQog ICAgICBvcGVyYXRvcnMNCiAgICAgIC0gZG9uJ3Qgd29yayB3ZWVrZW5kcw0KICAgICAgLSBkb24n dCBkbyBtb25pdG9yaW5nDQogICAgICAtIC4uLg0KICAgIC0gbmVlZCByZXBvc2l0b3J5IHN0cnVj dHVyZXMgdG8gYmUgZml4ZWQgKGFkZCBoaWVyYXJjaHkpDQoNCjQuMSBRdWVzdGlvbnMgDQotLS0t LS0tLS0tLS0tLQ0KICAgIC0gUnVzcyBIOiBzbGlkZSAyMCwgd2h5IGRvZXMgaXQgbG9vayBsaWtl IHRoYXQ/DQogICAgICAtIFJhbmR5OiB0aGUgbmljZSBvbmVzIGF0IHRoZSBib3R0b20gYXJlIHRo ZSBvbmVzIHRoYXQgaGF2ZSBhDQogICAgICAgIGZsYXQgc3RydWN0dXJlDQogICAgICAtIFJvYjog dGhlc2UgdGVzdHMgYXJlIGJlaW5nIGRvbmUgb24gW3dlbGwgY29ubmVjdGVkXSBtYWNoaW5lcw0K ICAgICAgICBpbiBzZWF0dGxlLiAgTGF0ZW5jeSBhcmVuJ3QgdGhlIHByb2JsZW0uICBTb21lIG9m IHRoZSBlZmZlY3RzDQogICAgICAgIG9uIHRoZSBoaWdoIGVuZCBhcmUgY29ubmVjdGl2aXR5IHBy b2JsZW1zIChsYWNuaWMgb3IgYWZyaW5pYyksDQogICAgICAgIGJ1dCBtb3N0IGFyZW4ndC4NCiAg ICAtIFJvYjogdGhlcmUgYXJlIHRocmVlIHJlYXNvbnMgd2h5IHJlcG8gc3RydWN0dXJlcyBhcmVu J3QgZml4ZWQ6DQogICAgICAxLiBoYXZlbid0IGZsaXBwZWQgdGhlIHN3aXRjaCB5ZXQNCiAgICAg IDIuIGNvbnNjaW91cyAocG9saXRpY2FsKSByZWFzb25zIG5vdCB0byBkbw0KICAgICAgMy4gW2Vk aXRvciBtaXNzZWQgaXRdDQogICAgLSBSYW5keTogd2UgYXJlIGhhcHB5IHRoYXQgdGhlIFJJUnMg KmhhdmUqIGRlcGxveWVkDQogICAgLSBSdWVkaWdlcjogRG8gd2UgaGF2ZSBzdGF0aXN0aWNzIGZv ciBhY3Rpdml0eSBmb3IgY3VycmVudCBzZXJ2ZXJzDQogICAgICBhbmQgdXNhZ2U/DQogICAgICAt IFJhbmR5IGFkZHM6IEkgd2FudCB0byBrbm93IHRoZSBjb25kaXRpb24gb2YgbWFueSBzZXJ2ZXJz LiAgV2UNCiAgICAgICAgZG9uJ3QgaGF2ZSBhIHdheSBvZiBkZXRlcm1pbmluZyBpZiBhIHNlcnZp Y2UgaXMgdXAgYW5kIGl0J3MNCiAgICAgICAgc3RhdHVzLiAgVGhlcmUgaXMgbm8gc2ltcGxlIHRl c3QgZm9yIGlzIHRoaXMgc2VydmljZSB1cC4NCiAgICAtIFNhbmR5OiBoYXMgYW55b25lIGV2ZXIg bG9va2VkIGF0IHByb2JsZW1zIHdpdGggdGhlIElSUiBzZXJ2ZXJzPw0KICAgICAgLSAobm8taXNo KQ0KDQo1IFJQS0kgcHJvcGFnYXRpb24gZW11bGF0aW9uIE1lYXN1cmVtZW50IGFuIGVhcmx5IHJl cG9ydCANCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KICAtIHRoZXJlIGFyZSBzZXJpb3VzIGlzc3VlcyB3aXRoIHNvbWUgb2YgdGhlIG1l YXN1cmVtZW50cywgYnV0IHdlJ2xsDQogICAgYmUgbWFraW5nIG1vcmUtYmV0dGVyIHJlc3VsdHMg c29vbg0KICAtIFtzbGlkZXMgYmVpbmcgcmVhZCB3b3JkLWZvci13b3JkLCBub3QgZW50aXJlbHkg cmVpdGVyYXRlZCBoZXJlXQ0KICAtIFNhbmR5OiBzbGlkZSA4OiB3aHkgYXJlIHRoZXJlIHR3byBy b3dzIGxhYmVsZWQgdGllci0zPw0KICAgIC0gUmFuZHk6IGJlY2F1c2UgeW91IGRvbid0IGhhdmUg YSB3aWRlIGVub3VnaCBwcm9qZWN0b3IgW0lFLCBsaW5lDQogICAgICAzIGlzIHdyYXBwZWRdDQog IC0gVGVzdCBiZWQgdXNlZCBiYXNlZCBvbiBTdGFyYmVkOg0KICAgIC0gYSBjbHVzdGVyIGluIGph cGFuIHdpdGggMTAwMCBLVk1zDQogICAgLSBlYWNoIHdpdGggMTIgQ1BVcyB3aXRoIDhHYi4NCiAg ICAtIHdlIHJ1biAxNSB2aXJ0dWFsIG1hY2hpbmVzIG9uIGVhY2ggb25lLCB1c2luZyA1MCBtYWNo aW5lcyBvciBzby4NCiAgLSAxNzogd2hlbiB3ZSB3YW50IHRvIGluZHVjZSBkZWxheSwgd2UganVz dCBhZGQgYSByb3V0ZXIgaW4gdGhlIG1pZGRsZQ0KICAtIHdhbnRlZCB0byBjcmVhdGUgdGhlIGN1 cnJlbnQgcm91dGluZyBvdXRwdXQgYW5kIHRoZW4gY3JlYXRlIGENCiAgICBjZXJ0aWZpY2F0ZSBz dHJ1Y3R1cmUgd2l0aCBpdA0KICAgIC0gbXVsdGlwbGUgcHJlZml4ZXMgYmVsb25nIHRvIHRoZSBz YW1lIGVudGl0eS4gIFlvdSBjYW4ndCBrbm93DQogICAgICB0aGF0Lg0KICAgIC0gbm8gd2F5IHRv IGFnZ3JlZ2F0ZSB0aGUgY29tbW9uIGFyZWFzDQogICAgLSB0aHVzIG5vIHdheSB0byBnbyBib3R0 b20tdXANCiAgICAtIFJhbmR5IHByb21pc2VzIGEgZGlubmVyIGZvciBhbnlvbmUgdGhhdCBjYW4g ZG8gaXQuDQogIC0gMjE6IGluaXRpYWxseSBhZnRlciBjcmVhdGluZyB0aGUgYXV0b25ldGtpdCBk aWFncmFtLCB0aGUgaW5pdGlhbA0KICAgIG1hY2hpbmUgc3RhcnRzIGl0IGFsbCB0byBjcmVhdGUg YWxsIHRoZSBjZXJ0cyBhbmQgQ0FzIGJlZm9yZQ0KICAgIHB1c2hpbmcgaXQgdG8gdGhlIGZ1bGwg c2ltdWxhdG9yLg0KICAgIC0gU3RldmUgSzogd2hlbiB3ZSB0cmllZCB0byBkbyBtZWFzdXJlbWVu dHMgd2UgZGlkIGEgdG9wIGRvd24NCiAgICAgIGFwcHJvYWNoLg0KICAtIDIxOiBST0FzIGdldCBj cmVhdGVkIGFuZCBkaXN0cmlidXRlZCBhcyBpdCBydW5zDQogICAgLSBBbnkgQ1JMcz8NCiAgICAg IC0gTm8NCiAgICAtIFdlIGRvbid0IGNyZWF0ZSBDQXMsIHdlIGp1c3QgY3JlYXRlIG1vcmUgUk9B cyBmb3IgdGhlIHNhbWUNCiAgICAgIHByZWZpeGVzIHdpdGggbmV3IEFTIG51bWJlcnMuDQogIC0g MjI6IHRoZSBibGFjayBkb3RzIG9uIHRoZSByaWdodCBoYW5kIHJ1biBhcmUgaW5kdWNpbmcgZGVs YXksIHNvIHdlDQogICAgY2FuIG1lYXN1cmUgaG93IGRlbGF5IGFmZmVjdHMNCiAgLSBUaGUgZ3Jh cGhzIHlvdSdyZSBhYm91dCB0byBzZWUgYXJlIGNvbXBsZXRlIGxpZXMuDQogICAgLSB0aGUgUk9B IHB1Ymxpc2ggdGltZSBpcyBldmVyeSAxMCBtaW51dGVzLCBzbyB0aGF0IGV2ZW4gdGhvdWdoDQog ICAgICB0aGUgZ2F0aGVyJ3MgYXJlIHR3aWNlIGFuIGhvdXIsIHRoZSBST0FzIGFyZSBvbmx5IDEw IG1pbnV0ZXMgb2xkDQogICAgICB0aGF0IGdldCBwdWxsZWQNCiAgLSBkZWxheSB0byB0aGUgdG9w IGxldmVsIGdhdGhlcmVycyBkb2VzIG5vdCBsb29rIHNpZ25pZmljYW50DQogIC0gMjU6IGRvbid0 IGtub3cgd2h5IHRoZSBibHVlIGxpbmUgaXMgdG8gdGhlIHJpZ2h0IG9mIHRoZSBibGFjaywgaXQN CiAgICBzaG91bGRuJ3QgYmUuDQogIC0gMjY6IGxvb2tzIGFib3V0IGxpa2Ugd2hhdCB3ZSdkIGV4 cGVjdDogMTgwMCwgb3IgaGFsZiBhbiBob3VyLg0KICAtIFNhbmR5Og0KICAgIC0gaG93IHdhcyBm bGF0IHZzIGhpZXJhcmNoaWFsIGRvbmU/DQogICAgLSBSb2I7IGJvdGggdHlwZXMgY2FuIGJlIGdl bmVyYXRlZCBiYXNlZCBvbiBhIGZsYWcNCiAgLSAyODogYmx1ZSBsaW5lIHRvIHRoZSByaWdodCBh Z2Fpbg0KICAgIC0gY291bGQgYmUgYW4gaW50ZXItcm91dGVyIGRlbGF5IGluIERhbGxhcyB0aGF0 IHdlIGRpZG4ndCB0aGluaw0KICAgICAgd291bGQgbWF0dGVyLCBidXQgbWF5YmUgaXQgZG9lcw0K DQo1LjEgUXVlc3Rpb25zIA0KLS0tLS0tLS0tLS0tLS0NCiAgICAtIFNhbmR5OiB3aGF0IGFyZSB5 b3VyIGNvbmNsdXNpb25zPw0KICAgICAgLSBSYW5keTogd2UgbXVzdCBkbyBoaWVyYXJjaHksIGFu ZCBoYW1tZXIgb24gdGhlIFJJUnMgdG8gZG8NCiAgICAgICAgdGhpbmdzIHJpZ2h0Lg0KICAgICAg LSBiaXR0b3JyZW50IHdpbGwgbGlrZWx5IGJlIGhlbHBmdWwuDQogICAgICAtIFJvYiBBOiB0aGVy ZSBhcmUgdG9vIG1hbnkgcnN5bmNzIHRvIG1hbnkgc21hbGwgbGl0dGxlDQogICAgICAgIGRpcmVj dG9yaWVzLiAgMTBrIGxpdHRsZSBmaWxlcyBiZWluZyBwdXNoZWQgb3ZlciBhbnl0aGluZyBpcyBh DQogICAgICAgIHByb2JsZW0uDQogICAgICAtIFJhbmR5OiB0aGUgcmVhbCBwcm9ibGVtIGlzIHRo YXQgd2UgaGF2ZSA1MGsgQ0FzIFtldmVudHVhbGx5XQ0KICAgICAgLSBJcyB0aGVyZSBhIHJhZGlj YWxseSBkaWZmZXJlbnQgcHJvdG9jb2w/DQogICAgICAtIGRpc2N1c3Npb24gYWJvdXQgd2hldGhl ciBpdCBzaG91bGQgYmUgYSBwcm90b2NvbCBjb3ZlcmVkIGJ5IGFuIFJGQw0KICAgICAgLSBUaGVy ZSBpcyBvbmx5IG9uZSBpbXBsZW1lbnRhdGlvbiBvZiByc3luYywgdGhlcmUgYXJlIGF0IGxlYXN0 DQogICAgICAgIGEgZmV3IG9mIGJpdHRvcnJlbnQuDQogICAgICAtIFJhbmR5OiB3ZSBjYW4gd3Jp dGUgc3BlY3MsIHdlIGNhbiB3cml0ZSBjb2RlIGJ1dCB3ZSBoYXZlIGENCiAgICAgICAgYXJjaGl0 ZWN0dXJhbCBwcm9ibGVtLg0KICAgICAgLSBSYW5keTogd2UgaGF2ZSBkZXBsb3ltZW50IGlzc3Vl cw0KICAgICAgICAxLiBSSVIsIEFSSU4gaW4gcGFydGljdWxhciwgaXMgcHJvYmxlbXMNCiAgICAg ICAgMi4gZG9jcyBhcmVuJ3QgZ2V0dGluZyBwdXNoZWQgb3V0IHRoZSBkb29yDQogICAgICAgIDMu IHdlIGRvbid0IHNwZWNpZnkgYXQgdGhlIG9wcyBtZWV0aW5ncyB0aGF0IHdlJ3JlIGxvb2tpbmcg Zm9yDQogICAgICAgICAgIG5leHQgc3RlcHMgYW5kIHNvbHV0aW9ucyBhbmQgd2UncmUgcHVzaGlu ZyBGVUQuDQogICAgICAtIFJhbmR5OiBXZSBuZWVkIHRvIHRlbGwgdGhlbSAidGhpcyBpcyB2YWxp ZCBzdHVmZiIgYnV0ICJ3ZSdyZQ0KICAgICAgICByZXNlYXJjaGVycyBzbyB3ZSdyZSBzdGlsbCBn b2luZyB0byB3b3JrIG9uIGl0IGZ1cnRoZXIsIGJ1dA0KICAgICAgICBkb24ndCB0YWtlIHRoYXQg YXMgYSBiYWQgW3Vuc3RhYmxlXSB0aGluZyINCiAgICAgICAgLSB3ZSBuZWVkIGEgZGVwbG95bWVu dCBncm91cCBvZiBwZW9wbGUvY29tbT8NCiAgICAtIFNhbmR5OiB3aGF0J3MgdGhlIG5leHQgc3Rl cD8gIHdlIGhhdmUgY2VydGlmaWNhdGVzIGJlaW5nDQogICAgICBwdWJsaXNoZWQsIGFuZCB3ZSBo YXZlIG51bWJlcnMgdGhhdCBoYXZlIGEgbG90IG9mIHBlb3BsZQ0KICAgICAgcHVibGlzaGluZyBi dXQgd2UgaGF2ZSBubyByZXBvcnRzIG9mIHBlb3BsZSBhY3R1YWxseSBkb2luZw0KICAgICAgdGhp bmdzIHdpdGggdGhlIGRhdGEuDQogICAgICAtIFJ1ZWRpZ2VyOiBJJ20gdHJ5aW5nIHRvIGZpZ3Vy ZSBvdXQgd2hhdCB0aGUgbmV4dCByZXBvcnQNCiAgICAgICAgc2hvdWxkIGJlDQogICAgICAtIFJh bmR5OiB0aGVyZSBpcyBvbmUgSVNQIHRoYXQgaGFzIHNhaWQgdGhhdCBwZW9wbGUgd2hvIGhhdmUN CiAgICAgICAgd2Fsa2VkIGF3YXkgd2l0aCBzb21lIG9mIHRoZWlyIGFkZHJlc3Mgc3BhY2UgbWF5 IGJlDQogICAgICAgIHN1cnByaXNlZCBhdCB0aGUgZW5kIG9mIHRoZSB5ZWFyLg0KICAgIC0gUmFu ZHk6IFRoaXMgcHJlc2VudGF0aW9uIHNob3dzIHRoYXQgdGhpbmdzIGFyZSBhY3R1YWxseSBwcmV0 dHkNCiAgICAgIGdvb2QuICBXZSd2ZSBzaG93biB0aGF0IHRoZSBsYXRlbmN5IGRvZXNuJ3QgbWF0 dGVyIHRvbyBtdWNoLA0KICAgICAgYW5kIHRoYXQgdGhpbmdzIGFyZSB3b3JraW5nLiAgQnV0IHdl IHdhbnQgdG8gbWFrZSBzdXJlIGl0J2xsDQogICAgICBzY2FsZSBmb3JldmVyLCBidXQgZm9yIHRo ZSBmb3JzZWVhYmxlIGZ1dHVyZSBpdCBsb29rcyBnb29kIHNvDQogICAgICBnZXQgb3V0IGFuZCBk ZXBsb3kgaXQuDQogICAgLSBmcm9tIHdlYmV4OiBkb2VzIHBvc2l4X2ZhZHZpc2UoKSBoZWxwPw0K ICAgICAgLSBSb2I6IGRvbid0IGtub3c7IHdpbGwgbmVlZCB0byBjaGVjaw0KICAgIC0gUmFuZHk6 IHRoZSByZXN1bHRzIEkgc2VlIGlzIHRoYXQgdGhlIHJlYWwgcHJvcGFnYXRpb24gcHJvYmxlbSBp cw0KICAgICAgdGhlIFJJUnMgYW5kIHdlIG5lZWQgdG8gaGFtbWVyIG9uIHRoZW0gdG8gbWFrZSB0 aGlzIHdvcmsuICBUaGUNCiAgICAgIHRlY2hub2xvZ3kgcGllY2VzIGFyZSBub3QgdGhlIHNsb3cg cGFydC4NCiAgICAtIFJ1c3MgSDogbXkgdmlldyBpcyB0aGF0IHRoaXMgaXMgbm9ybWFsIElFVEYg cHJvY2VzcywgYW5kIHRoZQ0KICAgICAgc29vbmVyIHdlIGdldCB0aGluZ3MgZG9uZSB0aGUgbW9y ZSBwZW9wbGUgd2lsbCBpbXBsZW1lbnQgaXQNCiAgICAgIC0gUm9iOiBUaGVyZSBpcyBubyB3YXkg d2UgZ290IHRoaXMgcmlnaHQgdGhlIGZpcnN0IHRpbWUsIGFuZA0KICAgICAgICB0aGVyZSBpcyBu byB3YXkgdGhpcyB3b24ndCBjaGFuZ2UgYXMgdGltZSBnb2VzIG9uLiAgR2V0IG92ZXINCiAgICAg ICAgaXQuDQogICAgLSBXaGF0IGNhbiB3ZSBkbyB3aXRoaW4gdGhlIElFVEYgKElFLCB3aXRoaW4g dGhlIFdHKQ0KICAgICAgLSBSdWVkaWdlcjogSSdtIGhhcHB5IHRvIHNlZSB0aGF0IHRoZXJlIGFy ZSBzbyBtYW55IGRvY3VtZW50cw0KICAgICAgICB0aGF0IGRlc2NyaWJlIG9wZXJhdGlvbmFsIGNv bmNlcm5zLiAgQnV0IHdlIGRvbid0IGhhdmUNCiAgICAgICAgZG9jdW1lbnRzIGRlc2NyaWJpbmcg dGhlIGNvbmNlcm5zIG9uIHRoZSByZXBvIHNpZGUuICBXaGF0DQogICAgICAgIGNvbmNlcm5zIGRv IEkgbmVlZCB0byBrbm93IHRoYXQgbXkgY3VzdG9tZXJzIG1heSBoYXZlLg0KDQo2IFJQS0kgUmVw b3NpdG9yeSBGZXRjaCBQcm90b2NvbHMgLSBSb2IgQXVzdGluZSANCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KICAtIEFsbCBvZiBvdXIgZnV0dXJlIHJl c2VhcmNoIGlzIHJlYWxseSBhYm91dCB2Mjsgd2Ugc2hvdWxkIGRlcGxveSBub3cuDQogIC0gcmVh bGx5IG5lZWQgbW9yZSB0aGFuIGEgZGF0YWJhc2UgcHJvdG9jb2wgaW5zdGVhZCBvZiByc3luYw0K ICAgIC0gd2hpY2ggaGFzIGlzc3VlcyB3aXRoIGZpbGVzeXN0ZW1zLCBhbmQgY2hhbmdpbmcsIGFu ZCAuLi4NCiAgICAtIHByb2JsZW1zIHdpdGggcnN5bmMgYW5kIGVycm9yIGNvZGVzIGFuZCBkZWFs aW5nIHdpdGggdGhlbQ0KICAgIC0gcXVvdGUgZnJvbSB0aGUgcnN5bmMgYXV0aG9yOiAiaXQgd291 bGQgYmUgZGlmZmljdWx0IHRvIHdyaXRlIGENCiAgICAgIHNwZWMgZm9yIGl0LCBiZWNhdXNlIGl0 IGp1c3Qga2luZCBvZiBkb2VzIHN0dWZmIg0KICAgIC0gc3RhcnRpbmcgYSBuZXcgcnN5bmMgcHJv Y2VzcyBpcyBleHBlbnNpdmUNCiAgICAtIFJ1c3M6IGlzIHRoaXMgY2xpZW50IG9yIHNlcnZlciBw cm9ibGVtczoNCiAgICAgIC0gUm9iOiBib3RoLiAgQ2xpZW50cyBoYXZlIGlzc3VlcyB0b28gd2l0 aCB0cnlpbmcgdG8gY29tcGFyZQ0KICAgICAgICBldmVyeXRoaW5nIG9uIGRpc2suDQogIC0gVFRM IGRvZXNuJ3QgZXhpc3QNCiAgICAtIFN0ZXZlIEs6IGNhbid0IHdlIGV4cHJlc3MgdGhhdCBpbiB0 aGUgbWFuaWZlc3Q/DQogICAgLSBSb2I6IHdpbGwgdGhpbmsgYWJvdXQgaXQNCiAgLSBpdCB0dXJu cyBvdXQgdGhlIGhpZXJhcmNoeSB3ZSByZWFsbHkgY2FyZSBhYm91dCBpcyBhY3R1YWxseSB0aGUN CiAgICBjZXJ0aWZpY2F0ZSBoaWVyYXJjaHkuICBJZiBJIGNvdWxkIGZldGNoIHRoZSBjZXJ0aWZp Y2F0ZSBoaWVyYXJjaHkNCiAgICBtb3JlIGV4YWN0bHksIEkgd291bGQgY2FyZSBsZXNzIGFib3V0 IHRoZSBVUkkgaGllcmFyY2h5Lg0KICAtIGl0IG1pZ2h0IGJlIHdvcnRoIGtlZXBpbmcgdGhlIHJz eW5jIHVyaSBldmVuIGlmIHdlIGRvbid0IHVzZQ0KICAgIHJzeW5jLCBhcyB3ZSBuZWVkIHVuaXF1 ZSB1cmkncyBmb3IgYWxsIG9iamVjdHMNCiAgLSByb2IgZGlzY3Vzc2VzIHdoYXQgRE5TIGlzDQog ICAgLSBSb2IgYW5kIFdhcnJlbiB3YWxrIGRvd24gYSBoeXBvdGhldGljYWwgb3RoZXIgc29sdXRp b24gYW5kIHdpbGwNCiAgICAgIGRpc2N1c3MgdGhpbmdzIGxhdGVyDQogIC0gRGF0YSBmcmVzaG5l c3M6ICJpcyB0aGUgc3R1ZmYgdGhlIFJQIGlzIGxvb2tpbmcgYXQgY2xvc2UgZW5vdWdoIHRvDQog ICAgd2hhdCB0aGUgc2VydmVyIHRoaW5ncyBpdCdzIHB1dCBvdXQsIG9yIGlzIHRoZXJlIHNpZ25p ZmljYW50IHNrZXcNCiAgICBiZXR3ZWVuIHdoYXQgdGhlIHNlcnZlciBoYXMgcHVibGlzaGVkIGFu ZCB3aGF0IHRoZSBjbGllbnQgaGFzIGdvdD8iDQogIC0gVHdvIGFwcHJvYWNoZXMsIGluIG15IG1p bmQ7DQogICAgMS4gRE5TIHRyYW5zZmVyIGxpa2UgcHJvdG9jb2xzIChBRlhSLCBJWEZSKQ0KICAg IDIuIHVzZSBBVE9NIChlZywgUlNTKSB0byBwdWJsaXNoIG5ldyBzdHVmZg0KICAtIEROUyB0cmFu c2ZlciBsaWtlOg0KICAgIC0gbW9yZSB3b3JrIGZvciB0aGUgQ0ENCiAgICAtIG11c3Qga2VlcCB2 ZXJzaW9ucyBiYWNrIGluIG9yZGVyIHRvIHN1cHBvcnQgdGhlIGluY3JlbWVudGFsDQogICAgICB0 cmFuc2ZlciAoSVhGUikNCiAgLSBBVE9NLWxpa2UgYXBwcm9hY2g6DQogICAgLSBzdGlsbCBuZWVk IHRvIGFzayAid2hhdCBpcyBjdXJyZW50PyINCiAgICAtIEFUT00gdnMgUlNTOiBBVE9NIGlzIElF VEYtZG9jdW1lbnQgYW5kIGhhcyBzb21lIG90aGVyIGNvb2wgZmVhdHVyZXMuDQoNCjYuMSBRdWVz dGlvbnM/IA0KLS0tLS0tLS0tLS0tLS0tDQogICAgLSBzdGV2ZSBiOiBob3cgbXVjaCBkYXRhIGFy ZSB3ZSB0YWxraW5nIGFib3V0IGluIHRvdGFsPw0KICAgICAgLSBSb2I6IHNvbWV0aGluZyBvbiB0 aGUgb3JkZXIgb2YgMU0gb2JqZWN0cw0KICAgICAgLSBTYW5keTogYXQgbGVhc3QgdGhhdCBiZWNh dXNlIDQwMGsgcm91dGVzLCBFRSBjZXJ0cywgUk9BcywgLi4uDQogICAgICAtIFJvYjogc2F5IDFN IHRvIDEwTSBhdCBtb3N0LiAgNiBmaWd1cmVzLg0KICAgICAgLSBDaHJpcyBNIG5vdGVzIG9uIGph YmJlcjoNCiAgICAgICAgLSB5b3UgY2FuIGRvLCBJIHRoaW5rIGJpbmFyeS1zdHVmZiBpbiByc3Mu IHNlZSBpdHVuZXMgZm9yDQogICAgICAgICAgZXhhbXBsZS4uLiBidXQgJ2dvIGZvciBpZXRmIHN0 ZCcgc2VlbXMgZmluZS4NCiAgICAgICAgLSBsb29rIGF0IHRoZSBub3RlcyBvZiB0aGUgbGFzdCBp bnRlcmltIGluIHJlc3RvbiBmb3Igc2l6ZWluZw0KICAgICAgICAgIGRhdGEvZ3Vlc3Nlcy4NCiAg ICAgICAgLSB3ZSB3b3JrZWQgdGhpcyBvdXQgcHJldmlvdXNseS4NCiAgICAgIC0gU3RldmUgQjog Sm91cm5hbCBmaWxlcyBzZWVtIHRvIGJlIHRoZSBiZXN0LiAgV2UgcmVhbGx5IGp1c3QNCiAgICAg ICAgd2FudCB0byBrbm93IHdoYXQgaXMgbmV3Lg0KICAgICAgLSBSb2IgQTogZnVuY3Rpb25hbGx5 IEFUT00gaXMgbGlrZSBhIGpvdXJuYWwsIGl0J3MgYSBsaXN0IG9mDQogICAgICAgIHdoYXQgaGFz IGNoYW5nZWQuDQogICAgLSBXYXJyZW46IG9uZSBvZiB0aGUgY29uY2VybnMgd2l0aCBiaXR0b3Jy ZW50IGlzIHRoYXQgcGVvcGxlIGFzc3VtZQ0KICAgICAgdGhhdCB3aGF0J3MgaW4gYml0dG9ycmVu dCBpcyBldmlsLg0KICAgIC0gUmFuZHkncyBjb25jZXJuIGlzIG5hcnJvd2luZyB0aGUgYXR0YWNr IGF2ZW51ZSB0b3dhcmQgdGhlIG5ldw0KICAgICAgc2VydmljZSBJJ20gc3RhbmRpbmcgdXANCg0K NyBEZXBsb3ltZW50IENvbnNpZGVyYXRpb25zIGluIFJQS0kgLSBUaW0gQnJ1aWpuemVlbHMgDQo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiAg LSByc3luYyBnaXZlcyB1cyBkZWx0YXMNCiAgLSBVc2UgYW4gdXBkYXRlIG5vdGlmaWNhdGlvbiBm aWxlPw0KICAgIC0gYW4gdXBkYXRlIG5vdGlmaWNhdGlvbiBmaWxlIHNob3dzIGV2ZXJ5dGhpbmcg dGhhdCBoYXMgY2hhbmdlZA0KICAgICAgc2luY2UgWA0KICAgIC0gVGhlIHNlcnZlciBpcyBub3Qg aW52b2x2ZWQgYXQgYWxsIGFuZCB0aGUgY2xpZW50IGZpZ3VyZXMgb3V0IGZvcg0KICAgICAgdGhl bXNlbHZlcyB3aGF0IHRoZXkgbmVlZC4NCiAgICAtIGNvdWxkIGNvbnRpbnVlIHVzaW5nIHJzeW5j IGFzIGFuIGlkZW50aWZpZXIsIGFzIFJvYiBzdWdnZXN0ZWQNCiAgICAgIGVhcmxpZXINCiAgICAt IEEgcHVibGljYXRpb24gc2VydmVyIGNhbiByZWNyZWF0ZSBtZXNzYWdlcyB0byBjcmVhdGUgZGVs dGEgZmlsZXMNCiAgLSByb3VnaGx5IDEwIHRpbWVzIGZhc3RlciB0aGFuIHJzeW5jDQogICAgLSBE b3VnIE06IGlzIHRoaXMgYW4gdW5jaGFuZ2luZyBkaXJlY3RvcnkgaW4gcnN5bmM/DQogICAgLSBU aW06IFRoaXMgaXMgZm9yIGZldGNoaW5nIGEgc3BlY2lmaWMgZmlsZQ0KICAgIC0gU2FuZHk6IGlz IHRoZSBmaWxlIGNoYW5naW5nIHRvIHRpY2tsZSByc3luYz8NCiAgICAtIFRpbTogcnN5bmMgYWxy ZWFkeSBoYXMgYSBjb3B5LCBhbmQgdGhlIGh0dHAgcHVsbCBpcyBwdWxsaW5nIGl0DQogICAgICBl dmVyeXRpbWUuICBbU28gdGhlIGRpc2NyZXBhbmN5IGluIHRoZSBncmFwaCBpcyBsaWtlbHkgZXZl bg0KICAgICAgd29yc2UgZm9yIHJzeW5jXQ0KICAtIFRpbTogdGhpcyByZWFsbHkgc2hvd3MgYXBh Y2hlIGlzIGJldHRlciBhdCBoYW5kbGluZyBsb2FkcyB0aGFuIHJzeW5jDQogIC0gQmVjYXVzZSBo dHRwIGlzIGZsZXhpYmxlLCBpdCBtaWdodCBiZSBnb29kIHRvIGNyZWF0ZSBoZWFkZXJzDQogICAg LSBidXQgaHR0cCBpcyBhbHNvIHVudHJ1c3RlZA0KICAtIGZldGNoIG9iamVjdHMgYnkgaGFzaCBp bnN0ZWFkIG9mIGJ5IG5hbWUgd291bGQgYmUgaGVscGZ1bA0KICAgIC0gYmVjYXVzZSB0aGUgbWFu aWZlc3QgY29udGFpbnMgaGFzaGVzLCB5b3UnbGwgZ2V0IHRoZSByaWdodA0KICAgICAgY2VydGlm aWNhdGVzIGZvciB0aGF0IG1hbmlmZXN0IHJhdGhlciB0aGFuIGEgcG90ZW50aWFsbHkNCiAgICAg IGRpZmZlcmVudCBzZXQgb2YgY2VydGlmaWNhdGVzIHRoYXQgZG9uJ3QgcGVyZmVjdGx5IG1hdGNo DQogICAgLSBTYW5keTogZG9lcyB0aGF0IG1ha2UgaXQgY3JpdGljYWwgZm9yIHdoZW4gdGhlIG1h bmlmZXN0IGlzDQogICAgICBwdWJsaXNoZWQ/DQogICAgLSBUaW06IGlkZWFsbHkgeW91IHdhbnQg dG8gZG8gdGhpcyBhcyBhbiBhdG9taWMgb3BlcmF0aW9uLiAgWW91DQogICAgICB3YW50IHRvIHB1 Ymxpc2ggdGhlIG9iamVjdHMgZmlyc3QgYW5kICp0aGVuKiBwdWJsaXNoIHRoZQ0KICAgICAgbWFu aWZlc3QuDQogIC0gU3RldmUgSzogSSBkb24ndCB1bmRlcnN0YW5kIHdoZW4gSSBjYW4ndCBnZXQg YSBjdXJyZW50IG1hbmlmZXN0Lg0KICAgIFdoeSBzaG91bGQgSSBrZWVwIG9sZCBzdHVmZiBhcm91 bmQgdG8gcmV3YXJkIHBlb3BsZSB0aGF0IGZhaWwgdG8NCiAgICBwdWxsIHRoZSBuZXcgb25lPw0K ICAgIC0gVGltOiB5b3UgbWF5IGJlIHJpZ2h0LCB0aGlzIG1heSBub3QgYmUgd29ydGggdGhlIGVm Zm9ydC4NCiAgICAtIFN0ZXZlOiB5b3UgaGF2ZSB0byBoYXZlIGEgd2F5IGZvciBhIFJQIHRvIGRv IGEgY29sZC1zdGFydC4NCiAgICAtIFN0ZXZlOiBXZSBjYW4ndCBrZWVwIHN0dWZmIGZvcmV2ZXIN CiAgICAtIFN0ZXZlOiB3ZSByZWFsbHkgbmVlZCBhIHJlcXVpcmVtZW50cyBsaXN0IGZvciB3aGF0 IHRoZSBuZXcNCiAgICAgIGRlcGxveW1lbnQgdGVjaG5vbG9neSBzaG91bGQgYmUNCiAgICAtIFRp bTogSSBhZ3JlZQ0KICAtIFRoZSByZXNvdXJjZXMgYXJlIGFscmVhZHkgdmVyaWZpYWJsZSwgc28g bGlrZWx5IGRvbid0IG5lZWQgaHR0cHMNCiAgICAtIGJpdHRvcnJlbnQsIGVnLCBhbHJlYWR5IHJl ZGlzdHJpYnV0ZXMgdW52ZXJpZmllZCBwaWVjZXMgeW91IG11c3QNCiAgICAgIHZlcmlmeQ0KICAt IGtleSByb2xsb3ZlcnMgYXJlIGdvaW5nIHRvIGJlIGEgcGFpbg0KICAgIC0gZXNwZWNpYWxseSBl bWVyZ2VuY3kgb25lcw0KICAtIHB1YmxpY2F0aW9uL3N1YnNjcmlwdGlvbiBwcm90b2NvbHMgd291 bGQgaGVscA0KDQo3LjEgUXVlc3Rpb25zPyANCi0tLS0tLS0tLS0tLS0tLQ0KICAgIC0gU2FuZHk6 IGhvdyBkb2VzIGFuIFJQIGtub3cgd2hpY2ggcHVibGljYXRpb24gc2VydmVycyB0bw0KICAgICAg c3Vic2NyaWJlIHRvPw0KICAgICAgLSBUaW06IHRoYXQgaXMgbWlzc2luZyBpbiB0aGlzIGFyY2hp dGVjdHVyZQ0KICAgICAgLSBSb2I6IEFUT00gaXMgYWxzbyBhIHBvbGwgYmFzZWQuICBIb3cgZmFz dCBkbyB5b3UgbmVlZCBhbg0KICAgICAgICB1cGRhdGU/ICBpbnN0YW50IG9yIGlzIDUgbWludXRl cyBnb29kIGVub3VnaD8NCg0KNy4yIENvbmNsdXNpb25zIA0KLS0tLS0tLS0tLS0tLS0tLQ0KICAg IC0gcmVkdWNlIHRoZSBsb2FkIG9mIHRoZSBzZXJ2ZXINCiAgICAtIGNsaWVudHMgZG8gdGhlIGNh bGN1bGF0aW9uIHdvcmsgZm9yIHdoYXQgdGhleSBuZWVkDQogICAgLSBjYW4gYmUgZGVsZWdhdGVk IHRvIENETnMNCiAgICAtIGNhbiBqdXN0IHdyaXRlIHRvIGRpc2sgb25jZQ0KICAgIC0gY2FuIGdp dmUgeW91IHRyYW5zYWN0aW9uYWxpdHkNCg0KNy4zIERpc2N1c3Npb25zIA0KLS0tLS0tLS0tLS0t LS0tLQ0KICAgIC0gdGFraW5nIHB1YmxpY2F0aW9ucyB0byBhIHB1YmxpY2F0aW9uIHBvaW50IG1l YW5zIHlvdSBjYW4gZG8NCiAgICAgIGNvbnNpc3RlbmNlIGNoZWNrcyBmaXJzdCBiZWZvcmUgcHVi bGlzaGluZyB0aGVtIGF0IHB1YmxpY2F0aW9uDQogICAgICBwb2ludHMuICBCYWQgZ3V5cyBjYW4n dCB1cGxvYWQganVuay4NCg0KNy40IE1vcmUgY29uY2x1c2lvbnMgDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0NCiAgICAtIGxpa2VseSB0aGF0IHNlY3VyZSB0cmFuc2ZlciBwcm90b2NvbHMgdG8gYXZv aWQgbWFuLWluLXRoZS1taWRkbGUNCiAgICAgIGFyZW4ndCBuZWVkZWQgYmVjYXVzZSB0aGUgb2Jq ZWN0cyBhcmUgc2lnbmVkIHRoZW1zZWx2ZXMNCiAgICAtIFJvYjogbm90IHN1cmUgaWYgdGhlcmUg YXJlIG5hdGl2ZSBsaWJyYXJpZXMgZm9yIGZldGNoaW5nIGxvdHMgb2YNCiAgICAgIHRoaW5ncywg YW5kIHlvdSBkb24ndCB3YW50IHN5bmNyb25vdXMgaHR0cCBvbmx5LiAgWW91IG5lZWQgdG8NCiAg ICAgIGZldGNoIG1hbnkgdGhpbmdzIGF0IG9uY2UuDQogICAgICAtIFdlcyBIOiB0aGVyZSBhcmUg Y2xpZW50cyB0aGF0IGhhdmUgZ29vZCBjbGllbnRzIGZvciBwdWxsaW5nIGxvdHMNCiAgICAgICAg b2YgZGF0YQ0KICAgIC0gVGltOiB3YW50IHRvIGtlZXAgYSBncmFwaCBpbiBtZW1vcnkgdGhhdCBs ZXRzIHlvdSBmaWd1cmUgb3V0DQogICAgICB3aGF0IHBhcnRzIG9mIHRoZSB0cmVlIG5lZWQgdG8g cmV2YWxpZGF0ZSBhZnRlciBkYXRhIGNoYW5nZXMuDQogICAgICBIYXZpbmcgZ29vZCBpbmZvcm1h dGlvbiBvbiB3aGF0IGNoYW5nZWQgd291bGQgaGVscCBoZXJlLg0KICAgIC0gU2FuZHk6IHRoZSBz ZXJ2ZXIgbG9hZCB2YXJpZXMgYSBsb3QgYW1vbmcgdGhlIENBIHNlcnZlcnMgYmVjYXVzZQ0KICAg ICAgb2YgdGhlaXIgc2l6ZXMuICBUaGUgUlBzIGhhdmUgdG8gYWxsIHJldHJpZXZlIGV2ZXJ5dGhp bmcuICBUaGlzDQogICAgICBoZWxwcyB0aGUgc2VydmVyLCByaWdodD8NCiAgICAgIC0gbW9yZSB3 b3JrIGlzIG5lZWRlZCB0byBzdHVkeSB3aGF0IHdvcmtzLCBidXQgd2UgZG9uJ3QgaGF2ZQ0KICAg ICAgICBjb2RlIHRoYXQgc3VwcG9ydHMgaXQgeWV0IHNvIHdlIGNhbid0IHRlc3QgYW5kIG1lYXN1 cmUgaXQgd2VsbA0KICAgICAgICB5ZXQuDQogICAgLSBSYW5keTogbXkgd29ycnkgaXMgdGhlIHNp Z25pZmljYW50IGluY3JlYXNlIGluIHNtYXJ0cy4gIEtlZXBpbmcNCiAgICAgIGEgZ3JhcGggc291 bmRzIGhhcmRlciB0aGFuIGp1c3QgZG9pbmcgdGhlIGNyeXB0by4NCiAgICAtIERvdWc6IGNhbiB0 aGUgc2VydmVyIHNheSBob3cgZmFyIGJhY2sgaXQgaGFzIHRvIGdvLg0KICAgICAgLSBSb2I6IGl0 IGhhcyB0byBkbyBzb21ldGhpbmcgbGlrZSBmdWxsL2luY3JlbWVudGFsIGJhY2t1cHMuDQogICAg ICAgIFdoZW4geW91IGdldCB0byBhIGNlcnRhaW4gcG9pbnQgeW91IGdldCB0byB5b3UgbmVlZCB0 bw0KICAgICAgICB0cmFuc2ZlciB0aGUgZW50aXJlIGJhY2t1cCBhZ2Fpbg0KICAgICAgLSBXZXMg SDogeW91J2xsIG5lZWQgdHdvIHNlcmlhbCBudW1iZXJzLCBub3Qgb25lLiAgWW91IG5lZWQgb25l DQogICAgICAgIHRvIGluZGljYXRlIHdoZXJlIHRoZSBsYXN0IGZ1bGwgc3RvcmUgaXMgYW5kIHRo ZW4gaW5jcmVtZW50YWwNCiAgICAgICAgbnVtYmVycyBiZXlvbmQgdGhhdCBmb3IgcmV0cmlldmlu ZyB0aGUgZGVsdGFzIGZyb20gdGhlIGxhc3QgZnVsbC4NCiAgICAgIC0gUm9iOiBETlMgSVhGUiB3 YXMgZGVzaWduZWQgY2FyZWZ1bGx5IHRvIG1ha2UgaXQgc2ltcGxlIGZvciB0aGUNCiAgICAgICAg Y2xpZW50IGFuZCBzZXJ2ZXIsIGJ1dCBtYXkgcmVxdWlyZSBtb3JlIGZyZXF1ZW50IGZ1bGwNCiAg ICAgICAgdHJhbnNmZXJzDQoNCjggRG9jdW1lbnQgYWR2YW5jZW1lbnQgDQo9PT09PT09PT09PT09 PT09PT09PT09PQ0KICAtIFJvb206IGhvdyBkbyB3ZSBhZHZhbmNlIHRoZSBkb2N1bWVudHMgb3V0 PyAgV2hhdCBjYW4gKndlKiBkbyB0byBoZWxwPw0KICAgIC0gU2FuZHk6IHRoZSBjaGFpcnMgaGF2 ZSBkaXZpZGVkIHVwIGR1dGllcyBhbmQgd2lsbCB0cnkgdG8gZ2V0IG91dA0KICAgICAgc29tZSBv ZiB0aGUgZG9jdW1lbnRzIHRoaXMgd2Vlay4NCiAgICAtIC4uLg0KICAgIC0gVGhlIGNoYWlycyBu ZWVkIHRvIGVuc3VyZSB0aGF0IGFsbCBjb21tZW50cyBoYXZlIGJlZW4gYWRlcXVhdGVseQ0KICAg ICAgYWRkcmVzc2VkLg0KICAgICAgLSBSdXNzIEg6IGluc3RlYWQsIHBvc3QgdGhlIG5ldyBkb2N1 bWVudCBhbmQgc2F5IHdlIGJlbGlldmUgYWxsDQogICAgICAgIGNvbW1lbnRzIGhhdmUgYmVlbiBy ZWZsZWN0ZWQsIHBsZWFzZSBzcGVhayBub3cgaWYgeW91IHRoaW5rDQogICAgICAgIHNvbWV0aGlu ZyB3YXMgbm90IGFkZHJlc3NlZC4NCiAgICAtIFNhbmR5IGNyZWF0ZWQgYSBjaGFpciBhY3Rpb24g cGFnZToNCiAgICAgIFtodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9zaWRyL3RyYWMvd2lr aS9DaGFpckFjdGlvbnNdDQogICAgLSBTYW5keTogdGhlIGlzc3VlIHRyYWNrZXIgaGFzbid0IHdv cmtlZCB3ZWxsDQogICAgLSBXZSBuZWVkIGEgV0cgc2VjcmV0YXJ5Pw0KICAgIC0gLi4uIGxvdHMg b2YgZGlzY3Vzc2lvbiBhYm91dCBwYXJ0aWN1bGFyIGRvY3VtZW50cyBhbmQgd2hlcmUgaXQNCiAg ICAgIGlzIGFuZCB3aHkgLi4uDQoNCjkgQkdQU0VDIHByb3RvY29sIGRvY3VtZW50IA0KPT09PT09 PT09PT09PT09PT09PT09PT09PT09DQogIC0gTWF0dDogZHJhZnQtMDQgdmVyc2lvbiBwdWJsaXNo ZWQgdG8gcmVmbGVjdCB0aGUgaXRlbXMgZGlzY3Vzc2VkIGluDQogICAgdGhlIGp1bmUgaW50ZXJv cCBtZWV0aW5nDQogICAgLSBJbiBwYXJ0aWN1bGFyIGl0IGhhcyBhIHNlY3Rpb24gaXRzZWxmIGRp c2N1c3NpbmcgY29uZmVkZXJhdGlvbg0KICAgICAgaXNzdWUNCiAgICAtIERvbid0IHRoaW5rIHRo ZXJlIGFyZSBhbnkgbmV3IG9wZW4gdGVjaG5pY2FsIGlzc3Vlcy4gIElmIHRoZXJlDQogICAgICBh bnkgb3BlbiBpc3N1ZXMsIHRoZXkgbmVlZCB0byBiZSByYWlzZWQgYXQgdGhpcyBwb2ludC4NCiAg LSBUYXJnZXQgQVMgaXNuJ3Qgb24gdGhlIHdpcmUsIGJ1dCBpcyBpbmNsdWRlZCBpbiB0aGUgaGFz aC4gIEkga25vdw0KICAgIHdoYXQgQVMgbnVtYmVyIEkgc2FpZCBJIHdhcyBmb3IgdGhhdCBzZXNz aW9uLCBidXQgaXQgZG9lc24ndCBnbw0KICAgIG92ZXIgdGhlIHdpcmUuDQogICAgLSBXaGVuIHRo ZSBBU04gbmVlZHMgdG8gY2hhbmdlLCB3aGVuIGRvZXMgdGhlIG90aGVyIHNpZGUgb2YgdGhlDQog ICAgICBjb25uZWN0aW9uIGtub3cgd2hlbiB0byBjaGFuZ2UgdGhlIG5vdGlvbiBvZiB0aGUgb3Ro ZXIgbnVtYmVyLg0KICAgIC0gb25lIGhvcCBpcyBlYXN5IGJlY2F1c2UgeW91IGNhbiB0cnkgYm90 aCBBUyBudW1iZXJzLCBidXQgMiBob3BzDQogICAgICBkb3duIGlzIGltcG9zc2libGUNCiAgICAt IFdlc0c6IGl0J3MgYSB3ZWxsIGtub3duIHVzZSBjYXNlIHNvIGkgZG9uJ3QgdGhpbmsgeW91IGNh biBzYXkNCiAgICAgIGl0J3MgdmVyYm90ZW4uDQogICAgLSBTYW5keTogZG9lc24ndCBpdCBsZXQg eW91IHRyZWF0IHRoZSBtaWRkbGUgYXMgYSBwY291bnQ9MCB3aXRoIGENCiAgICAgIHJvdXRlIHNl cnZlciBpbiB0aGUgbWlkZGxlPw0KICAgICAgLSBjb21wbGV4IGRpc2N1c3Npb24gYWJvdXQgd2hl dGhlciBpdCB3b3VsZCB3b3JrDQogICAgLSBSYW5keTogcHJvdmlkZXIgd2FudHMgdG8gY2hhbmdl IHRoZSBBUyBudW1iZXIgd2l0aG91dA0KICAgICAgY29vcmRpbmF0aW5nIHdpdGggdGhlIHNlbmRl cg0KICAgICAgLSB0aGlzIGlzIHVwc3RyZWFtIGZyb20gdGhhdA0KICAgIC0gdGhlIHNvbHV0aW9u IGlzIHRvIHNldCB0aGUgcGNvdW50PTAgaW4gdGhlIGluc2lkZSBvZiB0aGUgaXNwDQogICAgICBj aGFuZ2luZw0KDQogICAgICBEaWFncmFtOg0KDQogICAgICAgICBbaHR0cDovL2hhcmRha2Vycy5u ZXQvdGVtcC8xMjA3MDA0Ny5zbS5qcGddDQoNCg0KDQogICAgICAgICAgICAgICAgICBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgICAgICAgICAgICAgICAvICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBcDQogICstLS0tLS0rICAgICAgfCAgKy0tLS0tLSsgICAgICAg ICAgICAgICArLS0tLS0tKyB8DQogIHwgY3VzdCB8IC0tPiAgfCAgfCBJU1AxIHwgICAgLS0+ICAg ICAgICB8IElTUDIgfCB8DQogIHwgQVM3ICB8ICAgICAgfCAgfCBBUzEgIHwgcGNvdW50PTAgICAg ICB8IEFTMyAgfCB8DQogICstLS0tLS0rICAgICAgfCAgKy0tLS0tLSsgICAgICAgICAgICAgICAr LS0tLS0tKyB8DQogICAgICAgICAgICAgICAgIFxfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18vDQoNCg0KICAgICAgSVNQMSB1c2VzIG9yaWdpbmFsIEFTTiAoMSkgdW50aWwgbGF0ZXIu ICBJbnRlcm5hbGx5IGl0IGNvdWxkIGJlDQogICAgICBJR1AgaW5zdGVhZC4NCg0KDQogIC0gZG8g d2UgbmVlZCBhIG5ldyBkb2N1bWVudCB0byBkZXNjcmliZSBjaGFuZ2luZyBBUyBzY2VuYXJpb3M/ DQogICAgLSBIb3cgbXVjaCBkbyB3ZSBuZWVkIHRvIGRlc2NyaWJlIGFuZCB3aHk/DQogICAgLSBX YXJyZW4gYW5kIFdlc0cgd2lsbCBzaXQgZG93biBhbmQgZG9jdW1lbnQgaXQNCg0KICAtIE1hdHQg ZHJhd2luZyBvbiB0aGUgYm9hcmQ6DQogICAgLSBkbyB3ZSBsb29rIGZvcndhcmQgb3IgYmFja3dh cmQgZm9yIHRoZSBzcGVjaWFsIGVudHJ5DQoNCiAgICAgICAgIFtodHRwOi8vaGFyZGFrZXJzLm5l dC90ZW1wLzEyMDcwMDQ4LnNtLmpwZ10NCg0KDQoNCiAgICAgICAgb3JpZ2luICANCiAgICAgICAg QVMyICAqICAgICAgICBsb29rIF4NCiAgICAgICAgQVMzICAgICAgICAgICAgb3IgICANCiAgICAg ICAgQVM0ICAgICAgICAgdiAgICAgICANCiAgICAgICAgQVM1ICAgICANCiAgDQogIA0KICAgICAg ICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgICAgICAgICAgLyAg ICAgICAgICAgICAgICAqICAgICAgICAgICAgICAgIFwNCiAgKy0tLS0tKyAgLyAgKy0tLS0tKyAg ICAgKy0tLS0tKyAgICAgKy0tLS0tKyAgXCAgKy0tLS0tKw0KICB8IEFTMSB8IC0tPiB8IEFTMiB8 IC0tPiB8IEFTMyB8IC0tPiB8IEFTNCB8IC0tLT58IEFTNSB8DQogICstLS0tLSsgIFwgICstLS0t LSsgICAgICstLS0tLSsgICAgICstLS0tLSsgIC8gICstLS0tLSsNCiAgICAgICAgICAgIFxfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18vDQogICAgICAgICAgICAgICAgDQogICAgICAg ICAgICAgICB2DQogIA0KICAgICAgICAgICAgICAgc2V0DQogICAgICAgICAgICAgICBBRkxBRw0K DQoNCjEwIE11bHRpUGF0aCBEcmFmdHMgDQo9PT09PT09PT09PT09PT09PT09PQ0KICAtIFNhbmR5 OiBEb2VzIEJHUFNFQyBoZWxwIHdpdGggYW55IG9mIHRoZSBlbmQtcGF0aCB0aGluZ3M/DQogICAg LSBSdWVkaWdlcjogdGhvc2UgZG9jdW1lbnRzIGRvbid0IG1hbmdsZSB0aGUgQVNQQVRIIHNvIHRo ZXkNCiAgICAgIHNob3VsZG4ndCBjb25mbGljdCB3aXRoIEJHUFNFQywgdGhleSBqdXN0IGFkZCBu ZXcgYXR0cmlidXRlcw0KDQoxMSBTdGFibGUgU2lnbmF0dXJlIA0KPT09PT09PT09PT09PT09PT09 PT0NCiAgLSBEb3VnIE06IEVDRFNBIHByb2R1Y2VzIGRpZmZlcmVudCBzaWduYXR1cmVzIG9uIGVh Y2ggY2FsbC4gIE11bHRpcGxlDQogICAgdXBkYXRlcyB3aWxsIGxvb2sgZGlmZmVyZW50Lg0KICAg IC0gTWF0dCBhbmQgUm9iOiB0aGUgb25seSB0aGluZ3MgdGhhdCBjaGFuZ2UgYXJlIHRoZSBzaWdu YXR1cmUsIHRvDQogICAgICBhdm9pZCBkdXBsaWNhdGVzIHlvdSBkb24ndCBpbmNsdWRlIGNvbXBh cmluZyB0aGUgc2lnbmF0dXJlcyBpbg0KICAgICAgZHVwbGljYXRlIGRldGVjdGlvbi4NCiAgICAt IGFuZCB0aGUgU0tJIHdvdWxkIGNoYW5nZSBpZiBrZXlzIGNoYW5nZSB0b28NCiAgICAtIFNob3Vs ZCBhIHNlbnRlbmNlIGJlIGFkZGVkIHRvIGNsYXJpZnkgdGhpcyBhbmQgc3BlY2lmaWNhbGx5DQog ICAgICBzdWdnZXN0IHRoYXQgeW91IG1heSB3YW50IHRvIGRyb3AgZHVwbGljYXRlcyBpZiB0aGUg cGF0aCBhbmQNCiAgICAgIFNLSXMgYWxsIG1hdGNoLCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgdGhl IHNpZ25hdHVyZXMgZG9uJ3QNCiAgICAgIG1hdGNoLiAgUG90ZW50aWFsbHkgaW4gdGhlIG9wZXJh dGlvbmFsIHNlY3Rpb24uDQogICAgLSBTdGV2ZSBLIGFuZCBTYW5keSBwcm9wb3NlIGNlcnRhaW4g d29yZGluZw0KICAgIC0gRGVmZXIgdG8gTWF0dCdzIHdvcmRpbmcNCg0KMTIgUm91dGUgTGVha3Mg YW5kIEJyaWFuIERpY2tlcnNvbiANCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 DQogIC0gU2FuZHkgcmVjZWl2ZWQgYSBxdWVzdGlvbiBhYm91dCB3aGV0aGVyIHRoZXkncmUgZ29p bmcgdG8gYmUNCiAgICBwYXNzaW5nIG9uIHRoZSAzIGRyYWZ0cy4gIFN1Z2dlc3Rpb24gd2FzIHRv IGdpdmUgaXQgdG8gZ3JvdywgdGhlbg0KICAgIHRvIGlkciwgdGhlbiB0byBzaWRyLg0KDQoxMyBS ZXBvc2l0b3J5IHN5c3RlbSByZXF1aXJlbWVudHMgDQo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09DQogIC0gUnVlZGlnZXI6IEFyZ3VtZW50cyBhYm91dCB3aGF0IHNob3VsZCBiZSBk b25lIGFib3V0IHRoZSBjdXJyZW50DQogICAgcmVwb3NpdG9yeS4NCiAgLSBTdGV2ZSBLOiBMZXRz IHB1dCBpdCBvbiB0aGUgUklQRSAoc2VwdCkgYWdlbmRhPw0KICAtIFJ1ZWRpZ2VyOiBJJ2QgcmF0 aGVyIGhhdmUgaXQgZG9uZSBieSB0aGVuLg0KICAtIE1pc2M6IHRoZSBXRyBzaG91bGQgbWFrZSB0 aGUgc3RhdGVtZW50IHRoYXQgdGhlIFJQS0kgaXMgZGVzaWduZWQNCiAgICB0byBiZSBoaWVyYXJj aGljYWwgYW5kIHJlc2VhcmNoIHNob3dzIHRoZXJlIGFyZSByZWFsIG51bWJlcnMgdGhhdA0KICAg IHNob3cgdGhpcyB0byBiZSBjb25zaXN0ZW50Lg0KICAtIEhvdyBkbyB3ZSBtYWtlIGEgc3RhdGVt ZW50IHdpdGhvdXQgd3JpdGluZyBhIGRyYWZ0Pw0KICAgIC0gcnVzczogeW91IGNhbid0IHdyaXRl IGEgY29uc2Vuc3VzIHN0YXRlbWVudCB3aXRob3V0IHdyaXRpbmcgYSBkcmFmdA0KICAgIC0gV2Vz RzogeW91IGNvdWxkIHNwZWNpZnkgYSBidW5jaCBvZiBzcGVjcyB0aGV5IHNob3VsZCBtZWV0IGFu ZA0KICAgICAgbm90IGNhcmUgaG93IHRoZXkgbWVldCBpdCwgd2hldGhlciBpdCdzIHZpYSBtb3Jl IGhhcmR3YXJlIG9yDQogICAgICByZXBvc2l0b3J5IG9wdGltaXphdGlvbi4NCiAgICAtIFJhbmR5 OiBvcmlnaW4tb3BzIHdpdGggb25lIG5ldyBzZWN0aW9uLCB3aGljaCBpcyBuZWFyIGVuZC1nYW1l Pw0KICAgICAgLSByb29tIHNlZW1zIGZpbmUgd2l0aCB0aGlzIGNob2ljZQ0KICAgIC0gVGltOiBp ZiB5b3Ugc3BlY2lmeSByZXF1aXJlbWVudHMgdGhhdCBjYW4ndCBiZSBtZXQsIHRoZW4gUklScw0K ICAgICAgbWF5IHN0YXRlIHRoZXkgd29uJ3QgZG8gdGhlbS4NCiAgLSBHb2luZyB0byBoaWVyYXJj aGljYWwgYXQgbGVhc3Qgc2F2ZXMgdXMgdGltZSwgYnV0IGl0IGRvZXNuJ3QNCiAgICBjaGFuZ2Ug dGhlIGZhY3Qgd2UnbGwgbmVlZCBhIHYyIGluIHRoZSBmdXR1cmUuDQogIC0gV2hhdCBkb2VzIGl0 IHRha2UgdG8gY29udmVydCB0byBoaWVyYXJjaGljYWw/DQogICAgLSBpdCdzIGFib3V0IGVxdWFs IHRvIGEgcmVrZXkgYmVjYXVzZSBhbGwgdGhlIFVSSXMgaGF2ZSB0byBjaGFuZ2UNCiAgDQoNCg== --_002_24B20D14B2CD29478C8D5D6E9CBB29F625F368B4Hermescolumbiaa_-- From Sandra.Murphy@sparta.com Thu Aug 2 13:23:07 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B70F221E80E4 for ; Thu, 2 Aug 2012 13:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-L60skaIauN for ; Thu, 2 Aug 2012 13:23:07 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2544E21E80EA for ; Thu, 2 Aug 2012 13:23:07 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q72KN4ff006822 for ; Thu, 2 Aug 2012 15:23:05 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q72KN4Z2009303 for ; Thu, 2 Aug 2012 15:23:04 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0355.002; Thu, 2 Aug 2012 16:23:11 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: sidr participation in the LIM scheduled for 29 Sep in Amsterday Thread-Index: Ac1wzqPuytAgR6OGTwKrhYoo46AkMQ== Date: Thu, 2 Aug 2012 20:23:10 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F369D5@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] sidr participation in the LIM scheduled for 29 Sep in Amsterday X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 20:23:07 -0000 In the SIDR meeting, the interim meeting proposed for Sep was discussed.=0A= =0A= The original proposed date was 23 Sep, intended to take advantage of IETF p= lans to hold a large scale interim meeting around the RIPE meeting in Sep.= =0A= =0A= The IETF plans are now to hold the meeting on Sat 29 Sep (the Sat after RIP= E).=0A= =0A= The meeting participants indicated that they were still in favor of this me= eting. RIPE participants clarified for the group that RIPE participants te= nd to be operators, rather than strictly policy oriented.=0A= =0A= An estimate of attendance was requested by the Secretariat. About two doze= n people in the room indicated an interest in attending. =0A= =0A= All decisions must be confirmed on the list, so I ask for confirmation of t= he meeting decision in favor of this meeting.=0A= =0A= --Sandy, speaking as wg co-chair= From kent@bbn.com Thu Aug 2 16:51:08 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3260211E8131 for ; Thu, 2 Aug 2012 16:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.508 X-Spam-Level: X-Spam-Status: No, score=-106.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EoaN1M6befdo for ; Thu, 2 Aug 2012 16:51:07 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3C111E8087 for ; Thu, 2 Aug 2012 16:51:07 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:55536 helo=dhcp-15b7.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Sx5AW-000Ept-Da for sidr@ietf.org; Thu, 02 Aug 2012 19:51:04 -0400 Message-ID: <501B1267.3080606@bbn.com> Date: Thu, 02 Aug 2012 19:51:03 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: sidr@ietf.org References: <20120731172745.2797.51500.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] I-D Action: draft-ietf-sidr-origin-ops-18.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 23:51:08 -0000 Randy, I would like to add some more text, based on discussions with RP software developers, e.g., Rob and Andrew, and an analysis of a couple of SIDR RFCs RFC 6486 (TAL) states that no manifest will enumerate the self-signed certificate representing a trust anchor. RFC 6487 (Repository Structure) says that every signed object at a publication point is enumerated in the manifest published for a publication point. Thus the self-signed certificate representing a trust anchor MUST NOT be stored in a repository publication point. It is stored in a file independent of repository publication points, and pointed to by the URI in the TAL. This file may be stored on the same server(s) that are used to store repository publication points. Steve From randy@psg.com Thu Aug 2 22:20:38 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4C4211E809C for ; Thu, 2 Aug 2012 22:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8cG+7RjAR7A for ; Thu, 2 Aug 2012 22:20:37 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 72F3C11E809B for ; Thu, 2 Aug 2012 22:20:37 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SxAJQ-0008Ya-OB; Fri, 03 Aug 2012 05:20:37 +0000 Date: Thu, 02 Aug 2012 22:20:36 -0700 Message-ID: From: Randy Bush To: "Murphy, Sandra" In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F369D5@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F369D5@Hermes.columbia.ads.sparta.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "sidr@ietf.org" Subject: Re: [sidr] sidr participation in the LIM scheduled for 29 Sep in Amsterday X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 05:20:38 -0000 > All decisions must be confirmed on the list, so I ask for confirmation > of the meeting decision in favor of this meeting. yes, sigh From christopher.morrow@gmail.com Thu Aug 2 23:01:14 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF9521F8CC5 for ; Thu, 2 Aug 2012 23:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUERdUlKsRL4 for ; Thu, 2 Aug 2012 23:01:14 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA8C21F8CC3 for ; Thu, 2 Aug 2012 23:01:14 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so366535vbb.31 for ; Thu, 02 Aug 2012 23:01:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=HxdMafP6Firc9kjVHl7QfdQ4pp2rATNYZ1FEltQ4cM8=; b=vcpR8Jtd2Xv6BSv9frJOKv0vVzzL8CqKnJ1fym0494uuhrfYZ1h9Fi3QG26gTrF+eT gMPtRslSnZPOuFWdlgXWfJHxkeeb98lmw81ypLT2WDvpwlKEwCWeovYId/0Uxrg83Vb1 GgUEmYwpS/FJLp19FI/N5NpkpxtXUmrLEF/6SpMtDc4ehTZvsVyQOf8QFtYj90XLeDt0 GfU1AEHoqUwdxPQmXuNu3z9D6uDeqj3S8sh2kVgEjFky/DnWPLPS0jPMKVTe62CMyFD9 MHEL11qX+RuyPJ9YcgMtLDwtnp5/3UPNRCed+44AgcdM9oEPA6bfa2n3qdFgoai+Sq7G mK1A== MIME-Version: 1.0 Received: by 10.220.223.201 with SMTP id il9mr380998vcb.64.1343973673768; Thu, 02 Aug 2012 23:01:13 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.58.86.68 with HTTP; Thu, 2 Aug 2012 23:01:13 -0700 (PDT) In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F625F369D5@Hermes.columbia.ads.sparta.com> Date: Fri, 3 Aug 2012 02:01:13 -0400 X-Google-Sender-Auth: hwxCge5LGaLyFrWRTMD4PXgfSko Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] sidr participation in the LIM scheduled for 29 Sep in Amsterday X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 06:01:15 -0000 On Fri, Aug 3, 2012 at 1:20 AM, Randy Bush wrote: >> All decisions must be confirmed on the list, so I ask for confirmation >> of the meeting decision in favor of this meeting. > > yes, sigh also yes. From kent@bbn.com Fri Aug 3 06:44:23 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE8521F8D65 for ; Fri, 3 Aug 2012 06:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.511 X-Spam-Level: X-Spam-Status: No, score=-106.511 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgJV63QppNNV for ; Fri, 3 Aug 2012 06:44:23 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2312E21F8CB6 for ; Fri, 3 Aug 2012 06:44:23 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:43074 helo=COMSEC.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SxIAv-000Aps-OC for sidr@ietf.org; Fri, 03 Aug 2012 09:44:21 -0400 Message-ID: <501BD5B5.2090403@bbn.com> Date: Fri, 03 Aug 2012 09:44:21 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: sidr Content-Type: multipart/alternative; boundary="------------040106060507080108010100" Subject: Re: [sidr] sidr participation in the LIM scheduled for 29 Sep in Amsterday X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 13:44:23 -0000 This is a multi-part message in MIME format. --------------040106060507080108010100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All decisions must be confirmed on the list, so I ask for confirmation of the meeting decision in favor of this meeting. in favor, Steve --------------040106060507080108010100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
All decisions must be confirmed on the list, so I ask for confirmation
of the meeting decision in favor of this meeting.

in favor,

Steve
--------------040106060507080108010100-- From sra@hactrn.net Fri Aug 3 08:54:10 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6672221F8E35 for ; Fri, 3 Aug 2012 08:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0Y4XZ1P5AU5 for ; Fri, 3 Aug 2012 08:54:10 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [66.92.66.68]) by ietfa.amsl.com (Postfix) with ESMTP id AD7B921F8E34 for ; Fri, 3 Aug 2012 08:54:09 -0700 (PDT) Received: from minas-ithil.hactrn.net (dhcp-45b5.meeting.ietf.org [130.129.69.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id BEBAD9B441; Fri, 3 Aug 2012 15:54:05 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [127.0.0.1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id D8D56780CE4; Fri, 3 Aug 2012 08:54:02 -0700 (PDT) Date: Fri, 03 Aug 2012 08:54:02 -0700 From: Rob Austein To: "Murphy, Sandra" In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F369D5@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F369D5@Hermes.columbia.ads.sparta.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20120803155402.D8D56780CE4@minas-ithil.hactrn.net> Cc: "sidr@ietf.org" Subject: Re: [sidr] sidr participation in the LIM scheduled for 29 Sep in Amsterday X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 15:54:10 -0000 At Thu, 2 Aug 2012 20:23:10 +0000, Murphy, Sandra wrote: > > In the SIDR meeting, the interim meeting proposed for Sep was discussed. > The IETF plans are now to hold the meeting on Sat 29 Sep (the Sat after RIPE). > All decisions must be confirmed on the list, so I ask for confirmation of the meeting decision in favor of this meeting. Aye From tim@ripe.net Fri Aug 3 09:20:31 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F70721F8D5F for ; Fri, 3 Aug 2012 09:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOAZ2NM499Bl for ; Fri, 3 Aug 2012 09:20:30 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 6604221F8D50 for ; Fri, 3 Aug 2012 09:20:30 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SxKbz-0000pD-06; Fri, 03 Aug 2012 18:20:28 +0200 Received: from s258-sslvpn-1.ripe.net ([193.0.20.231] helo=vpn-61.ripe.net) by dodo.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1SxKby-0004zv-4i; Fri, 03 Aug 2012 18:20:26 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tim Bruijnzeels In-Reply-To: <501B1267.3080606@bbn.com> Date: Fri, 3 Aug 2012 09:20:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4ABFEC5F-782F-471D-88E8-AE101BEF067A@ripe.net> References: <20120731172745.2797.51500.idtracker@ietfa.amsl.com> <501B1267.3080606@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1084) X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20120803 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a071980e6640d021f214449dd0207d079cd70 Cc: sidr@ietf.org Subject: Re: [sidr] I-D Action: draft-ietf-sidr-origin-ops-18.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 16:20:31 -0000 Hi Steve, On 2 Aug 2012, at 16:51, Stephen Kent wrote: > Randy, >=20 > I would like to add some more text, based on discussions with RP = software developers, > e.g., Rob and Andrew, and an analysis of a couple of SIDR RFCs >=20 > RFC 6486 (TAL) states that no manifest will enumerate the self-signed = certificate > representing a trust anchor. I think I missed this one. Can you explain why this is? I understand that we have the subjectPublicKeyInfo to verify that the = self-signed cert has possession of the self signed key pertaining to = this public key that we trust. However the setup where we re-fetch this actual certificate was intended = to allow that the contents of this certificate could be updated in = particular wrt the resource extensions. If we have it on a manifest as = well that will actually give RPs the opportunity to verify that they see = a 'current' version of this cert and not an old one that is being = replayed to them. So in short: I don't understand why it 'MUST' *not* be on the manifest. = There is no normative MUST in the text of TAL (6490). And I think there = is a actually a better case for including it on the manifest.. > RFC 6487 (Repository Structure) says that every signed > object at a publication point is enumerated in the manifest published = for a > publication point. Thus the self-signed certificate representing a = trust anchor MUST NOT > be stored in a repository publication point. It is stored in a file = independent of > repository publication points, and pointed to by the URI in the TAL. = This file may be > stored on the same server(s) that are used to store repository = publication points. >=20 I take it that this is in your view(s) a logical consequence of the = first part of your mail? In other words if there is no MUST not be on manifest, and it actually = *is* on the manifest it can be in this publication point. Tim= From randy@psg.com Fri Aug 3 11:13:33 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9EA21F8E05 for ; Fri, 3 Aug 2012 11:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AISkrVZ8HX4h for ; Fri, 3 Aug 2012 11:13:33 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 028B721F8E01 for ; Fri, 3 Aug 2012 11:13:33 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SxMNO-0009wq-Qf; Fri, 03 Aug 2012 18:13:31 +0000 Date: Fri, 03 Aug 2012 11:13:30 -0700 Message-ID: From: Randy Bush To: "Murphy, Sandra" In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F369D5@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F369D5@Hermes.columbia.ads.sparta.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "sidr@ietf.org" Subject: Re: [sidr] sidr participation in the LIM scheduled for 29 Sep in Amsterday X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 18:13:33 -0000 > All decisions must be confirmed on the list was the decision that all decisions be confirmed on the list confirmed on the list? From christopher.morrow@gmail.com Fri Aug 3 11:22:19 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACB9721F8E30 for ; Fri, 3 Aug 2012 11:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYjWVH0m0j3O for ; Fri, 3 Aug 2012 11:22:18 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2164721F8E32 for ; Fri, 3 Aug 2012 11:22:18 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1134866vbb.31 for ; Fri, 03 Aug 2012 11:22:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=xeyJ3zg+XfvRnwRkz3jNXsfwnbBgrP5LuPi5XMrHPo0=; b=KdZnNdRGCUITaji7s3oUwQU4EwJFRZsLANYXWPHaoclznyBl+rahyoJfTFCUSfL971 IW7FHeDSgd38bL75JsQVUg24zUAqfY0zOX8OnoWajc9eTgMizFyy2XlYin23W0YBWGV9 I9viMeK6mBwn27iti1bgCv9ti7gNsb6DJ4C/dTGdUm6TLoLN1loeD3aTjl0fxUm4VQ+O N5icKVJSeIfJ2QYaaI28di1jsimUHMFP3EtDYoM76TUWpLkIkQoACQ8Fxzz3rdU6Vyz9 9Jb5jfNw1wTFA3Mpl78BeNS5gzVaALHl+5VKgQCnKrDPQZOfXShPmhJBcduoBRywGs9U tvfg== MIME-Version: 1.0 Received: by 10.58.151.197 with SMTP id us5mr2392174veb.14.1344018137461; Fri, 03 Aug 2012 11:22:17 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.58.86.68 with HTTP; Fri, 3 Aug 2012 11:22:17 -0700 (PDT) In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F625F369D5@Hermes.columbia.ads.sparta.com> Date: Fri, 3 Aug 2012 14:22:17 -0400 X-Google-Sender-Auth: uUPnTCIWlPNKsiJvxdZ4yv4KOYE Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] sidr participation in the LIM scheduled for 29 Sep in Amsterday X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 18:22:19 -0000 On Fri, Aug 3, 2012 at 2:13 PM, Randy Bush wrote: >> All decisions must be confirmed on the list > > was the decision that all decisions be confirmed on the list confirmed > on the list? +elliot I think it was confirmed on the IETF list... does it have to also happen here? From randy@psg.com Fri Aug 3 11:39:05 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2566021E804A for ; Fri, 3 Aug 2012 11:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTH26Su8Vr9y for ; Fri, 3 Aug 2012 11:39:04 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id CA59D21E8049 for ; Fri, 3 Aug 2012 11:39:04 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SxMm5-000A0T-UK; Fri, 03 Aug 2012 18:39:02 +0000 Date: Fri, 03 Aug 2012 11:39:01 -0700 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F625F369D5@Hermes.columbia.ads.sparta.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] sidr participation in the LIM scheduled for 29 Sep in Amsterday X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 18:39:05 -0000 >>> All decisions must be confirmed on the list >> was the decision that all decisions be confirmed on the list confirmed >> on the list? > +elliot > I think it was confirmed on the IETF list... does it have to also > happen here? we should probably schedule a meeting to decide if it needs to be confirmed here on the sidr list. From trac@tools.ietf.org Fri Aug 3 11:42:05 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 661D521E804A for ; Fri, 3 Aug 2012 11:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.304 X-Spam-Level: X-Spam-Status: No, score=-101.304 tagged_above=-999 required=5 tests=[AWL=1.295, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4JgK3jGjqDR for ; Fri, 3 Aug 2012 11:42:04 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6C421E8049 for ; Fri, 3 Aug 2012 11:42:04 -0700 (PDT) Received: from localhost ([127.0.0.1]:60573 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SxMop-0004ps-M5; Fri, 03 Aug 2012 20:41:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "sidr issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: sandy@tislabs.com X-Trac-Project: sidr Date: Fri, 03 Aug 2012 18:41:51 -0000 X-URL: http://tools.ietf.org/sidr/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sidr/trac/ticket/9#comment:1 Message-ID: <067.9c9ab344efef9387aae9e96eaa60a0b0@tools.ietf.org> References: <052.ca9ad92ff2f02764f9981b0f526eafac@tools.ietf.org> X-Trac-Ticket-ID: 9 In-Reply-To: <052.ca9ad92ff2f02764f9981b0f526eafac@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: sandy@tislabs.com, sidr@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: sidr@ietf.org Subject: Re: [sidr] #9: TA nits X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 18:42:05 -0000 #9: TA nits Changes (by sandy@…): * status: new => closed * resolution: => invalid Comment: OBE - ancient history, does not apply to current TAL -- --------------------------------+---------------------- Reporter: gih@… | Owner: Type: defect | Status: closed Priority: medium | Milestone: Component: ta | Version: Severity: Active WG Document | Resolution: invalid Keywords: | --------------------------------+---------------------- Ticket URL: sidr From bje@apnic.net Fri Aug 3 11:43:41 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6154A21E8064 for ; Fri, 3 Aug 2012 11:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.192 X-Spam-Level: X-Spam-Status: No, score=-1.192 tagged_above=-999 required=5 tests=[AWL=-1.108, BAYES_00=-2.599, HELO_EQ_IP_ADDR=1.119, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gF8x5BhYCtMa for ; Fri, 3 Aug 2012 11:43:36 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 3E87B21E805F for ; Fri, 3 Aug 2012 11:43:36 -0700 (PDT) Received: from [130.129.50.92] (dhcp-325c.meeting.ietf.org [130.129.50.92]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id D3706B66BF; Sat, 4 Aug 2012 04:43:33 +1000 (EST) References: <24B20D14B2CD29478C8D5D6E9CBB29F625F369D5@Hermes.columbia.ads.sparta.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9B206) From: Byron Ellacott Date: Fri, 3 Aug 2012 11:43:24 -0700 To: Randy Bush Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] sidr participation in the LIM scheduled for 29 Sep in Amsterday X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 18:43:41 -0000 On 03/08/2012, at 11:39 AM, Randy Bush wrote: >>>> All decisions must be confirmed on the list >>> was the decision that all decisions be confirmed on the list confirmed >>> on the list? >> +elliot >> I think it was confirmed on the IETF list... does it have to also >> happen here? >=20 > we should probably schedule a meeting to decide if it needs to be > confirmed here on the sidr list. Shall we confirm on the list that we did not need to confirm on the list tha= t we need to confirm things on the list? That seems the simplest way forwar= d from here. Byron --=20 The contents of this mail have not been confirmed by any list and must be tr= eated as speculative. If you have confirmed this mail by accident, please d= estroy all copies immediately.= From Sandra.Murphy@sparta.com Fri Aug 3 11:46:30 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC4321F8E3D for ; Fri, 3 Aug 2012 11:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hX8jCZ29mwDp for ; Fri, 3 Aug 2012 11:46:30 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8761921E808D for ; Fri, 3 Aug 2012 11:46:29 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q73IkSiF014147 for ; Fri, 3 Aug 2012 13:46:28 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q73IkSx3031710 for ; Fri, 3 Aug 2012 13:46:28 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%21]) with mapi id 14.01.0355.002; Fri, 3 Aug 2012 14:46:34 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: issue tracker cleanup Thread-Index: Ac1xqE2T71fvsQwoRFe2fe0RXgVb/Q== Date: Fri, 3 Aug 2012 18:46:33 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F4FCE3@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] issue tracker cleanup X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 18:46:30 -0000 I am trying to clean up the issue tracker removing old, ancient, OBE, issue= s.=0A= =0A= Unfortunately, by the test just performed, the result will be a message to = the sidr mailing list for each one. I will try to get the trac instance re= configured to fix that.=0A= =0A= Sorry about that folks.f=0A= =0A= --Sandy= From randy@psg.com Fri Aug 3 11:48:48 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7B621E8085 for ; Fri, 3 Aug 2012 11:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNCTbIuZxDv0 for ; Fri, 3 Aug 2012 11:48:47 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 8F01A21E8084 for ; Fri, 3 Aug 2012 11:48:47 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SxMvW-000A2u-Vp; Fri, 03 Aug 2012 18:48:47 +0000 Date: Fri, 03 Aug 2012 11:48:46 -0700 Message-ID: From: Randy Bush To: "Murphy, Sandra" In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F4FCE3@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F4FCE3@Hermes.columbia.ads.sparta.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "sidr@ietf.org" Subject: Re: [sidr] issue tracker cleanup X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 18:48:48 -0000 > I am trying to clean up the issue tracker removing old, ancient, OBE, > issues. > > Unfortunately, by the test just performed, the result will be a > message to the sidr mailing list for each one. I will try to get the > trac instance reconfigured to fix that. clearly, in the spirit of the day, that is an issue that should be entered into the tracker :) randy From kotikalapudi.sriram@nist.gov Fri Aug 3 11:52:59 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFF721F8DBA for ; Fri, 3 Aug 2012 11:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKxoxd8bd-2B for ; Fri, 3 Aug 2012 11:52:47 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC0521F8D9D for ; Fri, 3 Aug 2012 11:52:47 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 3 Aug 2012 14:52:31 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Fri, 3 Aug 2012 14:51:37 -0400 From: "Sriram, Kotikalapudi" To: "John G. Scudder" , sidr wg list Date: Fri, 3 Aug 2012 14:51:37 -0400 Thread-Topic: [sidr] bgpsec confeds bug, with fix Thread-Index: Ac1wRJo+lR1041XlRSy2db4QUFfxGQBSTgYn Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] bgpsec confeds bug, with fix X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 18:52:59 -0000 I don't think there is a bug. It seems to me that the solution as written now does indeed work if it can = be assumed=20 that every border router within a confed knows which peers are confed-EBGP peers and which peers are regular (external to confed) EBGP= peers. That seems to be a necessary assumption anyway.=20 (The modifications you propose also assume this.) Let us consider this example: ----(B1----B2)----(B3----B4)----(B5----B6)----> ---------AS1------------AS2------------AS3--------> where AS1, AS2 and AS3 form a confed, and the update is propagating from left to right; AS1 is the entry AS; B1, B2 are border routers in AS1; B3, B4 are border routers in AS2; B5, B6 are border routers in AS3. When B1 gets an update, it propagates it to B2 without adding a new signatu= re. B2 looks at the signatures backwards starting from the most recently added = AS. If the confed-entry flag is not set by any preceding AS (as expected at B2 = in this example),=20 then B2 sets the flag, adds AS1=92s signature and forwards the update to B3= . B3 propagates the update to B4 (w/o adding a new signature). B4 does the same check as B2 did. B4 finds a flag already set (by AS1).=20 So B4 simply adds AS2=92s signature and propagates to B5. =20 B6 happily strips all the confed internal signatures when it propagates the update to a regular (external to confed) EBGP peer. One special case is when the prefix is originated from within AS1 by B1. It seems that this case can be handled easily enough as well.=20 B1 originates and sends the update without any Signature-list Block to B2. B2 sees no prior confed-entry flag, so it sets the flag, signs and propagat= es=20 the prefix update to B3. =20 So it all works correctly! Right? Please let me know if I am missing something. Thanks. Sriram ________________________________________ From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] On Behalf Of John G. Sc= udder [jgs@juniper.net] Sent: Wednesday, Aonfeds bug, with fix Randy, Sandy and I realized there is a problem with confeds. As written rig= ht now, the entering-the-confed marker is applied by the first router sendi= ng the route across an internal-to-the-confed boundary (let's call this rou= ter R). It can't be applied by the external peer router sending it to the c= onfed in EBGP, since it has no clue (that's the nature of a confed), and it= can't be applied by the border router within the confed (called router B) = that's receiving it from that external peer, since it doesn't apply a signa= ture (we only do that when sending routes across EBGP, or confed-EBGP). So, how does router R figure out it should apply the marker? In short, it c= an't. After discussing a few possible solutions, we came up with two altern= atives: Have router B do the AS aliasing hack, i.e. sign to itself with pcount=3D0,= and apply the mark on that signature. Equivalently, we could invent some new thing to go into the signatures that= has the semantics of "this is a confed entry marker". ugust 01, 2012 8:18 PM To: sidr wg list Subject: [sidr] bgpsec c --John From jgs@juniper.net Fri Aug 3 12:16:02 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3910021F8D87 for ; Fri, 3 Aug 2012 12:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.802 X-Spam-Level: X-Spam-Status: No, score=-5.802 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBUuAh1+XGpJ for ; Fri, 3 Aug 2012 12:16:01 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id C68CD21F8D7B for ; Fri, 3 Aug 2012 12:15:58 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUBwjbndlkSs3ZLy0/cI9BqCjbkRW81wT@postini.com; Fri, 03 Aug 2012 12:16:01 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 3 Aug 2012 12:13:08 -0700 Received: from [172.19.168.15] ([172.19.168.15]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q73JD4h62828; Fri, 3 Aug 2012 12:13:04 -0700 (PDT) (envelope-from jgs@juniper.net) References: In-Reply-To: MIME-Version: 1.0 (1.0) Content-Type: text/plain; charset="utf-8" Message-ID: Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (9B206) From: "John G. Scudder" Date: Fri, 3 Aug 2012 14:12:55 -0500 To: "Sriram, Kotikalapudi" Cc: sidr wg list Subject: Re: [sidr] bgpsec confeds bug, with fix X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 19:16:02 -0000 On Aug 3, 2012, at 1:51 PM, "Sriram, Kotikalapudi" wrote: > Let us consider this example: >=20 > ----(B1----B2)----(B3----B4)----(B5----B6)----> >=20 > ---------AS1------------AS2------------AS3--------> >=20 > where AS1, AS2 and AS3 form a confed, and > the update is propagating from left to right; > AS1 is the entry AS; > B1, B2 are border routers in AS1; > B3, B4 are border routers in AS2; > B5, B6 are border routers in AS3. >=20 > When B1 gets an update, it propagates it to B2 without adding a new signat= ure. > B2 looks at the signatures backwards starting from the most recently added= AS. > If the confed-entry flag is not set by any preceding AS (as expected at B2= in this example),=20 > then B2 sets the flag, adds AS1=E2=80=99s signature and forwards the updat= e to B3. How is B2 supposed to know that the preceding ASes in the path aren't confed= members? I.e., how is it supposed to know it is in charge of setting the fl= ag? B1 knows this by configuration, but B2 doesn't.=20 One other option does occur to me however, and I'm not sure why I didn't thi= nk of it before: for *every* crossing of a confederation member border, set t= he flag, so it has the semantics of "this is a confederation hop" rather tha= n the current "entering a confederation" semantics. Then on exit, strip all c= ontiguous flagged hops. This is predicated on the observation that it's hard= for a router to know if its member AS was the confederation entry point, bu= t trivial to know it's sending the route to another member AS.=20 --John= From jgs@juniper.net Fri Aug 3 12:30:08 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B99D21E804E for ; Fri, 3 Aug 2012 12:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.787 X-Spam-Level: X-Spam-Status: No, score=-5.787 tagged_above=-999 required=5 tests=[AWL=-0.584, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2RxtygLFo13 for ; Fri, 3 Aug 2012 12:30:07 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 5614A21E804C for ; Fri, 3 Aug 2012 12:30:07 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKUBwmuxtB0lISARNU20sLNijix9l/iQFg@postini.com; Fri, 03 Aug 2012 12:30:07 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 3 Aug 2012 12:29:32 -0700 Received: from [172.19.168.15] ([172.19.168.15]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q73JTTh83718; Fri, 3 Aug 2012 12:29:29 -0700 (PDT) (envelope-from jgs@juniper.net) References: In-Reply-To: MIME-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Message-ID: <35EA3914-7C13-419E-9F04-1EEC10765426@juniper.net> X-Mailer: iPhone Mail (9B206) From: "John G. Scudder" Date: Fri, 3 Aug 2012 14:27:26 -0500 To: "John G. Scudder" Cc: "Sriram, Kotikalapudi" , sidr wg list Subject: Re: [sidr] bgpsec confeds bug, with fix X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 19:30:08 -0000 On Aug 3, 2012, at 2:12 PM, "John G. Scudder" wrote: > One other option does occur to me however, and I'm not sure why I didn't t= hink of it before: for *every* crossing of a confederation member border, se= t the flag, so it has the semantics of "this is a confederation hop" rather t= han the current "entering a confederation" semantics. Then on exit, strip al= l contiguous flagged hops. P. S. I prefer this to either of the other two suggestions I sent. It's less= hacky than the pcount=3D0 option and more faithfully mimics the semantics o= f AS_CONFED_SEQ.=20 --John= From randy@psg.com Fri Aug 3 12:34:12 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 369E211E80D7 for ; Fri, 3 Aug 2012 12:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Fb7HkQJ5P89 for ; Fri, 3 Aug 2012 12:34:11 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 52C3421E804E for ; Fri, 3 Aug 2012 12:34:11 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SxNdM-000ABq-1T; Fri, 03 Aug 2012 19:34:04 +0000 Date: Fri, 03 Aug 2012 12:34:03 -0700 Message-ID: From: Randy Bush To: "John G. Scudder" In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] bgpsec confeds bug, with fix X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 19:34:12 -0000 > One other option does occur to me however, and I'm not sure why I > didn't think of it before: for *every* crossing of a confederation > member border, set the flag, so it has the semantics of "this is a > confederation hop" rather than the current "entering a confederation" > semantics. Then on exit, strip all contiguous flagged hops. This is > predicated on the observation that it's hard for a router to know if > its member AS was the confederation entry point, but trivial to know > it's sending the route to another member AS. i think this works randy From kotikalapudi.sriram@nist.gov Fri Aug 3 13:30:00 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0484621E804A for ; Fri, 3 Aug 2012 13:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDFG8TZLixVL for ; Fri, 3 Aug 2012 13:29:59 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 33C7021E8049 for ; Fri, 3 Aug 2012 13:29:59 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 3 Aug 2012 16:29:43 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 3 Aug 2012 16:29:58 -0400 From: "Sriram, Kotikalapudi" To: "John G. Scudder" Date: Fri, 3 Aug 2012 16:28:51 -0400 Thread-Topic: [sidr] bgpsec confeds bug, with fix Thread-Index: Ac1xrEayD8FA1xwATGKNBx4lUMkjrAABuqxJ Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] bgpsec confeds bug, with fix X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 20:30:00 -0000 John, Thanks. I think we have converged on this -- yes, I have seen your latest e= mail also. Your newer suggestion is a slight variant of my suggestion but the basic principle is the same, namely, the semantic of the flag is changed to "this is a confed EBGP hop" or "signing update to a confed EBGP peer".=20 That is the same semantic that I was essentially using. Please see additional comments below (response to your questions/comments). Sriram > On Aug 3, 2012, at 1:51 PM, "Sriram, Kotikalapudi" wrote: > >> Let us consider this example: >> >> ----(B1----B2)----(B3----B4)----(B5----B6)----> >> >> ---------AS1------------AS2------------AS3--------> >> >> where AS1, AS2 and AS3 form a confed, and >> the update is propagating from left to right; >> AS1 is the entry AS; >> B1, B2 are border routers in AS1; >> B3, B4 are border routers in AS2; >> B5, B6 are border routers in AS3. >> >> When B1 gets an update, it propagates it to B2 without adding a new sign= ature. >> B2 looks at the signatures backwards starting from the most recently add= ed AS. >> If the confed-entry flag is not set by any preceding AS (as expected at = B2 in this example), >> then B2 sets the flag, adds AS1=92s signature and forwards the update to= B3. > > How is B2 supposed to know that the preceding ASes in the path aren't con= fed members? I.e., how is it supposed to know it is in charge of setting th= e flag? B1 knows this by configuration, but B2 doesn't. In the method I was suggesting, all border routers within a confed (i.e., B= 1, B2, =85, B6)=20 are configured to set the flag if they are forwarding the update to a confe= d-EBGP peer,=20 except when they see that a flag was already set by one of the preceding AS= es. This is a slightly different but similar semantics of "this is a confederat= ion hop" that you=20 are suggesting below. So we are converging to basically the same idea as I note below. > > One other option does occur to me however, and I'm not sure why I didn't = think of it before: for *every* crossing of a confederation member border, = set the flag, so it has the semantics of "this is a confederation hop" rath= er than the current "entering a confederation" semantics. Then on exit, str= ip all contiguous flagged hops. This is predicated on the observation that = it's hard for a router to know if its member AS was the confederation entry= point, but trivial to know it's sending the route to another member AS. Yes, I like this. In my proposal, a border router does not set a flag if a = one was already set by a preceding AS. That limits it to indicating only the entry AS in the confe= d. But I think your extension of that idea is better. That is, remove the condition and let each of the b= order routers always=20 set the flag if forwarding the update to a confed-EBGP peer.=20 Let there be multiple contiguous flags. Thanks! Sriram > > --John= From ejkern@gmail.com Fri Aug 3 19:25:52 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F3221F8D93 for ; Fri, 3 Aug 2012 19:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjAz7SH1JZVA for ; Fri, 3 Aug 2012 19:25:51 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id CC9B721F8D8F for ; Fri, 3 Aug 2012 19:25:51 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so454397pbb.31 for ; Fri, 03 Aug 2012 19:25:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Io84K0LJoQVwOyORVhEdt696BnNdCK+MuMZNzS4DaaM=; b=IS6jS/5ABKvNY0Ba6Yj4vdqCtayXtfXyXRbq7TLG/oMh8WMYOV1WACUE5FL3xZ8Jfp DFzyVhRkl9Y6AQSxD3q4cTi0OOD7+wjd+QEKwhwPOM3+yjqBDifHs0VeEfvpNFdfC+/2 KYf0t1eb1Y/3bgGWX6f23XH4ZTn38nIRteLQVue0xairqKRkU3k30qr0jbSG4O41VmBL yBX8pKJDYzD4V16FHkjhe2KZEQP3xkGLgJzDoHrBAx6TpVTEkeJ7QLIdWQMO4vEfcr1D ty2n+BKRD1C1CsdWnl3b2FI6sxp2e6PPUora1Q5QQik526gyM+xnpgFzi5rGa4IP+Qas kemw== Received: by 10.66.77.169 with SMTP id t9mr2645076paw.70.1344047151442; Fri, 03 Aug 2012 19:25:51 -0700 (PDT) Received: from [192.168.1.38] (72-160-62-50.dyn.centurytel.net. [72.160.62.50]) by mx.google.com with ESMTPS id se9sm4047027pbc.25.2012.08.03.19.25.45 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Aug 2012 19:25:50 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Ed Kern In-Reply-To: Date: Fri, 3 Aug 2012 18:54:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3C380790-9A92-4EB1-9E12-B81FF597A7AC@gmail.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F369D5@Hermes.columbia.ads.sparta.com> To: Randy Bush X-Mailer: Apple Mail (2.1485) Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] sidr participation in the LIM scheduled for 29 Sep in Amsterday X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2012 02:25:52 -0000 Ill be happy to host the webex for the meeting to decide if future = confirmations on the list are necessary. =20 Also support the meeting in september. Ed On Aug 3, 2012, at 11:39 AM, Randy Bush wrote: >>>> All decisions must be confirmed on the list >>> was the decision that all decisions be confirmed on the list = confirmed >>> on the list? >> +elliot >> I think it was confirmed on the IETF list... does it have to also >> happen here? >=20 > we should probably schedule a meeting to decide if it needs to be > confirmed here on the sidr list. > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From christopher.morrow@gmail.com Fri Aug 3 21:46:21 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E45AA21F87AE for ; Fri, 3 Aug 2012 21:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtXYGEhgYgFm for ; Fri, 3 Aug 2012 21:46:20 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4523821F87AD for ; Fri, 3 Aug 2012 21:46:20 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1542519vbb.31 for ; Fri, 03 Aug 2012 21:46:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=t4UqjTsIBjzWn2GYzApQipuMdXRBkeYSVarhM5N6ePc=; b=kuhzgJIU96P0IPO0RuVJ7tyEP+3me7tsTdDV87kW7ReMGMgZOFULufmKnOKp3tBo+a UxdnA4paPOj5yTDAaXgAQWCm+xAOpZgyn4fw98+S3djYymUKs2YNlKXV2PTHJJh3p6wb 9Ct94OBb/4fZuvPvHdf8bDNRSA02YFb8OV2ztUf1IHoJ/G7A+aJXl2VLMaTY5Owdq068 6c6VhLioIdbai36Ti9UM4lFWiefUskYlFxVGn1psE8k/mtNhe93TFsXwJ1DUwaJbZdYg Qn6kSB7k+HoK0BOyoweOhsgROyxHgJHjZO8lv+821QFT+eYAv/0N4/qsRIPtxgd3V9W9 +DJg== MIME-Version: 1.0 Received: by 10.220.116.11 with SMTP id k11mr2519729vcq.74.1344055579752; Fri, 03 Aug 2012 21:46:19 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.58.86.68 with HTTP; Fri, 3 Aug 2012 21:46:19 -0700 (PDT) In-Reply-To: <3C380790-9A92-4EB1-9E12-B81FF597A7AC@gmail.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F369D5@Hermes.columbia.ads.sparta.com> <3C380790-9A92-4EB1-9E12-B81FF597A7AC@gmail.com> Date: Sat, 4 Aug 2012 00:46:19 -0400 X-Google-Sender-Auth: Kdtce0YB3_MHahRuEf8QunZzol8 Message-ID: From: Christopher Morrow To: Ed Kern Content-Type: text/plain; charset=ISO-8859-1 Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] sidr participation in the LIM scheduled for 29 Sep in Amsterday X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2012 04:46:21 -0000 On Fri, Aug 3, 2012 at 9:54 PM, Ed Kern wrote: > Ill be happy to host the webex for the meeting to decide if future confirmations > on the list are necessary. I'm sorry, we certainly need to confirm on list the need for a webex, and of course for a meeting to talk about the meeting... I feel as if my head shape is changing... > Also support the meeting in september. > > Ed > > On Aug 3, 2012, at 11:39 AM, Randy Bush wrote: > >>>>> All decisions must be confirmed on the list >>>> was the decision that all decisions be confirmed on the list confirmed >>>> on the list? >>> +elliot >>> I think it was confirmed on the IETF list... does it have to also >>> happen here? >> >> we should probably schedule a meeting to decide if it needs to be >> confirmed here on the sidr list. >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > From alexey.melnikov@isode.com Sat Aug 4 11:12:37 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9272321F87D4 for ; Sat, 4 Aug 2012 11:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.202 X-Spam-Level: X-Spam-Status: No, score=-101.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsTFnjDWWN9A for ; Sat, 4 Aug 2012 11:12:36 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id A3C0D21F86DF for ; Sat, 4 Aug 2012 11:12:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1344104038; d=isode.com; s=selector; i=@isode.com; bh=u/AkbhtEGloR5rAqMR3i/9dl0UzbFoUtBJCqEwUB7T4=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=RxhB3YKz1XUm+YXy9FT07AbhAvqaNUUit1vLvvUymkz0CGEQ5yeHTaEa4ki3V7vmrBIGkK jPr+PJ50JTKmwzfT5d6jvuJCzDFtmPugvQyUsl8N0CNWgqMev33A7TWoZC0G4+QQCQ7Cpb iMM9LYfUe3rr4rFZ8CSe+FYjrNEMuXU=; Received: from [10.255.255.196] (s142-179-107-97.bc.hsia.telus.net [142.179.107.97]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 4 Aug 2012 19:13:58 +0100 From: Alexey Melnikov X-Mailer: iPad Mail (9B206) Message-Id: Date: Sat, 4 Aug 2012 11:12:45 -0700 To: "sidr@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Apple-Mail-4E93652C-5D43-4DE6-8539-4AB27F8E7765 Content-Transfer-Encoding: 7bit Subject: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2012 18:12:37 -0000 --Apple-Mail-4E93652C-5D43-4DE6-8539-4AB27F8E7765 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On behalf of SIDR WG chairs I would like to initiate 2 weeks acceptance call= for draft-ymbk-rpki-grandparenting starting from today, August 4th. Please s= end your positive or negative feedback to the mailing list or directly to ch= airs. Thank you, Alexey --Apple-Mail-4E93652C-5D43-4DE6-8539-4AB27F8E7765 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,
On behalf of SIDR W= G chairs I would like to initiate 2 weeks acceptance call for draft-ymbk-rpki-grandp= arenting starting from today, August 4th. Please send your positiv= e or negative feedback to the mailing list or directly to chairs.

Thank you,
Alexey

= --Apple-Mail-4E93652C-5D43-4DE6-8539-4AB27F8E7765-- From bje@apnic.net Sun Aug 5 18:25:22 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A1921F84A5 for ; Sun, 5 Aug 2012 18:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJoUeLU8rTBy for ; Sun, 5 Aug 2012 18:25:22 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id AD97B21F84FD for ; Sun, 5 Aug 2012 18:25:20 -0700 (PDT) Received: from [IPv6:2001:dc0:a000:4:1997:f74d:aac1:1b0] (unknown [IPv6:2001:dc0:a000:4:1997:f74d:aac1:1b0]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id D9819B67EA; Mon, 6 Aug 2012 11:25:16 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_60B527D8-1555-4B42-9D40-27FC950C616F"; protocol="application/pkcs7-signature"; micalg=sha1 From: Byron Ellacott In-Reply-To: Date: Mon, 6 Aug 2012 11:25:16 +1000 Message-Id: References: To: Alexey Melnikov X-Mailer: Apple Mail (2.1278) Cc: "sidr@ietf.org" Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 01:25:22 -0000 --Apple-Mail=_60B527D8-1555-4B42-9D40-27FC950C616F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Alexey and list, I oppose this acceptance call. The draft makes no reference to the = conflict with the CP draft (6484) [1] with respect to the requirement = that certificates issued by a CA conform to the record of current = holdings. If a grandchild is not listed in the record of current = holdings, a 6484 compliant CA must not issue certificates in their name; = if the grandchild is listed the record of current holdings, then they = are no longer a grandchild, and there is no need for a grandparenting = process. Byron [1] http://tools.ietf.org/html/rfc6484 sections 1.1, 1.4, and 4.2.2. On 05/08/2012, at 4:12 AM, Alexey Melnikov wrote: > Hi, > On behalf of SIDR WG chairs I would like to initiate 2 weeks = acceptance call for draft-ymbk-rpki-grandparenting starting from today, = August 4th. Please send your positive or negative feedback to the = mailing list or directly to chairs. >=20 > Thank you, > Alexey >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_60B527D8-1555-4B42-9D40-27FC950C616F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEBjCCBAIw ggLqoAMCAQICCCoPITf60ZNDMA0GCSqGSIb3DQEBBQUAMHMxETAPBgNVBAMMCHN0YWZmLWNhMRIw EAYDVQQLDAlUZWNobmljYWwxFjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNi YW5lMRIwEAYKCZImiZPyLGQBGRYCY2ExCzAJBgNVBAYTAkFVMB4XDTExMTEyODAxNTEzNloXDTEy MTEyNzAxNTEzNlowgZIxGTAXBgoJkiaJk/IsZAEBDAliamUtc3RhZmYxEjAQBgNVBAMMCWJqZS1z dGFmZjEOMAwGA1UEKgwFQnlyb24xETAPBgNVBAQMCEVsbGFjb3R0MQ8wDQYDVQQLDAZQZW9wbGUx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxFTATBgoJkiaJk/IsZAEZFgVzdGFmZjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBANVQo/BOmY5CCWNeAldlgoWZKOzIZpOsFzD6NB2oAErtclDu uiZsXfl+L97UOwUlhu1eGlY5gKuAhGcrEBvDgTT1eEr3vkdKILhJw78s5n8eLOWrmhPKBnW8gSn9 7MbAxVQx3V1/RpToKAF8cR4il03Z7mveaBQbaivM2jReHcgfJPt9w0qhTVZO2POLuVClRcExaNt1 h+QdMLa6VU5x7rJo9JFqjTAvJzMApW+WY/7oumR9+4a9ZGThlETI2b83XAMrrJ7DHm237Jskgl+X FGILIq8zOhNiAbhEg+gAyJ8bOzwwydDY+ggWQ466duZZq4wxmr1+YhxVf51v2R5MSicCAwEAAaN6 MHgwHQYDVR0OBBYEFIQXSivz3cLpaFy23DdhpGhyyo5pMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgw FoAU4D23klvuLqOyPnnbRaswQi8BS6wwDgYDVR0PAQH/BAQDAgHyMBgGA1UdEQQRMA+BDWJqZUBh cG5pYy5uZXQwDQYJKoZIhvcNAQEFBQADggEBAEk9zi8BTUEY4rqDGEIFDNIpmX/yS3fTah39Mele pV93sRsjqLy2G47vhhnkgSTEWV2jJOD7tjzjswxtWUL6KG36dUDVL3XbQ1OObxkiDJbqje4BoWrd a8/5PoIPC0hkSDXGoitvoXkL8Pd9x9Y+kyMlKo1C0lk5bCUG4yjk5wVLuSSm5m+KZ3+YVdPp6dKp C0DRhvFdsrz2zIOT/sWheCQO0HRU300UYngB/xoqc1KWH2dROIUhLqwtyoCQbQKQjW9C+JMMw2Ij vfVXJZGMWjbp5l8RQeUSJ+0vVJXJbIL6PfEsyQupUV3AJsSTRmtllqzCBCz2Abd14xyeqw0eJfwx ggMtMIIDKQIBATB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwxFjAU BgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQBGRYC Y2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzAJBgUrDgMCGgUAoIIBgzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA4MDYwMTI1MTdaMCMGCSqGSIb3DQEJBDEWBBRK cRURw4fDb6lzffzsDsuQ48DrKTCBjwYJKwYBBAGCNxAEMYGBMH8wczERMA8GA1UEAwwIc3RhZmYt Y2ExEjAQBgNVBAsMCVRlY2huaWNhbDEWMBQGA1UECgwNQVBOSUMgUHR5IEx0ZDERMA8GA1UEBwwI QnJpc2JhbmUxEjAQBgoJkiaJk/IsZAEZFgJjYTELMAkGA1UEBhMCQVUCCCoPITf60ZNDMIGRBgsq hkiG9w0BCRACCzGBgaB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQB GRYCY2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzANBgkqhkiG9w0BAQEFAASCAQCH93nrGGynwHYw Dmk4UOFH8ICKyU6jBqTg9qSpPFQraO1BxG1nsKn7P4jXHTIflUOsR5d0rNcca93GAg3VhsFH6Dum S78rZC15WYClFun/0xhwM5x+LUkOfXdAPYTQm+QUOs/ERvQuCNs8wwOE0R2wXhWbRejHNlXdfGRS llqrRaGMIxRxbdTxcWQoWuy+z72Lik89Y30Hg+wSH6axxmFYF7ssfrmNfrRSnLB9Gu75X1b8tULU hvJzPNDDieQ/UdmPLaE/S70OkncqmSLxJUvkFnHENFQIrq7U799lcTZhO+P936k1XHpPlsv2t9Lr 6AqcbHsi4GvlT8bHzYTj8fZwAAAAAAAA --Apple-Mail=_60B527D8-1555-4B42-9D40-27FC950C616F-- From rv@x37.NIC.DTAG.DE Mon Aug 6 05:49:51 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9F621F866A for ; Mon, 6 Aug 2012 05:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waNarr0APxUD for ; Mon, 6 Aug 2012 05:49:51 -0700 (PDT) Received: from limes.NIC.DTAG.DE (limes.NIC.DTAG.DE [194.25.1.113]) by ietfa.amsl.com (Postfix) with ESMTP id 71A7421F8667 for ; Mon, 6 Aug 2012 05:49:50 -0700 (PDT) Received: from x37.NIC.DTAG.DE (x37.NIC.DTAG.DE [194.25.1.186]) by limes.NIC.DTAG.DE (8.8.5/8.8.3) with ESMTP id OAA11867; Mon, 6 Aug 2012 14:49:39 +0200 (MET DST) To: "Murphy, Sandra" From: "Ruediger Volk, Deutsche Telekom Technik" In-Reply-To: Your message of "Thu, 02 Aug 2012 20:23:10 -0000." <24B20D14B2CD29478C8D5D6E9CBB29F625F369D5@Hermes.columbia.ads.sparta.com> Date: Mon, 06 Aug 2012 14:49:40 +0200 Message-ID: <4769.1344257380@x37.NIC.DTAG.DE> Sender: rv@x37.NIC.DTAG.DE Cc: "sidr@ietf.org" Subject: Re: [sidr] sidr participation in the LIM scheduled for 29 Sep in Amsterday X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 12:49:51 -0000 > In the SIDR meeting, the interim meeting proposed for Sep was discussed. > > The IETF plans are now to hold the meeting on Sat 29 Sep (the Sat after RIPE). > > All decisions must be confirmed on the list, so I ask for confirmation of > the meeting decision in favor of this meeting. support and will attend (please update date in SIDR Wiki!) Ruediger From Sandra.Murphy@sparta.com Mon Aug 6 08:16:00 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B8121F863F for ; Mon, 6 Aug 2012 08:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wybl5kyHCKPn for ; Mon, 6 Aug 2012 08:15:59 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5243421F861E for ; Mon, 6 Aug 2012 08:15:59 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q76FFvlJ025779; Mon, 6 Aug 2012 10:15:57 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q76FFsNK008627; Mon, 6 Aug 2012 10:15:57 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%21]) with mapi id 14.01.0355.002; Mon, 6 Aug 2012 11:15:57 -0400 From: "Murphy, Sandra" To: "John G. Scudder" Thread-Topic: [sidr] bgpsec confeds bug, with fix Thread-Index: AQHNcETAVYu3Hozv/EO66RgAZRcqdpdItImAgAAF9ICAAAQOAIAEKD8j Date: Mon, 6 Aug 2012 15:15:55 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F52065@Hermes.columbia.ads.sparta.com> References: , <35EA3914-7C13-419E-9F04-1EEC10765426@juniper.net> In-Reply-To: <35EA3914-7C13-419E-9F04-1EEC10765426@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Sriram, Kotikalapudi" , sidr wg list Subject: Re: [sidr] bgpsec confeds bug, with fix X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 15:16:00 -0000 Speaking as a regular ol' member=0A= =0A= This also matches a thought that I just sat down to write up. =0A= =0A= Record the usual AS_PATH type in the signature attribute, meaning that the = internally added AS_PATH elements get marked as AS_CONFED_SEQ and get strip= ped as such at the confed border, just as for current regular BGP.=0A= =0A= This is isomorphic to adding the confed marker on every internal peering, b= ut simply reuses existing confed semantics. (Rather than "more faithfully = mimics" :-) ) See also "reduce it to a problem that has already been sol= ved."=0A= =0A= I found the use of pcount=3D0 as part of the protocol behavior to be a pity= , so a way of getting around that is attractive.=0A= =0A= --Sandy=0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of John G. Sc= udder [jgs@juniper.net]=0A= Sent: Friday, August 03, 2012 3:27 PM=0A= To: John G. Scudder=0A= Cc: Sriram, Kotikalapudi; sidr wg list=0A= Subject: Re: [sidr] bgpsec confeds bug, with fix=0A= =0A= On Aug 3, 2012, at 2:12 PM, "John G. Scudder" wrote:=0A= =0A= > One other option does occur to me however, and I'm not sure why I didn't = think of it before: for *every* crossing of a confederation member border, = set the flag, so it has the semantics of "this is a confederation hop" rath= er than the current "entering a confederation" semantics. Then on exit, str= ip all contiguous flagged hops.=0A= =0A= P. S. I prefer this to either of the other two suggestions I sent. It's les= s hacky than the pcount=3D0 option and more faithfully mimics the semantics= of AS_CONFED_SEQ.=0A= =0A= --John=0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From jgs@juniper.net Mon Aug 6 08:26:27 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1249221F85FF for ; Mon, 6 Aug 2012 08:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.471 X-Spam-Level: X-Spam-Status: No, score=-6.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMZhZn5YDOXd for ; Mon, 6 Aug 2012 08:26:26 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 16B7B21F865F for ; Mon, 6 Aug 2012 08:26:26 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUB/iCwJgROQObWYH5dCmQb5dY1UsfbBc@postini.com; Mon, 06 Aug 2012 08:26:26 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 6 Aug 2012 08:25:42 -0700 Received: from [172.16.13.202] ([172.16.13.202]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q76FPfh68154; Mon, 6 Aug 2012 08:25:41 -0700 (PDT) (envelope-from jgs@juniper.net) MIME-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset="us-ascii" From: "John G. Scudder" In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F52065@Hermes.columbia.ads.sparta.com> Date: Mon, 6 Aug 2012 08:25:40 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: <411D33EA-7E9F-4BED-93F4-A7D8B4621E93@juniper.net> References: , <35EA3914-7C13-419E-9F04-1EEC10765426@juniper.net> <24B20D14B2CD29478C8D5D6E9CBB29F625F52065@Hermes.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1278) Cc: "Sriram, Kotikalapudi" , sidr wg list Subject: Re: [sidr] bgpsec confeds bug, with fix X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 15:26:27 -0000 In other words, instead of a single bit flag per signature, a one-byte = type code taken from the AS_PATH segment type space? I like it! This = would come closer to clearing concerns about being able to represent the = structure of an AS_PATH in bgpsec. (Representing the semantics is = another kettle of fish, see discussions of sets.) The only hitch with this approach in representing AS_PATH semantics is = that it doesn't capture segment boundaries. These are not important = between AS_{CONFED}_SEQUENCE segments, but they are meaningful between = AS_{CONFED}_SETs. If you want to go for 100% fidelity, it would also be = necessary to be able to represent the boundaries between segments.=20 (Granted we have decided that sets are not applicable in the bgpsec = world. Nonetheless I offer it as a demonstration that segment boundaries = can be meaningful in an AS_PATH.) --John On Aug 6, 2012, at 8:15 AM, Murphy, Sandra wrote: > Speaking as a regular ol' member >=20 > This also matches a thought that I just sat down to write up. =20 >=20 > Record the usual AS_PATH type in the signature attribute, meaning that = the internally added AS_PATH elements get marked as AS_CONFED_SEQ and = get stripped as such at the confed border, just as for current regular = BGP. >=20 > This is isomorphic to adding the confed marker on every internal = peering, but simply reuses existing confed semantics. (Rather than = "more faithfully mimics" :-) ) See also "reduce it to a problem that = has already been solved." >=20 > I found the use of pcount=3D0 as part of the protocol behavior to be a = pity, so a way of getting around that is attractive. >=20 > --Sandy > ________________________________________ > From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of John = G. Scudder [jgs@juniper.net] > Sent: Friday, August 03, 2012 3:27 PM > To: John G. Scudder > Cc: Sriram, Kotikalapudi; sidr wg list > Subject: Re: [sidr] bgpsec confeds bug, with fix >=20 > On Aug 3, 2012, at 2:12 PM, "John G. Scudder" wrote: >=20 >> One other option does occur to me however, and I'm not sure why I = didn't think of it before: for *every* crossing of a confederation = member border, set the flag, so it has the semantics of "this is a = confederation hop" rather than the current "entering a confederation" = semantics. Then on exit, strip all contiguous flagged hops. >=20 > P. S. I prefer this to either of the other two suggestions I sent. = It's less hacky than the pcount=3D0 option and more faithfully mimics = the semantics of AS_CONFED_SEQ. >=20 > --John > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From wesley.george@twcable.com Mon Aug 6 11:10:26 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7165821F844B for ; Mon, 6 Aug 2012 11:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.786 X-Spam-Level: X-Spam-Status: No, score=0.786 tagged_above=-999 required=5 tests=[AWL=-1.352, BAYES_50=0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9qPeUPwosMU for ; Mon, 6 Aug 2012 11:10:25 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8580A21E808B for ; Mon, 6 Aug 2012 11:10:18 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.77,720,1336363200"; d="scan'208,217";a="402455169" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 06 Aug 2012 14:09:40 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Mon, 6 Aug 2012 14:10:17 -0400 From: "George, Wes" To: Alexey Melnikov , "sidr@ietf.org" Date: Mon, 6 Aug 2012 14:10:15 -0400 Thread-Topic: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting Thread-Index: Ac1ybL3Av2puCkLTSfiaRy4iZWu3hgBjlfSg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DCC302FAA9FE5F4BBA4DCAD4656937791748EA89F6PRVPEXVS03cor_" MIME-Version: 1.0 Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 18:10:26 -0000 --_000_DCC302FAA9FE5F4BBA4DCAD4656937791748EA89F6PRVPEXVS03cor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgSSBub3RlZCBhdCB0aGUgbWljLCBJ4oCZZCBtdWNoIHByZWZlciB0aGF0IHdlIGZpbmQgYSBw bGFjZSB0byBpbmNvcnBvcmF0ZSB0aGUgaW5mb3JtYXRpb24gaW4gdGhpcyBkcmFmdCBpbnRvIGFu IGV4aXN0aW5nIGRyYWZ0KHMpLiBJIGRvbuKAmXQgdW5kZXJzdGFuZCB0aGUgbmVlZCBmb3IgaGF2 aW5nIHRoaXMgaW5mbyBzZXBhcmF0ZWQgaW4geWV0IGFub3RoZXIgZHJhZnQgYW5kIHRoZXJlZm9y ZSBkbyBub3Qgc3VwcG9ydCBhZG9wdGlvbi4gSSB0aGluayB0aGUgaW5mb3JtYXRpb24gaXMgdXNl ZnVsLCBqdXN0IHdvdWxkIHByZWZlciBpdCBpbnRlZ3JhdGVkIGludG8gYW4gZXhpc3RpbmcgZG9j dW1lbnQuDQpJZiB0aGUgYmVzdCBwbGFjZSBmb3IgaXQgd291bGQgYmUgaW4gYSBkb2N1bWVudCB0 aGF0IGlzIGFscmVhZHkgYW4gUkZDLCB0aGVuIEkgc3VwcG9ydCBhZG9wdGlvbiwgd2l0aCB0aGUg Y2F2ZWF0IHRoYXQgaXQgc2hvdWxkIGZvcm1hbGx5IHVwZGF0ZSB0aGUgYXBwcm9wcmlhdGUgZG9j dW1lbnQgdG8gbWFrZSBpdCBlYXNpZXIgdG8gdHJhY2sgdGhlIGluZm8uDQoNClRoZSByZWFzb24g SSBkb27igJl0IG1ha2UgYSBzcGVjaWZpYyByZWNvbW1lbmRhdGlvbiBhcyB0byB3aGljaCBkb2N1 bWVudCBpdCBiZWxvbmdzIGluIGlzIHByZWNpc2VseSB3aHkgSSB0aGluayB3ZSBzaG91bGRu4oCZ dCBoYXZlIHRoaXMgaW4gYSBzZXBhcmF0ZSBkb2N1bWVudCBpZiBhdCBhbGwgcG9zc2libGUg4oCT IEkgc2ltcGx5IGNhbuKAmXQga2VlcCB0cmFjayBvZiB3aGVyZSBhbGwgb2YgdGhlIGluZm9ybWF0 aW9uIGxpdmVzIGJlY2F1c2UgaXTigJlzIHNwcmVhZCBhY3Jvc3Mgc28gbWFueSBkcmFmdHMuDQoN ClRoYW5rcywNCg0KV2VzDQoNCg0KRnJvbTogc2lkci1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 c2lkci1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWxleGV5IE1lbG5pa292DQpTZW50 OiBTYXR1cmRheSwgQXVndXN0IDA0LCAyMDEyIDI6MTMgUE0NClRvOiBzaWRyQGlldGYub3JnDQpT dWJqZWN0OiBbc2lkcl0gV0cgYWNjZXB0YW5jZSBjYWxsIGZvciBkcmFmdC15bWJrLXJwa2ktZ3Jh bmRwYXJlbnRpbmcNCg0KSGksDQpPbiBiZWhhbGYgb2YgU0lEUiBXRyBjaGFpcnMgSSB3b3VsZCBs aWtlIHRvIGluaXRpYXRlIDIgd2Vla3MgYWNjZXB0YW5jZSBjYWxsIGZvciBkcmFmdC15bWJrLXJw a2ktZ3JhbmRwYXJlbnRpbmcgc3RhcnRpbmcgZnJvbSB0b2RheSwgQXVndXN0IDR0aC4gUGxlYXNl IHNlbmQgeW91ciBwb3NpdGl2ZSBvciBuZWdhdGl2ZSBmZWVkYmFjayB0byB0aGUgbWFpbGluZyBs aXN0IG9yIGRpcmVjdGx5IHRvIGNoYWlycy4NCg0KDQpUaGFuayB5b3UsDQpBbGV4ZXkNCg0KDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUaGlzIEUtbWFpbCBhbmQgYW55IG9m IGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFy eSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJq ZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1t YWlsIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBl bnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0 IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtl biBpbiByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMg RS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQg YW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCg== --_000_DCC302FAA9FE5F4BBA4DCAD4656937791748EA89F6PRVPEXVS03cor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5hcHBsZS1zdHlsZS1zcGFuDQoJ e21zby1zdHlsZS1uYW1lOmFwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFzIEkgbm90ZWQgYXQg dGhlIG1pYywgSeKAmWQgbXVjaCBwcmVmZXIgdGhhdCB3ZSBmaW5kIGEgcGxhY2UgdG8gaW5jb3Jw b3JhdGUgdGhlIGluZm9ybWF0aW9uIGluIHRoaXMgZHJhZnQgaW50byBhbiBleGlzdGluZyBkcmFm dChzKS4gSSBkb27igJl0IHVuZGVyc3RhbmQgdGhlIG5lZWQNCiBmb3IgaGF2aW5nIHRoaXMgaW5m byBzZXBhcmF0ZWQgaW4geWV0IGFub3RoZXIgZHJhZnQgYW5kIHRoZXJlZm9yZSBkbyBub3Qgc3Vw cG9ydCBhZG9wdGlvbi4gSSB0aGluayB0aGUgaW5mb3JtYXRpb24gaXMgdXNlZnVsLCBqdXN0IHdv dWxkIHByZWZlciBpdCBpbnRlZ3JhdGVkIGludG8gYW4gZXhpc3RpbmcgZG9jdW1lbnQuDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgdGhlIGJlc3QgcGxhY2UgZm9yIGl0IHdvdWxk IGJlIGluIGEgZG9jdW1lbnQgdGhhdCBpcyBhbHJlYWR5IGFuIFJGQywgdGhlbiBJIHN1cHBvcnQg YWRvcHRpb24sIHdpdGggdGhlIGNhdmVhdCB0aGF0IGl0IHNob3VsZCBmb3JtYWxseSB1cGRhdGUg dGhlIGFwcHJvcHJpYXRlDQogZG9jdW1lbnQgdG8gbWFrZSBpdCBlYXNpZXIgdG8gdHJhY2sgdGhl IGluZm8uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5UaGUgcmVhc29uIEkgZG9u4oCZdCBtYWtlIGEgc3BlY2lmaWMgcmVj b21tZW5kYXRpb24gYXMgdG8gd2hpY2ggZG9jdW1lbnQgaXQgYmVsb25ncyBpbiBpcyBwcmVjaXNl bHkgd2h5IEkgdGhpbmsgd2Ugc2hvdWxkbuKAmXQgaGF2ZSB0aGlzIGluIGEgc2VwYXJhdGUgZG9j dW1lbnQNCiBpZiBhdCBhbGwgcG9zc2libGUg4oCTIEkgc2ltcGx5IGNhbuKAmXQga2VlcCB0cmFj ayBvZiB3aGVyZSBhbGwgb2YgdGhlIGluZm9ybWF0aW9uIGxpdmVzIGJlY2F1c2UgaXTigJlzIHNw cmVhZCBhY3Jvc3Mgc28gbWFueSBkcmFmdHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+V2VzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNpZHItYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOnNpZHItYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8 L2I+QWxleGV5IE1lbG5pa292PGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBBdWd1c3QgMDQs IDIwMTIgMjoxMyBQTTxicj4NCjxiPlRvOjwvYj4gc2lkckBpZXRmLm9yZzxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBbc2lkcl0gV0cgYWNjZXB0YW5jZSBjYWxsIGZvciBkcmFmdC15bWJrLXJwa2ktZ3Jh bmRwYXJlbnRpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5IaSw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gYmVoYWxmIG9mIFNJRFIgV0cgY2hhaXJzIEkgd291bGQgbGlrZSB0byBpbml0aWF0ZSAyIHdl ZWtzIGFjY2VwdGFuY2UgY2FsbCBmb3ImbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3Bh biI+PGI+ZHJhZnQteW1iay1ycGtpLWdyYW5kcGFyZW50aW5nJm5ic3A7PC9iPnN0YXJ0aW5nIGZy b20gdG9kYXksIEF1Z3VzdCA0dGguIFBsZWFzZSBzZW5kIHlvdXIgcG9zaXRpdmUgb3IgbmVnYXRp dmUgZmVlZGJhY2sgdG8gdGhlDQogbWFpbGluZyBsaXN0IG9yIGRpcmVjdGx5IHRvIGNoYWlycy48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPlRoYW5rIHlv dSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+QWxleGV5PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0K PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnI+DQo8aHI+DQo8Zm9u dCBmYWNlPSJBcmlhbCIgY29sb3I9IkdyYXkiIHNpemU9IjEiPlRoaXMgRS1tYWlsIGFuZCBhbnkg b2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3ByaWV0 YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1 YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBF LW1haWwgaXMgaW50ZW5kZWQgc29sZWx5DQogZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwg b3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGlu dGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQg dGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24g dGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0bw0K IHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4g SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5h bCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC48YnI+DQo8L2Zv bnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DCC302FAA9FE5F4BBA4DCAD4656937791748EA89F6PRVPEXVS03cor_-- From dougm@nist.gov Mon Aug 6 11:27:45 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC6011E80E5 for ; Mon, 6 Aug 2012 11:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFwdNK9rkihN for ; Mon, 6 Aug 2012 11:27:44 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 4124011E80B8 for ; Mon, 6 Aug 2012 11:27:43 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 6 Aug 2012 14:27:12 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 6 Aug 2012 14:27:15 -0400 From: "Montgomery, Douglas" To: Byron Ellacott , Alexey Melnikov Date: Mon, 6 Aug 2012 14:26:14 -0400 Thread-Topic: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting Thread-Index: Ac10AOxTgDQRQ3dDRXan4XDkDgYudQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 18:27:45 -0000 I would be interested in seeing the issue below resolved in definitive language (maybe someplace stronger than the CP template). While I think the spirit of this draft was to show techniques that could be useful during incremental/partial deployment, there are some folks highly concerned about the potential for unwanted manipulation of the RPKI by outside influences on the allocation hierarchy. This draft has become the cook-book for their arguments of how this could be done. I.e., grandparents issues certs and ROAs that conflict with, or invalidate the CERT/allocation hierarchy beneath them. I see enough FUD in this space, that I think the issue should be addressed in SIDR somehow. dougm=20 --=20 Doug Montgomery =AD Mgr. Internet & Scalable Systems Research / ITL / NIST On 8/5/12 9:25 PM, "Byron Ellacott" wrote: >Hi Alexey and list, > >I oppose this acceptance call. The draft makes no reference to the >conflict with the CP draft (6484) [1] with respect to the requirement >that certificates issued by a CA conform to the record of current >holdings. If a grandchild is not listed in the record of current >holdings, a 6484 compliant CA must not issue certificates in their name; >if the grandchild is listed the record of current holdings, then they are >no longer a grandchild, and there is no need for a grandparenting process. > > Byron > >[1] http://tools.ietf.org/html/rfc6484 sections 1.1, 1.4, and 4.2.2. > >On 05/08/2012, at 4:12 AM, Alexey Melnikov wrote: > >> Hi, >> On behalf of SIDR WG chairs I would like to initiate 2 weeks acceptance >>call for draft-ymbk-rpki-grandparenting starting from today, August 4th. >>Please send your positive or negative feedback to the mailing list or >>directly to chairs. >>=20 >> Thank you, >> Alexey >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > From Sandra.Murphy@sparta.com Mon Aug 6 11:45:01 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3FBE21F84FE for ; Mon, 6 Aug 2012 11:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.954 X-Spam-Level: X-Spam-Status: No, score=-101.954 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_43=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yyz+7JAeao-O for ; Mon, 6 Aug 2012 11:44:59 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 36E9D21F84FC for ; Mon, 6 Aug 2012 11:44:59 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q76Iiwtv029306 for ; Mon, 6 Aug 2012 13:44:58 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q76IiwmH016905 for ; Mon, 6 Aug 2012 13:44:58 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%21]) with mapi id 14.01.0355.002; Mon, 6 Aug 2012 14:45:01 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: minutes from the IETF84 sidr meeting Thread-Index: Ac10A0820k+Gzvg6SfS+2wYvVB0Uqg== Date: Mon, 6 Aug 2012 18:44:59 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F52AFE@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] minutes from the IETF84 sidr meeting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 18:45:01 -0000 The meeting minutes were collected on the etherpad tool and are available a= t:=0A= =0A= http://tools.ietf.org/wg/sidr/minutes=0A= =0A= For convenience, below is a copy of the text.=0A= =0A= --Sandy=0A= =0A= =0A= SIDR=0A= August 1, 2012=0A= =0A= Note takers: John Scudder=0A= =0A= (Times provided for correlation with audio recording.)=0A= (No attempt made to capture anything that can be gleaned by reading the sli= des.)=0A= =0A= 9:03=0A= Meeting begins=0A= =0A= Reminder that authors must disclose IPR.=0A= =0A= 9:08=0A= Draft status=0A= =0A= 9:09=0A= Do we need a WG call for combining -cps documents?=0A= (various mic comments: no need, WG has already adopted the work, organizati= on of which drafts it goes in is immaterial)=0A= =0A= 9:11=0A= validation signalling dead unless authors resuscitate it=0A= =0A= 9:15=0A= randy bush: signaling draft has multiple interoperable implementations, let= 's move it forward=0A= chris morrow: it expired=0A= randy bush: will fix.=0A= =0A= 9:16=0A= randy: what needs to happen for pfx-validate to proceed?=0A= chris: I just need to do the writeup=0A= randy: ...=0A= =0A= 9:17 =0A= Steve Kent presenting Unified CPS=0A= 9:20=0A= soliciting comments from WG, especially IANA, RIRs, and large ISPs=0A= 9:21=0A= sandy: have the ISPs and RIRs expressed any opinion about combining the two= cps documents?=0A= steve: we didn't ask first, we haven't received any feedback and it's been = out there for a while.=0A= (room polled, no comments)=0A= =0A= 9:22=0A= Steve presenting Local TA Management=0A= 9:23=0A= (obnoxious cell phone, please turn off your ringers)=0A= 9:29=0A= should standardize syntax to facilitate interoperable tools (editors, etc)= =0A= suggests waiting for next version to come out as it "will be an easier read= "=0A= 9:31=0A= =0A= =0A= rob austein: about standardizing the syntax, you may want to consider makin= g the syntax recommended, wait for second implementation, then standardize.= =0A= steve: please send a more detailed message to the mailing list=0A= =0A= 9:33=0A= Matt Lepinski presenting on BGPSEC Protocol=0A= 9:39=0A= technical change needed for problem: some algorithms (ECSDA) will produce d= ifferent signatures if applied twice to same data. This implies special han= dling needed for duplicate updates. =0A= 9:40=0A= randy: re-keying will change SKI, so something other than the signature wil= l change.=0A= matt: yes, ONLY the actual bits of the digital signature are to be ignored.= =0A= randy: all the implementor has to do is pay attention to the SKI. =0A= 9:41=0A= keyur: one request, please document what randy just said=0A= steve kent: if we included the hash that would be helpful=0A= steve bellovin: no=0A= kent: yo mama=0A= bellovin: sez you=0A= (in other words the minute-taker was unable to capture anything other than = a disagreement)=0A= 9:43=0A= rob austein: the router guys can recognize dups, we just had to explain how= using signature bits and SKI=0A= 9:44=0A= sam weiler: is there an attack here? if you were to revoke a cert, you'd ch= ange your SKI. but could an attacker replay the SKI and signature bits?=0A= matt: how often are you going to go through your rib-in and revalidate all = your signatures just to make sure none have expired or gone bad based on rp= ki state?=0A= matt: this is completely separable and is a general implementation dependen= t issue having to do with things that were ok when you got them but rpki st= ate has changed such that they now are not. this is unrelated to dup detect= ion.=0A= (general nodding)=0A= 9:46=0A= sriram: when you get a dup, if state changed from invalid to valid or vice-= versa that would be an issue.=0A= 9:47=0A= matt: if it's a dup, why would you bother revalidating?=0A= wes relaying padma from jabber: mic: is ML suggesting RPKI state sync with = RIB in- what woud trigger a sig check trawl thru RIB in?=0A= 9:48=0A= randy: rpki update=0A= matt: agree but not for this doc=0A= jeff haas: the property we're looking for, is that the box receiving a dup = suppresses it at that point. we want to preserve that behavior. =0A= matt: agree=0A= 9:50=0A= john scudder: is it generally the case that the SKI will change whenever th= e key changes? this isn't specific to ecdsa right?=0A= matt, rob: right=0A= padma: mic: how would that rpki update be noticed by router?=0A= randy: analogously, how does a router notice a bgp update? the tcp stream p= rovides the data. if you're asking how it matches it to the data in the rib= -in, then look at the prefix-validate document. I feel we must be missing t= he question.=0A= 9:52=0A= (some missed)=0A= randy: now I get it. a new public key comes in that covers some set of pref= ixes. fair point since rpki-rtr doesn't currently cover router keys. that i= s because the spec isn't done, we'll update rpki-rtr when needed. sorry for= misunderstanding.=0A= 9:53=0A= doug m: should be clear in spec about whether you must validate update, vs.= are allowed to skip validation step.=0A= matt: there may be disagreement on that point, we should discuss on the lis= t.=0A= (agree to disagree, move to list)=0A= 9:55=0A= john scudder: suggest making validation inside confed optional. otherwise, = looks good.=0A= matt: sounds reasonable, I'll make the change unless there's an objection.= =0A= =0A= 9:56=0A= Sandy summarizing interim=0A= =0A= 10:05=0A= eric osterweil (sp?): nice to see we're starting to model larger sets. Any = intention take this approach up to something as big as or bigger than today= 's internet, then plot performance curves to show how performance degrades = with scale? I don't mind seeing rsync included, but this kind of methodolog= y can be applied to other distribution protocols. this may teach us somethi= ng about the underlying architecture, independent of specific distribution = protocol.=0A= 10:06=0A= randy: yes.=0A= eric: that's not sufficient.=0A= randy: almost yes. i.e. we're trying to do that kind of modelling, look at = other distribution protocols. adding bittorrent, trying to do it at scale, = specifically not presuming it won't scale.=0A= eric: nothing scales forever, but don't read into my words something that's= not there.=0A= 10:08=0A= randy: coherency isn't easy to define in this case. it's a lot like dns. at= any instant in time there is no "correct" global view. some protocols (rsy= nc) will have more homogenous views than flooding protocols (bittorrent). w= e would be glad of more collaborators for the research!=0A= 10:09=0A= eric: great. I disagree that my implication was that this won't work, it's = just that any system has scaling limits. as for consistency model I don't c= are about that for micro benchmarks, where we can just focus on fetch time.= =0A= 10:11=0A= randy: this was all in the presentation.=0A= (vigorous bickering at mic, ignoring chairs)=0A= =0A= sandy (voluably): sit down and shut up=0A= =0A= tim: I think randy and rob's focus has been on how this data can be shared = between relying parties and such. We on the other hand have looked mostly a= t server load. As Eric said, there's an end to all scaling. ... Current rep= o about 4000 objects, at current size I see no issues. We're doing test and= modelling to let us forsee problems before we encounter them.=0A= 10:13=0A= randy: server load and router load are salient points. these are also susce= ptible to operational fixes. broken protocol, otoh, not so much. =0A= chris: the numbers you're using to do scaling testing. we talked in may abo= ut 2/5/10 year target numbers. today's testing should test for the projecte= d numbers. finally, a lot of the discussion that was at the mic should be r= ecapitulated on the list.=0A= 10:15=0A= randy: your two questions are, how big a number? we are shooting for 1M pre= fixes. will buy dinner for anyone who can gen the whole rpki data set from = bgp data. second, timing? totally dependent on (missed, maybe cycle/refetch= time?). =0A= 10:17=0A= eric o: thanks chris, that was what I was trying to say. 4000 sounds great,= what does that mean? (something about chickens, elephants and tigers.)=0A= tim: after paris meeting I asked on the list for people's ideas about requi= rements, not much feedback, but very happy to discuss it. also, I do believ= e that current deployment works, I just want to look to the future.=0A= 10:18=0A= rob: 1. the way I'd characterize the discussion: we have early measurements= that indicate we have the potential for a success disaster. we can get goi= ng but need to plan ahead. 2. we are starting to look at things like bittor= rent potentially even for top-level publication. we'll report back when we = have data. 3. we had a protocol observation from steve kent on friday. one = of the drawbacks of the current approach is that we don't have (something m= umble something). there is a time til next manifest, steve pointed out that= this could be a hint for time until next poll.=0A= 10:20=0A= danny mcpherson: agree with chris and randy. (something about implications = for architecture) i imagine we would see more churn in the rpki than the ac= tual routing system.=0A= 10:21=0A= sandy: geoff was on remotely on friday and gave an estimate of the size of = the routing sytsem a few years out. of course we have to design for that sc= ale.=0A= 10:22=0A= sandy: please look at interim slides, they're all available=0A= =0A= 10:27=0A= Carlos Martinez presenting on Multiple Publication Points =0A= =0A= (hilarious hijinx with recursive comments related to mic placement and use)= =0A= =0A= questions for group on slide 5; propose WG adoption=0A= =0A= 10:34=0A= rob a: ok, I oppose it. I think you're solving the problem in the wrong pla= ce. I don't see value here, I do see more complexity for relying party. put= all the names in the DNS instead of putting in lots of URIs. Also, at leas= t put in a blank line after all the URIs and the key.=0A= carlos: sure, we'll put in a blank line.=0A= 10:35=0A= randy: +1 rob. non-problem, added complexity.=0A= ruediger: don't let work on this stop you from fixing whatever problems the= current publication points have.=0A= carlos: definitely.=0A= tim: I thought this was good, I do see complexity in RP software. I think i= t's worth continuing this on-list, we won't reach consensus here.=0A= terry m: I want to see the discussion continue. I don't think it's ready fo= r wg adoption. I'd like to continue on basis of looking at format of TAL.= =0A= 10:37=0A= (name? bbn): what problem are you actually solving? what is the RP supposed= to do if presented multiple choices.=0A= carlos: we might need in the future different things we can tweak, just as = we do with the DNS. we may use it, or not, but the possibility will be ther= e. I also like the chance to remove the dependency on DNS. might let us rem= ove a circular dependency. =0A= =0A= 10:39=0A= Benno presenting on RPKI ond Origin Validation Operational Practices=0A= =0A= Don't have a full document yet, we're trying to get interest from the WG.= =0A= =0A= 10:44=0A= randy: first bullet on slide 5 -- we all know RPKI is object-based security= , I'm a little lost about 'identity and authority management' and as for 'k= ey management' is that related to how I distribute the IANA TAL? I'm a litt= le confused.=0A= benno: I think the first... I'm putting a lot of things on one pile. I'm al= so talking about who is authorized *in an organization* to touch key manage= ment.=0A= 10:46=0A= rob: as far as key management, there's an issue for (something related to p= rivate keys)=0A= 10:46=0A= doug m: phased adoption model? that's something the community has struggled= with. piloting, alerting, before going to full-on 'ignore invalid' all ove= r the world.=0A= 10:47=0A= benno: interesting to consider that. wasn't part of the scope we had in min= d.=0A= =0A= see slide 6 for questions to the WG=0A= =0A= 10:49=0A= wes george: I support the document, also agree with Doug. To go back to org= anizational issues, there is typically a gap between router and security st= aff at an operator, so yes, guidance is needed. As to questions on slide 6,= I think this would be best as a wiki, similar to v6 deployment resources. = maybe start with a draft and turn it into a wiki, but eventually a wiki is = better than bis and ter and what have you. =0A= 10:51=0A= randy: philosophically I agree with you but as an ops community we have a p= oor track record at maintaining wikis. Benno, there is some stuff in there = that should go in origin-ops. Plenty of room for co-authors!=0A= =0A= 10:52=0A= Randy presenting on grandparenting=0A= there are no slides=0A= =0A= - There are operational reasons for a large RPKI CA that has children they'= ver certified, the children's children may need grandparents to act for the= m.=0A= - Some of the circumstances are enumerated in the document. Non-exhaustive = list. I don't object to adding more, email me.=0A= - Current draft is second iteration, suggests one circumstance. Suppose som= eone big, like a large ISP or RIR who due to their operational practices ne= eds to provide a facility for grandchildren to request action, might automa= te (e.g. web portal). =0A= - This draft merely points out that this can already be supported in the ex= isting RPKI structure, and that it is an operationally needed facility.=0A= - That is all.=0A= =0A= 10:56=0A= sandy: =0A= =0A= (here endeth my contribution to the minutes)=0A= =0A= (Carlos taking over minutes)=0A= =0A= Sandy asks for clarification on the example presented on randy's grandparen= ting i-d=0A= =0A= A. Robatchevsky: what guidance does the draft actually provide? my concern = is that the rpki follows the delegation structure 1 to 1, and that this dra= ft somewhat subverts that. Technically is all posible. Why do you want to a= dvertise that?=0A= =0A= Randy: because its operationally useful.=0A= =0A= (Doug mc henry) different grandparenting schemes are possible, some of them= more useful than others. Some people concerned about non-useful uses of th= e same techniques. Certain possibilities are more indicative of a problem t= han of a solution.=0A= =0A= (Rob Austein) one way of looking at it is providing guidance on how to addr= ess these situations. =0A= =0A= (T. Manderson) as an interim measure until things smooth over=0A= =0A= (Sandy) we already have docs on parents doing things on behalf of the child= ren, i'm not sure why people find the grandchildren case more troubling tha= n the children example=0A= =0A= (Randy) due to not having obvious contract relationship=0A= =0A= (S. Kent) it's possible to do this in a way that is virtually invisible. I'= m in favour of exploring this but share some of the concerns others have ex= pressed=0A= =0A= (W. George) this wg has a lot of documents, don't understand why this has t= o be a separate doc, can be included in an existing one=0A= =0A= (Sandy) discussion of interim meetings=0A= =0A= (Sandy) in march we did not put one for August, for the date for September,= it was proposed to hold one together with the RIPE meeting in september. T= here will be a LIM (large interim meeting) on sept 29, the saturday after t= he RIPE event finishes. Chances are the venue will be the same as the RIPE = meeting. None of these are final details but pretty firm.=0A= =0A= IETF would like to know whether SIDR would hold a meeting in the LIM.=0A= =0A= (Sandy asks for opinions)=0A= =0A= (W. George) the schedule puts operational items first and policy later. We = risk losing the operators.=0A= =0A= (Randy) RIPE is different, operators stay over. People doing policy in RIPE= actually touch routers.=0A= =0A= (R. Volk) Randy's reporting is right.=0A= =0A= (W. george) I'm not sure whether other WGs considering using the LIM=0A= =0A= (R. Houssley) other WG considering it v6ops and weirds=0A= =0A= (Sandy asks for a vote, R. Houssley wants a number)=0A= =0A= The number is just over 20=0A= =0A= (Sandy)=0A= =0A= we can hope we'll get some more attendance.=0A= =0A= Beyond september: interim meetings have been productive, we need to set up = a plan. There's a nanog/arin meeting in Dallas, IETF in novebmber in Atlant= a and we can talk about December=0A= =0A= RIPE is end of sept, IETF begn of nobemer=0A= =0A= (Randy) could the chairs and authors so that the meeting in AMS is to confi= rm WG concensus from the list on all the docs we having waiting?=0A= =0A= (Randy) yes, all of them if possible=0A= =0A= (W. George) i'd like to ask the folks who routinely complain about the inte= rims what can we do to have you participate. i'm getting frustrated by that= =0A= =0A= () we don't use the meetings to make decisions=0A= =0A= () restriction, travel budget. if we can take that out of the equation, the= n it becames possible to participate=0A= =0A= (R. Volk) let me remark that all the interims have had effective remote par= ticipation. i have participated in two of them, it is actually possible=0A= =0A= (Wes Hardiger) lack of virtual blackboard=0A= =0A= (Chris) we're looking at January, we'll talk about that in November=0A= =0A= (Rob Austein) we should use the IM to have deep technical discussions and u= se the face to face in ATL to push docs out of the door=0A= =0A= (Randy) docs should be out the door before dec/jan, it would be nice to hav= e some sidr technical workshops=0A= =0A= (Sandy) only concensus i see is for sept 29 with RIPE=0A= =0A= (Sandy) we're done, thank you very much=0A= =0A= =0A= =0A= From mlepinski@bbn.com Mon Aug 6 12:01:01 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F19BE21F8493 for ; Mon, 6 Aug 2012 12:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DJRJgkFMNSR for ; Mon, 6 Aug 2012 12:01:00 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id A999921F848A for ; Mon, 6 Aug 2012 12:00:50 -0700 (PDT) Received: from mail.bbn.com ([128.33.0.48]:36569) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SySXm-0003Xx-5x for sidr@ietf.org; Mon, 06 Aug 2012 15:00:46 -0400 Received: from [128.89.253.151] by mail.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1SySXm-0006pm-2l for sidr@ietf.org; Mon, 06 Aug 2012 15:00:46 -0400 Message-ID: <5020149B.3030403@bbn.com> Date: Mon, 06 Aug 2012 15:01:47 -0400 From: Matt Lepinski User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: sidr@ietf.org References: <24B20D14B2CD29478C8D5D6E9CBB29F625F369D5@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F369D5@Hermes.columbia.ads.sparta.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] sidr participation in the LIM scheduled for 29 Sep in Amsterday X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 19:01:01 -0000 Yes, having an interim in conjunction with RIPE is a good idea. 29 Sept is fine. On 8/2/2012 4:23 PM, Murphy, Sandra wrote: > In the SIDR meeting, the interim meeting proposed for Sep was discussed. > > The original proposed date was 23 Sep, intended to take advantage of IETF plans to hold a large scale interim meeting around the RIPE meeting in Sep. > > The IETF plans are now to hold the meeting on Sat 29 Sep (the Sat after RIPE). > > The meeting participants indicated that they were still in favor of this meeting. RIPE participants clarified for the group that RIPE participants tend to be operators, rather than strictly policy oriented. > > An estimate of attendance was requested by the Secretariat. About two dozen people in the room indicated an interest in attending. > > All decisions must be confirmed on the list, so I ask for confirmation of the meeting decision in favor of this meeting. > > --Sandy, speaking as wg co-chair > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From mlepinski@bbn.com Mon Aug 6 12:04:51 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8740521F8491 for ; Mon, 6 Aug 2012 12:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIFTn2H2929u for ; Mon, 6 Aug 2012 12:04:51 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id E30CD21F844C for ; Mon, 6 Aug 2012 12:04:50 -0700 (PDT) Received: from mail.bbn.com ([128.33.0.48]:53528) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SySbi-0001mZ-HR for sidr@ietf.org; Mon, 06 Aug 2012 15:04:50 -0400 Received: from [128.89.253.151] by mail.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1SySbi-0007Ap-E7 for sidr@ietf.org; Mon, 06 Aug 2012 15:04:50 -0400 Message-ID: <50201590.80802@bbn.com> Date: Mon, 06 Aug 2012 15:05:52 -0400 From: Matt Lepinski User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: sidr@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] bgpsec confeds bug, with fix X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 19:04:51 -0000 I also think this works. Additionally, this has the benefit of being easy to write-up (I can easily construct the delta from the current text). :-> On 8/3/2012 3:34 PM, Randy Bush wrote: >> One other option does occur to me however, and I'm not sure why I >> didn't think of it before: for *every* crossing of a confederation >> member border, set the flag, so it has the semantics of "this is a >> confederation hop" rather than the current "entering a confederation" >> semantics. Then on exit, strip all contiguous flagged hops. This is >> predicated on the observation that it's hard for a router to know if >> its member AS was the confederation entry point, but trivial to know >> it's sending the route to another member AS. > i think this works > > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From rogaglia@cisco.com Mon Aug 6 12:17:42 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C58A811E80F8; Mon, 6 Aug 2012 12:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SScww5H85jiM; Mon, 6 Aug 2012 12:17:42 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id D817C11E80F9; Mon, 6 Aug 2012 12:17:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rogaglia@cisco.com; l=4399; q=dns/txt; s=iport; t=1344280662; x=1345490262; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/orpJBDP3m7TASzImIY5xuOGyZYwUxcTeUPAK39XA5c=; b=Uts+86AdRB5JvjWUnBO4SA04C9mmHJxwx+dFyJU3azenoMgQgf07ouos AUOwTqTGt/ahPpHPa707f09X+8YImEVuNsWVfPcrKrnJvqNX+fvtaVTab CkvMZcEW4NIeL11xQfh/iZPemJoq34MdEuJ559EURU12Vnm3HHIyi9ZRr M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAI4XIFCtJV2d/2dsb2JhbABFuUeBB4IgAQEBAwEBAQEPAQodNAsFCwIBCBEDAQEBHxAnCx0IAgQOBQkZh2UGC5p2oB6LSoYkYAOVSYEUjRKBZoJf X-IronPort-AV: E=Sophos;i="4.77,720,1336348800"; d="scan'208";a="108933580" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 06 Aug 2012 19:17:41 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q76JHfHC018538 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Aug 2012 19:17:41 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.248]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0298.004; Mon, 6 Aug 2012 14:17:40 -0500 From: "Roque Gagliano (rogaglia)" To: "Murphy, Sandra" Thread-Topic: [sidr] WG Adoption call for draft-rogaglia-sidr-bgpsec-rollover-01.txt Thread-Index: AQHNdAgj4HhjjwP1tEe0rAetMqofGA== Date: Mon, 6 Aug 2012 19:17:37 +0000 Message-ID: <6A7CFEA8-D734-48E5-9926-842FFA67589F@cisco.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F1A3E8@Hermes.columbia.ads.sparta.com>, <24B20D14B2CD29478C8D5D6E9CBB29F625F2E583@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F34536@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F34536@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.19.12] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19090.001 x-tm-as-result: No--52.294400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <16508E537CF30C45B56ECDDD80E5E071@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr-chairs@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] WG Adoption call for draft-rogaglia-sidr-bgpsec-rollover-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 19:17:43 -0000 Sandy, Just upload the old version as draft-sidr-bgpsec-rollover-00. Link: http://www.ietf.org/id/draft-sidr-bgpsec-rollover-00.txt Roque. On Jul 29, 2012, at 1:26 AM, Murphy, Sandra wrote: > The eventual response from the wg showed consensus for adoption of this d= raft. >=20 > The authors may submit the draft as an initial version sidr draft (draft-= ietf-sidr-xxx-00). At your option, you may alert the chairs of the draft n= ame, and the submission can then be pre-approved.=20 >=20 > --Sandy > ________________________________________ > From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy, = Sandra [Sandra.Murphy@sparta.com] > Sent: Thursday, June 28, 2012 4:45 PM > To: Roque Gagliano (rogaglia); sidr@ietf.org > Cc: sidr-chairs@ietf.org > Subject: Re: [sidr] WG Adoption call for draft-rogaglia-sidr-bgpse= c-rollover-01.txt >=20 > There were only two responses to this call for adoption. Both were posit= ive (and one was followed by extensive comments), but that's a pretty low i= ndication of wg interest. >=20 > On the chance that people might be on holiday, we will give the wg until = 5 July (one week from today) to consider this work. >=20 > This is your last chance, so speak up. >=20 > --Sandy, speaking as wg co-chair > ________________________________________ > From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy, = Sandra [Sandra.Murphy@sparta.com] > Sent: Tuesday, June 12, 2012 5:27 PM > To: Roque Gagliano (rogaglia); sidr@ietf.org > Cc: sidr-chairs@ietf.org > Subject: [sidr] WG Adoption call for draft-rogaglia-sidr-bgpsec-rollov= er-01.txt >=20 > The authors request below that the wg adopt this work as a work item. >=20 > The draft is available at http://tools.ietf.org/html/draft-rogaglia-sidr-= bgpsec-rollover. >=20 > Please respond to the list to say whether you accept this draft as a work= ing group draft and are willing to work on it. Remember that you do not ne= ed to accept all content in a draft to adopt, as draft editors are required= to reflect the consensus of the working group. >=20 > This call will end 26 Jun 2012. >=20 > --Sandy, speaking as wg co-chair >=20 >=20 >=20 > From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Roque Ga= gliano (rogaglia) [rogaglia@cisco.com] >=20 > Sent: Tuesday, June 05, 2012 8:05 AM >=20 > To: sidr@ietf.org >=20 > Subject: [sidr] Fwd: New Version Notification for draft-rogaglia-sidr-bgp= sec-rollover-01.txt >=20 >=20 >=20 >=20 >=20 > Dear WG, >=20 >=20 >=20 > We submitted a new version of this draft based on the feedback from our l= ast meeting in Paris. >=20 >=20 >=20 > As mentioned during Brian's presentation we would like to ask for WG adop= tion. >=20 >=20 >=20 > Regards, > Roque >=20 >=20 >=20 >=20 > Begin forwarded message: >=20 >=20 >=20 > From: >=20 >=20 >=20 > Date: June 5, 2012 1:58:52 PM GMT+02:00 >=20 >=20 >=20 > To: >=20 >=20 >=20 > Cc: , > >=20 >=20 >=20 > Subject: New Version Notification for draft-rogaglia-sidr-bgpsec-rollover= -01.txt >=20 >=20 >=20 >=20 > A new version of I-D, draft-rogaglia-sidr-bgpsec-rollover-01.txt has been= successfully submitted by Roque Gagliano and posted to the IETF repository= . >=20 >=20 >=20 > Filename: draft-rogaglia-sidr-bgpsec-rollover >=20 > Revision: 01 >=20 > Title: BGPSEC router key rollover as an alternative to beaconing >=20 > Creation date: 2012-06-05 >=20 > WG ID: Individual Submission >=20 > Number of pages: 15 >=20 >=20 >=20 > Abstract: >=20 > The current BGPSEC draft documents do not specifies a key rollover >=20 > process for routers. This document describes a possible key rollover >=20 > process and explores its impact to mitigate replay attacks and >=20 > eliminate the need for beaconing in BGPSEC. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From dougm@nist.gov Mon Aug 6 12:23:37 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F9121E8053 for ; Mon, 6 Aug 2012 12:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mt35g6sWjbkA for ; Mon, 6 Aug 2012 12:23:36 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCC321E8039 for ; Mon, 6 Aug 2012 12:23:36 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 6 Aug 2012 15:23:32 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Mon, 6 Aug 2012 15:22:19 -0400 From: "Montgomery, Douglas" To: Matt Lepinski , "sidr@ietf.org" Date: Mon, 6 Aug 2012 15:23:21 -0400 Thread-Topic: [sidr] bgpsec confeds bug, with fix Thread-Index: Ac10CMsu0hrO/zsSRNGekb4i2FPjUA== Message-ID: In-Reply-To: <50201590.80802@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] bgpsec confeds bug, with fix X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 19:23:37 -0000 I would like to see the receiver rules deal will peers outside the cluster who set the "entering cluster" flag maliciously. dougm --=20 Doug Montgomery =AD Mgr. Internet & Scalable Systems Research / ITL / NIST On 8/6/12 3:05 PM, "Matt Lepinski" wrote: >I also think this works. > >Additionally, this has the benefit of being easy to write-up (I can >easily construct the delta from the current text). :-> > >On 8/3/2012 3:34 PM, Randy Bush wrote: >>> One other option does occur to me however, and I'm not sure why I >>> didn't think of it before: for *every* crossing of a confederation >>> member border, set the flag, so it has the semantics of "this is a >>> confederation hop" rather than the current "entering a confederation" >>> semantics. Then on exit, strip all contiguous flagged hops. This is >>> predicated on the observation that it's hard for a router to know if >>> its member AS was the confederation entry point, but trivial to know >>> it's sending the route to another member AS. >> i think this works >> >> randy >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >> > >_______________________________________________ >sidr mailing list >sidr@ietf.org >https://www.ietf.org/mailman/listinfo/sidr From mlepinski@bbn.com Mon Aug 6 12:49:44 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32AB21E80A9 for ; Mon, 6 Aug 2012 12:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoMaPk3DLuWk for ; Mon, 6 Aug 2012 12:49:44 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 290D521E80A8 for ; Mon, 6 Aug 2012 12:49:44 -0700 (PDT) Received: from mail.bbn.com ([128.33.0.48]:54808) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SyTJ6-0004AL-5e; Mon, 06 Aug 2012 15:49:40 -0400 Received: from [128.89.253.151] by mail.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1SyTJ6-0004V7-0G; Mon, 06 Aug 2012 15:49:40 -0400 Message-ID: <50202012.9030507@bbn.com> Date: Mon, 06 Aug 2012 15:50:42 -0400 From: Matt Lepinski User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Montgomery, Douglas" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sidr@ietf.org" Subject: Re: [sidr] bgpsec confeds bug, with fix X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 19:49:44 -0000 Doug, Sounds reasonable. What would you like those receiver rules to say? Are you saying that if I am a receiver and I believe that I am not a member of a confederation and I receive an update that has any confederation marking then I tear down the session (or treat as withdrawal, or whatever IDR tells us we do with mal-formed update messages)? I haven't checked, but I assume their are receiver processing rules in RFC 5065 for receiving an update with an segment of type AS_Confed_Sequence (when the receiver is not in a confederation). We probably want to do the same thing? - Matt Lepinski On 8/6/2012 3:23 PM, Montgomery, Douglas wrote: > I would like to see the receiver rules deal will peers outside the cluster > who set the "entering cluster" flag maliciously. > > dougm From kent@bbn.com Mon Aug 6 13:05:28 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C34F521F841B for ; Mon, 6 Aug 2012 13:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.512 X-Spam-Level: X-Spam-Status: No, score=-106.512 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8toJnebfrbT4 for ; Mon, 6 Aug 2012 13:05:27 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 39E7711E8087 for ; Mon, 6 Aug 2012 13:05:26 -0700 (PDT) Received: from dhcp89-089-055.bbn.com ([128.89.89.55]:58294) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SyTYM-0002vd-8R for sidr@ietf.org; Mon, 06 Aug 2012 16:05:26 -0400 Message-ID: <50202386.3040805@bbn.com> Date: Mon, 06 Aug 2012 16:05:26 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: sidr@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070305020906070908030306" Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 20:05:28 -0000 This is a multi-part message in MIME format. --------------070305020906070908030306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I am in favor of having a WG document addressing this topic. But, I agree that the proposal MUST be consistent with the RPKI CP (RFC 6484). Steve On 8/4/12 2:12 PM, Alexey Melnikov wrote: > Hi, > On behalf of SIDR WG chairs I would like to initiate 2 weeks > acceptance call for draft-ymbk-rpki-grandparenting starting from > today, August 4th. Please send your positive or negative feedback to > the mailing list or directly to chairs. > > Thank you, > Alexey > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --------------070305020906070908030306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I am in favor of having a WG document addressing this topic. But, I agree that the proposal
MUST be consistent with the RPKI CP (RFC 6484).

Steve

On 8/4/12 2:12 PM, Alexey Melnikov wrote:
Hi,
On behalf of SIDR WG chairs I would like to initiate 2 weeks acceptance call for draft-ymbk-rpki-grandparenting starting from today, August 4th. Please send your positive or negative feedback to the mailing list or directly to chairs.

Thank you,
Alexey



_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

--------------070305020906070908030306-- From Sandra.Murphy@sparta.com Mon Aug 6 13:18:40 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F0211E80A6 for ; Mon, 6 Aug 2012 13:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4CdWigNZk1q for ; Mon, 6 Aug 2012 13:18:39 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6012211E8098 for ; Mon, 6 Aug 2012 13:18:39 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q76KIXtc030739; Mon, 6 Aug 2012 15:18:33 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q76KIXIn020447; Mon, 6 Aug 2012 15:18:33 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%21]) with mapi id 14.01.0355.002; Mon, 6 Aug 2012 16:18:35 -0400 From: "Murphy, Sandra" To: "Montgomery, Douglas" , Matt Lepinski , "sidr@ietf.org" Thread-Topic: [sidr] bgpsec confeds bug, with fix Thread-Index: AQHNcETAVYu3Hozv/EO66RgAZRcqdpdItImAgAAF9ICAAAXngIAErx8AgAAE4oD//8dkzw== Date: Mon, 6 Aug 2012 20:18:34 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F52B50@Hermes.columbia.ads.sparta.com> References: <50201590.80802@bbn.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] bgpsec confeds bug, with fix X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 20:18:40 -0000 speaking as regular ol' member=0A= =0A= How about those who set the flag stupidly or by accident?=0A= =0A= :-)=0A= =0A= With current change of the flag semantics to "this-is-a-inside-confed-hop",= it would be difficult to cause damage by setting the flag outside the boun= daries. (Self-induced injury by a neighbor looks like the only case.)=0A= =0A= This error was discussed in the interim meeting - current confed processin= g checks for confed sequences in paths from outside-confed peers and report= s the error. Current error handling is to break the connection, but there'= s work in the idr to change error handling across the board, so that outcom= e may change.=0A= =0A= The question was whether the bgpsec attribute handling needed to detect ina= ppropriate confed syntax and match current bgp processing. The reason to m= atch current processing would be "there must be a reason for current= bgp to do this, let's just adopt the same". More reduce-to-problem-alread= y-solved. Of course, with current bgp handling in flux, there's no guarant= ee that what we stipulate would continue to match.=0A= =0A= --Sandy=0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Montgomery= , Douglas [dougm@nist.gov]=0A= Sent: Monday, August 06, 2012 3:23 PM=0A= To: Matt Lepinski; sidr@ietf.org=0A= Subject: Re: [sidr] bgpsec confeds bug, with fix=0A= =0A= I would like to see the receiver rules deal will peers outside the cluster= =0A= who set the "entering cluster" flag maliciously.=0A= =0A= dougm=0A= --=0A= Doug Montgomery =AD Mgr. Internet & Scalable Systems Research / ITL / NIST= =0A= =0A= =0A= =0A= =0A= =0A= =0A= On 8/6/12 3:05 PM, "Matt Lepinski" wrote:=0A= =0A= >I also think this works.=0A= >=0A= >Additionally, this has the benefit of being easy to write-up (I can=0A= >easily construct the delta from the current text). :->=0A= >=0A= >On 8/3/2012 3:34 PM, Randy Bush wrote:=0A= >>> One other option does occur to me however, and I'm not sure why I=0A= >>> didn't think of it before: for *every* crossing of a confederation=0A= >>> member border, set the flag, so it has the semantics of "this is a=0A= >>> confederation hop" rather than the current "entering a confederation"= =0A= >>> semantics. Then on exit, strip all contiguous flagged hops. This is=0A= >>> predicated on the observation that it's hard for a router to know if=0A= >>> its member AS was the confederation entry point, but trivial to know=0A= >>> it's sending the route to another member AS.=0A= >> i think this works=0A= >>=0A= >> randy=0A= >> _______________________________________________=0A= >> sidr mailing list=0A= >> sidr@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/sidr=0A= >>=0A= >=0A= >_______________________________________________=0A= >sidr mailing list=0A= >sidr@ietf.org=0A= >https://www.ietf.org/mailman/listinfo/sidr=0A= =0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From dougm@nist.gov Mon Aug 6 13:40:20 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 409AC11E80E5 for ; Mon, 6 Aug 2012 13:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.723 X-Spam-Level: X-Spam-Status: No, score=-5.723 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcssQ9yGZgKt for ; Mon, 6 Aug 2012 13:40:19 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 3597D11E80A6 for ; Mon, 6 Aug 2012 13:40:19 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 6 Aug 2012 16:40:15 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Mon, 6 Aug 2012 16:39:02 -0400 From: "Montgomery, Douglas" To: "Murphy, Sandra" , Matt Lepinski , "sidr@ietf.org" Date: Mon, 6 Aug 2012 16:40:04 -0400 Thread-Topic: [sidr] bgpsec confeds bug, with fix Thread-Index: Ac10E4KuB/k7qyPWRduncxt3lptheQ== Message-ID: In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F52B50@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: en-US Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [sidr] bgpsec confeds bug, with fix X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 20:40:20 -0000 U3VyZSwgc3R1cGlkaXR5IGlzIGluZGlzdGluZ3Vpc2hhYmxlIGZyb20gbWFsdXMsIHdpdGhvdXQg dW5kZXJzdGFuZGluZw0KaW50ZW50Lg0KDQpJIHdhc24ndCBwcm9wb3NpbmcgYW55IHNwZWNpZmlj IHJlYWN0aW9uLg0KDQpCdXQgaWYgb3VyIGJlaGF2aW9yIGlzIG5vdyB0byBzdHJpcCBiYWNrd2Fy ZHMgdGhyb3VnaCBjb25zZWN1dGl2ZSBjb25mZWQNCmZsYWdzIC4uLiBJIHdhbnQgdG8gbWFrZSBz dXJlIHdlIGFyZSByb2NrIHNvbGlkIHRoYXQgSSBjYW4ndCBnYW1lIHRoYXQuDQoNCldoaWxlIEkg cmVhbGl6ZSBpdCBtaWdodCBiZSBoYXJkIHRvIGJlIGEgcmVjZWl2ZXIgdG8gb3ZlciBzdHJpcCBh bmQgdGhlbg0KZ2VuZXJhdGUgYSB2YWxpZCBzaWduZWQgcGF0aCAuLi4gSSB3YXMgY29uY2VybmVk IGFib3V0IGdhbWluZyBhIHJlY2VpdmVyDQp0byBvdmVyIHN0cmlwIGFuZCB0aGVuIG1heWJlIHJl Z2VuZXJhdGUgYW4gdW5zaWduZWQgcGF0aCB0aGF0IGhhZCBiZWVuDQpnYW1lZC4NCg0KZG91Z20N Ci0tIA0KRG91ZyBNb250Z29tZXJ5IKGpIE1nci4gSW50ZXJuZXQgJiBTY2FsYWJsZSBTeXN0ZW1z IFJlc2VhcmNoIC8gSVRMIC8gTklTVA0KDQoNCg0KDQoNCg0KT24gOC82LzEyIDQ6MTggUE0sICJN dXJwaHksIFNhbmRyYSIgPFNhbmRyYS5NdXJwaHlAc3BhcnRhLmNvbT4gd3JvdGU6DQoNCj5zcGVh a2luZyBhcyByZWd1bGFyIG9sJyBtZW1iZXINCj4NCj5Ib3cgYWJvdXQgdGhvc2Ugd2hvIHNldCB0 aGUgZmxhZyBzdHVwaWRseSBvciBieSBhY2NpZGVudD8NCj4NCj46LSkNCj4NCj5XaXRoIGN1cnJl bnQgY2hhbmdlIG9mIHRoZSBmbGFnIHNlbWFudGljcyB0bw0KPiJ0aGlzLWlzLWEtaW5zaWRlLWNv bmZlZC1ob3AiLCBpdCB3b3VsZCBiZSBkaWZmaWN1bHQgdG8gY2F1c2UgZGFtYWdlIGJ5DQo+c2V0 dGluZyB0aGUgZmxhZyBvdXRzaWRlIHRoZSBib3VuZGFyaWVzLiAgKFNlbGYtaW5kdWNlZCBpbmp1 cnkgYnkgYQ0KPm5laWdoYm9yIGxvb2tzIGxpa2UgdGhlIG9ubHkgY2FzZS4pDQo+DQo+VGhpcyBl cnJvciB3YXMgIGRpc2N1c3NlZCBpbiB0aGUgaW50ZXJpbSBtZWV0aW5nIC0gY3VycmVudCBjb25m ZWQNCj5wcm9jZXNzaW5nIGNoZWNrcyBmb3IgY29uZmVkIHNlcXVlbmNlcyBpbiBwYXRocyBmcm9t IG91dHNpZGUtY29uZmVkIHBlZXJzDQo+YW5kIHJlcG9ydHMgdGhlIGVycm9yLiAgQ3VycmVudCBl cnJvciBoYW5kbGluZyBpcyB0byBicmVhayB0aGUNCj5jb25uZWN0aW9uLCBidXQgdGhlcmUncyB3 b3JrIGluIHRoZSBpZHIgdG8gY2hhbmdlIGVycm9yIGhhbmRsaW5nIGFjcm9zcw0KPnRoZSBib2Fy ZCwgc28gdGhhdCBvdXRjb21lIG1heSBjaGFuZ2UuDQo+DQo+VGhlIHF1ZXN0aW9uIHdhcyB3aGV0 aGVyIHRoZSBiZ3BzZWMgYXR0cmlidXRlIGhhbmRsaW5nIG5lZWRlZCB0byBkZXRlY3QNCj5pbmFw cHJvcHJpYXRlIGNvbmZlZCBzeW50YXggYW5kIG1hdGNoIGN1cnJlbnQgYmdwIHByb2Nlc3Npbmcu ICBUaGUgcmVhc29uDQo+dG8gbWF0Y2ggY3VycmVudCBwcm9jZXNzaW5nIHdvdWxkIGJlICJ0aGVy ZSBtdXN0IGJlIGEgPGdvb2Q+IHJlYXNvbiBmb3INCj5jdXJyZW50IGJncCB0byBkbyB0aGlzLCBs ZXQncyBqdXN0IGFkb3B0IHRoZSBzYW1lIi4gIE1vcmUNCj5yZWR1Y2UtdG8tcHJvYmxlbS1hbHJl YWR5LXNvbHZlZC4gIE9mIGNvdXJzZSwgd2l0aCBjdXJyZW50IGJncCBoYW5kbGluZw0KPmluIGZs dXgsIHRoZXJlJ3Mgbm8gZ3VhcmFudGVlIHRoYXQgd2hhdCB3ZSBzdGlwdWxhdGUgd291bGQgY29u dGludWUgdG8NCj5tYXRjaC4NCj4NCj4tLVNhbmR5DQo+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPkZyb206IHNpZHItYm91bmNlc0BpZXRmLm9yZyBbc2lkci1ib3Vu Y2VzQGlldGYub3JnXSBvbiBiZWhhbGYgb2YNCj5Nb250Z29tZXJ5LCBEb3VnbGFzIFtkb3VnbUBu aXN0Lmdvdl0NCj5TZW50OiBNb25kYXksIEF1Z3VzdCAwNiwgMjAxMiAzOjIzIFBNDQo+VG86IE1h dHQgTGVwaW5za2k7IHNpZHJAaWV0Zi5vcmcNCj5TdWJqZWN0OiBSZTogW3NpZHJdIGJncHNlYyBj b25mZWRzIGJ1Zywgd2l0aCBmaXgNCj4NCj5JIHdvdWxkIGxpa2UgdG8gc2VlIHRoZSByZWNlaXZl ciBydWxlcyBkZWFsIHdpbGwgcGVlcnMgb3V0c2lkZSB0aGUgY2x1c3Rlcg0KPndobyBzZXQgdGhl ICJlbnRlcmluZyBjbHVzdGVyIiBmbGFnIG1hbGljaW91c2x5Lg0KPg0KPmRvdWdtDQo+LS0NCj5E b3VnIE1vbnRnb21lcnkgoakgTWdyLiBJbnRlcm5ldCAmIFNjYWxhYmxlIFN5c3RlbXMgUmVzZWFy Y2ggLyBJVEwgLyBOSVNUDQo+DQo+DQo+DQo+DQo+DQo+DQo+T24gOC82LzEyIDM6MDUgUE0sICJN YXR0IExlcGluc2tpIiA8bWxlcGluc2tpQGJibi5jb20+IHdyb3RlOg0KPg0KPj5JIGFsc28gdGhp bmsgdGhpcyB3b3Jrcy4NCj4+DQo+PkFkZGl0aW9uYWxseSwgdGhpcyBoYXMgdGhlIGJlbmVmaXQg b2YgYmVpbmcgZWFzeSB0byB3cml0ZS11cCAoSSBjYW4NCj4+ZWFzaWx5IGNvbnN0cnVjdCB0aGUg ZGVsdGEgZnJvbSB0aGUgY3VycmVudCB0ZXh0KS4gOi0+DQo+Pg0KPj5PbiA4LzMvMjAxMiAzOjM0 IFBNLCBSYW5keSBCdXNoIHdyb3RlOg0KPj4+PiBPbmUgb3RoZXIgb3B0aW9uIGRvZXMgb2NjdXIg dG8gbWUgaG93ZXZlciwgYW5kIEknbSBub3Qgc3VyZSB3aHkgSQ0KPj4+PiBkaWRuJ3QgdGhpbmsg b2YgaXQgYmVmb3JlOiBmb3IgKmV2ZXJ5KiBjcm9zc2luZyBvZiBhIGNvbmZlZGVyYXRpb24NCj4+ Pj4gbWVtYmVyIGJvcmRlciwgc2V0IHRoZSBmbGFnLCBzbyBpdCBoYXMgdGhlIHNlbWFudGljcyBv ZiAidGhpcyBpcyBhDQo+Pj4+IGNvbmZlZGVyYXRpb24gaG9wIiByYXRoZXIgdGhhbiB0aGUgY3Vy cmVudCAiZW50ZXJpbmcgYSBjb25mZWRlcmF0aW9uIg0KPj4+PiBzZW1hbnRpY3MuIFRoZW4gb24g ZXhpdCwgc3RyaXAgYWxsIGNvbnRpZ3VvdXMgZmxhZ2dlZCBob3BzLiBUaGlzIGlzDQo+Pj4+IHBy ZWRpY2F0ZWQgb24gdGhlIG9ic2VydmF0aW9uIHRoYXQgaXQncyBoYXJkIGZvciBhIHJvdXRlciB0 byBrbm93IGlmDQo+Pj4+IGl0cyBtZW1iZXIgQVMgd2FzIHRoZSBjb25mZWRlcmF0aW9uIGVudHJ5 IHBvaW50LCBidXQgdHJpdmlhbCB0byBrbm93DQo+Pj4+IGl0J3Mgc2VuZGluZyB0aGUgcm91dGUg dG8gYW5vdGhlciBtZW1iZXIgQVMuDQo+Pj4gaSB0aGluayB0aGlzIHdvcmtzDQo+Pj4NCj4+PiBy YW5keQ0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Pj4gc2lkciBtYWlsaW5nIGxpc3QNCj4+PiBzaWRyQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaWRyDQo+Pj4NCj4+DQo+Pl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PnNpZHIgbWFpbGluZyBsaXN0 DQo+PnNpZHJAaWV0Zi5vcmcNCj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zaWRyDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj5zaWRyIG1haWxpbmcgbGlzdA0KPnNpZHJAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpZHINCg0K From kent@bbn.com Mon Aug 6 13:47:38 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C9721E80AC for ; Mon, 6 Aug 2012 13:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.516 X-Spam-Level: X-Spam-Status: No, score=-106.516 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1TAbJuO-fbJ for ; Mon, 6 Aug 2012 13:47:34 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id E61D821E80A6 for ; Mon, 6 Aug 2012 13:47:33 -0700 (PDT) Received: from dhcp89-089-055.bbn.com ([128.89.89.55]:58306) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SyUD6-0004nv-W0; Mon, 06 Aug 2012 16:47:33 -0400 Message-ID: <50202D64.50509@bbn.com> Date: Mon, 06 Aug 2012 16:47:32 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Tim Bruijnzeels References: <20120731172745.2797.51500.idtracker@ietfa.amsl.com> <501B1267.3080606@bbn.com> <4ABFEC5F-782F-471D-88E8-AE101BEF067A@ripe.net> In-Reply-To: <4ABFEC5F-782F-471D-88E8-AE101BEF067A@ripe.net> Content-Type: multipart/alternative; boundary="------------040709020202070003000102" Cc: sidr@ietf.org Subject: Re: [sidr] I-D Action: draft-ietf-sidr-origin-ops-18.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 20:47:38 -0000 This is a multi-part message in MIME format. --------------040709020202070003000102 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Tim, > Hi Steve, > > On 2 Aug 2012, at 16:51, Stephen Kent wrote: > >> Randy, >> >> I would like to add some more text, based on discussions with RP software developers, >> e.g., Rob and Andrew, and an analysis of a couple of SIDR RFCs >> >> RFC 6486 (TAL) states that no manifest will enumerate the self-signed certificate >> representing a trust anchor. > I think I missed this one. > > Can you explain why this is? It never occurred to me that one would want to store the ss-cert at a repository pub point, vs. storing it in a file independent of the repository structure. BBN SW developers talked with ARIN developers and learned that ARIN was planing to do this, which caused me to do homework to see if I could find references in SIDR RFCs to support my intuition. That's when I found several specific statements that indicate that such storage is not compliant with SIDR RFCs. > However the setup where we re-fetch this actual certificate was intended to allow that the contents of this certificate could be updated in particular wrt the resource extensions. If we have it on a manifest as well that will actually give RPs the opportunity to verify that they see a 'current' version of this cert and not an old one that is being replayed to them. The TAL RFC calls for "re-fetching" the ss-cert, but that is done via the URI in the TAL, not via the RPKI repository walk, which starts from the SKI in this ss-cert. I agree that, if the ss-cert were stored in a pub point one could check the manifest too, but that runs counter to the TAL RFC, and to other RFCs, as I note below. > So in short: I don't understand why it 'MUST' *not* be on the manifest. There is no normative MUST in the text of TAL (6490). And I think there is a actually a better case for including it on the manifest.. Section 2.2 of RFC 6490 (TA:) says: Because the trust anchor is a self-signed certificate, there is no corresponding CRL that can be used to revoke it, *nor is there a manifest [RFC6486] that lists this certificate.* I think this is a pretty clear MUST NOT, even though the 2119 terms are not present. Sam Weiler was the principal author of the TAL RFC, so it my make sense to ask him about the intent of this statement. >> RFC 6487 (Repository Structure) says that every signed >> object at a publication point is enumerated in the manifest published for a >> publication point. Thus the self-signed certificate representing a trust anchor MUST NOT >> be stored in a repository publication point. It is stored in a file independent of >> repository publication points, and pointed to by the URI in the TAL. This file may be >> stored on the same server(s) that are used to store repository publication points. >> > I take it that this is in your view(s) a logical consequence of the first part of your mail? > > In other words if there is no MUST not be on manifest, and it actually *is* on the manifest it can be in this publication point. First, there is the equivalent of a MUST NOT in RFC 6490, as noted above. Second, if we look at RFC 6481 (repository structure), Section 2 says: Additionally, a certificate's Authority Information Access (AIA) extension contains a URI that references the authoritative location for the CA certificate under which the given certificate was issued. Every CA certificate in a pub point contains a back pointer to a location where the issuer of that CA certificate is located, except if one stores a self-signed certificate at a pub point. A self-signed certificate MUST NOT contain an AIA extension or a CRLDP (RFC 6487, 4.8.7, 4.8.6). Thus storing a ss-cert at normal pub points seems odd, since that cert cannot contain the AIA back pointer. A "normal" repository pub point contains a CRL, a manifest, subordinate CA certs and other signed products, e.g., ROAs. If one were to place the ss-cert at a "normal" pub point, there would be no CRL, because that cert has no parent and it never appears on a CRL (see Section 2.2 from RFC 6490, as cited above). So storing this ss-cert in a normal pub point seems inconsistent with both RFC 6481 and 6490. All certificates contain an SIA extension, even self-signed certificates. As noted in 6487: This URI points to the directory containing all published material issued by this CA, i.e., all valid CA certificates, published EE certificates, the current CRL, manifest, and signed objects validated via EE certificates that have beenissued by this CA [RFC6481]. Thus the SIA in the self-signed certificate should point to the pub point for the CRL it issued, the associated manifest, and objects verifiable under that certificate.But if the ss-certificate is in the same pub point as these signed products, this implies a circular reference, which seems odd. Also note that every file at a pub point has a three-character extension identifying the content of the file. Certificates are stored in files marked as ".cer" So, one cannot tell a self-signed certificate from a regular certificate by looking at the file extension. Thus, when processinga set of .cer files from a pub point, a self-signed certificate will be initially appear like all of the others. Thus, only when processing the certificates will its special nature be detected. This seems to impose undue complexity for RPs. The manifest and repository RFCs describe what a "normal" pub point contains, and that does not seem to be compatible with having an ss-cert in such a pub point. Steve --------------040709020202070003000102 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Tim,
Hi Steve,

On 2 Aug 2012, at 16:51, Stephen Kent wrote:


Randy,

I would like to add some more text, based on discussions with RP software developers,
e.g., Rob and Andrew, and an analysis of a couple of SIDR RFCs

RFC 6486 (TAL) states that no manifest will enumerate the self-signed certificate
representing a trust anchor.

I think I missed this one.

Can you explain why this is?
It never occurred to me that one would want to store the ss-cert at a repository pub point, vs. storing it in a file independent of the repository structure. BBN SW developers talked with ARIN developers and learned that ARIN was planing to do this, which caused me to do homework to see if I could find references in SIDR RFCs to support my intuition. That's when I found several specific statements that indicate that such storage is not compliant with SIDR RFCs.
However the setup where we re-fetch this actual certificate was intended to allow that the contents of this certificate could be updated in particular wrt the resource extensions. If we have it on a manifest as well that will actually give RPs the opportunity to verify that they see a 'current' version of this cert and not an old one that is being replayed to them.
The TAL RFC calls for "re-fetching" the ss-cert, but that is done via the URI in the TAL, not via the RPKI repository walk, which starts from the SKI in this ss-cert. I agree that, if the ss-cert were stored in a pub point one could check the manifest too, but that runs counter to the TAL RFC, and to other RFCs, as I note below.
So in short: I don't understand why it 'MUST' *not* be on the manifest. There is no normative MUST in the text of TAL (6490). And I think there is a actually a better case for including it on the manifest..
Section 2.2 of RFC 6490 (TA:) says:

   Because the trust anchor is a self-signed certificate, there is no
   corresponding CRL that can be used to revoke it, nor is there a
   manifest [RFC6486] that lists this certificate.

I think this is a pretty clear MUST NOT, even though the 2119 terms are not present.  Sam Weiler was the principal author of the TAL RFC, so it my make sense to ask him about the intent of this statement.
RFC 6487 (Repository Structure) says that every signed
object at a publication point is enumerated in the manifest published for a
publication point. Thus the self-signed certificate representing a trust anchor MUST NOT
be stored in a repository publication point. It is stored in a file independent of
repository publication points, and pointed to by the URI in the TAL. This file may be
stored on the same server(s) that are used to store repository publication points.


I take it that this is in your view(s) a logical consequence of the first part of your mail?

In other words if there is no MUST not be on manifest, and it actually *is* on the manifest it can be in this publication point.

First, there is the equivalent of a MUST NOT in RFC 6490, as noted above.

Second, if we look at RFC 6481 (repository structure), Section 2 says:

Additionally, a certificate's Authority Information Access (AIA) extension contains a URI that references the authoritative location for the CA certificate under which the given certificate was issued.

 

Every CA certificate in a pub point contains a back pointer to a location where the issuer of that CA certificate is located, except if one stores a self-signed certificate at a pub point. A self-signed certificate MUST NOT contain an AIA extension or a CRLDP (RFC 6487, 4.8.7, 4.8.6).  Thus storing a ss-cert at normal pub points seems odd, since that cert cannot contain the AIA back pointer.


A "normal" repository pub point contains a CRL, a manifest,  subordinate CA certs and other signed products, e.g., ROAs.
If one were to place the ss-cert at a "normal" pub point, there would be no CRL, because that cert has no parent and it never appears on a CRL (see Section 2.2 from RFC 6490, as cited above). So storing this ss-cert in a normal pub point seems inconsistent with both RFC 6481 and 6490.


All certificates contain an SIA extension, even self-signed certificates. As noted in 6487:

 

This URI points to the directory containing all published material issued by this CA, i.e., all valid CA certificates, published EE certificates, the current CRL, manifest, and signed objects validated via EE certificates that have been issued by this CA [RFC6481].

 

Thus the SIA in the self-signed certificate should point to the pub point for the CRL it issued, the associated manifest, and objects verifiable under that certificate.  But if the ss-certificate is in the same pub point as these signed products, this implies a circular reference, which seems odd.

 

Also note that every file at a pub point has a three-character extension identifying the content of the file. Certificates are stored in files marked as “.cer” So, one cannot tell a self-signed certificate from a regular certificate by looking at the file extension. Thus, when processing  a set of .cer files from a pub point, a self-signed certificate will be initially appear like all of the others. Thus, only when processing the certificates will its special nature be detected. This seems to impose undue complexity for RPs.


The manifest and repository RFCs describe what a "normal" pub point contains, and that does not seem to be compatible with having an ss-cert in such a pub point.

Steve
--------------040709020202070003000102-- From morrowc@ops-netman.net Mon Aug 6 14:16:40 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B2911E80FF for ; Mon, 6 Aug 2012 14:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.486 X-Spam-Level: X-Spam-Status: No, score=-1.486 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_20=-0.74, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0xIBaatNP0W for ; Mon, 6 Aug 2012 14:16:40 -0700 (PDT) Received: from mailserver.ops-netman.net (mailserver.ops-netman.net [IPv6:2606:700:e:b00b:5054:ff:fe79:69db]) by ietfa.amsl.com (Postfix) with ESMTP id 224B011E80FA for ; Mon, 6 Aug 2012 14:16:40 -0700 (PDT) Received: from [IPv6:2607:fb90:1300:7a2a:0:30:9cdf:ae01] (unknown [IPv6:2607:fb90:1300:7a2a:0:30:9cdf:ae01]) (Authenticated sender: morrowc@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id BD51D320241 for ; Sat, 4 Aug 2012 22:11:34 +0000 (UTC) Date: Wed, 01 Aug 2012 13:24:12 -0400 Message-ID: From: Chris Morrow To: sidr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Subject: [sidr] Measurement sizing and requirements X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 21:16:41 -0000 U2xpZGVzIGZyb20gdGhlIGxhc3QgaW50ZXJpbSBpbiByZXN0b24gaGF2ZSBzaXppbmcgZXN0aW1h dGVzIGZyb20gR2VvZmYgSHVzdG9uIG9uIHRoZSBldmVudHVhbCB0YXJnZXRzIGZvciB0aGUgcnBr aSBzeXN0ZW0gc2l6ZS4gV2Ugc2hvdWxkIGNvZGlmeSB0aGVzZSBpbiB0aGUgcmVxdWlyZW1lbnRz IGRyYWZ0KHMpIGluIG9yZGVyIHRvIGV2YWx1YXRlIHRoZSBjdXJyZW50IHN5c3RlbXMgYW5kIGZ1 dHVyZSBvbmVzIGFnYWluc3QgYSBjb25zaXN0ZW50IGJlbmNobWFyay4KCi1jaHJpcw== From Sandra.Murphy@sparta.com Mon Aug 6 14:37:33 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF1921E804A for ; Mon, 6 Aug 2012 14:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.951 X-Spam-Level: X-Spam-Status: No, score=-101.951 tagged_above=-999 required=5 tests=[AWL=-0.552, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_43=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcXONDabJRIS for ; Mon, 6 Aug 2012 14:37:31 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 91D2021E804D for ; Mon, 6 Aug 2012 14:37:31 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q76LbUPo031704 for ; Mon, 6 Aug 2012 16:37:30 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q76LbUBr023068 for ; Mon, 6 Aug 2012 16:37:30 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%21]) with mapi id 14.01.0355.002; Mon, 6 Aug 2012 17:37:33 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: minutes from the IETF84 sidr meeting Thread-Index: Ac10A0820k+Gzvg6SfS+2wYvVB0UqgAGEkvV Date: Mon, 6 Aug 2012 21:37:32 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F52BD0@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F52AFE@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F52AFE@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] minutes from the IETF84 sidr meeting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 21:37:33 -0000 Did not state the obvious, sorry.=0A= =0A= Please review the minutes and post any additions or corrections to the list= .=0A= =0A= --Sandy, speaking as wg co-chair=0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy, Sa= ndra [Sandra.Murphy@sparta.com]=0A= Sent: Monday, August 06, 2012 2:44 PM=0A= To: sidr@ietf.org=0A= Subject: [sidr] minutes from the IETF84 sidr meeting=0A= =0A= The meeting minutes were collected on the etherpad tool and are available a= t:=0A= =0A= http://tools.ietf.org/wg/sidr/minutes=0A= =0A= For convenience, below is a copy of the text.=0A= =0A= --Sandy=0A= =0A= =0A= SIDR=0A= August 1, 2012=0A= =0A= Note takers: John Scudder=0A= =0A= (Times provided for correlation with audio recording.)=0A= (No attempt made to capture anything that can be gleaned by reading the sli= des.)=0A= =0A= 9:03=0A= Meeting begins=0A= =0A= Reminder that authors must disclose IPR.=0A= =0A= 9:08=0A= Draft status=0A= =0A= 9:09=0A= Do we need a WG call for combining -cps documents?=0A= (various mic comments: no need, WG has already adopted the work, organizati= on of which drafts it goes in is immaterial)=0A= =0A= 9:11=0A= validation signalling dead unless authors resuscitate it=0A= =0A= 9:15=0A= randy bush: signaling draft has multiple interoperable implementations, let= 's move it forward=0A= chris morrow: it expired=0A= randy bush: will fix.=0A= =0A= 9:16=0A= randy: what needs to happen for pfx-validate to proceed?=0A= chris: I just need to do the writeup=0A= randy: ...=0A= =0A= 9:17=0A= Steve Kent presenting Unified CPS=0A= 9:20=0A= soliciting comments from WG, especially IANA, RIRs, and large ISPs=0A= 9:21=0A= sandy: have the ISPs and RIRs expressed any opinion about combining the two= cps documents?=0A= steve: we didn't ask first, we haven't received any feedback and it's been = out there for a while.=0A= (room polled, no comments)=0A= =0A= 9:22=0A= Steve presenting Local TA Management=0A= 9:23=0A= (obnoxious cell phone, please turn off your ringers)=0A= 9:29=0A= should standardize syntax to facilitate interoperable tools (editors, etc)= =0A= suggests waiting for next version to come out as it "will be an easier read= "=0A= 9:31=0A= =0A= =0A= rob austein: about standardizing the syntax, you may want to consider makin= g the syntax recommended, wait for second implementation, then standardize.= =0A= steve: please send a more detailed message to the mailing list=0A= =0A= 9:33=0A= Matt Lepinski presenting on BGPSEC Protocol=0A= 9:39=0A= technical change needed for problem: some algorithms (ECSDA) will produce d= ifferent signatures if applied twice to same data. This implies special han= dling needed for duplicate updates.=0A= 9:40=0A= randy: re-keying will change SKI, so something other than the signature wil= l change.=0A= matt: yes, ONLY the actual bits of the digital signature are to be ignored.= =0A= randy: all the implementor has to do is pay attention to the SKI.=0A= 9:41=0A= keyur: one request, please document what randy just said=0A= steve kent: if we included the hash that would be helpful=0A= steve bellovin: no=0A= kent: yo mama=0A= bellovin: sez you=0A= (in other words the minute-taker was unable to capture anything other than = a disagreement)=0A= 9:43=0A= rob austein: the router guys can recognize dups, we just had to explain how= using signature bits and SKI=0A= 9:44=0A= sam weiler: is there an attack here? if you were to revoke a cert, you'd ch= ange your SKI. but could an attacker replay the SKI and signature bits?=0A= matt: how often are you going to go through your rib-in and revalidate all = your signatures just to make sure none have expired or gone bad based on rp= ki state?=0A= matt: this is completely separable and is a general implementation dependen= t issue having to do with things that were ok when you got them but rpki st= ate has changed such that they now are not. this is unrelated to dup detect= ion.=0A= (general nodding)=0A= 9:46=0A= sriram: when you get a dup, if state changed from invalid to valid or vice-= versa that would be an issue.=0A= 9:47=0A= matt: if it's a dup, why would you bother revalidating?=0A= wes relaying padma from jabber: mic: is ML suggesting RPKI state sync with = RIB in- what woud trigger a sig check trawl thru RIB in?=0A= 9:48=0A= randy: rpki update=0A= matt: agree but not for this doc=0A= jeff haas: the property we're looking for, is that the box receiving a dup = suppresses it at that point. we want to preserve that behavior.=0A= matt: agree=0A= 9:50=0A= john scudder: is it generally the case that the SKI will change whenever th= e key changes? this isn't specific to ecdsa right?=0A= matt, rob: right=0A= padma: mic: how would that rpki update be noticed by router?=0A= randy: analogously, how does a router notice a bgp update? the tcp stream p= rovides the data. if you're asking how it matches it to the data in the rib= -in, then look at the prefix-validate document. I feel we must be missing t= he question.=0A= 9:52=0A= (some missed)=0A= randy: now I get it. a new public key comes in that covers some set of pref= ixes. fair point since rpki-rtr doesn't currently cover router keys. that i= s because the spec isn't done, we'll update rpki-rtr when needed. sorry for= misunderstanding.=0A= 9:53=0A= doug m: should be clear in spec about whether you must validate update, vs.= are allowed to skip validation step.=0A= matt: there may be disagreement on that point, we should discuss on the lis= t.=0A= (agree to disagree, move to list)=0A= 9:55=0A= john scudder: suggest making validation inside confed optional. otherwise, = looks good.=0A= matt: sounds reasonable, I'll make the change unless there's an objection.= =0A= =0A= 9:56=0A= Sandy summarizing interim=0A= =0A= 10:05=0A= eric osterweil (sp?): nice to see we're starting to model larger sets. Any = intention take this approach up to something as big as or bigger than today= 's internet, then plot performance curves to show how performance degrades = with scale? I don't mind seeing rsync included, but this kind of methodolog= y can be applied to other distribution protocols. this may teach us somethi= ng about the underlying architecture, independent of specific distribution = protocol.=0A= 10:06=0A= randy: yes.=0A= eric: that's not sufficient.=0A= randy: almost yes. i.e. we're trying to do that kind of modelling, look at = other distribution protocols. adding bittorrent, trying to do it at scale, = specifically not presuming it won't scale.=0A= eric: nothing scales forever, but don't read into my words something that's= not there.=0A= 10:08=0A= randy: coherency isn't easy to define in this case. it's a lot like dns. at= any instant in time there is no "correct" global view. some protocols (rsy= nc) will have more homogenous views than flooding protocols (bittorrent). w= e would be glad of more collaborators for the research!=0A= 10:09=0A= eric: great. I disagree that my implication was that this won't work, it's = just that any system has scaling limits. as for consistency model I don't c= are about that for micro benchmarks, where we can just focus on fetch time.= =0A= 10:11=0A= randy: this was all in the presentation.=0A= (vigorous bickering at mic, ignoring chairs)=0A= =0A= sandy (voluably): sit down and shut up=0A= =0A= tim: I think randy and rob's focus has been on how this data can be shared = between relying parties and such. We on the other hand have looked mostly a= t server load. As Eric said, there's an end to all scaling. ... Current rep= o about 4000 objects, at current size I see no issues. We're doing test and= modelling to let us forsee problems before we encounter them.=0A= 10:13=0A= randy: server load and router load are salient points. these are also susce= ptible to operational fixes. broken protocol, otoh, not so much.=0A= chris: the numbers you're using to do scaling testing. we talked in may abo= ut 2/5/10 year target numbers. today's testing should test for the projecte= d numbers. finally, a lot of the discussion that was at the mic should be r= ecapitulated on the list.=0A= 10:15=0A= randy: your two questions are, how big a number? we are shooting for 1M pre= fixes. will buy dinner for anyone who can gen the whole rpki data set from = bgp data. second, timing? totally dependent on (missed, maybe cycle/refetch= time?).=0A= 10:17=0A= eric o: thanks chris, that was what I was trying to say. 4000 sounds great,= what does that mean? (something about chickens, elephants and tigers.)=0A= tim: after paris meeting I asked on the list for people's ideas about requi= rements, not much feedback, but very happy to discuss it. also, I do believ= e that current deployment works, I just want to look to the future.=0A= 10:18=0A= rob: 1. the way I'd characterize the discussion: we have early measurements= that indicate we have the potential for a success disaster. we can get goi= ng but need to plan ahead. 2. we are starting to look at things like bittor= rent potentially even for top-level publication. we'll report back when we = have data. 3. we had a protocol observation from steve kent on friday. one = of the drawbacks of the current approach is that we don't have (something m= umble something). there is a time til next manifest, steve pointed out that= this could be a hint for time until next poll.=0A= 10:20=0A= danny mcpherson: agree with chris and randy. (something about implications = for architecture) i imagine we would see more churn in the rpki than the ac= tual routing system.=0A= 10:21=0A= sandy: geoff was on remotely on friday and gave an estimate of the size of = the routing sytsem a few years out. of course we have to design for that sc= ale.=0A= 10:22=0A= sandy: please look at interim slides, they're all available=0A= =0A= 10:27=0A= Carlos Martinez presenting on Multiple Publication Points=0A= =0A= (hilarious hijinx with recursive comments related to mic placement and use)= =0A= =0A= questions for group on slide 5; propose WG adoption=0A= =0A= 10:34=0A= rob a: ok, I oppose it. I think you're solving the problem in the wrong pla= ce. I don't see value here, I do see more complexity for relying party. put= all the names in the DNS instead of putting in lots of URIs. Also, at leas= t put in a blank line after all the URIs and the key.=0A= carlos: sure, we'll put in a blank line.=0A= 10:35=0A= randy: +1 rob. non-problem, added complexity.=0A= ruediger: don't let work on this stop you from fixing whatever problems the= current publication points have.=0A= carlos: definitely.=0A= tim: I thought this was good, I do see complexity in RP software. I think i= t's worth continuing this on-list, we won't reach consensus here.=0A= terry m: I want to see the discussion continue. I don't think it's ready fo= r wg adoption. I'd like to continue on basis of looking at format of TAL.= =0A= 10:37=0A= (name? bbn): what problem are you actually solving? what is the RP supposed= to do if presented multiple choices.=0A= carlos: we might need in the future different things we can tweak, just as = we do with the DNS. we may use it, or not, but the possibility will be ther= e. I also like the chance to remove the dependency on DNS. might let us rem= ove a circular dependency.=0A= =0A= 10:39=0A= Benno presenting on RPKI ond Origin Validation Operational Practices=0A= =0A= Don't have a full document yet, we're trying to get interest from the WG.= =0A= =0A= 10:44=0A= randy: first bullet on slide 5 -- we all know RPKI is object-based security= , I'm a little lost about 'identity and authority management' and as for 'k= ey management' is that related to how I distribute the IANA TAL? I'm a litt= le confused.=0A= benno: I think the first... I'm putting a lot of things on one pile. I'm al= so talking about who is authorized *in an organization* to touch key manage= ment.=0A= 10:46=0A= rob: as far as key management, there's an issue for (something related to p= rivate keys)=0A= 10:46=0A= doug m: phased adoption model? that's something the community has struggled= with. piloting, alerting, before going to full-on 'ignore invalid' all ove= r the world.=0A= 10:47=0A= benno: interesting to consider that. wasn't part of the scope we had in min= d.=0A= =0A= see slide 6 for questions to the WG=0A= =0A= 10:49=0A= wes george: I support the document, also agree with Doug. To go back to org= anizational issues, there is typically a gap between router and security st= aff at an operator, so yes, guidance is needed. As to questions on slide 6,= I think this would be best as a wiki, similar to v6 deployment resources. = maybe start with a draft and turn it into a wiki, but eventually a wiki is = better than bis and ter and what have you.=0A= 10:51=0A= randy: philosophically I agree with you but as an ops community we have a p= oor track record at maintaining wikis. Benno, there is some stuff in there = that should go in origin-ops. Plenty of room for co-authors!=0A= =0A= 10:52=0A= Randy presenting on grandparenting=0A= there are no slides=0A= =0A= - There are operational reasons for a large RPKI CA that has children they'= ver certified, the children's children may need grandparents to act for the= m.=0A= - Some of the circumstances are enumerated in the document. Non-exhaustive = list. I don't object to adding more, email me.=0A= - Current draft is second iteration, suggests one circumstance. Suppose som= eone big, like a large ISP or RIR who due to their operational practices ne= eds to provide a facility for grandchildren to request action, might automa= te (e.g. web portal).=0A= - This draft merely points out that this can already be supported in the ex= isting RPKI structure, and that it is an operationally needed facility.=0A= - That is all.=0A= =0A= 10:56=0A= sandy:=0A= =0A= (here endeth my contribution to the minutes)=0A= =0A= (Carlos taking over minutes)=0A= =0A= Sandy asks for clarification on the example presented on randy's grandparen= ting i-d=0A= =0A= A. Robatchevsky: what guidance does the draft actually provide? my concern = is that the rpki follows the delegation structure 1 to 1, and that this dra= ft somewhat subverts that. Technically is all posible. Why do you want to a= dvertise that?=0A= =0A= Randy: because its operationally useful.=0A= =0A= (Doug mc henry) different grandparenting schemes are possible, some of them= more useful than others. Some people concerned about non-useful uses of th= e same techniques. Certain possibilities are more indicative of a problem t= han of a solution.=0A= =0A= (Rob Austein) one way of looking at it is providing guidance on how to addr= ess these situations.=0A= =0A= (T. Manderson) as an interim measure until things smooth over=0A= =0A= (Sandy) we already have docs on parents doing things on behalf of the child= ren, i'm not sure why people find the grandchildren case more troubling tha= n the children example=0A= =0A= (Randy) due to not having obvious contract relationship=0A= =0A= (S. Kent) it's possible to do this in a way that is virtually invisible. I'= m in favour of exploring this but share some of the concerns others have ex= pressed=0A= =0A= (W. George) this wg has a lot of documents, don't understand why this has t= o be a separate doc, can be included in an existing one=0A= =0A= (Sandy) discussion of interim meetings=0A= =0A= (Sandy) in march we did not put one for August, for the date for September,= it was proposed to hold one together with the RIPE meeting in september. T= here will be a LIM (large interim meeting) on sept 29, the saturday after t= he RIPE event finishes. Chances are the venue will be the same as the RIPE = meeting. None of these are final details but pretty firm.=0A= =0A= IETF would like to know whether SIDR would hold a meeting in the LIM.=0A= =0A= (Sandy asks for opinions)=0A= =0A= (W. George) the schedule puts operational items first and policy later. We = risk losing the operators.=0A= =0A= (Randy) RIPE is different, operators stay over. People doing policy in RIPE= actually touch routers.=0A= =0A= (R. Volk) Randy's reporting is right.=0A= =0A= (W. george) I'm not sure whether other WGs considering using the LIM=0A= =0A= (R. Houssley) other WG considering it v6ops and weirds=0A= =0A= (Sandy asks for a vote, R. Houssley wants a number)=0A= =0A= The number is just over 20=0A= =0A= (Sandy)=0A= =0A= we can hope we'll get some more attendance.=0A= =0A= Beyond september: interim meetings have been productive, we need to set up = a plan. There's a nanog/arin meeting in Dallas, IETF in novebmber in Atlant= a and we can talk about December=0A= =0A= RIPE is end of sept, IETF begn of nobemer=0A= =0A= (Randy) could the chairs and authors so that the meeting in AMS is to confi= rm WG concensus from the list on all the docs we having waiting?=0A= =0A= (Randy) yes, all of them if possible=0A= =0A= (W. George) i'd like to ask the folks who routinely complain about the inte= rims what can we do to have you participate. i'm getting frustrated by that= =0A= =0A= () we don't use the meetings to make decisions=0A= =0A= () restriction, travel budget. if we can take that out of the equation, the= n it becames possible to participate=0A= =0A= (R. Volk) let me remark that all the interims have had effective remote par= ticipation. i have participated in two of them, it is actually possible=0A= =0A= (Wes Hardiger) lack of virtual blackboard=0A= =0A= (Chris) we're looking at January, we'll talk about that in November=0A= =0A= (Rob Austein) we should use the IM to have deep technical discussions and u= se the face to face in ATL to push docs out of the door=0A= =0A= (Randy) docs should be out the door before dec/jan, it would be nice to hav= e some sidr technical workshops=0A= =0A= (Sandy) only concensus i see is for sept 29 with RIPE=0A= =0A= (Sandy) we're done, thank you very much=0A= =0A= =0A= =0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From terry.manderson@icann.org Mon Aug 6 17:07:21 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A214E11E80BF for ; Mon, 6 Aug 2012 17:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.435 X-Spam-Level: X-Spam-Status: No, score=-106.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVvEF-kXDPkz for ; Mon, 6 Aug 2012 17:07:21 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9C611E8087 for ; Mon, 6 Aug 2012 17:07:21 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Mon, 6 Aug 2012 17:07:20 -0700 From: Terry Manderson To: Alexey Melnikov , "sidr@ietf.org" Date: Mon, 6 Aug 2012 17:07:23 -0700 Thread-Topic: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting Thread-Index: Ac1ybMoSgLgozTMIRCC1v5npxKKQwgBw9Rvx Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3427178843_35139310" MIME-Version: 1.0 Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 00:07:21 -0000 --B_3427178843_35139310 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit After re-reading the -02 version, I do not think that this draft, as written, should be be adopted. I also retract my 'at mic' statement that this could work if termed as "interim" in function - as I doubt that there is any real mutual understanding of 'interim'. So while the current RFCs do not specifically speak against this, I think that in making this an option and allowing such 'grandparent' objects that validate will create ambiguity and complexity. Just because it's possible, doesn't mean we should. I'd also note that with the concepts of the up-down protocol and the amazing level of flexibility in the RFC3779 extensions which allows both range and prefix options. Slicing and dicing the various cert's 3779 extensions to take away the chunk from "C" and give to "G" should be a case of machine work and a small set of up/down processing. Cheers Terry On 5/08/12 4:12 AM, "Alexey Melnikov" wrote: > Hi, > On behalf of SIDR WG chairs I would like to initiate 2 weeks acceptance call > for draft-ymbk-rpki-grandparenting starting from today, August 4th. Please > send your positive or negative feedback to the mailing list or directly to > chairs. > > Thank you, > Alexey > --B_3427178843_35139310 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQAQYJKoZIhvcNAQcCoIIP8jCCD+4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Dc0wggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGsMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEXMBUGA1UECxMORE5TIE9wZXJh dGlvbnMxGDAWBgNVBAMTD1RlcnJ5IE1hbmRlcnNvbjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAKRhZ4W3U6MnfS2woYEFCIyN+g1MNILokbUKk+PTl5mmK3QtWQxTSOu2sdzN xHMy6p2RoT9BMGOamttFq2WswSru6/7JT1TflytGaPHfK5kMP/pI47hmcwUEm9Z169I5ar7z BTiEAQA06cGKtgJ8XiiLFUIHLVuRq3WGxjnFTHlAHXY6mdgDT/ntAnoEvvPVm4XqUnjJiZTS ojzyr1q2RqFvyXs2blOARumDqvLI33yLGcUuaEL+A+hgodzM/fL4kdoy964mXvmEerpm4d4f Y/JfbRUWxc0Eomu9nwGFNk6ijO41qk+OIboct2qeA+5PPclXJNNHYVfzT2dyWfGgxaMCAwEA AaOCA2gwggNkMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSz wvR2YXpP9XjS9cknMX5g3LM2jTAkBgNVHREEHTAbgRl0ZXJyeS5tYW5kZXJzb25AaWNhbm4u b3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFz c3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6 BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5 Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRr MGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEAYpwxK/KvdhbyQqrKp2ylMQpNzqVH ofo4hPILTnp/o+UyYVn6daWSilaV+XNBzE5Rm/f7ms2iA1zBzOvGv55pLH0n6lgIRTeuAGzf KIsPCwPvYQkkMAPXHzh9A44m19hvigTgOPNyjzcOTiHqwwCJSDTEZx17CEkrzQPq1vfG1Lvk +AWjEtxCsGmsuCHHaZjwQ8SsGI7W5cA1Y4RTcQf6S9eIpSsOwXIYdDgWq9Uhi/amW7ryW06Y GH7BHaitqgmm32MZuid3UzJUU6+Ljx7uGA9Fe6k1uPEHhaXTAoobPSpPdOgGmnxUCRQu2OI7 +I8vHiSe7DC/LmxEDC5kB+lUTjCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJ KoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQV wpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5Q ycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE 7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBd XPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcD AgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYL YIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUA cwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMA dABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQA aQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkA aQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwA aQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8A cgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMA ZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQu Y29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqg OKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNVHSMEGDAWgBRF 66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQqtbbvj/JV hbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F2XVA u6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6X vAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWye KU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjGCAfwwggH4AgEBMHYwYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAPz2lJUZsAlD35l4oJxf0FMAkGBSsO AwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQU+JHf5K+5LMExkTBcmyzTRv6lYcswGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwODA3MDAwNzIzWjANBgkqhkiG 9w0BAQEFAASCAQBwYF5iEZjqUPkFuW21wRgHrFpk3oOqvZgYRT/5F5Nwkd7SYaP0Ow5/Uwt+ gWQv5twNXqnYZAVfl1S0FznfJLNZhEalEoZqniAf+fLy9Gq1vmt7T93zPtgHJRZ8aYROizYc mDOltKRZdiu9R9ku2NgXZdIxsnOECmGYphsdYlHmNd1J9sUszTiNbED3i+Al8XyqSZ6IBVOy vz3rXCvlspEiTlxaMrJn3N49oxib2uAzgZ7vJ4X0Sd490hTKibaIq99UDvhRx7SqthfFc5mp +AA8bELVCAVLAe/UyDNUL+UBrF9GbryPWfnVWsLRoJN2Mr2WjQHKwz+jx39epxtAR5ze --B_3427178843_35139310-- From ggm+ietf@apnic.net Mon Aug 6 18:38:31 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 254BD21F8674 for ; Mon, 6 Aug 2012 18:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZE2QvQINyg7t for ; Mon, 6 Aug 2012 18:38:30 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id A958021F8658 for ; Mon, 6 Aug 2012 18:38:28 -0700 (PDT) Received: from [IPv6:2001:dc0:a000:4:2d45:468f:7923:2712] (unknown [IPv6:2001:dc0:a000:4:2d45:468f:7923:2712]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 4851FB684B for ; Tue, 7 Aug 2012 11:38:27 +1000 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: George Michaelson In-Reply-To: Date: Tue, 7 Aug 2012 11:38:29 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <53D504DF-C0A3-4CFC-AD93-689630336F7D@apnic.net> References: To: sidr@ietf.org X-Mailer: Apple Mail (2.1485) Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 01:38:31 -0000 I am very concerned the impact this kind of activity has on the = integrity of public allocation registries. How are external parties meant to understand what should exist, if the = RPKI signing leaps over intermediate parties that are explicitly listed = as having substantive authority over the disposition of resources? I am struggling to imagine how this activity happens in the context of = lawsuit, and the risk of lawsuit by the skipped-over party, and other = unrelated parties. The Grandparent has no contractual relationship with the Grandchild. = What is the basis for entering into an agreement to certify these = resources, rather than performing a publicly recognized transfer of = control? Whats the long-term relationship between the new child, and the = Grandparent? on what basis does RPKI certification continue, or cease? = Does the parent retain any control? What if the parent does wake up an = RPKI engine, and issues conflicting signing state?=20 I don't think these are subjects which vest well inside the IETF = process, or an RFC. I think they go to address policy questions = currently handled inside the RIR policy framework, by address holders. = Since the affected parties include address holders I cannot see how this = should be documented or defined outside of that process. -George On 05/08/2012, at 4:12 AM, Alexey Melnikov = wrote: > Hi, > On behalf of SIDR WG chairs I would like to initiate 2 weeks = acceptance call for draft-ymbk-rpki-grandparenting starting from today, = August 4th. Please send your positive or negative feedback to the = mailing list or directly to chairs. >=20 > Thank you, > Alexey >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From dougm@nist.gov Mon Aug 6 21:21:49 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8079A21F869D for ; Mon, 6 Aug 2012 21:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.307 X-Spam-Level: X-Spam-Status: No, score=-6.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpQPO+QdqQxS for ; Mon, 6 Aug 2012 21:21:49 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id B6F1B21F8691 for ; Mon, 6 Aug 2012 21:21:48 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 7 Aug 2012 00:21:43 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Tue, 7 Aug 2012 00:20:29 -0400 From: "Montgomery, Douglas" To: Matt Lepinski Date: Tue, 7 Aug 2012 00:21:33 -0400 Thread-Topic: [sidr] bgpsec confeds bug, with fix Thread-Index: Ac10U/nfsOF76GnkSTCA6EpbeJRMUQ== Message-ID: In-Reply-To: <50202012.9030507@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] bgpsec confeds bug, with fix X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 04:21:49 -0000 RFC5065 says if you receive a confed sequence/set from a peer that isn't in your confederation, you treat it as a malformed AS-PATH and refer to 4271 rules for such. >>> It is an error for a BGP speaker to receive an UPDATE message with an AS_PATH attribute that contains AS_CONFED_SEQUENCE or AS_CONFED_SET segments from a neighbor that is not located in the same confederation. If a BGP speaker receives such an UPDATE message, it SHALL treat the message as having a malformed AS_PATH according to the procedures of [BGP-4 ], Section 6.3 ("UPDATE Message Error Handling"). <<< Of course, we don't have a AS-PATH so to tie up these loose ends I think I think we would need a sentence similar to 5065 but pointing to BGPSEC's rules for malformed PATH-SIG attributes. dougm --=20 Doug Montgomery =AD Mgr. Internet & Scalable Systems Research / ITL / NIST On 8/6/12 3:50 PM, "Matt Lepinski" wrote: >Doug, > >Sounds reasonable. What would you like those receiver rules to say? Are >you saying that if I am a receiver and I believe that I am not a member >of a confederation and I receive an update that has any confederation >marking then I tear down the session (or treat as withdrawal, or >whatever IDR tells us we do with mal-formed update messages)? > >I haven't checked, but I assume their are receiver processing rules in >RFC 5065 for receiving an update with an segment of type >AS_Confed_Sequence (when the receiver is not in a confederation). We >probably want to do the same thing? > >- Matt Lepinski > >On 8/6/2012 3:23 PM, Montgomery, Douglas wrote: >> I would like to see the receiver rules deal will peers outside the >>cluster >> who set the "entering cluster" flag maliciously. >> >> dougm > From mlepinski@bbn.com Tue Aug 7 04:37:57 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 700F121F86F3 for ; Tue, 7 Aug 2012 04:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gtKzwpOkAMe for ; Tue, 7 Aug 2012 04:37:56 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id B9FCF21F86F4 for ; Tue, 7 Aug 2012 04:37:56 -0700 (PDT) Received: from mail.bbn.com ([128.33.0.48]:38093) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Syi6k-000ABq-VR; Tue, 07 Aug 2012 07:37:55 -0400 Received: from [128.89.253.48] by mail.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1Syi6k-0007cc-S6; Tue, 07 Aug 2012 07:37:54 -0400 Message-ID: <5020FE5B.8030108@bbn.com> Date: Tue, 07 Aug 2012 07:39:07 -0400 From: Matt Lepinski User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Montgomery, Douglas" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sidr@ietf.org" Subject: Re: [sidr] bgpsec confeds bug, with fix X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 11:37:58 -0000 Sounds reasonable. On 8/7/2012 12:21 AM, Montgomery, Douglas wrote: > RFC5065 says if you receive a confed sequence/set from a peer that isn't > in your confederation, you treat it as a malformed AS-PATH and refer to > 4271 rules for such. > > It is an error for a BGP speaker to receive an UPDATE message with an > AS_PATH attribute that contains AS_CONFED_SEQUENCE or AS_CONFED_SET > segments from a neighbor that is not located in the same > confederation. If a BGP speaker receives such an UPDATE message, it > SHALL treat the message as having a malformed AS_PATH according to > the procedures of [BGP-4 > ], Section 6.3 ("UPDATE > Message Error > Handling"). > <<< > > Of course, we don't have a AS-PATH so to tie up these loose ends I think I > think we would need a sentence similar to 5065 but pointing to BGPSEC's > rules for malformed PATH-SIG attributes. > > dougm From kent@bbn.com Tue Aug 7 07:36:17 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5D521F86DF for ; Tue, 7 Aug 2012 07:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.518 X-Spam-Level: X-Spam-Status: No, score=-106.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhlUKVNrfoB2 for ; Tue, 7 Aug 2012 07:36:16 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7841221F86D8 for ; Tue, 7 Aug 2012 07:36:16 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:57985 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SyktL-000DPM-QF; Tue, 07 Aug 2012 10:36:15 -0400 Message-ID: <502127DF.5030807@bbn.com> Date: Tue, 07 Aug 2012 10:36:15 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Tim Bruijnzeels References: <20120731172745.2797.51500.idtracker@ietfa.amsl.com> <501B1267.3080606@bbn.com> <4ABFEC5F-782F-471D-88E8-AE101BEF067A@ripe.net> In-Reply-To: <4ABFEC5F-782F-471D-88E8-AE101BEF067A@ripe.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr@ietf.org Subject: Re: [sidr] I-D Action: draft-ietf-sidr-origin-ops-18.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 14:36:17 -0000 Tim, Another thought re where (not) to place the ss-cert to which a TAL points. An RPKI repository pub point contains a CRL. That CRL contains serial numbers for certs that were published at this pub point, or that were embedded in objects at this pub point The ss-cert will never be on a CRL (this is true for TAs in general, and is explicitly mentioned in the TAL RFC). So, publishing this cert at a pub point is inconsistent with the general RPKI model as it is outside the scope of the CRL at that pub point. Steve From internet-drafts@ietf.org Tue Aug 7 08:32:28 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 235BD21F853C; Tue, 7 Aug 2012 08:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0BF1sMkNGvp; Tue, 7 Aug 2012 08:32:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B7C21F84A1; Tue, 7 Aug 2012 08:32:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120807153226.22130.73145.idtracker@ietfa.amsl.com> Date: Tue, 07 Aug 2012 08:32:26 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-rollover-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 15:32:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working Group= of the IETF. Title : BGPSEC router key rollover as an alternative to beaconing Author(s) : Roque Gagliano Keyur Patel Brian Weis Filename : draft-ietf-sidr-bgpsec-rollover-00.txt Pages : 15 Date : 2012-08-07 Abstract: The current BGPSEC draft documents do not specifies a key rollover process for routers. This document describes a possible key rollover process and explores its impact to mitigate replay attacks and eliminate the need for beaconing in BGPSEC. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-rollover There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-rollover-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tim@ripe.net Wed Aug 8 07:52:27 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 613F021F867A for ; Wed, 8 Aug 2012 07:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIaQ2SRSURtE for ; Wed, 8 Aug 2012 07:52:26 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 41B9221F8679 for ; Wed, 8 Aug 2012 07:52:26 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Sz7cV-0005Dr-TG; Wed, 08 Aug 2012 16:52:25 +0200 Received: from s258-sslvpn-1.ripe.net ([193.0.20.231] helo=vpn-232.ripe.net) by dodo.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1Sz7cT-0007Je-Cz; Wed, 08 Aug 2012 16:52:23 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1-1058118762 From: Tim Bruijnzeels In-Reply-To: <53D504DF-C0A3-4CFC-AD93-689630336F7D@apnic.net> Date: Wed, 8 Aug 2012 07:52:18 -0700 Message-Id: <097D025D-1879-455C-BB14-F9C8BFAC88AA@ripe.net> References: <53D504DF-C0A3-4CFC-AD93-689630336F7D@apnic.net> To: George Michaelson X-Mailer: Apple Mail (2.1084) X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816066, check: 20120808 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a071932054669c02cca3a6f587e8121637674 Cc: sidr@ietf.org Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 14:52:27 -0000 --Apple-Mail-1-1058118762 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Thank you George for phrasing this so accurately. I fully agree that in = case of the RIRs there already exists a frame work (address policy) that = provides all the process needed for this. I am not sure how many big = ISPs / LIRs follow this discussion, but I expect that there commercial = contractual concerns exist regarding this and I highly doubt that such = companies will follow this document's advice, just because it's a = standard.. Tim=20 On 6 Aug 2012, at 18:38, George Michaelson wrote: > I am very concerned the impact this kind of activity has on the = integrity of public allocation registries. >=20 > How are external parties meant to understand what should exist, if the = RPKI signing leaps over intermediate parties that are explicitly listed = as having substantive authority over the disposition of resources? >=20 > I am struggling to imagine how this activity happens in the context of = lawsuit, and the risk of lawsuit by the skipped-over party, and other = unrelated parties. >=20 > The Grandparent has no contractual relationship with the Grandchild. = What is the basis for entering into an agreement to certify these = resources, rather than performing a publicly recognized transfer of = control? Whats the long-term relationship between the new child, and the = Grandparent? on what basis does RPKI certification continue, or cease? = Does the parent retain any control? What if the parent does wake up an = RPKI engine, and issues conflicting signing state?=20 >=20 > I don't think these are subjects which vest well inside the IETF = process, or an RFC. I think they go to address policy questions = currently handled inside the RIR policy framework, by address holders. = Since the affected parties include address holders I cannot see how this = should be documented or defined outside of that process. >=20 > -George >=20 > On 05/08/2012, at 4:12 AM, Alexey Melnikov = wrote: >=20 >> Hi, >> On behalf of SIDR WG chairs I would like to initiate 2 weeks = acceptance call for draft-ymbk-rpki-grandparenting starting from today, = August 4th. Please send your positive or negative feedback to the = mailing list or directly to chairs. >>=20 >> Thank you, >> Alexey >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail-1-1058118762 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I am = very concerned the impact this kind of activity has on the integrity of = public allocation registries.

How are external parties meant to = understand what should exist, if the RPKI signing leaps over = intermediate parties that are explicitly listed as having substantive = authority over the disposition of resources?

I am struggling to = imagine how this activity happens in the context of lawsuit, and the = risk of lawsuit by the skipped-over party, and other unrelated = parties.

The Grandparent has no contractual relationship with the = Grandchild. What is the basis for entering into an agreement to certify = these resources, rather than performing a publicly recognized transfer = of control? Whats the long-term relationship between the new child, and = the Grandparent? on what basis does RPKI certification continue, or = cease? Does the parent retain any control? What if the parent does wake = up an RPKI engine, and issues conflicting signing state?

I don't = think these are subjects which vest well inside the IETF process, or an = RFC. I think they go to address policy questions  currently handled = inside the RIR policy framework, by address holders. Since the affected = parties include address holders I cannot see how this should be = documented or defined outside of that process.

-George

On = 05/08/2012, at 4:12 AM, Alexey Melnikov <alexey.melnikov@isode.com>= ; wrote:

Hi,
On behalf of SIDR WG chairs I would like to initiate 2 = weeks acceptance call for draft-ymbk-rpki-grandparenting starting from = today, August 4th. Please send your positive or negative feedback to the = mailing list or directly to chairs.

Thank = you,
Alexey

_______________________________________________
sidr mailing = list
sidr@ietf.org
https://www.ietf.org/m= ailman/listinfo/sidr

_____________________________= __________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/ma= ilman/listinfo/sidr


= --Apple-Mail-1-1058118762-- From randy@psg.com Thu Aug 9 07:34:03 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBDEC21F86B3 for ; Thu, 9 Aug 2012 07:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R91WlsUt7r7P for ; Thu, 9 Aug 2012 07:34:03 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD7521F86AF for ; Thu, 9 Aug 2012 07:34:03 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SzToE-0003Rf-Nk; Thu, 09 Aug 2012 14:33:59 +0000 Date: Thu, 09 Aug 2012 10:34:06 -0400 Message-ID: From: Randy Bush To: Tim Bruijnzeels In-Reply-To: <097D025D-1879-455C-BB14-F9C8BFAC88AA@ripe.net> References: <53D504DF-C0A3-4CFC-AD93-689630336F7D@apnic.net> <097D025D-1879-455C-BB14-F9C8BFAC88AA@ripe.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: George Michaelson , sidr wg Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 14:34:04 -0000 for those who might not have thought about the document very much Or a child, C, in the process of going out of business might place their grandchildren in precarious circumstances until they can re- home. The grandparent, without disturbing the child's data, could simply issue ROAs for the grandchildren, or issue certificates for those willing to manage their own rpki data. randy From randy@psg.com Thu Aug 9 07:50:12 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7064421F86FC for ; Thu, 9 Aug 2012 07:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhmvPIYYaw0J for ; Thu, 9 Aug 2012 07:50:12 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id DAC9521F86F9 for ; Thu, 9 Aug 2012 07:50:11 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SzU3s-0003Wm-NV; Thu, 09 Aug 2012 14:50:09 +0000 Date: Thu, 09 Aug 2012 10:50:16 -0400 Message-ID: From: Randy Bush To: Tim Bruijnzeels In-Reply-To: <097D025D-1879-455C-BB14-F9C8BFAC88AA@ripe.net> References: <53D504DF-C0A3-4CFC-AD93-689630336F7D@apnic.net> <097D025D-1879-455C-BB14-F9C8BFAC88AA@ripe.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: George Michaelson , sidr wg Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 14:50:12 -0000 tim, i see where some confusion might come from > I am not sure how many big ISPs / LIRs follow this discussion, but I > expect that there commercial contractual concerns exist regarding this > and I highly doubt that such companies will follow this document's > advice, just because it's a standard. i know rirs like to speak for their members, but this document was written by one of them :) as a large isp, we serve a fair number of smaller isps. i specifically had in mind the circumstance where one of our customers failed and their child needed support. we're engineers, and our primary concern is that the packets get delivered. indeed, the contractual concerns you raise are specifically why one may not want to disturb the child's cert while seeing that the grandchild's packets are delivered. i also have concern that rirs are not seeing the needs of the community, which includes the grandchildren (even though you do not rent integers to them directly). the issue here is operational packet delivery, not rir policy. randy From christopher.morrow@gmail.com Thu Aug 9 11:25:25 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6586221F86B3 for ; Thu, 9 Aug 2012 11:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnO+XADJ5tXD for ; Thu, 9 Aug 2012 11:25:25 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B5F9521F86AD for ; Thu, 9 Aug 2012 11:25:24 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so768275vcb.31 for ; Thu, 09 Aug 2012 11:25:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=pKJfjONmBzIs8MV8Dj2HMRn/AsCsYOL33QrAcacY9Pc=; b=uemwpnHyNNyoBbi39Uw4cJo1QjVuUaCwQmX40VKKgbVkff6PaDYMOa5jzU04tDDDTk JcXAdwXl/zOHTyZr7IqHCco7n58X89BzO3OgKde3qFp9KxOjt8BTgTHQpC5cW0kpV0RG vnnJmRQykpBSKhpm0syskmn+AOo821YwDFfvFbrZExiqYcpAV5IKTvGf7PvHG+W69tY2 QC/jvhigkO5Q+qvu/qAA48zZvi85BH1/wvExeWsAGzNOQTUuet+wyQKTMNmKuJZ2NcwH Opv2gpVcA61xPZwXNFY3Xm8aZ8f9dj0dG525sVS3vRFx90s4WhVMiTy+xe8nsgA6qpvn HcRQ== MIME-Version: 1.0 Received: by 10.52.22.38 with SMTP id a6mr200148vdf.37.1344536724156; Thu, 09 Aug 2012 11:25:24 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.58.255.197 with HTTP; Thu, 9 Aug 2012 11:25:24 -0700 (PDT) In-Reply-To: References: <53D504DF-C0A3-4CFC-AD93-689630336F7D@apnic.net> <097D025D-1879-455C-BB14-F9C8BFAC88AA@ripe.net> Date: Thu, 9 Aug 2012 14:25:24 -0400 X-Google-Sender-Auth: G01uqlTlHfLQqDdft0GujQifb_M Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr wg , George Michaelson Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 18:25:25 -0000 an interesting outgrowth of the grandparenting could be the ability to 'avoid' LEA actions at middle tiers of the address allocation heirarchy... that's something to consider, i'd say. On Thu, Aug 9, 2012 at 10:50 AM, Randy Bush wrote: > tim, > > i see where some confusion might come from > >> I am not sure how many big ISPs / LIRs follow this discussion, but I >> expect that there commercial contractual concerns exist regarding this >> and I highly doubt that such companies will follow this document's >> advice, just because it's a standard. > > i know rirs like to speak for their members, but this document was > written by one of them :) > > as a large isp, we serve a fair number of smaller isps. i specifically > had in mind the circumstance where one of our customers failed and their > child needed support. we're engineers, and our primary concern is that > the packets get delivered. > > indeed, the contractual concerns you raise are specifically why one may > not want to disturb the child's cert while seeing that the grandchild's > packets are delivered. > > i also have concern that rirs are not seeing the needs of the community, > which includes the grandchildren (even though you do not rent integers > to them directly). > > the issue here is operational packet delivery, not rir policy. > > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From andy@arin.net Thu Aug 9 13:26:20 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C516021F8606 for ; Thu, 9 Aug 2012 13:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DV5rl8MIrnNv for ; Thu, 9 Aug 2012 13:26:18 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id A4F8F21F8610 for ; Thu, 9 Aug 2012 13:26:18 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 19F3B1656FF; Thu, 9 Aug 2012 16:26:15 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 9F21B1656FB; Thu, 9 Aug 2012 16:26:14 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Thu, 9 Aug 2012 16:25:51 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.124]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0298.004; Thu, 9 Aug 2012 16:26:06 -0400 From: Andy Newton To: Alexey Melnikov Thread-Topic: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting Thread-Index: AQHNcmy8FCcE8Dzhaka0MZcJTJP7npdSOKCA Date: Thu, 9 Aug 2012 20:26:06 +0000 Message-ID: <68475FFA-CD1E-44DC-A588-5799D1DD9CDE@arin.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="us-ascii" Content-ID: <8D6DB9D7A3B4654187F1D63F5FFC0468@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 20:26:20 -0000 On Aug 4, 2012, at 2:12 PM, Alexey Melnikov wrote: > On behalf of SIDR WG chairs I would like to initiate 2 weeks acceptance c= all for draft-ymbk-rpki-grandparenting starting from today, August 4th. Ple= ase send your positive or negative feedback to the mailing list or directly= to chairs. In its present form, I do not believe this draft is acceptable as a working= group document. In addition to the issue Byron pointed out about the incompatibility of thi= s document with the 6484 CP, there are a number of other issues that should= be addressed. 1. Section 1 and Section 3 could be made more readable with the use of tree= diagrams describing the relationships and reworking of the paragraphs to s= etup the relationship of the entities from the described scenarios. At pres= ent, the prose can be difficult to read. 2. Section 4 notes social engineering attacks but does not clearly enumerat= e the damage done by such attacks. This section should more clearly and exp= ressly talk to the danger and damage to the RPKI system should such attacks= be successful. 3. If paragraph 4 of section 1 is suggesting that RIRs develop grandchild/g= randparent policies and that ISPs insert grandchild/grandparent contract cl= auses, that should probably be more explicitly stated. 4. This draft does not list or describe situations where and at what levels= this type of grandparenting may not be appropriate. Nor does it provide su= ggestions with regards about resolving conflicts (are grandchildren always = allowed to go to their grandparents?). 5. It is not clear why this draft is necessary given the mechanisms availab= le in 3779 and the RPKI ecosystem (this is the point Terry was speaking of)= . This draft should be more assertive about its own necessity. Thinking about this, it may be that #3 and #5 are intertwined and that reso= lving one resolves the other. Also it maybe that #4 and #5 will be resolved= when the CP issue is resolved. But from my reading of this document, none = of this is clear. -andy= From aservin@lacnic.net Thu Aug 9 14:26:48 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC88521F8605 for ; Thu, 9 Aug 2012 14:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.283 X-Spam-Level: X-Spam-Status: No, score=-1.283 tagged_above=-999 required=5 tests=[AWL=-1.316, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_DIALUP=0.862, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0v9Q2ohKriO for ; Thu, 9 Aug 2012 14:26:42 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4C521F8602 for ; Thu, 9 Aug 2012 14:26:42 -0700 (PDT) Received: from [192.168.1.145] (r186-49-10-40.dialup.adsl.anteldata.net.uy [186.49.10.40]) by mail.lacnic.net.uy (Postfix) with ESMTP id 0D9A0308436; Thu, 9 Aug 2012 18:26:39 -0300 (UYT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Arturo Servin In-Reply-To: Date: Thu, 9 Aug 2012 18:26:38 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2AFC5260-21B3-4AB3-95B1-A7B9DEAA5EA7@lacnic.net> References: <53D504DF-C0A3-4CFC-AD93-689630336F7D@apnic.net> <097D025D-1879-455C-BB14-F9C8BFAC88AA@ripe.net> To: Christopher Morrow X-Mailer: Apple Mail (2.1084) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: George Michaelson , sidr wg Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 21:26:48 -0000 Yes, and that's is why I have double feelings. I concur with you about the usability to 'overcome' LEA actions = but also I agree with others about some of the negative sides. I think = the draft has good intentions but IMHO it needs more thinking. Otherwise = it could create more problems than solving them. =09 I will keep trying to digest it, and f I have something more = constructive to say I will. Regards, as On 9 Aug 2012, at 15:25, Christopher Morrow wrote: > an interesting outgrowth of the grandparenting could be the ability to > 'avoid' LEA actions at middle tiers of the address allocation > heirarchy... that's something to consider, i'd say. >=20 > On Thu, Aug 9, 2012 at 10:50 AM, Randy Bush wrote: >> tim, >>=20 >> i see where some confusion might come from >>=20 >>> I am not sure how many big ISPs / LIRs follow this discussion, but I >>> expect that there commercial contractual concerns exist regarding = this >>> and I highly doubt that such companies will follow this document's >>> advice, just because it's a standard. >>=20 >> i know rirs like to speak for their members, but this document was >> written by one of them :) >>=20 >> as a large isp, we serve a fair number of smaller isps. i = specifically >> had in mind the circumstance where one of our customers failed and = their >> child needed support. we're engineers, and our primary concern is = that >> the packets get delivered. >>=20 >> indeed, the contractual concerns you raise are specifically why one = may >> not want to disturb the child's cert while seeing that the = grandchild's >> packets are delivered. >>=20 >> i also have concern that rirs are not seeing the needs of the = community, >> which includes the grandchildren (even though you do not rent = integers >> to them directly). >>=20 >> the issue here is operational packet delivery, not rir policy. >>=20 >> randy >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From randy@psg.com Thu Aug 9 20:18:23 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D813911E80A5 for ; Thu, 9 Aug 2012 20:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rW7uK88G1mWt for ; Thu, 9 Aug 2012 20:18:23 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 8606111E8087 for ; Thu, 9 Aug 2012 20:18:23 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Szfjs-0005RA-I9; Fri, 10 Aug 2012 03:18:16 +0000 Date: Thu, 09 Aug 2012 23:18:26 -0400 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <53D504DF-C0A3-4CFC-AD93-689630336F7D@apnic.net> <097D025D-1879-455C-BB14-F9C8BFAC88AA@ripe.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg , George Michaelson Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 03:18:24 -0000 > an interesting outgrowth of the grandparenting could be the ability to > 'avoid' LEA actions at middle tiers of the address allocation > heirarchy... that's something to consider, i'd say. yep. the point is o this is not pretty o but it is well defined o and can be useful as a hack around breakage so i wrote it up randy From bje@apnic.net Thu Aug 9 21:36:43 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03CBE11E80D9 for ; Thu, 9 Aug 2012 21:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id peXjGHG-GjPn for ; Thu, 9 Aug 2012 21:36:42 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 7DEB111E80D7 for ; Thu, 9 Aug 2012 21:36:41 -0700 (PDT) Received: from [IPv6:2001:dc0:a000:4:c433:b84f:e7bf:7e70] (unknown [IPv6:2001:dc0:a000:4:c433:b84f:e7bf:7e70]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id B7FAAB686C; Fri, 10 Aug 2012 14:36:37 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_6893C932-EF75-41D0-9CE9-6F3CDDAB2CF7"; protocol="application/pkcs7-signature"; micalg=sha1 From: Byron Ellacott In-Reply-To: Date: Fri, 10 Aug 2012 14:36:37 +1000 Message-Id: References: <53D504DF-C0A3-4CFC-AD93-689630336F7D@apnic.net> <097D025D-1879-455C-BB14-F9C8BFAC88AA@ripe.net> To: Christopher Morrow X-Mailer: Apple Mail (2.1278) Cc: George Michaelson , sidr wg Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 04:36:43 -0000 --Apple-Mail=_6893C932-EF75-41D0-9CE9-6F3CDDAB2CF7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 10/08/2012, at 4:25 AM, Christopher Morrow wrote: > an interesting outgrowth of the grandparenting could be the ability to > 'avoid' LEA actions at middle tiers of the address allocation > heirarchy... that's something to consider, i'd say. I don't believe this is true. If C has taken some action, LEA triggered or otherwise, that means the = RPKI system no longer asserts that G's intent for packet delivery is = true, then merely allowing G to issue an RPKI assertion does not prevent = C from asserting whatever they like, too. If a LEA requires C to issue = an AS0 ROA 10.42.2.0/23, then creating an ASn ROA for the same prefix, = same maxLength will not ensure packets are delivered correctly. Perhaps the underlying operational problem where A is not quite sure yet = of C's status could be better addressed by section 4.9.4 of the CPS - if = A has been convinced that G is the current holder of the resources, A = could register the change of holding, but include in their CPS that they = may provide a grace period for revocation on a case by case basis. (If A has not been convinced that G is the current holder of the = resources, then delivering packets to G for those resources would not be = a positive engineering outcome, it would be deliberately mis-directing = packets, which the RPKI is intended to prevent!) Byron, speaking only for myself --Apple-Mail=_6893C932-EF75-41D0-9CE9-6F3CDDAB2CF7 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEBjCCBAIw ggLqoAMCAQICCCoPITf60ZNDMA0GCSqGSIb3DQEBBQUAMHMxETAPBgNVBAMMCHN0YWZmLWNhMRIw EAYDVQQLDAlUZWNobmljYWwxFjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNi YW5lMRIwEAYKCZImiZPyLGQBGRYCY2ExCzAJBgNVBAYTAkFVMB4XDTExMTEyODAxNTEzNloXDTEy MTEyNzAxNTEzNlowgZIxGTAXBgoJkiaJk/IsZAEBDAliamUtc3RhZmYxEjAQBgNVBAMMCWJqZS1z dGFmZjEOMAwGA1UEKgwFQnlyb24xETAPBgNVBAQMCEVsbGFjb3R0MQ8wDQYDVQQLDAZQZW9wbGUx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxFTATBgoJkiaJk/IsZAEZFgVzdGFmZjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBANVQo/BOmY5CCWNeAldlgoWZKOzIZpOsFzD6NB2oAErtclDu uiZsXfl+L97UOwUlhu1eGlY5gKuAhGcrEBvDgTT1eEr3vkdKILhJw78s5n8eLOWrmhPKBnW8gSn9 7MbAxVQx3V1/RpToKAF8cR4il03Z7mveaBQbaivM2jReHcgfJPt9w0qhTVZO2POLuVClRcExaNt1 h+QdMLa6VU5x7rJo9JFqjTAvJzMApW+WY/7oumR9+4a9ZGThlETI2b83XAMrrJ7DHm237Jskgl+X FGILIq8zOhNiAbhEg+gAyJ8bOzwwydDY+ggWQ466duZZq4wxmr1+YhxVf51v2R5MSicCAwEAAaN6 MHgwHQYDVR0OBBYEFIQXSivz3cLpaFy23DdhpGhyyo5pMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgw FoAU4D23klvuLqOyPnnbRaswQi8BS6wwDgYDVR0PAQH/BAQDAgHyMBgGA1UdEQQRMA+BDWJqZUBh cG5pYy5uZXQwDQYJKoZIhvcNAQEFBQADggEBAEk9zi8BTUEY4rqDGEIFDNIpmX/yS3fTah39Mele pV93sRsjqLy2G47vhhnkgSTEWV2jJOD7tjzjswxtWUL6KG36dUDVL3XbQ1OObxkiDJbqje4BoWrd a8/5PoIPC0hkSDXGoitvoXkL8Pd9x9Y+kyMlKo1C0lk5bCUG4yjk5wVLuSSm5m+KZ3+YVdPp6dKp C0DRhvFdsrz2zIOT/sWheCQO0HRU300UYngB/xoqc1KWH2dROIUhLqwtyoCQbQKQjW9C+JMMw2Ij vfVXJZGMWjbp5l8RQeUSJ+0vVJXJbIL6PfEsyQupUV3AJsSTRmtllqzCBCz2Abd14xyeqw0eJfwx ggMtMIIDKQIBATB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwxFjAU BgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQBGRYC Y2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzAJBgUrDgMCGgUAoIIBgzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA4MTAwNDM2MzdaMCMGCSqGSIb3DQEJBDEWBBQP lkwQAtJRxZIXl9HtN8OFXT8f6zCBjwYJKwYBBAGCNxAEMYGBMH8wczERMA8GA1UEAwwIc3RhZmYt Y2ExEjAQBgNVBAsMCVRlY2huaWNhbDEWMBQGA1UECgwNQVBOSUMgUHR5IEx0ZDERMA8GA1UEBwwI QnJpc2JhbmUxEjAQBgoJkiaJk/IsZAEZFgJjYTELMAkGA1UEBhMCQVUCCCoPITf60ZNDMIGRBgsq hkiG9w0BCRACCzGBgaB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQB GRYCY2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzANBgkqhkiG9w0BAQEFAASCAQBmkF34zOkjMGax 3exRpy3N1mKHcXUtzSdhJtbEC3Bs1K0Ysk10X+Ou8aZYtj1bgD0wtr4HSp4PtX0NUriO3s2yYbiF Q3jiGF5JlNJFywjwI1frRuFNe/+pZXqbba9/m4b3Y0PxE2qKp+bnk4K8lMdLB0/aiSJQEcDqnK4U IXf4u0ntkhyY95lbifRyilGVEdWZ96gO5RVJWSf/cSMXCVEm0goIi8jvqdvaV7BcDTUjeJVTioqC uqpcV7ZE71ZCktnoXB9fR8ppzf3Y6ydq5wfXYnAyeOOqyYfMHUHK5csenfuUAf8ZBAJBh9A1Izzw saHjowOZDrmUMIj6fnwqOFZ4AAAAAAAA --Apple-Mail=_6893C932-EF75-41D0-9CE9-6F3CDDAB2CF7-- From dougm@nist.gov Thu Aug 9 22:03:29 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8006221F85E1 for ; Thu, 9 Aug 2012 22:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.38 X-Spam-Level: X-Spam-Status: No, score=-6.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+YiiZdmTDfp for ; Thu, 9 Aug 2012 22:03:28 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 752B121F85E0 for ; Thu, 9 Aug 2012 22:03:27 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 10 Aug 2012 01:02:52 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 10 Aug 2012 01:03:00 -0400 From: "Montgomery, Douglas" To: Byron Ellacott , Christopher Morrow Date: Fri, 10 Aug 2012 01:02:44 -0400 Thread-Topic: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting Thread-Index: Ac12tTUdY3BRB580QdujWrWp6QE2TA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: George Michaelson , sidr wg Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 05:03:29 -0000 On 8/10/12 12:36 AM, "Byron Ellacott" wrote: >Hi, > >On 10/08/2012, at 4:25 AM, Christopher Morrow wrote: > >> an interesting outgrowth of the grandparenting could be the ability to >> 'avoid' LEA actions at middle tiers of the address allocation >> heirarchy... that's something to consider, i'd say. > >I don't believe this is true. > >If C has taken some action, LEA triggered or otherwise, that means the >RPKI system no longer asserts that G's intent for packet delivery is >true, then merely allowing G to issue an RPKI assertion does not prevent >C from asserting whatever they like, too. If a LEA requires C to issue >an AS0 ROA 10.42.2.0/23, then creating an ASn ROA for the same prefix, >same maxLength will not ensure packets are delivered correctly. The way I understand http://tools.ietf.org/html/draft-ietf-sidr-pfx-validate-08, if there is a valid ROA that matches a route, and a valid AS0 ROA that also covers the route, the route will be considered VALID. AS0 ROAs don't "trump" other valid ROAs. > >Perhaps the underlying operational problem where A is not quite sure yet >of C's status could be better addressed by section 4.9.4 of the CPS - if >A has been convinced that G is the current holder of the resources, A >could register the change of holding, but include in their CPS that they >may provide a grace period for revocation on a case by case basis. > >(If A has not been convinced that G is the current holder of the >resources, then delivering packets to G for those resources would not be >a positive engineering outcome, it would be deliberately mis-directing >packets, which the RPKI is intended to prevent!) > > Byron, speaking only for myself > dougm --=20 Doug Montgomery =AD Mgr. Internet & Scalable Systems Research / ITL / NIST From bje@apnic.net Thu Aug 9 22:18:31 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 292F621F8523 for ; Thu, 9 Aug 2012 22:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z04O01UmXjo9 for ; Thu, 9 Aug 2012 22:18:30 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 2378221F8517 for ; Thu, 9 Aug 2012 22:18:29 -0700 (PDT) Received: from [IPv6:2001:dc0:a000:4:c433:b84f:e7bf:7e70] (unknown [IPv6:2001:dc0:a000:4:c433:b84f:e7bf:7e70]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 950CDB686C; Fri, 10 Aug 2012 15:18:28 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_9EB1072E-F977-4EB0-8509-E7A08E06A355"; protocol="application/pkcs7-signature"; micalg=sha1 From: Byron Ellacott In-Reply-To: Date: Fri, 10 Aug 2012 15:18:28 +1000 Message-Id: References: To: "Montgomery, Douglas" X-Mailer: Apple Mail (2.1278) Cc: sidr wg Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 05:18:31 -0000 --Apple-Mail=_9EB1072E-F977-4EB0-8509-E7A08E06A355 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Doug, On 10/08/2012, at 3:02 PM, Montgomery, Douglas wrote: > On 8/10/12 12:36 AM, "Byron Ellacott" wrote: >=20 >> If C has taken some action, LEA triggered or otherwise, that means = the >> RPKI system no longer asserts that G's intent for packet delivery is >> true, then merely allowing G to issue an RPKI assertion does not = prevent >> C from asserting whatever they like, too. If a LEA requires C to = issue >> an AS0 ROA 10.42.2.0/23, then creating an ASn ROA for the same = prefix, >> same maxLength will not ensure packets are delivered correctly. >=20 > The way I understand > http://tools.ietf.org/html/draft-ietf-sidr-pfx-validate-08, if there = is a > valid ROA that matches a route, and a valid AS0 ROA that also covers = the > route, the route will be considered VALID. >=20 > AS0 ROAs don't "trump" other valid ROAs. Substitute "ASm" for "AS0" in my example. I believe you're right about AS 0. I was taking the first sentence of = the Security Considerations of draft-ietf-idr-as0 [1] too literally; AS0 = ROAs are not entirely equivalent to BOAs, after all :-) (But this is sort of my point, the RPKI system's verification of right = of use breaks down if you start certifying multiple people as having a = simultaneous right to use resources :-) Byron [1] http://tools.ietf.org/html/draft-ietf-idr-as0 --Apple-Mail=_9EB1072E-F977-4EB0-8509-E7A08E06A355 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEBjCCBAIw ggLqoAMCAQICCCoPITf60ZNDMA0GCSqGSIb3DQEBBQUAMHMxETAPBgNVBAMMCHN0YWZmLWNhMRIw EAYDVQQLDAlUZWNobmljYWwxFjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNi YW5lMRIwEAYKCZImiZPyLGQBGRYCY2ExCzAJBgNVBAYTAkFVMB4XDTExMTEyODAxNTEzNloXDTEy MTEyNzAxNTEzNlowgZIxGTAXBgoJkiaJk/IsZAEBDAliamUtc3RhZmYxEjAQBgNVBAMMCWJqZS1z dGFmZjEOMAwGA1UEKgwFQnlyb24xETAPBgNVBAQMCEVsbGFjb3R0MQ8wDQYDVQQLDAZQZW9wbGUx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxFTATBgoJkiaJk/IsZAEZFgVzdGFmZjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBANVQo/BOmY5CCWNeAldlgoWZKOzIZpOsFzD6NB2oAErtclDu uiZsXfl+L97UOwUlhu1eGlY5gKuAhGcrEBvDgTT1eEr3vkdKILhJw78s5n8eLOWrmhPKBnW8gSn9 7MbAxVQx3V1/RpToKAF8cR4il03Z7mveaBQbaivM2jReHcgfJPt9w0qhTVZO2POLuVClRcExaNt1 h+QdMLa6VU5x7rJo9JFqjTAvJzMApW+WY/7oumR9+4a9ZGThlETI2b83XAMrrJ7DHm237Jskgl+X FGILIq8zOhNiAbhEg+gAyJ8bOzwwydDY+ggWQ466duZZq4wxmr1+YhxVf51v2R5MSicCAwEAAaN6 MHgwHQYDVR0OBBYEFIQXSivz3cLpaFy23DdhpGhyyo5pMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgw FoAU4D23klvuLqOyPnnbRaswQi8BS6wwDgYDVR0PAQH/BAQDAgHyMBgGA1UdEQQRMA+BDWJqZUBh cG5pYy5uZXQwDQYJKoZIhvcNAQEFBQADggEBAEk9zi8BTUEY4rqDGEIFDNIpmX/yS3fTah39Mele pV93sRsjqLy2G47vhhnkgSTEWV2jJOD7tjzjswxtWUL6KG36dUDVL3XbQ1OObxkiDJbqje4BoWrd a8/5PoIPC0hkSDXGoitvoXkL8Pd9x9Y+kyMlKo1C0lk5bCUG4yjk5wVLuSSm5m+KZ3+YVdPp6dKp C0DRhvFdsrz2zIOT/sWheCQO0HRU300UYngB/xoqc1KWH2dROIUhLqwtyoCQbQKQjW9C+JMMw2Ij vfVXJZGMWjbp5l8RQeUSJ+0vVJXJbIL6PfEsyQupUV3AJsSTRmtllqzCBCz2Abd14xyeqw0eJfwx ggMtMIIDKQIBATB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwxFjAU BgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQBGRYC Y2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzAJBgUrDgMCGgUAoIIBgzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA4MTAwNTE4MjhaMCMGCSqGSIb3DQEJBDEWBBRT JcFPM9LFv5NMVmP9XYeL11BrvTCBjwYJKwYBBAGCNxAEMYGBMH8wczERMA8GA1UEAwwIc3RhZmYt Y2ExEjAQBgNVBAsMCVRlY2huaWNhbDEWMBQGA1UECgwNQVBOSUMgUHR5IEx0ZDERMA8GA1UEBwwI QnJpc2JhbmUxEjAQBgoJkiaJk/IsZAEZFgJjYTELMAkGA1UEBhMCQVUCCCoPITf60ZNDMIGRBgsq hkiG9w0BCRACCzGBgaB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQB GRYCY2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzANBgkqhkiG9w0BAQEFAASCAQAqtsAlJlzBpZzM ej6RVGuN4YASXMF5L9gOvP1j3VzAHNCKP5nRyKdF12ykJREI8a+CCp2WRowjg9AO+mHNlyyO2Xe8 R2v+x3DJVtTHsKFjW+LQXGNSVsUbMMbiPzXMSNUH4S/A7gAb+dZMCgmaSk+ytpnCY1rsjCoTVUnu 17neWBeqwQRzHtmZ6s4xZrwq3EZR7R5ZzEiNkQY+XnVzZlrLwuPNLotOsTCcnhTr/mSR0MHBNybq aFywe2dssqJbdtS2BLqHnil3x4HR1ewgOksFjYQWnU4FerI5g01bqH2Wa1rcwLp+cgoRYGGdkHxn WJeLcu+5IpF56f0eZL0PoVUeAAAAAAAA --Apple-Mail=_9EB1072E-F977-4EB0-8509-E7A08E06A355-- From dougm@nist.gov Thu Aug 9 22:46:23 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5229611E80E8 for ; Thu, 9 Aug 2012 22:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.424 X-Spam-Level: X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ss5g4xNbr7nq for ; Thu, 9 Aug 2012 22:46:22 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 87C2B11E80E5 for ; Thu, 9 Aug 2012 22:46:22 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 10 Aug 2012 01:46:13 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 10 Aug 2012 01:46:21 -0400 From: "Montgomery, Douglas" To: Byron Ellacott Date: Fri, 10 Aug 2012 01:46:06 -0400 Thread-Topic: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting Thread-Index: Ac12u0Oj+JJlKOIhQKqRILhjK0D7yw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 05:46:23 -0000 Hi Byron, On 8/10/12 1:18 AM, "Byron Ellacott" wrote: >Hi Doug, > >On 10/08/2012, at 3:02 PM, Montgomery, Douglas wrote: > >> On 8/10/12 12:36 AM, "Byron Ellacott" wrote: >>=20 >>> If C has taken some action, LEA triggered or otherwise, that means the >>> RPKI system no longer asserts that G's intent for packet delivery is >>> true, then merely allowing G to issue an RPKI assertion does not >>>prevent >>> C from asserting whatever they like, too. If a LEA requires C to issue >>> an AS0 ROA 10.42.2.0/23, then creating an ASn ROA for the same prefix, >>> same maxLength will not ensure packets are delivered correctly. >>=20 >> The way I understand >> http://tools.ietf.org/html/draft-ietf-sidr-pfx-validate-08, if there is >>a >> valid ROA that matches a route, and a valid AS0 ROA that also covers the >> route, the route will be considered VALID. >>=20 >> AS0 ROAs don't "trump" other valid ROAs. > >Substitute "ASm" for "AS0" in my example. It doesn't change the logic. The validation algorithm basically searches for a match first, only if one is not found is the issue of other non-matching ROAs considered. That being, if no match is found and their exists at least one covering ROA, then the route is INVALID. You can not change a VALID route to any other state by creating additional valid ROAs. You have to delete (revoke, etc) the valid matching ROAs to achieve that. Creating a (covering) ROA can change an UNKNOW to an INVALID. =20 > >I believe you're right about AS 0. I was taking the first sentence of >the Security Considerations of draft-ietf-idr-as0 [1] too literally; AS0 >ROAs are not entirely equivalent to BOAs, after all :-) > >(But this is sort of my point, the RPKI system's verification of right of >use breaks down if you start certifying multiple people as having a >simultaneous right to use resources :-) The issues above can occur even when there is only a single issuer of such ROAs. While draft-ietf-idr-as0 and RFC6491 deal with what the semantics that a single given AS0 ROA conveys, neither draft (maybe rightly so) goes into the level of detail to note there might exist other valid ROAs that contradict the semantics of a AS0 ROA. I would agree on a weaker statement, that we should discuss and come to some understanding about issues of consistency associated with overlapping attestations from multiple levels of the resource hierarchy and/or a single holder. The current syntax of our objects and validation algorithms allow considerable flexibility here. If, and where policies should curtail some of this flexibility is what we are discussing. > > Byron > >[1] http://tools.ietf.org/html/draft-ietf-idr-as0 > -- Doug Montgomery =AD Mgr. Internet & Scalable Systems Research / ITL / NIST > From bje@apnic.net Fri Aug 10 00:40:52 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93C1521F8513 for ; Fri, 10 Aug 2012 00:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbiXAhn5CWHX for ; Fri, 10 Aug 2012 00:40:52 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id A334121F850D for ; Fri, 10 Aug 2012 00:40:51 -0700 (PDT) Received: from [IPv6:2001:dc0:a000:4:c433:b84f:e7bf:7e70] (unknown [IPv6:2001:dc0:a000:4:c433:b84f:e7bf:7e70]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 007FEB686C; Fri, 10 Aug 2012 17:40:49 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_AA4F5746-0D14-4D06-BD9C-9CB3B416590C"; protocol="application/pkcs7-signature"; micalg=sha1 From: Byron Ellacott In-Reply-To: Date: Fri, 10 Aug 2012 17:40:48 +1000 Message-Id: <1822C846-D000-4382-9314-EAD518D6BA2C@apnic.net> References: To: "Montgomery, Douglas" X-Mailer: Apple Mail (2.1278) Cc: sidr wg Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 07:40:52 -0000 --Apple-Mail=_AA4F5746-0D14-4D06-BD9C-9CB3B416590C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Doug, On 10/08/2012, at 3:46 PM, Montgomery, Douglas wrote: >> Substitute "ASm" for "AS0" in my example. >=20 > You can not change a VALID route to any other state by creating = additional > valid ROAs. You have to delete (revoke, etc) the valid matching ROAs = to > achieve that. Creating a (covering) ROA can change an UNKNOW to an > INVALID. =20 You can change an INVALID route to a VALID route by creating a ROA for = it, though, and if C doesn't think G should be getting their traffic, = they could issue the ROA and announce the route and capture at least = some traffic. > I would agree on a weaker statement, that we should discuss and come = to > some understanding about issues of consistency associated with = overlapping > attestations from multiple levels of the resource hierarchy and/or a > single holder. The current syntax of our objects and validation > algorithms allow considerable flexibility here. If, and where = policies > should curtail some of this flexibility is what we are discussing. I think that's a side discussion that might be interesting, but it's = orthogonal to a draft proposing certification that is for a purpose = other than authorisation of claims of current holdings. We're not = talking about attestations at multiple levels of the resource hierarchy = with grandfathering, we're talking about issuing certificates that are = intentionally not aligned with current holdings, to enable attestations = about resources to be made before the question of who the right holder = is has been resolved. This could possibly be resolved through section 4.9.4 of the CPS = document - a CA who wishes to allow themselves the flexibility to = recognise a claim to resources from a grandchild without immediately = severing their child could note that a grace period may be provided on = revocation due to resource holding changes on a case by case basis. = This allows a grandfathering approach where the CA updates the record of = current holding, but delays the revocation of the former holder while = resolving questions about who should be the current holder - but it does = not, in my view, solve the problem of getting packets to the right = place, because "the right place" is not known until the identity of the = current holder is known. Byron --Apple-Mail=_AA4F5746-0D14-4D06-BD9C-9CB3B416590C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEBjCCBAIw ggLqoAMCAQICCCoPITf60ZNDMA0GCSqGSIb3DQEBBQUAMHMxETAPBgNVBAMMCHN0YWZmLWNhMRIw EAYDVQQLDAlUZWNobmljYWwxFjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNi YW5lMRIwEAYKCZImiZPyLGQBGRYCY2ExCzAJBgNVBAYTAkFVMB4XDTExMTEyODAxNTEzNloXDTEy MTEyNzAxNTEzNlowgZIxGTAXBgoJkiaJk/IsZAEBDAliamUtc3RhZmYxEjAQBgNVBAMMCWJqZS1z dGFmZjEOMAwGA1UEKgwFQnlyb24xETAPBgNVBAQMCEVsbGFjb3R0MQ8wDQYDVQQLDAZQZW9wbGUx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxFTATBgoJkiaJk/IsZAEZFgVzdGFmZjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBANVQo/BOmY5CCWNeAldlgoWZKOzIZpOsFzD6NB2oAErtclDu uiZsXfl+L97UOwUlhu1eGlY5gKuAhGcrEBvDgTT1eEr3vkdKILhJw78s5n8eLOWrmhPKBnW8gSn9 7MbAxVQx3V1/RpToKAF8cR4il03Z7mveaBQbaivM2jReHcgfJPt9w0qhTVZO2POLuVClRcExaNt1 h+QdMLa6VU5x7rJo9JFqjTAvJzMApW+WY/7oumR9+4a9ZGThlETI2b83XAMrrJ7DHm237Jskgl+X FGILIq8zOhNiAbhEg+gAyJ8bOzwwydDY+ggWQ466duZZq4wxmr1+YhxVf51v2R5MSicCAwEAAaN6 MHgwHQYDVR0OBBYEFIQXSivz3cLpaFy23DdhpGhyyo5pMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgw FoAU4D23klvuLqOyPnnbRaswQi8BS6wwDgYDVR0PAQH/BAQDAgHyMBgGA1UdEQQRMA+BDWJqZUBh cG5pYy5uZXQwDQYJKoZIhvcNAQEFBQADggEBAEk9zi8BTUEY4rqDGEIFDNIpmX/yS3fTah39Mele pV93sRsjqLy2G47vhhnkgSTEWV2jJOD7tjzjswxtWUL6KG36dUDVL3XbQ1OObxkiDJbqje4BoWrd a8/5PoIPC0hkSDXGoitvoXkL8Pd9x9Y+kyMlKo1C0lk5bCUG4yjk5wVLuSSm5m+KZ3+YVdPp6dKp C0DRhvFdsrz2zIOT/sWheCQO0HRU300UYngB/xoqc1KWH2dROIUhLqwtyoCQbQKQjW9C+JMMw2Ij vfVXJZGMWjbp5l8RQeUSJ+0vVJXJbIL6PfEsyQupUV3AJsSTRmtllqzCBCz2Abd14xyeqw0eJfwx ggMtMIIDKQIBATB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwxFjAU BgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQBGRYC Y2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzAJBgUrDgMCGgUAoIIBgzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA4MTAwNzQwNDlaMCMGCSqGSIb3DQEJBDEWBBQ9 r22K+JiUD2/pOuje9YLRns4ESTCBjwYJKwYBBAGCNxAEMYGBMH8wczERMA8GA1UEAwwIc3RhZmYt Y2ExEjAQBgNVBAsMCVRlY2huaWNhbDEWMBQGA1UECgwNQVBOSUMgUHR5IEx0ZDERMA8GA1UEBwwI QnJpc2JhbmUxEjAQBgoJkiaJk/IsZAEZFgJjYTELMAkGA1UEBhMCQVUCCCoPITf60ZNDMIGRBgsq hkiG9w0BCRACCzGBgaB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQB GRYCY2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzANBgkqhkiG9w0BAQEFAASCAQCQaWTraCCVstMh vPjW6Vp4InSbuVKBakXkemliOJbX5iJYEP/bK4tDiZybWwpMyK1HOpZ9K+n0MKDItI6f7KaK7IUP zzG743vYkuGxZ8Bxqh38Ygi7mdM3K+ZjZWtj/r1XiuzWH/hFzP6fSVWNpq0T/GqiXqlnn2xtpBkh 0wZHLAH+yB6YWKdwRpCFEeDUgu/RgOqLO8wLppyjpPjLQP0ZsJ/1ftSJIB/OvrbwYtIT+ZoRBAXQ GKVtqlsMmaCso5OIc4mp3gJNyklcrsMfO0hJbQHwO696eAurOSw15Qxtj5qOwbR+9JIUlhi05R+f qapPAspm4AKt3hL7Q3TKKBobAAAAAAAA --Apple-Mail=_AA4F5746-0D14-4D06-BD9C-9CB3B416590C-- From dougm@nist.gov Fri Aug 10 01:01:33 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A46021F865B for ; Fri, 10 Aug 2012 01:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.453 X-Spam-Level: X-Spam-Status: No, score=-6.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UT-yM0MaqK+J for ; Fri, 10 Aug 2012 01:01:32 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id EAD1821F85D9 for ; Fri, 10 Aug 2012 01:01:31 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 10 Aug 2012 04:01:11 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 10 Aug 2012 04:01:30 -0400 From: "Montgomery, Douglas" To: Byron Ellacott Date: Fri, 10 Aug 2012 04:01:18 -0400 Thread-Topic: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting Thread-Index: Ac12ziRcZ9J2WlnCT82NOY9MxGAhPA== Message-ID: In-Reply-To: <1822C846-D000-4382-9314-EAD518D6BA2C@apnic.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: sidr wg Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 08:01:33 -0000 On 8/10/12 3:40 AM, "Byron Ellacott" wrote: >Hi Doug, > >On 10/08/2012, at 3:46 PM, Montgomery, Douglas wrote: > >>> Substitute "ASm" for "AS0" in my example. >> >> You can not change a VALID route to any other state by creating >>additional >> valid ROAs. You have to delete (revoke, etc) the valid matching ROAs to >> achieve that. Creating a (covering) ROA can change an UNKNOW to an >> INVALID. > >You can change an INVALID route to a VALID route by creating a ROA for >it, though, and if C doesn't think G should be getting their traffic, >they could issue the ROA and announce the route and capture at least some >traffic. Agreed. > >> I would agree on a weaker statement, that we should discuss and come to >> some understanding about issues of consistency associated with >>overlapping >> attestations from multiple levels of the resource hierarchy and/or a >> single holder. The current syntax of our objects and validation >> algorithms allow considerable flexibility here. If, and where policies >> should curtail some of this flexibility is what we are discussing. > >I think that's a side discussion that might be interesting, but it's >orthogonal to a draft proposing certification that is for a purpose other >than authorisation of claims of current holdings. We're not talking >about attestations at multiple levels of the resource hierarchy with >grandfathering, we're talking about issuing certificates that are >intentionally not aligned with current holdings, to enable attestations >about resources to be made before the question of who the right holder is >has been resolved. > >This could possibly be resolved through section 4.9.4 of the CPS document >- a CA who wishes to allow themselves the flexibility to recognise a >claim to resources from a grandchild without immediately severing their >child could note that a grace period may be provided on revocation due to >resource holding changes on a case by case basis. This allows a >grandfathering approach where the CA updates the record of current >holding, but delays the revocation of the former holder while resolving >questions about who should be the current holder - but it does not, in my >view, solve the problem of getting packets to the right place, because >"the right place" is not known until the identity of the current holder >is known. > > Byron There seems to be a lot of assumptions in terms like "the right place". Are you suggesting that EE Certs/attestations for a given resource can only be made at the leaves of the allocation tree? What about attestations about aggregate routes at higher levels of the hierarchy? dougm From terry@terrym.net Fri Aug 10 04:02:22 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D6E21F8667 for ; Fri, 10 Aug 2012 04:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzH7DkISY9mb for ; Fri, 10 Aug 2012 04:02:21 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id EDC9821F8645 for ; Fri, 10 Aug 2012 04:02:20 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so2565606pbb.31 for ; Fri, 10 Aug 2012 04:02:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=GzWziTsAdfSty/x8/24DdjM4I8DEu+8SyAH61RaRVe8=; b=QHlx0+Vhe6/raFXzEAQXSZXRFXJiPzMohaljH5Wv9HWxq8dWjuUQHKZk5W4d9tdxGo gOYYjgj0hoD7cgg/SAbcpkr8avnPiaskvJ6SwoI4Kr3lVZsyJy61/xCBVFij5H65fNE4 N+8hBQK0jwNFSD40sl7OOiduW0cdAHjd0FR95JgIxGfCG4nKocGwALFyUPMjOpjIZDlb Ap0cvvlNfnEQJMG0Il/By2xNxAFbwrAEgM4p+wnuh40orc76Oj6rCOx/8JLoUDh2zoi/ alNXqoTF4uGODxVem6QjCR9lhAn/MpMOckJ5PRIUNhe/LZNuOBsd39z7BaW7uYRZ7V7S AHhA== Received: by 10.68.193.162 with SMTP id hp2mr5978018pbc.34.1344596540752; Fri, 10 Aug 2012 04:02:20 -0700 (PDT) Received: from [192.168.1.101] (c58-107-3-239.fitzg4.qld.optusnet.com.au. [58.107.3.239]) by mx.google.com with ESMTPS id qn13sm3136621pbb.71.2012.08.10.04.02.17 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Aug 2012 04:02:19 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Terry Manderson In-Reply-To: Date: Fri, 10 Aug 2012 21:02:13 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53D504DF-C0A3-4CFC-AD93-689630336F7D@apnic.net> <097D025D-1879-455C-BB14-F9C8BFAC88AA@ripe.net> To: Christopher Morrow X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQlj5JLrVNPpUiBveRZQLMgVCRRIb+tLEsd2Tok3QXCa5UkjyGlZ857WXGHDydbY+ogIJRCK Cc: sidr wg Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 11:02:22 -0000 Speaking only, and strictly, as an individual. I'm sorry Chris, I think this concern about having to 'avoid' LEA = actions is FUD worthy. Regardless if it occurs at the peak of the = hierarchy or any level underneath. I'm quite sure from time to time LEA's WILL request some organisation at = some level to "freeze" changes for a particular resource as was = experienced in the DNSChanger event when ARIN and RIPE were 'ordered' = (following proper process or not) by some LEA arrangements to stop any = changes from occurring to some whois records. LEAs from my experience do = not do these things on a whim. I would have said 5 years ago that the = LEAs simply don't understand the internet, but recent experience = suggests that they are learning rapidly. So I'm not so sure that, if a = LEA takes some action involved in an ongoing criminal case, anything we = attempt to put in play protocol wise to 'void' their intentions will = actually help anyone's cause. Just as if a LEA where to issue a 'legal = intercept' order (for those countries that have such) to your upstreams = for your internet traffic, it's really unlikely that it is something = you'll be able to avoid. And in the same breath as allowing some entity = to 'avoid' a LEA action, it also provides "others" with a = non-transparent tool (I'll let your imagination run wild with who = "others" could be) to make stuff happen to your "secure" routing. Further, in a situation when you have a trust anchor, and yes do note = the word "trust", any event that occurs at those levels above you which = violates your belief that some RPKI CA in question has acted, or been = forced to act, in your best interests will simply degrade the trust = afforded by both the certificate recipient as well as the relying = parties. Again, I think LEAs are growing to understand this, at least = the ones I have interacted with are. Ultimately that is why one would = promote that the RPKI trust anchors are issued by = good-for-the-internet-and-benevolent-fully-tranparent organisations. = Your mileage may vary, but if you don't hold the trust in a TA you were = expecting as a relying party, then this is why the local TA idea exists, = or the entire premise about being able to trust the entities responsible = for resource allocation in the resource allocation hierarchy is flawed = to begin with. So for me, I would much prefer a scenario where any action that affects = my ROAs in any way is completely transparent to me and to all relying = parties which have the belief I am practicing secure origination, such = that if some CA in the hierarchy above me issues a ROA that includes, = covers, or overlaps my resource holding then I would really love to see = my cert revoked, and listed in a CRL, as a standard course of action = first and foremost. Cheers Terry On 10/08/2012, at 4:25 AM, Christopher Morrow wrote: > an interesting outgrowth of the grandparenting could be the ability to > 'avoid' LEA actions at middle tiers of the address allocation > heirarchy... that's something to consider, i'd say. >=20 From terry@terrym.net Fri Aug 10 04:11:42 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79A6921F8671 for ; Fri, 10 Aug 2012 04:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8blrWcn6pDc for ; Fri, 10 Aug 2012 04:11:42 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id EBFA921F8669 for ; Fri, 10 Aug 2012 04:11:41 -0700 (PDT) Received: by ggnh4 with SMTP id h4so1556787ggn.31 for ; Fri, 10 Aug 2012 04:11:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Itr7MZCDKlMLBUxgGlar06KGfg/YICJfidOSdPLItbs=; b=atSwwFqz/gfH6LihO0l1veCe7+JUScR1rCdetIMzVutXRXWusxXDuLyfALv35LIsrt 3GfexRr2VpooL155yecRrDI1hqgb4PENKH+1H7siOfSocJiK7sz7uEmNllQ/SxgTYoNv CtvWdO93ux9iIUvmC2wiyTO59486M/Ib/O3gSEJ+JpDT055D6qz4YisXUDF/mLQCNwt5 b1rTdUK4Lm2jWjuDaaq6ZRMqFitqdIx/03k95tgbSkbGumZiCtPfG8bJxPiuhqNerwak NftCcvir/OHaiW2uNGiXcLX/IBQceFKuFTre86BQjMtlcHhpqw0suJAUzzp7HYjfd5Ag 1fXA== Received: by 10.66.74.195 with SMTP id w3mr5436900pav.64.1344597101235; Fri, 10 Aug 2012 04:11:41 -0700 (PDT) Received: from [192.168.1.101] (c58-107-3-239.fitzg4.qld.optusnet.com.au. [58.107.3.239]) by mx.google.com with ESMTPS id ph1sm3157178pbb.45.2012.08.10.04.11.37 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Aug 2012 04:11:40 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Terry Manderson In-Reply-To: Date: Fri, 10 Aug 2012 21:11:34 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53D504DF-C0A3-4CFC-AD93-689630336F7D@apnic.net> <097D025D-1879-455C-BB14-F9C8BFAC88AA@ripe.net> To: Randy Bush X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQkztmRS2rjK7IayQJYUcLEAKKzxTfqcFPTI/RS2toOuvEbGeMdRRfGTAd8QXKuyafUz3Hyy Cc: sidr wg Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 11:11:42 -0000 On 10/08/2012, at 1:18 PM, Randy Bush wrote: >> an interesting outgrowth of the grandparenting could be the ability = to >> 'avoid' LEA actions at middle tiers of the address allocation >> heirarchy... that's something to consider, i'd say. >=20 > yep. the point is > o this is not pretty > o but it is well defined > o and can be useful as a hack around breakage >=20 > so i wrote it up And for that I am grateful. Truly. But I think what might be of value (huge earth shattering value) is to = take this, and also an analysis of the RPKI for where actors can create = valid objects which will result in routing outcomes that are not by the = strict design of the resource holder. Such a document I think, in light of this observed functionality, is = near mandatory to identify and perhaps ultimately address the = imperfections. Not saying that RPKI and BGPSEC needs to be perfect first = go, or even that we share a common definition of "imperfection" but I = see this as a crack in the looking glass. T.= From carlosm3011@gmail.com Fri Aug 10 06:28:37 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4107A21F85DB for ; Fri, 10 Aug 2012 06:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ThySTs8H1qI for ; Fri, 10 Aug 2012 06:28:36 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4615421F85E7 for ; Fri, 10 Aug 2012 06:28:36 -0700 (PDT) Received: by yenm5 with SMTP id m5so1689449yen.31 for ; Fri, 10 Aug 2012 06:28:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=3oeRPhZpD6KAZOIlhhlCwxsY9K98PFsITdD55eAVCg4=; b=aEwFwb42NBoIqZKKEsST/s2cDb6MOBglQpbt9xg5wPDzG5s6eHQVlUCRygRXVcwhN2 bRaxja3T1YMDYJz2Y7r91XcKxpqMI9TOH69jSEzDUeuE/vNlJKruUg1o3rcWToiRaVZq qlJB0LaWS6sUPovvyLXxbwObSmHpO6upG4Aa+vt/48D9PqbMw/i322nGw9tV8bUy3xk2 jMgHHAG8iJIxGjCXK5qXzKIVa4yF2RC4SuV57o/GafPbVLSOp9ntmH38HQdoT+8DAoYZ m/slQIgNh6o7iKk8dfvDDbPUyxPdWIPj6Ft/RELHuHGgkcFGNjtLkfL32R+6JsN0zURr OmOg== Received: by 10.101.139.20 with SMTP id r20mr899230ann.38.1344605315717; Fri, 10 Aug 2012 06:28:35 -0700 (PDT) Received: from Carloss-MacBook-Pro.local (r186-54-255-218.dialup.adsl.anteldata.net.uy. [186.54.255.218]) by mx.google.com with ESMTPS id a79sm7320987yhk.16.2012.08.10.06.28.31 (version=SSLv3 cipher=OTHER); Fri, 10 Aug 2012 06:28:34 -0700 (PDT) Message-ID: <50250C7F.8060603@gmail.com> Date: Fri, 10 Aug 2012 10:28:31 -0300 From: "Carlos M. martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: sidr@ietf.org References: <53D504DF-C0A3-4CFC-AD93-689630336F7D@apnic.net> <097D025D-1879-455C-BB14-F9C8BFAC88AA@ripe.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 13:28:37 -0000 I support the concept of grandpareting. However, as others here, believe the document needs more work. I share Andy's concerns, and personally believe that if grandparenting is going to be an 'approved' practice (a RFC or even a WG draft tends to give people such feelings) then this document or other document needs to clearly state requirements for grandparents so relying parties can keep trusting the system. I'd love to see a flag somewhere that marks that a given cert/roa represents a grandchild and not a direct child. regards Carlos On 8/9/12 3:25 PM, Christopher Morrow wrote: > an interesting outgrowth of the grandparenting could be the ability to > 'avoid' LEA actions at middle tiers of the address allocation > heirarchy... that's something to consider, i'd say. > > On Thu, Aug 9, 2012 at 10:50 AM, Randy Bush wrote: >> tim, >> >> i see where some confusion might come from >> >>> I am not sure how many big ISPs / LIRs follow this discussion, but I >>> expect that there commercial contractual concerns exist regarding this >>> and I highly doubt that such companies will follow this document's >>> advice, just because it's a standard. >> >> i know rirs like to speak for their members, but this document was >> written by one of them :) >> >> as a large isp, we serve a fair number of smaller isps. i specifically >> had in mind the circumstance where one of our customers failed and their >> child needed support. we're engineers, and our primary concern is that >> the packets get delivered. >> >> indeed, the contractual concerns you raise are specifically why one may >> not want to disturb the child's cert while seeing that the grandchild's >> packets are delivered. >> >> i also have concern that rirs are not seeing the needs of the community, >> which includes the grandchildren (even though you do not rent integers >> to them directly). >> >> the issue here is operational packet delivery, not rir policy. >> >> randy >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From christopher.morrow@gmail.com Fri Aug 10 07:00:50 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0AD021F84F2 for ; Fri, 10 Aug 2012 07:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+MPE0e86Ka3 for ; Fri, 10 Aug 2012 07:00:50 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1560921F84D3 for ; Fri, 10 Aug 2012 07:00:50 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so1725588vcb.31 for ; Fri, 10 Aug 2012 07:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=+PHmQwxeHKqZe9RnFR0otG3w5RVUlx/dNpmZFJ+xr5s=; b=x1CZleVrxNGYyoQWC0TolL+VkeQ2c4VDksEEO0BCXjQOEJT9k9cuNYsctVi4j3+q4C 2Ah5ZMqVa4TVk31phMP7Q+LoJCAaCn22uS5JdeXSllEGS3MbeSaOx7IurJ4zIrXiErDy FT3v5NdXxZdhCkWj9I8GPRIvzxi+rg3+jEMSL/khi1m0q7Na/lrertpVUJkAQ1C4osKS gHFNHlXBEC/jWSX+IebNCrRP4ugmvg8HQ2U8QgtRHIUroUpaY62X4nT2Y4FNwhxruAOK zvTdaykkfYnavf3RAjyjZFugjol7PJhJGKQWmrL0BkoFABjo/4oUJ+CuCTSdCrEDLxTl aImg== MIME-Version: 1.0 Received: by 10.220.107.136 with SMTP id b8mr2517762vcp.17.1344607249567; Fri, 10 Aug 2012 07:00:49 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.58.255.197 with HTTP; Fri, 10 Aug 2012 07:00:49 -0700 (PDT) In-Reply-To: References: Date: Fri, 10 Aug 2012 10:00:49 -0400 X-Google-Sender-Auth: Hz1r9uEsWiM4uo0HFadA7x-FyR8 Message-ID: From: Christopher Morrow To: Byron Ellacott Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr wg Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 14:00:50 -0000 On Fri, Aug 10, 2012 at 1:18 AM, Byron Ellacott wrote: > (But this is sort of my point, the RPKI system's verification of right of use breaks down if you start certifying multiple people as having a simultaneous right to use resources :-) but that model has to exist as you have many situations today with a single prefix and multiple ASN for origin... there's a commentor on this thread who proposed (and got through the IESG) such a draft/rfc, in the GROW wg I believe. It's not that the system breaks down, so much as you have multiple possible VALID origins, that's not bad, it's just how the network works. Now, if you have NO ROA (unknown) it's another story, I think the point of the grandparenting draft is to 'save' a customer's customer in the case of failure at the middle layer. -chris From christopher.morrow@gmail.com Fri Aug 10 07:11:39 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF6821F8659 for ; Fri, 10 Aug 2012 07:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwzUnM2zEIF5 for ; Fri, 10 Aug 2012 07:11:38 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7D06921F856D for ; Fri, 10 Aug 2012 07:11:38 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so1737766vcb.31 for ; Fri, 10 Aug 2012 07:11:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=kNryMDE972AfrOKFRysDxjDK5esghWPcP5JRbDv50No=; b=Au5iJFQ6Nb98P+6ZqDIbizBlSobyw0Z03vz6NZxLbmk5hLvX9qFiePLTYwrMTplNtF kG+Jn6HAK61qj6UXHT8yk/xurpbt9F7V4TP8OfoggvoUqsiGARP5Solb4VQ4A1WJ+awb w2Nz2+pfJmrl/Ezy5hMS4oLTbUVtsrCfjmm+WZpyf2nWm1Ehjn+YpJ/m7JgNeZ++yMA3 QVgOghzzvkAT6h2ZzoktnHvTxacVqQzvQmfR0VSZeEA4XatKVPAXkH98Rr9dsrWotaIx dFwspgYU45wPW0Jj3ls0bNd+ASU1upduDyq2d/KrZMqdXkvxxGrbbsdyZ2+jQeb3RIwb WaVg== MIME-Version: 1.0 Received: by 10.220.215.211 with SMTP id hf19mr2513025vcb.30.1344607897884; Fri, 10 Aug 2012 07:11:37 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.58.255.197 with HTTP; Fri, 10 Aug 2012 07:11:37 -0700 (PDT) In-Reply-To: References: <53D504DF-C0A3-4CFC-AD93-689630336F7D@apnic.net> <097D025D-1879-455C-BB14-F9C8BFAC88AA@ripe.net> Date: Fri, 10 Aug 2012 10:11:37 -0400 X-Google-Sender-Auth: LoMsgR4BmjQDWk0MbUboE3bsqoM Message-ID: From: Christopher Morrow To: Terry Manderson Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr wg Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 14:11:39 -0000 On Fri, Aug 10, 2012 at 7:02 AM, Terry Manderson wrote: > I'm sorry Chris, I think this concern about having to 'avoid' LEA actions is FUD worthy. Regardless if it occurs at the peak of the hierarchy or any level underneath. hrm, so... LEA folk figuring things out aside, which I think is a valid point (they are getting smarter, and they will just move their request to the right hinge) 1) the grandparenting idea permits a party above you in the chain to make an attestation that others would believe (presuming your current attestation times out/expires). 2) there is already support for multiple valid ROA's for the same resource (1.2.3.0/24 origined by AS1 and AS2 and AS3) 3) the actions available are: a) revoke cert for resource (invalidates roas and other bits along the way) b) issue a competing roa 4) both of the above are 'fixable' with grandparenting I wasn't actually trying to frighten anyone, I was just pointing out that if the original intent was to permit someone above me to 'fix' me in the case of a problem in the middle layer(s), that intent could be used for 'good' or for 'bad'. I don't see that that is an incorrect point here. I do agree with Terry that it's certainly seems dangerous. I'm also not sure that even without enumerating the facts in a draft people wouldn't eventually figure this out on their own... -chris From Sandra.Murphy@sparta.com Fri Aug 10 07:49:35 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19EFD21F8691 for ; Fri, 10 Aug 2012 07:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqmhhFHh6rvS for ; Fri, 10 Aug 2012 07:49:34 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8A50421F8615 for ; Fri, 10 Aug 2012 07:49:34 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q7AEnWYf031865 for ; Fri, 10 Aug 2012 09:49:32 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q7AEnWTx030747 for ; Fri, 10 Aug 2012 09:49:32 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%21]) with mapi id 14.01.0355.002; Fri, 10 Aug 2012 10:49:31 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting Thread-Index: AQHNcmzBDgLmICzaeEOZLRGrqn0RiJdN2OWAgAJwHwCAAZHEAIAAPBsAgAE/YoD//9MKWA== Date: Fri, 10 Aug 2012 14:49:30 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F55562@Hermes.columbia.ads.sparta.com> References: <53D504DF-C0A3-4CFC-AD93-689630336F7D@apnic.net> <097D025D-1879-455C-BB14-F9C8BFAC88AA@ripe.net> , <50250C7F.8060603@gmail.com> In-Reply-To: <50250C7F.8060603@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 14:49:35 -0000 speaking as co-chair=0A= =0A= A reminder to the group that the question is whether to adopt this draft as= a working group work item. The content of the draft is not the discussion= point here, the acceptance for the group to work on it.=0A= =0A= Whether you like the content or not, you should say whether you think the w= g should adopt this draft.=0A= =0A= --Sandy, speaking as co-chair= From Sandra.Murphy@sparta.com Fri Aug 10 13:36:59 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3818521F86C9 for ; Fri, 10 Aug 2012 13:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2i0WeihAcSDW for ; Fri, 10 Aug 2012 13:36:58 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 1987621F8682 for ; Fri, 10 Aug 2012 13:36:57 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q7AKapLw002825 for ; Fri, 10 Aug 2012 15:36:51 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q7AKapRJ008569 for ; Fri, 10 Aug 2012 15:36:51 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%21]) with mapi id 14.01.0355.002; Fri, 10 Aug 2012 16:36:50 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: [sidr] sidr participation in the LIM scheduled for 29 Sep in Amsterday Thread-Index: Ac1wzqPuytAgR6OGTwKrhYoo46AkMQGaAOiC Date: Fri, 10 Aug 2012 20:36:49 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F556F4@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F369D5@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F369D5@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] sidr participation in the LIM scheduled for 29 Sep in Amsterday X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 20:36:59 -0000 There have been no objections to this interim meeting on the list.=0A= =0A= I consider this consensus that the interim meeting meets the approval of th= e wg.=0A= =0A= --Sandy, speaking as wg co-chair=0A= =0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy, Sa= ndra [Sandra.Murphy@sparta.com]=0A= Sent: Thursday, August 02, 2012 4:23 PM=0A= To: sidr@ietf.org=0A= Subject: [sidr] sidr participation in the LIM scheduled for 29 Sep in Ams= terday=0A= =0A= In the SIDR meeting, the interim meeting proposed for Sep was discussed.=0A= =0A= The original proposed date was 23 Sep, intended to take advantage of IETF p= lans to hold a large scale interim meeting around the RIPE meeting in Sep.= =0A= =0A= The IETF plans are now to hold the meeting on Sat 29 Sep (the Sat after RIP= E).=0A= =0A= The meeting participants indicated that they were still in favor of this me= eting. RIPE participants clarified for the group that RIPE participants te= nd to be operators, rather than strictly policy oriented.=0A= =0A= An estimate of attendance was requested by the Secretariat. About two doze= n people in the room indicated an interest in attending.=0A= =0A= All decisions must be confirmed on the list, so I ask for confirmation of t= he meeting decision in favor of this meeting.=0A= =0A= --Sandy, speaking as wg co-chair=0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From Sandra.Murphy@sparta.com Fri Aug 10 13:45:07 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25DE421F86F1 for ; Fri, 10 Aug 2012 13:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtM8cghXko7C for ; Fri, 10 Aug 2012 13:45:06 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBBB21F86EF for ; Fri, 10 Aug 2012 13:45:05 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q7AKj5St002895 for ; Fri, 10 Aug 2012 15:45:05 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q7AKj4JI008774 for ; Fri, 10 Aug 2012 15:45:04 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%21]) with mapi id 14.01.0355.002; Fri, 10 Aug 2012 16:45:04 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: RPKI <-> allocation consistency Thread-Index: Ac13EBo5wrqMsPdrRdKYnzi7/aF9Vw== Date: Fri, 10 Aug 2012 20:45:03 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F555CB@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] RPKI <-> allocation consistency X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 20:45:07 -0000 speaking as regular ol' member=0A= =0A= About allocation <-> RPKI consistency=0A= =0A= The RPKI is a certification of resource holding. Because the allocation da= tabases continue to also record allocations, there's duplication of informa= tion between the RPKI and the allocation databases.=0A= =0A= Having duplicate records of the same data always presents an issue of consi= stency. We know we have this issue (have known it from the beginning), any= resource certification outside the allocation system would, so we need to = work on how to handle it.=0A= =0A= Handling it is out-of-band. Consistency will be a matter of process, to en= sure that allocation actions are bound to issuance of consistent CA certifi= cates (if and when one is issued) and vice versa. Monitoring the two to sp= ot inconsistencies will be another process.=0A= =0A= Duplicates may be valid. There may be reasons for multiple CA certificates= being issued for exactly the same prefix space. Transfer (or at least the= only method of transfer discussed in the wg) would result in multiple CA c= ertificates being issued for exactly the same prefix space, for make-before= -break purposes.=0A= =0A= We already have a potential for inconsistency. As noted in the IAB stateme= nt on the RPKI, multiple trust anchors present a risk of conflicting certif= ications for the same address block. We do not yet have a single root trus= t anchor. No need for panic, the RIRs are aware and I trust they have proc= ess in mind to ensure consistency. (This is a contentious issue - hopeful= ly that's worded with sufficient care and balance.) But that's another cas= e where consistency is/will be ensured by process.=0A= =0A= The sky's not falling, we're OK, we can do this, etc.=0A= =0A= --Sandy, speaking as regular ol' member=0A= =0A= From Sandra.Murphy@sparta.com Fri Aug 10 13:45:45 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 969C721F861D for ; Fri, 10 Aug 2012 13:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FtvYcDppFwX for ; Fri, 10 Aug 2012 13:45:45 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0C21321F861B for ; Fri, 10 Aug 2012 13:45:44 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q7AKjiQA002898 for ; Fri, 10 Aug 2012 15:45:44 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q7AKjiIJ008798 for ; Fri, 10 Aug 2012 15:45:44 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%21]) with mapi id 14.01.0355.002; Fri, 10 Aug 2012 16:45:43 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: about grandparenting Thread-Index: AQHNdzkcHOX63dulWkagCqlNnf/eOQ== Date: Fri, 10 Aug 2012 20:45:43 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F5556C@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] about grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 20:45:45 -0000 speaking as regular ol' member=0A= =0A= This is a discussion of grandparenting, NOT a discussion of adoption of the= grandparenting draft.=0A= =0A= There have been suggestions of several different actions a grandparent migh= t do. Most of the comments so far focus on issuance of CA certificates to = a grandchild. But there are other actions a grandparent might take.=0A= =0A= For example. One action already mentioned would be issuing ROAs for the gr= andchild, by the grandparent. That doesn't disturb the consistency with th= e allocation system. We have long discussed that providers might issue ROA= s for RPKI-unprepared children. The RPKI structure allows for multiple ROA= s for the same prefix (for multihoming) and for multiple ROAS for more spec= ifics inside the same space signed by the same entity (eg for TE advertisem= ents). =0A= =0A= For example. The grandparent could also host a CA service for the child. = That's allowed and is currently practiced. Under that hosted CA service, t= he grandparent could issue a cert for the grandchild. The process controll= ing this would be a matter for the agreement about the hosting service.=0A= =0A= For example. The grandparent could issue a CA cert for the grandchild and = reclaim that address space from the child by issuing new CA certs for the c= hild that omit the reclaimed space. (For: it keeps allocation and RPKI co= nsistent. Against: it fractures allocations and can produce routing table = bloat.) I think I saw this in one message on the thread. How, when, wher= e, why, with what proof or limitations - all that is out-of-band process an= d can vary per situation.=0A= =0A= For example. The grandparent could issue a ROA that it itself was allowed = to originate the grandchild's address space, and forward traffic to the chi= ld with the expectation that the child will forward traffic to the grandchi= ld. (This only works in cases where there is continued connectivity from c= hild to grandchild.) There's no CA cert action there, so it doesn't distu= rb the consistency with the allocation system.=0A= =0A= I presume there are lots of others.=0A= =0A= Do we want to try to record the many possibilities? A complete list (ulp!)= ? Reasons for and against certain critical ones?=0A= =0A= --Sandy, speaking only as regular ol' member=0A= =0A= =0A= From aservin@lacnic.net Fri Aug 10 14:19:45 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB22021F853B for ; Fri, 10 Aug 2012 14:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B02oF60Dr1mb for ; Fri, 10 Aug 2012 14:19:45 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3FD21F8526 for ; Fri, 10 Aug 2012 14:19:44 -0700 (PDT) Received: from 85-7-200.lacnic.net.uy (unknown [200.7.85.90]) by mail.lacnic.net.uy (Postfix) with ESMTP id B3E2E30844D; Fri, 10 Aug 2012 18:19:41 -0300 (UYT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Arturo Servin In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F5556C@Hermes.columbia.ads.sparta.com> Date: Fri, 10 Aug 2012 18:19:38 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <32FD2C03-7508-43B9-9AF0-D9192A5BDD7B@lacnic.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F5556C@Hermes.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1278) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: "sidr@ietf.org" Subject: Re: [sidr] about grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 21:19:46 -0000 The problem with a grandparent is that it cannot certify a = grandchild unless it has specific information about it, normally it = would come from the son/daughter. I think the idea of the grandparent has good will, but I am not = sure that we are following the right path. Regards, as On 10 Aug 2012, at 17:45, Murphy, Sandra wrote: > speaking as regular ol' member >=20 > This is a discussion of grandparenting, NOT a discussion of adoption = of the grandparenting draft. >=20 > There have been suggestions of several different actions a grandparent = might do. Most of the comments so far focus on issuance of CA = certificates to a grandchild. But there are other actions a grandparent = might take. >=20 > For example. One action already mentioned would be issuing ROAs for = the grandchild, by the grandparent. That doesn't disturb the = consistency with the allocation system. We have long discussed that = providers might issue ROAs for RPKI-unprepared children. The RPKI = structure allows for multiple ROAs for the same prefix (for multihoming) = and for multiple ROAS for more specifics inside the same space signed by = the same entity (eg for TE advertisements). =20 >=20 > For example. The grandparent could also host a CA service for the = child. That's allowed and is currently practiced. Under that hosted CA = service, the grandparent could issue a cert for the grandchild. The = process controlling this would be a matter for the agreement about the = hosting service. >=20 > For example. The grandparent could issue a CA cert for the grandchild = and reclaim that address space from the child by issuing new CA certs = for the child that omit the reclaimed space. (For: it keeps allocation = and RPKI consistent. Against: it fractures allocations and can produce = routing table bloat.) I think I saw this in one message on the thread. = How, when, where, why, with what proof or limitations - all that is = out-of-band process and can vary per situation. >=20 > For example. The grandparent could issue a ROA that it itself was = allowed to originate the grandchild's address space, and forward traffic = to the child with the expectation that the child will forward traffic to = the grandchild. (This only works in cases where there is continued = connectivity from child to grandchild.) There's no CA cert action = there, so it doesn't disturb the consistency with the allocation system. >=20 > I presume there are lots of others. >=20 > Do we want to try to record the many possibilities? A complete list = (ulp!)? Reasons for and against certain critical ones? >=20 > --Sandy, speaking only as regular ol' member >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From aservin@lacnic.net Fri Aug 10 14:31:34 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4353021F8618 for ; Fri, 10 Aug 2012 14:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbTnwFKjLURS for ; Fri, 10 Aug 2012 14:31:33 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id AA6BE21F8564 for ; Fri, 10 Aug 2012 14:31:33 -0700 (PDT) Received: from 85-7-200.lacnic.net.uy (unknown [200.7.85.90]) by mail.lacnic.net.uy (Postfix) with ESMTP id A993F308444; Fri, 10 Aug 2012 18:31:30 -0300 (UYT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Arturo Servin In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F55562@Hermes.columbia.ads.sparta.com> Date: Fri, 10 Aug 2012 18:31:28 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53D504DF-C0A3-4CFC-AD93-689630336F7D@apnic.net> <097D025D-1879-455C-BB14-F9C8BFAC88AA@ripe.net> , <50250C7F.8060603@gmail.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F55562@Hermes.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1278) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: "sidr@ietf.org" Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 21:31:34 -0000 It is difficult to judge without considering the content.=20 =09 But I think that grandparenting is not the right approach to = solve the problem with "strangled" grandchildren, then I'm sorry to say = that I oppose to adopt. Regards, as On 10 Aug 2012, at 11:49, Murphy, Sandra wrote: > speaking as co-chair >=20 > A reminder to the group that the question is whether to adopt this = draft as a working group work item. The content of the draft is not the = discussion point here, the acceptance for the group to work on it. >=20 > Whether you like the content or not, you should say whether you think = the wg should adopt this draft. >=20 > --Sandy, speaking as co-chair > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From Sandra.Murphy@sparta.com Fri Aug 10 14:38:22 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBED21F8666 for ; Fri, 10 Aug 2012 14:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRopoonDAHGf for ; Fri, 10 Aug 2012 14:38:21 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6B021F8652 for ; Fri, 10 Aug 2012 14:38:21 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q7ALcCs9003194; Fri, 10 Aug 2012 16:38:12 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q7ALcCXE009790; Fri, 10 Aug 2012 16:38:12 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%21]) with mapi id 14.01.0355.002; Fri, 10 Aug 2012 17:38:11 -0400 From: "Murphy, Sandra" To: Byron Ellacott , "Montgomery, Douglas" Thread-Topic: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting Thread-Index: AQHNcmzBDgLmICzaeEOZLRGrqn0RiJdN2OWAgAJwHwCAAZHEAIAAPBsAgACqxoCAAAdMAIAABGUAgADEjbQ= Date: Fri, 10 Aug 2012 21:38:10 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F5575F@Hermes.columbia.ads.sparta.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 21:38:22 -0000 speaking as regular ol' member:=0A= =0A= wrt:=0A= ------=0A= (But this is sort of my point, the RPKI system's verification of right of u= se breaks down if you start certifying multiple people as having a simultan= eous right to use resources :-)=0A= ------=0A= =0A= The CA certs assert the right to use resources. The ROAs assert authorizat= ion to originate routes. That's different.=0A= =0A= There can be multiple ROAs for the same address space, so people can be mul= ti-homed. (This could maybe also be useful in AS migration cases.)=0A= =0A= I believe Doug Montgomery is right. By the algorithm for validating BGP ro= utes, issuing one ROA does not "trump" other existing ROAs, and thereby mak= e previously valid routes look invalid.=0A= =0A= --Sandy, speaking as regular ol' member=0A= =0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Byron Ella= cott [bje@apnic.net]=0A= Sent: Friday, August 10, 2012 1:18 AM=0A= To: Montgomery, Douglas=0A= Cc: sidr wg=0A= Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting= =0A= =0A= Hi Doug,=0A= =0A= On 10/08/2012, at 3:02 PM, Montgomery, Douglas wrote:=0A= =0A= > On 8/10/12 12:36 AM, "Byron Ellacott" wrote:=0A= >=0A= >> If C has taken some action, LEA triggered or otherwise, that means the= =0A= >> RPKI system no longer asserts that G's intent for packet delivery is=0A= >> true, then merely allowing G to issue an RPKI assertion does not prevent= =0A= >> C from asserting whatever they like, too. If a LEA requires C to issue= =0A= >> an AS0 ROA 10.42.2.0/23, then creating an ASn ROA for the same prefix,= =0A= >> same maxLength will not ensure packets are delivered correctly.=0A= >=0A= > The way I understand=0A= > http://tools.ietf.org/html/draft-ietf-sidr-pfx-validate-08, if there is a= =0A= > valid ROA that matches a route, and a valid AS0 ROA that also covers the= =0A= > route, the route will be considered VALID.=0A= >=0A= > AS0 ROAs don't "trump" other valid ROAs.=0A= =0A= Substitute "ASm" for "AS0" in my example.=0A= =0A= I believe you're right about AS 0. I was taking the first sentence of the = Security Considerations of draft-ietf-idr-as0 [1] too literally; AS0 ROAs a= re not entirely equivalent to BOAs, after all :-)=0A= =0A= (But this is sort of my point, the RPKI system's verification of right of u= se breaks down if you start certifying multiple people as having a simultan= eous right to use resources :-)=0A= =0A= Byron=0A= =0A= [1] http://tools.ietf.org/html/draft-ietf-idr-as0=0A= =0A= From Sandra.Murphy@sparta.com Fri Aug 10 16:21:22 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9216C11E80AD for ; Fri, 10 Aug 2012 16:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.943 X-Spam-Level: X-Spam-Status: No, score=-101.943 tagged_above=-999 required=5 tests=[AWL=-0.544, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_43=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z22dwCT2QCtW for ; Fri, 10 Aug 2012 16:21:21 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 22A1F11E80E1 for ; Fri, 10 Aug 2012 16:21:21 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q7ANLJIq003544 for ; Fri, 10 Aug 2012 18:21:20 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q7ANLJF2011340 for ; Fri, 10 Aug 2012 18:21:19 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%21]) with mapi id 14.01.0355.002; Fri, 10 Aug 2012 19:21:18 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: minutes from the IETF84 sidr meeting Thread-Index: Ac10A0820k+Gzvg6SfS+2wYvVB0UqgAGEkvVAMeNoMQ= Date: Fri, 10 Aug 2012 23:21:17 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F55748@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F52AFE@Hermes.columbia.ads.sparta.com>, <24B20D14B2CD29478C8D5D6E9CBB29F625F52BD0@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F52BD0@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] minutes from the IETF84 sidr meeting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 23:21:22 -0000 The routing ADs are urging chairs to upload minutes to the proceedings site= . =0A= =0A= Based on guidance at IETF83, I believe that when minutes are uploaded, the = etherpad version will disappear, replaced with the uploaded minutes.=0A= =0A= A few corrections and additions to the text below have been noted, although= not to the list. Minutes will be uploaded next week with corrections rece= ived by COB EDT (UTC-4) Mon 13 Aug 2013.=0A= =0A= The final minutes version deadline is:=0A= =0A= 2012-08-31 (Friday): Proceedings submission cutoff date by UTC 24:00.=0A= =0A= --Sandy=0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy, Sa= ndra [Sandra.Murphy@sparta.com]=0A= Sent: Monday, August 06, 2012 5:37 PM=0A= To: sidr@ietf.org=0A= Subject: Re: [sidr] minutes from the IETF84 sidr meeting=0A= =0A= Did not state the obvious, sorry.=0A= =0A= Please review the minutes and post any additions or corrections to the list= .=0A= =0A= --Sandy, speaking as wg co-chair=0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy, Sa= ndra [Sandra.Murphy@sparta.com]=0A= Sent: Monday, August 06, 2012 2:44 PM=0A= To: sidr@ietf.org=0A= Subject: [sidr] minutes from the IETF84 sidr meeting=0A= =0A= The meeting minutes were collected on the etherpad tool and are available a= t:=0A= =0A= http://tools.ietf.org/wg/sidr/minutes=0A= =0A= For convenience, below is a copy of the text.=0A= =0A= --Sandy=0A= =0A= =0A= SIDR=0A= August 1, 2012=0A= =0A= Note takers: John Scudder=0A= =0A= (Times provided for correlation with audio recording.)=0A= (No attempt made to capture anything that can be gleaned by reading the sli= des.)=0A= =0A= 9:03=0A= Meeting begins=0A= =0A= Reminder that authors must disclose IPR.=0A= =0A= 9:08=0A= Draft status=0A= =0A= 9:09=0A= Do we need a WG call for combining -cps documents?=0A= (various mic comments: no need, WG has already adopted the work, organizati= on of which drafts it goes in is immaterial)=0A= =0A= 9:11=0A= validation signalling dead unless authors resuscitate it=0A= =0A= 9:15=0A= randy bush: signaling draft has multiple interoperable implementations, let= 's move it forward=0A= chris morrow: it expired=0A= randy bush: will fix.=0A= =0A= 9:16=0A= randy: what needs to happen for pfx-validate to proceed?=0A= chris: I just need to do the writeup=0A= randy: ...=0A= =0A= 9:17=0A= Steve Kent presenting Unified CPS=0A= 9:20=0A= soliciting comments from WG, especially IANA, RIRs, and large ISPs=0A= 9:21=0A= sandy: have the ISPs and RIRs expressed any opinion about combining the two= cps documents?=0A= steve: we didn't ask first, we haven't received any feedback and it's been = out there for a while.=0A= (room polled, no comments)=0A= =0A= 9:22=0A= Steve presenting Local TA Management=0A= 9:23=0A= (obnoxious cell phone, please turn off your ringers)=0A= 9:29=0A= should standardize syntax to facilitate interoperable tools (editors, etc)= =0A= suggests waiting for next version to come out as it "will be an easier read= "=0A= 9:31=0A= =0A= =0A= rob austein: about standardizing the syntax, you may want to consider makin= g the syntax recommended, wait for second implementation, then standardize.= =0A= steve: please send a more detailed message to the mailing list=0A= =0A= 9:33=0A= Matt Lepinski presenting on BGPSEC Protocol=0A= 9:39=0A= technical change needed for problem: some algorithms (ECSDA) will produce d= ifferent signatures if applied twice to same data. This implies special han= dling needed for duplicate updates.=0A= 9:40=0A= randy: re-keying will change SKI, so something other than the signature wil= l change.=0A= matt: yes, ONLY the actual bits of the digital signature are to be ignored.= =0A= randy: all the implementor has to do is pay attention to the SKI.=0A= 9:41=0A= keyur: one request, please document what randy just said=0A= steve kent: if we included the hash that would be helpful=0A= steve bellovin: no=0A= kent: yo mama=0A= bellovin: sez you=0A= (in other words the minute-taker was unable to capture anything other than = a disagreement)=0A= 9:43=0A= rob austein: the router guys can recognize dups, we just had to explain how= using signature bits and SKI=0A= 9:44=0A= sam weiler: is there an attack here? if you were to revoke a cert, you'd ch= ange your SKI. but could an attacker replay the SKI and signature bits?=0A= matt: how often are you going to go through your rib-in and revalidate all = your signatures just to make sure none have expired or gone bad based on rp= ki state?=0A= matt: this is completely separable and is a general implementation dependen= t issue having to do with things that were ok when you got them but rpki st= ate has changed such that they now are not. this is unrelated to dup detect= ion.=0A= (general nodding)=0A= 9:46=0A= sriram: when you get a dup, if state changed from invalid to valid or vice-= versa that would be an issue.=0A= 9:47=0A= matt: if it's a dup, why would you bother revalidating?=0A= wes relaying padma from jabber: mic: is ML suggesting RPKI state sync with = RIB in- what woud trigger a sig check trawl thru RIB in?=0A= 9:48=0A= randy: rpki update=0A= matt: agree but not for this doc=0A= jeff haas: the property we're looking for, is that the box receiving a dup = suppresses it at that point. we want to preserve that behavior.=0A= matt: agree=0A= 9:50=0A= john scudder: is it generally the case that the SKI will change whenever th= e key changes? this isn't specific to ecdsa right?=0A= matt, rob: right=0A= padma: mic: how would that rpki update be noticed by router?=0A= randy: analogously, how does a router notice a bgp update? the tcp stream p= rovides the data. if you're asking how it matches it to the data in the rib= -in, then look at the prefix-validate document. I feel we must be missing t= he question.=0A= 9:52=0A= (some missed)=0A= randy: now I get it. a new public key comes in that covers some set of pref= ixes. fair point since rpki-rtr doesn't currently cover router keys. that i= s because the spec isn't done, we'll update rpki-rtr when needed. sorry for= misunderstanding.=0A= 9:53=0A= doug m: should be clear in spec about whether you must validate update, vs.= are allowed to skip validation step.=0A= matt: there may be disagreement on that point, we should discuss on the lis= t.=0A= (agree to disagree, move to list)=0A= 9:55=0A= john scudder: suggest making validation inside confed optional. otherwise, = looks good.=0A= matt: sounds reasonable, I'll make the change unless there's an objection.= =0A= =0A= 9:56=0A= Sandy summarizing interim=0A= =0A= 10:05=0A= eric osterweil (sp?): nice to see we're starting to model larger sets. Any = intention take this approach up to something as big as or bigger than today= 's internet, then plot performance curves to show how performance degrades = with scale? I don't mind seeing rsync included, but this kind of methodolog= y can be applied to other distribution protocols. this may teach us somethi= ng about the underlying architecture, independent of specific distribution = protocol.=0A= 10:06=0A= randy: yes.=0A= eric: that's not sufficient.=0A= randy: almost yes. i.e. we're trying to do that kind of modelling, look at = other distribution protocols. adding bittorrent, trying to do it at scale, = specifically not presuming it won't scale.=0A= eric: nothing scales forever, but don't read into my words something that's= not there.=0A= 10:08=0A= randy: coherency isn't easy to define in this case. it's a lot like dns. at= any instant in time there is no "correct" global view. some protocols (rsy= nc) will have more homogenous views than flooding protocols (bittorrent). w= e would be glad of more collaborators for the research!=0A= 10:09=0A= eric: great. I disagree that my implication was that this won't work, it's = just that any system has scaling limits. as for consistency model I don't c= are about that for micro benchmarks, where we can just focus on fetch time.= =0A= 10:11=0A= randy: this was all in the presentation.=0A= (vigorous bickering at mic, ignoring chairs)=0A= =0A= sandy (voluably): sit down and shut up=0A= =0A= tim: I think randy and rob's focus has been on how this data can be shared = between relying parties and such. We on the other hand have looked mostly a= t server load. As Eric said, there's an end to all scaling. ... Current rep= o about 4000 objects, at current size I see no issues. We're doing test and= modelling to let us forsee problems before we encounter them.=0A= 10:13=0A= randy: server load and router load are salient points. these are also susce= ptible to operational fixes. broken protocol, otoh, not so much.=0A= chris: the numbers you're using to do scaling testing. we talked in may abo= ut 2/5/10 year target numbers. today's testing should test for the projecte= d numbers. finally, a lot of the discussion that was at the mic should be r= ecapitulated on the list.=0A= 10:15=0A= randy: your two questions are, how big a number? we are shooting for 1M pre= fixes. will buy dinner for anyone who can gen the whole rpki data set from = bgp data. second, timing? totally dependent on (missed, maybe cycle/refetch= time?).=0A= 10:17=0A= eric o: thanks chris, that was what I was trying to say. 4000 sounds great,= what does that mean? (something about chickens, elephants and tigers.)=0A= tim: after paris meeting I asked on the list for people's ideas about requi= rements, not much feedback, but very happy to discuss it. also, I do believ= e that current deployment works, I just want to look to the future.=0A= 10:18=0A= rob: 1. the way I'd characterize the discussion: we have early measurements= that indicate we have the potential for a success disaster. we can get goi= ng but need to plan ahead. 2. we are starting to look at things like bittor= rent potentially even for top-level publication. we'll report back when we = have data. 3. we had a protocol observation from steve kent on friday. one = of the drawbacks of the current approach is that we don't have (something m= umble something). there is a time til next manifest, steve pointed out that= this could be a hint for time until next poll.=0A= 10:20=0A= danny mcpherson: agree with chris and randy. (something about implications = for architecture) i imagine we would see more churn in the rpki than the ac= tual routing system.=0A= 10:21=0A= sandy: geoff was on remotely on friday and gave an estimate of the size of = the routing sytsem a few years out. of course we have to design for that sc= ale.=0A= 10:22=0A= sandy: please look at interim slides, they're all available=0A= =0A= 10:27=0A= Carlos Martinez presenting on Multiple Publication Points=0A= =0A= (hilarious hijinx with recursive comments related to mic placement and use)= =0A= =0A= questions for group on slide 5; propose WG adoption=0A= =0A= 10:34=0A= rob a: ok, I oppose it. I think you're solving the problem in the wrong pla= ce. I don't see value here, I do see more complexity for relying party. put= all the names in the DNS instead of putting in lots of URIs. Also, at leas= t put in a blank line after all the URIs and the key.=0A= carlos: sure, we'll put in a blank line.=0A= 10:35=0A= randy: +1 rob. non-problem, added complexity.=0A= ruediger: don't let work on this stop you from fixing whatever problems the= current publication points have.=0A= carlos: definitely.=0A= tim: I thought this was good, I do see complexity in RP software. I think i= t's worth continuing this on-list, we won't reach consensus here.=0A= terry m: I want to see the discussion continue. I don't think it's ready fo= r wg adoption. I'd like to continue on basis of looking at format of TAL.= =0A= 10:37=0A= (name? bbn): what problem are you actually solving? what is the RP supposed= to do if presented multiple choices.=0A= carlos: we might need in the future different things we can tweak, just as = we do with the DNS. we may use it, or not, but the possibility will be ther= e. I also like the chance to remove the dependency on DNS. might let us rem= ove a circular dependency.=0A= =0A= 10:39=0A= Benno presenting on RPKI ond Origin Validation Operational Practices=0A= =0A= Don't have a full document yet, we're trying to get interest from the WG.= =0A= =0A= 10:44=0A= randy: first bullet on slide 5 -- we all know RPKI is object-based security= , I'm a little lost about 'identity and authority management' and as for 'k= ey management' is that related to how I distribute the IANA TAL? I'm a litt= le confused.=0A= benno: I think the first... I'm putting a lot of things on one pile. I'm al= so talking about who is authorized *in an organization* to touch key manage= ment.=0A= 10:46=0A= rob: as far as key management, there's an issue for (something related to p= rivate keys)=0A= 10:46=0A= doug m: phased adoption model? that's something the community has struggled= with. piloting, alerting, before going to full-on 'ignore invalid' all ove= r the world.=0A= 10:47=0A= benno: interesting to consider that. wasn't part of the scope we had in min= d.=0A= =0A= see slide 6 for questions to the WG=0A= =0A= 10:49=0A= wes george: I support the document, also agree with Doug. To go back to org= anizational issues, there is typically a gap between router and security st= aff at an operator, so yes, guidance is needed. As to questions on slide 6,= I think this would be best as a wiki, similar to v6 deployment resources. = maybe start with a draft and turn it into a wiki, but eventually a wiki is = better than bis and ter and what have you.=0A= 10:51=0A= randy: philosophically I agree with you but as an ops community we have a p= oor track record at maintaining wikis. Benno, there is some stuff in there = that should go in origin-ops. Plenty of room for co-authors!=0A= =0A= 10:52=0A= Randy presenting on grandparenting=0A= there are no slides=0A= =0A= - There are operational reasons for a large RPKI CA that has children they'= ver certified, the children's children may need grandparents to act for the= m.=0A= - Some of the circumstances are enumerated in the document. Non-exhaustive = list. I don't object to adding more, email me.=0A= - Current draft is second iteration, suggests one circumstance. Suppose som= eone big, like a large ISP or RIR who due to their operational practices ne= eds to provide a facility for grandchildren to request action, might automa= te (e.g. web portal).=0A= - This draft merely points out that this can already be supported in the ex= isting RPKI structure, and that it is an operationally needed facility.=0A= - That is all.=0A= =0A= 10:56=0A= sandy:=0A= =0A= (here endeth my contribution to the minutes)=0A= =0A= (Carlos taking over minutes)=0A= =0A= Sandy asks for clarification on the example presented on randy's grandparen= ting i-d=0A= =0A= A. Robatchevsky: what guidance does the draft actually provide? my concern = is that the rpki follows the delegation structure 1 to 1, and that this dra= ft somewhat subverts that. Technically is all posible. Why do you want to a= dvertise that?=0A= =0A= Randy: because its operationally useful.=0A= =0A= (Doug mc henry) different grandparenting schemes are possible, some of them= more useful than others. Some people concerned about non-useful uses of th= e same techniques. Certain possibilities are more indicative of a problem t= han of a solution.=0A= =0A= (Rob Austein) one way of looking at it is providing guidance on how to addr= ess these situations.=0A= =0A= (T. Manderson) as an interim measure until things smooth over=0A= =0A= (Sandy) we already have docs on parents doing things on behalf of the child= ren, i'm not sure why people find the grandchildren case more troubling tha= n the children example=0A= =0A= (Randy) due to not having obvious contract relationship=0A= =0A= (S. Kent) it's possible to do this in a way that is virtually invisible. I'= m in favour of exploring this but share some of the concerns others have ex= pressed=0A= =0A= (W. George) this wg has a lot of documents, don't understand why this has t= o be a separate doc, can be included in an existing one=0A= =0A= (Sandy) discussion of interim meetings=0A= =0A= (Sandy) in march we did not put one for August, for the date for September,= it was proposed to hold one together with the RIPE meeting in september. T= here will be a LIM (large interim meeting) on sept 29, the saturday after t= he RIPE event finishes. Chances are the venue will be the same as the RIPE = meeting. None of these are final details but pretty firm.=0A= =0A= IETF would like to know whether SIDR would hold a meeting in the LIM.=0A= =0A= (Sandy asks for opinions)=0A= =0A= (W. George) the schedule puts operational items first and policy later. We = risk losing the operators.=0A= =0A= (Randy) RIPE is different, operators stay over. People doing policy in RIPE= actually touch routers.=0A= =0A= (R. Volk) Randy's reporting is right.=0A= =0A= (W. george) I'm not sure whether other WGs considering using the LIM=0A= =0A= (R. Houssley) other WG considering it v6ops and weirds=0A= =0A= (Sandy asks for a vote, R. Houssley wants a number)=0A= =0A= The number is just over 20=0A= =0A= (Sandy)=0A= =0A= we can hope we'll get some more attendance.=0A= =0A= Beyond september: interim meetings have been productive, we need to set up = a plan. There's a nanog/arin meeting in Dallas, IETF in novebmber in Atlant= a and we can talk about December=0A= =0A= RIPE is end of sept, IETF begn of nobemer=0A= =0A= (Randy) could the chairs and authors so that the meeting in AMS is to confi= rm WG concensus from the list on all the docs we having waiting?=0A= =0A= (Randy) yes, all of them if possible=0A= =0A= (W. George) i'd like to ask the folks who routinely complain about the inte= rims what can we do to have you participate. i'm getting frustrated by that= =0A= =0A= () we don't use the meetings to make decisions=0A= =0A= () restriction, travel budget. if we can take that out of the equation, the= n it becames possible to participate=0A= =0A= (R. Volk) let me remark that all the interims have had effective remote par= ticipation. i have participated in two of them, it is actually possible=0A= =0A= (Wes Hardiger) lack of virtual blackboard=0A= =0A= (Chris) we're looking at January, we'll talk about that in November=0A= =0A= (Rob Austein) we should use the IM to have deep technical discussions and u= se the face to face in ATL to push docs out of the door=0A= =0A= (Randy) docs should be out the door before dec/jan, it would be nice to hav= e some sidr technical workshops=0A= =0A= (Sandy) only concensus i see is for sept 29 with RIPE=0A= =0A= (Sandy) we're done, thank you very much=0A= =0A= =0A= =0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From dougm@nist.gov Fri Aug 10 16:51:15 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7965A11E80D9 for ; Fri, 10 Aug 2012 16:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.474 X-Spam-Level: X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRjlKlCvRsZM for ; Fri, 10 Aug 2012 16:51:15 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id E403111E80BF for ; Fri, 10 Aug 2012 16:51:14 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 10 Aug 2012 19:51:03 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 10 Aug 2012 19:51:12 -0400 From: "Montgomery, Douglas" To: "Murphy, Sandra" , Byron Ellacott Date: Fri, 10 Aug 2012 19:51:04 -0400 Thread-Topic: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting Thread-Index: Ac13Us75D0Pg6K+BTOeFG9UyWEVe6Q== Message-ID: In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F5575F@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: sidr wg Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 23:51:15 -0000 On 8/10/12 5:38 PM, "Murphy, Sandra" wrote: >speaking as regular ol' member: > >wrt: >------ >(But this is sort of my point, the RPKI system's verification of right of >use breaks down if you start certifying multiple people as having a >simultaneous right to use resources :-) >------ > >The CA certs assert the right to use resources. The ROAs assert >authorization to originate routes. That's different. > >There can be multiple ROAs for the same address space, so people can be >multi-homed. (This could maybe also be useful in AS migration cases.) > >I believe Doug Montgomery is right. By the algorithm for validating BGP >routes, issuing one ROA does not "trump" other existing ROAs, and thereby >make previously valid routes look invalid. Certainly that is the way the the origin validation algorithm works. But as I noted before, there is text in idr-as0 and RFC6491 that *might* lead one to believe AS0 ROAs have "special powers". Some additional text, maybe in prefix-validate, to explicitly note the multiple matching ROA situation might be useful. As for grandfathering ... We seem to struggle without a clear, and/or shared technical definition of "right to use". Personally, when an ISP is allocated a block to use for customer assignment, in my mind it has the "right to use that block" (in the common language sense). Even if sub-blocks are assigned to customers. The ISP might sign other types of objects with EE certs from the aggregate block CA. As Sandy notes, right to use is a different concept than route origination authorization. If we are careful to keep those concepts distinct in the conversation ... It will help. dougm > From bje@apnic.net Sun Aug 12 21:56:38 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A568821F84DC for ; Sun, 12 Aug 2012 21:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEXKAy2Z+MsQ for ; Sun, 12 Aug 2012 21:56:38 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id B0E3321F84D3 for ; Sun, 12 Aug 2012 21:56:36 -0700 (PDT) Received: from [IPv6:2001:dc0:a000:4:487f:4999:2cae:aedd] (unknown [IPv6:2001:dc0:a000:4:487f:4999:2cae:aedd]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 03F20B685F; Mon, 13 Aug 2012 14:56:35 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_8CD8BC8A-EA14-46DE-A1AC-6BFBD3405ED0"; protocol="application/pkcs7-signature"; micalg=sha1 From: Byron Ellacott In-Reply-To: Date: Mon, 13 Aug 2012 14:56:34 +1000 Message-Id: <9573C25A-6E28-48CD-ADF6-3D823585F7FF@apnic.net> References: To: Christopher Morrow X-Mailer: Apple Mail (2.1278) Cc: sidr wg Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 04:56:38 -0000 --Apple-Mail=_8CD8BC8A-EA14-46DE-A1AC-6BFBD3405ED0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Chris, On 11/08/2012, at 12:00 AM, Christopher Morrow wrote: > On Fri, Aug 10, 2012 at 1:18 AM, Byron Ellacott wrote: >> (But this is sort of my point, the RPKI system's verification of = right of use breaks down if you start certifying multiple people as = having a simultaneous right to use resources :-) >=20 > but that model has to exist as you have many situations today with a > single prefix and multiple ASN for origin... there's a commentor on > this thread who proposed (and got through the IESG) such a draft/rfc, > in the GROW wg I believe. Sorry, I wasn't very clear there - I don't mean to suggest that an = operator should not be able to issue multiple ROAs, I mean to suggest = that a CA should not certify multiple entities as the current, unique = holder of resources, as per RFC 6484, and that it is the trust model = that breaks down when you violate the CP document, not the operational = verifiability of the bits and bytes. I have objected to adoption because it seems to me that the intent of = the draft is to create a practice of certifying two entities at once, = indefinitely; I do not object to solving a real operational problem, so = I would withdraw my objection if the draft's intent is for a strictly = transitional process, with revocation of C to be addressed somehow. I consider this an objection to adoption because the intent is not = clear. The intent can be clarified without updating the document's = content, though a content update would be necessary to express the = intent, down the line. Byron Still speaking for myself, of course. --Apple-Mail=_8CD8BC8A-EA14-46DE-A1AC-6BFBD3405ED0 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEBjCCBAIw ggLqoAMCAQICCCoPITf60ZNDMA0GCSqGSIb3DQEBBQUAMHMxETAPBgNVBAMMCHN0YWZmLWNhMRIw EAYDVQQLDAlUZWNobmljYWwxFjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNi YW5lMRIwEAYKCZImiZPyLGQBGRYCY2ExCzAJBgNVBAYTAkFVMB4XDTExMTEyODAxNTEzNloXDTEy MTEyNzAxNTEzNlowgZIxGTAXBgoJkiaJk/IsZAEBDAliamUtc3RhZmYxEjAQBgNVBAMMCWJqZS1z dGFmZjEOMAwGA1UEKgwFQnlyb24xETAPBgNVBAQMCEVsbGFjb3R0MQ8wDQYDVQQLDAZQZW9wbGUx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxFTATBgoJkiaJk/IsZAEZFgVzdGFmZjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBANVQo/BOmY5CCWNeAldlgoWZKOzIZpOsFzD6NB2oAErtclDu uiZsXfl+L97UOwUlhu1eGlY5gKuAhGcrEBvDgTT1eEr3vkdKILhJw78s5n8eLOWrmhPKBnW8gSn9 7MbAxVQx3V1/RpToKAF8cR4il03Z7mveaBQbaivM2jReHcgfJPt9w0qhTVZO2POLuVClRcExaNt1 h+QdMLa6VU5x7rJo9JFqjTAvJzMApW+WY/7oumR9+4a9ZGThlETI2b83XAMrrJ7DHm237Jskgl+X FGILIq8zOhNiAbhEg+gAyJ8bOzwwydDY+ggWQ466duZZq4wxmr1+YhxVf51v2R5MSicCAwEAAaN6 MHgwHQYDVR0OBBYEFIQXSivz3cLpaFy23DdhpGhyyo5pMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgw FoAU4D23klvuLqOyPnnbRaswQi8BS6wwDgYDVR0PAQH/BAQDAgHyMBgGA1UdEQQRMA+BDWJqZUBh cG5pYy5uZXQwDQYJKoZIhvcNAQEFBQADggEBAEk9zi8BTUEY4rqDGEIFDNIpmX/yS3fTah39Mele pV93sRsjqLy2G47vhhnkgSTEWV2jJOD7tjzjswxtWUL6KG36dUDVL3XbQ1OObxkiDJbqje4BoWrd a8/5PoIPC0hkSDXGoitvoXkL8Pd9x9Y+kyMlKo1C0lk5bCUG4yjk5wVLuSSm5m+KZ3+YVdPp6dKp C0DRhvFdsrz2zIOT/sWheCQO0HRU300UYngB/xoqc1KWH2dROIUhLqwtyoCQbQKQjW9C+JMMw2Ij vfVXJZGMWjbp5l8RQeUSJ+0vVJXJbIL6PfEsyQupUV3AJsSTRmtllqzCBCz2Abd14xyeqw0eJfwx ggMtMIIDKQIBATB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwxFjAU BgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQBGRYC Y2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzAJBgUrDgMCGgUAoIIBgzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA4MTMwNDU2MzRaMCMGCSqGSIb3DQEJBDEWBBQz Dla+rUHWkCf15pGJA1LKeqRhADCBjwYJKwYBBAGCNxAEMYGBMH8wczERMA8GA1UEAwwIc3RhZmYt Y2ExEjAQBgNVBAsMCVRlY2huaWNhbDEWMBQGA1UECgwNQVBOSUMgUHR5IEx0ZDERMA8GA1UEBwwI QnJpc2JhbmUxEjAQBgoJkiaJk/IsZAEZFgJjYTELMAkGA1UEBhMCQVUCCCoPITf60ZNDMIGRBgsq hkiG9w0BCRACCzGBgaB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQB GRYCY2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzANBgkqhkiG9w0BAQEFAASCAQC+mAjmrnNUSrl0 E5JVhXxT9Y9so82QlTJ18Zn+1zMGnCITHNctZxsdORLbvMR/7dWNmx+U5PBqOoLJtqI4hc6xao+8 COQ4wgTKByFIxtx0vEYPbjsLmFW12F4sdEq/AL6IbRc72f1J5dCPqZbvZK+WQHox1DQzxJvervoh eIpiHju2P23UfHD5Jt/gW481WtxmOyi11DVdU61H0uFq5JNmJC7pOjSrlOZ4f9Xb5WIhB8cqZ+kN eN5sGnD1ZWaWjMCxpz9sO3obT7c41UxHW+irHiOSPdRm8/9m5Xn4CgiKFb6NDdGZ28Bjr7ceIl5W mfEkX4DsQ1gIxFczm3kHdsh4AAAAAAAA --Apple-Mail=_8CD8BC8A-EA14-46DE-A1AC-6BFBD3405ED0-- From christopher.morrow@gmail.com Mon Aug 13 06:45:23 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D76121F8773 for ; Mon, 13 Aug 2012 06:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtMeR6oy8FUu for ; Mon, 13 Aug 2012 06:45:23 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id ECE9221F8772 for ; Mon, 13 Aug 2012 06:45:22 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3819447vbb.31 for ; Mon, 13 Aug 2012 06:45:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=iECKAdfaISEcv3UxmE1uEJ83pkStJ15UMaL0rDk7r4U=; b=ZsM4/Z/zy4HQTxSs9srU4amWNoEv4g7H8Avz61b9OLlijYTzM+C6AzsMDKfKN+i2WG OsdFnVBdI/mbfSZp45Sz6EtOhZc/ZB/vBh3zddEIh2UDiTWpjvmlBdiSfW3QU/hQhsAO GnNSh5RCBA+m09CLXVPU9o/QgNLK+TR7xZmzAWkbrDLxrcJQQVqxNskaRcVVEui3qBnj 8qFsA4ApVh6JVclQ85+qyEggOThUNixrn0BTe2R1TggwUwtVO0NaeLFROi2+es4ohT4S 78fJrpaHC8snQSKK36TRyrXR1H5FvDr/wqdjFHROtTHhffMBH6yFGpex9LPCRVbj7086 TPfg== MIME-Version: 1.0 Received: by 10.220.155.3 with SMTP id q3mr8281995vcw.11.1344865522384; Mon, 13 Aug 2012 06:45:22 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.58.255.197 with HTTP; Mon, 13 Aug 2012 06:45:22 -0700 (PDT) In-Reply-To: <9573C25A-6E28-48CD-ADF6-3D823585F7FF@apnic.net> References: <9573C25A-6E28-48CD-ADF6-3D823585F7FF@apnic.net> Date: Mon, 13 Aug 2012 09:45:22 -0400 X-Google-Sender-Auth: zPmxE_y0sNor9BYisIs2cSvLaUs Message-ID: From: Christopher Morrow To: Byron Ellacott Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 13:45:23 -0000 On Mon, Aug 13, 2012 at 12:56 AM, Byron Ellacott wrote: > Hi Chris, > > On 11/08/2012, at 12:00 AM, Christopher Morrow wrote: > >> On Fri, Aug 10, 2012 at 1:18 AM, Byron Ellacott wrote: >>> (But this is sort of my point, the RPKI system's verification of right = of use breaks down if you start certifying multiple people as having a simu= ltaneous right to use resources :-) >> >> but that model has to exist as you have many situations today with a >> single prefix and multiple ASN for origin... there's a commentor on >> this thread who proposed (and got through the IESG) such a draft/rfc, >> in the GROW wg I believe. > > Sorry, I wasn't very clear there - I don't mean to suggest that an operat= or should not be able to issue multiple ROAs, I mean to suggest that a CA s= hould not certify multiple entities as the current, unique holder of resour= ces, as per RFC 6484, and that it is the trust model that breaks down when = you violate the CP document, not the operational verifiability of the bits = and bytes. > ah! i agree that a CA shouldn't, ideally, certify more than 1 entity as 'owning' a resource. I think this gets at part of terry's concern(s) as well? > I have objected to adoption because it seems to me that the intent of the= draft is to create a practice of certifying two entities at once, indefini= tely; I do not object to solving a real operational problem, so I would wit= hdraw my objection if the draft's intent is for a strictly transitional pro= cess, with revocation of C to be addressed somehow. > I think the point of the doc is to fix broken downstreams... I suppose a step to de-register/de-certify could be put in the middle between 'oh crap, vzb disappeared as a business' and 'oh, johnny-vzb-customer can no longer be seen in the routing system, quick issue him a replacement cert!'. Objecting to the draft because of a missing step seems draconian... > I consider this an objection to adoption because the intent is not clear.= The intent can be clarified without updating the document's content, thou= gh a content update would be necessary to express the intent, down the line= . > if the content isn't clear then we need to rev the draft with the 'right' content, right? In principle the problem (oops, ISP12 disappeared as a business) shows up 'often' in the real world, we ought to have a documented solution to that problem, and this draft seems to aim us in that direction... sure it has some rough edges to smooth out, I'm sure the authors would welcome text for their grindstone. > Byron > Still speaking for myself, of course. me too! (though if I try speaking for others my lips still move, I'm a horrible ventriloquist) -chris From carlosm3011@gmail.com Mon Aug 13 07:10:26 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD9D21F8763 for ; Mon, 13 Aug 2012 07:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTUEDCV6d2Iw for ; Mon, 13 Aug 2012 07:10:26 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBE021F8760 for ; Mon, 13 Aug 2012 07:10:26 -0700 (PDT) Received: by ghbg16 with SMTP id g16so3355268ghb.31 for ; Mon, 13 Aug 2012 07:10:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=vD9ZMR++K/zIhftxqxluVD5Ysqf4WZBRX4YrDhgBNAs=; b=Hk/X8EsvxbWZCSjtqHbqqmHtSeX1B/zLoRg6xU19bpOou3nDS0SpbOcvGsIYC1sh4B mCKYr6bJogLo7J3Sj7c8MGsW6x3q+TPTZNrvRM6eAT8osJStBDeQmYGasaOG4eYcH0X8 bt89bvzCmicHpHEgvzU8HUU9SHJSd/8crK8UGyzkCY8wrYdEKcBWbOXQIRG3JEYNV/XL Ybm/it+Hy+YdBnGrW4jXXXY5ufuQ55lgBdg5Jf1n1NPvX8TlOJqGNA5DRIhhnrSCW5aJ u7EsMoS9ifUARGI+pOTflg4/k/MloVNBJyjEJV9ZUNj7HbCJhpyxagVEQX+YYMk9zR8a qRFQ== Received: by 10.236.75.132 with SMTP id z4mr7495305yhd.25.1344867025743; Mon, 13 Aug 2012 07:10:25 -0700 (PDT) Received: from europa.local ([200.7.85.154]) by mx.google.com with ESMTPS id e5sm13887497yhi.12.2012.08.13.07.10.12 (version=SSLv3 cipher=OTHER); Mon, 13 Aug 2012 07:10:24 -0700 (PDT) Message-ID: <50290AC4.2000904@gmail.com> Date: Mon, 13 Aug 2012 11:10:12 -0300 From: Carlos Martinez-Cagnazzo User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: sidr@ietf.org References: <53D504DF-C0A3-4CFC-AD93-689630336F7D@apnic.net> <097D025D-1879-455C-BB14-F9C8BFAC88AA@ripe.net> , <50250C7F.8060603@gmail.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F55562@Hermes.columbia.ads.sparta.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: carlos@lacnic.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 14:10:26 -0000 I didn't state it in so many words, but, here it is. At this point I 'kinda' support the concept (meaning that, like others here, have an uneasy feeling about TAs issuing certs/roas for organizations they don't have contractual relationships with), and that if some changes were considered (see my earlier comment) I would support the adoption of the document. If the question is limited to the document in its current form, then I'm sorry to say that I oppose. regards ~Carlos On 8/10/12 6:31 PM, Arturo Servin wrote: > It is difficult to judge without considering the content. > > But I think that grandparenting is not the right approach to solve the problem with "strangled" grandchildren, then I'm sorry to say that I oppose to adopt. > > > Regards, > as > > > On 10 Aug 2012, at 11:49, Murphy, Sandra wrote: > >> speaking as co-chair >> >> A reminder to the group that the question is whether to adopt this draft as a working group work item. The content of the draft is not the discussion point here, the acceptance for the group to work on it. >> >> Whether you like the content or not, you should say whether you think the wg should adopt this draft. >> >> --Sandy, speaking as co-chair >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From andy@arin.net Tue Aug 14 07:07:48 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E3721F8673 for ; Tue, 14 Aug 2012 07:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8+jUbUOyUfp for ; Tue, 14 Aug 2012 07:07:47 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCFC21F866D for ; Tue, 14 Aug 2012 07:07:47 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 2F356213635; Tue, 14 Aug 2012 10:07:46 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp2.arin.net (Postfix) with ESMTP id DAC312135F0; Tue, 14 Aug 2012 10:07:45 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.283.3; Tue, 14 Aug 2012 10:07:36 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.124]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0298.004; Tue, 14 Aug 2012 10:07:45 -0400 From: Andy Newton To: "Murphy, Sandra" Thread-Topic: [sidr] about grandparenting Thread-Index: AQHNdzkcHOX63dulWkagCqlNnf/eOZdZoPcA Date: Tue, 14 Aug 2012 14:07:44 +0000 Message-ID: References: <24B20D14B2CD29478C8D5D6E9CBB29F625F5556C@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F5556C@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <9278D56DBA75F94EBA91603924126495@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] about grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 14:07:48 -0000 On Aug 10, 2012, at 4:45 PM, Murphy, Sandra wrote: > For example. One action already mentioned would be issuing ROAs for the = grandchild, by the grandparent. That doesn't disturb the consistency with = the allocation system. I'm not speaking for anybody but me here, but I would think that the notion= of RIRs issuing "operational" ROAs would be a BIG layer 9 issue. -andy= From Sandra.Murphy@sparta.com Tue Aug 14 07:48:00 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD13721F8535 for ; Tue, 14 Aug 2012 07:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1NEvrbMSvhK for ; Tue, 14 Aug 2012 07:48:00 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id D68EF21F84FB for ; Tue, 14 Aug 2012 07:47:59 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q7EElwVM021750; Tue, 14 Aug 2012 09:47:58 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q7EElvhU012314; Tue, 14 Aug 2012 09:47:58 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%21]) with mapi id 14.01.0355.002; Tue, 14 Aug 2012 10:47:53 -0400 From: "Murphy, Sandra" To: Andy Newton Thread-Topic: [sidr] about grandparenting Thread-Index: AQHNeiY06gIEyPkyx0CA7hq/ggAKM5dZXRVV Date: Tue, 14 Aug 2012 14:47:53 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F55FB2@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F5556C@Hermes.columbia.ads.sparta.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] about grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 14:48:00 -0000 speaking as a regular ol' member:=0A= =0A= On Tuesday, August 14, 2012 10:07 AM, Andy Newton [andy@arin.net] said=0A= =0A= >I'm not speaking for anybody but me here, but I would think =0A= >that the notion of RIRs issuing "operational" ROAs would be =0A= >a BIG layer 9 issue.=0A= =0A= =0A= Given all the caveats below.=0A= =0A= If you believe RIRs should not issue ROAs, what would be your preferred met= hod to deal with that: (a) relying party policy - reject ROAs signed by x,y= ,z keys, (b) cert policy - some words in the CP (c) operational - registrie= s promise not to implement a feature in their code that would allow this (d= ) contractual - the registry agreement promises that they will not do this,= (e) technical - some bits in the RPKI objects, etc.=0A= =0A= =0A= (Why did you speak of an "operational" ROA? What would a non-operational R= OA be?)=0A= =0A= =0A= List of caveats:=0A= =0A= I presume you aren't implying that you think the RIRs will be the only or t= he primary members of the RPKI hierarchy.=0A= =0A= And of course you are not speaking of the IANA objects that are now publish= ed as an RFC.=0A= =0A= And of course you are not speaking of RIRs that have decided to run a hoste= d service for their members, where code on the RIR system is actually doing= the signing operations that create ROAs that their members have requested.= =0A= =0A= And of course you are not speaking of RIRs who hold address space for their= own operational purposes, eg for registry servers and such.=0A= =0A= In the spirit of the IANA objects, I can see a potential of an RIR signing = a ROA for the /8 from which they are allocating (or v6 equivalent) to keep = bogus superblock announcements from being accepted.=0A= =0A= --Sandy, speaking as regular ol' member=0A= =0A= From Sandra.Murphy@sparta.com Tue Aug 14 09:19:43 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4636221F869F for ; Tue, 14 Aug 2012 09:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HkG0RGt2h0p for ; Tue, 14 Aug 2012 09:19:42 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id A829C21F86D5 for ; Tue, 14 Aug 2012 09:19:42 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q7EGJfLT022935 for ; Tue, 14 Aug 2012 11:19:42 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q7EGJflM015646 for ; Tue, 14 Aug 2012 11:19:41 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%21]) with mapi id 14.01.0355.002; Tue, 14 Aug 2012 12:19:37 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: WGLC on draft-ietf-sidr-bgpsec-threats-02 Thread-Index: Ac16N6Ae407rtL9CRxWS182ULJwIzg== Date: Tue, 14 Aug 2012 16:19:37 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F5604B@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] WGLC on draft-ietf-sidr-bgpsec-threats-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 16:19:43 -0000 The authors have indicated that they believe the draft=0A= =0A= Threat Model for BGP Path Security=0A= draft-ietf-sidr-bgpsec-threats-02=0A= http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-threats-02=0A= =0A= is ready for a working group last call.=0A= =0A= This starts the two week working group last call. It will end on Aug 28. = Please review the draft and send comments to the list.=0A= =0A= --Sandy= From andy@arin.net Tue Aug 14 10:34:00 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C138B21F8796 for ; Tue, 14 Aug 2012 10:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HcR0FyRNtI1 for ; Tue, 14 Aug 2012 10:34:00 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD6A21F8794 for ; Tue, 14 Aug 2012 10:33:59 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 0182C2135AA; Tue, 14 Aug 2012 13:33:59 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 6C8D0213587; Tue, 14 Aug 2012 13:33:58 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Tue, 14 Aug 2012 13:33:18 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.124]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0298.004; Tue, 14 Aug 2012 13:33:50 -0400 From: Andy Newton To: "Murphy, Sandra" Thread-Topic: [sidr] about grandparenting Thread-Index: AQHNdzkcHOX63dulWkagCqlNnf/eOZdZoPcAgAALNYCAAC5fgA== Date: Tue, 14 Aug 2012 17:33:49 +0000 Message-ID: References: <24B20D14B2CD29478C8D5D6E9CBB29F625F5556C@Hermes.columbia.ads.sparta.com>, <24B20D14B2CD29478C8D5D6E9CBB29F625F55FB2@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F55FB2@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <30F07806A221C64FB319B99BD7898C96@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] about grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 17:34:00 -0000 On Aug 14, 2012, at 10:47 AM, Murphy, Sandra wrote: > speaking as a regular ol' member: >=20 > On Tuesday, August 14, 2012 10:07 AM, Andy Newton [andy@arin.net] said >=20 >> I'm not speaking for anybody but me here, but I would think=20 >> that the notion of RIRs issuing "operational" ROAs would be=20 >> a BIG layer 9 issue. >=20 >=20 > Given all the caveats below. >=20 > If you believe RIRs should not issue ROAs For clarification, I personally don't have an opinion on this. It is just m= y observation that there have been concerns about the roles of RIRs in the = RPKI, and this would seem to collide with such concerns. > , what would be your preferred method to deal with that: (a) relying part= y policy - reject ROAs signed by x,y,z keys, (b) cert policy - some words i= n the CP (c) operational - registries promise not to implement a feature in= their code that would allow this (d) contractual - the registry agreement = promises that they will not do this, (e) technical - some bits in the RPKI= objects, etc. A, B, C, and D are above my pay grade. E, such as a grandchild bit in a ROA= or something, is interesting but I doubt would resolve layer 9 concerns. >=20 > (Why did you speak of an "operational" ROA? What would a non-operational= ROA be?) >=20 ROAs that represent real routes, not things like IANA space. If there is a = better term, let me know. -andy= From iesg-secretary@ietf.org Tue Aug 14 12:01:56 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2938E21E803D; Tue, 14 Aug 2012 12:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fx-bZ52eJORe; Tue, 14 Aug 2012 12:01:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9865321E8040; Tue, 14 Aug 2012 12:01:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120814190155.18408.9732.idtracker@ietfa.amsl.com> Date: Tue, 14 Aug 2012 12:01:55 -0700 Cc: sidr@ietf.org Subject: [sidr] SIDR WG Interim Meeting, Saturday, September 29, 2012 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 19:01:56 -0000 The SIDR working group plans a face-to-face interim meeting on Sat 29 Sep 2= 012 in Amsterdam. The meeting will be held 0900-1700. Location will be announced later, and i= s expected to be arranged as part of the IETF Large Interim Meeting (LIM). Anticipated topics include discussion of the latest version of the bgpsec p= rotocol. At this time, the agenda will be: 0900-1130 Discussion 1130-1330 Lunch 1330-1700 Discussion Refinements of this agenda will be announced on the SIDR mailing list. Remote participation by webex or meetecho, teleconference, jabber and ether= pad will be provided as needed. Details will be announced before hand. From brian.peter.dickson@gmail.com Tue Aug 14 14:20:44 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 326CC21F8535 for ; Tue, 14 Aug 2012 14:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.348 X-Spam-Level: X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lf8H4gHPrf-R for ; Tue, 14 Aug 2012 14:20:43 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id E355421F8530 for ; Tue, 14 Aug 2012 14:20:42 -0700 (PDT) Received: by weyu54 with SMTP id u54so682593wey.31 for ; Tue, 14 Aug 2012 14:20:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zDhdl3am68NXUGgGbNIUK6X8zTj2qmcwfEz61lH0YXo=; b=XieRIGYeBrMUoh5/G9oUll7qI55mTv77klDoaZsFac7xamvqlabhl6ZGqEr3bIp+RN mGEed/z6yKHGQsHafTc/+k8+6q04ApKOv/+3TNHMI0hkU427lPbLRHbiDtCc60OQokPI 5VzyTHzky86+ayKXqAUE3w7QLZGgj9vNG1x924eDXbyvYJNv94XO/njxKayO9uXw78jZ hH4lIx4d041pW34sMTXV/We3LQtlnD6JmzILwTcnX//lD5KdX+/QwwisgKfdWYNen5tF 9oJo+Fw3CQWIUXdRduV1PddTSEmWt3e5dXXOSl2kjhm/a1vQaELA6I5Nv5xXOvrjOpKE 1ekA== MIME-Version: 1.0 Received: by 10.216.132.25 with SMTP id n25mr8461511wei.25.1344979242075; Tue, 14 Aug 2012 14:20:42 -0700 (PDT) Received: by 10.223.169.196 with HTTP; Tue, 14 Aug 2012 14:20:41 -0700 (PDT) In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F5604B@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F5604B@Hermes.columbia.ads.sparta.com> Date: Tue, 14 Aug 2012 17:20:41 -0400 Message-ID: From: Brian Dickson To: "Murphy, Sandra" Content-Type: multipart/alternative; boundary=0016e6dd8d69f4450404c74061e6 Cc: "sidr@ietf.org" Subject: Re: [sidr] WGLC on draft-ietf-sidr-bgpsec-threats-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 21:20:44 -0000 --0016e6dd8d69f4450404c74061e6 Content-Type: text/plain; charset=ISO-8859-1 I have reviewed the draft. It remains vague and incomplete, in the Residual Threats section. This, despite extensive discussion (since the -00 version) on the list regarding very specific, very real, residual threats. It not only fails to discuss them, it fails to enumerate them. The extensive discussion is in the archives, and contains substantive comments from at least 1/4 active participants in SIDR, including those with the greatest degree of operational and/or implementation experience. I would request that the WGLC be retracted until the authors decide to address those previous comments. Chairs: There should not be a need to re-raise the particulars - if the authors got shot down before, and fail to include text or address the complaints, I fail to see why they are submitting this, or the chair(s) are doing a WGLC. The objective of a threats model should be to model the threats, and identify known weaknesses. If it is substantially incomplete, it is not ready to go. It fails to accomplish its _only_ goal. Excluding threats from this doc, because the solution does not address them, is beyond ridiculous. It is laughable. Sorry if this offends the authors. The authors' work is at issue, not the authors themselves. They are fine and upstanding individuals. This ID, in its current form, however, is, IMHO, junk. Brian On Tue, Aug 14, 2012 at 12:19 PM, Murphy, Sandra wrote: > The authors have indicated that they believe the draft > > Threat Model for BGP Path Security > draft-ietf-sidr-bgpsec-threats-02 > http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-threats-02 > > is ready for a working group last call. > > This starts the two week working group last call. It will end on Aug 28. > Please review the draft and send comments to the list. > > --Sandy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --0016e6dd8d69f4450404c74061e6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have reviewed the draft.

It remains vague and incomple= te, in the Residual Threats section. This, despite extensive discussion (si= nce the -00 version) on the list regarding very specific, very real, residu= al threats.

It not only fails to discuss them, it fails to enumerat= e them.

The extensive discussion is in the archive= s, and contains substantive comments from at least 1/4 active participants = in SIDR, including those with the greatest degree of operational and/or imp= lementation experience.

I would request that the WGLC be retracted until the au= thors decide to address those previous comments.

C= hairs: There should not be a need to re-raise the particulars - if the auth= ors got shot down before, and fail to include text or address the complaint= s, I fail to see why they are submitting this, or the chair(s) are doing a = WGLC.

The objective of a threats model should be to model the= threats, and identify known weaknesses. If it is substantially incomplete,= it is not ready to go. It fails to accomplish its _only_ goal.

Excluding threats from this doc, because the solution does n= ot address them, is beyond=A0ridiculous. It is laughable.

Sorry if this offends the authors. The authors' work is at issu= e, not the authors themselves. They are fine and upstanding individuals. Th= is ID, in its current form, however, is, IMHO, junk.

Brian

On Tue, Aug 14,= 2012 at 12:19 PM, Murphy, Sandra <Sandra.Murphy@sparta.com>= wrote:
The authors have indicated that they believe= the draft

Threat Model for BGP Path Security
draft-ietf-sidr-bgpsec-threats-02
http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-threats-0= 2

is ready for a working group last call.

This starts the two week working group last call. =A0It will end on Aug 28.= =A0Please review the draft and send comments to the list.

--Sandy
_______________________________________________
sidr mailing list
sidr@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sidr

--0016e6dd8d69f4450404c74061e6-- From Sandra.Murphy@sparta.com Wed Aug 15 10:56:19 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF8D921F85A2 for ; Wed, 15 Aug 2012 10:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duly5bB05Bds for ; Wed, 15 Aug 2012 10:56:19 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF4421F859A for ; Wed, 15 Aug 2012 10:56:18 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q7FHuFj3000803; Wed, 15 Aug 2012 12:56:16 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q7FHuFar014594; Wed, 15 Aug 2012 12:56:15 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%21]) with mapi id 14.01.0355.002; Wed, 15 Aug 2012 13:56:10 -0400 From: "Murphy, Sandra" To: Brian Dickson Thread-Topic: [sidr] WGLC on draft-ietf-sidr-bgpsec-threats-02 Thread-Index: Ac16N6Ae407rtL9CRxWS182ULJwIzgATI8aAACJa2qM= Date: Wed, 15 Aug 2012 17:56:09 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F5FF30@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F5604B@Hermes.columbia.ads.sparta.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: multipart/alternative; boundary="_000_24B20D14B2CD29478C8D5D6E9CBB29F625F5FF30Hermescolumbiaa_" MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] WGLC on draft-ietf-sidr-bgpsec-threats-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 17:56:20 -0000 --_000_24B20D14B2CD29478C8D5D6E9CBB29F625F5FF30Hermescolumbiaa_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Brian, I can see that you think that some people brought up some issues som= e time ago on some previous version(s) that have not been addressed. Unfortunately, that's not clear enough for the chairs or authors to take ac= tion. It would help if you could provide more specifics. --Sandy, speaking as wg co-chair ________________________________ From: Brian Dickson [brian.peter.dickson@gmail.com] Sent: Tuesday, August 14, 2012 5:20 PM To: Murphy, Sandra Cc: sidr@ietf.org Subject: Re: [sidr] WGLC on draft-ietf-sidr-bgpsec-threats-02 I have reviewed the draft. It remains vague and incomplete, in the Residual Threats section. This, des= pite extensive discussion (since the -00 version) on the list regarding ver= y specific, very real, residual threats. It not only fails to discuss them, it fails to enumerate them. The extensive discussion is in the archives, and contains substantive comme= nts from at least 1/4 active participants in SIDR, including those with the= greatest degree of operational and/or implementation experience. I would request that the WGLC be retracted until the authors decide to addr= ess those previous comments. Chairs: There should not be a need to re-raise the particulars - if the aut= hors got shot down before, and fail to include text or address the complain= ts, I fail to see why they are submitting this, or the chair(s) are doing a= WGLC. The objective of a threats model should be to model the threats, and identi= fy known weaknesses. If it is substantially incomplete, it is not ready to = go. It fails to accomplish its _only_ goal. Excluding threats from this doc, because the solution does not address them= , is beyond ridiculous. It is laughable. Sorry if this offends the authors. The authors' work is at issue, not the a= uthors themselves. They are fine and upstanding individuals. This ID, in it= s current form, however, is, IMHO, junk. Brian On Tue, Aug 14, 2012 at 12:19 PM, Murphy, Sandra > wrote: The authors have indicated that they believe the draft Threat Model for BGP Path Security draft-ietf-sidr-bgpsec-threats-02 http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-threats-02 is ready for a working group last call. This starts the two week working group last call. It will end on Aug 28. = Please review the draft and send comments to the list. --Sandy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --_000_24B20D14B2CD29478C8D5D6E9CBB29F625F5FF30Hermescolumbiaa_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Brian, I can see that you think that some people brought up some issu= es some time ago on some previous version(s) that have not been addressed.<= br>
Unfortunately, that's not clear enough for the chairs or authors to take ac= tion.

It would help if you could provide more specifics.

--Sandy, speaking as wg co-chair

From: Brian Dickson [brian.peter.dickson@= gmail.com]
Sent: Tuesday, August 14, 2012 5:20 PM
To: Murphy, Sandra
Cc: sidr@ietf.org
Subject: Re: [sidr] WGLC on draft-ietf-sidr-bgpsec-threats-02

I have reviewed the draft.

It remains vague and incomplete, in the Residual Threats section. This= , despite extensive discussion (since the -00 version) on the list regardin= g very specific, very real, residual threats.

It not only fails to discuss them, it fails to enumerate them.

The extensive discussion is in the archives, and contains substantive = comments from at least 1/4 active participants in SIDR, including those wit= h the greatest degree of operational and/or implementation experience.

I would request that the WGLC be retracted until the authors decide to= address those previous comments.

Chairs: There should not be a need to re-raise the particulars - if th= e authors got shot down before, and fail to include text or address the com= plaints, I fail to see why they are submitting this, or the chair(s) are do= ing a WGLC.

The objective of a threats model should be to model the threats, and i= dentify known weaknesses. If it is substantially incomplete, it is not read= y to go. It fails to accomplish its _only_ goal.

Excluding threats from this doc, because the solution does not address= them, is beyond ridiculous. It is laughable.

Sorry if this offends the authors. The authors' work is at issue, not = the authors themselves. They are fine and upstanding individuals. This ID, = in its current form, however, is, IMHO, junk.

Brian

On Tue, Aug 14, 2012 at 12:19 PM, Murphy, Sandra= <Sandra.Mu= rphy@sparta.com> wrote:
The authors have indicated that they believe the draft

Threat Model for BGP Path Security
draft-ietf-sidr-bgpsec-threats-02
http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-threats-0= 2

is ready for a working group last call.

This starts the two week working group last call.  It will end on Aug = 28.  Please review the draft and send comments to the list.

--Sandy
_______________________________________________
sidr mailing list
sidr@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sidr

--_000_24B20D14B2CD29478C8D5D6E9CBB29F625F5FF30Hermescolumbiaa_-- From brian.peter.dickson@gmail.com Wed Aug 15 13:26:02 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3BC21F86B1 for ; Wed, 15 Aug 2012 13:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8GcfCa+GvcD for ; Wed, 15 Aug 2012 13:26:00 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 6798021F8665 for ; Wed, 15 Aug 2012 13:26:00 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so1462823wib.13 for ; Wed, 15 Aug 2012 13:25:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mP5leoSaplqra9uSMM1IWTpg/9Cv9H50COVl5wsSSmE=; b=aq31PU0trmAvZWnVq/F3c40M8KLLSVhIvQwooJ2tdvLSxoArc0NY/1MC5IafQsoI57 Gj1x2uiaWrOU7Kx6TxVdUcjEPuCNs0pQx24HZVEiU1Gc9Arr34Az+A1Yv7qIYzY8WCGq P0c5lAXmfQKvWqA3rBInPzHmXZu757iRyKwektHkRzHlJOO+Tq6hgPhuM+BliqCw2U0C MPsX1Nx0VJbSgyevYQzODOAbS9lh66i2jGxrBisfFhXJKbHpDE/VI4yUm4w850Z0zZ2g aNp17RnZ2so1bVHdRhLJP0SawSYe4njCuIOUP0u3iqgPoEG4rsMjmB1ym597JhfPTa7d 8CJw== MIME-Version: 1.0 Received: by 10.180.81.38 with SMTP id w6mr39540588wix.10.1345062359523; Wed, 15 Aug 2012 13:25:59 -0700 (PDT) Received: by 10.223.169.196 with HTTP; Wed, 15 Aug 2012 13:25:59 -0700 (PDT) In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F5FF30@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F5604B@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F5FF30@Hermes.columbia.ads.sparta.com> Date: Wed, 15 Aug 2012 16:25:59 -0400 Message-ID: From: Brian Dickson To: "Murphy, Sandra" Content-Type: multipart/alternative; boundary=f46d044288c023e18704c753bc71 Cc: "sidr@ietf.org" Subject: Re: [sidr] WGLC on draft-ietf-sidr-bgpsec-threats-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 20:26:02 -0000 --f46d044288c023e18704c753bc71 Content-Type: text/plain; charset=ISO-8859-1 I'll try to be more clear: I do not believe comments regarding _any_ version of the draft in question, have been adequately addressed (on the mailing list, or in person, or in the document). There are a number of topics of contention, and I believe it is the duty of the chairs, not my responsibility, to track the specific items in question. To quote from RFC 2414, section 3.3: It is occasionally appropriate to revisit a topic, to re-evaluate alternatives or to improve the group's understanding of a relevant decision. However, unnecessary repeated discussions on issues can be avoided if the Chair makes sure that the main arguments in the discussion (and the outcome) are summarized and archived after a discussion has come to conclusion. I would respectfully point out the dates of the discussion, and a few of the subject lines, as follows: "BGP Thread Model ID" (between 10/29/2011 and 11/14/2011, covering a number of intertwined issues, where the author effectively states that he will only change the text at the direction of the Chair(s), and where there are a significant number of participants who express a desire to have the text changed.) "Route Leaks message to IDR" (3/21/2012 onward) Also, given that draft-dickson-sidr-route-leak-solns exists and has not expired, and that IDR has been asked to review the route-leaks issue, and have themselves asked GROW to take a look at it, it would be more appropriate to have the -threats- doc refer to this draft, and to the ongoing IETF process of codifying route-leaks, rather than disingenuously continuing to state that nothing codifies route-leaks in the IETF. (Technically, discussions in the mailing list archive are IETF materials, at the very least, as are current unexpired I-D docs.) Even without going into whether or not it is codified officially, the codification can easily be incorporated into the -threats- doc, in the residual threats. The importance of this is that in considering the body of work of the WG, and in particular potentially deploying BGPSEC (in whatever form it emerges), operators _must_ be given all the necessary information, including whether BGPSEC protects against threats that actually exist. Pretending the threats do not exist, by not detailing them in the "Residual Threats" section, is really not what I would consider IETF-worthy. So, in summary: - if the chairs cannot find a volunteer to summarize and track the major issues related to WG discussion (on-list and in-person) that affect the -threats- doc, their duty is to do it themselves. - I would like to see an assertion on each major issue, the following: --- has it been discussed to death? --- has consensus been reached (either way) about whether it should be included in the -threats- doc? --- has the threats doc adequately addressed the issue (and if so, in which section)? What I am contending is, that one or more issues have either reached an impasse (and thus the -threats- doc, as such, does not have rough consensus), or have a consensus which the doc does not incorporate adequately. Is that enough to act on? Oh, and in case it isn't abundantly clear: I do not support moving the document forward in its current state. Brian On Wed, Aug 15, 2012 at 1:56 PM, Murphy, Sandra wrote: > Brian, I can see that you think that some people brought up some issues > some time ago on some previous version(s) that have not been addressed. > > Unfortunately, that's not clear enough for the chairs or authors to take > action. > > It would help if you could provide more specifics. > > --Sandy, speaking as wg co-chair > > ------------------------------ > *From:* Brian Dickson [brian.peter.dickson@gmail.com] > *Sent:* Tuesday, August 14, 2012 5:20 PM > *To:* Murphy, Sandra > *Cc:* sidr@ietf.org > *Subject:* Re: [sidr] WGLC on draft-ietf-sidr-bgpsec-threats-02 > > I have reviewed the draft. > > It remains vague and incomplete, in the Residual Threats section. This, > despite extensive discussion (since the -00 version) on the list regarding > very specific, very real, residual threats. > > It not only fails to discuss them, it fails to enumerate them. > > The extensive discussion is in the archives, and contains substantive > comments from at least 1/4 active participants in SIDR, including those > with the greatest degree of operational and/or implementation experience. > > I would request that the WGLC be retracted until the authors decide to > address those previous comments. > > Chairs: There should not be a need to re-raise the particulars - if the > authors got shot down before, and fail to include text or address the > complaints, I fail to see why they are submitting this, or the chair(s) are > doing a WGLC. > > The objective of a threats model should be to model the threats, and > identify known weaknesses. If it is substantially incomplete, it is not > ready to go. It fails to accomplish its _only_ goal. > > Excluding threats from this doc, because the solution does not address > them, is beyond ridiculous. It is laughable. > > Sorry if this offends the authors. The authors' work is at issue, not > the authors themselves. They are fine and upstanding individuals. This ID, > in its current form, however, is, IMHO, junk. > > Brian > > On Tue, Aug 14, 2012 at 12:19 PM, Murphy, Sandra > wrote: > >> The authors have indicated that they believe the draft >> >> Threat Model for BGP Path Security >> draft-ietf-sidr-bgpsec-threats-02 >> http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-threats-02 >> >> is ready for a working group last call. >> >> This starts the two week working group last call. It will end on Aug 28. >> Please review the draft and send comments to the list. >> >> --Sandy >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >> > > --f46d044288c023e18704c753bc71 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'll try to be more clear:

I do not believe comments= regarding _any_ version of the draft in question, have been adequately add= ressed (on the mailing list, or in person, or in the document).

There are a number of topics of contention, and I believe it= is the duty of the chairs, not my responsibility, to track the specific it= ems in question.

To quote from RFC 2414, section 3.3:

   It is occasionally appropriate to revisit a topic, to re-evaluate
   alternatives or to improve the group's understanding of a relevant
   decision.  However, unnecessary repeated discussions on issues can be
   avoided if the Chair makes sure that the main arguments in the
   discussion (and the outcome) are summarized and archived after a
   discussion has come to conclusion.
I woul=
d respectfully point out the dates of the discussion, and a few of the subj=
ect lines, as follows:
"BGP Thread Model ID" (between 10/29/20=
11 and 11/14/2011, covering a number of intertwined issues, where the autho=
r effectively states that he will only change the text at the direction of =
the Chair(s), and where there are a significant number of participants who =
express a desire to have the text changed.)
"Route Leaks message to IDR" (3/21/2012=
 onward)
Also, given that draft-dickson-sidr-route-leak-solns =
exists and has not expired, and that=
 IDR has been asked to review the route-leaks issue, and have themselves as=
ked GROW to take a look at it, it would be more appropriate to have the -th=
reats- doc refer to this draft, and to the ongoing IETF process of codifyin=
g route-leaks, rather than disingenuously continuing to state that nothing =
codifies route-leaks in the IETF.
(Technically, discussions in the mailing list archive =
are IETF materials, at the very least, as are current unexpired I-D docs.)<=
/font>
Even without going into whether or not it is codified =
officially, the codification can easily be incorporated into the -threats- =
doc, in the residual threats.
The importance of this is that =
in considering the body of work of the WG, and in particular potentially de=
ploying BGPSEC (in whatever form it emerges), operators _must_ be given all=
 the necessary information, including whether BGPSEC protects against threa=
ts that actually exist. Pretending the threats do not exist, by not detaili=
ng them in the "Residual Threats" section, is really not what I w=
ould consider IETF-worthy.
So, in summary:
- if the chairs cannot find a volu= nteer to summarize and track the major issues related to WG discussion (on-= list and in-person) that affect the -threats- doc, their duty is to do it t= hemselves. 
- I would like to see an assert=
ion on each major issue, the following:
--- has it be=
en discussed to death?
--- has consensus been reached (either way) about whether it should be =
included in the -threats- doc?
--- has the threats doc adequat=
ely addressed the issue (and if so, in which section)?
What I am con=
tending is, that one or more issues have either reached an impasse (and thu=
s the -threats- doc, as such, does not have rough consensus), or have a con=
sensus which the doc does not incorporate adequately.
Is that enough to act on?
Oh, and in case it isn&#=
39;t abundantly clear:
I do not support moving the doc=
ument forward in its current state.
Brian<=
/pre>
On Wed, Aug 15, 2012 at 1:56 PM, Murphy=
, Sandra <Sandra.Murphy@sparta.com> wrote:












Brian, I can =
see that you think that some people brought up some issues some time ago on=
 some previous version(s) that have not been addressed.



Unfortunately, that's not clear enough for the chairs or authors to tak=
e action.



It would help if you could provide more specifics.



--Sandy, speaking as wg co-chair








Fro=
m: Brian Dickson [brian.peter.dickson@gmail.com]

Sent: Tuesday, August 14, 2012 5:20 PM

To: Murphy, Sandra

Cc: sidr@ietf.org=


Subject: Re: [sidr] WGLC on draft-ietf-sidr-bgpsec-threats-02








I have reviewed the draft.






It remains vague and incomplete, in the Residual Threats section. This=
, despite extensive discussion (since the -00 version) on the list regardin=
g very specific, very real, residual threats.







It not only fails to discuss them, it fails to enumerate them.







The extensive discussion is in the archives, and contains substantive =
comments from at least 1/4 active participants in SIDR, including those wit=
h the greatest degree of operational and/or implementation experience.









I would request that the WGLC be retracted until the authors decide to=
 address those previous comments.







Chairs: There should not be a need to re-raise the particulars - if th=
e authors got shot down before, and fail to include text or address the com=
plaints, I fail to see why they are submitting this, or the chair(s) are do=
ing a WGLC.










The objective of a threats model should be to model the threats, and i=
dentify known weaknesses. If it is substantially incomplete, it is not read=
y to go. It fails to accomplish its _only_ goal.







Excluding threats from this doc, because the solution does not address=
 them, is beyond=A0ridiculous. It is laughable.







Sorry if this offends the authors. The authors' work is at issue, =
not the authors themselves. They are fine and upstanding individuals. This =
ID, in its current form, however, is, IMHO, junk.







Brian




On Tue, Aug 14, 2012 at 12:19 PM, Murphy, Sandra=
 
<Sandra.Mu=
rphy@sparta.com> wrote:



The authors have indicated that they believe the draft



Threat Model for BGP Path Security

draft-ietf-sidr-bgpsec-threats-02

http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-threats-0=
2



is ready for a working group last call.



This starts the two week working group last call. =A0It will end on Aug 28.=
 =A0Please review the draft and send comments to the list.



--Sandy

_______________________________________________

sidr mailing list

sidr@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/sidr

--f46d044288c023e18704c753bc71-- From brian.peter.dickson@gmail.com Wed Aug 15 13:28:13 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E1E11E808A for ; Wed, 15 Aug 2012 13:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.379 X-Spam-Level: X-Spam-Status: No, score=-3.379 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdEEKzYXAilK for ; Wed, 15 Aug 2012 13:28:12 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC8E21F85B1 for ; Wed, 15 Aug 2012 13:28:12 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1182447wgb.13 for ; Wed, 15 Aug 2012 13:28:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TaTzn8+aTmOLAyyDFCA7/sHlF0Ldsc5lRnRvCoayhzA=; b=ihoFxX/sctEae0GwpE2Rh4FDOaeWSA1jQ/pZu2/bwTRl7YnBMlUbpV8Wf3AYLK7/JU HfpULsxuN2f3VcX9MMZs44SRKAguHVJDRWOYS0WU/lb1dX+fbcONy1zqEOt+aEi8L5zH f2cwpUMHW1ttxfkSg422k23P1QPQt2gOnqL658w/Gwia2TAxNjR0gI4SuMdUnpSUVw5c EPAw3RDjLq0AYPkqwSFbFLqzHLRV0Nq6zIq2Ieh0pQcJirdNRVK0wtTXel5kCSNKFHhm 0gNQC7nYTmWaMNTOD5P9PrDWT+uBoxney1KNm8jrup3vwjyLDJ9H6PTGOGaoPL7qaZKj CfTw== MIME-Version: 1.0 Received: by 10.216.132.25 with SMTP id n25mr10144693wei.25.1345062491034; Wed, 15 Aug 2012 13:28:11 -0700 (PDT) Received: by 10.223.169.196 with HTTP; Wed, 15 Aug 2012 13:28:10 -0700 (PDT) In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F625F5604B@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F5FF30@Hermes.columbia.ads.sparta.com> Date: Wed, 15 Aug 2012 16:28:10 -0400 Message-ID: From: Brian Dickson To: "Murphy, Sandra" Content-Type: multipart/alternative; boundary=0016e6dd8d69fa95f804c753c332 Cc: "sidr@ietf.org" Subject: Re: [sidr] WGLC on draft-ietf-sidr-bgpsec-threats-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 20:28:13 -0000 --0016e6dd8d69fa95f804c753c332 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable s/2414/2418/ - my bad. On Wed, Aug 15, 2012 at 4:25 PM, Brian Dickson < brian.peter.dickson@gmail.com> wrote: > I'll try to be more clear: > > I do not believe comments regarding _any_ version of the draft in > question, have been adequately addressed (on the mailing list, or in > person, or in the document). > > There are a number of topics of contention, and I believe it is the duty > of the chairs, not my responsibility, to track the specific items in > question. > > To quote from RFC 2414, section 3.3: > > It is occasionally appropriate to revisit a topic, to re-evaluate > alternatives or to improve the group's understanding of a relevant > decision. However, unnecessary repeated discussions on issues can be > avoided if the Chair makes sure that the main arguments in the > discussion (and the outcome) are summarized and archived after a > discussion has come to conclusion. > > I would respectfully point out the dates of the discussion, and a few of = the subject lines, as follows: > > "BGP Thread Model ID" (between 10/29/2011 and 11/14/2011, covering a numb= er of intertwined issues, where the author effectively states that he will = only change the text at the direction of the Chair(s), and where there are = a significant number of participants who express a desire to have the text = changed.) > > "Route Leaks message to IDR" (3/21/2012 onward) > > Also, given that draft-dickson-sidr-route-leak-solns exists and has not e= xpired, and that IDR has been asked to review the route-leaks issue, and ha= ve themselves asked GROW to take a look at it, it would be more appropriate= to have the -threats- doc refer to this draft, and to the ongoing IETF pro= cess of codifying route-leaks, rather than disingenuously continuing to sta= te that nothing codifies route-leaks in the IETF. > > (Technically, discussions in the mailing list archive are IETF materials,= at the very least, as are current unexpired I-D docs.) > > Even without going into whether or not it is codified officially, the cod= ification can easily be incorporated into the -threats- doc, in the residua= l threats. > > The importance of this is that in considering the body of work of the WG,= and in particular potentially deploying BGPSEC (in whatever form it emerge= s), operators _must_ be given all the necessary information, including whet= her BGPSEC protects against threats that actually exist. Pretending the thr= eats do not exist, by not detailing them in the "Residual Threats" section,= is really not what I would consider IETF-worthy. > > So, in summary: > > - if the chairs cannot find a volunteer to summarize and track the major = issues related to WG discussion (on-list and in-person) that affect the -th= reats- doc, their duty is to do it themselves. > > - I would like to see an assertion on each major issue, the following: > > --- has it been discussed to death? > > --- has consensus been reached (either way) about whether it should be in= cluded in the -threats- doc? > > --- has the threats doc adequately addressed the issue (and if so, in whi= ch section)? > > What I am contending is, that one or more issues have either reached an i= mpasse (and thus the -threats- doc, as such, does not have rough consensus)= , or have a consensus which the doc does not incorporate adequately. > > Is that enough to act on? > > Oh, and in case it isn't abundantly clear: > > I do not support moving the document forward in its current state. > > Brian > > > On Wed, Aug 15, 2012 at 1:56 PM, Murphy, Sandra wrote: > >> Brian, I can see that you think that some people brought up some issues >> some time ago on some previous version(s) that have not been addressed. >> >> Unfortunately, that's not clear enough for the chairs or authors to take >> action. >> >> It would help if you could provide more specifics. >> >> --Sandy, speaking as wg co-chair >> >> ------------------------------ >> *From:* Brian Dickson [brian.peter.dickson@gmail.com] >> *Sent:* Tuesday, August 14, 2012 5:20 PM >> *To:* Murphy, Sandra >> *Cc:* sidr@ietf.org >> *Subject:* Re: [sidr] WGLC on draft-ietf-sidr-bgpsec-threats-02 >> >> I have reviewed the draft. >> >> It remains vague and incomplete, in the Residual Threats section. This, >> despite extensive discussion (since the -00 version) on the list regardi= ng >> very specific, very real, residual threats. >> >> It not only fails to discuss them, it fails to enumerate them. >> >> The extensive discussion is in the archives, and contains substantive >> comments from at least 1/4 active participants in SIDR, including those >> with the greatest degree of operational and/or implementation experience= . >> >> I would request that the WGLC be retracted until the authors decide to >> address those previous comments. >> >> Chairs: There should not be a need to re-raise the particulars - if the >> authors got shot down before, and fail to include text or address the >> complaints, I fail to see why they are submitting this, or the chair(s) = are >> doing a WGLC. >> >> The objective of a threats model should be to model the threats, and >> identify known weaknesses. If it is substantially incomplete, it is not >> ready to go. It fails to accomplish its _only_ goal. >> >> Excluding threats from this doc, because the solution does not address >> them, is beyond ridiculous. It is laughable. >> >> Sorry if this offends the authors. The authors' work is at issue, not >> the authors themselves. They are fine and upstanding individuals. This I= D, >> in its current form, however, is, IMHO, junk. >> >> Brian >> >> On Tue, Aug 14, 2012 at 12:19 PM, Murphy, Sandra < >> Sandra.Murphy@sparta.com> wrote: >> >>> The authors have indicated that they believe the draft >>> >>> Threat Model for BGP Path Security >>> draft-ietf-sidr-bgpsec-threats-02 >>> http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-threats-02 >>> >>> is ready for a working group last call. >>> >>> This starts the two week working group last call. It will end on Aug >>> 28. Please review the draft and send comments to the list. >>> >>> --Sandy >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >>> >> >> > --0016e6dd8d69fa95f804c753c332 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable s/2414/2418/ - my bad.

On Wed, Aug 15, 20= 12 at 4:25 PM, Brian Dickson <brian.peter.dickson@gmail.com> wrote:
I'll try to be more clear:

I do not believe comments regarding _any_ version of the draft in que= stion, have been adequately addressed (on the mailing list, or in person, o= r in the document).

There are a number of topics of contention, and I believe it= is the duty of the chairs, not my responsibility, to track the specific it= ems in question.

To quote from RFC 2414, section 3.3:

   It is occasionally appropriate to revisit a topic, to re-evaluate
   alternatives or to improve the group's understanding of a relevant
   decision.  However, unnecessary repeated discussions on issues can be
   avoided if the Chair makes sure that the main arguments in the
   discussion (and the outcome) are summarized and archived after a
   discussion has come to conclusion.
I woul=
d respectfully point out the dates of the discussion, and a few of the subj=
ect lines, as follows:
"BGP Thread Model ID" (between 10/29/20=
11 and 11/14/2011, covering a number of intertwined issues, where the autho=
r effectively states that he will only change the text at the direction of =
the Chair(s), and where there are a significant number of participants who =
express a desire to have the text changed.)
"Route Leaks message to IDR" (3/21/2012=
 onward)
Also, given that dr=
aft-dickson-sidr-route-leak-solns exists and has not expired, a=
nd that IDR has been asked to review the route-leaks issue, and have themse=
lves asked GROW to take a look at it, it would be more appropriate to have =
the -threats- doc refer to this draft, and to the ongoing IETF process of c=
odifying route-leaks, rather than disingenuously continuing to state that n=
othing codifies route-leaks in the IETF.
(Technically,=
 discussions in the mailing list archive are IETF materials, at the very le=
ast, as are current unexpired I-D docs.)
Even without =
going into whether or not it is codified officially, the codification can e=
asily be incorporated into the -threats- doc, in the residual threats.
The importance of this is that =
in considering the body of work of the WG, and in particular potentially de=
ploying BGPSEC (in whatever form it emerges), operators _must_ be given all=
 the necessary information, including whether BGPSEC protects against threa=
ts that actually exist. Pretending the threats do not exist, by not detaili=
ng them in the "Residual Threats" section, is really not what I w=
ould consider IETF-worthy.
So, in summary:
- if the chairs cannot find a volu= nteer to summarize and track the major issues related to WG discussion (on-= list and in-person) that affect the -threats- doc, their duty is to do it t= hemselves. 
- I would like to see an assert=
ion on each major issue, the following:
--- has it be=
en discussed to death?
--- has consensus been reached (either way) about whether it should be =
included in the -threats- doc?
--- has the threats doc adequat=
ely addressed the issue (and if so, in which section)?
What I am con=
tending is, that one or more issues have either reached an impasse (and thu=
s the -threats- doc, as such, does not have rough consensus), or have a con=
sensus which the doc does not incorporate adequately.
Is that enough to act on?
Oh, and in case it isn&#=
39;t abundantly clear:
I do not support moving the doc=
ument forward in its current state.
Brian<=
/pre>

On=
 Wed, Aug 15, 2012 at 1:56 PM, Murphy, Sandra <Sandra.Murphy@sparta=
.com> wrote:













Brian, I can =
see that you think that some people brought up some issues some time ago on=
 some previous version(s) that have not been addressed.



Unfortunately, that's not clear enough for the chairs or authors to tak=
e action.



It would help if you could provide more specifics.



--Sandy, speaking as wg co-chair








Fro=
m: Brian Dickson [brian.peter.dickson@gmail.com]

Sent: Tuesday, August 14, 2012 5:20 PM

To: Murphy, Sandra

Cc: sidr@ietf.org=


Subject: Re: [sidr] WGLC on draft-ietf-sidr-bgpsec-threats-02








I have reviewed the draft.






It remains vague and incomplete, in the Residual Threats section. This=
, despite extensive discussion (since the -00 version) on the list regardin=
g very specific, very real, residual threats.







It not only fails to discuss them, it fails to enumerate them.







The extensive discussion is in the archives, and contains substantive =
comments from at least 1/4 active participants in SIDR, including those wit=
h the greatest degree of operational and/or implementation experience.










I would request that the WGLC be retracted until the authors decide to=
 address those previous comments.







Chairs: There should not be a need to re-raise the particulars - if th=
e authors got shot down before, and fail to include text or address the com=
plaints, I fail to see why they are submitting this, or the chair(s) are do=
ing a WGLC.











The objective of a threats model should be to model the threats, and i=
dentify known weaknesses. If it is substantially incomplete, it is not read=
y to go. It fails to accomplish its _only_ goal.







Excluding threats from this doc, because the solution does not address=
 them, is beyond=A0ridiculous. It is laughable.







Sorry if this offends the authors. The authors' work is at issue, =
not the authors themselves. They are fine and upstanding individuals. This =
ID, in its current form, however, is, IMHO, junk.







Brian




On Tue, Aug 14, 2012 at 12:19 PM, Murphy, Sandra=
 
<Sandra.Mu=
rphy@sparta.com> wrote:



The authors have indicated that they believe the draft



Threat Model for BGP Path Security

draft-ietf-sidr-bgpsec-threats-02

http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-threats-0=
2



is ready for a working group last call.



This starts the two week working group last call. =A0It will end on Aug 28.=
 =A0Please review the draft and send comments to the list.



--Sandy

_______________________________________________

sidr mailing list

sidr@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/sidr


--0016e6dd8d69fa95f804c753c332-- From internet-drafts@ietf.org Thu Aug 16 17:36:31 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB9AE11E80D7; Thu, 16 Aug 2012 17:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.461 X-Spam-Level: X-Spam-Status: No, score=-102.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c25xvN5oSyK7; Thu, 16 Aug 2012 17:36:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F43121F8499; Thu, 16 Aug 2012 17:36:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120817003630.10813.20494.idtracker@ietfa.amsl.com> Date: Thu, 16 Aug 2012 17:36:30 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-origin-ops-19.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 00:36:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working Group= of the IETF. Title : RPKI-Based Origin Validation Operation Author(s) : Randy Bush Filename : draft-ietf-sidr-origin-ops-19.txt Pages : 10 Date : 2012-08-16 Abstract: Deployment of RPKI-based BGP origin validation has many operational considerations. This document attempts to collect and present the most critical. It is expected to evolve as RPKI-based origin validation is deployed and the dynamics are better understood. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-origin-ops There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-origin-ops-19 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-origin-ops-19 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From christopher.morrow@gmail.com Fri Aug 17 08:03:11 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5172511E80DE; Fri, 17 Aug 2012 08:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.12 X-Spam-Level: X-Spam-Status: No, score=-103.12 tagged_above=-999 required=5 tests=[AWL=0.479, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLhgqriqHd1W; Fri, 17 Aug 2012 08:03:10 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id ABE2B11E80A5; Fri, 17 Aug 2012 08:03:10 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3935090vbb.31 for ; Fri, 17 Aug 2012 08:03:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=yeDudo/jspXT0d8G2tBL/otriMV/FN7nqH0VBPMfYJQ=; b=Htp4VFuBYw8gLa/lqFrz+qaHRzG1yJma5Enadc+0RAtqQYod5BCB/wvs6PaolgfkG3 CLB+VpE67lAtxmBAmI5OhCcC//SIE4UKik20LlOCeSiClYUR/uR5PMSLyxtit6BBhiVZ A7WVCGU2NYLCCZo2AcBxtnAsCZGWNAxBNwEd91TmJh1UrH5NdjzocYuWfVPINqoRXfb+ mpUs/9SVSM8VlMXc1buqFg5ALbEoQg7s4VHG5FVodX123VOm3cchhchW5ffOo217xRfE T181n/Dv4Nd0oi0hay3wsHjzs0IKDVI6/c5DpgAn5gBMrIdv7W3R4uGbm5GsI4NKUhEU u71w== MIME-Version: 1.0 Received: by 10.52.33.165 with SMTP id s5mr2234675vdi.51.1345215790198; Fri, 17 Aug 2012 08:03:10 -0700 (PDT) Received: by 10.58.216.42 with HTTP; Fri, 17 Aug 2012 08:03:10 -0700 (PDT) Date: Fri, 17 Aug 2012 11:03:10 -0400 Message-ID: From: Christopher Morrow To: sidr@ietf.org, sidr-chairs@ietf.org, sidr-ads@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [sidr] WGLC: draft-ietf-sidr-origin-ops- X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 15:03:11 -0000 Hello WG folk, This draft has undergone 9 revisions since the last WGLC, which seemed to end with requests for changes by the authors. Can we now have a final-final-please-let's-progress WGLC for this draft now? Let's end the call: 08/31/2012 (Aug 31 2012). Htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-origin-ops-19 Abstract: "Deployment of RPKI-based BGP origin validation has many operational considerations. This document attempts to collect and present the most critical. It is expected to evolve as RPKI-based origin validation is deployed and the dynamics are better understood." Thanks! -Chris From Sandra.Murphy@sparta.com Fri Aug 17 09:58:43 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0028C11E80E3 for ; Fri, 17 Aug 2012 09:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPzTtBejbAEp for ; Fri, 17 Aug 2012 09:58:39 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5353511E80DF for ; Fri, 17 Aug 2012 09:58:39 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q7HGwcSu018408 for ; Fri, 17 Aug 2012 11:58:38 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q7HGwcn2000428 for ; Fri, 17 Aug 2012 11:58:38 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%21]) with mapi id 14.01.0355.002; Fri, 17 Aug 2012 12:58:31 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: WGLC on draft-ietf-sidr-rpki-rtr-impl-01 Thread-Index: Ac18mPOGHW8RHAApQbyV52bpT9uaKw== Date: Fri, 17 Aug 2012 16:58:31 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F61435@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] WGLC on draft-ietf-sidr-rpki-rtr-impl-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 16:58:43 -0000 The authors believe that the draft is ready for publication. This announce= s a two week last call. The WGLC will end 31 Aug 2012.=0A= =0A= Please report to the list whether you support publication of this draft or = not.=0A= =0A= The draft is available at=0A= http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-impl-01=0A= =0A= The abstract says:=0A= =0A= This document provides an implementation report for RPKI Router=0A= protocol as defined in [I-D.ietf-sidr-rpki-rtr]. The editor did not=0A= verify the accuracy of the information provided by respondents or by=0A= any alternative means. The respondents are experts with the=0A= implementations they reported on, and their responses are considered=0A= authoritative for the implementations for which their responses=0A= represent. Respondents were asked to only use the YES answer if the=0A= feature had at least been tested in the lab.=0A= =0A= =0A= =0A= --Sandy, speaking as wg co-chair= From Sandra.Murphy@sparta.com Fri Aug 17 10:02:17 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A1D21F8456 for ; Fri, 17 Aug 2012 10:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7xSFF+nwyuF for ; Fri, 17 Aug 2012 10:02:17 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 63E9921F8452 for ; Fri, 17 Aug 2012 10:02:17 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q7HH2GAT018493 for ; Fri, 17 Aug 2012 12:02:16 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q7HH2GWq000611 for ; Fri, 17 Aug 2012 12:02:16 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%21]) with mapi id 14.01.0355.002; Fri, 17 Aug 2012 13:02:06 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: WGLC for draft-ietf-sidr-rpki-rtr-protocol-mib-00 Thread-Index: Ac18mgfI+y3ADDRpQYCDBOEwdIvVEA== Date: Fri, 17 Aug 2012 17:02:06 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F6144F@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] WGLC for draft-ietf-sidr-rpki-rtr-protocol-mib-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 17:02:18 -0000 The authors believe that the draft is ready for publication. This announce= s a two week last call. The WGLC will end 31 Aug 2012.=0A= =0A= Please report to the list whether you support publication of this draft or = not.=0A= =0A= The draft is available at=0A= http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-protocol-mib-00=0A= =0A= The abstract says:=0A= =0A= This document defines a portion of the Management Information Base=0A= (MIB) for use with network management protocols in the Internet=0A= community. In particular, it describes objects used for monitoring=0A= the RPKI Router protocol.=0A= =0A= --Sandy, speaking as wg co-chair= From christopher.morrow@gmail.com Sun Aug 19 21:14:42 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD7621F866A for ; Sun, 19 Aug 2012 21:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkfw-2LEPzzW for ; Sun, 19 Aug 2012 21:14:42 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E369721F8668 for ; Sun, 19 Aug 2012 21:14:41 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so5290021vcb.31 for ; Sun, 19 Aug 2012 21:14:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=WetdwWsPLMKeUENDciXZETZRz4HJVgRToP8L+tyEEsM=; b=PH6vVF6S83F/rp0COAhJHA4tIKZDf+CXRL4kE2W2JtI0uyrEEx4r3DGqySYlQbfMgQ aXMcrvN0wpKTl6oB+ySiMgXSzxkYXtCpLqQfQtA3GriH/cz9KJE+90n6Dra7ovbsAI8/ 8jDusmAC1PIeFGYIiOicwlU3XPhySeIJvxTnuQTkCB4t8qdT+sH3qCrLY4y2DkBxHIdK awbnZonGBJLrIZO6gQ9mgiKCh4BjKPBtab0K3egewFhcWVppnd/D0j2j0XDmF0DNOk4M 4UQkZLFmAKyTUT3hHH+O2HEGVQF0ieDhWIhzwLcE4n7DdiYYXbhEs6l/Mo27saLNTUnJ aDuw== MIME-Version: 1.0 Received: by 10.220.220.203 with SMTP id hz11mr6645478vcb.50.1345436081250; Sun, 19 Aug 2012 21:14:41 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.58.216.42 with HTTP; Sun, 19 Aug 2012 21:14:41 -0700 (PDT) In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F625F5604B@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F5FF30@Hermes.columbia.ads.sparta.com> Date: Mon, 20 Aug 2012 00:14:41 -0400 X-Google-Sender-Auth: ypWuwSuH9IEXBtRUuAHnlCYjJ3w Message-ID: From: Christopher Morrow To: Brian Dickson Content-Type: text/plain; charset=ISO-8859-1 Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] WGLC on draft-ietf-sidr-bgpsec-threats-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 04:14:42 -0000 On Wed, Aug 15, 2012 at 4:28 PM, Brian Dickson wrote: > On Wed, Aug 15, 2012 at 4:25 PM, Brian Dickson > wrote: >> >> I'll try to be more clear: >> >> I do not believe comments regarding _any_ version of the draft in >> question, have been adequately addressed (on the mailing list, or in person, >> or in the document). >> >> I would respectfully point out the dates of the discussion, and a few of >> the subject lines, as follows: >> "Route Leaks message to IDR" (3/21/2012 onward) I think there is text in the draft now about residual threats and route-leaks. I believe the status on the 'do something in grow so something happens in idr so something can happen in sidr' is 'waiting on author to get unstuck and proceed'. which is fine, but shouldn't hold up this doc which can be fixed/altered/etc once/if there is output from grow/idr that sidr can do something about. >> Also, given that draft-dickson-sidr-route-leak-solns exists and has not >> expired, and that IDR has been asked to review the route-leaks issue, and >> have themselves asked GROW to take a look at it, it would be more >> appropriate to have the -threats- doc refer to this draft, and to the >> ongoing IETF process of codifying route-leaks, rather than disingenuously >> continuing to state that nothing codifies route-leaks in the IETF. I don't think it's disingenuous... the threats doc says: ""Route leaks" are viewed as a routing security problem by many network operators, even though there is no IETF-codified definition of a route leak. BGP itself does not include semantics that preclude what many perceive as route leaks. Moreover, route leaks are outside the scope of BGPSEC, at this time, based on the SIDR charter. Thus route leaks are not addressed in this threat model." currently there isn't a completed definition, that's not to say that eventually there may be, and the doc can be updated then. Hopefully when there is a definition we can also have some 'method to fix them' from idr. >> The importance of this is that in considering the body of work of the WG, >> and in particular potentially deploying BGPSEC (in whatever form it >> emerges), operators _must_ be given all the necessary information, including >> whether BGPSEC protects against threats that actually exist. Pretending the >> threats do not exist, by not detailing them in the "Residual Threats" >> section, is really not what I would consider IETF-worthy. no one is pretending anything (I think), we are awaiting some results from the aforementioned groups/authors. I believe the other folk who were interested in this topic are satisfied with the direction. I think it's time to move the document along. -chris From warren@kumari.net Mon Aug 20 01:54:40 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A571921F84B2; Mon, 20 Aug 2012 01:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctNl3gMctJ31; Mon, 20 Aug 2012 01:54:40 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 633C821F8683; Mon, 20 Aug 2012 01:54:34 -0700 (PDT) Received: from [192.168.202.132] (unknown [74.125.121.33]) by vimes.kumari.net (Postfix) with ESMTPSA id C2D451B4044A; Mon, 20 Aug 2012 04:54:32 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: Date: Mon, 20 Aug 2012 04:03:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2E13D614-E5D9-4C52-AC73-662AF631C29C@kumari.net> References: To: Christopher Morrow X-Mailer: Apple Mail (2.1278) Cc: sidr-chairs@ietf.org, sidr-ads@tools.ietf.org, sidr@ietf.org Subject: Re: [sidr] WGLC: draft-ietf-sidr-origin-ops- X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 08:54:40 -0000 On Aug 17, 2012, at 11:03 AM, Christopher Morrow wrote: > Hello WG folk, > This draft has undergone 9 revisions since the last WGLC, which seemed > to end with requests for changes by the authors. > Can we now have a final-final-please-let's-progress WGLC for this > draft now? Let's end the call: 08/31/2012 (Aug 31 2012). Ok, Please let's progress this doc=85 W >=20 > Htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sidr-origin-ops-19 >=20 > Abstract: > "Deployment of RPKI-based BGP origin validation has many operational > considerations. This document attempts to collect and present the > most critical. It is expected to evolve as RPKI-based origin > validation is deployed and the dynamics are better understood." >=20 > Thanks! > -Chris > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 -- Do not meddle in the affairs of dragons, for you are crunchy and taste = good with ketchup.=20 From warren@kumari.net Mon Aug 20 01:54:41 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFC0E21F868A for ; Mon, 20 Aug 2012 01:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gaHGYNbVQIFk for ; Mon, 20 Aug 2012 01:54:40 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 96EDA21F8686 for ; Mon, 20 Aug 2012 01:54:39 -0700 (PDT) Received: from [192.168.202.132] (unknown [74.125.121.33]) by vimes.kumari.net (Postfix) with ESMTPSA id DB5DD1B40861; Mon, 20 Aug 2012 04:54:38 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F61435@Hermes.columbia.ads.sparta.com> Date: Mon, 20 Aug 2012 04:28:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24B20D14B2CD29478C8D5D6E9CBB29F625F61435@Hermes.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1278) Cc: "sidr@ietf.org" Subject: Re: [sidr] WGLC on draft-ietf-sidr-rpki-rtr-impl-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 08:54:41 -0000 On Aug 17, 2012, at 12:58 PM, Murphy, Sandra wrote: > The authors believe that the draft is ready for publication. This = announces a two week last call. The WGLC will end 31 Aug 2012. >=20 > Please report to the list whether you support publication of this = draft or not. >=20 > The draft is available at > http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-impl-01 >=20 > The abstract says: >=20 > This document provides an implementation report for RPKI Router > protocol as defined in [I-D.ietf-sidr-rpki-rtr]. The editor did not > verify the accuracy of the information provided by respondents or by > any alternative means. The respondents are experts with the > implementations they reported on, and their responses are considered > authoritative for the implementations for which their responses > represent. Respondents were asked to only use the YES answer if the > feature had at least been tested in the lab. >=20 Yes, support. Nits: I found the sentence "The editor did not verify the accuracy of the = information provided by respondents or by any alternative means." = unwieldy -- it makes it sound like "by respondents" is a means to verify = accuracy ("The editor did not verify the accuracy of the information = provided by reading entrails or by any alternative means."). I'd suggest = just dropping "or by any alternative means"... W >=20 >=20 > --Sandy, speaking as wg co-chair > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 -- Curse the dark, or light a match. You decide, it's your dark. -- Valdis Kletnieks From dmandelb@bbn.com Mon Aug 20 08:21:49 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D26D721F861A for ; Mon, 20 Aug 2012 08:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ws4kUHD7MI4Y for ; Mon, 20 Aug 2012 08:21:49 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 541EC21F85B8 for ; Mon, 20 Aug 2012 08:21:49 -0700 (PDT) Received: from mail.bbn.com ([128.33.0.48]:43226) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1T3TnX-0006uB-DA for sidr@ietf.org; Mon, 20 Aug 2012 11:21:47 -0400 Received: from dhcp89-089-068.bbn.com ([128.89.89.68]) by mail.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1T3TnX-0007bj-C3 for sidr@ietf.org; Mon, 20 Aug 2012 11:21:47 -0400 Message-ID: <1345476111.30471.23.camel@titan> From: David Mandelberg To: sidr@ietf.org Date: Mon, 20 Aug 2012 11:21:51 -0400 In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F61435@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F61435@Hermes.columbia.ads.sparta.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Subject: Re: [sidr] WGLC on draft-ietf-sidr-rpki-rtr-impl-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 15:21:49 -0000 In section 8: Does RPKI Router protocol implementation support Session ID procedures outlined in Section 5.10 of [I-D.ietf-sidr-rpki-rtr]? I think that should be a reference to section 5.1, not 5.10. From Sandra.Murphy@sparta.com Tue Aug 21 10:41:51 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C01C421F8628 for ; Tue, 21 Aug 2012 10:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dV8Kbrp4kR7o for ; Tue, 21 Aug 2012 10:41:49 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 618C221F857E for ; Tue, 21 Aug 2012 10:41:48 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q7LHflEE010519 for ; Tue, 21 Aug 2012 12:41:47 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q7LHflXh016398 for ; Tue, 21 Aug 2012 12:41:47 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%21]) with mapi id 14.01.0355.002; Tue, 21 Aug 2012 13:41:37 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: minutes for interim 27 Jul 2012 Thread-Index: Ac18mxdD6hEaeNTmSRKUAn5/9lK2IQ== Date: Tue, 21 Aug 2012 17:41:37 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F61468@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] btw: minutes for interim 27 Jul 2012 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 17:41:51 -0000 What I forwarded before was the pure text of the minutes taken.=0A= =0A= The minutes taker also published the minutes at a web site and incorporated= snapshots of blackboard (literally) drawings. Those might be useful in un= derstanding the text, so I uploaded the html from the web site to the IETF = site.=0A= =0A= If you look at:=0A= http://www.ietf.org/proceedings/interim/2012/07/27/sidr/minutes/minutes-int= erim-2012-sidr-5=0A= =0A= you can see the pictures.=0A= =0A= --Sandy, speaking as wg co-chair=0A= From danny@tcb.net Tue Aug 21 20:25:12 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1D511E8091 for ; Tue, 21 Aug 2012 20:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHuTFXhRXosJ for ; Tue, 21 Aug 2012 20:25:11 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 16F5F11E809A for ; Tue, 21 Aug 2012 20:25:11 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 5E4252680C7; Tue, 21 Aug 2012 21:25:10 -0600 (MDT) Received: from new-host-10.home (pool-173-72-146-12.clppva.fios.verizon.net [173.72.146.12]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Tue, 21 Aug 2012 21:25:10 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=173.72.146.12; client-port=59267; syn-fingerprint=65535:49:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1278) From: Danny McPherson In-Reply-To: Date: Tue, 21 Aug 2012 23:24:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24B20D14B2CD29478C8D5D6E9CBB29F625F5604B@Hermes.columbia.ads.sparta.com> To: sidr wg X-Mailer: Apple Mail (2.1278) Subject: [sidr] Some comments on draft-ietf-sidr-bgpsec-threats-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 03:25:12 -0000 Some comments on this document inline below.. I am surprised that external systems (e.g., NTP) are not mentioned at = all in this document? Also, this document makes no distinction between eBGP and iBGP speakers, = yet there are certainly places where text and context would suggest it = is certainly necessary. Some hints of this below. I believe this document needs a major overhaul before publication as a = WG document. More comments below.. -danny =3D=3D=3D=3D=3D ABSTRACT --- 1) Regarding "Intended Status: Standards Track", I'd expect any = standalone Threat Model draft would be should be Informational. --- 2) " Enabling an AS to verify that the AS-PATH represented in a route = matches the path travelled by the NLRI for the route" 2.1): s/AS-PATH/AS_PATH/ 2.2): I do not believe that even BGPSEC does this. Instead, in = introduces a new attribute which BGPSEC secures, and it forces no parity = between the new attribute and the old attribute. See 3) below, but = absent some clarification of this I am not comfortable with this text as = written. =3D=3D=3D=3D=3D INTRODUCTION --- 3) I'm not comfortable with the document as written, per it suggests = that the term "BGPSEC" =3D=3D BGP Path Security, yet even the proposals = received for BGPSEC in the WG only introduce new attributes, they do not = secure the BGP AS_PATH attribute, nor do they force parity between the = globally deployed BGP AS_PATH attribute and the new attributes they = propose. --- 4) "This model also takes into consideration classes of attacks that are = enabled by the use of BGPSEC (based on the current BGPSEC design.)" A = stable reference for "current BGPSEC design" is in order here. --- 5) "i.e., for the links that connect BGP routers." By "links" here I = assume you mean "transport connections"? --- 6) Can you explain what this means, I'm not sure how RPKI by itself = provides this: "secure route origination foundation offered by use of = the RPKI." The operative word "secure" appears to be used rather = loosely there, particularly when talking about BGP. Perhaps "route = origin validation" and a reference to RPKI-RTR would be more appropriate = - i.e., if it's not effectuated in BGP speaking routers through some = mechanism it doesn't matter whether it's in the RPKI or not. Conflating = the two tends to cause confusion in the operations community, methinks. --- 7) This text seems to muddy things, as it talks about the design of = BGPSEC rather than the Threat Model primitives which informed it's = design: " The security model adopted for BGPSEC does not assume an "oracle" that can see all of the BGP inputs and outputs associated with every AS or every BGP router. Instead, the model is based on a local notion of what constitutes legitimate, authorized behavior by the BGP routers associated with an AS. This is an AS-centric model of secure operation, consistent with the AS-centric model that BGP employs for routing. This model forms the basis for the discussion that = follows." =3D=3D=3D=3D=3D TERMINOLOGY --- 8) While I appreciate the attempt to restate and/or redefine these terms = in order to make this a standalone document, references to a large body = of previous IETF and SIDR WG documents (much of which at least one of = the authors is intimately familiar with :-) for these terms would seem = to be far more appropriate. =20 --- 9) A reference to one of your previous (or new) citations may well be in = order here: "False (Route) Origination - If a network operator originates a route for a prefix that the network operator does not hold (and that it has not been authorized to originate by the prefix holder, this is termed false route origination." Also, you're missing closing ")" there.. --- 10) I'm not sure I agree with this definition, can you explain? E.g., = given that motivatiors are complex in a world of hacktivists and = nation-state actors alike, or pay-for-for financially motivated actors, = this all seems a bit fuzzing to me. By it's very definition above, if = I've classified an entity as malicious ("Adversary - An adversary is an = entity (e.g., a person or an organization) perceived as malicious, = relative to the security policy of a system. The decision to = characterize an entity as an adversary is made by those responsible for = the security of a system. Often one describes classes of adversaries = with similar capabilities or motivations, rather than specific = individuals or organizations."). Furthermore, if I have an adversary = that's attempting to procure or develop capabilities to exploit a = vulnerability for which they do not have current capabilities, that = would seem to render it a threat to me - unless of course, I have = complete visibility to their motivations and capabilities, which is = highly improbable.=20 " Threat - A threat is a motivated, capable adversary. An adversary that is not motivated to launch an attack is not a threat. An adversary that is motivated but not capable of launching an attack also is not a threat." =3D=3D=3D=3D=3D THREAT CHARACTERIZATION --- 11) Regarding this text, a reference to the BGPSEC document to which = this This Threat Model subscribes would seem to be appropriate: " If it implements BGPSEC, it will have the ability to issue certificates for its routers, and to sign updates in a fashion that will be recognized by BGPSEC-enabled neighbors." --- 12) Also, the above seems to be implying that per router certificates = would be required here: "certificates for its routers", can you clarify = the intent of this text? --- 13) "sign updates" seems to be ambiguous, is your intention to suggest = that updates are signed, or that new BGP attributes would be introduced = that would be contained with existing BGP Update messaging that could be = "recognized" by BGPSEC-enabled neighbors? --- 14) Is the phrase "Hackers" even necessary here, or should you not = employ "Adversary" as defined in previous sections? --- 15) Regarding "It is assumed that hackers generally do not have the = capability to effect MITM attacks on most links between networks (links = used to transmit BGP and subscriber traffic)." given the preceding two = sentences, they'd certainly be able to, no? =20 --- 16) Also, can you define what "subscriber" means in this context, it = seems to focus on a particularly type of connection but if I'm reading = this correctly, the threat is more ubiquitous. --- 17) Regarding "A hacker might be recruited, without his/her knowledge, = by criminals or by nations, to act on their behalf." This seems to = describe a victim or compromised system more than a "hacker", by nearly = all conventional definitions, no? --- 18) Regarding "Hackers may be motivated by a desire for "bragging = rights" or for profit." -- again, I think expanding adversary as = appropriate, and leaving it at that, might be the simplest solution = here. --- 19) All of the above about "Hackers' applies to the "Criminals" section = as well. Again, refining adversaries terminology and applying would = perhaps be in order. =20 --- 20) The "Network Operators" section might be more useful if it makes a = distinction between benign and malicious activity, although both = represent threats, the current text seems to imply malice in all cases = -- when it may not have been intentional at all. --- 21) The "adversary" comments about apply equally to "Nations" as well, = methinks, if these represent threats to users of the system. =3D=3D=3D=3D=3D ATTACKS ON A BGP ROUTER --- 22) A stable reference for "route leaks" would be useful in the = document, given the recurring references :-) --- 23) Regarding: " Stale Path Announcement: An announcement may be = propagated with an origination signature segment that has expired. This behavior violates the BGPSEC spec and is considered a possible replay attack." -- This and other references to "BGPSEC spec" need a = stable reference. =20 --- 24) s/if such a time is mandates,/if such a time is mandated,/ --- 25) Can you define "Immediate neighbor" here: "Thus only an immediate = neighbor of a route originator could be expected to detect this type of = attack." Do you mean EBGP neighbor? BGPSEC EBGP neighbor? Or... " --- 26) s/in injected/injected/ --- 27) Regarding your definition of "Replay Attack", as written unless I'm = confused because BGP is stateful no new announcement is required at all = (simply suppress withdrawal, no need to re-announce - no?)? =3D=3D=3D=3D=3D ATTACKS ON NETWORK OPERATOR MANAGEMENT COMPUTERS --- 28) define "RP Tools" --- 29) Here and in elsewhere first use of acronyms should be expanded = (e.g., CRL, etc.) --- 30) Section 4.3 and throughout the document seems to conflate RPKI use = by operators and BGPSEC-enabled routers, while an attempt (intro of S.4) = was made to define 3 classes of attacks that decouple these elements. = Honoring these three classes and cleanly delineating would make the = document much clearer. For example, this _could happen even if the = local network were not BGPSEC-enabled, no?: "If the network operator is BGPSEC-enabled, and the adversary invoked a tool used to request certificates, it could replace valid certificates for routers with ones that might be rejected by BGPSEC- enabled neighbors." =3D=3D=3D=3D=3D ATTACKS ON A REPOSITORY PUBLICATION POINT --- 31) s/ inside or an external threat/ insider or an external threat/ ? --- 32) This seems to entirely gloss over the fact that the local systems = and remote systems will likely in practice handle expired data in very = different ways, and it seems to suggest that data should not be purged = until replaced (what if it's replaced with something compromised), and = that that information should ever be used anyway (using expired data can = causes other systems to need to purge it in BGPSEC, no?): "If repository publication points are unavailable or the retrieved data = is corrupted, an RP can revert to using the cached data This behavior helps insulate RPs = from the immediate effects of DoS attacks on publication points." --- 33) This seems like bad advice to me and should be removed: "Each RP = will decide, locally, whether to continue to make use of or ignore = cached RPKI objects that are stale or expired." We're suggesting we = build and employ this whole system and yet the threat model says we = should use expired data in a PKI? --- 34) Regarding this text, what if there is no "older object", or if this = is precisely the behavior the adversary aimed to trigger: "If an adversary deletes one or more CA certificates, ROAs or the CRL for a publication point, the manifest for that publication point will allow an RP to detect this attack. (The RP would be very unhappy if there is no CRL for the CA instance anyway.) An RP can continue to use the last valid instance of the deleted object as a local policy option), thus minimizing the impact of such an attack. --- 35) Regarding the above, what should an RP do when they detect such an = attack? =20 --- 36) Is this feedback loop a requirement of the system; "Such behavior should result in the CA (or publication point maintainer) = being notified of the problem. An RP can continue to use the last valid = instance of the deleted " --- 37) How does this happen?: " This alerts an RP that there may be a problem, and, hopefully, the entity responsible for the publication point will be asked to remedy the problem (e.g., republish the missing CA certificates and/or ROAs). --- 38) Is this an actual recommendation you're making? This seems like a = really bad idea to me, "An RP cannot know the content of the new certificates or ROAs that are = not present, but it can continue to use what it has cached." --- 39) s/be un aware/be unaware/ --- 40) This seems to contradict your previous recommendation where you = suggest that if stale or expired data exists that an RP should use it: "INRs associated with these objects will be treated as unauthenticated." --- 41) Hope? "Here too the hope is that the CA will be notified of the problem (by = RPs) and will remedy the error." =3D=3D=3D=3D=3D ATTACKS ON AN RPKI CA --- 42) Section 2 only loosely defines "Adversary", unless I missed = something it doesn't define various types of adversaries as this text = suggests: "All of adversaries listed in Section 2 are presumed to be capable of = launching attacks against the computers used to perform CA functions." As noted previously, collapsing the rather ambiguous terms you introduce = in section 3 into section 2's "Adversary" set might make sense. --- 43) "(as first noted by Pogo)" -- Reference/ =3D=3D=3D=3D=3D RESIDUAL VULNERABILITIES --- 44) The difference here is that if that information is used to sign = updates in the routing system which are propagated to BGPSEC-enabled = routers then using stale data can cause considerable churn or = non-deterministic behaviors (including forwarding loops_ in the routing = system. Unless I'm missing something, this is an incredibly bad idea: " 1. The RP may choose to make use of its local cache, employing local configuration settings that tolerate expired or stale objects. (Such behavior is, nominally, always within the purview of an RP in PKI.) Using cached, expired or stale data subjects the RP to attacks that take advantage of the RP's ignorance of changes to this data." --- 45) Here are you suggesting that BGPSEC should (will) protect the BGP = AS_PATH, or introduce a new attribute? =20 "BGPSEC signatures do not protect all attributes associated with an = AS_path. " Either way, some text about divergence between a BGPSEC path and a brand = new attribute would seem to be in order -- although in a previous = section and certainly not in a residual threats section. --- 46) s/AS_path/AS_PATH/ From tim@ripe.net Wed Aug 22 05:16:47 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F9621F86A1 for ; Wed, 22 Aug 2012 05:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5N-80VGSkhay for ; Wed, 22 Aug 2012 05:16:43 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 22BF621F86B7 for ; Wed, 22 Aug 2012 05:16:42 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1T49rQ-0001xt-0G; Wed, 22 Aug 2012 14:16:40 +0200 Received: from s258-sslvpn-1.ripe.net ([193.0.20.231] helo=vpn-73.ripe.net) by dodo.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1T49rP-0001AN-Id; Wed, 22 Aug 2012 14:16:35 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-12-110891570 From: Tim Bruijnzeels In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F61468@Hermes.columbia.ads.sparta.com> Date: Wed, 22 Aug 2012 14:16:35 +0200 Message-Id: <4F0409D4-8874-4495-A23D-1E6BA282B47E@ripe.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F61468@Hermes.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1084) X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816066, check: 20120822 clean X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07193ca7381bbf575c5090ee4baf8331e458 Cc: "sidr@ietf.org" Subject: Re: [sidr] btw: minutes for interim 27 Jul 2012 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 12:16:47 -0000 --Apple-Mail-12-110891570 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 21 Aug 2012, at 19:41, Murphy, Sandra wrote: > What I forwarded before was the pure text of the minutes taken. >=20 > The minutes taker also published the minutes at a web site and = incorporated snapshots of blackboard (literally) drawings. Those might = be useful in understanding the text, so I uploaded the html from the web = site to the IETF site. >=20 > If you look at: > = http://www.ietf.org/proceedings/interim/2012/07/27/sidr/minutes/minutes-in= terim-2012-sidr-5 >=20 A clarification on this: > rsyncd performance testing > full recursive fetch of just data (no validation) > client had all the data, on a local network: just rsync overhead > There is a boundary for clients/sec that can be handled that is = constrained by the CPU. > There is a boundary for the number of concurrent clients that is = constrained by the memory available > smallest test is 70k objects, and the real world isn't near that yet. = yet. In the long term when we have 100k-400k ROAs then these numbers = will become important. > Steve K: server was mac mini, how much memory? > Tim: 2Gb > Steve: we should try this again with a real server > Tim: I think the bigger issue is the CPU size, and there are much = bigger CPU sizes out there of course I don't remember my exact words, but what I meant to say regarding CPU = is this: =3D We see 1.6 clients/second for a repo size of 70k objects with the = mac mini core 2 duo 3GHz cpu. =3D Faster CPUs and more cores are available =3D But the order of magnitude improvement that you can expect here is = in 10s maybe 50s.. =3D And that is still a low number compared to http =3D Increasing memory will allow more concurrent clients =3D But if connection rate is consistently higher than the processing = rate you will see concurrency increase until it hits the ceiling even if = you increase memory I think this is an intrinsic problem to the server having to invest a = relatively large amount of CPU and memory when using rsync, just like = Randy pointed at in his remark about my slide here: > slide 26: latency has a huge impact > Randy: so what you've traded is the CPU/memory cost for network cost? > Tim: Yes > we're pushing work from the repo server to the clients because I think = it will scale better Like I said, I don't remember the exact words I used during the interim = so this may have been unclear then, even so I hope this clarifies = things. Thanks Tim= --Apple-Mail-12-110891570 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
What I forwarded before was the pure text of the = minutes taken.

The minutes taker also published the minutes at a = web site and incorporated snapshots of blackboard (literally) drawings. =  Those might be useful in understanding the text, so I uploaded the = html from the web site to the IETF site.

If you look at:
http://www.ietf.org/proceedings/interim/2012/07= /27/sidr/minutes/minutes-interim-2012-sidr-5


A clarification on = this:

rsyncd performance testing
  • full = recursive fetch of just data (no validation)
  • client had all the = data, on a local network: just rsync overhead
  • There is a = boundary for clients/sec that can be handled that is constrained by the = CPU.
  • There is a boundary for the number of concurrent clients = that is constrained by the memory available
  • smallest test is 70k = objects, and the real world isn't near that yet. yet. In the long term = when we have 100k-400k ROAs then these numbers will become = important.
  • Steve K: server was mac mini, how much = memory?
    • Tim: 2Gb
    • Steve: we should try this again with a = real server
    • Tim: I think the bigger issue is the CPU size, and = there are much bigger CPU sizes out there of = course
I don't remember my exact = words, but what I meant to say regarding CPU is = this:

=3D We see 1.6 clients/second for a repo = size of 70k objects with the mac mini core 2 duo 3GHz cpu.
=3D = Faster CPUs and more cores are available
=3D But the order of = magnitude improvement that you can expect here is in 10s maybe = 50s..
=3D And that is still a low number compared to = http

=3D Increasing memory will allow more = concurrent clients
=3D But if connection rate is consistently = higher than the processing rate you will see concurrency increase until = it hits the ceiling even if you increase = memory

I think this is an intrinsic problem to = the server having to invest a relatively large amount of CPU and memory = when using rsync, just like Randy pointed at in his remark about my = slide here:

slide 26: latency has a huge impact
  • Randy: so = what you've traded is the CPU/memory cost for network cost?
  • Tim: = Yes
  • we're pushing work from the repo server to the clients = because I think it will scale = better

Like I said, I = don't remember the exact words I used during the interim so this may = have been unclear then, even so I hope this clarifies = things.


Thanks
Tim=
= --Apple-Mail-12-110891570-- From danny@tcb.net Wed Aug 22 19:41:33 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E23621F8510 for ; Wed, 22 Aug 2012 19:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avtJQlZIiUUJ for ; Wed, 22 Aug 2012 19:41:32 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4D221F850D for ; Wed, 22 Aug 2012 19:41:32 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 0F68C2680C7; Wed, 22 Aug 2012 20:41:32 -0600 (MDT) Received: from new-host-10.home (pool-173-72-146-12.clppva.fios.verizon.net [173.72.146.12]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 22 Aug 2012 20:41:31 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=173.72.146.12; client-port=62716; syn-fingerprint=65535:48:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F555CB@Hermes.columbia.ads.sparta.com> Date: Wed, 22 Aug 2012 22:41:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24B20D14B2CD29478C8D5D6E9CBB29F625F555CB@Hermes.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1278) Cc: "sidr@ietf.org" Subject: Re: [sidr] RPKI <-> allocation consistency X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 02:41:33 -0000 Admittedly, I'm not certain what triggered this, but clearly, your email = to me suggests that others have expressed concern of consistency and = collisions, a concern expressed by the IAB as well. As such, I have a = question below. On Aug 10, 2012, at 4:45 PM, Murphy, Sandra wrote: > speaking as regular ol' member >=20 > About allocation <-> RPKI consistency >=20 > The RPKI is a certification of resource holding. Because the = allocation databases continue to also record allocations, there's = duplication of information between the RPKI and the allocation = databases. >=20 > Having duplicate records of the same data always presents an issue of = consistency. We know we have this issue (have known it from the = beginning), any resource certification outside the allocation system = would, so we need to work on how to handle it. >=20 > Handling it is out-of-band. Consistency will be a matter of process, = to ensure that allocation actions are bound to issuance of consistent CA = certificates (if and when one is issued) and vice versa. Monitoring the = two to spot inconsistencies will be another process. >=20 > Duplicates may be valid. There may be reasons for multiple CA = certificates being issued for exactly the same prefix space. Transfer = (or at least the only method of transfer discussed in the wg) would = result in multiple CA certificates being issued for exactly the same = prefix space, for make-before-break purposes. >=20 > We already have a potential for inconsistency. As noted in the IAB = statement on the RPKI, multiple trust anchors present a risk of = conflicting certifications for the same address block. We do not yet = have a single root trust anchor. No need for panic, the RIRs are aware = and I trust they have process in mind to ensure consistency. (This is = a contentious issue - hopefully that's worded with sufficient care and = balance.) But that's another case where consistency is/will be ensured = by process. Sandy (or others in the know), can you shed any light on the process you = have in mind to ensure consistency? Particularly from the perspective = of a prospective RP? Pointers to process (e.g., RIR processes in the = works) are fine. Thanks,=20 -danny= From eosterweil@verisign.com Thu Aug 23 07:21:41 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B357C21F856F for ; Thu, 23 Aug 2012 07:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIOaX2emecPV for ; Thu, 23 Aug 2012 07:21:39 -0700 (PDT) Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id 50E1121F856C for ; Thu, 23 Aug 2012 07:21:30 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKUDY8aScR6i6Uqf+La6qMfPoXPXtRvhad@postini.com; Thu, 23 Aug 2012 07:21:36 PDT Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q7NELP9P016826; Thu, 23 Aug 2012 10:21:25 -0400 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.29.242]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Aug 2012 10:21:24 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Thu, 23 Aug 2012 10:21:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24B20D14B2CD29478C8D5D6E9CBB29F625F555CB@Hermes.columbia.ads.sparta.com> To: Danny McPherson X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 23 Aug 2012 14:21:24.0676 (UTC) FILETIME=[93867040:01CD813A] Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] RPKI <-> allocation consistency X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 14:21:41 -0000 On Aug 22, 2012, at 10:41 PM, Danny McPherson wrote: >=20 > Admittedly, I'm not certain what triggered this, but clearly, your = email to me suggests that others have expressed concern of consistency = and collisions, a concern expressed by the IAB as well. As such, I have = a question below. >=20 > On Aug 10, 2012, at 4:45 PM, Murphy, Sandra wrote: >=20 >> speaking as regular ol' member >>=20 >> About allocation <-> RPKI consistency >>=20 >> The RPKI is a certification of resource holding. Because the = allocation databases continue to also record allocations, there's = duplication of information between the RPKI and the allocation = databases. >>=20 >> Having duplicate records of the same data always presents an issue of = consistency. We know we have this issue (have known it from the = beginning), any resource certification outside the allocation system = would, so we need to work on how to handle it. >>=20 >> Handling it is out-of-band. Consistency will be a matter of process, = to ensure that allocation actions are bound to issuance of consistent CA = certificates (if and when one is issued) and vice versa. Monitoring the = two to spot inconsistencies will be another process. >>=20 >> Duplicates may be valid. There may be reasons for multiple CA = certificates being issued for exactly the same prefix space. Transfer = (or at least the only method of transfer discussed in the wg) would = result in multiple CA certificates being issued for exactly the same = prefix space, for make-before-break purposes. >>=20 >> We already have a potential for inconsistency. As noted in the IAB = statement on the RPKI, multiple trust anchors present a risk of = conflicting certifications for the same address block. We do not yet = have a single root trust anchor. No need for panic, the RIRs are aware = and I trust they have process in mind to ensure consistency. (This is = a contentious issue - hopefully that's worded with sufficient care and = balance.) But that's another case where consistency is/will be ensured = by process. >=20 >=20 > Sandy (or others in the know), can you shed any light on the process = you have in mind to ensure consistency? Particularly from the = perspective of a prospective RP? Pointers to process (e.g., RIR = processes in the works) are fine. Indeed, I vaguely recall some conversations (on the list?) about the = specific consistency model that the RPKI is trying to achieve. I wasn't = able to unearth the thread, but what was the conclusion? That is, what = is the consistency model that the RPKI design team is striving for? Thanks, Eric= From eosterweil@verisign.com Thu Aug 23 07:27:38 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82AB521F8582 for ; Thu, 23 Aug 2012 07:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lof1RU5IdNYr for ; Thu, 23 Aug 2012 07:27:38 -0700 (PDT) Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE0721F8534 for ; Thu, 23 Aug 2012 07:27:26 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKUDY9zupmRvqL/Z3IrEhX4GuSf7mCAABg@postini.com; Thu, 23 Aug 2012 07:27:37 PDT Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q7NERLfp003432; Thu, 23 Aug 2012 10:27:21 -0400 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.29.242]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Aug 2012 10:27:21 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F55562@Hermes.columbia.ads.sparta.com> Date: Thu, 23 Aug 2012 10:27:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <761BD3D3-2906-45B8-A13D-942AD3C51F34@verisign.com> References: <53D504DF-C0A3-4CFC-AD93-689630336F7D@apnic.net> <097D025D-1879-455C-BB14-F9C8BFAC88AA@ripe.net> , <50250C7F.8060603@gmail.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F55562@Hermes.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 23 Aug 2012 14:27:21.0402 (UTC) FILETIME=[682681A0:01CD813B] Cc: "sidr@ietf.org" Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 14:27:38 -0000 On Aug 10, 2012, at 10:49 AM, Murphy, Sandra wrote: > speaking as co-chair >=20 > A reminder to the group that the question is whether to adopt this = draft as a working group work item. The content of the draft is not the = discussion point here, the acceptance for the group to work on it. >=20 > Whether you like the content or not, you should say whether you think = the wg should adopt this draft. >=20 > --Sandy, speaking as co-chair I do not think this should be adopted as a wg item. I think the topic = of this draft fits better as supporting text in another existing draft = (we have a plethora of those to choose from), but the contributions / = opinions in this draft do not (imho) stand firmly enough on their own to = be an atomic draft. Eric From Sandra.Murphy@sparta.com Thu Aug 23 09:09:03 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1028D21F85FC for ; Thu, 23 Aug 2012 09:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEDywc1bLCr9 for ; Thu, 23 Aug 2012 09:08:58 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 548D821F85A7 for ; Thu, 23 Aug 2012 09:08:57 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q7NG8u7t027654; Thu, 23 Aug 2012 11:08:56 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q7NG8uUH001798; Thu, 23 Aug 2012 11:08:56 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%21]) with mapi id 14.01.0355.002; Thu, 23 Aug 2012 12:09:45 -0400 From: "Murphy, Sandra" To: Danny McPherson Thread-Topic: [sidr] RPKI <-> allocation consistency Thread-Index: Ac13EBo5wrqMsPdrRdKYnzi7/aF9VwJ6jE8AAA+kTbg= Date: Thu, 23 Aug 2012 16:09:44 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F62D54@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F555CB@Hermes.columbia.ads.sparta.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] RPKI <-> allocation consistency X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 16:09:03 -0000 Speaking as regular ol' member=0A= =0A= On Wednesday, August 22, 2012 10:41 PM, Danny McPherson said:=0A= =0A= >Admittedly, I'm not certain what triggered this, but clearly, =0A= >your email to me suggests that others have expressed concern =0A= >of consistency and collisions, a concern expressed by the =0A= >IAB as well. As such, I have a question below.=0A= =0A= The trigger was some of the concerns expressed as part of the call for adop= tion of the grandparenting draft. Some of the comments concerned the conte= nt, where suggestions were made of potential grandparent RPKI actions.=0A= =0A= Note that the concerns in the email exchange were principally about inconsi= stencies between the RPKI and the allocation system. =0A= =0A= I am well aware of the IAB concerns (and thank you for leading that effort!= ) and refer to them later in my message. =0A= =0A= >=0A= >Sandy (or others in the know), can you shed any light on the =0A= >process you have in mind to ensure consistency? Particularly from =0A= >the perspective of a prospective RP? Pointers to process (e.g., =0A= >RIR processes in the works) are fine.=0A= =0A= IMHO (speaking as regular ol' member), the SIDR process in mind is as the I= AB statement says: a single trust anchor. The origin ops document says "I= t is assumed that eventually there will be a single root trust anchor for t= he public address space."=0A= =0A= It has been pointed out that the CP says that =0A= Each CA operating within the context of this PKI MUST employ=0A= procedures to ensure that each certificate it issues accurately=0A= reflects its records =0A= which is another "process in mind" about consistency of the RPKI and the al= location system.=0A= =0A= I don't speak for the RIRs. But the NRO has made a public request that ICA= NN "enter into discussions" to task ICANN with the management of the global= trust anchor, which is a good step. I have no view of the progress of tha= t discussion. I'd be curious to hear from anyone who does and may (is perm= itted to) speak of it!=0A= =0A= --Sandy, speaking as regular ol' member=0A= From eosterweil@verisign.com Thu Aug 23 12:46:31 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56BD421F86BA for ; Thu, 23 Aug 2012 12:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4Ism1lqUG9X for ; Thu, 23 Aug 2012 12:46:30 -0700 (PDT) Received: from exprod6og114.obsmtp.com (exprod6og114.obsmtp.com [64.18.1.33]) by ietfa.amsl.com (Postfix) with ESMTP id 9B08021F86A2 for ; Thu, 23 Aug 2012 12:46:28 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob114.postini.com ([64.18.5.12]) with SMTP ID DSNKUDaIk1oqdCKsTx7ZnfWQojNS7HEijZya@postini.com; Thu, 23 Aug 2012 12:46:30 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q7NJkMi5031606; Thu, 23 Aug 2012 15:46:23 -0400 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.29.242]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Aug 2012 15:46:21 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F62D54@Hermes.columbia.ads.sparta.com> Date: Thu, 23 Aug 2012 15:46:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6E0C3E50-20C0-4EC9-B620-23DD4B29B3D2@verisign.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F555CB@Hermes.columbia.ads.sparta.com>, <24B20D14B2CD29478C8D5D6E9CBB29F625F62D54@Hermes.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 23 Aug 2012 19:46:21.0931 (UTC) FILETIME=[F8CB73B0:01CD8167] Cc: "sidr@ietf.org" Subject: Re: [sidr] RPKI <-> allocation consistency X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 19:46:31 -0000 On Aug 23, 2012, at 12:09 PM, Murphy, Sandra wrote: > Speaking as regular ol' member >=20 > On Wednesday, August 22, 2012 10:41 PM, Danny McPherson said: >=20 >> Admittedly, I'm not certain what triggered this, but clearly,=20 >> your email to me suggests that others have expressed concern=20 >> of consistency and collisions, a concern expressed by the=20 >> IAB as well. As such, I have a question below. >=20 > The trigger was some of the concerns expressed as part of the call for = adoption of the grandparenting draft. Some of the comments concerned = the content, where suggestions were made of potential grandparent RPKI = actions. >=20 > Note that the concerns in the email exchange were principally about = inconsistencies between the RPKI and the allocation system.=20 >=20 > I am well aware of the IAB concerns (and thank you for leading that = effort!) and refer to them later in my message. =20 >=20 >>=20 >> Sandy (or others in the know), can you shed any light on the=20 >> process you have in mind to ensure consistency? Particularly from=20 >> the perspective of a prospective RP? Pointers to process (e.g.,=20 >> RIR processes in the works) are fine. >=20 > IMHO (speaking as regular ol' member), the SIDR process in mind is as = the IAB statement says: a single trust anchor. The origin ops document = says "It is assumed that eventually there will be a single root trust = anchor for the public address space." A single trust anchor is certainly an important goal, and I think it = would likely disambiguate a lot of the problems that seem to be getting = raised. However, until then why don't we still need to propose a = concrete consistency processes? Is the RPKI not intended to be useful = before then? >=20 > It has been pointed out that the CP says that=20 > Each CA operating within the context of this PKI MUST employ > procedures to ensure that each certificate it issues accurately > reflects its records=20 > which is another "process in mind" about consistency of the RPKI and = the allocation system. I think this is one very important point worth making some comments = about, openly. What are the current plans to help the RPKI's structure = remain consistent with the allocation hierarchy? Saying something like = the above seems to be tantamount to simply charging each participant = with the responsibility to try really really extra super hard to be a = good citizen. However, as an RP, that's clearly cold comfort. Without = outlining a transparent and rigorous process, how can consumers (the = RPs) ever hope to have faith that the structure defined by the RPKI has = any meaningful correlation with the actual allocation hierarchy? I = think this needs to be outlined more clearly, or the overall RPKI design = needs some rework in order to obviate the need for the specification of = these unspecified processes. Eric= From eosterweil@verisign.com Fri Aug 24 12:18:50 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B84721F860B; Fri, 24 Aug 2012 12:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLL4qHuPt6dj; Fri, 24 Aug 2012 12:18:49 -0700 (PDT) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by ietfa.amsl.com (Postfix) with ESMTP id 6260821F8609; Fri, 24 Aug 2012 12:18:48 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKUDfTkhdCzdHmdoY+4CqKilmcY7KyUwY/@postini.com; Fri, 24 Aug 2012 12:18:48 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q7OJIdCI031990; Fri, 24 Aug 2012 15:18:41 -0400 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.29.242]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Aug 2012 15:18:38 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Fri, 24 Aug 2012 15:18:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <62687358-7D4F-48E3-BEE9-AF56D62C052E@verisign.com> References: To: Christopher Morrow X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 24 Aug 2012 19:18:38.0772 (UTC) FILETIME=[43E34740:01CD822D] Cc: sidr-chairs@ietf.org, sidr-ads@tools.ietf.org, sidr@ietf.org Subject: Re: [sidr] WGLC: draft-ietf-sidr-origin-ops- X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 19:18:50 -0000 I've reviewed this draft and have a number of comments: At a high level, I think this draft is a very important piece of the = sidr landscape, so I certainly applaud Randy for writing it. - The second sentence in the abstract is a fragment, without a direct = object. Section 1 Intro: - 1st paragraph: if we are going to predicate advice on terms like = "widespread deployment," I think we need define them. I know we all = roughly know things like, "widespread means `a lot' of deployment," but = the assertion that RPKI-based origin validation has a dependency on some = level of penetration either needs to be qualified (or better yet, = quantified) or removed, imho. - 2nd para: "... the next year to five years." As a living document, = this work might want to stay away from relative time references. Will = this statement need to be updated every year? - 2nd para: "... eventually there will be a single root..." Is this = assumed in order for this document's advice to matter? It seems like = operational advice ought to be more topical than this. The advice in = this draft is intended to be relevant before the single root, so this = reference seems quite out of place. - 3rd para: s/AS's/AS'/ Section 3: - 2nd para: Some intuition behind _why_ hierarchy affects performance = would be quite useful. - 3rd para: As this is an operational document, and there is nothing = else available, shouldn't this text explain that there is currently no = choice of what to use? - 4th para: The edict that operators should make use of the = cache-chaining facility seems like it should have some operational = explanation/justification/intuition/something. It may be good advice, = but shouldn't there be some rationale that allows for the evaluation of = tradeoffs? - 4th para: "Of course, the recipient relying parties SHOULD re-validate = the date." This makes it seem (imho) like the benefits of the = immediately preceding advice might be lessened... Without an explanation = of the rationale, the reader is forced to ask if doing this re-validtion = wouldn't cause the same scaling worries as before the chaining. Without = a more detailed explanation, the reader really can't tell. - 5th para: This seems quite inappropriate to me. We need to know how = this design will scale and function in an operational setting. If = there's any place that this should be discussed, it would seem to be = here. The operational behavior, configuration, and dynamics of the = system seem like they must be described in the operational guidance = documents. How else should an operator know what configurations result = in which behaviors, and scaling properties, etc? I don't think this = draft can simply punt by saying these operational concerns are beyond = the scope of its operational guidance. - 6th para: What if the objects in a network are multi-mastered? I = wasn't able to tell what this paragraph's guidance was, but it seemed to = be a little narrow in its application. Maybe it is superfluous? - 7th para: I think this advice seems a little dilute, and may not be as = useful as it could be. Clearly, network configurations can be quite = varied, right? Since this is the case, I think it would be much more = helpful for the author to build a strawman here, and overlay advice on = it. In fact, perhaps a set of running strawmen throughout the document = would allow various pieces of advice to be hung on specific examples = that operators could then adapt to their own configurations. At the = very least, it would provide some context, and possibly some additional = substance to the document. - 8th para: This seems like good advice, but it could use an example = (i.e., the above comment). - 9th para: This paragraph seems to give direction without intuition of = the cost/benefits tradeoffs of this decision or the deployment decisions = (like how many). More generally, it seems like there is important = advice to give here, but maybe the experts should frame the advice in = terms of something like: what (specifically) does an operator pay for = $n$ peers and what (specifically) does she gain? - 10th para: I don't think the text is clear: it seems like upstreams = carrying traffic and the trust one has in attestation objects are quite = different. I don't think this is an apt analogy, and it really confuses = me (as a reader). As a result, it's hard for me to understand what the = point of that paragraph is (given the inapt analogy). - 10th para: With the above caveat that I might not be understanding = what is being said, the final sentence raises additional concerns for = me. If we recommend that operators use each others' caches, and then = force them to revalidate, we are either introducing a new attack vector = (cache poisoning of non-authoritative caches), or we increasing the = attack surface of an existing attack vector (more caches must be = validated because they can lie to me). Either way, I don't see the = benefit gained here, just the drawback. - 11th para: How does trusting caches relate to mandatory revalidation? = As I read the text (at least, as written), it seems to me that this is a = conflation of very different concepts. - 12th para: Should we define the term ``super-block'' before using it = here? I'm more used to seeing it in the context of filesystems, but = that doesn't mean we can't overload its definition here... I just think = we need to do so before using it. - 13th para: I think we need to add some context in this paragraph. = Specifically, I suggest adding the following text t the penultimate = sentence, ``, but only for those external routers that have also = deployed RPKI-based origin validation.'' And adding the following text = to the final sentence, `` for just those RPs.'' - 15th para: I think it is important to be specific, and after claiming = that something is ``more likely to be noticed,'' I think we ought to = describe _how_ one might/should do so, in an operational setting. As = before, I'd suggest some advice be given through an example. - 17th para: I think this paragraph makes good sense, but can we get a = more quantitative discussion here? I was just thinking that since this = is an operational/engineering document, it might be good to shift this = part from the qualitative end of the spectrum over more to the = quantitative side. - 20th para: This paragraph felt a little prescriptive from the = policy/provisioning side, to me. I caught myself wondering if this kind = of advice really belongs here? If it does, then maybe it would be more = appropriate to just mention that proxy registration of this kind of data = is an option, and cite how well that has worked elsewhere (like with = IRRs and stuff)? - 21st para: s/^While // - 21st para: This paragraph suggest a period of ``four to six hours.'' = I think we need some kind of explanation for these numbers. As an = operations document, it seems to me that we should be discussing = tradeoffs and the relative value of different settings, etc. Section 4: - 2nd para: I worry that this advice is a little dilute, and (as a = result) kind of falls a little limp (i.e., I was not able to clearly see = what it was trying to explain). I think if we had been carrying a = strawman (or some strawmen) through the document, it would help bring = the point of this paragraph into focus. - 3rd para: In the same vein as the above, it seems like some = examples/strawmen would be quite apropos. Section 5:=20 - 3rd para: ``10.0.666.0/24'' ? maybe 10.0.6.0/24 ? - 4th para: This paragraph seems to be offering tractable guidance. Is = there any thinking around the tradeoffs for when to change policy? - 5th para: s/AS-path/AS_PATH/g - 6th para: s/it's/its/ - 7th para: Should ``Local Pref'' be normalized to match earlier = discussions of ``Local-Preference''? - 10th para: I think we need to add a little bit of text. Perhaps add = to the last sentence, `` for the same prefix''? Section 6: - 1st para: The comment/implication that incoherency is a quality of all = distributed caching systems is totally untrue. In fact, there are many = cache protocols with different specific consistency models that = accomplish this. To claim something is not being attempted with RPKI is = one thing. To claim that no system is able to accomplish this is quite = different. Moreover, why is this (clearly a design issue with RPKI) = being discussed in this draft (an operational guidance draft)? This = seems like it is definitely the wrong place to talk about this, but = regardless, the text is quite wrong. - 2nd para: I think this paragraph brings up an important point, but = doesn't mention a very important operational side effect of that point. = I suggest adding one more sentence to the end, ``Alternately, since no = consistency model is attempted, it is possible that routing may not be = able to converge in those networks deploying this approach without = manual intervention.'' - 3rd para + 4th para: I don't understand how this paragraph is = conveying helpful operational advice? - 10th para: Why was 1 hour chosen? What are the tradeoffs, etc? Section 7: s/AS-Path/AS_PATH/g Thanks, Eric On Aug 17, 2012, at 11:03 AM, Christopher Morrow wrote: > Hello WG folk, > This draft has undergone 9 revisions since the last WGLC, which seemed > to end with requests for changes by the authors. > Can we now have a final-final-please-let's-progress WGLC for this > draft now? Let's end the call: 08/31/2012 (Aug 31 2012). >=20 > Htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sidr-origin-ops-19 >=20 > Abstract: > "Deployment of RPKI-based BGP origin validation has many operational > considerations. This document attempts to collect and present the > most critical. It is expected to evolve as RPKI-based origin > validation is deployed and the dynamics are better understood." >=20 > Thanks! > -Chris > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From kent@bbn.com Sat Aug 25 02:19:25 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D426721F84F9 for ; Sat, 25 Aug 2012 02:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.523 X-Spam-Level: X-Spam-Status: No, score=-106.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8I5gzi4mMqWF for ; Sat, 25 Aug 2012 02:19:25 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id BBCB621F84F5 for ; Sat, 25 Aug 2012 02:19:24 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:55784 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1T5CWX-0008CD-2B; Sat, 25 Aug 2012 05:19:23 -0400 Message-ID: <50389897.3040503@bbn.com> Date: Sat, 25 Aug 2012 05:19:19 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: sidr@ietf.org, eosterweil@verisign.com References: <24B20D14B2CD29478C8D5D6E9CBB29F625F555CB@Hermes.columbia.ads.sparta.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040805030004090302010106" Subject: Re: [sidr] RPKI <-> allocation consistency X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 09:19:25 -0000 This is a multi-part message in MIME format. --------------040805030004090302010106 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Eric, The short answer to your question is that each CA is supposed to ensure that the certs it issues match its allocation database. This applies to both cert issuance and cert revocation. A quick look at the RPKI RFCs provides a few examples of statements about the RPKI consistency model. Steve ----- RFC 6487 (Certificate Profile) Intro: Resource certificates are to be used in a manner that is consistent with the RPKI Certificate Policy (CP) [RFC6484].*They are issued by* *entities that assign and/or allocate public INRs, and thus the RPKI* *is aligned with the public INR distribution function.* *The specific goal for the associated RPKI is to precisely match the INR* *allocation structure through an aligned certificate structure* *that describes the allocation and its context within the INR* *distribution hierarchy.* RFC 6484 (RPKI CP) Overview *This PKI is designed to support validation of claims by current* *holders of INRs, in accordance with the records of the organizations* *that act as Certification Authorities (CAs) in this PKI.* ** Section 3.3.2.Identification and Authentication for Re-Key after Revocation *Each CA operating within the context of this PKI MUST employ* *procedures to ensure that each certificate it issues accurately* *reflects its records with regard to the organization to which the CA* *has distributed the INRs identified in the certificate.**The specific* *procedures employed for this purpose MUST be described by the CPS for* *each CA.* Section 3.4.Identification and Authentication for Revocation Request Each CA operating within the context of this PKI MUST employ procedures to ensure that: *oan organization requesting revocation is the legitimate holder of* *the certificate to be revoked.* o*each certificate it revokes accurately reflects its records with* *regard to the organization to which the CA has distributed the* *INRs identified in the certificate*. Section 4.2.2.Approval or Rejection of Certificate Applications *Certificate applications MUST be approved based on the normal* *business practices of the entity operating the CA, based on the CA's* *records of INR holders.* > Indeed, I vaguely recall some conversations (on the list?) about the specific consistency model that the RPKI is trying to achieve. I wasn't able to unearth the thread, but what was the conclusion? That is, what is the consistency model that the RPKI design team is striving for? > > Thanks, > > Eric > --------------040805030004090302010106 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Eric,

The short answer to your question is that each CA is supposed to ensure that the certs it issues match its allocation database. This applies to both cert issuance and cert revocation. A quick look at the RPKI RFCs provides a few examples of statements about the RPKI consistency model.

Steve
-----

RFC 6487 (Certificate Profile)

 

Intro:

 

   Resource certificates are to be used in a manner that is consistent

   with the RPKI Certificate Policy (CP) [RFC6484].  They are issued by

   entities that assign and/or allocate public INRs, and thus the RPKI

   is aligned with the public INR distribution function.

 

   The specific goal for the associated RPKI is to precisely match the INR

   allocation structure through an aligned certificate structure

   that describes the allocation and its context within the INR

   distribution hierarchy.

 

 

 

 

RFC 6484 (RPKI CP)

 

Overview

 

 

   This PKI is designed to support validation of claims by current

   holders of INRs, in accordance with the records of the organizations

   that act as Certification Authorities (CAs) in this PKI.

 

 

Section 3.3.2.  Identification and Authentication for Re-Key after Revocation

 

   Each CA operating within the context of this PKI MUST employ

   procedures to ensure that each certificate it issues accurately

   reflects its records with regard to the organization to which the CA

   has distributed the INRs identified in the certificate.  The specific

   procedures employed for this purpose MUST be described by the CPS for

   each CA.

 

 

Section 3.4.  Identification and Authentication for Revocation Request

 

   Each CA operating within the context of this PKI MUST employ

   procedures to ensure that:

 

   o  an organization requesting revocation is the legitimate holder of

      the certificate to be revoked.

 

   o  each certificate it revokes accurately reflects its records with

      regard to the organization to which the CA has distributed the

      INRs identified in the certificate.

 

Section 4.2.2.  Approval or Rejection of Certificate Applications

 

   Certificate applications MUST be approved based on the normal

   business practices of the entity operating the CA, based on the CA's

   records of INR holders.




Indeed, I vaguely recall some conversations (on the list?) about the specific consistency model that the RPKI is trying to achieve.  I wasn't able to unearth the thread, but what was the conclusion?  That is, what is the consistency model that the RPKI design team is striving for?

Thanks,

Eric

--------------040805030004090302010106-- From eosterweil@verisign.com Mon Aug 27 11:07:10 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A316B21F8565 for ; Mon, 27 Aug 2012 11:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.339 X-Spam-Level: X-Spam-Status: No, score=-6.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VutPEXLgIara for ; Mon, 27 Aug 2012 11:07:10 -0700 (PDT) Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) by ietfa.amsl.com (Postfix) with ESMTP id D0AE721F855D for ; Mon, 27 Aug 2012 11:07:09 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKUDu3SiExSEYCGhCXjwBo1eI6rpxrJt9L@postini.com; Mon, 27 Aug 2012 11:07:09 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q7RI72He009822; Mon, 27 Aug 2012 14:07:06 -0400 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.29.242]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Aug 2012 14:07:02 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: <50389897.3040503@bbn.com> Date: Mon, 27 Aug 2012 14:07:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <97856400-9F70-4AEC-AF91-A0673A6D716D@verisign.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F555CB@Hermes.columbia.ads.sparta.com> <50389897.3040503@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 27 Aug 2012 18:07:02.0058 (UTC) FILETIME=[C21600A0:01CD847E] Cc: sidr@ietf.org Subject: Re: [sidr] RPKI <-> allocation consistency X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 18:07:10 -0000 Thanks Steve, this is very helpful! However, I was also referring to the consistency model as viewed by the = RPs. I think this wasn't clear in my email, sorry. Clearly the = structure served by CAs (which you outlined below) is a critical first = step. To that point, I think I mentioned some of this in a follow-on = email to this thread. However, I think the consistency model of the RPs = (i.e. will they all have the same view/time ordered view/partial = view/etc. of these certs) is an important consideration too, right? Eric On Aug 25, 2012, at 5:19 AM, Stephen Kent wrote: > Eric, >=20 > The short answer to your question is that each CA is supposed to = ensure that the certs it issues match its allocation database. This = applies to both cert issuance and cert revocation. A quick look at the = RPKI RFCs provides a few examples of statements about the RPKI = consistency model. >=20 > Steve > ----- >=20 > RFC 6487 (Certificate Profile) > =20 > Intro: > =20 > Resource certificates are to be used in a manner that is consistent > with the RPKI Certificate Policy (CP) [RFC6484]. They are issued = by > entities that assign and/or allocate public INRs, and thus the RPKI > is aligned with the public INR distribution function. > =20 > The specific goal for the associated RPKI is to precisely match the = INR > allocation structure through an aligned certificate structure > that describes the allocation and its context within the INR > distribution hierarchy. > =20 > =20 > =20 > =20 > RFC 6484 (RPKI CP) > =20 > Overview > =20 > =20 > This PKI is designed to support validation of claims by current > holders of INRs, in accordance with the records of the = organizations > that act as Certification Authorities (CAs) in this PKI. > =20 > =20 > Section 3.3.2. Identification and Authentication for Re-Key after = Revocation > =20 > Each CA operating within the context of this PKI MUST employ > procedures to ensure that each certificate it issues accurately > reflects its records with regard to the organization to which the = CA > has distributed the INRs identified in the certificate. The = specific > procedures employed for this purpose MUST be described by the CPS = for > each CA. > =20 > =20 > Section 3.4. Identification and Authentication for Revocation Request > =20 > Each CA operating within the context of this PKI MUST employ > procedures to ensure that: > =20 > o an organization requesting revocation is the legitimate holder = of > the certificate to be revoked. > =20 > o each certificate it revokes accurately reflects its records with > regard to the organization to which the CA has distributed the > INRs identified in the certificate. > =20 > Section 4.2.2. Approval or Rejection of Certificate Applications > =20 > Certificate applications MUST be approved based on the normal > business practices of the entity operating the CA, based on the = CA's > records of INR holders. >=20 >=20 >> Indeed, I vaguely recall some conversations (on the list?) about the = specific consistency model that the RPKI is trying to achieve. I wasn't = able to unearth the thread, but what was the conclusion? That is, what = is the consistency model that the RPKI design team is striving for? >>=20 >> Thanks, >>=20 >> Eric >>=20 >>=20 >=20 From kent@bbn.com Mon Aug 27 21:23:07 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CAA721E803F for ; Mon, 27 Aug 2012 21:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.529 X-Spam-Level: X-Spam-Status: No, score=-106.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dHMaJAyLkRU for ; Mon, 27 Aug 2012 21:23:07 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0795421E8039 for ; Mon, 27 Aug 2012 21:23:07 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:36914 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1T6DKT-000AL4-O5; Tue, 28 Aug 2012 00:23:06 -0400 Message-ID: <503C47A8.7030700@bbn.com> Date: Tue, 28 Aug 2012 00:23:04 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Eric Osterweil References: <24B20D14B2CD29478C8D5D6E9CBB29F625F555CB@Hermes.columbia.ads.sparta.com> <50389897.3040503@bbn.com> <97856400-9F70-4AEC-AF91-A0673A6D716D@verisign.com> In-Reply-To: <97856400-9F70-4AEC-AF91-A0673A6D716D@verisign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr@ietf.org Subject: Re: [sidr] RPKI <-> allocation consistency X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 04:23:07 -0000 Eric, It seems likely that not all RPs will have the same view of INR allocation, e.g., due to differences in when RPs fetch data from repositories. This seems analogous to the transient inconsistencies that ISPs see today if they use IRR or other INR data sources, for similar reasons. I think Rob Austein has referred to the repository system as being "loosely consistent," a reasonable target for a large scale, distributed database with entries maintained by a large group of folks. Steve From kent@bbn.com Tue Aug 28 02:33:20 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 319BD21F84D2 for ; Tue, 28 Aug 2012 02:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.326 X-Spam-Level: X-Spam-Status: No, score=-105.326 tagged_above=-999 required=5 tests=[AWL=-1.142, BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpgocIZvReK8 for ; Tue, 28 Aug 2012 02:33:08 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id B088121F849C for ; Tue, 28 Aug 2012 02:33:07 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:58180 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1T6IAT-000ByZ-EY; Tue, 28 Aug 2012 05:33:06 -0400 Message-ID: <503C904F.2040609@bbn.com> Date: Tue, 28 Aug 2012 05:33:03 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: sidr@ietf.org, danny@tcb.net References: <24B20D14B2CD29478C8D5D6E9CBB29F625F5604B@Hermes.columbia.ads.sparta.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030800060803080209010501" Subject: Re: [sidr] Some comments on draft-ietf-sidr-bgpsec-threats-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 09:33:20 -0000 This is a multi-part message in MIME format. --------------030800060803080209010501 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Danny, here are replies to the issues you raised wrt the threats doc. Steve -------- I am surprised that external systems (e.g., NTP) are not mentioned at all in this document? *I will add some text to note that the use of certificates, CRLs, and other RPKI signed products requires access to a reliable (though not highly precise) time source by the devices that process them. For the RPKI, the current deployment model calls for such processing to be performed by servers, not routers. For BGPSEC, the need for a reliable time source may extend to routers, if BGPSEC path signatures carry an expiration time. * Also, this document makes no distinction between eBGP and iBGP speakers, yet there are certainly places where text and context would suggest it is certainly necessary. Some hints of this below. *I will add text noting that the focus of the doc is eBGP, not iBGP.* I believe this document needs a major overhaul before publication as a WG document. More comments below.. -danny ===== ABSTRACT 1) Regarding "Intended Status: Standards Track", I'd expect any standalone Threat Model draft would be should be Informational. *Agree. Fixed.* 2) " Enabling an AS to verify that the AS-PATH represented in a route matches the path travelled by the NLRI for the route" 2.1): s/AS-PATH/AS_PATH/ *fixed.* 2.2): I do not believe that even BGPSEC does this. Instead, in introduces a new attribute which BGPSEC secures, and it forces no parity between the new attribute and the old attribute. See 3) below, but absent some clarification of this I am not comfortable with this text as written. *This text is taken from the charter (including the "AS-PATH" typo). A discussion of whether the BGPSEC design addresses this charter goal may be appropriate for the BGPSEC architecture document, but not here. * ** ===== INTRODUCTION 3) I'm not comfortable with the document as written, per it suggests that the term "BGPSEC" == BGP Path Security, yet even the proposals received for BGPSEC in the WG only introduce new attributes, they do not secure the BGP AS_PATH attribute, nor do they force parity between the globally deployed BGP AS_PATH attribute and the new attributes they propose. *Your comment caused me to realize that I ought not be addressing BGPSEC in this document. BGPSEC is a proposed solution and thus not the focus of a threat analysis which, in turn, is intended to be an input to a requirements document. I'll remove all BGPSEC references. * 4) "This model also takes into consideration classes of attacks that are enabled by the use of BGPSEC (based on the current BGPSEC design.)" A stable reference for "current BGPSEC design" is in order here. *As noted above, I'm removing all references to BGPSEC. * 5) "i.e., for the links that connect BGP routers." By "links" here I assume you mean "transport connections"? *I meant the telecom links that connect eBGP speakers, but talking in terms of BGP/TCP sessions seems OK. I'll edit the text accordingly.* 6) Can you explain what this means, I'm not sure how RPKI by itself provides this: "secure route origination foundation offered by use of the RPKI." The operative word "secure" appears to be used rather loosely there, particularly when talking about BGP. Perhaps "route origin validation" and a reference to RPKI-RTR would be more appropriate - i.e., if it's not effectuated in BGP speaking routers through some mechanism it doesn't matter whether it's in the RPKI or not. Conflating the two tends to cause confusion in the operations community, methinks. *I have changed the text use the phrasing you suggested, and have included the relevant cite. * 7) This text seems to muddy things, as it talks about the design of BGPSEC rather than the Threat Model primitives which informed it's design: " The security model adopted for BGPSEC does not assume an "oracle" that can see all of the BGP inputs and outputs associated with every AS or every BGP router. Instead, the model is based on a local notion of what constitutes legitimate, authorized behavior by the BGP routers associated with an AS. This is an AS-centric model of secure operation, consistent with the AS-centric model that BGP employs for routing. This model forms the basis for the discussion that follows." *I disagree. It is common in academic literature to use an oracle as the basis against which the security of a protocol is measured. That's an appropriate model for protocol security in many contexts, e.g., for a point-to-point connection where a wiretapper would be able to see all of the traffic. It is overkill in this context, and thus I have chosen to explicitly reject it. But, I have removed the reference to any specific solution approach.* ===== TERMINOLOGY 8) While I appreciate the attempt to restate and/or redefine these terms in order to make this a standalone document, references to a large body of previous IETF and SIDR WG documents (much of which at least one of the authors is intimately familiar with for these terms would seem to be far more appropriate. *You're missing a ")" above **J. I don't know which SIDR (vs. IETF) RFCs you have in mind. Please be specific. Restating definitions in a terminology section is common; unless the WG chairs believe this is a bad idea for this document, I'll retain them. If you feel that specific terms have been redefined in a fashion that is inaccurate, please note which ones, and indicate the preferred definitions, and we can revisit them as needed.* 9) A reference to one of your previous (or new) citations may well be in order here: "False (Route) Origination - If a network operator originates a route for a prefix that the network operator does not hold (and that it has not been authorized to originate by the prefix holder, this is termed false route origination." *I looked at several of the RPKI RFCs and didn't see a definition for this term. I believe we added it in response to a request from Sriram. If you have an appropriate cite I can add it. * Also, you're missing closing ")" there.. *Fixed.* 10) I'm not sure I agree with this definition, can you explain? E.g., given that motivatiors are complex in a world of hacktivists and nation-state actors alike, or pay-for-for financially motivated actors, this all seems a bit fuzzing to me. By it's very definition above, if I've classified an entity as malicious ("Adversary - An adversary is an entity (e.g., a person or an organization) perceived as malicious, relative to the security policy of a system. The decision to characterize an entity as an adversary is made by those responsible for the security of a system. Often one describes classes of adversaries with similar capabilities or motivations, rather than specific individuals or organizations."). *You seem to have omitted some words above, so the result is not a sentence. I also don't know what "pay-for-for" means, ...* Furthermore, if I have an adversary that's attempting to procure or develop capabilities to exploit a vulnerability for which they do not have current capabilities, that would seem to render it a threat to me - unless of course, I have complete visibility to their motivations and capabilities, which is highly improbable. *When the adversary acquires the capabilities to carry out an attack, the adversary becomes a threat. If you believe that the adversary has a good chance of acquiring a specific capability (in a time frame of interest), then it is appropriate to treat the adversary as a threat, otherwise not. This characterization of "threat" has been used in defense and diplomatic contexts for decades.* " Threat - A threat is a motivated, capable adversary. An adversary that is not motivated to launch an attack is not a threat. An adversary that is motivated but not capable of launching an attack also is not a threat." ===== THREAT CHARACTERIZATION 11) Regarding this text, a reference to the BGPSEC document to which this This Threat Model subscribes would seem to be appropriate: " If it implements BGPSEC, it will have the ability to issue certificates for its routers, and to sign updates in a fashion that will be recognized by BGPSEC-enabled neighbors." *I've removed all references to BGPSEC.* 12) Also, the above seems to be implying that per router certificates would be required here: "certificates for its routers", can you clarify the intent of this text? *I've changed the text to avoid suggesting that a path security solution requires certificates to be per router vs. per-AS.* 13) "sign updates" seems to be ambiguous, is your intention to suggest that updates are signed, or that new BGP attributes would be introduced that would be contained with existing BGP Update messaging that could be "recognized" by BGPSEC-enabled neighbors? *I've reworded this to avoid the offending language.* 14) Is the phrase "Hackers" even necessary here, or should you not employ "Adversary" as defined in previous sections? *First, it's not clear where "here" is, since you didn't include any quoted text. If you are referring to the discussion of hackers as a class of adversary, then yes, it's necessary to explicitly describe the class of adversary. * 15) Regarding "It is assumed that hackers generally do not have the capability to effect MITM attacks on most links between networks (links used to transmit BGP and subscriber traffic)." given the preceding two sentences, they'd certainly be able to, no? *Not in general. An MITM attack against a link implies an on-path presence, which is not usually a capability of a hacker, e.g., an ability to insert a packet processing device on a link between two (e)BGP speakers. The underlying notion is that such links (in the layer 1, not layer 4 sense) are not accessible to this class of adversaries.* 16) Also, can you define what "subscriber" means in this context, it seems to focus on a particularly type of connection but if I'm reading this correctly, the threat is more ubiquitous. *In this context, a subscriber is a customer of a network operator, and who is not another network operator.* 17) Regarding "A hacker might be recruited, without his/her knowledge, by criminals or by nations, to act on their behalf." This seems to describe a victim or compromised system more than a "hacker", by nearly all conventional definitions, no? *No. The traditional term here is a "false flag" operation, if effected via a nation state. We're not talking about installing malware as a way to make use of the privileges of a legitimate network operator.* 18) Regarding "Hackers may be motivated by a desire for "bragging rights" or for profit." -- again, I think expanding adversary as appropriate, and leaving it at that, might be the simplest solution here. *The intent here is to give examples that distinguish motivations of different classes of adversaries, so using the generic term is not appropriate.* 19) All of the above about "Hackers' applies to the "Criminals" section as well. Again, refining adversaries terminology and applying would perhaps be in order. *The text describing criminal motivations and capabilities is different.* 20) The "Network Operators" section might be more useful if it makes a distinction between benign and malicious activity, although both represent threats, the current text seems to imply malice in all cases -- when it may not have been intentional at all. *I agree that some folks use the term "threat" more generally, to encompass non-malicious behavior, referring to threats as accidental vs. malicious. I have chosen to focus on malicious behavior here. I'll note that explicitly, e.g., by augmenting the definition of "threat."* 21) The "adversary" comments about apply equally to "Nations" as well, methinks, if these represent threats to users of the system. *I disagree, for the same reasons cited in my responses above. The text describing capabilities is distinct for different classes of adversaries and this argues against using the more generic term.* ===== ATTACKS ON A BGP ROUTER 22) A stable reference for "route leaks" would be useful in the document, given the recurring references *If we had one that the WG agreed upon, I'd be happy to insert it. Otherwise, maybe we should just delete the phrase from the document.* 23) Regarding: " Stale Path Announcement: An announcement may be propagated with an origination signature segment that has expired. This behavior violates the BGPSEC spec and is considered a possible replay attack." -- This and other references to "BGPSEC spec" need a stable reference. *I have reworded this to not be BGPSEC-specific.* 24) s/if such a time is mandates,/if such a time is mandated,/ *fixed.* 25) Can you define "Immediate neighbor" here: "Thus only an immediate neighbor of a route originator could be expected to detect this type of attack." Do you mean EBGP neighbor? BGPSEC EBGP neighbor? Or... " *The intent was an eBGP neighbor, which is also a BGPSEC neighbor. But, * 26) s/in injected/injected/ *More likely s/in injected//* 27) Regarding your definition of "Replay Attack", as written unless I'm confused because BGP is stateful no new announcement is required at all (simply suppress withdrawal, no need to re-announce - no?)? *I've removed the redundant comment about re-announcing.* ===== ATTACKS ON NETWORK OPERATOR MANAGEMENT COMPUTERS 28) define "RP Tools" ** *Software used by an RP to process RPKI signed products, consistent with RFCs 6486, 6487, 6488, 6490, and 6491.* 29) Here and in elsewhere first use of acronyms should be expanded (e.g., CRL, etc.) *Agreed, we'll revisit the text to verify that first uses of acronyms are expanded.* 30) Section 4.3 and throughout the document seems to conflate RPKI use by operators and BGPSEC-enabled routers, while an attempt (intro of S.4) was made to define 3 classes of attacks that decouple these elements. Honoring these three classes and cleanly delineating would make the document much clearer. For example, this _could happen even if the local network were not BGPSEC-enabled, no?: "If the network operator is BGPSEC-enabled, and the adversary invoked a tool used to request certificates, it could replace valid certificates for routers with ones that might be rejected by BGPSEC enabled neighbors." *I agree that we should keep separate attacks that apply to vanilla BGP, the RPKI context, and to the BGPSEC context. However, the example you gave is not one that crosses this boundary. This attack is describing replacement of router certificates, so it applies only to a network that is BGPSEC-enabled, and thus would publish router certificates. The text has been changed to reflect removal of all BGPSEC references.* ===== ATTACKS ON A REPOSITORY PUBLICATION POINT 31) s/ inside or an external threat/ insider or an external threat/ ? *Fixed.* 32) This seems to entirely gloss over the fact that the local systems and remote systems will likely in practice handle expired data in very different ways, and it seems to suggest that data should not be purged until replaced (what if it's replaced with something compromised), and that that information should ever be used anyway (using expired data can causes other systems to need to purge it in BGPSEC, no?): "If repository publication points are unavailable or the retrieved data is corrupted, an RP can revert to using the cached data This behavior helps insulate RPs from the immediate effects of DoS attacks on publication points." *What do you mean by local vs. remote systems? Are you referring to RPKI pub points vs. RP caches? The repository RFC says nothing about a repository removing data because the data is stale, There is no assumption that an entity operating a repository will scan its contents and delete expire certificates or stale CRLs.* ** *While it is always preferable to use current, validated data from the RPKI repository system, it is not unreasonable to use stale data in the absence of current, validated data. Ultimately this decision is up to each RP, but discarding stale data just because it's stale is not usually a great strategy. Consider my driver's license (which ought not be used to identify me except in the context of driving or renting a car). It is probably just as valid an ID the day after it expires as it was the day before.* 33) This seems like bad advice to me and should be removed: "Each RP will decide, locally, whether to continue to make use of or ignore cached RPKI objects that are stale or expired." We're suggesting we build and employ this whole system and yet the threat model says we should use expired data in a PKI? *I disagree. I think it is good advice and it is not inconsistent with how many systems operate today when RPs lack access to the freshest PKI data. * 34) Regarding this text, what if there is no "older object", or if this is precisely the behavior the adversary aimed to trigger: "If an adversary deletes one or more CA certificates, ROAs or the CRL for a publication point, the manifest for that publication point will allow an RP to detect this attack. (The RP would be very unhappy if there is no CRL for the CA instance anyway.) An RP can continue to use the last valid instance of the deleted object as a local policy option), thus minimizing the impact of such an attack. *If there is no older (valid) object instance in the RP's cache, then the RP cannot make use of it, and it is as though the object did not exist. Yes, an adversary can exploit this RP behavior, but is that worse that having an RP ignore the old (valid) data? Consider a generic PKI, that uses CRLs (not OCSP). If an adversary suppresses publication of the next CRL (as specified by the next Update field), what should RPs do? All of the previously revoked certificates are still revoked (ignoring the PKIX-deprecated CRL entry extension that can undo revocation). So, it makes sense to keep using the old CRL until a current one can be acquired, CRLs do not expire; they become stale. Yes, RPs ought to engage in some OOB action to try to cause a current CRL to be posted, but in the meantime ... * 35) Regarding the above, what should an RP do when they detect such an attack? *The Ghostbusters record was developed to provide a means for alerting pub point maintainers of this sort of problem. It was specified after we generated this text, so we can add a pointer to it now.* 36) Is this feedback loop a requirement of the system; "Such behavior should result in the CA (or publication point maintainer) being notified of the problem. An RP can continue to use the last valid instance of the deleted " *This is not a requirements document, so the question, in that form, in not applicable.* 37) How does this happen?: " This alerts an RP that there may be a problem, and, hopefully, the entity responsible for the publication point will be asked to remedy the problem (e.g., republish the missing CA certificates and/or ROAs). *See comment above re Ghostbusters.* 38) Is this an actual recommendation you're making? This seems like a really bad idea to me, "An RP cannot know the content of the new certificates or ROAs that are not present, but it can continue to use what it has cached." *Again, I disagree, for the reasons noted earlier.* 39) s/be un aware/be unaware/ *Fixed.* 40) This seems to contradict your previous recommendation where you suggest that if stale or expired data exists that an RP should use it: "INRs associated with these objects will be treated as unauthenticated." *No. This text refers to "...certificates or ROAs that are not present."* 41) Hope? "Here too the hope is that the CA will be notified of the problem (by RPs) and will remedy the error." *Gee, I didn't mean to sound like an Obama supporter. s/hope/goal/* ===== ATTACKS ON AN RPKI CA 42) Section 2 only loosely defines "Adversary", unless I missed something it doesn't define various types of adversaries as this text suggests: *Section 3 defined 5 classes of threats. Since a threat is a motivated capable adversary, ...* "All of adversaries listed in Section 2 are presumed to be capable of launching attacks against the computers used to perform CA functions." As noted previously, collapsing the rather ambiguous terms you introduce in section 3 into section 2's "Adversary" set might make sense. *See response above.* 43) "(as first noted by Pogo)" -- Reference/ *fixed.* ===== RESIDUAL VULNERABILITIES 44) The difference here is that if that information is used to sign updates in the routing system which are propagated to BGPSEC-enabled routers then using stale data can cause considerable churn or non-deterministic behaviors (including forwarding loops_ in the routing system. Unless I'm missing something, this is an incredibly bad idea: " 1. The RP may choose to make use of its local cache, employing local configuration settings that tolerate expired or stale objects. (Such behavior is, nominally, always within the purview of an RP in PKI.) Using cached, expired or stale data subjects the RP to attacks that take advantage of the RP's ignorance of changes to this data." *I've already address the question of whether it makes sense for an RP to use validated but stale data.* 45) Here are you suggesting that BGPSEC should (will) protect the BGP AS_PATH, or introduce a new attribute? "BGPSEC signatures do not protect all attributes associated with an AS_path. " ** *addressed as part of removing all BGPSEC references.* Either way, some text about divergence between a BGPSEC path and a brand new attribute would seem to be in order -- although in a previous section and certainly not in a residual threats section. *See comment above. * 46) s/AS_path/AS_PATH/ *fixed.* --------------030800060803080209010501 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Danny, here are replies to the issues you raised wrt the threats doc.

Steve
--------

 

I am surprised that external systems (e.g., NTP) are not mentioned at all in this document?

 

I will add some text to note that the use of certificates, CRLs, and other RPKI signed products requires access to a reliable (though not highly precise) time source by the devices that process them. For the RPKI, the current deployment model calls for such processing to be performed by servers, not routers. For BGPSEC, the need for a reliable time source may extend to routers, if BGPSEC path signatures carry an expiration time.

 

Also, this document makes no distinction between eBGP and iBGP speakers, yet there are certainly places where text and context would suggest it is certainly necessary. Some hints of this below.

 

I will add text noting that the focus of the doc is eBGP, not iBGP.

 

I believe this document needs a major overhaul before publication as a WG document. More comments below..

 

 

-danny

 

 

=====

ABSTRACT

 

 

1) Regarding "Intended Status: Standards Track", I'd expect any standalone Threat Model draft would be should be Informational.

 

Agree. Fixed.

 

 

2) " Enabling an AS to verify that the AS-PATH represented in a route matches the path travelled by the NLRI for the route"

 

 

2.1): s/AS-PATH/AS_PATH/

 

fixed.

 

2.2): I do not believe that even BGPSEC does this. Instead, in introduces a new attribute which BGPSEC secures, and it forces no parity between the new attribute and the old attribute. See 3) below, but absent some clarification of this I am not comfortable with this text as written.

 

This text is taken from the charter (including the “AS-PATH” typo). A discussion of whether the BGPSEC design addresses this charter goal may be appropriate for the BGPSEC architecture document, but not here.

 

=====

INTRODUCTION

 

 

3) I'm not comfortable with the document as written, per it suggests that the term "BGPSEC" == BGP Path Security, yet even the proposals received for BGPSEC in the WG only introduce new attributes, they do not secure the BGP AS_PATH attribute, nor do they force parity between the globally deployed BGP AS_PATH attribute and the new attributes they propose.

Your comment caused me to realize that I ought not be addressing BGPSEC in this document. BGPSEC is a proposed solution and thus not the focus of a threat analysis which, in turn, is intended to be an input to a requirements document. I’ll remove all BGPSEC references.

 

 

4) "This model also takes into consideration classes of attacks that are enabled by the use of BGPSEC (based on the current BGPSEC design.)" A stable reference for "current BGPSEC design" is in order here.

 

As noted above, I’m removing all references to BGPSEC.

 

5) "i.e., for the links that connect BGP routers." By "links" here I assume you mean "transport connections"?

 

I meant the telecom links that connect eBGP speakers, but talking in terms of BGP/TCP sessions seems OK. I’ll edit the text accordingly.

 

6) Can you explain what this means, I'm not sure how RPKI by itself provides this: "secure route origination foundation offered by use of the RPKI." The operative word "secure" appears to be used rather loosely there, particularly when talking about BGP. Perhaps "route origin validation" and a reference to RPKI-RTR would be more appropriate - i.e., if it's not effectuated in BGP speaking routers through some mechanism it doesn't matter whether it's in the RPKI or not. Conflating the two tends to cause confusion in the operations community, methinks.

 

I have changed the text use the phrasing you suggested, and have included the relevant cite.  

 

7) This text seems to muddy things, as it talks about the design of BGPSEC rather than the Threat Model primitives which informed it's design:

 

" The security model adopted for BGPSEC does not assume an "oracle"

that can see all of the BGP inputs and outputs associated with every

AS or every BGP router. Instead, the model is based on a local

notion of what constitutes legitimate, authorized behavior by the BGP

routers associated with an AS. This is an AS-centric model of secure

operation, consistent with the AS-centric model that BGP employs for

routing. This model forms the basis for the discussion that follows."

 

I disagree. It is common in academic literature to use an oracle as the basis against which the security of a protocol is measured. That’s an appropriate model for protocol security in many contexts, e.g., for a point-to-point connection where a wiretapper would be able to see all of the traffic. It is overkill in this context, and thus I have chosen to explicitly reject it. But, I have removed the reference to any specific solution approach.

 

=====

TERMINOLOGY

 

 

8) While I appreciate the attempt to restate and/or redefine these terms in order to make this a standalone document, references to a large body of previous IETF and SIDR WG documents (much of which at least one of the authors is intimately familiar with

for these terms would seem to be far more appropriate.

 

You’re missing a “)” above J. I don’t know which SIDR (vs. IETF) RFCs you have in mind. Please be specific. Restating definitions in a terminology section is common; unless the WG chairs believe this is a bad idea for this document, I’ll retain them. If you feel that specific terms have been redefined in a fashion that is inaccurate, please note which ones, and indicate the preferred definitions, and we can revisit them as needed.

 

9) A reference to one of your previous (or new) citations may well be in order here:

 

 

"False (Route) Origination - If a network operator originates a route

for a prefix that the network operator does not hold (and that it has

not been authorized to originate by the prefix holder, this is termed

false route origination."

 

I looked at several of the RPKI RFCs and didn’t see a definition for this term. I believe we added it in response to a request from Sriram. If you have an appropriate cite I can add it.

 

Also, you're missing closing ")" there..

 

Fixed.

 

10) I'm not sure I agree with this definition, can you explain?

 

E.g., given that motivatiors are complex in a world of hacktivists and nation-state actors alike, or pay-for-for financially motivated actors, this all seems a bit fuzzing to me. By it's very definition above, if I've classified an entity as malicious ("Adversary - An adversary is an entity (e.g., a person or an organization) perceived as malicious, relative to the security policy of a system. The decision to characterize an entity as an adversary is made by those responsible for the security of a system.

Often one describes classes of adversaries with similar capabilities or motivations,

rather than specific individuals or organizations.").

 

You seem to have omitted some words above, so the result is not a sentence. I also don’t know what “pay-for-for” means, …

 

Furthermore, if I have an adversary that's attempting to procure or develop capabilities to exploit a vulnerability for which they do not have current capabilities, that would seem to render it a threat to me - unless of course, I have complete visibility to their motivations and capabilities, which is highly improbable.

 

When the adversary acquires the capabilities to carry out an attack, the adversary becomes a threat. If you believe that the adversary has a good chance of acquiring a specific capability (in a time frame of interest), then it is appropriate to treat the adversary as a threat, otherwise not. This characterization of “threat” has been used in defense and diplomatic contexts for decades.

 

" Threat - A threat is a motivated, capable adversary. An adversary

that is not motivated to launch an attack is not a threat. An

adversary that is motivated but not capable of launching an attack

also is not a threat."

 

 

=====

THREAT CHARACTERIZATION

 

 

11) Regarding this text, a reference to the BGPSEC document to which this This Threat Model subscribes would seem to be appropriate:

 

" If it implements BGPSEC, it will have the ability to issue certificates for its routers, and to sign updates in a fashion that will be recognized by BGPSEC-enabled neighbors."

 

I’ve removed all references to BGPSEC.

 

12) Also, the above seems to be implying that per router certificates would be required here: "certificates for its routers", can you clarify the intent of this text?

 

I’ve changed the text to avoid suggesting that a path security solution requires certificates to be per router vs. per-AS.

 

13) "sign updates" seems to be ambiguous, is your intention to suggest that updates are signed, or that new BGP attributes would be introduced that would be contained with existing BGP Update messaging that could be "recognized" by BGPSEC-enabled neighbors?

 

I’ve reworded this to avoid the offending language.

 

14) Is the phrase "Hackers" even necessary here, or should you not employ "Adversary" as defined in previous sections?

 

First, it’s not clear where “here” is, since you didn’t include any quoted text. If you are referring to the discussion of hackers as a class of adversary, then yes, it’s necessary to explicitly describe the class of adversary.

 

15) Regarding "It is assumed that hackers generally do not have the capability to effect MITM attacks on most links between networks (links used to transmit BGP and subscriber traffic)." given the preceding two sentences, they'd certainly be able to, no?

 

Not in general. An MITM attack against a link implies an on-path presence, which is not usually a capability of a hacker, e.g., an ability to insert a packet processing device on a link between two (e)BGP speakers. The underlying notion is that such links (in the layer 1, not layer 4 sense) are not accessible to this class of adversaries.

 

16) Also, can you define what "subscriber" means in this context, it seems to focus on a particularly type of connection but if I'm reading this correctly, the threat is more ubiquitous.

 

In this context, a subscriber is a customer of a network operator, and who is not another network operator.

 

17) Regarding "A hacker might be recruited, without his/her knowledge, by criminals or by nations, to act on their behalf." This seems to describe a victim or compromised system more than a "hacker", by nearly all conventional definitions, no?

 

No. The traditional term here is a “false flag” operation, if effected via a nation state. We’re not talking about installing malware as a way to make use of the privileges of a legitimate network operator.

 

18) Regarding "Hackers may be motivated by a desire for "bragging rights" or for profit." -- again, I think expanding adversary as appropriate, and leaving it at that, might be the simplest solution here.

 

The intent here is to give examples that distinguish motivations of different classes of adversaries, so using the generic term is not appropriate.

 

19) All of the above about "Hackers' applies to the "Criminals" section as well. Again,

refining adversaries terminology and applying would perhaps be in order.

 

 

The text describing criminal motivations and capabilities is different.

 

20) The "Network Operators" section might be more useful if it makes a distinction between benign and malicious activity, although both represent threats, the current text seems to imply malice in all cases -- when it may not have been intentional at all.

 

I agree that some folks use the term “threat” more generally, to encompass non-malicious behavior, referring to threats as accidental vs. malicious. I have chosen to focus on malicious behavior here. I’ll note that explicitly, e.g., by augmenting the definition of “threat.”

 

21) The "adversary" comments about apply equally to "Nations" as well, methinks, if these represent threats to users of the system.

 

I disagree, for the same reasons cited in my responses above. The text describing capabilities is distinct for different classes of adversaries and this argues against using the more generic term.

 

=====

ATTACKS ON A BGP ROUTER

 

 

22) A stable reference for "route leaks" would be useful in the document, given the recurring references

 

If we had one that the WG agreed upon, I’d be happy to insert it. Otherwise, maybe we should just delete the phrase from the document.

 

23) Regarding: " Stale Path Announcement: An announcement may be propagated with an

origination signature segment that has expired. This behavior

violates the BGPSEC spec and is considered a possible replay

attack." -- This and other references to "BGPSEC spec" need a stable reference.

 

I have reworded this to not be BGPSEC-specific.

 

24) s/if such a time is mandates,/if such a time is mandated,/

 

fixed.

 

25) Can you define "Immediate neighbor" here: "Thus only an immediate neighbor of a route originator could be expected to detect this type of attack." Do you mean EBGP neighbor? BGPSEC EBGP neighbor? Or... "

 

The intent was an eBGP neighbor, which is also a BGPSEC neighbor. But,

 

26) s/in injected/injected/

 

More likely s/in injected//

 

27) Regarding your definition of "Replay Attack", as written unless I'm confused because BGP is stateful no new announcement is required at all (simply suppress withdrawal, no need to re-announce - no?)?

 

I’ve removed the redundant comment about re-announcing.

 

 

=====

ATTACKS ON NETWORK OPERATOR MANAGEMENT COMPUTERS

 

 

28) define "RP Tools"

 

Software used by an RP to process RPKI signed products, consistent with RFCs 6486, 6487, 6488, 6490, and 6491.

 

29) Here and in elsewhere first use of acronyms should be expanded (e.g., CRL, etc.)

 

Agreed, we’ll revisit the text to verify that first uses of acronyms are expanded.

 

30) Section 4.3 and throughout the document seems to conflate RPKI use by operators and BGPSEC-enabled routers, while an attempt (intro of S.4) was made to define 3 classes of attacks that decouple these elements. Honoring these three classes and cleanly delineating would make the document much clearer. For example, this _could happen even if the local network were not BGPSEC-enabled, no?:

 

"If the network operator is BGPSEC-enabled, and the adversary invoked

a tool used to request certificates, it could replace valid certificates for routers with ones that might be rejected by BGPSEC enabled neighbors."

 

I agree that we should keep separate attacks that apply to vanilla BGP, the RPKI context, and to the BGPSEC context. However, the example you gave is not one that crosses this boundary. This attack is describing replacement of router certificates, so it applies only to a network that is BGPSEC-enabled, and thus would publish router certificates. The text has been changed to reflect removal of all BGPSEC references. 

 

=====

ATTACKS ON A REPOSITORY PUBLICATION POINT

 

 

31) s/ inside or an external threat/ insider or an external threat/ ?

 

Fixed.

 

32) This seems to entirely gloss over the fact that the local systems and remote systems will likely in practice handle expired data in very different ways, and it seems to suggest that data should not be purged until replaced (what if it's replaced with something compromised), and that that information should ever be used anyway (using expired data can causes other systems to need to purge it in BGPSEC, no?):

 

"If repository publication points are unavailable or the retrieved data is corrupted, an RP can revert to using the cached data This behavior helps insulate RPs from the immediate effects of DoS attacks on publication points."

 

What do you mean by local vs. remote systems? Are you referring to RPKI pub points vs. RP caches? The repository RFC says nothing about a repository removing data because the data is stale, There is no assumption that an entity operating a repository will scan its contents and delete expire certificates or stale CRLs.

 

While it is always preferable to use current, validated data from the RPKI repository system, it is not unreasonable to use stale data in the absence of current, validated data. Ultimately this decision is up to each RP, but discarding stale data just because it’s stale is not usually a great strategy. Consider my driver’s license (which ought not be used to identify me except in the context of driving or renting a car). It is probably just as valid an ID the day after it expires as it was the day before.

 

33) This seems like bad advice to me and should be removed: "Each RP will decide, locally, whether to continue to make use of or ignore cached RPKI objects that are stale or expired." We're suggesting we build and employ this whole system and yet the threat model says we should use expired data in a PKI?

 

I disagree. I think it is good advice and it is not inconsistent with how many systems operate today when RPs lack access to the freshest PKI data.

 

34) Regarding this text, what if there is no "older object", or if this is precisely the behavior the adversary aimed to trigger:

 

"If an adversary deletes one or more CA certificates, ROAs or the CRL

for a publication point, the manifest for that publication point will

allow an RP to detect this attack. (The RP would be very unhappy if

there is no CRL for the CA instance anyway.) An RP can continue to

use the last valid instance of the deleted object as a local policy

option), thus minimizing the impact of such an attack.

 

If there is no older (valid) object instance in the RP’s cache, then the RP cannot make use of it, and it is as though the object did not exist. Yes, an adversary can exploit this RP behavior, but is that worse that having an RP ignore the old (valid) data? Consider a generic PKI, that uses CRLs (not OCSP). If an adversary suppresses publication of the next CRL (as specified by the next Update field), what should RPs do? All of the previously revoked certificates are still revoked (ignoring the PKIX-deprecated CRL entry extension that can undo revocation). So, it makes sense to keep using the old CRL until a current one can be acquired, CRLs do not expire; they become stale. Yes, RPs ought to engage in some OOB action to try to cause a current CRL to be posted, but in the meantime …

 

35) Regarding the above, what should an RP do when they detect such an attack?

 

The Ghostbusters record was developed to provide a means for alerting pub point maintainers of this sort of problem. It was specified after we generated this text, so we can add a pointer to it now.

 

36) Is this feedback loop a requirement of the system;

 

"Such behavior should result in the CA (or publication point maintainer) being notified of the problem. An RP can continue to use the last valid instance of the deleted "

 

This is not a requirements document, so the question, in that form, in not applicable.

 

37) How does this happen?:

 

" This alerts an RP that there may be a problem, and,

hopefully, the entity responsible for the publication point will be

asked to remedy the problem (e.g., republish the missing CA

certificates and/or ROAs).

 

See comment above re Ghostbusters.

 

38) Is this an actual recommendation you're making? This seems like a really bad idea to me,

 

"An RP cannot know the content of the new certificates or ROAs that are not present, but it can continue to use what it has cached."

 

Again, I disagree, for the reasons noted earlier.

 

39) s/be un aware/be unaware/

 

Fixed.

 

40) This seems to contradict your previous recommendation where you suggest that if stale or expired data exists that an RP should use it:

 

 

"INRs associated with these objects will be treated as unauthenticated."

 

No. This text refers to “…certificates or ROAs that are not present.”

 

41) Hope?

 

 

"Here too the hope is that the CA will be notified of the problem (by RPs) and will remedy the error."

 

Gee, I didn’t mean to sound like an Obama supporter. s/hope/goal/

 

=====

ATTACKS ON AN RPKI CA

 

 

42) Section 2 only loosely defines "Adversary", unless I missed something it doesn't define various types of adversaries as this text suggests:

 

Section 3 defined 5 classes of threats. Since a threat is a motivated capable adversary, …

 

"All of adversaries listed in Section 2 are presumed to be capable of launching attacks against the computers used to perform CA functions."

 

 

As noted previously, collapsing the rather ambiguous terms you introduce in section 3 into section 2's "Adversary" set might make sense.

 

See response above.

 

43) "(as first noted by Pogo)" -- Reference/

 

fixed.

 

=====

RESIDUAL VULNERABILITIES

 

 

44) The difference here is that if that information is used to sign updates in the routing system which are propagated to BGPSEC-enabled routers then using stale data can cause considerable churn or non-deterministic behaviors (including forwarding loops_ in the routing system. Unless I'm missing something, this is an incredibly bad idea:

 

 

" 1. The RP may choose to make use of its local cache, employing

local configuration settings that tolerate expired or stale

objects. (Such behavior is, nominally, always within the

purview of an RP in PKI.) Using cached, expired or stale data

subjects the RP to attacks that take advantage of the RP's

ignorance of changes to this data."

 

I’ve already address the question of whether it makes sense for an RP to use validated but stale data.

 

45) Here are you suggesting that BGPSEC should (will) protect the BGP AS_PATH, or introduce a new attribute?

 

 

"BGPSEC signatures do not protect all attributes associated with an AS_path. "

 

addressed as part of removing all BGPSEC references.

Either way, some text about divergence between a BGPSEC path and a brand new attribute would seem to be in order -- although in a previous section and certainly not in a residual threats section.

 

See comment above.

 

46) s/AS_path/AS_PATH/

 

 

fixed.

 

--------------030800060803080209010501-- From eosterweil@verisign.com Tue Aug 28 07:09:21 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C447521F84C5 for ; Tue, 28 Aug 2012 07:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.382 X-Spam-Level: X-Spam-Status: No, score=-6.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06ZIWneEFXV7 for ; Tue, 28 Aug 2012 07:09:21 -0700 (PDT) Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by ietfa.amsl.com (Postfix) with ESMTP id 15BDB21F8468 for ; Tue, 28 Aug 2012 07:09:20 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKUDzRDo+seWwplMjya4lAK1U0xMZkdJEE@postini.com; Tue, 28 Aug 2012 07:09:21 PDT Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q7SE9FYo002914; Tue, 28 Aug 2012 10:09:18 -0400 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.29.242]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Aug 2012 10:09:15 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: <503C47A8.7030700@bbn.com> Date: Tue, 28 Aug 2012 10:09:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <303C576D-D1F8-4F62-8E0E-0D74A28B2771@verisign.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F555CB@Hermes.columbia.ads.sparta.com> <50389897.3040503@bbn.com> <97856400-9F70-4AEC-AF91-A0673A6D716D@verisign.com> <503C47A8.7030700@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 28 Aug 2012 14:09:15.0200 (UTC) FILETIME=[B4C9FC00:01CD8526] Cc: sidr@ietf.org Subject: Re: [sidr] RPKI <-> allocation consistency X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 14:09:21 -0000 On Aug 28, 2012, at 12:23 AM, Stephen Kent wrote: > Eric, >=20 > It seems likely that not all RPs will have the same view of INR = allocation, e.g., due to differences > in when RPs fetch data from repositories. This seems analogous to the = transient inconsistencies that > ISPs see today if they use IRR or other INR data sources, for similar = reasons. Maybe yes, and maybe no. I don't necessarily want to diverge into that = topic now (though a separate thread would be ok). I'm more focused on = the pragmatic issues that come up when implementing. So far, my = concerns seem to be pretty specific to this design, but I'm sort of = seeking guidance here... >=20 > I think Rob Austein has referred to the repository system as being = "loosely consistent," a reasonable target for a large scale, distributed = database with entries maintained by a large group of folks. I admit that my memory/cache consistency background is a little rusty = (though I used to be quite dialed in on it), but I don't recall ever = coming across that model before. What are the access/ordering = guarantees in ``loose consistency?'' Again, it only matters from a = pragmatic perspective. I am having trouble ensuring that I have the = right idea here. Thanks a lot! Eric= From brian.peter.dickson@gmail.com Tue Aug 28 08:08:50 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE6711E80C5 for ; Tue, 28 Aug 2012 08:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.403 X-Spam-Level: X-Spam-Status: No, score=-2.403 tagged_above=-999 required=5 tests=[AWL=-0.805, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_42=1, J_BACKHAIR_44=1, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPVkmSf1eQTD for ; Tue, 28 Aug 2012 08:08:50 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id DB55F11E8099 for ; Tue, 28 Aug 2012 08:08:49 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2935598wgb.13 for ; Tue, 28 Aug 2012 08:08:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vtnnKdjJWgK6qt+c3rcNZYNbDkOVbcyfhCCzuGR+8ic=; b=z3xWIdytJC9AlQDoS8OTd4w8kaxUSNqX6Ha0QaTrLG4i7oHeexmGGmmcH8tdQF2Ha9 Wpz67jnEJOCrJZj5RIbpqCuAvGLBnWQU9SSQ04DKogMZ2tHiRp1uIdC51Wvq67l5Bktq r8zQP/3MyCY10xZWFXT/eAfyqAV1IiEx6hmJw7vu7ZWCxieeqColHbLcmHo8nCXzvSyf ie+UxAr28KUJar4kIMrhgFNmncZOfloc95f0iDPpH0WXymS/+IFfSxapTuAJh40hAG0z 3uv1V0W/yCE0Hwk+++kMY3TXwVHSqKRav2uf3SWlxRsysvyKDYFIV6h9VNTHnbmyZuan QkWA== MIME-Version: 1.0 Received: by 10.180.84.104 with SMTP id x8mr33516359wiy.20.1346166528906; Tue, 28 Aug 2012 08:08:48 -0700 (PDT) Received: by 10.223.61.12 with HTTP; Tue, 28 Aug 2012 08:08:48 -0700 (PDT) In-Reply-To: <503C47A8.7030700@bbn.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F555CB@Hermes.columbia.ads.sparta.com> <50389897.3040503@bbn.com> <97856400-9F70-4AEC-AF91-A0673A6D716D@verisign.com> <503C47A8.7030700@bbn.com> Date: Tue, 28 Aug 2012 11:08:48 -0400 Message-ID: From: Brian Dickson To: Stephen Kent Content-Type: multipart/alternative; boundary=f46d043bd758c3957e04c854d1c3 Cc: sidr@ietf.org Subject: Re: [sidr] RPKI <-> allocation consistency X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 15:08:50 -0000 --f46d043bd758c3957e04c854d1c3 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 28, 2012 at 12:23 AM, Stephen Kent wrote: > Eric, > > It seems likely that not all RPs will have the same view of INR > allocation, e.g., due to differences > in when RPs fetch data from repositories. This seems analogous to the > transient inconsistencies that > ISPs see today if they use IRR or other INR data sources, for similar > reasons. > I think there are a couple of things that are important, in the duality between INRA<->RPKI<->RP and Originator<->RP<->...<->RP relationships. For example, in the IRR world, there are a number of reasonably well-known processes used by the largest network operators, for IRR-update -> filter-update schedules (and mechanisms). And as such, recipients of new INRs have published rules they need to follow, to ensure their announcements won't be blocked by filters that have yet to be updated. So, there are a couple of analogous elements in the RPKI ecosystem that, IMHO, need to be described, proscribed, or categorized: What model for the processes of maintaining sync between INR and RPKI should be followed? A high-level finite state machine (FSM) model should be an eventual goal, so that implementors have a crystal clear model to follow. At any point in time, what states should any particular element be able to be in? How should an RP interpret each of those states? How can an RP identify the timeline it needs to follow, if it wants to be as current as possible, with as little overhead and work required? Clearly once-per-second polling won't scale. Is there any corresponding place in the RPKI that would allow an Originator to identify expected latency between ROA issuance, and the update towards a given RP which would guarantee that the RP will accept an announcement (in BGPSEC)? This is the level of modeling I'd hope to see, to understand how the overall system behaves, as a potential RP. Brian --f46d043bd758c3957e04c854d1c3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Aug 28, 2012 at 12:23 AM, Stephen Kent <kent@bbn.com> wro= te:
Eric,

It seems likely that not all RPs will have the same view of INR allocation,= e.g., due to differences
in when RPs fetch data from repositories. This seems analogous to the trans= ient inconsistencies that
ISPs see today if they use IRR or other INR data sources, for similar reaso= ns.

=A0I think there are a couple of th= ings that are important, in the duality between INRA<->RPKI<->R= P and Originator<->RP<->...<->RP relationships.

For example, in the IRR world, there are a number of re= asonably well-known processes used by the largest network operators, for IR= R-update -> filter-update schedules (and mechanisms).

And as such, recipients of new INRs have published rules they ne= ed to follow, to ensure their announcements won't be blocked by filters= that have yet to be updated.

So, there are a coup= le of analogous elements in the RPKI ecosystem that, IMHO, need to be descr= ibed, proscribed, or categorized:

What model for the processes of maintaining sync betwee= n INR and RPKI should be followed? A high-level finite state machine (FSM) = model should be an eventual goal, so that implementors have a crystal clear= model to follow.

At any point in time, what states should any particular= element be able to be in?

How should an RP interp= ret each of those states?

How can an RP identify t= he timeline it needs to follow, if it wants to be as current as possible, w= ith as little overhead and work required? Clearly once-per-second polling w= on't scale.

Is there any corresponding place in the RPKI that would= allow an Originator to identify expected latency between ROA issuance, and= the update towards a given RP which would guarantee that the RP will accep= t an announcement (in BGPSEC)?

This is the level of modeling I'd hope to see, to u= nderstand how the overall system behaves, as a potential RP.

=
Brian
--f46d043bd758c3957e04c854d1c3-- From danny@tcb.net Tue Aug 28 08:19:43 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6190311E80F6 for ; Tue, 28 Aug 2012 08:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cT-ybms611xC for ; Tue, 28 Aug 2012 08:19:43 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id EEBD411E80DF for ; Tue, 28 Aug 2012 08:19:42 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 5CDAC2680A3; Tue, 28 Aug 2012 09:19:42 -0600 (MDT) Received: from dul1dmcphers-m2.vcorp.ad.vrsn.com (nat1.corp-fo.iad1.verisign.com [216.168.230.7]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Tue, 28 Aug 2012 09:19:42 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=216.168.230.7; client-port=39452; syn-fingerprint=65535:53:1:64:M1460,N,W1,N,N,T,S MacOS 10.4.8; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Danny McPherson In-Reply-To: <503C904F.2040609@bbn.com> Date: Tue, 28 Aug 2012 11:19:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24B20D14B2CD29478C8D5D6E9CBB29F625F5604B@Hermes.columbia.ads.sparta.com> <503C904F.2040609@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1278) Cc: sidr wg Subject: Re: [sidr] Some comments on draft-ietf-sidr-bgpsec-threats-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 15:19:43 -0000 On Aug 28, 2012, at 5:33 AM, Stephen Kent wrote: > Gee, I didn=92t mean to sound like an Obama supporter. s/hope/goal/ Hahh, that's pretty funny :-) Thanks for the thoughtful reply Steve, I'll get back to you in short = order on these responses - but if an updated I-D appears in the interim = I'll try to apply comments only to the revision. -danny= From wesley.george@twcable.com Tue Aug 28 14:03:38 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E4021F85A0; Tue, 28 Aug 2012 14:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.942 X-Spam-Level: X-Spam-Status: No, score=-0.942 tagged_above=-999 required=5 tests=[AWL=0.521, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7DoflL8EdCW; Tue, 28 Aug 2012 14:03:37 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 0A89021F859F; Tue, 28 Aug 2012 14:03:36 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.80,328,1344225600"; d="scan'208";a="430844565" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 28 Aug 2012 17:03:26 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Tue, 28 Aug 2012 17:03:35 -0400 From: "George, Wes" To: Christopher Morrow , "sidr@ietf.org" , "sidr-chairs@ietf.org" , "sidr-ads@tools.ietf.org" Date: Tue, 28 Aug 2012 17:03:35 -0400 Thread-Topic: [sidr] WGLC: draft-ietf-sidr-origin-ops- Thread-Index: Ac18iX4lt5zQWjt9R76pbOMSA7aIOwI0f7og Message-ID: <2671C6CDFBB59E47B64C10B3E0BD592303CE11C0@PRVPEXVS15.corp.twcable.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] WGLC: draft-ietf-sidr-origin-ops- X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 21:03:38 -0000 I think we're ready to move this on, and I commend Randy for his work on it= . The only substantive comment I have is something that I believe Shane and I= raised in previous versions' review and is not addressed yet. In section 3= , where it discusses location of cache relative to routers "...'close' is o= f course complex..." - the current text still does not adequately explain w= hy 'close' is a recommendation, or how latency might affect performance of = the chosen deployment. This is a system that is by nature a loosely synchro= nized system, asymmetric in distribution of information, where elsewhere in= this doc we say that the clock has to be accurate to the hour, which isn't= exactly a high bar. If latency is a consideration, we need a bound on that= - how much is too much latency such that the cache should be closer to the= consuming router(s)? If there isn't a definite recommendation, what is the= consideration that operators should be using to determine latency's impact= ? Is this just about latency's impact on TCP throughput, or is there someth= ing more complex to be considered? I'd suggest text, but I still don't understand why geographic proximity mat= ters. Reachability, sure, but not proximity. Similarly with "consider trust boundaries..." - what should one be consider= ing here? How are trust boundaries related to a cache's proximity to a give= n router? I understand why bootstrap reachability between router and cache is importa= nt, but a few additional words about the reason might be helpful for the in= tended audience (that is, operators implementing RPKI for the first time) Suggested text: "If the cache is not reachable via IGP or even locally, thi= s will delay initial synchronization with the RPKI cache on boot, and may c= ause multiple BGP convergence events, first without RPKI data, and then aga= in once RPKI data is synchronized." Generally, if we are recommending that there should be some sort of proximi= ty, we need to provide some rationale or a view into the considerations tha= t went into that recommendation so that operators can make their own inform= ed decision about placement, justify standalone equipment instead of VMs, e= tc. Otherwise, I can see having the following discussion with our systems f= olks internally: "This RPKI cache thingy is just a server with an app running on it, right?" "yeah" "ok, we're going to stick it in a VM on our two national data center comput= e infrastructures like the rest of our servers, we can spin up more instanc= es if you need to scale it" "but RFC mumble mumble says that we shouldn't do that..." "ok, why? And where do you want to put it?" "ummm... 'close' to the routers? Because...reasons" Thanks, Wes George > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > Christopher Morrow > Sent: Friday, August 17, 2012 11:03 AM > To: sidr@ietf.org; sidr-chairs@ietf.org; sidr-ads@tools.ietf.org > Subject: [sidr] WGLC: draft-ietf-sidr-origin-ops- > > Hello WG folk, > This draft has undergone 9 revisions since the last WGLC, which seemed > to end with requests for changes by the authors. > Can we now have a final-final-please-let's-progress WGLC for this draft > now? Let's end the call: 08/31/2012 (Aug 31 2012). > > Htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sidr-origin-ops-19 > > Abstract: > "Deployment of RPKI-based BGP origin validation has many operational > considerations. This document attempts to collect and present the > most critical. It is expected to evolve as RPKI-based origin > validation is deployed and the dynamics are better understood." > > Thanks! > -Chris > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From kent@bbn.com Tue Aug 28 21:53:56 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A93B821F84EC for ; Tue, 28 Aug 2012 21:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.964 X-Spam-Level: X-Spam-Status: No, score=-105.964 tagged_above=-999 required=5 tests=[AWL=-0.434, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOTkErKaR8u1 for ; Tue, 28 Aug 2012 21:53:56 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0D98521F84D4 for ; Tue, 28 Aug 2012 21:53:56 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:56480 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1T6aHg-000Egf-Ao; Wed, 29 Aug 2012 00:53:44 -0400 Message-ID: <503D141F.1060404@bbn.com> Date: Tue, 28 Aug 2012 14:55:27 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Eric Osterweil References: <24B20D14B2CD29478C8D5D6E9CBB29F625F555CB@Hermes.columbia.ads.sparta.com> <50389897.3040503@bbn.com> <97856400-9F70-4AEC-AF91-A0673A6D716D@verisign.com> <503C47A8.7030700@bbn.com> <303C576D-D1F8-4F62-8E0E-0D74A28B2771@verisign.com> In-Reply-To: <303C576D-D1F8-4F62-8E0E-0D74A28B2771@verisign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr@ietf.org Subject: Re: [sidr] RPKI <-> allocation consistency X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 04:53:56 -0000 Eric, Perhaps what you are looking for is some text in an operations doc, suggesting what an RP can expect, depending on how it elects to interact with the repository system, maintain its local cache, etc. Steve From kent@bbn.com Tue Aug 28 22:25:46 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E635F21F84F1 for ; Tue, 28 Aug 2012 22:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.486 X-Spam-Level: X-Spam-Status: No, score=-106.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQlGB4kX-UbE for ; Tue, 28 Aug 2012 22:25:46 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 62D6821F84E4 for ; Tue, 28 Aug 2012 22:25:45 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:60761 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1T6amd-000EmH-4H; Wed, 29 Aug 2012 01:25:43 -0400 Message-ID: <503DA7D5.2090806@bbn.com> Date: Wed, 29 Aug 2012 01:25:41 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Brian Dickson References: <24B20D14B2CD29478C8D5D6E9CBB29F625F555CB@Hermes.columbia.ads.sparta.com> <50389897.3040503@bbn.com> <97856400-9F70-4AEC-AF91-A0673A6D716D@verisign.com> <503C47A8.7030700@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr@ietf.org Subject: Re: [sidr] RPKI <-> allocation consistency X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 05:25:47 -0000 Brian, As I mentioned in my rely to Eric, I think this is a topic to be addressed in an RPKI operational considerations doc. We have draft-ietf-sidr-origin-ops-19 in progress now, so I suggest you discuss this with the author of that doc. Nonetheless, I'll offer my views on a few of the topics you mentioned: > ... > What model for the processes of maintaining sync between INR and RPKI > should be followed? A high-level finite state machine (FSM) model > should be an eventual goal, so that implementors have a crystal clear > model to follow. I rarely see FSMs in RFCs these days, although I agree that they are valuable in many contexts. Do we have an FSM for IRR data use by RPs? > At any point in time, what states should any particular element be > able to be in? > > How should an RP interpret each of those states? > > How can an RP identify the timeline it needs to follow, if it wants to > be as current as possible, with as little overhead and work required? > Clearly once-per-second polling won't scale. As I mentioned at the SIDR interim, each manifest contains a next issue date/time, which is a way for the CA to tell RPs when the RPs should expect to see new objects published. An RP could use that value as an indication of when to check the pub point for the CA in question (vs. using some fixed, periodic checking interval for all CAs). > Is there any corresponding place in the RPKI that would allow an > Originator to identify expected latency between ROA issuance, and the > update towards a given RP which would guarantee that the RP will > accept an announcement (in BGPSEC)? I don't think that the term "guarantee" is applicable here, given the vagaries of communication :-) . Steve From christopher.morrow@gmail.com Wed Aug 29 08:12:03 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5527221F86D1 for ; Wed, 29 Aug 2012 08:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQGbQp058ttH for ; Wed, 29 Aug 2012 08:12:02 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7766621F86B6 for ; Wed, 29 Aug 2012 08:12:02 -0700 (PDT) Received: by iabz21 with SMTP id z21so1467754iab.31 for ; Wed, 29 Aug 2012 08:12:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=KMcRR9AOYz/K/uDdfOEJX/vFBGpVUVg99atQoIVd0uo=; b=TqXR5YChoYSmDLWW4JsvwE9IWluhpyweWedLH9QSj/EGa45qWQh+oYYa54NboDTP/G aTBaU4iK4/4u1XYoYKDaolfJ1JFyuisV1ip7Do9x178OLU9z93qnBDoSZcRg5nGMfHul 8twSa2PK8u9M8cC4ZvOeBIk/uN4bNFv997FaQNYKbwtRiCSu1BNbzXXIbIlzImTHFyiW p6GFy2jjqmyCRYjdiVTdnePeGJN6Wlh6eCJyRiHKpyThLE+xGk/4X6SYT8DndhU73dKs VwlxEue4tCguXLrr9ZdzhGsMDwOV+xvfV+gt/H0I+Vf4mrISzRgttJ3buYL3ieZp7aLV BTlw== MIME-Version: 1.0 Received: by 10.50.195.194 with SMTP id ig2mr17884082igc.24.1346253122011; Wed, 29 Aug 2012 08:12:02 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.64.129.10 with HTTP; Wed, 29 Aug 2012 08:12:01 -0700 (PDT) In-Reply-To: <503DA7D5.2090806@bbn.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F555CB@Hermes.columbia.ads.sparta.com> <50389897.3040503@bbn.com> <97856400-9F70-4AEC-AF91-A0673A6D716D@verisign.com> <503C47A8.7030700@bbn.com> <503DA7D5.2090806@bbn.com> Date: Wed, 29 Aug 2012 11:12:01 -0400 X-Google-Sender-Auth: 3p0SEuT8XBtMn_439giVYOLAMHo Message-ID: From: Christopher Morrow To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr@ietf.org Subject: Re: [sidr] RPKI <-> allocation consistency X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 15:12:03 -0000 On Wed, Aug 29, 2012 at 1:25 AM, Stephen Kent wrote: > Brian, > > As I mentioned in my rely to Eric, I think this is a topic to be addressed > in an RPKI > operational considerations doc. We have draft-ietf-sidr-origin-ops-19 in > progress now, i had actually thought that both of the ops docs had this data, yes. I had thought were the likely locations. Some of what both Eric and Brian are poking at is what Danny poked at long ago: "As a number resource 'owner' (user? lessor? operator?) how long does it take for my shiny new ROA to get from me to 'everywhere I care about?'" the 'everywhere I care about' is probably 'everywhere' and is probably here more of a guideline than a hard rule... I suspect given the origin-ops + bgpsec-ops docs suggestions you're looking at ~12 hrs from start/finish for today's 4-ASHOP interwebs. (just a guess, someone could do the math... in fact, this is one of the math bits I was asking about in a previous message: ) > so I suggest you discuss this with the author of that doc. Nonetheless, I'll > offer my > views on a few of the topics you mentioned: > >> ... >> >> What model for the processes of maintaining sync between INR and RPKI >> should be followed? A high-level finite state machine (FSM) model should be >> an eventual goal, so that implementors have a crystal clear model to follow. > > I rarely see FSMs in RFCs these days, although I agree that they are > valuable in many contexts. Do > we have an FSM for IRR data use by RPs? > >> At any point in time, what states should any particular element be able to >> be in? >> >> How should an RP interpret each of those states? >> >> How can an RP identify the timeline it needs to follow, if it wants to be >> as current as possible, with as little overhead and work required? Clearly >> once-per-second polling won't scale. > > As I mentioned at the SIDR interim, each manifest contains a next issue > date/time, which is a > way for the CA to tell RPs when the RPs should expect to see new objects > published. An RP could use > that value as an indication of when to check the pub point for the CA in > question (vs. using some > fixed, periodic checking interval for all CAs). > >> Is there any corresponding place in the RPKI that would allow an >> Originator to identify expected latency between ROA issuance, and the update >> towards a given RP which would guarantee that the RP will accept an >> announcement (in BGPSEC)? > > I don't think that the term "guarantee" is applicable here, given the > vagaries of communication :-) . for quite some time the discussion has been: "Hey, all of your internal caches, in the most simplistic deployment, may not have all the same data. Additionally, you will have to gather from all over the globe data at all publication points, by the time you finish gathering you may also be behind." I don't see that that has changed much ... has it? I do think that understanding "hey, this publication of a new ROA/CRL/EE takes 12hrs to get everywhere[*]" is important though. -chris [*]: 'everywhere' means 'to each asn/RP', I think inside that ASN it's harder to decide if the job is done, BUT it's on the local AS operator to 'get it done'. > > > > > Steve > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From andy@arin.net Wed Aug 29 08:22:58 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84F121F84F2 for ; Wed, 29 Aug 2012 08:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11tpnbCsWm+f for ; Wed, 29 Aug 2012 08:22:58 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 2093221F84C4 for ; Wed, 29 Aug 2012 08:22:58 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id F3A571651C3; Wed, 29 Aug 2012 11:22:46 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id B28281651A9; Wed, 29 Aug 2012 11:22:46 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 29 Aug 2012 11:22:34 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.124]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0298.004; Wed, 29 Aug 2012 11:22:45 -0400 From: Andy Newton To: Christopher Morrow , Stephen Kent Thread-Topic: [sidr] RPKI <-> allocation consistency Thread-Index: Ac13EBo5wrqMsPdrRdKYnzi7/aF9VwJ6jE8AABhzrgAAWghfgAB3AzeAABWD6gAAFo1PAAAd7SKAABR6OoD//7/vgA== Date: Wed, 29 Aug 2012 15:22:45 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.1.35.153] Content-Type: text/plain; charset="Windows-1252" Content-ID: <27FDA7E49BCA0C4A92AD4968B42E3C2C@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] RPKI <-> allocation consistency X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 15:22:58 -0000 On 8/29/12 11:12 AM, "Christopher Morrow" wrote: >"As a number resource 'owner' (user? lessor? operator?) =8A" 'holder' is probably closer to the concept you want. -andy From Sandra.Murphy@sparta.com Wed Aug 29 09:10:07 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D28821F8606 for ; Wed, 29 Aug 2012 09:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTD4ffMP7uL7 for ; Wed, 29 Aug 2012 09:10:06 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 99D4021F8581 for ; Wed, 29 Aug 2012 09:10:06 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q7TGA3U9004328; Wed, 29 Aug 2012 11:10:03 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q7TGA2bW003851; Wed, 29 Aug 2012 11:10:03 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%21]) with mapi id 14.01.0355.002; Wed, 29 Aug 2012 12:10:46 -0400 From: "Murphy, Sandra" To: Alexey Melnikov , "sidr@ietf.org" Thread-Topic: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting Thread-Index: AQHNcmzBDgLmICzaeEOZLRGrqn0RiJdxGn+d Date: Wed, 29 Aug 2012 16:10:46 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F6733D@Hermes.columbia.ads.sparta.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: multipart/alternative; boundary="_000_24B20D14B2CD29478C8D5D6E9CBB29F625F6733DHermescolumbiaa_" MIME-Version: 1.0 Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 16:10:07 -0000 --_000_24B20D14B2CD29478C8D5D6E9CBB29F625F6733DHermescolumbiaa_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Speaking as wg co-chair: Certainly a very lively acceptance call! The chairs do not see that there was consensus that the wg should adopt thi= s draft. But there was ample evidence that the wg was interested in the issue - by t= he wg spending lots of time discussing the issue. So that leaves the chairs with an ambivalent message. The wg is very inter= ested in the topic but not in adopting a draft that would record any decisi= ons about the topic. What would the wg like to do now? Particularly those who disagreed with th= e content of the draft - if you would dislike the recommendations, are you = OK with no recommendations instead? --Sandy, speaking as wg co-chair ________________________________ From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Alexey Mel= nikov [alexey.melnikov@isode.com] Sent: Saturday, August 04, 2012 2:12 PM To: sidr@ietf.org Subject: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting Hi, On behalf of SIDR WG chairs I would like to initiate 2 weeks acceptance cal= l for draft-ymbk-rpki-grandparenting starting from today, August 4th. Pleas= e send your positive or negative feedback to the mailing list or directly t= o chairs. Thank you, Alexey --_000_24B20D14B2CD29478C8D5D6E9CBB29F625F6733DHermescolumbiaa_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Speaking as wg co-chair:

Certainly a very lively acceptance call!

The chairs do not see that there was consensus that the wg should adopt thi= s draft.

But there was ample evidence that the wg was interested in the issue - by t= he wg spending lots of time discussing the issue.

So that leaves the chairs with an ambivalent message.  The wg is very = interested in the topic but not in adopting a draft that would record any d= ecisions about the topic.

What would the wg like to do now?  Particularly those who disagreed wi= th the content of the draft - if you would dislike the recommendations, are= you OK with no recommendations instead?

--Sandy, speaking as wg co-chair

From: sidr-bounces@ietf.org [sidr-bounces@= ietf.org] on behalf of Alexey Melnikov [alexey.melnikov@isode.com]
Sent: Saturday, August 04, 2012 2:12 PM
To: sidr@ietf.org
Subject: [sidr] WG acceptance call for draft-ymbk-rpki-grandparentin= g

Hi,
On behalf of SIDR WG chairs I would like to initiate 2 weeks acceptanc= e call for draft-ymbk-rpki-grandparenting starting from today, August 4th. Please send your positive or negative feedback to the mailing list or directly to= chairs.

Thank you,
Alexey

--_000_24B20D14B2CD29478C8D5D6E9CBB29F625F6733DHermescolumbiaa_-- From Sandra.Murphy@sparta.com Wed Aug 29 09:13:44 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8255821F86EE for ; Wed, 29 Aug 2012 09:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QakJjbZ6TKgT for ; Wed, 29 Aug 2012 09:13:44 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id DF93221F86EC for ; Wed, 29 Aug 2012 09:13:43 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q7TGDhl9004359 for ; Wed, 29 Aug 2012 11:13:43 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q7TGDgfw003968 for ; Wed, 29 Aug 2012 11:13:43 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%21]) with mapi id 14.01.0355.002; Wed, 29 Aug 2012 12:14:26 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: reminder of wglc in progress Thread-Index: Ac2GAVvrRyGnUU9eQJuEreoXSUNvYg== Date: Wed, 29 Aug 2012 16:14:25 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F67351@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] reminder of wglc in progress X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 16:13:44 -0000 A reminder that there are three wglc in progress:=0A= =0A= http://www.ietf.org/mail-archive/web/sidr/current/msg04987.html=0A= http://www.ietf.org/mail-archive/web/sidr/current/msg04988.html=0A= http://www.ietf.org/mail-archive/web/sidr/current/msg04989.html=0A= =0A= Silence does not count as support for publication, so please do take a look= at these drafts and respond.=0A= =0A= --Sandy= From aservin@lacnic.net Wed Aug 29 09:27:06 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65DD111E80E0 for ; Wed, 29 Aug 2012 09:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3gYjAmejCmY for ; Wed, 29 Aug 2012 09:27:02 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id BA0E711E80E4 for ; Wed, 29 Aug 2012 09:27:01 -0700 (PDT) Received: from 85-7-200.lacnic.net.uy (unknown [200.7.85.90]) by mail.lacnic.net.uy (Postfix) with ESMTP id 0B176308437; Wed, 29 Aug 2012 13:26:52 -0300 (UYT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_211493B6-8295-45A4-9FA4-9260EB68DEDE" From: Arturo Servin In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F6733D@Hermes.columbia.ads.sparta.com> Date: Wed, 29 Aug 2012 12:26:46 -0400 Message-Id: <915DF220-8F92-4B13-AF86-54F5C4624B32@lacnic.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F6733D@Hermes.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1278) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: "sidr@ietf.org" Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 16:27:07 -0000 --Apple-Mail=_211493B6-8295-45A4-9FA4-9260EB68DEDE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 My recommendation would be to follow the registry. If the parent disappears then the grandparent should re-allocate = the resource to the grandchildren (which then will become a new child). IMHO is the only way to guarantee some RPKI <-> allocation = consistency. Regards, as Disclaimer: I work for a grandparent but this is my personal view. =20 On 29 Aug 2012, at 12:10, Murphy, Sandra wrote: > Speaking as wg co-chair: >=20 > Certainly a very lively acceptance call! >=20 > The chairs do not see that there was consensus that the wg should = adopt this draft. >=20 > But there was ample evidence that the wg was interested in the issue - = by the wg spending lots of time discussing the issue. >=20 > So that leaves the chairs with an ambivalent message. The wg is very = interested in the topic but not in adopting a draft that would record = any decisions about the topic. >=20 > What would the wg like to do now? Particularly those who disagreed = with the content of the draft - if you would dislike the = recommendations, are you OK with no recommendations instead? >=20 > --Sandy, speaking as wg co-chair >=20 > From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of = Alexey Melnikov [alexey.melnikov@isode.com] > Sent: Saturday, August 04, 2012 2:12 PM > To: sidr@ietf.org > Subject: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting >=20 > Hi, > On behalf of SIDR WG chairs I would like to initiate 2 weeks = acceptance call for draft-ymbk-rpki-grandparenting starting from today, = August 4th. Please send your positive or negative feedback to the = mailing list or directly to chairs. >=20 > Thank you, > Alexey >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_211493B6-8295-45A4-9FA4-9260EB68DEDE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

My recommendation would be to = follow the registry.

If the = parent disappears then the grandparent should re-allocate the resource = to the grandchildren (which then will become a new = child).

IMHO is the only way to guarantee = some 
From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on = behalf of Alexey Melnikov [alexey.melnikov@isode.com]Sent: Saturday,= August 04, 2012 2:12 PM
To: sidr@ietf.org
Subject: [sidr] WG acceptance call = for = draft-ymbk-rpki-grandparenting

Hi,
On behalf of SIDR WG chairs I would like to initiate 2 weeks = acceptance call for starting from today, August 4th. Please send = your positive or negative feedback to the mailing list or directly to = chairs.

Thank you,
Alexey

____________= ___________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/m= ailman/listinfo/sidr

= --Apple-Mail=_211493B6-8295-45A4-9FA4-9260EB68DEDE-- From carlosm3011@gmail.com Wed Aug 29 10:47:07 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9D811E80E2 for ; Wed, 29 Aug 2012 10:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RB-VfCKXtmdX for ; Wed, 29 Aug 2012 10:47:06 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7C65E11E80E0 for ; Wed, 29 Aug 2012 10:47:06 -0700 (PDT) Received: by yenm5 with SMTP id m5so166227yen.31 for ; Wed, 29 Aug 2012 10:47:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=UqevLY11XnI838zUuypUcTk17cjsAnixnNTJBT/VOU8=; b=GvbCT1kCrJHj1If4ksHwEkoGL6/ghdGRzRFDZfFWw5+pM94ZtXQx9NetYkG3uoeJ4e +rv4J9LcnyBep5kjrHeHGtAMlWFTNtMzMAfwPgqFpjFHWckt/6MmZJPZZN5KBebEd6Nx d7BYCBDhRvVfYfJ9iMpTre9b/8AzKNUp5J1d6bWmMbf/oCSskor6BqhdJhaIDA5hKzp3 Zd9GhACZu40Jvg1nYkTeFfj/FNtCjEGz1f3F/WPU9vQA1uS5kQSM81jK+NUMoGXJQWVC 2Du3IaRHZjYj69YX/rprkdW9oI1hl6EPvvNDj1IE9XHXFhy/XQ99Fzciszaay/3aIRxY 1u2Q== Received: by 10.236.77.39 with SMTP id c27mr2339959yhe.99.1346262426055; Wed, 29 Aug 2012 10:47:06 -0700 (PDT) Received: from europa.local ([2001:13c7:7001:2128:51d0:c9db:5398:b9ee]) by mx.google.com with ESMTPS id z5sm23131161ang.7.2012.08.29.10.47.03 (version=SSLv3 cipher=OTHER); Wed, 29 Aug 2012 10:47:04 -0700 (PDT) Message-ID: <503E5595.3040306@gmail.com> Date: Wed, 29 Aug 2012 14:47:01 -0300 From: "Carlos M. martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "sidr@ietf.org" References: <24B20D14B2CD29478C8D5D6E9CBB29F625F6733D@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F6733D@Hermes.columbia.ads.sparta.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 17:47:07 -0000 IMO the idea is worth considering, but only iif some implementable mechanism can be devised that: 1- guarantees following the registries (this would require grandparents somehow being able to check children's registries) 2- makes the fact that a given object has been produced on behalf of a grandchild explicit At some point I started thinking about some form of 'lightweight up/down' for lack of a better name, something that submits requests upwards but doesn't require operating a CA, but I'm not sure if it's worth the effort and probably parents won't deploy it anyways. ~CArlos On 8/29/12 1:10 PM, Murphy, Sandra wrote: > Speaking as wg co-chair: > > Certainly a very lively acceptance call! > > The chairs do not see that there was consensus that the wg should adopt > this draft. > > But there was ample evidence that the wg was interested in the issue - > by the wg spending lots of time discussing the issue. > > So that leaves the chairs with an ambivalent message. The wg is very > interested in the topic but not in adopting a draft that would record > any decisions about the topic. > > What would the wg like to do now? Particularly those who disagreed with > the content of the draft - if you would dislike the recommendations, are > you OK with no recommendations instead? > > --Sandy, speaking as wg co-chair > > ------------------------------------------------------------------------ > *From:* sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of > Alexey Melnikov [alexey.melnikov@isode.com] > *Sent:* Saturday, August 04, 2012 2:12 PM > *To:* sidr@ietf.org > *Subject:* [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting > > Hi, > On behalf of SIDR WG chairs I would like to initiate 2 weeks acceptance > call for draft-ymbk-rpki-grandparenting starting from today, August 4th. > Please send your positive or negative feedback to the mailing list or > directly to chairs. > > Thank you, > Alexey > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From andy@arin.net Wed Aug 29 13:56:15 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C99AA11E80F3 for ; Wed, 29 Aug 2012 13:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+b9vzIXxLZA for ; Wed, 29 Aug 2012 13:56:15 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id C76AD11E80EA for ; Wed, 29 Aug 2012 13:56:14 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 3FD09213666; Wed, 29 Aug 2012 16:56:14 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id B9F55213652; Wed, 29 Aug 2012 16:56:11 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 29 Aug 2012 16:55:52 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.124]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0298.004; Wed, 29 Aug 2012 16:56:04 -0400 From: Andy Newton To: "Murphy, Sandra" , Alexey Melnikov , "sidr@ietf.org" Thread-Topic: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting Thread-Index: AQHNcmy8FCcE8Dzhaka0MZcJTJP7npdxX+YAgAAMpIA= Date: Wed, 29 Aug 2012 20:56:04 +0000 Message-ID: In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F6733D@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.1.35.153] Content-Type: multipart/alternative; boundary="_000_CC63F9EEC1A7andyarinnet_" MIME-Version: 1.0 Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 20:56:15 -0000 --_000_CC63F9EEC1A7andyarinnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Are the chairs not allowing the draft authors to address the issues and try= again? -andy From: , Sandra > Date: Wednesday, August 29, 2012 12:10 PM To: Alexey Melnikov >, "sidr@ietf.org" > Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting Speaking as wg co-chair: Certainly a very lively acceptance call! The chairs do not see that there was consensus that the wg should adopt thi= s draft. But there was ample evidence that the wg was interested in the issue - by t= he wg spending lots of time discussing the issue. So that leaves the chairs with an ambivalent message. The wg is very inter= ested in the topic but not in adopting a draft that would record any decisi= ons about the topic. What would the wg like to do now? Particularly those who disagreed with th= e content of the draft - if you would dislike the recommendations, are you = OK with no recommendations instead? --Sandy, speaking as wg co-chair ________________________________ From: sidr-bounces@ietf.org [sidr-bounces@iet= f.org] on behalf of Alexey Melnikov [alexey.m= elnikov@isode.com] Sent: Saturday, August 04, 2012 2:12 PM To: sidr@ietf.org Subject: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting Hi, On behalf of SIDR WG chairs I would like to initiate 2 weeks acceptance cal= l for draft-ymbk-rpki-grandparenting starting from today, August 4th. Pleas= e send your positive or negative feedback to the mailing list or directly t= o chairs. Thank you, Alexey --_000_CC63F9EEC1A7andyarinnet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Are the chairs not allowing the draft authors to address the issues an= d try again?

-andy

From: <Murphy>, Sandra <Sandra.Murphy@sparta.com><= br> Date: Wednesday, August 29, 2012 12= :10 PM
To: Alexey Melnikov <alexey.melnikov@isode.com>, "= sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] WG acceptance c= all for draft-ymbk-rpki-grandparenting

Speaking as wg co-chair:

Certainly a very lively acceptance call!

The chairs do not see that there was consensus that the wg should adopt thi= s draft.

But there was ample evidence that the wg was interested in the issue - by t= he wg spending lots of time discussing the issue.

So that leaves the chairs with an ambivalent message.  The wg is very = interested in the topic but not in adopting a draft that would record any d= ecisions about the topic.

What would the wg like to do now?  Particularly those who disagreed wi= th the content of the draft - if you would dislike the recommendations, are= you OK with no recommendations instead?

--Sandy, speaking as wg co-chair

From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of A= lexey Melnikov [alexey.melniko= v@isode.com]
Sent: Saturday, August 04, 2012 2:12 PM
To: sidr@ietf.org
Subject: [sidr] WG acceptance call for draft-ymbk-rpki-grandparentin= g

Hi,
On behalf of SIDR WG chairs I would like to initiate 2 weeks acceptanc= e call for draft-ymbk-rpki-grandparenting starting from today, August 4th. Please send your positive or negative feedback to the mailing list or directly to= chairs.

Thank you,
Alexey

 --_000_CC63F9EEC1A7andyarinnet_-- From Sandra.Murphy@sparta.com Wed Aug 29 14:06:05 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB62E21F85F4 for ; Wed, 29 Aug 2012 14:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNfiLPc+4lq4 for ; Wed, 29 Aug 2012 14:06:04 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id A153621F8605 for ; Wed, 29 Aug 2012 14:06:04 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q7TL63CG007428; Wed, 29 Aug 2012 16:06:03 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q7TL63MZ012852; Wed, 29 Aug 2012 16:06:03 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%21]) with mapi id 14.01.0355.002; Wed, 29 Aug 2012 17:06:47 -0400 From: "Murphy, Sandra" To: Andy Newton , Alexey Melnikov , "sidr@ietf.org" Thread-Topic: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting Thread-Index: AQHNcmzBDgLmICzaeEOZLRGrqn0RiJdxGn+dgACVHQD//74d0w== Date: Wed, 29 Aug 2012 21:06:46 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F68471@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F6733D@Hermes.columbia.ads.sparta.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 21:06:05 -0000 Speaking as wg co-chair=0A= =0A= Of course revision and new request for acceptance is possible.=0A= =0A= Even arguing some more leading to acceptance of draft as is is a possibilit= y.=0A= =0A= Some commentors specifically requested that the discussion be added to some= existing draft.=0A= =0A= Trying to judge wg desire of a way to proceed.=0A= =0A= =0A= --Sandy=0A= =0A= =0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Andy Newto= n [andy@arin.net]=0A= =0A= Sent: Wednesday, August 29, 2012 4:56 PM=0A= =0A= To: Murphy, Sandra; Alexey Melnikov; sidr@ietf.org=0A= =0A= Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Are the chairs not allowing the draft authors to address the issues and try= again?=0A= =0A= =0A= =0A= -andy=0A= =0A= =0A= =0A= =0A= =0A= From: , Sandra =0A= =0A= Date: Wednesday, August 29, 2012 12:10 PM=0A= =0A= To: Alexey Melnikov , "sidr@ietf.org"=0A= =0A= =0A= Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= BODY {direction: ltr;font-family: Arial;color: #000000;font-size: 10pt;}P {= margin-top:0;margin-bottom:0;}=0A= =0A= Speaking as wg co-chair:=0A= =0A= =0A= =0A= Certainly a very lively acceptance call!=0A= =0A= =0A= =0A= The chairs do not see that there was consensus that the wg should adopt thi= s draft.=0A= =0A= =0A= =0A= But there was ample evidence that the wg was interested in the issue - by t= he wg spending lots of time discussing the issue.=0A= =0A= =0A= =0A= So that leaves the chairs with an ambivalent message. The wg is very inter= ested in the topic but not in adopting a draft that would record any decisi= ons about the topic.=0A= =0A= =0A= =0A= What would the wg like to do now? Particularly those who disagreed with th= e content of the draft - if you would dislike the recommendations, are you = OK with no recommendations instead?=0A= =0A= =0A= =0A= --Sandy, speaking as wg co-chair=0A= =0A= =0A= =0A= =0A= =0A= From:=0A= =0A= sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Alexey Melnikov = [alexey.melnikov@isode.com]=0A= =0A= Sent: Saturday, August 04, 2012 2:12 PM=0A= =0A= To: =0A= sidr@ietf.org=0A= =0A= Subject: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting=0A= =0A= =0A= =0A= =0A= =0A= Hi,=0A= =0A= On behalf of SIDR WG chairs I would like to initiate 2 weeks acceptance cal= l for draft-ymbk-rpki-grandparenting starting from today, August 4th. Pleas= e=0A= send your positive or negative feedback to the mailing list or directly to= chairs.=0A= =0A= =0A= =0A= =0A= Thank you,=0A= Alexey=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= From jgs@juniper.net Wed Aug 29 14:15:27 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A8F21F8667 for ; Wed, 29 Aug 2012 14:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.423 X-Spam-Level: X-Spam-Status: No, score=-6.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8i4b3TVe27e for ; Wed, 29 Aug 2012 14:15:26 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id A44F321F8645 for ; Wed, 29 Aug 2012 14:15:26 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUD6Ga5Bo0XeAmNwmG4J9/LIjnwA00b8n@postini.com; Wed, 29 Aug 2012 14:15:26 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 29 Aug 2012 14:13:33 -0700 Received: from [172.16.13.202] ([172.16.13.202]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q7TLDWh36653; Wed, 29 Aug 2012 14:13:32 -0700 (PDT) (envelope-from jgs@juniper.net) MIME-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset="us-ascii" From: "John G. Scudder" In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F61435@Hermes.columbia.ads.sparta.com> Date: Wed, 29 Aug 2012 17:13:32 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <24B20D14B2CD29478C8D5D6E9CBB29F625F61435@Hermes.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1278) Cc: "sidr@ietf.org" Subject: Re: [sidr] WGLC on draft-ietf-sidr-rpki-rtr-impl-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 21:15:27 -0000 Looks good to me, except should it really be targeted for Standards = Track? Informational seems to make more sense. --John On Aug 17, 2012, at 12:58 PM, Murphy, Sandra wrote: > The authors believe that the draft is ready for publication. This = announces a two week last call. The WGLC will end 31 Aug 2012. >=20 > Please report to the list whether you support publication of this = draft or not. >=20 > The draft is available at > http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-impl-01 >=20 > The abstract says: >=20 > This document provides an implementation report for RPKI Router > protocol as defined in [I-D.ietf-sidr-rpki-rtr]. The editor did not > verify the accuracy of the information provided by respondents or by > any alternative means. The respondents are experts with the > implementations they reported on, and their responses are considered > authoritative for the implementations for which their responses > represent. Respondents were asked to only use the YES answer if the > feature had at least been tested in the lab. >=20 >=20 >=20 > --Sandy, speaking as wg co-chair > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From christopher.morrow@gmail.com Thu Aug 30 07:54:20 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0BD321F8587 for ; Thu, 30 Aug 2012 07:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCN3TgIkhqlo for ; Thu, 30 Aug 2012 07:54:19 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C2D0121F8597 for ; Thu, 30 Aug 2012 07:54:18 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2298089vbb.31 for ; Thu, 30 Aug 2012 07:54:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=74IjW0FBUP74xBz2EtuLBxfaPD96mtcY3xkZfQq8oxs=; b=wAboJbn5YWnzaTfAREpsTOc3DUTzUGxB3fQcvFbkNg5iiHburemgbyVjpMox1NVzgK kyUbTtsgi0MU5Ol0/pSGYs6+/oRRi+MNR9Dkh5BpfUeGYg6j7OA+1GIGdwK1h1rm/p+1 /VUYIbDa5cl+p3ZJM1o55TMvJ+RzWrpUk6ivKlQpXq2uZxCFDjvCtlE8kEOoYjuq+GCz m+zH7v9zKaVSZhItdwQkQbGg0IDXc2lFm2/FFpgxmoBoVdi1SVFDK5qcfJboEvLZbK6v sDmn9d8HeqS7bZhr4r+5BbTO/N3hRfMLQF2IDuZOK2105nuB9/o+Yg+TimFhdGLwwNQY 4LmA== MIME-Version: 1.0 Received: by 10.220.220.203 with SMTP id hz11mr3436475vcb.50.1346338458053; Thu, 30 Aug 2012 07:54:18 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.58.216.42 with HTTP; Thu, 30 Aug 2012 07:54:17 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Aug 2012 10:54:17 -0400 X-Google-Sender-Auth: 7uy4sc0w6gK-NagThRokELg7xO4 Message-ID: From: Christopher Morrow To: Andy Newton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "sidr@ietf.org" Subject: Re: [sidr] RPKI <-> allocation consistency X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 14:54:21 -0000 On Wed, Aug 29, 2012 at 11:22 AM, Andy Newton wrote: > > > On 8/29/12 11:12 AM, "Christopher Morrow" wrote= : > >>"As a number resource 'owner' (user? lessor? operator?) =C5=A0" > > 'holder' is probably closer to the concept you want. sounds good to me. From eosterweil@verisign.com Thu Aug 30 07:59:15 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4A4E21F8621 for ; Thu, 30 Aug 2012 07:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHVVgEx1Sg13 for ; Thu, 30 Aug 2012 07:59:15 -0700 (PDT) Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) by ietfa.amsl.com (Postfix) with ESMTP id 10DF621F8619 for ; Thu, 30 Aug 2012 07:59:15 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKUD9/wILbSHUhhve413G15zSyPAm+mwOO@postini.com; Thu, 30 Aug 2012 07:59:15 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q7UEx9gW021406; Thu, 30 Aug 2012 10:59:11 -0400 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.29.242]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 30 Aug 2012 10:59:09 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: <503D141F.1060404@bbn.com> Date: Thu, 30 Aug 2012 10:59:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3A791D9E-4F16-4481-94AE-BD38A5389593@verisign.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F555CB@Hermes.columbia.ads.sparta.com> <50389897.3040503@bbn.com> <97856400-9F70-4AEC-AF91-A0673A6D716D@verisign.com> <503C47A8.7030700@bbn.com> <303C576D-D1F8-4F62-8E0E-0D74A28B2771@verisign.com> <503D141F.1060404@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 30 Aug 2012 14:59:09.0006 (UTC) FILETIME=[021006E0:01CD86C0] Cc: sidr@ietf.org Subject: Re: [sidr] RPKI <-> allocation consistency X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 14:59:15 -0000 On Aug 28, 2012, at 2:55 PM, Stephen Kent wrote: > Eric, >=20 > Perhaps what you are looking for is some text in an operations doc, = suggesting what > an RP can expect, depending on how it elects to interact with the = repository system, > maintain its local cache, etc. Actually, I was looking for some intuition/guidance for people in a = position to take a systematic look at how to implement the design. I'm = not sure which draft, or which section, etc. Basically, I'm trying to = get things worked out, but I keep having issues w/ ensuring that = ingestion of data by a process at (say) one router has = something/anything to do with the ingestion of the same thing at (say) = another router. Consistency models tell me what properties I can rely = on at time t_0 at location r_0 vs time t_1 at r_1, etc. Right now, I'm = having a lot of trouble ensuring that anything agrees with anything else = in the Interwebz and I don't know if I should just let that be the case, = or there is some sort of consistency I need to adhere to... Eric= From christopher.morrow@gmail.com Thu Aug 30 10:17:15 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40FD421F8540 for ; Thu, 30 Aug 2012 10:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eb+HDYCT+B83 for ; Thu, 30 Aug 2012 10:17:14 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5AA21F853E for ; Thu, 30 Aug 2012 10:17:14 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so2586374vcb.31 for ; Thu, 30 Aug 2012 10:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ctMdfR8/MTfQwrvVrbSjcyHsRiO2BYw6ySWYHpSRafg=; b=slFp3ms8yVl8h7ykuLKoN1IOWXW/8pF9fM0DI3myC9p+oWSH6Xb1+thRFbdL0cPyPN AAkGqZDk9yZGJXwdOOI+GNFMapFY+Pyf7iyWXIvpzwg+Km6U2V0GcelZ+ZOueb5PCKfs a5PAqNnyzwoSPgux6Ne8eu4pdSioeHeQRJ1pXQvumE1ljx6jhM6kO33zgk9E3/+0B873 NA8XHnZX44daB0JEtuQeQGLXpXb67ekfVMMUD85StZ7mZnJgqn8DOs918pv/NUtcsUpW b3p651vE4uYtl2Ab1bbKxIhw9fLIvSn07lzdRpYxgTqYYLTnlaUBJkobudlKSW8sss/y cUBQ== MIME-Version: 1.0 Received: by 10.221.11.138 with SMTP id pe10mr2223285vcb.54.1346347033996; Thu, 30 Aug 2012 10:17:13 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.58.216.42 with HTTP; Thu, 30 Aug 2012 10:17:13 -0700 (PDT) In-Reply-To: <3A791D9E-4F16-4481-94AE-BD38A5389593@verisign.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F555CB@Hermes.columbia.ads.sparta.com> <50389897.3040503@bbn.com> <97856400-9F70-4AEC-AF91-A0673A6D716D@verisign.com> <503C47A8.7030700@bbn.com> <303C576D-D1F8-4F62-8E0E-0D74A28B2771@verisign.com> <503D141F.1060404@bbn.com> <3A791D9E-4F16-4481-94AE-BD38A5389593@verisign.com> Date: Thu, 30 Aug 2012 13:17:13 -0400 X-Google-Sender-Auth: KaitXx9v7CV1PffoZ-84vKD1r8g Message-ID: From: Christopher Morrow To: Eric Osterweil Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr@ietf.org Subject: Re: [sidr] RPKI <-> allocation consistency X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 17:17:15 -0000 On Thu, Aug 30, 2012 at 10:59 AM, Eric Osterweil wrote: > > On Aug 28, 2012, at 2:55 PM, Stephen Kent wrote: > >> Eric, >> >> Perhaps what you are looking for is some text in an operations doc, sugg= esting what >> an RP can expect, depending on how it elects to interact with the reposi= tory system, >> maintain its local cache, etc. > > Actually, I was looking for some intuition/guidance for people in a posit= ion to take a systematic look at how to implement the design. I'm not sure= which draft, or which section, etc. Basically, I'm trying to get things w= orked out, but I keep having issues w/ ensuring that ingestion of data by a= process at (say) one router has something/anything to do with the ingestio= n of the same thing at (say) another router. Consistency models tell me wh= at properties I can rely on at time t_0 at location r_0 vs time t_1 at r_1,= etc. Right now, I'm having a lot of trouble ensuring that anything agrees= with anything else in the Interwebz and I don't know if I should just let = that be the case, or there is some sort of consistency I need to adhere to.= .. > right, for the whole system you want to know: 'how long between ROA create and ROA-foo on router' I think what you really want (because across the whole of the realm it's a 'simple' model, where inside islands there is potentially lots more fudgery) is: 1) 'how long from roa-create -> roa-at-all-ASNs' 2) 'what model of timing makes sense for 'once a ROA is at a remote ASN, how long before that data is available on 1 routing-device, then all routing-devices in that realm' 3) should this set of numbers apply to ALL objects in the RPKI equally? or should some object types have different timing requirements? -chris (using ROA as the unit, you could use CRL update, EE-cert, etc... 'one item in the RPKI') > Eric > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From brian.peter.dickson@gmail.com Thu Aug 30 11:30:08 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0876F21F85C3 for ; Thu, 30 Aug 2012 11:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.494 X-Spam-Level: X-Spam-Status: No, score=-3.494 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcpNbPoD-0ku for ; Thu, 30 Aug 2012 11:30:06 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id F3BBE21F85AF for ; Thu, 30 Aug 2012 11:30:05 -0700 (PDT) Received: by wibhq12 with SMTP id hq12so568207wib.1 for ; Thu, 30 Aug 2012 11:30:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2w+GkoRpDoYFf+d0+0PJKu+jpsXHWhT2SwN/JVz4o0c=; b=I/iGy15OO/Bgdf+Ph2zT4Rqr/eVeGoy8nML3TKyW8oUxxxuPXFgl2r8gc2btGPAh4a 8B5aVMxqaPK1WVsSFBHKTDDdXJlRJKcm0qZ2730exVRUDdq9F+dAz2pPWTrN8Z6uK0IG PVZhimf99NYztd9NAD5eE8nbuH9zyKXbZJmSdpdzdLA+xEt/Mbwkq7AVWstd38D0oj9P iDkEAiAodz5R0sNMlLTCs0rOalHIfKECj5o7g4jisBdJZ1nsnx0bxHwu/6amh24TU381 d1ikzXFwIMxW07U9mjdG80Vtq8RQR/+6QMvmxsWxlwkdfx0V/LPhq3ipQqLxuUi30kEV hdKA== MIME-Version: 1.0 Received: by 10.216.245.70 with SMTP id n48mr3121974wer.139.1346351403492; Thu, 30 Aug 2012 11:30:03 -0700 (PDT) Received: by 10.223.61.12 with HTTP; Thu, 30 Aug 2012 11:30:03 -0700 (PDT) In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F625F555CB@Hermes.columbia.ads.sparta.com> <50389897.3040503@bbn.com> <97856400-9F70-4AEC-AF91-A0673A6D716D@verisign.com> <503C47A8.7030700@bbn.com> <303C576D-D1F8-4F62-8E0E-0D74A28B2771@verisign.com> <503D141F.1060404@bbn.com> <3A791D9E-4F16-4481-94AE-BD38A5389593@verisign.com> Date: Thu, 30 Aug 2012 14:30:03 -0400 Message-ID: From: Brian Dickson To: Christopher Morrow Content-Type: multipart/alternative; boundary=e0cb4e43d03325e6d204c87fdd42 Cc: sidr@ietf.org Subject: Re: [sidr] RPKI <-> allocation consistency X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 18:30:08 -0000 --e0cb4e43d03325e6d204c87fdd42 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 30, 2012 at 1:17 PM, Christopher Morrow wrote: > On Thu, Aug 30, 2012 at 10:59 AM, Eric Osterweil > wrote: > > > > On Aug 28, 2012, at 2:55 PM, Stephen Kent wrote: > > > >> Eric, > >> > >> Perhaps what you are looking for is some text in an operations doc, > suggesting what > >> an RP can expect, depending on how it elects to interact with the > repository system, > >> maintain its local cache, etc. > > > > Actually, I was looking for some intuition/guidance for people in a > position to take a systematic look at how to implement the design. I'm not > sure which draft, or which section, etc. Basically, I'm trying to get > things worked out, but I keep having issues w/ ensuring that ingestion of > data by a process at (say) one router has something/anything to do with the > ingestion of the same thing at (say) another router. Consistency models > tell me what properties I can rely on at time t_0 at location r_0 vs time > t_1 at r_1, etc. Right now, I'm having a lot of trouble ensuring that > anything agrees with anything else in the Interwebz and I don't know if I > should just let that be the case, or there is some sort of consistency I > need to adhere to... > > > > right, for the whole system you want to know: > 'how long between ROA create and ROA-foo on router' > > I think what you really want (because across the whole of the realm > it's a 'simple' model, where inside islands there is potentially lots > more fudgery) is: > 1) 'how long from roa-create -> roa-at-all-ASNs' > 2) 'what model of timing makes sense for 'once a ROA is at a remote > ASN, how long before that data is available on 1 routing-device, then > all routing-devices in that realm' > 3) should this set of numbers apply to ALL objects in the RPKI > equally? or should some object types have different timing > requirements? > > -chris > > (using ROA as the unit, you could use CRL update, EE-cert, etc... 'one > item in the RPKI') > I think this extends out to the several kinds of "consistency" questions I have, as well. For example: There are a whole bunch of documents that detail bits and pieces of the RPKI, some of which have some ASCII-art showing parts of the system. However, there is a severe lack of detail on the things it is about, specifically IP prefixes (INRs) that are protected via the whole system. In fact, in the one document that I think should be most critical, on validating ROAs, there are almost no references to IP blocks, and what few there are get referred to either indirectly (via another RFC reference) or using inconsistent terminology. After reviewing the whole mess of docs, and following the mutual implicit or explicit cross-references, I have some questions that don't seem to have been answered by the docs (both the published RFCs and current I-Ds). (1) What is the presumed model for INRs themselves? Are INRs presumed to be exclusive, and allocations hierarchical (with the occasional instance of an entire allocation being handed off without being divided)? That is to say, is a given piece of address space (contiguous power-of-2 block) always under the exclusive control of one party, based on longest-match rules of IP routing? (I'm pretty sure that the existing assignment methods starting at IANA->RIRs is built entirely on exclusivity, modulo RFC1918 space.) (2) If INRs are meant to be exclusive, why does the RPKI not enforce that exclusivity? It appears, having looked at the docs in the context of grandparenting, that despite the assertion that validation is a top-down activity, it is fundamentally a bottom-up process (looking for an eventual match against a trust anchor). And, in essence, there is no requirement that INR "delegations" that occur at any given CA, need to be unique, which presumably contradicts the nature of INRs. (Note here - the presumption is not uniqueness by ASN, but uniqueness by organization controlling ROA assignment, where that single org could/would issue ROAs for multiple ASNs.) I believe that enforcing exclusivity of INR blocks within each CA's set of signed objects, is all that is needed to achieve global uniqueness. A CA's ROA(s) could be matched against delegations, requiring a zero-overlap, or alternatively modifying the ROA validation process to somehow disambiguate things. (3) If an ROA is issued by CA_1 for A.B.C.D/X (max length X+Y, Y>=1), and the same CA_1 also signs a delegation on A.B.C.D/(X+1) to CA_2, who issues an ROA for A.B.C.D/(X+1) (max length (X+1)+Y, Y>=0), that two parties are then legitimately able to originate (conflicting) BGP routes for A.B.C.D/X+1 - something that I doubt CA_2 would be happy about (even as a possibility, let alone an actuality). (4) ROAs appear to be "containers" for (possibly) multiple prefixes. Is it strictly necessary for every prefix in a ROA to validate properly, for a ROA to validate? Or, if not, how does that work for partial validity, prefix-by-prefix? (5) Everything in the validation and RPKI seems to be forward-lookup oriented from an ASN perspective. What about trying to look up information on a given prefix, if you don't have the ASN(s)? It seems like it would require an exhaustive search of every pub point under any published CA that contained a covering address for the prefix in question. Is that correct, and did anyone look at this originally when designing the RPKI? What if you have one ASN that you know is announcing a given prefix, but want to find out if any other ASN has a valid ROA which includes the same prefix (or covering prefix, or child prefix)? (6) What about an informational RFC to tie all the relevant bits together, e.g. with big ASCII-art diagrams, high-level text describing relationships, and pointers to detailed technical RFCs? Without this, trying to understand any of this, let along trying to implement, is rather unwieldy. (7) This also points towards the number of places the docs "punt" on critical issues. E.g. the question of INR->RPKI timing ("...is a side-effect...") is pretty vague. I also think the issue of "bogon" space could/should be addressed, so that unused space can not only _not_ be part of any ROA, but that unused space can authoritatively be excluded from routing tables via BGPSEC mechanisms. (There is no reason to wait for everyone to deploy BGPSEC to achieve this piece of low hanging fruit.) Since INRs are allocated top-down, Reserved space can trivially be authenticated and placed into a "black list" dynamically. Any comments, from anyone, on any of these, are welcome. Brian --e0cb4e43d03325e6d204c87fdd42 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Aug 30, 2012 at 1:17 PM, Christo= pher Morrow <morrowc.lists@gmail.com> wrote:
On Thu, Aug 30, 2012 at 10:59 AM, Eric Osterweil
<eosterweil@verisign.com&= gt; wrote:
>
> On Aug 28, 2012, at 2:55 PM, Stephen Kent wrote:
>
>> Eric,
>>
>> Perhaps what you are looking for is some text in an operations doc= , suggesting what
>> an RP can expect, depending on how it elects to interact with the = repository system,
>> maintain its local cache, etc.
>
> Actually, I was looking for some intuition/guidance for people in a po= sition to take a systematic look at how to implement the design. =A0I'm= not sure which draft, or which section, etc. =A0Basically, I'm trying = to get things worked out, but I keep having issues w/ ensuring that ingesti= on of data by a process at (say) one router has something/anything to do wi= th the ingestion of the same thing at (say) another router. =A0Consistency = models tell me what properties I can rely on at time t_0 at location r_0 vs= time t_1 at r_1, etc. =A0Right now, I'm having a lot of trouble ensuri= ng that anything agrees with anything else in the Interwebz and I don't= know if I should just let that be the case, or there is some sort of consi= stency I need to adhere to...
>

right, for the whole system you want to know:
=A0 'how long between ROA create and ROA-foo on router'

I think what you really want (because across the whole of the realm
it's a 'simple' model, where inside islands there is potentiall= y lots
more fudgery) is:
=A0 1) 'how long from roa-create -> roa-at-all-ASNs'
=A0 2) 'what model of timing makes sense for 'once a ROA is at a re= mote
ASN, how long before that data is available on 1 routing-device, then
all routing-devices in that realm'
=A0 3) should this set of numbers apply to ALL objects in the RPKI
equally? or should some object types have different timing
requirements?

-chris

(using ROA as the unit, you could use CRL update, EE-cert, etc... 'one<= br> item in the RPKI')

=

I think this extends out to the several kinds of "= consistency" questions I have, as well.

For e= xample:

There are a whole bunch of documents that detail bits a= nd pieces of the RPKI, some of which have some ASCII-art showing parts of t= he system.

However, there is a severe lack of deta= il on the things it is about, specifically IP prefixes (INRs) that are prot= ected via the whole system.

In fact, in the one document that I think should be mos= t critical, on validating ROAs, there are almost no references to IP blocks= , and what few there are get referred to either indirectly (via another RFC= reference) or using inconsistent terminology.

After reviewing the whole mess of docs, and following t= he mutual implicit or explicit cross-references, I have some questions that= don't seem to have been answered by the docs (both the published RFCs = and current I-Ds).

(1) What is the presumed model for INRs themselves?
Are INRs presumed to be exclusive, and allocations hierarchical (wit= h the occasional instance of an entire allocation being handed off without = being divided)?
That is to say, is a given piece of address space (contiguous power-of= -2 block) always under the exclusive control of one party, based on longest= -match rules of IP routing?
(I'm pretty sure that the existin= g assignment methods starting at IANA->RIRs is built entirely on exclusi= vity, modulo RFC1918 space.)

(2) If INRs are meant to be exclusive, why does the RPK= I not enforce that exclusivity?
It appears, having looked at the = docs in the context of grandparenting, that despite the assertion that vali= dation is a top-down activity, it is fundamentally a bottom-up process (loo= king for an eventual match against a trust anchor).
And, in essence, there is no requirement that INR "delegations&qu= ot; that occur at any given CA, need to be unique, which presumably contrad= icts the nature of INRs.
(Note here - the presumption is not uniq= ueness by ASN, but uniqueness by organization controlling ROA assignment, w= here that single org could/would issue ROAs for multiple ASNs.)
I believe that enforcing exclusivity of INR blocks within each CA'= s set of signed objects, is all that is needed to achieve global uniqueness= . A CA's ROA(s) could be matched against delegations, requiring a zero-= overlap, or alternatively modifying the ROA validation process to somehow d= isambiguate things.

(3) If an ROA is issued by CA_1 for A.B.C.D/X (max leng= th X+Y, Y>=3D1), and the same CA_1 also signs a delegation on A.B.C.D/(X= +1) to CA_2, who issues an ROA for A.B.C.D/(X+1) (max length (X+1)+Y, Y>= =3D0), that two parties are then legitimately able to originate (conflictin= g) BGP routes for A.B.C.D/X+1 - something that I doubt CA_2 would be happy = about (even as a possibility, let alone an actuality).

(4) ROAs appear to be "containers" for (possi= bly) multiple prefixes. Is it strictly necessary for every prefix in a ROA = to validate properly, for a ROA to validate? Or, if not, how does that work= for partial validity, prefix-by-prefix?

(5) Everything in the validation and RPKI seems to be f= orward-lookup oriented from an ASN perspective. What about trying to look u= p information on a given prefix, if you don't have the ASN(s)? It seems= like it would require an exhaustive search of every pub point under any pu= blished CA that contained a covering address for the prefix in question. Is= that correct, and did anyone look at this originally when designing the RP= KI? What if you have one ASN that you know is announcing a given prefix, bu= t want to find out if any other ASN has a valid ROA which includes the same= prefix (or covering prefix, or child prefix)?

(6) What about an informational RFC to tie all the rele= vant bits together, e.g. with big ASCII-art diagrams, high-level text descr= ibing relationships, and pointers to detailed technical RFCs? Without this,= trying to understand any of this, let along trying to implement, is rather= unwieldy.

(7) This also points towards the number of places the d= ocs "punt" on critical issues. E.g. the question of INR->RPKI = timing ("...is a side-effect...") is pretty vague. I also think t= he issue of "bogon" space could/should be addressed, so that unus= ed space can not only _not_ be part of any ROA, but that unused space can a= uthoritatively be excluded from routing tables via BGPSEC mechanisms. (Ther= e is no reason to wait for everyone to deploy BGPSEC to achieve this piece = of low hanging fruit.) Since INRs are allocated top-down, Reserved space ca= n trivially be authenticated and placed into a "black list" dynam= ically.

Any comments, from anyone, on any of these, are welcome= .

Brian
--e0cb4e43d03325e6d204c87fdd42-- From brian.peter.dickson@gmail.com Thu Aug 30 11:59:43 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB8521F857D for ; Thu, 30 Aug 2012 11:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.323 X-Spam-Level: X-Spam-Status: No, score=-3.323 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkYoSu0in2PP for ; Thu, 30 Aug 2012 11:59:42 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3502821F8575 for ; Thu, 30 Aug 2012 11:59:42 -0700 (PDT) Received: by weyu54 with SMTP id u54so1304373wey.31 for ; Thu, 30 Aug 2012 11:59:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8XJg0reak3XHZi9Ck8m0MWzEOuQkvYYY1DAxwwVyzeE=; b=IrJjx64wTf8RGrIeMcZmGNWrpobpX5kby3alXsMBySt3mesTer/8f3dElgpqffB0hX eq6vgGc/2L426eHVz6+r52ZSdoZMw/oSvBJP6z3xldi4bAUSmSo5I0o9hegnLNdNpkNC D0Vc8473HWnkkk9rk2oMZ4AdoWhjeVSCi/gHZSEXSiZPzJpMGFUjCEi52c474ga47qX2 w5PlmrCDuyjpZ182JnJL0/uuMraQsTENpTGpxOD+WSbts1blOErcg7Hd0WZXM1+Arfzl zVKYn/PUeqellv+I+o+NZIa9P+SUaUHfUmvVjYJLCjlBwaP+GKpJFTqbuXEFy50nsnxp GhpQ== MIME-Version: 1.0 Received: by 10.216.66.7 with SMTP id g7mr3592441wed.146.1346353181101; Thu, 30 Aug 2012 11:59:41 -0700 (PDT) Received: by 10.223.61.12 with HTTP; Thu, 30 Aug 2012 11:59:40 -0700 (PDT) In-Reply-To: <503DA7D5.2090806@bbn.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F555CB@Hermes.columbia.ads.sparta.com> <50389897.3040503@bbn.com> <97856400-9F70-4AEC-AF91-A0673A6D716D@verisign.com> <503C47A8.7030700@bbn.com> <503DA7D5.2090806@bbn.com> Date: Thu, 30 Aug 2012 14:59:40 -0400 Message-ID: From: Brian Dickson To: Stephen Kent Content-Type: multipart/alternative; boundary=e0cb4e7004ed1a0e4104c8804780 Cc: sidr@ietf.org Subject: Re: [sidr] RPKI <-> allocation consistency X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 18:59:43 -0000 --e0cb4e7004ed1a0e4104c8804780 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 29, 2012 at 1:25 AM, Stephen Kent wrote: > Brian, > > As I mentioned in my rely to Eric, I think this is a topic to be addressed > in an RPKI > operational considerations doc. We have draft-ietf-sidr-origin-ops-19 in > progress now, > so I suggest you discuss this with the author of that doc. Nonetheless, > I'll offer my > views on a few of the topics you mentioned: > > ... >> >> What model for the processes of maintaining sync between INR and RPKI >> should be followed? A high-level finite state machine (FSM) model should be >> an eventual goal, so that implementors have a crystal clear model to follow. >> > I rarely see FSMs in RFCs these days, although I agree that they are > valuable in many contexts. Do > we have an FSM for IRR data use by RPs? I don't know about FSM _diagram, but the RIPE database (which includes not only IRR data but also authoritative INR data and RPKI data), is fully documented here: http://www.ripe.net/data-tools/support/documentation And in particular the manual, including how a request turns into an "inetnum" (and RPKI object, now) is here: http://www.ripe.net/lir-services/training/material/LIR-Training-Course/LIR-Handbook.pdf The language used in the objects, RPSL, is memorialized here: http://tools.ietf.org/html/rfc2622 (Published in 1999, updated by: http://tools.ietf.org/html/rfc4012) The history of the IRRs, language, and tools, is well documented here: http://tools.ietf.org/html/rfc4277#page-15 And it might be well noted, that the RADB dates back to the Routing Arbiter project, and to its predecessor-in-interest (PRDB) which predates BGP version 4. RIPE-81 -> RIPE-181 -> RPSL. But, as author or co-author of several SIDR docs, I'm presuming you're already familiar with the above? You wouldn't really try implementing a system for (securely) registering internet routing information, without being completely familiar with prior art in the field, would you? Brian --e0cb4e7004ed1a0e4104c8804780 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Aug 29, 2012 at 1:25 AM, Stephen= Kent <kent@bbn.com> wrote:
Brian,

As I mentioned in my rely to Eric, I think this is a topic to be addressed = in an RPKI
operational considerations doc. We have draft-ietf-sidr-origin-ops-19 in pr= ogress now,
so I suggest you discuss this with the author of that doc. Nonetheless, I&#= 39;ll offer my
views on a few of the topics you mentioned:

...

What model for the processes of maintaining sync between INR and RPKI shoul= d be followed? A high-level finite state machine (FSM) model should be an e= ventual goal, so that implementors have a crystal clear model to follow.
I rarely see FSMs in RFCs these days, although I agree that they are valuab= le in many contexts. Do
we have an FSM for IRR data use by RPs?

I don't know about FSM _diagram, but the RIPE database (whi= ch includes not only IRR data but also authoritative INR data and RPKI data= ), is fully documented here:
And in partic= ular the manual, including how a request turns into an "inetnum" = (and RPKI object, now) is here:

The= language used in the objects, RPSL, is memorialized here:
(Published in 1999,=A0updated by:=A0http://tools.ietf.org/html/rfc4012)

The history of the IRRs, language, and tools, is well d= ocumented here:

And it might be well noted, that the RADB dates back to the Routing Ar= biter project, and to its predecessor-in-interest (PRDB) which predates BGP= version 4. RIPE-81 -> RIPE-181 -> RPSL.

But, as author or co-author of several SIDR docs, I'm presuming you'= ;re already familiar with the above?
You wouldn't really try = implementing a system for (securely) registering internet routing informati= on, without being completely familiar with prior art in the field, would yo= u?

Brian

--e0cb4e7004ed1a0e4104c8804780-- From christopher.morrow@gmail.com Thu Aug 30 12:23:21 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6563E21F852B for ; Thu, 30 Aug 2012 12:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vDpywgkBrYi for ; Thu, 30 Aug 2012 12:23:21 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C4DB121F851E for ; Thu, 30 Aug 2012 12:23:20 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so2754309vcb.31 for ; Thu, 30 Aug 2012 12:23:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=0dCt+E/MwV4fcVnhyWU9DD35MA71wnx8ndc+KMYfUBk=; b=aNh9HLSHTuCgwuQifhxe1NPFZviExx+2BpbXhY3Tq5Nbnk00v/geG/ki+Gey6dL0K0 Im3YOX04Msyu5PScRlWyTZZ1x61U0aqtEsW5ufbAnmmL8OT5KmpyJ8ffdtSYgLlFIHBr VfP9WOtwNLmfyEjKtR6DT+47/MJqFz4BUx7WHIHsVF+9UvLyhQNjd5YHu9hntKXfT0RF sjTjg7JHAlTfE7avrTqeOsZu48uoNFOzzjYsFofquTTktDTEF5gpENanug00LGIhuJ8C iXgwEQqI+RSVJcUM9Q4P3/20CvvUzT60GXQYMg81yfJ7a7bC4nM6kKBFCsni2iukdtO9 k55g== MIME-Version: 1.0 Received: by 10.52.35.99 with SMTP id g3mr3265102vdj.21.1346354597024; Thu, 30 Aug 2012 12:23:17 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.58.216.42 with HTTP; Thu, 30 Aug 2012 12:23:16 -0700 (PDT) In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F625F555CB@Hermes.columbia.ads.sparta.com> <50389897.3040503@bbn.com> <97856400-9F70-4AEC-AF91-A0673A6D716D@verisign.com> <503C47A8.7030700@bbn.com> <303C576D-D1F8-4F62-8E0E-0D74A28B2771@verisign.com> <503D141F.1060404@bbn.com> <3A791D9E-4F16-4481-94AE-BD38A5389593@verisign.com> Date: Thu, 30 Aug 2012 15:23:16 -0400 X-Google-Sender-Auth: yevPOBt5coHpY9p7s3rvmuoF91w Message-ID: From: Christopher Morrow To: Brian Dickson Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr@ietf.org Subject: Re: [sidr] RPKI <-> allocation consistency X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 19:23:21 -0000 On Thu, Aug 30, 2012 at 2:30 PM, Brian Dickson wrote: > (2) If INRs are meant to be exclusive, why does the RPKI not enforce that > exclusivity? more than one origin ASN may be valid for a single prefix? From aservin@lacnic.net Thu Aug 30 13:13:49 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D10C21F84A2 for ; Thu, 30 Aug 2012 13:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.047 X-Spam-Level: X-Spam-Status: No, score=-1.047 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNSDve-MiWKT for ; Thu, 30 Aug 2012 13:13:48 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 760CE21F847D for ; Thu, 30 Aug 2012 13:13:48 -0700 (PDT) Received: from 85-7-200.lacnic.net.uy (unknown [200.7.85.90]) by mail.lacnic.net.uy (Postfix) with ESMTP id 0E04D308453; Thu, 30 Aug 2012 17:13:10 -0300 (UYT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_9836744F-DDC2-40A6-B433-55A621DE67E6" From: Arturo Servin In-Reply-To: Date: Thu, 30 Aug 2012 16:12:41 -0400 Message-Id: References: <24B20D14B2CD29478C8D5D6E9CBB29F625F555CB@Hermes.columbia.ads.sparta.com> <50389897.3040503@bbn.com> <97856400-9F70-4AEC-AF91-A0673A6D716D@verisign.com> <503C47A8.7030700@bbn.com> <303C576D-D1F8-4F62-8E0E-0D74A28B2771@verisign.com> <503D141F.1060404@bbn.com> <3A791D9E-4F16-4481-94AE-BD38A5389593@verisign.com> To: Christopher Morrow X-Mailer: Apple Mail (2.1278) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: sidr@ietf.org Subject: Re: [sidr] RPKI <-> allocation consistency X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 20:13:49 -0000 --Apple-Mail=_9836744F-DDC2-40A6-B433-55A621DE67E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think at least different RIRs have different time to publish = ROAs and certificates. At least from our side it was a decision taken long ago and if = we needed to change it to help the world to be a happier place we could = do it. Regards, as=09 On 30 Aug 2012, at 13:17, Christopher Morrow wrote: > 3) should this set of numbers apply to ALL objects in the RPKI > equally? or should some object types have different timing > requirements? --Apple-Mail=_9836744F-DDC2-40A6-B433-55A621DE67E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I think at least different RIRs = have different time to publish ROAs and = certificates.

At least from our side it was a = decision taken long ago and if we needed to change it to help the world = to be a happier place we could do = it.

Regards,
as =

On 30 Aug 2012, at 13:17, Christopher Morrow = wrote:

 3) = should this set of numbers apply to ALL objects in the RPKI
equally? = or should some object types have different = timing
requirements?

= --Apple-Mail=_9836744F-DDC2-40A6-B433-55A621DE67E6-- From brian.peter.dickson@gmail.com Fri Aug 31 05:34:41 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7D921F8602 for ; Fri, 31 Aug 2012 05:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.348 X-Spam-Level: X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTTTXMIxvm0K for ; Fri, 31 Aug 2012 05:34:40 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 786C421F85C7 for ; Fri, 31 Aug 2012 05:34:40 -0700 (PDT) Received: by weyu54 with SMTP id u54so1755413wey.31 for ; Fri, 31 Aug 2012 05:34:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=n6dZpkPlAJjfi7aXkyj3prYeWfcFhDdZP37TV/szFrE=; b=JXzz2lJZ0JNXIGlgRkRSsKCOE6Y3Ipf+VKubLabrn5sGAmQVHxhoANgzNGyv7NEEkh KSa6sDPGL3z+xebBB+FchJt8IKyjNHxFG8gXQqlFSie2MWBmqqdq3ey+Z1kKte6MONu+ zw5E92BTnJj1NS1+DmfUIRWDYQc4TyqKc9/qOq/DcVDXqKDTPHBqVIDNeC1HnUSIGTn0 t2b+Qd7yzvFDvl4t9lxgfeDyBQSJl4O3/OJs+wVKHw1Q08zpUmIkXuAfaq1XOfpusmzo 1rJ1ijGnP24M76zDY8pZkt5jE331sDOzNyNBfH++1FrK3z73z/zC8ODeMDCwO2+1r4/p UxTQ== MIME-Version: 1.0 Received: by 10.180.86.3 with SMTP id l3mr4383770wiz.16.1346416479335; Fri, 31 Aug 2012 05:34:39 -0700 (PDT) Received: by 10.223.61.12 with HTTP; Fri, 31 Aug 2012 05:34:39 -0700 (PDT) In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F625F555CB@Hermes.columbia.ads.sparta.com> <50389897.3040503@bbn.com> <97856400-9F70-4AEC-AF91-A0673A6D716D@verisign.com> <503C47A8.7030700@bbn.com> <303C576D-D1F8-4F62-8E0E-0D74A28B2771@verisign.com> <503D141F.1060404@bbn.com> <3A791D9E-4F16-4481-94AE-BD38A5389593@verisign.com> Date: Fri, 31 Aug 2012 08:34:39 -0400 Message-ID: From: Brian Dickson To: Christopher Morrow Content-Type: multipart/alternative; boundary=f46d044303faf8768504c88f0380 Cc: sidr@ietf.org Subject: Re: [sidr] RPKI <-> allocation consistency X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 12:34:41 -0000 --f46d044303faf8768504c88f0380 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 30, 2012 at 3:23 PM, Christopher Morrow wrote: > On Thu, Aug 30, 2012 at 2:30 PM, Brian Dickson > wrote: > > (2) If INRs are meant to be exclusive, why does the RPKI not enforce that > > exclusivity? > > more than one origin ASN may be valid for a single prefix? > In the same paragraph you snip-quoted, was the following: (Note here - the presumption is not uniqueness by ASN, but uniqueness by organization controlling ROA assignment, where that single org could/would issue ROAs for multiple ASNs.) Same org == same CA. So, does it not make sense that the RPKI, meaning its design, architecture, procedures, etc., should actually enforce exclulsivity? This is pretty fundamental to the number resource tree, and to routing validation. If this is a design flaw in the RPKI, I think it is one that needs to be addressed. Since origin validation is dependent on the RPKI and its validation rules, it's kind of "square one" for all things SIDR. Brian --f46d044303faf8768504c88f0380 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Aug 30, 2012 at 3:23 PM, Christo= pher Morrow <morrowc.lists@gmail.com> wrote:
On Thu, Aug 30, 2012 at 2:30 PM, Brian Dickson
<brian.peter.dickson@gm= ail.com> wrote:
> (2) If INRs are meant to be exclusive, why does the RPKI not enforce t= hat
> exclusivity?

more than one origin ASN may be valid for a single prefix?

In the same paragraph you snip-quoted, was the follo= wing:
(Note here - the presumption is not uniqueness by ASN, but uniquen= ess by organization controlling ROA assignment, where that single org=20 could/would issue ROAs for multiple ASNs.)

Same org =3D=3D same CA.<= br>
So, does it not make sense that the RPKI, meaning its design, archit= ecture, procedures, etc., should actually enforce exclulsivity?

This= is pretty fundamental to the number resource tree, and to routing validati= on.

If this is a design flaw in the RPKI, I think it is one that needs to b= e addressed.

Since origin validation is dependent on the RPKI and it= s validation rules, it's kind of "square one" for all things = SIDR.

Brian
--f46d044303faf8768504c88f0380-- From tim@ripe.net Fri Aug 31 06:24:19 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C2521F855D for ; Fri, 31 Aug 2012 06:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIu2y442HVVw for ; Fri, 31 Aug 2012 06:24:18 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 5160F21F848B for ; Fri, 31 Aug 2012 06:24:18 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1T7RCm-0003LJ-C2; Fri, 31 Aug 2012 15:24:17 +0200 Received: from s258-sslvpn-1.ripe.net ([193.0.20.231] helo=vpn-136.ripe.net) by dodo.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1T7RCm-0003Nu-4i; Fri, 31 Aug 2012 15:24:12 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-11-892548278 From: Tim Bruijnzeels In-Reply-To: Date: Fri, 31 Aug 2012 15:24:11 +0200 Message-Id: <40FB7E48-E808-4FC7-9458-E236FB356EC7@ripe.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F555CB@Hermes.columbia.ads.sparta.com> <50389897.3040503@bbn.com> <97856400-9F70-4AEC-AF91-A0673A6D716D@verisign.com> <503C47A8.7030700@bbn.com> <303C576D-D1F8-4F62-8E0E-0D74A28B2771@verisign.com> <503D141F.1060404@bbn.com> <3A791D9E-4F16-4481-94AE-BD38A5389593@verisign.com> To: Brian Dickson X-Mailer: Apple Mail (2.1084) X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816066, check: 20120831 clean X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719a85578b6760c40726855bd43b9d10a6c Cc: sidr@ietf.org Subject: Re: [sidr] RPKI <-> allocation consistency X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 13:24:19 -0000 --Apple-Mail-11-892548278 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 31 Aug 2012, at 14:34, Brian Dickson wrote: > So, does it not make sense that the RPKI, meaning its design, = architecture, procedures, etc., should actually enforce exclulsivity? I think that INRs appearing on certs in multiple locations, different = TAs, or different branches, are not really a *technical* problem. = Meaning that if these certs are used to sign objects they are just = complementary. It doesn't matter whether one CA signs a set of objects = or the same set (content) is signed by multiple CAs. Plus, this feature = is actually needed when doing make-before-break transfers of live = networks. Of course it's important that information is correct. But the notion = that uniqueness of resources in the tree guarantees correctness seems = fundamentally flawed to me. Correctness is assumed by transitive trust = placed in the TA(s), and can only be manually verified by comparing = certs to public registration databases. Regards, Tim= --Apple-Mail-11-892548278 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii So, does it = not make sense that the RPKI, meaning its design, architecture, = procedures, etc., should actually enforce = exclulsivity?

I think that INRs appearing on certs in multiple = locations, different TAs, or different branches, are not really a = *technical* problem. Meaning that if these certs are used to sign = objects they are just complementary. It doesn't matter whether one CA = signs a set of objects or the same set (content) is signed by multiple = CAs. Plus, this feature is actually needed when doing make-before-break = transfers of live networks.
Of course it's = important that information is correct. But the notion that = uniqueness of resources in the tree guarantees correctness seems = fundamentally flawed to me. Correctness is assumed by transitive trust = placed in the TA(s), and can only be manually verified by comparing = certs to public registration databases.

Regards,
Tim
= --Apple-Mail-11-892548278-- From brian.peter.dickson@gmail.com Fri Aug 31 07:13:00 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4299621F8459 for ; Fri, 31 Aug 2012 07:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.369 X-Spam-Level: X-Spam-Status: No, score=-3.369 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uzLHGB6YLnC for ; Fri, 31 Aug 2012 07:12:59 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 012A121F8458 for ; Fri, 31 Aug 2012 07:12:58 -0700 (PDT) Received: by weyu54 with SMTP id u54so1817643wey.31 for ; Fri, 31 Aug 2012 07:12:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iPLUjzeSsAYXD5pWyuyn3v0Pon/78DYG6Xlr+OVMnGk=; b=z1qnXTyPb89F2thff2UdXGKuEUeLzo0iC8YGA+rWC8nPkEla/C++cp87z5ARZNa4a9 gd6W9SN3eOCgjr5+EkiVvrVf47t5J4UH16Y8avLUQbpe7j9Vwy7BoMUb6iNOuscytV6T kvaN2WRRkhDRF9etd+AuX96j5jxWbvwmom06MxJE02dFOwMvBbg7DGHNzao9tW1IznWZ AX7an/YmppViRrMCrLCZBEaV3X/Dh75/QtqN62W0ZL4LKcIgKDwO5venDSTvk7oWfzWh x0ulvrww6rXvESMB2Vq5kyvhDSXp22B/1pNRCLtuh0v0Q8P/AqVk8uYlQ1WkX3VmdoVR X4YQ== MIME-Version: 1.0 Received: by 10.216.245.70 with SMTP id n48mr4584707wer.139.1346422378106; Fri, 31 Aug 2012 07:12:58 -0700 (PDT) Received: by 10.223.61.12 with HTTP; Fri, 31 Aug 2012 07:12:57 -0700 (PDT) In-Reply-To: <40FB7E48-E808-4FC7-9458-E236FB356EC7@ripe.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F555CB@Hermes.columbia.ads.sparta.com> <50389897.3040503@bbn.com> <97856400-9F70-4AEC-AF91-A0673A6D716D@verisign.com> <503C47A8.7030700@bbn.com> <303C576D-D1F8-4F62-8E0E-0D74A28B2771@verisign.com> <503D141F.1060404@bbn.com> <3A791D9E-4F16-4481-94AE-BD38A5389593@verisign.com> <40FB7E48-E808-4FC7-9458-E236FB356EC7@ripe.net> Date: Fri, 31 Aug 2012 10:12:57 -0400 Message-ID: From: Brian Dickson To: Tim Bruijnzeels Content-Type: multipart/alternative; boundary=e0cb4e43d033908e6104c890634a Cc: sidr@ietf.org Subject: Re: [sidr] RPKI <-> allocation consistency X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 14:13:00 -0000 --e0cb4e43d033908e6104c890634a Content-Type: text/plain; charset=ISO-8859-1 On Fri, Aug 31, 2012 at 9:24 AM, Tim Bruijnzeels wrote: > Hi, > > On 31 Aug 2012, at 14:34, Brian Dickson wrote: > > So, does it not make sense that the RPKI, meaning its design, > architecture, procedures, etc., should actually enforce exclulsivity? > > > I think that INRs appearing on certs in multiple locations, different TAs, > or different branches, are not really a *technical* problem. Meaning that > if these certs are used to sign objects they are just complementary. It > doesn't matter whether one CA signs a set of objects or the same set > (content) is signed by multiple CAs. Plus, this feature is actually needed > when doing make-before-break transfers of live networks. > > I think maybe it would help to do a worked example (straw man), on an example where a live network would be transitioned from one CA to another (versus one ASN to another). Do you have an example in mind? I think distinguishing PI vs PA (semantic attributes, but necessarily something to consider) in detailing the straw man would help. Are you thinking of situations where the owner (organization) changes but the announcing ASN does not? Or where the ASN changes but the owner (organization) does not? Or where both owner and ASN change? Thanks, Brian > Of course it's important that information is correct. But the notion that > uniqueness of resources in the tree guarantees correctness seems > fundamentally flawed to me. Correctness is assumed by transitive trust > placed in the TA(s), and can only be manually verified by comparing certs > to public registration databases. > If correctness cannot be confirmed via automated mechanism, this is a fatal scaling flaw. Or do you mean that this is a corollary of the uniqueness? In which case, I don't see how you reach that conclusion, and it would be helpful to show the steps in getting there. Brian P.S. I'm arguing not only uniqueness, but completeness, i.e. that the entire number space must be enumerated, where the state of every number or block in the space is well defined, and no overlaps occur. Enumeration would need to occur at each "manifest" level, as either "ROA", "used but no ROA", "reserved (bogon)", "unassigned", or "delegated", with corresponding references to actual signed objects. And enumeration must be specifically possible with minimal cost/effort, so that RPs can confirm the uniqueness (via the ROA validation prior to rpki-rtr). --e0cb4e43d033908e6104c890634a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Aug 31, 2012 at 9:24 AM, Tim Bru= ijnzeels <tim@ripe.net> wrote:
Hi,

On 31 Aug 2012, at 14:34, Brian Dickson wrote:
So, does it not make sense that the RPKI, meaning its design, arc= hitecture, procedures, etc., should actually enforce exclulsivity?

I think that=A0INRs appearing on certs in multiple= locations, different TAs, or different branches, are not really a *technic= al* problem. Meaning that if these certs are used to sign objects they are = just complementary. It doesn't matter whether one CA signs a set of obj= ects or the same set (content) is signed by multiple CAs. Plus, this featur= e is actually needed when doing make-before-break transfers of live network= s.


I think maybe it would help to do a worked examp= le (straw man), on an example where a live network would be transitioned fr= om one CA to another (versus one ASN to another).

Do you have an example in mind?

I think distinguishing PI vs PA (semantic attributes, but necessarily som= ething to consider) in detailing the straw man would help.

Are you thinking of situations where the owner (organization) ch= anges but the announcing ASN does not?
Or where the ASN changes b= ut the owner (organization) does not?
Or where both owner and ASN= change?

Thanks,
Brian


=A0
Of course it's important that information = is correct. But the=A0notion that uniqueness of resources in the tree guara= ntees correctness seems fundamentally flawed to me. Correctness is assumed = by transitive trust placed in the TA(s), and can only be manually verified = by comparing certs to public registration databases.

If correctness ca= nnot be confirmed via automated mechanism, this is a fatal scaling flaw.

Or do you mean that this is a corollary of the uniqu= eness? In which case, I don't see how you reach that conclusion, and it= would be helpful to show the steps in getting there.

Brian=A0

P.S. I'm arguing = not only uniqueness, but completeness, i.e. that the entire number space mu= st be enumerated, where the state of every number or block in the space is = well defined, and no overlaps occur. Enumeration would need to occur at eac= h "manifest" level, as either "ROA", "used but no = ROA", "reserved (bogon)", "unassigned", or "d= elegated", with corresponding references to actual signed objects. And= enumeration must be specifically possible with minimal cost/effort, so tha= t RPs can confirm the uniqueness (via the ROA validation prior to rpki-rtr)= .
--e0cb4e43d033908e6104c890634a-- From Sandra.Murphy@sparta.com Fri Aug 31 08:12:48 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6E7B21F84EA for ; Fri, 31 Aug 2012 08:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vV6h+qDQ1dYW for ; Fri, 31 Aug 2012 08:12:47 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC6621F84E4 for ; Fri, 31 Aug 2012 08:12:47 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q7VFCkZ4003157 for ; Fri, 31 Aug 2012 10:12:46 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q7VFCjS6021315 for ; Fri, 31 Aug 2012 10:12:46 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%21]) with mapi id 14.01.0355.002; Fri, 31 Aug 2012 11:13:28 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: reminder of wglc in progress Thread-Index: Ac2GAVvrRyGnUU9eQJuEreoXSUNvYgBiTwVm Date: Fri, 31 Aug 2012 15:13:27 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F68821@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F67351@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F67351@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] reminder of wglc in progress X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 15:12:49 -0000 Another nag. The mib document in particular has received little attention.= =0A= =0A= Remember - silence is not support. If you think the topic is important, lo= ok at the draft and say whether you believe it is ready for publication.=0A= =0A= --Sandy=0A= ________________________________________=0A= From: Murphy, Sandra=0A= Sent: Wednesday, August 29, 2012 12:14 PM=0A= To: sidr@ietf.org=0A= Subject: reminder of wglc in progress=0A= =0A= A reminder that there are three wglc in progress:=0A= =0A= http://www.ietf.org/mail-archive/web/sidr/current/msg04987.html=0A= http://www.ietf.org/mail-archive/web/sidr/current/msg04988.html=0A= http://www.ietf.org/mail-archive/web/sidr/current/msg04989.html=0A= =0A= Silence does not count as support for publication, so please do take a look= at these drafts and respond.=0A= =0A= --Sandy=0A= From christopher.morrow@gmail.com Fri Aug 31 20:43:08 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE4F21F8440 for ; Fri, 31 Aug 2012 20:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MagWZmCA9WXt for ; Fri, 31 Aug 2012 20:43:07 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7BB21F843C for ; Fri, 31 Aug 2012 20:43:06 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so4508776vcb.31 for ; Fri, 31 Aug 2012 20:43:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=pzPy3aRL+XEe0ivITwZ7cuH2fAFJd6Rfi6nQkqyPHBQ=; b=MEndJBkGfNfQzYZXkuL1zN8kCzXmWDeNuHC2wTH+e1MmOSSNG/GK15qF/Dtn0B5Go9 pQSaivz8dXGekBilpveOkKmjQD40LArwGWrKuJtpWCiATezR5n+E19d0EVwNFJgpEUnX 3f4Rc+vWfOlN/Lz4Xs27CQV9CxCD4SUYo8TkqoQXO1GbYBFfWy8rCxDGS5WAS2TpBq2y KUK9J1WByUo4VjBv0CeSoSlUmmJYgdNvvzymvOLAXlN6PMdr/xhMTBL2lfswfjPd5R/K CmbfQjL2QcAuum/ckH84WhkwhRIVwvlle2MfnEvLpjbKg05ndPQdRSZL7PB3qVzeAZXU sBoA== MIME-Version: 1.0 Received: by 10.52.88.18 with SMTP id bc18mr5645469vdb.99.1346470985615; Fri, 31 Aug 2012 20:43:05 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.58.216.42 with HTTP; Fri, 31 Aug 2012 20:43:05 -0700 (PDT) In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F625F555CB@Hermes.columbia.ads.sparta.com> <50389897.3040503@bbn.com> <97856400-9F70-4AEC-AF91-A0673A6D716D@verisign.com> <503C47A8.7030700@bbn.com> <303C576D-D1F8-4F62-8E0E-0D74A28B2771@verisign.com> <503D141F.1060404@bbn.com> <3A791D9E-4F16-4481-94AE-BD38A5389593@verisign.com> Date: Fri, 31 Aug 2012 23:43:05 -0400 X-Google-Sender-Auth: T6Ln0Ye0TE2719TFlV7qwPjb5Bk Message-ID: From: Christopher Morrow To: Brian Dickson Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr@ietf.org Subject: Re: [sidr] RPKI <-> allocation consistency X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2012 03:43:08 -0000 On Fri, Aug 31, 2012 at 8:34 AM, Brian Dickson wrote: > So, does it not make sense that the RPKI, meaning its design, architecture, > procedures, etc., should actually enforce exclulsivity? see tim's note.